You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcs-users@jakarta.apache.org by Roland Groen <ro...@gmail.com> on 2005/01/20 11:47:44 UTC
JCS configuration flexibility
I want to use JCS in one of our projects, but there is one annoying
issue: why does JCS need a configuration file format while it
internally uses a java.util.Properties instance. Why do I need to
create a file wile I can configure JCS using my own configuration
format and just pass on a Properties instance to the init process?
Configuration of a library as JSC should, of course, be supported by
passing a configuration file path, but there should be an option to
just configure it from the code eg. by instantiating and passing some
kind of configuration object. In this case an instance of Properties.
I always attempt to use one and only one xml configuration file for
for each project/application. It's confusing to have a million
different files with different syntaxes hanging around in a project.
For libraries, I always provide a configuration object which is passed
to the service/library and provide a builder architecture which builds
the configuration object from a specific source, usually an xml
element.
Element myConfigElement = ....
FooBuilder myBuilder = new XmlFooBuilder(myConfigElement);
or
String myConfigFilePath = ....
FooBuilder myBuilder = new PropsFooBuilder(myConfigFilePath);
and than:
FooConfig myFooConfig = myBuilder.build();
Foo myFoo = new Foo(myFooConfig);
This way the configuration of different libraries can be composed in
one xml file for each application. Clean and simple. Want it your own
way? Make your own builder...
For now it would be nice just to be able to pass an instance of
Properties to the JCS class:
public static void setConfigProperties(Properties configProperties)
regards,
Roland.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org
Re: JCS configuration flexibility
Posted by James Taylor <ja...@jamestaylor.org>.
CompositeCacheManager.getUnconfiguredInstance().configure(
propertiesObject );
CCM is still a singleton, you've just forced it to be configured
differently. Now access JCS as you normally would.
On Jan 20, 2005, at 5:47 AM, Roland Groen wrote:
> I want to use JCS in one of our projects, but there is one annoying
> issue: why does JCS need a configuration file format while it
> internally uses a java.util.Properties instance. Why do I need to
> create a file wile I can configure JCS using my own configuration
> format and just pass on a Properties instance to the init process?
>
> Configuration of a library as JSC should, of course, be supported by
> passing a configuration file path, but there should be an option to
> just configure it from the code eg. by instantiating and passing some
> kind of configuration object. In this case an instance of Properties.
>
> I always attempt to use one and only one xml configuration file for
> for each project/application. It's confusing to have a million
> different files with different syntaxes hanging around in a project.
> For libraries, I always provide a configuration object which is passed
> to the service/library and provide a builder architecture which builds
> the configuration object from a specific source, usually an xml
> element.
>
> Element myConfigElement = ....
> FooBuilder myBuilder = new XmlFooBuilder(myConfigElement);
>
> or
>
> String myConfigFilePath = ....
> FooBuilder myBuilder = new PropsFooBuilder(myConfigFilePath);
>
> and than:
>
> FooConfig myFooConfig = myBuilder.build();
> Foo myFoo = new Foo(myFooConfig);
>
> This way the configuration of different libraries can be composed in
> one xml file for each application. Clean and simple. Want it your own
> way? Make your own builder...
>
> For now it would be nice just to be able to pass an instance of
> Properties to the JCS class:
>
> public static void setConfigProperties(Properties configProperties)
>
> regards,
>
> Roland.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> turbine-jcs-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org
RE: JCS configuration flexibility
Posted by Aaron Smuts <aa...@wisc.edu>.
You can configure the cache using a Properties object via the
org.apache.jcs.engine.control.CompositeCacheManager.
Call:
CompositeCacheManager mgr =
CompositeCacheManager.getUnconfiguredInstance()
mgr.configure( properties );
Then use JCS the normal way:
JCS.getInstance( regionName );
Cheers,
Aaron
> -----Original Message-----
> From: Roland Groen [mailto:roland.groen@gmail.com]
> Sent: Thursday, January 20, 2005 2:48 AM
> To: turbine-jcs-user@jakarta.apache.org
> Subject: JCS configuration flexibility
>
> I want to use JCS in one of our projects, but there is one annoying
> issue: why does JCS need a configuration file format while it
> internally uses a java.util.Properties instance. Why do I need to
> create a file wile I can configure JCS using my own configuration
> format and just pass on a Properties instance to the init process?
>
> Configuration of a library as JSC should, of course, be supported by
> passing a configuration file path, but there should be an option to
> just configure it from the code eg. by instantiating and passing some
> kind of configuration object. In this case an instance of Properties.
>
> I always attempt to use one and only one xml configuration file for
> for each project/application. It's confusing to have a million
> different files with different syntaxes hanging around in a project.
> For libraries, I always provide a configuration object which is passed
> to the service/library and provide a builder architecture which builds
> the configuration object from a specific source, usually an xml
> element.
>
> Element myConfigElement = ....
> FooBuilder myBuilder = new XmlFooBuilder(myConfigElement);
>
> or
>
> String myConfigFilePath = ....
> FooBuilder myBuilder = new PropsFooBuilder(myConfigFilePath);
>
> and than:
>
> FooConfig myFooConfig = myBuilder.build();
> Foo myFoo = new Foo(myFooConfig);
>
> This way the configuration of different libraries can be composed in
> one xml file for each application. Clean and simple. Want it your own
> way? Make your own builder...
>
> For now it would be nice just to be able to pass an instance of
> Properties to the JCS class:
>
> public static void setConfigProperties(Properties configProperties)
>
> regards,
>
> Roland.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
turbine-jcs-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
turbine-jcs-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org