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-16 20:33
Message:
Logged In: YES
user_id=360804
Ok, I mixed my scenarios a bit. Thats what I found lastly
1) as Scott wrote: the provided jar, as well as my examples,
work right when removing the mf entries and packaging the
application as "ear-zip".
2) The UnifiedClassLoader fails to load classes when using
an unpacked scenario (as I did). I will have some deeper
lookings in the source of the UnifiedClassLoader. Buts thats
out of the scope of this bug.
Markus
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2002-07-16 15:33
Message:
Logged In: YES
user_id=175228
Post an ear that demonstrates that problem as if I remove
the ClassPath entries from the attached DeployDemo.ear
using JBoss-3.0.1RC1 it deploys fine.
08:43:16,328 INFO [MainDeployer] Starting deployment of
package: file:/G:/JBoss
Releases/jboss-
3.0.1RC1/server/default/deploy/DeployDemo.ear
08:43:16,390 INFO [EARDeployer] Init J2EE application:
file:/G:/JBossReleases/j
boss-3.0.1RC1/server/default/deploy/DeployDemo.ear
08:43:17,140 INFO [EjbModule] Creating
08:43:17,171 INFO [EjbModule] Deploying UserEJB
08:43:17,390 INFO [EjbModule] Deploying USER_DATA
08:43:17,406 INFO [EjbModule] Deploying
UserHistorySessionEJB
08:43:17,437 INFO [EjbModule] Deploying
SecurityProfileSessionEJB
08:43:17,453 INFO [EjbModule] Deploying
ProfileAppsSessionEJB
08:43:17,484 INFO [EjbModule] Deploying
ProfileFeaturesSessionEJB
08:43:17,515 INFO [EjbModule] Deploying
ProfileUsersSessionEJB
08:43:17,531 INFO [EjbModule] Deploying
SecurityConfigSessionEJB
08:43:17,562 INFO [EjbModule] Deploying
UserProfilesSession
08:43:17,578 INFO [EjbModule] Deploying
UsrQuicklistSession
08:43:17,875 INFO [EjbModule] Created
08:43:18,109 INFO [EJBDeployer]
Bean : InvoiceSessionEJB
Method : public abstract InvoiceSession create() throws
CreateException, RemoteE
xception
Section: 6.10.6
Warning: All the exceptions defined in the throws clause of
the matching ejbCrea
te(...) method of the enterprise bean class must be included
in the throws claus
e of a matching create(...) method.
08:43:18,140 INFO [EjbModule] Creating
08:43:18,171 INFO [EjbModule] Deploying
ApplicationSessionEJB
08:43:18,187 INFO [EjbModule] Deploying
FeatureSessionEJB
08:43:18,218 INFO [EjbModule] Deploying
MenuSessionEJB
08:43:18,250 INFO [EjbModule] Deploying
MenuItemSessionEJB
08:43:18,265 INFO [EjbModule] Deploying
LanguageSessionEJB
08:43:18,296 INFO [EjbModule] Deploying
InvoiceSessionEJB
08:43:18,312 INFO [EjbModule] Deploying
CustomerStatusMgmtSessionEJB
08:43:18,484 INFO [EjbModule] Created
08:43:18,484 INFO [EjbModule] Starting
08:43:18,921 INFO [EjbModule] Started
08:43:18,921 INFO [EjbModule] Starting
08:43:19,187 INFO [EjbModule] Started
08:43:19,187 INFO [MainDeployer] Deployed package:
file:/G:/JBossReleases/jboss
-3.0.1RC1/server/default/deploy/DeployDemo.ear
----------------------------------------------------------------------
Comment By: Markus Kling (mkling)
Date: 2002-07-16 13:07
Message:
Logged In: YES
user_id=360804
As I wrote before I could fix my first scenario while removing
the mf entries from the jar files -> all classes were visible to
each other.
But the deployer, more detailed the Verifier, throws
NoClassDef. Exceptions while deploying dependant ejb-jars. I
tried this scenario with the BRANCH_3_0 and HEAD version.
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2002-07-15 19:52
Message:
Logged In: YES
user_id=175228
The change that broke your questionable deployment was to
fix mf references to non-ejb jars. There is no reason to
reference ejb jars in an ear through the manifest as all
classes in the these jars are visible to each other. Your
deployment worked before because the manifest references
were not working. The simple fix is to drop the manifest
classpath in the ejb jars. In what context are they required?
We will prevent the looping such deployments cause.
----------------------------------------------------------------------
Comment By: Stephen Davidson (northgorky)
Date: 2002-07-15 18:11
Message:
Logged In: YES
user_id=490856
That scenario I think I already have, and I can speak from
happy experience that this patch covers that scenario, at
least currently.
The scenario I have is that stuff (including EJBs) in
Security extends stuff in Common, calls stuff in Common, and
passes stuff from common. To go into a little more depth,
most of the 90+ EJBs in my application extend from BaseEJB
classes in the Common.jar, and passes DataTokens that also
extend from classes in Common, but are defined in their
respective jars. The are passed back and forth between the
various EJBs, Servlets, and JSPs, and so far no problems.
As to how this would work with lib/jars is not a question I
have been able to answer.
I hope this answers your question.
-Steve
----------------------------------------------------------------------
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: Jabber - The world's fastest growing
real-time communications platform! Don't just IM. Build it in!
http://www.jabber.com/osdn/xim
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
