I mentioned the way Archaius improved Apache Commons Config before. They call it DeploymentContext: https://github.com/Netflix/archaius/wiki/Deployment-context
Although Tamaya has a few *Context elements of its own, such ways to scale your configuration (some are pre-defined, others can be applied just as you need them) do not exist in it at the moment. Regards, Werner On Sun, Jul 31, 2016 at 4:08 PM, Werner Keil <[email protected]> wrote: > 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 <[email protected]> > wrote: > >> @werner: >> project-stages aren't even related/close to multi-tenancy. >> >> regards, >> gerhard >> >> >> >> 2016-07-31 15:15 GMT+02:00 Werner Keil <[email protected]>: >> >> > 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 <[email protected] >> > >> > 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 <[email protected]>: >> > > >> > > > Lars, >> > > > >> > > > Thanks a lot for your input. Of course we have a few people with a >> > strong >> > > > financial background including Anatole who worked in a bank for many >> > > years >> > > > or myself. >> > > > Right now I help a major bank with their Java EE and Spring-based >> > > solutions >> > > > and there are also quite a few Apache projects like Wicket involved >> on >> > > the >> > > > front end. >> > > > >> > > > At the moment we're not yet dealing with the configuration part and >> > where >> > > > we do, I am pretty sure this client will leverage Spring. >> > > > A while ago in another large financial project pretty much >> everything >> > > Java >> > > > EE has to offer from CDI to JPA, Bean Validation or JBatch was used. >> > And >> > > > that project also applied a very fine grained separation of services >> > in a >> > > > "Microservice" style. So unlike marketing fuzz created by many >> vendors >> > > > (Spring/Pivotal also does a lot;-) Java EE applied correctly is >> usually >> > > > more than enough for a Microservice type project. >> > > > >> > > > Similar to what you described in your banking solution, frameworks >> and >> > > > libraries created there were inspired by e.g. Tamaya or DeltaSpike, >> but >> > > did >> > > > not use them. >> > > > With Tamaya it was mainly because of Incubation. Should it remain >> > useful >> > > to >> > > > real projects like yours or others, the guys in this project would >> > likely >> > > > use it if it left incubation. >> > > > With DeltaSpike it simply didn't meet its requirements. Lacking >> support >> > > for >> > > > Microservices or multi-tenancy which is why they chose to write >> their >> > > own, >> > > > quite similar to what you described or feeling not too different >> from >> > > e.g. >> > > > Spring Config with annotations like @Configuration or @Configurable >> but >> > > > suitable for their needs, e.g. a fine grained separation of >> > environments >> > > > and also security aspects Java failed to standardize as of now (some >> > were >> > > > identified by JSR 375 as relevant, but let's not go there here now) >> > > > >> > > > It is important to get a "reality check" from participants like >> > yourself. >> > > > And without proper vendor involvement it also won't see much >> adoption >> > I'm >> > > > afraid. >> > > > I worked with Java ever since it exists everywhere from Java ME >> > Embedded >> > > to >> > > > Java EE (the only thing I didn't do so far is JavaCard) >> > > > After writing even an entire application server based on EJB 1 and >> what >> > > > "J2EE 1" had to offer in 1998 (I was also at the JavaOne when Sun >> > > unveiled >> > > > it) for a pension fund I worked with every of the major vendors. >> Often >> > in >> > > > the same team as e.g. Oracle, IBM or BEA consultants. The result of >> > some >> > > of >> > > > that work went into standards like Portlet 1 or Java Content >> Repository >> > > > (both BEA and Day, now Adobe were in that project, so even then some >> > > > standards were derived from real client projects) >> > > > >> > > > Around 10 years ago I helped BEA Systems directly with their >> > Professional >> > > > Services teams and in the UK support center. The only external >> > freelance >> > > > consultant for the entire EMEA region. Our team manager had many >> > > interviews >> > > > with candidates either contract or permanent, but he always said, >> they >> > > did >> > > > not have my experience. So until the Oracle takeover I stayed the >> only >> > > > freelancer there. >> > > > With that background (e.g. after Oracle took over BEA the same >> manager >> > > > reported to Adam Messinger, now CTO at Twitter, he was working for >> the >> > > > original Weblogic company before that became part of BEA;-) and >> nearly >> > a >> > > > decade of JCP EC work now, I came across many interesting >> challenges. >> > > E.g. >> > > > the CDI you know now based on later proposed JSR 330 (@Inject) was >> born >> > > > from a serious amount of friction between Google, SpringSource (not >> so >> > > > active though) and JBoss/Red Hat. Mike Keith whom I knew well from >> > > Eclipse >> > > > and JPA work kindly offered to mediate. I was also involved from the >> > JCP >> > > EC >> > > > side and due to being in the EE 6 Umbrella JSR, too. You may find >> some >> > of >> > > > those discussions in Google Groups or Google Code Forums unless >> Google >> > > shut >> > > > down the latter now. Maybe some also happened in the earliest CDI >> > > > discussion forums. >> > > > >> > > > If you think any of the discussions I'm aware of here are harsh, you >> > have >> > > > not seen those arguments. Some technically, others simply fuelled by >> > > vanity >> > > > like (that's supposed to be in our JSR, not yours;-) You have to ask >> > > Mark, >> > > > if similar "vanity" is involved here, too. In a few threads I did >> > sense a >> > > > bit of that "don't compete with DeltaSpike" but I don't think it was >> > Mark >> > > > btw. And proposing "Yet another configuration API" pretending it >> was a >> > > JSR >> > > > did not sound like considering DeltaSpike the ultimate answer to all >> > > > configuration questions either. >> > > > I cannot say if a common standard developed under the JCP or a >> similar >> > > body >> > > > will end up entirely based on annotations or not. The most commonly >> > used >> > > > alternatives like Spring Config are mostly used via annotations. >> > > DeltaSpike >> > > > offers some aspects and the in-house framework you mentioned and >> others >> > > > also have seen at their customers also do. >> > > > Separating the underlying "value holder" (Configuration interface) >> from >> > > > usage by annotations like Spring (or Mike Keith also envisioned) I'd >> > say >> > > > Tamaya got pretty right already. >> > > > >> > > > Spring is not famous for its proper separation of "API" and >> > > > "Implementation". Unlike CDI and many other JSRs it is not a >> standard >> > > > specified by any place like ISO, ETSI, OASIS or JCP, so it does not >> see >> > > the >> > > > need for that. Nevertheless it allows to use @Inject and other >> > standards >> > > in >> > > > many areas now. >> > > > So if a standard was created by somebody it would not be bad to also >> > get >> > > > them involved or use some of it. >> > > > Spring Data or Spring Integration also make use of JSR 354 now btw, >> so >> > if >> > > > such standard for configuration did not contradict everything it >> does >> > > with >> > > > its config frameworks, I see no reason why they should not be >> > interested >> > > in >> > > > something like this. >> > > > >> > > > The only strong words you may have heard by me in this discussion >> was >> > > about >> > > > Mark's panic reaction and clear abuse of the JCP branding and >> package >> > > > names. >> > > > He's a JCP member himself and by doing so he violated and >> jeopardized >> > his >> > > > membership. Other fellow JCP EC members like the LJC reps who saw >> his >> > > > announcement e.g. on the Microprofile list also urged him to fix >> this >> > or >> > > > delete the codebase and the PMO was ready to "unleash the blood >> hounds" >> > > had >> > > > we not both confirmed that he at least changed the incriminating >> > package >> > > > name. >> > > > >> > > > Other than that like you and I'm sure enough others I hope Tamaya >> > becomes >> > > > "useful". Simple or modular into smaller chunks is not bad. Working >> > with >> > > > small and Embedded systems a lot,too I understand better than many >> > "Pure >> > > EE >> > > > developers" how important size can be. >> > > > However, the idea behind creating Tamaya was neither to directly >> > compete >> > > > with DeltaSpike or Commons Configuration, nor to create a JSR there >> > > > already. >> > > > Having a separation between API and implementation helps, under >> certain >> > > > circumstances Tamaya could even offer to be an RI for a possible >> > > standard, >> > > > but it's supposed to be the PoC for one or more configuration use >> > cases, >> > > > not the JSR. >> > > > >> > > > Hope everyone understands that? >> > > > >> > > > Regards, >> > > > Werner >> > > > >> > > > >> > > > >> > > > >> > > > On Sat, Jul 30, 2016 at 1:16 PM, Lars-Fredrik Smedberg < >> > > [email protected] >> > > > > >> > > > wrote: >> > > > >> > > > > Hi >> > > > > >> > > > > I've been following the discussions the last couple of week(s) >> and I >> > > must >> > > > > admit that it has both been interesting and frustrating. >> Interesting >> > > > > because I always like to see how different people choose to solve >> the >> > > > same >> > > > > or similar problems, frustrating because I (personally) feel that >> the >> > > > tone >> > > > > in the emails has been more than once or twice kindof harsh (from >> all >> > > > sides >> > > > > if I may call it "sides") and to me sometimes without a reaso... >> > > > > >> > > > > I would have loved to be more involved in Tamaya or the >> discussions >> > > going >> > > > > on about configuration in general, my excuse (accept it or not >> :)) is >> > > > that >> > > > > I >> > > > > work full time, takes care of my company, house and two kids on my >> > own. >> > > > > More on that over a beer or two if we ever meet :) >> > > > > >> > > > > I'm not sure who will be on the meetups but it would be nice / >> > > > interesting >> > > > > to either listen in / take part of them or at least the result of >> > them. >> > > > Who >> > > > > knows, I might have some input that will help :) >> > > > > >> > > > > I've been working with Java for 20 years now, mostly as a >> consultant >> > > but >> > > > > also started companies developing products for the financial >> industry >> > > > > (mostly derivatives trading, post trade systems). I wouldn't call >> me >> > an >> > > > > expert but I've seen alot of code and done alot of development >> during >> > > the >> > > > > years. >> > > > > >> > > > > Been working as a consultant for banks for a long time now and >> lately >> > > > with >> > > > > a customer where I'm involved in developing a "platform" for >> making >> > it >> > > > easy >> > > > > for developers to develop bank applications, the platform takes >> care >> > of >> > > > > (implicitly or explicitly depening on the functionality) all >> things >> > > that >> > > > a >> > > > > bank applications needs such as audit, security, logging etc. The >> > > > framework >> > > > > tries to be up to date with JEE and Java (that includes many of >> the >> > JEE >> > > > > related technologies sich as CDI, JAX-RS, JAX-WS, Bean validation >> and >> > > so >> > > > > on....). >> > > > > >> > > > > Typically a "bank application" is developed by a team and/or >> > maintained >> > > > by >> > > > > a team of people. In an appserver there can be many "bank >> > applications" >> > > > > running each requiring their configuration. When were going to >> look >> > at >> > > > > enhancing the way configuration were done we took a look at Tamaya >> > but >> > > > > still decided to write our own (partly inspired by Tamaya) >> > > configuration >> > > > > framework. Some of the features we needed I did not find in Tamaya >> > (or >> > > > > maybe I didn't understand how to implement them using Tamaya), we >> > also >> > > > > needed a nice API towards the bank application developers (which >> > > ofcourse >> > > > > could have been done on top of Tamaya) but the main reason for >> > rolling >> > > > our >> > > > > own solution was that we felt it hard to understand how to use >> Tamaya >> > > > > (maybe due to its flexibility, or maybe the documentation at the >> > early >> > > > > stage of development, I cannot tell exactly what part that made us >> > > choose >> > > > > to not use it...). >> > > > > >> > > > > Some of the features we have in our solution are: >> > > > > >> > > > > - API towards the bank application that is annotation based >> > > > > (@ApplicationConfiguration(property=...) and supports different >> types >> > > > such >> > > > > as String, Number derivatives and so on (in the configuration it >> is >> > all >> > > > > string->string) >> > > > > - Bank applications each have their set of configuration >> properties >> > > > > (META-INF/conf/<application> >> > > > > - Configuration for the platform can be used by bank applications >> but >> > > not >> > > > > overriden by them >> > > > > - All configuration can be set/overriden by operations who are >> > > > responsible >> > > > > for the servers >> > > > > - Overriding can be done using ordinals, this can also be done >> > withing >> > > an >> > > > > application if it contains multiple modules (not all modules >> might be >> > > > used >> > > > > for all installations) >> > > > > - Resolving using proprerty placeholder (if needed) syntax within >> the >> > > > > properites themselves but also withing e.g. XML files read by >> > > > applications >> > > > > - Properties can be placed in property files under META-INF... an >> but >> > > > also >> > > > > in environment entries, system properties, context/jndi etc >> > > > > - The resolving can make use of wether the server is a test server >> > > > > (functional, integration, production test, production), wether its >> > > > internal >> > > > > or external (different network zones, security mechanisms and so >> on) >> > > and >> > > > so >> > > > > on.. the configuration can therefor be written once (and only one >> > bank >> > > > > application artifact needs to be built) and used throughout the >> > testing >> > > > > process until (and including) it reaches production >> > > > > - ...and more things... >> > > > > >> > > > > The solution itself is very small but fulfills our needs and is >> > simple >> > > to >> > > > > use for the bank application developers. >> > > > > >> > > > > Thanks >> > > > > >> > > > > Regards >> > > > > LF >> > > > > >> > > > > >> > > > > On Tue, Jul 26, 2016 at 11:01 AM, Werner Keil < >> [email protected] >> > > >> > > > > wrote: >> > > > > >> > > > > > Also seen among many others in CDI where >> > > > > > javax.enterprise.inject.spi.CDIProvider is an SPI element to >> allow >> > > > access >> > > > > > to what's the only static accessor in CDI, the class with the >> same >> > > > name, >> > > > > > not a static factory itself;-) >> > > > > > >> > > > > > >> > > > > > On Tue, Jul 26, 2016 at 10:36 AM, Werner Keil < >> > [email protected] >> > > > >> > > > > > wrote: >> > > > > > >> > > > > > > The name IMO is. A static facade "ConfigurationProvider" is >> > > > misleading >> > > > > > > because its naming pattern overlaps with SPI elements commonly >> > > named >> > > > > > > *Provider everywhere (especially in JSRs, not every other >> > > "framework" >> > > > > > > popular or not even makes a distinction between API and SPI;-) >> > > > > > > >> > > > > > > Seems DeltaSpike brought that antipattern into Tamaya since >> > there's >> > > > at >> > > > > > > least one "provider" package with static facade singletons. If >> > > Tamaya >> > > > > can >> > > > > > > live with that, then why not in this Apache PoC. Neither >> Tamaya >> > nor >> > > > > > > DeltaSpike or Spring will be a 1:1 blueprint for a future >> > standard >> > > we >> > > > > > > probably see at least after JavaOne based on what Oracle plans >> > for >> > > > > "Java >> > > > > > EE >> > > > > > > in the Cloud". >> > > > > > > >> > > > > > > Cheers, >> > > > > > > Werner >> > > > > > > >> > > > > > > >> > > > > > > On Tue, Jul 26, 2016 at 8:21 AM, Mark Struberg >> > > > > <[email protected] >> > > > > > > >> > > > > > > wrote: >> > > > > > > >> > > > > > >> That's how it used to be since pretty much almost the >> beginning. >> > > > > > >> And that part was also not in question imo. >> > > > > > >> >> > > > > > >> >> > > > > > >> LieGrue, >> > > > > > >> strub >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> > On Thursday, 21 July 2016, 16:02, Anatole Tresch < >> > > > > [email protected]> >> > > > > > >> wrote: >> > > > > > >> > > yep... >> > > > > > >> > >> > > > > > >> > 2016-07-21 14:08 GMT+02:00 Werner Keil < >> [email protected] >> > >: >> > > > > > >> > >> > > > > > >> >> Anatole/all, >> > > > > > >> >> >> > > > > > >> >> So ConfigurationProvider boils down to just a >> > > getConfiguration() >> > > > > > >> method >> > > > > > >> >> now? >> > > > > > >> >> >> > > > > > >> >> >> > > > > > >> >> >> > > > > > >> >> > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > Med vänlig hälsning / Best regards >> > > > > >> > > > > Lars-Fredrik Smedberg >> > > > > >> > > > > STATEMENT OF CONFIDENTIALITY: >> > > > > The information contained in this electronic message and any >> > > > > attachments to this message are intended for the exclusive use of >> the >> > > > > address(es) and may contain confidential or privileged >> information. >> > If >> > > > > you are not the intended recipient, please notify Lars-Fredrik >> > Smedberg >> > > > > immediately at [email protected], and destroy all copies of this >> > > > > message and any attachments. >> > > > > >> > > > >> > > >> > >> > >
