You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Martin Koistinen <ma...@koistinen.com> on 1999/11/18 23:01:12 UTC
Am I in the right list?
I was wondering if I'm in the right list for general questions about Jakarta.
There seems to be a rather long thread of abstract thought about software
design (its interesting though).
Does anyone know where I could find out why Jakarta is presenting me with
cached classes even though it seem to be recompiling on changes? Is this a
known bug?
-- Martin
Re: Dynamic Class Loading
Posted by James Duncan Davidson <ja...@eng.sun.com>.
> so JSP based classes will re-load, but Servlet ones won't?
Reloading is the wrong word. When JSP compiles a class, it can change
the class name so that it's unique... So you can have GenServlet1,
GenServlet2 -- no class reloading necessary ! :)
.duncan
--
James Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do()
Re: Dynamic Class Loading
Posted by Anil V <an...@pacbell.net>.
Joseph Shelby wrote:
> "Anil K. Vijendran" wrote:
> > JSP files are indeed reloaded when you make little changes
> > to them. If you don't see them happen, please help me to reproduce it,
> > and I can fix it.
>
> so JSP based classes will re-load, but Servlet ones won't
That's right in Tomcat.
--
Peace, Anil +<:-)
Re: ´ð¸´: Dynamic Class Loading
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
AliGila wrote:
> "Anil K. Vijendran" wrote:
> >so JSP based classes will re-load, but Servlet ones won't?
> >Well, i suppose that would be easier to control, since the JSP engine
> >knows exactly what classes its controlling and where those files are
> >being stored, and could manage them independent of the main Servlet
> >engine (and probably does...). Yeah, i can see it in JspLoader.java now...
>
> yesterday,I have many trouble in this point:(
> It seem to work well whit JSP source file but not even
> beans contained in JSP.
That is to be expected. ***ONLY*** the JSP page itself exhibits the
auto-reload functionality. ***NO*** other Java classes (beans, servlets, or
anything else) are auto-reloaded by the current version of Tomcat.
Craig McClanahan
´ð¸´: Dynamic Class Loading
Posted by AliGila <al...@21cn.com>.
"Anil K. Vijendran" wrote:
>so JSP based classes will re-load, but Servlet ones won't?
>Well, i suppose that would be easier to control, since the JSP engine
>knows exactly what classes its controlling and where those files are
>being stored, and could manage them independent of the main Servlet
>engine (and probably does...). Yeah, i can see it in JspLoader.java now...
yesterday,I have many trouble in this point:(
It seem to work well whit JSP source file but not even
beans contained in JSP.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Dynamic Class Loading
Posted by jon * <jo...@clearink.com>.
on 11/18/99 6:17 PM, Joseph Shelby <ac...@io.com> wrote:
> hmm...i'm kinda seeing things the opposite -- I consider what's in
> a jar file to be "done and ready for delivery" (even if just alpha/beta
> testing);
> if a class is still being loaded via a .class file, then it is
> "still in development and testing" and is more likely to change (the source
> file is likely right next to it, being modified).
>
> I'd rather see .class files reloaded on change and .jar's left alone.
> regenerating a .jar file for every tweak is akin to restarting the
> servlet jvm (you are restarting _a_ jvm to make the jar, at any rate...
> but that's me just being pedantic :) ).
>
> or, again, the option to disable reloading...
Speed wise, reloading classes isn't a huge hit for development (regardless
of .class or .jar). Also, this would be a configurable option anyway, so on
a production server, you would turn this off.
-jon
Re: Dynamic Class Loading
Posted by Joseph Shelby <ac...@io.com>.
"Anil K. Vijendran" wrote:
> JSP files are indeed reloaded when you make little changes
> to them. If you don't see them happen, please help me to reproduce it,
> and I can fix it.
so JSP based classes will re-load, but Servlet ones won't?
Well, i suppose that would be easier to control, since the JSP engine
knows exactly what classes its controlling and where those files are
being stored, and could manage them independent of the main Servlet
engine (and probably does...). Yeah, i can see it in JspLoader.java now...
--
Jonathan Pierce wrote:
> I see no reason why we shouldn't pursue class reloading. Perhaps we should
> only reload classes that were loaded from lib jar files.
hmm...i'm kinda seeing things the opposite -- I consider what's in
a jar file to be "done and ready for delivery" (even if just alpha/beta testing);
if a class is still being loaded via a .class file, then it is
"still in development and testing" and is more likely to change (the source
file is likely right next to it, being modified).
I'd rather see .class files reloaded on change and .jar's left alone.
regenerating a .jar file for every tweak is akin to restarting the
servlet jvm (you are restarting _a_ jvm to make the jar, at any rate...
but that's me just being pedantic :) ).
or, again, the option to disable reloading...
joe
--
----------------------------------------------------------------------
Joseph Shelby mailto:acroyear@io.com
5809 Chase Commons Ct. #201 http://www.io.com/~acroyear
Burke, VA 22015 (703) 323-7121 | 247-7868
Software Engineer, ISX Corporation, Arlington, VA
"Any technology distinguishable from magic is insufficiently advanced"
-- First Corollary to Clarke's Law
----------------------------------------------------------------------
Re: Dynamic Class Loading
Posted by "Anil K. Vijendran" <An...@eng.sun.com>.
Joseph Shelby wrote:
> Basically, it does come to a matter of "convenience".
> When i'm making little, minor tweaks to .jsp files (especially when
> they're simple bug fixes or cosmetic changes to the HTML portions),
> it would definitely be a hassle to be required to shutdown and
> restart the server everytime. Debugging your web application requires
> "instant feedback" (as the original poster to this thread had mentioned
> when he started it).
See craig's previous post. JSP files are indeed reloaded when you make little changes
to them. If you don't see them happen, please help me to reproduce it, and I can fix
it.
--
Peace, Anil +<:-)
Dynamic Class Loading
Posted by Joseph Shelby <ac...@io.com>.
jon * wrote:
>
> on 11/18/99 4:55 PM, Craig R. McClanahan <cm...@mytownnet.com> wrote:
>
> > As our experience with Apache JServ showed (I'm one of the developers),
> > implementing class reloading is incredibly complicated. The semantics of the
> > JVM
> > force you to throw away the old class loader (and therefore all classes loaded
> > by
> > that class loader, and all object instances of these classes) in order to pull
> > this
> > off. Doing this without disrupting an ongoing application, and without
> > causing
> > class cast exceptions later, is quite a trick.
>
> But, I think that we have the knowledge to make it happen correctly. The
> custom classloader in Apache JServ 1.1 betas works quite well. I should
> know, I spent about 3 weeks fixing all the issues with it. ;-)
I agree. If its been done before, it can be done again. And theoretically
much easier the third time. (b.t.w., how much of AdaptiveClassLoader
would have to be re-written? any of it? and why? Admittedly, i'm still
on JServ 1.0 right now, so I've not looked at 1.1's changes...)
Perhaps an architecture that would load the appropriate class loader
(one that cares about .class/.jar/.zip file times, one that doesn't), and that
the chosen class loader is loaded at runtime, after checking the
configuration file...I do know I wouldn't want too many "if's" in there
at "delivery time" (for speed sake), and that might be the way to get rid of
many of them...
Basically, it does come to a matter of "convenience".
When i'm making little, minor tweaks to .jsp files (especially when
they're simple bug fixes or cosmetic changes to the HTML portions),
it would definitely be a hassle to be required to shutdown and
restart the server everytime. Debugging your web application requires
"instant feedback" (as the original poster to this thread had mentioned
when he started it).
another question -- is the reloader the problem, or the architecture
that surrounds it that needs to determine which loader to use and when?
(sorry if i'm a bit jvm-level code limited -- i've been doing mostly
swing stuff for the last year or so...)
joe
--
----------------------------------------------------------------------
Joseph Shelby mailto:acroyear@io.com
5809 Chase Commons Ct. #201 http://www.io.com/~acroyear
Burke, VA 22015 (703) 323-7121 | 247-7868
Software Engineer, ISX Corporation, Arlington, VA
"Any technology distinguishable from magic is insufficiently advanced"
-- First Corollary to Clarke's Law
----------------------------------------------------------------------
Re: Ant
Posted by Martin Koistinen <ma...@koistinen.com>.
Thanksgiving in the States is today, Nov. 25th.
At 05:41 PM 11/25/99 -0500, you wrote:
>When is Thanks Giving in the states? Ours was in October, and I don't think
>you mean a year from now :)
>
>- Brill Pappin
> www.jmonkey.com
>
>----- Original Message -----
>From: James Duncan Davidson <ja...@eng.sun.com>
>To: <ge...@jakarta.apache.org>
>Sent: Thursday, November 25, 1999 1:39 AM
>Subject: Re: Ant
>
>
> > Paul Philion wrote:
> > > Is ANT available in a seperate, stand-alone package. Or should I just
> > > grab from tomcat-tools?
> > >
> > > I'd like to use it with some other projects.
> >
> > Just grab it from tomcat-tools for now. After thanksgiving, I'm going to
> > get some builds set up so that you can do some one-stop-shopping.
> >
> > .duncan
> >
> > --
> > James Davidson duncan@eng.sun.com
> > Java + XML / Portable Code + Portable Data !try; do()
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: general-help@jakarta.apache.org
Re: Ant
Posted by Brill Pappin <br...@jmonkey.com>.
When is Thanks Giving in the states? Ours was in October, and I don't think
you mean a year from now :)
- Brill Pappin
www.jmonkey.com
----- Original Message -----
From: James Duncan Davidson <ja...@eng.sun.com>
To: <ge...@jakarta.apache.org>
Sent: Thursday, November 25, 1999 1:39 AM
Subject: Re: Ant
> Paul Philion wrote:
> > Is ANT available in a seperate, stand-alone package. Or should I just
> > grab from tomcat-tools?
> >
> > I'd like to use it with some other projects.
>
> Just grab it from tomcat-tools for now. After thanksgiving, I'm going to
> get some builds set up so that you can do some one-stop-shopping.
>
> .duncan
>
> --
> James Davidson duncan@eng.sun.com
> Java + XML / Portable Code + Portable Data !try; do()
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
Re: Ant
Posted by James Duncan Davidson <ja...@eng.sun.com>.
Paul Philion wrote:
> Is ANT available in a seperate, stand-alone package. Or should I just
> grab from tomcat-tools?
>
> I'd like to use it with some other projects.
Just grab it from tomcat-tools for now. After thanksgiving, I'm going to
get some builds set up so that you can do some one-stop-shopping.
.duncan
--
James Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do()
Re: Ant
Posted by Paul Philion <ph...@acmerocket.com>.
.duncan -
Is ANT available in a seperate, stand-alone package. Or should I just
grab from tomcat-tools?
I'd like to use it with some other projects.
- Paul
James Duncan Davidson wrote:
>
> > Is there some reason why Ant requires the Servlet-2.2.0.jar in its
> > classpath? It would be nice to remove that as a dependency.
>
> You're talking about in the build.sh file. Nope, it was moved over and
> not edited down far enough. :( Gone in a few hours.
>
> .duncan
> --
> James Davidson duncan@eng.sun.com
> Java + XML / Portable Code + Portable Data !try; do()
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
Re: Ant
Posted by James Duncan Davidson <ja...@eng.sun.com>.
> Is there some reason why Ant requires the Servlet-2.2.0.jar in its
> classpath? It would be nice to remove that as a dependency.
You're talking about in the build.sh file. Nope, it was moved over and
not edited down far enough. :( Gone in a few hours.
.duncan
--
James Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do()
Ant
Posted by jon * <jo...@clearink.com>.
Is there some reason why Ant requires the Servlet-2.2.0.jar in its
classpath? It would be nice to remove that as a dependency.
-jon
Re: Am I in the right list?
Posted by David Brownell <da...@pacbell.net>.
jon * wrote:
>
> on 11/19/99 10:39 PM, James Duncan Davidson <ja...@eng.sun.com>
> wrote:
>
> > I remember
> > all the design hoops that you went through on that! :)
>
> The Classloader is, IMHO, one of the most poorly designed parts of Java and
> it is so ingrained at this point that there is no hope of ever really
> improving it (at least not until a major revision...ie: Java 2.0 *). ;-(
>
> One should not be forced to write a custom class loader just to do class
> reloading. Period.
How could I ever agree with a statement _that_ extreme?
The fact that what you want to do isn't easy doesn't mean that
class loading is poorly designed. There are some fundamental
security issues (e.g. application integrity) that need to be
dealt with as part of "reloading". If you have solutions for
those, then reloading will in consequence be straightforward.
- Dave
Re: Am I in the right list?
Posted by jon * <jo...@clearink.com>.
on 11/19/99 10:39 PM, James Duncan Davidson <ja...@eng.sun.com>
wrote:
> I remember
> all the design hoops that you went through on that! :)
The Classloader is, IMHO, one of the most poorly designed parts of Java and
it is so ingrained at this point that there is no hope of ever really
improving it (at least not until a major revision...ie: Java 2.0 *). ;-(
One should not be forced to write a custom class loader just to do class
reloading. Period.
* Note that there will probably never be a Java2.0 cause there will be too
much confusion with the brain dead stupid idea of having Java2 == Java 1.2.
-jon
Re: Am I in the right list?
Posted by James Duncan Davidson <ja...@eng.sun.com>.
> But, I think that we have the knowledge to make it happen correctly. The
> custom classloader in Apache JServ 1.1 betas works quite well. I should
> know, I spent about 3 weeks fixing all the issues with it. ;-)
Yep. We should have somebody look at porting that code in. I remember
all the design hoops that you went through on that! :)
--
James Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do()
Re: Am I in the right list?
Posted by jon * <jo...@clearink.com>.
on 11/18/99 4:55 PM, Craig R. McClanahan <cm...@mytownnet.com> wrote:
> As our experience with Apache JServ showed (I'm one of the developers),
> implementing class reloading is incredibly complicated. The semantics of the
> JVM
> force you to throw away the old class loader (and therefore all classes loaded
> by
> that class loader, and all object instances of these classes) in order to pull
> this
> off. Doing this without disrupting an ongoing application, and without
> causing
> class cast exceptions later, is quite a trick.
But, I think that we have the knowledge to make it happen correctly. The
custom classloader in Apache JServ 1.1 betas works quite well. I should
know, I spent about 3 weeks fixing all the issues with it. ;-)
-jon
Re: Am I in the right list?
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
Joseph Shelby wrote:
> "Craig R. McClanahan" wrote:
> > Auto-reloading of changed servlet classes would be better characterized as a
> > missing feature, rather than a bug.
> >
> > What's going on is that, the first time you access a servlet, it's class file
> > gets loaded in to the JVMs memory. From then until you shut down Tomcat,
> > anything that happens to the original class file (you can even delete it) is
> > ignored, because the in-memory copy is being used. This is true for Java in
> > general, not just for servlets.
>
> ok, why the change?
What change? Jakarta Tomcat has never supported this feature.
> i figured the alternative (reloading the class
> if the .class file changed) would have been the harder thing to do
> (since its not the default by my understanding of the standard jvm
> as provided by sun and blackdown). I know JServ does it the other
> way, and i was pretty sure tomcat _used_ to do it the other way...
>
Nope. Tomcat (even in its earlier incarnations inside JSWDK and JSDK) has not ever
had this feature. You might be thinking about JWS, though, which is a product not
a reference implementation.
As our experience with Apache JServ showed (I'm one of the developers),
implementing class reloading is incredibly complicated. The semantics of the JVM
force you to throw away the old class loader (and therefore all classes loaded by
that class loader, and all object instances of these classes) in order to pull this
off. Doing this without disrupting an ongoing application, and without causing
class cast exceptions later, is quite a trick.
>
> is it just 'cause the re-checking is slowing it down too much?
>
> i would rather that be a configuration option -- i like having instant
> feedback when i change a .jsp file...killing the jvm and restarting it
> for every _minor_ .jsp change is a real hassle during development time...
>
Note: Tomcat *does* support reload checking on JSP pages -- not on servlets. When
it detects an updated JSP page it does not unload the old class; instead, it
generates a new class and starts using that instead. It can do this because the
JSP container owns the class name of the implementation of a page -- servlet
containers do not have that luxury.
>
> joe
>
Craig McClanahan
Re: Am I in the right list?
Posted by Joseph Shelby <ac...@io.com>.
"Craig R. McClanahan" wrote:
> Auto-reloading of changed servlet classes would be better characterized as a
> missing feature, rather than a bug.
>
> What's going on is that, the first time you access a servlet, it's class file
> gets loaded in to the JVMs memory. From then until you shut down Tomcat,
> anything that happens to the original class file (you can even delete it) is
> ignored, because the in-memory copy is being used. This is true for Java in
> general, not just for servlets.
ok, why the change? i figured the alternative (reloading the class
if the .class file changed) would have been the harder thing to do
(since its not the default by my understanding of the standard jvm
as provided by sun and blackdown). I know JServ does it the other
way, and i was pretty sure tomcat _used_ to do it the other way...
is it just 'cause the re-checking is slowing it down too much?
i would rather that be a configuration option -- i like having instant
feedback when i change a .jsp file...killing the jvm and restarting it
for every _minor_ .jsp change is a real hassle during development time...
joe
--
----------------------------------------------------------------------
Joseph Shelby mailto:acroyear@io.com
5809 Chase Commons Ct. #201 http://www.io.com/~acroyear
Burke, VA 22015 (703) 323-7121 | 247-7868
Software Engineer, ISX Corporation, Arlington, VA
"Any technology distinguishable from magic is insufficiently advanced"
-- First Corollary to Clarke's Law
----------------------------------------------------------------------
Re: Am I in the right list?
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
Martin Koistinen wrote:
> I was wondering if I'm in the right list for general questions about Jakarta.
>
About "Jakarta the project", yes. About "Jakarta Tomcat the servlet+JSP
container", probably not ... tomcat-dev would be better, but since you're here
...
>
> There seems to be a rather long thread of abstract thought about software
> design (its interesting though).
>
> Does anyone know where I could find out why Jakarta is presenting me with
> cached classes even though it seem to be recompiling on changes? Is this a
> known bug?
>
Auto-reloading of changed servlet classes would be better characterized as a
missing feature, rather than a bug.
What's going on is that, the first time you access a servlet, it's class file
gets loaded in to the JVMs memory. From then until you shut down Tomcat,
anything that happens to the original class file (you can even delete it) is
ignored, because the in-memory copy is being used. This is true for Java in
general, not just for servlets.
>
> -- Martin
>
Craig McClanahan