[Purisma Dev Team]

What operating system and version are you running? Windows XP
What Eclipse version and build id are you using? 2.6.2
– Was Eclipse freshly installed for MyEclipse? Yes
– Are any other external plugins installed? Yes: JFaceDbc, oXygen, Jalopy, SolarEclipse
– How many plugins in the <eclipse>/plugins directory are like org.eclipse.pde.*? 7 (seven)
What MyEclipse version are you using? (Help > About Eclipse Platform > Features) AppServerTooling, CoreTooling, Workbench, Help, DevTooling
What JDK version are you using to run Eclipse? Java HotSpot(TM) Client VM (build 1.4.1_03-b02, mixed mode)
What JDK version are you using to launch your application server? Java HotSpot(TM) Client VM (build 1.4.1_03-b02, mixed mode)
What application server are you using? Weblogic 8.1.1.0
Are there any errors in the Eclipse log? no

Our application is composed of several Eclipse projects, one of which is a MyEclipse web application project. We workaround MyEclipse’ limited ability to deal with project dependencies with an Ant script that moves dependent classes, and other resources, into the WEB-INF/classes folder of the webapp. For instance:

    projectA/ - an Eclipse project
        target/classes - where A's classes are built

    testapp - the webapp project, which depends upon projectA
        src/webapp
            WEB-INF/classes - where testapp's classes are built (by Eclipse) and projectA's are copied (by Ant)

    deploy/devserver/applications
        testapp/WEB-INF/classes - deployment folder for the testapp web application

We are seeing inconsistent behavior in how MyEclipse deploys classes from the webapp into a live Weblogic server. We have been unable to find detailed specification of how deployment, and especially “Sync-on-Demand”, is supposed to function, so this email is both an inquiry into that functionaity and a possible bug report.

More specifically, if we compile a Java file in a MyEclipse webapp project, e.g., testapp, the following occurs:
– The class is compiled into WEB-INF/classes, the build output path for the webapp.
– The class is copied (by MyEclipse, we presume) into the deployed application’s WEB-INF/classes folder.
– On the next request to the Weblogic server, every class in our application is reloaded.

It doesn’t appear that a hot deployment (aka partial redeployment) is occurring. This is troublesome because this requires static re-initialization of our entire application, which can be time consuming.

On the other hand, if we compile a Java file that lives in a dependent project, e.g., projectA, the following occurs:
– The class is compiled into a target/classes folder within that project. It is not copied into either the MyEclipse webapp project (this is done manually with our Ant build script) or the deployment area.
– On the next request to the Weblogic server, that class is reloaded. No other classes are reloaded.

Thus, in this case, MyEclipse appears to do a much less costly hot deployment of just the modified class. If we copy the modified classfile into the webapp’s WEB-INF/classes folder, using our build script, and then ‘refresh’ that folder within Eclipse, MyEclipse copies the class into the deployed application. On the next request, all classes will be reloaded.

In summary, it seems that whenever a classfile changes in our MyEclipse project’s WEB-INF/classes folder, that class is copied into the deployed application’s WEB-INF/classes folder, which in turns causes WebLogic to reload all classes in a new ClassLoader.

What do we need to do differently so that MyEclipse instead does a “minimal” hot deployment when classes change?

[support-michael]

One long post deserves a long reply, so here it goes. There are 2 hot-xxx mechanism at play here, hot-deployment and hot-code swapping.

The sync-on-demand is a hot-deployment mechanism. With exploded archive deployment the deployer detects and copies new *.class and other resource files from your Eclipse workspace to the auto-deployment location of all appservers to which the MyEclipse project is deployed. Thus the appserver’s application space is always in-sync with the MyEclipse project. This allows users the confidence of knowing that the deployed app consistently reflects the current state of the codebase.

MyEclipse deployer relies on appserver’s ability to detect and reload newly deployed code. For servers such as Tomcat and JBoss that support individual class reloading this is very convenient behavior. For Weblogic it appears in your case that the effect is to drop and reload the classloader responsible for the updated class and that classloader’s children. In the case of an EJB reload I’m assuming the behavior is to drop all web apps and reload them as well. For webapp changes either partial or complete reload will be experienced.

Q: Does any Java file change in a webapp result in a complete redeploy or just certain changes?

The second behavior in play here is the hot-swap code replacement of the Java utility classes. When a change is made to one of these codebases it does not result in hot-redeployment of the application, i.e., no resources are copied to a server’s auto-deploy area. (Note: when dependent projects are supported hot-redeployment will extend to these projects as well.) This is because Eclipse uses the JPDA interface of the JVM to replace modified Java elements directly in the JVM running WLS. This is a transient effect that reverts back to use of the deployed code when the WLS JVM is recycled. Other restrictions with this mechanism are that you may not change the form of a class. So like hot deployment it has its strengths and weaknesses.

With WLS reloading the app upon every hot-deployment change much time is being wasted waiting for app reloading (I assume). We have 2 approaches when working with WLS. If you are working on JSPs you’ll want to hot-redeploy them so we suggest using exploded deployment. If you are primarily performing EJB development, consider packaged deployment since only hot-swap code replacement is enabled in this mode. But note that you must redeploy a packaged archive anytime you change the form of a class (i.e., add/remove/rename method, add field, statics, …).

I will have to research this further but I believe you can enable/disable WLS8.x reloading behavior on an app-by-app basis. For webapps you can also use the REDEPLOY-touch file mechanism, see http://e-docs.bea.com/wls/docs81/webapp/deployment.html If you can help me isolate that type of Java file changes posed in my question above we will have a better insight into how to improve MyEclipse and/or recommended work patterns.

Regards,

Michael
MyEclipse Support

[Purisma Dev Team]

Michael,

I appreciate your detailed reply. I am going to try out some of your suggestions for alternative ways to configure/trigger WLS deployment, and will report back.

To answer your question, we are not using EJB. We are a developing a fairly vanilla J2EE application, with a JSP/Servlet (Struts) application layer, Hibernate persistence layer, and otherwise leveraging “lightweight” J2EE technologies like JMS and JNDI. At this point, we are most interested in streamlining the development process for JSPs, Struts Actions, and the data beans and management services provided by our business logic tier. Our business tier follows many J2EE design patterns: simple value objects paired with data access objects to assist with persistence operations, singleton/stateless business services, etc.

So I don’t think we’re asking for much from the WLS container: we need Java classes to be reloaded with minimal impact, classes that don’t require registration with EJB or such.

As soon as any resource within our webapp project changes, it is copied to the auto-deployment area, and on the next request that requires that resource WLS:
*.class – reloads all application classes, likely using a new ClassLoader
*.jsp – recompiles the JSP, but does not appear to reload any other classes (our JSPs live outside of WEB-INF)
*.html, *.css, and other static content – reloads the file from disk
*.xml, *.properties, and other configuration files – does nothing; configuration files are not “picked up” until something causes WLS to reload the app, which in turn requires the consumer (e.g., log4j) to reload the file

It sounds like WLS hot-deployment is just reloading the entire app whenever any Java class changes. I believe that WLS 8.1 can do better (I am almost positive we had WLS 7 doing it at my former employer), so I’m hoping a configuration change will make it happen. If not, we might just end up manually deploying our application and rely upon MyEclipse’s hot-swap for automatic updates.

Regards,
Nate

[Purisma Dev Team]

I looked into a few alternatives…here’s what I found (we’re going with option 3 for now).

1. Deploy as a packaged application. Rely upon MyEclipse hot code-swap to update the running instance. Do manual redeployments when needed (define what constitutes a “big change”).
+ Can’t use file-based resource lookup (e.g., Protege model). Need to use the ClassLoader to find resources.
+ JSPs, not to mention static content, cannot be hot-deployed.
+ Classes can be hot-swapped without reloading the application.

2. Try to configure Weblogic to not reload all classes on every partial redeployment.
+ Add a REDEPLOY file to the webapp. Touch this file to trigger redeployment. Maybe this will give WLS the hint to only reload specific classes and/or MyEclipse will rely upon hot code-swap
– Changing a classfile still causes the entire application to be reloaded.
+ Configure the Reload Period
– WLS servlets and web services can be configured to periodically reload (servlet-reload-check-secs), but this doesn’t help with other classes. See http://edocs.bea.com/wls/docs81/webapp/weblogic_xml.html.

3. Never build classes directly into WEB-INF/classes — rely upon hot-swap for most changes. Manually copy files into the webapp to trigger hot redeployment.
+ This seems to work well for us. Since hot-swap doesn’t always work, it would obviously be better to actually reload the class — we’ll be using JBoss soon as well, so this may be a good reason to use that for our primary development environment.

4. Layout the application according to WLS’ Split Development model, http://edocs.bea.com/wls/docs81/programming/environment.html#SplitDir
+ This requires laying out our application as an Enterprise App, which we don’t require.
+ This is specific to WLS.
+ This colocates the source and build files. Not clear if this is a good/bad thing.

[support-michael]

Thanks for the fine analysis. Later this week I’ll run a few test cases on our WLS systems and see if I can identify additional patterns to improve development efficiency. I would agree that #3 is probably best case when individual class changes result in complete application reload. I believe with JBoss you should have a better experience due to finer-grained reloading capability. We will be adding a “Reload” feature in Dec that will instruct an appserver to reload (not redeploy) an application. This will provide users fine-grained auto-redeployment of partial apps and user controlled complete app redeploy.

Michael
MyEclipse Support

[Author]

Posts