[jira] Updated: (SM-679) Create a servicemix-ehcache standard JBI component
[ https://issues.apache.org/activemq/browse/SM-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SM-679: --- Fix Version/s: (was: 3.2) Create a servicemix-ehcache standard JBI component -- Key: SM-679 URL: https://issues.apache.org/activemq/browse/SM-679 Project: ServiceMix Issue Type: New Feature Components: servicemix-components Affects Versions: 3.0 Reporter: Jeff Puro Assignee: Jeff Puro Priority: Minor Attachments: servicemix-ehcache.patch Add a servicemix-ehcache standard JBI component. Please see the following forum thread for more information on how this component should work. http://www.nabble.com/Ehcache-Standard-JBI-Component-tf2747953s12049.html#a7666554 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-679) Create a servicemix-ehcache standard JBI component
[ https://issues.apache.org/activemq/browse/SM-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Puro updated SM-679: - Description: Add a servicemix-ehcache standard JBI component. Please see the following forum thread for more information on how this component should work. http://www.nabble.com/Ehcache-Standard-JBI-Component-tf2747953s12049.html#a7666554 was:Add support for ehcache using a Map. Put example of how to set this up in Wiki. Summary: Create a servicemix-ehcache standard JBI component (was: Add map support for Ehcache) Create a servicemix-ehcache standard JBI component -- Key: SM-679 URL: https://issues.apache.org/activemq/browse/SM-679 Project: ServiceMix Issue Type: New Feature Components: servicemix-components Affects Versions: 3.0 Reporter: Jeff Puro Assigned To: Jeff Puro Priority: Minor Fix For: 3.2 Add a servicemix-ehcache standard JBI component. Please see the following forum thread for more information on how this component should work. http://www.nabble.com/Ehcache-Standard-JBI-Component-tf2747953s12049.html#a7666554 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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.
