[
https://issues.apache.org/jira/browse/CAMEL-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020749#comment-13020749
]
Piotr Klimczak commented on CAMEL-3867:
---------------------------------------
I've made a little more changes- I've done some code cleanup.
I do understand that code cleanups are dificult to analize but it is still
better option than improving bad code.
Here is the list what I've done in this patch:
- added URI configuration option named: eventListenerRegistry which is a ref to
CacheEventListenerRegistry type
- added unit test to test event listener behaviour- to make sure that
referenced listeners are invoked (CacheEventListenerRegistryTest)
- cleaned up consumer and producer by moving same code do the CacheEndpoint
- removed cache stop from consumer/producer and moved to the endpoint- as I
understand the camel it will prevent removing cache when route is stopped
manually.
- added unit test to test route manual shutdown and cache being still alive
If you don't like those changes, then please give me a sign.
Plese note that i did not want to divide it to 2 improvements as it'll be quite
complicated.
Plese also note that applying this patch to trunk will casuse the my last osgi
unit test to stop working, as the cache manager factory will not be initialized
until first routing will be done.
Will attach a patch soon.
Should I make new issue for that? or simply attach a patch to itest here?
Hope you like it :)
HAVE A FUN!
> camel-cache- improve ehcache configuration by reference
> RegisteredEventListeners
> --------------------------------------------------------------------------------
>
> Key: CAMEL-3867
> URL: https://issues.apache.org/jira/browse/CAMEL-3867
> Project: Camel
> Issue Type: Improvement
> Components: camel-cache
> Environment: Osgi/Spring based
> Reporter: Piotr Klimczak
> Priority: Minor
> Labels: camel-cache, ehcache, improvement, listener, replication
> Attachments: camel-cache.cleanupAndLitenersRef.txt
>
>
> The thing is, that cache names can be a dynamic list. But ehcache is
> expecting to get static list (known before start) on it's xml configuration
> file. Ehcache provides some defaults config. for new caches with some
> exceptions. One of them are cache listeners (like replication listeners).
> So the thing is, to give ability to define listeners (via spring/blueprint
> ref.) during endpoint construction.
> This will ease configuration of listeners as xml static list of listeners
> (per cache) will not be needed anymore. Instead of very long list which you
> have to keep up to date, you could define one list of listeners for all cache
> endpoints!
> SO SIMPLE! :)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
