geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: CDATA and GBean attributes
Date Fri, 25 Feb 2005 02:28:01 GMT
On Wed, Feb 23, 2005 at 04:51:31PM -0800, David Jencks wrote:
> 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="">
> >>>        <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

Seems either next to the namespace declaration or in a separate section of the plan, or both.

So like:
<xattribute name="securityConfig">
    <security xmlns="" plan:builder="o.a.g.SecurityBuilder">
        <default-principal realm-name="public-properties-realm">
            <principal class="o.a.g.s.r.p.GeronimoUserPrincipal" name="j2ee"/>
            <role role-name="Administrator">
                <realm realm-name="public-properties-realm">
class="o.a.g.s.r.p.GeronimoUserPrincipal" name="j2ee"/>
            <role role-name="Employee">
                <realm realm-name="public-properties-realm">
class="o.a.g.s.r.p.GeronimoUserPrincipal" name="j2ee"/>

Where builder is an attribute in the plan namespace, so the embedded schema doesn't need to
be one we control.

Or else some section containing builders:

<builders xmlns:security="" xmlns:ejb="...."
    <builder impl="security:o.a.g.SecurityBuilder"/>
    <builder impl="ejb:o.o.d.OpenEJBBuilder"/>
    <builder impl="connector:o.a.g.ConnectorBuilder"/>

Or a variant of that:

    <builder impl="security:o.a.g.SecurityBuilder"  xmlns:security=""/>
    <builder impl="ejb:o.o.d.OpenEJBBuilder" xmlns:ejb="...." />
    <builder impl="connector:o.a.g.ConnectorBuilder" xmlns:connector="...."/>

Since the primary job of a builder is to put a GBean into the system, we could take Hiram's
GBeanInfoFactory idea and mix it in somewhat.  Meaning that the builder could create the GBeanInfo
as well.  Se we give builders the ability to have properties themselves:

    <builder impl="security:o.a.g.SecurityBuilder"  xmlns:security="">
        <property name="attributeDefault" value="read-only" />

Maybe that is not a good example proptery, but the idea is that if they are responsible for
creating GBeans, and potentially the GBeanInfo, they may need some setup themselves.

Anyway, just throwing ideas out.  Pick, pook, prod, or ignore.


View raw message