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
