Re: gzip-encoding in TC 4.1.x/5.x

[Henri Gomez]

One of the problems is that the compressed streams from the JDK are not 
recyclable, cause a lot of possibly synced method calls, and so on. 
Plus, it's kinda ugly to fit the OS and IS models into the Coyote 
HTTP/1.1 filter model.

Does anyone know about compression code which would use byte arrays on 
input/output ?

I could try to make something like this, just tell me what you need.


I hope someone could works on it at the coyote level to make
it available for both HTTP 1.1 and JK2 upper layers.





You can't do it, unless the code is in the adapter, and that's bad 
design (it's a protocol feature, so it should be in the protocol 
hanlder).



Couldn't the compression goes in filter, like Amy does sometimes ago ?



You can use it there if you want. However, transfer encoding is a 
protocol feature. So it seems logical to handle this at the protocol 
layer (for example, chunked is a transfer encoding, and also hanlded at 
the protocol handler level). Plus you get a nice server wide 
configuration on the native webserver, rather than individual settings 
depending on where the resource is served from. It just seems much cleaner.

I agree


I don't quite see the Apache <-> Tomcat link being bandwidth constrained 
except in very specific situations. In loopback, it uses special 
optimized processing, and if there are separate boxes for Apache and 
Tomcat, then they should IMO use a dedicated network link.

Dedicated link, you know what it means say the average IT manager :

DECICATED LINK = A NEW SWITCH + NEW CABLES + NEW SUPERVISION => $/EUR++

If ever you came back to Lyon, I'll make you meet one of my IT manager ;-)


I don't see what you can do to improve Amy's filter performance, as it 
has to:
- be thread safe
- use inefficient methods from the servlet API (which create garbage, etc)

What could we do so ?

- Create a GZIP implementation using byte array
- Use it in HTTP 1.1 stack
- Use it in JK2

As I tell you, I could try to look for or write a GZIP writer 
implementation using byte array, just provide the interfaces.





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

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java

[billbarker]

billbarker2002/12/18 01:15:06

  Modified:jk/java/org/apache/jk/common HandlerRequest.java
   jk/java/org/apache/jk/core WorkerEnv.java
   jk/java/org/apache/jk/server JkCoyoteHandler.java
  Log:
  Fixing the mess that was SSL-Cert evalulation for Jk2.
  
  Fix for Bug #15456
  Reported By: Alex Roytman [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.19  +7 -6  
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java
  
  Index: HandlerRequest.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- HandlerRequest.java   23 Nov 2002 06:34:47 -  1.18
  +++ HandlerRequest.java   18 Dec 2002 09:15:06 -  1.19
  @@ -529,16 +529,17 @@
   msg.getBytes(req.instanceId());
   break;

  - case SC_A_SSL_CERT :
  - req.scheme().setString( "https" );
  +case SC_A_SSL_CERT :
  +req.scheme().setString( "https" );
   // Transform the string into certificate.
  +tmpMB = new MessageBytes();
   msg.getBytes(tmpMB);
   String certString = tmpMB.toString();
  - // SSL certificate extraction is costy, moved to 
JkCoyoteHandler
  -req.setAttribute(SSLSupport.CERTIFICATE_KEY, certString);
  +// SSL certificate extraction is costy, moved to JkCoyoteHandler
  +req.setNote(WorkerEnv.SSL_CERT_NOTE, tmpMB);
   break;
  - 
  - case SC_A_SSL_CIPHER   :
  +
  +case SC_A_SSL_CIPHER   :
req.scheme().setString( "https" );
   msg.getBytes(tmpMB);
req.setAttribute(SSLSupport.CIPHER_SUITE_KEY,
  
  
  
  1.9   +1 -0  
jakarta-tomcat-connectors/jk/java/org/apache/jk/core/WorkerEnv.java
  
  Index: WorkerEnv.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/core/WorkerEnv.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- WorkerEnv.java5 Jun 2002 21:23:32 -   1.8
  +++ WorkerEnv.java18 Dec 2002 09:15:06 -  1.9
  @@ -82,6 +82,7 @@
   
   public static final int ENDPOINT_NOTE=0;
   public static final int REQUEST_NOTE=1;
  +public static final int SSL_CERT_NOTE=16;
   int noteId[]=new int[4];
   String noteName[][]=new String[4][];
   private Object notes[]=new Object[32];
  
  
  
  1.32  +21 -19
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java
  
  Index: JkCoyoteHandler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java,v
  retrieving revision 1.31
  retrieving revision 1.32
  diff -u -r1.31 -r1.32
  --- JkCoyoteHandler.java  23 Nov 2002 06:34:47 -  1.31
  +++ JkCoyoteHandler.java  18 Dec 2002 09:15:06 -  1.32
  @@ -381,27 +381,29 @@
   } else if( actionCode==ActionCode.ACTION_REQ_SSL_ATTRIBUTE ) {
   org.apache.coyote.Request req=(org.apache.coyote.Request)param;
   
  - // Extract SSL certificate information (if requested)
  -String certString = 
(String)req.getAttribute(SSLSupport.CERTIFICATE_KEY);
  -byte[] certData = certString.getBytes();
  -ByteArrayInputStream bais = new ByteArrayInputStream(certData);
  +// Extract SSL certificate information (if requested)
  +MessageBytes certString = 
(MessageBytes)req.getNote(WorkerEnv.SSL_CERT_NOTE);
  +if( certString != null ) {
  +byte[] certData = certString.getByteChunk().getBytes();
  +ByteArrayInputStream bais = new ByteArrayInputStream(certData);

  -// Fill the first element.
  -X509Certificate jsseCerts[] = null;
  -try {
  -CertificateFactory cf =
  -CertificateFactory.getInstance("X.509");
  -X509Certificate cert = (X509Certificate)
  -cf.generateCertificate(bais);
  -jsseCerts =  new X509Certificate[1];
  -jsseCerts[0] = cert;
  -} catch(java.security.cert.CertificateException e) {
  -log.error("Certificate convertion failed" + e );
  -e.printStackTrace();
  -}
  +// Fill the first element.
  +X509Certificate jsseCer

DO NOT REPLY [Bug 15456] - NullPointerException in JkCoyoteHandler when connecting using SSL on Apache server

[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=15456

NullPointerException in JkCoyoteHandler when connecting using SSL on Apache server

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-12-18 09:17 ---
Fixed now in the CVS, and will appear in 4.1.18.

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

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common HandlerRequest.java

[billbarker]

billbarker2002/12/18 01:26:48

  Modified:jk/java/org/apache/jk/common HandlerRequest.java
  Log:
  Now, with the correct version, after remembering to save the file before doing a 
'ci'.
  
  Revision  ChangesPath
  1.20  +3 -4  
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java
  
  Index: HandlerRequest.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- HandlerRequest.java   18 Dec 2002 09:15:06 -  1.19
  +++ HandlerRequest.java   18 Dec 2002 09:26:48 -  1.20
  @@ -532,11 +532,10 @@
   case SC_A_SSL_CERT :
   req.scheme().setString( "https" );
   // Transform the string into certificate.
  -tmpMB = new MessageBytes();
  -msg.getBytes(tmpMB);
  -String certString = tmpMB.toString();
  +MessageBytes tmpMB2 = new MessageBytes();
  +msg.getBytes(tmpMB2);
   // SSL certificate extraction is costy, moved to JkCoyoteHandler
  -req.setNote(WorkerEnv.SSL_CERT_NOTE, tmpMB);
  +req.setNote(WorkerEnv.SSL_CERT_NOTE, tmpMB2);
   break;
   
   case SC_A_SSL_CIPHER   :
  
  
  

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

Re: gzip-encoding in TC 4.1.x/5.x

[Henri Gomez]

Did this ZLIB Java implementation could be what you're looking
Remy ?

http://www.jcraft.com/jzlib/index.html


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

DO NOT REPLY [Bug 15477] New: - Error opening database connection using DB2

[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=15477

Error opening database connection using DB2

   Summary: Error opening database connection using DB2
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When I try to open a DB2 connection an exception is thrown when I perform the 
 if I use a 
JSP. I have tried to do it in components and in the same JSP, and I get always 
the same exception.

Otherwise using the same components from a servlet, it works fine.

I have tried to use the JSP using Caucho Resin and it also works.

Thank you

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

DO NOT REPLY [Bug 15479] New: - doc typo in server.xml

[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=15479

doc typo in server.xml

   Summary: doc typo in server.xml
   Product: Tomcat 4
   Version: 4.1.17
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Webapps:Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


just a small typo: The server.xml delivered with 4.1.17 comes with a typo in a
commented Engine tag, where it says jmvRoute instead of jvmRoute.
As the tag is commented, the typo has no effect, unless you remove the comment
and don't check the already written values.

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

RE: Upgrade to Tomcat 4.1.17 - server has reset connection

[Matt Raible]

You are correct - I am using Apache 1.3.  Is there anyway I can change
this log message setting?

Thanks,

Matt

> -Original Message-
> From: Costin Manolache [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, December 17, 2002 11:22 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Upgrade to Tomcat 4.1.17 - server has reset connection
> 
> 
> Matt Raible wrote:
> 
> > I upgraded my site to use Tomcat 4.1.17 tonight.  While 
> this fixed all 
> > my previous ClassNotFound errors for the hsql jdbc driver 
> (in Tomcat 
> > 4.0.6), I started getting a new error:
> > 
> > 17-Dec-2002 10:02:52 PM org.apache.jk.common.ChannelSocket
> > processConnection
> > INFO: server has been restarted or reset this connection
> > 
> > I don't know if this is a Tomcat bug or if it's something in my 
> > application (Roller).  It seems to occur when someone views 
> the site, 
> > but it doesn't seem to affect the site at all.
> 
> I assume you are using Apache 1.3 ? 
> 
> This is a message indicating that the web server has been 
> restarted. Probably we should downgrade the message to debug, 
> since this 
> is normal for apache ( it is not normal for other servers ). 
> Apache has a config option to restart itself after a number 
> of requests - 
> to avoid memory leaks on some OSes.
> 
> 
> Costin
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 



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

Re: gzip-encoding in TC 4.1.x/5.x

[Remy Maucherat]

Henri Gomez wrote:

One of the problems is that the compressed streams from the JDK are
not recyclable, cause a lot of possibly synced method calls, and so
on. Plus, it's kinda ugly to fit the OS and IS models into the
Coyote HTTP/1.1 filter model.

Does anyone know about compression code which would use byte arrays
on input/output ?


I could try to make something like this, just tell me what you need.


I hope someone could works on it at the coyote level to make
it available for both HTTP 1.1 and JK2 upper layers.






You can't do it, unless the code is in the adapter, and that's bad 
design (it's a protocol feature, so it should be in the protocol 
hanlder).




Couldn't the compression goes in filter, like Amy does sometimes ago ?




You can use it there if you want. However, transfer encoding is a 
protocol feature. So it seems logical to handle this at the protocol 
layer (for example, chunked is a transfer encoding, and also hanlded 
at the protocol handler level). Plus you get a nice server wide 
configuration on the native webserver, rather than individual settings 
depending on where the resource is served from. It just seems much 
cleaner.


I agree


I don't quite see the Apache <-> Tomcat link being bandwidth 
constrained except in very specific situations. In loopback, it uses 
special optimized processing, and if there are separate boxes for 
Apache and Tomcat, then they should IMO use a dedicated network link.


Dedicated link, you know what it means say the average IT manager :

DECICATED LINK = A NEW SWITCH + NEW CABLES + NEW SUPERVISION => $/EUR++

If ever you came back to Lyon, I'll make you meet one of my IT manager ;-)


He's dumb ;-)
Look, you're putting together a cluster. Nothing good will come out of 
saving $50. Also, if you have only one Tomcat srever, you could use a 
crossover cable.

I don't see what you can do to improve Amy's filter performance, as it 
has to:
- be thread safe
- use inefficient methods from the servlet API (which create garbage, 
etc)


What could we do so ?

- Create a GZIP implementation using byte array
- Use it in HTTP 1.1 stack
- Use it in JK2

As I tell you, I could try to look for or write a GZIP writer 
implementation using byte array, just provide the interfaces.

Well, the idea is to be efficient, so:
- Have a ByteChunk compress(ByteChunk) method (assuming that giving it 
an empty chunk means it's the end of the input stream)
- Have a recycle method
- No object allocation (and esp buffers), except on init
- No need to worry about thread safety, so no syncs

But it's ok, we can have the first version use the JDK code.

> Did this ZLIB Java implementation could be what you're looking
> Remy ?
>
> http://www.jcraft.com/jzlib/index.html

Not really, it doesn't seem recyclable.

Remy


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

DO NOT REPLY [Bug 15480] New: - Errror compiling large JSP pages on Solaris 7

[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=15480

Errror compiling large JSP pages on Solaris 7

   Summary: Errror compiling large JSP pages on Solaris 7
   Product: Tomcat 3
   Version: 3.3.1 Final
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Major
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


An error occurs when compiling a big JSP page that produced a .java file of 
size >150k. On solaris JDK1.4.1_01 gives compilation errors like:

variable foo may not have been initialized

see message http://www.caucho.com/support/resin-interest/0203/0288.html for 
resin that seem to have thje same problem.

It seems that deprecated method  sun.tools.javac.Main does not work with large 
java sources

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

Re: gzip-encoding in TC 4.1.x/5.x

[Henri Gomez]

Dedicated link, you know what it means say the average IT manager :

DECICATED LINK = A NEW SWITCH + NEW CABLES + NEW SUPERVISION => $/EUR++

If ever you came back to Lyon, I'll make you meet one of my IT manager 
;-)


He's dumb ;-)
Look, you're putting together a cluster. Nothing good will come out of 
saving $50. Also, if you have only one Tomcat srever, you could use a 
crossover cable.

On production site, a 100 Mb switch + cabling and monitoring cost
much more than 50 EUR :)



As I tell you, I could try to look for or write a GZIP writer 
implementation using byte array, just provide the interfaces.


Well, the idea is to be efficient, so:
- Have a ByteChunk compress(ByteChunk) method (assuming that giving it 
an empty chunk means it's the end of the input stream)

Ok, but the compress method will create the returned
ByteChunk and you may want instead :

int compress(ByteChunk src, ByteChunk dst)

Which will make the caller task to create src/dst ByteChunk.


- Have a recycle method


With compress(src, dst), caller make the recycling.


- No object allocation (and esp buffers), except on init


Each using instance will create it's own dst chunk.


- No need to worry about thread safety, so no syncs


Caller decide what to pass.


But it's ok, we can have the first version use the JDK code.


I'll see how we could make use ByteChunk with JDK code for now.



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

Re: gzip-encoding in TC 4.1.x/5.x

[Remy Maucherat]

Henri Gomez wrote:

As I tell you, I could try to look for or write a GZIP writer 
implementation using byte array, just provide the interfaces.



Well, the idea is to be efficient, so:
- Have a ByteChunk compress(ByteChunk) method (assuming that giving it 
an empty chunk means it's the end of the input stream)


Ok, but the compress method will create the returned
ByteChunk and you may want instead :

int compress(ByteChunk src, ByteChunk dst)

Which will make the caller task to create src/dst ByteChunk.


Actually, they are both equivalent.


I'll see how we could make use ByteChunk with JDK code for now.


I've already started experimenting.

Remy


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

Re: gzip-encoding in TC 4.1.x/5.x

[Henri Gomez]

Actually, they are both equivalent.


I'll see how we could make use ByteChunk with JDK code for now.



I've already started experimenting.


Thanks to send me a note when code will be available.

I'll could add some code to mimic mod_deflate ie :

- compress only certain type of mimes (ie only text/html)
- desactivate it for some browsers


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

DO NOT REPLY [Bug 15484] New: - Can't delete application files after Manager Webapps remove web app

[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=15484

Can't delete application files after Manager Webapps remove web app

   Summary: Can't delete application files after Manager Webapps
remove web app
   Product: Tomcat 4
   Version: 4.1.17
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


remove Context don't kill Classloader ?

Here my ant trace:

list:
 [list] OK - Listed applications for virtual host localhost

 [list] /admin:running:0:C:/server/jakarta/jakarta-tomcat-
4.1.12/server/weba
pps/admin

 [list] /login:running:5:C:/Dokumente/Struts/example/project/Login/build

 [list] /manager:running:0:C:/server/jakarta/jakarta-tomcat-
4.1.12/server/we
bapps/manager


BUILD SUCCESSFUL
Total time: 1 second
C:\Dokumente\Struts\example\project\Login>ant remove
Buildfile: build.xml

remove:
   [remove] OK - Removed application at context path /login


BUILD SUCCESSFUL
Total time: 1 second
C:\Dokumente\Struts\example\project\Login>ant clean
Buildfile: build.xml

clean:
   [delete] Deleting directory C:\Dokumente\Struts\example\project\Login\build

BUILD FAILED
file:C:/Dokumente/Struts/example/project/Login/build.xml:49: Unable to delete 
fi
le C:\Dokumente\Struts\example\project\Login\build\WEB-INF\lib\struts.jar

Total time: 1 second
C:\Dokumente\Struts\example\project\Login>ant clean
Buildfile: build.xml

clean:
   [delete] Deleting directory C:\Dokumente\Struts\example\project\Login\build

BUILD FAILED
file:C:/Dokumente/Struts/example/project/Login/build.xml:49: Unable to delete 
fi
le C:\Dokumente\Struts\example\project\Login\build\WEB-INF\lib\struts.jar

Total time: 1 second
C:\Dokumente\Struts\example\project\Login>ant list
Buildfile: build.xml

list:
 [list] OK - Listed applications for virtual host localhost

 [list] /admin:running:0:C:/server/jakarta/jakarta-tomcat-
4.1.12/server/weba
pps/admin

 [list] /manager:running:0:C:/server/jakarta/jakarta-tomcat-
4.1.12/server/we
bapps/manager


BUILD SUCCESSFUL
Total time: 1 second
C:\Dokumente\Struts\example\project\Login>

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

DO NOT REPLY [Bug 15484] - Can't delete application files after Manager Webapps remove web app

[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=15484

Can't delete application files after Manager Webapps remove web app

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-12-18 15:28 ---
This is the normal behaviour on Windowses platform. Some of your tools is
pointing to that jar (is having a reference). That's why ant it is not able to
remove the file (probably Tomcat is started, and Tomcat uses struts.jar).

Next time, I recommend you first ask the question on [EMAIL PROTECTED]

-- Jeanfrancois

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

Re: gzip-encoding in TC 4.1.x/5.x

[Remy Maucherat]

Henri Gomez wrote:

Actually, they are both equivalent.


I'll see how we could make use ByteChunk with JDK code for now.




I've already started experimenting.


Thanks to send me a note when code will be available.

I'll could add some code to mimic mod_deflate ie :

- compress only certain type of mimes (ie only text/html)
- desactivate it for some browsers


I think I said a few mistakes in the previous emails.

To summarize:
- transfer-encoding allows a protocol level compression; that's what I 
was planning to add to Coyote (see general transfer encoding, section 4.5)
- content-encoding does the same, but is considered application layer 
(see entity header fields, section 7.1)

(I'm quite sure I knew that really well a few months ago, but forgot 
about the subtle difference, since actually, both do the exact same 
thing to the entity body)

The "problem" is that, although clients support content-encoding, they 
don't care about transfer-encoding.

So actually, to be really clean, you would need two places with 
compression code:
- in Coyote HTTP/1.1, to handle transfer-encoding
- in the adapter (or somewhere similar) to handle content-encoding

Of course, since the two do the same, I don't see any reason to be 
overly fancy, and I'll add the compression code (well, the first draft) 
in Coyote HTTP/1.1 for now, as the filtering model makes the 
implementation somewhat cleaner.

As a side note, it would be good if the Servlet specification marked the 
headers from section 4.5 as "use at your own risk" headers (and esp 
trailer, transfer-encoding, connection).

Remy


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

DO NOT REPLY [Bug 14292] - Status message not included in HTTP response

[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=14292

Status message not included in HTTP response





--- Additional Comments From [EMAIL PROTECTED]  2002-12-18 17:30 ---
just a quick note: this bug ist still present in the 4.1.17 distribution.

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

DO NOT REPLY [Bug 15411] - A translation error does not occur if jsp:attribute is used to provide an attribute value for an XML element that should be conisdered template text.

[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=15411

A translation error does not occur if jsp:attribute is used to provide an attribute 
value for an XML element that should be conisdered template text.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

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

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties

[luehe]

luehe   2002/12/18 09:37:50

  Modified:jasper2/src/share/org/apache/jasper/compiler Parser.java
Validator.java
   jasper2/src/share/org/apache/jasper/resources
messages.properties
  Log:
  Fixed 15411: A translation error does not occur if jsp:attribute is used to provide 
an attribute value for an XML element that should be conisdered template text.
  
  Revision  ChangesPath
  1.51  +9 -8  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
  
  Index: Parser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
  retrieving revision 1.50
  retrieving revision 1.51
  diff -u -r1.50 -r1.51
  --- Parser.java   16 Dec 2002 23:02:39 -  1.50
  +++ Parser.java   18 Dec 2002 17:37:50 -  1.51
  @@ -1190,7 +1190,7 @@
} else if (reader.matches("element")) {
parseElement(parent);
} else if (reader.matches("attribute")) {
  - err.jspError(start, "jsp.error.attribute.invalidUse");
  + err.jspError(start, "jsp.error.namedAttribute.invalidUse");
} else if (reader.matches("fallback")) {
err.jspError(start, "jsp.error.fallback.invalidUse");
} else if (reader.matches("params")) {
  @@ -1317,12 +1317,13 @@
// Note except for the beginning of a page, the current char is '<'.
// Quoting in template text is handled here.
// JSP2.6 "A literal <% is quoted by <\%"
  + String templateText = null;
if (reader.matches("<\\%")) {
  - String content = reader.nextContent();
  - new Node.TemplateText("<%" + content, start, parent);
  - } else {
  - new Node.TemplateText(reader.nextContent(), start, parent);
  + templateText = "<%";
}
  + String content = reader.nextContent();
  + templateText = (templateText == null) ? content : templateText+content;
  + new Node.TemplateText(templateText, start, parent);
   }
   
   /*
  
  
  
  1.63  +9 -3  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java
  
  Index: Validator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java,v
  retrieving revision 1.62
  retrieving revision 1.63
  diff -u -r1.62 -r1.63
  --- Validator.java16 Dec 2002 17:34:32 -  1.62
  +++ Validator.java18 Dec 2002 17:37:50 -  1.63
  @@ -656,6 +656,12 @@
   }
   }
   
  + public void visit(Node.UninterpretedTag n) throws JasperException {
  +if (n.getNamedAttributeNodes() != null) {
  + err.jspError(n, "jsp.error.namedAttribute.invalidUse");
  +}
  +}
  +
public void visit(Node.CustomTag n) throws JasperException {
TagInfo tagInfo = n.getTagInfo();
if (tagInfo == null) {
  
  
  
  1.75  +2 -2  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
  
  Index: messages.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
  retrieving revision 1.74
  retrieving revision 1.75
  diff -u -r1.74 -r1.75
  --- messages.properties   16 Dec 2002 22:21:16 -  1.74
  +++ messages.properties   18 Dec 2002 17:37:50 -  1.75
  @@ -106,7 +106,7 @@
   jsp.error.param.invalidUse=The jsp:param action must not be used outside the 
jsp:include, jsp:forward, or jsp:params elements
   jsp.error.params.invalidUse=jsp:params must be a direct child of jsp:plugin
   jsp.error.fallback.invalidUse=jsp:fallback must be a direct child of jsp:plugin
  -jsp.error.attribute.invalidUse=jsp:attribute must be a sublement of a standard or 
custom action
  +jsp.error.namedAttribute.invalidUse=jsp:attribute must be a sublement of a standard 
or custom action
   jsp.error.closeindividualparam=param tag needs to be closed with \"/>\"
   jsp.error.closeparams=param tag needs to be closed with /params
   jsp.error.params.emptyBody=jsp:params must contain at least one nested jsp:param
  
  
  

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

DO NOT REPLY [Bug 15484] - Can't delete application files after Manager Webapps remove web app

[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=15484

Can't delete application files after Manager Webapps remove web app





--- Additional Comments From [EMAIL PROTECTED]  2002-12-18 17:42 ---
Situation:

no other tool used the libs in my application

1) install application with manager (ant task)
2) used appliction
3) detect a error
4) remove application with manager (ant task)
5) now I can't remove the copy application to make a clean build!

I think tomcat classloader not correct delete all reference on the removed 
jars!

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

RE: Upgrade to Tomcat 4.1.17 - server has reset connection

[Costin Manolache]

It seems you are using jdk1.4 logging. Just set the level to WARN
for org.apache.jk.common.ChannelSocket ( or org.apache.jk ).

The server restart is a workaround for buggy OSes with leaks.
I think having an INFO when the server restarts is reasonable - 
but I don't mind changing it to debug for the next release. 
For 4.1.17 - you'll have to configure the logger.

Costin




Matt Raible wrote:

> You are correct - I am using Apache 1.3.  Is there anyway I can change
> this log message setting?
> 
> Thanks,
> 
> Matt
> 
>> -Original Message-
>> From: Costin Manolache [mailto:[EMAIL PROTECTED]]
>> Sent: Tuesday, December 17, 2002 11:22 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: Upgrade to Tomcat 4.1.17 - server has reset connection
>> 
>> 
>> Matt Raible wrote:
>> 
>> > I upgraded my site to use Tomcat 4.1.17 tonight.  While
>> this fixed all
>> > my previous ClassNotFound errors for the hsql jdbc driver
>> (in Tomcat
>> > 4.0.6), I started getting a new error:
>> > 
>> > 17-Dec-2002 10:02:52 PM org.apache.jk.common.ChannelSocket
>> > processConnection
>> > INFO: server has been restarted or reset this connection
>> > 
>> > I don't know if this is a Tomcat bug or if it's something in my
>> > application (Roller).  It seems to occur when someone views
>> the site,
>> > but it doesn't seem to affect the site at all.
>> 
>> I assume you are using Apache 1.3 ?
>> 
>> This is a message indicating that the web server has been
>> restarted. Probably we should downgrade the message to debug,
>> since this
>> is normal for apache ( it is not normal for other servers ).
>> Apache has a config option to restart itself after a number
>> of requests -
>> to avoid memory leaks on some OSes.
>> 
>> 
>> Costin
>> 
>> 
>> 
>> 
>> --
>> To unsubscribe, e-mail:
>>  [EMAIL PROTECTED]>
>> For
>> additional commands,
>> e-mail: 
>>




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

Re: cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs ssl-howto.xml

[jean-frederic clere]

[EMAIL PROTECTED] wrote:

jfclere 2002/12/16 09:39:36

  Modified:webapps/tomcat-docs ssl-howto.xml
  Log:
  Add the format of the different certificates.
  
  Revision  ChangesPath
  1.12  +4 -3  jakarta-tomcat-4.0/webapps/tomcat-docs/ssl-howto.xml
  
  Index: ssl-howto.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/ssl-howto.xml,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- ssl-howto.xml	8 Feb 2002 17:51:05 -	1.11
  +++ ssl-howto.xml	16 Dec 2002 17:39:35 -	1.12
  @@ -384,8 +384,9 @@
   	-keystore 
   
   
  -Now you have a file called certreq.csr that you can submit to the Certificate Authority (look at the
  -documenation of the Certificate Authority website on how to do this). In return you get a Certificate.
  +Now you have a file called certreq.csr. The file is encoded in PEM format.
  +You can submit it to the Certificate Authority (look at the
  +documentation of the Certificate Authority website on how to do this). In return you get a Certificate.
   
   
   
  @@ -403,7 +404,7 @@
   keytool -import -alias root -keystore  \
   	-trustcacerts -file 
   
  -And finally import your new Certificate
  +And finally import your new Certificate (It must be in X509 format):

What about something like?
"It must be only the X509 certificate in format PEM or format DER"

The "only" is for example for CA.pl (openssl) that produces a file that contains 
some human readable data and the X509 certificate in PEM. The "human readable" 
data are not  accepted by keytool.

   	keytool -import -alias tomcat -keystore  \
   	-trustcacerts -file 
   
  
  
  

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






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

error-page status codes broken, no response to bugzilla report

[Donald Ball]

I submitted this bug report a few days ago:

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

It seems to me that tomcat is doing the wrong thing when it tags the error
page contents with status code 200 instead of the actual error status code.
If this is the case, is anyone interested in fixing tomcat? If this is not
the case, can someone try to explain why tomcat's behavior is correct?

- donald


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

service() method called Twice when using creating response with MIME type application/x-shockwave-flash

[Andrew Milkowski]

Using Apache Tomcat/4.1.12 deployment, following sample code in the servlet
used to demonstrate this behavior

public void service (HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {

final BufferedOutputStream bufferedOutputStream = new
BufferedOutputStream(response.getOutputStream(), 2048);

..
..
..

response.setContentType("application/x-shockwave-flash");

schart.encodeAsSWF(bufferedOutputStream);  // (schart here is a carting
package that encodes swf file into the OutputStream)


response.setHeader("Expires", "-1");
response.setHeader("nPragma", "no-cache");

bufferedOutputStream.flush();
bufferedOutputStream.close();

response.flushBuffer();
}

in the above service method gets called twice, before rendering browser
output with the Flash MIME content!

Did anyone here had a similar experience? (maybe not necessarily with a
application/x-shockwave-flash) where service
method is called twice before completing response..

Any suggestions/solutions greatly appreciated!


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

Re: [PROPOSAL] EL Transition to Jakarta Commons

[Costin Manolache]

+1

Is the EL depenent on javax.servlet or javax.servlet.jsp, or is it
completely independent and useable in non-servlet-container environments ?


BTW, another option that can be considered is what Sam Ruby mentioned
few times on jakarta-general or community, i.e. just lower the 
walls between jakarta projects. Moving it to jakarta-commons does
the same thing ( all jakarta committers can get access to it ),
but I don't think we have to move code in order to get this effect.

You may also consider asking for a separate mailing list ( 
jakarta-commons-el ?), the traffic on jakarta-commons is already high.

Costin


Jan Luehe wrote:

> I'd like to resume discussion on a proposal circulated by James
> Strachan on March 13, 2002, about turning the implementation of JSTL's
> expression language (EL) into a reusable component and moving it from
> the Standard Taglib, an implementation of JSTL hosted by
> jakarta-taglibs, to jakarta-commons, in order to make it available to
> a larger number of projects.
> 
> James' original proposal received some positive feedback from the
> taglibs-dev community. Below is a draft proposal for a formal
> submission to jakarta-commons, following the format of the
> jakarta-commons charter at http://jakarta.apache.org/commons/charter.html.
> 
> (0) Rationale
> 
> The JSP Standard Tag Library (JSTL), version 1.0, introduced the
> concept of an Expression Language (EL), whose main goal is to provide
> page authors with an easy way to access and manipulate application
> data without requiring the use of scriptlets
> 
> JSP 2.0 adopted the EL specification from JSTL, and expanded its
> scope: EL expressions are no longer limited to JSTL action attributes,
> but may be used in any standard or custom action attribute declared to
> accept a runtime expression. In addition, EL expressions may now also
> be used directly in template text outside of any actions. JSP 2.0 also
> added an important feature to the EL specification: EL functions,
> which allow page authors to invoke static methods in Java classes from
> EL expressions. Additionally, JSP 2.0 allows programmatic access and
> customization of the EL evaluator through a set of standard interfaces
> and abstract classes.
> 
> Currently, there are a number of projects (including Tomcat 5 and Java
> Server Faces) that leverage the EL implementation of the Standard
> Taglib. In addition, there seems to be interest in leveraging the EL
> in the context of scripting workflow activities using custom tag
> libraries.
> 
> In order to make the EL implementation available to Tomcat 5, the
> Tomcat team defined a new "ant" target for the Standard Taglib that
> builds just the EL portion and packages it in a JAR file
> ("jsp20el.jar") which is stored in Tomcat's common/lib directory. This
> approach has always been considered an interim solution only, until
> the EL implementation would move from the Standard Taglib to a more
> visible location such as jakarta-commons.
> 
> (1) Scope of the package
> 
> The package shall provide an implementation of the Expression Language
> specification which is part of the JSP 2.0 standard.
> 
> (1.5) Interaction with other packages
> 
> The package shall provide an implementation of the standard interfaces
> and abstract classes of the javax.servlet.jsp.el package, which is
> defined in the JSP 2.0 specification.
> 
> (2) Identify the initial source for the package
> 
> The initial codebase will be taken from the Standard Taglib project
> hosted at jakarta-taglibs. The source of the Standard Taglib is
> available as part of the jakarta-taglibs nightly source distribution
> at http://jakarta.apache.org/builds/jakarta-taglibs/nightly/src/
> 
> (2.1) Identify the base name for the package
> 
> The base name of the package shall be org.apache.commons.el
> 
> (2.2) Identify the coding conventions for this package
> 
> The package follows Sun's Java coding conventions (see
> http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html).
> 
> (3) Identify any Jakarta-Commons resources to be created
> 
> (3.1) Mailing list
> 
> The package shall use the jakarta-commons mailing list.
> 
> (3.2) CVS repositories
> 
> The package shall use a root branch of the jakarta-commons CVS.
> 
> (3.3) Bugzilla
> 
> The package shall be listed as the "EL" component under the "Commons"
> project in Bugzilla.
> 
> (3.4) Jyve FAQ (when available)
> 
> n/a
> 
> (4) Identify the initial set of committers to be listed in the Status
> File.
> 
> The initial set of committers will be identical to the set of
> committers of the Standard Taglib project.
> 
> 
> Thoughts?
> 
> Jan


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

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteConnector.java

[remm]

remm2002/12/18 10:11:11

  Modified:coyote/src/java/org/apache/coyote/tomcat4
CoyoteConnector.java
   coyote/src/java/org/apache/coyote/tomcat5
CoyoteConnector.java
  Log:
  - Add new compression attribute.
  
  Revision  ChangesPath
  1.19  +44 -11
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteConnector.java
  
  Index: CoyoteConnector.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteConnector.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- CoyoteConnector.java  26 Nov 2002 03:26:56 -  1.18
  +++ CoyoteConnector.java  18 Dec 2002 18:11:10 -  1.19
  @@ -259,13 +259,6 @@
*/
   private boolean secure = false;
   
  -/**
  - * Flag to disable setting a seperate time-out for uploads.
  - * If true, then the timeout parameter is
  - * ignored.  If false, then the timeout
  - * parameter is used to control uploads.
  - */
  -private boolean disableUploadTimeout = false;
   
   /**
* The string manager for this package.
  @@ -305,6 +298,21 @@
   
   
   /**
  + * Flag to disable setting a seperate time-out for uploads.
  + * If true, then the timeout parameter is
  + * ignored.  If false, then the timeout
  + * parameter is used to control uploads.
  + */
  +private boolean disableUploadTimeout = false;
  +
  +
  +/**
  + * Compression value.
  + */
  +private String compression = "off";
  +
  +
  +/**
* Coyote Protocol handler class name.
* Defaults to the Coyote HTTP/1.1 protocolHandler.
*/
  @@ -478,6 +486,29 @@
   
   
   /**
  + * Get the value of compression.
  + */
  +public String getCompression() {
  +
  +return (compression);
  +
  +}
  +
  +
  +/**
  + * Set the value of compression.
  + * 
  + * @param compression The new compression value, which can be "on", "off"
  + * or "force"
  + */
  +public void setCompression(String compression) {
  +
  +this.compression = compression;
  +
  +}
  +
  +
  +/**
* Return the current number of processors that have been created.
*/
   public int getCurProcessors() {
  @@ -990,6 +1021,8 @@
  "" + connectionTimeout);
   IntrospectionUtils.setProperty(protocolHandler, "disableUploadTimeout", 
  "" + disableUploadTimeout);
  +IntrospectionUtils.setProperty(protocolHandler, "compression", 
  +   compression);
   if (address != null) {
   IntrospectionUtils.setProperty(protocolHandler, "address", 
  address);
  
  
  
  1.6   +35 -4 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteConnector.java
  
  Index: CoyoteConnector.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteConnector.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- CoyoteConnector.java  27 Nov 2002 20:14:43 -  1.5
  +++ CoyoteConnector.java  18 Dec 2002 18:11:10 -  1.6
  @@ -155,6 +155,12 @@
   
   
   /**
  + * Compression value.
  + */
  +private String compression = "off";
  +
  +
  +/**
* The set of processors that have ever been created.
*/
   private Vector created = new Vector();
  @@ -352,6 +358,29 @@
   
   
   /**
  + * Get the value of compression.
  + */
  +public String getCompression() {
  +
  +return (compression);
  +
  +}
  +
  +
  +/**
  + * Set the value of compression.
  + * 
  + * @param compression The new compression value, which can be "on", "off"
  + * or "force"
  + */
  +public void setCompression(String compression) {
  +
  +this.compression = compression;
  +
  +}
  +
  +
  +/**
* Return the connection timeout for this Connector.
*/
   public int getConnectionTimeout() {
  @@ -964,6 +993,8 @@
  "" + connectionTimeout);
   IntrospectionUtils.setProperty(protocolHandler, "disableUploadTimeout", 
  "" + disableUploadTimeout);
  +IntrospectionUtils.setProperty(protocolHandler, "compression", 
  +   compression);
   if (address != null) {
   IntrospectionUtils.setProperty(protocolHandler, "address", 
  address);
  
  
  

--
To unsubscribe, e-mai

DO NOT REPLY [Bug 15397] - class loader problem with javamail and tomcat 4.1.12

[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=15397

class loader problem with javamail and tomcat 4.1.12





--- Additional Comments From [EMAIL PROTECTED]  2002-12-18 18:29 ---
The problem appears to be gone in the 4.1.17 release.

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

cvs commit: jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext .nbattrs BodyTag.java IterationTag.java JspFragment.java SimpleTag.java Tag.java TagData.java TagLibraryValidator.java TagVariableInfo.java VariableInfo.java

[kinman]

kinman  2002/12/18 10:35:38

  Modified:jsr152/src/share/javax/servlet/jsp JspContext.java
PageContext.java
   jsr152/src/share/javax/servlet/jsp/el Expression.java
ExpressionEvaluator.java VariableResolver.java
   jsr152/src/share/javax/servlet/jsp/tagext .nbattrs
BodyTag.java IterationTag.java JspFragment.java
SimpleTag.java Tag.java TagData.java
TagLibraryValidator.java TagVariableInfo.java
VariableInfo.java
  Log:
  - Patch by Mark Roth
  
  Attached are a set of API patches leading up to PFD2 of the
  specification.  Look for a corresponding patch to jakarta-tomcat-jasper
  to bring it up to date with these APIs.
  
  Also note the attached replacement for TagProtocol.gif.
  
  jsr152/src/share/javax/servlet/jsp/tagext/doc-files/TagProtocol.gif
   - Updated diagram to remove arrow from released state to all
 properties initialized state.
   - Moved label [3] to another arrow.
  
  jsr152/src/share/javax/servlet/jsp/tagext/Tag.java
   - Removed state transition [3] from class javadocs.
   - Added a new [3] label clarifying details about what may be called
 on tag reuse.
  
  jsr152/src/share/javax/servlet/jsp/tagext/TagData.java
   - Updated description for getAttribute() to clarify
 REQUEST_TIME_VALUE is returned for any dynamic attribute set
 via .
  
  jsr152/src/share/javax/servlet/jsp/tagext/JspFragment.java
   - "for example" --> "in other words"
  
  jsr152/src/share/javax/servlet/jsp/tagext/VariableInfo.java
   - Fixed incorrect class comment about variable scope.
   - Removed old comment about JLS verbiage.
   - Improved description of why 'boxed' types are necessary.
  
  jsr152/src/share/javax/servlet/jsp/tagext/TagVariableInfo.java
   - Fixed erroneous comment about only being available in JSP 2.0
 format
  
  jsr152/src/share/javax/servlet/jsp/tagext/SimpleTag.java
   - Clarified SimpleTag has the equivalent power of BodyTag but with a
 much simpler lifecycle.
  
  jsr152/src/share/javax/servlet/jsp/tagext/IterationTag.java
   - Clarified description for return value of SKIP_BODY from
 doAfterBody()
  
  jsr152/src/share/javax/servlet/jsp/PageContext.java
   - Fixed class description as some elements were moved to JspContext.
  
  jsr152/src/share/javax/servlet/jsp/JspContext.java
   - Fixed class description as some elements were moved from
 PageContext.
   - Removed constants PAGE_SCOPE, REQUEST_SCOPE, SESSION_SCOPE and
 APPLICATION_SCOPE as these are duplicated in PageContext.
  
  jsr152/src/share/javax/servlet/jsp/tagext/BodyTag.java
   - Clarified that in a classic tag invocation with an empty body
 (e.g. ), the body methods are not to be called by the
 container.
  
  jsr152/src/share/javax/servlet/jsp/tagext/TagLibraryValidator.java
   - A validator operates on the XML view associated with the JSP page,
 not the "XML document".
  
  jsr152/src/share/javax/servlet/jsp/el/VariableResolver.java
   - Removed pContext parameter from resolveVariable()
  
  jsr152/src/share/javax/servlet/jsp/el/ExpressionEvaluator.java
   - Changed from an interface to an abstract class.
  
  jsr152/src/share/javax/servlet/jsp/el/Expression.java
   - Changed from an interface to an abstract class.
  
  Revision  ChangesPath
  1.6   +17 -32
jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/JspContext.java
  
  Index: JspContext.java
  ===
  RCS file: 
/home/cvs/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/JspContext.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- JspContext.java   8 Nov 2002 21:30:21 -   1.5
  +++ JspContext.java   18 Dec 2002 18:35:37 -  1.6
  @@ -84,45 +84,30 @@
*
* Methods Intended for JSP authors
* 
  + * Some methods provide uniform access to the diverse objects
  + * representing scopes.
  + * The implementation must use the underlying machinery
  + * corresponding to that scope, so information can be passed back and
  + * forth between the underlying environment (e.g. Servlets) and JSP pages.
  + * The methods are:
  + * setAttribute(),  getAttribute(),
  + * findAttribute(),  removeAttribute(),
  + * getAttributesScope() and 
  + * getAttributeNamesInScope().
  + * 
  + * 
* The following methods provide convenient access to implicit objects:
  - * 
* getOut()
*
  + * 
  + * The following methods provide programmatic access to the 
  + * Expression Language evaluator:
  + * getExpressionEvaluator(), getVariableResolver()
  + *
* @since 2.0
*/
   
   public abstract class JspContext {
  -
  -/**
  - * Page scope: (this is the default) the named referenc

cvs commit: jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/doc-files TagProtocol.gif

[kinman]

kinman  2002/12/18 10:40:41

  Modified:jsr152/src/share/javax/servlet/jsp/tagext/doc-files
TagProtocol.gif
  Log:
  - Patch by Mark Roth
  
  Revision  ChangesPath
  1.2   +19 -18
jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/doc-files/TagProtocol.gif
  
<>
  
  

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

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime ExpressionEvaluatorImpl.java JspContextWrapper.java PageContextImpl.java

[kinman]

kinman  2002/12/18 10:46:59

  Modified:jasper2/src/share/org/apache/jasper/runtime
ExpressionEvaluatorImpl.java JspContextWrapper.java
PageContextImpl.java
  Log:
  - Patch by Mark Roth
  
  Attached is a patch to bring Japser2 up to date with the latest APIs
  from the JSR-152 Expert Group.
  
  jasper2/src/share/org/apache/jasper/runtime/JspContextWrapper.java
   - Updated to conform to new VariableResolver API
  
  jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java
   - Updated to conform to new VariableResolver API
  
  jasper2/src/share/org/apache/jasper/runtime/ExpressionEvaluatorImpl.java
   - Updated to conform to new VariableResolver API
   - Updated to conform to new ExpressionEvaluator API (which is now an
 abstract class instead of an interface)
   - Updated to conform to new Exrpression API (which is now an
 abstract class instead of an interface)
  
  Revision  ChangesPath
  1.6   +3 -3  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/ExpressionEvaluatorImpl.java
  
  Index: ExpressionEvaluatorImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/ExpressionEvaluatorImpl.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- ExpressionEvaluatorImpl.java  29 Aug 2002 02:04:21 -  1.5
  +++ ExpressionEvaluatorImpl.java  18 Dec 2002 18:46:59 -  1.6
  @@ -74,7 +74,7 @@
*/
   
   public class ExpressionEvaluatorImpl 
  -implements ExpressionEvaluator
  +extends ExpressionEvaluator
   {
   private PageContextImpl pageContext;
   
  @@ -153,7 +153,7 @@
   // pContext parameter is going away in JSP 2.0
   Object result;
   try {
  -result = delegate.resolveVariable( pName, null );
  +result = delegate.resolveVariable( pName );
   }
   catch( ELException e ) {
   throw new org.apache.jasper.runtime.el.jstl.ELException( 
  @@ -255,7 +255,7 @@
* can be moved out of JSTL into its own project.
*/
   private class JSTLExpression 
  -implements Expression
  +extends Expression
   {
   private String expression;
   private Class expectedType;
  
  
  
  1.10  +6 -8  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspContextWrapper.java
  
  Index: JspContextWrapper.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspContextWrapper.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- JspContextWrapper.java3 Dec 2002 23:17:48 -   1.9
  +++ JspContextWrapper.java18 Dec 2002 18:46:59 -  1.10
  @@ -303,16 +303,14 @@
   /**
* VariableResolver interface
*/
  -public Object resolveVariable( String pName, Object pContext )
  +public Object resolveVariable( String pName )
   throws ELException
   {
if (invokingJspCtxt instanceof PageContextImpl) {
  - return ((PageContextImpl) invokingJspCtxt).resolveVariable(pName,
  -pContext);
  + return ((PageContextImpl) invokingJspCtxt).resolveVariable(pName);
}
   
  - return ((JspContextWrapper) invokingJspCtxt).resolveVariable(pName,
  -  pContext);
  + return ((JspContextWrapper) invokingJspCtxt).resolveVariable(pName);
   }
   
   /**
  
  
  
  1.38  +6 -7  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java
  
  Index: PageContextImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java,v
  retrieving revision 1.37
  retrieving revision 1.38
  diff -u -r1.37 -r1.38
  --- PageContextImpl.java  3 Dec 2002 01:58:36 -   1.37
  +++ PageContextImpl.java  18 Dec 2002 18:46:59 -  1.38
  @@ -640,13 +640,12 @@
   /**
* VariableResolver interface
*/
  -public Object resolveVariable( String pName, Object pContext )
  +public Object resolveVariable( String pName )
   throws ELException
   {
  -// Note: pContext will be going away.
   try {
  -return PageContextImpl.variableResolver.resolveVariable(
  -pName, this );
  +return PageContextImpl.variableResolver.resolveVariable( pName, 
  +this );
   }
   catch( org.apache.jasper.runtime.el.jstl.ELException e ) {

cvs commit: jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext .nbattrs

[kinman]

kinman  2002/12/18 10:54:54

  Removed: jsr152/src/share/javax/servlet/jsp/tagext .nbattrs
  Log:
  - Remove Betbean file that got included inadvently.

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

DO NOT REPLY [Bug 15496] New: - Tag Libs

[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=15496

Tag Libs

   Summary: Tag Libs
   Product: Tomcat 4
   Version: 4.1.12
  Platform: Other
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I am using the Jakarta taglibs in my app.  When using the DBTags tag library 
and the resultset returns no rows, the sql query is printed on the jsp page.  
This does not happen in Tomcat 4.0.  I could not find a way to stop the query 
from being displayed on the jsp.  Oracle 817 is the backend database.

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

DO NOT REPLY [Bug 15497] New: - deadlock in threadpool

[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=15497

deadlock in threadpool

   Summary: deadlock in threadpool
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I think I have found a possible deadlock in Tomcat 4.1.12 and 4.1.14 using JDk 
1.4.1
Here is the thread dump of the vm:

"Thread-15" daemon prio=5 tid=0x0AE6E520 nid=0x10c0 in Object.wait() 
[c71f000..c71fd88]
at java.lang.Object.wait(Native Method)
- waiting on <05289758> (a 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Object.wait(Object.java:426)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:512)
- locked <05289758> (a 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Thread.run(Thread.java:536)

"Thread-14" daemon prio=5 tid=0x0AE72D90 nid=0x9f0 in Object.wait() 
[c6df000..c6dfd88]
at java.lang.Object.wait(Native Method)
- waiting on <052897C0> (a 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Object.wait(Object.java:426)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:512)
- locked <052897C0> (a 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Thread.run(Thread.java:536)




"Thread-9" daemon prio=5 tid=0x0AEE38E8 nid=0x1134 in Object.wait() 
[c55f000..c55fd88]
at java.lang.Object.wait(Native Method)
- waiting on <039BF8B8> (a 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Object.wait(Object.java:426)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:512)
- locked <039BF8B8> (a 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Thread.run(Thread.java:536)

"MonitorRunnable" daemon prio=5 tid=0x0B694950 nid=0xca8 in Object.wait() 
[c4df000..c4dfd88]
at java.lang.Object.wait(Native Method)
- waiting on <037A6708> (a 
org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable)
at org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run
(ThreadPool.java:423)
- locked <037A6708> (a 
org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable)
at java.lang.Thread.run(Thread.java:536)

"Thread-6" daemon prio=5 tid=0x0B693DC0 nid=0x908 in Object.wait() 
[c49f000..c49fd88]
at java.lang.Object.wait(Native Method)
- waiting on <037B2880> (a 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Object.wait(Object.java:426)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:512)
- locked <037B2880> (a 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Thread.run(Thread.java:536)

"Thread-5" daemon prio=5 tid=0x0B6933D0 nid=0xe4c in Object.wait() 
[c45f000..c45fd88]
at java.lang.Object.wait(Native Method)
- waiting on <037B28E8> (a 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Object.wait(Object.java:426)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:512)
- locked <037B28E8> (a 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Thread.run(Thread.java:536)


"HostConfig[localhost]" daemon prio=5 tid=0x0B6923E8 nid=0x1044 waiting on 
condition [c39f000..c39fd88]
at java.lang.Thread.sleep(Native Method)
at org.apache.catalina.startup.HostConfig.threadSleep
(HostConfig.java:985)
at org.apache.catalina.startup.HostConfig.run(HostConfig.java:1009)
at java.lang.Thread.run(Thread.java:536)

"StandardManager[/webdav]" daemon prio=5 tid=0x0AE40E98 nid=0x9d4 waiting on 
condition [c35f000..c35fd88]
at java.lang.Thread.sleep(Native Method)
at org.apache.catalina.session.StandardManager.threadSleep
(StandardManager.java:780)
at org.apache.catalina.session.StandardManager.run
(StandardManager.java:839)
at java.lang.Thread.run(Thread.java:536)

"StandardManager[]" daemon prio=5 tid=0x0AE40200 nid=0x112c waiting on 
condition [c2df000..c2dfd88]
at java.lang.Thread.sleep(Native Method)
at org.apache.catalina.session.StandardManager.threadSleep
(StandardManager.java:780)
at org.apache.catalina.session.StandardManager.run
(StandardManager.java:839)
at java.lang.Thread.run(Thread.java:536)

"Thre

DO NOT REPLY [Bug 15474] - tomcatAuthentication ignored for Coyote JK 2 connector

[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=15474

tomcatAuthentication ignored for Coyote JK 2 connector





--- Additional Comments From [EMAIL PROTECTED]  2002-12-18 19:34 ---
Note that this issue makes Tomcat 4.1.17 completely unusable for us.

Also note that this issue has occured at least once before in the 4.1.x build
stream.  Is there a way this can be part of a release test suite?

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

DO NOT REPLY [Bug 15474] - tomcatAuthentication ignored for Coyote JK 2 connector

[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=15474

tomcatAuthentication ignored for Coyote JK 2 connector





--- Additional Comments From [EMAIL PROTECTED]  2002-12-18 19:40 ---
One further note:

The Coyote JK 2 documentation in Tomcat 4.1.17 does not seem to clearly note the
existence/applicability of the tomcatAuthentication attribute on this connector.
 This attribute is critical, however.  Is this lack of sufficiently
obvious/explicit documentation contributing to this piece of functionality being
rebroken?

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

[PROPOSAL] EL Transition to Jakarta Commons

[Jan Luehe]

I'd like to resume discussion on a proposal circulated by James
Strachan on March 13, 2002, about turning the implementation of JSTL's
expression language (EL) into a reusable component and moving it from
the Standard Taglib, an implementation of JSTL hosted by
jakarta-taglibs, to jakarta-commons, in order to make it available to
a larger number of projects.

James' original proposal received some positive feedback from the
taglibs-dev community. Below is a draft proposal for a formal
submission to jakarta-commons, following the format of the
jakarta-commons charter at http://jakarta.apache.org/commons/charter.html.

(0) Rationale

The JSP Standard Tag Library (JSTL), version 1.0, introduced the
concept of an Expression Language (EL), whose main goal is to provide
page authors with an easy way to access and manipulate application
data without requiring the use of scriptlets

JSP 2.0 adopted the EL specification from JSTL, and expanded its
scope: EL expressions are no longer limited to JSTL action attributes,
but may be used in any standard or custom action attribute declared to
accept a runtime expression. In addition, EL expressions may now also
be used directly in template text outside of any actions. JSP 2.0 also
added an important feature to the EL specification: EL functions,
which allow page authors to invoke static methods in Java classes from
EL expressions. Additionally, JSP 2.0 allows programmatic access and
customization of the EL evaluator through a set of standard interfaces
and abstract classes.

Currently, there are a number of projects (including Tomcat 5 and Java
Server Faces) that leverage the EL implementation of the Standard
Taglib. In addition, there seems to be interest in leveraging the EL
in the context of scripting workflow activities using custom tag
libraries.

In order to make the EL implementation available to Tomcat 5, the
Tomcat team defined a new "ant" target for the Standard Taglib that
builds just the EL portion and packages it in a JAR file
("jsp20el.jar") which is stored in Tomcat's common/lib directory. This
approach has always been considered an interim solution only, until
the EL implementation would move from the Standard Taglib to a more
visible location such as jakarta-commons.

(1) Scope of the package

The package shall provide an implementation of the Expression Language
specification which is part of the JSP 2.0 standard.

(1.5) Interaction with other packages

The package shall provide an implementation of the standard interfaces
and abstract classes of the javax.servlet.jsp.el package, which is
defined in the JSP 2.0 specification.

(2) Identify the initial source for the package

The initial codebase will be taken from the Standard Taglib project
hosted at jakarta-taglibs. The source of the Standard Taglib is
available as part of the jakarta-taglibs nightly source distribution
at http://jakarta.apache.org/builds/jakarta-taglibs/nightly/src/

(2.1) Identify the base name for the package

The base name of the package shall be org.apache.commons.el

(2.2) Identify the coding conventions for this package

The package follows Sun's Java coding conventions (see
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html).

(3) Identify any Jakarta-Commons resources to be created

(3.1) Mailing list

The package shall use the jakarta-commons mailing list.

(3.2) CVS repositories

The package shall use a root branch of the jakarta-commons CVS.

(3.3) Bugzilla

The package shall be listed as the "EL" component under the "Commons"
project in Bugzilla.

(3.4) Jyve FAQ (when available)

n/a

(4) Identify the initial set of committers to be listed in the Status File.

The initial set of committers will be identical to the set of
committers of the Standard Taglib project.


Thoughts?

Jan


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

Re: [PROPOSAL] EL Transition to Jakarta Commons

[Craig R. McClanahan]

+1, but you'll probably also want to post this on COMMONS-DEV :-).

Craig

On Wed, 18 Dec 2002, Jan Luehe wrote:

> Date: Wed, 18 Dec 2002 09:48:34 -0800 (PST)
> From: Jan Luehe <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>,
>  Jan Luehe <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: [PROPOSAL] EL Transition to Jakarta Commons
>
> I'd like to resume discussion on a proposal circulated by James
> Strachan on March 13, 2002, about turning the implementation of JSTL's
> expression language (EL) into a reusable component and moving it from
> the Standard Taglib, an implementation of JSTL hosted by
> jakarta-taglibs, to jakarta-commons, in order to make it available to
> a larger number of projects.
>
> James' original proposal received some positive feedback from the
> taglibs-dev community. Below is a draft proposal for a formal
> submission to jakarta-commons, following the format of the
> jakarta-commons charter at http://jakarta.apache.org/commons/charter.html.
>
> (0) Rationale
>
> The JSP Standard Tag Library (JSTL), version 1.0, introduced the
> concept of an Expression Language (EL), whose main goal is to provide
> page authors with an easy way to access and manipulate application
> data without requiring the use of scriptlets
>
> JSP 2.0 adopted the EL specification from JSTL, and expanded its
> scope: EL expressions are no longer limited to JSTL action attributes,
> but may be used in any standard or custom action attribute declared to
> accept a runtime expression. In addition, EL expressions may now also
> be used directly in template text outside of any actions. JSP 2.0 also
> added an important feature to the EL specification: EL functions,
> which allow page authors to invoke static methods in Java classes from
> EL expressions. Additionally, JSP 2.0 allows programmatic access and
> customization of the EL evaluator through a set of standard interfaces
> and abstract classes.
>
> Currently, there are a number of projects (including Tomcat 5 and Java
> Server Faces) that leverage the EL implementation of the Standard
> Taglib. In addition, there seems to be interest in leveraging the EL
> in the context of scripting workflow activities using custom tag
> libraries.
>
> In order to make the EL implementation available to Tomcat 5, the
> Tomcat team defined a new "ant" target for the Standard Taglib that
> builds just the EL portion and packages it in a JAR file
> ("jsp20el.jar") which is stored in Tomcat's common/lib directory. This
> approach has always been considered an interim solution only, until
> the EL implementation would move from the Standard Taglib to a more
> visible location such as jakarta-commons.
>
> (1) Scope of the package
>
> The package shall provide an implementation of the Expression Language
> specification which is part of the JSP 2.0 standard.
>
> (1.5) Interaction with other packages
>
> The package shall provide an implementation of the standard interfaces
> and abstract classes of the javax.servlet.jsp.el package, which is
> defined in the JSP 2.0 specification.
>
> (2) Identify the initial source for the package
>
> The initial codebase will be taken from the Standard Taglib project
> hosted at jakarta-taglibs. The source of the Standard Taglib is
> available as part of the jakarta-taglibs nightly source distribution
> at http://jakarta.apache.org/builds/jakarta-taglibs/nightly/src/
>
> (2.1) Identify the base name for the package
>
> The base name of the package shall be org.apache.commons.el
>
> (2.2) Identify the coding conventions for this package
>
> The package follows Sun's Java coding conventions (see
> http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html).
>
> (3) Identify any Jakarta-Commons resources to be created
>
> (3.1) Mailing list
>
> The package shall use the jakarta-commons mailing list.
>
> (3.2) CVS repositories
>
> The package shall use a root branch of the jakarta-commons CVS.
>
> (3.3) Bugzilla
>
> The package shall be listed as the "EL" component under the "Commons"
> project in Bugzilla.
>
> (3.4) Jyve FAQ (when available)
>
> n/a
>
> (4) Identify the initial set of committers to be listed in the Status File.
>
> The initial set of committers will be identical to the set of
> committers of the Standard Taglib project.
>
>
> Thoughts?
>
> Jan
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


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

Re: [PROPOSAL] EL Transition to Jakarta Commons

[Jan Luehe]

Craig,

> +1, but you'll probably also want to post this on COMMONS-DEV :-).

My plan was to post this to tomcat-dev and taglibs-dev first,
get feedback, and then post it to commons-dev, but I guess it is
OK to get commons-dev involved right away.

I just posted the proposal there, too.

Thanks,


Jan


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

Re: [PROPOSAL] EL Transition to Jakarta Commons

[Pierre Delisle]

+1

-- Pierre

Jan Luehe wrote:
> 
> I'd like to resume discussion on a proposal circulated by James
> Strachan on March 13, 2002, about turning the implementation of JSTL's
> expression language (EL) into a reusable component and moving it from
> the Standard Taglib, an implementation of JSTL hosted by
> jakarta-taglibs, to jakarta-commons, in order to make it available to
> a larger number of projects.
> 
> James' original proposal received some positive feedback from the
> taglibs-dev community. Below is a draft proposal for a formal
> submission to jakarta-commons, following the format of the
> jakarta-commons charter at http://jakarta.apache.org/commons/charter.html.
> 
> (0) Rationale
> 
> The JSP Standard Tag Library (JSTL), version 1.0, introduced the
> concept of an Expression Language (EL), whose main goal is to provide
> page authors with an easy way to access and manipulate application
> data without requiring the use of scriptlets
> 
> JSP 2.0 adopted the EL specification from JSTL, and expanded its
> scope: EL expressions are no longer limited to JSTL action attributes,
> but may be used in any standard or custom action attribute declared to
> accept a runtime expression. In addition, EL expressions may now also
> be used directly in template text outside of any actions. JSP 2.0 also
> added an important feature to the EL specification: EL functions,
> which allow page authors to invoke static methods in Java classes from
> EL expressions. Additionally, JSP 2.0 allows programmatic access and
> customization of the EL evaluator through a set of standard interfaces
> and abstract classes.
> 
> Currently, there are a number of projects (including Tomcat 5 and Java
> Server Faces) that leverage the EL implementation of the Standard
> Taglib. In addition, there seems to be interest in leveraging the EL
> in the context of scripting workflow activities using custom tag
> libraries.
> 
> In order to make the EL implementation available to Tomcat 5, the
> Tomcat team defined a new "ant" target for the Standard Taglib that
> builds just the EL portion and packages it in a JAR file
> ("jsp20el.jar") which is stored in Tomcat's common/lib directory. This
> approach has always been considered an interim solution only, until
> the EL implementation would move from the Standard Taglib to a more
> visible location such as jakarta-commons.
> 
> (1) Scope of the package
> 
> The package shall provide an implementation of the Expression Language
> specification which is part of the JSP 2.0 standard.
> 
> (1.5) Interaction with other packages
> 
> The package shall provide an implementation of the standard interfaces
> and abstract classes of the javax.servlet.jsp.el package, which is
> defined in the JSP 2.0 specification.
> 
> (2) Identify the initial source for the package
> 
> The initial codebase will be taken from the Standard Taglib project
> hosted at jakarta-taglibs. The source of the Standard Taglib is
> available as part of the jakarta-taglibs nightly source distribution
> at http://jakarta.apache.org/builds/jakarta-taglibs/nightly/src/
> 
> (2.1) Identify the base name for the package
> 
> The base name of the package shall be org.apache.commons.el
> 
> (2.2) Identify the coding conventions for this package
> 
> The package follows Sun's Java coding conventions (see
> http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html).
> 
> (3) Identify any Jakarta-Commons resources to be created
> 
> (3.1) Mailing list
> 
> The package shall use the jakarta-commons mailing list.
> 
> (3.2) CVS repositories
> 
> The package shall use a root branch of the jakarta-commons CVS.
> 
> (3.3) Bugzilla
> 
> The package shall be listed as the "EL" component under the "Commons"
> project in Bugzilla.
> 
> (3.4) Jyve FAQ (when available)
> 
> n/a
> 
> (4) Identify the initial set of committers to be listed in the Status File.
> 
> The initial set of committers will be identical to the set of
> committers of the Standard Taglib project.
> 
> Thoughts?
> 
> Jan
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 


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

Re: [PROPOSAL] EL Transition to Jakarta Commons

[Henri Yandell]

With the String Taglib hat on, +1. Would be nice to have a smaller jar to
link to. [Though I see it can kinda be done now].

With a Commons hat on, +0. Sounds useful, but want to make sure the
Standard Taglib developers still monitor it and that it doesn't get
abandoned. With Standard driving it, there seems less chance of this than
with other projects.

Hen

On Wed, 18 Dec 2002, Pierre Delisle wrote:

> +1
>
> -- Pierre
>
> Jan Luehe wrote:
> >
> > I'd like to resume discussion on a proposal circulated by James
> > Strachan on March 13, 2002, about turning the implementation of JSTL's
> > expression language (EL) into a reusable component and moving it from
> > the Standard Taglib, an implementation of JSTL hosted by
> > jakarta-taglibs, to jakarta-commons, in order to make it available to
> > a larger number of projects.
> >
> > James' original proposal received some positive feedback from the
> > taglibs-dev community. Below is a draft proposal for a formal
> > submission to jakarta-commons, following the format of the
> > jakarta-commons charter at http://jakarta.apache.org/commons/charter.html.
> >
> > (0) Rationale
> >
> > The JSP Standard Tag Library (JSTL), version 1.0, introduced the
> > concept of an Expression Language (EL), whose main goal is to provide
> > page authors with an easy way to access and manipulate application
> > data without requiring the use of scriptlets
> >
> > JSP 2.0 adopted the EL specification from JSTL, and expanded its
> > scope: EL expressions are no longer limited to JSTL action attributes,
> > but may be used in any standard or custom action attribute declared to
> > accept a runtime expression. In addition, EL expressions may now also
> > be used directly in template text outside of any actions. JSP 2.0 also
> > added an important feature to the EL specification: EL functions,
> > which allow page authors to invoke static methods in Java classes from
> > EL expressions. Additionally, JSP 2.0 allows programmatic access and
> > customization of the EL evaluator through a set of standard interfaces
> > and abstract classes.
> >
> > Currently, there are a number of projects (including Tomcat 5 and Java
> > Server Faces) that leverage the EL implementation of the Standard
> > Taglib. In addition, there seems to be interest in leveraging the EL
> > in the context of scripting workflow activities using custom tag
> > libraries.
> >
> > In order to make the EL implementation available to Tomcat 5, the
> > Tomcat team defined a new "ant" target for the Standard Taglib that
> > builds just the EL portion and packages it in a JAR file
> > ("jsp20el.jar") which is stored in Tomcat's common/lib directory. This
> > approach has always been considered an interim solution only, until
> > the EL implementation would move from the Standard Taglib to a more
> > visible location such as jakarta-commons.
> >
> > (1) Scope of the package
> >
> > The package shall provide an implementation of the Expression Language
> > specification which is part of the JSP 2.0 standard.
> >
> > (1.5) Interaction with other packages
> >
> > The package shall provide an implementation of the standard interfaces
> > and abstract classes of the javax.servlet.jsp.el package, which is
> > defined in the JSP 2.0 specification.
> >
> > (2) Identify the initial source for the package
> >
> > The initial codebase will be taken from the Standard Taglib project
> > hosted at jakarta-taglibs. The source of the Standard Taglib is
> > available as part of the jakarta-taglibs nightly source distribution
> > at http://jakarta.apache.org/builds/jakarta-taglibs/nightly/src/
> >
> > (2.1) Identify the base name for the package
> >
> > The base name of the package shall be org.apache.commons.el
> >
> > (2.2) Identify the coding conventions for this package
> >
> > The package follows Sun's Java coding conventions (see
> > http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html).
> >
> > (3) Identify any Jakarta-Commons resources to be created
> >
> > (3.1) Mailing list
> >
> > The package shall use the jakarta-commons mailing list.
> >
> > (3.2) CVS repositories
> >
> > The package shall use a root branch of the jakarta-commons CVS.
> >
> > (3.3) Bugzilla
> >
> > The package shall be listed as the "EL" component under the "Commons"
> > project in Bugzilla.
> >
> > (3.4) Jyve FAQ (when available)
> >
> > n/a
> >
> > (4) Identify the initial set of committers to be listed in the Status File.
> >
> > The initial set of committers will be identical to the set of
> > committers of the Standard Taglib project.
> >
> > Thoughts?
> >
> > Jan
> >
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


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

Re: [PROPOSAL] EL Transition to Jakarta Commons

[Jeanfrancois Arcand]

+1

-- Jeanfrancois

Jan Luehe wrote:


I'd like to resume discussion on a proposal circulated by James
Strachan on March 13, 2002, about turning the implementation of JSTL's
expression language (EL) into a reusable component and moving it from
the Standard Taglib, an implementation of JSTL hosted by
jakarta-taglibs, to jakarta-commons, in order to make it available to
a larger number of projects.

James' original proposal received some positive feedback from the
taglibs-dev community. Below is a draft proposal for a formal
submission to jakarta-commons, following the format of the
jakarta-commons charter at http://jakarta.apache.org/commons/charter.html.

(0) Rationale

The JSP Standard Tag Library (JSTL), version 1.0, introduced the
concept of an Expression Language (EL), whose main goal is to provide
page authors with an easy way to access and manipulate application
data without requiring the use of scriptlets

JSP 2.0 adopted the EL specification from JSTL, and expanded its
scope: EL expressions are no longer limited to JSTL action attributes,
but may be used in any standard or custom action attribute declared to
accept a runtime expression. In addition, EL expressions may now also
be used directly in template text outside of any actions. JSP 2.0 also
added an important feature to the EL specification: EL functions,
which allow page authors to invoke static methods in Java classes from
EL expressions. Additionally, JSP 2.0 allows programmatic access and
customization of the EL evaluator through a set of standard interfaces
and abstract classes.

Currently, there are a number of projects (including Tomcat 5 and Java
Server Faces) that leverage the EL implementation of the Standard
Taglib. In addition, there seems to be interest in leveraging the EL
in the context of scripting workflow activities using custom tag
libraries.

In order to make the EL implementation available to Tomcat 5, the
Tomcat team defined a new "ant" target for the Standard Taglib that
builds just the EL portion and packages it in a JAR file
("jsp20el.jar") which is stored in Tomcat's common/lib directory. This
approach has always been considered an interim solution only, until
the EL implementation would move from the Standard Taglib to a more
visible location such as jakarta-commons.

(1) Scope of the package

The package shall provide an implementation of the Expression Language
specification which is part of the JSP 2.0 standard.

(1.5) Interaction with other packages

The package shall provide an implementation of the standard interfaces
and abstract classes of the javax.servlet.jsp.el package, which is
defined in the JSP 2.0 specification.

(2) Identify the initial source for the package

The initial codebase will be taken from the Standard Taglib project
hosted at jakarta-taglibs. The source of the Standard Taglib is
available as part of the jakarta-taglibs nightly source distribution
at http://jakarta.apache.org/builds/jakarta-taglibs/nightly/src/

(2.1) Identify the base name for the package

The base name of the package shall be org.apache.commons.el

(2.2) Identify the coding conventions for this package

The package follows Sun's Java coding conventions (see
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html).

(3) Identify any Jakarta-Commons resources to be created

(3.1) Mailing list

The package shall use the jakarta-commons mailing list.

(3.2) CVS repositories

The package shall use a root branch of the jakarta-commons CVS.

(3.3) Bugzilla

The package shall be listed as the "EL" component under the "Commons"
project in Bugzilla.

(3.4) Jyve FAQ (when available)

n/a

(4) Identify the initial set of committers to be listed in the Status File.

The initial set of committers will be identical to the set of
committers of the Standard Taglib project.


Thoughts?

Jan


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


 



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

cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/filters GzipOutputFilter.java

[remm]

remm2002/12/18 12:36:58

  Modified:http11/src/java/org/apache/coyote/http11 Constants.java
Http11Processor.java Http11Protocol.java
  Added:   http11/src/java/org/apache/coyote/http11/filters
GzipOutputFilter.java
  Log:
  - Add support for gzip content encoding.
  - I believe some broken user agents must be excluded.
  
  Revision  ChangesPath
  1.13  +6 -0  
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Constants.java
  
  Index: Constants.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Constants.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- Constants.java24 Nov 2002 22:00:04 -  1.12
  +++ Constants.java18 Dec 2002 20:36:58 -  1.13
  @@ -199,6 +199,12 @@
   
   
   /**
  + * GZIP filters (input and output).
  + */
  +public static final int GZIP_FILTER = 3;
  +
  +
  +/**
* HTTP/1.0.
*/
   public static final String HTTP_10 = "HTTP/1.0";
  
  
  
  1.48  +86 -0 
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
  
  Index: Http11Processor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
  retrieving revision 1.47
  retrieving revision 1.48
  diff -u -r1.47 -r1.48
  --- Http11Processor.java  28 Nov 2002 15:15:02 -  1.47
  +++ Http11Processor.java  18 Dec 2002 20:36:58 -  1.48
  @@ -86,6 +86,8 @@
   
   import org.apache.coyote.http11.filters.ChunkedInputFilter;
   import org.apache.coyote.http11.filters.ChunkedOutputFilter;
  +//import org.apache.coyote.http11.filters.GzipInputFilter;
  +import org.apache.coyote.http11.filters.GzipOutputFilter;
   import org.apache.coyote.http11.filters.IdentityInputFilter;
   import org.apache.coyote.http11.filters.IdentityOutputFilter;
   import org.apache.coyote.http11.filters.VoidInputFilter;
  @@ -223,32 +225,76 @@
*/
   protected Socket socket;
   
  +
   /**
* Remote Address associated with the current connection.
*/
   protected String remoteAddr = null;
   
  +
   /**
* Remote Host associated with the current connection.
*/
   protected String remoteHost = null;
   
  +
   /**
* Maximum timeout on uploads.
*/
   protected int timeout = 30;   // 5 minutes as in Apache HTTPD server
   
  +
   /**
* Flag to disable setting a different time-out on uploads.
*/
   protected boolean disableUploadTimeout = false;
   
  +
  +/**
  + * Allowed compression level.
  + */
  +protected int compressionLevel = 0;
  +
  +
   /**
* Host name (used to avoid useless B2C conversion on the host name).
*/
   protected char[] hostNameC = new char[0];
   
   
  +// - Properties
  +
  +
  +/**
  + * Return compression level.
  + */
  +public String getCompression() {
  +switch (compressionLevel) {
  +case 0:
  +return "off";
  +case 1:
  +return "on";
  +case 2:
  +return "force";
  +}
  +return "off";
  +}
  +
  +
  +/**
  + * Set compression level.
  + */
  +public void setCompression(String compression) {
  +if (compression.equals("on")) {
  +this.compressionLevel = 1;
  +} else if (compression.equals("force")) {
  +this.compressionLevel = 2;
  +} else {
  +this.compressionLevel = 0;
  +}
  +}
  +
  +
   // - Public Methods
   
   
  @@ -350,6 +396,7 @@
   public void setDisableUploadTimeout(boolean isDisabled) {
   disableUploadTimeout = isDisabled;
   }
  +
   /**
* Get the flag that controls upload time-outs.
*/
  @@ -363,6 +410,7 @@
   public void setTimeout( int timeouts ) {
   timeout = timeouts ;
   }
  +
   /**
* Get the upload timeout.
*/
  @@ -918,6 +966,34 @@
   contentDelimitation = true;
   }
   
  +// Check for compression
  +boolean useCompression = false;
  +if (entityBody && (compressionLevel > 0)) {
  +// Check accept-encoding
  +// FIXME: write a comma parser; also reuse 
  +// for transfer-encoding parsing
  +MessageBytes acceptEncodingMB = 
  +request.getMimeHeaders().getValue("accept-encoding");
  +if ((acceptEncodingMB != null) 
  +&& (acceptEncodingMB.indexOf("gzip") != -1)) {

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx DynamicMBeanProxy.java

[costin]

costin  2002/12/18 13:21:33

  Modified:util/java/org/apache/tomcat/util/mx DynamicMBeanProxy.java
  Log:
  Deprecate DynamicMBean, all the functionality has been
  merged in modeler.
  
  Revision  ChangesPath
  1.8   +3 -1  
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx/DynamicMBeanProxy.java
  
  Index: DynamicMBeanProxy.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx/DynamicMBeanProxy.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- DynamicMBeanProxy.java3 Oct 2002 19:34:47 -   1.7
  +++ DynamicMBeanProxy.java18 Dec 2002 21:21:33 -  1.8
  @@ -70,7 +70,9 @@
* component that follows the bean/ant/Interceptor/Valve/Jk2 patterns.
*
* The class will wrap any component conforming to those patterns.
  - * 
  + *
  + * @deprecated The same functionality ( and more ) is now available in
  + * commons-modeler
* @author Costin Manolache
*/
   public class DynamicMBeanProxy implements DynamicMBean {
  
  
  

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

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/log Log.java

[costin]

costin  2002/12/18 13:23:27

  Modified:util/java/org/apache/tomcat/util/log Log.java
  Log:
  Add deprecated comment. Commons-logging should be used
  instead. We'll need to finish converting all logs
  from both tomcat.util.log and catalina.Log
  
  Revision  ChangesPath
  1.3   +1 -0  
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/log/Log.java
  
  Index: Log.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/log/Log.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- Log.java  12 Jul 2002 17:56:23 -  1.2
  +++ Log.java  18 Dec 2002 21:23:26 -  1.3
  @@ -97,6 +97,7 @@
*  embeding application can then set up or change the logging details,
*  without any action from the log user.
*
  + * @deprecated Commons-logging should be used instead.
* @author Alex Chaffee [[EMAIL PROTECTED]]
* @author Costin Manolache
**/
  
  
  

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

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads Reaper.java

[costin]

costin  2002/12/18 14:52:13

  Modified:util/java/org/apache/tomcat/util/threads Reaper.java
  Log:
  Add getter.
  
  Revision  ChangesPath
  1.3   +7 -1  
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/Reaper.java
  
  Index: Reaper.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/Reaper.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- Reaper.java   22 Apr 2002 18:55:56 -  1.2
  +++ Reaper.java   18 Dec 2002 22:52:13 -  1.3
  @@ -98,10 +98,16 @@
   Object lock=new Object();
   static boolean running=true;
   
  +// XXX Should be called 'interval' not defaultInterval
  +
   public void setDefaultInterval( long t ) {
interval=t;
   }
  -
  +
  +public long getDefaultIntervale() {
  +return interval;
  +}
  +
   public int addCallback( ThreadPoolRunnable c, int interval ) {
synchronized( lock ) {
cbacks[count]=c;
  
  
  

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

j-t-c/util, 3.3 and logging

[Costin Manolache]

Is it ok if I change util.thread and util.net to commons-logging ?
That would mean c-l will be required for tomcat3.3, and thread
and net would use c-l instead of the Log.

It should be easy to modify the util.Log implementation in 3.3
to support commons-logging API, or implement util.Log using 
commons-logging API ( if using the old Log is needed ).

Right now a lot of j-t-c code uses c-l, and thread and net are
different.



Costin 





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

DO NOT REPLY [Bug 15508] New: - jsp pages have sometimes no 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=15508

jsp pages have sometimes no output

   Summary: jsp pages have sometimes no output
   Product: Tomcat 4
   Version: 4.1.17
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Example:  
  
<%  
System.out.println( "BEGIN" )  
%>  
This is a test  
<%  
System.out.println( out.getRemaining())  
System.out.println( "END" )  
%>  
  
In catalina.out, i always have BEGIN/buffer remaining/END, but tomcat response  
this  
 
...Sample: 
 
200 Ok 
Content-Length: 0

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

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServletWrapper.java

[luehe]

luehe   2002/12/18 15:18:21

  Modified:jasper2/src/share/org/apache/jasper
JspCompilationContext.java
   jasper2/src/share/org/apache/jasper/compiler
ImplicitTagLibraryInfo.java JspDocumentParser.java
Parser.java ParserController.java
TagFileProcessor.java TagLibraryInfoImpl.java
   jasper2/src/share/org/apache/jasper/servlet
JspServletWrapper.java
  Log:
  If a tag file is packaged in a JAR, any of its include directives must
  be resolved against the JAR as opposed to the filesystem.
  
  Revision  ChangesPath
  1.28  +24 -11
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java
  
  Index: JspCompilationContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java,v
  retrieving revision 1.27
  retrieving revision 1.28
  diff -u -r1.27 -r1.28
  --- JspCompilationContext.java8 Dec 2002 13:42:52 -   1.27
  +++ JspCompilationContext.java18 Dec 2002 23:18:20 -  1.28
  @@ -64,6 +64,7 @@
   import java.io.*;
   import java.net.*;
   import java.util.*;
  +import java.util.jar.JarFile;
   import javax.servlet.ServletContext;
   import javax.servlet.jsp.tagext.TagInfo;
   import javax.servlet.jsp.tagext.TagData;
  @@ -122,6 +123,7 @@
   private boolean isTagFile;
   private boolean protoTypeMode;
   private TagInfo tagInfo;
  +private JarFile tagFileJar;
   
   // jspURI _must_ be relative to the context
   public JspCompilationContext(String jspUri,
  @@ -162,13 +164,12 @@
ServletContext context,
 JspServletWrapper jsw,
JspRuntimeContext rctxt,
  -  Hashtable tagFileJars) {
  -
  +  JarFile tagFileJar) {
   this(tagfile, false, options, context, jsw, rctxt);
   this.isTagFile = true;
   this.tagInfo = tagInfo;
  - this.tagFileJars = tagFileJars;
  - if (tagFileJars != null && tagFileJars.get(tagfile) != null) {
  + this.tagFileJar = tagFileJar;
  + if (tagFileJar != null) {
isPackagedTagFile = true;
}
   }
  @@ -284,13 +285,25 @@
   }
   
   /**
  - * Returns the tag-file-to-JAR-file mapping for tag files packaged in JARs.
  + * Returns the tag-file-name-to-JAR-file map of this compilation unit,
  + * which maps tag file names to the JAR files in which the tag files are
  + * packaged.
*
  - * The mapping uses the tag file name as the key, and the JAR file 
  - * containing the tag file as the value. 
  + * The map is populated when parsing the tag-file elements of the TLDs
  + * of any imported taglibs. 
*/
   public Hashtable getTagFileJars() {
  - return tagFileJars;
  + return this.tagFileJars;
  +}
  +
  +/**
  + * Returns the JAR file in which the tag file for which this
  + * JspCompilationContext was created is packaged, or null if this
  + * JspCompilationContext does not correspond to a tag file, or if the
  + * corresponding tag file is not packaged in a JAR.
  + */
  +public JarFile getTagFileJar() {
  + return this.tagFileJar;
   }
   
   /*  Common implementation  */
  
  
  
  1.18  +7 -5  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ImplicitTagLibraryInfo.java
  
  Index: ImplicitTagLibraryInfo.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ImplicitTagLibraryInfo.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- ImplicitTagLibraryInfo.java   14 Dec 2002 14:16:07 -  1.17
  +++ ImplicitTagLibraryInfo.java   18 Dec 2002 23:18:20 -  1.18
  @@ -159,8 +159,10 @@
   
TagInfo tagInfo = null;
try {
  - tagInfo = TagFileProcessor.parseTagFile(pc, shortName, path,
  - this);
  + tagInfo = TagFileProcessor.parseTagFileDirectives(pc,
  +   shortName,
  +   path,
  +   this);
} catch (JasperException je) {
throw new RuntimeException(je.toString());
}
  
  
  
  1.34  +4 -4  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java
  
  Index: JspDocumentParser.java
  ===

Re: [PROPOSAL] EL Transition to Jakarta Commons

[Jan Luehe]

Costin,

> +1
> 
> Is the EL depenent on javax.servlet or javax.servlet.jsp, or is it
> completely independent and useable in non-servlet-container environments ?

There are some dependencies on servlet containers. For example, the EL
supports implicit objects, one of them being "pageContext", so if you
have an expression of the form "${pageContext}", it is evaluated to
the PageContext object, which exists only in a servlet environment.
 
> BTW, another option that can be considered is what Sam Ruby mentioned
> few times on jakarta-general or community, i.e. just lower the 
> walls between jakarta projects. Moving it to jakarta-commons does
> the same thing ( all jakarta committers can get access to it ),
> but I don't think we have to move code in order to get this effect.

Not sure I exactly understand what "lowering the walls between jakarta
projects" means. Would the EL implementation remain a component of the
Standard Taglib under this approach?

> You may also consider asking for a separate mailing list ( 
> jakarta-commons-el ?), the traffic on jakarta-commons is already high.

Good point.

Thanks for your comments,


Jan



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

Re: [PROPOSAL] EL Transition to Jakarta Commons

[Hans Bergsten]

Jan Luehe wrote:

Costin,



+1

Is the EL depenent on javax.servlet or javax.servlet.jsp, or is it
completely independent and useable in non-servlet-container environments ?



There are some dependencies on servlet containers. For example, the EL
supports implicit objects, one of them being "pageContext", so if you
have an expression of the form "${pageContext}", it is evaluated to
the PageContext object, which exists only in a servlet environment.


No, in the EL API defined in JSP 2.0, a separate VariableResolver takes
care of all variable value lookup, including implicit variables if any.
The intention with the EL API is that it should not have any servlet or
JSP dependencies. Some minor tweaks will be included in JSP 2.0 PFD2
to be released pretty soon.

> [...]

Hans
--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software   
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at


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

Re: [PROPOSAL] EL Transition to Jakarta Commons

[Costin Manolache]

Jan Luehe wrote:

> Costin,
> 
>> +1
>> 
>> Is the EL depenent on javax.servlet or javax.servlet.jsp, or is it
>> completely independent and useable in non-servlet-container environments
>> ?
> 
> There are some dependencies on servlet containers. For example, the EL
> supports implicit objects, one of them being "pageContext", so if you
> have an expression of the form "${pageContext}", it is evaluated to
> the PageContext object, which exists only in a servlet environment.

I assume that can be done by the servlet container ( or whatever app is
using the EL package ) by pushing some objects into env ?

My question was - is the EL code using HttpServletRequest or similar things?
Can it be run without a servlet container ( for example - from inside ant )?

>> BTW, another option that can be considered is what Sam Ruby mentioned
>> few times on jakarta-general or community, i.e. just lower the
>> walls between jakarta projects. Moving it to jakarta-commons does
>> the same thing ( all jakarta committers can get access to it ),
>> but I don't think we have to move code in order to get this effect.
> 
> Not sure I exactly understand what "lowering the walls between jakarta
> projects" means. Would the EL implementation remain a component of the
> Standard Taglib under this approach?

I don't know if anyone understand it exactly :-)

If the intention is to give access to EL to other projects - then you
can either move EL to jakarta-commons or just lower the wall on taglib, by 
using the same rules as jakarta-commons ( i.e. all jakarta committers would
have commit access to EL by just adding themself to the STATUS ).

Costin



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

CoyoteWriter in error, never cleaned up

[Mark Plotnick]

I'm using a rather complicated web page with two frames and
a jsp in both frames.

The upper frame has an applet, and the applet loads a
document by calling a servlet (in the same session as the page).

Clicking within the applet will cause new pages to load in the
lower page.


As a result of all this activity I seem to get the "Socket Error"
bug described in thread "Problem with Socket closing" and
bug#12810.


Things would still not be too bad if the "CoyoteWriter" objects
were recycled. When the socket error occurs, the relevant 
"CoyoteWriter" objects get marked as being in error.

The problem is Tomcat (4.1.17 & 16) is still trying to reuse
these "CoyoteWriter" objects with the result of tomcat
returning blank pages to the browser.


CoyoteWriter does have a "isError()" method. A grep through
the source reveals nothing is ever calling this method.

It seems reasonable that after a socket write error, these
objects should get cleaned up and the application would
have a reasonable chance to recover.


I appreciate any insight and feedback on where these
"CoyoteWriter" objects should be managed.

Mark Plotnick
Ensodex, Inc.

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

Re: [PROPOSAL] EL Transition to Jakarta Commons

[Glenn Nielsen]

+1  It would also be nice to split out the EL documentation from JSTL
into docs that come with the EL.

Jan Luehe wrote:

I'd like to resume discussion on a proposal circulated by James
Strachan on March 13, 2002, about turning the implementation of JSTL's
expression language (EL) into a reusable component and moving it from
the Standard Taglib, an implementation of JSTL hosted by
jakarta-taglibs, to jakarta-commons, in order to make it available to
a larger number of projects.

James' original proposal received some positive feedback from the
taglibs-dev community. Below is a draft proposal for a formal
submission to jakarta-commons, following the format of the
jakarta-commons charter at http://jakarta.apache.org/commons/charter.html.

(0) Rationale

The JSP Standard Tag Library (JSTL), version 1.0, introduced the
concept of an Expression Language (EL), whose main goal is to provide
page authors with an easy way to access and manipulate application
data without requiring the use of scriptlets

JSP 2.0 adopted the EL specification from JSTL, and expanded its
scope: EL expressions are no longer limited to JSTL action attributes,
but may be used in any standard or custom action attribute declared to
accept a runtime expression. In addition, EL expressions may now also
be used directly in template text outside of any actions. JSP 2.0 also
added an important feature to the EL specification: EL functions,
which allow page authors to invoke static methods in Java classes from
EL expressions. Additionally, JSP 2.0 allows programmatic access and
customization of the EL evaluator through a set of standard interfaces
and abstract classes.

Currently, there are a number of projects (including Tomcat 5 and Java
Server Faces) that leverage the EL implementation of the Standard
Taglib. In addition, there seems to be interest in leveraging the EL
in the context of scripting workflow activities using custom tag
libraries.

In order to make the EL implementation available to Tomcat 5, the
Tomcat team defined a new "ant" target for the Standard Taglib that
builds just the EL portion and packages it in a JAR file
("jsp20el.jar") which is stored in Tomcat's common/lib directory. This
approach has always been considered an interim solution only, until
the EL implementation would move from the Standard Taglib to a more
visible location such as jakarta-commons.

(1) Scope of the package

The package shall provide an implementation of the Expression Language
specification which is part of the JSP 2.0 standard.

(1.5) Interaction with other packages

The package shall provide an implementation of the standard interfaces
and abstract classes of the javax.servlet.jsp.el package, which is
defined in the JSP 2.0 specification.

(2) Identify the initial source for the package

The initial codebase will be taken from the Standard Taglib project
hosted at jakarta-taglibs. The source of the Standard Taglib is
available as part of the jakarta-taglibs nightly source distribution
at http://jakarta.apache.org/builds/jakarta-taglibs/nightly/src/

(2.1) Identify the base name for the package

The base name of the package shall be org.apache.commons.el

(2.2) Identify the coding conventions for this package

The package follows Sun's Java coding conventions (see
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html).

(3) Identify any Jakarta-Commons resources to be created

(3.1) Mailing list

The package shall use the jakarta-commons mailing list.

(3.2) CVS repositories

The package shall use a root branch of the jakarta-commons CVS.

(3.3) Bugzilla

The package shall be listed as the "EL" component under the "Commons"
project in Bugzilla.

(3.4) Jyve FAQ (when available)

n/a

(4) Identify the initial set of committers to be listed in the Status File.

The initial set of committers will be identical to the set of
committers of the Standard Taglib project.


Thoughts?

Jan


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





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

Re: j-t-c/util, 3.3 and logging

[Bill Barker]

- Original Message -
From: "Costin Manolache" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, December 18, 2002 2:53 PM
Subject: j-t-c/util, 3.3 and logging


> Is it ok if I change util.thread and util.net to commons-logging ?
> That would mean c-l will be required for tomcat3.3, and thread
> and net would use c-l instead of the Log.

TC 3.3.2-dev already requires c-l.  The o.a.t.u.** classes in j-t are
already using it.

>
> It should be easy to modify the util.Log implementation in 3.3
> to support commons-logging API, or implement util.Log using
> commons-logging API ( if using the old Log is needed ).

Last time I checked, o.a.t.u.log.Log already implements o.a.c.l.Log.

>
> Right now a lot of j-t-c code uses c-l, and thread and net are
> different.

+1

>
>
>
> Costin
>
>
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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

DO NOT REPLY [Bug 15513] New: - OutOfMemoryError and adjusting the heap size not helping

[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=15513

OutOfMemoryError and adjusting the heap size not helping

   Summary: OutOfMemoryError and adjusting the heap size not helping
   Product: Tomcat 4
   Version: 4.0.2 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have Tomcat 4.0.2 Final runing through IIS on a server with 1gb of physical 
memory. (And Tomcat 4.1.12 on my test box)

On the live site, after running for a while (1hr to 1 day)  I start to get 
errors:
-
java.lang.OutOfMemoryError
<>
AND
org.apache.jasper.JasperException: Unable to compile class for JSP The 
compiler has run out of memory.  Consider using the "-J-mx" 
command line option to increase the maximum heap size.
--

following the suggestion in the second error, I have set 
CATALINA_OPTS="-Xmx700m -Xms700m"

By setting low values, I can get the system to error sooner, but still get the 
out of memory errors even with those high values.

When tomcat starts, java.exe promptly goes up to about 100mb, and never goes 
over about 120mb. (in Windows Task Manager)

Does anyone have an idea why I still get OutOfMemoryError after setting -Xmx 
to 700MB? (and why java.exe never goes above 120mb?  Shouldn’t it be over 
700mb?)

Thanks!

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

Re: j-t-c/util, 3.3 and logging

[Costin Manolache]

Bill Barker wrote:

>> Is it ok if I change util.thread and util.net to commons-logging ?
>> That would mean c-l will be required for tomcat3.3, and thread
>> and net would use c-l instead of the Log.
> 
> TC 3.3.2-dev already requires c-l.  The o.a.t.u.** classes in j-t are
> already using it.

Sorry, I lost track of this. It seems I'm running out of memory.


>> It should be easy to modify the util.Log implementation in 3.3
>> to support commons-logging API, or implement util.Log using
>> commons-logging API ( if using the old Log is needed ).
> 
> Last time I checked, o.a.t.u.log.Log already implements o.a.c.l.Log.

I know, but it needs a factory and manifest to be useable
as a c-l impl.  ( I never tried it - it may work if someone already 
added this )

Ok, I'll go ahead with the commits.

Costin



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

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

[costin]

costin  2002/12/18 21:31:47

  Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
  Log:
  Use commons-loggign directly.
  
  This way any logger can be used ( and the same logger config ).
  
  Revision  ChangesPath
  1.9   +42 -25
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java
  
  Index: PoolTcpEndpoint.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- PoolTcpEndpoint.java  28 Nov 2002 15:16:31 -  1.8
  +++ PoolTcpEndpoint.java  19 Dec 2002 05:31:46 -  1.9
  @@ -67,10 +67,12 @@
   import org.apache.tomcat.util.res.*;
   import org.apache.tomcat.util.collections.SimplePool;
   import org.apache.tomcat.util.threads.*;
  -import org.apache.tomcat.util.log.*;
  +//import org.apache.tomcat.util.log.*;
  +import org.apache.commons.logging.Log;
  +import org.apache.commons.logging.LogFactory;
  +
   import java.io.*;
   import java.net.*;
  -import java.util.*;
   
   /* Similar with MPM module in Apache2.0. Handles all the details related with
  "tcp server" functionality - thread management, accept policy, etc.
  @@ -123,7 +125,10 @@
   static final int debug=0;
   
   ThreadPool tp;
  -protected Log _log=Log.getLog("tc/PoolTcpEndpoint", "PoolTcpEndpoint");
  +// XXX Do we need it for backward compat ?
  +//protected Log _log=Log.getLog("tc/PoolTcpEndpoint", "PoolTcpEndpoint");
  +
  +static Log log=LogFactory.getLog(PoolTcpEndpoint.class );
   
   protected boolean tcpNoDelay=false;
   protected int linger=100;
  @@ -133,7 +138,11 @@
//  super("tc_log");// initialize default logger
tp = new ThreadPool();
   }
  -
  +
  +public PoolTcpEndpoint( ThreadPool tp ) {
  +this.tp=tp;
  +}
  +
   //  Configuration 
   
   public void setPoolOn(boolean isPool) {
  @@ -294,7 +303,7 @@
listener = new TcpWorkerThread(this);
   tp.runIt(listener);
   } else {
  - log("XXX Error - need pool !", null, Log.ERROR);
  + log.error("XXX Error - need pool !");
}
   }
   
  @@ -315,12 +324,12 @@
}
s.close();
} catch(Exception e) {
  -log("Caught exception trying to unlock accept.", e);
  +log.error("Caught exception trying to unlock accept.", e);
}
try {
serverSocket.close();
} catch(Exception e) {
  -log("Caught exception trying to close socket.", e);
  +log.error("Caught exception trying to close socket.", e);
}
serverSocket = null;
}
  @@ -362,7 +371,7 @@
   
String msg = sm.getString("endpoint.err.nonfatal",
  serverSocket, e);
  - log(msg, e, Log.ERROR);
  + log.error(msg, e);
   
   if (accepted != null) {
   try {
  @@ -371,7 +380,7 @@
   } catch(Exception ex) {
   msg = sm.getString("endpoint.err.nonfatal",
  accepted, ex);
  -log(msg, ex, Log.INFORMATION);
  +log.warn(msg, ex);
   }
   }
   // Restart endpoint when getting an IOException during accept
  @@ -381,7 +390,7 @@
   } catch(Exception ex) {
   msg = sm.getString("endpoint.err.nonfatal",
  serverSocket, ex);
  -log(msg, ex, Log.INFORMATION);
  +log.warn(msg, ex);
   }
   serverSocket = null;
   try {
  @@ -396,7 +405,7 @@
   } catch (Throwable t) {
   msg = sm.getString("endpoint.err.fatal", 
  serverSocket, t);
  -log(msg, t, Log.ERROR);
  +log.error(msg, t);
   stopEndpoint();
   }
   }
  @@ -408,23 +417,31 @@
return accepted;
   }
   
  -public void log(String msg) 
  +/** @deprecated
  + */
  +public void log(String msg)
   {
  - _log.log(msg, null, Log.INFORMATION);
  + log.info(msg);
   }
  -
  -public void log(String msg, Throwable t) 
  +
  +/** @deprecated
  + */
  +public void log(String msg, Throwable t)
   {
  - _log.log(msg, t, Log.ERROR);
  + log.error( msg, t );
   }
   
  -public void log(String m

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPool.java

[costin]

costin  2002/12/18 21:45:42

  Modified:util/java/org/apache/tomcat/util/threads ThreadPool.java
  Log:
  - use commons-logging directly.
  - remove unused imports ( thanks idea )
  - added a ThreadListener. It'll be used to add
   JMX proxies for the thread pool ( and it can be used to
  get notifications of thread start and end ).
  - added missing getters
  - added a method to list the threads in the pool
  - (experimental) instead of creating Thread, the code
  will create ThreadWithAttributes. This would allow O(1)
  notes to be stored.
  
  I want to add JMX support and make calls to store the
  "state" of the thread, i.e. what is the thread doing.
  This would allow people to debug hunged threads and
  allow more control.
  
  Revision  ChangesPath
  1.5   +161 -33   
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java
  
  Index: ThreadPool.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- ThreadPool.java   27 Nov 2002 20:12:17 -  1.4
  +++ ThreadPool.java   19 Dec 2002 05:45:42 -  1.5
  @@ -1,7 +1,4 @@
   /*
  - * $Header$
  - * $Revision$
  - * $Date$
*
* 
*
  @@ -63,11 +60,9 @@
   
   package org.apache.tomcat.util.threads;
   
  -import java.util.zip.*;
  -import java.net.*;
   import java.util.*;
  -import java.io.*;
  -import org.apache.tomcat.util.log.*; 
  +import org.apache.commons.logging.Log;
  +import org.apache.commons.logging.LogFactory;
   
   /**
* A thread pool that is trying to copy the apache process management.
  @@ -75,6 +70,7 @@
* @author Gal Shachor
*/
   public class ThreadPool  {
  +static Log log = LogFactory.getLog(ThreadPool.class);
   
   /*
* Default values ...
  @@ -130,10 +126,17 @@
   
   static int debug=0;
   
  +/** The threads that are part of the pool.
  + * Key is Thread, value is the ControlRunnable
  + */
  +protected Hashtable threads=new Hashtable();
  +
  +protected Vector listeners=new Vector();
  +
   /**
* Helper object for logging
**/
  -Log loghelper = Log.getLog("tc/ThreadPool", "ThreadPool");
  +//Log loghelper = Log.getLog("tc/ThreadPool", "ThreadPool");
   
   public ThreadPool() {
   maxThreads  = MAX_THREADS;
  @@ -157,6 +160,10 @@
   monitor = new MonitorRunnable(this);
   }
   
  +public MonitorRunnable getMonitor() {
  +return monitor;
  +}
  +
   public void setMaxThreads(int maxThreads) {
   this.maxThreads = maxThreads;
   }
  @@ -181,6 +188,22 @@
   return maxSpareThreads;
   }
   
  +public int getCurrentThreadCount() {
  +return currentThreadCount;
  +}
  +
  +public int getCurrentThreadsBusy() {
  +return currentThreadsBusy;
  +}
  +
  +public boolean isDaemon() {
  +return isDaemon;
  +}
  +
  +public static int getDebug() {
  +return debug;
  +}
  +
   /** The default is true - the created threads will be
*  in daemon mode. If set to false, the control thread
*  will not be daemon - and will keep the process alive.
  @@ -192,7 +215,31 @@
   public boolean getDaemon() {
   return isDaemon;
   }
  -
  +
  +public void addThread( Thread t, ControlRunnable cr ) {
  +threads.put( t, cr );
  +for( int i=0; i0) p.log( "No toRun ???");
  +if( p.log.isDebugEnabled())
  +p.log.debug( "No toRun ???");
   }
   
   if( shouldTerminate ) {
  -if( p.debug>0) p.log( "Terminate");
  +if( p.log.isDebugEnabled())
  +p.log.debug( "Terminate");
   break;
   }
   
   /* Check if should execute a runnable.  */
   try {
   if(noThData) {
  -if(p.debug>0) p.log( "Getting new thread data");
  +if(p.log.isDebugEnabled())
  +p.log.debug( "Getting new thread data");
   thData=toRun.getInitData();
   noThData = false;
   }
  @@ -530,8 +593,7 @@
toRun.runIt(thData);
   }
   } catch(Throwable t) {
  - loghelper.log("Caught exception executing " + toRun.toString() 
+ ", terminating thread", t);
  - loghelper.flush();
  + p.log.error("Caught exceptio

Re: j-t-c/util, 3.3 and logging

[Bill Barker]

- Original Message -
From: "Costin Manolache" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, December 18, 2002 8:59 PM
Subject: Re: j-t-c/util, 3.3 and logging


> Bill Barker wrote:
>
> >> Is it ok if I change util.thread and util.net to commons-logging ?
> >> That would mean c-l will be required for tomcat3.3, and thread
> >> and net would use c-l instead of the Log.
> >
> > TC 3.3.2-dev already requires c-l.  The o.a.t.u.** classes in j-t are
> > already using it.
>
> Sorry, I lost track of this. It seems I'm running out of memory.

Well, they say that memory is cheap these days ;-).

>
>
> >> It should be easy to modify the util.Log implementation in 3.3
> >> to support commons-logging API, or implement util.Log using
> >> commons-logging API ( if using the old Log is needed ).
> >
> > Last time I checked, o.a.t.u.log.Log already implements o.a.c.l.Log.
>
> I know, but it needs a factory and manifest to be useable
> as a c-l impl.  ( I never tried it - it may work if someone already
> added this )

I'll look into adding a factory to qlog (since I assume that the 4.x/5.x
groups aren't interested :).  For me, qlog does what I want, and is much
lighter-weight than log4J (sorry Ceki, but implementing a 3.3 module for
http://qos.ch/logging/sc.html is still on my plate, when I have the time :).

>
> Ok, I'll go ahead with the commits.
>
> Costin
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>


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

Re: CoyoteWriter in error, never cleaned up

[Remy Maucherat]

Mark Plotnick wrote:

I'm using a rather complicated web page with two frames and
a jsp in both frames.

The upper frame has an applet, and the applet loads a
document by calling a servlet (in the same session as the page).

Clicking within the applet will cause new pages to load in the
lower page.


As a result of all this activity I seem to get the "Socket Error"
bug described in thread "Problem with Socket closing" and
bug#12810.


Things would still not be too bad if the "CoyoteWriter" objects
were recycled. When the socket error occurs, the relevant 
"CoyoteWriter" objects get marked as being in error.

The problem is Tomcat (4.1.17 & 16) is still trying to reuse
these "CoyoteWriter" objects with the result of tomcat
returning blank pages to the browser.


CoyoteWriter does have a "isError()" method. A grep through
the source reveals nothing is ever calling this method.

It seems reasonable that after a socket write error, these
objects should get cleaned up and the application would
have a reasonable chance to recover.

Yes, this is correct (and a major bug, expect a new release soon).
There is no problem with recycling after an error. OTOH, the writer must 
not be set to a non error state right away once an IOException occurred.

I appreciate any insight and feedback on where these
"CoyoteWriter" objects should be managed.


Here's a patch:

Index: CoyoteResponse.java
===
RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java,v
retrieving revision 1.30
diff -r1.30 CoyoteResponse.java
322a323,324
> writer.recycle();
>
Index: CoyoteWriter.java
===
RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteWriter.java,v
retrieving revision 1.2
diff -r1.2 CoyoteWriter.java
98a99,109
> //  
Package Methods
>
>
> /**
>  * Recycle.
>  */
> void recycle() {
> error = false;
> }
>
>

Remy


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