geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <gianny.dam...@optusnet.com.au>
Subject Re: Namespace-driven builders and the UPA rule
Date Sun, 18 Jun 2006 11:55:00 GMT
Hi,

Is there a way to do this substitution of JACC implementation by 
providing a substitutionGroup attribute to the security element?

This may be not be correct; yet, this could look like this:

    <xs:complexType name="security">
        <xs:sequence>
            <xs:element ref="security:security" minOccurs="0"/>
        </xs:sequence>
    </xs:complexType>

    <xs:complexType name="pluggable-security">
        <xs:complexContent>
            <xs:extension base="geronimo:security"/>
                <xs:sequence>
                    <xs:element name="jacc-implementation" 
type="xs:string"/>
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

    <xs:element substitutionGroup="geronimo:security" 
name="pluggable-security" type="geronimo:pluggable-security"/>

    <xs:complexType name="applicationType">
        <xs:sequence>
            <xs:element ref="sys:environment"/>

            <xs:element name="module" type="geronimo:moduleType" 
minOccurs="0" maxOccurs="unbounded"/>
            <xs:element name="ext-module" type="geronimo:ext-moduleType" 
minOccurs="0" maxOccurs="unbounded"/>
            <xs:element name="security" type="geronimo:security" 
minOccurs="0"/>
            <xs:element ref="sys:gbean" minOccurs="0" 
maxOccurs="unbounded"/>
        </xs:sequence>

        <!--TODO application name should be settable using name-key in 
the environment.  Does this work? -->
        <xs:attribute name="application-name" type="xs:string" 
use="optional"/>
    </xs:complexType>

I think that this approach is more verbose than the namespace-driven 
approach; however, it is then easier to read the schema and understands 
how to swap the JACC implementation.

Thanks,
Gianny

David Jencks wrote:

>For the pluggable jacc implementation (GERONIMO-1563)
>I've been working on making a basic namespace-driven
>builder framework.  The code is simple and looks like
>it will work fine but..... there's a problem with the
>schema unique particle attribute rule, which basically
>says that in order for a schema to be valid each
>element can only be parsed in one way, and the way
>must be determined without looking forward or
>backwards or looking very hard at the context.
>
>OK.  So, I wanted to make the geronimo security
>element namespace-driven, so if you used the current
>security-1.1 namespace you'd get our current impl, if
>you used something else you'd get that impl.  We had
>
>...
>            <xs:element name="ext-module"
>type="geronimo:ext-moduleType" minOccurs="0"
>maxOccurs="unbounded"/>
>            <xs:element ref="security:security"
>minOccurs="0"/>
>            <xs:element ref="sys:gbean" minOccurs="0"
>maxOccurs="unbounded"/>
>        </xs:sequence>
>
>In order to make the security element variable, it
>needs to be <xs:any namespace="##other"
>minOccurs="0:/>
>
>Then in order to prevent the first gbean matching this
>if there's no security element I have to make the
>gbeans work through namespace driven builder too, and
>get
>...
>            <xs:element name="ext-module"
>type="geronimo:ext-moduleType" minOccurs="0"
>maxOccurs="unbounded"/>
>            <xs:any namespace="##other"
>processContents="lax" minOccurs="0"
>maxOccurs="unbounded"/>
>        </xs:sequence>
>
>This works fine for the geronimo-application schema
>
>the problem comes with the web schemas  (and perhaps
>the openejb schema, I haven't got that far yet).  We
>now have
>
>            <xs:group
>ref="naming:jndiEnvironmentRefsGroup"/>
>            <xs:element
>ref="naming:message-destination" minOccurs="0"
>maxOccurs="unbounded"/>
>
>            <xs:sequence minOccurs="0">
>                <xs:element name="security-realm-name"
>type="xs:string"/>
>                <xs:element ref="security:security"
>minOccurs="0"/>
>            </xs:sequence>
>
>            <xs:element ref="sys:gbean" minOccurs="0"
>maxOccurs="unbounded"/>
>
>        </xs:sequence>
>
>With a similar combination as in the g-app schema we'd
>get:
>
>            <xs:group
>ref="naming:jndiEnvironmentRefsGroup"/>
>            <xs:element
>ref="naming:message-destination" minOccurs="0"
>maxOccurs="unbounded"/>
>
>            <xs:element name="security-realm-name"
>type="xs:string" minOccurs="0"/>
>
>            <xs:any namespace="##other"
>processContents="lax" minOccurs="0"
>maxOccurs="unbounded"/>
>
>        </xs:sequence>
>
>if the security-realm-name element was required
>there'd be no problem, you could tell that the naming
>elements are not part of the anys at the end.  However
>if it is missing, the naming elements could match the
>explicit elements or the anys.
>
>I don't know how to get by this problem.  xmlbeans has
>a no-upa option which might let use use this schema,
>but it's an invalid schema, so this is not completely
>desirable.  We could turn the entire schema into a
>bunch of anys, but this sort of loses the point of
>having a schema.  We could make an incompatible change
>to the schema, or we could special case the current
>security namespace and effectively introduce another
>element to hold other builders security info,
>something like
>
>            <xs:sequence minOccurs="0">
>                <xs:element name="security-realm-name"
>type="xs:string"/>
>                <xs:choice>
>                    <xs:element
>ref="security:security" minOccurs="0"/>
>                    <xs:element
>ref="security:security-holder" minOccurs="0"/><!--
>holds other peoples security element -->
>                </choice>
>            </xs:sequence>
>
>(I'm not sure this is a legal schema bit)
>
>I'm going to try out the noupa option first but I'm
>hoping someone will come up with a generally better
>approach.
>
>thanks
>david jencks
>
>
>
>
>
>
>  
>



Mime
View raw message