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