[dogeared]

– System Setup ——————————-
Operating System and version: XP Pro SP 2
Eclipse version: 3.1
Eclipse build id:
Fresh Eclipse install (y/n): y
If not, was it upgraded to its current version using the update manager?
Other installed external plugins:
Number of plugins in the <eclipse>/plugins directory that begin with org.eclipse.pde.*:
MyEclipse version:
Eclipse JDK version: 1.4.2
Application Server JDK version: 1.4.1
Are there any exceptions in the Eclipse log file?
no
If this is a DB related question please answer the following:

RDBMS vendor and version:
JDBC driver vendor and version, and access type (thin, type-2, etc):
Connection URL:
Eclipse error logs related to com.genuitec.eclipse.sqlexplorer packages:

– Message Body ——————————-

I have followed the instructions and done “the dance” to get an application to update on the fly from MyEclipse with WAS 5.1. If I make a change in a JSP or a supporting Java class, the code us automatically distributed out the proper place in the WAS directory tree.

The issue I am having is if I make changes to the web app deployment descriptor (web.xml). While it properly gets published out to the …/installedApps/… folder, it does not get to the …/config/cells/…/deployments/…web.xml which is where WebSphere apparantly uses for the web application.

I can manually replace this file, stop and start the server and everything works fine, but this isn’t exactly an integrated approach.

-Micah

[Riyad Kalla]

Micah,
MyEclipse is honoring the sync-on-the-fly functionality we set forth to provide, if your app server is not setup to reload changes to the context, then that might explain why you aren’t see the changes occuring real-time. I don’t have much experience with WS however so I can’t suggest anything to you. In Tomcat this is fixed by setting your context to reloadable, I don’t know if the same holds true for WS.

[dogeared]

@support-rkalla wrote:

Micah,
MyEclipse is honoring the sync-on-the-fly functionality we set forth to provide, if your app server is not setup to reload changes to the context, then that might explain why you aren’t see the changes occuring real-time. I don’t have much experience with WS however so I can’t suggest anything to you. In Tomcat this is fixed by setting your context to reloadable, I don’t know if the same holds true for WS.

I wi ll double check, but I do believe that I set the reloadable checkbox when I deployed this app.

[dogeared]

@dogeared wrote:

@support-rkalla wrote:

Micah,
MyEclipse is honoring the sync-on-the-fly functionality we set forth to provide, if your app server is not setup to reload changes to the context, then that might explain why you aren’t see the changes occuring real-time. I don’t have much experience with WS however so I can’t suggest anything to you. In Tomcat this is fixed by setting your context to reloadable, I don’t know if the same holds true for WS.

I wi ll double check, but I do believe that I set the reloadable checkbox when I deployed this app.

I have checked and the reloading is enabled. This seems to only apply to objects (servlets, JSPs, supporting classes) in the web application. It doeas also update the web.xml with in the installedApps/…/WEB-INF folder, but this is *not* where WebSphere saves (and uses) the web.xml. Is there any way to automatically sync the web.xml to the right place?

[Scott Anderson]

Actually, I don’t think the issue is where the file is being saved; it’s forcing WebSphere to reread it. Rather than manually copying the web.xml file as you’ve been doing, can you verify that the new copy is placed under InstalledApps, where MyEclipse is targeting it, and then shutdown and restart WebSphere. Is the new web.xml being used then?

[dogeared]

@support-scott wrote:

Actually, I don’t think the issue is where the file is being saved; it’s forcing WebSphere to reread it. Rather than manually copying the web.xml file as you’ve been doing, can you verify that the new copy is placed under InstalledApps, where MyEclipse is targeting it, and then shutdown and restart WebSphere. Is the new web.xml being used then?

web.xml is definitely being changed in the installedApps directory. Shutting down and restarting WebSphere does *not* cause it to re-read this file.

As part of the deployment process, WebSphere makes a copy of the web.xml and puts it in the config directory. It seems that this is the only time that WebSphere does this, so I think it would have to be a part of the MyEclipse sync process.

[Scott Anderson]

Then the “correct” way to force WebSphere to reload the context would be through it’s admin control panel, and you can do this without the restart, which would be faster. What I’d suggest is to create a Packaged deployment using the <Custom…> deployment target so that it goes into the WebSphere ‘InstallableApps’ subdirectory, which is the default target for the Websphere packaged deployment option. Once that has happened, open the websphere console, navigate to the installed applications list, and tell websphere you have an update for the installed application. Load the updated EAR and start it. That will update the full deployment and reload the context. Your real-time changes can continue to be synced through your exploded deployment, but for web.xml changes you’ll need to tell the deployment manager to update the packaged deployment then repeat the update in the websphere console.

The idea of updating the cached version for websphere will still require a full server restart, so it really isn’t a tremendous help for keeping development moving along. Most other servers will detect changes and reload contexts for you, but to my knowledge for websphere you must use the admin console since no such detection facility exists.

[dogeared]

@support-scott wrote:

Then the “correct” way to force WebSphere to reload the context would be through it’s admin control panel, and you can do this without the restart, which would be faster. What I’d suggest is to create a Packaged deployment using the <Custom…> deployment target so that it goes into the WebSphere ‘InstallableApps’ subdirectory, which is the default target for the Websphere packaged deployment option. Once that has happened, open the websphere console, navigate to the installed applications list, and tell websphere you have an update for the installed application. Load the updated EAR and start it. That will update the full deployment and reload the context. Your real-time changes can continue to be synced through your exploded deployment, but for web.xml changes you’ll need to tell the deployment manager to update the packaged deployment then repeat the update in the websphere console.

The idea of updating the cached version for websphere will still require a full server restart, so it really isn’t a tremendous help for keeping development moving along. Most other servers will detect changes and reload contexts for you, but to my knowledge for websphere you must use the admin console since no such detection facility exists.

My point here is that I am looking to replace WSAD (with the WAS runtime) with eclipse and MyEclipse. In WSAD, the integration with the WAS runtime is much tighter. You don’t every have to use the administrative console. Maybe there is not enough demand, but it’d be nice if we could do the same with MyEclipse.

Flipping back and forth from eclipse to the administrative console and eclipse is not the kind of tight integration we are looking for.

I had gotten to the point where it was “acceptable” in that you had to do the initial packaged, administrative console, exploded dance, but from that point on, everything would be updated.

But not being able to (easily) keep the web.xml in synch is problematic.

I will try your suggestion, but I don’t know if that is going to be feasible. It would require us to build the ear file for every little change to the web.xml, which for a project of our size would be a considerable time hassle.

[Riyad Kalla]

dogeared,
I don’t think it’s unreasonable to expect WSAD and WS to have tight integration considering where they came from and the desire to create vendor lockin. While we support many many more application servers, we do that by sacrificing extremely tight integration with each app server (as you are seeing).

When weighing the pros and cons of staying with WSAD or moving to MyEclipse I think there are many factors, if deployment is going to pose that big a problem for your team and is a core item of importance that overshadows pricing or features then having the tighest integration with your app server as possible is probably the way to go. We try and provide tools that can be everything to everybody, but in some cases we miss the mark and have to weigh the cost of making that user happy.

In this case this is the first time someone has requested this feature, I believe the reason is that web.xml files don’t typically change as often as application code files (jsp, xml, java, etc.).

[dogeared]

@dogeared wrote:

@dogeared wrote:

@support-rkalla wrote:

Micah,
MyEclipse is honoring the sync-on-the-fly functionality we set forth to provide, if your app server is not setup to reload changes to the context, then that might explain why you aren’t see the changes occuring real-time. I don’t have much experience with WS however so I can’t suggest anything to you. In Tomcat this is fixed by setting your context to reloadable, I don’t know if the same holds true for WS.

I wi ll double check, but I do believe that I set the reloadable checkbox when I deployed this app.

I have checked and the reloading is enabled. This seems to only apply to objects (servlets, JSPs, supporting classes) in the web application. It doeas also update the web.xml with in the installedApps/…/WEB-INF folder, but this is *not* where WebSphere saves (and uses) the web.xml. Is there any way to automatically sync the web.xml to the right place?

Thanks for all of your responses. It’s *really* close for us here. We would very much like to get rid of the Bloat of WSAD and (even worse) Rational. We are used to having to restart the server when changes occur in web.xml (which are infrequent). The real key in this particular case would be to be able to get the web.xml to the right place so that when we add a new servlet, we can simply restart the server without having to redeploy the entire ear file (which is quite large).

Do you have any API exposed in myEclipse that would allow me to add this functionality? Maybe there is some kind of an xdoclet thing I could do to achieve this?

I am going to try to do the de-deploy the “right” way as you suggested to see just how long it takes, but I’d be interested in your feedback on my suggestions.

Thanks,

Micah

[Riyad Kalla]

Micah,

Do you have any API exposed in myEclipse that would allow me to add this functionality? Maybe there is some kind of an xdoclet thing I could do to achieve this?

We are glad to hear you guys are getting closer to desired behavior, unfortunately at this time there are no exposed MyEclipse APIs to speak of that can be hooked into, as far an XDoclet thing… I wonder if a custom Ant script/target JUST used to do the web.xml step and then added to the builders for your project would giv eyou what you want? You might want to add logic to the Ant script to see if the source and destination web.xml files are the same, if they are then don’t perform the copy, if they are different then perform the copy (and either hope that WS restarts the context or you can now restart the server?)

This would be run every time you built (saved) a file so it might be overkill, but if you made the Ant script smart about it, it may be a workaround that puts your team in a good position?

[Author]

Posts