Re: Namespace-driven builders and the UPA rule
On Jun 18, 2006, at 1:55 PM, Gianny Damour wrote: Hi, Is there a way to do this substitution of JACC implementation by providing a substitutionGroup attribute to the security element? I think this is the best solution, although there are some problems. It appears that substitution groups may not really be intended to provide runtime-extensible element support, at least xmlbeans doesn't work that way. I think I have a solution. Xmlbeans' ideas about substitution groups are that it only recognizes the substitutions that are in the set of schemas compiled at the same time as the element being substituted for. Later schemas compile just fine but the list of substitute qnames is hardcoded in the generated code for the substitutable element and also in the binary xsb encoding of the schema. It might be possible to add more qnames into the object model the xsb is deserialized into, but I don't see a reasonable way to modify the hardcoded list in the generated code. What I've come up with that appears to work is: - use substitution groups in the schemas. This makes it plausible to see what is intended, unlike with the use of any. - track substitution group elements ourselves, so we can dynamically change recognized substitution groups as builders are added. I'm less sure about tracking removing builders. In this case the elements wouldn't get deployed but we wouldn't get an error. - modify our response to validation failures to ignore those caused by unrecognized substitution group elements - use the XmlObject.selectChildren(QNameSet) method to get the substitution group elements based on our tracking of the QNames in the substitution group. I hope to iron out the remaining wrinkles shortly and submit an updated patch for review. thanks david jencks
Re: Namespace-driven builders and the UPA rule
I'll have to investigate this more. I'm not very familiar with substitution groups. If we can make this work, I think it would take care of at least some of Aarons concerns about anys, although for a generic build structure we might end up with something similar to anys. I don't like anys either, so I'm pretty motivated to look into this :-) I think the application-name is obsolete and should be removed. Thanks david jencks --- Gianny Damour <[EMAIL PROTECTED]> wrote: > 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: > > > > minOccurs="0"/> > > > > > > > > name="jacc-implementation" > type="xs:string"/> > > > > > > substitutionGroup="geronimo:security" > name="pluggable-security" > type="geronimo:pluggable-security"/> > > > > > > type="geronimo:moduleType" > minOccurs="0" maxOccurs="unbounded"/> > type="geronimo:ext-moduleType" > minOccurs="0" maxOccurs="unbounded"/> > type="geronimo:security" > minOccurs="0"/> > minOccurs="0" > maxOccurs="unbounded"/> > > > > type="xs:string" > use="optional"/> > > > 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 > > > >... > > >type="geronimo:ext-moduleType" minOccurs="0" > >maxOccurs="unbounded"/> > > >minOccurs="0"/> > > minOccurs="0" > >maxOccurs="unbounded"/> > > > > > >In order to make the security element variable, it > >needs to be >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 > >... > > >type="geronimo:ext-moduleType" minOccurs="0" > >maxOccurs="unbounded"/> > > >processContents="lax" minOccurs="0" > >maxOccurs="unbounded"/> > > > > > >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 > > > > >ref="naming:jndiEnvironmentRefsGroup"/> > > >ref="naming:message-destination" minOccurs="0" > >maxOccurs="unbounded"/> > > > > > > name="security-realm-name" > >type="xs:string"/> > > >minOccurs="0"/> > > > > > > minOccurs="0" > >maxOccurs="unbounded"/> > > > > > > > >With a similar combination as in the g-app schema > we'd > >get: > > > > >ref="naming:jndiEnvironmentRefsGroup"/> > > >ref="naming:message-destination" minOccurs="0" > >maxOccurs="unbounded"/> > > > > >type="xs:string" minOccurs="0"/> > > > > >processContents="lax" minOccurs="0" > >maxOccurs="unbounded"/> > > > > > > > >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 > > > > > > name="security-realm-name" > >type="xs:string"/> > > > > >ref="security:security" min
Re: Namespace-driven builders and the UPA rule
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: type="xs:string"/> name="pluggable-security" type="geronimo:pluggable-security"/> minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/> minOccurs="0"/> maxOccurs="unbounded"/> use="optional"/> 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 ... In order to make the security element variable, it needs to be 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 With a similar combination as in the g-app schema we'd get: 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 (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
Re: Namespace-driven builders and the UPA rule
I don't really like listing "any" elements in the middle of our schema. Then there's no way to tell what is valid or intended. Is there any other possible way to make this work? If not, I'd at least like to have a element that holds the any so it's clear what the any is supposed to hold (and so that all the following content doesn't also have to be "any"). But I would really prefer to do just about anything to avoid having schemas that just have "any" in the middle. Now not only are you required to use namespaces to make the file work at all, but also there's no guidance at all as to what schemas or content are valid. Thanks, Aaron On 6/17/06, David Jencks <[EMAIL PROTECTED]> wrote: The "noupa" approach seems to be working, although it's going to require changes to either or both of the m1 and m2 xmlbeans plugins... still investigating. thanks david jencks --- David Jencks <[EMAIL PROTECTED]> 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 > > ... > type="geronimo:ext-moduleType" minOccurs="0" > maxOccurs="unbounded"/> > minOccurs="0"/> > minOccurs="0" > maxOccurs="unbounded"/> > > > In order to make the security element variable, it > needs to be 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 > ... > type="geronimo:ext-moduleType" minOccurs="0" > maxOccurs="unbounded"/> > processContents="lax" minOccurs="0" > maxOccurs="unbounded"/> > > > 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 > > ref="naming:jndiEnvironmentRefsGroup"/> > ref="naming:message-destination" minOccurs="0" > maxOccurs="unbounded"/> > > > name="security-realm-name" > type="xs:string"/> > minOccurs="0"/> > > > minOccurs="0" > maxOccurs="unbounded"/> > > > > With a similar combination as in the g-app schema > we'd > get: > > ref="naming:jndiEnvironmentRefsGroup"/> > ref="naming:message-destination" minOccurs="0" > maxOccurs="unbounded"/> > > type="xs:string" minOccurs="0"/> > > processContents="lax" minOccurs="0" > maxOccurs="unbounded"/> > > > > 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 > > > name="security-realm-name" > type="xs:string"/> > > ref="security:security" minOccurs="0"/> > ref="security:security-holder" minOccurs="0"/> > > > > (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 > > > > >
Re: Namespace-driven builders and the UPA rule
The "noupa" approach seems to be working, although it's going to require changes to either or both of the m1 and m2 xmlbeans plugins... still investigating. thanks david jencks --- David Jencks <[EMAIL PROTECTED]> 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 > > ... > type="geronimo:ext-moduleType" minOccurs="0" > maxOccurs="unbounded"/> > minOccurs="0"/> > minOccurs="0" > maxOccurs="unbounded"/> > > > In order to make the security element variable, it > needs to be 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 > ... > type="geronimo:ext-moduleType" minOccurs="0" > maxOccurs="unbounded"/> > processContents="lax" minOccurs="0" > maxOccurs="unbounded"/> > > > 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 > > ref="naming:jndiEnvironmentRefsGroup"/> > ref="naming:message-destination" minOccurs="0" > maxOccurs="unbounded"/> > > > name="security-realm-name" > type="xs:string"/> > minOccurs="0"/> > > > minOccurs="0" > maxOccurs="unbounded"/> > > > > With a similar combination as in the g-app schema > we'd > get: > > ref="naming:jndiEnvironmentRefsGroup"/> > ref="naming:message-destination" minOccurs="0" > maxOccurs="unbounded"/> > > type="xs:string" minOccurs="0"/> > > processContents="lax" minOccurs="0" > maxOccurs="unbounded"/> > > > > 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 > > > name="security-realm-name" > type="xs:string"/> > > ref="security:security" minOccurs="0"/> > ref="security:security-holder" minOccurs="0"/> > > > > (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 > > > > >
Namespace-driven builders and the UPA rule
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 ... In order to make the security element variable, it needs to be 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 With a similar combination as in the g-app schema we'd get: 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 (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
