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