<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<div class="moz-text-flowed" style="font-size: 16px;" lang="x-western">Hi,
<br>
<br>
I do the following in a small script, which I have configured as
additional tool in eclipse, so I just run it from the menu, whenever I
like (but you can also link your script to execute automatically after
each build process, if you like).
<br>
<br>
my script does
<br>
- restart the opencms webapplication context by calling wget and
trigger the URL-based tomcat admin to reload the opencms context
<br>
(wget also exists for windows - if you search, you'll probably find
binarys somewhere, just as I have; or you ask me and I send them to
you)
<br>
- then the script copies all of my re-compiled classes into the
classes-directory of the Opencms Webapp
<br>
<br>
You don't need to use jars and you don't need to upload any
classes/jars into the VFS, before your module is really to be given
away for others.
<br>
The Java VM loads classes from the real Filesystem anyway, so why
bother with VFS, while still developing.
<br>
Just make sure, that your classes appear at only one location in the
classpath, as I said, I use the classes directory of OpenCms.
<br>
<br>
When I have copied the new classfiles the classfiles, I have a complete
login bookmark in my browser. That bookmark already contains username
and password and I can even leave my old cms window open.
<br>
<br>
It's still a bit annoying, but replacing the classfiles will only work
together with restarting the webapp. And if you restart the webapp,
then of course you have to login again.
<br>
<br>
__
<br>
<br>
Another thing is very handy, too:
<br>
- turn your Java engine into debug mode.
<br>
- connect with the eclipse debugger to the running engine
<br>
- debug as much as you like;
<br>
- even if you don't really debug:
<br>
if you change and compile some classes now, while the debugger is
connected, then your modified classes get injected into the running
instance.
<br>
<br>
Of course, if you shutdown and restart your java instance, then the
classes are loaded again from the classpath, so the hot insertion
through this method lasts only as long as the classes are held in
memory.
<br>
But until then, the hotly inserted versions are used immediately,
without restarting anything.
<br>
<br>
The only thing (according to my experience is): don't re-compile (which
in this case means: don't cause a re-injection of classes), while at
the same time your program is waiting at a breakpoint.
<br>
Instead: let the program run through again, until it doesn't wait at
any breakpoints anymore and then you can re-compile (and thereby
re-inject) your modified classes.
<br>
<br>
Your new class versions take over immediately with the next request.
<br>
<br>
Regards
<br>
Christian
<br>
<br>
</div>
</body>
</html>