users@glassfish.java.net

Re: Can I inject a JCA Connection Factory?

From: Sivakumar Thyagarajan <Sivakumar.Thyagarajan_at_Sun.COM>
Date: Fri, 12 Oct 2007 13:24:23 +0530

glassfish_at_javadesktop.org wrote:
> Yes, my reference adapter holds a reference to the BootstrapContext that was
> passed to it via the start method. This is because it needs the contained
> WorkManager to schedule work related to inbound event processing. Now, from what
> I can see, the WorkManager implementation
> (com.sun.enterprise.connectors.work.CommonWorkManager) is not Serializable
> either. So I can't hold a reference to the WorkManager in place of the
> BootstrapContext. I could define the variable as transient, but can I be
> guaranteed that, when the object is restored, the start method will be called
> again. I can only assume that the RA you're testing with does not hold a
> reference to the BootstrapContext or a WorkManager. Not having access to the
> WorkManager is not acceptable in my case, and there's nowhere I can see that I
> will be guaranteed an instance should it be serialized out due to being a
> transient variable.

I think we now understand the real issue. Thanks for all the helpful comments. I
see that you are trying to get access to the WorkManager via the
BootStrapContext in your CF.

Unfortunately the Connector spec does not mandate that the BootStrapContext and
WorkManager implementations to be serializable and hence GlassFish does not
implement Serializable for these implementations. My guess is that this usecase
[outbound communication implementations using WorkManager] was probably
overlooked. For inbound there is no issue, none of those artifacts are
serialized by the container.

However, having said that, atleast in GlassFish, we would love to support this.
Could you raise a jca issue in GlassFish issue tracker for this? However, please
note that this usage may not be portable across other containers, because they
might not have serializable BSC and WM implementations.

Until we fix this in GlassFish, could you use the following "temporary"
workaround for now:
- As you have probably found out, and also pointed to by Jagadish, when the
resource reference is called as "eis/Foo", there is no copy of the CF instance
in the Naming subsytem and you wouldn't hit this issue.

>
> In my mind, the isConnection is the core problem here. The application, in
> this case, does not need to use the name to ascertain the type of reference. The
> type will provide exactly what the component is. This is acceptable for JDBC
> resources. The code does not check the name syntax for JDBC or JMS resources.

In NamingManagerImpl, binding a resource that is not prefix with "eis" results
in it being bounded as a MUTABLE wrapper.

During lookup, a copy of the object is made for all MUTABLE wrapper objects and
hence we have this issue.

> This whole bug would have been avoided if the same existing functionality was
> applied to ConnectionFactory objects as well.

I agree since "eis" prefix is just a recommendation, marking all
non-"eis"/JDBC/JMS resources as MUTABLE is incorrect. I shall let the Naming
subsystem engineer, Sheetal [copied], respond on the reasons of why this is done
and whether this can be changed, as I am not a Naming expert.

However once we fix BSC and WM to be serializable, a non-"eis" resource being
set as MUTABLE and a copy being made, would not affect a resource adapter.

Thanks for all your support and hope the temporary workaround works for you.

Thanks
--Siva.

> From ResourceReferenceDescriptor...
>
> // start IASRI 4734197
> /**
> * @return true if the resource is a jdbc DataSource object.
> */
> public boolean isJDBCResource() {
> return this.getType().equals(JDBC_RESOURCE_TYPE);
> }
>
> public boolean isJMSConnectionFactory() {
> String myType = this.getType();
> return
> ( myType.equals("javax.jms.QueueConnectionFactory") ||
> myType.equals("javax.jms.TopicConnectionFactory") );
> }
>
>
> and later on in the file
>
> //START OF IASRI 4633229
> /**
> * Return true if this resource is a CCI connection factory.
> * @return true if the resource is a CCI connection factory, false
> * otherwise.
> */
> public boolean isResourceConnectionFactory () {
> return this.getType().equals(CONNECTOR_RESOURCE_TYPE);
> }
> //END OF IASRI 4633229
>
> So, there are two checks the code can make
>
> if (next.isResourceConnectionFactory() || isConnector(logicalJndiName)) {
>
> With this simple change, the chances improve of the app server knowing with what it is working.
>
> This, to me, makes it much less reliant on naming standards. Helping apply the same standards to CCI Factories that are already applied to other resources.
>
> I will admit, did not read that document. I can't even find that developer's manual when coming from the glassfish site (it may be one of the 20 documents there, but I can't say for sure The developer's guide available from the Glassfish site doesn't match the link you've provided).
> [Message sent by forum member 'hildo' (hildo)]
>
> http://forums.java.net/jive/thread.jspa?messageID=239625
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>