Bugs item #589808, was opened at 2002-08-01 20: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: Colin Sampaleanu (colins)
Date: 2002-10-28 21:05
Message:
Logged In: YES
user_id=71283
Does anybody with a good enough knowledge of JBoss have the
bandwidth to fix this bug? It is a pretty serious
non-compliance with the J2EE 1.3 spec, which makes it a big
pain sometimes to deploy third party EJBs without having to
do modifications on them.
Given that the spec says this behaviour should be allowed,
that should completely be the end of the argument. Even if
as mentioned previously (by Scott), it is possible in your
own projects to set up your beans so they don't have
manifest classpath references to jars containing other beans
(and forcing the current JBOSS code to try to redploy thos
other beans again), a number of 3rd party EJBs do include
such references. To use these EJBs I now have to go into
them and modify the entries.
What is interesting (and relevant) is that if the
application is not deployed as an ear but rather as an
exploded directory version of that ear, the problem does not
happen. If it can work properly for exploded ears, what is
the issue with normal ears?
Regards,
Colin
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2002-10-02 17:04
Message:
Logged In: NO
My post of 2002-10-02 09:57 refers to JBoss version 3.0.2.
Cheers, Matt
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2002-10-02 16:57
Message:
Logged In: NO
I've come across the same problem (I think). I have a 3rd
party supplied JAR, up.jar, which contains client code *and*
EJB code including the ejb-jar.xml deployment descriptor.
I've have listed up.jar in my WAR's manifest classpath. Both
the WAR and up.jar are packaged in an EAR. The
application.xml only defines the WAR as a module.
As JBoss deploys the WAR, the EJBs in up.jar are also
getting deployed even though the application.xml does not
list up.jar as an EJB module.
I would expect *only* the modules explicitly defined in
application.xml to get deployed but it seems that anything
that looks even vaguely deployable is getting deployed.
----------------------------------------------------------------------
Comment By: David Bergman (davber)
Date: 2002-08-01 21:47
Message:
Logged In: YES
user_id=395691
The situation of having code in one EJB jar being used by the
code in another EJB jar in the manner described is obviously
a bit contrived, and one should clearly put "auxiliary" classes
in a separate jar file, just as you suggested.
However, I have not seen that restriction in the J2EE specs,
but instead seen the phrase "Any deployment descriptors in
references .jar files are ignored when processing the
referencing .jar file". This phrase not only suggests that it
indead is possible, according to specs, to have an EJB jar in
the MANIFEST ClassPath, but also that the current full-
fledged nested deployment of JBoss is wrong.
Am still waiting for you to show me my mistake. It is better
for everyone if we do not assume people to be wrong from the
start...
The current behavior of failing to deploy in this case is simply
wrong. It is easy to fix in the current implementation, though.
Thanks,
David
----------------------------------------------------------------------
Comment By: David Bergman (davber)
Date: 2002-08-01 21: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 21: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 21: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 20:53
Message:
Logged In: YES
user_id=175228
Just show me the exception.
----------------------------------------------------------------------
Comment By: David Bergman (davber)
Date: 2002-08-01 20: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 20: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 20: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 20: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 20: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
