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
groupIdconsole/groupId
artifactIdAnotherPool/artifactId
version1.0/version
typerar/type
nameMyPool/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 [EMAIL PROTECTED] 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:documentationThis 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