Classpath in ear

Hi,
I have a classpath problem with my EAR archive and strange effects.
I pack an EAR archive wich contains :
- 1 jar containings EJB's
- 1 war that use struts
- several jars with common objects (DTO)
- several jars like common-logging,...
+ struts jar files are in the WAR file (/WEB-INF/lib)
+ Manifest.mf Classpath of war and ejb include common jars
When I access an action I get an excption comming from servlet (weblogic.servlet.internal.ServletRequestImpl) :
java.lang.NoClassDefFoundError: org/apache/struts/action/Action
The strange effect are :
- when I only remove the EJB module entry in application.xml, the error do not occurs
- when I access a JSP instead of an action, Class.forName("org.apache.struts.action.Action") return a Class object.
Is there known bug with the BEA classloader or did I miss something? I tried hours to solve this without success :-(
Thank you for your responses,
Frederic

Hi,
Thank you for your repsonse, I am going to try your suggestions.
Last night I isolated the problem:
I use a third-party-jar which contains helper abstract classes for both Beans and Actions (reference on j2ee & struts). It is first used by the EJB (during the deploy), Then when I make my first Action (which extends this 3rd party AbstractAction) Bea use the wrong classloader (ejb one not the web).
The workaround is to include all struts jars in ear and ejb-manifest... (not really nice)
I will try your both suggestions in order to solves this problem correctly.
Thank You,
Frederic

Similar Messages

JMS Listener classpath and EAR files

I am trying to deploy our application using the EAR file format on Weblogic
6.0 sp2.
In order to use JMS sessionPools, we call
SessionPoolFactory.getServerSessionPool() API (which takes our JMS
Message listener class name as a string), from our startup servlet.
Can any one tell me in which classpath this listener class should be defined
? System, EJB or Web application classpath ?
I have put the relevant jar file in the EAR as well as the EAR manifest
file, but I get
weblogic.jms.common.ConfigurationException: Listener class, <class name>,
not found.
Is there any way around this (apart from putting it in the System class
path) ?
Can anyone help out here ?
Thanks.
- Venky

I am trying to deploy our application using the EAR file format on Weblogic
6.0 sp2.
In order to use JMS sessionPools, we call
SessionPoolFactory.getServerSessionPool() API (which takes our JMS
Message listener class name as a string), from our startup servlet.
Can any one tell me in which classpath this listener class should be defined
? System, EJB or Web application classpath ?
I have put the relevant jar file in the EAR as well as the EAR manifest
file, but I get
weblogic.jms.common.ConfigurationException: Listener class, <class name>,
not found.
Is there any way around this (apart from putting it in the System class
path) ?
Can anyone help out here ?
Thanks.
- Venky

Re: Classpath in ear

The Class-Path entry in manifest.mf should work. Here's the manifest.mf
for my ejb jar files (ignore the lines with the asterisks):
Manifest-Version: 1.0
Created-By: Ant 1.3
Class-Path: utility.jar
Please make sure that you add an empty line after the Class-Path entry,
it might not work otherwise. If this doesn't help, please post your
manifest.mf file.
Hope that helps,
Nils
Bernhard Lenz wrote:
>
I package an ejb.jar and a utility.jar into a myApp.ear file. However when I
deploy the ear wls 6.1 doesn't seem to find the utility.jar. I get
java.lang.NoClassDefFoundError exceptions.
What do I have to do to tell wls that the ejb.jar needs utility.jar in the
classpath?
I couldn't find anything in the application.xml dtd to accomplish this task.
I also tried the Class-path property in the manifest.mf file but it didn't
work. Maybe I did something wrong...
Thanks
Bernie--
============================
[email protected]

It didn't work in WLS81 either. Any body have a solution to this problem?

Classpath per EAR file

System:
- Sun Java System Application Server 7 2004Q2
- OS: Windows 2000 Professional
- JVM: 1.4.2_04
Does the "library" directory, inside EAR file (at the EAR root) works as a classpath ?
The Assembly Tool, has an option to add libraries to the EAR file, where this action, just creates a
directory called "library", at the root of EAR file and put there the libraries (JAR files). Does this works as
classpath when deployed to SunOne 7 2004Q2 ?
I need this because my EAR app, has 2 webcontexts and 1 JAR module (around 12 EJBs)
each one has common libraries, where I want to put inside the EAR file, and don't want replicated
libraries along the modules (web and ejb).
Do you have some suggestion ?
Thanks in advance.
- Claudio

check the classloader hierarchy at the following url:
http://docs.sun.com/source/817-2171-10/dgdeploy.html#wp58502

JSPC classpath and .ear files (WLS6.0)

          We're just beginning to use weblogic 6.0, and would like to make use of the .ear file format for deployment. The odd thing is that the system seems to have a problem with compiling JSPs that rely on our code that's bundled in the jsp as an EJB element.
          We tried placing the non-ejb specific code outside the EJB jar file and in the war file's web-inf/lib directory, but the EJB woudln't deploy. So we stuffed all our non-web specific classes in one big jar, named it the EJB jar for the .ear file, and deployed the whole mess.
          The EJB jar deploys fine, but now the JSP's inside the WAR file won't compile because the system doesn't automatically know how to find the .jar file inside the .ear file.
          What should we do? Thanks in advance for any help,
          Tim


          We're just beginning to use weblogic 6.0, and would like to make use of the .ear file format for deployment. The odd thing is that the system seems to have a problem with compiling JSPs that rely on our code that's bundled in the jsp as an EJB element.
          We tried placing the non-ejb specific code outside the EJB jar file and in the war file's web-inf/lib directory, but the EJB woudln't deploy. So we stuffed all our non-web specific classes in one big jar, named it the EJB jar for the .ear file, and deployed the whole mess.
          The EJB jar deploys fine, but now the JSP's inside the WAR file won't compile because the system doesn't automatically know how to find the .jar file inside the .ear file.
          What should we do? Thanks in advance for any help,
          Tim

Datastore id and flat class mapping

Hi,
I have
- an abstract persistent class A with 2 concrete persistent subclasses A1
and A2. I'm using datastore identity and flat class mapping.
- a class B that has a field fb with a one-many mapping to A1 objects
(Hashset).
- a class C that has a field fc with a one-many mapping to A objects
(Hashset).
- an instance a1 of A1 (id = 5)
- an instance b of B in which fb contains a1
- an instance c of C in which fc contains a1
When loading b and then c, i happen to have 2 instances representing a1 in
the same persistent manager. the one loaded in b has A1-5 as ObjectId and
the one loaded in c has A-5 as ObjectId. Thus those two objects have a
different object id while they represents the same data.
I would expect to find only one.
Do you have any idea ?
Thanks,
Laurent Czinczenheim

I found the problem! There is no more jdo-1.0.1.jar in the kodo rar :-)
Czinczenheim wrote:
I have only kodo in the rar. If i put the kodo rar 3.1.3, i can deploy it.
if i put the kodo rar 3.2.0, i cannot and get the previous exception. Is
there any difference in the packages used by kodo 3.2.0 (other than kodo
packages) that could interfer with the one i could have in my jboss lib
directories ?
thanks
laurent
Stephen Kim wrote:
Kodo should either not be in the classpath and only in the rar or
viceversa. It still seems like a classpath issue. Can you inspect your
kodo-jdo-runtime.jars for the existence of kodo/util/FatalUserException?
Czinczenheim wrote:
I have only one version of Kodo in my classpath. Therefore, when i
replace
the rar by the one from version 3.1.3 (or any older version), i don'thave
any problem to deploy the kodo resource adapter.
Stephen Kim wrote:
It appears that you may be having classpath problems. Do you have
multiple versions of Kodo in the classpath or ear/rar?
Czinczenheim wrote:
Marc,
i wanted to try it with the new 3.2 beta version but i can't even deploy
kodo 3.2.b1 in JBoss 3.2.3. Here is the stacktrace i get when deploying
the rar (My kodo-ds.xml is the same as the one i used with kodo 3.1.3):
11:47:52,975 INFO [RARDeployment] Starting
11:47:53,036 WARN [ServiceController] Problem starting service
jboss.jca:service=ManagedConnectionFactory,name=jdo/pmf/prisma01
java.lang.NoClassDefFoundError: kodo/util/FatalUserException
     at java.lang.Class.getDeclaredConstructors0(Native Method)
     at java.lang.Class.privateGetDeclaredConstructors(Class.java:1610)
     at java.lang.Class.getConstructor0(Class.java:1922)
     at java.lang.Class.newInstance0(Class.java:278)
     at java.lang.Class.newInstance(Class.java:261)
     at
org.jboss.resource.connectionmanager.RARDeployment.startService(RARDeployment.java:533)
>>>
     at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192)
     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:324)
     at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
>>>
     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
     at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:976)
>>>
     at $Proxy12.start(Unknown Source)
     at org.jboss.system.ServiceController.start(ServiceController.java:394)
     at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
     at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>
     at java.lang.reflect.Method.invoke(Method.java:324)
     at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
>>>
     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
     at $Proxy4.start(Unknown Source)
     at org.jboss.deployment.SARDeployer.start(SARDeployer.java:226)
     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:324)
     at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
>>>
     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
     at
org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:177)
     at $Proxy18.start(Unknown Source)
     at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:231)
     at org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:632)
     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:605)
     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:324)
     at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
>>>
     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
     at $Proxy6.deploy(Unknown Source)
     at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:302)
>>>
     at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:476)
>>>
     at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:201)
>>>
     at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:274)
>>>
     at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192)
     at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
     at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>
     at java.lang.reflect.Method.invoke(Method.java:324)
     at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
>>>
     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
     at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:976)
>>>
     at $Proxy0.start(Unknown Source)
     at org.jboss.system.ServiceController.start(ServiceController.java:394)
     at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
     at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>
     at java.lang.reflect.Method.invoke(Method.java:324)
     at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
>>>
     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
     at $Proxy4.start(Unknown Source)
     at org.jboss.deployment.SARDeployer.start(SARDeployer.java:226)
     at org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:632)
     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:605)
     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:589)
     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:324)
     at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
>>>
     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
     at $Proxy5.deploy(Unknown Source)
     at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:384)
     at org.jboss.system.server.ServerImpl.start(ServerImpl.java:291)
     at org.jboss.Main.boot(Main.java:150)
     at org.jboss.Main$1.run(Main.java:388)
     at java.lang.Thread.run(Thread.java:534)
Thanks for your help since the initial bug i described is critical forus.
Laurent
Marc Prud'hommeaux wrote:
Laurent-
I believe I have seen that problem, but I can't recall the exact
symptoms (or the exact bug number). However, I do think that it was
fixed for Kodo 3.2. Can you download the 3.2 beta and see if the
problem
still occurs?
If it does still happen, can you provide us with your .jdo, .mapping,
and .java files for the classes so we can take a look?
In article <[email protected]>, Czinczenheim wrote:
Hi,
I have
- an abstract persistent class A with 2 concrete persistent subclasses
A1
and A2. I'm using datastore identity and flat class mapping.
- a class B that has a field fb with a one-many mapping to A1 objects
(Hashset).
- a class C that has a field fc with a one-many mapping to A objects
(Hashset).
- an instance a1 of A1 (id = 5)
- an instance b of B in which fb contains a1
- an instance c of C in which fc contains a1
When loading b and then c, i happen to have 2 instances representing
a1
in
the same persistent manager. the one loaded in b has A1-5 as ObjectIdand
the one loaded in c has A-5 as ObjectId. Thus those two objects have a
different object id while they represents the same data.
I would expect to find only one.
Do you have any idea ?
Thanks,
Laurent Czinczenheim
Marc Prud'hommeaux
SolarMetric Inc.
Steve Kim
[email protected]
SolarMetric Inc.
http://www.solarmetric.com
Steve Kim
[email protected]
SolarMetric Inc.
http://www.solarmetric.com

Javax.xml.bind.JAXBException: Unable to locate jaxb.properties for package ...

I want to marshall a java content tree (generated with jaxb api) in xml stream
in an EJB.
Generated classes are archived in a jar file containing its jaxb.properties, when
I test it
in a classic java process it runs well.
When I try to do it in an EJB with weblogic 8.1 I get the following error:
javax.xml.bind.JAXBException: Unable to locate jaxb.properties for package
I've checked:
- jaxb.properties is in the archive file
I've tried to put the jar file in the classpath of the server in the starter script.
I've tried to put reference classpath in the manifest of the ejb jar and of application
ear.
I've tried to put both reference in server classpath and ear/jar manifest.
I still doesn't run.
Any idea?
Thanks a lot
Franck

Add the directory of the generated classes in the classpath.
"franck" <[email protected]> wrote:
>
I want to marshall a java content tree (generated with jaxb api) in xml
stream
in an EJB.
Generated classes are archived in a jar file containing its jaxb.properties,
when
I test it
in a classic java process it runs well.
When I try to do it in an EJB with weblogic 8.1 I get the following error:
javax.xml.bind.JAXBException: Unable to locate jaxb.properties for package
I've checked:
- jaxb.properties is in the archive file
I've tried to put the jar file in the classpath of the server in the
starter script.
I've tried to put reference classpath in the manifest of the ejb jar
and of application
ear.
I've tried to put both reference in server classpath and ear/jar manifest.
I still doesn't run.
Any idea?
Thanks a lot
Franck

Weird classpath issue in EAR.Some classes can access jars that others cant!

Hi,
I'm experiencing a very frustrating problem that's proving to be a bit of a show stopper for me. I would really appreciate some help...
I have an EAR deployed successfully on Sun Appserver 8 which passes the tests from the sun EAR verifier tool. The ear contains a jar file that I built which has a stateless session bean, home, remote interfaces and rmi stubs, deployment descriptors, as well as some utility classes. The EAR also contains some third-party jars such as Hibernate, Log4-j, apache-commons etc etc. The jar I built has in it's manifest file, the classpath information to reference the other jars in the ear.
The problem I am having is that one of the classes in a third-party jar (hibernate3.jar) cannot see a class in another of the third party jars (log4j-1.2.8.jar) and as a result is throwing a NoClassDefFoundError for org/apache/log4j/Layout while trying to initialise - the two jars are at the root of the EAR.
Furthermore, my utility classes can access and use Log4j classes without any problem and logging command from those classes is output successfully to the server console. However, my session bean, which is packaged in the same jar as the utility classes, fails to log anything even though it uses exactly the same logger and log configuration as the utility classses.
I have tried adding classpath information to the manifest of the EAR so that the third-party jars can pick it up but this makes no difference. Also, according to the EAR verifier tool, you are not allowed to put any classpath information in the EAR manifest.
I have also tried deploying this in weblogic but am experiencing the same problem.
If anyone can offer any advice or solutions I would greatly appreciate it.
:)

whatÂ´s type error have you?
perhaps external libraries (located in classpath) invoke opsCommon.jar and config-3.0.jar classes. then, classnotfound is normal.
and... why separate external libraries (opsCommon.jar and config-3.0.jar inside ear, and other in classpath)?

Ears, wars, support jars, and CLASSPATH

I am trying to migrate an application from WLS 5.1 to 6.1. There are 25
EJB jars with an equal number of support jars, most of which are referenced
by multiple EJBs. There are also a large number of jsps, and html pages.
I have tried packaging an ear that contains the 25 ejb jars, a war file
containing the web pages. I have attempted to include the support jars in
the ear as well.
In all attempts, the only way I get class references sastisfied is to
include all the jars on the system CLASSPATH. But this defeats the purpose
of packaging, since none of the components referenced in the system
CLASSPATH will be re-deployable.
The online documents refer to separate class loaders and classpaths for the
war and ejbs, but no detail as to how classes are found by the loaders.
Unless I put all the jars into the CLASSPATH, jsp pages cannot reference the
EJBs, and EJBs are unable to reference other EJBs.

Thanks,
Now if I could just get Webgain Visual Cafe to allow me to include the
Classpath entries in the generated manifests for the EJB jars.
"Gregory Gerard" <[email protected]> wrote in message
news:3ba24da1$[email protected]..
You need to mangle all the Manifest files within the EAR and EJB-JARs and
WAR to get the right thing to happen. Check out this PDF on Sun's site:
http://java.sun.com/j2ee/j2ee-1_3-pfd4-spec.pdf
section 8.1.1.2
I don't entirely understand all the restrictions and formatting -- Ihaven't
found an example ear file out there that implements a non-trivial case.
greg
"Carl Lawstuen" <[email protected]> wrote in message
news:3ba21d8e$[email protected]..
I am trying to migrate an application from WLS 5.1 to 6.1. There are
25
EJB jars with an equal number of support jars, most of which arereferenced
by multiple EJBs. There are also a large number of jsps, and htmlpages.
I have tried packaging an ear that contains the 25 ejb jars, a war file
containing the web pages. I have attempted to include the support jarsin
the ear as well.
In all attempts, the only way I get class references sastisfied is to
include all the jars on the system CLASSPATH. But this defeats thepurpose
of packaging, since none of the components referenced in the system
CLASSPATH will be re-deployable.
The online documents refer to separate class loaders and classpaths forthe
war and ejbs, but no detail as to how classes are found by the loaders.
Unless I put all the jars into the CLASSPATH, jsp pages cannot referencethe
EJBs, and EJBs are unable to reference other EJBs.

EAR and long CLASSPATH at JSP compilation time

          Hi all,
          we have an EAR-packaged application with over 260 jars (mainly
          EJB) that is deployed to a managed server WL6.1SP3(AIX). Then
          we hit a JSP page of this app. and Weblogic generates the
          adecuate .java file that is passed as an argument to a forked
          process for the javac compiler with a CLASSPATH that is more
          than 22KB!! of length because of the EAR classloader schema
          (it must include all the jars of the EJB level).
          The problem is that the EAR deployment in WL6.1 generates a fixed and very long
          path for every jar that it is composed of:
          $WL_HOME/./config/DOMAIN/applications/.wl_notdelete_EARNAME
          /wlap#####/ejbjarname.jar
          and the invoke of the compiler fails with argument too long.
          We can control the EJB jar name, EARNAME, WL_HOME
          and DOMAIN to shorten the CLASSPATH, but that is not enough
          giving that the fixed part of the PATH is very long, for example:
          with DOMAIN=DOM1, WL_HOME=W, ejbjar name=EJB1, EARNAME=EAR1
          you get:
          /w/./config/DOM1/applications/.wl_notdelete_EAR1/wlap#####/EJB1.jar: that is
          68 chars * 260 jars = more than 17KB only with the
          EJB part of the CLASSPATH (plus the standard SYSTEM CLASSPATH
          and WARS CLASSPATH.)
          As workarounds we can:
          1.- Use an "pseudo exploded" EAR with EJBREMOTE and EJBHOME in clientclasses path
          with every jar and war by their own. Not very
          clean and we've lost the benefits of EAR deployment.
          2.- Consolidate a bunch of EJB in every jar. More administrative
          tasks (common xml descriptors:ejb-jar.xml,...) and less isolation
          between developer teams.
          3.- Consolidate at functionality level (source) a bunch of EJB
          in a few one. :(
          4.- Precompile every JSP outside of WEBLOGIC and generate
          the corresponding class and entries at web.xml and weblogic.xml
          5.- ...?
          or maybe:
          6.- configure this very long directory of deployment
          to a shorter deployer choosen and use relative paths.
          Is this possible? :)
          PacoG.


You may try to use JSP compiler class. Please specify 'compilerclass'
          option in weblogic.xml. This option specifies name of a Java compiler
          that is executed in WebLogic Servers's virtual machine. (Used in place of
          an executable compiler such as javac or sj.)
          Please see
          http://e-docs.bea.com/wls/docs61/webapp/weblogic_xml.html#jsp-descriptor.
          Paco Garcia wrote:
          > oops!
          >
          > >$WL_HOME/./config/DOMAIN/applications/.wl_notdelete_EARNAME
          > >/wlap#####/ejbjarname.jar
          >
          > >with DOMAIN=DOM1, WL_HOME=W, ejbjar name=EJB1, EARNAME=EAR1
          > >you get:
          > >/w/./config/DOM1/applications/.wl_notdelete_EAR1/wlap#####/EJB1.jar:
          >
          > please read SERVERNAME instead of EARNAME
          >
          > PacoG.
          Regards,
          Ann
          Developer Relations Engineer
          BEA Support

Classpath problem in exploded ear

I'm having problems deploying an application in a new environment. We deploy Mercury.ear as an exploded ear under
Windows in a single-server domain without any problem.
I am tasked with setting up a WL cluster as the first step in our cluster certification/testing (under Linux/RedHat ASE 3.0).
We are using WL 8.1. SP2. This should be a relatively trivial task, but I must be missing something obvious,
because I've been banging my head on it the last couple of days.
Basically, I have two WL managed servers, ClusterMember1 and ClusterMember2 and an admin server AdminServer created in a WL domain.
All servers start normally (when no applications are deployed to the managed servers).
I have appended our entire config.xml to the end of this post, but here is the relevant <Application> section:
<Application Name="Mercury"
Path="/root/bea/user_projects/domains/clusterdomain/applications/Mercury"
StagingMode="nostage" TwoPhase="true">
<EJBComponent Name="MercuryEJB.jar" Targets="ClusterMember1" URI="MercuryEJB.jar"/>
<WebAppComponent Name="Apollo" Targets="ClusterMember1" URI="MercuryWeb.war"/>
<ConnectorComponent Name="SpectraConnector.rar"
Targets="ClusterMember1" URI="SpectraConnector.rar"/>
</Application>
I am only attempting to deploy to managed server ClusterMember1 at this time.
When I attempt to start ClusterMember1:
./startManagedWebLogic.sh ClusterMember1 http://localhost:9001 &
It starts up, syncs with the admin server, and then attempts to deploy the Mercury application. I get the following exception when it attempts to start the Mercury application:
<Feb 1, 2006 10:07:55 AM CST> <Error> <HTTP> <BEA-101216> <Servlet: "context" failed to preload on startup in Web application: "Apollo".
javax.servlet.ServletException: Error registering bean with name 'ApolloSessionManager' defined in URL [file:/root/bea/user_projects/domains/clusterdomain/applications/Mercury/mercuryresources.jar/resources/xml/springconfig/Service-DAO-config.xml]: Class that bean class [com.sg.sims.mercury.apolloweb.service.processor.ApolloSessionManager] depends on not found; nested exception is java.lang.NoClassDefFoundError: com/sg/sims/mercury/apolloweb/service/processor/ApolloSessionManager
     at weblogic.servlet.internal.ServletStubImpl.createServlet()Ljavax/servlet/Servlet;(ServletStubImpl.java:985)
{...snipped...}
Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: Error registering bean with name 'ApolloSessionManager' defined in URL [file:/root/bea/user_projects/domains/clusterdomain/applications/Mercury/mercuryresources.jar/resources/xml/springconfig/Service-DAO-config.xml]: Class that bean class [com.sg.sims.mercury.apolloweb.service.processor.ApolloSessionManager] depends on not found; nested exception is java.lang.NoClassDefFoundError: com/sg/sims/mercury/apolloweb/service/processor/ApolloSessionManager
     at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinition(Lorg/w3c/dom/Element;Ljava/lang/String;)Lorg/springframework/beans/factory/config/BeanDefinition;(DefaultXmlBeanDefinitionParser.java:366)
{...snipped...}
Caused by: java.lang.NoClassDefFoundError: com/sg/sims/mercury/apolloweb/service/processor/ApolloSessionManager
     at java.lang.Class.forName(Ljava/lang/String;ZLjava/lang/ClassLoader;)Ljava/lang/Class;(Unknown Source)
     at org.springframework.beans.factory.support.BeanDefinitionReaderUtils.createBeanDefinition(Ljava/lang/String;Ljava/lang/String;Lorg/springframework/beans/factory/config/ConstructorArgumentValues;Lorg/springframework/beans/MutablePropertyValues;Ljava/lang/ClassLoader;)Lorg/springframework/beans/factory/support/AbstractBeanDefinition;(BeanDefinitionReaderUtils.java:50)
{...snipped...}
Clearly, Spring can't find the ApolloSessionManager class (or one of its dependent classes, the error message is somewhat unclear in places).
However, the ApolloSessionManager.class file is there, under the mercurybusiness.jar directory (with package structure).
// from ${DOMAIN_HOME}/applications/Mercury:
ls -la mercurybusiness.jar/com/sg/sims/mercury/apolloweb/service/processor/ApolloSessionManager
-rw-r--r-- 1 root root 7162 Jan 31 17:20 mercurybusiness.jar/com/sg/sims/mercury/apolloweb/service/processor/ApolloSessionManager.class
mercurybusiness.jar (in turn) is present in the MercuryEJB.jar MANIFEST.MF file:
// ${DOMAIN_HOME}/applications/Mercury/MercuryEJB.jar/META-INF/MANIFEST.MF:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.1
Created-By: 1.4.2_05-b04 (Sun Microsystems Inc.)
Class-Path: mercurycommon.jar mercuryresources.jar mercurybusiness.jar mercuryserviceflow.jar mercuryutils.jar spectraconnector.rar {...snipped...}
The same situation appears for the classes that ApolloSessonManager depends on: MercuryLogger (a log4j wrapper) and the HTTPClient.jar classes
(e.g. Cookie, etc), except 3rd party jars are listed in the MANIFEST.MF of MercuryEJB.jar but are not exploded.
There is no weblogic-application.xml file to override the default classloader hierarchy, so my understanding
is that everything in the application should share a single classloader.
So I am at a loss to understand why classes in MercuryWeb.war can not load classes in dependent jars of MercuryEJB.jar.
As a note, if I add /root/bea/user_projects/domains/clusterdomain/applications/Mercury/mercurybusiness.jar to the CLASSPATH variable in startManagedWebLogic.sh,
this error disappears of course, and it barfs on the next application class it can't find (in one of the other exploded jars that MercuryEJB.jar depends on.
Can someone help point out what I may be missing?
Chris Goodacre
// config.xml
<?xml version="1.0" encoding="UTF-8"?>
<Domain ConfigurationVersion="8.1.5.0" Name="clusterdomain">
<Server Cluster="SIMS_TEST_CLUSTER_1" ListenAddress=""
ListenPort="9001" Name="AdminServer" NativeIOEnabled="true"
ReliableDeliveryPolicy="RMDefaultPolicy" ServerVersion="8.1.5.0">
<SSL Enabled="false" HostnameVerificationIgnored="false"
IdentityAndTrustLocations="KeyStores" Name="AdminServer"/>
</Server>
<WSReliableDeliveryPolicy DefaultRetryCount="10"
DefaultTimeToLive="60000" Name="RMDefaultPolicy" Store="FileStore"/>
<Security Name="clusterdomain"
PasswordPolicy="wl_default_password_policy"
Realm="wl_default_realm" RealmSetup="true"/>
<EmbeddedLDAP
CredentialEncrypted="{3DES}dMeE/vNpCcbjzOMZGfNeShv5VFZuQ=" Name="clusterdomain"/>
<SecurityConfiguration
CredentialEncrypted="{3DES}jFRG5NzABP8IAJa5M/PNNRCtZYaqkc2zUTYjlysL+md+TAgZw6IfgCjzzre4e7p5gyJEt+0UkPXNleN0QtW7Ef"
Name="clusterdomain" RealmBootStrapVersion="1"/>
<Realm FileRealm="wl_default_file_realm" Name="wl_default_realm"/>
<FileRealm Name="wl_default_file_realm"/>
<PasswordPolicy Name="wl_default_password_policy"/>
<JMSConnectionFactory DefaultDeliveryMode="Non-Persistent"
JNDIName="jms/ConnectionFactory" Name="ConnectionFactory" Targets="AdminServer"/>
<JMSFileStore Directory="rmfilestore" Name="FileStore"/>
<JMSServer Name="WSStoreForwardInternalJMSServerAdminServer"
Store="FileStore" Targets="AdminServer">
<JMSQueue CreationTime="1123128740234"
JNDIName="jms.internal.queue.WSStoreForwardQueue"
JNDINameReplicated="false" Name="WSInternaljms.internal.queue.WSStoreForwardQueueAdminServer"/>
<JMSQueue CreationTime="1123128740390"
JNDIName="jms.internal.queue.WSDupsEliminationHistoryQueue"
JNDINameReplicated="false" Name="WSInternaljms.internal.queue.WSDupsEliminationHistoryQueueAdminServer"/>
<JMSQueue CreationTime="1123128837453" JNDIName="jms/MenuQueue"
Name="MenuQueue" StoreEnabled="false"/>
<JMSQueue CreationTime="1123128864296"
JNDIName="jms/MenuXMLQueue" Name="MenuXMLQueue" StoreEnabled="false"/>
<JMSQueue CreationTime="1123128892343"
JNDIName="jms/DataSyncQueue" Name="DataSyncQueue" StoreEnabled="false"/>
<JMSQueue CreationTime="1123128915421"
JNDIName="jms/LoginRefreshQueue" Name="LoginRefreshQueue" StoreEnabled="false"/>
<JMSQueue CreationTime="1123128937046"
JNDIName="jms/ProfileQueue" Name="ProfileQueue" StoreEnabled="false"/>
<JMSQueue CreationTime="1123128957125"
JNDIName="jms/ReportsQueue" Name="ReportsQueue" StoreEnabled="false"/>
</JMSServer>
<Cluster Name="SIMS_TEST_CLUSTER_1"/>
<Server Cluster="SIMS_TEST_CLUSTER_1" ExpectedToRun="false"
ListenPort="9999" Name="ClusterMember1" ServerVersion="8.1.5.0">
<ServerDebug Name="ClusterMember1"/>
<SSL IdentityAndTrustLocations="KeyStores" Name="ClusterMember1"/>
<KernelDebug Name="ClusterMember1"/>
<Log Name="ClusterMember1"/>
<ServerStart Name="ClusterMember1"
PasswordEncrypted="{3DES}TC7nfOvKF0xwJB/f+tyYwQ==" Username="toolbox"/>
<WebServer Name="ClusterMember1"/>
<COM Name="ClusterMember1"/>
<IIOP Name="ClusterMember1"/>
<JTAMigratableTarget Name="ClusterMember1" UserPreferredServer="ClusterMember1"/>
<JTARecoveryService Name="ClusterMember1"/>
</Server>
<MigratableTarget Cluster="SIMS_TEST_CLUSTER_1"
Name="ClusterMember1 (migratable)"
Notes="This is a system generated default migratable target for a server. Do not delete manually." UserPreferredServer="ClusterMember1"/>
<Server Cluster="SIMS_TEST_CLUSTER_1" ExpectedToRun="false"
ListenPort="9998" Name="ClusterMember2" ServerVersion="8.1.5.0">
<ServerDebug Name="ClusterMember2"/>
<SSL IdentityAndTrustLocations="KeyStores" Name="ClusterMember2"/>
<KernelDebug Name="ClusterMember2"/>
<Log Name="ClusterMember2"/>
<ServerStart Name="ClusterMember2"
PasswordEncrypted="{3DES}TC7nfOvKF0xwJB/f+tyYwQ==" Username="toolbox"/>
<WebServer Name="ClusterMember2"/>
<COM Name="ClusterMember2"/>
<IIOP Name="ClusterMember2"/>
<JTAMigratableTarget Name="ClusterMember2" UserPreferredServer="ClusterMember2"/>
<JTARecoveryService Name="ClusterMember2"/>
</Server>
<MigratableTarget Cluster="SIMS_TEST_CLUSTER_1"
Name="ClusterMember2 (migratable)"
Notes="This is a system generated default migratable target for a server. Do not delete manually." UserPreferredServer="ClusterMember2"/>
<JDBCConnectionPool DriverName="com.sybase.jdbc2.jdbc.SybDriver"
Name="MercuryJDBCConnPool"
PasswordEncrypted="{3DES}Enwr7V6DdUk="
Properties="user=dbuser;url=jdbc:sybase:Tds:10.15.3.66:4100/ENT_60_DEV;networkProtocol=Tds;portNumber=4100;userName=dbuser;databaseName=ENT_60_DEV;serverName=10.15.3.66"
Targets="SIMS_TEST_CLUSTER_1" TestTableName="SQL SELECT 1" URL="jdbc:sybase:Tds:10.15.3.66:4100/ENT_60_DEV"/>
<JDBCDataSource JNDIName="jdbc/MercuryDS" Name="MercuryDS"
PoolName="MercuryJDBCConnPool" Targets="SIMS_TEST_CLUSTER_1"/>
<MigratableTarget Cluster="SIMS_TEST_CLUSTER_1"
Name="AdminServer (migratable)"
Notes="This is a system generated default migratable target for a server. Do not delete manually." UserPreferredServer="AdminServer"/>
<Application Name="Mercury"
Path="/root/bea/user_projects/domains/clusterdomain/applications/Mercury"
StagingMode="nostage" TwoPhase="true">
<EJBComponent Name="MercuryEJB.jar" Targets="ClusterMember1" URI="MercuryEJB.jar"/>
<WebAppComponent Name="Apollo" Targets="ClusterMember1" URI="MercuryWeb.war"/>
<ConnectorComponent Name="SpectraConnector.rar"
Targets="ClusterMember1" URI="SpectraConnector.rar"/>
</Application>
</Domain>
////////////////////////////////////////////////////////////

Sorry, I don't have the response to your question.
But I'd like to know how youmake your servlet and your applet communicate.
I'm building a web site using both applets and servlet. And I nned to make them communicate. I'm trying to use RMI but I get many problems.
Can I know Which solution you have chosen for applet-servlet communication ?
Thank's.

Developing using EAR structure gives redeploy/classpath issues

I am very keen to get people's opinions and methods of developing and packaging
EARs/WARs/EJBs under WL6.1 sp2.
What method do you use and what problems do you get...
We have recently migrated to WL6.1 sp2, and looked forward to using the Enterprise
Applications Archive expanded structure to deploy and develop under. However I
have come across a few fundamental problems that seem to make development in this
structure worthless.
It seems it's easier just have all the expanded classes paths on the Java Classpath
and just restart the server after a individual class file recompile ?
Problems :-
- With an expanded EAR structure, I believe you can only redeploy the WHOLE EAR
(by touching the REDEPLOY file), not an individual ejb jar or just the WAR part.
I have tried putting a REDEPLOY file in the WAR \WEB-INF\ directory, as recommended,
but I think this only works outside of the EAR structure. If you use the Console
to just undeploy an redeploy the Web App, it redeploys the whole EAR. So this
leaves us having to undeploy everything to test out a change.
- The classloaders hierarchy available with an EAR structure seems ideal at first,
e.g. the Web App can see all EJB jar classes. We have our EJB jars containing
the beans and just the DEPENDANT classes (often these are abstract types), this
keeps the jars lean and avoids duplicated classes across ejb jars. But this leaves
some classes which are not in any EJB jar at all (often subclasses or implementations
of these abstract types), however the Web App still needs them. It is difficult
to isolate these individual classes. So for now we have two solutions which don't
seem quite right :-
Make one of the EJB.jars contain ALL the Server side classes, not just dependant
classes. Or make a full jar of ALL server side classes and add this jar to the
Web Apps \META-INF\manifest Class-Path like you would do with an EJB jar.
Is there a way to have a non-EJB jar at the EJB classloader level ? This would
solve this and allow Web Apps to see other non-ejb jars.
How do you guys works and avoid the problems we've hit ?

Pete <[email protected]> wrote:
Is there a way to have a non-EJB jar at the EJB classloader level ? Sure, just add it to the Class-Path: manifest entry in your ejb.jar.
Dimitri

Can I specify classpath in MANIFEST.MF of a ear file?

Hi,
I know that one can specify classpath in MANIFEST.MF of a jar file, I'd like to know whether I can specify classpath in MANIFEST.MF of a ear file?
If yes, will the classpath specified affect all j2ee components in this ear file?(e.g. jar files,war files)
Thanks

Unfortunately, yes, you'd have to edit the MANIFEST.MF
of each module within the .ear that has a dependency on
the bundled library. One workaround is to add the common
code to the server's classpath. However, that approach
doesn't work if the common code has dependencies on the
code packaged within the ejb-jars and .wars themselves.
--ken

Classpath problems in EAR packaging?

I try to access an EJB from a JSP. The JSP resides in web.war and the bean is in ejb.jar, and both of these are packaged together in an ear.
I get a compile error when I try opening a JSP. I've had this problem in all my attempts to use my bean classes from JSP.
My browser reports that the compiler cannot find the beans package. I have servlets within the war-file that are able to find the beans package, but the JSPs aren't.
My ear-file contains 3 files
ejb.jar
web.war
META-INF\MANIFEST.MF
The manifest classpath points to ejb.jar and web.war
My guess is that this has something to do with the way this is deployed by GlassFish.
The application is deployed in the
domains\mydomain\applications\j2ee-apps\myear\
This directory contains the expanded files:
ejb_jar\
web_war\
META-INF
So the Java classes under web_war\ are able to see the Java classes under ejb_jar\ (i.e. my servlets)
However; when GlassFish creates Java files from the JSPs and then tries to compile them, these files are placed under
domains\mydomain\generated\jsp\j2ee-apps\myear\web_war\org\apache\jsp\jsp
This might be correct for all I know, but apparently the compiler is unable to find the Java classes located under the mydomain\applications\.. directory when compiling classes located under the mydomain\generated\.. directory. There are no other files from my ear anywhere in the "generated" directory.
So to me this seems to be some kind of classpath problem, as the compiler cannot find the needed files.
Does this make any sense to anyone?
PS
In my ear, the JSPs are placed in the web.war. The war file looks like this:
jsp\
   myjsp.jsp
META-INF
   MANIFEST.MF
WEB-INF
   web.xml
   lib\
      mylib.jarThanks
\\Marius

Marius,
If you want communicate the bean you have to do following things.
. Create a factory for the correct protocol
. Obtain a Home
. Use the Home to create stubs to the remote object
So you want to call the Home and Remote interfaces to access the bean. When you run the client program, it will create the remote object that time it has to search the Home and Remote interfaces. So you have included those files for references in following location
WEB-INF/classes
     -- <Home Interface File Name>.class
     -- <Remote Interface File Name>.class
Or
WEB-INF/lib
     -- <Bean Jar file name>.jar
I think you will understand.
-Mani

Ear Classpath problem

I have an ear file that contains
staiAppln.ear
-> stai.war
-> staiEJB.jar
-> application.xml (defining stai.war as web module & staiEJB as EJB
module)
-> manifest.mf (empty except for version number)
staiEJB.jar contains the various classes and EJBs to support the web
app as well as a class that allows you to run the application from a
dos prompt
(eg java -cp staiEJB.jar;%CLASSPATH% stai.Client) which works fine.
The problem is how to configure the ear file so that you can run the
same prompt using the ear file (eg java -cp staiAppln.ear;%CLASSPATH%
stai.Client).
Currently I get a ClassNotFound exception on stai.Client as it is not
finding the class within staiEJB.jar. I have tried modifying the
manifest.mf and adding a classpath line, but that only worked if the
staiEJB.jar was in the same directory as the staiAppln.ear. Can anyone
point me in the right direction??
Thanks
Terry

Hi Terry,
EAR is a jar file. AFAIK you java can not load classes from
jars in a jar (unless you implement a classloader that can handle it).
So you could just unjar ear and put it's jars into the classpath.
Regards,
Slava Imeshev
"Terry Treadwell" <[email protected]> wrote in message
news:[email protected]..
I have an ear file that contains
staiAppln.ear
-> stai.war
-> staiEJB.jar
-> application.xml (defining stai.war as web module & staiEJB as EJB
module)
-> manifest.mf (empty except for version number)
staiEJB.jar contains the various classes and EJBs to support the web
app as well as a class that allows you to run the application from a
dos prompt
(eg java -cp staiEJB.jar;%CLASSPATH% stai.Client) which works fine.
The problem is how to configure the ear file so that you can run the
same prompt using the ear file (eg java -cp staiAppln.ear;%CLASSPATH%
stai.Client).
Currently I get a ClassNotFound exception on stai.Client as it is not
finding the class within staiEJB.jar. I have tried modifying the
manifest.mf and adding a classpath line, but that only worked if the
staiEJB.jar was in the same directory as the staiAppln.ear. Can anyone
point me in the right direction??
Thanks
Terry

Classpath in ear

Similar Messages

Maybe you are looking for