DO NOT REPLY [Bug 16001] - Tag.release() not invoked
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16001. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16001 Tag.release() not invoked --- Additional Comments From [EMAIL PROTECTED] 2003-01-20 08:35 --- Ok, thank you for your responses, I misinterpretted the specification. But I was confused because on previous version of tomcat (4.1.12 I think) it seemed to work as I thought it should work. I also tested on another servers and I got the same behaviour. Sorry, next time I will reread the specification before posting :) -- 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
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? Is this the way the Jasper tag pooling is implemented? Hans Br - Johan __ This message and its attachments have been found clean from known viruses with three different antivirus programs. __ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Calling DLL
Hi I want to call a dll from a jsp page using JNI i am using both Apache and Tomcat as servers.It is showing an error Class already loaded in another Class loader.I am placing the dll in the tomcat bin directory. Regards Thomas
Re: Tomcat 5 target JDK1.4?
V. Cekvenich wrote: Does Tomcat 5 Target JDK 1.4? It not...it should please. Apple, IBM, BEA have JDK1.4 (betas) available to download. The imports might change a bit. Tomcat5 should support JDK 1.4 but JDK 1.4 MUST NOT BE A PRE REQUISITE for TC 5 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16253] New: - Security roles in web.xml do not work with IIS
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16253. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16253 Security roles in web.xml do not work with IIS Summary: Security roles in web.xml do not work with IIS Product: Tomcat 4 Version: 4.1.18 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Security roles do not work in web.xml when using tomcat with Coyote JK2 connector and Microsoft IIS. We are using IIS to perform the authentication because the target environment has requirement for NTML authentication (we have request.tomcatAuthentication=false in jk2.properties). IIS authenticates user OK and the authenticated username is visible tomcat as expected. However, it is impossble to assign any roles to this user. The Coyote JK2 connector DLL seems to retrieve windows group names - one might imagine that those are for role names. But no, on code in java side seems to process them. Also, using Realms doesn't work since they don't do role processing when Principal is not created with them. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16254] New: - invalid response header
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16254. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16254 invalid response header Summary: invalid response header Product: Tomcat 4 Version: 4.1.18 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello! I tried to override the Server information of the response header by a filter servlet. But response.setHeader(Server, no name) does not override the existing attribute. The information appears twice! hdr HTTP/1.1 200 OK hdr Server: no name [...] hdr Server: Apache Coyote/1.0 hdr Connection: close I think it had been working well in Tomcat 3.?? Ciao Holger -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DataSourceRealm -- test case (question to Glenn Nielsen)
Hello list, especially Glenn! I'm not sure if this list is the right place to ask this kind of questions, and ask them directly to one person, but I thought that writing straight to such a busy person like Glenn would be even worse. As I saw in sources, you are the author of DataSourceRealm class, am I right? Can you provide me with some test cases about how to configure this realm? I tried to start using DataSourceRealm for about a four days, but still have no luck -- I end up at NameNotFoundException Name java: is not bound in this Context. I tried various places in server.xml to place Resource and ResourceParams tags... Looking at the sources, I found that resource should be placed inside GlobalNamingResource tag, but this didn't help either. Tomcat Users List didn't help me much, may be because nobody have tried this kind of realm yet. BTW, another person in tomcat-user asked for something similar, so this information will be useful not for me only. If you will be so kind to shed some light at this problem, please answer me directly or write in tomcat-user list so anybody who need it will be happy. :-) *** Sorry again, if i broke this list's netiquette. -- Veniamin Fichin [EMAIL PROTECTED] Programmer athttp://www.rbcsoft.ru/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16000] - Symlinks in /WEB-INF/lib not followed
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16000. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16000 Symlinks in /WEB-INF/lib not followed --- Additional Comments From [EMAIL PROTECTED] 2003-01-20 13:51 --- The problem is still existing with Tomcat 1.1.18 even when I set allowLinking with true -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15845] - 4.1.19 Memory Leak when creating compilier for JSP pages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15845. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15845 4.1.19 Memory Leak when creating compilier for JSP pages [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-01-20 13:55 --- I can not reproduce a memory leak with the information that has been provided. There is no Map used in any of the code related to checking of JSP compile time include dependencies. In fact, in all of Jasper 2 there are only a handful of places where a Map is used. If you have found a memory leak please provide more detailed information of the actual code responsible and examples of how to reproduce it. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16000] - Symlinks in /WEB-INF/lib not followed
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16000. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16000 Symlinks in /WEB-INF/lib not followed [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-01-20 13:58 --- I do not think you configured it properly. If you did and it still doesn't work, then bad luck, but it likely won't be fixed (as I don't see anything left to fix, with allowLinking, the code executed should be similar to 4.0.x). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16258] New: - getContext does not work on default context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16258. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16258 getContext does not work on default context Summary: getContext does not work on default context Product: Tomcat 4 Version: 4.1.12 Platform: Other OS/Version: Linux Status: NEW Severity: Blocker Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Having several contexts declared in a host entry, the default context ( context name= .. /context ) does not give access to other contexts declared in that host entry: myContext.Context(/other) will always return myContext. server.xml code snippet: host name=myhost.mydomain Context path= docBase=/myWebapps/test crossContext=true / Context path=other docBase=/myWebapps/other crossContext=true / /host /myWebapps/test/index.jsp: my context: %= getServletContext() % other context: %= getServletContext().getContext(/other) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16258] - getContext does not work on default context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16258. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16258 getContext does not work on default context [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-01-20 15:05 --- Try to do a query before filing a bug, as well as assign sensible severity level. *** This bug has been marked as a duplicate of 13040 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13040] - can't retrieve external context who's uri is a sub-dir of current context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13040. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13040 can't retrieve external context who's uri is a sub-dir of current context [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-01-20 15:05 --- *** Bug 16258 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 16258] - getContext does not work on defaultcontext
Martin Algesten wrote: Believe me, when your different web apps are relying on actually being able to use this part of the API to communicate with each other, then this is a blocker... Martin (who still doesn't understand why this isn't an issue worth fixing) Because your fix breaks more things, and makes a Watchdog test fail. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16253] - Security roles in web.xml do not work with IIS
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16253. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16253 Security roles in web.xml do not work with IIS [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||REMIND --- Additional Comments From [EMAIL PROTECTED] 2003-01-20 15:18 --- The idea was to use NT UserGroups as Roles, but never reached to conclusion, that is to read that Info gathered from Native-NT at Java Land ( they are transmited to tomcat over the wire but tomcat doenst get them from the AJP13 packet), and use them as roles... Maybe you were the next person after me who needed this :).. Unfortunately my tomcat time has reached 0 lately, i'll be unable to complete that feature in a timely fashion, ( we dont use Tomcat anymore for our Daily job so, sorry :) patches are welcomed :), thought .. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Why unpackWars=true default?
Howdy, Why is the unpackWars flag set to true by default in tomcat 4.1? I'm not suggesting the setting be changed, just curious about the reasoning. Thanks, Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
catalina.bat bug: can't start up tomcat with: startup -Dfile.encoding=ISO-8859-1 -Duser.language=en %CMD_LINE_ARGS% and %MAINCLASS% should be switched
I try to startup tomcat on my Chinese Windows2000 with English environment, but I found I can't startup tomcat: startup -Dfile.encoding=ISO-8859-1 -Duser.language=en and I checked the catalina.bat and echo the full cammand as following: start Tomcat ... org.apache.catalina.startup.Bootstrap -Dfile.encoding=ISO-8859-1 -Duser.language=en start the server starts ok after modified to: start Tomcat ... -Dfile.encoding=ISO-8859-1 -Duser.language=en org.apache.catalina.startup.Bootstrap start so I think the %CMD_LINE_ARGS% should before the %MAINCLASS% other wise some JVM arguments can't transfer to mainclass after mainclass has been loaded. %_EXECJAVA% %JAVA_OPTS% ... %MAINCLASS% %CMD_LINE_ARGS% %ACTION% == %_EXECJAVA% %JAVA_OPTS% ... %CMD_LINE_ARGS% %MAINCLASS% %ACTION% ^---^ My system: (Windows 2000 Chinese version) SUN JDK-1.4.1 tomcat 4.1.18-LE Che, Dong
Re: Tomcat 5 target JDK1.4?
Why? I say TC5 should require JDK1.4 or above. TC5 is JSP2.0. JDK1.4 is now available from multiple sources. It would make some code and imports easier. Even now, TC4 is run on JDK1.4. There is JDK 1.5 coming up, we would be one back. We do need to move ahead, and clean up the import so that TC5 does not need to carry as much jars. V Henri Gomez wrote: V. Cekvenich wrote: Does Tomcat 5 Target JDK 1.4? It not...it should please. Apple, IBM, BEA have JDK1.4 (betas) available to download. The imports might change a bit. Tomcat5 should support JDK 1.4 but JDK 1.4 MUST NOT BE A PRE REQUISITE for TC 5 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Why unpackWars=true default?
From looking at the docs for both Tomcat 4.0 and Tomcat 4.1 in the section on automatic application deployment it states for both that the default for unpackWARs is true. The section on the unpackWARs attribute does not mention the default value, perhaps it should. From my review it looks like Tomcat 4 has always defaulted to unpackWARs=true. I have no problem with that being the default. And it would not be good to change at this time since Tomcat 4 has been released for quite a while. Glenn Shapira, Yoav wrote: Howdy, Why is the unpackWars flag set to true by default in tomcat 4.1? I'm not suggesting the setting be changed, just curious about the reasoning. Thanks, Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Why unpackWars=true default?
Glenn Nielsen wrote: From looking at the docs for both Tomcat 4.0 and Tomcat 4.1 in the section on automatic application deployment it states for both that the default for unpackWARs is true. The section on the unpackWARs attribute does not mention the default value, perhaps it should. From my review it looks like Tomcat 4 has always defaulted to unpackWARs=true. I have no problem with that being the default. And it would not be good to change at this time since Tomcat 4 has been released for quite a while. More importantly, it would break webapps which rely on the filesystem, and would cause 1000 duplicates with blocker severity about getRealPath always returning null to be filed ;-) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Why unpackWars=true default?
Not to put words into other peoples mouth, but this was Craig's opinion awhile ago (from tomat-user): http://marc.theaimsgroup.com/?l=tomcat-userm=104000918909139w=2 Would it be better to remove unpackWARs from tomcat5 since there isn't that much of a concern for backwards compatibilty on major releases? -Tim Glenn Nielsen wrote: From looking at the docs for both Tomcat 4.0 and Tomcat 4.1 in the section on automatic application deployment it states for both that the default for unpackWARs is true. The section on the unpackWARs attribute does not mention the default value, perhaps it should. From my review it looks like Tomcat 4 has always defaulted to unpackWARs=true. I have no problem with that being the default. And it would not be good to change at this time since Tomcat 4 has been released for quite a while. Glenn Shapira, Yoav wrote: Howdy, Why is the unpackWars flag set to true by default in tomcat 4.1? I'm not suggesting the setting be changed, just curious about the reasoning. Thanks, Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Why unpackWars=true default?
Hi, From my review it looks like Tomcat 4 has always defaulted to unpackWARs=true. I have no problem with that being the default. And it would not be good to change at this time since Tomcat 4 has been released for quite a while. More importantly, it would break webapps which rely on the filesystem, and would cause 1000 duplicates with blocker severity about getRealPath always returning null to be filed ;-) I agree ;) This is why I said I was NOT suggesting it be changed ;) Was it a conscious decision to make it true by default back when tomcat 4.0 came out? Or just kind of happened? Thanks, Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Turkish Character Encoding
Dear Friends, I have got a problem with character encoding under tomcat 4. When I post a form containing TURKISH character the Turkish characters transferd as ? (d?hy?), Could you help me about this? Thanks Seyavouysh AKRAMI -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Fwd: catalina.bat bug: can't start up tomcat with: startup-Dfile.encoding=ISO-8859-1 -Duser.language=en
From: Che Dong [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: catalina.bat bug: can't start up tomcat with: startup -Dfile.encoding=ISO-8859-1 -Duser.language=en %CMD_LINE_ARGS% and %MAINCLASS% should be switched Date: Mon, 20 Jan 2003 23:44:42 +0800 I try to startup tomcat on my Chinese Windows2000 with English environment, but I found I can't startup tomcat: startup -Dfile.encoding=ISO-8859-1 -Duser.language=en and I checked the catalina.bat and echo the full cammand as following: start Tomcat ... org.apache.catalina.startup.Bootstrap -Dfile.encoding=ISO-8859-1 -Duser.language=en start the server starts ok after modified to: start Tomcat ... -Dfile.encoding=ISO-8859-1 -Duser.language=en org.apache.catalina.startup.Bootstrap start so the %CMD_LINE_ARGS% should before the %MAINCLASS% other wise some JVM arguments can't transfer to mainclass after mainclass has been loaded. I think the %CMD_LINE_ARGS% and %MAINCLASS% in catalina.bat should be switched: %_EXECJAVA% %JAVA_OPTS% ... %MAINCLASS% %CMD_LINE_ARGS% %ACTION% == %_EXECJAVA% %JAVA_OPTS% ... %CMD_LINE_ARGS% %MAINCLASS% %ACTION% ^---^ My system: (Windows 2000 Chinese version) SUN JDK-1.4.1 tomcat 4.1.18-LE Regards Che, Dong _ ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£ http://www.hotmail.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 athttp://TheJSPBook.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 16258] - getContext does not work on default context
Believe me, when your different web apps are relying on actually being able to use this part of the API to communicate with each other, then this is a blocker... Martin (who still doesn't understand why this isn't an issue worth fixing) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 20 January 2003 15:05 To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 16258] - getContext does not work on default context DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cg i?id=16258. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16258 getContext does not work on default context [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-01-20 15:05 --- Try to do a query before filing a bug, as well as assign sensible severity level. *** This bug has been marked as a duplicate of 13040 *** -- 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]
Timeout Sesion
Hola, tengo una pregunta acerca de la caducidad de sessiones de tomcat.
Si pongo el sihuiente código en un .jsp:
%
session.setMaxInactiveInterval( 1 );
out.println(html +
headtitleSession Information/title/head +
body bgcolor=\#FF\ +
h1Session Information/h1table);
out.println (trtdIdentifier/td);
out.println (td + session.getId() + /td/tr);
out.println (trtdCreated/td);
out.println (td + new Date(session.getCreationTime()) +
/td/tr);
out.println (trtdLast Accessed/td);
out.println (td + new Date(session.getLastAccessedTime()) +
/td/tr);
out.println (trtd session.getMaxInactiveInterval()???/td);
out.println (td + session.getMaxInactiveInterval() +
/td/tr);
out.println (trtdNew Session?/td);
out.println (td + session.isNew() + /td/tr);
Enumeration names = session.getAttributeNames();
while ( names.hasMoreElements() ) {
String name = (String) names.nextElement();
out.println (trtd + name + /td);
out.println (td + session.getAttribute(name) + /td/tr);
}
out.println(/table/center/body/html);
if(session==null){
out.println(engine: session expired !!! What to do ?);
}
else{
if(session.isNew()){
out.println(engine: session control. Session expired
!! getLastAccessedTime() = +session.getLastAccessedTime());
response.sendRedirect(http://www.google.com;);
}else{
System.out.println(\n\n.NNNOOOisNew(), session
control. Session still alive ...);
out.println(\ncontrol. Session still alive
...getLastAccessedTime() = +session.getLastAccessedTime());
}
}
%
pues al cabo de unos de segundos de entrar el ese .jsp, si actualizo, la
sesión ha caducado, pero me gustaría que el tiempo se pudiese controlar
desde la etiqueta
session-config
session-timeout1/session-timeout
/session-config
del web.xml, pero eso no me funciona así, si uso la etiqueta en el
web.xml, al recoger mel getMaxInactiveInterval,
vale...session.getMaxInactiveInterval()= -1
qué puedo hacer para configurar el timeout de tomcat desde el web.xml,
qué le falta a mi código???
además usando session.setMaxInactiveInterval( 1 ); , no me caduca al
segundo, sinó que al cabo de varios segundos!!
Gracias, Patricia
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Why unpackWars=true default?
Shapira, Yoav wrote: Hi, From my review it looks like Tomcat 4 has always defaulted to unpackWARs=true. I have no problem with that being the default. And it would not be good to change at this time since Tomcat 4 has been released for quite a while. More importantly, it would break webapps which rely on the filesystem, and would cause 1000 duplicates with blocker severity about getRealPath always returning null to be filed ;-) I agree ;) This is why I said I was NOT suggesting it be changed ;) Was it a conscious decision to make it true by default back when tomcat 4.0 came out? Or just kind of happened? IMO packed WARs are evil and shouldn't be ever used at runtime. They increase the code complexity, reduce the ability to integrate with web servers, fail if the code uses the file system. Even if you can get an InputStream and avoid using the filesystem - there are a lot of things that won't work - random access to files, NIO, etc. WAR is a _deployment_ format - just like RPM or PKG or install shield .exe files. Nobody is running programs directly from the RPM or from inside the uninstalled install shield application. I would be pretty happy if packed wars will be deprecated or strongly discouraged in 5.0 - but strongly -1 on changing the default. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util CookieTools.java
costin 2003/01/20 10:38:50
Modified:catalina/src/share/org/apache/catalina/util CookieTools.java
Log:
Add an extra space after ; in cookies.
This avoids problems with some IE/Mac versions, and makes the
cookies closer to the examples in the spec ( which include the space )
Revision ChangesPath
1.8 +11 -11
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/CookieTools.java
Index: CookieTools.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/CookieTools.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- CookieTools.java 21 Feb 2002 22:51:55 - 1.7
+++ CookieTools.java 20 Jan 2003 18:38:50 - 1.8
@@ -122,11 +122,11 @@
// add version 1 specific information
if (version == 1) {
// Version=1 ... required
-buf.append (;Version=1);
+buf.append (; Version=1);
// Comment=comment
if (cookie.getComment() != null) {
-buf.append (;Comment=);
+buf.append (; Comment=);
maybeQuote (version, buf, cookie.getComment());
}
}
@@ -134,14 +134,14 @@
// add domain information, if present
if (cookie.getDomain() != null) {
-buf.append(;Domain=);
+buf.append(; Domain=);
maybeQuote (version, buf, cookie.getDomain());
}
// Max-Age=secs/Discard ... or use old Expires format
if (cookie.getMaxAge() = 0) {
if (version == 0) {
-buf.append (;Expires=);
+buf.append (; Expires=);
if (cookie.getMaxAge() == 0)
DateTool.oldCookieFormat.format(new Date(1), buf,
new FieldPosition(0));
@@ -151,21 +151,21 @@
cookie.getMaxAge() *1000L), buf,
new FieldPosition(0));
} else {
-buf.append (;Max-Age=);
+buf.append (; Max-Age=);
buf.append (cookie.getMaxAge());
}
} else if (version == 1)
- buf.append (;Discard);
+ buf.append (; Discard);
// Path=path
if (cookie.getPath() != null) {
-buf.append (;Path=);
+buf.append (; Path=);
maybeQuote (version, buf, cookie.getPath());
}
// Secure
if (cookie.getSecure()) {
- buf.append (;Secure);
+ buf.append (; Secure);
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 5 target JDK1.4?
For TC 4 OK, but TC5 will have tested 4 vendors JVM 1.4. Most people run JDK 1.4 now. Costin Manolache wrote: V. Cekvenich wrote: Why? I say TC5 should require JDK1.4 or above. Why would you decide for what other people ? TC5 is JSP2.0. JDK1.4 is now available from multiple sources. It would make some code and imports easier. Not everyone can play with the VM version they run. Production servers usually preffer more tested and stable VMs. Some people may also preffer an open-source VM ( kaffe, GCJ, etc ). Costin Even now, TC4 is run on JDK1.4. There is JDK 1.5 coming up, we would be one back. We do need to move ahead, and clean up the import so that TC5 does not need to carry as much jars. V Henri Gomez wrote: V. Cekvenich wrote: Does Tomcat 5 Target JDK 1.4? It not...it should please. Apple, IBM, BEA have JDK1.4 (betas) available to download. The imports might change a bit. Tomcat5 should support JDK 1.4 but JDK 1.4 MUST NOT BE A PRE REQUISITE for TC 5 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Why unpackWars=true default?
Costin Manolache wrote: Shapira, Yoav wrote: Hi, From my review it looks like Tomcat 4 has always defaulted to unpackWARs=true. I have no problem with that being the default. And it would not be good to change at this time since Tomcat 4 has been released for quite a while. More importantly, it would break webapps which rely on the filesystem, and would cause 1000 duplicates with blocker severity about getRealPath always returning null to be filed ;-) I agree ;) This is why I said I was NOT suggesting it be changed ;) Was it a conscious decision to make it true by default back when tomcat 4.0 came out? Or just kind of happened? IMO packed WARs are evil and shouldn't be ever used at runtime. They increase the code complexity, reduce the ability to integrate with web servers, fail if the code uses the file system. Even if you can get an InputStream and avoid using the filesystem - there are a lot of things that won't work - random access to files, NIO, etc. WAR is a _deployment_ format - just like RPM or PKG or install shield .exe files. Nobody is running programs directly from the RPM or from inside the uninstalled install shield application. I would be pretty happy if packed wars will be deprecated or strongly discouraged in 5.0 - but strongly -1 on changing the default. Costin I agree with Costin, I would be -1 for removing unpackWARs or changing its default. Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 5 target JDK1.4?
V. Cekvenich wrote: For TC 4 OK, but TC5 will have tested 4 vendors JVM 1.4. Most people run JDK 1.4 now. Perhaps you do, but where is the data to support your claim above that most people run JDK 1.4? Those who have systems in production and have spent alot of time developing applications which are hosted on those systems can't do a major upgrade like JVM 1.3 - JVM 1.4 at the drop of a hat. Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 5 target JDK1.4?
Howdy, Most people run JDK 1.4 now. Where, pray tell, did you gather that statistical gem? ;) Yoav Shapira Millennium ChemInformatics -- 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]
I haven't read all the posts on this discussion, but here's some facts from personal observations. for pages with only a few tags, ie less than 30, tag pooling doesn't help. On the otherhand, if your page has 100+ tags, it improves performance. Some of the pages I benchmarked with had about 135 tags. In those situations, I saw a 20-50% improvement. I would argue that sites that don't have a lot of load should simply turn off tag pooling. Site that use tags extensively and get 1millions page views a day, will gain significantly from tag pooling. peter lin Costin Manolache [EMAIL PROTECTED] wrote:Hans Bergsten wrote: Without pooling With pooling Reuse w/o overhead - 5 threads Avg.: 330 ms 349 ms N/A Rate: 15.2/sec 13.6/sec N/A 20 threads Avg.: 1,752 ms 1,446 ms 1,265 ms Rate: 12.1/sec 13.6/sec 14.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 And the test page is not representative of the type of pages that will run on a real site. I know that. All we can measure with relative accuracy is the overhead of the container/jsp implementation - at least in relative terms. Take as the reference the time ( or RPS ) for Apache to serve the same output as a static page. Or the time a servlet will take to generate the same output. Run your tests with 5, 20, 100 RPS ( and ab may be a better driver ). Compare the results - and most likely a production server will see similar ratios. I'll try to find some time ( next week - I hope ) and run the same tests with the no sync pool. 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. Well - it shows pretty clearly that the _current_ implementation of thread pool is broken. Even if we don't take sync into account, the pool has a 5 object limit - what else could you expect ?? 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. The 1.4 JIT takes some time to kick in, if you run batches of 1000 requests you'll see the time keeps improving. I would do at leat 5000 request to warm up the jit. 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. Most of the improvements in coyote ( or in 3.3 over 3.2 ) are due to object reuse. It is possible that tag handlers are different and the other overheads will obscure any benefit ( at least under low load ), but I can bet that under heavy load recycling will be very significant, if done correctly. Costin -- To unsubscribe, e-mail: For additional commands, e-mail: - Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java
costin 2003/01/20 11:20:32
Modified:jk/java/org/apache/jk/common ChannelSocket.java
HandlerDispatch.java JkMX.java MsgAjp.java
jk/java/org/apache/jk/server JkCoyoteHandler.java
Log:
Remove unused imports, add/fix comments.
JkMX will only load the jmx console, since components now know and support
JMX. This also removes the dependency on DynamicMbean - modeler now supports
all the features of DynamicMBean, it should be deprecated.
Revision ChangesPath
1.32 +0 -6
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java
Index: ChannelSocket.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- ChannelSocket.java16 Jan 2003 22:13:37 - 1.31
+++ ChannelSocket.java20 Jan 2003 19:20:32 - 1.32
@@ -60,17 +60,11 @@
package org.apache.jk.common;
import java.io.*;
-
import java.net.*;
-import java.util.*;
-
-import org.apache.tomcat.util.buf.*;
-import org.apache.tomcat.util.http.*;
import org.apache.tomcat.util.threads.*;
import org.apache.jk.core.*;
-import org.apache.jk.server.JkMain;
import org.apache.commons.modeler.Registry;
1.4 +1 -7
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerDispatch.java
Index: HandlerDispatch.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerDispatch.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- HandlerDispatch.java 17 Apr 2002 22:38:42 - 1.3
+++ HandlerDispatch.java 20 Jan 2003 19:20:32 - 1.4
@@ -60,15 +60,9 @@
package org.apache.jk.common;
import java.io.*;
-import java.net.*;
-import java.util.*;
-import java.security.*;
-import java.security.cert.*;
-
import org.apache.jk.core.*;
-import org.apache.tomcat.util.http.*;
-import org.apache.tomcat.util.buf.*;
+
/**
1.8 +27 -16jakarta-tomcat-connectors/jk/java/org/apache/jk/common/JkMX.java
Index: JkMX.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/JkMX.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- JkMX.java 30 Oct 2002 22:22:46 - 1.7
+++ JkMX.java 20 Jan 2003 19:20:32 - 1.8
@@ -58,22 +58,20 @@
*/
package org.apache.jk.common;
-import java.io.*;
-import java.net.*;
-import java.util.*;
-import org.apache.jk.core.*;
-import org.apache.jk.server.JkMain;
+import org.apache.jk.core.JkHandler;
-import javax.management.*;
+import javax.management.MBeanServer;
+import javax.management.ObjectName;
+import javax.management.Attribute;
+import javax.management.MBeanServerFactory;
+import java.io.IOException;
-import org.apache.tomcat.util.mx.*;
-
-/** MX-enable jk.
+/**
+ * Load the HTTP or RMI adapters for MX4J and JMXRI.
+ *
+ * Add mx.port=PORT in jk2.properties to enable it.
*
- * Add mx.port=PORT in jk2.properties to enable it.
- * If port==-1 the JMX will be enabled but no HTTP adapter will be loaded.
- * Port 0 will load the mx4j adapter, if possible.
*/
public class JkMX extends JkHandler
{
@@ -216,7 +214,7 @@
public void init() throws IOException {
try {
-mserver = DynamicMBeanProxy.getMBeanServer();
+mserver = getMBeanServer();
if( port 0 ) {
loadAdapter();
@@ -231,27 +229,40 @@
log.info(Can't enable log4j mx);
}
-DynamicMBeanProxy.createMBean( JkMain.getJkMain(), jk2, name=JkMain
);
+/*
+DynamicMBeanProxy.createMBean( JkMain.getJkMain(), jk2, name=JkMain
);
for( int i=0; i wEnv.getHandlerCount(); i++ ) {
JkHandler h=wEnv.getHandler( i );
DynamicMBeanProxy.createMBean( h, jk2, name= + h.getName() );
}
-
+*/
} catch( Throwable t ) {
log.error( Init error, t );
}
}
public void addHandlerCallback( JkHandler w ) {
-if( w!=this ) {
+/*if( w!=this ) {
DynamicMBeanProxy.createMBean( w, jk2, name= + w.getName() );
}
+*/
+}
+
+MBeanServer getMBeanServer() {
+MBeanServer server;
+if( MBeanServerFactory.findMBeanServer(null).size() 0 ) {
+
cvs commit: jakarta-tomcat-site/xdocs resources.xml
remm2003/01/20 11:25:25 Modified:docs resources.html xdocsresources.xml Log: - Update book listing, with links to Amazon. - Wow, 9 books now (including mine) :) Revision ChangesPath 1.10 +20 -4 jakarta-tomcat-site/docs/resources.html Index: resources.html === RCS file: /home/cvs/jakarta-tomcat-site/docs/resources.html,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- resources.html17 Dec 2002 16:40:23 - 1.9 +++ resources.html20 Jan 2003 19:25:25 - 1.10 @@ -137,23 +137,39 @@ blockquote ul li - bApache Jakarta-Tomcat/b, by James Goodwillbr / + ba href=http://www.amazon.com/exec/obidos/tg/detail/-/1893115364/qid=1043089531/sr=1-4/ref=sr_1_4/002-9433156-6683214?v=glanceamp;s=books;Apache Jakarta-Tomcat/a/b, by James Goodwillbr / iAPress/i /li li ba href=http://tomcatbook.sourceforge.net/;Tomcat Book Project/a/b /li li - bProfessional Apache Tomcat/b, by Chanoch Wiggers, Ben Galbraith, Vivek Chopra, Sing Li, Debashish Bhattacharjee, Amit Bakore, Romin Irani, Sandip Bhattacharya, Chad Fowlerbr / + ba href=http://www.amazon.com/exec/obidos/tg/detail/-/1861007736/ref=pd_sbs_b_1/002-9433156-6683214?v=glanceamp;s=books;Professional Apache Tomcat/a/b, by Chanoch Wiggers, Ben Galbraith, Vivek Chopra, Sing Li, Debashish Bhattacharjee, Amit Bakore, Romin Irani, Sandip Bhattacharya, Chad Fowlerbr / iWrox Press/i /li li - bMastering Tomcat Development/b, by Peter Harrison, Ian McFarlandbr / + ba href=http://www.amazon.com/exec/obidos/tg/detail/-/0471237647/qid=1043089531/sr=1-1/ref=sr_1_1/002-9433156-6683214?v=glanceamp;s=books;Mastering Tomcat Development/a/b, by Peter Harrison, Ian McFarlandbr / iJohn Wiley amp; Sons/i /li li - bTomcat Kick Start/b, by Martin Bond, Debbie Lawbr / + ba href=http://www.amazon.com/exec/obidos/tg/detail/-/0672324393/qid=1043089531/sr=1-5/ref=sr_1_5/002-9433156-6683214?v=glanceamp;s=books;Tomcat Kick Start/a/b, by Martin Bond, Debbie Lawbr / iSams/i +/li +li + ba href=http://www.amazon.com/exec/obidos/tg/detail/-/0596003188/qid=1043089531/sr=1-6/ref=sr_1_6/002-9433156-6683214?v=glanceamp;s=books;Tomcat: The Definitive Guide/a/b, by Jason Brittain, Ian F. Darwinbr / + iO'Reilly amp; Associates/i +/li +li + ba href=http://www.amazon.com/exec/obidos/tg/detail/-/1861008309/qid=1043089531/sr=1-8/ref=sr_1_8/002-9433156-6683214?v=glanceamp;s=books;Apache Tomcat Security Handbook/a/b, by Vivek Chopra, Ben Galbriaths, Brian Rickabaugh, Gotham Pollysettybr / + iWrox Press/i +/li +li + ba href=http://www.amazon.com/exec/obidos/tg/detail/-/1861008546/qid=1043089531/sr=1-7/ref=sr_1_7/002-9433156-6683214?v=glanceamp;s=books;Apache Tomcat Performance Handbook/a/b, by Remy Maucherat, Peter Linbr / + iWrox Press/i +/li +li + ba href=http://www.amazon.com/exec/obidos/tg/detail/-/0764526065/qid=1043089531/sr=1-9/ref=sr_1_9/002-9433156-6683214?v=glanceamp;s=books;Apache Tomcat Bible/a/b, by Warner Godfrey, Jon Eaves, Rupert Jonesbr / + iHungry Minds, Inc/i /li /ul /blockquote 1.5 +20 -4 jakarta-tomcat-site/xdocs/resources.xml Index: resources.xml === RCS file: /home/cvs/jakarta-tomcat-site/xdocs/resources.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- resources.xml 17 Dec 2002 13:26:04 - 1.4 +++ resources.xml 20 Jan 2003 19:25:25 - 1.5 @@ -20,23 +20,39 @@ ul li - bApache Jakarta-Tomcat/b, by James Goodwillbr/ + ba href=http://www.amazon.com/exec/obidos/tg/detail/-/1893115364/qid=1043089531/sr=1-4/ref=sr_1_4/002-9433156-6683214?v=glanceamp;s=books;Apache Jakarta-Tomcat/a/b, by James Goodwillbr/ iAPress/i /li li ba href=http://tomcatbook.sourceforge.net/;Tomcat Book Project/a/b /li li - bProfessional Apache Tomcat/b, by Chanoch Wiggers, Ben Galbraith, Vivek Chopra, Sing Li, Debashish Bhattacharjee, Amit Bakore, Romin Irani, Sandip Bhattacharya, Chad Fowlerbr/ + ba href=http://www.amazon.com/exec/obidos/tg/detail/-/1861007736/ref=pd_sbs_b_1/002-9433156-6683214?v=glanceamp;s=books;Professional Apache Tomcat/a/b, by Chanoch Wiggers, Ben Galbraith, Vivek Chopra, Sing Li, Debashish Bhattacharjee, Amit Bakore, Romin Irani, Sandip Bhattacharya, Chad Fowlerbr/ iWrox Press/i /li li - bMastering Tomcat Development/b, by Peter Harrison, Ian McFarlandbr/ + ba
Re: Timeout Sesion (spanish answer, excuse me!!)
pues al cabo de unos de segundos de entrar el ese .jsp, si actualizo, la sesión ha caducado, pero me gustaría que el tiempo se pudiese controlar desde la etiqueta session-config session-timeout1/session-timeout /session-config del web.xml, pero eso no me funciona así, si uso la etiqueta en el web.xml, al recoger mel getMaxInactiveInterval, vale...session.getMaxInactiveInterval()= -1 qué puedo hacer para configurar el timeout de tomcat desde el web.xml, qué le falta a mi código??? además usando session.setMaxInactiveInterval( 1 ); , no me caduca al segundo, sinó que al cabo de varios segundos!! Pues yo tengo puesto un timeout de 120 en el web.xml y en session.getMaxInactiveInterval() me sale 7200 (lo cual es correcto). Seguro que tienes bien escrito el web.xml? Debería ser: session-config session-timeout 120 /session-timeout /session-config Y sobre lo de que le cueste más de 1 segundo desecharte la sesión, puede ser por los mecanismos de detección de expiración de sesiones de Tomcat, que se ejecutan periódicamente, pero no continuamente por lo que puede haber retrasos. No se si esto te solucionará el problema. Un saludo y encantado de hablar con alguien en castellano en la lista. Un saludo. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16274] New: - JAASRealm breaks catalina classloader under JDK 1.4
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16274. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16274 JAASRealm breaks catalina classloader under JDK 1.4 Summary: JAASRealm breaks catalina classloader under JDK 1.4 Product: Tomcat 4 Version: 4.1.18 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I managed to configure the JAASRealm authenticator that I found was part of Catalina. The jaas.conf, I initially set to use the JAASMemoryLoginModule (that allows JAAS to use the tomcat-users.xml file to perform authentication). On starting tomcat can with the -security flag and passing the jaas related VM flags I found that the VM was not finding the LoginModule which is part of catalina.jar . I placed catalina.jar in the vm classpath but this resulted in catalina not starting at all. (LifeCycle Classdefnotfound). I tried placing catalina.jar in all the places I could think off but to no avail. I then extracted the JAAS related class (and org.apache.catalina.Realm) and placed it in a seperated jar (loginmodule.jar) and placed it in bin and add the jar to the classpath (after bootstrap.jar). This also failed to resolve the issue as JAASMemoryLoginModule implements Realm. This interface is part of the catalina.jar and essentially I ended up with the same results as having catalina.jar in the classpath (LifeCycle classdefnotfound). As an experiment I decided to create a new LoginModule with no dependencies to catalina except for JAASCallbackHandler (principals and roles were statically initialized in the class to simulate authentication). Up on placing this jar in the classpath and leaving the rest of tomcat the way it was seems to have done the trick. I presume that the LoginModule needs to be in the classpath as of jdk1.4 as JAAS is shipped with the jdk. If this is true then I thik it would be necessary to repackage the JAAS related functionality in a seperate jar and do with it the same as bootstrap.jar. Regards suhail -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 16258] - getContext does not work on defaultcontext
I know I've taken several stabs at fixing this (e.g. submitting loads of patches). And I know some of them broke more than fixed. However have you reviewed the latest patch I did? If it still breaks, please tell me why so I can do a proper one. Martin -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 20 January 2003 15:11 To: Tomcat Developers List Subject: Re: DO NOT REPLY [Bug 16258] - getContext does not work on defaultcontext Martin Algesten wrote: Believe me, when your different web apps are relying on actually being able to use this part of the API to communicate with each other, then this is a blocker... Martin (who still doesn't understand why this isn't an issue worth fixing) Because your fix breaks more things, and makes a Watchdog test fail. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tag reuse performance [Was: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked]
Peter Lin wrote: I haven't read all the posts on this discussion, but here's some facts from personal observations. for pages with only a few tags, ie less than 30, tag pooling doesn't help. On the otherhand, if your page has 100+ tags, it improves performance. Some of the pages I benchmarked with had about 135 tags. In those situations, I saw a 20-50% improvement. I would argue that sites that don't have a lot of load should simply turn off tag pooling. Site that use tags extensively and get 1millions page views a day, will gain significantly from tag pooling. Is this based on the current tag pool implementation in jasper2 ? Because it is pretty clear that the tag pool has few problems. I would say the nature of the tags will also have a big impact. If your tag is very simple - you'll probably get some small benefits under load ( 20..30% ?). If the tag uses internal data structures, buffers, etc - it's very likely you'll see more ( since creating each tag instance will also create the additional hashtable, StringBuffers, etc ). I would bet that with complex tags that are specifically written to take advantage of the recycling you would see at least 2x better performance ( with a good sync-free and large enough tag pool ). If your tag is using any buffers or complex/expensive data structures that can be recycled - you'll save a lot. I don't think the number of tags in a page is too important - even if you have 1 complex tag - with 100 concurent users - you should see a difference. 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. Costin peter lin Costin Manolache [EMAIL PROTECTED] wrote:Hans Bergsten wrote: Without pooling With pooling Reuse w/o overhead - 5 threads Avg.: 330 ms 349 ms N/A Rate: 15.2/sec 13.6/sec N/A 20 threads Avg.: 1,752 ms 1,446 ms 1,265 ms Rate: 12.1/sec 13.6/sec 14.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 And the test page is not representative of the type of pages that will run on a real site. I know that. All we can measure with relative accuracy is the overhead of the container/jsp implementation - at least in relative terms. Take as the reference the time ( or RPS ) for Apache to serve the same output as a static page. Or the time a servlet will take to generate the same output. Run your tests with 5, 20, 100 RPS ( and ab may be a better driver ). Compare the results - and most likely a production server will see similar ratios. I'll try to find some time ( next week - I hope ) and run the same tests with the no sync pool. 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. Well - it shows pretty clearly that the _current_ implementation of thread pool is broken. Even if we don't take sync into account, the pool has a 5 object limit - what else could you expect ?? 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. The 1.4 JIT takes some time to kick in, if you run batches of 1000 requests you'll see the time keeps improving. I would do at leat 5000 request to warm up the jit. 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. Most of the improvements in coyote ( or in 3.3 over 3.2 ) are due to object reuse. It is possible that tag handlers are different and the other overheads will obscure any benefit ( at least under low load ), but I can bet that under heavy load recycling will be very
Re: Tomcat 5 target JDK1.4?
Glenn Nielsen wrote: V. Cekvenich wrote: For TC 4 OK, but TC5 will have tested 4 vendors JVM 1.4. Most people run JDK 1.4 now. Perhaps you do, but where is the data to support your claim above that most people run JDK 1.4? Going around to clients site. What are you running.. Those who have systems in production and have spent alot of time developing applications which are hosted on those systems can't do a major upgrade like JVM 1.3 - JVM 1.4 at the drop of a hat. Drop of the hat == when is TC5 due? Anyway, no one is arguing my side that we must have progress. JRockit, a popular VM is JDK 1.4. And IBM has a download that supports AS400 on 1.4, and Apple is coming out. In Java, the whole point is you can go switch out a VM, at a drop of a hat. I mean, JDK 1.5 is coming out. But if I am the only one asking, maybe I am drunk. The thing is go to your IDE (IDEj) and flag target 1.4, do you see all the import changes? .V Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote RequestInfo.java RequestProcessor.java
costin 2003/01/20 15:42:45
Added: coyote/src/java/org/apache/coyote RequestInfo.java
Removed: coyote/src/java/org/apache/coyote RequestProcessor.java
Log:
Better name.
Revision ChangesPath
1.1
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/RequestInfo.java
Index: RequestInfo.java
===
/*
*
*
* 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 AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.coyote;
import java.util.ArrayList;
/**
* Structure holding the Request and Response objects. It also holds statistical
* informations about request processing and provide management informations
* about the requests beeing processed.
*
* Each thread uses a Request/Response pair that is recycled on each request.
* This object provides a place to collect global low-level statistics - without
* having to deal with synchronization ( since each thread will have it's own
* RequestProcessorMX ).
*
* TODO: Request notifications will be registered here.
*
* @author Costin Manolache
*/
public class RequestInfo {
RequestGroupInfo global=null;
// --- Constructors
public RequestInfo( Request req) {
this.req=req;
}
public void setGlobalProcessor(RequestGroupInfo global) {
if( global != null) {
this.global=global;
global.addRequestProcessor( this );
}
}
// - Instance Variables
Request req;
Response res;
// Information about the current request ---
// This is usefull for long-running requests only
public String getCurrentUri() {
return req.requestURI().toString();
}
public String getCurrentQueryString() {
return req.queryString().toString();
}
public String getProtocol() {
return req.protocol().toString();
}
public String getVirtualHost() {
return req.serverName().toString();
}
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote RequestGroupInfo.java
costin 2003/01/20 15:43:41
Added: coyote/src/java/org/apache/coyote RequestGroupInfo.java
Log:
Group info - agregate the data from all requests.
Implement collection for the time data.
Revision ChangesPath
1.1
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/RequestGroupInfo.java
Index: RequestGroupInfo.java
===
package org.apache.coyote;
import java.util.ArrayList;
/** This can be moved to top level ( eventually with a better name ).
* It is currently used only as a JMX artifact, to agregate the data
* collected from each RequestProcessor thread.
*/
public class RequestGroupInfo {
ArrayList processors=new ArrayList();
public void addRequestProcessor( RequestInfo rp ) {
processors.add( rp );
}
public long getMaxTime() {
long maxTime=0;
for( int i=0; iprocessors.size(); i++ ) {
RequestInfo rp=(RequestInfo)processors.get( i );
if( maxTime rp.getMaxTime() ) maxTime=rp.getMaxTime();
}
return maxTime;
}
// Used to reset the times
public void setMaxTime(long maxTime) {
for( int i=0; iprocessors.size(); i++ ) {
RequestInfo rp=(RequestInfo)processors.get( i );
rp.setMaxTime(maxTime);
}
}
public long getProcessingTime() {
long time=0;
for( int i=0; iprocessors.size(); i++ ) {
RequestInfo rp=(RequestInfo)processors.get( i );
time += rp.getProcessingTime();
}
return time;
}
public void setProcessingTime(long totalTime) {
for( int i=0; iprocessors.size(); i++ ) {
RequestInfo rp=(RequestInfo)processors.get( i );
rp.setProcessingTime( totalTime );
}
}
public int getRequestCount() {
int requestCount=0;
for( int i=0; iprocessors.size(); i++ ) {
RequestInfo rp=(RequestInfo)processors.get( i );
requestCount += rp.getRequestCount();
}
return requestCount;
}
public void setRequestCount(int requestCount) {
for( int i=0; iprocessors.size(); i++ ) {
RequestInfo rp=(RequestInfo)processors.get( i );
rp.setRequestCount( requestCount );
}
}
public int getErrorCount() {
int requestCount=0;
for( int i=0; iprocessors.size(); i++ ) {
RequestInfo rp=(RequestInfo)processors.get( i );
requestCount += rp.getErrorCount();
}
return requestCount;
}
public void setErrorCount(int errorCount) {
for( int i=0; iprocessors.size(); i++ ) {
RequestInfo rp=(RequestInfo)processors.get( i );
rp.setErrorCount( errorCount);
}
}
public long getBytesReceived() {
long bytes=0;
for( int i=0; iprocessors.size(); i++ ) {
RequestInfo rp=(RequestInfo)processors.get( i );
bytes += rp.getBytesReceived();
}
return bytes;
}
public void setBytesReceived(long bytesReceived) {
for( int i=0; iprocessors.size(); i++ ) {
RequestInfo rp=(RequestInfo)processors.get( i );
rp.setBytesReceived( bytesReceived );
}
}
public long getBytesSent() {
long bytes=0;
for( int i=0; iprocessors.size(); i++ ) {
RequestInfo rp=(RequestInfo)processors.get( i );
bytes += rp.getBytesSent();
}
return bytes;
}
public void setBytesSent(long bytesSent) {
for( int i=0; iprocessors.size(); i++ ) {
RequestInfo rp=(RequestInfo)processors.get( i );
rp.setBytesSent( bytesSent );
}
}
public void resetCounters() {
this.setBytesReceived(0);
this.setBytesSent(0);
this.setRequestCount(0);
this.setProcessingTime(0);
this.setMaxTime(0);
this.setErrorCount(0);
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Request.java
costin 2003/01/20 15:45:11
Modified:coyote/src/java/org/apache/coyote Request.java
Log:
Update RequestInfo.
Add a new field - start time. It's very usefull - it can be used
in many places to avoid calling System.currentTimeMillis().
Revision ChangesPath
1.18 +11 -3
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java
Index: Request.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- Request.java 16 Jan 2003 22:25:19 - 1.17
+++ Request.java 20 Jan 2003 23:45:11 - 1.18
@@ -190,8 +190,10 @@
private ActionHook hook;
private int bytesRead=0;
+// Time of the request - usefull to avoid repeated calls to System.currentTime
+private long startTime;
-private RequestProcessor reqProcessorMX=new RequestProcessor(this);
+private RequestInfo reqProcessorMX=new RequestInfo(this);
// - Properties
@@ -447,11 +449,17 @@
// debug
-
public String toString() {
return R( + requestURI().toString() + );
}
+public long getStartTime() {
+return startTime;
+}
+
+public void setStartTime(long startTime) {
+this.startTime = startTime;
+}
// Per-Request notes
@@ -509,7 +517,7 @@
}
// Info
-public RequestProcessor getRequestProcessor() {
+public RequestInfo getRequestProcessor() {
return reqProcessorMX;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java Http11Protocol.java
costin 2003/01/20 15:47:05
Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java Http11Protocol.java
Log:
Update for RequestInfo and new group info.
Revision ChangesPath
1.57 +1 -0
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Index: Http11Processor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
retrieving revision 1.56
retrieving revision 1.57
diff -u -r1.56 -r1.57
--- Http11Processor.java 16 Jan 2003 22:29:51 - 1.56
+++ Http11Processor.java 20 Jan 2003 23:47:05 - 1.57
@@ -577,6 +577,7 @@
while (started !error keepAlive) {
try {
+request.setStartTime(System.currentTimeMillis());
if( !disableUploadTimeout keptAlive soTimeout 0 ) {
socket.setSoTimeout(soTimeout);
}
1.20 +9 -1
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java
Index: Http11Protocol.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- Http11Protocol.java 16 Jan 2003 22:29:51 - 1.19
+++ Http11Protocol.java 20 Jan 2003 23:47:05 - 1.20
@@ -349,6 +349,7 @@
static class Http11ConnectionHandler implements TcpConnectionHandler {
Http11Protocol proto;
static int count=0;
+RequestGroupInfo global=null;
Http11ConnectionHandler( Http11Protocol proto ) {
this.proto=proto;
@@ -381,7 +382,14 @@
if( proto.getDomain() != null ) {
try {
-RequestProcessor rp=new
RequestProcessor(processor.getRequest());
+if( global==null ) {
+global=new RequestGroupInfo();
+Registry.getRegistry().registerComponent( global,
+proto.getDomain(), GlobalRequestProcessor,
+type=GlobalRequestProcessor,name=http);
+}
+RequestInfo rp=processor.getRequest().getRequestProcessor();
+rp.setGlobalProcessor(global);
Registry.getRegistry().registerComponent( rp,
proto.getDomain(), RequestProcessor,
type=RequestProcessor,name=HttpRequest + count++ );
--
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]
these were all JSTL tags. Back when I ran the tests, I posted some of the results. I did tests that were synthetic, ie out 100 JSTL out tags in one page. Others were based on an actual page layout with lots of markup logic that use jstl c:choose in conjunction with jslt xml tags. the tests were with tomcat 4.1's jasper2 and with 4.0x jasper1. obviously the tag pooling was only with jasper2. I didn't have time to test tomcat 3.x tag pooling. peter lin Costin Manolache [EMAIL PROTECTED] wrote:Peter Lin wrote: I haven't read all the posts on this discussion, but here's some facts from personal observations. for pages with only a few tags, ie less than 30, tag pooling doesn't help. On the otherhand, if your page has 100+ tags, it improves performance. Some of the pages I benchmarked with had about 135 tags. In those situations, I saw a 20-50% improvement. I would argue that sites that don't have a lot of load should simply turn off tag pooling. Site that use tags extensively and get 1millions page views a day, will gain significantly from tag pooling. Is this based on the current tag pool implementation in jasper2 ? Because it is pretty clear that the tag pool has few problems. I would say the nature of the tags will also have a big impact. If your tag is very simple - you'll probably get some small benefits under load ( 20..30% ?). If the tag uses internal data structures, buffers, etc - it's very likely you'll see more ( since creating each tag instance will also create the additional hashtable, StringBuffers, etc ). I would bet that with complex tags that are specifically written to take advantage of the recycling you would see at least 2x better performance ( with a good sync-free and large enough tag pool ). If your tag is using any buffers or complex/expensive data structures that can be recycled - you'll save a lot. I don't think the number of tags in a page is too important - even if you have 1 complex tag - with 100 concurent users - you should see a difference. 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. Costin - Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java JkMain.java
costin 2003/01/20 15:48:40
Modified:jk/java/org/apache/jk/common HandlerRequest.java
jk/java/org/apache/jk/server JkCoyoteHandler.java
JkMain.java
Log:
Few updates for RequestInfo.
Revision ChangesPath
1.22 +13 -2
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java
Index: HandlerRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- HandlerRequest.java 16 Jan 2003 22:13:37 - 1.21
+++ HandlerRequest.java 20 Jan 2003 23:48:40 - 1.22
@@ -411,22 +411,33 @@
}
static int count=0;
+RequestGroupInfo global=null;
private int decodeRequest( Msg msg, MsgContext ep, MessageBytes tmpMB )
throws IOException
{
// FORWARD_REQUEST handler
Request req=(Request)ep.getRequest();
+req.setStartTime(System.currentTimeMillis());
if( req==null ) {
req=new Request();
Response res=new Response();
req.setResponse(res);
ep.setRequest( req );
-RequestProcessor rp=new RequestProcessor(req);
if( this.getDomain() != null ) {
try {
+if( global==null ) {
+global=new RequestGroupInfo();
+Registry.getRegistry().registerComponent( global,
+getDomain(), GlobalRequestProcessor,
+type=GlobalRequestProcessor,name=jk);
+}
+
+RequestInfo rp=req.getRequestProcessor();
+rp.setGlobalProcessor(global);
Registry.getRegistry().registerComponent( rp,
-getDomain(), RequestProcessor, name=Request +
count++ );
+getDomain(), RequestProcessor,
+type=RequestProcessor,name=JkRequest + count++ );
} catch( Exception ex ) {
log.warn(Error registering request);
}
1.35 +1 -1
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java
Index: JkCoyoteHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- JkCoyoteHandler.java 20 Jan 2003 19:20:32 - 1.34
+++ JkCoyoteHandler.java 20 Jan 2003 23:48:40 - 1.35
@@ -456,7 +456,7 @@
{
// XXX Can we have multiple JkMain ?
Registry.getRegistry().registerComponent(jkMain, name.getDomain(),
-JkMain, name=JkMain);
+JkMain, type=JkHandler,name=JkMain);
return super.preRegister(server, name);
}
}
1.34 +4 -1
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java
Index: JkMain.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- JkMain.java 16 Jan 2003 22:17:37 - 1.33
+++ JkMain.java 20 Jan 2003 23:48:40 - 1.34
@@ -513,6 +513,9 @@
String fullName=name;
String localName=;
String propName=;
+// ignore
+if( name.startsWith(key.)) return;
+
int dot=name.indexOf(.);
int lastDot=name.lastIndexOf(.);
if( dot 0 ) {
@@ -564,7 +567,7 @@
}
if( this.domain != null ) {
try {
-Registry.getRegistry().registerComponent(handler, this.domain,
JkHandler,
+Registry.getRegistry().registerComponent(handler, this.domain,
classN,
type=JkHandler,name= + fullName);
} catch (Exception e) {
log.error( Error registering + fullName, e );
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk build.xml
costin 2003/01/20 15:57:58
Modified:jk build.xml
Log:
Move the paths higher, so jar target can be called directly.
Exclude ajp connector for tomcat5.
Revision ChangesPath
1.63 +42 -33jakarta-tomcat-connectors/jk/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/build.xml,v
retrieving revision 1.62
retrieving revision 1.63
diff -u -r1.62 -r1.63
--- build.xml 16 Jan 2003 22:41:37 - 1.62
+++ build.xml 20 Jan 2003 23:57:58 - 1.63
@@ -33,12 +33,46 @@
location=../../jakarta-tomcat-catalina/build /
property name=coyote.home
location=../coyote/build /
+property name=tomcat-coyote.jar
location=${coyote.home}/lib/tomcat-coyote.jar /
property name=commons-logging.jar location=../lib/commons-logging.jar /
property name=tomcat-util.jar location=../util/build/lib/tomcat-util.jar /
-property name=jmx.jar location=../lib/mx4j.jar /
+property name=commons-modeler.jar
location=../../jakarta-commons/modeler/dist/commons-modeler.jar /
-!-- Detection and reports --
+property name=jmx.jar location=../lib/mx4j.jar /
+
+!-- Fix build via ECLIPSE which didn't export ant's jars --
+path id=xml-apis.classpath
+pathelement path=${jaxp.home}/jaxp.jar/
+pathelement path=${jaxp.home}/crimson.jar/
+pathelement path=${xerces2.home}/xmlParserAPIs.jar/
+pathelement path=${xml-parser-apis.jar}/
+/path
+
+path id=build-main.classpath
+fileset dir=../lib includes=*.jar /
+pathelement location=../util/build/classes/
+pathelement location=${tomcat5.home}/server/lib/catalina.jar/
+pathelement location=${tomcat5.home}/common/lib/servlet-api.jar/
+pathelement location=${tomcat41.home}/server/lib/catalina.jar/
+pathelement location=${tomcat40.home}/server/lib/catalina.jar/
+pathelement location=${tomcat33.home}/lib/common/tomcat_core.jar/
+pathelement location=${tomcat33.home}/lib/common/core_util.jar/
+pathelement location=${tomcat-util.jar} /
+pathelement location=${commons-logging.jar}/
+pathelement location=${commons-modeler.jar}/
+pathelement location=${jmx.jar}/
+pathelement location=${tomcat33.home}/lib/container/tomcat_modules.jar/
+!-- this is needed - otherwise tomcat33 connector will not compile.
+Just change tomcat33.home in build.properties to point
+to nowhere, and tomcat_util will no longer be visible, nor
+3.3 classes. --
+pathelement
+ location=${tomcat33.home}/lib/container/tomcat_util.jar/
+pathelement location=${tomcat-coyote.jar}/
+/path
+
+ !-- Detection and reports --
target name=report
echo message=Tomcat33: ${tomcat33.detect} ${tomcat33.home} /
@@ -49,6 +83,7 @@
echo message=Apache2: ${apache2.detect} ${apache2.home} /
echo message=iPlanet: ${iplanet.detect} ${iplanet.home} /
echo message=IIS: ${iis.detect} ${iis.home} /
+echo message=jmx: ${jmx.jar} ${jmx.detect} ${commons-modeler.jar}
${modeler.detect} /
/target
target name=detect
@@ -79,6 +114,8 @@
file=${jmx.jar} /
available property=jdk14.detect
classname=java.nio.MappedByteBuffer /
+available property=modeler.detect
+ file=${commons-modeler.jar} /
!-- Check if we can find the XSLTProcessor class in the classpath --
available
property=avail.xalan
@@ -102,9 +139,9 @@
!-- util and coyote must be build first --
copy tofile=${jk.build}/lib/tomcat-coyote.jar
- file=../coyote/build/lib/tomcat-coyote.jar /
+ file=${tomcat-coyote.jar} /
- !-- Fix build via ECLIPSE which didn't export ant's jars --
+!-- Fix build via ECLIPSE which didn't export ant's jars --
path id=xml-apis.classpath
pathelement path=${jaxp.home}/jaxp.jar/
pathelement path=${jaxp.home}/crimson.jar/
@@ -112,34 +149,6 @@
pathelement path=${xml-parser-apis.jar}/
/path
-path id=build-main.classpath
-fileset dir=../lib includes=*.jar /
-pathelement location=../util/build/classes/
-pathelement location=${tomcat5.home}/server/lib/catalina.jar/
-pathelement location=${tomcat5.home}/common/lib/servlet-api.jar/
-pathelement location=${tomcat41.home}/server/lib/catalina.jar/
-pathelement
RE: DO NOT REPLY [Bug 16258] - getContext does not work on defaultcontext
BTW. I'm not asking you to test my fixes... I'm using that fix myself. Martin -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 20 January 2003 15:11 To: Tomcat Developers List Subject: Re: DO NOT REPLY [Bug 16258] - getContext does not work on defaultcontext Martin Algesten wrote: Believe me, when your different web apps are relying on actually being able to use this part of the API to communicate with each other, then this is a blocker... Martin (who still doesn't understand why this isn't an issue worth fixing) Because your fix breaks more things, and makes a Watchdog test fail. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tag Pooling ( was: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
Taking Glenn's post out of thread: Glenn Nielsen wrote: Per JSP Page (current) -- The current tag pool manages one or more pools of tags on a per JSP page basis. With a synchronized method call for each get/reuse pair for a TagHandler used in the page. That page could have as many current requests as Processor threads. The TagHandlerPool's for the JSP page could grow to the point where they have as many TagHandler elements as needed to handle the maximum number of concurrent requests (Threads). If we're going to keep the current around - we should at least increase the limit. Per JSP Page Thread Local - Switching this to ThreadLocal would remove all need for synchronized access for the TagHandlerPool get/reuse but significantly increase the memory usage. You end up with a TagHandlerPool for each thread, for each JSP page. Both of these could require enoubh memory to hold the number of TagHandler classes = Number of Threads * Number of JSP pages * Number of unique TagHandlers needed per JSP A mechanism to clean up unused pools could help reduce this ( similar with ThreadPool ). ( maybe combined with some JMX to give insight into how many pools and tags are in used - quite usefull ). This is the classical memory versus time - a choice that users should make for themself, depending on the application they run. A production site with a lot of memory and very high traffic on few pages may choose the speed. There are two other options based on managing a global tag pool rather than a per JSP page tag pool. If you have many JSP pages with custom tags there will be common tags/attributes used across all of them. Why not be able to reuse these TagHandler's across all the JSP pages instead of on a per JSP page basis. This could significantly reduce the number of instances of TagHandler's which have to be pooled, and the memory the consume. Consider the JSTL c:if tag and how many times it could get used across 20 different JSP pages. If this is still thread local - I'm +0 ( i.e. I won't implement it, but I think it's a great idea ). That would make it ( threads * maxTag ), where maxTag is the maximum number of one tag in any page. It shouldn't be hard - you'll need to pass the context and keep the ThreadLocal in the context. Of course - keep in mind that you need one pool for each tag+attribute_set ( another wise requirement..) Global -- TagHandlerPool's which are global and pool all unique TagHandler classes for all JSP pages. In this case you would require one synchronized call at the start of the JSP page to populate its local pool with reusable TagHandler's from the global pool. Then on JSP page exit return the TagHandler's from its local pool to the global. Requires two synchronized method calls per JSP page execution, but mimimizes the memory footprint of pooled tags. If by global you mean cross-context - I don't think it would work ( versioning, security, etc ). Global Thread Local --- TagHandlerPool's which are global within a thread and pool all unique TagHandler classes for all JSP pages which execute within the thread. No synchronized methods would be required for this design. This would have a smaller memory footprint than the Per JSP Page (current) and Per Jsp Page Thread Local tag pools, but use more memory than the Global tag pool. Again - if by global you mean per context, +1. Per server is too dangerous ( a thread can hold on the reference for a tag and access it when it is in used in a different context ). Of the four designs above I think the Global Thread Local design may be the best. It removes the need for synchronized get/reuse and has a smaller memory footprint than the Per JSP Page tag pool design. +1 for Context Thread Local ( eventually combined with some expiration strategy ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPool.java ThreadPoolMX.java
costin 2003/01/20 16:17:11
Modified:util/java/org/apache/tomcat/util/threads ThreadPool.java
ThreadPoolMX.java
Log:
Remove the dependency on JMX.
ThreadPoolMX will be wrapped in a model mbean - but it doesn't need to depend
on JMX.
Revision ChangesPath
1.10 +0 -5
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java
Index: ThreadPool.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- ThreadPool.java 14 Jan 2003 18:47:39 - 1.9
+++ ThreadPool.java 21 Jan 2003 00:17:11 - 1.10
@@ -171,11 +171,6 @@
return new ThreadPool();
}
-public void register( String domain, String name ) {
-// nothing in the base class - it'll register in jmx mode
-// We could use the name to create a ThreadGroup and name threads
-}
-
public synchronized void start() {
stopThePool=false;
currentThreadCount = 0;
1.4 +0 -13
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPoolMX.java
Index: ThreadPoolMX.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPoolMX.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ThreadPoolMX.java 14 Jan 2003 18:47:39 - 1.3
+++ ThreadPoolMX.java 21 Jan 2003 00:17:11 - 1.4
@@ -63,7 +63,6 @@
import java.util.*;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
-import org.apache.commons.modeler.Registry;
/**
* Manageable thread pool
@@ -72,24 +71,12 @@
*/
public class ThreadPoolMX extends ThreadPool {
static Log log = LogFactory.getLog(ThreadPoolMX.class);
-Registry reg;
protected String domain;
protected String name;
public ThreadPoolMX() {
super();
-}
-
-public void register(String domain, String name) {
-this.name=name;
-this.domain=domain;
-reg=Registry.getRegistry();
-try {
-reg.registerComponent(this, domain, ThreadPool, name);
-} catch( Exception ex ) {
-log.error( Error registering thread pool, ex );
-}
}
public synchronized void start() {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.xml
costin 2003/01/20 16:18:26
Modified:.build.xml
Log:
Few changes in the fast build targets.
Revision ChangesPath
1.65 +7 -4 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.64
retrieving revision 1.65
diff -u -r1.64 -r1.65
--- build.xml 17 Jan 2003 17:05:34 - 1.64
+++ build.xml 21 Jan 2003 00:18:26 - 1.65
@@ -50,7 +50,7 @@
property name=tomcat.release value=${basedir}/release/
property name=webapps.buildvalue=${catalina.home}/webapps/build/
property name=webapps.dist value=${catalina.home}/webapps/dist/
-
+
!-- Some compilers will disable debugging if true. And it doesn't do anything
in most cases --
property name=compile.optimize value=false/
@@ -151,10 +151,11 @@
target name=build-tomcatjk unless=tomcatjk.build.notrequired
echo== Building: tomcat-jk /echo
-ant dir=${jtc.home}/jk target=build-main
+ant dir=${jtc.home}/jk target=jkjava
property name=tomcat5.home value=${catalina.build}/
property name=commons-logging.jar value=${commons-logging.jar}/
property name=jmx.jar value=${jmx.jar}/
+ property name=tomcat-coyote.jar
value=${tomcat.build}/server/lib/tomcat-coyote.jar /
property name=jk.build value=${tomcat.build}/
@@ -172,9 +173,10 @@
depends=init
echo== Building: tomcat-coyote /echo
-ant dir=${jtc.home}/coyote target=compile.tomcat5
+ant dir=${jtc.home}/coyote target=jar.tomcat5
property name=catalina.home value=${tomcat.build}/
property name=tomcat5.detect value=true/
+ property name=tomcat-coyote.jar
value=${tomcat.build}/server/lib/tomcat-coyote.jar /
property name=servlet.jar
value=${tomcat.build}/common/lib/servlet-api.jar/
/ant
/target
@@ -187,6 +189,7 @@
ant dir=${jtc.home}/http11 target=compile
property name=build.home value=${tomcat.build}/
property name=tomcat-http11.jar
value=${tomcat.build}/server/lib/tomcat-http11.jar/
+ property name=tomcat-coyote.jar
value=${tomcat.build}/server/lib/tomcat-coyote.jar /
property name=commons-logging.jar value=${commons-logging.jar}/
/ant
/target
@@ -251,7 +254,7 @@
target name=build-commons-modeler unless=commons-modeler.build.notrequired
echo== Building: commons-modeler /echo
-ant dir=${cvs.base}/jakarta-commons/modeler target=compile-only
+ant dir=${cvs.base}/jakarta-commons/modeler target=jar
property name=commons-logging.jar
location=${tomcat.build}/server/lib/commons-logging.jar /
property name=commons-modeler.jar
location=${tomcat.build}/server/lib/commons-modeler.jar /
property name=build.home value=${tomcat.build} /
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.xml
costin 2003/01/20 16:26:09
Modified:.build.xml
Log:
Added back some of the changes - precompile jsps in admin, generate .ser
form for mbean descriptors, speed up compilation.
Revision ChangesPath
1.66 +89 -1 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.65
retrieving revision 1.66
diff -u -r1.65 -r1.66
--- build.xml 21 Jan 2003 00:18:26 - 1.65
+++ build.xml 21 Jan 2003 00:26:09 - 1.66
@@ -153,6 +153,7 @@
ant dir=${jtc.home}/jk target=jkjava
property name=tomcat5.home value=${catalina.build}/
+ property name=tomcat5.detect value=true/
property name=commons-logging.jar value=${commons-logging.jar}/
property name=jmx.jar value=${jmx.jar}/
property name=tomcat-coyote.jar
value=${tomcat.build}/server/lib/tomcat-coyote.jar /
@@ -175,6 +176,7 @@
ant dir=${jtc.home}/coyote target=jar.tomcat5
property name=catalina.home value=${tomcat.build}/
+ property name=build.home value=${tomcat.build}/
property name=tomcat5.detect value=true/
property name=tomcat-coyote.jar
value=${tomcat.build}/server/lib/tomcat-coyote.jar /
property name=servlet.jar
value=${tomcat.build}/common/lib/servlet-api.jar/
@@ -186,7 +188,7 @@
depends=init
echo== Building: tomcat-http11 /echo
-ant dir=${jtc.home}/http11 target=compile
+ant dir=${jtc.home}/http11 target=compile-only
property name=build.home value=${tomcat.build}/
property name=tomcat-http11.jar
value=${tomcat.build}/server/lib/tomcat-http11.jar/
property name=tomcat-coyote.jar
value=${tomcat.build}/server/lib/tomcat-coyote.jar /
@@ -205,6 +207,69 @@
touch file=${tomcat.build}/server/webapps/admin/WEB-INF/web.xml /
/target
+ target name=build-admin-precompile
+ depends=init description=Builds the admin webapp
+echo== Building: admin to ${tomcat.build}/server/webapps /echo
+ant dir=${catalina.home}/webapps/admin target=build-main
+ property name=flags.hide value=true /
+ property name=webapps.build value=${tomcat.build}/server/webapps/
+/ant
+
+!-- JSPC --
+property name=admin.base location=${tomcat.build}/server/webapps/admin /
+
+mkdir dir=${admin.base}/WEB-INF/src/admin /
+
+taskdef classname=org.apache.jasper.JspC name=jasper2
+ classpath id=jspc.classpath
+pathelement location=${java.home}/../lib/tools.jar/
+fileset dir=${tomcat.build}/server/lib
+ include name=*.jar/
+/fileset
+fileset dir=${tomcat.build}/common/lib
+ include name=*.jar/
+/fileset
+pathelement location=${build.dir}/classes/
+ /classpath
+/taskdef
+
+jasper2 verbose=0
+ package=admin
+ compile=false
+ validateXml=false
+ uriroot=${admin.base}
+ webXmlFragment=${admin.base}/WEB-INF/generated_web.xml
+ outputDir=${admin.base}/WEB-INF/src/admin /
+
+loadfile property=generated_web.xml
+ srcFile=${admin.base}/WEB-INF/generated_web.xml /
+
+replace file=${admin.base}/WEB-INF/web.xml
+ token=lt;!--GENERATED_JSPS--gt; value=${generated_web.xml} /
+
+javac destdir=${admin.base}/WEB-INF/classes
+ optimize=off
+ debug=on
+ srcdir=${admin.base}/WEB-INF/src
+ classpath
+pathelement location=${java.home}/../lib/tools.jar/
+fileset dir=${tomcat.build}/server/lib
+ include name=*.jar/
+/fileset
+fileset dir=${admin.base}/WEB-INF/lib
+ include name=*.jar/
+/fileset
+fileset dir=${tomcat.build}/common/lib
+ include name=*.jar/
+/fileset
+pathelement location=${tomcat.build}/classes/
+ /classpath
+ include name=admin/** /
+/javac
+
+
+ /target
+
target name=build depends=init
description=Builds all components
@@ -283,6 +348,12 @@
echoTarget: Catalina - Deploy .../echo
ant dir=${catalina.home} target=deploy/
+!--
+ant dir=${catalina.home} target=deploy-catalina/
+antcall target=build-tomcat-coyote/
+antcall target=build-tomcat-jk/
+antcall target=build-tomcat-http11/
+ --
copy todir=${tomcat.build}
fileset dir=${catalina.home}/build/
/copy
@@ -993,6 +1064,9 @@
cvs cvsroot=${cvsroot} quiet=true
command=checkout -P jakarta-servletapi-5
dest=../
+cvs cvsroot=${cvsroot} quiet=true
+ command=checkout -P jakarta-commons
+ dest=../
/target
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 c:if and c:forEach 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 athttp://TheJSPBook.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core NamingContextListener.java
costin 2003/01/20 16:38:27
Modified:catalina/src/share/org/apache/catalina/core
NamingContextListener.java
Log:
Remove unused imports, convert to c-l.
Revision ChangesPath
1.2 +18 -19
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/NamingContextListener.java
Index: NamingContextListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/NamingContextListener.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- NamingContextListener.java18 Jul 2002 16:48:06 - 1.1
+++ NamingContextListener.java21 Jan 2003 00:38:27 - 1.2
@@ -67,24 +67,13 @@
import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
-import java.io.IOException;
-import java.util.ArrayList;
-import java.util.HashMap;
-import java.net.URL;
-import java.util.Iterator;
-import java.util.TreeMap;
import java.util.Hashtable;
-import java.util.Stack;
import java.util.Enumeration;
import java.util.StringTokenizer;
import javax.naming.NamingException;
-import javax.naming.InitialContext;
import javax.naming.Reference;
import javax.naming.StringRefAddr;
-import javax.naming.NamingEnumeration;
-import javax.naming.Binding;
import javax.naming.StringRefAddr;
-import javax.naming.directory.DirContext;
import org.apache.naming.NamingContext;
import org.apache.naming.ContextBindings;
import org.apache.naming.ContextAccessController;
@@ -99,7 +88,6 @@
import org.apache.catalina.Context;
import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
-import org.apache.catalina.LifecycleException;
import org.apache.catalina.LifecycleListener;
import org.apache.catalina.Logger;
import org.apache.catalina.Server;
@@ -112,6 +100,9 @@
import org.apache.catalina.deploy.ResourceParams;
import org.apache.catalina.util.StringManager;
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
+
/**
* Helper class used to initialize and populate the JNDI context associated
@@ -124,6 +115,8 @@
public class NamingContextListener
implements LifecycleListener, ContainerListener, PropertyChangeListener {
+private static Log log = LogFactory.getLog(NamingContextListener.class);
+
// --- Constructors
@@ -132,6 +125,8 @@
* Create a new naming context listener.
*/
public NamingContextListener() {
+if( log.isDebugEnabled() )
+log.debug( new NamingContextListener);
}
@@ -236,7 +231,8 @@
public void setName(String name) {
this.name = name;
-
+if( log.isDebugEnabled() )
+log.debug( setName + name);
}
@@ -283,6 +279,9 @@
}
ContextAccessController.setSecurityToken(getName(), container);
ContextBindings.bindContext(container, namingContext, container);
+if( log.isDebugEnabled() ) {
+log.debug(Bound + container );
+}
// Setting the context in read/write mode
ContextAccessController.setWritable(getName(), container);
@@ -699,8 +698,8 @@
int i;
-if (debug = 1)
-log(Creating JNDI naming context);
+if (log.isDebugEnabled())
+log.debug(Creating JNDI naming context);
if (namingResources == null) {
namingResources = new NamingResources();
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves ValveBase.java
costin 2003/01/20 16:42:42
Modified:catalina/src/share/org/apache/catalina/valves ValveBase.java
Log:
Let the mbean know its name.
Revision ChangesPath
1.2 +38 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ValveBase.java
Index: ValveBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ValveBase.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ValveBase.java18 Jul 2002 16:47:42 - 1.1
+++ ValveBase.java21 Jan 2003 00:42:42 - 1.2
@@ -67,6 +67,10 @@
import java.io.IOException;
import javax.servlet.ServletException;
+import javax.management.ObjectName;
+import javax.management.MBeanRegistration;
+import javax.management.MBeanServer;
+
import org.apache.catalina.Contained;
import org.apache.catalina.Container;
import org.apache.catalina.Request;
@@ -88,7 +92,7 @@
*/
public abstract class ValveBase
-implements Contained, Valve {
+implements Contained, Valve, MBeanRegistration {
//-- Instance Variables
@@ -199,5 +203,34 @@
ValveContext context)
throws IOException, ServletException;
+// JMX and Registration
+protected String domain;
+protected ObjectName oname;
+protected MBeanServer mserver;
+
+public ObjectName getObjectName() {
+return oname;
+}
+
+public String getDomain() {
+return domain;
+}
+
+public ObjectName preRegister(MBeanServer server,
+ ObjectName name) throws Exception {
+oname=name;
+mserver=server;
+domain=name.getDomain();
+return name;
+}
+
+public void postRegister(Boolean registrationDone) {
+}
+
+public void preDeregister() throws Exception {
+}
+
+public void postDeregister() {
+}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session ManagerBase.java
costin 2003/01/20 16:43:18
Modified:catalina/src/share/org/apache/catalina/session
ManagerBase.java
Log:
Let the manager know its name.
Revision ChangesPath
1.13 +35 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java
Index: ManagerBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- ManagerBase.java 9 Jan 2003 21:15:46 - 1.12
+++ ManagerBase.java 21 Jan 2003 00:43:18 - 1.13
@@ -78,6 +78,10 @@
import java.util.Iterator;
import java.util.Random;
+import javax.management.MBeanRegistration;
+import javax.management.ObjectName;
+import javax.management.MBeanServer;
+
import org.apache.catalina.Container;
import org.apache.catalina.DefaultContext;
import org.apache.catalina.Engine;
@@ -97,7 +101,7 @@
* @version $Revision$ $Date$
*/
-public abstract class ManagerBase implements Manager {
+public abstract class ManagerBase implements Manager, MBeanRegistration {
protected Log log = LogFactory.getLog(ManagerBase.class);
// - Instance Variables
@@ -980,5 +984,34 @@
return new Date(s.getLastAccessedTime()).toString();
}
+// JMX and Registration
+protected String domain;
+protected ObjectName oname;
+protected MBeanServer mserver;
+
+public ObjectName getObjectName() {
+return oname;
+}
+
+public String getDomain() {
+return domain;
+}
+
+public ObjectName preRegister(MBeanServer server,
+ ObjectName name) throws Exception {
+oname=name;
+mserver=server;
+domain=name.getDomain();
+return name;
+}
+
+public void postRegister(Boolean registrationDone) {
+}
+
+public void preDeregister() throws Exception {
+}
+
+public void postDeregister() {
+}
}
--
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]
Hans Bergsten wrote: 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 c:if and c:forEach 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. +1 - open coding is far better ( for performance ). Is the API/model for portable open coding defined and stable ? That would be by far the biggest improvement in JSP performance. But for people who use regular tag handlers - I think we need to fix the tag pool, and a fixed tag pool will improve the performance significantly. And if regular tags are used, for whatever reason, recycling should be taken into account - if people care a bit about performance. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Branch j-t-c for Tomcat 5
A little late :-) ballot [ ] +1 I Support the idea of a branch, and will help maintain it. [X ] +0 I like the idea [ ] -0 I don't like the idea [ ] -1 I'm against the idea of branching /ballot -- Jeanfrancois -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16285] New: - Japser (JSPC) can't generate appropriate package structure
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16285.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16285
Japser (JSPC) can't generate appropriate package structure
Summary: Japser (JSPC) can't generate appropriate package
structure
Product: Tomcat 4
Version: 4.1.18
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Critical
Priority: Other
Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I use Ant to define the Jasper as a Ant Task to generate the Java source from
JSP files.
===
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath refid=run.classpath/
/taskdef
jasper2 verbose=0 package=eric.test.jsp uriroot=${basedir}/myserv
webXmlFragment=${basedir}/jsp/web.xml outputDir=${basedir}/jsp /
In fact, all JSP files can be generated to Java sources. The problem is that
all the packages of the generated Java source are same as eric.test.jsp.
Although the JSPs in different folder.
For example:
$WEB_ROOT/index.jsp
$WEB_ROOT/admin/index.jsp
The above two index.jsp will be generated to index_jsp.java in different
folders. But they have the same package name eric.test.jsp. As the result,
when I compiled those Java sources, it failed for Duplicate class name
Jasper seems can't add the extra package path for the extra folder in the
$WEB_ROOT.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[GUMP] [connectors] Add some missing dependencies
Index: gump.xml === RCS file: /home/cvspublic/jakarta-tomcat-connectors/gump.xml,v retrieving revision 1.11 diff -u -r1.11 gump.xml --- gump.xml11 Jan 2003 16:27:40 - 1.11 +++ gump.xml21 Jan 2003 07:22:06 - @@ -71,6 +71,8 @@ depend project=jakarta-tomcat-util/ depend project=jakarta-servletapi-5-servlet/ depend project=jakarta-tomcat-catalina / +depend project=commons-logging/ +depend project=commons-modeler/ home nested=coyote/ jar name=build/lib/tomcat-coyote.jar/ @@ -95,6 +97,7 @@ depend project=jakarta-tomcat-util/ depend project=xml-xerces/ depend project=jakarta-tomcat-coyote/ +depend project=jakarta-servletapi-5-servlet/ home nested=jk/build/ jar name=lib/jkant.jar/ -- 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
Hans Bergsten wrote: 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). Ok, thanks for clarifying this. 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. Like the last paragraph... =) Is this the way the Jasper tag pooling is implemented? As far as I have seen, yes. Sorry for asking, I should have (did actually) checked myself... Hans __ This message and its attachments have been found clean from known viruses with three different antivirus programs. __ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
