Fw: Possible Explanation - Re: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems.

[Bill Barker]

FYI for the 4.x group mostly.  He is refering to bug #5390, which it seems
is still alive in 4.x.
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 23, 2002 10:48 PM
Subject: Re: Possible Explanation - Re: DO NOT REPLY [Bug 5684] -
WEB-INF/lib jar file loading and operations problems.


> Hi Bill,
>
> It's been a week now and everything is AOK.  Please close out this bug.
> Thanks for your great job in pursuing a fix to this problem.  Truly
> appreciate this.
>
> BTW, I'm starting on an implementation of a Tomcat 4 shared jvm.  I ran
all
> of my jar scenarios against Tomcat 4 and it works great.  It does lock jar
> files (from deletion only) but only when the context is in use.  If you
stop
> the context using the /manager app, it frees up the jar files as well as
any
> files and directories associated with the context.  If you replace jar
> files, it's auto detection works excellent.  My only gripe with tomcat 4
is
> it has the same jspinit problem that you fixed and it's ajp13 connector
does
> not do tomcat authentication.  So I just have to wait until these problems
> are fixed.
>
> Thanks again for everything.
>
> Regards,
> Mike
>
>
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: "Bill Barker" <[EMAIL PROTECTED]>
> Sent: Thursday, January 17, 2002 7:42 PM
> Subject: Re: Possible Explanation - Re: DO NOT REPLY [Bug 5684] -
> WEB-INF/lib jar file loading and operations problems.
>
>
> Hi Bill,
>
> It's looking real excellent.  Your changes passed all my tests.  I felt
> comfortable enough with the 1/16 build that I installed it on my
production
> server last night.  I emailed my customers whom I've been working on this
> issue to give it a spin.  One developer already responded with positive
> results.  So far so good.  Let's give it a week of usage before we close
> this issue.  I'll email you in about a week once all the results are in.
> Once again, thanks for all of your help.
>
> Regards,
> Mike
>
>
> - Original Message -
> From: "Bill Barker" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Wednesday, January 16, 2002 9:00 AM
> Subject: Re: Possible Explanation - Re: DO NOT REPLY [Bug 5684] -
> WEB-INF/lib jar file loading and operations problems.
>
>
> I checked in a patch to DependClassLoader12 last night (which should
appear
> in tonight's nightly) that seems to make jar replacement much better at
> least with my very limited testing.  It was leaving the jar file open
> whenever it had to define a new Package.  From your description, it sounds
> like it would eventually get garbage collected, but it may take quite a
> while.  While servlets and beans are loaded the same way, if the package
> contains a load-on-startup servlet it would get loaded very early on (and
> define the package for everyone else).  This means that the open jar file
is
> very likely to be finalized by the time Tomcat actually starts serving
> pages.
>
> You are also correct that the ProtectionDomain is still set even when
using
> SimpleClassLoader.  That is because DependClassLoader12 is the one that
> actually defines the class (and it sets the PD).  SimpleClassLoader is
only
> used to load resources (even under Java 1.1).  It isn't used to load
classes
> by itself.
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, January 12, 2002 2:41 PM
> Subject: Re: Possible Explanation - Re: DO NOT REPLY [Bug 5684] -
> WEB-INF/lib jar file loading and operations problems.
>
>
> > Hi Bill,
> >
> > Oooh.  I spoke up to soon.  After further testing, I still have the same
> > problem BUT ONLY with regular bean or taglib classes in the jar.
Servlet
> > classes in a jar are working great.  But as soon as a bean class is
loaded
> > from the jar, the same problems exist -- locked jar or 404 resulting
from
> a
> > class not found exception and it also affects the servlet classes from
> that
> > point on.  Even if I restart the context (remove then add), the same
> > problems exist.  I'm trying to research the problem but I got to admit
> that
> > the tomcat code is pretty hefty to trace through due to my lack of
> > experience with the code.  Are servlet classes loaded from a jar any
> > different from regular classes loaded from a jar?
> >
> > Any thoughts?
> >
> > Regards,
> > Mike
> >
> >
> > - Original Message -
> > From: <[EMAIL PROTECTED]>
> > To: "Bill Barker" <[EMAIL PROTECTED]>
> > Sent: Friday, January 11, 2002 8:55 PM
> > Subject: Re: Possible Explanation - Re: DO NOT REPLY [Bug 5684] -
> > WEB-INF/lib jar file loading and operations problems.
> >
> >
> > Bill,
> >
> > First I'd like to say that you are darn good.  Everything worked
> perfectly.
> > What can I say.  Thank you very much.  I will put it through more
> extensive
> > testing but my initial tests which was to delete the jar, replace the
jar,
> > restart contexts with jar reloading, servlet reloading

DO NOT REPLY [Bug 6000] - getOutputStream function can't be used inside JSP page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6000

getOutputStream  function can't be used inside JSP page

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-01-24 08:05 ---
If you want to retrieve binary data, then you must use request.getInputStream.  
JSP pages (as required by the spec) use response.getWriter, so that calls to 
response.getOutputStream are then correctly faulted.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5684

WEB-INF/lib jar file loading and operations problems.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-01-24 08:00 ---
Reporter says that it's working now.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 6000] New: - getOutputStream function can't be used inside JSP page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6000

getOutputStream  function can't be used inside JSP page

   Summary: getOutputStream  function can't be used inside JSP page
   Product: Tomcat 3
   Version: 3.3 Final
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Major
  Priority: Other
 Component: Servlet
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hello,


I want to use a jsp page to retrieve binary data.

here is the code of the jsp page : 
<%@ page language="java" %>
<%@ page import="java.io.*" %>

<%
OutputStream out1 = response.getOutputStream();
%>
 
and here is the message I receive from the Server.

Error: 500
Location: /activities/jsp/transform.jsp
Erreur interne de servlet:

java.lang.IllegalStateException: getOutputStream() a déjà été appelé
at org.apache.tomcat.facade.HttpServletResponseFacade.getWriter(Unknown 
Source)
at org.apache.jasper.runtime.JspWriterImpl.initOut(Unknown Source)
at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(Unknown Source)
at jsp.transform_11._jspService(transform_11.java:111)
at org.apache.jasper.runtime.HttpJspBase.service(Unknown Source)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at org.apache.tomcat.facade.ServletHandler.doService(Unknown Source)
at org.apache.tomcat.core.Handler.invoke(Unknown Source)
at org.apache.tomcat.core.Handler.service(Unknown Source)
at org.apache.tomcat.facade.ServletHandler.service(Unknown Source)
at org.apache.tomcat.core.ContextManager.internalService(Unknown Source)
at org.apache.tomcat.core.ContextManager.service(Unknown Source)
at org.apache.tomcat.modules.server.Http10Interceptor.processConnection
(Unknown Source)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(Unknown Source)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(Unknown Source)
at java.lang.Thread.run(Thread.java:484)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp Ajp13.java

[Kevin Seguin]

> 
> 
> >   
> >   total_read = readN(in, b, H_SIZE, len);
> >  -
> >  -if (total_read <= 0) {
> >  +
> >  +// it's ok to have read 0 bytes when len=0 -- this means
> >  +// the end of the stream has been reached.
> >  +if (total_read < 0) {
> >   logger.log("can't read body, waited #" + len);
> >   return JK_AJP13_BAD_BODY;
> >   }
> >  
> 
> Why not just skip the readN call when len = 0 since 
> the only case where readN will return 0 is when the 
> passed len is 0 ;)
> 
> I'll commit a patch later
> 

yeah, that same thought occurred to me too.  but, then i never did anything
about it.  i was just happy i figured out what went wrong :)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp Ajp13.java

[GOMEZ Henri]

>   
>   total_read = readN(in, b, H_SIZE, len);
>  -
>  -if (total_read <= 0) {
>  +
>  +// it's ok to have read 0 bytes when len=0 -- this means
>  +// the end of the stream has been reached.
>  +if (total_read < 0) {
>   logger.log("can't read body, waited #" + len);
>   return JK_AJP13_BAD_BODY;
>   }
>  

Why not just skip the readN call when len = 0 since 
the only case where readN will return 0 is when the 
passed len is 0 ;)

I'll commit a patch later

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server/tomcat40 Worker40.java

[GOMEZ Henri]

That's why jtc tag 4.0.2 b2 didn't build when you only have 
jakarta-tomcat-4.0.2-b2.

Question :

- Should we retag jtc 4.0.2-b2 including these patches or 
  should I patch my tarball for jtc tagged 4.0.2-b2 to compile
  jtc with just TC 4.0.2-B2 on path ?

Regards

BTW: Did the jtc tagged tarball is available on tomcat 4.0.2-b2 
 distribution source dir ?

Regards

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Monday, January 21, 2002 9:12 PM
>To: [EMAIL PROTECTED]
>Subject: cvs commit:
>jakarta-tomcat-connectors/jk/java/org/apache/jk/server/tomcat40
>Worker40.java
>
>
>costin  02/01/21 12:11:52
>
>  Modified:jk/java/org/apache/catalina/jk JkServlet40.java
>Worker40.java
>   jk/java/org/apache/jk/common WorkerDummy.java
>   jk/java/org/apache/jk/core Worker.java
>   jk/java/org/apache/jk/server JkMain.java JkServlet.java
>   jk/java/org/apache/jk/server/tomcat40 Worker40.java
>  Log:
>  Removed unused import statements pointing to 3.3 stuff that 
>is not used
>  in jk2. So far we imported only the utils that are actually needed.
>  
>  Revision  ChangesPath
>  1.2   +0 -1  
>jakarta-tomcat-connectors/jk/java/org/apache/catalina/jk/JkServ
>let40.java
>  
>  Index: JkServlet40.java
>  ===
>  RCS file: 
>/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/catalina
>/jk/JkServlet40.java,v
>  retrieving revision 1.1
>  retrieving revision 1.2
>  diff -u -r1.1 -r1.2
>  --- JkServlet40.java 6 Jan 2002 08:38:55 -   1.1
>  +++ JkServlet40.java 21 Jan 2002 20:11:52 -  1.2
>  @@ -77,7 +77,6 @@
>*/
>   import org.apache.jk.server.tomcat40.*;
>   
>  -import org.apache.tomcat.util.net.*;
>   import org.apache.tomcat.util.buf.*;
>   import org.apache.tomcat.util.http.*;
>   
>  
>  
>  
>  1.2   +0 -2  
>jakarta-tomcat-connectors/jk/java/org/apache/catalina/jk/Worker40.java
>  
>  Index: Worker40.java
>  ===
>  RCS file: 
>/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/catalina
>/jk/Worker40.java,v
>  retrieving revision 1.1
>  retrieving revision 1.2
>  diff -u -r1.1 -r1.2
>  --- Worker40.java6 Jan 2002 08:39:38 -   1.1
>  +++ Worker40.java21 Jan 2002 20:11:52 -  1.2
>  @@ -64,9 +64,7 @@
>   import java.util.*;
>   
>   import org.apache.jk.*;
>  -import org.apache.tomcat.modules.server.PoolTcpConnector;
>   
>  -import org.apache.tomcat.util.net.*;
>   import org.apache.tomcat.util.buf.*;
>   import org.apache.tomcat.util.log.*;
>   import org.apache.tomcat.util.http.*;
>  
>  
>  
>  1.2   +0 -1  
>jakarta-tomcat-connectors/jk/java/org/apache/jk/common/WorkerDummy.java
>  
>  Index: WorkerDummy.java
>  ===
>  RCS file: 
>/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/commo
>n/WorkerDummy.java,v
>  retrieving revision 1.1
>  retrieving revision 1.2
>  diff -u -r1.1 -r1.2
>  --- WorkerDummy.java 31 Dec 2001 19:02:01 -  1.1
>  +++ WorkerDummy.java 21 Jan 2002 20:11:52 -  1.2
>  @@ -64,7 +64,6 @@
>   
>   import org.apache.jk.core.*;
>   
>  -import org.apache.tomcat.util.net.*;
>   import org.apache.tomcat.util.buf.*;
>   import org.apache.tomcat.util.log.*;
>   import org.apache.tomcat.util.http.*;
>  
>  
>  
>  1.2   +0 -1  
>jakarta-tomcat-connectors/jk/java/org/apache/jk/core/Worker.java
>  
>  Index: Worker.java
>  ===
>  RCS file: 
>/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/core/
>Worker.java,v
>  retrieving revision 1.1
>  retrieving revision 1.2
>  diff -u -r1.1 -r1.2
>  --- Worker.java  31 Dec 2001 19:03:53 -  1.1
>  +++ Worker.java  21 Jan 2002 20:11:52 -  1.2
>  @@ -64,7 +64,6 @@
>   
>   import org.apache.jk.core.*;
>   
>  -import org.apache.tomcat.util.net.*;
>   import org.apache.tomcat.util.buf.*;
>   import org.apache.tomcat.util.log.*;
>   import org.apache.tomcat.util.http.*;
>  
>  
>  
>  1.6   +0 -1  
>jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java
>  
>  Index: JkMain.java
>  ===
>  RCS file: 
>/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/serve
>r/JkMain.java,v
>  retrieving revision 1.5
>  retrieving revision 1.6
>  diff -u -r1.5 -r1.6
>  --- JkMain.java  16 Jan 2002 15:38:29 -  1.5
>  +++ JkMain.java  21 Jan 2002 20:11:52 -  1.6
>  @@ -66,7 +66,6 @@
>   import org.apache.jk.core.*;
>   import org.apache.jk.common.*;
>   
>  -import 

DO NOT REPLY [Bug 5998] New: - Exception hiding when a JspExceptioin is thrown by a tag

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5998

Exception hiding when a JspExceptioin is thrown by a tag

   Summary: Exception hiding when a JspExceptioin is thrown by a tag
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The signature of Tag and BodyTag methods declare that they should throw 
JspExceptions. This is all good, but the problem is that the exception that is 
being wrapped by the JspException will be hidden by 
PageContextImpl.handlerPageException() as it will wrap the JspException into a 
ServletException.

My suggestion is to build the ServletException from the actual exception 
wrapped by the JspException... Something like this:

if( t instanceof JspException )
{
  Throwable rootCause = ((JspException)t).getRootCause();
  if( rootCause != null )
throw new ServletException( t.getMessage(), rootCause );
  else
throw new ServletException( t );
}

Thanks,

-Yanik-

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina Globals.java

[craigmcc]

craigmcc02/01/23 18:13:53

  Modified:catalina/src/share/org/apache/catalina Tag: tomcat_40_branch
Globals.java
  Log:
  Fix a leading slash that was apparently accidentally deleted.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.39.2.10 +5 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java
  
  Index: Globals.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java,v
  retrieving revision 1.39.2.9
  retrieving revision 1.39.2.10
  diff -u -r1.39.2.9 -r1.39.2.10
  --- Globals.java  20 Jan 2002 16:38:45 -  1.39.2.9
  +++ Globals.java  24 Jan 2002 02:13:52 -  1.39.2.10
  @@ -1,7 +1,7 @@
  -*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java,v 
1.39.2.9 2002/01/20 16:38:45 remm Exp $
  - * $Revision: 1.39.2.9 $
  - * $Date: 2002/01/20 16:38:45 $
  +/*
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java,v 
1.39.2.10 2002/01/24 02:13:52 craigmcc Exp $
  + * $Revision: 1.39.2.10 $
  + * $Date: 2002/01/24 02:13:52 $
*
* 
*
  @@ -69,7 +69,7 @@
* Global constants that are applicable to multiple packages within Catalina.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.39.2.9 $ $Date: 2002/01/20 16:38:45 $
  + * @version $Revision: 1.39.2.10 $ $Date: 2002/01/24 02:13:52 $
*/
   
   public final class Globals {
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 5993] - Build of mod_jk ends in error (Command failed with rc=16777215 )

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5993

Build of mod_jk ends in error (Command failed with rc=16777215 )





--- Additional Comments From [EMAIL PROTECTED]  2002-01-24 01:34 ---
3. build-solaris.sh is pretty broken.
4. You need to include -lposix4 to the apxs command on Solaris.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 5995] New: - multipar enctype does not work for Netscape

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5995

multipar enctype does not work for Netscape 

   Summary: multipar enctype does not work for Netscape
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In Netscape 4.78, the data from the FORM can't be processed when using 
enctype="multipart/form-data"

It seemed all of the parameters are ignored.

The code works fine with Internet Explorer.

--



  


..


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 5769] - NT Service display name should not be used as service name

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5769

NT Service display name should not be used as service name





--- Additional Comments From [EMAIL PROTECTED]  2002-01-24 00:19 ---
Ultimately, the display name and service name should be specified independently. 
The previously posted patches were aimed at a compromise that would avoid having 
to change the command line but allow nicer display names.  However, that makes 
the service name look a bit goofy.  An even better patch for this would modify 
the command line arg to take both a service name and a display name.  I'll see 
if I can submit another patch along these lines.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: classloader issues (ClassCastException on org.xml.sax.Parser)

[Ed Korthof]

On Wed, Jan 23, 2002 at 02:28:52AM -0800, Remy Maucherat wrote:
> > On Tue, Jan 22, 2002 at 06:14:18PM -0800, Remy Maucherat wrote:
> >
> > Do you mean you're spawning another process to do compilation?  I
> > thought that javac's core class had been fixed so that it'd be possible
> > to run it in a thread in an existing server ... for a number of reasons,
> > including performance and the awkwardness of spawning processes on
> > win32.  (I know there was talk about that years ago, when I last worked
> > on a page compilation system, but I don't know what happened with it.)
> 
> Jasper uses the javac API which doesn't spawn a process, but it still
> behaves the same way it does if you actually spawn a process.

You said the reason that we can't do what I suggested is that it would
"make JSPs behave differently from servlets" -- so I went to look at
Jasper to see how similar the behavior is right now, in terms of
classloading.  It looks like there's no guarantee at all about
consistency:

Jasper already assumes that the classpath for JSP compilation may be
different from that used in servlets.  There are a number of
inconsistencies, including at least the following:

1) jars accessed by URLs using protocols other than the file protocol
will be silently left out (JspEngineContext.java:155)

2) the order of classname resolution does not match the special logic in
WebappClassLoader, since the webapp classloader's jars aren't ever
preptended to the system classpath, they're always appended
(Compiler.java:233).  I haven't yet followed the logic all the way back
in terms of how the data gets into the context for use by JspServlet --
it is possible that the order is reversed somewhere else ... but if so,
the logic isn't in WebappClassLoader, which is the only class which will
know if delegation is true or false.  So I suspect it's not being done.

Note that #2 may mean that excluding the jars from the classpath to
Jasper might not be such a big deal, as the only reason for the
filtering of those jars in WebappClassloader is the fact that they could
override classes defined in their parent classloaders.

I can imagine that there may be other good reasons not to allow the
changes which I suggested, but AFAICT there's very little consistency
left to be preserved, when comparing classpath handling for JSP pages
and servlets.

> Also, you can't change the delegation and still be spec compliant. We could
> avoid implementing the requirement of preventing loading core libraries, if
> it turns out it's not implementable.

I don't mind configuring tomcat so that my install isn't spec compliant
(that's already possible, with the setDelgate toggle).  I tend to feel
as Daniel said -- the spec is broken.  But I can understand wanting to
build tomcat in such a way that it satisfies the spec as well as is
possible.

It is possible to be compliant with the specification, but I don't think
the current implementation is.  I can override classes in each of the
"protected" packages, so long as I take care to leave out the trigger
class, for which tomcat looks, in my .jar files -- so if it's tomcat's
job to avoid loading core libraries in the webapp classloaders, I don't
think it's doing it reliably.

Anyway -- one possibility would be to do filtering of .jars before
handing them to the JSP engine (much as it's being done now, thought it
might make more sense to read through the contents of the jars and look
for any classes which are in packages they're not allowed to be in), but
to do the kind of filtering which I described in my first message, in
loadClass.  And I'd suggest adding one or more toggles, to configure how
filtering is done.  (I'm not sure if one or two is appropriate because
I'm not sure if #2 -- up above -- should be fixed.)

thanks --

Ed

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade JspInterceptor.java

[costin]

costin  02/01/23 15:58:38

  Modified:src/facade22/org/apache/tomcat/facade JspInterceptor.java
  Log:
  The last patch for the "strange tools.jar" problem.
  
  We make sure tools.jar is added to the context loader, and pass it to jasper
  ( using the previous patch to make sure no implicit deps are in the .class and
  the right loader is used )
  
  This seems to solve the problem, and is certainly more a robust and controlable
  environment.
  
  Revision  ChangesPath
  1.36  +77 -18
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/JspInterceptor.java
  
  Index: JspInterceptor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/JspInterceptor.java,v
  retrieving revision 1.35
  retrieving revision 1.36
  diff -u -r1.35 -r1.36
  --- JspInterceptor.java   9 Jan 2002 06:57:42 -   1.35
  +++ JspInterceptor.java   23 Jan 2002 23:58:38 -  1.36
  @@ -275,20 +275,45 @@
ctx.addClassPath( url );
if( debug > 9 ) log( "Added to classpath: " + url );
} catch( MalformedURLException ex ) {
  +ex.printStackTrace();
}
  - } else if( !ctx.isTrusted() ) {
  + }
  +
  +if( !ctx.isTrusted() ) {
   try {
  -File f=new File( cm.getInstallDir(), "lib/container/jasper.jar" );
  +File f=new File( cm.getInstallDir(),
  + "lib/container/jasper.jar" );
   URL url=new URL( "file", null,
  -f.getAbsolutePath().replace('\\','/') );
  -ctx.addClassPath( url );
  -if( debug > 9 ) log( "Added to classpath: " + url );
  -url=new URL( "file", "" ,
  -System.getProperty( "java.home" ) + "/../lib/tools.jar");
  + f.getAbsolutePath().replace('\\','/') );
   ctx.addClassPath( url );
   if( debug > 9 ) log( "Added to classpath: " + url );
} catch( MalformedURLException ex ) {
  - }
  +ex.printStackTrace();
  +}
  +}
  +
  +// Add tools.jar in any case
  +try {
  +File f=new File( System.getProperty( "java.home" ) +
  + "/../lib/tools.jar");
  +if( ! f.exists() ) {
  +// On some systems java.home gets set to the root of jdk.
  +// That's a bug, but we can work around and be nice.
  +f=new File( System.getProperty( "java.home" ) +
  + "/lib/tools.jar");
  +if( ! f.exists() ) {
  +log("Tools.jar not found " +
  +System.getProperty( "java.home" ));
  +} else {
  +log("Detected wrong java.home value " +
  +System.getProperty( "java.home" ));
  +}
  +}
  +URL url=new URL( "file", "" , f.getAbsolutePath() );
  +ctx.addClassPath( url );
  +if( debug > 9 ) log( "Added to classpath: " + url );
  +} catch( MalformedURLException ex ) {
  +ex.printStackTrace();
   }
   }
   
  @@ -335,6 +360,14 @@
} else {
ctx.addServlet( new JspPrecompileH());
}
  +
  +//Extra test/warnings for tools.jar
  +try {
  +ctx.getClassLoader().loadClass( "sun.tools.javac.Main" );
  +if( debug>0) log( "Found javac in context init");
  +} catch( ClassNotFoundException ex ) {
  +if( debug>0) log( "javac not found in context init");
  +}
   }
   
   /** Set the HttpJspBase classloader before init,
  @@ -652,11 +685,31 @@
log.log( "Update class Name " + mangler.getServletClassName());
handler.setServletClassName( mangler.getServletClassName() );
   
  - // May be called from include, we need to set the context class loader
  + // May be called from include, we need to set the context class
  +// loader
// for jaxp1.1 to work using the container class loader
  - ClassLoader savedContextCL= containerCCL( ctx.getContextManager()
  -   .getContainerLoader() );
  - 
  +//Extra test/warnings for tools.jar
  +
  +ClassLoader savedContextCL= containerCCL( ctx.getContextManager()
  +  .getContainerLoader() );
  +
  +try {
  +ctx.getClassLoader().loadClass( "sun.tools.javac.Main" );
  +if(debug>0) log.log( "Found javac using context loader");
  +} catch( ClassNotFoundException ex ) {
  +if(debug>0) log.log( "javac not found using 

RE: [Tomcat 4.0.2-b2] Java binaries uploaded

[Craig R. McClanahan]

On Wed, 23 Jan 2002, GOMEZ Henri wrote:

> Date: Wed, 23 Jan 2002 23:26:37 +0100
> From: GOMEZ Henri <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: RE: [Tomcat 4.0.2-b2] Java binaries uploaded
>
> I've got a little problems with all the jars that are
> mandatory to build TC 4.0, javamail, jta, jdbc-ext, jmxri.
>
> tyrex is allready packaged and JSSE is only optional.
>
> Could someone, may be from Sun staff, could release all of
> them in a single tarball and put it on the download area ?
>

This isn't allowed under the license through which these JARs are
downloaded.  You can package them with your own distribution (as we do in
the .tar.gz and .exe distros of Tomcat 4), but not separately.

> Henri Gomez

Craig McClanahan


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: HEAD Branch Build Problems

[Remy Maucherat]

> On Wed, 23 Jan 2002, Remy Maucherat wrote:
>
> Did a fresh checkout of j-t-c.  The file is still there, but this time it
> worked ... wierd.

That's not normal, there shouldn't be a j-t-c/webapp/java/Constants.java at
all.
http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-connectors/webapp/java/

There was one 6 months ago. Until now, it was generated from
Constants.java.in as part of the build process.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: HEAD Branch Build Problems

[Craig R. McClanahan]

On Wed, 23 Jan 2002, Remy Maucherat wrote:

> Date: Wed, 23 Jan 2002 15:26:11 -0800
> From: Remy Maucherat <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: HEAD Branch Build Problems
>
> > I"ve just done a CVS update to pick up Remy's reorganization of the build
> > process (and added dependency on jakarta-tomcat-connectors).  Trying to do
> > "ant clean" followed by "ant" fails on line 155 of the
> > jakarta-tomcat-connectors/webapp/build.xml file, with the compiler
> > claiming that class org.apache.catalina.connector.warp.Constants is
> > already defined in file
> > "jakarta-tomcat-connectors/webapp/java/Constants.java".  Do I need to set
> > any special build properties to get around this?
>
> This file was created by a preprocessor, and isn't controlled by CVS. So you
> have to remove it by hand, and it shouldn't come back next time you update.
>

Did a fresh checkout of j-t-c.  The file is still there, but this time it
worked ... wierd.

> Remy
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [Tomcat 4.0.2-b2] Java binaries uploaded

[GOMEZ Henri]

I've got a little problems with all the jars that are
mandatory to build TC 4.0, javamail, jta, jdbc-ext, jmxri.

tyrex is allready packaged and JSSE is only optional.

Could someone, may be from Sun staff, could release all of 
them in a single tarball and put it on the download area ?

For now I use packages from the jPackage project, www.jpackage.org,
where all these fine Jars are available as RPM but may be some will
find better to have all of these original jars at apache.org ;)

Thanks to comment

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, January 23, 2002 3:54 PM
>To: Tomcat Developers List
>Subject: Re: [Tomcat 4.0.2-b2] Java binaries uploaded
>
>
>> That's fine for me since that's exactly how I built the packages for
>> TC 4.x.
>> build TC 4 jars , then build jtc jar (against TC 4.0) then copy to
>> appropriate dirs
>
>There was a circular dependency when doing that (which was solved by
>committing some JARs in the Tomcat CVS), but it does work :)
>
>> Ok, RPM should be ready later today or tomorrow :)
>
>Great !
>
>Remy
>
>
>--
>To unsubscribe, e-mail:   
>
>For additional commands, e-mail: 
>
>
>

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat-4.0/lib tomcat-ajp.jar tomcat-util.jar

[GOMEZ Henri]

Bravo :)

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, January 23, 2002 6:57 PM
>To: [EMAIL PROTECTED]
>Subject: cvs commit: jakarta-tomcat-4.0/lib tomcat-ajp.jar
>tomcat-util.jar
>
>
>remm02/01/23 09:57:04
>
>  Removed: lib  tomcat-ajp.jar tomcat-util.jar
>  Log:
>  - Change in the build system: the connectors will now be 
>build straight out of the
>j-t-c repository, to avoid version conflicts, lost 
>updates, and all other kind of problems
>which can happen when code is duplicated.
>  - New jtc.home property, which must point to the j-t-c 
>repository (defaults to
>${basedir}/../jakarta-tomcat-connectors).
>  - Components built from j-t-c and included in the TC build include:
>- util: Util components coming form TC 3.3, used by AJP/JK 
>and Coyote
>- jk: AJP 1.3 / JK 1.4 / JK 2.0
>- webapp: WARP connector v1.0.x
>- coyote: connector framework, with adapter for Tomcat 4.x 
>(not code complete)
>- http11: HTTP/1.1 stack for Coyote (alpha quality)
>  - Rename JARs from j-t-c to tomcat-componentname.jar.
>  - One advantage is that Catalina will be able to use 
>components from j-t-c/util
>without any problems.
>
>--
>To unsubscribe, e-mail:   
>
>For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Native2: proposed interface change

[GOMEZ Henri]

>> What do you think ? Henri, JFC, Kevin - I hope for an quick 
>answer :-)

>it sounds like you're heading towards a good deal of symmetry 
>between the
>java and c code, which is definitely good :)

Yes, and you got my +1 also :)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: jk tags

[GOMEZ Henri]

>For the C side, I'm working on JNI worker as a channel - that 
>will resolve
>some of the current problems in jni ( performance, i18n, etc) and will
>make the jni channel available in 4.0 too. But we still have 
>to update the
>other server connectors, decide what we want to do about 
>config, etc - so
>it'll take more time.
>The new C connector should be perfectly interoperable with the 
>old one if
>ajp13 is used, so a smooth and flexible transition is possible.
>
>
>Comments, feedback, votes ?

+1, continue the refactory :)

Better, i'm more than pleased to see you and Remy so often agree.

Just to show to some that a 3.3 guy could works with a 4.0 guy.

I'm just waiting to see Pier again on this list ;)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler SunJavaCompiler.java

[costin]

costin  02/01/23 15:28:49

  Modified:src/share/org/apache/jasper/compiler SunJavaCompiler.java
  Log:
  A bit of cut&paste from ant, to better control javac.Main loading.
  
  In some cases, even if we do have tools.jar in the thread loader or another
  class loader, having Main referenced directly can result in ClassNotFound.
  
  Revision  ChangesPath
  1.4   +60 -25
jakarta-tomcat/src/share/org/apache/jasper/compiler/SunJavaCompiler.java
  
  Index: SunJavaCompiler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/SunJavaCompiler.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- SunJavaCompiler.java  14 Jan 2001 20:45:40 -  1.3
  +++ SunJavaCompiler.java  23 Jan 2002 23:28:49 -  1.4
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/SunJavaCompiler.java,v 
1.3 2001/01/14 20:45:40 larryi Exp $
  - * $Revision: 1.3 $
  - * $Date: 2001/01/14 20:45:40 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/SunJavaCompiler.java,v 
1.4 2002/01/23 23:28:49 costin Exp $
  + * $Revision: 1.4 $
  + * $Date: 2002/01/23 23:28:49 $
*
* 
* 
  @@ -62,7 +62,8 @@
   package org.apache.jasper.compiler;
   
   import java.io.OutputStream;
  -import sun.tools.javac.Main;
  +import java.lang.reflect.Constructor;
  +import java.lang.reflect.Method;
   
   /**
* The default compiler. This is the javac present in JDK 1.1.x and
  @@ -132,29 +133,63 @@
   this.classDebugInfo = classDebugInfo;
   }
   
  +ClassLoader loader=null;
  +public void setLoader( ClassLoader cl  ) {
  +loader=cl;
  +}
  +
   public boolean compile(String source) {
  -Main compiler = new Main(out, "jsp->javac");
  -String[] args;
   
  -if (classDebugInfo) {
  -args = new String[]
  -{
  -"-g",
  -"-encoding", encoding,
  -"-classpath", classpath,
  -"-d", outdir,
  -source
  -};
  - } else {
  -args = new String[]
  -{
  -"-encoding", encoding,
  -"-classpath", classpath,
  -"-d", outdir,
  -source
  -};
  +try {
  +Class c;
  +if( loader==null ) 
  +c = Class.forName("sun.tools.javac.Main");
  +else
  +c=loader.loadClass("sun.tools.javac.Main");
  +
  +Constructor cons =
  +c.getConstructor(new Class[] { OutputStream.class,
  +   String.class });
  +
  +Object compiler = cons.newInstance(new Object[] { out,
  +  "jsp->javac" });
  +
  +// Call the compile() method
  +Method compile = c.getMethod("compile",
  + new Class [] { String[].class });
  +
  +String[] args;
  +
  +if (classDebugInfo) {
  +args = new String[]
  +{
  +"-g",
  +"-encoding", encoding,
  +"-classpath", classpath,
  +"-d", outdir,
  +source
  +};
  +} else {
  +args = new String[]
  +{
  +"-encoding", encoding,
  +"-classpath", classpath,
  +"-d", outdir,
  +source
  +};
  +}
  +Boolean ok =
  +(Boolean)compile.invoke(compiler,
  +new Object[] {args});
  +return ok.booleanValue();
   }
  -
  -return compiler.compile(args);
  +catch (ClassNotFoundException ex) {
  +ex.printStackTrace();
  +return false;
  +}
  +catch (Exception ex1) {
  +ex1.printStackTrace();
  +return false;
  +} 
   }
   }
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: HEAD Branch Build Problems

[Remy Maucherat]

> I"ve just done a CVS update to pick up Remy's reorganization of the build
> process (and added dependency on jakarta-tomcat-connectors).  Trying to do
> "ant clean" followed by "ant" fails on line 155 of the
> jakarta-tomcat-connectors/webapp/build.xml file, with the compiler
> claiming that class org.apache.catalina.connector.warp.Constants is
> already defined in file
> "jakarta-tomcat-connectors/webapp/java/Constants.java".  Do I need to set
> any special build properties to get around this?

This file was created by a preprocessor, and isn't controlled by CVS. So you
have to remove it by hand, and it shouldn't come back next time you update.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util IntrospectionUtils.java

[costin]

costin  02/01/23 15:26:04

  Modified:src/share/org/apache/tomcat/util IntrospectionUtils.java
  Log:
  Check for tools.jar existence and try java.home/lib/tools.jar too, for the
  few vms using a 'strange' layout or setting java.home to JAVA_HOME.
  
  Revision  ChangesPath
  1.16  +22 -4 
jakarta-tomcat/src/share/org/apache/tomcat/util/IntrospectionUtils.java
  
  Index: IntrospectionUtils.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/IntrospectionUtils.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- IntrospectionUtils.java   20 Sep 2001 03:46:32 -  1.15
  +++ IntrospectionUtils.java   23 Jan 2002 23:26:04 -  1.16
  @@ -185,7 +185,10 @@
if( path.endsWith( jarName ) ) {
home=path.substring( 0, path.length() - jarName.length() );
try {
  - File f=new File( home );
  +if( "".equals(home) ) {
  +home=new File("./").getCanonicalPath();
  +}
  +File f=new File( home );
File f1=new File ( f, "..");
install = f1.getCanonicalPath();
if( installSysProp != null )
  @@ -472,9 +475,24 @@
   public static void addToolsJar( Vector v )
   {
try {
  - v.addElement( new URL( "file", "" ,
  -System.getProperty( "java.home" ) +
  -"/../lib/tools.jar"));
  +// Add tools.jar in any case
  +File f=new File( System.getProperty( "java.home" ) +
  + "/../lib/tools.jar");
  +
  +if( ! f.exists() ) {
  +// On some systems java.home gets set to the root of jdk.
  +// That's a bug, but we can work around and be nice.
  +f=new File( System.getProperty( "java.home" ) +
  + "/lib/tools.jar");
  +if( f.exists() ) {
  +System.out.println("Detected strange java.home value " +
  +   System.getProperty( "java.home" ) +
  +   ", it should point to jre");
  +}
  +}
  +URL url=new URL( "file", "" , f.getAbsolutePath() );
  +
  + v.addElement( url );
} catch ( MalformedURLException ex ) {
ex.printStackTrace();
}
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

HEAD Branch Build Problems

[Craig R. McClanahan]

I"ve just done a CVS update to pick up Remy's reorganization of the build
process (and added dependency on jakarta-tomcat-connectors).  Trying to do
"ant clean" followed by "ant" fails on line 155 of the
jakarta-tomcat-connectors/webapp/build.xml file, with the compiler
claiming that class org.apache.catalina.connector.warp.Constants is
already defined in file
"jakarta-tomcat-connectors/webapp/java/Constants.java".  Do I need to set
any special build properties to get around this?

Craig



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 5994] New: - HTTP date headers not set correctly [patch included]

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5994

HTTP date headers not set correctly [patch included]

   Summary: HTTP date headers not set correctly [patch included]
   Product: Tomcat 3
   Version: 3.3 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I was finding that if a servlet used HttpServletResponse.setDateHeader, it worked fine 
for the first request. On subsequent requests, however, the value of the header would 
always be the same as that from the first request, regardless of what was set by the 
servlet.

I tracked it down to src/share/org/apache/tomcat/util/buf/DateTool.java. It uses  
modulus, when surely integer division is wanted (I think it wants to discard the 
millisecond component of the time value):


--- DateTool.java.orig  Wed Jan 23 15:29:26 2002
+++ DateTool.java   Tue Jan 15 13:47:10 2002
@@ -142,7 +142,7 @@
 /** 
  */
 public static String format1123( Date d ) {
-long dt = d.getTime() % 1000;
+long dt = d.getTime() / 1000;
 if ((rfc1123DS != null) && (dt == rfc1123Sec))
 return rfc1123DS;
 rfc1123DS  = rfc1123Format.format( d );
@@ -151,7 +151,7 @@
 } 
 
 public static String format1123( Date d,DateFormat df ) {
-long dt = d.getTime() % 1000;
+long dt = d.getTime() / 1000;
 if ((rfc1123DS != null) && (dt == rfc1123Sec))
 return rfc1123DS;
 rfc1123DS  = df.format( d );


This patch fixed the problem I was seeing.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 5993] New: - Build of mod_jk ends in error (Command failed with rc=16777215 )

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5993

Build of mod_jk ends in error (Command failed with rc=16777215 )

   Summary: Build of mod_jk ends in error (Command failed with
rc=16777215 )
   Product: Tomcat 3
   Version: 3.3.x Nightly
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Connectors
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


1.Built apache 1.3.22 with the configure settings that follow (see below).
2.Built tomcat from jakarta-tomcat-3.3a-src.tar.gz by executing ant.
3.Attempted build-solaris.sh from native/mod_jk/apache1.3
4.Attempted the following:
$APACHE_HOME/bin/apxs -o mod_jk.so -DSOLARIS -I../common -I$JAVA_HOME/include -
I$JAVA_HOME/include/solaris -c *.c ../common/*.c

5.Received the following error in both cases:

  -o mod_jk.so jk_worker.o jk_util.o jk_uri_worker_map.o jk_sockbuf.o jk_pool.o
jk_nwmain.o jk_msg_buff.o jk_map.o jk_lb_worker.o jk_jni_worker.o jk_connect.o j
k_ajp13_worker.o jk_ajp13.o jk_ajp12_worker.o mod_jk.o
apxs:Break: Command failed with rc=16777215 

./configure \
"--with-layout=Apache" \
"--enable-module=so" \
"--enable-rule=SHARED_CORE" \
"--enable-rule=SHARED_CHAIN" \
"--prefix=/home/employ/apache" \
"--enable-module=most" \
"--enable-shared=max" \
"$@"

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin AttributeTag.java ListGroupsAction.java ListGroupsForm.java ListUsersAction.java ListUsersForm.java UsersTreeBuilder.java ApplicationResources_en.properties RowTag.java SetUpTreeAction.java

[craigmcc]

craigmcc02/01/23 15:06:54

  Modified:webapps/admin/WEB-INF controls.tld struts-config.xml web.xml
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin
ApplicationResources_en.properties RowTag.java
SetUpTreeAction.java
  Added:   webapps/admin listGroups.jsp listUsers.jsp
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin
AttributeTag.java ListGroupsAction.java
ListGroupsForm.java ListUsersAction.java
ListUsersForm.java UsersTreeBuilder.java
  Log:
  Initial integration of user database administration.  So far, only the
  "list" screens for groups and users are present -- next step is to add
  the ability to add, remove, and edit them.
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-4.0/webapps/admin/listGroups.jsp
  
  Index: listGroups.jsp
  ===
  
  <%@ page language="java" %>
  <%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
  <%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
  <%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
  <%@ taglib uri="/WEB-INF/controls.tld" prefix="controls" %>
  
  
  
  <%@ include file="header.jsp" %>
  
  
  
  
  
  
  
  
  

  
 
  

  

 
  
  

  


  -


  


  


  
  

  

  
  
  <%--<%@ include file="buttons.jsp" %>--%>

  
<%-- Groups List --%>
  

   
 
  

  

  
  

  


  
 
  

 
  

  

  

  

  
  <%--   <%@ include file="buttons.jsp" %>  --%>
  

  
   
  
  
  
  
  
  1.1  jakarta-tomcat-4.0/webapps/admin/listUsers.jsp
  
  Index: listUsers.jsp
  ===
  
  <%@ page language="java" %>
  <%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
  <%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
  <%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
  <%@ taglib uri="/WEB-INF/controls.tld" prefix="controls" %>
  
  
  
  <%@ include file="header.jsp" %>
  
  
  
  
  
  
  
  
  

  
 
  

  

 
  
  

  


  -


  


  


  
  

  

  
  
  <%--<%@ include file="buttons.jsp" %>--%>

  
<%-- Users List --%>
  

   
 
  

  

  
  

  


  
 
  

 
  

  

  

  

  
  <%--   <%@ include file="buttons.jsp" %>  --%>
  

  
   
  
  
  
  
  
  1.4   +62 -0 jakarta-tomcat-4.0/webapps/admin/WEB-INF/controls.tld
  
  Index: controls.tld
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/controls.tld,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- controls.tld  3 Jan 2002 23:21:53 -   1.3
  +++ controls.tld  23 Jan 2002 23:06:53 -  1.4
  @@ -322,4 +322,66 @@
   
 
   
  +  
  +
  +  
  +
  +attribute
  +org.apache.webapp.admin.AttributeTag
  +empty
  +
  +  Look up an attribute on a JMX MBean, specified by an object name
  +  specified by the "name" (and optional "property" and "scope")
  +  attributes, and render it to the current JSP writer.  The object name
  +  identified by these attributes can be either a java.lang.String version
  +  of the name, or a javax.management.ObjectName instance.
  +
  +
  +
  +  attribute
  +  true
  +  true
  +  
  +Name of the attribute of the JMX MBean whose value is to be
  +retrieved and written to the current JSP writer.
  +  
  +
  +
  +
  +  name
  +  true
  +  t

RE: iSeries (AS/400) unusual JDK layout problem

[GOMEZ Henri]

Our iSeries are using now latest JDK 1.3.1
and the strange layout is still here :(

/QIBM/ProdData/Java400/jdk13

The patch is really needed ;)

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 5560] - Removal of unnecesary white space in output

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5560

Removal of unnecesary white space in output

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-01-23 22:46 ---
Both of the JSP 1.1 and JSP 1.2 spec specify that the white space is
preserved.  Since Tomcat 3.x is a reference implementation of the JSP 1.1
spec, it is not allowed to remove the whitespace.  You are welcome to
customize your version to do this, though.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 5411] - JSP session does not work with IE/IIS5/Tomcat 3.3

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5411

JSP session does not work with IE/IIS5/Tomcat 3.3

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-01-23 22:37 ---
There isn't enough information to determine how much Tomcat may be contributing
to problem  behavior.  IE and possibly your web application are contributing as
well, but how much can't be determined with the information given.  As a result,
I'm resolving this as INVALID.

If frames are involved, IE is known to be able to make multiple requests which
will each get a different session, causing their session objects not to be
shared.  I can't tell if this applies to your web application.

If you can supply a web application and steps to reproduce, reopen the bug
with the additional information.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 5246] - illegal tag at jsp:plugin

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5246

illegal tag at jsp:plugin

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-01-23 22:24 ---
If I understand the document correctly, the "java_code" and "java_codebase"
parameters are provided in case there is a conflict with "code" and "codebase"
parameters used by the executed bean or applet.  It is beyond the scope of
Tomcat 3.3.x development to update Jasper to determine if it is safe to use
"code" and "codebase" as parameters, instead of "java_code" and "java_codebase".

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 4426] - DB polling

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4426

DB polling

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-01-23 22:18 ---
There isn't enough information here to attempt to diagnose the problem.
Please retry with the latest Tomcat 3.3.x version and reopen with additional
details if the problem still exists.  Include, if possible, a webapp that
illustrates the problem.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 5990] New: - Starting in another directory problem

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5990

Starting in another directory problem

   Summary: Starting in another directory problem
   Product: Tomcat 4
   Version: Nightly Build
  Platform: PC
   URL: http://jakarta.apache.org/builds/gump/latest/jakarta-
cactus-23.html
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,

I'm having problem starting Tomcat 4.1dev (i.e. latest nightly build
18/1/2002) when I use catalina.base to start it from another directory. It 
works fine with Tomcat 4.0, Tomcat 4.0.1 and Tomcat 4.0.2b2 but _not_ with 
Tomcat 4.1dev.

The error can be found at http://jakarta.apache.org/builds/gump/latest/jakarta-
cactus-23.html

Here's my start script :







  
  

  
  
  
  



Any idea why this worked before (on older versions of Tomcat) and is now 
failing ?

Thanks a lot
-Vincent

P.S. : java.class.path = C:\apps\jdk1.3.1_01\lib\tools.jar;C:\apps\jakarta-ant-
1.4.1\lib\xerces.j
ar;C:\apps\jakarta-ant-1.4.1\lib\xalan-2.2.0-D8.jar;C:\apps\jakarta-ant-
1.4.1\lib\stylebook-1.0-b3_xalan-2.jar;C:\apps\jakarta-ant-1.4.1\lib\rhi
no.jar;C:\apps\jakarta-ant-1.4.1\lib\resolver.jar;C:\apps\jakarta-ant-1.
4.1\lib\mockobjects.jar;C:\apps\jakarta-ant-1.4.1\lib\logkit.jar;C:\apps
\jakarta-ant-1.4.1\lib\junit.jar;C:\apps\jakarta-ant-1.4.1\lib\jrefactor
y.jar;C:\apps\jakarta-ant-1.4.1\lib\jaxp.jar;C:\apps\jakarta-ant-1.4.1\l
ib\jakarta-ant-1.4.1-optional.jar;C:\apps\jakarta-ant-1.4.1\lib\fop-0_20
_1-dev.jar;C:\apps\jakarta-ant-1.4.1\lib\cocoon.jar;C:\apps\jakarta-ant-
1.4.1\lib\cactus.jar;C:\apps\jakarta-ant-1.4.1\lib\cactus-ant.jar;C:\app
s\jakarta-ant-1.4.1\lib\bsf.jar;C:\apps\jakarta-ant-1.4.1\lib\batik-libs
.jar;C:\apps\jakarta-ant-1.4.1\lib\avalon-framework.jar;C:\apps\jakarta-
ant-1.4.1\lib\avalon-excalibur.jar;C:\apps\jakarta-ant-1.4.1\lib\aspectj
tools.jar;C:\apps\jakarta-ant-1.4.1\lib\aspectjrt.jar;C:\apps\jakarta-an
t-1.4.1\lib\aspectj-ant.jar;C:\apps\jakarta-ant-1.4.1\lib\ant.jar

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Native2: proposed interface change

[Kevin Seguin]

> 
> What I want is to make the C code implement the
> same abstractions with the java side and to get JNI to use the
> same transport abstraction.
> 
> 
> What do you think ? Henri, JFC, Kevin - I hope for an quick answer :-)
> 

it sounds like you're heading towards a good deal of symmetry between the
java and c code, which is definitely good :)

+1

-kevin.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 5908] - java.lang.IllegalStateException: zip file closed

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5908

java.lang.IllegalStateException: zip file closed

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
   ||m



--- Additional Comments From [EMAIL PROTECTED]  2002-01-23 20:46 ---
*** Bug 5894 has been marked as a duplicate of this bug. ***

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 5894] - Manager get IllegalStateException during 'install' command

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5894

Manager get IllegalStateException during 'install' command

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-01-23 20:46 ---


*** This bug has been marked as a duplicate of 5908 ***

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Native2: proposed interface change

[costinm]

One of the goals of the new native connector is to provide better
interfaces and support for different transports.

What I would like is to clarify ( and simplify ) the relation
between the 3 objects that are involved in the transport:
- worker
- endpoint
- channel
in order to have less duplicated code and more flexibility.

The proposal is:
- move service() from endpoint_t to worker_t.
- move get_endpoint() from worker_t and done() from endpoint_t to
channel_t.
- move processCallbacks() from workerEnv_t to channel_t.

What we acomplish by that:
- channel will be the only object dealing with message transport
( regardless of the message format ). JNI which uses a different
protocol will be a normal channel like any other.

- worker will only implement service() ( the actual action ), using
delegation to channel or a different mechanism. A worker can
implement a different protocol ( like warp ), or do anything else -
it still have the same flexibility, just that the code will be much
simpler since it'll delegate instead of duplicate.

- endpoint is specific and managed by channel, and represents a
(single) connection between java and C.

Worker remains the 'central' object, controlling how the request is
forwarded. We just move the overhead of managing specific connections
to channel, which is handling the transport.


What I want is to make the C code implement the
same abstractions with the java side and to get JNI to use the
same transport abstraction.


What do you think ? Henri, JFC, Kevin - I hope for an quick answer :-)

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 5988] - Jasper Null Pointer Exception Error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5988

Jasper Null Pointer Exception Error





--- Additional Comments From [EMAIL PROTECTED]  2002-01-23 19:50 ---
One additional thing...it goes away when I try to refresh the page.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 5988] New: - Jasper Null Pointer Exception Error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5988

Jasper Null Pointer Exception Error

   Summary: Jasper Null Pointer Exception Error
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Quite a number of times, I receive a null pointer exception error when
trying to access components with the "request" and/or "pagecontext" objects 
within a JSP page. Could this be related to session issues? Could this be 
related to using the  attribute?

Here is the stack-trace dump on one of the pages:

java.lang.NullPointerException
at org.apache.jasper.servlet.JasperLoader.loadClass
(JasperLoader.java:198)
at org.apache.jasper.servlet.JasperLoader.loadClass
(JasperLoader.java:132)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
at org.apache.jsp.display$jsp._jspService(display$jsp.java:101)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service
(JspServlet.java:202)
at org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:382)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:243)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:201)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2344)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:164)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.valves.AccessLogValve.invoke
(AccessLogValve.java:462)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:163)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.connector.http.HttpProcessor.process
(HttpProcessor.java:1011)
at org.apache.catalina.connector.http.HttpProcessor.run
(HttpProcessor.java:1106)
at java.lang.Thread.run(Thread.java:484)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 5986] - The lib directory in WEB-INF only takes jar files

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5986

The lib directory in WEB-INF only takes jar files

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-01-23 18:54 ---
a) You can use the 'classes' folder to do that. Put the properties there, so 
that you can edit them easily.
b) Won't fix, as the spec mandates using JARs. Using a zip would break 
portability.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: