I think this all ties in to how we construct the dynamic deployment module for a module we are trying to deploy.

There's certainly no need for the namespace to be included in the gbean name of the builder. Builders are going to have to register with a framework somehow: currently they either register with Deployer if they are ConfigBuilders or have references from the EarBuilder or a ModuleBuilder. A builder gbean can certainly have a read-only namespace attribute, or call a registration method with the namespace as a parameter.

I'm not yet convinced that the tradeoff of eliminating complete validation of a plan is worth the flexibility of an any element with dynamic extension registration.

david jencks


On Feb 25, 2005, at 11:37 AM, Hiram Chirino wrote:



Jeremy Boynes wrote:
Alan D. Cabrera wrote:

Stealing a page from the JavaMail spec
Those words send a cold cold shiver through my soul.
why not have resource files called geronimo.builders and geronimo.default.builders. These are resource files located in META-INF. They declare a builders and could also hold their configuration. This way, we wouldn't have to embed the name of the builder in the config file, just use the namespace.

Why not just make the builder a GBean and locate it using the namespace?
E.g.
<gbean gbeanName='type=builder,namespace=http://geronimo.apache.org/xml/ns/ security'> ...
</gbean>

I like this. But then the name space is restricted be something that can be used in a GBeanName right (since we don't escape)? I'm not sure that's good restriction.


Regards,
Hiram

Then when you hit the new namespace look up the GBean and hand off the content processing to it?
--
Jeremy




Reply via email to