[Patrick Kates]

@support-rkalla wrote:

Patrick, we provide a doc for WebSphere here: http://www.myeclipseide.com/images/tutorials/quickstarts/websphere6/

This seems like a pretty good doc – I am much closer to having this working than before. However, I am still having problems with the deployment. My app appears to be deployed ( I can hit my html pages), but none of the JSP/servlets work. From the messages I am receiving in the log it appears that Websphere has cached an invalid version of my web.xml from one of my previous attempts at deploying the app. I have gone to the actual file under the installedApps/blah/blah/WEB-INF directory and verified that the correct file is actually deployed.

Any suggestions you have on getting WAS to pick up the correct web.xml would be greatly appreciated.

And finally, I have two suggestions for additions to the doc you linked.

1 – Add a note mentioning the need to uninstall DefaultApplication.ear if your own app installs at “/”. Possibly this step could be done near the logging changes section. I knew to do this, but did not realize that the new profile also installed all the IBM sample apps, and so had to spend a little time figuring out what was wrong.

2 – Add a note about not changing the default application name during deployment. I changed the name of my app to what we use in PROD (which is different from the name of the project / EAR file) and was then unable to complete the Sync-On_Demand portion of the instructions because MyEclipse wants to default the deploy directory to a path based on the project / EAR name.

Actually, I agree with tomng92’s earlier post. Much of the frustration involved here would be solved if the deploy location was editable by the user. It ought to be since WAS allows you to specify an application name during deployment.

[Riyad Kalla]

Any suggestions you have on getting WAS to pick up the correct web.xml would be greatly appreciated.

I would start by removing the deployment from MyEclipse, logging into the WAS admin console and uninstalling the app and then shutting down the app server. Then drill down to the installedapps dir and make sure it is gone, then redeploying the whole thing. Basically cleaning house.

And finally, I have two suggestions for additions to the doc you linked.

Good suggestions, I will file them for documentation to add them.

Actually, I agree with tomng92’s earlier post. Much of the frustration involved here would be solved if the deploy location was editable by the user. It ought to be since WAS allows you to specify an application name during deployment.

You can deploy wherever you want, just when you go to create the deployment, instead of selecting the server select “Custom Location”.

[Patrick Kates]

@support-rkalla wrote:

I would start by removing the deployment from MyEclipse, logging into the WAS admin console and uninstalling the app and then shutting down the app server. Then drill down to the installedapps dir and make sure it is gone, then redeploying the whole thing. Basically cleaning house.

Yes that is exactly what I had to do. The app is working now and I am able to debug in classes and JSPs

I found the culprit web.xml in C:\Program Files\IBM\WebSphere\AppServer\profiles\MyEclipse\config\cells\mymachineNode02Cell\applications\myapp.ear\deployments\. Apparently at some point I deployed an EAR which contained my WAR, which also contained my WAR. The extra WAR had an incorrect version of web.xml for local development. All my redeployments of the app from myeclipse never affected the files under that MyEclipse\config path.

Actually it appears that any modification to the web.xml file will go completely unchanged in that MyEclipse\config path. Redeploying from MyEclipse will not fix it; it seems to require a complete update of the application from the WAS console. Which is kinda ugly for a development environment, imo. This has to be possible to do tho, or IBM couldn’t do it with their WTE included in their IDEs.

[Riyad Kalla]

Yes that is exactly what I had to do. The app is working now and I am able to debug in classes and JSPs

Glad to hear it. If during development you want a more automated/easier experience, JBoss is quite nice out of the box as far as deploy-n-go. But I realize for production you may want to develop on websphere to keep everything the same.

Actually it appears that any modification to the web.xml file will go completely unchanged in that MyEclipse\config path. Redeploying from MyEclipse will not fix it; it seems to require a complete update of the application from the WAS console. Which is kinda ugly for a development environment, imo. This has to be possible to do tho, or IBM couldn’t do it with their WTE included in their IDEs.

There is actually a trick to this, it’s covered in the doc. It requires you to overlay an exploded deployment ontop of the one that WAS created, but you have to follow the steps in the doc pretty closely.

Again, you might just do initial development with JBoss then switch to WAS for testing to avoid all this headache (or Tomcat if you don’t need the EJBs).

[Patrick Kates]

@support-rkalla wrote:

If during development you want a more automated/easier experience, JBoss is quite nice out of the box as far as deploy-n-go. But I realize for production you may want to develop on websphere to keep everything the same.

heh – yeah I already use tomcat and jboss on other projects and I’d like nothing better than to switch. but it’s not my requirement. oh well.

There is actually a trick to this, it’s covered in the doc. It requires you to overlay an exploded deployment ontop of the one that WAS created, but you have to follow the steps in the doc pretty closely.

I did do this, and I thought I did it as outlined in the doc. It appears to be trying to hotswitch the classes when I make changes to the classes. It actually hasn’t succeeded in doing so – everytime so far has required a complete restart of the server.

[Riyad Kalla]

I did do this, and I thought I did it as outlined in the doc. It appears to be trying to hotswitch the classes when I make changes to the classes. It actually hasn’t succeeded in doing so – everytime so far has required a complete restart of the server.

Hmm, is WAS setup to allow class reloading for that project? Check it under the admin console, I know in Tomcat and JBoss this is actually a setting to allow it.

[Patrick Kates]

Well I did check the class reloading checkbox during deployment of the EAR. And I made sure to do that again when I redeployed this morning. I will doublecheck the console to see if there is some sort of server level setting I can find.

[Patrick Kates]

I did not find any server level setting for enabling class reloading. I have verified that the app was installed via the console with class reloading enabled. The ibm-web-exit.xmi file included in my app also has class reloading set to true.

When I change a class on the fly I get the Hot code replace failed message window – with a message of

com.ibm.ws.bootstrap.WSLauncher at localhost:1863 was unable to replace the running code with the code in the workspace.

Reason:
The target VM does not support hot code replace

[Riyad Kalla]

Hmm, can’t really work around that issue if the VM is not allowing it. Is there an easy way to reload contexts during runtime from the admin console to help speed up development?

[Author]

Posts