On 24 Apr 2008, at 07:14, Peter Stavrinides wrote:
Tomcat in eclipse has an Automatic publishing feature, which is not
to be confused with live class reloading.
I'm currently using Tomcat 6 with Eclipse/WTP. I'm not publishing
anything as I'm using the "Serve modules without publishing" option,
designed to get Tomcat to serve directly from the project folder.
Class reloading works flawlessly. (Well, as far as I can detect;
changes are instantly live, without a context reload or any other
kind of restart happening). My only difficulty at the moment is that
changes to templates in the context root (i.e. not under WEB-INF/
classes) are not picked up and require a restart.
It's clear from the variety of previous responses (ranging from
claims that you can't use Tomcat for class reloading to reported
success) that there is considerable confusion on this issue. As it's
something that so fundamentally affects developer productivity, it
would be great if someone could offer a definitive clarification on
where things stand. My understanding (from a quick preliminary trawl)
is as follows:
The current Tapestry 5 documentation indicates that Tomcat deployment
requires that you use the Maven war plugin archiveClasses option.
This workaround was first mentioned by Howard in the discussion on
Tapestry-1287. It seems that the source of the difficult, at the
time, was the following line in ComponentClassLocatorImpl:
Enumeration<URL> urls = _contextClassLoader.getResources(packagePath);
Howard felt that if you pass a folder to the above, you should get
back an enumeration of the folder's contents and he posted a Tomcat
bug to this extent:
https://issues.apache.org/bugzilla/show_bug.cgi?id=41664
The Tomcat people responded that their classloader implementation was
correct; that you should get back an object representing the folder
and you need to examine its contents yourself. Ben Sommerville then
submitted a patch that did this. His patch was eventually
incorporated into the Tapestry codebase via Tapestry-1333. This was
marked as Fixed back on 30th April, 2007. As such, it's not clear why
the archiveClasses workaround is still there in the documentation.
Unless, of course, it's required because of a totally separate issue
to the one that it was originally introduced to work around. Can
someone in the know clarify on this?
Regards,
Don.
P.S. If anyone has any pointers on the template reloading issue, that
would be great.
This message has been scanned for content and viruses by the DIT Information
Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]