[Curtis J Reinke]

I searched the forum for the problem we are having and found multiple references similar to this issue. However, most of the problems reported were for earlier version of MyEclipse and/or for app servers other than WL8.1. Anyway …

The problem we are having is that we have a 3rd party EJB jar that we wanted included in various EAR Projects. Our process is as follows:

I create a standard Java Project that uses Ant script to modify various EJB descriptor files as necessary, and compile (wlappc) a new EJB.jar, i.e., create project, explode jar, modify deployment descripts as necessary, use Ant script to invoke wlappc that builds a new jar (including modified deployment descriptors and generated stubs and skels). The newly created jar is created in the base of the EAR and is named using the standard jar extension.

I then refresh the EAR project. This signals MyEclipse that a change has been made to a file in the EAR and marks the EAR as needing redployment

I then use the MyEclipse deployment feature to build and deploy my EAR

When using the packaged deploy, the EAR deploys and works as expected, however, when using the exploded deploy, the MyEclipse builder/deployer drops the .jar extension from the EJB module element in the application.xml

My Weblogic instance then spits out a message saying that the EJB jar could not be located

To resolve the issue, we hand modify the deployed application.xml back to include the .jar extension

Obviously, we don’t want to continue to do this as each time we redeploy our EAR, however, from the FAQs I read, the solution is unclear. Some FAQs say that WL8.1 does not like EJB modules named with a .jar extension, however, that is not the case according to the tests (described above) that we’ve done. Another FAQ eluded to submitting a report to your development group for clarification/resolution, but I could not find anything later that addressed this futher.

So, bottom line, how do we handle this type of problem short of hand modifying the built application.xml?

BTW, the reason we want to use the exploded format is so that we can use the Hot Deploy feature. I submitted a previous question to you regarding this and the answer was that we needed to deploy using the exploded EARs.

[Riyad Kalla]

creinke,
Thank you for the report, I kicked this back to one of the devs and they think you might have run across a bug here. Can you create some stubbed out test projects that exhibit exactly this problem, and then export them all (File > Export > To ZIP) and email them to us, support@genuitec.com ATTN Riyad with a link to this post. Then I can verify the behavior and attach the example to a bug report so we can get this fixed ASAP.

[Curtis J Reinke]

Well, it would be much easier if I walked you through it. You should be able to contruct a test case in 5 minutes. However, I don’t think this is a bug so much as an oversight perhaps that you may not have considered. That is what we are trying to determine.

Our situation is that we merely have a 3rd party EJB jar, supplied to us by someone else, for which we have no sources, just a jar with classes and deployment descriptors, and manifests, that we need to deploy with our Enterprise Application to an application server. In our case, the application server is Weblogic 8.1. So we explode the jar, change the deployment descriptors as necessary, generate the necessary stubs and skeletons using WL8.1 appc, and produce a deployable EJB.jar ready for deployment with our enterprise application. As such, it is just a jar file that that we can choose to manage inside or outside Eclipse/MyEclipse. However, to include this in the EAR deployment, we have to manually edit the EA’s application.xml and include an EJB module entry as follows:

<module>
<ejb>atdEJB.jar</ejb>
</module>
[/list]

We are fully aware that you regenerate that application.xml when you add a new module and do not preserve our entry. We don’t like that and wished you processed the application.xml better so that any entries placed there manually were preserved. When we are completely through with our evaluation, I’ll be submitting a list of improvements that we’d like to see. However, at this time, we are just working around various issues to finish our evaluation.

I guess we had to accept that you were going to wipe out our entry in the application.xml when you added/deleted a new module, but when you mucked with it once again when you built and deployed it, this makes it difficult to manage 3rd party EJBs for the following reasons: One that you did this without informing us that you did and that it took a lot of work to determine that that is what you did (sour grapes), two that we now need to modify the deployed application.xml manually, three that the deployment isn’t seamless, and four because the process we went trhough for creating a packaged EAR is different that that of creating an exploded EAR. Our feeling was that someone else out there must be deploying 3rd party EJBs with their application and just want to know how they did it.

So the steps to reproduce this are simple: In a separate workspace create an EJB Project/jar complete with DDs, stubs and skels. In a separate workspace create an EA and use that external jar. How did you make this work?

[Scott Anderson]

Excellent description of the problem. And, you’re right, it’s not a *bug* per se but an edge case we never considered. We’ve now got a high-priority bug report to remind us to address this in the 4.0 development schedule. Thanks for bringing it to our attention and taking the time to document it to such a level that we can immediately see the issue and therefore act on it.

When we are completely through with our evaluation, I’ll be submitting a list of improvements that we’d like to see. However, at this time, we are just working around various issues to finish our evaluation.

Excellent! User requests drive this product and I think you’ll see that our dev team is very responsive.

[Curtis J Reinke]

Thanks. I appreciate the response. Looking forward to 4.0.

[Scott Anderson]

We can’t wait either. It’ll be public on 3.1 any day now. 🙂

[Zion.Lo]

Hello, with respect to the last post by scott, will there be a patch for 3.8.3 any time soon? This problem is exactly what I am facing right now. I have a primary EJB project which gets exploded, but I also have a number of third-party EJB jars that I am trying to include, but since all extensions get stripped out in application.xml, weblogic is having problems. As an intermediate solution, I have an ANT script to coax the application.xml back to a usable form. Not ideal, but I needed a workaround. The JBoss deploy, on the hand, works flawlessly (none of the extensions get stripped off, and both exploded and packaged EJBs are named as specified in application.xml).

[Scott Anderson]

In MyEclipse 4.0M3 we’ll have a project setting for Enterprise Projects that will allow you to manually manage the application.xml file and protect it from being overwritten. I think that will address the issue. However, we do not plan on backporting that or any other changes to the Eclipse 3.0/MyEclipes 3.8.4 platform at this time.

[Zion.Lo]

Hi, in MyEclipse 4.1, I have checked the box “Do not modify ‘application.xml’ (I will manually manage it)” in the properties of my EAR projects and have tried to deploy, but am finding that the application.xml is still being updated as before. I deploy an exploded archive along with third party jars (same as my post back in August), and the “.jar” extensions are still getting stripped off. I have also recreated my EAR project and deployed anew, but am experiencing the same results. Can you verify if this is a bug and if there is another setting somewhere that I need to set make this work correctly? Thanks!

[Scott Anderson]

Zion,

I tried to recreate this problem using the following steps but could not.
1) Created EAR, Web, and EJB projects
2) Set the MyEclipse-EAR project property to manually manage application.xml
3) Opened application.xml in the XML editor and changed the names of the web archives
4) Deployed the application in exploded format to Geronimo
5) Opened the deployed application.xml file in an editor and verified that it was exactly what I changed it to manually

Since this is working for me, can you provide me with the exact steps you used that show the application.xml overwrite issue?

[Zion.Lo]

Hi Scott, I guess I forgot to mention in my last post that this occurs for Weblogic deployments. Although I don’t have Geronimo, I do have JBoss, and the deployment in JBoss works just fine. You can follow the same steps as you detailed, but with Weblogic as the target. Thanks for the fast response!

[Scott Anderson]

Zion,

The deployer is the same for all the servers. However, just to verify I deployed the same project exploded to WebLogic with the server shutdown. I then opened the application.xml file in the deployed location and it was exactly as I changed it. Can you tell me *exactly* when you’re seeing a change?

[Zion.Lo]

Scott, sorry it has taken a while to get back to this. To get a clean start, I created a new workspace, created EJB/Web/EAR projects called Z_BT, Z_UI, and Z_EAR respectively, where the EAR project holds both EJB and Web. I set the project property to manually manage application.xml and modified the application.xml in Z_EAR/META_INF to be like this:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE application PUBLIC “-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN” “http://java.sun.com/dtd/application_1_3.dtd”&gt;

<application>
<display-name>Z_EAR</display-name>
<module id=”myeclipse.1139518988194″>
<web>
<web-uri>Z_UI.war</web-uri>
<context-root>/Z_UI</context-root>
</web>
</module>
<module id=”myeclipse.1139518959717″>
<ejb>Z_BT.jar</ejb>
</module>

<module id=”sample.bt”>
<ejb>SAMPLE_BT.jar</ejb>
</module>
</application>

I then deployed the EAR in exploded format to Weblogic 8, and the resultant application.xml in the deployed folder is this:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE application PUBLIC “-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN” “http://java.sun.com/dtd/application_1_3.dtd”&gt;

<application>
<display-name>Z_EAR</display-name>
<module id=”myeclipse.1139518988194″>
<web>
<web-uri>Z_UI</web-uri>
<context-root>/Z_UI</context-root>
</web>
</module>
<module id=”myeclipse.1139518959717″>
<ejb>Z_BT</ejb>
</module>

<module id=”sample.bt”>
<ejb>SAMPLE_BT</ejb>
</module>
</application>

I have MyEclipse 4.1.0 GA and Eclipse 3.1.1, where MyEclipse was upgraded from a 4.0.3 version. Before I installed the 4.0.3 version, I used to have a 3.8.3 version (my post back in August) where the problem was confirmed. I wonder if there is something residual on my system from 3.8.3 that may be causing this for me since the behavior is similar to what I experienced earlier? Maybe an old MyEclipse jar … would you be able to pinpoint which plugin or jar file in MyEclipse contains the deployer code so I can search for the old one on my system?

Since we seem to be following the same steps, and it works fine in your test, I’m guessing there must be something different in my environment.

thanks!
Zion

[Riyad Kalla]

Zion,
Scott has me try to duplicate this and I was unable to. The only differences I can see if that I am running a clean install and yuo have been through a few upgrades that may be causing a conflict.

For testing sake, let’s try this. Download Eclipse 3.1.2 SDK from the Eclispe website. Unzip it to a new location. Now download MyEclipse 4.1 GA from our website and install it to a new location as well and point at your new Eclipse 3.1 install. Now fire it up and create your Z_EAR test case again and see what happens (be sure to use a new workspace).

[Author]

Posts