sounds good to me!
On Jan 7, 2008, at 8:36 AM, khudalla wrote:
Ok then!
From my point of view the main problem is the fact that the factory
property
of the ActiveMQConnectionFactory class is transient. Thus, if the
ActiveMQConnectionFactory gets serialized/deserialized in the
process of
binding/retrieving from/to JNDI (which glassfish obviously does), its
reference to the ActiveMQManagedConnectionFactory gets lost, i.e.
becomes
null.
As I have already written in my comment to JIRA issue AMQ-765 it is
not
sufficient to simply declare the factory property as not transient
since the
ActiveMQResourceAdapter referenced by the
ActiveMQManagedConnectionFactory
is not serializable when deployed to glassfish. This is because the
BootstrapContext implementation injected by glassfish is not
serializable
itself but gets stored in a property of the ActiveMQResourceAdapter.
My understanding is that the ActiveMQManagedConnectionFactory
contains the
reference to the resource adapter mainly in order to re-use its
makeConnection() methods for creating a physical connection to
ActiveMQ
(however, I do not really understand the meaning of the
ActiveMQResoureAdapter's connectionFactory property and its
corresponding
setter/getter since these are never used anywhere, can't we just get
rid of
them? The expensive operation seems to be creating the physical
connection
itself anyway, not instantiating the connection factory). My
suggestion now
is to refactor the makeConnection() methods of
ActiveMQResourceAdapter into
a base class that both ActiveMQResourceAdapter as well as
ActiveMQManagedConnectionFactory derive from and can thus use the
same code
for creating physical connections without the need for the reference
to the
resource adapter. Taking this a step further I would even suggest to
not
have ActiveMQManagedConnectionFactory implement the
ResourceAdapterAssociation interface at all. My understanding is
that this
is mainly used to copy the resource adapter configuration properties
specified during RA deployment to the
ActiveMQManagedConnectionFactory.
This, however, can also be achieved by just having
ActiveMQManagedConnectionFactory have the same properties (and then
some) as
the ActiveMQResourceAdapter. During deployment of the RA the
application
server will set the same property values on
ActiveMQManagedConnectionFactory
as it has set on ActiveMQResourceAdapter if they have the same
properties
declared in the ra.xml (at least this is my interpretation of the
JCA spec
regarding configuration/depoyment). Therefore, these properties
(along with
the ActiveMQConnectionRequestInfo property) could also be refactored
to the
base class.
Apart from the refactoring of the configuration properties I have
already
applied the suggested changes to my local copy of the source and have
successfully deployed and used the RA in glassfish v2 this way.
What do you think about this?
Regards,
Kai
rajdavies wrote:
please discuss it on the list kai
--
View this message in context:
http://www.nabble.com/NullPointerException-with-RA-on-Glassfish-tp4947362s2354p14660390.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
