Gerhard, As projects like those we mentioned found certain aspects of DeltaSpike (or Spring Configuration) inspirational but not sufficient for their project they just don''t use it. And hence won't bother raising issues on a mailing list of something they are not using ;-) Besides, I don't have time to file an issue but there's a broken link in the JavaDoc for a long time now: http://deltaspike.apache.org/javadoc/1.7.2-SNAPSHOT/ does not work, only http://deltaspike.apache.org/javadoc/1.7.1/ does.
The proven fact is, org.apache.deltaspike.core.api.projectstage may be a nice improvement over the very limited JSF construct (working with JSF a lot I guess you know, and probably also remember I told this to Ed numerous times in the JSF EG;-) but a "project stage" like Dev, Test, UAT, etc. is not the same as real multi-tenancy. And unlike e.g. a simple but more flexible construct of a "Profile" in Spring you'd have to abuse the term "stage" to get remotely something to cover tenant, service, release, etc. You improved over JSF, and I'm sure, there are projects who welcome that, but other solutions and framework are more simple and versatile with that respect. Hence more popular and used. Which is why e.g. the idea of similar terms in Tamaya like "Environment", "Stage", etc. was dismissed. That doesn't mean it should not have something to handle multiple "dimensions" where JSF or DeltaSpike (or e.g. Wicket) only handle one. Regards, Werner On Sun, Jul 31, 2016 at 2:33 PM, Gerhard Petracek <gpetra...@apache.org> wrote: > @werner: > the comments e.g. about deltaspike-config for > microservices/multi-tenancy/... are proven to be wrong (proven by real > projects in production). > >afair< we haven't seen any question about issues with such topics (on the > deltaspike-lists). > we can't help if nobody asks, however, that doesn't mean that there is a > limitation. > -> i would prefer discussions based on proven facts which are more to the > point. > > regards, > gerhard > > > > 2016-07-30 23:30 GMT+02:00 Werner Keil <werner.k...@gmail.com>: > > > Lars, > > > > Thanks a lot for your input. Of course we have a few people with a strong > > financial background including Anatole who worked in a bank for many > years > > or myself. > > Right now I help a major bank with their Java EE and Spring-based > solutions > > and there are also quite a few Apache projects like Wicket involved on > the > > front end. > > > > At the moment we're not yet dealing with the configuration part and where > > we do, I am pretty sure this client will leverage Spring. > > A while ago in another large financial project pretty much everything > Java > > EE has to offer from CDI to JPA, Bean Validation or JBatch was used. And > > that project also applied a very fine grained separation of services in a > > "Microservice" style. So unlike marketing fuzz created by many vendors > > (Spring/Pivotal also does a lot;-) Java EE applied correctly is usually > > more than enough for a Microservice type project. > > > > Similar to what you described in your banking solution, frameworks and > > libraries created there were inspired by e.g. Tamaya or DeltaSpike, but > did > > not use them. > > With Tamaya it was mainly because of Incubation. Should it remain useful > to > > real projects like yours or others, the guys in this project would likely > > use it if it left incubation. > > With DeltaSpike it simply didn't meet its requirements. Lacking support > for > > Microservices or multi-tenancy which is why they chose to write their > own, > > quite similar to what you described or feeling not too different from > e.g. > > Spring Config with annotations like @Configuration or @Configurable but > > suitable for their needs, e.g. a fine grained separation of environments > > and also security aspects Java failed to standardize as of now (some were > > identified by JSR 375 as relevant, but let's not go there here now) > > > > It is important to get a "reality check" from participants like yourself. > > And without proper vendor involvement it also won't see much adoption I'm > > afraid. > > I worked with Java ever since it exists everywhere from Java ME Embedded > to > > Java EE (the only thing I didn't do so far is JavaCard) > > After writing even an entire application server based on EJB 1 and what > > "J2EE 1" had to offer in 1998 (I was also at the JavaOne when Sun > unveiled > > it) for a pension fund I worked with every of the major vendors. Often in > > the same team as e.g. Oracle, IBM or BEA consultants. The result of some > of > > that work went into standards like Portlet 1 or Java Content Repository > > (both BEA and Day, now Adobe were in that project, so even then some > > standards were derived from real client projects) > > > > Around 10 years ago I helped BEA Systems directly with their Professional > > Services teams and in the UK support center. The only external freelance > > consultant for the entire EMEA region. Our team manager had many > interviews > > with candidates either contract or permanent, but he always said, they > did > > not have my experience. So until the Oracle takeover I stayed the only > > freelancer there. > > With that background (e.g. after Oracle took over BEA the same manager > > reported to Adam Messinger, now CTO at Twitter, he was working for the > > original Weblogic company before that became part of BEA;-) and nearly a > > decade of JCP EC work now, I came across many interesting challenges. > E.g. > > the CDI you know now based on later proposed JSR 330 (@Inject) was born > > from a serious amount of friction between Google, SpringSource (not so > > active though) and JBoss/Red Hat. Mike Keith whom I knew well from > Eclipse > > and JPA work kindly offered to mediate. I was also involved from the JCP > EC > > side and due to being in the EE 6 Umbrella JSR, too. You may find some of > > those discussions in Google Groups or Google Code Forums unless Google > shut > > down the latter now. Maybe some also happened in the earliest CDI > > discussion forums. > > > > If you think any of the discussions I'm aware of here are harsh, you have > > not seen those arguments. Some technically, others simply fuelled by > vanity > > like (that's supposed to be in our JSR, not yours;-) You have to ask > Mark, > > if similar "vanity" is involved here, too. In a few threads I did sense a > > bit of that "don't compete with DeltaSpike" but I don't think it was Mark > > btw. And proposing "Yet another configuration API" pretending it was a > JSR > > did not sound like considering DeltaSpike the ultimate answer to all > > configuration questions either. > > I cannot say if a common standard developed under the JCP or a similar > body > > will end up entirely based on annotations or not. The most commonly used > > alternatives like Spring Config are mostly used via annotations. > DeltaSpike > > offers some aspects and the in-house framework you mentioned and others > > also have seen at their customers also do. > > Separating the underlying "value holder" (Configuration interface) from > > usage by annotations like Spring (or Mike Keith also envisioned) I'd say > > Tamaya got pretty right already. > > > > Spring is not famous for its proper separation of "API" and > > "Implementation". Unlike CDI and many other JSRs it is not a standard > > specified by any place like ISO, ETSI, OASIS or JCP, so it does not see > the > > need for that. Nevertheless it allows to use @Inject and other standards > in > > many areas now. > > So if a standard was created by somebody it would not be bad to also get > > them involved or use some of it. > > Spring Data or Spring Integration also make use of JSR 354 now btw, so if > > such standard for configuration did not contradict everything it does > with > > its config frameworks, I see no reason why they should not be interested > in > > something like this. > > > > The only strong words you may have heard by me in this discussion was > about > > Mark's panic reaction and clear abuse of the JCP branding and package > > names. > > He's a JCP member himself and by doing so he violated and jeopardized his > > membership. Other fellow JCP EC members like the LJC reps who saw his > > announcement e.g. on the Microprofile list also urged him to fix this or > > delete the codebase and the PMO was ready to "unleash the blood hounds" > had > > we not both confirmed that he at least changed the incriminating package > > name. > > > > Other than that like you and I'm sure enough others I hope Tamaya becomes > > "useful". Simple or modular into smaller chunks is not bad. Working with > > small and Embedded systems a lot,too I understand better than many "Pure > EE > > developers" how important size can be. > > However, the idea behind creating Tamaya was neither to directly compete > > with DeltaSpike or Commons Configuration, nor to create a JSR there > > already. > > Having a separation between API and implementation helps, under certain > > circumstances Tamaya could even offer to be an RI for a possible > standard, > > but it's supposed to be the PoC for one or more configuration use cases, > > not the JSR. > > > > Hope everyone understands that? > > > > Regards, > > Werner > > > > > > > > > > On Sat, Jul 30, 2016 at 1:16 PM, Lars-Fredrik Smedberg < > itsme...@gmail.com > > > > > wrote: > > > > > Hi > > > > > > I've been following the discussions the last couple of week(s) and I > must > > > admit that it has both been interesting and frustrating. Interesting > > > because I always like to see how different people choose to solve the > > same > > > or similar problems, frustrating because I (personally) feel that the > > tone > > > in the emails has been more than once or twice kindof harsh (from all > > sides > > > if I may call it "sides") and to me sometimes without a reaso... > > > > > > I would have loved to be more involved in Tamaya or the discussions > going > > > on about configuration in general, my excuse (accept it or not :)) is > > that > > > I > > > work full time, takes care of my company, house and two kids on my own. > > > More on that over a beer or two if we ever meet :) > > > > > > I'm not sure who will be on the meetups but it would be nice / > > interesting > > > to either listen in / take part of them or at least the result of them. > > Who > > > knows, I might have some input that will help :) > > > > > > I've been working with Java for 20 years now, mostly as a consultant > but > > > also started companies developing products for the financial industry > > > (mostly derivatives trading, post trade systems). I wouldn't call me an > > > expert but I've seen alot of code and done alot of development during > the > > > years. > > > > > > Been working as a consultant for banks for a long time now and lately > > with > > > a customer where I'm involved in developing a "platform" for making it > > easy > > > for developers to develop bank applications, the platform takes care of > > > (implicitly or explicitly depening on the functionality) all things > that > > a > > > bank applications needs such as audit, security, logging etc. The > > framework > > > tries to be up to date with JEE and Java (that includes many of the JEE > > > related technologies sich as CDI, JAX-RS, JAX-WS, Bean validation and > so > > > on....). > > > > > > Typically a "bank application" is developed by a team and/or maintained > > by > > > a team of people. In an appserver there can be many "bank applications" > > > running each requiring their configuration. When were going to look at > > > enhancing the way configuration were done we took a look at Tamaya but > > > still decided to write our own (partly inspired by Tamaya) > configuration > > > framework. Some of the features we needed I did not find in Tamaya (or > > > maybe I didn't understand how to implement them using Tamaya), we also > > > needed a nice API towards the bank application developers (which > ofcourse > > > could have been done on top of Tamaya) but the main reason for rolling > > our > > > own solution was that we felt it hard to understand how to use Tamaya > > > (maybe due to its flexibility, or maybe the documentation at the early > > > stage of development, I cannot tell exactly what part that made us > choose > > > to not use it...). > > > > > > Some of the features we have in our solution are: > > > > > > - API towards the bank application that is annotation based > > > (@ApplicationConfiguration(property=...) and supports different types > > such > > > as String, Number derivatives and so on (in the configuration it is all > > > string->string) > > > - Bank applications each have their set of configuration properties > > > (META-INF/conf/<application> > > > - Configuration for the platform can be used by bank applications but > not > > > overriden by them > > > - All configuration can be set/overriden by operations who are > > responsible > > > for the servers > > > - Overriding can be done using ordinals, this can also be done withing > an > > > application if it contains multiple modules (not all modules might be > > used > > > for all installations) > > > - Resolving using proprerty placeholder (if needed) syntax within the > > > properites themselves but also withing e.g. XML files read by > > applications > > > - Properties can be placed in property files under META-INF... an but > > also > > > in environment entries, system properties, context/jndi etc > > > - The resolving can make use of wether the server is a test server > > > (functional, integration, production test, production), wether its > > internal > > > or external (different network zones, security mechanisms and so on) > and > > so > > > on.. the configuration can therefor be written once (and only one bank > > > application artifact needs to be built) and used throughout the testing > > > process until (and including) it reaches production > > > - ...and more things... > > > > > > The solution itself is very small but fulfills our needs and is simple > to > > > use for the bank application developers. > > > > > > Thanks > > > > > > Regards > > > LF > > > > > > > > > On Tue, Jul 26, 2016 at 11:01 AM, Werner Keil <werner.k...@gmail.com> > > > wrote: > > > > > > > Also seen among many others in CDI where > > > > javax.enterprise.inject.spi.CDIProvider is an SPI element to allow > > access > > > > to what's the only static accessor in CDI, the class with the same > > name, > > > > not a static factory itself;-) > > > > > > > > > > > > On Tue, Jul 26, 2016 at 10:36 AM, Werner Keil <werner.k...@gmail.com > > > > > > wrote: > > > > > > > > > The name IMO is. A static facade "ConfigurationProvider" is > > misleading > > > > > because its naming pattern overlaps with SPI elements commonly > named > > > > > *Provider everywhere (especially in JSRs, not every other > "framework" > > > > > popular or not even makes a distinction between API and SPI;-) > > > > > > > > > > Seems DeltaSpike brought that antipattern into Tamaya since there's > > at > > > > > least one "provider" package with static facade singletons. If > Tamaya > > > can > > > > > live with that, then why not in this Apache PoC. Neither Tamaya nor > > > > > DeltaSpike or Spring will be a 1:1 blueprint for a future standard > we > > > > > probably see at least after JavaOne based on what Oracle plans for > > > "Java > > > > EE > > > > > in the Cloud". > > > > > > > > > > Cheers, > > > > > Werner > > > > > > > > > > > > > > > On Tue, Jul 26, 2016 at 8:21 AM, Mark Struberg > > > <strub...@yahoo.de.invalid > > > > > > > > > > wrote: > > > > > > > > > >> That's how it used to be since pretty much almost the beginning. > > > > >> And that part was also not in question imo. > > > > >> > > > > >> > > > > >> LieGrue, > > > > >> strub > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > On Thursday, 21 July 2016, 16:02, Anatole Tresch < > > > atsti...@gmail.com> > > > > >> wrote: > > > > >> > > yep... > > > > >> > > > > > >> > 2016-07-21 14:08 GMT+02:00 Werner Keil <werner.k...@gmail.com>: > > > > >> > > > > > >> >> Anatole/all, > > > > >> >> > > > > >> >> So ConfigurationProvider boils down to just a > getConfiguration() > > > > >> method > > > > >> >> now? > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Med vänlig hälsning / Best regards > > > > > > Lars-Fredrik Smedberg > > > > > > STATEMENT OF CONFIDENTIALITY: > > > The information contained in this electronic message and any > > > attachments to this message are intended for the exclusive use of the > > > address(es) and may contain confidential or privileged information. If > > > you are not the intended recipient, please notify Lars-Fredrik Smedberg > > > immediately at itsme...@gmail.com, and destroy all copies of this > > > message and any attachments. > > > > > >
