Maybe something to discuss in upcoming hangouts, too. I am moving between apartments tomorrow. Hope the wifi works and I don't need to pick up more stuff before they close, but if possible I'll join.
Ideally those who already commit should be able to do in the ".next" branch. When I last cloned Anatole's GH branch/repo that ConfigProcessingContext was still missing. If it was to change, happy to check back again tomorrow. Cheers, Werner On Sun, Jul 31, 2016 at 10:25 PM, Mark Struberg <[email protected]> wrote: > 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 <[email protected]>: > > > > 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. > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >> > >> > > >
