Created attachment 72652 [details]
Stack trace detail, showing chain of class loaders

Created attachment 72653 [details]
Excerpt of log with class-loading debugging info (gzip)

Created attachment 72654 [details]
Test Case (see README.txt) for details

The problem does not happen if EJB classes are bundled within the same Library Wrapper Module as the Glassfish jars.

I wonder if this is a problem with glassfish' "makeClass" method:

	at com.sun.corba.ee.impl.codegen.CodeGeneratorUtil.makeClass(CodeGeneratorUtil.java:95)
	at com.sun.corba.ee.spi.codegen.Wrapper._generate(Wrapper.java:1051)
	at com.sun.ejb.EJBUtils$2.run(EJBUtils.java:537)

That is possibly generating the class on the fly.

With core-main #b52a46c4455a, NB will report the problem more usefully:

java.lang.ClassNotFoundException: com.sun.ejb.containers.GenericEJBHome
        at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
        at org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java:254)
Caused: java.lang.ClassNotFoundException: com.sun.ejb.containers.GenericEJBHome starting from
org.netbeans.StandardModule$OneModuleClassLoader@1f88fbd[net.antonioshome.rcp.ear1] with possible defining loaders
[org.netbeans.StandardModule$OneModuleClassLoader@f70ee1[net.antonioshome.rcp.glassfish]] and declared parents []
        at org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java:256)
[....]

(Note that you will get nicer stack traces if you simply use Exceptions.printStackTrace.)

Solution on your side is to make net.antonioshome.rcp.ear1 depend on net.antonioshome.rcp.glassfish (rather than the
other way around, which makes little sense to me). Then you get a different problem:

java.lang.ClassNotFoundException: com.sun.ejb.codegen.GenericEJBHome_Generated starting from
org.netbeans.StandardModule$OneModuleClassLoader@8d0b0f[net.antonioshome.rcp.ear1] with possible defining loaders
[org.netbeans.StandardModule$OneModuleClassLoader@6937f9[net.antonioshome.rcp.glassfish]] and declared parents
[org.netbeans.StandardModule$OneModuleClassLoader@6937f9[net.antonioshome.rcp.glassfish]]
        at org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java:256)

which I presume is some kind of problem in the Glassfish libraries I can hardly debug further, as I am not familiar with
them nor how their dynamic class generation is intended to work. Generally speaking such bugs arise from code which
incorrectly assumes it is running in an environment containing only one ClassLoader for both infrastructure and user
classes.

Hi Jesse,

Thanks for your comment and for taking a look at this. The fact is that I think it's the dependencies!

- Glassfish libraries need to know about EJB Interface classes (in order to create stubs/skeletons for remote objects).
- Stubs and skeletons, in turn, require glassfish libraries to be instantiated.

That's probably the reason why the program works if EJB interfaces and Glassfish libraries coexist inside a module.

The solution for ease of packaging and deployment could be to try to separate glassfish libraries in separate jars, and
then packaging those in different NetBeans modules.

I may investigate this (will post here my findings).

"Glassfish libraries need to know about EJB Interface classes (in order to create stubs/skeletons for remote objects)" -
well, they need to be able to _load_ these classes. That is very different from referring to them statically, which they
certainly could not (GF code was not compiled against your EJBs). If the GF code is unable to find your EJB classes when
it has no ClassLoader dependency on them, that could mean that it is incorrectly calling e.g. Class.forName(String)
rather than Class.forName(String,boolean,ClassLoader).

Integrated into 'main-golden', will be available in build *200810280201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/b52a46c4455a
User: Jesse Glick <jglick@netbeans.org>
Log: Better diagnostics for CNFEs as in #151368.

Hi,

Some news on this:

1.- I think this is duplicate of http://www.netbeans.org/issues/show_bug.cgi?id=125107

On that bug they solved the problem by adding all jar files (including EJB stuff) into the system classpath.

2.- It used to work in NB 5.5:

http://www.nabble.com/can't-access-ejbs-after-switching--to-netbeans-6.0-platform-td14731157.html

3.- Tried out with new dependencies:

[EJB1->GLASSFISH LIBRARY WRAPPER]

Exception is: 
ADVERTENCIA [javax.enterprise.resource.corba.ee._CORBA_.util]: "IOP01211405: (BAD_OPERATION) Exception in loadStub"
java.lang.ClassNotFoundException: com.sun.ejb.codegen.GenericEJBHome_Generated
        at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)

The "com.sun.ejb.codegen.GenericEJBHome_Generated" is a class that glassfish builds "on the fly" using BCEL.

Maybe NetBeans class loaders are refusing to load classes generated with BCEL? I wonder if any changes to classloaders
between 5.5 and 6.X avoid NetBeans to load generated classes?

Thanks,
Antonio

Hi,

I'm still working on this. Please let me know if it's not appropriate to post my findings here.

I've hacked com.sun.ejb.EJBUtils from glassfish, adding some traces:

----
      ClassLoader loader =
              getBusinessIntfClassLoader(businessInterface);

      Class genericEJBHome = loadGeneratedGenericEJBHomeClass(loader);

      final Object genericHomeObj =
              PortableRemoteObject.narrow(jndiObj, genericEJBHome);

      System.err.println("CLASS LOADER IS: " + loader );
      System.err.println("JNDI OBJ IS: " + jndiObj );
      System.err.println("JNDI OBJ CL: " + jndiObj.getClass().getClassLoader() );
      System.err.println("GENERIC EJB HOME IS : " + genericEJBHome );
      System.err.println("GENERIC CL: " + genericEJBHome.getClassLoader() );
      System.err.println("GENERIC HOME OBJ IS: " + genericHomeObj );
----

Traces are:

----
CLASS LOADER IS: org.netbeans.StandardModule$OneModuleClassLoader@3da850[net.antonioshome.rcp.ear1]
JNDI OBJ IS:
IOR:0000000000000042524d493a636f6d2e73756e2e656a622e636f646567656e2e47656e65726963454a42486f6d655f47656e6572617465643a303030303030303030303030303030300000000000000100000000000001f4000102000000000a3132372e302e312e31000e74000000d2afabcb00000000260000006400000009533141532d4f5242000000000000000300000008526f6f74504f41000000003023494e5445524e414c235265666572656e6365466163746f72794d616e616765724261736523494e5445524e414c23000000005938303239333837393632363938393536385f52427573696e6573735f6e65742e616e746f6e696f73686f6d652e7365727665722e656a62732e5f53696d706c65454a4252656d6f74655f52656d6f74652d454a42486f6d65000000000000000d011d42dbacce000000000001ff14000000000007000000010000002000000000000100010000000205010001000100200001010900000001000101000000002600000002000200000000000300000014000000000000000a3132372e302e312e31000eec0000000300000014000000000000000a3132372e302e312e31000f500000001f00000004000000030000002000000004000000010000002100000078000000000000000100000000000000240000001c0000006600000000000000010000000a3132372e302e312e31000eec00400000000000080606678102010101000000170401000806066781020101010000000764656661756c74000400000000000000000000010000000806066781020101010000000f
JNDI OBJ CL: org.netbeans.StandardModule$OneModuleClassLoader@423d4f[net.antonioshome.rcp.glassfish]
GENERIC EJB HOME IS : interface com.sun.ejb.codegen.GenericEJBHome_Generated
GENERIC CL: org.netbeans.StandardModule$OneModuleClassLoader@3da850[net.antonioshome.rcp.ear1]
GENERIC HOME OBJ IS: null
----

So the basic problem seems to be PortableRemoteObject.narrow returning null.

Note that the two objects being passed to PortableRemoteObject.narrow come from different class loaders 
(the first being from net.antonioshome.rcp.glassfish and the second being net.antonioshome.rcp.ear1)
maybe that's why PortableRemoteObject.narrow is unable to work.

Solution is, as stated previously, to bundle EJB classes and Glassfish classes in the same module, so that
PortableRemoteObject.narrow works properly.

Hi again,

The problem is with glassfish EJBUtils class. I'm attaching a patch for that class (binary & source code).

To solve the problem:

1.- Create a Glassfish Library Wrapper with the following jars, in this order (order is important for the patch to
work). Order is defined in the "nbproject/project.xml" file inside this Glassfish Library Wrapper.

  - APPSSERVRT.jar (the patch, attached to this issue report)
  - javaee.jar
  - appserv-rt.jar
  - appserv-deployment-client.jar
  - appserv-ext.jar

2.- Create dependencies between your EJB Library Wrapper to Glassfish Library Wrapper.

Things should be working now. You can now deploy independently your EJB Library Wrappers and your Glassfish Library
Wrapper (so whenever your EJB interfaces change you only have to update your EJB Library Wrappers, etc.).

3.- Create your normal modules as usual, and add dependencies to EJB Library Wrappers and to Glassfish Library Wrappers.

Created attachment 72778 [details]
Tar-gz of the patch for glassfish (NetBeans Project, binaries and sources)

A binary patch is nice as a workaround but I do not see an actual patch (i.e. diff), or even comments indicating what
was changed, and your version of the class is rather different from that in

http://fisheye4.atlassian.com/browse/~raw,r=17529/glassfish-svn/trunk/v2/appserv-core/src/java/com/sun/ejb/EJBUtils.java

and

http://fisheye4.atlassian.com/browse/~raw,r=20211/glassfish-svn/trunk/v3/ejb/ejb-container/src/main/java/com/sun/ejb/EJBUtils.java

If you believe this class is at fault, please file a patch on glassfish.dev.java.net (and CC jglick too).

Jesse,

Regarding the patch: I'm working it out, cleaning up stuff and the such. I'll post a complete test case here as soon as
I have some spare time.

Jay,
You may need to physically remove com/sun/ejb/EJBUtils.* from appserv-rt.jar in the glassfish library wrapper. It seems
the ordering in project.xml has nothing to do with the real order.

Both:

The second test case is working ok with NB 6.5RC1 and Glassfish v2UR2.

Cheers,
Antonio

Created

https://glassfish.dev.java.net/issues/show_bug.cgi?id=6655

(I can't CC jclick there, sorry by that).

Created attachment 72797 [details]
New test case with cleaner code and diff patch (tar.gz)

This issue had *1 votes* before move to platform component

*** Bug 125107 has been marked as a duplicate of this bug. ***

Hi,

My project is stopped because of this problem, I have talked with other users in the list that has the same problem with their projects.

This stop Netbeans Platforms Applications from being clients of Glassfish.

Please see:
https://netbeans.org/bugzilla/show_bug.cgi?id=125107

There is also a bug report in Glassfish:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=6655


Change EJB for web services is not a good option for me, to much problems with JAXB serialization (cycled many-to-many relationships) and dupplication of model for example.

I don't want to get back to JEE 5 either.

What can we do to help?

rgds.
xavier

Reassigning to David. I am not much involved to this issue.

The conclusion I came to is that this is GF classloader problem. For more details see my last comment in issue 125107. In that sense this issue is WORKSFORME but in order to verify it the GF issue has to be fixed first. I will comment in GF issue as well.

Hi,

Yes, the patch for Glassfishv2 at https://glassfish.dev.java.net/issues/show_bug.cgi?id=6655 confirms that Glassfish is using the "wrong" classloader.

The method "generateAndLoad" at http://fisheye4.atlassian.com/browse/~raw,r=17529/glassfish-svn/trunk/v2/appserv-core/src/java/com/sun/ejb/EJBUtils.java is passed a ClassLoader as the second argument. If you ignore this classloader and use protectionDomainBase.getClassLoader() instead then things work.

The patch I posted at https://glassfish.dev.java.net/nonav/issues/showattachment.cgi/2023/patch.diff does exactly this, and as far as I can tell nothing is broken.

When developing with the NetBeans Platform you separate classes in modules, with independent class loaders. The home and remote interfaces of EJBs are usually packaged in a module (classloader), that depends on glassfish and J2EE binaries (packaged in a separate module, i.e, separate classloader). From the home and remote interfaces you can "see" J2EE binaries, but the opposite is usually wrong (i.e., from EJBUtils.class.getClassLoader() you won't "see" the home or remote interfaces).

Let me know if I can be of any further help on this.

Cheers,
Antonio

Antonio,

Hi, I'm a Glassfish v3 user.

How can I use your patch for GFv3? do I need to recompile GF3 completely?

I really need to fix this to be able to continue working in our project.

David, thank you to you too, thank you all for your support.

rgds.
xavier

Hi Xavier,

I haven't looked at glassfish v3 yet. If I have some time I may go take a look at it and I'll try to get a patch for it too.

Cheers,
Antonio

Antonio,

As my project is a brand new project, I think is a good idea and would love to start developing it in Glassfish v3 from scratch.

For now I am trying to continue in Glassfish v3 using JAX-WS web services, but the resulting jaxb model is very limited (a lot of problem with cycling) comparated with jpa (with EJB I would manage JPA in server/client).

As I don't know how much time it will take to fix this issue in Glassfish v3, would you advice me to go back to GF 2.1 ?

Thank you.

xavier.

Hi Xavier,

I downloaded and tried out Glassfish v3, but I couldn't create a standalone client. I'd appreciate you sending me the list of jars you use to create a standalone client, or are you using an appclient?

Thanks,
Antonio

Antonio,

Glassfish v3.0 works as expected with stand-alone java clients, as it is explained here:

https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html#StandaloneRemoteEJB

You need to include the gf-client.jar in your client.


Maybe you can also try to call a EJB from a Netbeans Platform Application, witch is the problem.

Here is documented how to cal a EJB from a Netbeans Platform Application:

http://wiki.netbeans.org/DevFaqCallEjbFromNbm

But do not work with Glassfish v3.0

Thank you and rgds.
xavier

Hi again,

I've tried out with standalone client and I got it running in a standalone application.

When running from witihin NB 6.8 I get:

java.lang.NullPointerException
        at com.sun.enterprise.naming.impl.SerialContext.getRemoteProvider(SerialContext.java:297)
        at com.sun.enterprise.naming.impl.SerialContext.getProvider(SerialContext.java:271)
Caused: javax.naming.NamingException: Unable to acquire SerialContextProvider for SerialContext  [Root exception is java.lang.NullPointerException]
        at com.sun.enterprise.naming.impl.SerialContext.getProvider(SerialContext.java:276)
        at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:430)
Caused: javax.naming.NamingException: Lookup failed for 'a.b.c/SimpleBeanRemote' in SerialContext  [Root exception is javax.naming.NamingException: Unable to acquire SerialContextProvider for SerialContext  [Root exception is java.lang.NullPointerException]]
        at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:442)


I tried out with java:comp/env/ejb/a.b.c.SimpleBeanRemote as well, without success.

A quick google search shows many people is having this issue:

http://www.google.es/search?q=com.sun.enterprise.naming.impl.SerialContext.getRemoteProvider%28SerialContext.java%3A297%29

So I'd close this until this is solved somehow in the Glassfish side.

Hi all,

Yes, remote calls to Glassfish v3 from within a NB RCP application using a standalone client (i.e, without an application container) are possible and seem to work well.

This requires patching EJBUtils.java again in Glassfish v3.

From
https://glassfish-svn.dev.java.net/source/browse/glassfish-svn/trunk/v3/ejb/ejb-container/src/main/java/com/sun/ejb/EJBUtils.java?rev=35461&view=markup

The change is in line 592

From

return  _generate(loader, protectionDomainBase.getProtectionDomain(),

To

return  _generate(protectionDomainBase.getClassLoader(), protectionDomainBase.getProtectionDomain(),

I'll post more details during the weekend.

Note: The test I'm running requires 46Mb of Glassfish jar files (don't know if all of them are required, though)!

Antonio,

Can you provide a binary of the jar with the patched EJBUtils.java of GF3?


Thank you!!!

Created attachment 94346 [details]
Recompiled EJBUtils.java

Remove com.sun.ejb.EJBUtils**.class from the original Glassfish v3 ejb-container.jar and add this new JAR file to your classpath.

Antonio, you are a genius!!! it is working! your patch worked, now I can call a EJB from NB Platform App. I haven't tested yet a lot, but it seems that it fixed the problem.

Thank you very much!

I hope this fix completely the problem and that GF team merge it to upstream ASAP.

My best regards.

This is to inform that there's some activity on the glassfish side, at:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=6655

Glassfish guys are requesting just another "simple" test case, and I won't generate another one, so I'm marking this issue as resolved incomplete.

Hi Antonio,

I am under way to patch Glassfish v3.0.1 to be used with your patch and therefore I have tried to change the source of glassfish. But I am getting now always the message "NO PERMISSION". Do you know if it is enough to change the described lines in EJBUtils.java or is there since 3.0.1 more ?

The stacktrace is the following:
INFO [javax.enterprise.resource.jta.com.sun.enterprise.transaction]: Using com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate as the delegate
SEVERE [at.itarchitects.wist.dclient.servercom.ServerCommunication]: Lookup failed for 'RLogin' in SerialContext targetHost=localhost,targetPort=23782,orb'sInitialHost=localhost,orb'sInitialPort=3700
org.omg.CORBA.NO_PERMISSION: ----------BEGIN server-side stack trace----------
org.omg.CORBA.NO_PERMISSION:   vmcid: 0x0  minor code: 0  completed: No
        at com.sun.enterprise.iiop.security.SecServerRequestInterceptor.receive_request(SecServerRequestInterceptor.java:583)
        at com.sun.corba.ee.impl.interceptors.InterceptorInvoker.invokeServerInterceptorIntermediatePoint(InterceptorInvoker.java:654)
        at com.sun.corba.ee.impl.interceptors.PIHandlerImpl.invokeServerPIIntermediatePoint(PIHandlerImpl.java:752)
        at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.getServantWithPI(CorbaServerRequestDispatcherImpl.java:395)
        at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:213)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1841)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1695)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:1078)
        at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:221)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:797)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:561)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2558)
        at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:492)
        at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:528)

----------END server-side stack trace----------  vmcid: 0x0  minor code: 0  completed: No
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at com.sun.corba.ee.impl.protocol.giopmsgheaders.MessageBase.getSystemException(MessageBase.java:913)
        at com.sun.corba.ee.impl.protocol.giopmsgheaders.ReplyMessage_1_2.getSystemException(ReplyMessage_1_2.java:129)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.getSystemExceptionReply(CorbaMessageMediatorImpl.java:681)
        at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.processResponse(CorbaClientRequestDispatcherImpl.java:510)
        at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete(CorbaClientRequestDispatcherImpl.java:369)
        at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:235)
        at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:187)
Caused: java.rmi.AccessException: CORBA NO_PERMISSION 0 No; nested exception is: 
        org.omg.CORBA.NO_PERMISSION: ----------BEGIN server-side stack trace----------
org.omg.CORBA.NO_PERMISSION:   vmcid: 0x0  minor code: 0  completed: No
        at com.sun.enterprise.iiop.security.SecServerRequestInterceptor.receive_request(SecServerRequestInterceptor.java:583)
        at com.sun.corba.ee.impl.interceptors.InterceptorInvoker.invokeServerInterceptorIntermediatePoint(InterceptorInvoker.java:654)
        at com.sun.corba.ee.impl.interceptors.PIHandlerImpl.invokeServerPIIntermediatePoint(PIHandlerImpl.java:752)
        at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.getServantWithPI(CorbaServerRequestDispatcherImpl.java:395)
        at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:213)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1841)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1695)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:1078)
        at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:221)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:797)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:561)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2558)
        at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:492)
        at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:528)

----------END server-side stack trace----------  vmcid: 0x0  minor code: 0  completed: No
        at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:276)
        at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:200)
        at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:147)
        at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:225)
        at com.sun.ejb.codegen._GenericEJBHome_Generated_DynamicStub.create(com/sun/ejb/codegen/_GenericEJBHome_Generated_DynamicStub.java)
        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.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:418)
Caused: javax.naming.NamingException: ejb ref resolution error for remote business interfaceat.itarchitects.wist.server.ejb.LoginBeanRemote [Root exception is java.rmi.AccessException: CORBA NO_PERMISSION 0 No; nested exception is: 
        org.omg.CORBA.NO_PERMISSION: ----------BEGIN server-side stack trace----------
org.omg.CORBA.NO_PERMISSION:   vmcid: 0x0  minor code: 0  completed: No
        at com.sun.enterprise.iiop.security.SecServerRequestInterceptor.receive_request(SecServerRequestInterceptor.java:583)
        at com.sun.corba.ee.impl.interceptors.InterceptorInvoker.invokeServerInterceptorIntermediatePoint(InterceptorInvoker.java:654)
        at com.sun.corba.ee.impl.interceptors.PIHandlerImpl.invokeServerPIIntermediatePoint(PIHandlerImpl.java:752)
        at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.getServantWithPI(CorbaServerRequestDispatcherImpl.java:395)
        at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:213)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1841)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1695)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:1078)
        at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:221)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:797)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:561)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2558)
        at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:492)
        at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:528)

----------END server-side stack trace----------  vmcid: 0x0  minor code: 0  completed: No]
        at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:430)
        at com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:70)
        at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
        at com.sun.enterprise.naming.impl.SerialContext.getObjectInstance(SerialContext.java:472)
        at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:437)
Caused: javax.naming.NamingException: Lookup failed for 'RLogin' in SerialContext targetHost=localhost,targetPort=23782,orb'sInitialHost=localhost,orb'sInitialPort=3700 [Root exception is javax.naming.NamingException: ejb ref resolution error for remote business interfaceat.itarchitects.wist.server.ejb.LoginBeanRemote [Root exception is java.rmi.AccessException: CORBA NO_PERMISSION 0 No; nested exception is: 
        org.omg.CORBA.NO_PERMISSION: ----------BEGIN server-side stack trace----------
org.omg.CORBA.NO_PERMISSION:   vmcid: 0x0  minor code: 0  completed: No
        at com.sun.enterprise.iiop.security.SecServerRequestInterceptor.receive_request(SecServerRequestInterceptor.java:583)
        at com.sun.corba.ee.impl.interceptors.InterceptorInvoker.invokeServerInterceptorIntermediatePoint(InterceptorInvoker.java:654)
        at com.sun.corba.ee.impl.interceptors.PIHandlerImpl.invokeServerPIIntermediatePoint(PIHandlerImpl.java:752)
        at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.getServantWithPI(CorbaServerRequestDispatcherImpl.java:395)
        at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:213)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1841)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1695)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:1078)
        at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:221)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:797)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:561)
        at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2558)
        at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:492)
        at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:528)

----------END server-side stack trace----------  vmcid: 0x0  minor code: 0  completed: No]]
        at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:442)
        at javax.naming.InitialContext.lookup(InitialContext.java:392)
        at at.itarchitects.wist.dclient.servercom.ServerCommunication.login(ServerCommunication.java:66)
        at at.itarchitects.wist.dclient.access.util.LoginWorker.doInBackground(LoginWorker.java:51)
        at at.itarchitects.wist.dclient.access.util.LoginWorker.doInBackground(LoginWorker.java:26)
        at javax.swing.SwingWorker$1.call(SwingWorker.java:277)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at javax.swing.SwingWorker.run(SwingWorker.java:316)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[catch] at java.lang.Thread.run(Thread.java:637)

Hi,

I'm sorry I haven't tried with latest glassfish releases. Since glassfish guys are unable to find a link in a web page, I'm dropping glassfish in favor of some open source servers, so I don't think I can patch 3.0.1 in the near future.

The "patch" I proposed applies only to the client-side "EJBUtils.java", so you don't need to modify the server-side stuff.

I'd try with the precompiled EJBUtils.class (GF3.0) attached to this issue, and see how things go in 3.0.1.

Anyway my personal recommendation would be to drop glassfish in favor of some other rich-client friendly app server.

Cheers,
Antonio

Hi,

I'm using Glassfish 3.0.1 as EJB server for my NBP application using the patch from Antonio.

What I do is to replace the files:

/com/sun/ejb/EJBUtils$1.class
/com/sun/ejb/EJBUtils$2.class
/com/sun/ejb/EJBUtils$3.class
/com/sun/ejb/EJBUtils$4.class
/com/sun/ejb/EJBUtils$5.class
/com/sun/ejb/EJBUtils$6.class
/com/sun/ejb/EJBUtils.class

in the ejb-container.jar from Glassfish with the ones of Antonio's binary patch.

This is the only way I can use Glassfish 3.x in my enterprise application NBP application client.

I have been waiting for Glassfish to incorporate this patch in the official release, for me as for everyone that wants to use NBP as enterprise client this is a showstopper.

Thank you and regards.
xavier

Antonio,

what are the alternatives to glassfish opensource ?
Or what would you suggest for usage with nb rcp?

Clemens
(In reply to comment #36)
> Hi,
> 
> I'm sorry I haven't tried with latest glassfish releases. Since glassfish guys
> are unable to find a link in a web page, I'm dropping glassfish in favor of
> some open source servers, so I don't think I can patch 3.0.1 in the near
> future.
> 
> The "patch" I proposed applies only to the client-side "EJBUtils.java", so you
> don't need to modify the server-side stuff.
> 
> I'd try with the precompiled EJBUtils.class (GF3.0) attached to this issue, and
> see how things go in 3.0.1.
> 
> Anyway my personal recommendation would be to drop glassfish in favor of some
> other rich-client friendly app server.
> 
> Cheers,
> Antonio

Created attachment 100344 [details]
Replacement ejb-container.jar

This is the version which works for 3.0.1 as a standalone client and is a complete re-compile of the original sources including Antonios patch.

The patch is working but there are some additional todo's:
- Copy all jars which are listed in the MANIFEST.MF inside gf-client.jar to your module
- patch MANIFEST.MF so that gf-client.jar can load additional classes (the manifest includes some hardcoded glassfish directories)
- Add the switch to your netbeans platform config: J-Xmx512m

With this changes all is working. What I do not have tests are JMS things.

This brings me to the conclusion that glassfish is working with standalone clients but it is at least an investment of 1 day to get things working.

I will use it now during the development phase but hopefully in the end there is an replacement which:
- Is working out of the box with netbeans rcp
- Has a smaller footprint (63 MB is too huge)
- J2EE 6 complient
- Opensource

Clemens

(In reply to comment #40)
> The patch is working but there are some additional todo's:
> - Copy all jars which are listed in the MANIFEST.MF inside gf-client.jar to
> your module
> - patch MANIFEST.MF so that gf-client.jar can load additional classes (the
> manifest includes some hardcoded glassfish directories)

or you could use '.../glassfish/bin/package-appclient' to easy packing the needed jars.

> - Has a smaller footprint (63 MB is too huge)

the generated '.../glassfish/lib/appclient.jar' would have ~40M. Indeed is to much for me that for the moment only need to make EJB calls.

But for now, I'm sticking with GF3, I hope the team could improve theses problems ASAP.

Thank you GF team.

rgds.
xavier