For simple applications in development, you're right -- there is no technical roadblack that prevents you from comingling your source and compiled classes, modifying Tomcat's classpath so that the default classloader finds them, and running your app. However, no one (or very few) do this because
(1) it's more complicated than compiling your classes directly to WEB-INF/classes,
(2) deploying, versioning, and managing such a setup, especially once you inevitably introduce multiple webapps, would be a collossal nightmare, and perhaps most importantly
(3) running each webapp in its own classloader (it classes loaded from WEB-INF/classes) allows Tomcat to manage that application independently -- for developers that means redeploying the application without restarting the server to catch changes that are made.
Unless you have some overwhelming reason to sidestep this, I'd suggest separating your source and compiled classes, using the directories as intended, and -- especially if this is a commercial project -- using Ant to do all of the above.
(And if you do see a reason otherwise, I'd love to hear it!) :)
justin
At 02:21 PM 11/4/2002, you wrote:
Consider you have a package structure:
com.xyz.clients (/home/jdoe/java/src/com/xyz/client)
com.xyz.server (/home/jdoe/java/src/com/xyz/server)
com.xyz.util (/home/jdoe/java/src/com/xyz/util)
Suppose you wanted to compile all these packages. Where would you direct
the output of the generated classes after compiliation? In order for
your Tomcat web application to be able to use the com.xyz.util classes
they need to be either copied to WEB-INF/classes or your compiler needs
to generate them and put them their right?
Currently, we have the complier place the .class files with the
packages. So, if we want to make them available to Tomcat, we would
have to copy them to Tomcat's WEB-INF directory. If Tomcat would let us
point our classpath to /home/jdoe/java/src then that step would be
unnecessary. It seems that I'm missing something rather obvious from
your answers.. :)
Chris
> -----Original Message-----
> From: tomcat-user-return-40023-
> [EMAIL PROTECTED]
[mailto:tomcat-user-return-
> [EMAIL PROTECTED]] On Behalf Of
Turner,
> John
> Sent: Monday, November 04, 2002 11:39 AM
> To: 'Tomcat Users List'
> Subject: RE: Tomcat and CLASSPATH
>
>
> We don't use symbolic links. Everything is under Tomcat's directory
tree.
>
> What is the advantage to using symbolic links or an external
classpath?
> I'm
> not seeing what advantage you would get.
>
> John
>
> > -----Original Message-----
> > From: Chris gokey [mailto:cgokey@;gcmd.nasa.gov]
> > Sent: Monday, November 04, 2002 11:30 AM
> > To: 'Tomcat Users List'
> > Subject: RE: Tomcat and CLASSPATH
> >
> >
> > That's actually what I was referring to by the building an
incremental
> > jar. Maybe that isn't the right term, but I meant as the
> > classes change
> > it will automatically update the jar with only the changed
> > classes. Of
> > course copying the changed class files to WEB-INF/classes would work
> > too. I just do not know enough about Ant to know if it can
> > capture the
> > classes that have changed and copy them. Still seems like it would
be
> > nice to be able to specify an external classpath in the web.inf
file..
> > thus, you wouldn't need two copies of your classes and jars
> > on the same
> > machine. What does everyone else do? Just have a script that does
a
> > straight copy?
> >
> > Chris
> >
> > > -----Original Message-----
> > > From: tomcat-user-return-40012-
> > > [EMAIL PROTECTED]
> > [mailto:tomcat-user-return-
> > > [EMAIL PROTECTED]] On
> > Behalf Of Cox,
> > > Charlie
> > > Sent: Monday, November 04, 2002 10:40 AM
> > > To: 'Tomcat Users List'
> > > Subject: RE: Tomcat and CLASSPATH
> > >
> > > can't you just have ant copy the modified classes(or jar)
> > to WEB-INF?
> > >
> > > > -----Original Message-----
> > > > From: Chris gokey [mailto:cgokey@;gcmd.nasa.gov]
> > > > Sent: Monday, November 04, 2002 10:34 AM
> > > > To: 'Tomcat Users List'
> > > > Subject: RE: Tomcat and CLASSPATH
> > > >
> > > >
> > > >
> > > > We never run Tomcat as root so this is not an issue. So
> > what is the
> > > > general pattern? To add to your Ant build script to
> > create a jar of
> > > > your application and place it in WEB-INF whenever the classes
> > change?
> > > > This is fine for small applications but for development, but for
> > very
> > > > large apps, it seems like pointing it to your general
> > classes would
> > be
> > > > much easier. Or is it possible for Ant to do incremental
> > > > changes to a
> > > > jar file?
> > > >
> > > > Chris
> > > >
> > > > > -----Original Message-----
> > > > > From: tomcat-user-return-39993-
> > > > > [EMAIL PROTECTED]
> > > > [mailto:tomcat-user-return-
> > > > > [EMAIL PROTECTED]] On Behalf
Of
> > > > Turner,
> > > > > John
> > > > > Sent: Monday, November 04, 2002 8:08 AM
> > > > > To: 'Tomcat Users List'
> > > > > Subject: RE: Tomcat and CLASSPATH
> > > > >
> > > > >
> > > > > And in general, symbolic links from an application space
running
> > as
> > > > root
> > > > > is
> > > > > generally a bad idea.
> > > > >
> > > > > John
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Andreas Probst [mailto:andpro77@;gmx.net]
> > > > > > Sent: Saturday, November 02, 2002 10:48 AM
> > > > > > To: Tomcat Users List
> > > > > > Subject: Re: Tomcat and CLASSPATH
> > > > > >
> > > > > >
> > > > > > Hi Chris,
> > > > > >
> > > > > > you could set your classpath in the tomcat startup script.
But
> > > > > > this is not recommended. There were messages a few days ago
> > > > > > explaining this.
> > > > > >
> > > > > > Besides, it might not always be desirable that Tomcat
> > knows when
> > > > > > classes change...
> > > > > >
> > > > > > Andreas
> > > > > >
> > > > > >
> > > > > > On 2 Nov 2002 at 7:52, Chris gokey wrote:
> > > > > >
> > > > > > > Under UNIX it was very convenient for us to create
> > a symbolic
> > > > > > > link from our WEB-INF/lib and WEB-INF/classes
> > directory to the
> > > > > > > respective directories in our package that contained
> > > > our jars and
> > > > > > > to the base directory of our package structure (for the
> > purpose
> > > > > > > of setting up the CLASSPATH). But unfortunately this
> > > > approach is
> > > > > > > not platform independent and won't work under
> > windows. Is my
> > > > > > > only alternative to copy all these files to WEB-INF? The
> > > > > > > advantage of symbolically linking is that any time these
> > classes
> > > > > > > changed, Tomcat would automatically know about it. Is
there
> > > > > > > another way to tell Tomcat where my claases are? Possibly
> > > > > > > specify the CLASSPATH in my web.xml file?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Chris
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > > <mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > > <mailto:tomcat-user-help@;jakarta.apache.org>
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail: <mailto:tomcat-user-> > > > > [EMAIL PROTECTED]>
> > > > > For additional commands, e-mail: <mailto:tomcat-user-> > > > > [EMAIL PROTECTED]>
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > > <mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > > <mailto:tomcat-user-help@;jakarta.apache.org>
> > > >
> > >
> > > --
> > > To unsubscribe, e-mail: <mailto:tomcat-user-> > > [EMAIL PROTECTED]>
> > > For additional commands, e-mail: <mailto:tomcat-user-> > > [EMAIL PROTECTED]>
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:tomcat-user-help@;jakarta.apache.org>
>
> --
> To unsubscribe, e-mail: <mailto:tomcat-user-> [EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:tomcat-user-> [EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
-- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
