Bugs item #589808, was opened at 2002-08-01 13: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: Scott M Stark (starksm)
Date: 2002-10-28 14:48
Message:
Logged In: YES
user_id=175228
And for now the third time in this bug report I am stating that I
agree this is a problem. As you state its easy to work around
and so when I have time I will fix it. Your whinning in this
report most likely put off others developers who could also
have fixed this issue. The bulk of this report is now rambling
junk off the topic of the bug which I don't appreciate. If you
want to rant use the forums or dev list.
----------------------------------------------------------------------
Comment By: David Bergman (davber)
Date: 2002-10-28 14:05
Message:
Logged In: YES
user_id=395691
Scott,
It is easy to become a jackass when you are treated in a
jackassingly fashion. You showed no interest in the issue,
and certainly did not confess that it was a problem at all.
But, it is. A problem for JBoss, so this is about helping JBoss
out in becoming a better, and even more compliant, product.
It is certainly not about helping me out, since I can always
apply the proper changes locally.
Did you get hurt by my former comment? If so, I apologize,
but that is the feeling I and others (in "offline" discussions)
get sometimes. So, there might be reason to change the
attitude and really treat people (experienced people, with
some having IQs well above 160) and their comments
seriously. That is the way to spread this product further.
Your comment including hard words does not help in that
respect. I did not use strong words and will not it either.
Else, we "pious" people will find other venues for our creativity
and our strive to produce the best J2EE infrastructure.
Best,
David "Pious" Bergman
----------------------------------------------------------------------
Comment By: Colin Sampaleanu (colins)
Date: 2002-10-28 13:58
Message:
Logged In: YES
user_id=71283
Is there any chance the two of you put aside the history on
this topic and somebody can get the code in, given that
everybody agrees the code needs to be fixed, and David has
offered to do the fix?
I think there was some confusion/misunderstanding here. To
be fair to David, when I read your post in question, Scott,
it was not terribly clear (to me) that you were in fact
agreeing that it was a problem which should be fixed. The
first sentence did quote the proper behaviour from the spec,
but then the rest of the same paragraph went on to basically
say nobody should be doing this anyways.
Regards,
Colin
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2002-10-28 13:43
Message:
Logged In: YES
user_id=175228
And my comment date 2002-08-01 14:23
clearly states I agree this is a problem: "The spec states
that jars referenced through manifests should not be used as
j2ee component deployments."
Perhaps if you weren't being such a pious jackass here more
developers would be inclined to help you out.
----------------------------------------------------------------------
Comment By: David Bergman (davber)
Date: 2002-10-28 13:20
Message:
Logged In: YES
user_id=395691
I can easily fix this problem. Just got a bit tired of starksm
comments, and temporary inability to see this as the obvious
non-compliance to the J2EE 1.3 it actually is. I appreciate he
has got a lot to do, not always having time to penetrate each
comment thoroughly.
One just have to add a flag to the JAR deployment informing
whether it should be J2EE-deployed or merely added to the
internal classpath, and use the latter variant when dealing
with indirect (through MANIFEST.MF) deployables. And, of
course, make sure that a subsequent real deployment
(through application.xml etc.) of the JAR does not choke on
the previous partial deployment, but rather just leave
classpath forest as is, and add the J2EE stuff...
If I get a message from starksm that he realizes that the
current behavior is non-compliant, I will attach updated files,
fixing this problem.
Sometimes Open Source means "a gang of presumed
geniuses showing off their superiority, and even sharing their
creations with less fortunate developers". In this particular
case, the gang even make money on the Open Source
product (documentation, consulting etc..) But, this semi-
openess has actually led to a great product, so it might be
the way to go.
Best
----------------------------------------------------------------------
Comment By: Colin Sampaleanu (colins)
Date: 2002-10-28 13: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 10: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 09: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 14: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 14: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 14: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 14: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 13:53
Message:
Logged In: YES
user_id=175228
Just show me the exception.
----------------------------------------------------------------------
Comment By: David Bergman (davber)
Date: 2002-08-01 13: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 13: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 13: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 13: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 13: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
