geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: CDATA and GBean attributes
Date Wed, 23 Feb 2005 21:53:39 GMT

On Feb 23, 2005, at 11:53 AM, Dain Sundstrom wrote:

> On Feb 23, 2005, at 11:40 AM, David Blevins wrote:
>> On Wed, Feb 23, 2005 at 12:13:50PM -0500, Alan D. Cabrera wrote:
>>> I don't parse the data at startup.  The data gets parsed by a
>>> tssConfigEditor and a cssConfigEditor at deployment time.
>> Cool.  Is this a case where you could put the xml in another file in 
>> the archive and have the attribute be the name of the file?
> I personally dislike having lots of little config files in the 
> archive.  I think it would be more natural for our xml document to be 
> extensible, and support importing of schemas into our catalog.

I agree that lots of files is unpleasant.
> And to appease david's no-mixed context rule we could have two 
> attribute elements, one for xml and one for text;
> <attribute name="port">8888</attribute>
> <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.

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.

david jencks

> -dain

View raw message