8:55 p.m.
[
https://jira.jboss.org/jira/browse/JBDS-427?page=com.atlassian.jira.plugi...
]
Rob Stryker commented on JBDS-427:
----------------------------------
This issue, while its results seem like deja-vu, seems different at its core than any
others we've had so far (no others mentioned IModelProvider before as the root cause).
I've commented extensively on this issue in the issue-tracker, however, I'll try
to re-iterate what I discovered.
First of all, let's not forget our issue before releasing JBDS1.1 was that the
upstream ability to discover what type of jar was on their hands was very limited, and we
needed to patch their jars. This, despite the fact that their HEAD code (AKA the current
3.x stream) had already changed and fixed most if not all of the problems and the ability
to recognize jar types (ear, ejb, etc) and versions.
Basically, JBDS 1.1 is using old outdated wtp code which has had SUBSTANTIAL changes since
then. As we're not releasing a patch to JBDS 1.1 (as far as I know), and the future
version is likely to come with the latest and greatest upstream fixes, the only thing I
can do is to see what's going on in the newest stream. Again, the changes are vast.
This is compounded by the fact that this issue supposedly only occurs in windows, which
means I need to locate a windows box and do this for a day.
The only thing I've been able to discover is that, in the old JBDS-1.1 (plus pre-reqs)
code, our patch changed only the JEEDeployableFactory class, which is what turns this jar
into a module. It's possible that some OTHER piece of code which I did not know about
or patch was somewhere using the same logic and did not benefit from the patch. This
seems to have thrown a wrench directly in the Virtual Component Model. Again, in the past
all the bugs happened in the layer AFTER the virtual component model. The previous bugs
all existed in the JEEDeployableFactory, which took information from the VCM and turned it
into a module. Here, the issue seems to lie much lower in the VCM, which honestly is code
I am not familiar with yet.
However, like I said before, WTP's ability to properly determine jar type has improved
vastly. They've created classes dedicated to figuring this out and so should not have
the problem of duplicate code. I seriously do not expect this issue to still be present.
However I obviously cannot close the issue just based on expectation.
The lack of a stack trace of the VCM's problem also makes this harder as it gives me
very little clue where to start. Either way, something somewhere does not like our
jboss-seam.jar, and it seems to be deep in the VCM.
Seam EARs are not correctly deployed on windows
-----------------------------------------------
Key: JBDS-427
URL: https://jira.jboss.org/jira/browse/JBDS-427
Project: Developer Studio
Issue Type: Bug
Affects Versions: 1.1.0.GA
Environment: Windows only (2000 & XP), Seam 2.0.2SP1, Sun JDK 1.5.0_16
Reporter: Jeronimo Ginzburg
Assignee: Rob Stryker
Priority: Blocker
Fix For: 2.0.0.beta1
JBDS often doesn't include or update some files when deploying Seam EARs. This only
happens on the JBDS 1.1.0GA win32 version. We couldn't reproduce this wrong behavior
neither in RHEL version nor in JBoss Tools 2.1.2 over eclipse 3.3.2-win32 using WTP
2.0.3.
At the same time the error is not *always* exactly reproducible. The missing or not
updated files are not always the same. In one occasion a jar was deployed with 0 kb size.
Following is a more detailed description of the steps performed in the customer
environment and later reproduced in my machine with *more or less* similar problems.
1) Windows 2000 and the JBDS win32 1.1.0 GA distribution (in my case I installed Win 2000
SP4, but the customer has XP). I was using Sun JDK 1.5.0_16.
2) I generated a new Seam Web Project called "aProject" using Seam 2.0.2SP1
with the EAR packaging option.
3) I published the new blank application to the JBoss EAP 4.3 (included in the JBDS
distribution)
The first thing I noticed was that the EJB files (in this case Authenticator.class and
others) WERE NOT COPIED. (This didn't happened at the customer)
I tried stoping/restarting the AS/deleting the ear folder, redeploying the application
several times. Finally the files were deployed. (Note that I hadn't changed the
project settings for getting it done)
4) I removed jboss-seam.jar from the EJB manifest file. I added it as an external jar to
the ejb project. (this is because of a reported bug)
5) I created a new Java project called "core". I included an external jar file
("model.jar") on the build path of this project and I checked
"model.jar" to be exported to other dependant projects.
I coded a reference to a model.jar class in the "core" project. Later I coded a
reference to a class from core project inside Authenticator class login method.
I made "aProject-ejb" and "aProject-ear" to depend on
"core" (in the project references)
In the J2EE module dependencies of core project I checked core.jar and model.jar
I the build path of aProject-ejb I included core. I also checked it for export
In the aProject-ear J2EE module dependencies I checked core.jar (model.jar is
automatically included)
(Note: Perhaps I'm forgetting to write any substep here. The result must be that the
ear package must contain model.jar and core.jar)
5) I published the seam application to the AS. In this case all the files were copied but
on the customer, sometimes core.jar or model.jar were not copied or copied with 0 kb size
6) I logged in. A class not found exception was thrown because I forgot to include
core.jar and model.jar in the EJB Manifest file classpath.
I added it to the manifest file. I saved the file. I published the application again. The
deployed manifest file is not updated. I made some retries and nothing happened. Then I
realized the manifest file date was about 30 minutes later than the local time of my
machine. So I changed the time (+35 minutes) and then after republishing the file was
updated.
Errors:
*** ERROR ***: Wed Sep 17 17:34:13 ART 2008 No IModelProvider exists for virtual
component P/aProject-ear aProject-ear/EarContent/jboss-seam.jar of version: null
(An exception stack trace is not available.)
/////////////////////////////// (other error only in the case of the 0kb deployed jar):
unable to assemble module
java.util.zip.ZipException: ZIP file must have at least one entry
at java.util.zip.ZipOutputStream.finish(Unknown Source)
at java.util.zip.DeflaterOutputStream.close(Unknown Source)
at java.util.zip.ZipOutputStream.close(Unknown Source)
at
org.jboss.ide.eclipse.as.core.server.xpl.ModulePackager.finished(ModulePackager.java:58)
at
org.jboss.ide.eclipse.as.core.publishers.JstPublisher.packModuleIntoJar(JstPublisher.java:332)
at
org.jboss.ide.eclipse.as.core.publishers.JstPublisher.fullPublish(JstPublisher.java:138)
at
org.jboss.ide.eclipse.as.core.publishers.JstPublisher.publishModule(JstPublisher.java:112)
at
org.jboss.ide.eclipse.as.core.server.internal.DeployableServerBehavior.publishModule(DeployableServerBehavior.java:132)
at
org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:749)
at
org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:835)
at
org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:669)
at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:887)
at org.eclipse.wst.server.core.internal.Server.publish(Server.java:874)
at org.eclipse.wst.server.core.internal.PublishServerJob.run(PublishServerJob.java:72)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira