@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. > > >
