Ehcache Standard JBI Component
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. 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. 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. Regards, Jeff -- View this message in context: http://www.nabble.com/Ehcache-Standard-JBI-Component-tf2747953s12049.html#a7666554 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: Ehcache Standard JBI Component
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-N61ED\!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/
Re: Ehcache Standard JBI Component
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-N61ED\!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.