JSLEE Discussions
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
SBB Classloader and System classpath - Rhino 2.1
Forum Index » Rhino SLEE Discussions
Author Message
phil.dunks


Joined: 06/05/2009 21:31:55
Messages: 12
Location: Brighton, UK.
Offline

Hi

I have added a jar to the system classpath (at the call to com.opencloud.rhino.tools.StartRhinoProcess in start-rhino.sh).

However, my SBB gets a ClassNotFoundException as follows :
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)

I'm thinking this could be a security issue, and I need to grant permission to my SBB (??).

I've added ..
<security-permissions>
<security-permission-spec>
grant { permission java.security.AllPermission; };
</security-permission-spec>
</security-permissions>

.. to sbb-jar.xml, but still no luck.

Any clues would be much appreciated.

Thanks,

Phil.





[WWW]
bsd

[Avatar]

Joined: 22/03/2008 00:37:15
Messages: 355
Location: Cambridge, UK
Offline

Hi Phil,

You should only need to change the runtime classpath and the startup scripts when adding support for a database. In this case you change the "read-config-variables" file by adding the jar to the runtime classpath property and granting permissions to that library in the file rhino.policy. Have a look at the databases configuration.

The SDK Java process boot classloader is not added to the runtime classpath property when starting the Rhino SLEE process. Adding that new jar to the boot classloader has no effect. To make it work you can add the property "-Drhino.runtime.classpath" with that library to the startup command.

Note that you should use the production version of Rhino if you have access to it.

Last but not least, you should not be doing anything of this if not configuring a database. :) Any library should be deployed as a JSLEE Library jar. This allows you to install your app with all the dependencies without having to change the SLEE configuration.

Bruno

Bruno Duarte
Technical Consultant
OpenCloud
[Email] [WWW]
phil.dunks


Joined: 06/05/2009 21:31:55
Messages: 12
Location: Brighton, UK.
Offline

Hi Bruno

Thanks for this.

Yes, I am currently installing a production Rhino node.

I initially deployed as a JSLEE library jar, but had class loader (I think) problems.

The issue is not with locating the classes in the library jar.

But when invoking them (they are Web Beans classes), the dependency injection fails, because the Web Beans reflection process cannot locate classes that are deployed in the same JSLEE library - eeek!!.

So I wanted to at least prove the concept that Web Beans can work in Rhino by putting everything on the system classpath, before I entered the class loader minefield.

Do you know if anybody has yet successfully used Web Beans DI in Rhino?

Thanks

Phil



[WWW]
bsd

[Avatar]

Joined: 22/03/2008 00:37:15
Messages: 355
Location: Cambridge, UK
Offline

Hi Phil,

I've seen reports in the past about using Spring for dependency injection but never with Web Beans.

The integration issues are usually related with the classloader and the security manager. Most frameworks tend to use the context classloader which in JSLEE has no meaning. Therefore, to workarround this problem you need to set the default classloader on the framework (if possible) or set and unset the context classloader when the framework tries to access it. Regarding the permissions, you can add them using the security permissions descriptor's configuration of the JSLEE components.

The above should be possible from a library and should work on any JSLEE compliant container. You shouldn't have the need to hack Rhino's classpaths.

Bruno

Bruno Duarte
Technical Consultant
OpenCloud
[Email] [WWW]
phil.dunks


Joined: 06/05/2009 21:31:55
Messages: 12
Location: Brighton, UK.
Offline


Hi Bruno

Ok thanks.

Actually I tried to hack the classpath (ie. update read-config-variables, and rhino-policy) but this also didn't work on production version as well as SDK.
Same symptoms - my SBB had no visibility of the classes in the jars I defined. Would you expect SBBs to see these classes, or only RAs?

Anyway, I am now trying to deploy as a library again, and set the classloader as you suggest.

However, not having much luck.

Our library larger than before - I realised I was missing some dependencies. This time rhino gave the error ...

Caused by: com.opencloud.transaction.TransientRollbackException: Unable to prepare due to size limits of the DB
at com.opencloud.ob.Rhino.rI.commit(18504:108)
at com.opencloud.ob.Rhino.nt.commit(18504:151)
at com.opencloud.ob.Rhino.im.c(18504:44)


So I searched your site, and found some information at..

https://developer.opencloud.com/devportal/display/OCDEV/Deployment+problem+on+exceeding+DB+size

And hacked rhino-config.xml as it instructs, and set all database <committed-size> values to 500M.

But now I get the following exception when I try to deploy.

2009-06-15 14:37:45.343 WARN [rhino.management.deployment] <RMI TCP Connection(2)-192.168.45.49> Installation of deployable unit failed: javax.slee.management.ManagementException: I/O error
at com.opencloud.ob.Rhino.eX.a(18504:149)
at com.opencloud.ob.Rhino.aa.a(18504:24)
at com.opencloud.ob.Rhino.aa.a(18504:16)
at com.opencloud.ob.Rhino.nu$a.b(18504:183)
at com.opencloud.ob.Rhino.bM$a$a.b(18504:749)
at com.opencloud.ob.Rhino.bM$a.e(18504:483)
at com.opencloud.ob.Rhino.bM$a.a(18504:232)
at com.opencloud.ob.Rhino.bM.b(18504:103)
at com.opencloud.rhino.management.deployment.Deployment.a(18504:234)
at com.opencloud.rhino.management.deployment.Deployment.install(18504:160)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.opencloud.rhino.management.DynamicMBeanSupport.doInvoke(18504:159)
at com.opencloud.rhino.management.DynamicMBeanSupport$a.run(18504:119)
at java.security.AccessController.doPrivileged(Native Method)
at com.opencloud.rhino.management.DynamicMBeanSupport.invoke(18504:111)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1426)
at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72)
at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1264)
at java.security.AccessController.doPrivileged(Native Method)
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1366)
at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:637)
Caused by: java.io.FileNotFoundException: unit1245073059091/null
at com.opencloud.ob.Rhino.eX.a(18504:271)
at com.opencloud.ob.Rhino.eX.a(18504:143)



It looks like my changes to rhino-config.xml did have some effect (from rhino-stats) ...



MemDB-Replicated.ManagementDatab
time churn cleanups csize max
----------------------- --------------------------------
2009-06-15 14:35:11.824 - - - -
2009-06-15 14:35:12.822 0 1 34578 51200


MemDB-Replicated.ManagementDatab
time churn cleanups csize max
----------------------- --------------------------------
2009-06-15 14:48:25.875 - - - -
2009-06-15 14:48:26.874 0 1 34578 512000


Any help much appreciated.

Thanks
Phil

[WWW]
bsd

[Avatar]

Joined: 22/03/2008 00:37:15
Messages: 355
Location: Cambridge, UK
Offline

Hi Phil,

At the moment there is a bug on Rhino and it doesn't log the correct error message if a DU has a library with a wrong jar name and has other types of components on the same DU (like an SBB).

If deploying a DU with only the library you should get the following error message:
javax.slee.management.DeploymentException: Error(s) in deployable unit:
Verification error(s) in one or more components in my-library.jar:
Library jar BANG!! not found in library component jar my-library.jar


When deploying with other components, you get the following message:
javax.slee.management.ManagementException: I/O error
Caused by: java.io.FileNotFoundException: unit1239114708157/null


Can you please confirm that the descriptor of you library has a wrong jar name?

Bruno

Bruno Duarte
Technical Consultant
OpenCloud
[Email] [WWW]
phil.dunks


Joined: 06/05/2009 21:31:55
Messages: 12
Location: Brighton, UK.
Offline


Hi Bruno

Think I've found the issue.

The error seemed to come after sbb verification...

2009-06-15 16:51:31.529 INFO [rhino.management.deployment] <RMI TCP Connection(14)-192.168.45.49> Installing deployable unit from URL file:dist/cie.du.jar
2009-06-15 16:51:32.756 INFO [rhino.management.deployment] <RMI TCP Connection(14)-192.168.45.49> Installing: cie.du.jar
2009-06-15 16:51:34.987 INFO [rhino.management.deployment] <RMI TCP Connection(14)-192.168.45.49> Parsing library deployment descriptor in netdev-cie2-library.jar
2009-06-15 16:51:35.008 INFO [rhino.management.deployment] <RMI TCP Connection(14)-192.168.45.49> Parsing sbb deployment descriptor in netdev-cie2-inap-sbb.jar
2009-06-15 16:51:35.012 INFO [rhino.management.deployment] <RMI TCP Connection(14)-192.168.45.49> Parsing service deployment descriptor in service.xml
2009-06-15 16:51:35.012 INFO [rhino.management.deployment] <RMI TCP Connection(14)-192.168.45.49> Verifying library component definitions in netdev-cie2-library.jar
2009-06-15 16:51:39.053 INFO [rhino.management.deployment] <RMI TCP Connection(14)-192.168.45.49> Verifying sbb component definitions in netdev-cie2-inap-sbb.jar
2009-06-15 16:51:39.075 WARN [rhino.management.deployment] <RMI TCP Connection(14)-192.168.45.49> Installation of deployable unit failed: javax.slee.management.ManagementException: I/O error
at com.opencloud.ob.Rhino.eX.a(18504:149)


But actually the problem was a mismatch (underscore vs hyphen) between one of the (recently added) library content jars actual name, and the name defined in <jar><jar-name> element in library-jar.xml

Cheers
Phil

[WWW]
bsd

[Avatar]

Joined: 22/03/2008 00:37:15
Messages: 355
Location: Cambridge, UK
Offline

When installing a DU, each verification phase checks the various components jars.

In your case:
Check deployment descriptors
- Check library
- Check SBB
- Check Service
Verify component's definition
- Check library
- Check SBB
Install component, compile code and add classes and jars to runtime environemnt
- Install library (FAIL)
- Install SBB
etc...

Therefore, the issue is really when installing the library and adding that specific jar to the library runtime environment.

Bruno Duarte
Technical Consultant
OpenCloud
[Email] [WWW]
phil.dunks


Joined: 06/05/2009 21:31:55
Messages: 12
Location: Brighton, UK.
Offline


Hi Bruno

Making some progress now !!

Web Beans is working (deployed in JSLEE library in same DU as SBB).

Setting classloader as you suggested. Doing this in SBB before invoking web beans, as follows :

Thread.currentThread( ).setContextClassLoader( getClass().getClassLoader( ) );

Do I really need to unset this, or will the SLEE simply ignore ContextClassLoader anyway?

If I do need to unset it, do I just set it to null ?

Thanks
Phil
[WWW]
bsd

[Avatar]

Joined: 22/03/2008 00:37:15
Messages: 355
Location: Cambridge, UK
Offline

Happy to know that this is working properly. :) Now the bad news...

The JSLEE spec only allows resource adaptors to set the context classloader. Therefore, if the framework requires to set the context classloader (does it?) you should consider integrating it in the SLEE with a custom resource adaptor.

The disadvantage is the bigger integration effort required. The advantages can be various: do not break any restrictions of the JSLEE spec and ensure it will work in any complaint SLEE, unify the integration and the use of the framework between different SBBs and create a more powerful integration.

If you're still not convinced or want to prototype a bit more the integration with directly from the SBB, you should:
- set the context classloader back to the original one as soon as the framework doesn't require it anymore (the SBB object should retain at "all" time the normal classloader)
- make sure you are initializing the framework in the correct way (check the SBB lifecycle carefully)
- make sure you catch all exceptions when performing operations with the different classloader and set it back to the original if something fails (if rolling back the transaction the classloader of the thread should be original one)

Bruno

Bruno Duarte
Technical Consultant
OpenCloud
[Email] [WWW]
phil.dunks


Joined: 06/05/2009 21:31:55
Messages: 12
Location: Brighton, UK.
Offline


Hi Bruno.
Yes, we may need an RA for other reasons as well for this deployment (we may need to access a web service).
We were trying to avoid an RA this time, because as you say, the additional development and integration overhead, but also the maintenance. We are currently supporting applications with four different versions of javax.slee.resource.ResourceAdaptor, which we developed to the current SLEE versions as the specification developed over the last four years. Customers with stable deployments are reluctant to upgrade their application unless they really have to, as they see no direct benefit.
I realise the 1.1 spec is now stable, so hopefully we should start seeing some of the benefits you mention.
Thanks for all your help.
Best Regards
Phil
[WWW]
bsd

[Avatar]

Joined: 22/03/2008 00:37:15
Messages: 355
Location: Cambridge, UK
Offline

Yes, unfortunately JSLEE 1.1 took too long to be completed. On the other hand, it is a very well written spec that will be applicable for a couple of years and current SLEE containers can "easily" be upgraded to v1.1

By the way, which Web Beans framework are you integrating with?

Bruno Duarte
Technical Consultant
OpenCloud
[Email] [WWW]
phil.dunks


Joined: 06/05/2009 21:31:55
Messages: 12
Location: Brighton, UK.
Offline

Hi Bruno

The spec is here:
http://docs.jboss.org/webbeans/spec/PRD2/JSR-299-PRD2.pdf

The RI documentation is here :
http://www.tardis.ed.ac.uk/~pmuir/webbeans/reference/1.0.0.PREVIEW1/en-US/pdf/webbeans_reference.pdf
http://www.tardis.ed.ac.uk/~pmuir/webbeans/reference/1.0.0.PREVIEW1/en-US/html/

Cheers
Phil

[WWW]
 
Forum Index » Rhino SLEE Discussions
Go to:   
Powered by JForum 2.1.8 © JForum Team