-
1. Re: upgrade to WTP 2.0.2 breaks EAR deployment in JBoss Tool
erimag Mar 6, 2008 4:51 AM (in response to erimag)The order of installation/update does not seem to matter.
It seems like this might be a bug in WTP2.0.2 -
2. Re: upgrade to WTP 2.0.2 breaks EAR deployment in JBoss Tool
baz Mar 6, 2008 6:41 AM (in response to erimag)I can verify this.
Yesterday i changed to eclipse-jee-europa-winter which includes WTP2.0.2
After reading this post, i setup a new seamproject(2.0) which leads to this exception:12:36:16,234 ERROR [MainDeployer] Could not initialise deployment: file:/E:/IDE/jboss-4.2.2.GA/server/default/deploy/seamear-ear.ear/ org.jboss.deployment.DeploymentException: url file:/E:/IDE/jboss-4.2.2.GA/server/default/deploy/seamear-ear.ear/seamear-ejb.jar could not be opened, does it exist?
Ciao,
Carsten -
3. Re: upgrade to WTP 2.0.2 breaks EAR deployment in JBoss Tool
maxandersen Mar 6, 2008 7:07 AM (in response to erimag)sounds more like a WTP bug than a jboss tools bug to me...
-
4. Re: upgrade to WTP 2.0.2 breaks EAR deployment in JBoss Tool
erimag Mar 6, 2008 9:27 AM (in response to erimag)I've gotten it to work by NOT including any dependent jars in application.xml - then they are deployed in the ear. If I do include them in application.xml (they are automatically put there if I choose to generate deployment descriptor) they are left out of the ear.
-
5. Re: upgrade to WTP 2.0.2 breaks EAR deployment in JBoss Tool
maxandersen Mar 6, 2008 9:41 AM (in response to erimag)besides that actually being correct (e.g. not listing them in application.xml) i don't follow why that should affect it ;(
does it work with eclipse 3.2.1/wtp 2.0.1? -
6. Re: upgrade to WTP 2.0.2 breaks EAR deployment in JBoss Tool
baz Mar 7, 2008 2:19 AM (in response to erimag)I have reactivated my old eclipse configuration.
With eclipse-jee-europa-fall2 WTP(2.0.1) i get the same failure as with
eclipse-jee-europa-winter(WTP 2.0.2) -
7. Re: upgrade to WTP 2.0.2 breaks EAR deployment in JBoss Tool
erimag Mar 7, 2008 2:49 AM (in response to erimag)It worked for me under Eclipse 3.2.1/wtp2.0.1, but something weird happened in the updates after that. I'm not sure if it was the application.xml or some other settings that I tweaked, but now it's working again, so I'm not touching it ;)
BTW, any ETA on JBoss Tools 2.0.1? :) -
8. Re: upgrade to WTP 2.0.2 breaks EAR deployment in JBoss Tool
baz Mar 7, 2008 2:58 AM (in response to erimag)There is this difference between my 2 eclipse installations:
For eclipse-jee-europa-fall2 i get the error when i first deploy my project with Run as/run on server
But after the server is started i can do a clean in the Jboss server view and all is well. No error and the app is running.
It is this clean which does not work with eclipse-jee-europa-winter :-(
Eclipse displays an error box when i do the cleanResource '/tre-ejb/build/classes' does not exist.
-
9. Re: upgrade to WTP 2.0.2 breaks EAR deployment in JBoss Tool
maxandersen Mar 7, 2008 4:58 AM (in response to erimag)i'm curious...i never heard about winter, fall, summer editions...where do you get those names from ? i'm used to specific version numbers ,)
-
10. Re: upgrade to WTP 2.0.2 breaks EAR deployment in JBoss Tool
baz Mar 7, 2008 5:06 AM (in response to erimag)Hi max,
thats the names of the downloadbundles which ia am grabbing directly from the eclipse downloadsite.
http://www.eclipse.org/downloads/
When you download a current, specific bundle, say Eclipse IDE for Java EE Developers , it has the name eclipse-jee-europa-winter which was released a couple of days ago.
I have never used the Eclipse Classic bundles. These are the only bundles with version names:-) -
11. Re: upgrade to WTP 2.0.2 breaks EAR deployment in JBoss Tool
maxandersen Mar 7, 2008 5:49 AM (in response to erimag)never noticed that. It's sweet, but rather annoying since they have might have more than 1 patch release per quarter...thanks for the education.
-
12. Re: upgrade to WTP 2.0.2 breaks EAR deployment in JBoss Tool
rituraj_tiwari Mar 10, 2008 1:12 AM (in response to erimag)I encountered the same problem as Baz (seam jar missing). Erimag's tip on editing application.xml helped.
Now I have a new problem. The ejb module as created by Eclipse is missing the META-INF folder. The first error this causes is missing persistence unit. This is followed by a flurry of exceptions that I did not care to follow up.
My Eclipse version is: 3.3.2
Build id: M20080221-1800
I am using the latest drop of Jboss tools with Seam 2.0 (since the tools refuse to work with Seam 2.1).
Any pointers on how to get Eclipse to build the deployment correctly?
My project is a "Seam Web Project". Is this a JBoss issue or do I need to go to an Eclipse forum?
Thanks for your help. -
13. Re: upgrade to WTP 2.0.2 breaks EAR deployment in JBoss Tool
maxandersen Mar 10, 2008 6:46 AM (in response to erimag)we are still investigating this...I don't know why it started happening out-of-the-blue.
I created http://jira.jboss.com/jira/browse/JBIDE-1862 for tracking it. -
14. Re: upgrade to WTP 2.0.2 breaks EAR deployment in JBoss Tool
rob.stryker Mar 12, 2008 7:58 PM (in response to erimag)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