+1 I know some groups including DeviceMap prefer the mailing list, but for some more graphic and descriptive design decisions I personally prefer either JIRA (if it's already in place?) or Wiki, too.
On Mon, Dec 1, 2014 at 8:52 PM, Romain Manni-Bucau <[email protected]> wrote: > a bt off topic but wouldn't a wiki - confluence - be more efficient > for such discussion. When something is under discussion we put a kind > of poll/table with possibilities and when done we have more or less > some spec/doc. > > issue with mails is we switch easily of topic and we need to summarize > regularly. > > wdyt? > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2014-12-01 20:12 GMT+01:00 Anatole Tresch <[email protected]>: > > That is also the reason, why I suggested to postpone the > assembly/providing > > discussion until we have at least a basic idea of > > > > - PropertyProviders (building blocks) > > - default combination mechanism that help defining new > config/providers > > for doing filtering, aggregation, overriding, security, views, ... > > - Configuration (representation and SE access) > > - Environment (basic environment model and access > > - Basic Services (still SE): injection, configuration templates, > dynamic > > expressions > > - implementing config changes (events) > > > > Then we are able to really talk about how to best support power users > (the > > ones that setup the configuration meta-model) for > > > > - implementing the configuration providers in a system > > - dynamically loading property providers in the right context > > - combining all that stuff with CDI (and Java EE) > > - ... > > > > It is not that I want to prevent any discussions, I just want to add some > > minimal structure to it, so we are more effective ;) > > > > -Anatole > > > > > > 2014-12-01 19:48 GMT+01:00 Gerhard Petracek <[email protected] > >: > > > >> @romain: > >> i just mentioned it (as one possibility), because oliver asked about > >> multiple config-sources which provide values for the same key. > >> independent of the final approach we will agree on (for that use-case), > it > >> shouldn't affect the use-case we discuss right now. > >> (that's the reason for discussing it step by step and if a more complex > >> case really impacts a simple(r) case later on, we can re-visit the > >> corresponding api + tests at any time). > >> > >> regards, > >> gerhard > >> > >> > >> > >> 2014-12-01 19:34 GMT+01:00 Werner Keil <[email protected]>: > >> > >> > That's where some sort of "scope" is clearly necessary, see the > different > >> > CDI scopes. > >> > It might make sense to inject a configuration via @Inject too btw. CDI > >> (and > >> > AFAIK DeltaSpike) rarely uses singletons or public factories along the > >> > lines of JSR 354. > >> > A single class and public accessor can be found in BeanValidation: > >> > Validation. > >> > That has a default factory but also offers other providers. If we > needed > >> > something similar for Configuration then maybe something like > >> > getDefault...() could be more appropriate than simply calling it > >> > getInstance() ;-) > >> > > >> > On Mon, Dec 1, 2014 at 7:24 PM, Romain Manni-Bucau < > >> [email protected]> > >> > wrote: > >> > > >> > > if you have tamaya in server/lib and call it from webapps for > >> > > instance, each webapp can use different providers so you need > >> > > different instances. That is no more a singleton. If it is still one > >> > > cause we consider it as a factory/builder then the "instance" is > >> > > useless no? > >> > > > >> > > > >> > > Romain Manni-Bucau > >> > > @rmannibucau > >> > > http://www.tomitribe.com > >> > > http://rmannibucau.wordpress.com > >> > > https://github.com/rmannibucau > >> > > > >> > > > >> > > 2014-12-01 19:20 GMT+01:00 Werner Keil <[email protected]>: > >> > > > If you get one by app, is there any form of "context" you'd pass > to > >> > such > >> > > > factory method? > >> > > > > >> > > > Currency.getInstance() returns exactly one singleton instance of a > >> > > Currency > >> > > > class (otherwise has no constructor either) for a given currency > >> code. > >> > > > While Money.of() in JSR 354 RI returns totally different instances > >> > > > depending on the combination of (nearly unlimited) different > numbers > >> > and > >> > > > currency codes. 354 tries to broaden the definition of Currency, > but > >> if > >> > > you > >> > > > get exactly one distinct instance per VM/app that's a singleton > IMHO > >> > even > >> > > > if you may call the same application multiple times. > >> > > > > >> > > > On Mon, Dec 1, 2014 at 7:12 PM, Romain Manni-Bucau < > >> > > [email protected]> > >> > > > wrote: > >> > > > > >> > > >> Hmm, > >> > > >> > >> > > >> for me getInstance() = singleton in term of instance where > >> > > >> Configuration will be all but a singleton IMO (you'll get at > least > >> one > >> > > >> by app and surely a new instance each time you call it) no? > >> > > >> > >> > > >> > >> > > >> Romain Manni-Bucau > >> > > >> @rmannibucau > >> > > >> http://www.tomitribe.com > >> > > >> http://rmannibucau.wordpress.com > >> > > >> https://github.com/rmannibucau > >> > > >> > >> > > >> > >> > > >> 2014-12-01 18:56 GMT+01:00 Werner Keil <[email protected]>: > >> > > >> > Hi, > >> > > >> > > >> > > >> > Adding to the question of convenience factories, there is no > such > >> > > thing > >> > > >> as > >> > > >> > "naming convention" by Stephen Colebourne or JSR 310. In fact, > it > >> > > >> violates > >> > > >> > or bends almost every one of them in itself, so a suggestion > like > >> > > >> > Configuration.current() would sound very similar to the > >> > > >> LocalDateTime.now() > >> > > >> > ones in 310. > >> > > >> > For several other cases of() or longer variations (like > ofMilli() > >> > > >> ofNanos() > >> > > >> > etc.;-O) are used, while static factories from strings similar > to > >> > what > >> > > >> JSR > >> > > >> > 354 adopted are called parse(String). > >> > > >> > > >> > > >> > Josh Bloch defined a clear distinction between what he then in > >> most > >> > > cases > >> > > >> > (except EnumSet, that's where he started using of() so Josh > also > >> > > >> "invented" > >> > > >> > that while it violated some of his earlier naming > conventions;-D) > >> > > called > >> > > >> > valueOf() and getInstance(), see > >> > > >> > > >> > > >> > >> > > > >> > > >> > http://blog.codefront.net/2003/06/21/java-tip-2-static-factory-methods-vs-constructors/ > >> > > >> > getInstance() returns a singleton, either the only instance for > >> this > >> > > type > >> > > >> > of object or the only instance for a distinct code or enum (see > >> > > >> > java.util.Currency) > >> > > >> > > >> > > >> > Very recent APIs and JSRs like MEEP 8 make a clear distinction, > >> and > >> > > >> classes > >> > > >> > like > >> > > >> > > >> > > >> > >> > > > >> > > >> > https://docs.oracle.com/javame/8.0/api/meep/api/javax/microedition/event/EventManager.html > >> > > >> > clearly explain that, too. In other places ME 8 uses of() where > >> > > >> appropriate. > >> > > >> > So at least getInstance() is neither outdated nor wrong, it > just > >> > > depends > >> > > >> on > >> > > >> > what you return. > >> > > >> > > >> > > >> > If Configuration returns just a default instance then > >> > > >> > Configuration.getInstance() seems appropriate. > >> > > >> > > >> > > >> > > >> > > >> > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec > >> Lead > >> > | > >> > > >> > Eclipse UOMo Lead, Babel Language Champion | Apache Committer > >> > > >> > > >> > > >> > Twitter @wernerkeil | @UnitAPI | @JSR354 | @DeviceMap | > >> > #EclipseUOMo | > >> > > >> > #Java_Social > >> > > >> > | #DevOps > >> > > >> > Skype werner.keil | Google+ gplus.to/wernerkeil > >> > > >> > > >> > > >> > On Mon, Dec 1, 2014 at 6:31 PM, Oliver B. Fischer < > >> > > >> [email protected]> > >> > > >> > wrote: > >> > > >> > > >> > > >> >> Hi, > >> > > >> >> > >> > > >> >> for me the most simple use case is > >> > > >> >> > >> > > >> >> Configuration conf = new Configuration(); > >> > > >> >> String value = conf.get("key") > >> > > >> >> > >> > > >> >> And this use case is already very complex under the hood. > >> > > >> >> > >> > > >> >> Before discussing other details we have to decide how > >> > > PropertyProviders > >> > > >> >> are activated. > >> > > >> >> > >> > > >> >> I would like to have the following possibilites: > >> > > >> >> > >> > > >> >> 1. Tamaya activates all PropertyProviders found in the > classpath > >> > and > >> > > >> >> activated via SPI. > >> > > >> >> 2. Tamaya activates only a explicitly named list of Property > >> > > providers > >> > > >> >> 3. I have the ability to control the order in which the > property > >> > > >> solution > >> > > >> >> will be performed > >> > > >> >> > >> > > >> >> Bye, > >> > > >> >> > >> > > >> >> Oliver > >> > > >> >> > >> > > >> >> > >> > > >> >> Am 01.12.14 17:54, schrieb Romain Manni-Bucau: > >> > > >> >> > >> > > >> >>> Configuration.current() sounds easier to understand first > time > >> you > >> > > see > >> > > >> >>> it. I like Configuration.newInstance() if that's really what > it > >> > does > >> > > >> >>> (ie no caching by classloader or anything else). > >> > > >> >>> > >> > > >> >>> > >> > > >> >>> Romain Manni-Bucau > >> > > >> >>> @rmannibucau > >> > > >> >>> http://www.tomitribe.com > >> > > >> >>> http://rmannibucau.wordpress.com > >> > > >> >>> https://github.com/rmannibucau > >> > > >> >>> > >> > > >> >>> > >> > > >> >>> 2014-12-01 17:42 GMT+01:00 Anatole Tresch < > [email protected]>: > >> > > >> >>> > >> > > >> >>>> There is a naming concept from Stephen Colebourne when to > use > >> of, > >> > > >> from, > >> > > >> >>>> with. I try to lookup the link later, see also jsr 310 and > 354. > >> > > >> >>>> getInstance, valueOf are considered to be outdated for > modern > >> api > >> > > >> design. > >> > > >> >>>> > >> > > >> >>>> Adding a helper, why? Another artifact a user must know, > makes > >> > > sense, > >> > > >> >>>> where > >> > > >> >>>> you have a huge acces api IMO (see PropertyProviders where > the > >> > > factory > >> > > >> >>>> methods are not part of the PropertyProvider interface. For > >> > > >> >>>> Configuration I > >> > > >> >>>> prefer having sn intuitive simple/single access... > >> > > >> >>>> > >> > > >> >>>> Nevertheless I would like to encourage you to make a > concrete > >> > > proposal > >> > > >> >>>> how > >> > > >> >>>> would name things, so we can compare what your idea of > fluent > >> is > >> > ;) > >> > > >> >>>> > >> > > >> >>>> -anatole > >> > > >> >>>> Gerhard Petracek <[email protected]> schrieb am > Mo., > >> 1. > >> > > Dez. > >> > > >> >>>> 2014 > >> > > >> >>>> um 17:24: > >> > > >> >>>> > >> > > >> >>>> hi anatole, > >> > > >> >>>>> > >> > > >> >>>>> again - yes and no. > >> > > >> >>>>> no - it wasn't similar before, because you haven't started > >> with > >> > > the > >> > > >> most > >> > > >> >>>>> trivial usage (supported by tamaya right now). > >> > > >> >>>>> however, now we are talking about a "different part" of the > >> api > >> > > >> which is > >> > > >> >>>>> very similar -> yes > >> > > >> >>>>> > >> > > >> >>>>> -> let's discuss > >> > > >> >>>>> String myValue = > >> > Configuration.of().get("myKey").orElse(null); > >> > > >> >>>>> > >> > > >> >>>>> maybe we can get something better than ".of().get" or we > >> > provide a > >> > > >> >>>>> static > >> > > >> >>>>> helper for it. > >> > > >> >>>>> currently this first part doesn't read fluently. a lot of > >> users > >> > > might > >> > > >> >>>>> not > >> > > >> >>>>> need more than that (at least in the beginning) and > therefore > >> it > >> > > >> should > >> > > >> >>>>> be > >> > > >> >>>>> nice. > >> > > >> >>>>> > >> > > >> >>>>> regards, > >> > > >> >>>>> gerhard > >> > > >> >>>>> > >> > > >> >>>>> > >> > > >> >>>>> > >> > > >> >>>>> 2014-12-01 16:07 GMT+01:00 Tresch, Anatole > >> > > >> >>>>> <anatole.tresch@credit-suisse. > >> > > >> >>>>> com > >> > > >> >>>>> > >> > > >> >>>>>> : > >> > > >> >>>>>> Hi Gerhard > >> > > >> >>>>>> > >> > > >> >>>>>> as I said granularity is not matching in your example. > >> > Comparing > >> > > >> >>>>>> concepts > >> > > >> >>>>>> on the same granularity level it would be: > >> > > >> >>>>>> > >> > > >> >>>>>> String myValue = > >> ConfigResolver.getPropertyValue("myKey"); > >> > > // > >> > > >> >>>>>> Deltaspike > >> > > >> >>>>>> > >> > > >> >>>>>> compared to: > >> > > >> >>>>>> > >> > > >> >>>>>> String myValue = > >> > > Configuration.of().get("myKey").orElse(null); > >> > > >> >>>>>> // > >> > > >> >>>>>> Tamaya > >> > > >> >>>>>> > >> > > >> >>>>>> So that looks more or less similar (I did not count the > >> > > characters) > >> > > >> ;) > >> > > >> >>>>>> > >> > > >> >>>>>> It will be interesting to see how it feels, when defining > the > >> > > model > >> > > >> >>>>>> > >> > > >> >>>>> behind > >> > > >> >>>>> > >> > > >> >>>>>> this facades. Tamaya can support dynamic property > providers > >> > (aka > >> > > >> >>>>>> PropertySource) managed by CDI for app config as well. > But on > >> > > top of > >> > > >> >>>>>> them > >> > > >> >>>>>> also will probably be capable to configure CDI and other > >> > aspects. > >> > > >> >>>>>> Already > >> > > >> >>>>>> in place is a Properties implementation that can be > applied > >> to > >> > > >> >>>>>> System.setProperties(Properties), which adds dynamic > >> > > >> >>>>>> > >> > > >> >>>>> (configurable)system > >> > > >> >>>>> > >> > > >> >>>>>> properties as a minimal shared level of API already > available > >> > as > >> > > of > >> > > >> now > >> > > >> >>>>>> > >> > > >> >>>>> on > >> > > >> >>>>> > >> > > >> >>>>>> SE level. > >> > > >> >>>>>> > >> > > >> >>>>>> -Anatole > >> > > >> >>>>>> > >> > > >> >>>>>> > >> > > >> >>>>>> -----Original Message----- > >> > > >> >>>>>> From: Gerhard Petracek [mailto:[email protected] > ] > >> > > >> >>>>>> Sent: Montag, 1. Dezember 2014 14:30 > >> > > >> >>>>>> To: [email protected] > >> > > >> >>>>>> Subject: Re: Use Case 1: Read simple properties and get > >> values. > >> > > >> >>>>>> > >> > > >> >>>>>> hi anatole, > >> > > >> >>>>>> > >> > > >> >>>>>> yes and no - the part i talked about mainly is: > >> > > >> >>>>>> String myValue = ConfigResolver.getPropertyValue("myKey"); > >> > > >> >>>>>> > >> > > >> >>>>>> compared to: > >> > > >> >>>>>> Configuration config = > PropertyProviders.fromPaths(/*...*/); > >> > > >> >>>>>> String myValue = config.get("myKey", String.class); > >> > > >> >>>>>> > >> > > >> >>>>>> regards, > >> > > >> >>>>>> gerhard > >> > > >> >>>>>> > >> > > >> >>>>>> > >> > > >> >>>>>> > >> > > >> >>>>>> 2014-12-01 14:22 GMT+01:00 Anatole Tresch < > >> [email protected] > >> > >: > >> > > >> >>>>>> > >> > > >> >>>>>> Hi Gerhard > >> > > >> >>>>>>> What you describe is use case that will follow later. You > >> > asked > >> > > me > >> > > >> to > >> > > >> >>>>>>> > >> > > >> >>>>>> start > >> > > >> >>>>>> > >> > > >> >>>>>>> with a simple one, so this is the most simple one. Next > use > >> > > cases > >> > > >> will > >> > > >> >>>>>>> > >> > > >> >>>>>> add > >> > > >> >>>>>> > >> > > >> >>>>>>> aadditional sources, then we will combine things (aka > >> complex > >> > > >> >>>>>>> > >> > > >> >>>>>> overridings). > >> > > >> >>>>>> > >> > > >> >>>>>>> After that we will emphasize on the environment model, > >> because > >> > > this > >> > > >> >>>>>>> > >> > > >> >>>>>> defines > >> > > >> >>>>>> > >> > > >> >>>>>>> the context, which determines which config is > appropriate. > >> The > >> > > >> user in > >> > > >> >>>>>>> > >> > > >> >>>>>> most > >> > > >> >>>>>> > >> > > >> >>>>>>> cases will call Configuration.of() to access.the current > >> > > >> >>>>>>> configuration. > >> > > >> >>>>>>> This method then is backed by a config provider. This > >> provider > >> > > >> decides > >> > > >> >>>>>>> > >> > > >> >>>>>> how > >> > > >> >>>>>> > >> > > >> >>>>>>> the current environment is determining the config to be > >> > returned > >> > > >> (aka > >> > > >> >>>>>>> defines implements the config metamodel). > >> > > >> >>>>>>> This metamodel can be defined rather differently > depending > >> > your > >> > > >> target > >> > > >> >>>>>>> runtime and require config solutions. And for this we > >> require > >> > > the > >> > > >> >>>>>>> > >> > > >> >>>>>> basics > >> > > >> >>>>> > >> > > >> >>>>>> (where I started). > >> > > >> >>>>>>> > >> > > >> >>>>>>> What is in Deltaspike as of now is only a subset of what > I > >> see > >> > > >> >>>>>>> > >> > > >> >>>>>> necessary > >> > > >> >>>>> > >> > > >> >>>>>> to > >> > > >> >>>>>> > >> > > >> >>>>>>> build a compelling config system. We will be able to > cover > >> > that > >> > > >> >>>>>>> functionality easily and it will be easy to use. > >> > > >> >>>>>>> > >> > > >> >>>>>>> So please have some patience and let me post the use > cases > >> and > >> > > >> >>>>>>> > >> > > >> >>>>>> solutions > >> > > >> >>>>> > >> > > >> >>>>>> one by one and focus on these. I try to post them if > possible > >> > on > >> > > a > >> > > >> >>>>>>> > >> > > >> >>>>>> daily > >> > > >> >>>>> > >> > > >> >>>>>> basis. Hopefully we will have then a common terminology > and > >> > > >> >>>>>>> > >> > > >> >>>>>> architectural > >> > > >> >>>>> > >> > > >> >>>>>> view on the whole topic that helps us discuss things > >> > efficiently > >> > > ;) > >> > > >> >>>>>>> > >> > > >> >>>>>>> Cheers > >> > > >> >>>>>>> Anatole > >> > > >> >>>>>>> > >> > > >> >>>>>>> Gerhard Petracek <[email protected]> schrieb am > >> Mo., > >> > > 1. > >> > > >> Dez. > >> > > >> >>>>>>> > >> > > >> >>>>>> 2014 > >> > > >> >>>>>> > >> > > >> >>>>>>> um 13:58: > >> > > >> >>>>>>> > >> > > >> >>>>>>> hi @ all, > >> > > >> >>>>>>>> > >> > > >> >>>>>>>> @anatole: thx for starting this thread. > >> > > >> >>>>>>>> > >> > > >> >>>>>>>> let's start/continue with the first part - the > equivalent > >> in > >> > > >> >>>>>>>> > >> > > >> >>>>>>> deltaspike > >> > > >> >>>>> > >> > > >> >>>>>> is: > >> > > >> >>>>>>> > >> > > >> >>>>>>>> String myValue = > ConfigResolver.getPropertyValue("myKey"); > >> > > >> >>>>>>>> > >> > > >> >>>>>>>> as a precondition for this call, you need 1-n registered > >> > > >> >>>>>>>> > >> > > >> >>>>>>> config-source(s) > >> > > >> >>>>>> > >> > > >> >>>>>>> (= std. spi config -> in this case in: > >> > > >> >>>>>>>> META-INF/services/org.apache.deltaspike.core.spi.config. > >> > > >> >>>>>>>> > >> > > >> >>>>>>> ConfigSource). > >> > > >> >>>>> > >> > > >> >>>>>> this approach is nice for >applications<, because > everything > >> is > >> > > done > >> > > >> >>>>>>>> automatically based on the "visible" configs. > >> > > >> >>>>>>>> furthermore, it's very flexible, because a config-source > >> > > >> encapsulates > >> > > >> >>>>>>>> > >> > > >> >>>>>>> the > >> > > >> >>>>>> > >> > > >> >>>>>>> logic for different config-locations (files, jndi, > db,...). > >> > > >> >>>>>>>> > >> > > >> >>>>>>>> mark wrote that part -> he might add some details which > are > >> > > >> important > >> > > >> >>>>>>>> > >> > > >> >>>>>>> to > >> > > >> >>>>>> > >> > > >> >>>>>>> him (for the >current< use-case): > >> > > >> >>>>>>>> > >> > > >> >>>>>>>> regards, > >> > > >> >>>>>>>> gerhard > >> > > >> >>>>>>>> > >> > > >> >>>>>>>> > >> > > >> >>>>>>>> > >> > > >> >>>>>>>> 2014-12-01 11:30 GMT+01:00 Romain Manni-Bucau < > >> > > >> [email protected] > >> > > >> >>>>>>>> > >> > > >> >>>>>>> : > >> > > >> >>>>>> > >> > > >> >>>>>>> Looks like a good entry point, I like the "prefixing" to > >> > switch > >> > > of > >> > > >> >>>>>>>>> "reader". However I don't like to be forced to use an > >> > > Optional. > >> > > >> In > >> > > >> >>>>>>>>> several cases I prefer to stick to properties API ie > get > >> > > >> something > >> > > >> >>>>>>>>> > >> > > >> >>>>>>>> or > >> > > >> >>>>> > >> > > >> >>>>>> a default, default being null if not set when queried. > >> Optional > >> > > is > >> > > >> >>>>>>>>> > >> > > >> >>>>>>>> not > >> > > >> >>>>>> > >> > > >> >>>>>>> bad but makes code very verbose for pretty much nothing > is > >> > > several > >> > > >> >>>>>>>>> cases (of config). > >> > > >> >>>>>>>>> > >> > > >> >>>>>>>>> > >> > > >> >>>>>>>>> wdyt? > >> > > >> >>>>>>>>> > >> > > >> >>>>>>>>> > >> > > >> >>>>>>>>> Romain Manni-Bucau > >> > > >> >>>>>>>>> @rmannibucau > >> > > >> >>>>>>>>> http://www.tomitribe.com > >> > > >> >>>>>>>>> http://rmannibucau.wordpress.com > >> > > >> >>>>>>>>> https://github.com/rmannibucau > >> > > >> >>>>>>>>> > >> > > >> >>>>>>>>> > >> > > >> >>>>>>>>> 2014-12-01 11:15 GMT+01:00 Anatole Tresch < > >> > [email protected] > >> > > >: > >> > > >> >>>>>>>>> > >> > > >> >>>>>>>>>> Hi all > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> I have put together a first couple of simple use > cases. > >> It > >> > is > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> targeting > >> > > >> >>>>>>> > >> > > >> >>>>>>>> SE > >> > > >> >>>>>>>>> > >> > > >> >>>>>>>>>> level only (as many use cases will do, especially the > >> basic > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> ones). > >> > > >> >>>>> > >> > > >> >>>>>> *Basic use case 1:* > >> > > >> >>>>>>>>>> We want to write some properties file and read it > from a > >> > > file or > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> the > >> > > >> >>>>>> > >> > > >> >>>>>>> classpath into a Configuration instance. This is done by > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> Configuration config = PropertyProviders.fromPaths( > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> > "classpath:ucs/UC1ReadProperties/UC1ReadPropertiesTest. > >> > > >> >>>>>>> properties") > >> > > >> >>>>>>> > >> > > >> >>>>>>>> .toConfiguration(); > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> The PropertyProvider which is created here by > >> > > >> >>>>>>>>>> PropertyProviders.fromPaths hereby > >> > > >> >>>>>>>>>> is a simplified version that can be easily aggregated > >> (for > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> composites) > >> > > >> >>>>>>> > >> > > >> >>>>>>>> and > >> > > >> >>>>>>>>> > >> > > >> >>>>>>>>>> only provides String values (no type support yet). > >> > > Nevertheless > >> > > >> >>>>>>>>>> mapping to Configuration > >> > > >> >>>>>>>>>> is trivial. > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> Given that we then can access different values. Since > we > >> > > return > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> Optional > >> > > >> >>>>>>>> > >> > > >> >>>>>>>>> as > >> > > >> >>>>>>>>> > >> > > >> >>>>>>>>>> a result type the values returned are never null. For > >> > showing > >> > > >> the > >> > > >> >>>>>>>>>> capabilities I added multiple examples of types: > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> String name = config.get("name").orElse("Anatole"); > >> > > >> >>>>>>>>>> BigDecimal bigNum = config.get("num.BD", > >> BigDecimal.class) > >> > > >> >>>>>>>>>> .orElseThrow(() -> new > >> > > >> >>>>>>>>>> IllegalStateException("Sorry")); > >> > > >> >>>>>>>>>> double anotherNum = config.getDouble("num.Double") > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> .getAsDouble(); > >> > > >> >>>>> > >> > > >> >>>>>> long longNum = config.getLong("num.Long").orElse(288900L); > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> Finally plugins or modules often only want a view on > >> their > >> > > >> subset > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> of > >> > > >> >>>>>> > >> > > >> >>>>>>> entries. This can be achieved easily by using > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> Configuration areaConfig2 = > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> config.with(ConfigFunctions.selectArea("num")); > >> > > >> >>>>>>>>> > >> > > >> >>>>>>>>>> This will return a Configuration subset, which will > only > >> > > contain > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> the > >> > > >> >>>>>> > >> > > >> >>>>>>> child > >> > > >> >>>>>>>>> > >> > > >> >>>>>>>>>> values of the num area, which are BD, double, ... > >> > > >> ConfigFunctions > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> BTW > >> > > >> >>>>>> > >> > > >> >>>>>>> is > >> > > >> >>>>>>>> > >> > > >> >>>>>>>>> a > >> > > >> >>>>>>>>> > >> > > >> >>>>>>>>>> dingleton accessot, which serves > >> > > >> >>>>>>>>>> ConfigOperator functional extensions (there is also a > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> ConfigQuery), > >> > > >> >>>>> > >> > > >> >>>>>> so > >> > > >> >>>>>>> > >> > > >> >>>>>>>> this > >> > > >> >>>>>>>>> > >> > > >> >>>>>>>>>> is a common pattern for adding whatever extension > needed > >> to > >> > > >> >>>>>>>>>> Configuration instances > >> > > >> >>>>>>>>>> without having them to directly implement/provide on > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> Configuration > >> > > >> >>>>> > >> > > >> >>>>>> itself. > >> > > >> >>>>>>>>> > >> > > >> >>>>>>>>>> All the features are reflected in the test class (in > the > >> > core > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> module): > >> > > >> >>>>>>> > >> > > >> >>>>>>>> > >> org.apache.tamaya.uc.UC1ReadProperties.UC1ReadPropertiesTest > >> > > (we > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> should > >> > > >> >>>>>>>> > >> > > >> >>>>>>>>> lower case the package name ;) ). > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> This test also contains additional features/use > cases... > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> *Extended use case 1.1: multiple formats* > >> > > >> >>>>>>>>>> It is possible to read multiple file formats, by > default > >> > the > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> following > >> > > >> >>>>>>> > >> > > >> >>>>>>>> formats are supported > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> - .properties (as defined by java.util.Properties) > >> > > >> >>>>>>>>>> - .xml properties (as defined by > >> java.util.Properties) > >> > > >> >>>>>>>>>> - .ini format > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> Configuration config = PropertyProviders.fromPaths( > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> > "classpath:ucs/UC1ReadProperties/UC1ReadPropertiesTest. > >> > > >> >>>>>>> properties", > >> > > >> >>>>>>> > >> > > >> >>>>>>>> > >> > > "classpath:ucs/UC1ReadProperties/UC1ReadPropertiesTest.xml", > >> > > >> >>>>>>>>>> "file:c:/temp/myProps.properties") > >> > > >> >>>>>>>>>> .toConfiguration(); > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> In the back format resolution is handled by an SPI, > which > >> > is > >> > > >> >>>>>>>>>> extendable/pluggable. > >> > > >> >>>>>>>>>> The basic component here ist the ConfigurationFormats > >> > > singleton > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> and > >> > > >> >>>>> > >> > > >> >>>>>> the ConfigurationFormat > >> > > >> >>>>>>>>>> interfaCE. > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> *Extended use case 1.2: multiple sources* > >> > > >> >>>>>>>>>> It is possible to read multiple files, by adding > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> - additional paths (see above) > >> > > >> >>>>>>>>>> - ant styled expressions > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> Configuration config = PropertyProviders.fromPaths( > >> > > >> >>>>>>>>>> > >> > > "classpath:ucs/UC1ReadProperties/UC1ReadPropertiesTest.*", > >> > > >> >>>>>>>>>> > "classpath*:ucs/UC1ReadProperties/**/*.properties") > >> > > >> >>>>>>>>>> .toConfiguration(); > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> In the back resource resolution is handled by an SPI, > >> which > >> > > is > >> > > >> >>>>>>>>>> extendable/pluggable as well. > >> > file,file*,classpath,classpath* > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> are > >> > > >> >>>>> > >> > > >> >>>>>> the > >> > > >> >>>>>> > >> > > >> >>>>>>> locator ids which are implemented based on a subset of > the > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> Spring > >> > > >> >>>>> > >> > > >> >>>>>> resource > >> > > >> >>>>>>>>> > >> > > >> >>>>>>>>>> loader is working. Additional resource location > mechanism > >> > > could > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> be > >> > > >> >>>>> > >> > > >> >>>>>> easily added by implementing the > >> > > >> >>>>>>>>>> org.apache.tamaya.core.internal.resources.PathResolver > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> interface. > >> > > >> >>>>> > >> > > >> >>>>>> If > >> > > >> >>>>>> > >> > > >> >>>>>>> one > >> > > >> >>>>>>>> > >> > > >> >>>>>>>>> implements and registers (using the Bootstrap > component, > >> by > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> default > >> > > >> >>>>> > >> > > >> >>>>>> using > >> > > >> >>>>>>>> > >> > > >> >>>>>>>>> ServiceLoader), e.g. a resolver called "foo", the > >> expression > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> would > >> > > >> >>>>> > >> > > >> >>>>>> look > >> > > >> >>>>>>> > >> > > >> >>>>>>>> like: > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> Configuration config = PropertyProviders.fromPaths( > >> > > >> >>>>>>>>>> "foo:myResourceExpression"); > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> Next variants would be reading properties from other > >> > > resources. > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> We > >> > > >> >>>>> > >> > > >> >>>>>> could > >> > > >> >>>>>>>> > >> > > >> >>>>>>>>> e.g. create a programmatic random resource and also > use a > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>> database, > >> > > >> >>>>> > >> > > >> >>>>>> or > >> > > >> >>>>>>> > >> > > >> >>>>>>>> remote resource. > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> Cheers, > >> > > >> >>>>>>>>>> Anatole > >> > > >> >>>>>>>>>> > >> > > >> >>>>>>>>>> > >> > > >> >> -- > >> > > >> >> 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 > >> > > >> >> > >> > > >> >> > >> > > >> > >> > > > >> > > >> > > > > > > > > -- > > *Anatole Tresch* > > Java Engineer & Architect, JSR Spec Lead > > Glärnischweg 10 > > CH - 8620 Wetzikon > > > > *Switzerland, Europe Zurich, GMT+1* > > *Twitter: @atsticks* > > *Blogs: **http://javaremarkables.blogspot.ch/ > > <http://javaremarkables.blogspot.ch/>* > > > > *Google: atsticksMobile +41-76 344 62 79* >
