Bugs item #589808, was opened at 2002-08-01 16:17
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=589808&group_id=22866
Category: JBossServer
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: David Bergman (davber)
Assigned to: Nobody/Anonymous (nobody)
Summary: EJB Jars already deployed by MANIFEST.MF
Initial Comment:
It is currently impossible to use "auxiliary" code
belonging to one EJB Jar EJB1.jar in another EJB Jar,
EJB2.jar.
This problem arises now when (finally, after a few wronly
claimed closures) the handling of dependent Jars,
through MANIFEST.MF, really looks in the right
directory (it used to look in EJB2.jar itself, no good...)
Since JBoss does not make a clear distinction between
EJB-deployments and regular JAR-deployments, the
deployment of EJB1.jar fails with an error:
javax.management.InstanceAlreadyExistsException:
blah,blah,blah (no this is not important, since the
problem is very clearly defined)...-contents/EJB1.jar
already registered.
I.e., the MANIFEST.MF-deployment process beats the
regular EJB-deployer to the EJB1.jar.
We can also bypass this problem by enforcing ALL
auxiliary code to be put in non-EJB Jars, but would it not
be nicer to be able to deploy any J2EE-compliant
application.
So, "we" (I am not an active member) have to either (1)
differentiate between real deployment (e.g. EJBs) and
MANIFEST-dependent deployments, or (2) be silent
when we encounter a "MANIFEST"-deployed module
again.
Thanks for a great product!
----------------------------------------------------------------------
>Comment By: David Bergman (davber)
Date: 2002-08-01 17:26
Message:
Logged In: YES
user_id=395691
Am forced to sit in front of a Windows machine, I slipped with
the uploading... Not a super-user yet.
Here comes the log file.
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2002-08-01 17:23
Message:
Logged In: YES
user_id=175228
The spec states that jars referenced through manifests
should not be used as j2ee component deployments. Using
a manifest classpath reference is completely unnecessary
between ejb jars. The intent is to reference jars included in
an ear that are not j2ee application modules referenced in
the application.xml descriptor. The trival fix is to remove the
classpath references from the ejb-jar manifests.
----------------------------------------------------------------------
Comment By: David Bergman (davber)
Date: 2002-08-01 17:16
Message:
Logged In: YES
user_id=395691
But, can we not agree that nested deployments should not be
full-fledged deployments?
Well, I will show you the exception. By the way, if you do not
want input from the community in helping make JBoss even a
better product, state that clearly: that you only want reports
of the effects, not opinions on the causes.
I thought it would be helpful to get to know the exact cause of
this malbehavior, instead of just its symtoms.
I attach the log output, which is quite big (sorry about that).
The MANIFEST.MF for CommunityMiner-ejb.jar contains
ClassPath: espressChart.jar.
Both CommunityMiner-ejb.jar and espressChart.jar contain
EJBs and are included in the J2EE/JBoss descriptors.
Am waiting for you to show me my mistake,
Thanks.
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2002-08-01 16:53
Message:
Logged In: YES
user_id=175228
Just show me the exception.
----------------------------------------------------------------------
Comment By: David Bergman (davber)
Date: 2002-08-01 16:51
Message:
Logged In: YES
user_id=395691
No, you are thinking about the reverse situation, i.e., where
EJB1.jar is deployed at the top-level and then EJB2.jar
(through the MANIFEST dependency) tries to nestly deploy it
again. That situation is handled, by the condition in
MainDeployer.java:907.
Trust me, there is no equivalent code if the nested
deployment find the EJB1.jar first...
----------------------------------------------------------------------
Comment By: David Bergman (davber)
Date: 2002-08-01 16:44
Message:
Logged In: YES
user_id=395691
The general point is that nested deployments through the
MANIFEST-dependencies should not be full J2EE
deployments. There is no support for that behavior in the
J2EE specifications, as far as I know (but I am just a C++
programmer...). The only thing one wants by the
MANIFEST.MF:ClassPath declaration is to make certain
classes visible by the ClassLoader...
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2002-08-01 16:43
Message:
Logged In: YES
user_id=175228
This should work in the latest head codebase. Show me the
exception you are seeing with a snapshot from today.
----------------------------------------------------------------------
Comment By: David Bergman (davber)
Date: 2002-08-01 16:40
Message:
Logged In: YES
user_id=395691
starksm,
if the EAR contains two files: EJB1.jar and EJB2.jar, both
containing EJBs (with at least one JBoss descriptor)
and the MANIFEST.MF file of EJB2.jar contains the following
ClassPath: EJB1.jar
and EJB2.jar is tried by MainDeployer before EJB1.jar, then
the nested deployment in lines 887-921 of MainDeployer.java
will force deployment of EJB1.jar, and when the top-level
deployment process subsequently reaches EJB1.jar, we get
the InstanceAlreadyExistsException.
I hope this is clear.
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2002-08-01 16:26
Message:
Logged In: YES
user_id=175228
Give an explicit example of what you are talking about here.
What manifests are referencing what jars in what overall
deployment structure.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=589808&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
