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
