Hello,
We are working with MyEclipse 4.1 and WebSphere 6.0.2
Our goal is to debug the application with MyEclipse.
For that purpose we followed the instruction from the following document: http://myeclipseide.com/enterpriseworkbench/help/index.jsp?topic=/com.genuitec.myeclipse.doc/html/quickstarts/appservers/index.html

In brief: After we installed the ear file (via the admin console after deployed as packaged from IDE), we deployed the application onto the appServer, but this time as exploded application.
The result of the above is:
1) The single ear file (first deployed) from installableApps folder has been deleted (OK)
2) The ear file has been exploded (second deployment) to ..\installedApps\{NodeName}\{appName} folder (OK)

The problem occurs since the deploy process doesn't generate the stub files (and we know that MyEclipse doesn't support this by definition) and no binding occurs for any session bean, i.e. the java code that calls Context.lookup("ejb/MySessionBeanFacade") always fails!

What should we need to do in order to be able to debug the application via MyEclipse?
BTW: Prior to MyEclipse, we used to develop with RAD and the deployment was done from within the IDE. Even though, MyEclipse is our preferable IDE...

Another (small?) question:
It seems that Hot-Sync (Enterprise Sync-on-Demand Development feature) doesn’t work in our machine. Although changes to code is reflected immediately with the deployed code on the server, a dialog box from MyEclipse appears and claims that the VM doesn’t support this hot changes.
Do you have any idea?

THANKS.
simon

Quote:

The problem occurs since the deploy process doesn't generate the stub files (and we know that MyEclipse doesn't support this by definition) and no binding occurs for any session bean, i.e. the java code that calls Context.lookup("ejb/MySessionBeanFacade") always fails!

These should have been created when the app was original deployed within the app server. Are these being removed somehow when the packaged deployment is being removed?

Quote:

Another (small?) question: It seems that Hot-Sync (Enterprise Sync-on-Demand Development feature) doesn’t work in our machine. Although changes to code is reflected immediately with the deployed code on the server, a dialog box from MyEclipse appears and claims that the VM doesn’t support this hot changes. Do you have any idea?

As long as you are using JDK 1.4+ to run Eclipse and WebSphere you should be OK. However, the hot sync spec itself is very limited, if the shape of your class is changing (member vars, methods, etc.) then hotsync will fail. If you are merely changing a method impl, it should work and be instant.

Hello

I read your answer about the hot sync and i think it will create alot of problem during the development process - Do you intend to fix/add this problem: the ability to change ejb shape and continue to work without reinstall the application.

In purpose to solve this problem:
We think for the meantime to create a script that will run the ejbdeploy(ibm command tool) and copy the .classes to the installedApps folder - will it solve the problem?

Thanks.

Quote:

I read your answer about the hot sync and i think it will create alot of problem during the development process - Do you intend to fix/add this problem: the ability to change ejb shape and continue to work without reinstall the application.

No, there is nothing to *fix*. THe hot sync is part of the debugger spec created by Sun, it provides a limited amount of situations in which case a VM can safely reload a class without ill effects. The debugger and running app server communicate these changes adn the app server will reply to the debugger with a success or failure message if the reload was successful.

Quote:

We think for the meantime to create a script that will run the ejbdeploy(ibm command tool) and copy the .classes to the installedApps folder - will it solve the problem?

This won't change the hot sync issue. With hot sync the new class is communicated via the socket between debugger and app server. However, if WebSphere supports reloading changed classes, then doing this step (or using an exploded deployment as outlined here in Section 10: http://www.myeclipseide.com/images/tutorials/quickstarts/websphere6/ ) will cause WebSphere to reload the context just like Tomcat and JBoss support when changes are detected. This is another possible workaround to the limitation of hot syncing.