It's not there in DeltaSpike, while e.g. ProjectStage IS. Stop repeating yourself, that does not bring us further.
For Open Source projects like Agorava we also use DS (even the config part to a small extent, so no need to explain stuff I'm already using to me;-) Again similar to Money I was among the first to discuss these ideas in the JCP (I believe it was still Seam and e.g. DeltaSpike did not even exist then;-) or with the likes of Mike Keith. Or asked Ed Burns why the enum was so limited in JSF. Nobody says what's discussed here for Tamaya has to go into DeltaSpike or other frameworks out there, unless some of those ended up standardized and these projects were to implement them. So save your energy for making Tamaya useful and not keep repeating here all the time that it should not compete with DeltaSpike (which started the whole discussion not by me;-) Cheers, Werner Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | Eclipse UOMo Lead, Babel Language Champion | Apache Committer Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap | #DevOps | #EclipseUOMo Skype werner.keil | Google+ gplus.to/wernerkeil On Sun, Jul 31, 2016 at 9:26 PM, Mark Struberg <strub...@yahoo.de.invalid> wrote: > You are perfectly right John. > > Otoh we already explained the concepts of DeltaSpike (and thus Tamaya) to > Werner many times already. > Means if it _would_ be broken in DeltaSpike, then it would also not work > in Tamaya > Make your own conclusion… > > @Werner: please finally stop claiming things about other Apache projects > which are not true. > > txs and LieGrue, > strub > > > Am 31.07.2016 um 14:49 schrieb John D. Ament <johndam...@apache.org>: > > > > @gerhard: > > > > Don't forget, most questions go unasked. granted, i'm not sure what the > > scope of configuration per tenant looks like, and may drive more your > > architectural decisions around env per tenant/schema per tenant/column > > discriminator. > > > > I'd be very happy to hear what about DS Werner found inadequate. > > > > John > > > > On Sun, Jul 31, 2016 at 8:34 AM 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. > >>>> > >>> > >> > >
