geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Re: Schema duplication/inconsistency in patternType
Date Fri, 26 May 2006 18:24:01 GMT
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:

 - contains DB Pool "MyPool"

 - contains DB Pool "MyPool"

 - contains a thread pool "MyPool"

 - 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:

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.


On 5/26/06, David Jencks <> 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

View raw message