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*
