I am sorry, I guess I was not being clear. I thought you were asking
> my question is, if I need to construct a JBossMQ
> QueueConnectionFactory and load it into WebLogic's
> JNDI so I can drive a WebLogic MDB off a JBossMQ
> queue, how do I create it ?
I gave you the answer. You can create a JBossMQ QueueConnectionFactory by
putting the proper lines in your jboss.jcml. Jboss creates the
QueueConnectionFactory and registers it with it's registry.
> Hmmm..., what I am trying to do, is write a paper
> that
> describes how to load JMS connection factories (and
> JMS Destinations)into AppServer's JNDI. This is so
> they can be used for deploying and running MDBs. I
> am
> also attempting to write a framework which will
> allow
> developers to easily incoorporate JMS objects from
> any
> vendor.
>From your follow up, I thought you were asking is there any generic way to
create JMS ConnectionFactories, or at least to make them available from one
app server to another (presumably for loose coupling of objects across app
servers).
All that I am saying is that the JMS ConnectionFactories are vendor
specific. There is no defined constructor. So there is no generic way to
create a ConnectionFactory object. This is a common issue for code that uses
JDBC connections and JDBC connection pools. So in cases where you need a
common interface for managing, accessing, or creating JDBC pools, people can
use the Data Accessor pattern. If you want a common object that can handle
the vendor specific instantiation of ConnectionFactories, then you might
find this pattern a helpful starting point.
As for the serialization of the ConnectionFactory, I guess I was being
ambiguous by stating that you cannot serialize the ConnectionFactory. You
can serialize the ConnectionFactory administrative object. But the actual
factory that makes the connections may or may not be serialized--it too is
implementation specific. The ConnectionFactory administrative object that
you retrieve out of the JNDI tree is analogous to the javax.sql.Datasource
object. It contains the data to fetch a connection for you. It may create a
new connection, it may access a connection pool, it may contact a remote
connection factory.
In any case, The point is that if you take a ConnectionFactory object from
one App Servers registry and register it with another, you are only
guaranteed to have two copies of the ConnectionFactory. This may or may not
give you the behavior you are looking for.
For instance, in the Case of the Joram JMS server with the Jonas EJB server,
Joram can live in the same JVM as Jonas. It creates a ConnectionFactory
object and registers it with the local Registry. The ConnectionFactory
object contains data to utilize the Joram connection factory which lives in
the Joram JVM and creates and pools connections. If you serialize the
ConnectionFactory object and put it another registry, you now have two
copies of an object that will utilize the same connection factory object
maintained in the Joram JVM. For example, if you start up another Jonas EJB
server and copy over the ConnectionFactory object to it, both of the
ConnectionFactories will utilize the connection factory in the original JVM
that is running Joram. So if you shutdown the first JVM, your second will
now have a ConnectionFactory that will no longer be able to fetch new
connections. So, in this case, you cannot serialize the connection factory
that the ConnectionFactories depend upon. It is compliant with the JMS
specifications. It is just something that you have to be aware of.
I hope that you find what information I am able to provide helpful, and I
hope that I have clarified any ambiguities,
Lucas McGregor, NovaLogic.
-----Original Message-----
From: Nicholas [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 25, 2002 3:35 PM
To: Lucas McGregor
Cc: [EMAIL PROTECTED]
Subject: RE: [JBoss-user] Constructor for JBossMQ ConnectionFactories
Lucas;
Just for the record, WebLogic to JBossMQ is not a
specific scenario I am trying to support, but rather
it is an example of a generic scenario I am trying to
support in my framework.
I see your points, but it is common and supported
practice to serialize ConnectionFactory objects into
JNDI. The factory is static and should be configured
to produce connections that are valid ("conectable")
assuming that the JMS server they are configured to
connect to is up and running. The location of the JNDI
where the ConnectionFactory should be irrelevant.
To further this point, see the Java Doc for the parent
class fo QueueConnectionFactory
(javax.jms.ConnectionFactory) at
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/ConnectionFactory.ht
ml
Quotes:
1.A ConnectionFactory object encapsulates a set of
connection configuration parameters that has been
defined by an administrator. A client uses it to
create a connection with a JMS provider.
2. A ConnectionFactory object is a JMS administered
object.
3. Although the interfaces for administered objects do
not explicitly depend on the Java Naming and Directory
Interface (JNDI) API, the JMS API establishes the
convention that JMS clients find administered objects
by looking them up in a JNDI namespace.
In summary, for a compliant JMS server, I believe that
you shoudl be able to acquire a QueueConnectionFactory
(either by construction one, as in my SonicExample,
or by looking it up in the JMS server's own JNDI) and
serialize into another JNDI (say an LDAP server).
Subsequent retrievals of the newly serialized
QueueConnectionFactory will deliver an object that
should yield up valid connections to the orogonal JMS
server that the QueueConnectionFactory was configured
to attach to.
At least, it works that way with:
MQSeries
WebLogic
SonicMQ
Fiorano
iBus
(Working on more.....)
//Nicholas
--- Lucas McGregor <[EMAIL PROTECTED]> wrote:
> So you want to access a Jboss QueueConnectionFactory
> from weblogic.
>
> Just to make sure that I am being clear on the
> subject (warning, I might
> sound resundant :-), you cannot serialize a
> QueueConnectionFactory. What is
> serialized and registered in the JNDI tree is a
> handle to the connection
> factory. This is analogous to a JDBC connection
> pools, you get access to
> them via a handle object, a DataSource.
>
> You can take the reference to the handle object from
> the Jboss JNDI registry
> and register it to the JNDI tree that weblogic is
> accessing. Now you have
> two JNDI tree's, each with a reference to a
> QueueConnectionFactory that is
> living in the Jboss JVM. Thus, if you shut down the
> Jboss JVM, you will have
> stale references in your weblogic JNDI tree. So, by
> serializing the
> ConnectionFactory, you are just copying the
> reference to the
> QueueConnectionFactory, not the actual factory.
>
> Jboss' QueueConnectionFactory is a MBean that Jboss
> loads in response to
> lines in your jboss.jcml file.
>
> The QueueConnectionFactory API defines no
> constructors,
>
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/QueueConnectionFacto
> ry.html
> It is up to the vendor to create
> QueueConnectionFactory as they see fit.
> They just have to implement the two
> createQueueConnection() methods.
>
> How app servers deal with JMS is very similar to how
> they deal with JDBC.
> The actual connections and connection pools are up
> to the app server and the
> driver vendor. How your EJB's (MDB's) interact with
> JMS is defined by the
> EJB 2.0 standard, but how each vendor implements the
> creation and management
> of the resource is not--just like how entity beans
> are bound to
> javax.sql.DataSource resources is defined by the EJB
> spec, but how your app
> server configures, manages, and runs the JDBC
> connections that the
> javax.sql.DataSource represent is not defined.
>
> The Sun J2EE Pattern Catalog (requires registration,
> but it's free) has a
> Data Accessor Object
>
pattern(http://developer.java.sun.com/developer/restricted/patterns/DataAcce
> ssObject.html). It is used to isolate the
> differences between DataSource
> implementations. maybe you could adapt it to isolate
> differences in JMS
> implementations. They might have other patterns in
> the JDBC arena that might
> be helpful.
>
> http://www.theserverside.com/ has had a lot about
> JMS and MDB's in the last
> couple of months, maybe that have something that
> will help your with your
> abstraction layer.
>
> Good Luck!
> Lucas McGregor, NovaLogic
>
>
>
> -----Original Message-----
> From: Nicholas [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 25, 2002 2:23 PM
> To: Lucas McGregor
> Subject: RE: [JBoss-user] Constructor for JBossMQ
> ConnectionFactories
>
>
> Hmmm..., what I am trying to do, is write a paper
> that
> describes how to load JMS connection factories (and
> JMS Destinations)into AppServer's JNDI. This is so
> they can be used for deploying and running MDBs. I
> am
> also attempting to write a framework which will
> allow
> developers to easily incoorporate JMS objects from
> any
> vendor.
>
> So for example, and SonicMQ QueueConnectionFactory
> can
> be constructed as follows:
>
> QueueConnectionFactory qcf = new
> QueueConnectionFactory(host, port, protocol,
> username,
> password);
>
> The resulting object is then serialized into JNDI.
>
> So, my question is, if I need to construct a JBossMQ
> QueueConnectionFactory and load it into WebLogic's
> JNDI so I can drive a WebLogic MDB off a JBossMQ
> queue, how do I create it ? Perhaps I should simply
> encpasulate the retrieval of the factory from an
> instance of JBoss and then serialize into the
> applicable counterpart's JNDI......
>
> Thanks for the response.
>
> //Nicholas
> --- Lucas McGregor <[EMAIL PROTECTED]> wrote:
> > I am not sure that this is what you are asking,
> but
> > the JMS connection
> > factory is application specific. Meaning that each
> > app server will construct
> > it's JMS connections and infrastructure
> differently.
> >
> >
> > In Jboss, you configure the connection factories
> in
> > the jboss.jcml and Jboss
> > creates them.
> >
> > ---- start jboss.jcml snippet ----
> >
> >
> > <!-- InvocationLayers are the different
> transport
> > methods that can be used
> > to access the server -->
> > <mbean
> > code="org.jboss.mq.il.jvm.JVMServerILService"
> > name="JBossMQ:service=InvocationLayer,type=JVM">
> > <attribute
> >
>
name="ConnectionFactoryJNDIRef">java:/ConnectionFactory</attribute>
> > <attribute
> >
>
name="XAConnectionFactoryJNDIRef">java:/XAConnectionFactory</attribute>
> > </mbean>
> >
> > <mbean
> > code="org.jboss.mq.il.rmi.RMIServerILService"
> > name="JBossMQ:service=InvocationLayer,type=RMI">
> > <attribute
> >
>
name="ConnectionFactoryJNDIRef">RMIConnectionFactory</attribute>
> > <attribute
> >
>
name="XAConnectionFactoryJNDIRef">RMIXAConnectionFactory</attribute>
> > </mbean>
> >
> > <mbean
> > code="org.jboss.mq.il.oil.OILServerILService"
> > name="JBossMQ:service=InvocationLayer,type=OIL">
> > <attribute
> >
>
name="ConnectionFactoryJNDIRef">ConnectionFactory</attribute>
> > <attribute
> >
>
name="XAConnectionFactoryJNDIRef">XAConnectionFactory</attribute>
> > </mbean>
> >
> > <mbean
> > code="org.jboss.mq.il.uil.UILServerILService"
> > name="JBossMQ:service=InvocationLayer,type=UIL">
> > <attribute
> >
>
name="ConnectionFactoryJNDIRef">UILConnectionFactory</attribute>
> > <attribute
> >
>
name="XAConnectionFactoryJNDIRef">UILXAConnectionFactory</attribute>
> > </mbean>
> >
> > ---- end jboss.jcml snippet ------
> >
> > This will create four different connection
> > factories: one that is
> > for only internal JVM access, one for RMI access,
> > one for Jboss' OIL
> > protocol, and one for Jboss' UIL protocol. All of
> > these impelement the
> > javax.jms.Connectionfactor interface. They will
> give
> > you access to the Jboss
> > specific connection which implements
> > javax.jms.Connection and will know how
> > to access the Jboss specific ConnectionFactories.
>
=== message truncated ===
=====
Nicholas Whitehead
Home: (973) 377 9335
Cell: (201) 615 2716
Work(@ JP Morgan): (212) 235 5783
[EMAIL PROTECTED]
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
