geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <djen...@gluecode.com>
Subject Re: CDATA and GBean attributes
Date Thu, 24 Feb 2005 00:51:31 GMT

On Feb 23, 2005, at 3:16 PM, Dain Sundstrom wrote:

> 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="http://geronimo.apache.org/xml/ns/security">
>>>         <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.

that was my point.
>
> 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....

won't be hard, but I'm still not sure its worth it.
>
>> 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.

I think this is what I mean by a security builder.  However, I haven't 
figured out a very extensible way to choose the builder based on 
namespace while having the entire document validated.  There's probably 
some way to do it elegantly, but I haven't found it yet.

david jencks
>
> -dain
>


Mime
View raw message