Dear all
We as a group have been developing a system based around JMS and a set of independent
EAR applications. These apps have been developed independently to a degree and were
also run on different instances of JBoss.
Now that we are trying to deploy on less servers in an environment
.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Chris Mein [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 03, 2002 7:53 AM
Subject: Re: [JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work
Dear all
We
patched the class org.apache.struts.digester.Digester
to use:
Thread.currentThread().getContextClassLoader().loadClass()
instead of
Class.forName()
and this fixed the first problem, but straight away ran into more of the same. So is
Class.forName() supposed to work with the new jboss3
Yeah, I am aware of this problem. A different classloader is now used to
load classes and lib, and this is very bad. We can make them the same, but
which do we use? A unified loader, or the servlet-containers loader? It is
a simple fix to throw the WEB-INF/classes into the unified loader, but
I'm also running into a problem that may be related to this.
I have a .war (or the .war embedded in a .ear properly referenced in
application.xml.
Essentially, I have some .properties files jarred into the .war:
WEB-INF/
classes/
com/
I'm also running into a problem that may be related
to this. I have a .war (or the .war embedded in a .ear
properly referenced in application.xml ...
OK - A few questions. From where are you accessing this resource (i.e. the location
of the directory or jar file where the accessing class
Technology Officer
JBoss Group, LLC
- Original Message -
From: Larry Sanderson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, April 19, 2002 8:42 AM
Subject: Re: [JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work
I'm also running into a problem that may
Officer
JBoss Group, LLC
- Original Message -
From: Larry Sanderson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, April 19, 2002 8:42 AM
Subject: Re: [JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work
I'm also running into a problem
package.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: lsanders [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, April 19, 2002 9:30 AM
Subject: Re: [JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments
1. The resource is being accessed from a struts taglib. So I guess
that means it is being accessed from a jar installed in WEB-INF/lib
2. It has been working for sometime (weeks) in JBoss HEAD up until a
day or two ago.
3. I would not expect .war classes to be able to see
Bugs item #544848, was opened at 2002-04-16 13:19
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=544848group_id=22866
Category: None
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 9
Submitted By: Peter Luttrell (objec)
Assigned to:
It doesn't seem to be fixed. I just (18-Apr-2002 21:00 MET) compiled the latest code
from Branch_3_0 and ran into the same problems again.
I, too, bundled struts.jar with my EAR. I could only make it work by copying
struts.jar to JBoss' lib directory.
tom
* * *
View thread online:
Applications within an ear file will only get deployed if:
1) They are referenced from an application.xml module tag (rars,ejbs,wars,
and client jars)
2) They are spcified in a META-INF / Class-Path entry of one of the the
deployed applications from step 1. (See
Bugs item #544848, was opened at 2002-04-16 15:19
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=544848group_id=22866
Category: None
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 9
Submitted By: Peter Luttrell (objec)
Assigned to:
Bugs item #544848, was opened at 2002-04-16 13:19
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=544848group_id=22866
Category: None
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 9
Submitted By: Peter Luttrell (objec)
Assigned to:
It was my patch that changed this. I changed the EARDeployer to only deploy
those applications listed in an application.xml file (I believe that this
was another bug on sourceforge?). The struts.jar should only be included on
the classpath if it is an application in the application.xml file, if
Bugs item #544848, was opened at 2002-04-16 15:19
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=544848group_id=22866
Category: None
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Luttrell (objec)
Assigned to:
Hmmm, I thought that might be what the spec wanted, but when I read it I
decided it was consistent with put everything in sight on the classpath
since then everything they mention is definitely on the classpath. Maybe
we need a configuration switch? What problems come from everything in
sight?
The J2EE 1.3 spec (8.1.1.2) goes into several examples of how nested
ejb-jar's and war's should share classes, and it is all based on Class-Path
Manifest entries. Technically, per spec, nested archives should never share
Classpath's unless there is a Class-Path META-INF entry (i.e. web archives
Bugs item #544848, was opened at 2002-04-16 15:19
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=544848group_id=22866
Category: None
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Luttrell (objec)
Assigned to:
I agree that there should be a single definitive user-specified list of
what should be deployed, but I think it belongs in the ant build file that
constructs what gets deployed. To me, it is more sloppy to include stuff
in your package that you don't want deployed than to deploy everything in a
Comments inlined...
I agree that there should be a single definitive user-specified list of
what should be deployed, but I think it belongs in the ant build file that
constructs what gets deployed. To me, it is more sloppy to include stuff
in your package that you don't want deployed than
22 matches
Mail list logo
