Hello there I am using the Eclipse/WTP enviroment to develop with Tomcat
and would like to get a greater understanding of some issues that crop
up that lower the quality of development <-> testing cycle for web
application developers.
Do you know of any JSR that covers _REMOTE_ web-app deployment,
exporting of entire web-apps, updating of file/dirs within exploded
web-apps (delta uploads during development on a remote server), web-app
deployment control, web-app reconfiguration, server re-configuration,
etc..., apart from the TC add-on package "admin" is there any other work
you could advise me to go look at that goes someway to forfilling these
requirements ?
Do you think such work should be integrated into the "admin" package ?
My perception of the admin package is that it provides a HTML based
interface to deployment function. Where as I'm thinking of a more grass
roots level protocol (like Java Debug) that works over TCPIP, which is
more a "developer support" package and runs entirely within the
container (not as web-app itself).
Things I'd like to address (and experiment with) :
My first advise to ask is on a ThreadDeath issue within
ContainerBackgroundProcessor, when this occurs the TC server no longer
responds to any web requests, although it appears to be running and the
warning message in the log indicates all should be well. The only way
to recover is to restart TC, this was caused during a web-app automatic
re-deploy. At the end of this email is the log output and stack trace.
Is it possible to get a log output emitted by TC for the event that
occured for it to auto-redeploy ? From my understanding of the
annoyances I see this area "the automatic re-deploy" mechanism is at the
root of most problems. I'd like my development IDE to instruct TC when
its editing the web-app runtime enviroment, so that the deploy part (of
the automatic re-reploy) is delayed until my IDE has finished all its
edits. My IDEs build process is often slower than the time it takes TC
to detect, undeploy and redeploy, but My IDE is still updating the
enviroment, so the re-deploy bounces again as another edit comes in. It
is at these times I see all sorts of problems from the TC JVM crashing
out to ThreadDeath errors. I believe this could be solved by being able
to send TC an instruction that for Context "/foo" to disable the
auto-deploy temporarly, then once building is complete to re-enable and
start the deploy. Maybe this could be achieved locally with a simple
file existance test (lockfile) but I'd really like to see a solution
that works local and remotely.
I would also like to experiment with setting TC up to be able to switch
between two exploded web-app trees for the same context. Think of this
like double-buffering used on 2D/3D graphics. Updates are made to the
one that is currently not deployed, TC is kept informed as to which
files have changed and TC has complete control to be able to decide if
this update can be merged into the currently running wbe-app or a
re-deploy is necessary for the changes to be picked up. TC would also
have control as to exactly when a particular change is merged if that
helps maintain stability of the running development container. But for
this to happen there needs to be an API to delta update an exploded web-app.
Do you have any problems or situations yourself you'd like to throw in
that maybe relevant ?
Your thoughts ?
Darryl
DEBUG 03:13:15,020 (ApplicationLifecycleListener.java:contextDestroyed:36)
-contextDestroyed on "foo"
INFO 03:13:15,024 (ApplicationLifecycleListener.java:contextDestroyed:43)
-contextDestroyed on "foo" done!
25-Oct-2005 03:13:16 org.apache.catalina.session.PersistentManagerBase start
SEVERE: No Store configured, persistence disabled
INFO 03:13:16,813 (ApplicationLifecycleListener.java:contextInitialized:23)
-contextInitialized on "foo"
25-Oct-2005 03:13:16 org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped
already. Could not load org.apache.log4j.spi.ThrowableInformation. The
eventual following stack trace is caused by an error thrown for debugging
purposes as well as to attempt to terminate the thread which caused the
illegal access, and has no functional impact.
25-Oct-2005 03:13:24
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor
processChildren
SEVERE: Exception invoking periodic operation: java.lang.ThreadDeath
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1221)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1181)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at org.apache.log4j.spi.LoggingEvent.<init>(LoggingEvent.java:145)
at org.apache.log4j.Category.forcedLog(Category.java:379)
at org.apache.log4j.Category.log(Category.java:844)
at org.apache.commons.logging.impl.Log4JLogger.error(Log4JLogger.java:193)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3673)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4104)
at
org.apache.catalina.core.StandardContext.reload(StandardContext.java:2930)
at
org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.java:403)
at
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1276)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1568)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1577)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1577)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1557)
at java.lang.Thread.run(Thread.java:595)
25-Oct-2005 03:13:34 org.apache.catalina.core.StandardContext reload
INFO: Reloading this Context has started
DEBUG 03:13:34,128 (ApplicationLifecycleListener.java:contextDestroyed:36)
-contextDestroyed on "foo"
25-Oct-2005 03:13:34 org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped
already. Could not load org.apache.log4j.spi.ThrowableInformation. The
eventual following stack trace is caused by an error thrown for debugging
purposes as well as to attempt to terminate the thread which caused the
illegal access, and has no functional impact.
25-Oct-2005 03:13:34
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor
processChildren
SEVERE: Exception invoking periodic operation: java.lang.ThreadDeath
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1221)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1181)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at org.apache.log4j.spi.LoggingEvent.<init>(LoggingEvent.java:145)
at org.apache.log4j.Category.forcedLog(Category.java:379)
at org.apache.log4j.Category.log(Category.java:844)
at org.apache.commons.logging.impl.Log4JLogger.error(Log4JLogger.java:193)
at
org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3714)
at
org.apache.catalina.core.StandardContext.stop(StandardContext.java:4283)
at
org.apache.catalina.core.StandardContext.reload(StandardContext.java:2924)
at
org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.java:403)
at
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1276)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1568)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1577)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1577)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1557)
at java.lang.Thread.run(Thread.java:595)
--
Darryl L. Miles
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
