Bugs item #580190, was opened at 2002-07-11 17:31
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=580190&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 7
Submitted By: Stephen Davidson (northgorky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ear Deployer Broken (Infinite Looping)
Initial Comment:
When trying to deploy an ear which has jars with
multiple interdependincies, JBoss Deployer goes into an
infinite loop, and eventually starts throwing
StackOverflow and OutOfMemory Exceptions.
Sample Ear file that demonstrates this behaviour attached.
----------------------------------------------------------------------
Comment By: Markus Kling (mkling)
Date: 2002-07-15 17:07
Message:
Logged In: YES
user_id=360804
Attached two e-mails to dev-list facing the same issues.
----------------
Hi Folx,
some more additional thoughts/comments:
- I could fix my scenario while removing the ejb-jars from the
manifest of
the web-application
- I created another scenario where ejb-jars depend on each
other during
deployment (base classes for jar2 are located within jar1). If I
remove the
manifest entries I get NoClassDef... erros. If I add manifest
entries the
pointed out InstanceAlreadyExistsException exception is
thrown (same
situation as shown before)
- Imagine the following scenario would be functional with the
current
classloading architecture
ear
-> ejb1
-> ejb2
-> manifest -> ejb1
Can the current classloading scenario handle local calls from
ejb2 to ejb1
with classes from ejb1 as parameters without the need to
serialize these
parameters. Imho the classes need to be serialized since
they have been
loaded with different classloaders.
thanks for your help,
Markus
-----Urspr�ngliche Nachricht-----
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Im
Auftrag von
[EMAIL PROTECTED]
Gesendet: Sonntag, 14. Juli 2002 23:14
An: [EMAIL PROTECTED]
Betreff: [JBoss-dev] MainDeployer / Manifest class-path
Hi,
could it be possible that there is an error in the
MainDeployer? Assume the
following scenario:
ear
war (references jar1 and jar2 via manifest)
jar1 - contains ejb/normal classes
jar2 - same as above
The MainDeployer loads the ear and extracts the war. It
assigns a
WebClassloader and searches the Manifest classpath.
MainDeployer finds jar1
and jar2 -> init. Jar1/Jar2 are ejb-jars so they get assigned an
EJBDeployer. Than deployer -> deploy -> start.
But now jar1 gets loaded again with an EJBDeployer, but the
Beans have
allready been registered which results in a
javax.management.InstanceAlreadyExistsException.
I think jars (here jar1/jar2) MUST be loaded with the
JARDeployer (dependant
to the war-classloader) if a war/ejb references them via
manifest classpath.
Did i miss something? e-mail me if you want to get a test-jar.
regards,
Markus
----------------------------------------------------------------------
Comment By: Stephen Davidson (northgorky)
Date: 2002-07-15 16:24
Message:
Logged In: YES
user_id=490856
Sorry that I have not come up with a complete solution. I
have my own deadlines right now, and this has thrown me
behind. The proposed patches allow me to work around the
current issues, until a permanent solution can be implemented.
To patch this for the moment, and address future circularity
issues, I am proposing the following patches;
diff -u -r1.28.2.13 MainDeployer.java
--- system/src/main/org/jboss/deployment/MainDeployer.java
26 Jun 2002 19:18:48 -0000 1.28.2.13
+++ system/src/main/org/jboss/deployment/MainDeployer.java
15 Jul 2002 16:03:28 -0000
@@ -845,6 +845,7 @@
*/
private void parseManifestLibraries(DeploymentInfo sdi)
throws DeploymentException
{
+ log.debug("Parsing Manifest for: " + sdi.shortName);
String classPath = null;
Manifest mf = sdi.getManifest();
@@ -879,13 +880,15 @@
{
lib = new URL(sdi.url, tk);
}
-
- if (!isDeployed(lib))
+/* SPDBUG: Bad idea. If the jar really should be deployed,
there should be
+ *an entry in the ear application.xml file.
+ if (!(isDeployed(lib) || sdi.hasParent(lib)))
{
// Try having it as a full subdeployment
sub = new DeploymentInfo(lib, sdi,
getServer());
deploy(sub);
}
+ */
}
catch (Exception ignore)
{
#################
diff -u -r1.5.2.8 DeploymentInfo.java
--- system/src/main/org/jboss/deployment/DeploymentInfo.java
29 Jun 2002 21:17:40 -0000 1.5.2.8
+++ system/src/main/org/jboss/deployment/DeploymentInfo.java
15 Jul 2002 16:16:16 -0000
@@ -190,6 +190,26 @@
// Do we have an XML descriptor only deployment?
isXML = shortName.toLowerCase().endsWith("xml");
}
+
+ public boolean hasParent(final URL url){
+ //SPDDBG:
+ System.out.println("Checking for parent: " + url);
+ if (this.parent == null){
+ //No Parents
+ //SPDDBG:
+ System.out.println("No Parents");
+ return(false);
+ }
+ //else
+ //Check to see if parent is the URL we are trying to
compare, or if we
+ //are a grandchild of this URL;
+ //SPDDBG:
+ System.out.println("ShortName: " + shortName);
+ System.out.println("Parent.shortName: " +
parent.shortName);
+ System.out.println("Test ShortName: " +
getShortName(url.getFile()));
+ return(
parent.shortName.equalsIgnoreCase(getShortName(url.getFile()))
+ || parent.hasParent(url));
+ }
#######
diff -u -r1.12.2.10 EARDeployer.java
--- server/src/main/org/jboss/deployment/EARDeployer.java
30 Jun 2002 00:26:19 -0000 1.12.2.10
+++ server/src/main/org/jboss/deployment/EARDeployer.java
15 Jul 2002 16:20:56 -0000
@@ -190,13 +190,19 @@
try
{
URL url = new URL(urlPrefix + name);
+ log.debug("Checking if Deployable
(name|URL):" + name + '|' + url);
if (isDeployable(name, url))
{
// Obtain a jar url for the nested jar
URL nestedURL =
JarUtils.extractNestedJar(url, this.tempDeployDir);
// and store in it in map
+ log.debug("Storing name|nestedURL: " +
name + '|' + nestedURL);
extractedJars.put(name, nestedURL);
}
+ else
+ {
+ log.debug("Jar file not Deployable
(name|URL):" + name + '|' + url);
+ }
}
catch (MalformedURLException mue)
{
@@ -226,6 +232,10 @@
{
// The nested jar url was placed into
extractedJars above
URL nestedURL = (URL)
extractedJars.get(fileName);
+ //NOTE: If nulls show up in the next
line, check to make sure
+ //that ALL jars listed in the Ear's
application.xml file are
+ //actually present.
+ log.info("Creating subdeployment for
(filename|URL): " + fileName + '|' + nestedURL);
sub = new DeploymentInfo(nestedURL, di,
getServer());
}
// Set the context-root on web modules
-Steve
----------------------------------------------------------------------
Comment By: Stephen Davidson (northgorky)
Date: 2002-07-15 16:11
Message:
Logged In: YES
user_id=490856
After examing the MainDeployer.parseManifest function, I
have an issue with it. It is trying to do a FULL deploy of
all the jars listed in a jar file. This is a bad idea, for
several reasons. The only jars that should be fully
deployed are the ones listed in the Ear's application.xml
file, or that one of the scanners have decided to deploy.
What I view as the biggest flaw in this concept is that fact
that trying to deploy jars from jar manifest files gives two
places that an application in an Ear file could be deployed
from. When the deployer is reading from an Ear file, the
jars are in inconsistent states, and this can generate
problems like what we are seeing.
Therefore, I propose the following concept;
The parseManifest function should NOT try to fully deploy a
listed jar, but should instead make sure that the listed jar
is loaded by a Classloader, so that its classes are
available for usage. Until this is done, I recommend two
patches (to be listed in my next posting).
-Steve
----------------------------------------------------------------------
Comment By: Stephen Davidson (northgorky)
Date: 2002-07-12 20:49
Message:
Logged In: YES
user_id=490856
This was working from JBoss3.0 RC3 through 2 weeks ago.
When I updated this week was when my copy broke.
The ear file submitted is only a fraction of the entire
project. Unfortunately, it is not possible to execute the
suggested reconfiguration.
Common has base classes that Admin and Security classes both
extend.
Common also does some of the basic Security Authorization
(as JAAS was still under development when the Security model
was implemented), and therefore needs to talk to the
Security classes.
One of the Security EJBs needs to access an Admin EJB and
some Admin objects to do its thing.
And the Admin objects need to check security privileges
before deciding what and how to execute.
Hence the circularity.
These are the only Jars in the project where this is an
issue. The other Jars only normally rely on Security and
Common.
Thanks in advance for chasing down what broke. The way the
log and stack trace was going, I wonder if the issue is that
the Jars are not actually getting to the point where they
are deployed, or condsidered deployed? The Manifest appears
to be causing JBoss to try to deploy the Jars listed in the
Manifest before it deploys the one it is working on.
-Steve
----------------------------------------------------------------------
Comment By: Julien Viet (cooperfbi)
Date: 2002-07-12 19:46
Message:
Logged In: YES
user_id=337141
This problem come from the fact there are cross references
between jar libraries via classpath manifest :
Security.jar references Common.jar and Admin.jar
Common.jar references Security.jar
Admin.jar references Security.jar and Common.jar
I think the problem can be solved at first sight by breaking
circular references between libraries.
However there is something wrong in
MainDeployer.parseManifestLibraries().
There is a loop because the jar being deployed is not seen as
deployed by parseManifestLibraries.
I will try to solve the problem.
----------------------------------------------------------------------
Comment By: Stephen Davidson (northgorky)
Date: 2002-07-12 19:25
Message:
Logged In: YES
user_id=490856
This is a show stopper for me. I can not currently deploy
my EAR file because of this bug. Please somebody help?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=580190&group_id=22866
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
