I can't get servlet re-loading to work in TC4b3. Looking at the code -
Loader creates a thread that sleeps until the time set in server.xml
expires. This thread calls StandardClassLoader.modified
The modified call checks the classCache to see if there are any entries
(code is here)
if (classCac
Sorry it's taken me a week to get back to you on this. Class-reloading is
not working in the latest nightly build. I know why, but don't know what the
fix is.
The problem is in StandardClassLoader::loadClass. This method checks that
the class exists, if it does it wants to add
to the
> cache.
>
> Should that 'jndi:/localhost' be there ?
>
> This is with the latest nightly build BTW,
>
By "latest", do you mean 20010503? The reason I ask is that Remy made
some changes yesterday that would have shown up in the 20010504 build, and
et added to the
> cache.
>
> Should that 'jndi:/localhost' be there ?
I take it from the silence that this behaviour is expected and that I should
not be able to do any reloading?
Kevin Jones
DevelopMentor
www.develop.com
> -Original Message-
> From: Kevin Jones
R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: 04 May 2001 20:00
> To: Tomcat-Dev
> Subject: Re: class reloading
>
>
>
>
> On Fri, 4 May 2001, Kevin Jones wrote:
>
> > I can't get servlet re-loading to work in TC4b3. Looking at the code -
> >
> &g
On Mon, 7 May 2001, Kevin Jones wrote:
> > Printing out the value of 'pathname' just before this code executes gives
> >
> > "jndi:/localhost/AddressBook/WEB-INF/classes\com\develop\ewebjava\
> > lab\Browse
> > .class",
> >
> > which means that the 'file' doesn't exist and so doesn't get added
ently supported only for unpacked
classes in WEB-INF/lib.
Craig
On Fri, 11 May 2001, Kevin Jones wrote:
> Sorry it's taken me a week to get back to you on this. Class-reloading is
> not working in the latest nightly build. I know why, but don't know what the
> fix is
"Craig R. McClanahan" wrote:
> Thanks Kevin ... I think it's safe to assume that Beta 4 still has this
> issue :-(.
>
> But, other than efficiency concerns, it should still work if the
> particular class is *only* found in WEB-INF/classes and *not* in any of
> the WEB-INF/lib/*.jar files, right?
On Fri, 11 May 2001, Bo Xu wrote:
> "Craig R. McClanahan" wrote:
>
> > Thanks Kevin ... I think it's safe to assume that Beta 4 still has this
> > issue :-(.
> >
> > But, other than efficiency concerns, it should still work if the
> > particular class is *only* found in WEB-INF/classes and *no
ECTED]]
> Sent: 11 May 2001 18:58
> To: Tomcat-Dev
> Subject: Re: Class Reloading
>
>
> Thanks Kevin ... I think it's safe to assume that Beta 4 still has this
> issue :-(.
>
> But, other than efficiency concerns, it should still work if the
> particular class is
After a successful FORM login, how does Tomcat restore the original request?
If it uses the forward mechanism, how does it force the browser to use the
URL of the original request, and not */j_security_check?
Tim Julien
HP Middleware
On Fri, 11 May 2001, JULIEN,TIMOTHY (HP-NewJersey,ex2) wrote:
> After a successful FORM login, how does Tomcat restore the original request?
> If it uses the forward mechanism, how does it force the browser to use the
> URL of the original request, and not */j_security_check?
>
> Tim Julien
>
Kevin Jones wrote:
> [...]
> I believe (I've yet to test this) that the only way reloading works
> currently (for me) is if I have no jars in web-inf/lib,
>
> Kevin Jones
> DevelopMentor
> www.develop.com
> [...]
yes! I just test it with TC4.0-b4:
- when I empty WEB-INF/lib, auto-reloading works
"Craig R. McClanahan" wrote:
>
> On Fri, 11 May 2001, JULIEN,TIMOTHY (HP-NewJersey,ex2) wrote:
>
> > After a successful FORM login, how does Tomcat restore the original request?
> > If it uses the forward mechanism, how does it force the browser to use the
> > URL of the original request, and no
Quoting Bo Xu <[EMAIL PROTECTED]>:
> Kevin Jones wrote:
>
> > [...]
> > I believe (I've yet to test this) that the only way reloading works
> > currently (for me) is if I have no jars in web-inf/lib,
> >
> > Kevin Jones
> > DevelopMentor
> > www.develop.com
> > [...]
>
> yes! I just test it wit
On Fri, 11 May 2001, Remy Maucherat wrote:
>
> but unfortunately, it's a post beta 4 fix.
>
This is going to turn out not to be a problem, as it happens.
Tomcat 4.0-beta-4 is also subject to the "...jsp%00" bug that Marc just
fixed in 3.2.2 (patch will be committed in a second). However, th
On Fri, 11 May 2001, Craig R. McClanahan wrote:
> Tomcat 4.0-beta-4 is also subject to the "...jsp%00" bug that Marc just
> fixed in 3.2.2 (patch will be committed in a second). However, the more
> serious issue is the introspection one (I can hear Costin laughing at me
> from 600 miles away :-)
On Fri, 11 May 2001 [EMAIL PROTECTED] wrote:
> On Fri, 11 May 2001, Craig R. McClanahan wrote:
>
> > Tomcat 4.0-beta-4 is also subject to the "...jsp%00" bug that Marc just
> > fixed in 3.2.2 (patch will be committed in a second). However, the more
> > serious issue is the introspection one (
On Fri, 11 May 2001, Craig R. McClanahan wrote:
> > The introspection problem is not very serious - it doesn't work if
> > sandboxing is enabled ( at least from what I know - if it works then it's
> > a very serious VM bug ).
> >
>
> It doesn't work if you start Tomcat 4.0 with a security mana
[EMAIL PROTECTED] wrote:
>
> On Fri, 11 May 2001, Craig R. McClanahan wrote:
>
> > > The introspection problem is not very serious - it doesn't work if
> > > sandboxing is enabled ( at least from what I know - if it works then it's
> > > a very serious VM bug ).
> > >
> >
> > It doesn't work if
This now works in the latest nightly drop, thanks guys,
Kevin Jones
DevelopMentor
www.develop.com
> -Original Message-
> From: Kevin Jones [mailto:[EMAIL PROTECTED]]
> Sent: 11 May 2001 22:44
> To: [EMAIL PROTECTED]
> Subject: RE: Class Reloading
>
>
> >
On Sat, 12 May 2001, Glenn Nielsen wrote:
> [EMAIL PROTECTED] wrote:
> >
> > If the security manager is not used everything has AllPermissions - the
> > fact that someone can access the internal objects is quite small compared
> > with the fact that it could call System.exit() and read/change an
I saw a message on here a while back about problems with class
reloading for accessory classes within a context, but never saw a resolution for
the problem. I am having this problem currently when trying to save an
object to the servlet context for use by multiple servlets. When the class
Guten Tag!
I have a .java under WEB-INF/classes/ changed and recompled after
tomcat started,
but it always plays as old version.
Can anybody tell me about it ?
thanks
malix
shanghai china
hey,
Is anyone fixing that point? Problem is that JSP doesn't reload classes when servlet
container in same context does?
Tuukka
---
--Me olemme keskella jotain. jossa olemme totaalisen ulkopuolisia--
Get 250 color business cards for FREE!
http://businesscards.lycos.com/vp/fastpath/
On Wed, 30 May 2001, Tuukk4 |[:)<-<| p4s4n3n wrote:
> hey, Is anyone fixing that point? Problem is that JSP doesn't reload
> classes when servlet container in same context does?
>
Can you provide a small example that illustrates this?
> Tuukka
>
Craig McClanahan
i was litlle un detailed sorry but i try to explain.
This can be test with Tomcat 4.0 b6-dev (last week CVS version at least i haven't see
this to be fixed)
make app dir like test/ then create index.jsp.
make some class like test.testIt that context is like
package test;
public class TestIt
> i was litlle un detailed sorry but i try to explain.
>
> This can be test with Tomcat 4.0 b6-dev (last week CVS version at least i
haven't see this to be fixed)
>
> and turn reloading on to test/ context then create servlet that uses this
Class [test.TestIt] (i think you know how to do it) make
See below.
On Thu, 31 May 2001, Remy Maucherat wrote:
> > i was litlle un detailed sorry but i try to explain.
> >
> > This can be test with Tomcat 4.0 b6-dev (last week CVS version at least i
> haven't see this to be fixed)
> >
> > and turn reloading on to test/ context then create servlet that
Quoting "Craig R. McClanahan" <[EMAIL PROTECTED]>:
> See below.
>
> On Thu, 31 May 2001, Remy Maucherat wrote:
>
>
> I'm not sure this proposed change would really make any difference.
> The
> "parent" classloader here is the web app classloader already, which is
> the
> same thing that the c
On Thu, 31 May 2001 12:40:34
Remy Maucherat wrote:
>Quoting "Craig R. McClanahan" <[EMAIL PROTECTED]>:
>
>> See below.
>>
>> On Thu, 31 May 2001, Remy Maucherat wrote:
>>
>>
>> I'm not sure this proposed change would really make any difference.
>> The
>> "parent" classloader here is the web
as any ideas about for the Tomcat
3.x tree.
-Dave
-Original Message-
From: Allen Akers [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 19, 2000 7:45 AM
To: [EMAIL PROTECTED]
Subject: Class reloading problems
I saw a message on here a while back about problems with class reloading for
is normal and what in the hell
is taking so long in "java.io.Win32FileSystem.canonacalize"? Once I
disabled class reloading, by performance and CPU utilization went back to what
was present with 3.1.
Thanks for any input.
Brett M. Bergquist
Canoga Perkins Corp.
T
> and ook a look. I found that 68% time was being spent in
> "org.apache.tomcat.core.ServletWrapper.handleReload" and of the time
> within this method, 51% of the time was being spent in
> "java.io.File.getCanonicalPath" and of the time spend within this method,
&
> The cases you've described above all happen only once (at startup
> time). Assuming that we could safely optimize these cases, would it
> really make a significant difference?
It wouldn't.
While you were away, I did some profiling of the startup (since people
complained), and it turns out tha
Remy & Craig,
Thanks for your responses...
On Saturday, July 7, 2001, at 07:28 am, Remy Maucherat wrote:
>> The cases you've described above all happen only once (at startup
>> time). Assuming that we could safely optimize these cases, would it
>> really make a significant difference?
>
> It
36 matches
Mail list logo
