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.

Reply via email to