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

2002-01-23 Thread bugzilla 

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5986.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread bugzilla 

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5988.
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 jsp:usebean 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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread bugzilla 

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5988.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Native2: proposed interface change

2002-01-23 Thread 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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread bugzilla 

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5894.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread bugzilla 

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5908.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: Native2: proposed interface change

2002-01-23 Thread 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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread bugzilla 

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5990.
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 :

java classname=org.apache.catalina.startup.Bootstrap
fork=yes
jvmarg value=-Dcatalina.home=${tomcat.home.40}/
jvmarg value=-Dcatalina.base=${out.tomcat40.dir}/
arg value=start/
classpath

  !-- This is to allow the use of -Dbuild.sysclasspath=only when
   starting Ant - Meaning that all jars need to be on the
   initial classpath --
  pathelement path=${java.class.path}/

  !-- These are ignore if -Dbuild.sysclasspath=only is used
--
  fileset dir=${tomcat.home.40}
  include name=bin/bootstrap.jar/
  /fileset
/classpath
/java

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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

DO NOT REPLY [Bug 4426] - DB polling

2002-01-23 Thread bugzilla 

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4426.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread bugzilla 

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5246.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread bugzilla 

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5411.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread bugzilla 

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5560.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread 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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread 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
  ===
  !-- Standard Struts Entries --
  %@ 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 %
  
  html:html locale=true
  
  %@ include file=header.jsp %
  
  !-- Body --
  body bgcolor=white
  
  !--Form --
  
  html:errors/
  
  html:form action=/listUsers
table width=100% border=0 cellspacing=0 cellpadding=0
  tr bgcolor=7171A5
td width=81% 
  div class=page-title-text align=left
bean:message key=listGroups.title/
  /div
/td
td width=19% 
  div align=right
  controls:actions
controls:action selected=true
  bean:message key=actions.available.actions/
/controls:action
controls:action
  -
/controls:action
controls:action url=
  bean:message key=actions.group.create/
/controls:action
controls:action url=
  bean:message key=actions.group.delete/
/controls:action
!-- add the urls later once those screens get implemented --
  /controls:actions
  /div
/td
  /tr
/table
  /html:form
  
  %--%@ include file=buttons.jsp %--%
br
  
%-- Groups List --%
  
table class=back-table border=0 cellspacing=0 cellpadding=1 width=100%
  tr 
td 
  table class=front-table border=1
   cellspacing=0 cellpadding=0 width=100%
tr class=header-row
  tddiv align=left class=table-header-text
bean:message key=listGroups.groupname/
  /div/td
  tddiv align=left class=table-header-text
bean:message key=listGroups.description/
  /div/td
/tr
logic:iterate name=groups id=group
  tr class=line-row
tddiv align=left class=table-normal-textnbsp;
  controls:attribute name=group attribute=groupname/
/div/td
tddiv align=left class=table-normal-textnbsp;
  controls:attribute name=group attribute=description/
/div/td
  /tr
/logic:iterate
  /table
/td
  /tr
/table
  
  %--   %@ include file=buttons.jsp %  --%
  
br
  
  pnbsp;/p
  /body
  /html:html
  
  
  
  1.1  jakarta-tomcat-4.0/webapps/admin/listUsers.jsp
  
  Index: listUsers.jsp
  ===
  !-- Standard Struts Entries --
  %@ 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 %
  
  html:html locale=true
  
  %@ include file=header.jsp %
  
  !-- Body --
  body bgcolor=white
  
  !--Form --
  
  html:errors/
  
  html:form action=/listUsers
table width=100% border=0 cellspacing=0 cellpadding=0
  tr bgcolor=7171A5
td width=81% 
  div class=page-title-text align=left
bean:message key=listUsers.title/
  /div
/td
td width=19% 
  div align=right
  controls:actions
controls:action selected=true
  bean:message key=actions.available.actions/
/controls:action
controls:action
  -
/controls:action
controls:action url=
  bean:message key=actions.user.create/
/controls:action
controls:action url=

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

2002-01-23 Thread bugzilla 

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5993.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread bugzilla 

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5994.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

HEAD Branch Build Problems

2002-01-23 Thread Craig R. McClanahan 

Ive 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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread 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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: HEAD Branch Build Problems

2002-01-23 Thread Remy Maucherat 

 Ive 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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread costin 

costin  02/01/23 15:28:49

  Modified:src/share/org/apache/jasper/compiler SunJavaCompiler.java
  Log:
  A bit of cutpaste 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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: jk tags

2002-01-23 Thread 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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: Native2: proposed interface change

2002-01-23 Thread 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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread 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:   
mailto:[EMAIL PROTECTED]
For additional commands, e-mail: 
mailto:[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: [Tomcat 4.0.2-b2] Java binaries uploaded

2002-01-23 Thread 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:   
mailto:[EMAIL PROTECTED]
For additional commands, e-mail: 
mailto:[EMAIL PROTECTED]



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: HEAD Branch Build Problems

2002-01-23 Thread 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

  Ive 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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: HEAD Branch Build Problems

2002-01-23 Thread 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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: [Tomcat 4.0.2-b2] Java binaries uploaded

2002-01-23 Thread 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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread 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( debug0) log( Found javac in context init);
  +} catch( ClassNotFoundException ex ) {
  +if( debug0) 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(debug0) log.log( Found javac using context loader);
  +} catch( ClassNotFoundException ex ) {
  +if(debug0) log.log( javac not found using context loader);
  +}
  +
  +try {
  +

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

2002-01-23 Thread 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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread bugzilla 

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5769.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread bugzilla 

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5995.
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.

--
FORM action=createtask enctype=multipart/form-data
CENTER
TABLE border=0 cellspacing=1 bgcolor=#dcdcdd
  TBODY bgcolor=white

INPUT type=HIDDEN name=task_ID value = %= taskID% 
..
/FORM

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread bugzilla 

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5993.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread 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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread bugzilla 

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5998.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread 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 org.apache.tomcat.util.net.*;
   import org.apache.tomcat.util.buf.*;
   import org.apache.tomcat.util.http.*;
   
  
  
  
  1.4   +0

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

2002-01-23 Thread 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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread 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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread bugzilla 

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6000.
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.* %
jsp:useBean id=transform scope=page class=transform.Transform/
%
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread bugzilla 

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5684.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread bugzilla 

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6000.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

2002-01-23 Thread 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, and full
reloading
  all worked.
 
  I do have one thing to clear up in my mind in understanding this class
  loader mechanism.  The simpleclassloader has one deficiency as