geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: CDATA and GBean attributes
Date Sat, 26 Feb 2005 15:11:43 GMT
David Jencks wrote:
> 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.
> 

The "type" and "namespace" keys provide a unique locator for a service 
by defining what it is (a builder that handles XML instances) and how 
things of that type can be differentiated (by the namespace it handles). 
That is sufficient to allow this service to located by anything that 
wants an XML document handled.

This seems simpler than inventing a proprietary registration mechanism. 
We already have a GBean registry, lets use it.

> 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.
> 

I have reservations as well, primarily that the user will need to deal 
with an ever increasing number of fairly small XML namespaces and the 
maintenance problems that they will incur with upgrades.

I would prefer to see fewer, larger namespaces that incorporate common 
elements by inclusion with schema override. This also will have 
advantages for validation. Yes it means more work for us in producing 
and maintaining the schema definitions, but we do that once rather than 
forcing users to deal with it in every plan instance.

However, this does seem to be better than the original mechanism of 
placing CDATA inside attribute values.

--
Jeremy

Mime
View raw message