I hear you on the configuration item. Yes, it would definately be useful to allow a SU to provide its own ehcache.xml within it. Perhaps we do something where you can specify an <ehcache:configuration/> element that will let you provide an ehcache.xml file location, which will bind all of the endpoints within the SU to the CacheManager that gets created/configured by that ehcache.xml file. If you do not provide this configuration element then it will default to whatever CacheManager is already configured for the component itself. This would allow a lot of flexibility with integrations that get created and that have specialized caching requirements. So your SU may look something like:
<beans xmlns:ehcache="http://servicemix.apache.org/ehcache/1.0";> <ehcache:configuration location="/META-INF/ehcache.xml"/> <ehcache:endpoint service="ehcache:MyCache1" cacheName="MyCache1" keyExpression="#expression1"/> <ehcache:endpoint service="ehcache:MyCache2" cacheName="MyCache2" keyExpression="#expression2"/> </beans> Regards, -Jeff bsnyder wrote: > > On 12/3/06, jpuro <[EMAIL PROTECTED]> wrote: >> >> I am planning on creating a standard JBI component for ehcache so that >> one >> can easily deploy ehcache endpoints into ServiceMix and other JBI >> compliant >> containers. Here are some high level requirements that I think would be >> useful for this component. Please respond to this thread with any >> comments >> are concerns. > > Great idea! > >> 1) There should be a way to configure endpoints that when deployed >> create >> actual Caches. The endpoints should be able to have expressions >> associated >> with them that can determine how the Cache matches information based off >> of >> the Normalized Message. So for example, if you have properties that need >> to >> be a part of your key in the cache then you can use an expression to >> match >> that. If there is an XPath expression that needs to be matched, this can >> also be used. > > Interesting idea. > >> 2) I'm still not sure whether it makes sense to allow for a SU to >> configure >> the CacheManager itself using the ehcache.xml configuration file. The >> benefit of this is that you leave the component to just worrying about >> configuration files and not starting up any cachemanagers itself. You >> will >> also be able to create specialized cachemanager's with their associated >> information on the fly. I could see this as being beneficial. However, >> perhaps it's better to leave the Ehcache configuration specific to the >> component itself. That is to say that when you deploy the component it >> loads up its already packaged ehcache.xml file which configures the >> CacheManager. If someone needs a different configuration they will have >> to >> edit the one packaged with the component or go to JMX and update the >> values >> stored there. > > I think the configuration is pretty critical. Obviously there needs to > be a default configuration, but allowing users to change that > configuration or offer a completely different configuration both need > to be top priorities. > > Bruce > -- > perl -e 'print > unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" > );' > > Apache Geronimo - http://geronimo.apache.org/ > Apache ActiveMQ - http://activemq.org/ > Apache ServiceMix - http://servicemix.org/ > Castor - http://castor.org/ > > -- View this message in context: http://www.nabble.com/Ehcache-Standard-JBI-Component-tf2747953s12049.html#a7670741 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
