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