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