date:20020526

Re: [Proposal] Removing 64K limit in jasper 2

2002-05-26 Thread costinm

On Mon, 27 May 2002, Denis Benoit wrote:

> 1. In the generated page, there is a lot of consecutive:
> 
>   out.write("some string");
>   out.write("another string");
>   and so on.
> 
>Why don't we merge all these consecutive strings together?
> 
>   out.write("some string\nanother string");

Since you mention this - String->byte conversion usually has a very
large performance penalty. 

With Coyote we do get the same optimizations that 3.3 is using for
reducing the GC involved with the conversion, but it remains 
an expensive operation.

If I remember corectly, it is now possible to use both the writer and
output stream ( and if it's not, we can call some tomcat-specific 
methods - even write directly to the OutputBuffer and avoid another copy).

The only problem with using byte[]  is that for some pages, it is possible
to have requests in multiple encodings, so we may have 2-3 different 
byte[] representations for the same page. 

Most current browsers use unicode, and we could at least support this 
case. 

I think cutting of the String->byte conversion ( and eventually
one or 2 memcpy for the data ) would be quite significant. 

I'm very interested in this subject - chunks of byte[] can 
be further optimized at the connector level, by either NIO or
the web server, plus avoids sending stuff over ajp. Not easy,
but has huge potential.

> 2. This one has nothing to do with the size, it's just something that I think
>we should plan for: tag reuse.  Some of the pages that have a lot of tags,
>do so because they have them in an HTML table.  A "big" page can reference 
>80 or so tags, but these tags can represent only four or five distinct
>types.  It is not so difficult to find 80 tags in a page, but it would be
>difficult to find one with 80 _distinct_ tag classes!  Most of these tags
>could be reused, that is we often call:

This is implemented already in jasper ( the tomcat3.3 version ). I don't
think it'll reduce the method size ( the code is more complex ), but
it'll improve the performance ( even with the best GC, memory allocation
and gc is never free ).

Unfortunately some pages will fail, due to bugs in tags that don't 
clean up properly. 

>   So, the specs seem to imply that tag reuse is allowed.

Yes, and it works pretty well - it's just that it'll expose several bugs
in tags ( not a direct problem for jasper, but for the users who'll
have a hard time figuring out what's happening ).

> optimize them.  Most tags won't see a big performance boost from reuse, but some
> tags can be pretty hefty, and for them, tag reuse can be a big factor.

Some tests showed quite significant boosts. Some extreme cases showed a 
reduction ( in pages with many distinct tags, the overhead is bigger and 
the gain is null ). That happened long ago, check the archives.

> Now, there were two approach to the "64K problem".  Kin-Man proposed creating
> methods for each custom tags, and Costin proposed a state machine.  I tend to

It was just an idea, not a real proposal. 

There are few important things that happen if we reduce the size of the 
class ( either by using a state machine for some of the logic, or moving 
more static content in data files - the largefile option ). First we 
reduce the footprint of the tomcat process, and we can make better use of 
the memory ( the static data can be cached or manipulated much easier than 
.class, where we have no control except the hope it'll be garbaged collected )

The current mechanism doesn't scale well for a large number of pages
( 100.000s ? ) with uniform accesses. ( right now we care more
about how a page scales under increased load, not how the system scales
if you add more documents ). 

Costin

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

Re: [Proposal] Removing 64K limit in jasper 2

2002-05-26 Thread Denis Benoit

On Fri, 24 May 2002, Kin-Man Chung wrote:

> My proposal to solving this problem is to generate codes for a tag
> handler (including its body) to a separate method.  This is only feasible
> if the tag action element and its body does not include any scripting
> elements.  The current trend (in the coming JSP1.3) seems to be moving
> to scriptless pages, so this is not as restrictive as it appears.
> 
> I don't have a detailed design yet for Generator, but I don't see any
> obvious problems.  The recent change in flattening out the try/catch
> blocks complicates things a little, but they are manageable.
> 
> There is obviously some performance trade-offs.  I really don't like

Like Costin, I don't think that there would be much performance penalty
by calling a private method.  In fact, if we want to reduce the number
of "unnecessary" calls, I have another idea...  well I have two ideas,
one of which is not related to the 64 K limit.

1. In the generated page, there is a lot of consecutive:

out.write("some string");
out.write("another string");
and so on.

   Why don't we merge all these consecutive strings together?

out.write("some string\nanother string");

   it would greatly reduce the number of write() calls.  So it would
   contribute, in a limited way to reduce the size of the _jsp_service()
   method.  It would be sligthly faster, which is not bad :) by reducing
   the number of method calls.

2. This one has nothing to do with the size, it's just something that I think
   we should plan for: tag reuse.  Some of the pages that have a lot of tags,
   do so because they have them in an HTML table.  A "big" page can reference 
   80 or so tags, but these tags can represent only four or five distinct
   types.  It is not so difficult to find 80 tags in a page, but it would be
   difficult to find one with 80 _distinct_ tag classes!  Most of these tags
   could be reused, that is we often call:

tag1 = new SomeTag();
tag1.doStartTag();
tag1.doEndTag();
tag1.release();
tag2 = new SomeTag();
tag2.doStartTag();
tag2.doEndTag();
tag2.release();

  There is no real reason to create a new tag for tag2, it could have
  been replaced by:

tag1 = new SomeTag();
tag1.doStartTag();
tag1.doEndTag();
tag1.doStartTag();
tag1.doEndTag();
tag1.release();

   Here is the relevant section of the JSP specs (I know Kin-Man, you don't need
   a reminder, but others might :):

"public void release()
 Called on a Tag handler to release state. The page compiler guarantees
 that JSP page implementation objects will invoke this method on all tag
 handlers, but there may be multiple invocations on doStartTag and
 doEndTag in between."

  So, the specs seem to imply that tag reuse is allowed.

Now, why do I brought about this second point, if it is not relevant to the 64K
limit?  Just that whatever the solution we'll take to address the issue, it
should not make tag reuse impossible.  I agree with Kin-Man, Tag will take more
importance in the future of JSP pages.  So we must take whatever measures to
optimize them.  Most tags won't see a big performance boost from reuse, but some
tags can be pretty hefty, and for them, tag reuse can be a big factor.

Now, there were two approach to the "64K problem".  Kin-Man proposed creating
methods for each custom tags, and Costin proposed a state machine.  I tend to
agree with Kin-Man for one account, at the current state of the compiler,
Kin-Man's method could be done faster.  I don't think we should throw away
the "state machine" implementation, but I see it more as a Jasper 3 / Tomcat 5
thing :)  At that time, it could be further investigated the benefits and
penalties of this approach.  But if we choose to delegate each tag to a method,
I think it would be important to leave the door open to tag reuse, that is if we
do not implement it at the same time.

Comments?

-- 
Denis Benoit
[EMAIL PROTECTED]

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

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi SSIServlet.java SSIServletExternalResolver.java

2002-05-26 Thread Bill Barker


Thanks Remy! This is a better solution.

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, May 25, 2002 5:00 PM
Subject: cvs commit:
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi
SSIServlet.java SSIServletExternalResolver.java


> remm02/05/25 17:00:55
>
>   Modified:catalina/src/share/org/apache/catalina/ssi
> SSIServletExternalResolver.java
>   Added:   catalina/src/share/org/apache/catalina/ssi SSIServlet.java
>   Log:
>   - Move SSI servlet to the ssi package (so that it's more
> an independent package).
>   - Remove uneeded imports.
>   - SSI is mostly independent of Catalina. Whatever util classes it needs
can
> be moved to j-t-c/util. Then we could consider moving it out of the
Catalina
> tree (the return of the j-t-modules repository ?).
>



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

DO NOT REPLY [Bug 9430] - getResource() doesn't return null for invalid URLs

2002-05-26 Thread bugzilla


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

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

getResource() doesn't return null for invalid URLs

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

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

DO NOT REPLY [Bug 9430] New: - getResource() doesn't return null for invalid URLs

2002-05-26 Thread bugzilla


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

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

getResource() doesn't return null for invalid URLs

   Summary: getResource() doesn't return null for invalid URLs
   Product: Tomcat 3
   Version: 3.2.3 Final
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Servlet
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,

>From the Servlet 2.2 javax.servlet.ServletContext javadocs, method:

public java.net.URL getResource(java.lang.String path):

"This method returns null if no resource is mapped to the pathname."

Yet it clearly doesn't, as this JSP demonstrates:

<%= config.getServletContext().getResource("/some/nonexistent/path") %>

This bug is fixed in 3.3.1rc1 and 4.0.1 (at least), but I thought I'd just
record this bug for future generations.


--Jeff

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

Re: [PATCH] improved HTMLManagerServlet

2002-05-26 Thread Malcolm Edgar


Glenn Nielsen wrote:

>I have a number of comments.  First thanks for working on improving the
>HTMLManagerServlet.
>
>1.  GC should not be user initiated, it should be left to the JVM.
> In addition, when virtual hosting web sites, those who have permission
> to manage applications for a particluar host may not be the
> system admin for Tomcat.  I wouldn't want them to be able to trigger a 
>GC.
> The GC option needs to be removed.

Done

>2.  The js which you added for onClick really isn't necessary.  The
> HTMLManagerServlet should be usable w/o JavaScript enabled
> in the browser. It should be removed.

Done

>3.  The listing of memory usage isn't really needed if GC is removed.
> It doesn't provide info that is of benefit to someone
> who just manages web applications and is not the Tomcat sysad.
> A Tomcat sysad would be better off using the -verbose:gc arg to
> java when starting Tomcat so that they collect GC data which they
> can later graph to profile the Tomcat JVM memory usage.

Done

The memory status stuff is probably out of place here. A performance 
monitoring module could be included in the Admin application, covering mem 
status, request response time, etc.

Regards Malcolm Edgar



_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.


defaultservlet.directorylistingfor=Directory Listing for:
defaultservlet.upto=Up to:
defaultservlet.subdirectories=Subdirectories:
defaultservlet.files=Files:
htmlManagerServlet.appsAvailable=Running
htmlManagerServlet.appsName=Display Name
htmlManagerServlet.appsPath=Path
htmlManagerServlet.appsReload=Reload
htmlManagerServlet.appsRemove=Remove
htmlManagerServlet.appsSessions=Sessions
htmlManagerServlet.appsStart=Start
htmlManagerServlet.appsStop=Stop
htmlManagerServlet.appsTitle=Applications
htmlManagerServlet.installButton=Install
htmlManagerServlet.installConfig=Config URL:
htmlManagerServlet.installPath=Path:
htmlManagerServlet.installTitle=Install
htmlManagerServlet.installWar=WAR URL:
htmlManagerServlet.messageLabel=Message:
htmlManagerServlet.serverJVMVendor=JVM Vendor
htmlManagerServlet.serverJVMVersion=JVM Version
htmlManagerServlet.serverOSArch=OS Arch
htmlManagerServlet.serverOSName=OS Name
htmlManagerServlet.serverOSVersion=OS Version
htmlManagerServlet.serverTitle=Server
htmlManagerServlet.serverVersion=Server Version
htmlManagerServlet.title=Tomcat Manager
invokerServlet.allocate=Cannot allocate servlet instance for path {0}
invokerServlet.cannotCreate=Cannot create servlet wrapper for path {0}
invokerServlet.deallocate=Cannot deallocate servlet instance for path {0}
invokerServlet.invalidPath=No servlet name or class was specified in path 
{0}
invokerServlet.notNamed=Cannot call invoker servlet with a named dispatcher
invokerServlet.noWrapper=Container has not called setWrapper() for this 
servlet
managerServlet.alreadyContext=FAIL - Application already exists at path {0}
managerServlet.alreadyDocBase=FAIL - Directory {0} is already in use
managerServlet.cannotInvoke=Cannot invoke manager servlet through invoker
managerServlet.configured=OK - Installed application from context file {0}
managerServlet.deployed=OK - Deployed application at context path {0}
managerServlet.exception=FAIL - Encountered exception {0}
managerServlet.installed=OK - Installed application at context path {0}
managerServlet.invalidPath=FAIL - Invalid context path {0} was specified
managerServlet.invalidWar=FAIL - Invalid application URL {0} was specified
managerServlet.listed=OK - Listed applications for virtual host {0}
managerServlet.listitem={0}:{1}:{2}:{3}
managerServlet.noAppBase=FAIL - Cannot identify application base for context 
path {0}
managerServlet.noCommand=FAIL - No command was specified
managerServlet.noContext=FAIL - No context exists for path {0}
managerServlet.noDirectory=FAIL - Non-directory document base for path {0}
managerServlet.noDocBase=FAIL - Cannot remove document base for path {0}
managerServlet.noGlobal=FAIL - No global JNDI resources are available
managerServlet.noPath=FAIL - No context path was specified
managerServlet.noReload=FAIL - Reload not supported on WAR deployed at path 
{0}
managerServlet.noRename=FAIL - Cannot deploy uploaded WAR for path {0}
managerServlet.noRole=FAIL - User does not possess role {0}
managerServlet.noWrapper=Container has not called setWrapper() for this 
servlet
managerServlet.reloaded=OK - Reloaded application at context path {0}
managerServlet.removed=OK - Removed application at context path {0}
managerServlet.resourcesAll=OK - Listed global resources of all types
managerServlet.resourcesType=OK - Listed global resources of type {0}
managerServlet.rolesList=OK - Listed security roles
managerServlet.saveFail=FAIL - Configuration save failed: {0}
managerServlet.sessiondefaultmax=Default maximum session inactive interval 
{0} minutes
managerServlet.sessiontimeout={0} minutes:{1

cvs commit: jakarta-tomcat-connectors/jk build.xml

2002-05-26 Thread jfclere


jfclere 02/05/26 14:43:36

  Modified:jk   build.xml
  Log:
  Add the tasks to build documentation for xml files.
  
  Revision  ChangesPath
  1.41  +56 -0 jakarta-tomcat-connectors/jk/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/build.xml,v
  retrieving revision 1.40
  retrieving revision 1.41
  diff -u -r1.40 -r1.41
  --- build.xml 9 May 2002 00:20:22 -   1.40
  +++ build.xml 26 May 2002 21:43:36 -  1.41
  @@ -11,6 +11,8 @@
   
   
   
  +
  +
   
   
   
  @@ -64,6 +66,14 @@
  file="${jmx.jar}" />
   
  +
  +
  +   
  +
   
   
   
  @@ -265,5 +275,51 @@
   
   
   
  +
  +  
  +  
  + 
  +
  +
  +   
  +
  +  
  +  
  + 
  +
  +
  + 
  +
  +
  + 
  +
  +
  +  
  +
  +
  +
  +
  +  
  +
  +   
  +
   
   
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/xdocs/images jakarta.gif mod_jk.jpeg pixel.gif tomcat.ico

2002-05-26 Thread jfclere


jfclere 02/05/26 14:41:20

  Added:   jk/xdocs AJPv13.xml menu.idx style.css style.xsl
   jk/xdocs/images jakarta.gif mod_jk.jpeg pixel.gif tomcat.ico
  Log:
  Add the xml version of the old Ajp13 protocol description.
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-connectors/jk/xdocs/AJPv13.xml
  
  Index: AJPv13.xml
  ===
   
  

  Apache JServ Protocol version 1.3
  [EMAIL PROTECTED]

  
  
  
  
  The original document was written by
  Dan Milstein, [EMAIL PROTECTED]
  on December 2000. The present document is generated out of an xml file
  to allow a more easy integration in the Tomcat documentation.
  
  
  
  
  This describes the Apache JServ Protocol version 1.3 (hereafter
  ajp13).  There is, apparently, no current documentation of how the
  protocol works.  This document is an attempt to remedy that, in order to
  make life easier for maintainers of mod_jk, and for anyone who wants to
  port the protocol somewhere (into jakarta 4.x, for example).
  
  
  
  
  
  
  
  I am not one of the designers of this protocol -- I believe that Gal
  Shachor was the original designer.  Everything in this document is derived
  from the actual implementation I found in the tomcat 3.x code.  I hope it
  is useful, but I can't make any grand claims to perfect accuracy.  I also
  don't know why certain design decisions were made.  Where I was able, I've
  offered some possible justifications for certain choices, but those are
  only my guesses.  In general, the C code which Shachor wrote is very clean
  and comprehensible (if almost totally undocumented).  I've cleaned up the
  Java code, and I think it's reasonably readable.
  
  
  
  
  
  
  According to email from Gal Shachor to the jakarta-dev mailing list,
  the original goals of mod_jk (and thus ajp13) were to extend
  mod_jserv and ajp12 by (I am only including the goals which
  relate to communication between the web server and the servlet container):
  
  
 Increasing performance (speed, specifically). 
  
 Adding support for SSL, so that isSecure() and
 geScheme() will function correctly within the servlet
 container.  The client certificates and cipher suite will be
 available to servlets as request attributes. 
  
  
  
  
  
  
  
  
  The ajp13 protocol is packet-oriented.  A binary format was
  presumably chosen over the more readable plain text for reasons of
  performance.  The web server communicates with the servlet container over
  TCP connections.  To cut down on the expensive process of socket creation,
  the web server will attempt to maintain persistent TCP connections to the
  servlet container, and to reuse a connection for multiple request/response
  cycles.
  
  Once a connection is assigned to a particular request, it will not be
  used for any others until the request-handling cycle has terminated.  In
  other words, requests are not multiplexed over connections.  This makes
  for much simpler code at either end of the connection, although it does
  cause more connections to be open at once.
  
  Once the web server has opened a connection to the servlet container,
  the connection can be in one of the following states:
  
  
 Idle  No request is being handled over this connection. 
 Assigned  The connecton is handling a specific request.
  
  
  
  Once a connection is assigned to handle a particular request, the basic
  request informaton (e.g. HTTP headers, etc) is sent over the connection in
  a highly condensed form (e.g. common strings are encoded as integers).
  Details of that format are below in Request Packet Structure. If there is a
  body to the request (content-length > 0), that is sent in a separate
  packet immediately after.
  
  At this point, the servlet container is presumably ready to start
  processing the request.  As it does so, it can send the
  following messages back to the web server:
  
  
SEND_HEADERS Send a set of headers back to the browser.
  
SEND_BODY_CHUNK Send a chunk of body data back to the browser.
  
GET_BODY_CHUNK Get further data from the request if it hasn't all
been transferred yet.  This is necessary because the packets have a fixed
maximum size and arbitrary amounts of data can be included the body of a
request (for uploaded files, for example).  (Note: this is unrelated to
HTTP chunked tranfer).
  
END_RESPONSE  Finish the request-handling cycle.
  
  
  
  Each message is accompanied by a differently formatted packet of data.  See
  Response Packet Structures below for details.
  
  
  
  
  
  
  There is a bit of an XDR heritage to this protocol, but it differs in
  lots of ways (no 4 byte alignment, for example).
  
  Byte order: I am not clear about the endian-ness of the individual
  bytes.  I'm guessing the bytes are little-endian, because that's what XDR
  specifies, and I'm guessing t

cvs commit: jakarta-tomcat-connectors/jk/xdocs/images - New directory

2002-05-26 Thread jfclere


jfclere 02/05/26 14:36:07

  jakarta-tomcat-connectors/jk/xdocs/images - New directory

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

cvs commit: jakarta-tomcat-connectors/jk/xdocs - New directory

2002-05-26 Thread jfclere


jfclere 02/05/26 14:35:44

  jakarta-tomcat-connectors/jk/xdocs - New directory

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

Bug report for Tomcat 4 [2002/05/26]

2002-05-26 Thread bugzilla


+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| |   |   MIN=Minor   NOR=Normal  ENH=Enhancement   |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
| 2820|Opn|Enh|2001-07-26|Implement GZIPOutput on HTTP 1.1 Connector|
| 3509|Ass|Blk|2001-09-07|Apache 1.3.20 & mod_webapp & Tomcat 4b7 HANGS unde|
| 4023|Opn|Min|2001-10-08|exceptions that terminate engine should be saved i|
| 4042|Ass|Enh|2001-10-09|webapp component requires Port directive versus Li|
| 4212|Ass|Enh|2001-10-16|How to configure Apache to serve static contents? |
| 4217|Opn|Nor|2001-10-16|Mis-named SetCharacterEncodingFilter.clas in distr|
| 4350|Ass|Nor|2001-10-22|SSLAuthenticator did not associate SSO session|
| 4352|Ass|Nor|2001-10-22|JDBCRealm does not work with CLIENT-CERT auth-meth|
| 4371|Unc|Nor|2001-10-23|No responses on browsing root when using WarpConne|
| 4500|New|Nor|2001-10-29|isapi_redirect.dll does not pass Client certificat|
| 4829|Opn|Enh|2001-11-13|Automatic deployment of war files does not work pr|
| 4930|Ass|Maj|2001-11-16|java.io.StreamCorruptedException: Type code out of|
| 5143|New|Enh|2001-11-27|Please allow to specify the cipher set for HTTPS c|
| 5229|New|Blk|2001-12-02|Session cannot unbind if using DistributedManager |
| 5329|New|Nor|2001-12-08|NT Service exits startup before Tomcat is finished|
| 5383|New|Nor|2001-12-12|/etc/rc.d/init.d/tomcat4 on RedHat 6.1 fails  |
| 5405|New|Enh|2001-12-13|Powered by Tomcat |
| 5446|Opn|Min|2001-12-16|Can't change webapp class loader (bug #5391 revisi|
| 5507|New|Cri|2001-12-19|Swapping sessions causes exceptions and it doesn't|
| 5551|New|Enh|2001-12-21|MANAGER: add system information query |
| 5603|New|Min|2001-12-28|ServletContext.getResourcePaths() returns extra sl|
| 5647|Opn|Blk|2002-01-01|AJP13 connector will not pass authentication reque|
| 5704|Ass|Maj|2002-01-05|CgiServlet corrupting images? |
| 5709|New|Nor|2002-01-06|HttpServletRequest.getHost returns web server addr|
| 5758|New|Nor|2002-01-08|Server-side includes do not work properly |
| 5759|Opn|Maj|2002-01-09|CGI servlet mapping by extension *.cgi does not wo|
| 5762|Opn|Maj|2002-01-09|CGI servlet misses to include port number in HTTP_|
| 5764|New|Enh|2002-01-09|Key Information Missing--Automatic Application Dep|
| 5795|New|Enh|2002-01-10|Catalina Shutdown relies on localhost causing prob|
| 5829|New|Nor|2002-01-13|StandardManager needs to cope with sessions throwi|
| 5858|New|Enh|2002-01-15|Add tomcat dir to java.library.path   |
| 5877|New|Min|2002-01-16|Facade of facade. |
| 5899|New|Blk|2002-01-17|HTTP POST parameters ignored in CGIServlet.java   |
| 5952|New|Nor|2002-01-22|Refence to $JAVACMD  in tomcat.conf incorrect in R|
| 5975|New|Nor|2002-01-23|isSecure and getScheme: http are not set when usin|
| 5985|New|Enh|2002-01-23|Tomcat should perform a more restrictive validatio|
| 6036|Ass|Blk|2002-01-25|Problems with URI mapping |
| 6048|Ass|Nor|2002-01-26|JDBC pool unavailable while using WARP connector  |
| 6049|New|Nor|2002-01-26|jsp-version should be 1.2 |
| 6058|New|Enh|2002-01-27|Generated java files not in a correct package |
| 6068|New|Maj|2002-01-28|AJP13 "bad read", IOException |
| 6118|New|Enh|2002-01-30|Ambiguous error message for syntax errors |
| 6206|New|Min|2002-02-04|Sixteen Lifecycle implementers disagree with Lifec|
| 6218|New|Nor|2002-02-04|Relative links broken for servlets|
| 6228|Ass|Cri|2002-02-04|res.sendError sends blank page.   |
| 6229|New|Enh|2002-02-04|Need way to specify where to write catalina.out   |
| 6235|New|Maj|2002-02-05|tomcat4-4.0.1-1 rpm has wrong owner for /var/tomca|
| 6279|New|Nor|2002-02-06|Resubmit to j_security_check mistakenly fetches a |
| 6299|New|Nor|2002-02-07|SSI problem with multiple include statements in on|
| 6335|New|Enh|2002-02-08|JspC doesn't compile the Java it produces |
| 6399|New|Nor|2002-02-12|unknown protocol: https   |
| 6408

Bug report for Tomcat 3 [2002/05/26]

2002-05-26 Thread bugzilla


+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| |   |   MIN=Minor   NOR=Normal  ENH=Enhancement   |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|  258|Unc|Nor|2000-11-27|response.SendRedirect() resets/destroys Cookies th|
| 2478|Opn|Cri|2001-07-06|Passing Session variables between JSP's and Servle|
| 4380|New|Enh|2001-10-23|Multiple ISAPI redirectors on single IIS website  |
| 4551|Opn|Nor|2001-10-31|Ctx( /tt01 ): IOException in: R( /tt01 + /com/abc/|
| 4893|Unc|Blk|2001-11-15|Tomcat dies with following error..|
| 4915|New|Blk|2001-11-16|Relocation error while loading mod_jk when startin|
| 4980|New|Min|2001-11-20|Startup message indicates incorrect log file  |
| 4994|New|Nor|2001-11-21|Tomcat needs a mechanism for clean and certain shu|
| 5064|New|Cri|2001-11-25|Socket write error when include files is more than|
| 5108|New|Maj|2001-11-26|Docs for Tomcat 3.2.x appear to be for Tomcat 3.3 |
| 5137|New|Nor|2001-11-27|Null pointer in class loader after attempting to r|
| 5160|Unc|Maj|2001-11-28|'IllegalStateException'   |
| 5231|New|Nor|2001-12-02|Tomcat 3.2.4 does not start due to error in classp|
| 5261|New|Cri|2001-12-04|Directory Listing in Tomcat 3.2.4 |
| 5331|New|Nor|2001-12-09|getPathInfo vs URL normalization  |
| 5411|Opn|Nor|2001-12-13|JSP session does not work with IE/IIS5/Tomcat 3.3 |
| 5510|New|Blk|2001-12-19|How to call ejb deployed in JBoss from Tomcat serv|
| 5511|New|Nor|2001-12-19|Error upload files|
| 5581|New|Cri|2001-12-24|java.lang.ArrayIndexOutOfBoundsException  |
| 5756|New|Nor|2002-01-08|jspc.bat exits with wrong ERRORLEVEL  |
| 5797|New|Nor|2002-01-10|UnCatched ? StringIndexOutOfBoundsException: Strin|
| 5925|New|Cri|2002-01-19|Apache server hangs up and consumes 100% CPU resou|
| 6027|New|Maj|2002-01-25|Tomcat  Automatically shuts down as service   |
| 6168|New|Blk|2002-02-01|double execution of java code in JSP  |
| 6324|New|Nor|2002-02-08|Invalid POST requests through ajp13 cause 'garbage|
| 6451|New|Cri|2002-02-14|Stackoverflow |
| 6478|New|Enh|2002-02-14|Default Tomcat Encoding   |
| 6488|Ver|Maj|2002-02-15|Error: 304. Apparent bug in default ErrorHandler c|
| 6648|New|Nor|2002-02-25|jakarta-servletapi build with java 1.4 javadoc err|
| 6702|New|Cri|2002-02-27|jk_nt_service.exe -i cannot work  |
| 6796|New|Cri|2002-03-01|Tomcat dies periodically  |
| 6989|New|Maj|2002-03-08|Unable to read tld file during parallel JSP compil|
| 7008|Opn|Maj|2002-03-10|facade.HttpServletRequestFacade.getParameter(HttpS|
| 7013|New|Cri|2002-03-10|Entering a servlet path with non-ISO8859-1 charact|
| 7227|New|Nor|2002-03-19| directive don't work |
| 7236|New|Blk|2002-03-19|Permission denied to do thread.stop   |
| 7626|New|Nor|2002-03-29|classloader not working properly  |
| 7637|New|Cri|2002-03-30|Tomcat terminates after connecting to a database  |
| 7652|New|Cri|2002-04-01|Tomcat stalls periodically|
| 7654|New|Min|2002-04-01|Exception in preInit - java.lang.ClassCastExceptio|
| 7762|New|Enh|2002-04-05|stdout logfile handling   |
| 7785|New|Blk|2002-04-06|tomcat bug in context reloading   |
| 7789|New|Maj|2002-04-06|JSP Cookie Read/Write Fails With DNS Names|
| 7863|New|Maj|2002-04-09|I have a problem when running Tomcat with IIS |
| 8154|New|Nor|2002-04-16|logrotate script in RPM rotates non-existing file |
| 8155|New|Nor|2002-04-16|Tomcat from RPM doesn't do logrotate  |
| 8187|New|Cri|2002-04-17|Errors when Tomcat used with MS Access database   |
| 8239|New|Cri|2002-04-18|Resource temporary unavailable|
| 8263|New|Cri|2002-04-18|url-pattern easy to circumvent|
| 8297|New|Blk|2002-04-19|inetinfo.exe error ;  Also no resource found (erro|
| 8332|New|Min|2002-04-20|missing mod_jk source for apache2.0 or all mod_jk |
| 8438|New|Cri|200

cvs commit: jakarta-tomcat-connectors/jk/native2/jni jk_jni_aprImpl.c org_apache_jk_apr_AprImpl.h

2002-05-26 Thread costin


costin  02/05/26 00:38:17

  Modified:jk/native2/jni jk_jni_aprImpl.c org_apache_jk_apr_AprImpl.h
  Log:
  - removed code we don't need. ( creating and using directly the apr pools
  is overkill and dangerous, things are better handled by keeping them
  in the execution context - jk_endpoint ).
  
  - started to add the signal callbacks ( using the code in the jni channel ).
  The jni channel is not used only for in-process apache-tomcat communication,
  but for any callbacks from C to java ( i.e. you can have tomcat standalone
  using libjkjni.so to receive SIGHUP or any other callbacks we want ).
  
  - add jkInit/jkDestroy ( for component initialization )
  
  Revision  ChangesPath
  1.24  +114 -65   jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c
  
  Index: jk_jni_aprImpl.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- jk_jni_aprImpl.c  24 May 2002 04:30:07 -  1.23
  +++ jk_jni_aprImpl.c  26 May 2002 07:38:17 -  1.24
  @@ -91,7 +91,9 @@
   #include "apr_shm.h"
   #endif
   
  +#ifdef HAVE_SIGNAL
   #include "signal.h"
  +#endif
   
   static apr_pool_t *jniAprPool;
   static jk_workerEnv_t *workerEnv;
  @@ -152,55 +154,86 @@
   return 0;
   }
   
  -JNIEXPORT jlong JNICALL 
  -Java_org_apache_jk_apr_AprImpl_poolCreate(JNIEnv *jniEnv, jobject _jthis, jlong 
parentP)
  -{
  -apr_pool_t *parent;
  -apr_pool_t *child;
  -
  -parent=(apr_pool_t *)(void *)(long)parentP;
  -apr_pool_create( &child, parent );
  -return (jlong)(long)child;
  -}
  -
  -JNIEXPORT jlong JNICALL 
  -Java_org_apache_jk_apr_AprImpl_poolClear(JNIEnv *jniEnv, jobject _jthis,
  - jlong poolP)
  -{
  -apr_pool_t *pool;
  -
  -pool=(apr_pool_t *)(void *)(long)poolP;
  -apr_pool_clear( pool );
  -return 0;
  -}
  -
   /*  Signals  */
  +
   #ifdef HAVE_SIGNALS
   static struct sigaction jkAction;
   
  +/* We use a jni channel to send the notification to java
  + */
  +static jk_channel_t *jniChannel;
  +
  +/* XXX we should sync or use multiple endpoints if multiple signals
  +   can be concurent
  +*/
  +static jk_endpoint_t *signalEndpoint;
  +
   static void jk2_SigAction(int sig) {
  -fprintf(stderr, "Signal %d\n", sig );
  +jk_env_t *env;
   
   /* Make a callback using the jni channel */
  +fprintf(stderr, "Signal %d\n", sig );
  +
  +if( jk_env_globalEnv == NULL ) {
  +return;
  +}
  +
  +env=jk_env_globalEnv->getEnv( jk_env_globalEnv );
  +
  +if( jniChannel==NULL ) {
  +jniChannel=env->getByName( env, "channel.jni:jni" );
  +fprintf(stderr, "Got jniChannel %p\n", jniChannel );
  +}
  +if( jniChannel==NULL ) {
  +return;
  +}
  +if( signalEndpoint == NULL ) {
  +jk_bean_t *component=env->createBean2( env, NULL, "endpoint", NULL );
  +if( component == NULL ) {
  +fprintf(stderr, "Can't create endpoint\n" );
  +return;
  +}
  +component->init( env, component );
  +fprintf(stderr, "Create endpoint %p\n", component->object );
  +signalEndpoint=component->object;
  +}
  +
  +/* Channel:jni should be initialized by the caller */
  +
  +/* XXX make the callback */
   
  -signal( sig, jk2_SigAction );
  +jk_env_globalEnv->releaseEnv( jk_env_globalEnv, env );
  +
   }
  -#endif
  +
   
   /* XXX We need to: - preserve the old signal ( or get them ) - either
implement "waitSignal" or use invocation in jk2_SigAction
   
Probably waitSignal() is better ( we can have a thread that waits )
  -*/
  + */
   
   JNIEXPORT jint JNICALL 
   Java_org_apache_jk_apr_AprImpl_signal(JNIEnv *jniEnv, jobject _jthis, jint signalNr 
)
   {
  -#ifdef HAVE_SIGNALS
   memset(& jkAction, 0, sizeof(jkAction));
   jkAction.sa_handler=jk2_SigAction;
   sigaction((int)signalNr, &jkAction, (void *) NULL);
  -#endif
  +return 0;
  +}
  +
  +JNIEXPORT jint JNICALL 
  +Java_org_apache_jk_apr_AprImpl_sendSignal(JNIEnv *jniEnv, jobject _jthis, jint 
target ,
  +  jint signo)
  +{
  +return kill( (pid_t)target, (int)signo );
  +}
  +
  +#else /* ! HAVE_SIGNALS */
  +
  +JNIEXPORT jint JNICALL 
  +Java_org_apache_jk_apr_AprImpl_signal(JNIEnv *jniEnv, jobject _jthis, jint signalNr 
)
  +{
   return 0;
   }
   
  @@ -208,10 +241,12 @@
   Java_org_apache_jk_apr_AprImpl_sendSignal(JNIEnv *jniEnv, jobject _jthis, jint 
signo,
 jlong target)
   {
  -
   return 0;
   }
   
  +#endif
  +
  +
   /*  User related functions  */
   
   JNIEXPORT jint JNICALL 
  @@ -262,10 +297,13 @@
  'nat

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel.c

2002-05-26 Thread costin


costin  02/05/26 00:33:49

  Added:   jk/native2/common jk_channel.c
  Log:
  Common dispatcher for all channels - allow any jk channel to be called by
  the JNI code.
  
  This is not yet completed, but will reduce the work in 1/2, since the
  same code will be used on both sides and optimizations will be shared
  by all components.
  
  I hope to see in few months at least a doors channel, and maybe play
  with message queues and some windows-specific things - just for the fun
  of doing a small benchmark.
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-connectors/jk/native2/common/jk_channel.c
  
  Index: jk_channel.c
  ===
  /* = *
   *   *
   * The Apache Software License,  Version 1.1 *
   *   *
   *  Copyright (c) 1999-2001 The Apache Software Foundation.  *
   *   All rights reserved.*
   *   *
   * = *
   *   *
   * Redistribution and use in source and binary forms,  with or without modi- *
   * fication, are permitted provided that the following conditions are met:   *
   *   *
   * 1. Redistributions of source code  must retain the above copyright notice *
   *notice, this list of conditions and the following disclaimer.  *
   *   *
   * 2. Redistributions  in binary  form  must  reproduce the  above copyright *
   *notice,  this list of conditions  and the following  disclaimer in the *
   *documentation and/or other materials provided with the distribution.   *
   *   *
   * 3. The end-user documentation  included with the redistribution,  if any, *
   *must include the following acknowlegement: *
   *   *
   *   "This product includes  software developed  by the Apache  Software *
   *Foundation ."  *
   *   *
   *Alternately, this acknowlegement may appear in the software itself, if *
   *and wherever such third-party acknowlegements normally appear. *
   *   *
   * 4. The names  "The  Jakarta  Project",  "Jk",  and  "Apache  Software *
   *Foundation"  must not be used  to endorse or promote  products derived *
   *from this  software without  prior  written  permission.  For  written *
   *permission, please contact <[EMAIL PROTECTED]>.*
   *   *
   * 5. Products derived from this software may not be called "Apache" nor may *
   *"Apache" appear in their names without prior written permission of the *
   *Apache Software Foundation.*
   *   *
   * THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED WARRANTIES *
   * INCLUDING, BUT NOT LIMITED TO,  THE IMPLIED WARRANTIES OF MERCHANTABILITY *
   * AND FITNESS FOR  A PARTICULAR PURPOSE  ARE DISCLAIMED.  IN NO EVENT SHALL *
   * THE APACHE  SOFTWARE  FOUNDATION OR  ITS CONTRIBUTORS  BE LIABLE  FOR ANY *
   * DIRECT,  INDIRECT,   INCIDENTAL,  SPECIAL,  EXEMPLARY,  OR  CONSEQUENTIAL *
   * DAMAGES (INCLUDING,  BUT NOT LIMITED TO,  PROCUREMENT OF SUBSTITUTE GOODS *
   * OR SERVICES;  LOSS OF USE,  DATA,  OR PROFITS;  OR BUSINESS INTERRUPTION) *
   * HOWEVER CAUSED AND  ON ANY  THEORY  OF  LIABILITY,  WHETHER IN  CONTRACT, *
   * STRICT LIABILITY, OR TORT  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN *
   * ANY  WAY  OUT OF  THE  USE OF  THIS  SOFTWARE,  EVEN  IF  ADVISED  OF THE *
   * POSSIBILITY OF SUCH DAMAGE.   *
   *   *
   * = *
   *   *
   * This software  consists of voluntary  contributions made  by many indivi- *
   * duals on behalf of the  Apache Software Foundation.

cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_channel.h jk_workerEnv.h

2002-05-26 Thread costin


costin  02/05/26 00:31:12

  Modified:jk/native2/include jk_channel.h jk_workerEnv.h
  Log:
  Remove the duplicated init method in channel.
  
  The AJP13 callback ( used in JNI mode ) that was supposed to be use
  by the unix channel should work with all channels.
  
  Revision  ChangesPath
  1.12  +0 -10 jakarta-tomcat-connectors/jk/native2/include/jk_channel.h
  
  Index: jk_channel.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_channel.h,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- jk_channel.h  16 May 2002 20:49:53 -  1.11
  +++ jk_channel.h  26 May 2002 07:31:12 -  1.12
  @@ -118,16 +118,6 @@
   struct jk_worker *worker; 
   char *workerName; 
   
  -/** Prepare the channel, check the properties. This 
  - * will resolve the host and do all the validations.
  - * ( needed to remove the dependencies on sockets in ajp)
  - * 
  - * The channel may save or use data from the worker ( like cache
  - *  the inet addr, etc )
  - *  XXX revisit this - we may pass too much that is not needed
  - */
  -int (JK_METHOD *init)(struct jk_env *env, jk_channel_t *_this);
  -
   /** Open the communication channel
*/
   int (JK_METHOD *open)(struct jk_env *env, jk_channel_t *_this, 
  
  
  
  1.24  +4 -4  jakarta-tomcat-connectors/jk/native2/include/jk_workerEnv.h
  
  Index: jk_workerEnv.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_workerEnv.h,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- jk_workerEnv.h24 May 2002 04:35:17 -  1.23
  +++ jk_workerEnv.h26 May 2002 07:31:12 -  1.24
  @@ -58,7 +58,7 @@
   /***
* Description: Workers controller header file *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   * 
  - * Version: $Revision: 1.23 $   *
  + * Version: $Revision: 1.24 $   *
***/
   
   #ifndef JK_WORKERENV_H
  @@ -115,14 +115,14 @@
   /* Login Rejected (servlet engine -> web server) */
   #define JK_HANDLE_LOGON_ERR  0x14
   
  -/* Dispatcher for jni channel ( JNI -> web server ) */
  +/* Dispatcher for jni channel ( java->C ) */
   #define JK_HANDLE_JNI_DISPATCH 0x15
   
   /* Dispatcher for shm object ( java->C) */
   #define JK_HANDLE_SHM_DISPATCH 0x16
   
  -/* Dispatcher for unix socket channel ( java->C )*/
  -#define JK_HANDLE_UN_DISPATCH 0x17
  +/* Dispatcher for channel components ( java->C )*/
  +#define JK_HANDLE_CH_DISPATCH 0x17
   
   /* Dispatcher for mutex object  ( java->C ) */
   #define JK_HANDLE_MUTEX_DISPATCH 0x18
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_apr_socket.c jk_channel_jni.c jk_channel_socket.c jk_channel_un.c jk_workerEnv.c

2002-05-26 Thread costin


costin  02/05/26 00:30:01

  Modified:jk/native2/common jk_channel_apr_socket.c jk_channel_jni.c
jk_channel_socket.c jk_channel_un.c jk_workerEnv.c
  Log:
  Moved channels to use the init() method in jk_bean.
  
  ( all jk components will eventually be useable from java using
  the ajp 'bridge', but channels are important and need to be initialized
  corectly )
  
  Revision  ChangesPath
  1.20  +3 -2  
jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c
  
  Index: jk_channel_apr_socket.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- jk_channel_apr_socket.c   16 May 2002 23:48:27 -  1.19
  +++ jk_channel_apr_socket.c   26 May 2002 07:30:01 -  1.20
  @@ -133,8 +133,9 @@
   /** resolve the host IP ( jk_resolve ) and initialize the channel.
*/
   static int JK_METHOD jk2_channel_apr_init(jk_env_t *env,
  -  jk_channel_t *ch)
  +  jk_bean_t *chB)
   {
  +jk_channel_t *ch=chB->object;
   jk_channel_apr_private_t *socketInfo=
   (jk_channel_apr_private_t *)(ch->_privatePtr);
   int rc;
  @@ -431,7 +432,6 @@
   
   ch->recv= jk2_channel_apr_recv; 
   ch->send= jk2_channel_apr_send; 
  -ch->init= jk2_channel_apr_init; 
   ch->open= jk2_channel_apr_open; 
   ch->close= jk2_channel_apr_close; 
   ch->is_stream=JK_TRUE;
  @@ -439,6 +439,7 @@
   result->setAttribute= jk2_channel_apr_setProperty; 
   ch->mbean=result;
   result->object= ch;
  +result->init= jk2_channel_apr_init; 
   
   ch->workerEnv=env->getByName( env, "workerEnv" );
   ch->workerEnv->addChannel( env, ch->workerEnv, ch );
  
  
  
  1.22  +8 -10 jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c
  
  Index: jk_channel_jni.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- jk_channel_jni.c  19 May 2002 21:41:25 -  1.21
  +++ jk_channel_jni.c  26 May 2002 07:30:01 -  1.22
  @@ -106,7 +106,7 @@
   
   
   
  -static int JK_METHOD jk2_channel_jni_setProperty(jk_env_t *env,
  +static int JK_METHOD jk2_channel_jni_setAttribute(jk_env_t *env,
jk_bean_t *mbean, 
char *name, void *valueP)
   {
  @@ -120,8 +120,9 @@
   }
   
   static int JK_METHOD jk2_channel_jni_init(jk_env_t *env,
  -  jk_channel_t *jniW)
  +  jk_bean_t *jniWB)
   {
  +jk_channel_t *jniW=jniWB->object;
   jk_workerEnv_t *wEnv=jniW->workerEnv;
   
   if( wEnv->vm == NULL ) {
  @@ -156,7 +157,7 @@
   return JK_OK;
   }
   
  -env->l->jkLog(env, env->l, JK_LOG_INFO,"channel_jni.init():  \n" );
  +env->l->jkLog(env, env->l, JK_LOG_INFO,"channel_jni.open():  \n" );
   
   if( _this->worker != NULL )
   _this->worker->mbean->disabled=JK_TRUE;
  @@ -313,10 +314,7 @@
   if( epData->jniJavaContext != NULL){
   (*jniEnv)->DeleteGlobalRef( jniEnv, epData->jniJavaContext );
   }
  -endpoint->mbean->pool->realloc(env,endpoint->mbean->pool,0,
  -epData->carray,epData->arrayLen);
  -endpoint->mbean->pool->realloc(env,endpoint->mbean->pool,0,
  -epData,sizeof( jk_ch_jni_ep_private_t ));
  +
   endpoint->channelData=NULL;
   return JK_OK;
   
  @@ -404,7 +402,7 @@
   nbuf = (*jniEnv)->GetPrimitiveArrayCritical(jniEnv, jbuf, &iscopy);
   #else
   nbuf = (*jniEnv)->GetByteArrayElements(jniEnv, jbuf, &iscopy);
  -#endif
  + #endif
   if( iscopy )
   env->l->jkLog(env, env->l, JK_LOG_INFO,
 "channelJni.send() get java bytes iscopy %d\n", iscopy);
  @@ -545,7 +543,6 @@
   
   ch->recv= jk2_channel_jni_recv;
   ch->send= jk2_channel_jni_send; 
  -ch->init= jk2_channel_jni_init; 
   ch->open= jk2_channel_jni_open; 
   ch->close= jk2_channel_jni_close; 
   
  @@ -556,9 +553,10 @@
   sizeof(jk_channel_jni_private_t));
   ch->is_stream=JK_FALSE;
   
  -result->setAttribute= jk2_channel_jni_setProperty;
  +result->setAttribute= jk2_channel_jni_setAttribute;
   ch->mbean=result;
   result->object= ch;
  +result->init= jk2_channel_jni_init; 
   
   wEnv=env->getByName( env, "workerEnv" );
   ch->workerEnv=wEnv;
  
  
  
  1.29  +3 -2  jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c
  
  Index: jk_channel_socket.c
  ===

Re: [Proposal] Removing 64K limit in jasper 2

Re: [Proposal] Removing 64K limit in jasper 2

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi SSIServlet.java SSIServletExternalResolver.java

DO NOT REPLY [Bug 9430] - getResource() doesn't return null for invalid URLs

DO NOT REPLY [Bug 9430] New: - getResource() doesn't return null for invalid URLs

Re: [PATCH] improved HTMLManagerServlet

cvs commit: jakarta-tomcat-connectors/jk build.xml

cvs commit: jakarta-tomcat-connectors/jk/xdocs/images jakarta.gif mod_jk.jpeg pixel.gif tomcat.ico

cvs commit: jakarta-tomcat-connectors/jk/xdocs/images - New directory

cvs commit: jakarta-tomcat-connectors/jk/xdocs - New directory

Bug report for Tomcat 4 [2002/05/26]

Bug report for Tomcat 3 [2002/05/26]

cvs commit: jakarta-tomcat-connectors/jk/native2/jni jk_jni_aprImpl.c org_apache_jk_apr_AprImpl.h

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel.c

cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_channel.h jk_workerEnv.h

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_apr_socket.c jk_channel_jni.c jk_channel_socket.c jk_channel_un.c jk_workerEnv.c

16 matches

Site Navigation

Mail list logo

Footer information