7;t have a clean interface ).
I placed it in util/loader mainly for eclipse/IDE users - I have it
compiled to a separate classes dir, and use the eclipse autocompilation
- it's pretty cool and efficient ( i.e. no need to use "ant" or compile
most of the time, just
Costin Manolache wrote:
I checked in the first part - I'm still working on making build.xml
changes and the catalina-side code.
It is certainly experimental code for now - I think it works better than
Bootstrap/etc, but the reloading of connectors/etc is still very tricky
( it kind of works, b
works, but I still don't have a clean interface ).
I placed it in util/loader mainly for eclipse/IDE users - I have it
compiled to a separate classes dir, and use the eclipse autocompilation
- it's pretty cool and efficient ( i.e. no need to use "ant" or compile
most of th
ss or eclipse -
which both use similar class loaders and module mechanisms ( jbossmx and
osgi ).
One extra benefit may be on allowing more flexibility in the
common/shared/webapp hierarchy - if WebappClassLoader extends the
loader, it will be easier to have webapps using different versions of
s
omcat in apps like jboss or eclipse -
which both use similar class loaders and module mechanisms ( jbossmx and
osgi ).
One extra benefit may be on allowing more flexibility in the
common/shared/webapp hierarchy - if WebappClassLoader extends the
loader, it will be easier to have webapps
asier to integrate tomcat in apps like jboss or eclipse -
which both use similar class loaders and module mechanisms ( jbossmx
and osgi ).
One extra benefit may be on allowing more flexibility in the
common/shared/webapp hierarchy - if WebappClassLoader extends the
loader, it will be easier to
Costin Manolache wrote:
Mladen Turk wrote:
What about commons-deamon?
What about it :-) ?
Daemon is a different level - it's about launching a resident process
(or service in windows ). No connection with how the process is loading
its classes.
Sure, but the wheel was invented long time ago :).
omcat in apps like jboss or eclipse -
which both use similar class loaders and module mechanisms ( jbossmx
and osgi ).
One extra benefit may be on allowing more flexibility in the
common/shared/webapp hierarchy - if WebappClassLoader extends the
loader, it will be easier to have webapps
l was invented long time ago :).
How about making things usable?
Which things to make usable ? Daemon ? It's not my itch to start
services on windows:-)
Yes, the wheel was invented long ago - and we are still using the
simplistic hierarchical class loader + delegation.
Do we really need all those
Remy Maucherat wrote:
I didn't have time to look at the code yet, though.
Wait a week or 2 - the loader part is fine, but the catalina side is
still a bit messy and I need to find a good way to integrate with the
build ( to make it completely optional/isolated - I don't want to affec
I am using Tomcat 3.2.1 and getting the Exception printed below for a class
file (VCALookup.class) that I KNOW is not malformed (since the class loads
and runs fine under Weblogic 4.0.4). The Exception appears to occur during
the loading of another class (VCATemplate) that in turn accesses VCALook
javax.sql.DataSource is legal as a class file in a webapp library, but
not in a system wide library, such as is found in CATALINA/common/lib
My question is, if having javax.sql.DataSource was a problem in the
parent class loader, why isnt it a problem in the lower loaders?
AS a bit of history, I s
Gentlemen,
I hope you
will be able to assist me with a Tomcat Class Loader problem I am
experiencing. I am using:
Apache Tomcat: 4.0.1
JDK: 1.4.1_02
Running on Windows 2000
Server.
I have the
following java
code:
import java.util.*;
public class ActionFactory
--Original Message-
From: Wildeboer, Tonnis
Sent: Tuesday, May 01, 2001 7:20 PM
To: '[EMAIL PROTECTED]'
Subject: Class Loader Problem?
I am using Tomcat 3.2.1 and getting the Exception printed below for a class
file (VCALookup.class) that I KNOW is not malformed (since the class loads
"Wildeboer, Tonnis" wrote:
>
> [...]
>
> I have gone so far as completely removing VCALookup.class from my classes
> directory and I still get the same Exception.
> I also tried instantiating the class from a different file (first line of my
> doGet()) and still get the same Exception.
> I copied
esson in itself...
Thanks for your reply.
--Tonnis
-Original Message-
From: Bip Thelin [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 08, 2001 4:48 PM
To: [EMAIL PROTECTED]
Subject: Re: Class Loader Problem?
"Wildeboer, Tonnis" wrote:
>
> [...]
>
> I have gone so
PROTECTED]]
> Sent: Tuesday, May 08, 2001 5:47 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Class Loader Problem?
>
>
> Well, I considered all those things and finally, I did the only thing you
> can do when things get this weird:
> I did a completely clean checkou
Ted,
Thanks for your reply. My responses below...
--Tonnis
> -Original Message-
> From: Ted Neward [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 11, 2001 1:35 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Class Loader Problem?
>
>
> I think it's fairly safe
// "org.apache.crimson.jaxp.DocumentBuilderImpl",
> // Crimson added in
> 1.4
> };
>
> In this case, there is a different list of files that are excluded.
>
> So, for some reason, it has been decided that
In my opinion, this is a bad design decision. ClassLoaders are supposed to
delegate to their parent before attempting to load a class and the system
class loader (which loads the core libraries and all standard extensions) is
the parent of all classloaders. So, if you're worried
> In my opinion, this is a bad design decision. ClassLoaders are supposed
to
> delegate to their parent before attempting to load a class and the system
> class loader (which loads the core libraries and all standard extensions)
is
> the parent of all classloaders. So, if you'
n
c.. Bootstrap classes of your JVM
d.. System class loader classses (described above)
e.. $CATALINA_HOME/common/classes
f.. $CATALINA_HOME/common/lib/*.jar
g.. $CATALINA_HOME/classes
h.. $CATALINA_HOME/lib/*.jar
Wouldn't it be better to do it this way...
a.. Bootstrap classes of yo
of your web application
> c.. Bootstrap classes of your JVM
> d.. System class loader classses (described above)
> e.. $CATALINA_HOME/common/classes
> f.. $CATALINA_HOME/common/lib/*.jar
> g.. $CATALINA_HOME/classes
> h.. $CATALINA_HOME/lib/*.jar
> Wouldn't it b
On Wed, 27 Feb 2002, James Carman wrote:
> Date: Wed, 27 Feb 2002 17:09:33 -0500
> From: James Carman <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: Class Loader Trig
TED]>
Sent: Wednesday, February 27, 2002 6:01 PM
Subject: Re: Class Loader Triggers
>
>
> On Wed, 27 Feb 2002, James Carman wrote:
>
> > Date: Wed, 27 Feb 2002 17:09:33 -0500
> > From: James Carman <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Developers
> Shouldn't the servlet.jar file be placed on the system classpath by the
> startup scripts? The servlet container itself supports a specific version
> of the servlet API and the web applications should not be able to pick and
> choose which version they wish to use. Placing these classes on the
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:414)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:378)
... my stuff
Seems to be a problem with the class loader code when doing dispatching,
because if I call the destination
SE.
If I run the code outside Tomcat with the same classpath everything works.
This looks like a class loader mess, but given that the Tomcat code needs
access to the j2ee.jar I can't think of a way around it.
Any ideas appreciated.
OpenJaw Technologie
Hi,
I've switched (temporarily, maybe) away from JavaService to Procrun.
The problem is that I couldn't get it to work.
In the install script, I'm using the following command:
ExecWait '"$INSTDIR\bin\tomcatw.exe" //IS//Tomcat5 --DisplayName
"Apache Tomcat @VERSION@" --Description "Apache Tomca
Remy,
We don't have checkInterval attribute for loader and
manager after refactoring. Should I remove it from
admin? I see it's broken since then.
Thanks,
Amy
HTTP Status 500 - Error retrieving attribute
che
costin 2004/10/05 21:56:56
jakarta-tomcat-connectors/util/loader/org/apache/tomcat/util/loader - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
costin 2004/10/06 08:41:44
Modified:util build.xml
util/loader/org/apache/tomcat/util/loader Loader.java
Module.java
Log:
A bit of cleanup. The lib dir and the checked in binaries are long gone.
Avoid creation of loader dir if loader is
; Date: Sat, 17 Feb 2001 19:40:29 -0800
> > To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> > Subject: Tomcat 4.0 Class Loader Reorganization
> >
> > I've changed the way that Tomcat 4.0 loads classes so that we should no
> > longer have the "package sealing violation
lina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:513)
> at
>
>org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:414)
> at
>
>org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:378)
>
I understand that the patch would be welcome :) But I must say that it's
definitely not easy to get down into the class loading code of Tomcat.
My gut feeling about this bug is that somehow the class loader isn't the
right one once the dispatching process starts. In my example it
> > at
> org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:594)
> > at
> >
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:513)
> > at
> >
>
>org.apache.catalina.core.ApplicationDispatcher.doInclude(A
at
>
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.
java:513)
> at
>
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatch
er.java:414)
> at
>
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher
.java:378)
> ... my
I noticed there were comments saying that it's hard to replicate. I get it
pretty regularly, but the trick seems to be that it only occurs for me once
I reload a context. Then pretty much my first servlet request generates
this error.
I couldn't figure out how to add a note to a bug in Bugzi
> I noticed there were comments saying that it's hard to replicate. I get
it
> pretty regularly, but the trick seems to be that it only occurs for me
once
> I reload a context. Then pretty much my first servlet request generates
> this error.
>
> I couldn't figure out how to add a note to a bug
-
From: Sean [mailto:[EMAIL PROTECTED]]
Sent: 03 September 2002 22:31
To: [EMAIL PROTECTED]
Subject: j2ee/j2se class loader problem??
My environment is Win 2k, JDK 1.4, J2EE 1.4.1 on Tomcat 4.0.2.
Within my SOAP service running on Tomcat I need to access an entity
EJB and also post messages
Remy Maucherat wrote:
Hi,
I've switched (temporarily, maybe) away from JavaService to Procrun.
The problem is that I couldn't get it to work.
In the install script, I'm using the following command:
ExecWait '"$INSTDIR\bin\tomcatw.exe" //IS//Tomcat5 --DisplayName
"Apache Tomcat @VERSION@" --De
jean-frederic clere wrote:
Remy Maucherat wrote:
Hi,
I've switched (temporarily, maybe) away from JavaService to Procrun.
The problem is that I couldn't get it to work.
In the install script, I'm using the following command:
ExecWait '"$INSTDIR\bin\tomcatw.exe" //IS//Tomcat5 --DisplayName
"
> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
> Sent: 17. veljača 2003 9:38
> To: Tomcat Developers List
> Subject: Re: [5.0] Procrun problems / New loader
>
> jean-frederic clere wrote:
> > Remy Maucherat wrote:
> >
> >&g
[EMAIL PROTECTED] wrote:
-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
Sent: 17. veljača 2003 9:38
To: Tomcat Developers List
Subject: Re: [5.0] Procrun problems / New loader
jean-frederic clere wrote:
Remy Maucherat wrote:
I've switched (temporarily,
[EMAIL PROTECTED] wrote:
Those can be used only if you redirect onother process. Try with "-Java
java".
Ok, it's the magic parameter indeed :) Rereading the readme.txt, it
looks like it's supposed to be equivalent to "auto".
Another question: Can I use procrun on 9x ?
There's a duplication of
> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
> Sent: 17. veljača 2003 11:28
> To: Tomcat Developers List
> Subject: Re: [5.0] Procrun problems / New loader
>
>
> [EMAIL PROTECTED] wrote:
> > Those can be used only if you redi
[EMAIL PROTECTED] wrote:
It could, need some API cheching. There is no CreateRemoteThread API,
and Services alltogether.
The simplest would be using some #ifdefs and and another build.
If the nsis installer can distinguish the host OS, than we can
make something like procrun9x.
That's doable.
> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
> >
> > The simplest would be using some #ifdefs and and another
> build. If the
> > nsis installer can distinguish the host OS, than we can
> make something
> > like procrun9x.
>
> That's doable. I don't know i
[EMAIL PROTECTED] wrote:
-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
Sent: 17. veljača 2003 11:28
To: Tomcat Developers List
Subject: Re: [5.0] Procrun problems / New loader
[EMAIL PROTECTED] wrote:
Those can be used only if you redirect onother process. Try
> -Original Message-
> From: jean-frederic clere
> [mailto:[EMAIL PROTECTED]]
> Sent: 17. veljača 2003 12:14
> To: Tomcat Developers List
> Subject: Re: [5.0] Procrun problems / New loader
>
> #ifdefs No...
> I remember doing this in instmain.c
> (jaka
[EMAIL PROTECTED] wrote:
-Original Message-
From: jean-frederic clere
[mailto:[EMAIL PROTECTED]]
Sent: 17. veljača 2003 12:14
To: Tomcat Developers List
Subject: Re: [5.0] Procrun problems / New loader
#ifdefs No...
I remember doing this in instmain.c
(jakarta-commons-sandbox/daemon
[EMAIL PROTECTED] wrote:
-Original Message-
From: jean-frederic clere
[mailto:[EMAIL PROTECTED]]
Sent: 17. veljača 2003 12:14
To: Tomcat Developers List
Subject: Re: [5.0] Procrun problems / New loader
#ifdefs No...
I remember doing this in instmain.c
(jakarta-commons-sandbox/daemon
> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
>
> There's a puzzling side effect to procrun, though: Ant fails to start
> the Java compiler in "fork" mode. If I disable forking javac,
> it works. Does the Java process lose the right to fork other
> processes
[EMAIL PROTECTED] wrote:
-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
There's a puzzling side effect to procrun, though: Ant fails to start
the Java compiler in "fork" mode. If I disable forking javac,
it works. Does the Java process lose the right to fork other
[EMAIL PROTECTED] wrote:
-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
There's a puzzling side effect to procrun, though: Ant fails to start
the Java compiler in "fork" mode. If I disable forking javac,
it works. Does the Java process lose the right to fork other
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
-Original Message-
From: jean-frederic clere
[mailto:[EMAIL PROTECTED]] Sent: 17. veljača 2003
12:14
To: Tomcat Developers List
Subject: Re: [5.0] Procrun problems / New loader
#ifdefs No...
I remember doing this in instmain.c
Amy Roh wrote:
Remy,
We don't have checkInterval attribute for loader and
manager after refactoring. Should I remove it from
admin? I see it's broken since then.
Ah, yes, sorry, I forgot to update admin :-(
All containers should get the new "backgroundProcessorDelay" at
I have fixed admin so checkInterval is no longer on the context pages. I like your
first name better than "backgroundProcessorDelay" ;-)
Remy Maucherat <[EMAIL PROTECTED]> wrote:
Amy Roh wrote:
> Remy,
>
> We don't have checkInterval attribute for loader a
Amy Roh wrote:
I have fixed admin so checkInterval is no longer on the context pages. I like your first name better than "backgroundProcessorDelay" ;-)
Really ? It was executeDelay. The problem was that it gave no clue as to
what it did; maybe it was "lighter" than the current one. I'm no good
f
The docs for both Tomcat 4 and 5 imply that you can nest a Context Listener inside
the DefaultContext. But this had not been implemented.
I had a need to implement a custom Context Listener and Custom Loader (WebappLoader)
which needed to be configurable using the DefaultContext.
I have patches
Glenn Nielsen wrote:
The docs for both Tomcat 4 and 5 imply that you can nest a Context
Listener inside
the DefaultContext. But this had not been implemented.
I had a need to implement a custom Context Listener and Custom Loader
(WebappLoader)
which needed to be configurable using the
costin 2005/09/28 23:35:48
Modified:util/loader/org/apache/tomcat/util/loader Loader.java
Module.java ModuleClassLoader.java
ModuleListener.java Repository.java package.html
Removed: util/loader/org/apache/tomcat/util/loader
gzilla/show_bug.cgi?id=6714
Class Loader error
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
gzilla/show_bug.cgi?id=7891
Class loader collision
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
gzilla/show_bug.cgi?id=11846
Class loader problem
--- Additional Comments From [EMAIL PROTECTED] 2002-08-20 20:53 ---
We are experiencing a very similar problem with our project.
We have a Web App which is accessing EJBs running on a WebLogic 6.1
installation. Thus in WEB-INF/lib w
gzilla/show_bug.cgi?id=11846
Class loader problem
--- Additional Comments From [EMAIL PROTECTED] 2002-08-21 02:21 ---
Certainly my problem is not a bug. Using Tomcat 4.1.9b, a message is printed
highlighting the servlet spec which requires that libraries in WEB-INF/lib not
overrise javax.s
gzilla/show_bug.cgi?id=11846
Class loader problem
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
I have just fixed this in CVS. Thanks for the report.
Mark
> -Original Message-
> From: Daniel Rall [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 02, 2004 12:26 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [PATCH][Tomcat 4.1 docs] Class loader HOWTO
>
costin 2004/10/05 22:01:16
Added: util/loader loader.properties
Log:
Example loader.properties ( I need to clean it up to match the distro, right now
it's using
my eclipse layout ).
Revision ChangesPath
1.1 jakarta-tomcat-connectors/util/l
gzilla/show_bug.cgi?id=6714
Class Loader error
Summary: Class Loader error
Product: Tomcat 4
Version: 4.0.2 Final
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Ca
gzilla/show_bug.cgi?id=7891
Class loader collision
Summary: Class loader collision
Product: Tomcat 4
Version: 4.0 Beta 6
Platform: PC
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Ca
gzilla/show_bug.cgi?id=11846
Class loader problem
Summary: Class loader problem
Product: Tomcat 4
Version: 4.0.4 Final
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Minor
Priority: Other
Com
gzilla/show_bug.cgi?id=24508
Webapp class loader issue
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
gzilla/show_bug.cgi?id=24508
Webapp class loader issue
--- Additional Comments From [EMAIL PROTECTED] 2003-11-07 19:20 ---
a) The Sun engineer is wrong
b) This has been discussed at length, and the current behavior will not be
changed, as it is the one which gives the best behavior
c) Ple
gzilla/show_bug.cgi?id=30568
Cannot find daemon loader
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
gzilla/show_bug.cgi?id=30568
Cannot find daemon loader
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
Status|RE
gzilla/show_bug.cgi?id=30568
Cannot find daemon loader
--- Additional Comments From [EMAIL PROTECTED] 2004-09-08 19:51 ---
OK, if you want, please submit doc patches for setup.xml and I'll modify that
file so that the instructions
gzilla/show_bug.cgi?id=30568
Cannot find daemon loader
--- Additional Comments From [EMAIL PROTECTED] 2004-09-09 01:33 ---
Perhaps you misinterpret my comments. The documentation describes two different
ways to start Tomcat. The method described in RUNNING.txt works okay. The method
descri
gzilla/show_bug.cgi?id=30568
Cannot find daemon loader
--- Additional Comments From [EMAIL PROTECTED] 2004-09-15 16:20 ---
I understand your comments, I think ;) I'm asking you to provide a diff patch
of setup.xml so that it
costin 2004/10/05 21:56:33
jakarta-tomcat-connectors/util/loader - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Not Acked...
Pier
-- Forwarded Message
> From: [EMAIL PROTECTED] (CTP Steve Temple)
> Date: Thu, 28 Feb 2002 13:57:14 -
> To: <[EMAIL PROTECTED]>
> Subject: The Tomcat 4 Servlet-JSP Container - Class Loader INFO
>
> Hi,
>
> Just a quick one, I noti
gzilla/show_bug.cgi?id=16577
WebappClassLoader delegates to parent loader
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
gzilla/show_bug.cgi?id=16577
WebappClassLoader delegates to parent loader
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Reso
gzilla/show_bug.cgi?id=16577
WebappClassLoader delegates to parent loader
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Reso
gzilla/show_bug.cgi?id=16577
WebappClassLoader delegates to parent loader
--- Additional Comments From [EMAIL PROTECTED] 2003-01-30 19:14 ---
Okay, thanks for clearing that up (the part about not being open for
discussion).
In light of your decision you might want to tell the documentation
remm2003/09/05 01:56:01
Modified:webapps/docs class-loader-howto.xml
Log:
- Classloader docs refresh.
Revision ChangesPath
1.4 +40 -30jakarta-tomcat-catalina/webapps/docs/class-loader-howto.xml
Index: class-loader-howto.xml
remm2003/09/08 06:49:32
Modified:webapps/docs class-loader-howto.xml
Log:
- Update the classloader contents.
Revision ChangesPath
1.5 +4 -1 jakarta-tomcat-catalina/webapps/docs/class-loader-howto.xml
Index: class-loader-howto.xml
es of your JVM
System class loader classses (described above)
[...]
Shouldn't this really be:
Bootstrap classes of your JVM
System class loader classses (described above)
/WEB-INF/classes of your web application
/WEB-INF/lib/*.jar of your web application
[...]
Otherwise, Rem
luehe 2003/09/08 15:03:32
Modified:webapps/docs class-loader-howto.xml
Log:
- Fixed classloader delegation order as seen from webapp perspective.
- Removed "org.apache.commons.logging.*" from list of packages that trigger
delegation to parent (the doc already men
funkman 2003/09/13 07:58:09
Modified:webapps/docs class-loader-howto.xml
Log:
typo fix per Per 9766
Revision ChangesPath
1.7 +1 -1 jakarta-tomcat-catalina/webapps/docs/class-loader-howto.xml
Index: class-loader-howto.xml
gzilla/show_bug.cgi?id=24508
Webapp class loader issue
Summary: Webapp class loader issue
Product: Tomcat 4
Version: 4.1.27
Platform: All
OS/Version: All
Status: NEW
Severity: Major
Priority: Other
Component: Ca
yoavs 2004/06/16 08:50:30
Modified:webapps/docs class-loader-howto.xml
Log:
Added clarifications per Bugzilla 29389.
Revision ChangesPath
1.10 +5 -2 jakarta-tomcat-catalina/webapps/docs/class-loader-howto.xml
Index: class-loader-howto.xml
gzilla/show_bug.cgi?id=30568
Cannot find daemon loader
Summary: Cannot find daemon loader
Product: Tomcat 5
Version: 5.0.27
Platform: Macintosh
OS/Version: Linux
Status: NEW
Severity: Normal
Priority: Other
Com
markt 2004/02/01 14:43:21
Modified:webapps/docs class-loader-howto.xml
Log:
- Fix bug 13772. Add a link to the security manager how-to.
- Reported by Greg Bullough.
Revision ChangesPath
1.8 +9 -0 jakarta-tomcat-catalina/webapps/docs/class-loader-howto.xml
markt 2004/02/02 13:39:28
Modified:webapps/docs class-loader-howto.xml
Log:
- Fix 13805. Update docs to show that the shared directory is relative to
CATALINA_BASE not CATALINA_HOME.
- Reported by Michael Eriksson.
Revision ChangesPath
1.9 +6 -6 jakarta
costin 2004/10/05 21:56:39
jakarta-tomcat-connectors/util/loader/org - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
marcsaeg01/03/03 19:47:58
Modified:src/share/org/apache/tomcat/loader Tag: tomcat_32
AdaptiveClassLoader.java
Log:
Explictly close ZipFile to avoid leaking file descriptors. Bugzilla 134.
Revision ChangesPath
No revision
craigmcc00/11/16 14:04:42
Modified:src/share/org/apache/tomcat/loader Tag: tomcat_32
AdaptiveClassLoader.java
Log:
Make getResource() and getResourceAsStream() consult the parent class
loader (if there is one) before delegating to the system class loader
craigmcc01/10/03 15:00:41
Modified:webapps/tomcat-docs class-loader-howto.xml
Log:
Update the Class Loader doc for the HEAD branch to reflect the revised
state of the world.
Revision ChangesPath
1.2 +36 -93jakarta-tomcat-4.0/webapps/tomcat-docs/class-loader
craigmcc02/01/10 14:17:13
Modified:webapps/tomcat-docs Tag: tomcat_40_branch
class-loader-howto.xml
Log:
Fix typos in class loader HOWTO docs.
Submitted by: Samarth Kumar
Revision ChangesPath
No revision
No
1 - 100 of 404 matches
Mail list logo
