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