tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Marchesani" <>
Subject Re: WebappLoader RFC
Date Tue, 13 Jun 2006 15:16:54 GMT
The IDE features you mention sound cool which one is it?  Any pointers/links
to how you got that setup?  Unfortunately for the environment I am working
in an IDE specific solution would be incomplete.  We have a broad range of
use cases (IDEs, OSes) as well as users where we need people to be able to
checkout a project and be productive with it in a minimal amount of time.
So doing IDE specific tweaks won't cut it.  Our solution has worked
extremely well with other app containers for example WebSphere, Resin and
Jetty (all three that we use) come with support for something like this out
of the box.

The IDE we use really depends on the customer, project and environment.  So
could be any of the following ant+text editors, eclipse, WSDC, and/or
netbeans...  We can seemlessly switch between any of these using this
technique by just adding the extendedClasspath line to the context and
dropping a jar in server/lib/ all of which is handled by our ant scripts.

I am all for continuing this tangential discussion of webapp development
techniques but it really is tangential to the intent of the original post..

Hot-code replace works fine in this scenario, I get the impression that you
think it doesn't.  As for your comments about future proofing.  I am very
confident that IDE's will from now on into the future will compile my .java
files to some directory on the disk and that this option will be
configurable and use some consistent default.  So this solution is
completely future-proof.

In all the "jar exporting to WEB-INF" stuff I have seen in various IDE's you
need to manually kick off that process so it is adding a step to the
edit-compile process.  Effectively adding a deploy step so you have
edit-compile-deploy.  Which is exactly what I am trying to avoid albeit if
it is properly contained in the IDE it is less of a headache.

I enjoy the discussion of good practices (I don't think there is a one size
fits all best practice here) for having a smooth development process so keep
it coming ;-)

On 6/13/06, Darryl Miles <> wrote:
> Glen Marchesani wrote:
> >   <Loader
> >           className="org.apache.catalina.loader.MyWebappLoader"
> >
> extendedClasspath="C:/mycode/myproject/lib/*.jar;C:/mycode/myproject2/lib/*.jar;C:/mycode/myproject2/classes/"
> >       />
> > </Context>
> >
> > The reason for doing this is when developping a webapp that consists of
> > several smaller projects I wanted to be able to from within the ide
> > edit-compile-run skipping the deploy step.  Skipping the deploy step
> > saves a
> > fair bit of tediousness.
> Which IDE are you using ?
> My IDE understands both the containers classpath and the web-app
> classpath fairly well.  This means my IDE is able to resolve a
> dependency tree so its able to calculate the best possible approach to
> take.  My IDE also supports hot-code replace (providing the JVM will
> allow it for a given situation, adding fields is a problem when one or
> more instances exist).  My IDE also supports exporting of a JAR from
> another project into the WEB-INF/lib of the web-app project that is
> running under a debugging version of TC.
> If you are now bypassing all of the above, how do you cope with the
> problematic scenarios this now presents ?  On the face of it; it may
> appear to skip the redeploy process but how can you be sure what you are
> debugging is the current version of code ?  Then how in the future as
> IDE technology and tooling gets better can it make the best decision
> given that only the IDE has all the available knowledge about the
> edit-compile-run process.
> In short if one popular IDE is able to do so much (without patching
> features into TC) then it would appear to set the mark of what is
> possible.  It questions if your approach would be a long term fix or
> just a patch over how you currently see the problem in the moment.
> Maybe your problem is more of configuration.
> Infact I think might be worth adding a section to the documentation
> outlining the features TC supports in the development cycle and when and
> how to set them up for use.  Then another section on how setup (or tips)
> on working with a particular IDE (from the web-app developers PoV).
> Darryl
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message