I mentioned the "vanity" bit. Sorry if some feel offended if e.g. some clients prefer to use Spring or write their own. If customers asked me to write their own app server with them, I also did that. Maybe not any more today, that was a while ago but if they learn about say DS or Weld and prefer to do their own CDI or DI implementation, the customer should know what's best for them in the end.
I'm sure you're not forcing every customer to use CDI if e.g. they have a strong Spring investment, so stay pragmatic and leave false vanity or pride about projects for the sake of getting things done;-) I'm not saying who, but co Spec Lead Jean-Marie who also famously hosted a JCP EC meeting as only Individual so far told me about somebody else who used to be in the EC once (and also contributed to parts of the Java platform) "He's a Diva". I am not, and hoping you're neither please stop acting like you are. Cheers, Werner On Sun, Jul 31, 2016 at 9:51 PM, Werner Keil <werner.k...@gmail.com> wrote: > Just don't communicate about DS here, this is not a DS mailing list;-) > > Cheers > > 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:44 PM, Gerhard Petracek <gpetra...@apache.org> > wrote: > >> @werner >> >> your assumption isn't correct. >> moreover, there are big companies which use ds and ds-config in similar >> projects successfully (with and without jsf and/or ui). >> assuming that all others have less experience or less complex/innovative >> projects and talking about your involvements all the time is just arrogant >> imo. >> i refuse to communicate in such a style. >> >> regards, >> gerhard >> >> >> >> 2016-07-31 20:14 GMT+02:00 Werner Keil <werner.k...@gmail.com>: >> >> > Gerhard/all, >> > >> > Again there were several shortcomings of DS for more than one client, >> not >> > all of them can be discussed as (unlike e.g. Multiconf) those are not >> Open >> > Source. >> > The whole of DeltaSpike was both too complex in some areas and not >> flexible >> > enough in others. >> > >> > You (IRIAN) work a lot on the JSF front end side I assume. And having >> > worked with Java since it existed I've simply done stuff for clients >> around >> > the world often before buzzwords for it were even made up. E.g. what's >> now >> > called "Smart Greenhouse" or in the same project mobile device >> recognition >> > from a UA string (not to the extent DeviceMap does it, but at least very >> > comparable to a few others like 51DegreeMobi in the "community" edition) >> > I prefer stuff that works for me and my customers over buzzwords, >> > unfortunately not everyone does, but without the obvious key- and >> buzzwords >> > Anatole's proposal of Tamaya was also accepted for JavaOne (even at a >> > rather early stage while they still seem to be stuck in decision making >> > over e.g. JSON-B or JSON-P now,-O) >> > >> > There's more than just a "stage", I am sure even with a majority of work >> > and customers on certain layers (like Presentation/Web) you must have >> dealt >> > with one or the other Agile project. And for many years now I deal with >> > "DevOps" environments where not only development or a cool demo counts >> but >> > having to scale a solution across the whole globe to multiple server >> farms >> > of these clients, there are aspects neither DeltaSpike nor Tamaya in >> their >> > current form can cope with. >> > >> > Adding a simple yet versatile thing like a string (label, tag, call it >> as >> > you prefer) in the right place or a number of them should do the trick. >> I'm >> > not asking to add something like that project stage, you keep mention >> it. >> > I'm saying it's not relevant in that form, so forget about it and try >> to >> > cover what helps more than just the DB or the Web tier (we already got >> that >> > in various forms inside all the existing JSRs,-) >> > >> > Regards, >> > Werner >> > >> > >> > On Sun, Jul 31, 2016 at 7:45 PM, Gerhard Petracek <gpetra...@apache.org >> > >> > wrote: >> > >> > > @werner: >> > > you always mention project-stages (for whatever reason) and i try to >> > > explain you that project-stages are a different story (they are even >> OT >> > > currently). >> > > >> > > listing some buzzwords without any concrete point is just pointless. >> > > several of us are involved in similar areas and have no issues with >> such >> > > topics (since years). >> > > (sometimes it's easier/simpler than some people expect.) >> > > >> > > regards, >> > > gerhard >> > > >> > > >> > > >> > > 2016-07-31 17:05 GMT+02:00 Werner Keil <werner.k...@gmail.com>: >> > > >> > > > Well that's the limited approach lacking multi-tencancy that we >> have so >> > > > far;-| >> > > > >> > > > I helped large multi-national companies like Maersk get their Java >> EE, >> > > Play >> > > > or Node.js landscape into the cloud in a unified way. >> > > > (and though it could have improved a bit, believe me, neither of >> those >> > > had >> > > > an answer to Multi-tenancy or Microservices then, not Oracle, not >> Red >> > Hat >> > > > or what's now called Lightbend;-) >> > > > >> > > > It's not enough to only cover the DS-config in a multi-tenant way. >> > > There's >> > > > much more. >> > > > I can only point you to the GH open source foundations of that, but >> > they >> > > > show fairly well how it works: >> > > > https://github.com/lhupfeldt/multiconf >> > > > >> > > > In fact Lars seems to further work on Multiconf. At the heart is the >> > idea >> > > > of a configuration "Matrix" which is where those dimensions come >> into >> > > play. >> > > > >> > > > You keep talking about project-stage all the time, that's just ONE >> > > possible >> > > > dimension;-) >> > > > >> > > > Werner >> > > > >> > > > >> > > > >> > > > On Sun, Jul 31, 2016 at 4:51 PM, Gerhard Petracek < >> > gpetra...@apache.org> >> > > > wrote: >> > > > >> > > > > @werner: >> > > > > you don't need special/explicit support for multi-tenancy in ds to >> > use >> > > > e.g. >> > > > > ds-config in a multi-tenant-architecture. >> > > > > >> > > > > there are different approaches you can use. >> > > > > one approach which is even independent of cdi is based on a tenant >> > > aware >> > > > > config-source. >> > > > > >> > > > > once again: project-stages aren't even related/close to >> > multi-tenancy. >> > > > > >> > > > > regards, >> > > > > gerhard >> > > > > >> > > > > >> > > > > >> > > > > 2016-07-31 16:08 GMT+02:00 Werner Keil <werner.k...@gmail.com>: >> > > > > >> > > > > > I know, that's why multi-tenancy is not really supported by DS >> at >> > the >> > > > > > moment;-) >> > > > > > >> > > > > > >> > > > > > >> > > > > > On Sun, Jul 31, 2016 at 3:42 PM, Gerhard Petracek < >> > > > gpetra...@apache.org> >> > > > > > wrote: >> > > > > > >> > > > > > > @werner: >> > > > > > > project-stages aren't even related/close to multi-tenancy. >> > > > > > > >> > > > > > > regards, >> > > > > > > gerhard >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > 2016-07-31 15:15 GMT+02:00 Werner Keil <werner.k...@gmail.com >> >: >> > > > > > > >> > > > > > > > Gerhard, >> > > > > > > > >> > > > > > > > As projects like those we mentioned found certain aspects of >> > > > > DeltaSpike >> > > > > > > (or >> > > > > > > > Spring Configuration) inspirational but not sufficient for >> > their >> > > > > > project >> > > > > > > > they just don''t use it. And hence won't bother raising >> issues >> > > on a >> > > > > > > mailing >> > > > > > > > list of something they are not using ;-) >> > > > > > > > Besides, I don't have time to file an issue but there's a >> > broken >> > > > link >> > > > > > in >> > > > > > > > the JavaDoc for a long time now: >> > > > > > > > http://deltaspike.apache.org/javadoc/1.7.2-SNAPSHOT/ >> > > > > > > > does not work, only >> > http://deltaspike.apache.org/javadoc/1.7.1/ >> > > > > does. >> > > > > > > > >> > > > > > > > The proven fact is, >> org.apache.deltaspike.core.api.projectstage >> > > may >> > > > > be >> > > > > > a >> > > > > > > > nice improvement over the very limited JSF construct >> (working >> > > with >> > > > > JSF >> > > > > > a >> > > > > > > > lot I guess you know, and probably also remember I told >> this to >> > > Ed >> > > > > > > numerous >> > > > > > > > times in the JSF EG;-) but a "project stage" like Dev, Test, >> > UAT, >> > > > > etc. >> > > > > > is >> > > > > > > > not the same as real multi-tenancy. And unlike e.g. a simple >> > but >> > > > more >> > > > > > > > flexible construct of a "Profile" in Spring you'd have to >> abuse >> > > the >> > > > > > term >> > > > > > > > "stage" to get remotely something to cover tenant, service, >> > > > release, >> > > > > > etc. >> > > > > > > > You improved over JSF, and I'm sure, there are projects who >> > > welcome >> > > > > > that, >> > > > > > > > but other solutions and framework are more simple and >> versatile >> > > > with >> > > > > > that >> > > > > > > > respect. Hence more popular and used. >> > > > > > > > Which is why e.g. the idea of similar terms in Tamaya like >> > > > > > "Environment", >> > > > > > > > "Stage", etc. was dismissed. >> > > > > > > > That doesn't mean it should not have something to handle >> > multiple >> > > > > > > > "dimensions" where JSF or DeltaSpike (or e.g. Wicket) only >> > handle >> > > > > one. >> > > > > > > > >> > > > > > > > Regards, >> > > > > > > > Werner >> > > > > > > > >> > > > > > > > >> > > > > > > > On Sun, Jul 31, 2016 at 2:33 PM, 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. >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> > >
