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