[jboss-user] [JBoss Tools (users)] - Re: upgrade to WTP 2.0.2 breaks EAR deployment in JBoss Tool

[rob.stryker@jboss.com]

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 at 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#4136153

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136153