Any news on this? I was about to make a post suggesting something similar. I thought it might be better to use the Spring cache integration interface so that other caches than EHCache can be plugged in.
I have a small presentation showing the issues and would welcome comments. Specifically I think that the users should be able to dynamically configure both the cache the way in which it is applied. I would be interested in progress so far.... Cheers ray http://www.nabble.com/file/p12094962/ESB%2BCaching%2B-%2BServiceMix.ppt ESB+Caching+-+ServiceMix.ppt 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 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: Regards, -Jeff bsnyder wrote: > > On 12/3/06, jpuro 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 > > -- View this message in context: http://www.nabble.com/Ehcache-Standard-JBI-Component-tf2747953s12049.html#a12094962 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
