geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: CDATA and GBean attributes
Date Wed, 23 Feb 2005 23:16:37 GMT
On Feb 23, 2005, at 1:53 PM, David Jencks wrote:

> On Feb 23, 2005, at 11:53 AM, Dain Sundstrom wrote:
>> <xattribute name="securityConfig">
>>     <security xmlns="">
>>         <default-principal realm-name="public-properties-realm">
>>             <principal class="o.a.g.s.r.p.GeronimoUserPrincipal" 
>> name="j2ee"/>
>>         </default-principal>
>>         <role-mappings>
>>             <role role-name="Administrator">
>>                 <realm realm-name="public-properties-realm">
>>                     <principal 
>> class="o.a.g.s.r.p.GeronimoUserPrincipal" name="j2ee"/>
>>                 </realm>
>>             </role>
>>             <role role-name="Employee">
>>                 <realm realm-name="public-properties-realm">
>>                     <principal 
>> class="o.a.g.s.r.p.GeronimoUserPrincipal" name="j2ee"/>
>>                 </realm>
>>             </role>
>>         </role-mappings>
>>     </security>
>> </xattibute>
> This satisfies my insistence on no-mixed content, and IMO would be 
> possible to implement.  It still has the problem that the 
> xml-attribute element will have to contain an "any" thus making it 
> impossible to check if you put the right kind of document in there 
> without loading it into the gbean you are configuring.

Are you sure?  In the example above I put a security element using 
security namespace.  I would assume that the xml parser would verify 
that the security element is internally consistent.  Now that would not 
assure me that the component wasn't looking for say an ActiveMQ queue 
configuration element.

I suppose that if we went down this path, we would want something like 
the java beans property editors that took an xml dom (or XmlObject) and 
created java object, and that may be too much work for the effort....

> However, I wonder if this is really a good way to approach this.  Why 
> wouldn't we prefer a builder that reads, in this case, a security 
> config document and generates gbeanDatas from it? Rather than trying 
> to break up the concepts into independent single-gbean sized pieces, 
> wouldn't it provide a better administrator experience to have a single 
> schema for the entire area you are trying to configure?   Such a 
> schema can make sure that you are setting up corresponding gbeans, set 
> relationships, etc etc and generally work better.

Good point.  I'm not sure.  As an administrator, I hate the idea of an 
Easter egg hunt, and would personally like a single document with many 
internal types.   On the other hand, I really don't like the idea of 
having a (in this case) a security descriptor as an attribute.

Building on David Blevins idea from earlier and using the example 
above, it would nice to be able to have a plain old security descriptor 
in the  plan without any wrapper.  In that case you would have your 
gbeans and then several xs:any types.  At deployment time, we would 
look up a handler for the unknown element based on the namespace.  The 
handler would get the element and the deployment context.  Having 
deployment plugin support for all of our standard descriptors would be 
very powerful.


View raw message