It’s actually not so much about the name (ConfigSource vs ConfigProvider, that’s the same basically). But Anatoles idea with the ConfigProcessor proposal otoh is really something technically different.
A ConfigSource does not dynamically change values from the chain. They are really just a ‚source‘ (read-only, non-modifying). Anatoles idea with the ConfigProcessor otoh seems more like a valve. Those things also have the ability to amend or even totally change values which get passed through them. Even if they are not from themselves. It’s basically a chain pattern. I didn’t play much with it yet, but a few pros and cons already came to my mind: pro: more flexible. It can literally do anything you like con: no clear separation of concerns anymore. Much more complex. Probably hard to maintain from an Ops perspective. It is certainly a possible way to got, but I didn’t yet make up my mind. LieGrue, strub > Am 31.07.2016 um 22:13 schrieb Werner Keil <werner.k...@gmail.com>: > > Mark/all, > > The "Environment" or similar part was removed from Tamaya even before 0.2. > So as of now (unlike what you may do with some "context" profile or label, > don't care about details of how each project does that;-) > > So a "low level hack" as mentioned by putting a prefix or postfix to keys, > sure, just take Agorava > https://github.com/agorava/agorava-socializer/blob/develop/src/main/java/org/agorava/socializer/SettingsProducer.java, > we applied exactly that sort of prefix based on the social service (also a > form of "tenant) > > Without going into details of the "non-JSR" the name of some SPI elements > like ConfigSource (Tamaya before mostly sounded like Spring IMHO) sounds a > bit more appealing to me than ConfigurationProcessor. Not that you couldn't > call retrieving configuration from a source "processing" but at least in > my interpretation that might be more appropriate for something that > "processes" configuration data further down the stream. > > Any thoughts on that, or do you prefer the Processor? > > > Cheers, > > Werner > > > On Sun, Jul 31, 2016 at 9:58 PM, Mark Struberg <strub...@yahoo.de.invalid> > wrote: > >> Werner, NO ONE questioned that you worked for many companies for a long >> time already. >> And you also don’t need to tell it to us in every 2nd mail. WE KNOW >> ALREADY. >> >> But what the hell has this to do with a simple discussion about >> configuration? >> >> For me it’s as simple as that: >> I proposed an API with 6 classes. Tamaya has 20++ >> You now tell me a use case and I give you an example source how it can be >> implemented with those 6 classes. >> >> One thing as example which I currently left out intentionally: a >> @ConfigProperty annotation. >> Ok, that would be 1 more small class. >> Now we can define whether it is worth it to add this class. >> I’m not yet 100% sure so I left it out for now (we have this in DeltaSpike >> and it’s in a local branch of the javaConfig project already). >> But it is very easy to impement yourself (a simple CDI producer) and it >> has quite a few non-obvious pitfalls. E.g. that String, Integer etc cannot >> be proxied. >> >> Anything else? >> >> Let’s interpret your claim that you cannot deal with multi-tenancy in >> DeltaSpike as a question for a use case: >> >> „how would you implement multi-tenancy“ >> E.g. you have multiple SOAP server to talk with for each tenant and you >> like to have the endpoint url configurable. >> >> Now here is the answer: >> >> way 1.) Implement it in the ConfigSource as explained by Gerhard. >> pro: nothing special needed on the customer code side >> con: You need to adopt your config sources >> >> way 2.) implement a custom lookup path >> public class MyProjectConfig { >> public static String getValue(String key) { >> return getValue(key, String.class); >> } >> >> public static <T> T getValue(String key, Class<T> asType) { >> Config cfg = ConfigProvider.getConfig(); >> // first try e.g. someremote.service.url.customer1 >> T val = cfg.getValue(key + “.“ + getCurrentTenant(), asType); >> if (val == null) { >> // if no tenant specific config found we fall back to default key >> val = cfg.getValue(key, asType); >> } >> return val; >> } >> } >> >> The main point is: almost every (bit more complex) project I know has it’s >> very own lookup chain logic. >> So is it good to hardcode those in any API? Or isn’t it better to move >> them to userland as shown? >> >> way 3.) >> Implement a way to specify custom lookup chains inside the config >> mechanism. >> >> https://github.com/struberg/javaConfig/blob/configValue/api/src/main/java/javx/config/ConfigValue.java#L69 >> >> Essentially way 2 but directly in the API. Makes 1 more class >> (ConfigValue) means we are at 7 in that case. >> This would also provide value caching, support for mutable configs >> (including logging out the new value if something got changed), etc >> >> Any more questions? >> Anything for multi tenancy support which you still miss? >> >> LieGrue, >> strub >> >> >> >>> Am 31.07.2016 um 20:14 schrieb 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. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >>
