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

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 jsseCerts[] = 

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
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15456.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

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

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
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15477.
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 
Class.forName(COM.ibm.db2.jdbc.app.DB2Driver).newInstance(); 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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15479.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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



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

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

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
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15480.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

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

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

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
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15484.
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\Loginant remove
Buildfile: build.xml

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


BUILD SUCCESSFUL
Total time: 1 second
C:\Dokumente\Struts\example\project\Loginant 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\Loginant 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\Loginant 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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15484.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

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
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14292.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15411.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

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
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15484.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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





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

Re: 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 lt;your_keystore_filenamegt;/source
   /li
   /ul
  -pNow you have a file called codecertreq.csr/code 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./p
  +pNow you have a file called codecertreq.csr/code. 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./p
   /subsection
   
   subsection name=Importing the Certificate
  @@ -403,7 +404,7 @@
   sourcekeytool -import -alias root -keystore lt;your_keystore_filenamegt; \
   	-trustcacerts -file lt;filename_of_the_chain_certificategt;/source
   /li
  -liAnd finally import your new Certificate
  +liAnd 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.

   	sourcekeytool -import -alias tomcat -keystore lt;your_keystore_filenamegt; \
   	-trustcacerts -file lt;your_certificate_filenamegt;/source
   /li
  
  
  

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






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

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

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

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 codetrue/code, then the codetimeout/code parameter is
  - * ignored.  If codefalse/code, then the codetimeout/code
  - * 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 codetrue/code, then the codetimeout/code parameter is
  + * ignored.  If codefalse/code, then the codetimeout/code
  + * 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, 
  

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
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15397.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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 jsp:attribute.
  
  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. my:tag/), 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 @@
*
* pBMethods Intended for JSP authors/B
* p
  + * Some methods provide Buniform access/B 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:
  + * codesetAttribute()/code,  codegetAttribute()/code,
  + * codefindAttribute()/code,  coderemoveAttribute()/code,
  + * codegetAttributesScope()/code and 
  + * codegetAttributeNamesInScope()/code.
  + * 
  + * p
* The following methods provide Bconvenient access/B to implicit objects:
  - * ul
* codegetOut()/code
*
  + * p
  + * The following methods provide Bprogrammatic access/b to the 
  + * Expression Language evaluator:
  + * codegetExpressionEvaluator()/code, codegetVariableResolver()/code
  + *
* @since 2.0
*/
   
   

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
  
Binary file
  
  

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

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

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
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15496.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15497.
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)

Thread-2 daemon prio=5 tid=0x0AD67230 nid=0x11b8 

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
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15474.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15474.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

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




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

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


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

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


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




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

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


 



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

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

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

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

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

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
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15508.
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

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   http://www.gefionsoftware.com/
Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0
Details athttp://TheJSPBook.com/


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

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

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

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





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

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



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

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
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15513.
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
no stack trace available
AND
org.apache.jasper.JasperException: Unable to compile class for JSP The 
compiler has run out of memory.  Consider using the -J-mxlt;numbergt; 
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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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

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 msg, int level) 
  +/** 

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; ilisteners.size(); i++ ) {
  +ThreadPoolListener tpl=(ThreadPoolListener)listeners.elementAt(i);
  +tpl.threadStart(this, t);
  +}
  +}
  +
  +public void removeThread( Thread t ) {
  +threads.remove(t);
  +for( int i=0; ilisteners.size(); i++ ) {
  +ThreadPoolListener tpl=(ThreadPoolListener)listeners.elementAt(i);
  +tpl.threadEnd(this, t);
  +}
  +}
  +
  +public void addThreadPoolListener( ThreadPoolListener tpl ) {
  +listeners.addElement( tpl );
  +}
  +
  +public Enumeration getThreads(){
  +return threads.keys();
  +}
  +
   //
   // You may wonder what you see here ... basically I am trying
   // to maintain a stack of threads. This way locality in time
  @@ -225,7 +272,7 @@
   int toOpen = currentThreadCount + minSpareThreads;
   openThreads(toOpen);
   } else {
  - logFull(loghelper, currentThreadCount, maxThreads);
  + logFull(log, currentThreadCount, maxThreads);
   // Wait for a thread to become idel.
   while(currentThreadsBusy == currentThreadCount) {
   try {
  @@ -237,7 +284,7 @@
// it'll never 

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




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