[jboss-user] [JBoss Tools (users)] - Re: upgrade to WTP 2.0.2 breaks EAR deployment in JBoss Tool
Ok... so here's what I've discovered so far. Methodology is similar to yours.
Open an eclipse with wtp-2.0.1 workspace and create a seam project (seam 2), make sure it
deploys appropriately (it does), close down eclipse.
Open a new eclipse with wtp-2.0.2 but use the same workspace.
The very first thing I notice is a stacktrace in the output (starting from command-line).
Trace is as follows:
[rob@localhost eclipse]$ ./eclipse
Listening for transport dt_socket at address: 4000
*** ERROR ***: Wed Mar 12 19:27:50 EDT 2008
org.eclipse.jst.j2ee.commonarchivecore.internal.exception.OpenFailureException: IWAE0006E
Archive is not a valid Application Client JAR File because the deployment descriptor can
not be found (case sensitive): META-INF/application-client.xml
at
org.eclipse.jst.j2ee.internal.componentcore.EnterpriseBinaryComponentHelper$ArchiveCache.openArchive(EnterpriseBinaryComponentHelper.java:339)
at
org.eclipse.jst.j2ee.internal.componentcore.EnterpriseBinaryComponentHelper.openArchive(EnterpriseBinaryComponentHelper.java:149)
at
org.eclipse.jst.j2ee.internal.componentcore.EnterpriseBinaryComponentHelper.getUniqueArchive(EnterpriseBinaryComponentHelper.java:79)
at org.eclipse.jst.j2ee.internal.componentcore.AppClientBinaryComponentH
elper.getPrimaryRootObject(AppClientBinaryComponentHelper.java:110)
at org.eclipse.wst.common.componentcore.ArtifactEdit.getContentModelRoot
(ArtifactEdit.java:540)
at org.eclipse.jst.jee.internal.deployables.JEEDeployableFactory.createB
inaryModules(JEEDeployableFactory.java:163)
Tracing through, this happens during startup for me because I made sure to have the
JBossServers view up which probably helped force the initialization of the deployable
factories. blah blah ;) Moving along.
I stopped the trace at createBinaryModules because this, I feel, is the important part.
This is where the model for this project is started. Looking at the code for this
method, we see the following. (context: It's parsing through the list of objects in
the application.xml's module tags). Here are some snippets.
| if (moduleComponent.isBinary()) {
| // create an ear edit, app only if the module is binary prevents exceptions when
there
| // is no deployment descriptor in many cases see bug 174711
| if(earEdit == null){
| earEdit = EARArtifactEdit.getEARArtifactEditForRead(component.getProject());
| app = earEdit.getApplication();
| }
| // if we are missing the application.xml, cannot check for module URI so assume an
archive
| if (app == null) {
| continue;
| }
|
So it's obvious they're trying to make sure if it's binary and has no
application.xml, to just give up on it and accept that it's a generic archive.
The problem is despite their best efforts, this is not working. It is returning something.
app is not null. The code fails at the following place.
| else if (j2eeModule.isJavaModule()) {
| moduleEdit = ComponentUtilities.getArtifactEditForRead(moduleComponent,
| J2EEProjectUtilities.APPLICATION_CLIENT);
| ApplicationClient appClient = (ApplicationClient) moduleEdit.getContentModelRoot();
| moduleType = J2EEProjectUtilities.APPLICATION_CLIENT;
| moduleVersion = appClient.getVersion();
| }
|
So basically, the top snippet tries to screen out generic java modules, but somehow fails.
When it gets to the second snippet, it's assuming it's an application client jar,
not a generic archive.
This is most definitely an upstream wtp bug and I will mark it as such and push it to tim
and the server team. I'll also continue looking into it and try to provide a patch to
eclipse.
- Rob
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136153#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...