Extend class path from config.xml

[Dain Sundstrom <da...@iq80.com>]

I think we should add support to extend the class path from the  
config.xml file.  Without this it is not possible to add GBeans via a  
the configuration.xml using classes not declared in the original  
plan.  Another problem revolves around extension hooks in services.   
It is common for a service to allow you to specify a alternative  
implementation for some internal service.  For example, our  
SecurityService GBean allows for the replacement of the  
policyConfigurationFactory
  and the policyProvider.  Unfortunately, these hooks are virtually  
useless since the replacement classes must have been included in the  
environment of the original plan.  Of course, the best option would  
be to rewrite this service to use references, which are easily  
replaceable and externalizable in another plan, but that is not  
always possible.

I have no plans to implement this myself, but wanted to get a  
discussion going, and if we decide that is want to add this feature,  
I'll create a JIRA to track it.

-dain

Re: Extend class path from config.xml

[Jason Dillon <ja...@planet57.com>]

Seems like a reasonable thing to have.

Is this an extension to the plan's xsd or just a specialized gbean  
that can augment the classpath?

--jason


On Jun 26, 2006, at 5:26 PM, Dain Sundstrom wrote:

> I think we should add support to extend the class path from the  
> config.xml file.  Without this it is not possible to add GBeans via  
> a the configuration.xml using classes not declared in the original  
> plan.  Another problem revolves around extension hooks in  
> services.  It is common for a service to allow you to specify a  
> alternative implementation for some internal service.  For example,  
> our SecurityService GBean allows for the replacement of the  
> policyConfigurationFactory
>  and the policyProvider.  Unfortunately, these hooks are virtually  
> useless since the replacement classes must have been included in  
> the environment of the original plan.  Of course, the best option  
> would be to rewrite this service to use references, which are  
> easily replaceable and externalizable in another plan, but that is  
> not always possible.
>
> I have no plans to implement this myself, but wanted to get a  
> discussion going, and if we decide that is want to add this  
> feature, I'll create a JIRA to track it.
>
> -dain
>