I've modified the DestinationMarshaller,
DefaultDestinationMarshaller, and
DefaultClusterFactory to use "Session.createTopic(String
destinationName)"
instead of "new ActiveMQTopic(String destinationName)". This will
work
with ActiveMQ, SonicMQ, Tibco, and probably most other vendors.
Since DestinationMarshaller.getDestination(String name) is called
on every
heartbeat message, and most JMS implementations (ActiveMQ excluded)
perform
a remote call to create a new Destination, I've also added a lookup
cache
of name->destination mappings in DefaultDestinationMarshaller, and
changed
the interface definition to throw a JMSException.
Since Weblogic (and perhaps others) may use JNDI lookups or other
mechanism
to do name->Destination mappings, I've modified the
DefaultClusterFactory,
making the protected createCluster method that takes a Connection and
Session object to be public. This way you can create the
Connection and
Session objects prior to creating your DestinationMarshaller object.
(See attached file: DestinationMarshaller.java)(See attached file:
DefaultClusterFactory.java)(See attached file:
DefaultDestinationMarshaller.java)
I had to modify the unit tests slightly to throw the new
JMSException, and
to provide a Session object to the DefaultDestinationMarshaller
constructor. Once modified, all the unit tests ran successfully.
Does this sound like a workable solution? Should I give up on a
cross-vendor implementation, and write my own ClusterFactory and
Marshaller
implementations? (in hindsight, it would have been simpler ;-)
Thanks,
Ben
|---------+---------------------------->
| | James Strachan |
| | <[EMAIL PROTECTED]|
| | mail.com> |
| | |
| | 03/01/2006 01:55 |
| | PM |
| | Please respond to|
| | user |
| | |
|---------+---------------------------->
---------------------------------------------------------------------
---------------------------------------------------------|
|
|
| To:
[EMAIL PROTECTED]
|
| cc: activemq-
[email protected]
|
| Subject: Re: [activecluster-user] ActiveCluster move to
ActiveMQ |
---------------------------------------------------------------------
---------------------------------------------------------|
On 1 Mar 2006, at 18:16, [EMAIL PROTECTED] wrote:
Unfortunately, activecluster-4.0-M4 is dependent on activemq-core,
so it
can't be used easily with another JMS provider.
Depending on classes inside activemq-core.jar != not working with
another JMS provider :)
The DefaultClusterFactory class depends on
org.apache.activemq.util.IdGenerator. That seems like a simple
dependency
to remove (maybe use Jakarta Commons Id package?).
Maybe we should just copy that one class across.
Not so obvious is an issue where the DestinationMarshaller
interface is
required to create a Destination from a String. Creating a
destination for
most JMS vendors requires access to the Session object (e.g.
Session.createTopic(String name)), which is encapsulated in the
DefaultClusterFactory class. How would I create a destination in
my own
marshaller implementation, with no access to the Session object? The
DefaultDestinationMarshaller implementation creates a new
ActiveMQTopic
object, which obviously only works in ActiveMQ....
We could just use a dummy Destination object for now that gets
serialised?
So, if I tweak the DefaultClusterFactory class, changing the
protected
createCluster method to public, then I can easily write my own
DestinationMarshaller, and the code is truly independent of ActiveMQ.
Is anyone else interested in using ActiveCluster with a JMS
provider other
than ActiveMQ?
Sure - supporting any JMS is a good thing.
Any plans to make ActiveCluster a top-level Geronimo
project, and not just a subcomponent of ActiveMQ?
We'll see what happens with Geronimo / WADI / ActiveMQ. It might make
sense as a module in Geronimo or in ActiveMQ. Am not sure if its big
enough to be a top level project
James
-------
http://radio.weblogs.com/0112098/
This communication is for informational purposes only. It is not
intended
as an offer or solicitation for the purchase or sale of any financial
instrument or as an official confirmation of any transaction. All
market prices,
data and other information are not warranted as to completeness or
accuracy and
are subject to change without notice. Any comments or statements
made herein
do not necessarily reflect those of JPMorgan Chase & Co., its
subsidiaries
and affiliates.
