Werner, I agree or atleast not disagree :)) to most of what you write, just some notes below.
Regards LF On Sat, Jul 30, 2016 at 11:30 PM, Werner Keil <[email protected]> wrote: > 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. > Where I consult we have actually gone the other way, from Spring to "plain JEE"... still some solutions use Spring here though. In the past I worked quite some with Spring but I tend to like the "plain JEE" solutions better... > 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. > We were not really "scared" (if I may put it that way) of using a framework still in incubation but rather that we would have liked to see more examples, documentation etc. In the end we would have needed to put an abstraction on top of it anyway to make it easier (the annotations I mentioned before).... this I beleave we would have done regardsless of the framework choosen... the reason for this is to make it easier for most of the use-cases of course but also to make it easy to use for the not so advanced Java devlopers... I beleave its quite common in major banks (at least in Sweden) to have a good domain knowledge but rather average Java skills... in the end its about fulfilling requirements and meet customer demands and thats what we try to do with our "framework / abstraction" for building bank applications internally here... > 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. > > I've never questioned anyones Java skills :)) I'm sure that we together can pull it off... Looking at the resumes/past projects of people participating in the discussions is impressive... > 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. > It was just what I felt when looking at it from the outside so to speak... to compare it to my kids (8 and 9 years) who constantly likes to fight I usually tell them it doesn't really matter who started and in most/some cases it doesn't matter who is right, if both cannot back off then it will just go on :)) ... just my thoughts about it... > 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. > Having it annotations based worked for us and our use cases, again its just another abstraction on top of other APIs... > > 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. > I'm not aware of all details in this matter but in the end it might lead to something good, the discussions are lively and things seems to be moving on, right? > > 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? > > The main reason for my post was that I would love to share our thoughts on what we would like to use a configuration framework for, what is working and not working for us and so on... If I could share inputs or be involved in any way that would not eat to much of the little time I have left I would loe ot... > 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. > > > -- 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.
