the SHOULD was not targeted at our impl. What I meant is that a user CAN add this file into every jar he likes. And all those files will get picked up and evaluated by default.
This is kind of the easiest way to add some default configuration into his application. If there is no such a file then nothing will happen. LieGrue, strub > On Tuesday, 6 January 2015, 12:31, Romain Manni-Bucau <[email protected]> > wrote: > > ok so if it is a SHOULD I wouldn't handle it now. We should stick to > the MUST until first release. > > Issue doing what you describe is it shows the default ordinal is not > enough so you add another one and finally reading a config is no more > straight forward. > > This can be an extension but I wouldnt provide it by default *now*. > > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > > 2015-01-06 12:26 GMT+01:00 Mark Struberg <[email protected]>: >>>> - we could do the same for ini files and json files (once we > manage to >>> parse ini and JSON in a _very_ lightweight approach) >>>> - impl to be merged from the JIRA patch >>>> - we need to discuss the default ordinals >>>> >>> >>> I have a big issue with it: how do you merge them? They all have the >>> same ordinal and pretty sure you'll get it quickly in >>> src/main/resources and src/test/resources for enough projects. >> >> >> >> That's perfectly fine and even intended. Check out how we did it in > DeltaSpike and also look at Reinhards impl: the ordinal can simply be > configured > within those property files by adding >> >> javaconfiguration.ordinal=123 >> >> Users SHOULD be able to simply add a > src/main/resources/META-INF/javaconfiguration.properties file and write their > configs into it. Or even override some default configs by given this file a > higher javaconfiguration.ordinal . >> >> That way a user doesn't even need to register own PropertySources but > simply has to add a single file. >> >> >> If you like to split this in different file names then you are up to own > PropertySources of course. >> >> LieGrue, >> strub >> >> >> >> >>> On Tuesday, 6 January 2015, 11:44, Romain Manni-Bucau > <[email protected]> wrote: >>> > Hi globally agree but few additions inline >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2015-01-06 11:29 GMT+01:00 Mark Struberg <[email protected]>: >>>> I guess by 'finding' you mean how a user can add > PropertySources >>> which the ConfigurationContext later finds? >>>> >>>> I'm not quite sure I can follow you what you mean with the 3 > different >>> approaches. They have nothing to do with 'finding' at all but > how we >>> _implement_ PropertySources. >>>> >>>> >>>> Thus first let me give you my personal view about how we pickup > the >>> PropertySources. >>>> >>>> A.) There are exactly 3 ways of registering a PropertySource (in > SE mode): >>>> >>>> 1.) Picking up PropertySources via java.util.ServiceLoader [1] >>>> >>>> Just write a file > META-INF/services/org.apache.tamaya.spi.PropertySource >>> which contains the fully qualified class name of your own > PropertySource (needs >>> a default ct). Each picked up PropertySource gets registered 1:1 >>>> >>>> >>>> 2.) Picking up PropertySourceProviders via java.util.ServiceLoader > [1] >>>> Just write a file >>> META-INF/services/org.apache.tamaya.spi.PropertySourceProvider which > contains >>> the fully qualified class name of your own PropertySourceProvider. For > each >>> PropertySourceProvider we get we call getPropertySources() and register > each of >>> the Collection<PropertySource. >>>> >>>> This way is very useful if you just know e.g. the name of a config > file >>> (regardless if .properties, .ini or .json) but you don't know how > many of >>> them are in all the various jars in your project. Remember that each of > the jar >>> can package their own config file (with the same name) and just contain > a >>> different ordinal. That way we can easily build some 'plugin' > or SPI >>> approach. >>>> >>>> >>>> >>>> 3.) Programmatically added via >>> ConfigurationContext#addPropertySources(PropertySource...) >>>> This is very handy if you need to register PropertySources which > can only >>> work after e.g. EJB or CDI got started. You can also leverage this to > e.g. pick >>> up additional PropertySources via CDIs ProcessAnnotatedType [2][3]. >>>> >>>> >>> >>> I like the discovery through "integration" (CDI) but not that > much >>> addPropertySources(). for me it is opposed and we should select one >>> for the first version. >>> >>>> >>>> >>>> B.) Now let's focus on HOW we implement those PropertySources >>>> >>>> >>>> B.1 Imo we should keep the core as small as possible which means >>>> >>>> B.1.1) no external dependencies >>>> >>>> B.1.2) not too much code. We have to balance between features vs > size. If >>> something has an enormous benefit then let's add it. Or if it is > very nice >>> and very small to implement. Otoh I'd not add something which is > rather >>> large and complicated ad has not much benefit. Classpath scanning falls > into >>> this category (really hard to do *right* within < 300 kBytes) >>>> >>>> >>>> >>>> B.2 Which PropertySources do we like to support out of the box? >>>> >>>> B.2.1 shell environment >>>> >>>> - System.getenv() >>>> - done >>>> - still need to discuss it's default ordinal >>>> >>>> >>>> B.2.2 system properties >>>> >>>> - System.getProperties() >>>> - done >>>> - still need to discuss it's default ordinal >>>> >>>> B.2.3 JNDI - >>>> - lookup all properties under a some certain JNDI location >>>> >>>> - we need to define those locations e.g. >>>> - java:env/javaconfiguration - for all global stuff on the server >>>> - java:app/javaconfiguration - for all application specific > overrides of >>> the server. I suggest to use a higher ordinal than for >>> java:env/javaconfiguration >>>> - I'm not 100% sure if e.g. java:app isolation is well > defined in the >>> EE spec. Still worth trying imo >>>> - we need to also discuss whether JNDI is worth getting picked up > as well >>> as it often is highly vendor specific (that's why I simply name it >>> 'JavaEE data toilet') >>>> >>>> - impl tbd once we finished this discussion >>>> >>>> - we need to discuss the default ordinals >>>> >>> >>> I wouldnt rely on JNDI sinc eit is a direct concurrent which was >>> rejected by a lot of users. java:app and java:global dont exist for >>> app but only for apps with EJBs which is no more fashion today and >>> clearly not the future. >>> >>> I would skip it for now and if enough users come saying they need it >>> we just add it later. >>> >>>> B.2.4 default property files >>>> - ClassLoader.getResources(DEFAULT_CONFIG_FILE_NAME) -> > register all >>> those property files as own PropertySources >>>> - we need to define it's default name. Reinhard did suggest >>> META-INF/javaconfiguration.properties which is fine for me. >>>> >>>> - we could do the same for ini files and json files (once we > manage to >>> parse ini and JSON in a _very_ lightweight approach) >>>> - impl to be merged from the JIRA patch >>>> - we need to discuss the default ordinals >>>> >>> >>> I have a big issue with it: how do you merge them? They all have the >>> same ordinal and pretty sure you'll get it quickly in >>> src/main/resources and src/test/resources for enough projects. >>> >>> >>>> >>>> C. How do we like to implement those PropertySources? >>>> >>>> This is your original question it seems, right? >>>> >>>>> 1. org.apache.tamaya.format.ConfigurationFormat interface by > Anatole >>>> >>>> This imo adds a layer of indirection which is hardly needed. Could > all be >>> done with a single base class as well as far as I've seen. >>>> >>>> >>>>> 2. Using an URL by Reinhard >>>> Not yet looked at the patch but could be a very simple option. >>>> >>>> >>>>> 3. Custom interface by me for the JSON PropertySource >>>> The benefit of JSON would be it's native support of arrays.But > all the >>> JSON discussion imo mostly depends whether we find a very small > solution to >>> parse those files. So I'd rather keep this in an extension module > right now. >>>> >>>> >>>> >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> [1] > https://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html >>>> [2] >>> > https://github.com/apache/deltaspike/blob/master/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/config/ConfigurationExtension.java#L58 >>>> [3] >>> > https://github.com/apache/deltaspike/blob/master/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/config/ConfigurationExtension.java#L80 >>>> >>>> >>>> On Tuesday, 6 January 2015, 8:29, Oliver B. Fischer >>> <[email protected]> wrote: >>>> >>>> >>>>> >>>>> >>>>> Dear all, >>>>> >>>>> we have to clarify how do we find a property source at the end > of the >>>>> day. I have seen now three different apporaches: >>>>> >>>>> 1. org.apache.tamaya.format.ConfigurationFormat interface by > Anatole >>>>> 2. Using an URL by Reinhard >>>>> 3. Custom interface by me for the JSON PropertySource >>>>> >>>>> The solution by Anatole and me is very similar and could be > unified >>>>> easily. Independent of the way we go this interface belongs to > the core >>>>> module. Or not? >>>>> >>>>> Furthermore how does a normal Java SE user will use it? How > does the top >>>>> level usage of Tamaya looks like? >>>>> >>>>> Oliver >>>>> >>>>> >>>>> -- >>>>> N Oliver B. Fischer >>>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany >>>>> P +49 30 44793251 >>>>> M +49 178 7903538 >>>>> E [email protected] >>>>> S oliver.b.fischer >>>>> J [email protected] >>>>> X http://xing.to/obf >>>>> >>>>> >>>>> >>>>> >>> >
