Starting a Configuration JSR

[Mark Struberg]

Hi!

I know a bit about configuration. I wrote the original stuff in OWB and together with Gerhard Petracek I did the config part of Apache MyFaces CODI and Apache DeltaSpike.

I've now extracted the most important bits out of DeltaSpike into an own project. 

The approach is strictly String/String based. Namespacing is achieved by using dots similar to Java package names.

The API itself has only 2 classes (Config and ConfigProvider).

The SPI for extending the config mechanism has 4 classes. 

Anything else can easily be provided on top of it. E.g. caching, variable resolvement, ProjectStage, conditional lookups, etc. All that stuff is easy to add on an additional layer later.

https://github.com/struberg/javaConfig

Happy to get any feedback.

LieGrue,

strub

[Werner Keil]

All those in the JCP or EC will have noticed, Mark missed the step of "proposing a JSR" before it can be called a JSR.
(we have not heard about this "JSR" yet or were asked to vote on its creation review;-)

Whether Mark and Gerhard wish to help in a more legitimate place, e.g. https://github.com/microprofile I guess that would be perfectly fine, should there be a desire to add "missing ingredients" available elsewhere like Spring, DropWizard, etc. mentioned here

• Monitoring
  
• Configuration
• ...

However, just "self-declaring" your own JSR is extremely disruptive and counterproductive. Seems a bit like out of "Pinky & Brain" ;-)

And in the worst case it would fuel the views by some inside Oracle that "this whole Open Source thing ain't gonna work" and they may well prefer their own closed, proprietary efforts instead.

It makes Apache, the Java Community Process, standardization efforts in this space and the Java (EE) community as a whole look like fools who lost control of their followers if people start creating their own JSRs in a garage now because Oracle is too slow to respond.

I don't believe that's the intention of most here.

Cheers,

Werner

[Christian Kaltepoth]

Werner,

I don't think that Mark "self-declared" his own JSR. The subject of his email was "Starting a Configuration JSR". So in my understanding the mail is about discussing whether or not it makes sense to propose such a JSR. And I don't think that this is "disruptive" or "counterproductive".

Christian

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/85adbc5f-7835-46ce-ba46-5b0651136b35%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Christian Kaltepoth

Blog: http://blog.kaltepoth.de/

Twitter: http://twitter.com/chkal

GitHub: https://github.com/chkal

[Rene Enriquez]

It seems awesome, I think that a good idea could be embrace yaml instead of properties files

[Werner Keil]

Christian/all,

The way he put it there as "javax.config" and aiming to present facts he cannot do was quite unthoughtful. We (mostly those involved in Tamaya where he's also been a team member for quite a while) discussed it with him. And his thoughts about Tamaya probably beeing a bit bigger than what a future JSR could be are not wrong. It seems he was afraid, Tamaya could become the standard exactly as it is developed at Apache right now. That's not the case and you practically never find this happened for existing JSRs. JBatch wasn't an exact clone of Spring Batch nor is the MVC JSR going to be a copy of Spring MVC. They take inspirations from Spring and other sources. In the case of JBatch or JSR 330 Spring was even a member of the EG.

As I told Mark, should Pivotal still be interested to help JSRs now, such JSR would certainly be a good opportunity. Spring has good examples of configuration, so does e.g. Typesafe/Lightbend. As well as half a dozen Apache projects (Tamaya isn't the only one, there are also 2 generations of Commons Config, the newest one also greatly improved)

All of this could and should influence a config JSR and since Anatole (he did this the right way given he's already been a Spec Lead who also received multiple awards;-) already presented the idea to the JCP EC once, chances are good it could be accepted relatively soon. Probably in time for Java EE 8 although it should work with SE or "micro" solutions, too.

Regards,
Werner

[Werner Keil]

Apache Tamaya already does;-)

[Mark Struberg]

Hi Rene!

The main point about this proposal is that it's exactly _not_ bound to any configuration format. 

It's actually more a 'Configuration Aggregator' and you can plug in your own ConfigSource which reads yaml. And others can plug in their own ConfigSource which reads from the DB, etc

LieGrue,

strub

Am Sonntag, 17. Juli 2016 15:54:03 UTC+2 schrieb Rene Enriquez:

[Mark Struberg]

as explained many times on many other places:

* Tamaya has grown way beyond a small API suitable to work as a broad baseline - especially if we like to push it for a JSR. For anyone who is interested in details should simply look it up on the public tamaya dev list.

* please stop writing FUD and misinformation. Either add constructive information or remain silent - txs.

LieGrue,

strub

[Werner Keil]

The rogue "JSR" was unconstructive and fuelled by FUD so you should have remained silent about that and kept it "in the closet" in the first place.

Anatole said the discussion though only 1 on 1 was reasonably constructive, so stick to that and the Tamaya mailing list instead of spreading misinformation here that just confuses people and irritates the community even further (when some are already afraid of "forks")

Thanks,
Werner

[Werner Keil]

Again, that whole thread missed the point and was unnecessary in the first place;-|

If there's "a new JSR" you'd learn about it on https://jcp.org/en/home/index
E.g. JSR 380 is just under creation approval ballot.

If along the lines of DropWizard, Lightbend or Spring a future version of Microprofile has a configuration need, it may use any project and technology it wants. E.g. 2, 3 or more modules by Tamaya should it find it that appropriate. It's not up to you to judge if it's useful for the purpose or not. The other thread here by Matthew https://groups.google.com/forum/?hl=en#!topic/microprofile/6ZrmqFaMG2M was much better suited. Asking the question instead of making false assumptions about non-existing standards.

Werner

[Mark Struberg]

You still don't get it!

a.) The ones who codes and makes proposals creates progress. Not the ones who just blame others of wrong doing but don't write a single line themselves. 

b.) In the whole OSS world there is no single (good) programmer who fears a fork! It's all about evolving and making things better. 

c.) If you want go down the 'fork' story, then I debunked all your accusations already in many other places and tried to clarify it even in private mails. Again: Not I did fork Tamaya but I wrote that stuff in Apache OpenWebBeans in 2009 and later Gerhard and I moved it to Apache MyFaces CODI and from there to DeltaSpike. So if you like to call it a fork, well then I plead guilty that I forked my own work so to say... The reason why Tamaya looks similar is simply because I contributed that stuff to Tamaya as well when the project came to the conclusion that their original algorithm didn't work out. 

d.) Yes, the hangout with Anatole was very constructive. Exactly because we don't blame each other, but we try to get things down to the ground instead of shipping hot air for 2 years.

>  E.g. 2, 3 or more modules by Tamaya should it find it that appropriate

e.) Well that perfectly shows the different approach. I don't aim for 2,3 more modules in addition to the already 50 classes. I aim for about 5 to 7 classes IN SUMMARY. Not 50 or 300 as Tamaya had when it started. Simply because nobody will use such a complex piece! Especially not if I can do the exact same with a very minimalistic approach.

f.) Txs I know how a JSR works. I've seen good ones, and sadly I've also seen bad ones.

g.) Stop with all that namedropping. You permanently drop names of companies you don't speak for. Or link to github sources which have nothing to do with this proposal and also have nothing to do with you. Why? Just to confuse people? Are you a technician or a politician? PLEASE stick to the topic and show code or algorithms. And if you have nothing to offer, then please remain silent.

Of course any technical feedback is still welcome, but please keep it at a technical level.

txs and LieGrue,

strub

[Werner Keil]

No point discussing any of that here as you still don't understand that "your JSR" was a bad idea and you're not supposed to do that in this way.

Nobody other than you drops names or acted as if he was speaking for the JCP or wider Java Community with that "JSR".

Nobody is afraid of a "fork" as long as you play by the rules which you did not in several ways. The worst was abusing the "javax.*" package name space.

I can and will speak for the JCP (not Oracle;-) because I'm a member of several EGs, many of them do good, constructive work in a democratic way. 

As long as you are willing to propose something and do  this in a democratic manner (regardless of Apache, Eclipse or JSR projects there is always some decision making process) and not just delete something or change it single-handed because you think it's right without asking others first, you're more than welcome in either of these communities and projects.

If not, there are examples like the ones I mentioned. And they all played by the rules. The guy who forked Apache DeviceMap did so under a new name, project and domain (I think) not calling it "Apache DeviceMap" any more, He was told not to do so. Others like the former "Apache Commons Money Incubator" (which I also dealt with since it was discussed for JSR 354 before Anatole joined as Spec Lead) is now developed in GitHub, too as "Joda-Money". 

So not dropping any names, just working with myriads of Open Source projects for decades now. And these cases followed rules like not pretending to be either a JSR or Apache project in a different place after the fork. 

So propose things in the right place and way not pretend to do something you're not supposed to do.

You should be fine moving stuff inside Apache.org from one project to another, but when you create something even in a "sandbox" or your own private branch, please do so by following developer guidelines like http://tamaya.apache.org/devguide.html. If Tamaya isn't the first Apache or Open Source project you participate in, then you should have seen those numerous times and learn how to apply them ;-)

Even if "concepts" or ideas for a complete fork may be based on either of these projects mentioned, you're not supposed to use the "org.apache" namespace there either or call it part of Apache Geronimo, CODI, Tamaya or other. The rare exception was e.g. preparing Tamaya here https://github.com/java-config/tamaya-export.

If you want to propose something to Tamaya, Geronimo or whatever, do so in a "sandbox" or private discussion branch.

If you really wanted a full new fork or project, neither abuse the javax nor org.apache namespace or something that sounds like them. Use "org.struberg" or also think of another ".io" domain like everyone else;-)

Your "JSR" was none of that. If you plan a whole new module of an existing project like Geronimo or Tamaya there are sandbox repositories like http://svn.apache.org/viewvc/geronimo/sandbox/ for that. No need to call it "org.apache" or "javax.config" there. 

Neither was appropriate, and I hope you finally get that now??? 

This is not the right thread for any of the other items and there have been much better threads here or in different places, So not bothering with the rest.

Cheers,

Werner

[Mark Struberg]

Fuuu, Werner you still don't get it.

I can take MY code and move it to all the projects I have trademarks for IF the community likes it. That might be apache commons, geronimo, deltaspike, tomee, and even Tamaya! 

And as explained multiple times: javx.* is NOT javax.*. Of course the goal is a proper JSR and javax in the end.

Btw, this is a public list. Stop making a fool of yourself and stop with repeated ad hominem attacks.

Again: I'm happy to hear your USE CASES or TECHNICAL arguments.

But I will _not_  further respond to any of your EG arguments. Especially as you surely know that you are not the only EG member of us 2...

LieGrue,

strub

[Werner Keil]

Sorry you still don't get it, that there IS NO EG or JSR at the moment ;-)

If using org.apache in your private pet project is legitimate or not,  that's up to Apache Foundation to decide, I won't bother discussing this further.

You claim eventually you'd like to see a "true JSR" but you did everything  to jeopardize the JCP as a whole.

Yes this is a public list, but you made a total fool of yourself by the  claim that "you started a JSR" in the first place. Visible to several JCP EC Members and at least the mailing list is certainly also on Oracle's radar. I was not the only one  who told you to fix the package name, but having posted a thread like this with a ridiculous claim and "pseudo JSR" should not have happened in the first place.

Such a clumsy mishap may not kill or bring down the JCP but in the current situation there is great scrutiny everywhere, both in- and outside Oracle. And with things like that you simply gave ammunition to those who'd prefer there be no more JSRs, but something else (maybe JEPs at OpenJDK)

So please while you can't put the "clown" you made yourself look like into the box. just remain silent in this thread.

Everyone else discusses technical things in the right place, but you presented this mishap on a plate to everyone, be it media, JCP Members or those who prefer to develop their stuff elsewhere.

Stick to the Tamaya list or maybe that Mike Keith created earlier. And don't break more china than you already did with this "non-JSR".

Thanks,

Werner

[Ondrej Mihályi]

Hey guys,

I can see that this discussion is going nowhere close to an agreement. I know you are good and smart guys, so I suggest starting a new thread about a config spec. If we stop calling the new spec a "JSR" and packages are renamed, I think it is a good start to have something more in MicroProfile in near future.

In my opinion, the proposed spec fits well into what MicroProfile tries to achieve - being light and lean, going first through an open discussion and short cycles, instead of going first through JCP. I would like to more efforts like this, I'd call them MicroProfile spec requests (MSR or just micro spec :) ). I also consider starting similar initiative with a spec for fat JAR packaging. All such efforts could end up being a JSR eventually, but not necessarily.

For package names, I suggest to prefix with io.microprofile and stay away from javax prefix for a while.

-- Ondrej

Dňa nedeľa, 31. júla 2016 21:23:39 UTC+2 Werner Keil napísal(-a):

[Mark Struberg]

Txs Ondrej!

Note that I'm not using javax but javx as the package name. Close enough to be familiar, different enough to not cause any trademark or JCP troubles.

LieGrue,

strub

[Mark Struberg]

Werner, which part of "please stop personal insults and start focusing on technical questions" did you not understand?

[Heiko Braun]

+1 to Ondrej's suggestion.

[Werner Keil]

Mark/all,

I suggested very early in this thread, that maybe instead of your own GitHub repo you could offer the ideas to io.microprofile (GH organization), too.

Ondrej and Heiko just like myself or Ben/Martijn from LJC told you to use a different package name.
"javx" is pretty much like those "typo trap domains" to lure you into the dark net or spread malware. So that is an "insult" package name to provoke and mock JCP efforts, nothing more.

Neither of us who asked you to change this insulted you.

You made a mistake by claiming "Look I just created a JSR" because that's not how JSRs or similar Open Source projects work and get started. Take it as "Lesson learned" and stop complaining about those who tried to help you before Oracle started sending their legal team...

Offer it to Microprofile, it's something other similar solutions (e.g. Dropwizard) or commercial vendors also use, so why not leverage it here in a proper way.

[Werner Keil]

Heiko,

As you're one of the Red Hat contributors to Microprofile and Red Hat was also approached by Anatole Tresch when he actually made a PRE-proposal: https://jcp.org/aboutJava/communityprocess/ec-public/materials/2014-09-2526/ConfigJSR.html

That was "as close as it gets to a Config JSR" but it wasn't officially proposed and neither Oracle (Mike Keith had other duties like so many there including most Spec Leads;-|) nor Red Hat were able to step in and support his proposal at the time.

Do you feel microprofile.io could be a better place to do this right now or would you rather wait for a JSR to use it like the others? (especially for Java EE 8)

Cheers,
Werner

[Heiko Braun]

A couple of thoughts on this thread in general and Werner's question in particular:

From my point of view this working group has two notable characteristics:

a) It's pre-standardisation work

b) It's open to everybody

I am in agreement with Mark Little [1] that this group's work is not about creating a new standard. However this does not mean anything derived from our work cannot be taken to a standards body at some point. But to what degree this will happen it's uncertain at the moment. Therefore I would suggest we consider the work on the Microprofile a pre-standardisation effort and make it explicit wherever we can. (i.e. "io.microprofile.*" versus "javax.*")

But there will be situations where we tap into the domain of existing specification efforts (i.e JSR's), most likely because a related standard or proposal exists elsewhere. Here the relationship needs to be pointed out and examined. In situations like this it may be worthwhile to ask prior spec leads for an advice and possible contributions to the Microprofile.

The fact that this group is open to everybody allows for people with various backgrounds to contribute. Some may be well experienced with the work in established standards bodies while others are not. Neither of these two positions makes one perspective more legit then the other. Furthermore do I believe that it's exactly the tension between the different, partial perspectives that can unleash the potential of this group.

To provide an environment where people can easily contribute, I think we need two things:

- a mindset that helps people getting aboard (i.e. be open to mistakes and appreciate the various backgrounds)

- a formal guide that describes our expectations towards the contents and scope of proposals and processes around submission, review, etc [2]

With regard to Werner's question:

Werner, I think that Mark Struberg's proposal looks reasonable and it seems that other people on this thread seem to acknowledge that. The fact the a JSR proposal along the same lines already exists, suggests that we reach out to Anatole Tresch and invite him to this discussion. It would be good either Anatole or anybody else who participated in the java config proposal could add some meat to the discussion by providing further examples that allow us to better compare the two proposals. 

With regard to Mark's proposal:

Mark, to avoid the confusion between the Microprofile work and existing standards bodies, I think it would be helpful if you could update your proposal to reflect the following:

- remove any references to JCP related terms (i.e JSR, TCK, etc)

- change the package names from "javx." to "io.microprofile"

Apart from that I think your proposal looks sensible and I appreciate the work you've put into it.

Regards, Heiko 

[1] https://developer.jboss.org/blogs/mark.little/2016/07

[2] https://groups.google.com/forum/#!topic/microprofile/Ovmg0EdKXfk

[Martijn Verburg]

I'll add to this that I think we need we also need a code of conduct set up, the sooner the better to foster a vibrant, respectful community, I'll start a new thread with a new draft to discuss this.

Cheers,
Martijn

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/67719357-b4e3-4bcc-89b8-64dd4592c779%40googlegroups.com.

[Werner Keil]

Heiko/Mark (Little but actually both;-)

Thanks for the feedback.

Mark (Struberg) and Anatole are already talking to each other especially in the Apache Tamaya podling.
A large portion of what Mark tried to express was Tamaya should either have a smaller API or at least a "Micro kernel" (along the lines of what Micro profile tries to archive on the Java EE platform) and modular levels of API. That is a perfectly valid argument and all he was criticized for was the way he "hijacked" Anatole's and Credit Suisse's earlier pre-proposal without even asking them or other JCP members.

Anatole got a Tamaya talk at JavaOne. And everyone who plans to be there interested in the subject is welcome to see and meet him there (a few others from the Tamaya team should also be there like myself)

During JavaOne we also hope to hear what Oracle has in mind for Java EE and the Cloud. Kurian explicitly mentioned configuration and Anatole's talk being accepted as one of the first who received feedback shows it must be of relatively high interest to a few people.

Regards,
Werner

[John Clingan]

+1. Well said on all counts, Heiko.

[Mark Struberg]

Hi Heiko and John, txs for the constructive feedback!

I've adopted the wording and moved to the io.microprofile package. 

https://github.com/struberg/javaConfig

You can find the adopted spec PDF over her:

http://long4.me/javaconfig/microprofile-config-spec.pdf

Of course if we like to aim for wide adoption then we also would need a proper way to handle such common efforts in a sane way.

In my experience there are only 2 ways to deliver a *good* specification:

1.) By making it legally binding ;) Well, that's probably not what we aim, but instead:

2.) By making it technically excellent. That is my preferred way. And while the proposal might be a decent start, we surely still need additional input from vendors.

A few thoughts about how to proceed with such a body:

1.) I would love to see a use-case based approach. We don't need arguments like 'oh I like to have this API this and that way'. That ends into a war about privately preferred flavours. Instead it should imo be "I have this and that use case. How to solve it with the proposed API. If it's not possible, what do we need to change". 

2.) We cannot solve all problems around the world. Imo the only thing we need to do is to make it possible to solve the standard use case PLUS make it easy to extend the core mechanism in a very flexible way to adopt it to additional use cases.

That way we can really prevent spec bloat (called 'featuritis' over here). I would love to really keep this as small as possible. The more we add, the more complicated it will be to use. And that in turn means that we would heavily reduce adoption.

txs and LieGrue,

strub

PS: IF Oracle would be willing to accept such an effort as JSR, then it would still be better for the whole Java community (including the microservice.io effort). But it's of course no show-stopper if oracle totally blocks!

PPS: We should definitely look forward to properly set up microprofile.io as vendor independent platform. Or instead we might reach out to an established OSS community like the ASF to coordinate such a vendor independent effort. As ASF member that would ofc be my preferred option ;)

[John D. Ament]

On Wednesday, August 3, 2016 at 5:22:32 PM UTC-4, Mark Struberg wrote:

Hi Heiko and John, txs for the constructive feedback!

I've adopted the wording and moved to the io.microprofile package. 

https://github.com/struberg/javaConfig

You can find the adopted spec PDF over her:

http://long4.me/javaconfig/microprofile-config-spec.pdf

You're assigning copyright of the spec to the ASF?  Seems odd.

I like the spec, its concise, to the point.  There's some features/switches I'd recommend making. (e.g. addConfigSources(ConfigSource...) would be useful).  I don't particularly understand why a config needs to be released.  Its not specified how a config source is discovered, but I would assume service loader.  I could see people getting behind this faster than CDI-30.

[Werner Keil]

Also while the API looks OK, it has the microprofile.io signature (I suggested that as the first response to Mark's announcement in this thread;-) both "implementation" and "tck" still say org.apache.geronimo.config.*

I assume, John is the expert to judge between "odd but OK" and "should not be here in this form".

As well as others including owners and admins of the "microprofile" organization on GitHub. Following the pattern of what Antonio started with his examples, I guess it would eventually be imported or forked into that organization instead of private repos in different places.

The thread about licensing hinted, that all material should be under Apache 2.0, but that's not the same as belonging to Apache Foundation or being licensed by it.

CDI has license headers like

/*
 * JBoss, Home of Professional Open Source
 * Copyright 2010, Red Hat, Inc., and individual contributors
 * by the @authors tag. See the copyright.txt in the distribution for a
 * full listing of individual contributors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 * http://www.apache.org/licenses/LICENSE-2.0
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,  
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

So I'm sure, Heiko and Red Hat can also provide their experience on how headers and source files should look like without violating existing organizations. Unless some or all of microprofile.io was contributed to and accepted by Apache Foundation it does not feel right in this place.

If microprofile.io plans to offer a "stack" for microservices based on Java, then looking at other frameworks and products like Dropwizard, Lightbend or Spring it can certainly benefit from a configuration library.

Having a wide enough range of solutions to use as inspiration certainly helps if a formal standardization attempt was made.
JPA was a good example where all major vendors and some individuals also involved here were in the expert group at some point. And also others like Spring.
So we don't know what Oracle has in mind for Java EE 8 or upcoming future JSRs it also put on the horizon, but if enough vendors and experts were involved and welcome like JPA or others did, then it's not a question of "Oracle totally blocking it", but don't expect to create the only single blue print here they'll just take over and change the package name;-)

Either way there's no harm for Microprofile. If a standard is at least partially inspired by it, then it'll be easy to implement or use that. Otherwise it has something similar to offer as Spring or Lightbend already do.

Regards,
Werner

[Mark Struberg]

> You're assigning copyright of the spec to the ASF?  Seems odd.

No, it is not odd but intentionally. Should I assign it to Oracle? ;)

I'll leave it as such until there is a well established and neutral standards body for microprofile.io.
At the end that source is 95% taken from the stuff we wrote in OWB and DeltaSpike, so it's basically (c) ASF.

And so far I have not even a clue who owns the microprofile.io domain (and thus probably the copyright).

> Its not specified how a config source is discovered

I think it is well defined in the spec and JavaDoc. Please look at the "Custom ConfigSources" chapter. Plz ping back if you find it not clear enough.

To answer it quickly:

You can either register a ConfigSource via META-INF/services/io.micropofile.config.spi.ConfigSource (the impl can either use java.util.ServiceLoader or OSGi service-registry for that matter - it's totally up to the impl).

Or you can also register a ConfigSourceProvider (the same way) which creates ConfigSources on the fly as needed. E.g. picking up all myconfig.yaml on the whole ClassPath and wrap them as ConfigSource.

It's basically the parts we also use in DeltaSpike

> There's some features/switches I'd recommend making. (e.g. addConfigSources(ConfigSource...) 

I had those initially ;) 

Romain Manni-Bucau gave the good feedback that a Config should rather be immutable. So we removed this and made the inner builder interface instead.

This might also answer the question for the 'release(Config)' method.

If you like to add additional ConfigSources at a later time, you can release the current config. After that the next call to ConfigProvider#getConfig() will collect all ConfigSources + ConfigSourceProviders again (picking up your new ones from a ConfigSourceProvider which initially returned no ConfigSources for example).

That's a bit different to DeltaSpike. We get an immutable Config, but it's a bit more complicated to add ConfigSources for information which is not available right at the start of the Container.

Let's talk about CDI-30 over at the cdi spec list ;)

txs and LieGrue,

strub

PS: txs for the feedback and good questions!

[Alasdair Nottingham]

If you assign copyright to ASF then I believe only the ASF could reassign copyright. My understanding is that in general ASF does not own the copyright for code in the projects, the copyright is retained by the author’s, but they license it to the ASF under the Apache license. In that sense it does appear odd to me, I would expect you to own copyright, but license it under the ASLv2.

Alasdair

-- 
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/41e81136-7f2a-4776-9c69-00f0278e7ce8%40googlegroups.com.

[Mark Struberg]

Hi Alasdair!

> If you assign copyright to ASF then I believe only the ASF could reassign copyright

No. Without diving too deep into IP law:

The core point is 'non-exclusive'. If I contribute to a project under ALv2 I don't give up my own rights! It's just that all the others also have (almost) the same rights now. I could go on and also use MY work and donate it to another project as GPLv2 or even a commercial license. But only MY work! As soon as someone else also contributed to that code (and I take that version), then I have to ask those people as well. It's a bit complicated and I hope I didn't take too many shortcuts with my explanation.

For the matter:

I wrote large parts of that code myself (and especially all of the spec wording). 

But the code and algorithm was mostly developed in ASF projects (Apache OpenWebBeans, Apache MyFaces CODI and Apache DeltaSpike). There also have been other ASF contributors to that codebase (Gerhard Petracek, Ron Smeral, Romain Manni-Bucau, John Ament). 

And that's the reason why the license header remained unchanged. Compare it with e.g. :

https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSource.java

It was originally planned to extract it off DeltaSpike core, simply because DeltaSpike is a CDI extension project and people always think the config stuff only works for CDI :( 

This was about 2 years ago and also one of the reasons for starting the Tamaya incubation proposal.

As it seems that Tamaya doesn't share the same goals anymore the option was to either move it inside DeltaSpike into an own module (perfectly possible) or to Apache commons ('SE commons') or Apache Geronimo ('EE commons' at ASF). Or even trim back Tamaya (though unlikely). 

Side note: I'm Apache Software Foundation member; VP, OpenWebBeans and OpenJPA; former VP DeltaSpike; PMC member in Geronimo and a other ASF projects. So (contrary to some claims) I certainly DO have the right to contribute code to those projects and use the org.apache.deltaspike and org.apache.gerinomo name spaces for such proposals. 

What do you not like about that header?

The main point is that it contains a TCK and an API which can freely used and copied. The impl part might work for some projects but it's perfectly possible to adopt it to other needs or even write an own impl from scratch. E.g if you have different needs in your environment and special OSGi integration etc. The only important part is that the 2 interface parts for the app developers remain the same (how to use that config + how to provide own ConfigSources and Filters).

txs and LieGrue,

strub

[Werner Keil]

Mark/all,

It seems the whole structure at least from a Maven point is all Geronimo:

<dependency>
	<groupId>org.apache.geronimo.config</groupId>
	<artifactId>config-api</artifactId>
	<version>0.1-SNAPSHOT</version>
	</dependency>

Except most API packages.

Guess it's up to the owners of the microprofile organization whether or not they feel that was acceptable. If Apache Foundation does not have antything against that outside its own repositories (or GitHub mirrors which are usually read only) I know of a case where a former  PMC member and VP decided to fork an Apache project. And I believe he also left the PMC or Apache Foundation (he's not listed as committer any more) which is why he was told not to use "org.apache" or the name "Apache soandso" for his new project.

As you're an active member of e.g. Geronimo, other than the members of  "microprofile" I assume people at Apache and Geronimo can tell you for sure, if that entitles you to use Maven GroupIDs or Java packages with "org.apache" in a project either in your own or a community GitHub repo.

Even without the intent of a "100% blueprint" for a possible future standard, being able to create independent implementations by others (e.g. different containers and its vendors) is not a bad idea. 

And unless either Oracle participated in the Microprofile effort or became Spec Lead of a Configuration JSR you contribute to, there is no reason or need to assign anything to Oracle;-)

Martijn mentioned, using a Maven license plugin for certain artifacts was planned, so unless it's only meant for examples, I am pretty sure this can and should be used by all other contributions, too.

Cheers,

Werner

[Alasdair Nottingham]

Hi,

I’ll start by saying IANAL, but when I contribute to Apache I do so under the ASF ICLA which is quite clear that I (or my employer) retain copyright for the work I contribute, however I grant the ASF a license to use it under the ASLv2. This is consistent with the copyright header in the source file you link to. It states that ASF has a license to the copyrighted work, not that it owns the copyright.

In terms of the comment I was making the PDF states that the Copyright for the spec is with the ASF, that (and this email chain) means you have intentionally transferred your copyright on the specification to the ASF and as such you lose any rights except for those explicitly granted by the ASL. As a result you cannot assign copyright at a later date to anyone, the ASF would need to. You being a member might make that somewhat simpler, but you would need the ASF to agree. 

I don’t really care one way or the other, but I don’t believe the ASF owns the copyright for OWB or DeltaSpike, I believe the copyright remains with the contributors as per the ICLA.

ICLA: http://www.apache.org/licenses/icla.pdf

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/cb4ecacc-af3e-48eb-bbf0-de757796edef%40googlegroups.com.

[Mark Struberg]

Oh I see what you mean. I totally overlooked the PDF. Good catch, txs!

.

As I've written all the wording so far (with spelling fixes from ASF member Matt Benson), I'm free to change this. Will of course ask Matt as well, but don't expect he is opposed to it.

How about the following (for now):

"Copyright 2016 Original Authors,
Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements.

Licensed to the Microprofile.io Community."

?

> I don’t believe the ASF owns the copyright for OWB or DeltaSpike

Copyright isn't always an exclusive right. After all 'copyright' is just a summary term for having the right to copy, modify, sell etc. All those rights can essentially can be dealt with separately as well. 

And that doesn't necessarily mean that the contributor gives up his own rights. Think about a book author who sells the copyrights for a book to different publishers in different countries. You just hand over a 'non-exclusive' right in that case.

Btw it gets a tad trickier with trademarks (as opposed to the copyright on the sources). The ASF resp the single PMCs hold those trademarks for Apache projects, so yes the term 'OpenWebBeans' is an ASF trademark. Sometimes unregistered, sometimes even registered ones (e.g. Hadoop). But we'll better leave that discussion for now ;)

txs and LieGrue,

strub

[Alasdair Nottingham]

That is what I expected. I'll provide technical feedback soon, still mulling the proposal over. 

Alasdair Nottingham

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/deae5935-0033-403a-ae0b-d8da1e0ed326%40googlegroups.com.

[Werner Keil]

Neither of us are lawyers, but I suppose when you come across a usable header, it seems good to coordinate with Antonio and others to apply it to any artifact contributed to Microprofile.io.

Also see the license thread https://groups.google.com/forum/?hl=en#!topic/microprofile/8UUYqkhYzHU

And maybe the involved corporate players (IBM, Red Hat, Paraya or TomiTribe) also get a chance to run it through their legal teams and provide input on headers. After all, they and their customers could be most affected if somebody believes there's a license issue and they (not Mark or other Individuals) are also more likely to be targets of lawsuits ;-)

Cheers,
Werner

[Mark Struberg]

Txs Alasdair!

I'll try to give you (and others) a bit background about the intentions and different parts.

If you have ideas then let's keep them rolling around.

1.) The logic with the ConfigSources is tried and proved in Apache DeltaSpike Config since 2011. 

It's actively used by 1000s of projects in production.

This work is the extract of the core ideas into an own package (because DeltaSpike is CDI focused, while the core config is really JavaSE only).

2.) The absolutely minimal parts necessary for this proposal and very core classes and interfaces are:

On the user facing part (API):

* ConfigProvider - to access a Config

* Config - the configuration itself. This allows access to the configured values.

That's it! 

On the 'user integration' part (SPI), intended for the developers to use in their projects:

* ConfigSource - a single 'source' for a configuration, e.g. a single property file

* ConfigSourceProvider - if you like to register n ConfigSources in one go (e.g. pick up all yaml files with a certain name along the classpath).

This part is similar to CDI Extensions! They are fully portable and intended for 'extension developers' in customer projects.

Think about a user who likes to pick up config values from a database table in his cluster.

Or simply provide default values in a property file named myproject.properties.

A user can use commons-config to read from xml or even provide values he reads from the Windows registry and provides it as ConfigSource.

Of course only for his very application! Another WAR/EAR might use totally different ConfigSources (in addition to the ones provided by the container by default).

3.) Now let's look at the other classes provided in the proposal.

All of them are *optional* 

3.a.) type-safe configuration

* Converter - Convert the configured String into a target type

If we want to provide a method 

<T> T getValue(String key, Class<T> asType)

then we need to convert the Strings to the asType target type.

Again: it of course might make perfect sense to provide this out of the box, but it's actually optional!

3.b.) filtering configured values on the fly

* ConfigFilter - modify configured values on the fly.

This can be used to e.g. decrypt secret tokens on the fly.

The other method is for 'output', e.g. logging or showing a value on the UI.

This can be used to mask out passwords with '*******' in the logs.

Again: totally optional feature, but both features really proved very useful in real world projects

Note: Romain and I are not sure about the exact signatures. 

Maybe add the Config as parameter or merge the 2 methods together?

Feedback much appreciated...

3.c.) * dynamic access with lookup Paths

* ConfigValue - allows caching, lookup paths, fallbacks, etc

The API is a streamlined version of Gerhards and Ron Smerals (JBoss) work in DeltaSpikes TypedResolver.

I've not merged this into master yet, so please check out this branch:

https://github.com/struberg/javaConfig/blob/configValue/api/src/main/java/javx/config/ConfigValue.java

Usage:

Config config = ConfigProvicer.getConfig();

ConfigValue<Integer> fetchProcessAmount 

    = config.access("myapp.processengine.config.fetchsize")

        .as(Integer.class)

        .cacheFor(5, TimeUnit.MINUTES)

        .logValues(true)

        .withLookupChain("postgres", "production");

...

fetchNumberItems(fetchProcessAmount.get());

Interesting might be the cacheFor() feature.

It allows to not trash the ConfigSources but still be able to apply values during runtime without the need to restart the server ;)

       

The withLookupChain() is also nice to have imo:

That example above (.withLookupChain("postgres", "production")) would result in the following key lookups until you find something non empty:        

 1. myapp.processengine.config.fetchsize.postgres.production

 1. myapp.processengine.config.fetchsize.postgres

 1. myapp.processengine.config.fetchsize.production

 1. myapp.processengine.config.fetchsize

The path logic is kind of a bitflag and decrementing those bits ;)

Imagine how nicely one can e.g. configure multi-tenant specific defaults inside his jars!

Of course this feature is again purely optional!

All those features (3a .. 3c) can easily be built on top of the core mechanism in a user project. 

But some of them might make perfect sense to incorporate in a spec. 

Please tell me if you like this feature and whether we might merge 3c over to trunk!

I'd personally prefer to not go far beyond those 8 classes as I would love to avoid a bloated API.

I hope the core concepts are now clear and it's easy to understand now. 

If you have additional questions and ideas then just shout out ;)

txs and LieGrue,

strub

[Werner Keil]

Hi,

From experience with many actual JSRs I can't remember any API static facade class called *Provider like the ConfigProvider intends to do (or does in a very similar way with Tamaya)

DeltaSpike has at least one or the other case, so I assume that's where this pattern came from in the first place?

Annotation a = AnnotationInstanceProvider.of(annotationClass)

For a core mandatory API offered in a modular way, there is nothing wrong with keeping the size and number of elements low. Take JSR 363: http://unitsofmeasurement.github.io/unit-api/site/apidocs/javax/measure/package-frame.html The mandatory core package consists of 7 interfaces and classes. The only JSR I remember only 1 piece smaller was JSR 330: http://docs.oracle.com/javaee/6/api/javax/inject/package-summary.html

I'm sure most involved know, CDI and DeltaSpike on top of those 6 elements are much bigger. CDI 2 tries to break itself down into smaller pieces right now with a "core" to work on Java SE.

ConfigValue<Integer> feels somewhat similar to Archaius' PropertyWrapper types:
http://netflix.github.io/archaius/archaius-core-javadoc/com/netflix/config/PropertyWrapper.html

If such type-safe extension can sit on top of a mandatory core in a modular way, why not.
As for the JDK or possible standards, the concept isn't new, JavaFX has dynamic type-safe properties like https://docs.oracle.com/javase/8/javafx/api/javafx/beans/value/ObservableValue.html

Unfortunately like other areas of Java SE 8 it remained an isolated "island" so far. A "Beans Binding" JSR (295) was withdrawn which pre-anticipated many ideas now realized by JavaFX. Whether or not this can be standardized any time soon, I don't dare to foresee, but if any of the ideas here should ever influence future standards, it may have to play well with both JSF converters and JavaFX converters (pretty much doing the same in a different UI framework) alike.

Cheers,
Werner

To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/microprofile/deae5935-0033-403a-ae0b-d8da1e0ed326%40googlegroups.com?utm_medium=email&utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href='https://groups.google.com/d/msgid/microprofile/deae5935-0033-403a-ae0b-d8da1e0ed326%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" onclick="this.href=

[Alasdair Nottingham]

Hi Mark,

I’m sorry for taking a while with my comments. Overall I like the proposal, I like the simplicity and it does what is needed. I do have a few thoughts:

1. I think it would be good if it suggested CDI injection of the configuration. That would remove the need to have the ConfigProvider class. I know it would be useful for Java SE, but in micro profile CDI integration would seem to be preferable.

2. I’m uneasy about the tie to the classloader. I would have thought a tie to the module or application would be better. I know in implementation terms this might often be the same thing, but I think that would offer more flexibility in CDI managed environments.

3. Following on from 1 I’d like to be able to express a dependency on some configuration existing so if it didn’t the bean wouldn’t have its dependencies satisfied.

4. It would be good if we could put some metadata into the application so an administration system could provide a nice admin view.

5. What about having a converter for URI or URLs?

6. I like the converter having a way to convert for trace vs non-trace so you can ensure things don’t end up in logs by mistake, but it doesn’t protect you if you do something careless and grab the config as a String and it gets logged that way. A common issue I’ve seen is putting it in a Java collection at which point logging the collection will result in the value in the logs. What about returning a Value with a getString method instead? Then people can use the Value class disconnected from Config, but still get the value as needed?

7. I was thinking I’d like a way to do default values so I can guarantee my code has config, but it can be overridden in a deployment, but then I realized you can do this with multiple config sources. It did make me think the pdf would be good if it had a couple of usage scenarios

Thanks

Alasdair

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/2ffcd0fb-0f6d-4ef3-8be7-d59e82a00174%40googlegroups.com.

[Mark Struberg]

Hi Alasdair!

Thanks again for your in-depth review, and glad you liked it so far!

> 1. I think it would be good if it suggested CDI injection of the configuration.

The problem is that you very often need the configuration _before_ the container is booted already :/

That is the reason why the whole config core really must be JavaSE only. 

Think about the following example we have in Apache DeltaSpike

@Exclude(onExpression="dbvendor!=oracle")

@ApplicationScoped 

@Transactional

@Specializes

public class OracleSerachService extends JpqlSearchService {...

Of course we can provide a @ConfigProperty in the spec (would be the 9th class) + define default injection capabilities.

But all that needs to be additional functionality _on top_ of the core config mechanism.

> 2. I’m uneasy about the tie to the classloader. I would have thought a tie to the module or application would be better.

Romain also doesn't like that, so it might be that the wording is not yet good enough. Let me explain how I mean this

Well, technically the ClassLoader is an implementation detail. In my easy impl I use a Weak map to the ClassLoader, but it's actually totally impl specific.

In your own app it might be a Map<WasApplication, WeakReference<Config>> or whatever. The only important point is that ConfigProvider#getConfig returns the Configuration for THAT Application. 

The only API which has the ClassLoader as parameter is ConfigProvider#getConfig(ClassLoader). But that is just the least common denominator for getting to 'the Application'. It's especially useful if you deal with EARs. Example: You have a shared @javax.ejb.Singleton in the ear/lib and 3 WARs. Now you get the first request from war1, which contains a custom ConfigSource. You don't like to pick that up, because then you would end up having config from war1 also in war2.

But EARs are beyond repair anyway :/

Point is: the ClassLoader is the only 'portable' way to reach an 'Application'. 

Any better ideas? Highly welcome!

> 3.

See my example from 1 and the whole Apache DeltaSpike Config + Exclude mechanism. Works like a charm.

 

> 4. It would be good if we could put some metadata into the application so an administration system could provide a nice admin view.

That also does already exist (although only in my customer projects). That might be a nice addition for each container to provide. 

I'd keep this as added value by the container and not pollute the spec with it. Of course, I'm totally with you that the spec needs to enable those features!

Think about the following:

A JavaEE container might provide  ConfigSources with well defined 'ordinals' out of the box

a.) a ClusterConfigSource shared e.g. via the DB over all nodes in the cluster. We use such a ConfigSource to configure REST and SOAP endpoints over our whole Cluster. Ordinal is bigger than app, but smaller than env and properties. Means somewhere around 170.

b.) a ServerConfigSource with e.g. ordinal=175

c.) an 'ApplicationConfigSource' to override settings for a single application  e.g. ordinal = 180

The container might also provide a nice UI in it's admin gui. The container knows all it's ClassLoaders anyway. Now you simply have to allow to select them and call ConfigProvider#getConfig(ClassLoader). (a nice additional feature of that method).

Then iterate over all the Config#getProperties and show them. 

In our UI we also show from which ConfigSource they effectively got resolved from (Config.getConfigSources() -> iterate ver getValue() and check where to find.

To view it in the UI I use Config#filterForLogging to have passwords starred out...

> 5. What about having a converter for URI or URLs?

Possible. But java.net.URL are kid of ugly left overs from the 90s in my view. But fine to add them.

> 6. I like the converter having a way to convert for trace vs non-trace so you can ensure things don’t end up in logs by mistake, but it doesn’t protect you if you do something careless and grab the config as a String and it gets logged that way. A common issue I’ve seen is putting it in a Java collection at which point logging the collection will result in the value in the logs. What about returning a Value with a getString method instead? Then people can use the Value class disconnected from Config, but still get the value as needed?

That should imo go into something like ConfigValue. Otherwise we cannot prevent all failures. Preventing users from doing wrong things will effectively also prevent users from doing good things. And it might blow up the API. 

> 7. I was thinking I’d like a way to do default values 

Hah, we have this in Apache DeltaSpike, but I intentionally left this out ;)

The reason is the following:

A user can easily add his default configuration in META-INF/java-config.properties.

That way it is _really_ well documented in a well specified place. And it is _not_ spread as constants over the whole codebase where you cannot easily find it.

Another huge benefit of this approach is that our Ops _immediately_ see all the possibly configurable values in their admin UI (see my explanation in pt5).

If it's just in the getValue("mykey", "somedefault value"); then it doesn't show up in any ConfigSource. So we have no way to tell the Ops people that they might tweak it.

There are quite a lot takeaways we learned from the last 6 years of using that approach ;)

> It did make me think the pdf would be good if it had a couple of usage scenarios

Yes, or maybe even better we write a second document with Samples and real-world how-tos as seperate document.

That way we would avoid to bloat the spec paper. Wdyt?

LieGrue,

strub

strub

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.<br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;

[Mark Struberg]

Oh, maybe my explanation of pt 1 is not fully clear:

The reason why we need the Config to be available before the CDI container is booted is simply because we often need it inside CDI Extensions during boot.

E.g. the @Exclude in my sample works with ProcessAnnotatedType#veto(). And in that early phase you simply don't have any @Inject available. This would only work _after_ the container is fully booted. And that would be WAY too late.

LieGrue,

strub

strub

[1] <a href="https://developer.jboss.org/blogs/mark.little/2016/07" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fdeveloper.jboss.org%2Fblogs%2Fmark.little%2F2016%2F07\

[Werner Keil]

Alasdair/Mark,

> 2.
Hard-wiring the static facade (ConfigProvider) to only use Java ServiceLoader seems a little restrictive these days.
Simply looking at some of the vendors around here, IBM/Liberty is all about OSGi, and there are also other containers where you can use it.

Modern JSRs and related projects allow to change the underlying SPI element, whether you call it CDIProvider (like CDI;-) or ConfigurationContext (like Tamaya does) The hidden private "SPI" element should probably go to an actual SPI or be detached from the static facade. To allow implementations to use what they best need, whether it's OSGi, CDI, Spring or good old java ServiceLoader.

Werner

strub

[Alasdair Nottingham]

I don’t have a problem with the service loader pattern as a way for someone to specify their implementation class, it is simple and a lot of people know how to use it. However I hate having implementation in static classes that do not allow the resolution of the implementation be overridden. OSGi is a key scenario where you need a way to plug in alternatives.

Thanks

Alasdair

-- 
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/ae5ecb0f-3acb-461e-a89f-1c81223e9ffe%40googlegroups.com.

[Mark Struberg]

The ConfigProvider loads an instance of the interface ConfigProvider$SPI.

I'm happy about improvements of this mechanism.

LieGrue,

strub

[Werner Keil]

As mentioned, a way to plug-in a new provider or SPI that's clearly defined via an SPI element would do.

Similar to CDI.setProvider() or http://unitsofmeasurement.github.io/unit-api/site/apidocs/javax/measure/spi/ServiceProvider.html#setCurrent(javax.measure.spi.ServiceProvider) in the JSR 363 SPI.

Something similar could be done in your provider with ConfigProvider.setCurrent() if you introduce the notion of a "current" provider (thus would  not require another class or interface)

Or if you prefer a separate element similar to ConfigurationContext as Tamaya calls it (the name is not as important as the fact that it can be extended and overriden)

Cheers,

Werner

[Mark Struberg]

The JavaDoc you linked to is imo very underspecified imo. 

What does it change? The ServiceProvider for the very web app? The ServiceProvider for the enterprise application? The ServiceProvider for the whole JVM?

That would be rather scary imo...

LieGrue,

strub

</div

[Werner Keil]

There's nothing underspecified. And the JavaDoc is from an actual JSR;-)

Another actual JSR you'll probably know: https://docs.jboss.org/cdi/api/1.1/javax/enterprise/inject/spi/CDI.html

CDI works in Java EE for some time now, but CDI.current() says "access to the current container", that's all. No reason to worry if that's the web container, enterprise container or entire VM;-)

That is an implementation detail IMHO and its implementations seem handle it quite well.

JCache has extra ClassLoader arguments, beside defining its own configuration in a proprietary,  JSR-specific way;-|

If you really think you need stuff like that in an API/SPI suit yourself: http://ignite.apache.org/jcache/1.0.0/javadoc/javax/cache/Caching.html

However, JSR 107 seems unflexible and so far relies on java.util.ServiceLoader only. You can set the default ClassLoader, but everything else is written in stone (and cannot be overriden  because the accessor  is final)

I would allow extending it. or set something "useful" like the ConfigurationContext or ConfigurationSpi, etc. 

Cheers,

Werner

[Werner Keil]

A good API makes no restrictions where it can avoid it. 

JSR 363 is already used in Enterprise containers or with Spring via Parfait. Should an implementation have special needs in a Web or Enterprise environment, ServiceProvider is extended for that environment. There is neither reason nor need to force something like "web container" onto the API because that API works in small Embedded devices like a Smart Home or Smart Car or in large Enterprise containers through systems  like Parfait. They each have differrent requirements.

I saw you tried some of the JCache like approach. 

CDI makes very few assumptions in the API/SPI. Those that are for Java EE only like @ApplicationScoped, etc. are now subject to modularization, because many of them make no sense for Java SE. However CDI.getBeanManager simply says "Get the CDI BeanManager for the current context"

There is no assumption or suggestion whether thats Application, Web or Portlet Context (e.g. for JSR 362;-)

[Mark Struberg]

> Another actual JSR you'll probably know: https://docs.jboss.org/cdi/api/1.1/javax/enterprise/inject/spi/CDI.html

It is as underspecified as the money one.

And thanks for educating me about CDI - didn't know about that ;)

Point is: It is always set by the container when it boots up. So it doesn't matter if the container core invokes any 'setProvider()' or if it triggers the getConfig() once and thus 'sucks in' the default implementation provided by the container.

The only exception I can think about by now would be if an application would provide it's own API jar. But in that case most containers simply ignore those packages and have a a parent-first logic for ALL packages starting with java.* and javax.*. On some containers this is configurable, on others not. Those where it's not configurable are usually the lightweight ones. And for those you can simply swap out the impl in the lib folder of the container itself.
So I see no benefit. Do I miss anything? 

Also take into consideration that the impl might also delegate through to some other impl. It's basically all up to the vendor - without changing anything for the user.

JCache works fine btw.

> However CDI.getBeanManager simply says "Get the CDI BeanManager for the current context"

And as we all know that is broken when it comes to the gory details of EARs.

That exactly is one reason for ConfigProvider.getConfig(ClassLoader).

LieGrue,

strub

[Werner Keil]

We took Money and its Bootstrap/facade approach into consideration, but based on discussion and refinement in the EG we simplified it in JSR 363. It's not the place here to discuss JSR 354 in detail, but e.g. exchange rate providers seem to behave "odd" based on some user's feedback, but his special case involves cron jobs and could not be reproduced as of now.

CDI is struggeling to find the right balance between Server and Desktop (Embedded, "Micro" or "Serverless") environments in 2.0 as you should know;-)
It started as a Server only solution. JCache as it stands in JSR 107 targets SE or "standalone" usage at first I'd say. It's used with Spring, CDI and other server-side components, but until maybe some day it'll be added to some (EE) profiles it's a standalone JSR just like 330, 354 or 363.

Bean Validation is another example that comes with a small, single-class accessor.
https://docs.jboss.org/hibernate/stable/beanvalidation/api/javax/validation/Validation.html
You find different implementations, including Apache BVal. These implementations whether it's Hibernate Validator, BVal or others deal with aspects like CDI integration. On its API or SPI level that is no concern to Bean Validation itself. Nor is it to JSR 363.

>Also take into consideration that the impl might also delegate through to some other impl. It's basically all up to the vendor - without >changing anything for the user.

That's exactly the point. Extension modules like SI or Unicode (https://github.com/unitsofmeasurement/uom-systems/tree/master/unicode) are supposed to extend ServiceProvider and offer all extension points they need, e.g. unit systems or other services.

Whether they deal with special environments like an OSGi or EJB container is totally up to them. The only thing ServiceProvider cares about is e.g. the priority if multiple providers were found.
Somewhere along the lines of http://tamaya.apache.org/apidocs/org/apache/tamaya/spi/PropertySource.html#getOrdinal--
(or the similar method you got in the provider now, the JavaDoc shows, it was heavily inspired by DeltaSpike)
However, DeltaSpike implements and extends the CDI standard, yet CDI does not impose things like

1. System properties (ordinal 400)
2. Environment properties (ordinal 300)
3. JNDI values (ordinal 200)
4. Properties file values (/META-INF/applicationConfiguration.properties) (ordinal 100)

Or

>That means, you have to add e.g. deltaspike_ordinal=401 to /META-INF/apache-deltaspike.properties . Hint: In case of property files every >file is handled as independent config-source, but all of them have ordinal 400 by default (and can be reordered in a fine-grained manner.

This has no place in an API or even SPI on that level. It's purely implementation specific. The priority e.g. in javax.measure.spi.ServiceProvider simply states the higher priority is used to select between two providers if multiple are found, but we did not write unnecessary assumptions there like:
1. SI Units: (priority 100)
2. US Customary Units (priority 200)
...

The service provider and spec has no knowledge of either SI units or others. That's its purpose to be implementation agnostic.

If the ClassLoader is necessary in some cases, why not, feel free to use it. We did not feel that's necessary in the case of JSR 363 and the API is ultra-slim for a good reason (only JSR 330 is probably a few kb smaller ;-)
If such requirement came up, we could add it at a later point, but IMHO JCache or Bean Validation are also loaded with things like configuration or even "JDK substitute" classes like

public interface Factory<T>

in JSR 107 that blow it up beyond the core need of caching. We had a few similar interfaces like Parser<T>, too, but removed them from the core API as they did not add real value there. Either they're part of implementations or other libraries now, but not the small API/SPI.

Cheers,
Werner

[Werner Keil]

Extension modules are not supposed to mix implementations (e.g. the RI and the Java SE 8 port) but that's nothing new.
Among the most important goals when we applied Multiconf in a large Cloud was to allow combinations like deploying IBM JRules (including Apache OpenFaces) in a JBoss EAP container (using Rich Faces then, seems that was just shut down: http://richfaces.jboss.org/, maybe Wildfly also uses OpenFaces now?)
And out of the box that just didn't work without a lot of configuration and classpath isolation "magic".

Should apps use PrimeFaces, ICEFaces or another implementation, that'll multiply such problems.

The beauty of a "Microservice" or "Container" approach these days is, that you can often avoid this simply by putting them in two separate (Docker or similar) containers.
And similarly in a distributed "Sensor Web" environment you also normally wouldn't run JSR 363 RI or other light-weight implementations for Edge Devices and a Java SE 8 or similar implementation for desktop/server in exactly the same JVM or physical device. They are usually far away from each other;-)

[Mark Struberg]

You are totally confusing things. We discussed picking up the implementation (like ValidationProvider, JPA Persistence, FacesContext, CDI.current(), etc).

That has nothing to do with the ConfigSources. And of course there are specs where we have tons of defaults and even magic numbers. 

E.g.  adocs.oracle.com/javaee/7/api/constant-values.html#javax.interceptor.Interceptor.Priority.APPLICATION

Please stay on the topic and don't always go off-topic.

There is a big potpourri of different ways to achieve the same goals. 

I really don't care much what other specs are doing. 

The only thing I DO care are use-cases. If you have a use case which cannot be solved with the proposed API then go on.

But please finally stop highjacking this thread to go off rails by discussing other specs. Open new threads if you like to discuss CDI or anything else.

thanks,

strub

[Werner Keil]

Please keep in mind there are no "other specs" because this IS NO spec and never will here;-)

It's at most an idea similar to say EHCache, not JSR 107 that later became partially inspirational to 107/JCache but not its RI either.
It now implements JSR 107. If there may be a Config JSR (by Oracle or others) taking inspirations from other JSRs (whichever you think suit your idea) may make it easier to implement that, but that is totally premature and not worth discussing here any more.

The thread was wrong in the first place, so hope that's clear now, nobody talks about a JSR or standardizing configuration here.

It's a possible alternative to the likes of DropWizard, Spring Config and other solutions aiming to offer support building Microservices with Java.

Cheers,
Werner

[Mark Struberg]

> The thread was wrong in the first place, so hope that's clear now, nobody talks about a JSR or standardizing configuration here.

Quite a few _other_ people already gave constructive feedback.

You are actually the only one who seem to try to forcefully destroy any constructive discussions.

This is really annoying, please stop it!

txs,

strub

[Werner Keil]

My last reply here is pointing to a better, new thread: https://groups.google.com/forum/?hl=en#!topic/microprofile/5CZYa1uughU

There is no "Config JSR" here and never will be. As mentioned in many other threads, building blocks like Netflix OS (also offering quite a decent configuration support with Archaius btw.;-) or "home-grown" libraries could be part of the "Microprofile Stack" but it does not intend to standardize technologies at this point.

Try to respect that and focus on creating a useful solution, otherwise "the stack" will just look elsewhere...

[Werner Keil]

Please stop this thread, it's misleading, continue https://groups.google.com/forum/?hl=en#!topic/microprofile/5CZYa1uughU please,

And take a look at Archaius 2, it really rocks from what I see and is as close to a JSR blueprint or inspiration as it gets;)

Cheers,
Werner

[Mark Struberg]

No this thread is surely not stopped.

Werner, it's really unfriendly to declare a thread as stopped only because _you_ don't like it.

If you don't like it then simply stop participating and    l e t     u s     w o r k !

You can of course open a new topic whenever you like and about whatever you like. 

But please stop disturbing people who try to move things forward.

txs,

strub

[Werner Keil]

We missed you in yesterday's fairly constructive hangout;-|

Oliver will send out the minutes and further roadmap. Everyone who has something constructive to participate is more than welcome to help.

The other thread is about configuration in general. Archaius is certainly a strong force to take into consideration, but Tamaya also being used by several clients and projects already has gone far enough to continue. And aim for graduation if ASF feels it's ready for it.

As we also briefly discussed, nobody knows for sure at this point, if Oracle will start, lead or "accept" a Configuration JSR at all, or rather try to keep a tight grip and control over it by simply doing this as a JEP in OpenJDK. So working on a "JSR" right now is a waste of time, brain power and energy I'm afraid. Working on even multiple approaches on an Open Source basis for the community to chose which ones they like best, sure, why not do that;-)

I was hoping to focus on extension modules to such solutions (be it Tamaya, Archaius, DeltaSpike, Spring or Commons Configuration) and we also discussed how it could better work to decouple the "Kernel" from extension modules. Archaius or JSRs like 354 and many others see a vivid community writing extensions. Not everything has to be done at Apache, so that's one of the goals that will reduce the number of modules and perceived "complexity" of Tamaya as it stands now. If I can help I'll certainly be happy to contribute to its "Kernel", too.

Cheers,
Werner

[Mark Struberg]

FTR: JavaConfig is now part of the official JavaEE8 roadmap. And heavily influenced by this very proposal. 

So we already achieved some partial success.

The next milestone is to get the yet to be made official JSR on track and finish it as fast as possible and make it as lean and focused as possible.

LieGrue,

strub

Am Freitag, 15. Juli 2016 00:01:28 UTC+2 schrieb Mark Struberg:

Hi!

I know a bit about configuration. I wrote the original stuff in OWB and together with Gerhard Petracek I did the config part of Apache MyFaces CODI and Apache DeltaSpike.

I've now extracted the most important bits out of DeltaSpike into an own project. 

The approach is strictly String/String based. Namespacing is achieved by using dots similar to Java package names.

The API itself has only 2 classes (Config and ConfigProvider).

The SPI for extending the config mechanism has 4 classes. 

Anything else can easily be provided on top of it. E.g. caching, variable resolvement, ProjectStage, conditional lookups, etc. All that stuff is easy to add on an additional layer later.

https://github.com/struberg/javaConfig

Happy to get any feedback.

LieGrue,

strub

[John D. Ament]

Great news.  I'm assuming then you've been in chats w/ the folks are oracle and the J1 session on this topic is based on this?

John

[Mark Struberg]

Yes, since 3 weeks already. But we agreed to keep it silent to not spoil anything before J1 ;)

LieGrue,

strub

[Werner Keil]

The proposal was not mentioned (Linda briefly did in her F2F discussion with the JCP EC) at all by Dmitry in his slides: https://static.rainfocus.com/oracle/oow16/sess/1471982098231001nCBx/ppt/Java%20EE%20Configuration.pptx
A few bits of the naming, e.g. a "Config" type instead of "Configuration" sounds similar, but I guess he rather got it from Typesafe: https://typesafehub.github.io/config/latest/api/

Which like most others features type-safety, something totally absent in Mark's approach.
Being also the (award-winning) Spec Lead of JSON-B he confirmed, the type-system and e.g. mandatory built-in types like numbers or Date/Time should be quite similar to e.g. JSON-B (or Typesafe Config)

He presented a great overview of the config evolution, starting primarily with Apache Commons Config and having the likes of Archaius and Apache Tamaya as the most advanced examples. In between others like Spring Config or DeltaSpike.

Cheers,
Werner

[Gunnar Morling]

Werner,

Thanks for sharing these slides.

Below you mention type safety, do you have some more details on this? The API on slide 29 looks rather type-unsafe. I only quickly skimmed through the slides, though. Would be eager to learn more :)

Thanks,

--Gunnar

[Werner Keil]

Gunnar,

Thanks for the update and your interest. Anatole said he'd also updated his slides about Tamaya, [CON1141], I could not see link to the slides, but know from my own talks, the content sometimes takes a few hours to propagate. Should be there throughout the day I hope.

Tamaya similar to the JSR ideas Dmitry based heavily on it (and a few others like Typesafe or Spring) is based on string config entries. Sources like XML, JSON, YAML or others. Which then through Converters can be parsed into an appropriate type. Not too different from JSON-B (also with Dmitry as Spec Lead), JAX-B or JSF.
While it seems to store information as a map of Java objects rather than strings, Apache Commons Config 2 also contains new elements like a ConversionHandler:

* <p>
30	* This interface defines a couple of methods related to different kinds of data
31	* type conversion:
32	* </p>
33	* <ul>
34	* <li>Conversion to an object of a specific type</li>
35	* <li>Conversion to an array of a specific type</li>
36	* <li>Conversion to a collection of a specific type</li>
37	* </ul>
38	* <p>

The idea is not so different from the converters of Tamaya or the JSR proposal by Dmitry.

The Spring or Typesafe Config holders that would be closest (PropertySource, ConfigImpl) use generics. And while I have not looked into Spring in so much detail, Typesafe Config has a number of wrappers like ConfigInt. They feel somewhat similar to JavaFX https://docs.oracle.com/javase/8/javafx/api/javafx/beans/property/package-summary.html.

Spring also uses Generics, so most of these holders go down to more or less the same idea. Some with more, others with fewer special cases for particular types.

Especially the JSR is not written in stone, and if you or others feel, such mechanisms worked better than marshalling/unmarshalling from string based attributes, please join the EG on behalf of  Red Hat once the JSR is formed. I guess you'd be very qualified based on Bean Validation. Can't say off the top of my head, if validation is aimed for Java EE 8 or 9, but I believe it should play a role. Some alternatives (to Microprofile) especially Dropwizard showed, how that's done ;-)

Regards,
Werner

[Mark Struberg]

Werner, please stop top-posting and finally stop spreading wrong information again. You again behave like a troll.

Dmitry and I had a hangout 4 weeks before JavaOne where we talked about my proposal. Go ask him if you don't believe me. He even sent me his slides for review 2 weeks b4 JavaOne...

>  type-safety, something totally absent in Mark's approach.

You didn't read my proposal it seems?

https://github.com/struberg/javaConfig/blob/JSR/api/src/main/java/javx/config/Config.java#L50

Oh and the variable stuff?

https://github.com/struberg/javaConfig/blob/configValue/api/src/main/java/javx/config/ConfigValue.java#L54

all there. But only needs 7 classes...

Am Montag, 26. September 2016 12:04:34 UTC+2 schrieb Werner Keil:

[Werner Keil]

Mark,

Please stop your trolling and disturbing the exchange of thoughts e.g. by Gunnar who asked a constructive question.

Dmitry and I met at JavaOne, as he did with Anatole, John or others involved here or at Apache.
His slides unlike Anatole's Tamaya session and live demo (http://www.slideshare.net/AnatoleTresch/configure-once-run-everywhere-2016?qid=df430bd9-a8a3-4e12-8182-03576d31696b&v=&b=&from_search=1) are "pseudocode", but it's been clearly inspired by the likes of Tamaya and a few others. Not the way you earlier drafted with some multiple calls via "asType" or similar.

Seems your strawman proposal was improved based on Tamaya, Spring Config and others, at least there was no get(Key, Class) there when you pointed to it before or called it "your own JSR" once.

ConfigValue you got from Lightbend/Typesafe, or others, but if you look at Dmitry's slides they state "keys and values are strings" so it's closer to the Tamaya approach and current implementation.

Other slides mentioned the evolution of config systems, DeltaSpike is mentioned as some step on this ladder, but there are others since then.
He should propose the JSR in the near future. So instead of constantly acting like "Mr. Ricola" (Wer hat's erfunden?) and making a fool of yourself, please just ask the Spec Lead(s) to join the EG and then (just like it's done elsewhere, e.g. JSON-P) you may contribute to a JSR while it's being shaped.

Dmitry and I discussed your input to that JSR. And mainly because it is simply more consistent with JSON-P 1.0 he also leans towards interfaces (whether Java 8 style or not is up to the EG, no need to discuss that here now)

Cheers,
Werner

[Mark Struberg]

You claimed that the new JSR is mostly influenced by Tamaya. I just corrected this because it is not true. 

> ConfigValue you got from Lightbend/Typesafe,

Nope, from DeltaSpike TypedResolver, that's why I also added Ron Smeral (RedHat) and the other involved people as co-authors. I have absolutely no problem giving props to people who really do the work! But I get pretty pissed when people try to claim fame for stuff they simply didn't write/invent themselves!

The point is, the initial code in Tamaya was pretty much bloated and hard-tailored for a few specific use cases before Gerhard Petracek and I explained to them how it could properly work.

We had a series of hangouts and while explaining we basically threw away the original stuff and did it properly. Of course, Anatole also added some very valueable input to this, so kudos to him. Reinhard Sandtner as well. You don't believe me? Well github doesn't lie:

https://github.com/apache/incubator-tamaya/commit/c4e24709b13774413bf18d42b0fb41344648b00b

Oh and you see date and the author tag? Where are your contributions to Tamaya? Show us some commit logs...

The logic of Tamaya is basically taken from DeltaSpike (written in 2011), see 

https://github.com/apache/deltaspike/commit/fb0131106481f0b9a8fdc13b9879a5482219c736#diff-c414b92812ebe47acc35539f25d4db45

Enriched with a few (good!) ideas rom Anatole and Reinhard. The problem I have is that later on way too much stuff got added to the core API. We (the active Apache mentors) tried to push them for some time to move all those 'additional' stuff into pluggable modules and _not_ make them part of the core api. But it went pretty much out of control. ConfigOperator? ConfigQuery? What is that for? I got no explanation till today...

Btw the DeltaSpike stuff got ported over from MyFaces CODI (written by Gerhard Petracek, Jakob Korherr and me) which was based on the stuff I did in OpenWebBeans in 2009. I even wrote a blog post about it in 2010:

https://struberg.wordpress.com/2010/09/21/flexible-configuration-for-modular-systems/

The nice thing on the internet is that I can prove all this. And you cannot because you didn't write it. As simple as that. So either you show me your comitts or stop claiming and behaving like you are the 'father of config' blabla.

Tamaya (Anatole and you as well) did a good job in giving conference talks, etc. But that obviously wasn't enough for creating a JSR for 2 years. Oracle only started to move when this very microprofile group was about to create a configuration standard which was not under their control. There have been informal talks about exactly this, also with Oracle representatives. But that is way beyond your influence...

I'm also looking forward to working on the ConfigJSR, but please stop bashing the work done by other people.

LieGrue,

strub

[Werner Keil]

Again the slides Dmitry presented (see link earlier) is pseudocode, inspired by various sources.

The "ConfigProvider" static class was something Tamaya more or less inherited from DeltaSpike prior in the evolution process (nobody denies that)
Everything else except the name Config (which Typesafe also introduced back in 2011 so you certainly did not take that from DeltaSpike) has not the slightest similarity with your own proposal or draft. In fact @Config exists in Tamaya except there being used as annotation (similar to Spring's @Configuration)

getProperty() are method signatures you'd find in both Spring and Apache Commons Config.

So pseudocode. The only thing Dmitry probably forgot to mention is Typesafe Config.

Instead of further Ricola arguments, just take the timeline from Dmitry's slides. He did not mention Typesafe, but the earliest approaches are Apache Commons Config and Spring. Whatever came then, CODI, DeltaSpike,... took inspirations from those whether you'd admit it or not.

You insist giving everybody credit, but keep denying Mike Keith's role in it. https://vimeo.com/56225529 was at least a year before JavaOne 2013. He discussed this much earlier than talking about it at JavaOne. At GIDS 2011 he had a different topic, but as I gave a Java EE 7 keynote there and Tom Marrs from Denver JUG spoke about Apache Commons Config, we also discussed it there already. Especially since I helped an Offshore team where they did "configuration injection" by unzipping the WAR or EAR with WinZip, change the content of XML or properties files and then zipped it up again;-D
That's when Mike Keith's idea for the "CAR" archive was born.

Mike (he was Oracle's rep in the 330 EG, they did not name them at the time, but he was very active in mailing lists, etc.) did a lot to make JSR 299 (CDI 1) and 330 work together after heavy arguments and at least verbal fights. Being both in the Java EE 6 Umbrella JSR and the EC at the time, that also got me involved in some of the discussions from the EC side especially regarding the "spec" (only JavaDoc like very few others, e.g. JSON-P) for 330 or the lack thereof.

So it's not always about pushing code. Do you see Mike's name as author in either CDI or JSR 330? I don't think so, but while we had two major companies behind Microprofile, IBM and Red Hat each against one of them (Red Hat abstained or did not vote on JSR 330 because of "its own" 299, IBM voted against JSR 299 because it though it would be unnecessary competition with other "then en vogue" principles like EJB;-) and no sign of consensus between the two JSRs on how they could build upon each other, it was Oracle and Mike Keith who helped find a solution. Without him neither CDI nor DeltaSpike as you and others built on top of it or CODI, OpenWebBeans, etc. would ever exist.

Cheers,
Werner

[Mark Struberg]

Werner, no lame excuses please - where are  Y O U R  contributions? None to show? Ok, but then please shut up on this very thread! As simple as that.

PS: I do _not_ deny Mikes role. You claimed so, but I didn't! In fact I met with Mike three times back then as well. Just ask him. But that was in end of 2012 to start with.

And back then Mike aimed for cleaning up all the various deployment descriptors as main target - which is quite a bit different from application configuration. Nontheless it was an important step in getting Oracle to be aware of the problem. Too bad this effort seems to have been messed up when Mike got moved to a different role within Oracle.

[Werner Keil]

Well, 2012 was long after Mike had discussed these things with me and others before. So once again, there are plenty of ways to contribute, this mailing list or that of JSRs.

I keep JSON-P (JSR 374) alive (including my talk), same (with significant input by Arjan) for 375, Java EE Security.
Yet, others push the code at least for JSON-P, so save us those lame arguments please.

More examples, JSRs 360 or 361 see http://docs.oracle.com/javame/config/cldc/opt-pkgs/api/meep/api/ under "Contributors".
It's like pretty much everything on the ME side closed source, so you can't even look it up who at Oracle actually wrote the code, but with the JSR 361 EG (some of that I applied to 363 in a more open, transparent manner) I helped to define exactly the kind of "Mix & Match" profile, Microprofile is still struggeling to get into the Java EE world;-)


So just shut up please and let those who are willing to do something constructive in or outside the JCP do their work.

Thanks,
Werner

[Heiko Braun]

Werner/Mark,

I'd suggest you either find back to an acceptable tone in these discussions or you take your arguments offline. 

Regards, Heiko

[Mark Struberg]

No answer is also an answer ;)

[Werner Keil]

Everybody else but Mark uses an acceptable tone and refrains from aggressive wording (including BOLD shouting and other means of a bad temper;-)

Gunnar was polite and provided constructive feedback. Till Mark got on his trolling trail.
We had a lot of good conversations about the JSR proposal, but except Linda during the EC F2F (you have to wait for the minutes for Sep here https://jcp.org/en/resources/EC_summaries) nobody mentioned him or his discussion items here or elsewhere.
Sorry but that's how it is. If ideas influenced primarily by Tamaya sounded also like DeltaSpike, that's because some of the concepts (e.g. when it comes to ordinal or ConfigurationProvider) were inspired by it, while he still decided to play a more or less constructive role in it.

The biggest difference is, that the likes of Spring Config, Apache Commons Config or DeltaSpike were all meant to work inside just one container. Strict wording like a "JNDI ordinal" and mention of only .properties files etc. are clear indicators.
The main reason why Tamaya was accepted despite Apache Commons Config (or DeltaSpike's subsystem) being around for all those years is, that it aims at the Cloud, not just a single container or JVM.

- Archaius
- cfg4j
- Tamaya
- Spring Cloud Config

are all examples of Configuration systems for the Cloud or "Microservices".

Regards,
Werner

[Werner Keil]

I am pretty sure, with such erratic behavior and bad temper someone like Mark would never win a JCP Award or even be nominated.
Many others did, including Dmitry or myself this year. Anatole also did last year. And he's a Star Spec Lead, too.

Mark probably claims the 2 or 3 times Apache Foundation won it for himself because he IS Apache Foundation;-D

Cheers,
Werner

[Mark Little]

+1

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/85442e1e-c786-4f6d-bac8-28323e2eaf66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Little]

Werner, let’s keep these discussions about technical aspects of MicroProfile.

Thanks,

Mark.

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/03915ee0-1edd-4037-b1a7-85e2184aa209%40googlegroups.com.

[Werner Keil]

Thanks for your +1

That (focussing on config solutions for the Cloud or Microservice rather than somebody's own personality show) is what this thread https://groups.google.com/forum/?hl=en#!topic/microprofile/5CZYa1uughU is meant for.

I guess the recording of Thursday's panel is not online (only saw BOF minutes) but you or those who attended will also recall Anatole's input there and the positive reception by panelists and attendees.

Regards,

Werner

[Mark Struberg]

> The main reason why Tamaya was accepted despite Apache Commons Config (or DeltaSpike's subsystem) 

> being around for all those years is, that it aims at the Cloud, not just a single container or JVM.

Werner, please re-read your text again. 'Only' Tamaya aimed for the Cloud? lol. You don't believe that yourself,  don't you?

Your problem is that the Internet is sooo merciless and everyone can read up the facts years later:  http://mail-archives.apache.org/mod_mbox/incubator-general/201411.mbox/browser

To spare you the reading: The reasons why Tamaya was accepted in the ASF incubator back then was that we tried to extract the best ideas of a few configuration systems to eventually go for a JSR.

But soon after we started it became clear that the initial code drop proved to be too restrictive. So we had to fall back to the DeltaSpike solution. That's it, accept that fact. Go ask Reinhard Sandtner, Romain Manni-Bucau, Gerhard Petracek and even Anatole if you don't believe me.

DeltaSpike-Config is btw already heavily used in apps running in the cloud. Pulling config from GIT or Consul is just another portable ConfigSource. Same as in Tamaya (where it got renamed to PropertySource, that's really the whole difference if you compare the sources). And that's really how it should be! We don't need any hardcoded 2MB libraries which are not flexible for future situations. We need a thin, flexible solution which can quickly adopt and evolve to many use cases now and in the future. Please let us avoid that JavaConfig becomes the next java.util.Logging!

LieGrue,

strub

PS: I won't respond to your personal attacks.

[Werner Keil]

Just read Anatole's slides, Tamaya despite your constant attacks (primarily against it and those contributing either on the mailing list or directly pushing code) works in the Cloud with consul, etcd and many others.

At least 2 Spring Boot like CDI based Microservice "containers" also use Tamaya. And ask Oliver, Anatole and others which corporate clients do (not all may be willing to act as references, but that seems similar for all the great DeltaSpike Cloud stories, too;-)

No more of your nonsense, the other thread is meant for facts about configuration.

It's up to the Spec Lead and experts of a (not even officially proposed) JSR how it does. 

The fact, that it's proposed as a standalone (Java EE afine) JSR hoping to enter the Java EE 8, 9 or later platform release train is a good sign. Oracle could also simply have declared it another JEP at OpenJDK like the Java 9 REPL or java.time (is there an independent implementation of that by Apache?;-)

License discussions and Oracle being open to have a RI at Apache (Tamaya) will show, if the very challenging schedule (Final in less than a year) can be met or not.

Every working solution or "finger exercise" by some individuals has one thing in common, they are all under the Apache License, so if the strict No-Go for JSRs by Oracle targetting the Java EE or SE platform with Apache license was kept, then none of that can or will be used. The EG and Spec Lead would have to write it all from scratch under Glassfish.

Cheers,

Werner

[Mark Struberg]

So you prefer to believe a slide made-up in 2016 more than the plain facts laid out in front of you in form of links to mail-archives, commits etc when it did originally happen?

That's really an 'interesting' perspective...

[Werner Keil]

No, I believe the actual live-demos Anatole showed everyone. I don't think the sessions in that room were recorded (neither in Dmitry's case or mine on JSON-P), but ApacheCon NA also  did not invite him (and fully pay his trip) for nothing.

Maybe that was recorded, otherwise come to some conference and see for yourself;-)

[Ondrej Mihályi]

Werner/Mark,

Please just stop or make your discussion private. Noone really reads it anymore.

Btw, Mark Little gave +1 to Heiko's suggestion to behave yourselves, not to anything any one of you posted.

--Ondrej

[Amelia Eiras]

Hola wonderful #usualsuspects,

 I enjoyed seeing many of you last week during JavaOne, what a legendary week, loved it! 

---------

This thread has 461 views, wonderful pull of attention. :)  

---------

I would like to note that some of the tone through out the written messages has been not optimal. 

Everyone who participated in those sections is at fault & equally responsible for some of it "unfriendly" wording. 

----------------

It is counter-effective to be defensive...  &  waist the 461 readers' time dwelling on stuff on such a "negative" integration.    

MicroProfile is about  adult & healthy collaboration.  There are no judges & none is a know it all.

Being grounded is key. 

--------------

When communicating, we can always do better. There is not a single person I know that it is a master at it. 

We all make mistakes...  sometimes we used the power of our  emotions too fast instead of a bit of logic & thoughtful reflection...  sometimes we lose sight of the bigger picture, being too stubborn to enable our brains to actually stop & be a bit wiser ( i call that "smelling too much of our own farts" ) i hope that quote makes all the readers smile:)   

There is nothing wrong with  showing passion about stuff.  It is the beauty of being us, unique!

--------------

Personally, i believe that the most important thing when communicating, aside from proactively listening, if knowing when to stop ourselves from talking.

 

I believe this thread has arrived at its end. Lets move forward, be kind & be just!

Abrazos a todos,  

[Werner Keil]

I believe Mark chilled down by now.

And regarding Tamaya, the Apache community as a whole (not single people who don't wish to participate any more) continues to be excited about it: http://sched.co/8UM6

There are no talks about e.g. DeltaSpike, Geronimo, etc. so even if its committers should have proposed something, it was not selected.
Nothing on TomEE either btw ;-O

So while one or the other continues to spread microaggressions (maybe they believe that should be part of MicroProfile?;-) here, everyone else sticks to facts.

And the facts speak for themselves, so hopefully the sources of microaggressions here keep them to themselves now and stay silent.

Cheers,
Werner

[Amelia Eiras]

Werner, you and I have been friends for a long time, I know you mean well when you share your opinions. 

However, how can you read my message above & blatantly feel justified to reply with: "I believe Mark chilled down by now.” 

 Do  you actually consider yourself not a part of the issue that lead to the negative tone on this thread?  

My first instinct was to disregard your reply, to let go & move on.  Part of knowing where silence is a must b/c any other action make no sense. 

Yet we are friends,  how can I ignore your reply & still expect to respect you?   I choose to share my thoughts below bc you, as a person, matter.   

Your reply is the highest level of BS I have read in a long while.  Everything written after first sentence means nothing & is worth nothing.  

You, alone-  have single handedly decided to take zero responsibility on the negative tone of many of the messages on the thread. How can you do so?  Why would you even reply in such a manner?   ... staying silent in turn would have shown you took responsibility.    

As your friend,  I recommend you go back to the 1st email on this thread & read the full thread, carefully.   

---------

Only those who do nothing, make no mistakes & have no room for improvements.  Our actions lead to “products”...  base on the outcome, we adjust our actions, hopefully aiming at doing stuff just a tiny bit better, each time.

 

I believe that at its core, it is not our mistakes that matters, but the acknowledging that we made a mistake and the courage to correct it. 

Cheers my friend,  

[Werner Keil]

There are different, more technically than ideologically driven threads here now, started e.g. by Gunnar, so I guess this one can be considered to have outlived itself;-)

In another reply, Mark also suggested using Tamaya for particular use cases, so I guess he also changed his view and tone regarding Tamaya which was a large part of the problem here in this thread more focussed on "Who invented what first?".

Let's leave this thread and focus on technical details in others now;-)

Cheers,
Werner

[Anatole Tresch]

Hi all

I just went through this thread. I am happy that it has found its end here (dont restart it, please). I see misunderstandings and also invalid claims on both sides. As a result I only can ask so stay focused on getting a config JSR up and running, which is something the whole eco-systems will profit of. And be aware that we even with the latest proposals presented at JavaOne we still do not have yet a running JSR (but hopefully get one soon...), so we as a community should stay focused on

- the minimum we need (I think type support is such a feature that simply is required by the community)

- is effectively achievable within time and resources available (that includes politics - I have long discussions with people 2 years ago so I know also quite well the political/economic aspects that go far beyond the technical ones discussed here).

Everything else is useless and not worth spending one time of our precious life time...

J Anatole