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 <[email protected]>: > > @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 <[email protected]> > 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 <[email protected]>: >> >>> 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 < >> [email protected] >>>> >>> 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 <[email protected]> >>>> 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 <[email protected] >>> >>>>> 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 >>>> <[email protected] >>>>>> >>>>>> 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 < >>>> [email protected]> >>>>>>> wrote: >>>>>>>>> yep... >>>>>>>> >>>>>>>> 2016-07-21 14:08 GMT+02:00 Werner Keil <[email protected]>: >>>>>>>> >>>>>>>>> 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 [email protected], and destroy all copies of this >>>> message and any attachments. >>>> >>> >>
