You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Adrian Gonzalez <ad...@yahoo.fr> on 2012/03/14 11:35:15 UTC
Easy configuration externalization
Hello,
I'm wondering if it would be beneficial to add this ConfigSource to DS :
* ConfigSource retrieving property file location from JNDI (i.e. java:comp/env/ApacheDeltaspikeConfigLocation)
Or perhaps java:module/env, or java:app/env [1]
With initOrdinal 99 ? (before PropertyFileConfigSource)
Motivation :
None of the out of the box enables 'easily' to externalize all the configuration from the application, see [2] - at least I didn't figured it.
WDYT ?
[1] java:comp/env, java:module/env or java:app/env
For webapps, java:comp/env can be used I think [3].
For ear (with EJB components), java:comp/env can get messy I think.
So perhaps it should search from java:comp/env, java:module/env and java:app/env in this order until it finds one.
[2] Comparison of Deltaspike's ConfigSource :
* SystemPropertyConfigSource :
pros :
* enables conf externalization.
cons :
* difficult to configure when app has many config properties.
* difficult to configure for appserver with multiple applications on it.
* EnvironmentPropertyConfigSource :
pros /cons :
* same as SystemPropertyConfigSource
* LocalJndiConfigSource :
pros :
* enables conf externalization.
cons :
* if java:comp/env is used : web.xml clutering when app has many config properties.
* if not, difficult to use for many properties (at least on websphere, it's several clicks in order to add a single property).
* PropertyFileConfigSource :
pros :
* simple to use
cons :
* configuration inside the app (need to redeploy the app when conf is changed - or we need to configure an application classloader to add an external path to the app).
[3] quote from EE.5.2.2Application Component Environment Namespaces (http://download.oracle.com/otndocs/jcp/javaee-6.0-fr-eval-oth-JSpec/)
For historical reasons, the java:comp namespace is shared by all components in a web module. To preserve compatibility,
this specification doesn’t change that. In a web module, java:comp refers to the same namespace as java:module.
It is recommended that resources in a web module that are intended to be shared by more than one component be declared in the java:module/env namespace.
Re: Easy configuration externalization
Posted by Gerhard Petracek <ge...@gmail.com>.
hi adrian,
my first comment at [1] is also my comment for this topic.
(however, we could use this idea for the documentation to explain an
advanced use-case for custom implementations of ConfigSource.)
regards,
gerhard
[1] https://issues.apache.org/jira/browse/DELTASPIKE-128
2012/3/14 Adrian Gonzalez <ad...@yahoo.fr>
> Hello,
>
> I'm wondering if it would be beneficial to add this ConfigSource to DS :
> * ConfigSource retrieving property file location from JNDI (i.e.
> java:comp/env/ApacheDeltaspikeConfigLocation)
> Or perhaps java:module/env, or java:app/env [1]
> With initOrdinal 99 ? (before PropertyFileConfigSource)
>
> Motivation :
> None of the out of the box enables 'easily' to externalize all the
> configuration from the application, see [2] - at least I didn't figured it.
>
> WDYT ?
>
> [1] java:comp/env, java:module/env or java:app/env
> For webapps, java:comp/env can be used I think [3].
> For ear (with EJB components), java:comp/env can get messy I think.
> So perhaps it should search from java:comp/env, java:module/env and
> java:app/env in this order until it finds one.
>
> [2] Comparison of Deltaspike's ConfigSource :
> * SystemPropertyConfigSource :
> pros :
> * enables conf externalization.
> cons :
> * difficult to configure when app has many config properties.
> * difficult to configure for appserver with multiple applications on
> it.
> * EnvironmentPropertyConfigSource :
> pros /cons :
> * same as SystemPropertyConfigSource
> * LocalJndiConfigSource :
> pros :
> * enables conf externalization.
> cons :
> * if java:comp/env is used : web.xml clutering when app has many
> config properties.
> * if not, difficult to use for many properties (at least on websphere,
> it's several clicks in order to add a single property).
> * PropertyFileConfigSource :
> pros :
> * simple to use
> cons :
> * configuration inside the app (need to redeploy the app when conf is
> changed - or we need to configure an application classloader to add an
> external path to the app).
>
> [3] quote from EE.5.2.2Application Component Environment Namespaces (
> http://download.oracle.com/otndocs/jcp/javaee-6.0-fr-eval-oth-JSpec/)
> For historical reasons, the java:comp namespace is shared by all
> components in a web module. To preserve compatibility,
> this specification doesn’t change that. In a web module, java:comp refers
> to the same namespace as java:module.
> It is recommended that resources in a web module that are intended to be
> shared by more than one component be declared in the java:module/env
> namespace.
>