Hello Tim,
thanks for the quick reply.
[quote=tjquinn]
Hello, Stephan.
Which JAR contains the class in the exception? You could try deploying the
EAR using the asadmin command line utility and specifying --compatibility=v2
[/quote]
The class in the exception is contained in JAR file sprint-ejbClient.jar. I
tried to deploy the EAR file from the command line with "asadmin deploy", but
it does not recognize the option "--compatibility=v2":
C:\Users\stm>C:\glassfishv3\bin\asadmin.bat deploy --compatibility=v2
C:\Users\stm\tmp\sprint-ear.ear Invalid option: --compatibility=v2 Usage:
asadmin [asadmin-utility-options] deploy [--virtualservers
<virtual_servers>] [--contextroot <context_root>]
[--force[=<force(default:false)>]]
[--precompilejsp[=<precompilejsp(default:false)>]]
[--verify[=<verify(default:false)>]] [--name <component_name>]
[--upload[=<upload(default:false)>]] [--retrieve <local_dirpath>]
[--dbvendorname <dbvendorname>]
[--createtables[=createtables(default:false)>] |
--dropandcreatetables[=<dropandcreatetables(default:false)>]]
[--uniquetablenames[=<uniquetablenames(default:false)>]]
[--deploymentplan <deployment_plan>] [--enabled[=<enabled(default:true)>]]
[--generatermistubs[=<generatermistubs(default:false)>]]
[--libraries jar_file[,jar_file*]] [--type <pkg-type>]
[--properties (name=value)[:name=value]*]
[-?|--help[=<help(defalt:false)>]] file_archive | filepath
C:\Users\stm>C:\glassfishv3\bin\asadmin.bat --compatibility=v2 deploy
C:\Users\stm\tmp\sprint-ear.ear Invalid option: --compatibility=v2 Usage:
asadmin [-H|--host <host(default:localhost)>] [-p|--port
<port(default:4848)>] [-u|--user <user(default:admin)>]
[-W|--passwordfile <passwordfile>]
[-t|--terse[=<terse(default:false)>]]
[-s|--secure[=<secure(default:false)>]]
[-e|--echo[=<echo(default:false)>]]
[-I|--interactive[=<interactive(default:true)>]]
[-?|--help[=<help(default:false)>]] [subcommand [options] [operands]]
[quote=tjquinn] This might help because the Java EE 6 spec is much stricter
than Java EE 5 about which JARs in an EAR each module is allowed to see.
GlassFish 3 implements Java EE 6 so it enforces the tighter restrictions by
default. Normally an app client will be able to access any JAR listed in the
app client JAR's manifest Class-Path plus any JARs in the EAR's library
directory (/lib by default). The added option uses the older behavior that
does not comply with the more restrictive rules in Java EE 6. Naturally, if
this proves to be the problem then I'd suggest that you revise your
application so it complies with these new Java EE 6 rules, primarily so you
won't need to remember to deploy it with the added option. (By the way, in v2
an app client was allowed to access any EJB JAR as well as any JAR at the top
level of the EAR.) Hope that helps. - Tim [/quote] I read the J2EE 6
specification about the Class-Path, and I added the sprint-ejbClient.jar file
containing the remote interface to the Class-Path entry in the manifest file.
This had an effect,and now I'm getting a different error:
Caused by: javax.naming.NamingException: Lookup failed for
'com.pluginsmithy.sprint.ejb.PrintScheduleBeanRemote#com.pluginsmithy.sprint.ejb.PrintScheduleBeanRemote'
in SerialContext
targetHost=localhost,targetPort=3700,orb'sInitialHost=localhost,orb'sInitialPort=3700
[Root exception is javax.naming.NameNotFoundException:
com.pluginsmithy.sprint.ejb.PrintScheduleBeanRemote#com.pluginsmithy.sprint.ejb.PrintScheduleBeanRemote
not found] at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:442)
at javax.naming.InitialContext.lookup(InitialContext.java:392) at
com.sun.ejb.EjbNamingReferenceManagerImpl.resolveEjbReference(EjbNamingReferenceManagerImpl.java:169)
... 22 more Caused by: javax.naming.NameNotFoundException:
com.pluginsmithy.sprint.ejb.PrintScheduleBeanRemote#com.pluginsmithy.sprint.ejb.PrintScheduleBeanRemote
not found at
com.sun.enterprise.naming.impl.TransientContext.doLookup(TransientContext.java:197)
at
com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:168)
at
com.sun.enterprise.naming.impl.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:58)
at
com.sun.enterprise.naming.impl.RemoteSerialContextProviderImpl.lookup(RemoteSerialContextProviderImpl.java:89)
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.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:146)
at
com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:176)
at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:682)
at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:216)
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)
I will do more research about the Class-Path and try to fix it. Thanks
Stephan
--
[Message sent by forum member 'smuehlst']
View Post: http://forums.java.net/node/715589