You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Aaron Mulder <am...@alumni.princeton.edu> on 2005/06/16 03:32:59 UTC
JMS References
Well, I thought we just worked this out on IRC, but now I'm not
convinced. So I'm going to try to restate the situation here, and point
out a few problems. David J, please take a close look at this, but
everyone's input is welcome.
Scenario:
- 1 connector (ActiveMQ)
- 2 instances (let's say "vanilla" and "priority")
- 2 admin objects (let's say "topic" and "queue")
common ActiveMQ RAR: ra.xml
- declares ActiveMQ RA, including outbound-RA
- declares Topics and Queues as available admin objects
standalone: my-destinations.xml (a geronimo-connector_1_5.xsd document)
- points to the above RAR
- declares outbound instance "vanilla" (pool size 5)
- declares outbound instance "priority" (pool size 100)
- declares Topic "topic", with PhysicalName "SomeTopic"
- declares Queue "queue", with PhysicalName "SomeQueue"
EJB JAR: ejb-jar.xml
- declares session bean "MyService"
- includes resource-ref "vanillaconnection"
- includes resource-ref "priorityconnection"
- includes message-destination-ref "ejb-topic"
- includes message-destination-link "topic"
- includes message-destination-ref "ejb-queue"
- NO message-destination-link
- declares message-driven bean "TopicMDB"
- includes message-destination-link "topic"
- declares message-driven bean "QueueMDB"
- delares that it requires a javax.jms.Queue
- NO message-destination-link
- declares message-destination "topic"
- implicitly mapped to the named admin object "topic"
- declares message-destination "queue"
- implicitly mapped to the named admin object "queue"
--------------
Alright, here's where we stand, as far as I can tell:
- No JMS stuff should be working!
- MyService/ejb-topic is mapped to an admin object
- MyService/ejb-queue is not mapped to an admin object
- MyService/vanillaconnection is not mapped to an RA
- MyService/priorityconnection is not mapped to an RA
(since neither connection factory is mapped, it doesn't matter
whether the destination refs are mapped, since there's nothing
to connect to)
- TopicMDB is mapped to an admin object with no RA
- QueueMDB is not mapped to an admin object and also has no RA
(since neither MDB is mapped to an RA there's nothing to connect
to to get messages yet)
- The missing links must be resolved in openejb-jar.xml
--------------
EJB JAR: openejb-jar.xml
- Session Bean "MyService"
- Reference "ejb-topic" is already mapped to an admin object; nothing
is required here
- Reference "ejb-queue" cannot be mapped to admin object
- There are no elements available to resolve a
message-destination-ref!
- Reference "vanillaconnection" is mapped to the "vanilla" RA instance
- Reference "priorityconnection" is mapped to the "priority" RA
- MDB "TopicMDB"
- This MDB is mapped to the "priority" RA instance
- There is no need to identify an admin object, since the link in
ejb-jar.xml linked this to "topic"
- MDB "QueueMDB"
- This MDB is mapped to the "vanilla" RA instance
- It is not possible to identify an admin object for this EJB!
- Destination "topic" and destination "queue" cannot be resolved or
overridden here. They either match based on the name provided in
ejb-jar.xml, or things get hairy.
--------------
So it looks like the session bean stuff is broken in that it's not
possible to point a message-destination-ref to an admin object
(Destination). I think we should provide a message-destination-ref in the
geronimo-naming schema, and include it in the
openejb-jndiEnvironmentRefsGroup in the OpenEJB schema -- and it should
have the same content as the resource-env-ref type. There is a workaround
(use the resource-env-ref instead of message-destination-ref in
ejb-jar.xml in the first place), but as far as I can tell it's possible
that a valid ejb-jar.xml (message-destination-ref with no
message-destination-link) will not be able to be deployed in Geronimo.
It looks like the MDB stuff is broken in that it's not possible to point
an MDB to an admin object if that was left out of ejb-jar.xml (if there
was no message-destination-link). Perhaps the idea is to include the
destination name in the activation-config properties? But if so, what
happens if the value in there contradicts the message-destination-link
(both of which may be specified in ejb-jar.xml)? Perhaps the MDB data
should include an optional message-destination element with contents that
are the same as the resource-env-ref, in case no destination was selected
in ejb-jar.xml?
Finally, it's still possible that there's a "topic" admin object defined
in more than one place (in the current app as well as at the top level, or
at the top level in two different RA deployment plans, or whatever,
pointing to two diferent PhysicalName destinations). If that is the case,
there's no way to narrow down which "topic" admin object (and this which
physical topic) is referred to by the "topic" message-destination named in
ejb-jar.xml. Likewise, if two EJB JARs both name a message-destination
called "topic", there's no way to force them to point to two different
physical topics (we'll try to map them both to a single admin object). I
think it would be valuable to allow you to resolve a message-destination
in openejb-jar.xml, again using the same content as a resource-env-ref.
I'm happy to enter JIRA issues for these, but I'd like someone to look
over this whole thing and let me know if there's something I'm overlooking
or whatever.
Thanks,
Aaron
Re: JMS References
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Shoot, I think I got one thing backward. It looks like ActiveMQ
requires a destionation name and destination type for its ActivationSpec,
which means an MDB will always need to specify its destination name and
type in either the ejb-jar.xml or the openejb-jar.xml. So I should have
phrased my second problem all the way at the bottom as "what happens if
you specify a message-destination-link in your message-driven
configuration? Is it just ignored? Or do we 'magically' pass that data
through to the correct fields of the ActiveMQ ActivationSpec?"
Thanks,
Aaron
On Wed, 15 Jun 2005, Aaron Mulder wrote:
> Well, I thought we just worked this out on IRC, but now I'm not
> convinced. So I'm going to try to restate the situation here, and point
> out a few problems. David J, please take a close look at this, but
> everyone's input is welcome.
>
> Scenario:
> - 1 connector (ActiveMQ)
> - 2 instances (let's say "vanilla" and "priority")
> - 2 admin objects (let's say "topic" and "queue")
>
> common ActiveMQ RAR: ra.xml
> - declares ActiveMQ RA, including outbound-RA
> - declares Topics and Queues as available admin objects
>
> standalone: my-destinations.xml (a geronimo-connector_1_5.xsd document)
> - points to the above RAR
> - declares outbound instance "vanilla" (pool size 5)
> - declares outbound instance "priority" (pool size 100)
> - declares Topic "topic", with PhysicalName "SomeTopic"
> - declares Queue "queue", with PhysicalName "SomeQueue"
>
> EJB JAR: ejb-jar.xml
> - declares session bean "MyService"
> - includes resource-ref "vanillaconnection"
> - includes resource-ref "priorityconnection"
> - includes message-destination-ref "ejb-topic"
> - includes message-destination-link "topic"
> - includes message-destination-ref "ejb-queue"
> - NO message-destination-link
> - declares message-driven bean "TopicMDB"
> - includes message-destination-link "topic"
> - declares message-driven bean "QueueMDB"
> - delares that it requires a javax.jms.Queue
> - NO message-destination-link
> - declares message-destination "topic"
> - implicitly mapped to the named admin object "topic"
> - declares message-destination "queue"
> - implicitly mapped to the named admin object "queue"
>
> --------------
> Alright, here's where we stand, as far as I can tell:
> - No JMS stuff should be working!
> - MyService/ejb-topic is mapped to an admin object
> - MyService/ejb-queue is not mapped to an admin object
> - MyService/vanillaconnection is not mapped to an RA
> - MyService/priorityconnection is not mapped to an RA
> (since neither connection factory is mapped, it doesn't matter
> whether the destination refs are mapped, since there's nothing
> to connect to)
> - TopicMDB is mapped to an admin object with no RA
> - QueueMDB is not mapped to an admin object and also has no RA
> (since neither MDB is mapped to an RA there's nothing to connect
> to to get messages yet)
> - The missing links must be resolved in openejb-jar.xml
> --------------
>
> EJB JAR: openejb-jar.xml
> - Session Bean "MyService"
> - Reference "ejb-topic" is already mapped to an admin object; nothing
> is required here
> - Reference "ejb-queue" cannot be mapped to admin object
> - There are no elements available to resolve a
> message-destination-ref!
> - Reference "vanillaconnection" is mapped to the "vanilla" RA instance
> - Reference "priorityconnection" is mapped to the "priority" RA
> - MDB "TopicMDB"
> - This MDB is mapped to the "priority" RA instance
> - There is no need to identify an admin object, since the link in
> ejb-jar.xml linked this to "topic"
> - MDB "QueueMDB"
> - This MDB is mapped to the "vanilla" RA instance
> - It is not possible to identify an admin object for this EJB!
> - Destination "topic" and destination "queue" cannot be resolved or
> overridden here. They either match based on the name provided in
> ejb-jar.xml, or things get hairy.
>
> --------------
>
> So it looks like the session bean stuff is broken in that it's not
> possible to point a message-destination-ref to an admin object
> (Destination). I think we should provide a message-destination-ref in the
> geronimo-naming schema, and include it in the
> openejb-jndiEnvironmentRefsGroup in the OpenEJB schema -- and it should
> have the same content as the resource-env-ref type. There is a workaround
> (use the resource-env-ref instead of message-destination-ref in
> ejb-jar.xml in the first place), but as far as I can tell it's possible
> that a valid ejb-jar.xml (message-destination-ref with no
> message-destination-link) will not be able to be deployed in Geronimo.
>
> It looks like the MDB stuff is broken in that it's not possible to point
> an MDB to an admin object if that was left out of ejb-jar.xml (if there
> was no message-destination-link). Perhaps the idea is to include the
> destination name in the activation-config properties? But if so, what
> happens if the value in there contradicts the message-destination-link
> (both of which may be specified in ejb-jar.xml)? Perhaps the MDB data
> should include an optional message-destination element with contents that
> are the same as the resource-env-ref, in case no destination was selected
> in ejb-jar.xml?
>
> Finally, it's still possible that there's a "topic" admin object defined
> in more than one place (in the current app as well as at the top level, or
> at the top level in two different RA deployment plans, or whatever,
> pointing to two diferent PhysicalName destinations). If that is the case,
> there's no way to narrow down which "topic" admin object (and this which
> physical topic) is referred to by the "topic" message-destination named in
> ejb-jar.xml. Likewise, if two EJB JARs both name a message-destination
> called "topic", there's no way to force them to point to two different
> physical topics (we'll try to map them both to a single admin object). I
> think it would be valuable to allow you to resolve a message-destination
> in openejb-jar.xml, again using the same content as a resource-env-ref.
>
> I'm happy to enter JIRA issues for these, but I'd like someone to look
> over this whole thing and let me know if there's something I'm overlooking
> or whatever.
>
> Thanks,
> Aaron
>