This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
It seems there're class-loading issues that prevent a NetBeans RCP application to invoke EJBs in Glassfish using RMI-IIOP (a simple standalone Java application connects correctly with the same code). I'm not sure if this is a problem in NetBeans class loaders or in Glassfish class loaders. Platform details: Product Version: NetBeans IDE 6.5 RC1 (Build 200810171318) Java: 1.6.0_10; Java HotSpot(TM) Client VM 11.0-b15 System: Linux version 2.6.24-19-generic running on i386; UTF-8; es_ES (nb) Userdir: /home/antonio/.netbeans/6.5rc1 Attachments that follow: - Exception stack trace detail. - Excerpt of the log with -Dorg.netbeans.ProxyClassLoader.level=FINE - Zipped source code with test case. (see "README.TXT")
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