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 <[email protected]> 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 <[email protected]>: > > > > 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 <[email protected]> > > 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 <[email protected]>: > >> > >>> 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 < > [email protected]> > >>> 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 <[email protected]>: > >>>> > >>>>> 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. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > >
