[Jon Nermut]

I’m currently trialling switching from JDeveloper to My-Eclipse for the development of a large J2EE app.
Has anyone had success in getting hot replace working for oc4j?
This seems to me to be one of the best features of eclipse, and the productivity increase would be a very good reason to switch.
Hot replace seems to be working fine in Tomcat using the same JDK (Sun 1.4.1_02).
But when I try to hot replace a class with minimal changes on a running instance of OC4J I get the error:
Hot code replace failed – Scheme change not implimented
Does oc4j support this at all, or is this a problem with my setup?

[support-michael]

If you are running OC4J with JDK 1.4.1+ and not changing the shape of a class while debugging I would expect hot-swapping changes to the remote JVM to succeed. What JVM are you launching OC4J with?

Michael
MyEclipse Support

[Scott Anderson]

Does oc4j support this at all, or is this a problem with my setup?

It’s not a matter of oc4j supporting it. It is handled by the interaction between the JVM oc4j is running on and Eclipse’s debugging client. Oc4j doesn’t even know it’s happening so the problem is either that you modified your class in a way that is not supported by the JPDA specification (changed the “shape”), or your JDK configuration.

–Scott
MyEclipse Support

[Jon Nermut]

Thanks for the replies guys.
The change to the class I am making is only changing a string, so I presume that doesn’t change the “shape” of the class.

I am launching oc4j (9.0.4) through the 1.4.1 jre. I think 9.0.3 used to come with its own JDK, but they seem to have removed this in the latest version, so it seems like it is starting up the same way as Tomcat, where hot replace works fine.

One thing that might be affected it is that I am not using the my-eclipse deployment options. My project is a bit too complicated for it to handle, so I am using an Ant build script to build an ear and then copy it to the oc4j deployment directory. This seems work fine, but I am wondering if the my-eclipse deployment stuff is doing any magic behind the scenes.

[Scott Anderson]

I am using an Ant build script to build an ear and then copy it to the oc4j deployment directory. This seems work fine, but I am wondering if the my-eclipse deployment stuff is doing any magic behind the scenes.

This is probably the root of the issue as it can be problematic for a few reasons. Sometimes people forget to compile their Java code with debug information included. Sometimes Ant versions change and the “default” for whether or not to include debugging information is reversed by the Ant team. We don’t perform any “magic”, we just deploy the class files as they are complied by the Eclipse compiler. You might try that instead of recompiling them. Could you be using a different JDK for compiling/deployment than you’re launching the server with?

Out of curiosity, what about your project is too complicated for our J2EE model / deployer? Is it just the historical layout (ie. it isn’t in exploded formats) or something else?

–Scott
MyEclipse Support

[Jon Nermut]

Well after shutting everything down, rebooting, and starting everything back up, hot replace magically started working for oc4j. No idea why, but its all good , I just don’t want to turn off my machine now.
J2EE black magic 😉

[Jon Nermut]

Scott,
I think you are right. When I run oc4j pointing to the classes generated by eclipse, rather than the Ant ones, hot code replace seems to reliably work, which is great. You can make oc4j use the actual project files, so you don’t actually have to deploy at all, by using the following:

in server.xml :

<application auto-start=”true” name=”councilc” path=”C:\foo\bar\application-eclipse.xml”/>

and then make application-eclipse.xml something like this:

<orion-application>
<ejb-module path=”file:/C:/foo/bar/BusinessTier/classes/”/>
<web-module id=”presentation” path=”C:\foo\bar\PresentationTier\web”/>

<library path=”C:\foo\bar\Common\dist\common.jar”/>
… etc,
<data-sources path=”.\All\src\META-INF.dev\data-sources.xml”/>
</orion-application>

This is exactly the way that JDeveloper deploys a workspace app to its integrated oc4j.

This has a couple of advantages:
1. It uses the eclipse generated class files, so hot code replace works, and files are automatically compiled
2. It is a hell of a lot faster than starting up ant, generating an ear and deploying that

We will still use our ant scripts for continous integration and for building deployment ears, as it is nice to have that all IDE independant.

The reason that the my-eclipse deployment stuff doesn’t work is because there are lots of random things from different projects that need to go into random places in the ear to make it work. Ant does a great job of doing this, whereas there are no options given on the structure of the ear given in my-eclipse. We could probably restructure our source tree, but its nowhere near worthwhile several months into the project. But anyway if we can deploy on developer workstations without using an ear, its all well and good.

Thanks for your help. I reckon we will start switching over in the next few weeks.

[Author]

Posts