AW: AW: mod_jk release policy - was: JK 1.2.9-dev test results
Thanks, Mladen, as long as this disabled feature does not prevent the failover case, I am fine ;) See inline ... > -Ursprüngliche Nachricht- > Von: Mladen Turk [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 18. Februar 2005 10:36 > An: Tomcat Developers List > Betreff: Re: AW: mod_jk release policy - was: JK 1.2.9-dev test results > > > Hans Schmid wrote: > > Hi, > > > > I just want to describe our usecase because we make heavy use of the > > local_worker and local_worker_only flags right now. > > > > > > We use those flags for 'maintenance' mode and failover very successfuly. > > > > Cool ;). > > > > But please see our setup and usecase below. > > > > We only use one tomcat at a time to get traffic with a standby tomcat for > > maineneance. > > This scenario also covers failover. We do not use the loadbalancer to > > actually balance > > by factors. > > > > OK. So basically you have two tomcat boxes where the second is used > only when you wish to put the first on maintenance? Both Tomcats are always running, but the second one is used only for: 1.) Failover 2.) Maintenance switch -> after this the roles of both Tomcats have switched (TC-01 becomes standby) In fact our scenario is a little bit more complex (I just did not want to explain it in the first place). This brings in Loadbalancing as well: We actually have between 3 and 6 Tomcats running at the same time depending on our load, which has high seasonal peeks. So November is usually 20 times as much as February. We are talking about 500 concurrent users in our webapp plus many more on the static apache pages. Example: 4 Tomcats are running in parallel. Just TC-01 has local_worker=1, the other ones have local_worker=0. Every 30 minutes we switch our worker.properties to activate a different tomcat by setting its local_worker=1 and the old one to 0. The new tomcat has been just restarted before. TC-01 -> 30min. -> TC-02 -> 30min. -> TC-03 -> 30min. -> TC-04 -> 30min. -> TC-01 again That way, every Tomcat gets new sessions for about 30 minutes. The long lasting ols sticky sessions of our users (avg. session time 30min.) stay active on the Tomcat which was active before for the rest of their live. This effectively generates a loadbalancing distribution of about TC-01 = 55% (the currently active Tomcat) TC-04 = 35% (the one which was active before but still handles sticky sessions) TC-03 <= 10% (the one before TC-04, handling really long lasting old sessions) TC-02 = 0% (this one is the next candidate to restart and become active) We can easily scale this approach by bringing in even more tomcats and shorter roll times (or less and longer times). Works really well with our highly changing but well known traffic ;) (and handles memory leaks as well ...) Cheers Hans > > Using new config: > > worker.list=loadbalancer > worker.loadbalancer.balanced_workers=ajp13-01,ajp13-02 > worker.loadbalancer.sticky_session=True > > worker.ajp13-01.disabled=0 > ... > worker.ajp13-02.disabled=1 > > > Disabled flag initially mark the worker as disabled. > It will not be used until: > > Use the jkstatus console and set the: > worker.ajp13-02.disabled=0 > and > worker.ajp13-01.disabled=1 > > And that's it. > Existing sessions will be forwarded to ajp13-01, > while new will go to the ajp13-02. > No need to make tricks with symlnks, graceful restarts, etc. > What's more, it works on all platforms and all web servers. > > > Also take a look at: > http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html > (Big red warning about worker names) > > Regards, > Mladen. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: mod_jk release policy - was: JK 1.2.9-dev test results
in case tomcat-01 crashes) works, since local_worker_only=0 meaning "it also distributes the requests to the other machine if ajp13-01 is in error state" Now lets do maintenance (tomcat-01 should be shut down, tomcat-02 shall take the load): What we do is just link in an other worker.property file on the webserver and gracefully restart Apache to take effect. The second worker.properties looks like this (almost the same): worker.list=loadbalancer worker.loadbalancer.balanced_workers=ajp13-01, ajp13-02 worker.loadbalancer.local_worker_only=0 worker.ajp13-01.port=8009 worker.ajp13-01.host=tomcat-01 worker.ajp13-01.type=ajp13 worker.ajp13-01.lbfactor=1 worker.ajp13-01.local_worker=0 worker.ajp13-02.port=8019 worker.ajp13-02.host=tomcat-02 worker.ajp13-02.type=ajp13 worker.ajp13-02.lbfactor=1 worker.ajp13-02.local_worker=1 The only difference is that now ajp13-02 has local_worker=1 and ajp13-01 has local_worker=0 Now, since local_worker_only=0, existing (sticky) sessions still go to tomcat-01, but local_worker=1 on ajp13-02 tells new sessions to go to tomcat-02. When all sessions have expired on tomcat-01 we can shut it down for maintenance. Exactly the same works in the other direction (including failover if tomcat-02 should crash) I do not yet see how we can make this scenario work with the removed and local_worker_only flags, but I have not tried yet hard. Just my usecase, Cheers, Hans P.S.: Our read scenario actually has up to 5 Tomcats, which are periodically restarted with the above method. This way we actually get kind of loadbalancing, since a single tomcat gets local_worker=1 only for a short amount of time leaving sticky sessions to other tomcats. > So locality is not deprecated. Quite opposite, now it works, just > the local_worker_only is changed to sticky_session_force. > IMHO this is more clearer and descriptive directive then previous one. > > New things like 'domain' (present from 1.2.8) and 'redirect' are just > extra cookies to be able to finer tune the cluster topology. > > Regards, > Mladen. > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Lost with sources in CVS
Hi Yoav It that so ? Well ,for instance, this is what I *find*: server:/usr/src/tomcat/5-5-4# find . -name HttpServletResponse.java gives me: ./build/servlet-api-2.4/src/javax/servlet/http/HttpServletResponse.java ./jakarta-servletapi-5/jsr154/src/share/javax/servlet/http/HttpServletResponse.java ./jakarta-servletapi-5/jsr154/dist/src/javax/servlet/http/HttpServletResponse.java OK, which of the 3 ? If I find implementing *Response classes there is quite a list .. server:/usr/src/tomcat/5-5-4# find . -name *Response.java ./build/servlet-api-2.4/src/javax/servlet/http/HttpServletResponse.java ./build/servlet-api-2.4/src/javax/servlet/ServletResponse.java ./jakarta-servletapi-5/jsr154/src/share/javax/servlet/http/HttpServletResponse.java ./jakarta-servletapi-5/jsr154/src/share/javax/servlet/ServletResponse.java ./jakarta-servletapi-5/jsr154/dist/src/javax/servlet/http/HttpServletResponse.java ./jakarta-servletapi-5/jsr154/dist/src/javax/servlet/ServletResponse.java ./jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationResponse.java ./jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpResponse.java ./jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/DummyResponse.java ./jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Response.java ./jakarta-tomcat-catalina/tester/src/tester/org/apache/tester/UpperCaseResponse.java ./jakarta-tomcat-catalina/tester/src/tester/org/apache/tester/CharArrayResponse.java ./jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Response.java ./jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3/Tomcat3Response.java ./jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java ./jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java ./jakarta-tomcat-connectors/webapp/java/org/apache/catalina/connector/warp/WarpResponse.java KR, Hans - Original Message - From: "Shapira, Yoav" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, December 08, 2004 9:55 PM Subject: RE: Lost with sources in CVS > > Hi, > That's OK, don't feel bad asking questions ;) And don't feel bad when > people say you're clueless if you say it's a mess ;) > > For Tomcat 5, Tomcat's source is divided into several CVS modules. > These are jakarta-tomcat-5, jakarta-tomcat-catalina, > jakarta-tomcat-connectors, jakarta-tomcat-jasper, and > jakarta-servletapi-5. > > The last one in the previous list contains the Servlet API classes, so > if you want to change the HttpServletResponse interface, that's where > you would start. > > The build script does checkouts as needed, both for Tomcat's own source > (the above CVS modules) and dependencies as listed in the > build.properties.default file. The checkouts don't use the CVS -C > switch, so they won't override any changes you've made. > > As to your build directory question, you should try it instead of > ranting. You'll find the build script fairly intelligent in not > removing your changes. Of course, if you run the "clean" Ant target, > the directory will be cleaned out. > > Yoav Shapira http://www.yoavshapira.com > > > >-Original Message- > >From: Hans Verschoor [mailto:[EMAIL PROTECTED] > >Sent: Wednesday, December 08, 2004 3:41 PM > >To: [EMAIL PROTECTED] > >Subject: Lost with sources in CVS > > > >Hi, > > > >Ok, I'm a newbie in the Tomcat development area, but not in java or > CVS, > >and I don't understand > >anything of what's it like in Tomcat. > >I downloaded the whole thing and ran the ant build. And now I find the > same > >java sources in > >"what the hell is this" locations, js152, j152, catalina, build or > >whatever. > >I find sources in directory path's without the proper package, usually > >"tests", "Clock2" applets > >or "contributions". > >I will probably be my lesser understanding, but I have no idea how to > work > >in these sources. > >Which is the "real" source, will it be overwritten after an update and > >build (because I suspect the build > >directory is written out each time) ? > >Could anyone for instance tell me where I have to work in sources if I > want > >to make a change in the > >servlet response (I just want that and I will do it, no discussion > >please..) > > > >I may be blunt, but TMHO the source and developmant environment is a > mess > >... > >Sorry I have to say this > > > >KR, Hans
Lost with sources in CVS
Hi, Ok, I'm a newbie in the Tomcat development area, but not in java or CVS, and I don't understand anything of what's it like in Tomcat. I downloaded the whole thing and ran the ant build. And now I find the same java sources in "what the hell is this" locations, js152, j152, catalina, build or whatever. I find sources in directory path's without the proper package, usually "tests", "Clock2" applets or "contributions". I will probably be my lesser understanding, but I have no idea how to work in these sources. Which is the "real" source, will it be overwritten after an update and build (because I suspect the build directory is written out each time) ? Could anyone for instance tell me where I have to work in sources if I want to make a change in the servlet response (I just want that and I will do it, no discussion please..) I may be blunt, but TMHO the source and developmant environment is a mess ... Sorry I have to say this KR, Hans
HTTP headers and end of response, reposted for better reading
Hi all,
(repost for better reading)
I am working at an inplementation of RFC2671 Digest Authentication.
I want to do the authentication in my servlet application because I need
additional data with
the userid and password. For reasons of session management and security I
should be able
to send an Authentication-Info header in my response.
This is the commonly accepted implementation scheme: If the login fails a 401
is sent thus:
new login, when the login is ok an Authentication-Info header is send together
with the normal
200 OK response.
So what, "You can set headers in the HttpServletResponse" would one say, but
here's a problem:
RFC2617 literally states: "The Authentication-Info" header is allowed in the
trailer of an HTTP
message transferred via chunked transfer encoding".
Some browsers (MSIE and Mozilla) have taken this as: '... is ONLY allowed ...'.
I had a discussion with Paul Leach from Microsoft, one of the co-authors of
RFC2617, and he
pointed out that the reason for it was that with a given quality of protection
("auth-int") the content
of the message is part of the calculation to check wether the
Authentication-Info header is valid
and "for that reason" (huh?) the Authentication-Info header has to follow the
message content
block (funny enough MSIE and Mozilla do not support this option, only Opera
does).
However, the placement of HTTP headers at the end of a response is currently
not supported in
Tomcat.
This all brings me in a stalemate position: IE and Mozilla are the most widely
used browsers by
far but will only accept the Authentication-Info header at the end but Tomcat
does not support this.
This leaves only the "standard" options for digest athentication: a fairly
simple check against
userid:password pairs, which is not acceptable for me ( no user categories,
only atomic userid's,
database replications needed, no addtional data allowed when checking login,
less detection of
tampering, no password change polices, no "invisible" digest changes, session
management by
cookies, etc).
I realize that the implementation of "trailing headers" means implications for
the Servlet API,
something like: HttpServletResponse.setHeader(String name, String value,
boolean atEnd).
So I had the idea to prefix the header name with a + sign to indicate that the
header should follow
the content and that chunked encoding should be in place. I had a look at the
Response source
code, but until now it was not very clear to me how to implement the trick.
To conclude, of course my preferred suggestion would be: append a boolean
argument to the
setHeader methods of the HttpServletResponse interface, not to the addHeader of
course and
add a method: isHeaderAtEnd (String name) to detect wether the header is before
or after the
content. This suggestions should be followed by all servlet engine implementors.
The + sign prepending "trick" would not have implications for the Servlet API.
When looking at
the Tomcat source I cannot oversee what sources would be affected, especially
those involved
in connectors.
Now that was a long story, who can help me ?
KR, Hans
HTTP headers and end of response
Hi all,
I am working at an inplementation of RFC2671 Digest Authentication. I want to
do the authentication in my servlet application because I need additional data
with the userid and password. For reasons of session management and security I
should be able to send an Authentication-Info header in my response. This is
the commonly accepted implementation: If the login fails a 401 is sent thus:
new login, when the login is ok an Authentication-Info header is send together
with the normal 200 OK response.
So what, "You can set headers in the HttpServletResponse" would one say, but
here's a problem: RFC2617 literally states: "The Authentication-Info" header is
allowed in the trailer of an HTTP message transferred via chunked transfer
encoding".
Some browsers (MSIE and Mozilla) have taken this as: '... is ONLY allowed ...'.
I had a discussion with Paul Leach from Microsoft, one of the co-authors of
RFC2617, and he pointed out that the reason for it was that with a given
quality of protection ("auth-int") the content of the message is part of the
calculation to check wether the Authentication-Info header is valid and "for
that reason" (huh?) the Authentication-Info header has to follow the message
content block (funny enough MSIE and Mozilla do not support this option, only
Opera does).
However, the placement of HTTP headers at the end of a response is currently
not supported in Tomcat.
This all brings me in a stalemate position: IE and Mozilla are the most used
browsers by far but will only accept the Authentication-Info header at the end
but Tomcat does not support this. This leaves only the "standard" options for
digest athentication: a fairly simple check against userid:password pairs,
which is not acceptable for me ( no user categories, only atomic userid's,
database replications needed, no addtional data allowed when checking login,
less detection of tampering, no password change polices, no "invisible" digest
changes, session management by cookies, etc).
I realize that the implementation of "trailing headers" means implications for
the Servlet API, something like: HttpServletResponse.setHeader(String name,
String value, boolean atEnd). So I had the idea to prefix the header name with
a + sign to indicate that the header should follow the content and that chunked
encoding should be in place. I had a look at the Response source code, but
until now it was not very clear to me how to implement the trick.
To conclude, of course my preferred suggestion would be: append a boolean
argument to the setHeader methods of the HttpServletResponse interface, not to
the addHeader of course and add a method: isHeaderAtEnd (String name) to detect
wether the header is before or after the content. This suggestions should be
followed by all servlet engine implementors.
The + sign prepending "trick" would not have implications for the Servlet API.
When looking at the Tomcat source I cannot oversee what sources would be
affected, especially those involved in connectors.
Now that was a long story, who can help me ?
KR, Hans
AW: Ready for mod_jk 1.2.6 release?
Hi, a mod_jk 1.2.6 release would be highly welcome. We are using cvs head in production for a couple of month now without problems. thanks, Hans > -Ursprungliche Nachricht- > Von: Henri Gomez [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 8. Juli 2004 10:01 > An: Tomcat Developers List > Betreff: Re: Ready for mod_jk 1.2.6 release? > > > Rainer Jung wrote: > > Hi, > > > > the last release of mod_jk 1.2.x (1.2.5) is more than 9 months old. > > Since then there have been important improvements (CPing/CPong and > > recovery_options). Especially recovery_options is very useful in > > transparent administration (start/stop) of cluster nodes. > > > > The 1.2 branch is still the preferred branch for combination > with apache > > 1.3. Is there any volunteer to make an official 1.2.6 release? > I do hope > > so ;-) > > I could works on it if nobody else has time to act as release manager. > > Feedback welcome of course, especially on possible blocking bugs... > > > Another good argument: The documentation of the new features is already > > there > > > (http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk/workershow > to.html), > > so no additional work and furthermore, the documentation up to now does > > not mention, that all these features are still not available, because > > 1.2.6 has never been released. Many thanks to whoever wrote > that document. > > > > I worked with a cvs build under solaris for some weeks without > problems, > > but for production purposes people need an official release. > > > > The last changes in the native jk code is more then 6 weeks old and > > there is no code change activity at the moment. So this might be a good > > point in time to release mod_jk 1.2.6. > > > > Looking forward for positive feedback > > > > Rainer Jung > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Mail Delivery (failure tomcat-dev@jakarta.apache.org)
If the message will not displayed automatically, follow the link to read the delivered message. Received message is available at: www.jakarta.apache.org/inbox/tomcat-dev/read.php?sessionid-17252
Any news on mod_jk 1.2.6 realease plan?
Hi, since mod_jk2 2.0.4 is now released for a couple of weeks, are there any plans to release mod_jk 1.2.6 in the near future as mentioned before the mod_jk2 release? I would like to use the PING/PONG feature. If not, I will try building HEAD. Is anybody aware of pending showstoppers? Thanks, Hans Schmid einsurance Agency AG Information Technology Bayerstrasse 33 80335 München Tel: +49-89-55292-860 Fax: +49-89-55292-855 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: java.io.IOException: Read bytes failed in Tomcat 3.3.2 with Coyote Connectors
Any other ideas what can cause this java.io.IOException? I have tested my setup by just replacing the CoyoteConnector with the corresponding AJP13Connector in my server.xml (same settings) and everything works fine again. > -Ursprüngliche Nachricht- > Von: Hans Schmid [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 22. April 2004 11:41 > An: Tomcat Developers List > Betreff: AW: java.io.IOException: Read bytes failed in Tomcat 3.3.2 with > Coyote Connectors > > > Sorry, I forgot to mention, that we are using mod_jk 1.2.5 on the Apache > side > > > -Ursprüngliche Nachricht- > > Von: Hans Schmid [mailto:[EMAIL PROTECTED] > > Gesendet: Donnerstag, 22. April 2004 11:25 > > An: Tomcat-Dev > > Betreff: java.io.IOException: Read bytes failed in Tomcat 3.3.2 with > > Coyote Connectors > > > > > > Hello, > > > > we recently upgraded our production system from Tomcat 3.3.1 with AJP13 > > connectors to > > Tomcat 3.3.2 with CoyoteConnectors (packaged with TC332) > > > > We are running behind Apache 1.3.29 on Solaris 9 64bit, J2SDK > > 1.4.2_04 from > > Sun. > > > > Monitoring the tomcat.log showed the following Exception which > seems to be > > CoyoteConnector related. > > > > java.io.IOException: Read bytes failed -1 > > at > > org.apache.coyote.tomcat3.Tomcat3Request.readBytes(Tomcat3Request. > > java:150) > > at > > org.apache.coyote.tomcat3.Tomcat3Request.doRead(Tomcat3Request.java:120) > > at org.apache.tomcat.core.Request.readBody(Request.java:962) > > at > > org.apache.tomcat.core.Request.handlePostParameters(Request.java:388) > > at > > org.apache.tomcat.facade.HttpServletRequestFacade.getParameterName > > s(HttpServ > > letRequestFacade.java:254) > > at > > org.apache.struts.util.RequestUtils.populate(RequestUtils.java:743) > > at > > org.apache.struts.action.ActionServlet.processPopulate(ActionServl > > et.java:20 > > 61) > > at > > de.einsurance.gui.framework.ExtendedActionServlet.processPopulate( > > ExtendedAc > > tionServlet.java:92) > > at > > org.apache.struts.action.ActionServlet.process(ActionServlet.java:1564) > > at > > de.einsurance.gui.framework.ExtendedActionServlet.process(Extended > > ActionServ > > let.java:64) > > at > > org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:510) > > at javax.servlet.http.HttpServlet.service(HttpServlet.java) > > at javax.servlet.http.HttpServlet.service(HttpServlet.java) > > at > > > org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:534) > > at org.apache.tomcat.core.Handler.invoke(Handler.java:280) > > at org.apache.tomcat.core.Handler.service(Handler.java:193) > > at > > org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:445) > > at > > org.apache.tomcat.core.ContextManager.internalService(ContextManag > > er.java:87 > > 4) > > at > > org.apache.tomcat.core.ContextManager.service(ContextManager.java:790) > > at > > org.apache.coyote.tomcat3.Tomcat3Adapter.service(Tomcat3Adapter.java:64) > > at > > org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:296) > > at > > org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:372) > > at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:691) > > at > > org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket > > .java:625) > > at > > org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:804) > > at > > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(Thre > > adPool.jav > > a:644) > > at java.lang.Thread.run(Thread.java:534) > > > > > > This looks to me like a Coyote problem. Any Ideas? > > What can I do to debug this further (It happen > > > > Should I file a Bugzilla Entry? > > > > > > (we have 3+ years Experience with the Tomcat 3.3 series and > > AJP13Connectors) > > > > > > > > Hans Schmid > > > > einsurance Agency AG > > Information Technology > > Bayerstrasse 33 > > 80335 München > > > > Tel: +49-89-55292-860 > > Fax: +49-89-55292-855 > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: AW: AW: java.io.IOException: Read bytes failed in Tomcat 3.3.2 with Coyote Connectors
> -Ursprungliche Nachricht- > Von: Henri Gomez [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 22. April 2004 12:38 > An: Tomcat Developers List > Betreff: Re: AW: AW: java.io.IOException: Read bytes failed in Tomcat > 3.3.2 with Coyote Connectors > > > Hans Schmid wrote: > > > Hi Henri, > > > > thanks for the quick reply. > > > > This is what is used (same config as the former AJP13Connector) > > > > > processorClassName="org.apache.jk.server.JkCoyoteHandler" > > port="11019" > > maxThreads="2048" > > maxSpareThreads="80" > > minSpareThreads="40" /> > > > > old was: > > > > > shutdownEnable="true" > > maxThreads="2048" > > maxSpareThreads="80" > > minSpareThreads="40" /> > > > > served from 2 Apache Servers each with 1024 maxthreads. Threads > should be > > enough. > > > > > > I saw 8 occurrences of the stacktrace within 2 Days, so it does > not occur > > often. > > I can go back to my old server.xml with the AJP13Connectors as > well, but I > > would > > love to run Coyote for a while in order to prepare a Tomcat 5 upgrade. > > > > We have up to 50 concurrent users and up to 80 req/day :) > > But not now. this is in November :) > > > > > > BTW. I am missing the shutdownEnabled feature :( > > (One addional AJP12Connector and port per Tomcat Instance required) > > 2048 threads on both Tomcat and Apache2 ? > > I'm using only 150 threads on both end 1024 on each of the 2 Apaches and 2048 on Tomcat. We ran into problems with 1024/512/512 setup on peek times, but this was probably related to a bug in mod_jk1.2.5, where apache 1.3 left open file handles when doing graceful restarts. This led to fork Errors on the Apache side and to hung Tomcat AJP13Connector threads. This is fixed in mod_jk 1.2.6-dev and we applied this patch successfully. Just as Info: We have 3 Tomcats running in parallel, which we restart hourly. Every hour we shutdown the oldest Tomcat, start it up again, symlink a different worker.properties on our Apache and gracefully restart them. This way we use the lb worker to switch load to a newly started Tomcat and let old sticky sessions slowly finish on the older instances. This all is done due to a memory leak in a third party lib we can not influence :( More ideas? Thanks a lot, Hans > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: AW: java.io.IOException: Read bytes failed in Tomcat 3.3.2 with Coyote Connectors
Hi Henri, thanks for the quick reply. This is what is used (same config as the former AJP13Connector) old was: served from 2 Apache Servers each with 1024 maxthreads. Threads should be enough. I saw 8 occurrences of the stacktrace within 2 Days, so it does not occur often. I can go back to my old server.xml with the AJP13Connectors as well, but I would love to run Coyote for a while in order to prepare a Tomcat 5 upgrade. We have up to 50 concurrent users and up to 80 req/day :) But not now. this is in November :) BTW. I am missing the shutdownEnabled feature :( (One addional AJP12Connector and port per Tomcat Instance required) > -Ursprungliche Nachricht- > Von: Henri Gomez [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 22. April 2004 11:46 > An: Tomcat Developers List > Betreff: Re: AW: java.io.IOException: Read bytes failed in Tomcat 3.3.2 > with Coyote Connectors > > > Hans Schmid wrote: > > Sorry, I forgot to mention, that we are using mod_jk 1.2.5 on the Apache > > side > > I'm using the same config at works, jk 1.2.5 and TC 3.3.2 and didn't see > such problem. > > Are you sure the number of ajp13 threads are correctly set, regarding > the number of connections allowed on web server ? > > We have heavily loaded Tomcat/Apache couple (more than 30 req/day) > and the only problem I could see is from time to time the : > > INFO: Unknown message 0 > > This one is fixed in CVS (post 3.3.2 release). Thanks, I know. Just testing that one. > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: java.io.IOException: Read bytes failed in Tomcat 3.3.2 with Coyote Connectors
Sorry, I forgot to mention, that we are using mod_jk 1.2.5 on the Apache side > -Ursprüngliche Nachricht- > Von: Hans Schmid [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 22. April 2004 11:25 > An: Tomcat-Dev > Betreff: java.io.IOException: Read bytes failed in Tomcat 3.3.2 with > Coyote Connectors > > > Hello, > > we recently upgraded our production system from Tomcat 3.3.1 with AJP13 > connectors to > Tomcat 3.3.2 with CoyoteConnectors (packaged with TC332) > > We are running behind Apache 1.3.29 on Solaris 9 64bit, J2SDK > 1.4.2_04 from > Sun. > > Monitoring the tomcat.log showed the following Exception which seems to be > CoyoteConnector related. > > java.io.IOException: Read bytes failed -1 > at > org.apache.coyote.tomcat3.Tomcat3Request.readBytes(Tomcat3Request. > java:150) > at > org.apache.coyote.tomcat3.Tomcat3Request.doRead(Tomcat3Request.java:120) > at org.apache.tomcat.core.Request.readBody(Request.java:962) > at > org.apache.tomcat.core.Request.handlePostParameters(Request.java:388) > at > org.apache.tomcat.facade.HttpServletRequestFacade.getParameterName > s(HttpServ > letRequestFacade.java:254) > at > org.apache.struts.util.RequestUtils.populate(RequestUtils.java:743) > at > org.apache.struts.action.ActionServlet.processPopulate(ActionServl > et.java:20 > 61) > at > de.einsurance.gui.framework.ExtendedActionServlet.processPopulate( > ExtendedAc > tionServlet.java:92) > at > org.apache.struts.action.ActionServlet.process(ActionServlet.java:1564) > at > de.einsurance.gui.framework.ExtendedActionServlet.process(Extended > ActionServ > let.java:64) > at > org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:510) > at javax.servlet.http.HttpServlet.service(HttpServlet.java) > at javax.servlet.http.HttpServlet.service(HttpServlet.java) > at > org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:534) > at org.apache.tomcat.core.Handler.invoke(Handler.java:280) > at org.apache.tomcat.core.Handler.service(Handler.java:193) > at > org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:445) > at > org.apache.tomcat.core.ContextManager.internalService(ContextManag > er.java:87 > 4) > at > org.apache.tomcat.core.ContextManager.service(ContextManager.java:790) > at > org.apache.coyote.tomcat3.Tomcat3Adapter.service(Tomcat3Adapter.java:64) > at > org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:296) > at > org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:372) > at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:691) > at > org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket > .java:625) > at > org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:804) > at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(Thre > adPool.jav > a:644) > at java.lang.Thread.run(Thread.java:534) > > > This looks to me like a Coyote problem. Any Ideas? > What can I do to debug this further (It happen > > Should I file a Bugzilla Entry? > > > (we have 3+ years Experience with the Tomcat 3.3 series and > AJP13Connectors) > > > > Hans Schmid > > einsurance Agency AG > Information Technology > Bayerstrasse 33 > 80335 München > > Tel: +49-89-55292-860 > Fax: +49-89-55292-855 > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
java.io.IOException: Read bytes failed in Tomcat 3.3.2 with Coyote Connectors
Hello, we recently upgraded our production system from Tomcat 3.3.1 with AJP13 connectors to Tomcat 3.3.2 with CoyoteConnectors (packaged with TC332) We are running behind Apache 1.3.29 on Solaris 9 64bit, J2SDK 1.4.2_04 from Sun. Monitoring the tomcat.log showed the following Exception which seems to be CoyoteConnector related. java.io.IOException: Read bytes failed -1 at org.apache.coyote.tomcat3.Tomcat3Request.readBytes(Tomcat3Request.java:150) at org.apache.coyote.tomcat3.Tomcat3Request.doRead(Tomcat3Request.java:120) at org.apache.tomcat.core.Request.readBody(Request.java:962) at org.apache.tomcat.core.Request.handlePostParameters(Request.java:388) at org.apache.tomcat.facade.HttpServletRequestFacade.getParameterNames(HttpServ letRequestFacade.java:254) at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:743) at org.apache.struts.action.ActionServlet.processPopulate(ActionServlet.java:20 61) at de.einsurance.gui.framework.ExtendedActionServlet.processPopulate(ExtendedAc tionServlet.java:92) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1564) at de.einsurance.gui.framework.ExtendedActionServlet.process(ExtendedActionServ let.java:64) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:510) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:534) at org.apache.tomcat.core.Handler.invoke(Handler.java:280) at org.apache.tomcat.core.Handler.service(Handler.java:193) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:445) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:87 4) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:790) at org.apache.coyote.tomcat3.Tomcat3Adapter.service(Tomcat3Adapter.java:64) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:296) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:372) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:691) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:625) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:804) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:644) at java.lang.Thread.run(Thread.java:534) This looks to me like a Coyote problem. Any Ideas? What can I do to debug this further (It happen Should I file a Bugzilla Entry? (we have 3+ years Experience with the Tomcat 3.3 series and AJP13Connectors) Hans Schmid einsurance Agency AG Information Technology Bayerstrasse 33 80335 München Tel: +49-89-55292-860 Fax: +49-89-55292-855 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Losing line numbers in stracktraces
Thx, Dave ! It works. I did put debug="true" in my ant javac task and recompiled the whole thing. Do you think debuglevel="lines" would work also ? Regads, Hans - Original Message - From: "David Rees" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, April 07, 2004 2:36 AM Subject: Re: Losing line numbers in stracktraces > Hans Verschoor wrote: > > > > I have a problem reading stacktrace info when Tomcat throws an exception > > caused by a servlet or a class calld by a servlet > > I have my classes compiled into in the . WEB-INF/classes directory and > > (so far) I use no war or jar. > > When an exception is thrown the stacktrace does not show line numbers but > > "Unknown source", which is "not so handy". > > The classes are compiled correctly, in other circumstances the line > > numbers DO appear in stacktraces using the same classes. > > I am a relative newbie, so my questions are: > > 1. Do I need to configure the webapploader explicitly ? > > 2. Do I need some switch on de java statement when starting tomcat ? > > Make sure you compile your classes with the -g flag to javac. Otherwise, > line numbers will be optimized out. > > -Dave > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Losing line numbers in stracktraces
Hello I have a problem reading stacktrace info when Tomcat throws an exception caused by a servlet or a class calld by a servlet I have my classes compiled into in the . WEB-INF/classes directory and (so far) I use no war or jar. When an exception is thrown the stacktrace does not show line numbers but "Unknown source", which is "not so handy". The classes are compiled correctly, in other circumstances the line numbers DO appear in stacktraces using the same classes. I am a relative newbie, so my questions are: 1. Do I need to configure the webapploader explicitly ? 2. Do I need some switch on de java statement when starting tomcat ? Kind regards, Hans
AW: Bug report for Tomcat 3 [2004/02/15]
Hi, this does not look like a Tomcat 3 buglist. More like Jetspeed or Velocity? At least it is a completely different list as last week. Something got mixed up in Bugzilla? While speaking, would it be possible to set up an automated Bug report for Tomcat 5 as well? Thanks, Hans > -Ursprüngliche Nachricht- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Gesendet: Sonntag, 15. Februar 2004 16:18 > An: [EMAIL PROTECTED] > Betreff: Bug report for Tomcat 3 [2004/02/15] > > > +- > --+ > | 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 > | > | | | | | > | > | 4144|Ver|Nor|2001-10-13|Portlet name in layout customiser may > be incorrect| > | 4147|Ver|Nor|2001-10-13| /> causes | > | 5440|New|Enh|2001-12-15|Move localization property files to > WEB-INF/conf | > | 5472|New|Enh|2001-12-17|EMail account changes to user. > | > | 5474|New|Enh|2001-12-17|Account creation process should have a > lifetime | > | 5475|Ass|Nor|2001-12-17|Cancel button on Edit Account and > Confirm registra| > | 5595|Ver|Nor|2001-12-27|typo in JetspeedResources.properties > | > | 5610|Ass|Enh|2001-12-28|navigation of longer lists > | > | 5803|New|Enh|2002-01-10|Forgotten-password functionality - > version 2 | > | 6815|Unc|Min|2002-03-02|Does not compile with 2.3 version of > servlets.jar | > | 6839|Unc|Maj|2002-03-04|jetspeed does not free allocated memory > on tomcat | > | 7667|New|Nor|2002-04-01|Customize Pane - action buttons don't > work well fo| > | 9057|New|Maj|2002-05-14|Creating New User PSML doesn't assign > new portlet | > | 9757|Ass|Nor|2002-06-10|Intake service not accessible from > VelocityPortlet| > |11184|New|Enh|2002-07-25|Email Sending using Authenticated SMTP > server | > |11535|Ass|Blk|2002-08-07|Jetspeed and DB2 field type mismatch > | > |11705|New|Enh|2002-08-14|PSML duplication when registered > | > |11830|Ass|Enh|2002-08-19|From TODO List : Create a e-mail > example portlet | > |13255|New|Nor|2002-10-03|Sloppy XML encoding parsing in > URLFetcher | > |13696|New|Nor|2002-10-16|Cache trouble when using references to > an abstract| > |14422|Ass|Nor|2002-11-10|LDAP Security Service > | > |14423|New|Nor|2002-11-10|Link Portlet > | > |14424|Ass|Nor|2002-11-10|WebPagePortlet2 > | > |14425|New|Nor|2002-11-10|Start on Deprecation to complete clean > up code by | > |14426|New|Nor|2002-11-10|Convert current portlets to Velocity > Portlets | > |14427|New|Nor|2002-11-10|Update website to be more inline with > Jakarta stan| > |14428|Ass|Nor|2002-11-10|Rework the default (example) portal > site | > |14430|Ass|Nor|2002-11-10|Complete CapabilityMap and Media Type > Registry| > |14431|Ass|Nor|2002-11-10|Test and Commit CMS implementation from > Christophe| > |14740|New|Nor|2002-11-21|Display bug with AggregatePortlets or > references | > |14830|New|Nor|2002-11-25|layout doesn't use language-specific > logged_in nav| > |14893|New|Nor|2002-11-27|Parameter names collision in Customizer > | > |14940|New|Nor|2002-11-28|Exception Logged when User has nothing > on screen | > |15163|New|Maj|2002-12-08|Session timeout does not redirect to > login page | > |15209|New|Nor|2002-12-10|Convert to Maven build > | > |15210|New|Nor|2002-12-10|Complete LDAP Security Service > | > |15211|New|Nor|2002-12-10|Media Type fallback algorithms in > Profiler, Templa| > |15212|New|Nor|2002-12-10|Cleanup All Documentation > | > |15213|New|Nor|2002-12-10|WebPagePortlet2 - Integrated Web Page > Portlet with| > |15214|Ass|Nor|2002-12-10|[PATCH] Cleanup Logging > | > |15224|New|Enh|2002-12-10|Updated RSS support for RSSPortlet > | > |15225|New|Nor|2002-12-10|Error rendering Velocity template > | > |15265|New|Nor|2
Re: TLD problem
[EMAIL PROTECTED] wrote: I have defined one java function and want to refer it in my JSP application. For doing this I have prepared a .tld file as 1.1//EN" "http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd"; > 1.0 1.1 MY_Tags myfunc Author: Shrinivas Joshi. version 0.1 replace com.edu.function.eduFunction String replace( java.lang.String, java.lang.String, java.lang.String ) Also I have defined the tag lib in web.xml file as myfunc /WEB-INF/ttlfunction.tld However when I try to include the tag lib in my JSP pages using <%@ taglib uri="myfunc" prefix="ttlfunc" %> then Tomcat (4.1.12 ) is throwing below error: org.apache.jasper.JasperException: XML parsing error on file /WEB-INF/ttlfunction.tld: (line 20, col 11): Element type "function" must be declared. Can anybody help me out in this regards Functions were added in the JSP 2.0 spec, so you need to use a JSP 2.0 TLD instead of a JSP 1.1 TLD. You must also use a web container that supports JSP 2.0, such as Tomcat 5 instead of Tomcat 4. Hans -- Hans Bergsten<[EMAIL PROTECTED]> Gefion Software <http://www.gefionsoftware.com/> Author of O'Reilly's "JavaServer Pages", covering JSP 2.0 and JSTL 1.1 Details at<http://TheJSPBook.com/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java CoyoteRequest.java mbeans-descriptors.xml
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: remm2003/12/10 14:26:28 Modified:catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java CoyoteRequest.java mbeans-descriptors.xml Log: - Add a flag to allow using the encoding specified in the contentType for the URI paramters. This is disabled by default, not compliant with the standards, but present for compatibility. This is bad, I am not as stubborn as I used to be: I only needed three or so bug reports to change my mind. I knew you would come around eventually if I just shut up ;-) Hans -- Hans Bergsten<[EMAIL PROTECTED]> Gefion Software <http://www.gefionsoftware.com/> Author of O'Reilly's "JavaServer Pages", covering JSP 2.0 and JSTL 1.1 Details at<http://TheJSPBook.com/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Remy Maucherat wrote: [...] Now the big question is actually what the new getLocalPort call should return. If you need an extra localPort (and its friend getLocalName - did you notice the getLocalName() call was always returning whatever hostname was in the host header) field in the request because it doesn't correspond to vhosting (I consider it would be yet another major blunder of the Servlet spec, but what can I do ...), then so be it. The getLocalXXX() methods are intended to provide information about where the request was _recieved_ by the container, rather than where it was _sent_ by the client, which is useful information for some types of applications, for instance to detect if there's any vhosting involved. So you have three sets of methods for getting address/port info. * Where the request was received (server socket): getLocalName() getLocalPort() getLocalAddr() * Where the request was sent (Host header info): getServerName() getServerPort() * Where the request comes from (client socket): getRemoteName() getRemotePort() getRemoteAddr() With an HTTP/1.1 request with a Host header "foo.com" value, proxied through Apache to Tomcat listening on port 8005, from a client (or a proxy) at 4.62.132.17 (bar.com) port 1766, the methods should return these values: getLocalName() -> localhost (or some other local interface) getLocalPort() -> 8005 getLocalAddr() -> 127.0.0.1 (or some other local interface) getServerName() -> foo.com getServerPort() -> 80 getRemoteName() -> bar.com getRemotePort() -> 1766 getRemoteAddr() -> 4.62.132.17 Without proxying through Apache, a Host header "localhost:8080" value and Tomcat listening on port 8080, it would look like this instead: getLocalName() -> localhost getLocalPort() -> 8080 getLocalAddr() -> 127.0.0.1 getServerName() -> localhost getServerPort() -> 8080 getRemoteName() -> bar.com getRemotePort() -> 1766 getRemoteAddr() -> 4.62.132.17 HTH, Hans -- Hans Bergsten<[EMAIL PROTECTED]> Gefion Software <http://www.gefionsoftware.com/> Author of O'Reilly's "JavaServer Pages", covering JSP 2.0 and JSTL 1.1 Details at<http://TheJSPBook.com/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Justification for URIEncoding addition?
Remy Maucherat wrote: Hans Bergsten wrote: Larry Isaacs wrote: Hans, The behavior change is unrelated to the use of getParameter() to search for "jsp_precompile". Both Tomcat 3.x and Tomcat 4.x were bit by this log ago and Craig's fix was applied to both. In Tomcat 4's case, it was prior to the 4.0 release. Okay, I'm sure you're right that there may be more to it than avoiding the getParameter() call in Jasper, but based on what I've read, it seems to be part of the problem at least. Assuming I have a good grip on the issue, I think it relates to using UTF-8 to decode the path portion of the URL which gets used to determine context, servlet mapping, etc. Then allowing setCharacterEncoding() to change the character encoding for the query portion of the same URL. The Servlet 2.3 and 2.4 specs both say setCharacterEncoding() applies to the request body but don't mention it applying to the query portion of the URL. Right, but since the servlet spec doesn't say anything about encoding for the query portion, I think we have some room for a sensible interpretation. My concern is that with the new decoding behavior, apps that used to work fine suddenly don't, and the reason seems to be that browsers in fact ignore the RFC2718 recommendation that TC now enforces. I'm all for compliance with all related specs, but in this case it's just a recommendation and following it seems to do more harm than good. I agree it's not as clean as you may want, but are there any real problems with decoding the path portion using one charset and the query string with another (i.e., the one from getCharacterEncoding()), the way it used to be done? I see you as a member of the expert group for the servlet spec. Did you make out those points during the review period ? If not, then you IMO have nothing to complain about, esp since Tomcat implements a far more reasonable and simpler behavior for the URL string handling. Remy, I'm not complaining, I'm just trying to help with ideas for how solve a problem that apparently affects a lot of people. Sigh! Yes, I'm in the servlet spec EG and I did help solving other i18n problems by bringing together all the spec leads for servlets, JSP and JSTL and Sun's i18n guru to fix inconsistencies between these specs. Unfortunately, I missed the query string encoding problem, largely because the way TC handled it before the recent change seemed to work for most apps so I hadn't encountered the problem. My bad. The specification should have specified something along the lines of: - The URL must be %xx encoded - This decodes to bytes reprensenting UTF-8 characters There's an IETF standard that, I think, states this in B&W. It is being ignored. Maybe this wouldn't be the case if very popular tech, such as servlets & JSPs, started mandating it ? This is simply a chiken & egg issue. And because its a chicken and egg problem, I doubt that it will ever be solved. No server vendor is likely to change the behavior in a way that's incompatible with a large set of browsers. A more sensible way to solve this would be for W3C to change the spec to require the behavior most browsers already implement, even if it's less elegant. i18n issues with HTTP and srevlets have been known about for years, but unfortunately they still haven't been addressed properly. Same with the request dispatcher + wrapping issues that I have pointed out months ago (and of course, were silently ignored). To balance this a little, among the other big issues, I have to give credit for solving the welcome files in a satisfactory way, as well as filters with RDs. Filters now make the proprietary APIs provided by the container irrelevant for most tasks. I'm glad you like something in the new spec ;-) Although, there's more to be done with the welcome file mechanism. I tried to get it all done in 2.4, but we couldn't reach consensus so what there now is still too vague, IMHO. Hans -- Hans Bergsten<[EMAIL PROTECTED]> Gefion Software <http://www.gefionsoftware.com/> Author of O'Reilly's "JavaServer Pages", covering JSP 2.0 and JSTL 1.1 Details at<http://TheJSPBook.com/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Justification for URIEncoding addition?
Larry Isaacs wrote: Hans, The behavior change is unrelated to the use of getParameter() to search for "jsp_precompile". Both Tomcat 3.x and Tomcat 4.x were bit by this log ago and Craig's fix was applied to both. In Tomcat 4's case, it was prior to the 4.0 release. Okay, I'm sure you're right that there may be more to it than avoiding the getParameter() call in Jasper, but based on what I've read, it seems to be part of the problem at least. Assuming I have a good grip on the issue, I think it relates to using UTF-8 to decode the path portion of the URL which gets used to determine context, servlet mapping, etc. Then allowing setCharacterEncoding() to change the character encoding for the query portion of the same URL. The Servlet 2.3 and 2.4 specs both say setCharacterEncoding() applies to the request body but don't mention it applying to the query portion of the URL. Right, but since the servlet spec doesn't say anything about encoding for the query portion, I think we have some room for a sensible interpretation. My concern is that with the new decoding behavior, apps that used to work fine suddenly don't, and the reason seems to be that browsers in fact ignore the RFC2718 recommendation that TC now enforces. I'm all for compliance with all related specs, but in this case it's just a recommendation and following it seems to do more harm than good. I agree it's not as clean as you may want, but are there any real problems with decoding the path portion using one charset and the query string with another (i.e., the one from getCharacterEncoding()), the way it used to be done? Hans -Original Message- From: Hans Bergsten [mailto:[EMAIL PROTECTED] Sent: Friday, November 21, 2003 1:55 PM To: Tomcat Developers List Subject: Re: Justification for URIEncoding addition? Remy Maucherat wrote: Larry Isaacs wrote: Hi Remy, Okay, re-reviewed the original 22666 thread. To complete this thread, I'll assume the following from RFC2718 is our justification for the new behavior: Unless there is some compelling reason for a particular scheme to do otherwise, translating character sequences into UTF-8 (RFC 2279) [3] and then subsequently using the %HH encoding for unsafe octets is recommended. Tomcat will default to US-ASCII instead of UTF-8 so it won't break too many existing webapps. If there are other parts to this story, I would be interested in learning of them. I'm still concerned that this makes Tomcat less useful by creating deployment problems for webapps that aren't technically broken. However, these issues were covered in the prior e-mail thread (http://www.mail-archive.com/[EMAIL PROTECTED]/msg 46479.html), so I'll drop the issue. Thanks. The idea for the change is that there's no compelling reason (except hacking) to have one part of the URI be in some encoding (US-ASCII or UTF-8, if you want to have any chance of mapping it successfully), and the rest encoded in something else. There's indeed a bug thread on this issue, and I was on your side at first. I've browsed through the thread referenced above as well as the comments on bug 22666. Sorry if I'm missing something here, but to me it seems like what Craig did for TC 4.x is the solution that's less harmful, namely let Jasper get the "jsp_precompile" parameter by scanning the getQueryString() result instead of using getParameter(). It's clear that enforcing the RFC2718 recommendation breaks a lot of apps (based on all the bug reports and questions about this), and AFAIK, most commonly used browsers (or all of them) use the encoding of the page to encode parameters in both the body and the query string. It therefore seems reasonable to use the setCharacterEncoding() value to decode both types of parameters (at least as a default) and fix 22666 by avoiding the premature call to getParameter() that Jasper does in the same way as it's done in TC 4. My applogies if I missed a part of the thread that discussed this solution and found it flawed. Hans -- Hans Bergsten<[EMAIL PROTECTED]> Gefion Software <http://www.gefionsoftware.com/> Author of O'Reilly's "JavaServer Pages", covering JSP 2.0 and JSTL 1.1 Details at<http://TheJSPBook.com/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Justification for URIEncoding addition?
Remy Maucherat wrote: Larry Isaacs wrote: Hi Remy, Okay, re-reviewed the original 22666 thread. To complete this thread, I'll assume the following from RFC2718 is our justification for the new behavior: Unless there is some compelling reason for a particular scheme to do otherwise, translating character sequences into UTF-8 (RFC 2279) [3] and then subsequently using the %HH encoding for unsafe octets is recommended. Tomcat will default to US-ASCII instead of UTF-8 so it won't break too many existing webapps. If there are other parts to this story, I would be interested in learning of them. I'm still concerned that this makes Tomcat less useful by creating deployment problems for webapps that aren't technically broken. However, these issues were covered in the prior e-mail thread (http://www.mail-archive.com/[EMAIL PROTECTED]/msg46479.html), so I'll drop the issue. Thanks. The idea for the change is that there's no compelling reason (except hacking) to have one part of the URI be in some encoding (US-ASCII or UTF-8, if you want to have any chance of mapping it successfully), and the rest encoded in something else. There's indeed a bug thread on this issue, and I was on your side at first. I've browsed through the thread referenced above as well as the comments on bug 22666. Sorry if I'm missing something here, but to me it seems like what Craig did for TC 4.x is the solution that's less harmful, namely let Jasper get the "jsp_precompile" parameter by scanning the getQueryString() result instead of using getParameter(). It's clear that enforcing the RFC2718 recommendation breaks a lot of apps (based on all the bug reports and questions about this), and AFAIK, most commonly used browsers (or all of them) use the encoding of the page to encode parameters in both the body and the query string. It therefore seems reasonable to use the setCharacterEncoding() value to decode both types of parameters (at least as a default) and fix 22666 by avoiding the premature call to getParameter() that Jasper does in the same way as it's done in TC 4. My applogies if I missed a part of the thread that discussed this solution and found it flawed. Hans -- Hans Bergsten<[EMAIL PROTECTED]> Gefion Software <http://www.gefionsoftware.com/> Author of O'Reilly's "JavaServer Pages", covering JSP 2.0 and JSTL 1.1 Details at<http://TheJSPBook.com/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Schedule change
Remy Maucherat wrote: Bill Barker wrote: [...] people want most from Tomcat 5 is a Servlet 2.4/JSP 2.0 container. There are only bad solutions here: - wait for an unspecified, and possibly long, amount of time, sitting on a finished product - backport patches (we probably don't have the resources, and destabilizing 4.1 would be bad; we'd have to use a new 4.2 branch) - branch a new 4.2 based on the current 5.0, and remove features (IMO it doesn't make any sense, plus that would destabilize the codebase - a bit less than the previous option, however -, and run into a similar resources issues) If the first option is chosen, I will go work on other stuff (at JBoss) while the project stays idle (chômage technique, as we say in French). As you all know: no stable release = no testers = no bugs = nothing to fix :-( I'm pretty sure that if you release a TC 5 Beta, you will get quite a few people to test it, and unless it's already perfect, they will find bugs. I don't know more than you do about when J2EE 1.4 will be released, but the specs are starting to move through final approval now, so I'm pretty sure it will happen in a month or two. Three months for running a few Beta releases instead of releasing it as something it's not doesn't seem to bad to me ... I don't have any time to dedicate to either of the other two options, as I have neither motivation nor need for such a product. Sorry :-( Sure, I understand how you feel and no one can force you to work on it, of course, but I hope you do even if it's just Beta for another few months. So I think we're stuck :-( I hope not. 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 at<http://TheJSPBook.com/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java
Jan Luehe wrote: Hans, good point. What about environments that embed Tomcat without following Tomcat's directory layout, and in which the classloader hierachy/depth is different from that in Tomcat? I don't give them that option (with regards to this) in LiteWebServer. The only place I look for shared libraries is $CATALINA_HOME/shared/lib. Is that really a severe limitation, you think? I think it depends on whether you anticipate (or support) LiteWebServer being bundled (as one or more libraries) into other products that use a different directory layout, with different locations for shared libs. If that's the case, limiting the location of shared libs to $CATALINA_HOME/shared/lib might be too restrictive. Your milage may wary, but no one embedding LiteWebServer (LWS) today has complained. I think sometimes too much flexibility is what makes a product hard to use. With LWS, I've stripped down Tomcat to the bare minimum and removed a lot of choices, and people seem to like how simple things get this way. That's why Tomcat searches the webapp's classloader delegation chain for JARs, which ensures that it will find shared libs regardless of their location. Of course, by searching the classloader chain all the way up, we end up parsing too many JARs. I think it's impossible to know ahead of time where to stop in the chain, until you've actually traversed the entire chain. For example, an approach that walks the chain just two levels up won't work in environments where the classloaders 3 or 4 levels up in the chain are also responsible for loading shared libs. Sure, if you can't restrict installation of shared tag libraries to a directory with a well-known name (off some configurable base, like CATALINA_HOME), you have no choice but to walk the chain. It's up to you to decide if it's worth it or not. I'm just piping in with an alternative that works fine for me and my users. 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 at<http://TheJSPBook.com/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java
Jan Luehe wrote: Hans, thanks for stepping in. sorry, but I don't see which part of our email exchange you found "very frustrating". As I said, I'm open to suggestions, and if my patch is deemed useless, I'll revert it. No problem. [...] Sorry for not jumping in earlier in this discussion. When I implemented the "shared tag libraries" feature in LiteWebServer, I added scanning of JAR files in just /shared/lib. I do _not_ scan JAR files in common/lib and server/lib, because placing shared tag libraries there would be point-less; the container doesn't need access to them, only the applications do, which is what shared/lib is for. Maybe that cuts down the list enough so you don't have to mess with an exclusion list at all? good point. What about environments that embed Tomcat without following Tomcat's directory layout, and in which the classloader hierachy/depth is different from that in Tomcat? I don't give them that option (with regards to this) in LiteWebServer. The only place I look for shared libraries is $CATALINA_HOME/shared/lib. Is that really a severe limitation, you think? 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 at<http://TheJSPBook.com/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java
Jan Luehe wrote: Remy, sorry, but I don't see which part of our email exchange you found "very frustrating". As I said, I'm open to suggestions, and if my patch is deemed useless, I'll revert it. No problem. [...] Sorry for not jumping in earlier in this discussion. When I implemented the "shared tag libraries" feature in LiteWebServer, I added scanning of JAR files in just /shared/lib. I do _not_ scan JAR files in common/lib and server/lib, because placing shared tag libraries there would be point-less; the container doesn't need access to them, only the applications do, which is what shared/lib is for. Maybe that cuts down the list enough so you don't have to mess with an exclusion list at all? 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 at<http://TheJSPBook.com/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.12 stability rating
Remy Maucherat wrote: [ ] Alpha [x] Beta It runs all examples in my upcoming JSP 2.0 book, so it looks fine to me. I had some problems with a bundled Xerces version, but for now I consider that an application problem rather than a container problem. If further analysis proves otherwise, I'll let you know. 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 at<http://TheJSPBook.com/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JSPC and TC 5?
Is there any particular reason why the jspc.sh/bat and jasper.sh/bat files are not included in Tomcat 5? I realize that Ant is the preferred way to precompile a web application, but JSPC is very convenient to use for simple sites when there's no Ant installation in place. I tested using the TC 4.1.24 scripts with TC 5.0.7, and it seems to work fine. Any chance that these scripts can be added back into TC 5? 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 at<http://TheJSPBook.com/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Solved AW: jk 1.2.4 LB bug?
Sorry Glenn, by looking deeper into the mod_jk.log. When changing worker names, I realized, that I was actually restarting Apache with the same worker.properties every time. There was a link earlier in the configuration chain, which made my switching useless :( We should definately reduce our linking !!! Thanks very much. p.s. If anybody else is interested in our LB/failover setup I am glad to provide some info. Best regards, Hans > -Ursprungliche Nachricht- > Von: Hans Schmid [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 16. Juli 2003 15:15 > An: Tomcat Developers List > Betreff: AW: jk 1.2.4 LB bug? > > > Thanks for your reply, > comments see inline > > > -Ursprungliche Nachricht- > > Von: Glenn Nielsen [mailto:[EMAIL PROTECTED] > > Gesendet: Mittwoch, 16. Juli 2003 12:26 > > An: Tomcat Developers List > > Betreff: Re: jk 1.2.4 LB bug? > > > > > > mod_jk will print out information about the lb config if you set > > the JkLogLevel to debug. > > > > done > > > I would suggest setting up a test system where you can test > > the below with JkLogLevel debug configured. Then grep the > > log for lines which have jk_lb_worker.c in them. > > > > OK > > > This will tell you several things. > > > > 1. Whether the worker.properties are getting reread when you > >do an apache restart. (They should be) > > > > Yes they were reread: > Initial: > [Wed Jul 16 14:11:14 2003] [jk_worker.c (118)]: Into wc_close > [Wed Jul 16 14:11:14 2003] [jk_worker.c (199)]: close_workers > got 6 workers > to destroy > [Wed Jul 16 14:11:14 2003] [jk_worker.c (206)]: close_workers > will destroy > worker lb-einsurance > [Wed Jul 16 14:11:14 2003] [jk_lb_worker.c (561)]: Into > jk_worker_t::destroy > [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1461)]: Into > jk_worker_t::destroy > [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1468)]: Into > jk_worker_t::destroy up to 1 endpoint to close > [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (605)]: In > jk_endpoint_t::ajp_close_endpoint > [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (612)]: In > jk_endpoint_t::ajp_close_endpoint, closed sd = 12 > [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1461)]: Into > jk_worker_t::destroy > [Wed Jul 16 14:11:14 2003] [jk_worker.c (118)]: Into wc_close > [Wed Jul 16 14:11:14 2003] [jk_worker.c (118)]: Into wc_close > [Wed Jul 16 14:11:14 2003] [jk_worker.c (118)]: Into wc_close > [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1468)]: Into > jk_worker_t::destroy up to 1 endpoint to close > [Wed Jul 16 14:11:14 2003] [jk_worker.c (199)]: close_workers > got 6 workers > to destroy > [Wed Jul 16 14:11:14 2003] [jk_worker.c (199)]: close_workers > got 6 workers > to destroy > [Wed Jul 16 14:11:14 2003] [jk_worker.c (199)]: close_workers > got 6 workers > to destroy > [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1461)]: Into > jk_worker_t::destroy > [Wed Jul 16 14:11:14 2003] [jk_worker.c (206)]: close_workers > will destroy > worker lb-einsurance > [Wed Jul 16 14:11:14 2003] [jk_worker.c (206)]: close_workers > will destroy > worker lb-einsurance > [Wed Jul 16 14:11:14 2003] [jk_worker.c (206)]: close_workers > will destroy > worker lb-einsurance > [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1468)]: Into > jk_worker_t::destroy up to 1 endpoint to close > [Wed Jul 16 14:11:14 2003] [jk_lb_worker.c (561)]: Into > jk_worker_t::destroy > [Wed Jul 16 14:11:14 2003] [jk_lb_worker.c (561)]: Into > jk_worker_t::destroy > [Wed Jul 16 14:11:14 2003] [jk_lb_worker.c (561)]: Into > jk_worker_t::destroy > > ... closing other not related worker > > [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (172)]: Into > jk_uri_worker_map_t::uri_worker_map_alloc > [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (375)]: Into > jk_uri_worker_map_t::uri_worker_map_open > [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (396)]: > jk_uri_worker_map_t::uri_worker_map_open, rule map size is 12 > [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (321)]: Into > jk_uri_worker_map_t::uri_worker_map_open, match rule > /einsurance/=lb-einsurance was added > [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (345)]: Into > jk_uri_worker_map_t::uri_worker_map_open, exact rule > /einsurance=lb-einsurance was added > > ... 5 other workers (including other lb-workers and normal workers) > > added > [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (408)]: Into > jk_uri_worker_map_t::uri_worker_map_open, there are 12 rules > [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (422)]: > jk_uri_worker_map_t::uri_worker_map_open, done > [Wed Jul 16 14:11:16 2003] [jk_w
AW: jk 1.2.4 LB bug?
lidate for worker ajp13-01 contact is tomcathost-ei:11009 [Wed Jul 16 14:11:16 2003] [jk_ajp_common.c (1397)]: Into jk_worker_t::init [Wed Jul 16 14:11:16 2003] [jk_ajp_common.c (1421)]: In jk_worker_t::init, setting socket timeout to 0 [Wed Jul 16 14:11:16 2003] [jk_worker.c (187)]: wc_create_worker, done [Wed Jul 16 14:11:16 2003] [jk_worker.c (148)]: Into wc_create_worker [Wed Jul 16 14:11:16 2003] [jk_worker.c (162)]: wc_create_worker, about to create instance ajp13-02 of ajp13 [Wed Jul 16 14:11:16 2003] [jk_ajp13_worker.c (108)]: Into ajp13_worker_factory [Wed Jul 16 14:11:16 2003] [jk_worker.c (171)]: wc_create_worker, about to validate and init ajp13-02 [Wed Jul 16 14:11:16 2003] [jk_ajp_common.c (1343)]: Into jk_worker_t::validate [Wed Jul 16 14:11:16 2003] [jk_ajp_common.c (1364)]: In jk_worker_t::validate for worker ajp13-02 contact is tomcathost-ei:11019 [Wed Jul 16 14:11:16 2003] [jk_ajp_common.c (1397)]: Into jk_worker_t::init [Wed Jul 16 14:11:16 2003] [jk_ajp_common.c (1421)]: In jk_worker_t::init, setting socket timeout to 0 [Wed Jul 16 14:11:16 2003] [jk_worker.c (187)]: wc_create_worker, done [Wed Jul 16 14:11:16 2003] [jk_worker.c (148)]: Into wc_create_worker [Wed Jul 16 14:11:16 2003] [jk_worker.c (162)]: wc_create_worker, about to create instance ajp13-sb of ajp13 [Wed Jul 16 14:11:16 2003] [jk_ajp13_worker.c (108)]: Into ajp13_worker_factory [Wed Jul 16 14:11:16 2003] [jk_worker.c (171)]: wc_create_worker, about to validate and init ajp13-sb [Wed Jul 16 14:11:16 2003] [jk_ajp_common.c (1343)]: Into jk_worker_t::validate [Wed Jul 16 14:11:16 2003] [jk_ajp_common.c (1364)]: In jk_worker_t::validate for worker ajp13-sb contact is tomcathost-ei-sb:11015 [Wed Jul 16 14:11:16 2003] [jk_ajp_common.c (1397)]: Into jk_worker_t::init [Wed Jul 16 14:11:16 2003] [jk_ajp_common.c (1421)]: In jk_worker_t::init, setting socket timeout to 0 [Wed Jul 16 14:11:16 2003] [jk_worker.c (187)]: wc_create_worker, done [Wed Jul 16 14:11:16 2003] [jk_lb_worker.c (498)]: Balanced worker 0 has name ajp13-01 [Wed Jul 16 14:11:16 2003] [jk_lb_worker.c (498)]: Balanced worker 1 has name ajp13-sb [Wed Jul 16 14:11:16 2003] [jk_lb_worker.c (498)]: Balanced worker 2 has name ajp13-02 [Wed Jul 16 14:11:16 2003] [jk_lb_worker.c (502)]: in_local_worker_mode: true [Wed Jul 16 14:11:16 2003] [jk_lb_worker.c (505)]: local_worker_only: false [Wed Jul 16 14:11:16 2003] [jk_worker.c (187)]: wc_create_worker, done [Wed Jul 16 14:11:16 2003] [jk_worker.c (238)]: build_worker_map, removing old lb-einsurance worker this last line looks suspicous to me > 2. What the lb worker thinks the config is. > initial: [Wed Jul 16 14:04:44 2003] [jk_lb_worker.c (586)]: Into lb_worker_factory [Wed Jul 16 14:04:44 2003] [jk_lb_worker.c (420)]: Into jk_worker_t::validate [Wed Jul 16 14:04:44 2003] [jk_lb_worker.c (498)]: Balanced worker 0 has name ajp13-01 [Wed Jul 16 14:04:44 2003] [jk_lb_worker.c (498)]: Balanced worker 1 has name ajp13-sb [Wed Jul 16 14:04:44 2003] [jk_lb_worker.c (498)]: Balanced worker 2 has name ajp13-02 [Wed Jul 16 14:04:44 2003] [jk_lb_worker.c (502)]: in_local_worker_mode: true [Wed Jul 16 14:04:44 2003] [jk_lb_worker.c (505)]: local_worker_only: false but after the switching and graceful restart exactly the same (which is the error) [Wed Jul 16 14:11:16 2003] [jk_lb_worker.c (420)]: Into jk_worker_t::validate [Wed Jul 16 14:11:16 2003] [jk_lb_worker.c (498)]: Balanced worker 0 has name ajp13-01 [Wed Jul 16 14:11:16 2003] [jk_lb_worker.c (498)]: Balanced worker 1 has name ajp13-sb [Wed Jul 16 14:11:16 2003] [jk_lb_worker.c (498)]: Balanced worker 2 has name ajp13-02 [Wed Jul 16 14:11:16 2003] [jk_lb_worker.c (502)]: in_local_worker_mode: true [Wed Jul 16 14:11:16 2003] [jk_lb_worker.c (505)]: local_worker_only: false This explains the observed (wrong) fall-over behavior, (should be ajp13-02, ajp13-sb, ajp13-01) original workers.properties: worker.ajp13-01.lbfactor=1 worker.ajp13-01.local_worker=1 worker.ajp13-02.lbfactor=1 worker.ajp13-02.local_worker=0 worker.ajp13-sb.lbfactor=0 worker.ajp13-sb.local_worker=1 local_worker_only=0 for the lb-worker changed to before graceful restart: (linking a different worker.properties) worker.ajp13-01.lbfactor=1 worker.ajp13-01.local_worker=0 worker.ajp13-02.lbfactor=1 worker.ajp13-02.local_worker=1 worker.ajp13-sb.lbfactor=0 worker.ajp13-sb.local_worker=1 local_worker_only=0 the lb-worker So it *seems* there might be something wrong with the reinitialisation of the worker order ? If you need further information, I can mail you the complete logs offline. Thanks for looking into this, Hans > Then post those log lines here. > > Thanks, > > Glenn > > Hans Schmid wrote: > > Hi, > > > > I noticed the following with mod_jk 1.2.4, Apache 1.3.26 and > > Tomcat 3.3.1a on Solaris 8 JDK 1.4.1_03. > > > > Maybe a LB bug (Loadfactors do not recover after st
jk 1.2.4 LB bug?
Hi, I noticed the following with mod_jk 1.2.4, Apache 1.3.26 and Tomcat 3.3.1a on Solaris 8 JDK 1.4.1_03. Maybe a LB bug (Loadfactors do not recover after startup of new tomcat/graceful Apache restart). Let me explain my scenario first: I want to gracefully upgrade our webapp without loosing sessions + have a fail over scenario. Therefor we have sticky sessions enabled. Setup: 1 tomcat 01 running on Server A, 0 tomcat 02 running on Server A, 1 tomcat SB running on Server B 01 tomcat on Server A runs the application, SB tomcat on server B is standby(fallback), 02 tomcat is shutdown on Server A at the moment. All three Tomcats are in the same lb_worker: worker.list=lb-worker worker.ajp13-01.port=11009 worker.ajp13-01.host=A worker.ajp13-01.type=ajp13 worker.ajp13-01.lbfactor=1 worker.ajp13-01.local_worker=1 worker.ajp13-02.port=11019 worker.ajp13-02.host=A worker.ajp13-02.type=ajp13 worker.ajp13-02.lbfactor=1 worker.ajp13-02.local_worker=0 worker.ajp13-sb.port=11015 worker.ajp13-sb.host=B worker.ajp13-sb.type=ajp13 worker.ajp13-sb.lbfactor=0 worker.ajp13-sb.local_worker=1 worker.lb-worker.type=lb worker.lb-worker.balanced_workers=ajp13-01, ajp13-02, ajp13-sb worker.lb-worker.local_worker_only=0 The worker List order should now be: 1. worker.ajp13-01 lbfactor=1,local_worker=1 TC 01 2. worker.ajp13-sb lbfactor=0,local_worker=1 TC SB 3. worker.ajp13-02 lbfactor=1,local_worker=0) TC 02 (not running) Now all requests go to worker.ajp13-01 (TC 01), none to worker.ajp13-sb (TC SB lbfactor=0), none to worker.ajp13-02.port (TC 02 not running). If Server A crashes (TC 01) all new requests go to Server B (TC SB worker.ajp13-sb) since this is then the only running Tomcat FINE This is our Fail-Over Solution (lost running sessions, but OK). Now the webapp update Scenario: 1.) shutdown TC SB on Server B, update the webapp, start tc SB and test via a seperate HTTPConnector port without Apache. 2.) this does not affect anything on production, since the lbfactor=0 on TC SB -> no sessions arrive on tc SB 3.) When the test was successful, our Standby Tomcat SB is updated 4.) Now upgrade the webapp on Server A TC 02, which is currently not running. 5.) Start up TC 02 on Server A with the new version of the webapp, immediately exchange the worker.properties with a different version and gracefully restart apache: worker.list=lb-worker worker.ajp13-01.port=11009 worker.ajp13-01.host=A worker.ajp13-01.type=ajp13 worker.ajp13-01.lbfactor=1 worker.ajp13-01.local_worker=0 < put old webapp on TC 01 to the foreign worker list worker.ajp13-02.port=11019 worker.ajp13-02.host=A worker.ajp13-02.type=ajp13 worker.ajp13-02.lbfactor=1 worker.ajp13-02.local_worker=1 < put new webapp on TC 02 in front of the local worker list worker.ajp13-sb.port=11015 worker.ajp13-sb.host=B worker.ajp13-sb.type=ajp13 worker.ajp13-sb.lbfactor=0 worker.ajp13-sb.local_worker=1 worker.lb-worker.type=lb worker.lb-worker.balanced_workers=ajp13-01, ajp13-02, ajp13-sb worker.lb-worker.local_worker_only=0 Just the two lines marked above with < swap (local_worker values of TC 01 and TC 02) 6.) now all 3 Tomcats are running. All existing sessions still go to TC 01 (sticky sessions; we do not loose running sessions) 7.) What I expect: TC 02 takes a while to startup. The worker List order should now be: 1. worker.ajp13-02 lbfactor=1,local_worker=1 TC 02 2. worker.ajp13-sb lbfactor=0,local_worker=1 TC SB 3. worker.ajp13-01 lbfactor=1,local_worker=0) TC 01 (old webapp) Since TC 02 needs 3 minutes to start up (filling caches etc.) it is not immediately availlable. During this time new sessions arrive at TC SB, since it is the next in the worker list. OK fine this works. Since these sessions are sticky as well, all users connecting during this time stay on TC SB during their whole session life. FINE 8.) As soon as TC 02 is up and running (finished all load-on-startup servlet initialisition stuff) I would expect that TC 02 gets all new Sessions (Number 1 in the worker List). This is not the case! All new Sessions still arrive at TC SB. 9.) After a while (one hour) we shutdown TC 01. Since no new sessions arrived there since our graceful restart of Apache, all old Sessions should have expired. 10.) even now (only 2 Tomcats running TC 02 and TC SB) and even after a graceful restart new Sessions arrive at TC SB Conclusion: Now, do I misunderstand the supposed behaviour of lbfactor and local_worker flag ? I think that the behaviour in 8.) is wrong. 10.) is starange too. Thanks for any suggestion if I am completely wrong here or further looking into this. Hans > -Ursprungliche Nachricht- > Von: Glenn Nielsen [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 9. Juli 2003 15:56 > An: Tomcat Developers List > Betreff: Re: jk 1.2.25 release ? > > > I was hoping to get it released this week. > > But I just noticed that under Apache 2 mod_jk piped logs there > are two i
AW: java processes created by tomcat
See http://tomcatfaq.sourceforge.net/linx.html cheers, Hans > -Ursprüngliche Nachricht- > Von: siddharth [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 17. Juni 2003 12:13 > An: [EMAIL PROTECTED] > Betreff: java processes created by tomcat > > > hello, > > > I am running following servers on my linux machine > > 1. tomcat4 using many JSPs and Servlets > 2. apache > 3. qmail > 4. postgresql > etc. > > Tomcat is the only process which is usijg java. > > when i do 'top' and 'sort by memory usage' i get > following output. > > - > > 2:10pm up 5:24, 5 users, load average: 0.22, > 0.52, 0.83 > 168 processes: 166 sleeping, 2 running, 0 zombie, 0 > stopped > CPU states: 1.1% user, 17.6% system, 0.0% nice, > 81.1% idle > Mem: 384416K av, 381356K used,3060K free, > 2324K shrd, 11720K buff > Swap: 522072K av, 60548K used, 461524K free >71616K cached > > > > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM > TIME COMMAND > 9458 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:24 java > 9489 root 8 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9490 root 9 0 118M 115M 23768 S 0.0 30.8 > 1:45 java > 9491 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9495 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:01 java > 9502 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9537 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9538 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9539 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:05 java > 9639 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9717 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9719 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9720 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9721 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9723 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9724 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9725 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9726 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9727 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9728 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9729 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9730 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9731 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9732 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9733 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9734 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9735 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9736 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9737 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9738 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9739 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9740 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9741 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9742 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > 9743 root 9 0 118M 115M 23768 S 0.0 30.8 > 0:00 java > > - > > *** > Notice that first page displayed by output of 'top' is > full of JAVA processes ... > > > is this a problem ? because my machine is getting > heavily loaded. ( with around 400 MB of RAM ) > > > > please help > > thanks. > > > -- > siddharth > [EMAIL PROTECTED] > > -- > http://www.fastmail.fm - The way an email service should be > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpSessionBindingListener.valueUnbound() not called
David Thielen wrote:
One note to the below:
It does call it on a timeout under 4.1.24 (it did not do that in 4.1.18).
But it does not call it if Tomcat is reloaded or exits - which according to
the spec it is supposed to do.
Two things:
1) When you stop Tomcat, it saves all session data to disk; it does not
terminate the sessions at this time, so don't expect a valueUnbound()
call immediately at stop. When Tomcat is restarted, it loads all
session data again and eventually calls valueUnbound() when it finds
that the session has timed out. Also note that it only checks for
timeouts every 1 second, so that's the shortest time-out value that
is honored.
2) In order to save and reload the session data, all objects in the
session must be serializable, e.g. implement java.io.Serializable.
Your FileList class doesn't, so it can be saved and reloaded, hence
the valueUnbound() method is never called after a restart.
Arguably, there's still a bug here. There's a comment in the Standard-
Session class for the method that saves the session data that any object
that is not serializable "will be unbound from the session, with
appropriate actions if it implements HttpSessionBindingListener," which
I assume mean valueUnbound() will be called. I don't see any signs of
this being done, however. You may want to file a bug report about this.
For a class that implements Serializable, however, everything seems to
work as it should in 4.1.24.
Hans
- Original Message -
From: "David Thielen" <[EMAIL PROTECTED]>
To: ""Hans Bergsten"" <[EMAIL PROTECTED]>
Cc: "Tomcat - dev" <[EMAIL PROTECTED]>
Sent: Sunday, March 30, 2003 1:04 PM
Subject: Re: HttpSessionBindingListener.valueUnbound() not called
Nope - with 4.1.24 I still get called for valueBound() but not
valueUnbound().
Any other ideas?
code:
public class FileList implements HttpSessionBindingListener {
public void valueBound(HttpSessionBindingEvent event) {
event.getSession().getServletContext().log( "bind" );
}
public void valueUnbound(HttpSessionBindingEvent event) {
// never logged
event.getSession().getServletContext().log( "unbind" );
}
}
- Original Message -
From: "Hans Bergsten" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Saturday, March 29, 2003 2:19 PM
Subject: Re: HttpSessionBindingListener.valueUnbound() not called
David Thielen wrote:
Hi;
I have an object that implements HttpSessionBindingListener. It calls
valueBound fine. But it never calls valueUnbound. Not when it times out
and
not when Tomcat is closed. I am running 4.1.18.
Any ideas?
It works fine in TC 4.1.24, so you may want to upgrade.
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 at<http://TheJSPBook.com/>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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 at<http://TheJSPBook.com/>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpSessionBindingListener.valueUnbound() not called
David Thielen wrote: Hi; I have an object that implements HttpSessionBindingListener. It calls valueBound fine. But it never calls valueUnbound. Not when it times out and not when Tomcat is closed. I am running 4.1.18. Any ideas? It works fine in TC 4.1.24, so you may want to upgrade. 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 at<http://TheJSPBook.com/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.21] Stability rating
Amy Roh wrote: Hans Bergsten wrote: Remy Maucherat wrote: [X] Alpha [ ] Beta [ ] Stable (GA) The TagLibraryInfoImpl patch attached to bug 14302 is still not applied, so JSPC fails with an NPE for any web app that contains a tag library packaged as a JAR file (with the TLD in the JAR file). I just applied the patch. Great, thanks! 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 at<http://TheJSPBook.com/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.21] Stability rating
Costin Manolache wrote: Hans Bergsten wrote: Good. For JspC, I think there are more urgent problems than the tag related problem, such as the mangling issues which just got fixed in Tomcat 5. That's why I didn't bother trying to apply whatever patch was needed for tags, knowing it would still be broken. Well, if you apply the patch that fixes the "NPE when packaged tag libraries are used" proble, it would be _less_ broken ;-) Seriously, this patch has been submitted by at least two people, has been available for months, and does not cause any regression. Why not just apply it and move on? You are a tomcat committer just like Remy or everyone else. Commit the fix - and if someone has a problem with it he can -1 and propose a better solution. Yes, I am, but it's been years since I committed anything and my environment is not set up for it. I simply don't have the time right now to fix my environment (figure out how to set up ssh, find out if I have submitted a signature to ASF and if so, where it is, find out what my CVS password is, etc. etc.), so my contributions to this project will be in the form of patches in Bugzilla. And yes, some nagging now and then when the patches are not applied ;-) I know I can not demand that someone else commits the patches, and in a prefect world I would find the time to do it myself. But I find it quite annoying that the JSPC bugs are allowed to remain from release to release when there are tested patches available in Bugzilla. Anyway, since committing the patches myself is not an option at this time (but may be in the future), my only alternatives are to continue to submit patches and nag, or to stop contributing altogether. Hey, I can patch my own copy to fix the problems I find. Believe it or not, I'm actually trying to help out by submitting patches and reminding you of them. But if you want me to shut up, I'll do that. Even submitting patches takes time and if you're just going to ignore them, that's time I can use for other things ... 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 at<http://TheJSPBook.com/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.21] Stability rating
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: [ ] Alpha [ ] Beta [X] Stable (GA) Please vote (after testing the release, if possible ;). It works for me. It would be nice to fix the jspc bugs tough. I fixed a small regression in modeler(HEAD) so it can be used as drop-in replacement ( if you have non-supported components - like other connectors - to avoid the exceptions ) Good. For JspC, I think there are more urgent problems than the tag related problem, such as the mangling issues which just got fixed in Tomcat 5. That's why I didn't bother trying to apply whatever patch was needed for tags, knowing it would still be broken. Well, if you apply the patch that fixes the "NPE when packaged tag libraries are used" proble, it would be _less_ broken ;-) Seriously, this patch has been submitted by at least two people, has been available for months, and does not cause any regression. Why not just apply it and move on? The "mangling problem" (I assume you refer to problems with filepath names containing dots) is far less common, and if it's hard to fix (I haven't looked at it), it could wait. But if the TC 5 patch can easily be ported to 4.1, why not do it? Even if you refer to some problem I'm not aware of, fixing the NPE problem can hardly be a bad idea since it affects _everyone_ who tries to use JSPC with packaged tag libraries (the majority case in the real world). > [...] 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 at<http://TheJSPBook.com/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.21] Stability rating
Kin-Man Chung wrote: The patch you mentioned in 14302 was actually applied to TC5. Right, thanks, but it needs to be applied to TC 4.1 as well. And this is a stability ballot for TC 4.1 ;-) Hans Date: Fri, 28 Feb 2003 12:07:21 -0800 From: Hans Bergsten <[EMAIL PROTECTED]> Subject: Re: [4.1.21] Stability rating To: Tomcat Developers List <[EMAIL PROTECTED]> Remy Maucherat wrote: [X] Alpha [ ] Beta [ ] Stable (GA) The TagLibraryInfoImpl patch attached to bug 14302 is still not applied, so JSPC fails with an NPE for any web app that contains a tag library packaged as a JAR file (with the TLD in the JAR file). Other than that, all my tests works okay. 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 at<http://TheJSPBook.com/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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 at<http://TheJSPBook.com/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.21] Stability rating
Actually, let's change that to Beta; it's just one bug after all, even though it's a fairly important one. Hans Hans Bergsten wrote: Remy Maucherat wrote: [X] Alpha [ ] Beta [ ] Stable (GA) The TagLibraryInfoImpl patch attached to bug 14302 is still not applied, so JSPC fails with an NPE for any web app that contains a tag library packaged as a JAR file (with the TLD in the JAR file). Other than that, all my tests works okay. 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 at<http://TheJSPBook.com/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.21] Stability rating
Remy Maucherat wrote: [X] Alpha [ ] Beta [ ] Stable (GA) The TagLibraryInfoImpl patch attached to bug 14302 is still not applied, so JSPC fails with an NPE for any web app that contains a tag library packaged as a JAR file (with the TLD in the JAR file). Other than that, all my tests works okay. 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 at<http://TheJSPBook.com/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.20] Tagging soon ?
Remy Maucherat wrote: I plan to port the changes made to JSPC in the Tomcat 5 branch, and (as I think fixing the issue is important) tag a new 4.1.20 milestone within a few days. Comments ? That would be great, but can you please apply the TagLibraryInfoImpl patch from bug #14302 before you so? Without it, JspC fails for JSP pages that use tag libraries with the TLD packaged in the JAR file. This is the same problem as described by bugs #13212 and #14537. 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 at<http://TheJSPBook.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java
Jeanfrancois Arcand wrote: Hans Bergsten wrote: Jeanfrancois Arcand wrote: [...] We can support runtime package name addition (when the servlet is generated, ask the security manager to protect the package). So it can be optional, i.e. being able to tell jasper to generate servlet using org.apache.jsp (something configurable via JMX ;-) ), without or with a aaa.bbb.ccc. Then when package generation option is selected, then ask the security manager to protect it.. It will be easy to document the functionality and that will improve the security manager protection mechanim (by having the choice of protecting or not a package, and by having the choice of the package name). I admit I'm almost totally ignorant about this, so can you please explain why I would want to protect the package used for my JSP pages? In the normal case (when your web app is bundled as a standalone module), you doesn't need to protect your JSP. The classloader will protect your JSP. It is when you bundle more that one web app in a single war file that you may need protection. How can you bundle more that one app in a WAR file? A WAR file is the deployment format for _one_ web app only. Who am I protecting myself against, what type of attack, in what type of environment? Given that each web app has it's own classloader and (I assume) is in control over what goes in it's web app structure, I just don't see the need for this protection. But I may be totally wrong, so please enlighten me. You are right, but when the Tomcat classloading mechanism is not used, we need a way to still ensure the protection. That will not happen when you use Tomcat as it is, but that can happen in JBoss and J2EE RI (when you change the installation structure). The servlet spec requires a separate classloader per web app, so I don't see how this could be a concern no matter which container is used. And knowing how classloading works ;-)., I would prefer having a protection alternative. Sorry, but I strongly disagree. Adding security mechanisms for cases where it's not needed (assuming spec compliant implementations) only adds complexity to the code and have a negative impact on performance. 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 at<http://TheJSPBook.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java
Jeanfrancois Arcand wrote: [...] We can support runtime package name addition (when the servlet is generated, ask the security manager to protect the package). So it can be optional, i.e. being able to tell jasper to generate servlet using org.apache.jsp (something configurable via JMX ;-) ), without or with a aaa.bbb.ccc. Then when package generation option is selected, then ask the security manager to protect it.. It will be easy to document the functionality and that will improve the security manager protection mechanim (by having the choice of protecting or not a package, and by having the choice of the package name). I admit I'm almost totally ignorant about this, so can you please explain why I would want to protect the package used for my JSP pages? Who am I protecting myself against, what type of attack, in what type of environment? Given that each web app has it's own classloader and (I assume) is in control over what goes in it's web app structure, I just don't see the need for this protection. But I may be totally wrong, so please enlighten me. 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 at<http://TheJSPBook.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java
Craig R. McClanahan wrote: On Wed, 22 Jan 2003, Hans Bergsten wrote: See my previous mail; you do _not_ need to have a package statement for the generated servlet class. Adding it just complicates life. There is a situation when *not* having the package statement can cause big problems for users. The JSP spec doesn't mandate any particular package (or the use of a package at all) for the generated page class. But if the container uses no package, users will find that they can utilize unpackaged beans without needing to import them -- yet, as soon as they move their application to a different container (which does put pages in a package), their app no longer works. Worse than that, if the new container is running on a JDK 1.4.1 system, they can't even fix the problem by adding import statements, because 1.4.1 won't let you import unpackaged classes. IIRC, the portability issue was why we switched from unpackaged to packaged back in Tomcat 3.2 days. Again, I'm only talking about JSPC here; I'm not arguing for removing the package name that JspServlet adds. For JSPC, the above is not an issue. The servlet classes are used as is, no matter if you deploy to Tomcat or another container; no one's inserting package statement at any point after the class is generated. The only problem would be if the JSP page includes references to classes in the "default package" and you decide to deploy the JSP page as is instead of the precompiled class file. Then you may run into the problem you describe, i.e. it works fine precompiled but not when the container compiles it. JSPC has been totally broken in TC 4.1 and TC 5 for a long time. I suggest we bring it back in line with TC 4.0.4 now (which is what the current patch does, if you also add the TagLibraryInfoImpl patch I posted). If there are other concerns which package names, let's please come up with a consitent solution for _both_ JSPC and JspServlet and implement it later. Priority one should be to stop all the "JSPC doesn't work" bug reports. 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 at<http://TheJSPBook.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java
Remy Maucherat wrote: Jeanfrancois Arcand wrote: The only problem I see by removing the package org.apache.jsp is that when Tomcat run under the security manager, it is no longer possible to protect an application from package insertion/access (dangerous). It is still possible to protect the application by manually adding the new package name under the conf/tomcat.properties file. This will have to be documented somewhere. That's a good point, also. (oh, no, I'm back in the middle of a JSPC induced mess ;-) ) Ok, I can re-revert my patch ;-) Please don't. The way it's pathced now, it works as in TC 4.0.4. Also note that this is for precompiled JSP pages only. If there are security concerns (I know I'm ignorant), let's look at both JspServlet and JSPC and find a solution that works for both at the same time. 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 at<http://TheJSPBook.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: Then why not default to the context path ? Can you give examples ? It's very hard to determine the context path from JSPC IMO. I agree. I think the naming conventions for the generated servlets should be settled down, documented - and treated as APIs ( i.e. no change unless absolutely needed ). Ok, but in the meantime, we must not allow non packaged classes. See my previous mail; you do _not_ need to have a package statement for the generated servlet class. Adding it just complicates life. When I wrote my patch, I also felt that a default package prefix was a good idea, but I dropped it in the end due to the package/directory structure mismatch. If it's really important to, you should also make sure the class files are generated in a directory structure that starts with "org/apache/jsp/" I was wondering about that, actually, and thought this was inconsistent. JSPC does generate the right package directory structure. As long as there's no prefix added to the package name, yes. If you add a package name prefix, the JspC in TC 4.1.18 (with the patch we're talking about here) generates "package org.apache.jsp.foo;" for a JSP page in the context-relative dir "foo" and places the class file in "/foo". Hence, a structure mismatch that will cause confusion. I think JspServlet should do the same - if it doesn't already. Well, I don't think we care. JspServlet generates in the workdir, and uses one CL per page. So packaging is not relevant IMO. OTOH, JSPC may generate the classes in /WEB-INF/classes, so we would need to create the full package structure. I'd like to point out that you admin precompilation example does include an extra "admin" subfolder in the output directory path. Right. 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 at<http://TheJSPBook.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java
Remy Maucherat wrote: Hans Bergsten wrote: [EMAIL PROTECTED] wrote: remm2003/01/22 03:40:00 Modified:jasper2/src/share/org/apache/jasper JspC.java Log: - Fix package name generation. - Default to "org.apache.jsp" package name. Why do you need a default package name? Doesn't this make it harder to to use, since the package structure no longer matches the directory structure? Because if the user doesn't set a package, it won't work with JDK 1.4. So I'm forcing one by default; I know the structure won't match. That's what I thought as well, at first. But it's not the case. What doesn't work in JDK 1.4 is to use classes from the "default package" (i.e. no package) in a class that is part of a package. But there's nothing wrong with having a class in the default package per se if it doesn't get imported or used in another, packaged class; the generated class is not used in another class, hence it doesn't have to be in a package. Does that make sense? If not, I can elaborate. When I wrote my patch, I also felt that a default package prefix was a good idea, but I dropped it in the end due to the package/directory structure mismatch. If it's really important to, you should also make sure the class files are generated in a directory structure that starts with "org/apache/jsp/" I was wondering about that, actually, and thought this was inconsistent. Yep, it is. While I was going down this road I added code in a few places (forgot where) to also set the output dir for the class file. But I realized after a while that the idea of a requiring a package was flawed, so I removed it. 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 at<http://TheJSPBook.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java
[EMAIL PROTECTED] wrote: remm2003/01/22 03:40:00 Modified:jasper2/src/share/org/apache/jasper JspC.java Log: - Fix package name generation. - Default to "org.apache.jsp" package name. Why do you need a default package name? Doesn't this make it harder to to use, since the package structure no longer matches the directory structure? When I wrote my patch, I also felt that a default package prefix was a good idea, but I dropped it in the end due to the package/directory structure mismatch. If it's really important to, you should also make sure the class files are generated in a directory structure that starts with "org/apache/jsp/" 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 at<http://TheJSPBook.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java
[EMAIL PROTECTED] wrote:
costin 2003/01/21 15:24:51
Modified:jasper2/src/share/org/apache/jasper JspC.java
Log:
Use the patch submited by Hans ( at least the part related to package ).
I modified it so that if a package is specified, it is used as prefix.
The second patch - I'm not sure what it does.
You mean the o.a.j.compiler.TagLibraryInfoImpl.java patch, right?
As I mentioned briefly in my last comment for the bug, it fixes a
problem with TLDs packaged in JAR files. Without this patch, you get
an NPE for this case (the problem described by bug #13212).
The code the patch removes is admittedly a mystery to me (why is a
leading slash only removed if a URLClassLoader is used? Isn't this
always the case?) and I don't remember why it failed for TLDs in
JAR files (maybe path is null?). In all my tests, however, this patch
fixes #13212 and has not caused any side-effects.
Hans
Revision ChangesPath
1.23 +4 -4 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
Index: JspC.java
===
RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- JspC.java 21 Jan 2003 22:49:53 - 1.22
+++ JspC.java 21 Jan 2003 23:24:50 - 1.23
@@ -548,7 +548,7 @@
targetClassName = null;
}
if (targetPackage != null) {
-clctxt.setServletPackageName( targetPackage + "." +
+clctxt.setServletPackageName( targetPackage +
toPackageName(jspUri));
} else {
clctxt.setServletPackageName( toPackageName(jspUri));
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
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 at<http://TheJSPBook.com/>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [PROPOSAL] Replace Jasper's logging facility with commons-logging
Jan Luehe wrote: Jasper currently uses its own private logging facility implemented in the org.apache.jasper.logging package. This is inconsistent with the way the other Tomcat subsystems perform logging (by leveraging the commons-logging package). Proposal is to remove org.apache.jasper.logging, and replace calls to it with calls to the commons-logging APIs. Comments? +0. Do you suggest this for TC 5 only, or also for TC 4.1? 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 at<http://TheJSPBook.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java
Costin Manolache wrote:
Sorry, I didn't see the patch - I was precompiling the admin and
hit the problem.
BTW - why don't you fix it yourself - you are committer AFAIK :-) ?
There's a simple reason: it's been so long since I was actively involved
in the development that I (a) want to lurk a bit before I start
making commits, and (b) I've lost my password/key/procedures and
haven't had the time to figure it all out again ;-)
I _will_ start committing again, but I hope you can have some patience
and apply a few patches I submit in the bug database database until
then.
Hans
Hans Bergsten wrote:
[EMAIL PROTECTED] wrote:
costin 2003/01/21 11:44:42
Modified:jasper2/src/share/org/apache/jasper JspC.java
Log:
Support for packages in precompiled servlets - otherwise all go to the
same package and we get conflicts.
Thanks for finally fixing this, but please use the patch I submitted for
BugID 14302 instead, since it handles special characters in the path
as well. The TagLibraryInfoImpl patch (same BugID) is also required to
support TLDs located in JAR files.
Hans
Revision ChangesPath
1.21 +8 -5
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
Index: JspC.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
retrieving revision 1.20 retrieving revision 1.21
diff -u -r1.20 -r1.21
--- JspC.java 31 Dec 2002 14:01:17 - 1.20
+++ JspC.java 21 Jan 2003 19:44:42 - 1.21
@@ -547,7 +547,10 @@
targetClassName = null;
}
if (targetPackage != null) {
-clctxt.setServletPackageName(targetPackage);
+int baseLen=jspUri.lastIndexOf("/");
+if( baseLen <0 ) baseLen=0;
+String packageSubs= jspUri.substring(0,
baseLen).replace( '/', '.' );
+clctxt.setServletPackageName( targetPackage + "." +
packageSubs);
}
setupContext(clctxt);
@@ -593,7 +596,7 @@
} else if (dieLevel != NO_DIE_LEVEL) {
dieOnExit = true;
}
-throw new JasperException( e );
+throw new JasperException( "Error compiling " + file, e );
}
}
--
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]>
--
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 at<http://TheJSPBook.com/>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java
[EMAIL PROTECTED] wrote:
costin 2003/01/21 11:44:42
Modified:jasper2/src/share/org/apache/jasper JspC.java
Log:
Support for packages in precompiled servlets - otherwise all go to the
same package and we get conflicts.
Thanks for finally fixing this, but please use the patch I submitted for
BugID 14302 instead, since it handles special characters in the path
as well. The TagLibraryInfoImpl patch (same BugID) is also required to
support TLDs located in JAR files.
Hans
Revision ChangesPath
1.21 +8 -5 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
Index: JspC.java
===
RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- JspC.java 31 Dec 2002 14:01:17 - 1.20
+++ JspC.java 21 Jan 2003 19:44:42 - 1.21
@@ -547,7 +547,10 @@
targetClassName = null;
}
if (targetPackage != null) {
-clctxt.setServletPackageName(targetPackage);
+int baseLen=jspUri.lastIndexOf("/");
+if( baseLen <0 ) baseLen=0;
+String packageSubs= jspUri.substring(0, baseLen).replace( '/', '.' );
+clctxt.setServletPackageName( targetPackage + "." + packageSubs);
}
setupContext(clctxt);
@@ -593,7 +596,7 @@
} else if (dieLevel != NO_DIE_LEVEL) {
dieOnExit = true;
}
-throw new JasperException( e );
+throw new JasperException( "Error compiling " + file, e );
}
}
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
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 at<http://TheJSPBook.com/>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Jasper, JMX and JSR77
Costin Manolache wrote: JSR77 defines a certain model - in particular a WebModule must include an attribute "servlets[]" that lists all the servlets in the webapp, and it also requires on JMX mbean per servlet. ( tomcat uses that to provide all kind of performance and statistical info ). The problem is - JSPs are not visible, since Jasper creates them internally. One solution is to turn JspServletWrapper into an interface, with a GenericServletWrapper impl ( the current code ) and a mechanism to create container-specific wrappers. A TomcatServletWrapper can hook JSP servlets into JMX and it may also provide future tomcat-specific optimizations ( like bypassing JspServlet - by registering the ServletWrapper directly into the mapper ). Questions: Just some answers from the floor: - do we want to do that ( there is some extra complexity and some work ) ? Does anyone care about JSR77 support in tomcat ? I think JMX and JSR77 is interesting, even though I admit I haven't read up on it yet, so yes. But I suggest that major changes like this are restricted to TC 5, and that we keep TC 4.1 possible to use without any JMX dependencies (which is possible with TC 4.1.18). I've just released a slimmed down and modularized version of TC 4.1.18 plus a module management web app, distributed under the name LiteWebServer. One of the main points with this distribution is that it's _small_, so I strip off all JARs (and even individual classes) that are not needed for the base functionality (some of it can be added through add-on modules to enable specific features). I've managed to exclude all JMX and MBeans stuff so far, and I hope I can continue to do so as long as it's based on the TC 4.1 tree. - where should TomcatServletWrapper live - jasper can have an optional dependency on catalina, or catalina can have an optional dependency on jasper. It would make most sense to me to make Catalina have an optional dependency on Jasper for this; it's only when you use Jasper with Catalina that you get the JMX support, but Jasper can be used without it in other containers. - should we extend JMX support to other jasper components - to report things like compilation times, tag pool usage, tag usage, etc ? Sounds cool :-) As long as it doesn't add too much overhead. - anyone willing to help, or I'm alone :-) ? I'm +0 for TC 5. Eventually, I hope to find time to help out with TC 5, but for now I need to focus on TC 4.1. 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 at<http://TheJSPBook.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Tag reuse performance [Was: Re: DO NOT REPLY [Bug 16001] - Tag.release()not invoked]
Costin Manolache wrote: [...] In an ideal world, all "core" tags would be recyclable and garbage-free - that may allow them to run at comparable speed with a hard-coded page. I think it's more important to implement "open coding" of JSTL, i.e. generate if and for statement instead of using and tag handlers. That would really make a difference for all apps that use JSTL, while the potential gains from tag handler reuse depend on a lot of factors that varies between applications and the runtime environment. 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 at<http://TheJSPBook.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
Johan Åbrandt wrote: Hans Bergsten wrote: Tim Moore wrote: This bug seems to be submitted several times a week. Maybe an FAQ would be in order? (or FOB -- frequently opened bugs haha) Then again, if people don't search the bug database before submitting a new one, then I guess they can't be expected to read the FAQ. And on the other hand, if the spec confuses this many people, maybe that should be fed back to the spec authors. Just adding a "reset" method to Tag that is called before each invocation might help people understand the difference between that and release. I'm in the EG and we had a long discussion about this again for JSP 2.0. The end result is that the current behavior (do _not_ call release() between invocations) will stay. A confusing arrow from the "released" state to the "initialized" state in the state diagram will be removed, however. This state transition came with lots and lots of restrictions, but it seems like some vendor (and developers) saw it as a requirement to call release() between invocations, even though the text clearly state that that's not the case. This is being discussed pretty much everywhere these days and I hope people eventually will get it. I wrote about it in an article just after JSP 1.2 was released. Feel free to point people to it if you get tired of rehashing the same arguments over and over ;-) <http://www.onjava.com/pub/a/onjava/2001/11/07/jsp12.html> Page 2, the "Tag handler life cycle and instance reuse" section If I understand the section Hans directs to correctly, re-use of a pooled tag is only allowed if the tags have the same set of attributes: "A tag handler instance can only be reused for an occurrence with the same set of attributes." Where in the specification (JSP 1.2) is this specified? Is it derived from section 10.3?, or is it mentioned explicitly somewhere else? See JSP.10.1.1 in the JSP 1.2 spec: Methods There are two main actions: doStartTag and doEndTag. Once all appropriate properties have been initialized, the doStartTag and doEndTag methods can be invoked on the tag handler. Between these invocations, the tag handler is assumed to hold a state that must be preserved. After the doEndTag invocation, the tag handler is available for further invocations (and it is expected to have retained its properties). Lifecycle [...] * [3] Note that since there are no guarantees on the state of the properties, a tag handler that had some optional properties set can only be reused if those properties are set to a new (known) value. This means that tag handlers can only be reused within the same "AttSet" (set of attributes that have been set). I could have sworn it was explicitly stated somewhere else as well, since bullet [3] is confusing; it's a description of a transition from "released" to "initialized", which by the way comes with a few more rules (e.g. the tag handler must recreate long-lived resources it may have created in its constructor when reused after release()). For JSP 2.0, however, the "same set of attributes" requirement is explicitly stated (from an upcoming PFD2): The JSP container may reuse classic tag handler instances for multiple occurrences of the corresponding custom action, in the same page or in different pages, but only if the same set of attributes are used for all occurrences. If a tag handler is used for more than one occurence, the container must reset all attributes where the values differ between the custom action occurrences. Attributes with the same value in all occurrences must not be reset. If an attribute value is set as a request-time attribute value (using a scripting or an EL expression), the container must reset the attribute between all reuses of the tag handler instance. Is this the way the Jasper tag pooling is implemented? As far as I have seen, yes. 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 at<http://TheJSPBook.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Tag reuse performance [Was: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked]
Costin Manolache wrote: Hans Bergsten wrote: Without pooling With pooling Reuse w/o overhead - 5 threads Avg.: 330 ms349 ms N/A Rate:15.2/sec 13.6/sec N/A 20 threads Avg.:1,752 ms 1,446 ms1,265 ms Rate:12.1/sec 13.6/sec14.7/sec To me, this indicates that if you can avoid _all_ reuse overhead, there's some performace to be gained from reuse but not much. With the From 1.2s to 1.7s there is about 35% difference. I would call this quite significant. Even between 1.4 and 1.7 - you have 20%. Try to increase the thread count to 100 - and you'll see this going up. The difference ( 0.5s ) is probably 2-3 times the response time of apache for a static page. And most users will feel it. I agree that in percentage, the difference is somewhat significant, but don't make too much out of the real value. My test server is not representative of the type of hardware you would use for a site with this type of load. On hardware suitable for the task, the difference in the real values will likely be a lot smaller, and IMHO, insignificant. But please, let's not start a long debate about what's significant or not (that depends on too many factors). All I'm trying to show with these simple tests is that for pooling to really make a difference at all, you need to avoid all overhead, which may be very hard, and that the overhead with current pooling seems to eat all potential gain. current implementation, however, the overhead seems to kill all gains from creating fewer instances. I doubt increasing MAX_POOL_SIZE makes much of a difference. Increasing it from the current 5 - it would make a difference. I agree - the "ideal" no overhead is harder to achieve, but I think the thread-local,no-sync case is close enough. I'll try to reproduce the test. BTW, how many requests did you make, and what was the max response time ( max is very affected by GC ) ? I usually do 5000 to warm up and 10.000 to run the test. I ran 10,000 requests for each test case after a manual warm up (just a few requests to give the JIT a chance to kick in). If I rerun the tests to capture GC data (as Glen was asking for), I can run a longer warm-up as well. I didn't record the max values, but IIRC they were around 100 sec in all cases. This is a very good start, thanks for bringing this up. I hope it at least gives us a better idea about what types of gains we can realistically expect from tag handler reuse. 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 at<http://TheJSPBook.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Tag reuse performance [Was: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked]
Glenn Nielsen wrote: Interesting. Your test JSP page looks like a valid test. Good. There is no data about GC in your tests, of course GC can happen at any time. I would be interested in seeing the tests run with -Xincgc and -Xverbose:gc. Then run a high enough volume of tests that a Full GC gets triggered a dozen times or so. I would think the GC data would be very different between the 5 thread and 20 thread tests with tag pooling enabled. The metrics to use might be the time spent doing GC, the number of incremental GC's, and the number of Full GC's. I can rerun the tests with these options and include a sample of the verbose:gc output. Does that help? I'm afraid I don't have the time to summarize the GC data as you suggest, but you're welcome to do so ;-) There is also no data about system CPU load. The tests show performance from a request latency and requests per second viewpoint, but do not necessarily show the difference in scaling. Showing CPU load might indicate whether one solution scales better than another. Any tips about the best way to measure CPU in a meaningful way on Linux? I know about top/gtop, vmstat, uptime etc. but they show system values (or snapshots of the current CPU for a thread). I vaguely recall using a command on Solaris many years ago that takes the command you want to measure as an argument and gives you min, max and average CPU when it completes, but I've forgot what it's called. Does it ring any bells? If not, what do you recommend to measure CPU? Hans Hans Bergsten wrote: Hans Bergsten wrote: Costin Manolache wrote: [...] Wow. I would be _very_ curious to see those benchmarks and the "modern" JVM that was used. All my tests ( including JDK1.4, IBM vms, GCJ ) show that reusing is well worth the trouble - at least if you have 100s of requests per second ( it is not worht the trouble for very low loads ). But I'm happy to hear that I'm wrong. I'll try to find the figures we looked at and post them, or run a new benchmark against TC 4.1 with and without tag handler pooling enabled. But it may take some time, because right now I'm busy with other stuff. If you disagree with the decision, you may want to send your feedback to the EG: [EMAIL PROTECTED] JSP 2.0 is still just PFD. Okay, I ran a few test cases with Tomcat 4.1.18. Benchmarks are of course never perfect, but it should be good enough to evaluate the difference with and without tag handler reuse. My test server is a 1 GHz Pentium with 256 MB, with Sun's Linux JDK 1.4.1. I ran all tests with Apache JMeter, once with 5 threads (so the MAX_POOL_SIZE is not exceeded) and one time with 20 threads, with and without pooling enabled. I also hacked the servlet class generated with pooling enabled so that there's no overhead from the reuse itself. I simple create one instance of each tag handler at the beginning of the _jspService() method and use this instance for all invokations. This is as efficient as it can be, with no extra cost for synchronization or Map lookups. I ran this test once with 20 threads. I used this test page: <%@ page contentType="text/plain" %> <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core"; %> While it's simple, it should show the impact of tag handler reuse. With pooling disabled, one tag handler instance is created for the outer , a new one is created for the inner for each pass through the loop (i.e. 100 instances), and a new instance for is created for each invokation (i.e. 1000 instances). With pooling enabled, the total number of instances depends on the number of concurrent requests. For the 5 threads tests, it should stay close to 5 instances (although non-pooled instances may occasionally be created and released immediately). For the 20 threads test, a lot more instances are created (since the pool is currently limited to 5 instances), but it should still be less than when pooling is disabled. Okay, here are the results Without pooling With pooling Reuse w/o overhead - 5 threads Avg.: 330 ms349 ms N/A Rate:15.2/sec 13.6/sec N/A 20 threads Avg.:1,752 ms 1,446 ms1,265 ms Rate:12.1/sec 13.6/sec14.7/sec To me, this indicates that if you can avoid _all_ reuse overhead, there's some performace to be gained from reuse but not much. With the current implementation, however, the overhead seems to kill all gains from creating fewer instances. I doubt increasing MAX_POOL_SIZE makes much of a difference. Feel free to run the test on your platform. It could be interesting to see some more results. Also, if you think my test page is flawed, I'd appreciate ideas for how to improve
Tag reuse performance [Was: Re: DO NOT REPLY [Bug 16001] - Tag.release()not invoked]
Hans Bergsten wrote: Costin Manolache wrote: [...] Wow. I would be _very_ curious to see those benchmarks and the "modern" JVM that was used. All my tests ( including JDK1.4, IBM vms, GCJ ) show that reusing is well worth the trouble - at least if you have 100s of requests per second ( it is not worht the trouble for very low loads ). But I'm happy to hear that I'm wrong. I'll try to find the figures we looked at and post them, or run a new benchmark against TC 4.1 with and without tag handler pooling enabled. But it may take some time, because right now I'm busy with other stuff. If you disagree with the decision, you may want to send your feedback to the EG: [EMAIL PROTECTED] JSP 2.0 is still just PFD. Okay, I ran a few test cases with Tomcat 4.1.18. Benchmarks are of course never perfect, but it should be good enough to evaluate the difference with and without tag handler reuse. My test server is a 1 GHz Pentium with 256 MB, with Sun's Linux JDK 1.4.1. I ran all tests with Apache JMeter, once with 5 threads (so the MAX_POOL_SIZE is not exceeded) and one time with 20 threads, with and without pooling enabled. I also hacked the servlet class generated with pooling enabled so that there's no overhead from the reuse itself. I simple create one instance of each tag handler at the beginning of the _jspService() method and use this instance for all invokations. This is as efficient as it can be, with no extra cost for synchronization or Map lookups. I ran this test once with 20 threads. I used this test page: <%@ page contentType="text/plain" %> <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core"; %> While it's simple, it should show the impact of tag handler reuse. With pooling disabled, one tag handler instance is created for the outer , a new one is created for the inner for each pass through the loop (i.e. 100 instances), and a new instance for is created for each invokation (i.e. 1000 instances). With pooling enabled, the total number of instances depends on the number of concurrent requests. For the 5 threads tests, it should stay close to 5 instances (although non-pooled instances may occasionally be created and released immediately). For the 20 threads test, a lot more instances are created (since the pool is currently limited to 5 instances), but it should still be less than when pooling is disabled. Okay, here are the results Without pooling With pooling Reuse w/o overhead - 5 threads Avg.: 330 ms349 ms N/A Rate:15.2/sec 13.6/sec N/A 20 threads Avg.:1,752 ms 1,446 ms1,265 ms Rate:12.1/sec 13.6/sec14.7/sec To me, this indicates that if you can avoid _all_ reuse overhead, there's some performace to be gained from reuse but not much. With the current implementation, however, the overhead seems to kill all gains from creating fewer instances. I doubt increasing MAX_POOL_SIZE makes much of a difference. Feel free to run the test on your platform. It could be interesting to see some more results. Also, if you think my test page is flawed, I'd appreciate ideas for how to improve it. 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 at<http://TheJSPBook.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
Tim Moore wrote: [...] I thought the benefit of Tag.release and pooling was that I could create a tag that does something expensive at init time (acquire a DB connection, read a file, whatever) and reuse those resources until released. Maybe that's a bad practice? But then what's the advantage of having release called only once before GC? Yes, that was the idea, and since the "classic" API is still part of JSP 2.0, you can use it for this type of tag handler if you need it. Most tag handler's don't need it though (you can often cache the expensive objects elsewhere, such as in the application or session scope). So for the majority of case, the SimpleTag API will be the best fit. 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 at<http://TheJSPBook.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
Costin Manolache wrote: Hans Bergsten wrote: evaluation all in one place. To make things even easier, these tag handlers can _not_ be reused at all. Benchmarks with modern JVMs show that the gain from reuse is not worth all the trouble. So, for new tags we recommend using the SimpleTag API which takes care of the problem by forbidding reuse. Wow. I would be _very_ curious to see those benchmarks and the "modern" JVM that was used. All my tests ( including JDK1.4, IBM vms, GCJ ) show that reusing is well worth the trouble - at least if you have 100s of requests per second ( it is not worht the trouble for very low loads ). But I'm happy to hear that I'm wrong. I'll try to find the figures we looked at and post them, or run a new benchmark against TC 4.1 with and without tag handler pooling enabled. But it may take some time, because right now I'm busy with other stuff. If you disagree with the decision, you may want to send your feedback to the EG: [EMAIL PROTECTED] JSP 2.0 is still just PFD. 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 at<http://TheJSPBook.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
Tim Moore wrote: [...] I agree that the current behavior of release should not change. There are important uses for long-term state that we shouldn't throw away just because of some confusion. Right. But what do you think about the idea of adding a new method? My thinking is that if there were a reset method where people could reset invocation-local state, then it would be easier for people to understand the correct purpose of release in contrast. I know there are perfectly good ways to reset now, so this change would be more for psychological reasons than technical ones. You have to admit, though, the fact that this misunderstanding is so common does say something about the clarity of the API. I made this mistake initially, and I believe many of the Jakarta tags did as well. Yes, the whole reuse things was pretty much unspecified in JSP 1.1. When we tried to clarify it in JSP 1.2, we discussed adding a reset() method at length (the reuse discussions are by far the most intense discussions in the JSP EG ;-) but in the end decided to keep the API backwards compatible and bolt reuse on top of it (with the various rules for when release() can be called, only reuse for the same attribute set, etc.). In hindsight, I think it was a mistake, but that boat has sailed. See below. I also know that adding methods to an interface can be problematic for backwards compatibility reasons, but if a noop implementation is added to TagSupport, that would handle 90% of the problem. What do you think? That's the main reason that we decided to not add a method in JSP 1.2, and the same applies to JSP 2.0. Even though you can minimize the problem by adding a noop in TagSupport, you're still not covering 100% of the cases. Another reason for not doing this in JSP 2.0 is that JSP 2.0 introduces a new tag handler API: SimpleTag. This API has a much simpler lifecycle, basically just attribute setters and one doTag() method that, coupled with the new JspFragment API, handles iterations and accessing the body evaluation all in one place. To make things even easier, these tag handlers can _not_ be reused at all. Benchmarks with modern JVMs show that the gain from reuse is not worth all the trouble. So, for new tags we recommend using the SimpleTag API which takes care of the problem by forbidding reuse. 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 at<http://TheJSPBook.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
Tim Moore wrote: This bug seems to be submitted several times a week. Maybe an FAQ would be in order? (or FOB -- frequently opened bugs haha) Then again, if people don't search the bug database before submitting a new one, then I guess they can't be expected to read the FAQ. And on the other hand, if the spec confuses this many people, maybe that should be fed back to the spec authors. Just adding a "reset" method to Tag that is called before each invocation might help people understand the difference between that and release. I'm in the EG and we had a long discussion about this again for JSP 2.0. The end result is that the current behavior (do _not_ call release() between invocations) will stay. A confusing arrow from the "released" state to the "initialized" state in the state diagram will be removed, however. This state transition came with lots and lots of restrictions, but it seems like some vendor (and developers) saw it as a requirement to call release() between invocations, even though the text clearly state that that's not the case. This is being discussed pretty much everywhere these days and I hope people eventually will get it. I wrote about it in an article just after JSP 1.2 was released. Feel free to point people to it if you get tired of rehashing the same arguments over and over ;-) <http://www.onjava.com/pub/a/onjava/2001/11/07/jsp12.html> Page 2, the "Tag handler life cycle and instance reuse" section 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 at<http://TheJSPBook.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [PATCH] forward instead of redirect for welcome files
Matt Parker wrote: On Mon, 2003-01-06 at 12:14, Hans Bergsten wrote: Matt Parker wrote: I'd like to suggest that catalina perform a forward, rather than a redirect, for requests that end with '/'. With a redirect, special configuration is necessary for proxy servers to work correctly. Also, a forward doesn't require an additional round trip to the client--a redirect must get back to the client and the client then issues a new request. I've tested this under Linux. Thanks! You mean requests that do _not_ end with '/', right? Unfortunatly, you must do a redirect in this case so that the browser can resolve relative paths in the page correctly. If you use a forward, it can't do so correctly. Hans No, I mean requests that _do_ end with a trailing slash, but that should be resolved to one of the files specified in the web application's . This is similar to Apache's DirectoryIndex directive. Maybe the following Apache documentation snippet can explain it more clearly than I can: "The DirectoryIndex directive sets the list of resources to look for, when the client requests an index of the directory by specifying a / at the end of the a directory name." For Apache, this is index.html by default. When Apache receives a trailing slash (e.g. /foo/bar/), it resolves index.html and returns it. Note that it does _not_ send a redirect to index.html. The redirect occurs only when there is no trailing slash at the end of a directory request (e.g. /foo/bar is redirected to /foo/bar/, which is then resolved to index.html) So tomcat's behavior is actually going against what Apache does. Hope I'm explaining it correctly. Okay, that's different. Maybe I misread your patch, but to me it looked as if you changed the behavior when there's no trailing slash. Anyway, I leave it to Costin to decide if it can be applied safely or not. 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 at<http://TheJSPBook.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [PATCH] forward instead of redirect for welcome files
Matt Parker wrote:
I'd like to suggest that catalina perform a forward, rather than a
redirect, for requests that end with '/'. With a redirect, special
configuration is necessary for proxy servers to work correctly. Also, a
forward doesn't require an additional round trip to the client--a
redirect must get back to the client and the client then issues a new
request. I've tested this under Linux. Thanks!
You mean requests that do _not_ end with '/', right? Unfortunatly,
you must do a redirect in this case so that the browser can resolve
relative paths in the page correctly. If you use a forward, it can't
do so correctly.
Hans
--- DefaultServlet.java 2003-01-03 16:20:23.0 -0700
+++ DefaultServlet.java.new 2003-01-03 16:20:18.0 -0700
@@ -942,26 +942,18 @@
if (!request.getRequestURI().endsWith("/")) {
String redirectPath = path;
-String contextPath = request.getContextPath();
-if ((contextPath != null) && (!contextPath.equals("/"))) {
-redirectPath = contextPath + redirectPath;
-}
if (!(redirectPath.endsWith("/")))
redirectPath = redirectPath + "/";
redirectPath = appendParameters(request, redirectPath);
-response.sendRedirect(redirectPath);
+request.getRequestDispatcher(redirectPath).forward(request, response);
return;
}
ResourceInfo welcomeFileInfo = checkWelcomeFiles(path, resources);
if (welcomeFileInfo != null) {
String redirectPath = welcomeFileInfo.path;
-String contextPath = request.getContextPath();
-if ((contextPath != null) && (!contextPath.equals("/"))) {
-redirectPath = contextPath + redirectPath;
-}
redirectPath = appendParameters(request, redirectPath);
-response.sendRedirect(redirectPath);
+request.getRequestDispatcher(redirectPath).forward(request, response);
return;
}
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
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 at<http://TheJSPBook.com/>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [PROPOSAL] EL Transition to Jakarta Commons
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 at<http://TheJSPBook.com/>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
AW: [VOTE] minimal JSR 154 only distribution
Hi, I would like to have the possibility to not include jasper in our production system. We are using TC 3.3.2-dev plus Velocity. It does not really hurt us, but having fewer code is always better IHMO :) I really love the modularity og TC 3.3.x Bill, can you give me hints, how to patch TC 3.3.2-dev to exclude jasper ? Another thought regarding the Admin Webapp in TC 4.x/TC 5.0: (please forgive me if I am completly off the track here) I would rather like to be able to use the Admin Webapp on a seperate remote Admin Tomcat to control our production system. I really do not want to install such sensitive code on our live servers. So the Admin Webapp could connect to the production Tomcat and execute for example ant tasks to restart contexts, deploy a webapp and so on. (The localhost shutdown restriction is no option, since our servers are at out ISP and have to be controlled from within our office.) Thanks, Hans > -Ursprüngliche Nachricht- > Von: Bill Barker [mailto:[EMAIL PROTECTED]] > Gesendet: Samstag, 7. Dezember 2002 09:59 > An: Tomcat Developers List > Betreff: Re: [VOTE] minimal JSR 154 only distribution > > > It would cause nightmares if you knew how badly I've got my e-mails > cross-linked :). > > This is to +1 the original VOTE. While I'm personally a heavy JSP user, > having patched TC 3.3.x to allow it to run in servlet-only mode, I see the > need for offering a servlet-only container. > > According to the Costin-vote-watch, we still need at least one more > (binding) +1 to authorize a servlet-only release of Tomcat. > > - Original Message - > From: "IAS" <[EMAIL PROTECTED]> > To: "'Tomcat Developers List'" <[EMAIL PROTECTED]> > Sent: Friday, December 06, 2002 11:02 PM > Subject: RE: [VOTE] minimal JSR 154 only distribution > > > > I'm very glad to see this vote proposal because it seems to me like the > > first step of Servlet/JSP mutual independence. > > > > Two months ago I proposed Tomcat architectural refactoring plan (at that > > time "Tomcat subproject plan") on > > http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg34720.html. > > I also showed JSF+Struts+Catalina ensemble on > > http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg35116.html > > and a possible Jasper-Catalina relationship on > > http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg35119.html. > > I sincerely understand a very few of Tomcat committers share interest in > > this issue like jean-frederic clere's seconding on > > http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg34768.html. > > > > > > In my humble opinion, in terms of technology, it is not imperative that > > Servlet should go with JSP. In fact, the mother of Tomcat, JServ also > > started as a Servlet engine. In other words, Servlet technology itself > > is independent one. It also implies that Java Web developers have > > freedom of choosing dynamic page generation technology over Servlet. We > > can say we have right to use JSP, but on the other hand, we have right > > not to use JSP in purely technical perspective. > > > > However, I totally agree on the need that we deliver JSP equipped Tomcat > > for the majority of Tomcat users who are very familiar with JSP (even > > cannot live without JSP like me :-). I guess the problem is "Who will do > > (or exactly speaking, be willing to do) the job, i.e. making > > Servlet-only-Tomcat since we need a considerable number of Tomcat > > committers (Costin said 3) for that. If we get wide support from Tomcat > > committers but they can't afford the job, how about gathering > > Servlet-only-Tomcat team whether they belong to committers or not? I > > hope there would be many people who will volunteer for that, including > > myself. The detailed processes respecting the work could be discussed > > from now on, and this chance might be a new attempt to develop greater > > Tomcat empowered by volunteers. > > > > Thanks in advance. > > IAS > > > > === > > Lee, Changshin (Korean name) > > IAS (International name) > >Company Web Site: http://www.tmax.co.kr > >Personal Web Site: http://www.iasandcb.pe.kr > > --- > > Senior Researcher & Java Technology Evangelist > > JCP member - http://jcp.org/en/participation/members/L > > R&D Institute > > Tmax Soft, Inc. > > JCP member - http://jcp.org/en/participation/members/T > > ===
Re: JspC enhancement
I like the way JspC works in Tomcat 4.0.x (at least from 4.0.4 and forward). As far as I can tell, it does exactly what you want without the need for extra options (it generates directory-based packages by default). I'm sorry I still haven't found the time to look into the problems with the Tomcat 4.1.x version of JspC, but maybe someone who's close to the Jasper2 source can explain why the Tomcat 4.0.x JspC approach had to be changed for Tomcat 4.1.x, and what the problems are with getting it back to its original behavior at this point? Before we start adding new options, I'd like to understand why we can't just preserve the features we had in TC 4.0.x. Hans Brent Jenkins wrote: Hi, I'd like to propose a change to org.apache.jasper.JspC in Tomcat4.1.12. Specifically, I'd like to introduce a new command line argument: "-pp" to apply a package name prefix and create the package name based on the jsp directory structure. Tomcat4's "-p" option applies the package name prefix, but creates all the jsps in the same package. This leads to "duplicate class" problems if two jsps in different directories share the same name. BACKGROUND: Our company used to use JspC in Tomcat3 to precompile our JSPs for deployment. Tomcat3 JspC used to generate package names for the JSPs that were based on the directory structure of the jsp directory. We've recently moved to Tomcat4, and this feature apparently didn't carry over to Tomcat4 codeline. EXAMPLE: Given a directory structure of: /jsp/index.jsp /jsp/employee/index.jsp Tomcat3 using JspC like this: java org.apache.jasper.JspC -d . -p foo.bar would yield package and class names of: package foo.bar.jsp; public class index extends HttpJspBase package foo.bar.jsp.employee; public class index extends HttpJspBase Tomcat4 using JspC like this: java org.apache.jasper.JspC -d . -p foo.bar would yield package and class names of: package foo.bar; public class index_jsp extends HttpJspBase package foo.bar; public class index_jsp extends HttpJspBase We'd get a duplicate class definition error here. Thus Tomcat4 using my proposed JspC like this: java org.apache.jasper.JspC -d . -pp foo.bar would yield package and class names of: package foo.bar.jsp; public class index_jsp extends HttpJspBase package foo.bar.jsp.employee; public class index_jsp extends HttpJspBase I'd love to get this committed to the tomcat4 sources. Any suggestions? I've included the code at the end of the email. Sincerely, Brent Jenkins /* * $Header: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v 1.12.2.1 2002/08/21 17:54:24 kinman Exp $ * $Revision: 1.12.2.1 $ * $Date: 2002/08/21 17:54:24 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *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 (http://www.apache.org/)." *Alternately, this acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. * * 4. The names "The Jakarta Project", "Tomcat", 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 Group. * * 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
Re: [Jasper2] framework for tag optimization
Peter Romianowski wrote: If you think using it for JSTL is okay, why wouldn't it be okay for other tag libraries? The same issues (if they are issues) apply to JSTL, don't they? I thought of it beeing done by the jasper-crew, i.e. being part of "stock tomcat", so it could be assured that it is working correct. Well, I hope that it the plugin API would be easy enough to use to ensure that others than the "jasper crew" can get it right for other tig libraries ;-) The way I understand the proposal is that it *could* be some kind of a replacement for a tag-library. So for conformity and interoperability a programmer would have to implement the plugin *AND* the taghandler. (And I extremely doubt that many will). I may be wrong, but I don't think the proposal is a replacement. For instance, the config file makes a reference to the tag handler class (the element). I was involved in a discussion about a "precompile all JSPs in a webapp"-functionality (which was wanted by *many* users). I was willing to contribute to it, but the developers (Craig himself, I think :) said that such a thing would not belong to a reference i mplementation of a servlet-container. After he told me so, I agreed with him, although I still would like to have this feature. :) So that was the reason why I posted my comments. This was before I rejoined this list, so I can't comment on that specific proposal (yes, I _could_ look for it in the archives, but I wont ;-) In general, though, I don't see anything wrong with adding non-standard features to Tomcat, as long as they are clearly optional and the behavior defined by the spec still works. In fact, there was a discussion about this in the Jakarta PMC when Jakarta was formed. The consensus at the time was that Tomcat has to be spec compliant (it _is_ the RI, after all), but that there are no restrictions on additional features. As an application developer I would say: "YES! Give me that plugin- feature!" since it would improve performance drastically. So, I like the idea but I am not sure if such a thing would belong to "stock tomcat". As long as a feature doesn't break spec conformance, it should be fine. For this specific proposal (assuming my understanding of it is correct), I don't see any problems. 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 at<http://TheJSPBook.com/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [Jasper2] framework for tag optimization
Peter Romianowski wrote:
Just a thought: Doesn't this breack the standard conformance
tomcat is all about?
If I understand the proposal correctly, I don't see that it breaks
standard conformance (I'm in the JSP JRE group, BTW). As long as
it doesn't require extra, non-standard directives or elements in the
JSP files, it's just a proprietary way to get better performance
when using Tomcat. The same JSP files would work fine in any other
JSP container, except that they may run a bit slower.
Another way to look at it. The JSP spec allows a container to do
tricks like this for "well-known tag libraries", such as JSTL. The
proposed feature can be seen as a just way to add other "well-known
libraries", where the knowledge is encoded by the tag library
developer instead of the container developer.
One could easily be bound to tomcat after
writing some plugins that break the initial semantics of a tag.
Sure, but then you have done things with the plugin feature that it's
not supposed to be used for. It's no different than relying on
non-standard APIs a container may provide.
I think there is no way to assure the correctness of a plugin-
implementation, so it would become impossible to switch to
another servlet-container. And I saw many improvement-discussion
on this list, which had been canceled with exact this reason.
Hmm... Testing the app with and without the plugin seems like a
reasonable approach to ensure it's correct. The plugin feature should
only be used to improve performance, not to add behavior.
But having plugins for standard tags (JSTL) out of the box
would be great in respect of performance.
If you think using it for JSTL is okay, why wouldn't it be okay for
other tag libraries? The same issues (if they are issues) apply to JSTL,
don't they?
Hans
-Original Message-
From: Peter Lin [mailto:[EMAIL PROTECTED]]
Sent: Saturday, November 23, 2002 4:59 AM
To: Tomcat Developers List; Kin-Man Chung
Subject: Re: [Jasper2] framework for tag optimization
hey kin-man,
that sounds great! I was actually thinking along those lines
a while back, but thought it was impracticle because the
project I was working one didn't have enough time to explore
that approach.
when I was doing performance analysis of jasper1 with jslt
and saw how bad the performance was (due to the nested
try/catch bug), I went through and manually wrote scriplet
code to do the same exact logic. The performance compared to
jasper1 + jstl was tremendous. I had full mockups of a 3
pages written in JSTL and pure scriplet.
If memory serves me correctly, the difference was 5-8x. the
JSTL version using jasper1 would take 900-1000ms+ to display
15 results. The same exact page using scriplet took about
100-150ms. I would definitely be interested in spending time
on this and assisting. I may have some time opening up next
year, so I hope to start contributing actively :) cross my fingers.
peter lin
Kin-Man Chung <[EMAIL PROTECTED]> wrote:I am
designing a framework in Jasper for enabling plugins that
work closely with Jasper to generate Java codes instead of
calls to tag handlers. The main idea is to take take JSTL
tags, such as
${i}
and generates the Java codes
for (int i = 0; i <= 100; i++) {
pageContext.setAttribute("i", String.valueOf(i));
out.print(evaluate("${i}"));
}
or even
for (int i = 0; i <= 100; i++) {
out.print(i);
}
The design is not to do the actual optimization in Jasper,
but to provide a framework for taglib writers to develop
plugins to Jasper that will do the actual optimization.
Eventually, Jasper will be bundled with 1 or 2 plugins for
JSTL, as test cases for the framework and as examples for
writing the plugins.
The plugins are specified in a xml file:
the name of the tag class
the name of the pkugin class
There are currently 3 interfaces:
TagPluginFactory
Used for creating a TagPlugin.
TagPlugin
Created at code generation time for a specific tag
invokation. Used by Jasper to generate java codes.
TagPlugContext
Created by Japser and used by the plugin to query properties
of the current tag, and to use resources in Jasper.
This work is at the very early stage of the design, and is
purely experimental. I'll be checking in sources for this
work, and they should not affect the other part of Jasper,
when plugins are not turned on.
I welcome comments and suggestions.
--
To unsubscribe, e-mail:
For additional commands, e-mail:
-
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software <http://www.gefionsoftware.com/>
Author of O'Reilly'
AW: Nightly TC 3.3.x builds not working anymore?
Last time they were created was 08-Nov-2002 but today is the 20.11.2002 ;) http://jakarta.apache.org/builds/jakarta-tomcat/nightly-3.3.x/ Parent Directory - JmxSupport.war 08-Nov-2002 06:28 459K PasswordPrompter.war08-Nov-2002 06:28 23K StreamHandler.war 08-Nov-2002 06:28 9.4K jakarta-tomcat-3.3.2-dev-src.tar.gz 08-Nov-2002 06:07 2.9M GZIP compressed file jakarta-tomcat-3.3.2-dev-src.zip08-Nov-2002 05:22 3.1M jakarta-tomcat-3.3.2-dev.tar.gz 08-Nov-2002 06:08 5.4M GZIP compressed file jakarta-tomcat-3.3.2-dev.zip08-Nov-2002 05:27 5.5M jsp-tests.war 08-Nov-2002 06:28 318K servlet-tests.war 08-Nov-2002 06:28 1.8M test.war08-Nov-2002 06:28 165K > -Ursprungliche Nachricht- > Von: Henri Gomez [mailto:[EMAIL PROTECTED]] > Gesendet: Mittwoch, 20. November 2002 10:41 > An: Tomcat Developers List > Betreff: Re: Nightly TC 3.3.x builds not working anymore? > > > Hans Schmid wrote: > > Hi, > > > > the nightly build of Tomcat 3.3.x seems to have stopped at 08-Nov-2002. > > > > Any Idea, why? > > > > Cheers, > > Hans > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > > What's the error ? > > > > -- > 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]>
Nightly TC 3.3.x builds not working anymore?
Hi, the nightly build of Tomcat 3.3.x seems to have stopped at 08-Nov-2002. Any Idea, why? Cheers, Hans -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: TagHandlerPool doesn't release Tags on reuse
Torsten,
You may want to read the section about the tag handler lifecycle in an
article I wrote for ONJava.com:
<http://www.onjava.com/pub/a/onjava/2001/11/07/jsp12.html>
It explains how the methods are called and how to deal with attribute
values.
Hans
Torsten Fohrer wrote:
But if i looking into the generated jsp/servlet sources, i see the following:
--- example ---
/* tools:simpleCell */
de.dcsi.util.jsp.taglibs.Validator_SimpleCell
_jspx_th_tools_simpleCell_0 = (de.dcsi.util.jsp.taglibs.Validator_SimpleCell)
_jspx_
tagPool_tools_simpleCell_width_valign_messageName_height_errorName_errorColor.get(de.dcsi.util.jsp.taglibs.Validator_SimpleCell.class);
_jspx_th_tools_simpleCell_0.setPageContext(pageContext);
_jspx_th_tools_simpleCell_0.setParent(null);
_jspx_th_tools_simpleCell_0.setErrorName("messages");
_jspx_th_tools_simpleCell_0.setMessageName("login");
_jspx_th_tools_simpleCell_0.setHeight("30");
_jspx_th_tools_simpleCell_0.setValign("top");
_jspx_th_tools_simpleCell_0.setWidth("14%");
_jspx_th_tools_simpleCell_0.setErrorColor( errorColor );
int _jspx_eval_tools_simpleCell_0 =
_jspx_th_tools_simpleCell_0.doStartTag();
if (_jspx_th_tools_simpleCell_0.doEndTag() ==
javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
return;
example
If i now reset my tag to a initial state in doStartTag() i haven't any
properties set
Who call the release method in reaction of the GC, finalize can't it.
On Monday 11 November 2002 18:44, Kin-Man Chung wrote:
According to the JSP 1.2 Spec, the release method is not invoked between
tag usages, but is invoked before GC of the tag handler. Therefore
it should not be used to reset the tag handler to its initial state;
you should do that in doStartTag. See p164 and p166.
Date: Mon, 11 Nov 2002 13:32:31 +0100
From: Torsten Fohrer <[EMAIL PROTECTED]>
Subject: TagHandlerPool doesn't release Tags on reuse
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
I have some jsp sites which taglibs. With pooling enabled, some problems
occures.
Samples:
Customer Registration: all fields have the same values???
Sessions Values are used together
After reading the jsp spezifikation and source of the
jasper/runtime/TagHandlerPool, i see that the pool doesn't call release
in his reuse method?
After adding a general release in the reuse methode, which perhaps breaks
the lifecycle of the IterationTag ( see jsp-spec, page 168 ) it's
working.
/**
* Adds the given tag handler to this tag handler pool, unless this
tag * handler pool has already reached its capacity, in which case the
tag * handler's release() method is called.
*
* @param handler Tag handler to add to this tag handler pool
*/
public synchronized void reuse(Tag handler) {
// Releasing Tags, see jsp spec 1.2-fcs, page 172
handler.release();
if (current < (handlers.length - 1))
handlers[++current] = handler;
}
Torsten Fohrer
**
* DCSI AG* Tel.: +49 7131 155 88-0 *
* Lessingstrasse 17-19 * Fax.: +49 7131 155 88-99 *
* D-74076 Heilbronn * [EMAIL PROTECTED]*
* GERMANY* http://www.dcsi.de*
**
--
To unsubscribe, e-mail:
<mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional
commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
--
To unsubscribe, e-mail:
<mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands,
e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
--
To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
--
Hans Bergsten [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
JavaServer Pages http://TheJSPBook.com
--
To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Costin Manolache wrote: Hans Bergsten wrote: Removing the CLI and keeping the basic functionality seems like a good idea. "CLI" as in ...? Sorry, I'm not familar with this acronym. Command line interface. jspc.sh, main() and the argument processing. Ah, I should have known ;-) Just use the jspc task in ant. My understanding is that ant's can also generate code for other containers, so one extra benefit. But why should we require Ant? Isn't it better to refactor the code so that the CLI interface and the Ant task can use the same core, just using different interfaces? [...] I would go even further - since we are already using ant to compile the java to .class, it may be a good idea to make the .jsp->.java task 'first class'. Not sure I follow. If you mean to do this in addition to fixing JSPC (with the -webapp option), it's okay with me. Basically add an execute() method and setters to Compiler, and calling jasper indirectly, using the ant task. Jasper will be a very large ant task. That means we could switch jasper versions ( or other jsp impl ), it could be used in other containers or applications, etc. Are you saying pretty much what I said above: a common core that can be used both a an Ant task implementation and a CLI? ( well, I'm not volunteering for that - but I think it would be a nice idea for 5.0 ). I agree that this type of refactoring is better targetted for TC 5. For TC 4.1.x I suggest we just fix what's broken. I still haven't heard what _is_ broken, though. Can someone tell me? I'll start running some test soon (this weekend, most likely) with TC 4.1.14 (or .15 if it's available by then) and see what I'll find. > [...] Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com JavaServer Pages http://TheJSPBook.com -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Glenn Nielsen wrote: Remy Maucherat wrote: [...] I agree that JSPC needs to be simplified and that the webapp mode should be retained. But the webapp mode should allow for a war file to be generated which is self contained including the precompiled JSP classses. And for the generated war to be able to run from the war file with no need to unpack it. Why add this to JSPC? Isn't it already very easy to use external tools to create the WAR file (the jar command, ant's war task, etc)? I have no objections to cleaning up the JSPC code, but I would like it to stay focused on it's its main task: convert JSP source to servlet source. I have sometimes wished for automatic compilation of the servlet source to class files, but in the name of simplicity and separation of concerns, I think it's better handled by other tools. Also I agree that this feature is a proprietary feature of Tomcat and we should no longer try to generate a war that can be deployed in any container. Why not? This works today (at least in TC 4.0.4) and I find it very handy to be able to create a JAR file for all my JSPs that I know I can deploy to any container along with the jasper-runtime.jar. If there are issues with this that I don't know about, please tell me. Otherwise I see no reason to remove this capability. If you can use JSPC to create the servlet source and web.xml fragments, it's easy to use other tools to compile the source and create a WAR with all other parts of the app (servlets, taglibs, web.xml, static stuff, etc.) and deploy it to Tomcat or any other container. As far as I can see, there's no need for a proprietary solution to get this to work. > [...] Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com JavaServer Pages http://TheJSPBook.com -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Costin Manolache wrote: Remy has a point - the current code is not very clean, and doesn't seem to be tested/maintained enough. I use the ant tasks - and I have a feeling many other users of jspc are doing the same. Removing the CLI and keeping the basic functionality seems like a good idea. "CLI" as in ...? Sorry, I'm not familar with this acronym. For example compiling a jsp page outside a webapp can't work in all cases - if it has includes, etc it needs to resolve, it needs taglib definitions from WEB-INF, etc. I can't see any good reason to keep it if it's half broken by definition. Right, I agree. Also - compiling the java files is the job of , and the mapping and web.xml fragment generation can be more easily done using only the ant tasks. Even though I see one advantage with including compilation to class files in JSPC (simlicity, no need to set up Ant, which is not always available in the web app developers environment), I wasn't aware of the -compile option until this week (since it's not documented). I'm okay with removing it and handle compilation in other ways. I would go even further - since we are already using ant to compile the java to .class, it may be a good idea to make the .jsp->.java task 'first class'. Not sure I follow. If you mean to do this in addition to fixing JSPC (with the -webapp option), it's okay with me. In any case - the task is supported ( at least by me, it seems Henri is using it as well ). If there are people who want to support the CLI and the other options - then we can keep them, but if not - I think it's better to remove them or mark as unsupported. See above. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com JavaServer Pages http://TheJSPBook.com -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Remy Maucherat wrote: Hi, jspc is IMO overly complex, with many features nobody knows how to use, and nobody cares to test (hence sometimes some of them are randomly broken during Jasper refactorings). I will not formally vote on this, because I've been inactive in this project for so long I feel I need to familiarize myself with the current code base before I can exercise my voting priviledges. But I do have some comments, see below. I propose that: - In Tomcat 5, all jspc options are removed, in favor of allowing only the webapp mode (with its relevant options). This webapp mode would generate code and classes which should be deployed in the work directory, exactly the same as if they were dynamically compiled by Jasper (which has the big advantage of using only one big operation mode for everything). Single file mode is IMO useless (dynamic compilation works fine). I agree with you regading single file mode, but not with the rest. - In Tomcat 4.1, the options will stay in for compatibility, but the usage help will be modified to be the same as Tomcat 5. I'm not sure what you mean by this proposal. Are you saying that the TC 4.1.x version would have a usage message (documentation) that doesn't match its features? If so, why? If there will be differences between the TC 4.1.x and TC 5 versions, I assume we will maintain a separate code base for each version, each with documentation that correctly reflects their features. It has to be noted that: - The JSP runtime is now very efficient. The old webapp mode (with its static web.xml) is a hack (and a 100% proprietary one at that). Efficiency is not all that important here, since precomiplation is done before deployment (that's the whole idea, right ;-) Not sure what you mean with "100% proprietary". The web.xml file (or fragment) that is generated is defined by the servlet spec. - Precompilation should only occur at webapp deployment time in the general case (the generated code is closely tied to the Jasper runtime release). I don't agree. It's very handy to be able to generate a JAR file with all JSP pages for an application and deploy it to many different container instances (Tomcat or others, as long as jasper-runtime.jar is included). There are many users that want to keep the production environment as simple (and small in embedded systems, for instance) as possible, and deploying precompiled JSP pages lets me use a production environment without the JSP compiler and use JRE instead of the JDK. - Additional features could be added to the manager servlet to, for example, cause precompilation of the deployed webapp in a separate process. That's a separate thing, more of a container feature than JSPC in my mind. - I am -1 to returning to the old "webapp" option behavior (ie, the generated files should by default be deployed in the work directory, not /WEB-INF/classes). Why not discuss what the problems with the current options are, and try to find a solution instead? Like I've said, it's been a while since I was actively involved with Tomcat development, but I know that in Tomcat 4.0.4, JSPC seemed to work fine with all options available at the time. How did Jasper2 break things? If I understand what the main problem is, I can help find a solution (primarily for Tomcat 4.1.x; I'm afraid I don't have enough cycles to get into Tomcat 5 at the moment). Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com JavaServer Pages http://TheJSPBook.com -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
Re: Bug 13736
I will try by best next week. I have seen this only once in the logs, I have not been able to reproduce it yet. I'll do my best to reproduce the error conditions, and see if it occurs again. Cheers, Hans On Sun, 20 Oct 2002 00:08:33 -0700 "Bill Barker" <[EMAIL PROTECTED]> wrote: Remy's fix is now in the 3.3 nightly. Since you can reproduce this, it would be a big help if you could find a machine to test this on. - Original Message - From: "Hans Schmid" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Saturday, October 19, 2002 5:59 AM Subject: AW: Bug 13736 Bill, Remy, I have seen this one once on our production system running Tomcat 3.3.1 with AJP1.3, Apache 1.3.27, mod_jk 1.1.0 This is on Sparc Solaris 8 running JDK 1.3.1_04. 11019 is our ajp13 port (which we uswe also as shutdown port. No AJP 1.2 port open) Our webservers use the lb_worker to connect to the Tomcat servers (different machine) It occured, when we had a bug in our application causing an endless stacktrace, which filled up our logs.( 5000 !!! MB per minute). At some stage, the JVM crashed out after a stack overflow. Before the crash, tomcat got slower and slower due to the massive logging. 11019 is our ajp13 port (which we uswe also as shutdown port. No AJP 1.2 port open) I can reproduce the endless stacktrace, but am not sure to get the ServerSocket error (can not reproduce this on our production server for obvious reasons) PoolTcpEndpoint: Endpoint ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=11019] ignored exception: java.net.SocketException: Interrupted system call java.net.SocketException: Interrupted system call at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:463) at java.net.ServerSocket.implAccept(ServerSocket.java:238) at java.net.ServerSocket.accept(ServerSocket.java:217) at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultSe rverSocketFactory.java:107) at org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoint.java :326) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:472) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:516) at java.lang.Thread.run(Thread.java:479) 2002-10-05 16:01:24 - Ctx(/einsurance) : IllegalStateException in R( /einsurance + /view + /screens/car/carDescription.htm) - java.lang.IllegalStateException: Cannot forward because the response has already been committed at org.apache.tomcat.facade.RequestDispatcherImpl.doForward(RequestDispatcherIm pl.java:207) at org.apache.tomcat.facade.RequestDispatcherImpl.forward(RequestDispatcherImpl .java:174) at de.einsurance.gui.framework.ExceptionHandler.handle(ExceptionHandler.java:25 5) at de.einsurance.gui.framework.ExceptionHandler.handle(ExceptionHandler.java:15 1) at de.einsurance.gui.framework.ExtendedActionServlet.process(ExtendedActionServ let.java:69) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:491) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574) at org.apache.tomcat.core.Handler.invoke(Handler.java:322) at org.apache.tomcat.core.Handler.service(Handler.java:235) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485) at org.apache.tomcat.facade.RequestDispatcherImpl.doForward(RequestDispatcherIm pl.java:272) at org.apache.tomcat.facade.RequestDispatcherImpl.forward(RequestDispatcherImpl .java:174) at org.apache.struts.action.ActionServlet.processActionForward(ActionServlet.ja va:1758) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1595) at de.einsurance.gui.framework.ExtendedActionServlet.process(ExtendedActionServ let.java:65) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:491) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574) at org.apache.tomcat.core.Handler.invoke(Handler.java:322) at org.apache.tomcat.core.Handler.service(Handler.java:235) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:91 7) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833) at org.apache.tomcat.modules.server.Ajp13Interceptor.processConnection(Ajp13Int erceptor.java:341) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:516) at java.lang.Thread.run(Thread.java:479) Cheers, Hans > -Ursprungliche Nachricht- > Von:
AW: Bug 13736
Bill, Remy, I have seen this one once on our production system running Tomcat 3.3.1 with AJP1.3, Apache 1.3.27, mod_jk 1.1.0 This is on Sparc Solaris 8 running JDK 1.3.1_04. 11019 is our ajp13 port (which we uswe also as shutdown port. No AJP 1.2 port open) Our webservers use the lb_worker to connect to the Tomcat servers (different machine) It occured, when we had a bug in our application causing an endless stacktrace, which filled up our logs.( 5000 !!! MB per minute). At some stage, the JVM crashed out after a stack overflow. Before the crash, tomcat got slower and slower due to the massive logging. 11019 is our ajp13 port (which we uswe also as shutdown port. No AJP 1.2 port open) I can reproduce the endless stacktrace, but am not sure to get the ServerSocket error (can not reproduce this on our production server for obvious reasons) PoolTcpEndpoint: Endpoint ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=11019] ignored exception: java.net.SocketException: Interrupted system call java.net.SocketException: Interrupted system call at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:463) at java.net.ServerSocket.implAccept(ServerSocket.java:238) at java.net.ServerSocket.accept(ServerSocket.java:217) at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultSe rverSocketFactory.java:107) at org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoint.java :326) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:472) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:516) at java.lang.Thread.run(Thread.java:479) 2002-10-05 16:01:24 - Ctx(/einsurance) : IllegalStateException in R( /einsurance + /view + /screens/car/carDescription.htm) - java.lang.IllegalStateException: Cannot forward because the response has already been committed at org.apache.tomcat.facade.RequestDispatcherImpl.doForward(RequestDispatcherIm pl.java:207) at org.apache.tomcat.facade.RequestDispatcherImpl.forward(RequestDispatcherImpl .java:174) at de.einsurance.gui.framework.ExceptionHandler.handle(ExceptionHandler.java:25 5) at de.einsurance.gui.framework.ExceptionHandler.handle(ExceptionHandler.java:15 1) at de.einsurance.gui.framework.ExtendedActionServlet.process(ExtendedActionServ let.java:69) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:491) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574) at org.apache.tomcat.core.Handler.invoke(Handler.java:322) at org.apache.tomcat.core.Handler.service(Handler.java:235) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485) at org.apache.tomcat.facade.RequestDispatcherImpl.doForward(RequestDispatcherIm pl.java:272) at org.apache.tomcat.facade.RequestDispatcherImpl.forward(RequestDispatcherImpl .java:174) at org.apache.struts.action.ActionServlet.processActionForward(ActionServlet.ja va:1758) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1595) at de.einsurance.gui.framework.ExtendedActionServlet.process(ExtendedActionServ let.java:65) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:491) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574) at org.apache.tomcat.core.Handler.invoke(Handler.java:322) at org.apache.tomcat.core.Handler.service(Handler.java:235) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:91 7) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833) at org.apache.tomcat.modules.server.Ajp13Interceptor.processConnection(Ajp13Int erceptor.java:341) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:516) at java.lang.Thread.run(Thread.java:479) Cheers, Hans > -Ursprungliche Nachricht- > Von: Remy Maucherat [mailto:remm@;apache.org] > Gesendet: Freitag, 18. Oktober 2002 20:15 > An: Tomcat Developers List > Betreff: Re: Bug 13736 > > > Bill Barker wrote: > > > +1. As I said above, it probably hasn't shown up in 3.3 mostly because > > AJP13 has many fewer accepts. > > I'll fix it then. > > You have to be careful that no IOException should end up in that code,
AW: [POLL] Tomcat 3.3.2 updates
Hi, since our application uses TopLink, we can not upgrade to xerces 2. There are hardcoded xerces 1 classes used directly from TopLink. So 2) is a showstopper for all people with 3rd party jars requiring xerces 1 MBeans are useful for us, but not required. We are already using mx4j and mx4j-tools in our webapp together with xerces 1.4.0 and xalan 2.1.0 My preference would be. Leave it as it is, but give a short readme hat to copy where to be abe to use MxInterceptor Thanks, Hans > -Ursprungliche Nachricht- > Von: Henri Gomez [mailto:[EMAIL PROTECTED]] > Gesendet: Montag, 23. September 2002 16:02 > An: [EMAIL PROTECTED] > Betreff: [POLL] Tomcat 3.3.2 updates > > > Hi to all, > > If you tracked the discussion about MxInterceptor and it's > use in Tomcat 3.3.2-dev you should know that we have some > modification to Tomcat 3.3.2 jars layout to be able to > use MxInterceptor : > > 1) mx4j and mx4j-tools should goes in lib/common > > 2) mx4j-tools HTTP adaptor require TRAX (xalan), > so we should put in common/lib JAXP+XML PARSER+TRANSFORMER, > and as such could use : > > xerces-j2 2.1.0 > xalan-j2 2.4.0 > xml-commons-apis 1.0 > > Since these jars will be in lib/common, users won't be able > to use another one for it's own apps. > > 3) We'll have to remove JAXP/XML-PARSER for lib/container. > > > Thanks to give your opinion here. > > [ ] 1. Don't care about MBeans, or do want to be able to have > different XML apis for apps and container, so keep the > current situation. > > [ ] 2. MxInterceptor is really needed, ok to change the layout, > we'll warn users in Changelog / Readme > > [ ] 3. I'd like to MxInterceptor and old layout, I'd rather like to > have a copy of DynamicMBeanProxy from jtc/util located in > a location compatible with container/lib (to be in > container_util.jar we could copy it in org.apache.tomcat.util.mx) > > [ ] 4. I'd like to use MxInterceptor, keep the old layout, but don't > want to make the copy and could provide some code to avoid that. > > > Personally, I'd like solution 4 (but don't know how to), so I'll be > pragmatic and retains 3. > > > > > > -- > 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]>
[TC 5] XMLSchema validation and Xerces 2.1.0
Hi, as far as I understand, there are problems in Tomcat 5 with the XML Schema validation. A hack in Tomcat plus Xerces 2.0.1 are currentzly in the build system. Has anyone tried the new Xerces release 2.1.0 yet ? If 2.1.0 fixes the XML Schema problems it might be worth including it in Tomcat 4.1 as well Just a thought, Hans Schmid -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
AW: Proposal draft for Tomcat 5.0 : #3 Straw Man
Hi, > -Ursprüngliche Nachricht- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Gesendet: Samstag, 22. Juni 2002 06:32 > An: [EMAIL PROTECTED] > Betreff: Re: Proposal draft for Tomcat 5.0 : #3 Straw Man > > > Glenn Nielsen wrote: > > > > Proposal in General: > > > > The proposal is pretty vague on details. I have seen a number of > > replies stating "That's an implementation detail". I for one would > > like to see the proposal broken out into much more detail before > > work starts. Perhaps we should take a step back and start asking > > questions first so that there is more information and consensus for > > a formal proposal. Questions like: > > > >1. What code in Tomcat really smells bad? > >2. Based on the previews of the Servlet 2.4 and JSP 1.3 specs, > > what major changes are expected. > >3. Are there any major new features needed? Perhaps we can look into bugzilla to have a starting point here: Entries marked as 1.) Enhancement: May be candidates of 'new features wanted by users' or 'features needed in some user usecases' 2.) LATER: Things not implemented because it is too complicated with the current architecture -> these might point us to design problems to be addressed and possibly 3.) WONTFIX: There might be some entries which have the same reason as LATER (too complicated to implement on the existing codebase) just my 0.02 ;) Regards, HAns > > > > My fear is that work on Tomcat 5 will turn into a CVS version of > > the wild wild west if the proposal isn't detailed enough. > > > > +1. > > I will be out of town this weekend. I'll be checking > my mail, but I won't be able to participate as fully as I like > for the next day or so. I can't expect everything to grind to > a screeching halt because I'm not here. On the other hand, a > discussion as important as this needs to take place over the > course of a couple of normal business days so the entire > community has a chance to give input. > > > -- > Christopher St. John [EMAIL PROTECTED] > DistribuTopia http://www.distributopia.com > > -- > 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]>
AW: cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.2.txt
Hi I miss the following fix in there: Configuration: Bug No. Description 7520 Tomcat starts with title 3.3 instead of 3.3.1. Insert version string during build. Cheers, Hans > -Ursprüngliche Nachricht- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Gesendet: Freitag, 17. Mai 2002 07:15 > An: [EMAIL PROTECTED] > Betreff: cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.2.txt > > > billbarker02/05/16 22:15:29 > > Modified:.RELEASE-NOTES-3.3.2.txt > Log: > Document fix for #9165 > > Revision ChangesPath > 1.7 +3 -1 jakarta-tomcat/RELEASE-NOTES-3.3.2.txt > > Index: RELEASE-NOTES-3.3.2.txt > === > RCS file: /home/cvs/jakarta-tomcat/RELEASE-NOTES-3.3.2.txt,v > retrieving revision 1.6 > retrieving revision 1.7 > diff -u -r1.6 -r1.7 > --- RELEASE-NOTES-3.3.2.txt 30 Apr 2002 05:25:22 - 1.6 > +++ RELEASE-NOTES-3.3.2.txt 17 May 2002 05:15:29 - 1.7 > @@ -3,7 +3,7 @@ > Release Notes > = > > -$Id: RELEASE-NOTES-3.3.2.txt,v 1.6 2002/04/30 05:25:22 billbarker Exp $ > +$Id: RELEASE-NOTES-3.3.2.txt,v 1.7 2002/05/17 05:15:29 billbarker Exp $ > > >This document describes the changes that have been made since the > @@ -36,6 +36,8 @@ >7770Fixed thread race problem in accessing the Hooks. > >8092Fixed JSP source exposure proplem. > + > +9165Fix auto-detection of tomcat.install for certain > 1.1.x JDKs. > >Jasper: > > > > > > -- > 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]>
AW: startup.bat window
First, this is clearly a tomcat-user question. To find out, what is wrong, execute tomcat.bat run This will start tomcat in the same window. (TC 3.3.1 at least) I can't help you with the mySQL question though. Regards, Hans > -Ursprüngliche Nachricht- > Von: Bill Blackmon [mailto:[EMAIL PROTECTED]] > Gesendet: Mittwoch, 15. Mai 2002 14:16 > An: Tomcat Developers List > Betreff: startup.bat window > > > I'm trying to set the following JDBC Realm up: > > to use with mySQL. Obviously there is an error because the startup.bat > window flits off of the screen. > What can I do in startup.bat to make it stay opened so I can see what the > problem is? Also, can anyone point me > to a good example or a book that covers using mySQL and Tomcat together? > > > -- > 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]>
AW: PROPOSAL: mod_jk2: Group/Instance
> -Ursprungliche Nachricht- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Gesendet: Donnerstag, 2. Mai 2002 19:35 > An: Tomcat Developers List > Betreff: Re: PROPOSAL: mod_jk2: Group/Instance > > > On Thu, 2 May 2002, Bernd Koecke wrote: > > > misunderstood it. After you said that my patch is included a > had a closer look > > at mod_jk. I can't see anything of my code but I found the > special meaning of > > the zero lb_factor/lb_value. It seems that I didn't understand > it right at the > > first time. This could solve my problem but after a closer look > and some testing > > I found another problem. When you set the lb_value in > workers.properties to 1 > > for the local tomcat and 0 for the others, you get the desired > behavior. But if > > you switch off the local tomcat for a short time you come into > trouble. The > > problem is the 0 for the other workers. The calculation of > lb_worker transforms > > the 0 to _inf_. Because 1/0 for a double is _inf_. This is > greater than any Thats why we use values like 0.01 in this situation in mod_jk1 and live with the few lost sessions. Somewhere in the tomcat-Dev archives I once saw a patch introducing a 'active' flag for the lbfactor, but I never had the time to apply this patch and try it out. it was something like worker.ajp13-01.lbfactor=1 worker.ajp13-01.active=0 in the workers.properties (we already discussed this one in 2001 :) http://marc.theaimsgroup.com/?l=tomcat-dev&m=100719342027584&w=4 > > I think there is a piece that checks for 0 and sets it to DEFAULT_VALUE > (==1 ) before doing 1/lb. > > While looking at the code - I'm not very sure this whole float is needed, > I'll try to find a way to simplify it and use ints ( maybe 0..100 with > some 'special' values for NEVER and ALLWAYS, or some additional flags ). > > But the way it works ( or at least how I understand it ) is that if the > main worker fails, then we look at all workers in error state and try the > one with the oldest error. And the 'main' worker will be tried again when > the timeout expires. > > > I haven't tested this too much, I just applied the patches ( that I > understand :-), I'll add some more debugging for this process and maybe > we can find a better solution. > > But this functionality is essential for the JNI worker and very important > in general - so I really want to find the best solution. If you have any > patch idea, let me know. > > To avoid further confusion and complexity in the lb-factor/value, I > think we should add one more flag ( 'local_worker' ? ) and use it > explicitely. Again, patches are wellcome - it's allways good to have > different ( and more ) eyes looking at the code. > > ( that can go in both jk1, but I can't see a release of jk2 without this > functionality ) > > Costin > > > > other lb_value and greater than the lb_value of the local > tomcat. But after a > > failure of the local tomcat he is in error_state. After some > time its set to > > recovering and if the local tomcat is back again the function > jk(2)_get_max_lb > > gets the highest lb_value. This is _inf_ from one of the other > workers. The > > addition of a value to _inf_ is meaningless. You end up with an > lb_value of > > _inf_ for the local worker. If this worker isn't the first in > the worker list, > > it will never be choosen again. Because his lb_value will never > be less than > > another lb_value, because all the other workers have _inf_ as > theire lb_values. > > So every request without a session will be routed to the first > of the other > > tomcats. > > > > The only way out is a restart of the local apache after tomcat > is up and > > running. But I don't know when tomcat is finished with all his > contexts and > > started the connectors. > > > > I didn't looked very deep into jk2, but I found the same > > get_most_suitable_worker and get_max_lb functions. The > jk2_get_max_lb function > > will always return _inf_. In your answer to some other mails > you said, that > > workers could be removed. Do I understand it right, that if my > local tomcat goes > > down his worker is removed from the list and after he is > comming up again added > > to the worker list with reseted lb_value (only for mod_jk2)? > > > > The next days I will look in the docu and code of jk2 and give > it a try. May be > > all my problems gone away with the new module :). > > > > Sorry if I ask stupid questions, but I want to make it working > for our new cluster. > > > > Thanks > > > > Bernd > > > > > This is essential for jk2's JNI worker, which fits perfectly this case > > > ( you don't want to send via TCP when you have a tomcat > instance in the > > > same process ). > > > > > > > > > > > >>(2) Tomcat instances in standby or "soft shutdown" mode where > they serve > > >>requests bound by established sessions, and requests without > a session only > > >>if all non-standby instances have failed. > > > > > > > > > That's what the SHM scoreboard is going to do ( among o
AW: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common Shm.java
Please see questions on shm and lb worker intermixed,
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Gesendet: Donnerstag, 2. Mai 2002 05:18
> An: [EMAIL PROTECTED]
> Betreff: cvs commit:
> jakarta-tomcat-connectors/jk/java/org/apache/jk/common Shm.java
>
>
> costin 02/05/01 20:18:01
>
> Modified:jk/java/org/apache/jk/common Shm.java
> Log:
> Few more features. I think the sending part works fine now (
> but we should
> still do more tunning ).
>
> For each tomcat instance we create a shm slot in the scoreboard. The
> slot is named TOMCAT:host:port ( host:port is used as instance ID ), and
> contains a ( ajp13-encoded ) structure with informations about
> the channels
> ( currently the socket and unix channel - jni is special ). It'll also
> include the groups where the instance belongs, and possibly other
> informations.
>
> If the number of channels is 0, the lb worker is supposed to stop
> sending new requests to the instance ( but keep forwarding the
> existing sessions ). That'll implement 'gracefull shutdown'.
>
I hope the current 'lbfactor' functionality mod_jk from TC3.3.1 will still
be working
(or an equivilent strategy):
Scenario:
We have two Tomcats in a lb group. Only one is running at a time with
lbfactor=1,
the other has lbfactor=0 assinged but is not running -> all requests go to
TC1
When we upgrade our system we update the classes/jars and start the second
Tomcat TC2 in the group,
switch the lbfactor of TC1 to 0 and the lbfactor fo TC2 to 1 and do a
graceful
restart of apache. This way old sessions still go to TC1 whereas new
sessions go to TC2.
After all sessions on TC1 have ended, we shutdown TC1 and TC2 serves
everything.
Next update goes in the oposit direction (start TC1, switch lbfactors, wait
for the end of all
sessions on TC2 and finally shutdown TC2.
Thanks,
Hans
> Still to add:
> - display ( nicely ) the information in the shm
> - read info from shm ( like slots owned by apache processes with
> statistics - in a future release )
>
> Revision ChangesPath
> 1.9 +27 -0
> jakarta-tomcat-connectors/jk/java/org/apache/jk/common/Shm.java
>
> Index: Shm.java
> ===
> RCS file:
> /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/S
> hm.java,v
> retrieving revision 1.8
> retrieving revision 1.9
> diff -u -r1.8 -r1.9
> --- Shm.java1 May 2002 22:40:17 - 1.8
> +++ Shm.java2 May 2002 03:18:01 - 1.9
> @@ -95,6 +95,7 @@
>
>boolean unregister=false;
>boolean reset=false;
> +String dumpFile=null;
>
>// Will be dynamic ( getMethodId() ) after things are stable
>static final int SHM_SET_ATTRIBUTE=0;
> @@ -102,6 +103,8 @@
>static final int SHM_ATTACH=3;
>static final int SHM_DETACH=4;
>static final int SHM_RESET=5;
> +static final int SHM_DUMP=6;
> +static final int SHM_DESTROY=7;
>
>public Shm() {
>}
> @@ -112,6 +115,13 @@
>file=f;
>}
>
> +/** Copy the scoreboard in a file for debugging
> + * Will also log a lot of information about what's in the
> scoreboard.
> + */
> +public void setDump( String dumpFile ) {
> +this.dumpFile=dumpFile;
> +}
> +
>/** Size. Used only if the scoreboard is to be created.
> */
>public void setSize( int size ) {
> @@ -199,6 +209,20 @@
>this.invoke( msg, mCtx );
>}
>
> +public void dumpScoreboard(String fname) throws IOException {
> +if( apr==null ) return;
> +MsgContext mCtx=createMsgContext();
> +Msg msg=(Msg)mCtx.getMsg(0);
> +C2BConverter c2b=(C2BConverter)mCtx.getNote(C2B_NOTE);
> +msg.reset();
> +
> +msg.appendByte( SHM_DUMP );
> +
> +appendString( msg, fname, c2b);
> +
> +this.invoke( msg, mCtx );
> +}
> +
>public void setNativeAttribute(String name, String val)
> throws IOException {
>if( apr==null ) return;
>MsgContext mCtx=createMsgContext();
> @@ -315,8 +339,11 @@
>return;
>}
>init();
> +
>if( reset ) {
>resetScoreboard();
> +} else if( dumpFile!=null ) {
> +dumpScoreboard(dumpFile);
>} else if( unregister ) {
>unRegisterTomcat( host, port );
>} else {
>
>
>
>
> --
> 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]>
AW: AW: PROPOSAL: mod_jk2 autoconfig
> -Ursprungliche Nachricht- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Gesendet: Dienstag, 30. April 2002 16:39 > An: Tomcat Developers List > Betreff: Re: AW: PROPOSAL: mod_jk2 autoconfig > > > On Tue, 30 Apr 2002, Hans Schmid wrote: > > > I can not see how this works if you have Apache and Tomcat on different > > machines. > > This way we do not have a webapp/ directory on that Apache server. > > It works fine. > > There are 2 cases: > 1. You want Apache to serve static pages. That's the 'normal' case, and > it automatically require that you _have_ the webapp (at lest the static > pages, you can remove the clasesses, lib, etc ) on the apache server. > > 2. You don't want apache to serve static pages for the app. In this case > you'll just put a small file in the webapp/ ( myApp.jk2 or something > similar - see how 3.3 apps-myApp.xml or 4.1 webapps/myApp.xml works ), > with the single mapping that is required to forward all requests. > We have lots of not webapp related static stuff so we have set the DocumenRoot of apache at our static 'source' tree (not tomcat related source tree). For the few bits of static content in our webapps (few logos) we do not really care (yet). They are served by Tomcat. This has all historic reasons. This is an old system migrating slowly :) So we do not even have a Tomcat installed on our webservers - so no webapps directories. > Even in the second case, I think it is easier to 'deploy' one conf file > per webapp in a clear format than editing workers.properties. > > > Did I misunderstand the intent of this configuration? Is it a > 'best guess' > > for simple setups? > > Probably in our scenario we have to configure it manually anyways. > > Manual configuration will work, of course. In tomcat you can still edit > server.xml. It's just that I would strongly discourage that for 'normal' > use. > We make heavy use of the apps-myall.xml files in TC 3.3.1 - but as I said, no Tomcat on our webservers. We have 2 hardware loadbalanced small pizzaboxes running Apache and three bigger Solaris machines running our Tomcats and the database. > > > Some 'special' files ( like in 4.1 and the 3.3 apps- files ) will > > > also be read and used to load webapps that sit in different > directories. > > > > same here we are on different machines. > > Again, all you need is to install 1 file on the server machine for each > webapp ( without static files ). > > I personally believe that is a very bad choice to not let apache serve > the static files, but it'll work. Have not yet figured out how to combine our static DocumentRoot plus serving static contents from our webapps. > > > Just make sure, everything in the config can be overwritten and > configures > > manually > > if possible in a single file (as workers.properties right now) > > Either workers2.properties, or one file in the webapps ( named > after the application, with .jk2 extension ). > > The file can be used if you have the docRoot in a different place in > the apache server. > > exactly this is our setup. So we will use a workers2.properties. Thanks for clarifying. Cheers, Hans > 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]>
AW: PROPOSAL: mod_jk2 autoconfig
See intermixed > -Ursprungliche Nachricht- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Gesendet: Montag, 29. April 2002 19:17 > An: List Tomcat-Dev > Betreff: PROPOSAL: mod_jk2 autoconfig > > > Hi, > > I spent a lot of time on this - and I think this is a very good solution. > Please send feedback - the sooner the better... > > I think the current solution of generating configs on tomcat startup, > or having tomcat send it's config to apache is wrong. > > Basically what I would like to propose is similar with what Glen > implemented in jk1 for apache1.3 ( the webapp/ directory > auto-conf )- with > few enhancements. > > The major requirement is that mod_jk2 is configured with the location > of the webapp/ directory. Inside webapp, it'll look for directories > and configure them automatically, like tomcat is doing. I can not see how this works if you have Apache and Tomcat on different machines. This way we do not have a webapp/ directory on that Apache server. Or does this work across several machines? We have two Apache 1.3 servers which are busy serving static contents plus PHP legacy stuff. We run at least 4 Tomcats on two different servers to distribute our webapps. Did I misunderstand the intent of this configuration? Is it a 'best guess' for simple setups? Probably in our scenario we have to configure it manually anyways. > > Some 'special' files ( like in 4.1 and the 3.3 apps- files ) will > also be read and used to load webapps that sit in different directories. same here we are on different machines. > > In addition, a separate directory ( named ??? ) can be used with a > host-based hierarchy. Given that most users are using a single > host and the current webapps/ habbits, the vhost hierarchy will > be different from the 'default server'. > > For each discovered webapp ( either directory or CONTEXT.jk2 file ) , jk > will look for WEB-INF/jk2/map.properties and load the file. > I would need a complete webapp structure for configurating mod_jk2 on a server which does not have any tomcat - and webapp installed. Just make sure, everything in the config can be overwritten and configures manually if possible in a single file (as workers.properties right now) But I agree the concept is nice for simple setups. > The map.properties file will be generated from web.xml - using a > small tool ( I'll commit the first code shortly ) that is independent > of tomcat ( it doesn't require starting tomcat ). It can be used > as CLI, as ant task or as a bean inside an admin or deploy application. > > The tool curently uses DOM - and very simple and strictly specialized > code, no "LoadModule" or anything that is beyond web.xml content. > In addition, the tool may generate Apache-specific configuration > fragments for the 'native' mapper ( as you may remember, jk2 can > map URIs using it's internal mapper - but also using > and Set-Handler directives ). It'll also generate JkMounts for > backward compat. > > All other code from the jk1 autoconf will be separated ( or replaced > with some templates ) - the location of jk, other global settings > are better to be done manually ( and have decent defaults ). > > Finally, the shmem system that is ( will be ) used for autoconfiguration > of workers ( i.e. when a tomcat starts up it can add itself automatically, > without admin intervention ) can be used by the deploy/admin tool to > reconfigure uri mappings ( with the common mapper, the native mapper > still requires a soft restart - but that can be automated as well ). > > Implementation-wise - this is not difficult, and can be done pretty > fast if Glenn and few other people step in. > > I believe that's going to be very close to 'minimal' pain for the > regular user while preserving the ability to fine tune everything. > > NOTE: jk2 will use a different model for the lb, see next mail. > > Costin > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> Thanks, Hans -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
AW: Apache1.3/mod_jk (unix) & Tomcat 4 & No processor available, rejecting this connection
Hi, what about Tomcat 3.3 ? Does this correspond to Ajp13Connector maxThreads >= the maxiumum number of Apache httpd processes in this case? Thanks, Hans > -Ursprungliche Nachricht- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im > Auftrag von Glenn Nielsen > Gesendet: Freitag, 22. Marz 2002 16:39 > An: [EMAIL PROTECTED] > Betreff: Apache1.3/mod_jk (unix) & Tomcat 4 & No processor available, > rejecting this connection > > > I have finally figured out why sometimes the Tomcat4 Ajp13Connector > would refuse connections. > > > Each Apache1.3 httpd process using mod_jk establishes a single connection > to Tomcat the first time it has to forward a request to Tomcat. > That connection is only used by that httpd process. > > mod_jk can fail to make a new connection to Tomcat when an httpd process > forwards its first request to Tomcat if the number of httpd > processes which > have already established a connection to Tomcat exceeds the > Ajp13Connector > maxProcessors setting. > > So it is critical that the Ajp13Connector maxProcessors be set >= > the maxiumum number of Apache httpd processes. > > This may be a known config issue, but I haven't any documentation > for this issue. > > Regards, > > Glenn > > -- > Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| > MOREnet System Programming | * if iz ina coment. | > Missouri Research and Education Network | */ | > -- > > -- > 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]>
AW: AW: mod_jk suggestion, add "request" logging option
> -Ursprungliche Nachricht- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im > Auftrag von Glenn Nielsen > Gesendet: Donnerstag, 21. Februar 2002 19:28 > An: Tomcat Developers List > Betreff: Re: AW: mod_jk suggestion, add "request" logging option > > > Hans Schmid wrote: > > > > Hi, > > > > what about adding 'port' to the list. > > > > Is this the port the http request came in on, or the port for the worker? I thought of the host and port of the worker. In our setup we send different workers to different hosts (even loadbalanced workers) So its easy to see where the request was sent to. But if we can configure, which of the fields we want to see in the log there can't be too much availlable :) Cheers, Hans > > > For lb workers the worker would be the real one used not 'loadbalancer', > > right? > > > > Yes, you would want the worker which points at the actual instance of > Tomcat the request was forwarded to. > > > I think it would be really helpful to have this log level. > > > > Cheers, > > Hans > > > > > -Ursprungliche Nachricht- > > > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]Im > > > Auftrag von Glenn Nielsen > > > Gesendet: Donnerstag, 21. Februar 2002 16:57 > > > An: Tomcat Developers List > > > Betreff: Re: mod_jk suggestion, add "request" logging option > > > > > > > > > Updated list of fields for request logging. > > > > > > Timestamp > > > worker > > > host > > > URI > > > Status (OK, FAIL, etc) > > > Latency (Time in ms or us to handle request) > > > > > > Glenn > > > > > > Glenn Nielsen wrote: > > > > > > > > Currently mod_jk has four logging levels - (debug,info,error,emerg). > > > > > > > > I suggest a fifth log level be added called "request". > > > > (debug, info, request, error, emerg) > > > > > > > > This log level would log each request with the following > possible info, > > > > what info is logged could be controlled by an new config option > > > > JkLogRequestFormat. > > > > > > > > Timestamp > > > > URI > > > > Status (OK, FAIL, etc) > > > > Latency (Time in ms or us to handle request) > > > > > > > > And there may be other fields of interest to add to the above list. > > > > > > > > I am most interested in using mod_jk to log the request latency for > > > > Tomcat to handle different requests so that statistics can > be generated. > > > > > > > > Having mod_jk do this instead of Tomcat avoids violating > the heisenberg > > > > principal. > > > > > > > > Regards, > > > > > > > > Glenn > > > > > > > > > -- > > > > Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut > madder| > > > > MOREnet System Programming | * if iz ina > coment. | > > > > Missouri Research and Education Network | */ > | > > > > > -- > > > > > > > > -- > > > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > -- > > -- > > Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| > > MOREnet System Programming | * if iz ina coment. | > > Missouri Research and Education Network | */ | > > -- > > > > -- > > 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]> > > -- > -- > Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| > MOREnet System Programming | * if iz ina coment. | > Missouri Research and Education Network | */ | > -- > > -- > 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]>
AW: mod_jk suggestion, add "request" logging option
Hi, what about adding 'port' to the list. For lb workers the worker would be the real one used not 'loadbalancer', right? I think it would be really helpful to have this log level. Cheers, Hans > -Ursprungliche Nachricht- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im > Auftrag von Glenn Nielsen > Gesendet: Donnerstag, 21. Februar 2002 16:57 > An: Tomcat Developers List > Betreff: Re: mod_jk suggestion, add "request" logging option > > > Updated list of fields for request logging. > > Timestamp > worker > host > URI > Status (OK, FAIL, etc) > Latency (Time in ms or us to handle request) > > Glenn > > Glenn Nielsen wrote: > > > > Currently mod_jk has four logging levels - (debug,info,error,emerg). > > > > I suggest a fifth log level be added called "request". > > (debug, info, request, error, emerg) > > > > This log level would log each request with the following possible info, > > what info is logged could be controlled by an new config option > > JkLogRequestFormat. > > > > Timestamp > > URI > > Status (OK, FAIL, etc) > > Latency (Time in ms or us to handle request) > > > > And there may be other fields of interest to add to the above list. > > > > I am most interested in using mod_jk to log the request latency for > > Tomcat to handle different requests so that statistics can be generated. > > > > Having mod_jk do this instead of Tomcat avoids violating the heisenberg > > principal. > > > > Regards, > > > > Glenn > > > > -- > > Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| > > MOREnet System Programming | * if iz ina coment. | > > Missouri Research and Education Network | */ | > > -- > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- 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]>
Loadbalancer problems in mod_jk 4.0.3 [was Native Connector problems]
(300)]: Into jk_endpoint_t::service [Tue Feb 12 15:28:32 2002] [jk_ajp13_worker.c (865)]: Into jk_worker_t::get_endpoint [Tue Feb 12 15:28:32 2002] [jk_ajp13_worker.c (775)]: Into jk_endpoint_t::service [Tue Feb 12 15:28:32 2002] [jk_ajp13.c (403)]: Into ajp13_marshal_into_msgb [Tue Feb 12 15:28:32 2002] [jk_ajp13.c (537)]: ajp13_marshal_into_msgb - Done [Tue Feb 12 15:28:32 2002] [jk_connect.c (108)]: Into jk_open_socket [Tue Feb 12 15:28:32 2002] [jk_connect.c (115)]: jk_open_socket, try to connect socket = 38 [Tue Feb 12 15:28:32 2002] [jk_connect.c (124)]: jk_open_socket, after connect ret = 0 [Tue Feb 12 15:28:32 2002] [jk_connect.c (132)]: jk_open_socket, set TCP_NODELAY to on [Tue Feb 12 15:28:32 2002] [jk_connect.c (140)]: jk_open_socket, return, sd = 38 [Tue Feb 12 15:28:32 2002] [jk_ajp13_worker.c (189)]: In jk_endpoint_t::connect_to_tomcat, connected sd = 38 [Tue Feb 12 15:28:32 2002] [jk_ajp13_worker.c (206)]: sending to ajp13 #436 [Tue Feb 12 15:28:32 2002] [jk_ajp13_worker.c (645)]: send_request 2: request body to send 0 - request body to resend 0 [Tue Feb 12 15:28:34 2002] [jk_ajp13_worker.c (258)]: received from ajp13 #82 4.0.2 version of mod_jk: [Tue Feb 12 15:27:02 2002] [jk_uri_worker_map.c (464)]: Attempting to map URI '/einsurance/doEntry.do' [Tue Feb 12 15:27:02 2002] [jk_uri_worker_map.c (489)]: jk_uri_worker_map_t::map_uri_to_worker, Found a context match loadbalancer -> /einsurance/ [Tue Feb 12 15:27:02 2002] [jk_worker.c (132)]: Into wc_get_worker_for_name loadbalancer [Tue Feb 12 15:27:02 2002] [jk_worker.c (136)]: wc_get_worker_for_name, done found a worker [Tue Feb 12 15:27:02 2002] [jk_lb_worker.c (487)]: Into jk_worker_t::get_endpoint [Tue Feb 12 15:27:02 2002] [jk_lb_worker.c (306)]: Into jk_endpoint_t::service [Tue Feb 12 15:27:02 2002] [jk_ajp_common.c (1345)]: Into jk_worker_t::get_endpoint [Tue Feb 12 15:27:02 2002] [jk_ajp_common.c (1075)]: Into jk_endpoint_t::service [Tue Feb 12 15:27:02 2002] [jk_ajp_common.c (280)]: Into ajp_marshal_into_msgb [Tue Feb 12 15:27:02 2002] [jk_uri_worker_map.c (447)]: Into jk_uri_worker_map_t::map_uri_to_worker [Tue Feb 12 15:27:02 2002] [jk_uri_worker_map.c (464)]: Attempting to map URI '/einsurance/doEntry.do' [Tue Feb 12 15:27:02 2002] [jk_uri_worker_map.c (489)]: jk_uri_worker_map_t::map_uri_to_worker, Found a context match loadbalancer -> /einsurance/ [Tue Feb 12 15:27:02 2002] [jk_worker.c (132)]: Into wc_get_worker_for_name loadbalancer [Tue Feb 12 15:27:02 2002] [jk_worker.c (136)]: wc_get_worker_for_name, done found a worker [Tue Feb 12 15:27:02 2002] [jk_lb_worker.c (487)]: Into jk_worker_t::get_endpoint [Tue Feb 12 15:27:02 2002] [jk_lb_worker.c (306)]: Into jk_endpoint_t::service [Tue Feb 12 15:27:02 2002] [jk_ajp_common.c (1345)]: Into jk_worker_t::get_endpoint [Tue Feb 12 15:27:02 2002] [jk_ajp_common.c (1075)]: Into jk_endpoint_t::service [Tue Feb 12 15:27:02 2002] [jk_ajp_common.c (280)]: Into ajp_marshal_into_msgb [Tue Feb 12 15:27:02 2002] [jk_uri_worker_map.c (447)]: Into jk_uri_worker_map_t::map_uri_to_worker [Tue Feb 12 15:27:02 2002] [jk_uri_worker_map.c (464)]: Attempting to map URI '/einsurance/doEntry.do' [Tue Feb 12 15:27:02 2002] [jk_uri_worker_map.c (489)]: jk_uri_worker_map_t::map_uri_to_worker, Found a context match loadbalancer -> /einsurance/ [Tue Feb 12 15:27:02 2002] [jk_worker.c (132)]: Into wc_get_worker_for_name loadbalancer [Tue Feb 12 15:27:02 2002] [jk_worker.c (136)]: wc_get_worker_for_name, done found a worker [Tue Feb 12 15:27:02 2002] [jk_lb_worker.c (487)]: Into jk_worker_t::get_endpoint [Tue Feb 12 15:27:02 2002] [jk_lb_worker.c (306)]: Into jk_endpoint_t::service [Tue Feb 12 15:27:02 2002] [jk_ajp_common.c (1345)]: Into jk_worker_t::get_endpoint [Tue Feb 12 15:27:02 2002] [jk_ajp_common.c (1075)]: Into jk_endpoint_t::service [Tue Feb 12 15:27:02 2002] [jk_ajp_common.c (280)]: Into ajp_marshal_into_msgb [Tue Feb 12 15:27:02 2002] [jk_uri_worker_map.c (447)]: Into jk_uri_worker_map_t::map_uri_to_worker Thanks a lot for looking into this, Best Regards, Hans -Ursprungliche Nachricht- Von: Hans Schmid [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 13. Februar 2002 08:23 An: Tomcat Developers List Betreff: AW: Native Connector problems Hi, I just ran into a problem with the loadbalancing stuff. I built mod_jk.so from the 4.0.2 connector package and replaced my mod_jk.so (TC3.3 Version) with this one in apache/libexec (1.3.19). By just changing a link back and forth between the two versions, I tested our TC3.3 based application against the two versions of mod_jk. If this is not enough and I am missing something, please let me know. Otherwise exactly the same setup All works perfectly with the new mod_jk when I use normal ajp13 workers (one webapp), but fails when I use a loadbalancing worker pointing to another webapp on a different Tomcat instance. I do not have the mod_jk.log here at home. Will
AW: Native Connector problems
Hi, I just ran into a problem with the loadbalancing stuff. I built mod_jk.so from the 4.0.2 connector package and replaced my mod_jk.so (TC3.3 Version) with this one in apache/libexec (1.3.19). By just changing a link back and forth between the two versions, I tested our TC3.3 based application against the two versions of mod_jk. If this is not enough and I am missing something, please let me know. Otherwise exactly the same setup All works perfectly with the new mod_jk when I use normal ajp13 workers (one webapp), but fails when I use a loadbalancing worker pointing to another webapp on a different Tomcat instance. I do not have the mod_jk.log here at home. Will send it in a couple of hours when I am in the office. What else would be required for debugging? Note, We use the loadbalancer just for switching tomcats. Only one instance of the two loadbalanced Tomcats is active most of the time. (by changing the lbvalue) Thanks, Hans > -Ursprungliche Nachricht- > Von: Mike Anderson [mailto:[EMAIL PROTECTED]] > Gesendet: Mittwoch, 13. Februar 2002 02:17 > An: [EMAIL PROTECTED] > Betreff: RE: Native Connector problems > > > The problem is that the default cache size is one and in the ajp_init > function > in jk_ajp_common.c we return from inside of an if when we initialize > the cache > so the secrect member of the structure never gets initialized. This > caused > some GPFs in certain cases on some of my builds. > > I've checked in the fix. All I did was move the line that initializes > secret up above > the if statement. > > Remy, would it be possible to relabel jk_ajp_common.c > rev. 1.24 as the rev for tomcat_402? I've built and tested this fix on > NetWare > and the resolved my GPFs and bad behavior talking to older > installations > of Tomcat (i.e. 3.3). I was able to use the same module to talk to > Tomcat 4.0.2 and Tomcat 3.3 from the same instance of the web server. > I love it when a plan comes together :-) > > Mike Anderson > > > >>> [EMAIL PROTECTED] 02/12/02 05:19PM >>> > >One of the last changes on the connector ( the secret ) > >introduced a bug, > >when worker_cache is enabled. The secret will not be initialized, and > > >that may creates all kind of serious problems. > > Could you detail the problem ? > > -- > 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]>
WG: TC3.3 updating a webapp without killing sessions
Hi, since Costin is currently refactoring mod_jk in jakarta-tomcat-connectors I want to throw in our usage scenario. We are abusing the loadbalancing feature of mod_jk to switch tomcats on the fly in order to be able to make application updates without killing our curreent user sessions. See discussion below from tomcat-user This feature (graceful restart) was present in jserv and is still missing in mod_jk/Tomcat3.3 as far as I know. Below are references to the archive where Michael Kuz has sent a patch to decouple this feature from the lbfactor (introducing an active flag). So please keep in mind the requirement to be able to update Webapps in a farm of Tomcats without killing active sessions. Thanks, Hans -Ursprüngliche Nachricht- Von: Hans Schmid [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 28. November 2001 18:21 An: Tomcat Users List Betreff: AW: TC3.3 updating a webapp without killing sessions Thanks Larry, perhaps a lbfactor of 0.1 or so would do the job for us. We could probably live with 1 out of 10 sessions beeing sent to the wrong Tomcat and beeing killed if this instance shuts down. Should this be discussed in tomcat-dev ? I remember a patch from early this year which tried to fix this (check the archives) but did never make it into the release It tried to add a flag called 'active' in the worker.properties file for each worker instead of misusing the lbfactor for this. ajp13-01... lbfactor=1 active=0 and ajb13-02... lbfactor=1 active=1 see http://w6.metronet.com/~wjm/tomcat/2001/Jan/msg00102.html and http://w6.metronet.com/~wjm/tomcat/2001/Jan/msg00114.html for the patch which might be a little bit outdated > -Ursprüngliche Nachricht- > Von: Larry Isaacs [mailto:[EMAIL PROTECTED]] > Gesendet: Mittwoch, 28. November 2001 15:00 > An: 'Tomcat Users List' > Betreff: RE: TC3.3 updating a webapp without killing sessions > > > I assume the value or lbfactor is requested to be >0 > because 1/lbfactor is calculated during initialization. > Since this is done with doubles, it may generate an > internal representation for infinity rather than a division > by zero error. > > I don't have a complete understanding of what mod_jk > does internally for loadbalancing, but your approach > seems like it should work. A brief scan of the codes > shows that some updates to mod_jk would be needed > to insure that lbfactor=0 means only use this worker > when mandated by session routing. > > There isn't much logging around the choice of worker. > Perhaps adding some logging would help determine > why requests are being routed to the lbfactor=0 > Tomcat when session routing shouldn't be a factor. > > Hope this helps. > > Cheers, > Larry > > > > -Original Message- > > From: Hans Schmid [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, November 28, 2001 4:25 AM > > To: Tomcat-User > > Subject: TC3.3 updating a webapp without killing sessions > > > > > > Hi, > > > > We try to make a workaround for the following problems: > > 1.) memory management > > 2.) application update > > 3.) do not kill active sessions > > > > Perhaps someone can comment on the startegy and answer some questions. > > > > > > Our environment: > > Tomcat 3.3 final with mod_jk Apache 1.3.19 on Solaris 2.7 Sparc > > > > Our problem: > > ever growing cache until memory runs out (clearly an > > application problem) > > plus soft updates to our application without killing actiove sessions > > > > The idea: > > when a certain ammount of memory is reached by the tomcat > > java process, > > start up a second > > Tomcat and route all new requests to the second instance > > while existing > > sessions should phase out > > on the first instance. > > If no more sessions are active on the original Tomcat, shut it down > > (currently we just shut it down 30 minutes after the second > > Tomcat started > > up) > > > > How to do it with mod_jk: > > We have two versions of a worker.properties. Before we start > > up our second > > tomcat, > > we switch a link to point to the other version. > > > > Both versions of the worker.property file have a loadbalancer worker > > defined: > > > > First version: > > worker.list=loadbalancer > > > > worker.ajp13-01.port=11009 > > worker.ajp13-01.host=tomcathost > > worker.ajp13-01.type=ajp13 > > worker.ajp13-01.lbfactor=1 <- important > > > > worker.ajp13-02.port=11019 > > worker.ajp13-02.host=tomcathost > > worker.ajp13-02.type=ajp13 > > worker.ajp13-02.lbfactor=0 <
AW: tomcat in the production environment
Hi Kandasamy. we are using Tomcat 3.3 on our production site. Solaris 2.7 Sparc, 2 processors, JDK 1.3.1_01 mod_jk ajp1.3 behind two Apache 1.3.19 with a HW loadbalancer in front. And still our single Tomcat 3.3 instance is not the bottleneck. Currently it is our Oracle machine :) BTW. we make heavy use of Velocity as well. We have currently up to 200 concurrent users and I must say, Tomcat is the most stable and reliable piece in our architecture. We have some JVM crashes when the heap fills up and sometimes at startup (when there are already many customers trying to log in) But this is clearly the JVM - not Tomcat. But it is true, you have to make test for your environment. All the best, Regards, Hans > -Ursprüngliche Nachricht- > Von: T. Kandasamy [mailto:[EMAIL PROTECTED]] > Gesendet: Freitag, 23. November 2001 11:02 > An: 'Tomcat Developers List' > Betreff: RE: tomcat in the production environment > > > Hi Bojan: > > Thanks for your kind reply. How about the stability of the tomcat > i.e.if the > number of concurrent increases. whether the tomcat will be stable? or > getting > crashed. Please let me know, do you use tomcat in the production server? > > regards > Kandasamy > Singapore > > -Original Message- > From: Bojan Smojver [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 23, 2001 5:39 PM > To: Tomcat Developers List > Subject: Re: tomcat in the production environment > > > "T. Kandasamy" wrote: > > > > Hi > > > > In our organization, we are trying to put the tomcat 3.3 in the > production > > environment. I wish to see > > some performance test results of the tomcat. Is it highly > stable?. If any > is > > using the tomcat in the > > production/ live server, please share your experinces with me. > > > > we have successfully integrated apache web server with tomcat. > I unable to > > see performance results > > in the jakarata.apache.org. How concurrent requests it will handle?. we > are > > having redhad linux with > > processor and 4gb ram machine. please give your reply > > I wouldn't rely on any benchmarks or experiences of others since they > could be a result of a totally different scenario then yours. There is a > simple tool called 'ab' that comes with Apache. It is extremely easy to > simulate server load with it. I suggest you try it in your environment > and make decisions for yourself. > > Bojan > > PS. My own benchmarks show that a P2 266 with 288 MB of RAM, 2 UW SCSI > disks, running RedHat Linux 7.0 with selective Rawhide updates, kernel > 2.4.14, Apache 1.3.22 and TC 3.3 can serve around 60 requests per second > (or 17 ms per request) at concurrency of 10 requests, using one of my > typical Velocity pages... which is probably totally irrelevant for your > scenario. > > -- > 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]>
WG: worker.properties swallows my first worker (mod_jk)
Hi,
just filed a bug on Larrys request
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3467
Thanks for looking into this one.
Cheers,
Hans
-Ursprüngliche Nachricht-
Von: Larry Isaacs [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 6. September 2001 19:39
An: '[EMAIL PROTECTED]'
Betreff: RE: worker.properties swallows my first worker (mod_jk)
Hi Hans,
The answers to your questions are:
1.) Why gets this hardcoded worker on port 8007 created?
Don't know, I will investigate.
2.) Is this a Bug I shall report?
Yes, and please attache the workers.properties in question.
Thanks.
Larry
> -Original Message-
> From: Hans Schmid [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 06, 2001 12:57 PM
> To: Tomcat-User
> Subject: worker.properties swallows my first worker (mod_jk)
>
>
> Hello,
>
> This is about mod_jk in Tomcat 3.3b1 on Solaris with Apache 1.3.19
>
> It seems to me that the first worker found in the worker.list
> always gets
> created as ajp12 on port 8007
> regardless what i configure.
>
> The following worker.list entry
> worker.list=worker.list=ajp12-01, ajp12-02, ajp13-01, ajp13-02
>
> produces 4 workers:
> ajp12-01 on port 8007 ajp12
> ajp12-02 on port 9017 ajp12
> ajp13-01 on port 9009 ajp13
> ajp13-02 on port 9019 ajp13
>
> instead of the expected:
> ajp12-01 on port 9007 ajp12
> ajp12-02 on port 9017 ajp12
> ajp13-01 on port 9009 ajp13
> ajp13-02 on port 9019 ajp13
>
> Please note the ajp12-01 worker points to port 8007 instead of 9007.
>
> When I put a space in front of the first worker I get my
> expected 4 workers
> pointing to the correct ports
> plus a 5th worker ('' on port 8007)
>
>
> The following entry in workers.properties
> worker.list=worker.list= ajp12-01, ajp12-02, ajp13-01, ajp13-02
>
> produces 5 workers instead of 4
> Please note the port 8007 for the first worker named
> worker.list= of ajp12
> I do not have a worker assigned to this port (greped through
> all config
> files).
>
>
> [Thu Sep 06 18:26:17 2001] [jk_worker.c (207)]: Into
> build_worker_map,
> creating 5 workers
> [Thu Sep 06 18:26:17 2001] [jk_worker.c (213)]:
> build_worker_map, creating
> worker worker.list=
> [Thu Sep 06 18:26:17 2001] [jk_worker.c (138)]: Into wc_create_worker
> [Thu Sep 06 18:26:17 2001] [jk_worker.c (152)]:
> wc_create_worker, about to
> create instance worker.list= of ajp12
> [Thu Sep 06 18:26:17 2001] [jk_ajp12_worker.c (264)]: Into
> ajp12_worker_factory
> [Thu Sep 06 18:26:17 2001] [jk_worker.c (161)]:
> wc_create_worker, about to
> validate and init worker.list=
> [Thu Sep 06 18:26:17 2001] [jk_ajp12_worker.c (182)]: Into
> jk_worker_t::validate
> [Thu Sep 06 18:26:17 2001] [jk_ajp12_worker.c (194)]: In
> jk_worker_t::validate for worker worker.list= contact is
> localhost:8007
> [Thu Sep 06 18:26:17 2001] [jk_worker.c (177)]:
> wc_create_worker, done
> [Thu Sep 06 18:26:17 2001] [jk_worker.c (223)]:
> build_worker_map, removing
> old worker.list= worker
> [Thu Sep 06 18:26:17 2001] [jk_worker.c (213)]:
> build_worker_map, creating
> worker ajp12-01
> [Thu Sep 06 18:26:17 2001] [jk_worker.c (138)]: Into wc_create_worker
> [Thu Sep 06 18:26:17 2001] [jk_worker.c (152)]:
> wc_create_worker, about to
> create instance ajp12-01 of ajp12
> [Thu Sep 06 18:26:17 2001] [jk_ajp12_worker.c (264)]: Into
> ajp12_worker_factory
> [Thu Sep 06 18:26:17 2001] [jk_worker.c (161)]:
> wc_create_worker, about to
> validate and init ajp12-01
> [Thu Sep 06 18:26:17 2001] [jk_ajp12_worker.c (182)]: Into
> jk_worker_t::validate
> [Thu Sep 06 18:26:17 2001] [jk_ajp12_worker.c (194)]: In
> jk_worker_t::validate for worker ajp12-01 contact is localhost:9007
> [Thu Sep 06 18:26:17 2001] [jk_worker.c (177)]:
> wc_create_worker, done
> [Thu Sep 06 18:26:17 2001] [jk_worker.c (223)]:
> build_worker_map, removing
> old ajp12-01 worker
> [Thu Sep 06 18:26:17 2001] [jk_worker.c (213)]:
> build_worker_map, creating
> worker ajp12-02
> [Thu Sep 06 18:26:17 2001] [jk_worker.c (138)]: Into wc_create_worker
> [Thu Sep 06 18:26:17 2001] [jk_worker.c (152)]:
> wc_create_worker, about to
> create instance ajp12-02 of ajp12
> [Thu Sep 06 18:26:17 2001] [jk_ajp12_worker.c (264)]: Into
> ajp12_worker_factory
> [Thu Sep 06 18:26:17 2001] [jk_worker.c (161)]:
> wc_create_worker, about to
> validate and init ajp12-02
> [Thu Sep 06 18:26:17 2001] [jk_ajp12_worker.c (182)]: Into
> jk_worker_t::validate
> [Thu Sep 06 18:26:17 2001] [jk_ajp12_worker.c (194)]: In
> jk_worker_t::validate for worker ajp12-02 contact is localhost:9017
> [Thu Sep 06 18:26:17 2001] [jk_worker.c (177)]:
> wc_creat
[PATCH] Tomcat 3.3 m3 mod_jk-howto.html (new Bug #1809)
Hello, I just installed Tomcat3.3-m3 with ajpv13 behind Apache 1.3.19 on Win2000. While setting up mod_jk with ajp1.3, I noticed a bug in the mod_jk-howto.html It states: Add the following block to your TOMCAT_HOME/conf/server.xml file. but this is the way Tomcat 3.2.2 has to be setup. In TC 3.3 the entry should be: and its enabled by default. Anyway, I have attatched diffs against /src/doc/mod_jk-howto.html. This is the new paragraph: --- (Optional) Configuring Tomcat to use the Ajpv13 protocol mod_jk can use either the original Ajpv12 protocol or the newer Ajpv13 protocol. If you choose the latter, you need to activate the "Ajp13" Connection Handler in Tomcat. This will give you the benefit of a faster protocol and the ability to identify requests made via HTTPS. Add the following block to your TOMCAT_HOME/conf/server.xml file. The server.xml file already has a block similar to this for Ajp12 connections on port 8007 (as delivered by mod_jserv). Even if you think you're only using Ajp13, you probably don't want to delete this connector -- it's required to shut down Tomcat. --- There is a mod_jk-howto.html in proposals as well. I don't know, if this patch should be applied to this one as well. I hope this helps a little bit since there seems to be so much confusion in the user-list about setting up mod_jk. Best regards, Hans --- mod_jk-howto.html.orig Fri May 18 14:22:58 2001 +++ mod_jk-howto.html Fri May 18 14:32:21 2001 @@ -643,14 +643,13 @@ (Optional) Configuring Tomcat to use the Ajpv13 protocol mod_jk can use either the original Ajpv12 protocol or the newer Ajpv13 protocol. -If you choose the latter, you need to activate the "Ajp13" Connection Handler in Tomcat. This -will give you the benefit of a faster protocol and the ability to identify requests made via HTTPS. -Add the following block to your TOMCAT_HOME/conf/server.xml file. +Both protocols are enabled by default. The "Ajp13" Connection Handler in +Tomcat will +give you the benefit of a faster protocol and the ability to identify requests made +via HTTPS. +The following block enables Ajpv13 in your TOMCAT_HOME/conf/server.xml file. -<Connector className="org.apache.tomcat.service.PoolTcpConnector"> - <Parameter name="handler" value="org.apache.tomcat.service.connector.Ajp13ConnectionHandler"/> - <Parameter name="port" value="8009"/> -</Connector> +<RequestInterceptor + className="org.apache.tomcat.modules.server.Ajp13Interceptor" + port="8009"/> The server.xml file already has a block similar to this for
Re: JSP doInitBody/doAfterBody with no body
Marc Saegesser wrote: > > The follow email discussion happened on tomcat-dev back in January. In > reviewing the open bugs for Tomcat 3.2.2 I came across this issues again and > I'm trying to decide if it should dealt with, marked invalid, etc. > > Did anyone hear anything back from jsp-comments? For that matter, has any > *ever* heard anything back from jsp-comments? I've never received a single > response to any message I've ever sent to that address. I brought this to the JSR-053 working group yesterday, and Eduardo has promised to try to resolve the issue with a mail today or tomorrow. My reading of the spec, though, is that no matter if an action element has a body or not, all body methods must always be called if BodyTag is implemented. Not doing so means that the tag developer needs to deal with different usage scenarios in the code, and that should not be necessary. Hans > -- > > Jeff Turner wrote: > > Having a look through bug 652: > > > > BodyTag doInitBody and doAfterBody called on tags without body > > > > (http://znutar.cortexity.com/BugRatViewer/ShowReport/652) > > > > I don't think this is a bug. > > > > The JSP spec, p88, says: > > > > "If an action element can have a non-empty body and is > > interested in the content of that body, the methods doInitBody() and > > doAfterBody(), defined in the BodyTag interface are involved." > > My interpretation of this is: > * Tag "foo" may have body > * Blah -> body methods called > * -> no body methods called > > > Note, "can have", not "if it does have". So an element without a body, but > > that *could* have a body according to the TLD, still has do*Body methods > > called. > > .. if it has a body *in the usage of it*, sure. Of course. But if it's > not *used* with a body, then the body methods should not be called. > > > So: > > foo has do*Body() called (obviously). > > has do*Body() called (the body will just be blank) > > has do*Body() called, because according to the XML spec, this > is > > shorthand for the notation, and therefore processes > > equivalently. > > I see the two last ones as distinctly different, whereas the first two > are identical semantically. And I have a couple of tags that indeed > makes a major difference between and . > > > Interestingly, JRun3.0 has the opposite bug, and doesn't call > setBodyContent > > if the tag doesn't have a body but could. > > To me that is correct. > > > Eg, in JRun the following action breaks: > > > > > > Why? How is this tag dependent on a body to be supplied? > > > But this works: > > > > > > > > The taglib in question is from the Jakarta Taglibs project. > > To me this hints at a bug in the Jakarta Taglibs. > > It might be beneficial to send a query about this to the JSP spec > writers, since it's a rather important issue. I have CC'ed > [EMAIL PROTECTED] > > regards, > Rickard > > -- > Rickard Öberg > > Email: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] New Committer: Amy Roh
"Craig R. McClanahan" wrote: > > Amy has recently joined the JSP/Servlet team at Sun, and has contributed > several documentation updates and new tests for the test harness. She > would like to work on bug fixes, as well as participate in the development > of better admin tools, primarily on the Tomcat 4.0 code base. > > Votes please? +1 Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH] JSP examples TC 3.3 latest
Hi folks, there is still a little bug in the TC 3.3 JSP examples after my patch has been applied. The JSP-Servlet-JSP example does not show the Source code (with IE 5.5) Instead an Error 500 pops up. Reason: Wrong directory name referenced in jts.html (jsp/jsptoservlet instead of jsp/jsptoserv) Attatched is a patch. Best regards, Hans jts.html.diff --- src/examples/jsp/jsptoserv/jts.html.origSun Mar 11 19:38:57 2001 +++ src/examples/jsp/jsptoserv/jts.html Sun Mar 11 19:28:57 2001 @@ -12,10 +12,10 @@ -Source Code for JSP calling servlet +Source Code +for JSP calling servlet -Source Code for Servlet calling JSP +Source Code for +Servlet calling JSP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
