You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Claus Ibsen (JIRA)" <ji...@apache.org> on 2013/03/25 09:13:16 UTC

[jira] [Comment Edited] (CAMEL-6203) Cache configuration using properties file

    [ https://issues.apache.org/jira/browse/CAMEL-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13612453#comment-13612453 ] 

Claus Ibsen edited comment on CAMEL-6203 at 3/25/13 8:12 AM:
-------------------------------------------------------------

Should we introduce a new configuration format, when ehcache already has its own format. Which end users ideally should use instead?

The uri options is just for some basic use cases to quickly configure it.


On the other side we could allow to configure endpoints from an external resource in a generic way. So people can define a .properties file, or .json file etc. (or even xml if we want). And map that to endpoint uri parameters.

So maybe ponder a bit more about this, and consider a general way instead.

You can do this a bit with the property placeholders today:
{code}
from("cache://MyApplicationCache:{{cache.options}}")
{code}

And then have a .properties with
{code}
cache.options=?maxElementsInMemory=1000&maxElementsInMemory=1000 ...
{code}

But with a general solution it can maybe be more friendly
{code}
from("cache://MyApplicationCache?endpointConfigurationFile=classpath:com/foo/myCache.properties"
{code}

Would need to find a option name that don't clash with existing options, and would be reserved for this kind of general functionality.

myCache.properties
{code}
maxElementsInMemory=1000
maxElementsInMemory=1000
...
{code}


                
      was (Author: davsclaus):
    Should we introduce a new configuration format, when ehcache already has its own format. Which end users ideally should use instead?

The uri options is just for some basic use cases to quickly configure it.


On the other side we could allow to configure endpoints from an external resource in a generic way. So people can define a .properties file, or .json file etc. (or even xml if we want). And map that to endpoint uri parameters.

So maybe ponder a bit more about this, and consider a general way instead.

You can do this a bit with the property placeholders today:
from("cache://MyApplicationCache:{{cache.options}}")
{code}

And then have a .properties with
{code}
cache.options=?maxElementsInMemory=1000&maxElementsInMemory=1000 ...
{code}

But with a general solution it can maybe be more friendly
{code}
from("cache://MyApplicationCache?endpointConfigurationFile=classpath:com/foo/myCache.properties"
{code}

Would need to find a option name that don't clash with existing options, and would be reserved for this kind of general functionality.

myCache.properties
{code}
maxElementsInMemory=1000
maxElementsInMemory=1000
...
{code}


                  
> Cache configuration using properties file
> -----------------------------------------
>
>                 Key: CAMEL-6203
>                 URL: https://issues.apache.org/jira/browse/CAMEL-6203
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-cache
>            Reporter: Piotr Klimczak
>              Labels: camel-cache, ehcache, properties
>
> There should be a way to configure camel-cache with properties file using DefaultPropertiesResolver#loadPropertiesFromClasspath. So the route might look like this:
> {code}
> from("cache://myCache?configurationFile=classpath:com/foo/mycache.properties")...
> {code}
> instead of 
> {code}
> from("cache://MyApplicationCache" +
>           "?maxElementsInMemory=1000" +
>           "&memoryStoreEvictionPolicy=" +
>               "MemoryStoreEvictionPolicy.LFU" +
>           "&overflowToDisk=true" +
>           "&eternal=true" +
>           "&timeToLiveSeconds=300" +
>           "&timeToIdleSeconds=true" +
>           "&diskPersistent=true" +
>           "&diskExpiryThreadIntervalSeconds=300")
> {code}
> This improvement was added due to Henryk Konsek request.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira