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