[
https://issues.apache.org/jira/browse/KARAF-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Pieber updated KARAF-550:
---------------------------------
Description:
The current custom.properties approach has some drawbacks in case you have a
structure like karaf <- other framework project like smx <- client project. In
this case you may like to add some custom.properties which should not be as
easy to overwrite by the client. For example you want to provide a default
configuration for activemq webconsole, or some other properties. As the
framework you can overwrite the config.properties file now and include
additional property files used this way but this has the drawback that you, as
framework developer, have to upgrade the config.properties with each karaf
upgrade. I've two options in minds:
<<edit>>
After some lengthy discussion with Guillaume and JB we come to the following
conclusion for this issue:
In addition to providing directly the files which should be used in
config.properties in system.properties and config.properties a pattern could be
defined in config.properties and system.properties (besides the "regular"
includes) to allow that client projects/frameworks could easily add additional
config files which are included without any additional work
was:
The current custom.properties approach has some drawbacks in case you have a
structure like karaf <- other framework project like smx <- client project. In
this case you may like to add some custom.properties which should not be as
easy to overwrite by the client. For example you want to provide a default
configuration for activemq webconsole, or some other properties. As the
framework you can overwrite the config.properties file now and include
additional property files used this way but this has the drawback that you, as
framework developer, have to upgrade the config.properties with each karaf
upgrade. I've two options in minds:
1) Support the * operator in the ${INCLUDE} section in config.properties and
add a *.defaults in karaf
2) load an includes.properties file not provided by karaf per default. That way
the framework can provide a includes.properties loaded at bootstrap and
searched for e.g. ${ADDITIONAL_INCLUDES} = activemq.properties
otherframworkspecificthings.properties ...
I slightly prefer the second option since it should be easier to implement :)
I would really like to know what you think about this idea.
> Make it easier to add additional custom property files
> ------------------------------------------------------
>
> Key: KARAF-550
> URL: https://issues.apache.org/jira/browse/KARAF-550
> Project: Karaf
> Issue Type: Improvement
> Reporter: Andreas Pieber
> Assignee: Andreas Pieber
> Fix For: 3.0.0
>
>
> The current custom.properties approach has some drawbacks in case you have a
> structure like karaf <- other framework project like smx <- client project.
> In this case you may like to add some custom.properties which should not be
> as easy to overwrite by the client. For example you want to provide a default
> configuration for activemq webconsole, or some other properties. As the
> framework you can overwrite the config.properties file now and include
> additional property files used this way but this has the drawback that you,
> as framework developer, have to upgrade the config.properties with each karaf
> upgrade. I've two options in minds:
> <<edit>>
> After some lengthy discussion with Guillaume and JB we come to the following
> conclusion for this issue:
> In addition to providing directly the files which should be used in
> config.properties in system.properties and config.properties a pattern could
> be defined in config.properties and system.properties (besides the "regular"
> includes) to allow that client projects/frameworks could easily add
> additional config files which are included without any additional work
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
