Issue Details (XML | Word | Printable)

Key: GLASSFISH-3790
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Blocker Blocker
Assignee: Jagadish
Reporter: edwardchou
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
glassfish

Admin Console cannot load class when deploying Connector Module

Created: 21/Oct/07 05:46 PM   Updated: 18/Jan/10 10:20 PM   Resolved: 18/Jan/10 10:20 PM
Component/s: jca
Affects Version/s: 9.1pe
Fix Version/s: 9.1peur1

Time Tracking:
Not Specified

Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 3,790
Status Whiteboard:

91ur1Approved

Tags:
Participants: Anissa Lam, basler, edwardchou, Jagadish and Sivakumar Thyagarajan


 Description  « Hide

When deploying a Connector Module to Glassfish through Admin Console, it would
fail to configure the Connector Module because Admin Console is unable to load
class needed by Connector Module. Same deployment is successful when using
commandline "asadmin deploy <file_name>".

The reason is because for our Connector Module, we put the classes required by
Connector Module inside jars in "glassfish/domains/domain1/lib" directory.
This is legal, since this is the Commmon Classloader as defined by Glassfish
Classloader hierachy, Connector Module would delegate classloading to its
parent Classloader, which is the Common Classloader.

However, when Admin Console is deploying the Connector Module, after the first
deployment step, in the next step it would attempt to configure the resource-
adapter-class bean as defined in ra.xml of Connector Module. In order to do
this, Admin Console will try to load the this resource-adapter-class. However
Admin Console does not use the Glassfish Classloader hierachy to load the
class, instead it uses "com.sun.enterprise.connectors.util.RARUtils" to load
the class, and this helper class only tries to load from jars inside the
Connector Module archive and jars under "glassfish/lib" directory. It ignores
the "domain1/lib" directory, thus it would catch
java.lang.ClassNotFoundException at line 105 of RARUtils, and log a harmless
message in server.log such as

[#|2007-10-19T18:45:55.433-0700|INFO|sun-
appserver9.1|javax.enterprise.resource.resourceadapter|_ThreadID=20;_ThreadName=
httpWorkerThread-4848-
0;|com.stc.connector.framework.jca.system.STCResourceAdapter|#]

However, this would not work for us, since we would like to have the Admin
Console to deploy the Connector Module and configure the adapter-class. Admin
Console needs to use the same Classloading hierachy as Glassfih container to
try to load this adapter-class.



Anissa Lam added a comment - 21/Oct/07 09:53 PM

Thanks for the detailed description on what is the problem.
Transferring this bug to 'jca' as the class loading code is not in admin-gui module.


basler added a comment - 23/Oct/07 11:14 AM

Approved for check into the SJSAS91_UR1_BRANCH


Sivakumar Thyagarajan added a comment - 23/Oct/07 11:09 PM

"In order to do
this, Admin Console will try to load the this resource-adapter-class. However
Admin Console does not use the Glassfish Classloader hierachy to load the
class, instead it uses "com.sun.enterprise.connectors.util.RARUtils" to load
the class, and this helper class only tries to load from jars inside the
Connector Module archive and jars under "glassfish/lib" directory. It ignores
the "domain1/lib" directory, thus it would catch
java.lang.ClassNotFoundException at line 105 of RARUtils, and log a harmless
message in server.log such as "

This description of what is happening is correct and it is how RARUtils
currently behaves. As per section 17.2.0.1 of Connectors 1.5 spec, a portable,
modular stand-alone connector module should:
"The Java interfaces, implementation, and utility classes required by the
resource adapter must be packaged as one or more JAR files as part of the
resource adapter module. A JAR file must use the .jar file extension.
The platform-specific libraries required by the resource adapter must be
packaged with the resource adapter module."

Though I agree that RARUtils should use a classloader hierarchy that is similar
to the runtime classloader hierarchy of the standalone connector module, I don't
think such a deployment strategy [of having dependent libraries or the RA
implementation jar itself] in a separate location was ever supported or planned.

As of now, I am marking this bug as "invalid", because as I have explained
above, the use-case mentioned is not portable and hasn't been supported gfv1/v2
and AS8.x/9.x, and there are other portable alternatives that would work. Could
you let me know why you would like this scenario to be supported?


Sivakumar Thyagarajan added a comment - 23/Oct/07 11:11 PM

adding Jagadish to the bug interest list


edwardchou added a comment - 23/Oct/07 11:40 PM

In our Java CAPS product, we have 40+ different Resource Adapters, and they all
share some common libraries. We are trying to avoid having to package the same
common jars in each Resource Adapter, as this would help us to reduce the size
of each Resource Adapter, and make it easier to issue patches later.

We decided to put these common libraries in the "glassfish/domains/domain1/lib"
instead of "glassfish/lib" directory, because this would make clustering
possible.


Sivakumar Thyagarajan added a comment - 23/Oct/07 11:57 PM

Hi Edward

"We are trying to avoid having to package the same
common jars in each Resource Adapter, as this would help us to reduce the size
of each Resource Adapter, and make it easier to issue patches later."

Thanks. This is a good usecase and we tried to address this for web/ejb
applications in GlassFish via "application specific classloading"
http://docs.sun.com/app/docs/doc/819-3659/6n5s6m57l?a=view. This is, IIRC, not
supported today for standalone connector modules, but we can do something like
that to fix the issue, rather than depending on common classloader being
available. Do you agree?

"We decided to put these common libraries in the "glassfish/domains/domain1/lib"
instead of "glassfish/lib" directory, because this would make clustering"

Would glassfish/lib also work? Libraries in glassfish/lib would not loaded by
the system classloader but a "shared chain" classloader and RARUtils by default
creates a classloader with the system classloader as the parent, and therefore,
the libraries should be invisible to RARUtils.

Thanks
--Siva.


Sivakumar Thyagarajan added a comment - 26/Oct/07 01:40 AM

We shall fix this issue for 9.1 UR1 to handle such usecases. However please note
that this usecase is non-portable and may not work on other application servers.
I have also raised an RFE 3808 to add support for --libraries in standalone
connector modules.


Sivakumar Thyagarajan added a comment - 26/Oct/07 01:42 AM

Jagadish will check in the fix into UR1.


Sivakumar Thyagarajan added a comment - 30/Oct/07 08:38 PM

Sivakumar Thyagarajan added a comment - 30/Oct/07 08:39 PM

Jagadish added a comment - 18/Jan/10 10:20 PM

Evaluation for V3 :
Not applicable as the use-case works fine (taken care of) in v3.