Schema duplication/inconsistency in patternType

[David Jencks <da...@yahoo.com>]

Aaron pointing out a long time ago that we have two
similar elements with the same localName in our plan
schemas:

In geronimo-module-1.1.xsd:

    <xs:complexType name="patternType">
        <xs:annotation>
            <xs:documentation>This group contains the
components of an abstract name</xs:documentation>
        </xs:annotation>
         <xs:sequence>
            <xs:sequence>
                <xs:element name="groupId"
type="xs:string" minOccurs="0"/>
                <xs:element name="artifactId"
type="xs:string" minOccurs="0"/>
                <xs:element name="version"
type="xs:string" minOccurs="0"/>
                <xs:element name="module"
type="xs:string" minOccurs="0"/>
                <xs:element name="type"
type="xs:string" minOccurs="0"/>
                <xs:element name="name"
type="xs:string" minOccurs="0"/>
            </xs:sequence>
        </xs:sequence>
    </xs:complexType>

Let's call this one "A""

This is used in gbean references ( reference element
inside a gbean element) to locate the target gbean.  

In geronimo-naming-1.1.xsd:

    <xsd:complexType name="patternType">
        <xsd:sequence>
            <xsd:element name="groupId"
type="xsd:string" minOccurs="0"/>
            <xsd:element name="artifactId"
type="xsd:string" minOccurs="0"/>
            <xsd:element name="version"
type="xsd:string" minOccurs="0"/>
            <xsd:element name="module"
type="xsd:string" minOccurs="0"/>
            <xsd:element name="name"
type="xsd:string"/>
        </xsd:sequence>
    </xsd:complexType>

Let's call this one "B"

This is used in a jndi *-ref element to locate the
gbean for a j2ee component that we will call a method
on to get the j2ee component (or a proxy to it) that
we hand out to whatever is looking up in jndi.

There are 2 differences:

1. A has minOccurs=0 on name, in B it is required.  I
strongly suspect this is a bug in A and name should be
required.  This is IMO minor.

2. A has a type element missing in B.  This is what
Aaron is asking about.  This is a very problematic
element.  Based on the element localName type, it
could mean any of 3 things:
- type of the geronimo module the target gbean is in. 
For a long time this had to be "car" and I'm not sure
if this has changed.  There's certainly been some
discussion in favor of changing that restriction.  At
the moment I'm not in favor of changing it.
- If the gbean is a j2ee component, it will be in a
j2ee module, which means it's a j2ee component in a
standalone module (ejb jar, war, or rar deployed into
a car) or a module inside an ear.  This module will
have a type (EJBModule, WebModule,
ResourceAdapterModule).    Note that the "module"
element will only be present if the gbean is in a j2ee
module.  Currently there's a bug in that if you
specify "module" you will never find the target gbean
since it will have something like EJBModule=foo but we
will look for J2EEModule=foo.
- Every abstract name we construct has a j2eeType key.
 type could refer to this.

If you look at where the value of this element is
used, it is used only in GBeanBuilder and it means the
3rd choice, j2eeType.  As such it is unnecessary in B
since we know the j2eeType of the target gbean for
jndi refs since it is determined by the kind of ref it
is (ejb-ref, resource-ref, etc).  Also in B we can
figure out the module type (as in the 2nd possibility)
since an ejb will only be in an EJBModule, etc.

---------------

proposal:

We might be able to simplify this situation a little
bit by:
- To reduce duplication between similar elements, make
the naming schema patternType a restriction of the
module schema patternType, with type's maxOccurs=0.
- To eliminate the bug in module schema when you
specify the module, construct matching patterns using
all possible module types (ServiceModule, EJBModule,
WebModule, etc).  There might be a similar bug in the
naming schema when looking for a resource-ref that is
in fact implemented as a plain gbean such as the
MailGBean or JAXR connection factory.  This needs more
investigation.
- Ignore/document the rather extreme ambiguity about
the possible meaning of "type"  I really don't know
what to do about this part.

I'll try implementing these and see how far I get. 
Due to very limited internet access at the moment I
probably won't have anything to report until at least
tomorrow (may 27).  Comments and suggestions would be
great.

thanks
david jencks

Re: Schema duplication/inconsistency in patternType

[Aaron Mulder <am...@alumni.princeton.edu>]

We can't assume that every module's type is "car".  That is not
correct.  Many have J2EE module types (rar, ear, war, etc.).  In
particular, if you're constructing a reference to an EJB, you probably
need the module type to be "jar" and for a database pool or JMS
resource is needs to be "rar".  (Though of course the ones configured
with Geronimo by default are "car".)

So I think we need a "type" element to go with the groupId,
artifactId, and version.  To give a concrete example, let's say I have
these 4 modules:

console/MyPool1/1.0/rar
 - contains DB Pool "MyPool"

console/AnotherPool/1.0/rar
 - contains DB Pool "MyPool"

console/AnotherPool/1.0/jar
 - contains a thread pool "MyPool"

aaron/test/1.0/war
 - dependency on console/MyPool1/1.0/rar
 - dependency on console/AnotherPool/1.0/rar
 - dependency on console/AnotherPool/1.0/jar
 - resource-ref type DataSource that I want to map to MyPool (the one
in console/AnotherPool/1.0/rar)

How do I set that resource-ref?  I think it needs something like this:
<pattern>
  <groupId>console</groupId>
  <artifactId>AnotherPool</artifactId>
  <version>1.0</version>
  <type>rar</type>
  <name>MyPool</name>
</pattern>

If we leave out the type, either it assumes "car" (wrong) or it gets
confused between DB pool MyPool in console/AnotherPool/1.0/rar and
thread pool MyPool in console/AnotherPool/1.0/jar (2 matches).

I recognize this is a completely different definition of "type" than
we are currently using.  I suggested using "moduleType" for that
reason, but David J said he thought we should stick strictly to Maven
syntax and therefore it needs to be called "type".  Personally, I
don't think we need to stick to Maven syntax (since we are not using
Maven or passing this plan to Maven for processing), but I don't feel
super-strongly about it.

Thanks,
    Aaron

On 5/26/06, David Jencks <da...@yahoo.com> wrote:
> Aaron pointing out a long time ago that we have two
> similar elements with the same localName in our plan
> schemas:
>
> In geronimo-module-1.1.xsd:
>
>     <xs:complexType name="patternType">
>         <xs:annotation>
>             <xs:documentation>This group contains the
> components of an abstract name</xs:documentation>
>         </xs:annotation>
>          <xs:sequence>
>             <xs:sequence>
>                 <xs:element name="groupId"
> type="xs:string" minOccurs="0"/>
>                 <xs:element name="artifactId"
> type="xs:string" minOccurs="0"/>
>                 <xs:element name="version"
> type="xs:string" minOccurs="0"/>
>                 <xs:element name="module"
> type="xs:string" minOccurs="0"/>
>                 <xs:element name="type"
> type="xs:string" minOccurs="0"/>
>                 <xs:element name="name"
> type="xs:string" minOccurs="0"/>
>             </xs:sequence>
>         </xs:sequence>
>     </xs:complexType>
>
> Let's call this one "A""
>
> This is used in gbean references ( reference element
> inside a gbean element) to locate the target gbean.
>
> In geronimo-naming-1.1.xsd:
>
>     <xsd:complexType name="patternType">
>         <xsd:sequence>
>             <xsd:element name="groupId"
> type="xsd:string" minOccurs="0"/>
>             <xsd:element name="artifactId"
> type="xsd:string" minOccurs="0"/>
>             <xsd:element name="version"
> type="xsd:string" minOccurs="0"/>
>             <xsd:element name="module"
> type="xsd:string" minOccurs="0"/>
>             <xsd:element name="name"
> type="xsd:string"/>
>         </xsd:sequence>
>     </xsd:complexType>
>
> Let's call this one "B"
>
> This is used in a jndi *-ref element to locate the
> gbean for a j2ee component that we will call a method
> on to get the j2ee component (or a proxy to it) that
> we hand out to whatever is looking up in jndi.
>
> There are 2 differences:
>
> 1. A has minOccurs=0 on name, in B it is required.  I
> strongly suspect this is a bug in A and name should be
> required.  This is IMO minor.
>
> 2. A has a type element missing in B.  This is what
> Aaron is asking about.  This is a very problematic
> element.  Based on the element localName type, it
> could mean any of 3 things:
> - type of the geronimo module the target gbean is in.
> For a long time this had to be "car" and I'm not sure
> if this has changed.  There's certainly been some
> discussion in favor of changing that restriction.  At
> the moment I'm not in favor of changing it.
> - If the gbean is a j2ee component, it will be in a
> j2ee module, which means it's a j2ee component in a
> standalone module (ejb jar, war, or rar deployed into
> a car) or a module inside an ear.  This module will
> have a type (EJBModule, WebModule,
> ResourceAdapterModule).    Note that the "module"
> element will only be present if the gbean is in a j2ee
> module.  Currently there's a bug in that if you
> specify "module" you will never find the target gbean
> since it will have something like EJBModule=foo but we
> will look for J2EEModule=foo.
> - Every abstract name we construct has a j2eeType key.
>  type could refer to this.
>
> If you look at where the value of this element is
> used, it is used only in GBeanBuilder and it means the
> 3rd choice, j2eeType.  As such it is unnecessary in B
> since we know the j2eeType of the target gbean for
> jndi refs since it is determined by the kind of ref it
> is (ejb-ref, resource-ref, etc).  Also in B we can
> figure out the module type (as in the 2nd possibility)
> since an ejb will only be in an EJBModule, etc.
>
> ---------------
>
> proposal:
>
> We might be able to simplify this situation a little
> bit by:
> - To reduce duplication between similar elements, make
> the naming schema patternType a restriction of the
> module schema patternType, with type's maxOccurs=0.
> - To eliminate the bug in module schema when you
> specify the module, construct matching patterns using
> all possible module types (ServiceModule, EJBModule,
> WebModule, etc).  There might be a similar bug in the
> naming schema when looking for a resource-ref that is
> in fact implemented as a plain gbean such as the
> MailGBean or JAXR connection factory.  This needs more
> investigation.
> - Ignore/document the rather extreme ambiguity about
> the possible meaning of "type"  I really don't know
> what to do about this part.
>
> I'll try implementing these and see how far I get.
> Due to very limited internet access at the moment I
> probably won't have anything to report until at least
> tomorrow (may 27).  Comments and suggestions would be
> great.
>
> thanks
> david jencks
>
>
>
>
>