DO NOT REPLY [Bug 33266] - Context defined datasources require driver classes placed in common classloader
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33266. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33266 [EMAIL PROTECTED] changed: What|Removed |Added Priority|P2 |P5 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 09:41 --- Sure, I get it, its not a discomfort for me to place the driver in common/lib or define my own DS. But condider the following: Context reloadable=true override=true Resource name=jdbc/postgres auth=Container type=javax.sql.DataSource ... / Realm className=org.apache.catalina.realm.DataSourceRealm dataSourceName=jdbc/postgres ... localDataSource=true / /Context What I am trying to say, is that it *would be* nice that the context realm and application could share the same DS. Provided that there is a localDataSource attribute in the realm, means that it is possible to use a local datasource, which in turn renders unusable due to NoClassDefFoundError. I consider this a slight inconsistency. Still, I consider this issue as a low priority enhancement rather than a bug. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10021] - Include upgrade option in installer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=10021. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=10021 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] OS/Version||All --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 10:51 --- Any chance this could be looked at for Tomcat 5? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33351] New: - silent uninstall
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33351. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33351 Summary: silent uninstall Product: Tomcat 5 Version: Unknown Platform: PC OS/Version: Windows 2000 Status: NEW Severity: enhancement Priority: P2 Component: Native:Packaging AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] if bug 10021 is unfesable to do then at least there could be a silent uninstall option so that a batch file could be writted to effectively do bug 10021. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33339] - Shutdown script down not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=9. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=9 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 12:15 --- My post to this bug got lost somehow. The code indicates that shutdown of the JK connector is failing in the unlock accept process. This code has been there unchanged (and identical) for years in both JK and HTTP, and hasn't caused any problems. If you're not using JK, you can try disabling it. BTW, don't write statements like which seems to show there are a lot of threads waiting on an object. This doesn't make any sense, and makes the credibility of the report go down. Stick to reproduceable facts if you are not aware of implementation details. The only thread which matters here is: main prio=1 tid=0x0805bda8 nid=0x33b6 runnable [bfffc000..bfffd618] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305) - locked 0xabae0260 (a java.net.PlainSocketImpl) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158) at java.net.Socket.connect(Socket.java:452) at java.net.Socket.connect(Socket.java:402) at java.net.Socket.init(Socket.java:309) at java.net.Socket.init(Socket.java:153) at org.apache.jk.common.ChannelSocket.unLockSocket (ChannelSocket.java:460) at org.apache.jk.common.ChannelSocket.pause(ChannelSocket.java:272) - locked 0xacb1ee08 (a org.apache.jk.common.ChannelSocket) at org.apache.jk.server.JkMain.pause(JkMain.java:677) at org.apache.jk.server.JkCoyoteHandler.pause(JkCoyoteHandler.java:208) at org.apache.catalina.connector.Connector.pause(Connector.java:933) at org.apache.catalina.core.StandardService.stop (StandardService.java:491) - locked 0xabefeca8 (a [Lorg.apache.catalina.connector.Connector;) at org.apache.catalina.core.StandardServer.stop (StandardServer.java:717) at org.apache.catalina.startup.Catalina.stop(Catalina.java:586) at org.apache.catalina.startup.Catalina.start(Catalina.java:561) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:271) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:409) I tested this on Cygwin with startup.sh and shutdown.sh, with the default Tomcat configuration. Honestly, I don't see what it changes. One thing is certain: no developer will install the crappy distro you're using just for the sake of testing this. FC 3 is at least decent ... I will eventually install Tomcat on my Ubuntu. When you file a bug, if developers cannot reproduce it, you need to explain how to reproduce it. If it still fails, or there's no possibility of reproducing, then sorry, there's no other way than try to find where the problem comes from, post to tomcat-user, or use another product if you think the problem is too serious. Given your attitude, I will not miss you ;) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33351] - silent uninstall
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33351. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33351 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 12:17 --- /s has been implemented long ago (in theory). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 33339] - Shutdown script down not work
Al Sutton wrote: So let me get this right, just because you can't reproduce it on your system you're not willing to leave it open for others to check, despite the fact you haven't, as yet, told me if your using the same JDK, Linux environment, and you've not waiting for others to comment. Guess the easiest way to get round this is to move to Jetty. Bye then ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33351] - silent uninstall
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33351. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33351 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 12:20 --- It still presents a dialog box to the user asking if everything under tomcat should be removed. This dialog box should be avoided by some command line options. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33351] - silent uninstall
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33351. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33351 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 12:29 --- It's /S, and 5.5.7 works great. Please do not reopen the report. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33351] - silent uninstall
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33351. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33351 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 12:39 --- Created an attachment (id=14158) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14158action=view) Dialog box that shows on silent uninstall I am not sure what you understand by silent install. I define it as the user not being presented with any dialog boxes whatsoever. I have attached a screenshot of the dialog box that gets present when you run the uninstaller with the /S option. I am requesting that there be another option for example /CLEAN=TRUE which will avoid the dialog box. The whole point of a silent install is that you can integrate it into the installer of another package. We dont want to expose the use of Tomcat to the end user of our product because it really does not concern them. If the attached dialog box pops up to our end user they will not know what to do with it. I hope I am making myself clear. Please let me know if I am not. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33351] - silent uninstall
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33351. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33351 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 12:57 --- Ah, ok, the problem is during the uninstallation process, with this yes/no. You should have described the issue more precisely. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 tomcat.nsi
remm2005/02/02 04:01:44 Modified:.tomcat.nsi Log: - Fix silent uninstallation (bug 33351). Revision ChangesPath 1.68 +3 -1 jakarta-tomcat-5/tomcat.nsi Index: tomcat.nsi === RCS file: /home/cvs/jakarta-tomcat-5/tomcat.nsi,v retrieving revision 1.67 retrieving revision 1.68 diff -u -r1.67 -r1.68 --- tomcat.nsi22 Nov 2004 15:04:58 - 1.67 +++ tomcat.nsi2 Feb 2005 12:01:43 - 1.68 @@ -626,6 +626,8 @@ RMDir /r $INSTDIR\src RMDir $INSTDIR + IfSilent Removed 0 + ; if $INSTDIR was removed, skip these next ones IfFileExists $INSTDIR 0 Removed MessageBox MB_YESNO|MB_ICONQUESTION \ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33351] - silent uninstall
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33351. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33351 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 13:14 --- Fixed in CVS. Sorry for the trouble. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33351] - silent uninstall
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33351. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33351 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 13:22 --- I am sorry if my description was not clear. I will endevour to be more eliquent in future. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33339] - Shutdown script down not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=9. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=9 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 14:03 --- I just tested with Ubuntu Hoary and Sun JRE 1.5.0_01. Both startup.sh and shutdown.sh work as expected, and Tomcat runs great. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33356] New: - Incorrect parsing of tag attributes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33356.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33356
Summary: Incorrect parsing of tag attributes
Product: Tomcat 5
Version: 5.0.28
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Jasper
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
I get a org.apache.jasper.JasperException: with the error: The function string
must be used with a prefix when a default namespace is not specified when
trying to compile the following within a JSP page:
foo:set var=bar value=this $ is a { silly string (/
foo is our own tablib, it seems that Jasper seems to think that the string
provided to the value attribute contains some JSP/EL which it does not.
If I change the page to be:
c:set var=bar value=this $ is a { silly string (/
Then I do not get this error. However I need to use my own taglib.
In the foo.tld file, the value attribute of set has rtexprvalue=true.
If I set this to false then the problem goes away. However I noticed that c.tld
in standard.jar also has rtexprvalue=true for the value attribute of set.
Why the difference in behaviour ? We also wish to have rtexprvalue=true.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33356] - Incorrect parsing of tag attributes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33356. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33356 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33358] New: - jasper2 bug because classloader-problems
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33358.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33358
Summary: jasper2 bug because classloader-problems
Product: Tomcat 5
Version: 5.0.30
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Jasper
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
hi there,
i think the patch of bugreport
http://issues.apache.org/bugzilla/show_bug.cgi?id=32330 is not correct.
jspc get an error if i compile jsp's with struts-el tags like
html-el:option.
following stacktrace is coming:
[jasper2] SCHWERWIEGEND: MessageResourcesFactory.createFactory
[jasper2] java.lang.ClassNotFoundException:
org.apache.struts.util.PropertyMessageResourcesFactory
[jasper2] at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
[jasper2] at java.security.AccessController.doPrivileged(Native Method)
[jasper2] at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
[jasper2] at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
[jasper2] at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
[jasper2] at
org.apache.struts.util.RequestUtils.applicationClass(RequestUtils.java:117)
[jasper2] at
org.apache.struts.util.MessageResourcesFactory.createFactory(MessageResourcesFactory.java:148)
[jasper2] at
org.apache.struts.util.MessageResources.getMessageResources(MessageResources.java:493)
[jasper2] at
org.apache.struts.taglib.html.BaseHandlerTag.clinit(BaseHandlerTag.java:64)
[jasper2] at java.lang.Class.forName0(Native Method)
[jasper2] at java.lang.Class.forName(Class.java:141)
[jasper2] at
org.apache.strutsel.taglib.html.ELLinkTagBeanInfo.class$(ELLinkTagBeanInfo.java:46)
[jasper2] at
org.apache.strutsel.taglib.html.ELLinkTagBeanInfo.getPropertyDescriptors(ELLinkTagBeanInfo.java:46)
[jasper2] at
java.beans.Introspector.getTargetPropertyInfo(Introspector.java:459)
[jasper2] at java.beans.Introspector.getBeanInfo(Introspector.java:372)
[jasper2] at java.beans.Introspector.getBeanInfo(Introspector.java:144)
[jasper2] at
org.apache.jasper.compiler.Generator$TagHandlerInfo.init(Generator.java:3684)
[jasper2] at
org.apache.jasper.compiler.Generator$GenerateVisitor.getTagHandlerInfo(Generator.java:2102)
[jasper2] at
org.apache.jasper.compiler.Generator$GenerateVisitor.visit(Generator.java:1583)
[jasper2] at
org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1441)
[jasper2] at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2163)
[jasper2] at
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2213)
[jasper2] at
org.apache.jasper.compiler.Generator$GenerateVisitor.visit(Generator.java:1689)
[jasper2] at
org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1441)
[jasper2] at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2163)
[jasper2] at
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2213)
[jasper2] at
org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2219)
[jasper2] at org.apache.jasper.compiler.Node$Root.accept(Node.java:456)
[jasper2] at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2163)
[jasper2] at
org.apache.jasper.compiler.Generator.generate(Generator.java:3272)
[jasper2] at
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:244)
[jasper2] at
org.apache.jasper.compiler.Compiler.compile(Compiler.java:470)
[jasper2] at org.apache.jasper.JspC.processFile(JspC.java:805)
[jasper2] at org.apache.jasper.JspC.execute(JspC.java:938)
...
in the source code of Jspc.java the finaly-block in the processFile method for
resetting the classloader is wrong there. because
it resets the classloader after the first file was processed. and any other
jsp's, that uses
the struts-el-tags (for example html-el:option...) can not be compiled. i
think the finaly-block belongs
to the end of the execute-method with following change:
} finally {
if(originalClassLoader != null) {
Thread.currentThread().setContextClassLoader(originalClassLoader);
loader = null; // set to null!!
}
}
where originalClassLoader is declared as instance variable as:
private ClassLoader originalClassLoader = null;
what's your opinion?
marco
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
Re: DO NOT REPLY [Bug 33339] - Shutdown script down not work
A few points; 1) This bug is also on SuSE Enterprise Server 8 as welll as FC2. 2) The sentance which seems to show there are a lot of threads waiting on an object does make sense if you've delt with threaded programming and strack traces before. All of the threads with Object.wait() listed at the top are held in the wait() method of an object (i.e. the thread is waiting on an object). This is a term which comes from Suns own JavaDoc for the Object class and can be seen at http://java.sun.com/j2se/1.3/docs/api/java/lang/Object.html. Although a number of the threads are daemon threads, and thus don't need to exit before the JVM exits, it's usually safe programming to allow the thread to exit gracefully to ensure the correct release of any resources. 3) Cygwin is definatley NOT a good platform for testing Linux bugs on. Cygwin is a layer that converts Unix calls into their Windows equivalents, but it does not have Linux underneath and therefore does not represent the threading, networking, and scheduling characteristics of a Linux machine. 4) Do you want to tell the Fedora guys that the Tomcat developers official view of Fedora Core 2 is that its' a crappy distro? 5) Do you expect me to re-install my system just to get Tomcat working?, It's easier to replace Tomcat with Jetty than it would be to resintall my machine with one of the distros that you don't consider crappy (mind you I would have thought Novell would be interested to hear it if you want to call SLES 8 crappy as well). Now I'd like to help resolve this, but at the moment all I'm seeing is a wall of not interesting, can't be bothered, lets' mark it as invalid because I can't reproduce on my own personal setup. Which kinda worries me about how many other bugs have been treated in this manner and the bug reporters just gave up hope of getting things fixed. Regards, Al. [EMAIL PROTECTED] wrote on 02.02.2005, 12:15:55: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=9 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 12:15 --- My post to this bug got lost somehow. The code indicates that shutdown of the JK connector is failing in the unlock accept process. This code has been there unchanged (and identical) for years in both JK and HTTP, and hasn't caused any problems. If you're not using JK, you can try disabling it. BTW, don't write statements like which seems to show there are a lot of threads waiting on an object. This doesn't make any sense, and makes the credibility of the report go down. Stick to reproduceable facts if you are not aware of implementation details. The only thread which matters here is: main prio=1 tid=0x0805bda8 nid=0x33b6 runnable [bfffc000..bfffd618] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305) - locked (a java.net.PlainSocketImpl) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158) at java.net.Socket.connect(Socket.java:452) at java.net.Socket.connect(Socket.java:402) at java.net.Socket.(Socket.java:309) at java.net.Socket.(Socket.java:153) at org.apache.jk.common.ChannelSocket.unLockSocket (ChannelSocket.java:460) at org.apache.jk.common.ChannelSocket.pause(ChannelSocket.java:272) - locked (a org.apache.jk.common.ChannelSocket) at org.apache.jk.server.JkMain.pause(JkMain.java:677) at org.apache.jk.server.JkCoyoteHandler.pause(JkCoyoteHandler.java:208) at org.apache.catalina.connector.Connector.pause(Connector.java:933) at org.apache.catalina.core.StandardService.stop (StandardService.java:491) - locked (a [Lorg.apache.catalina.connector.Connector;) at org.apache.catalina.core.StandardServer.stop (StandardServer.java:717) at org.apache.catalina.startup.Catalina.stop(Catalina.java:586) at org.apache.catalina.startup.Catalina.start(Catalina.java:561) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:271) at
Re: Re: DO NOT REPLY [Bug 33339] - Shutdown script down not work
Nice to know you care about quality so much. Remy Maucherat [EMAIL PROTECTED] wrote on 02.02.2005, 12:17:55: Al Sutton wrote: So let me get this right, just because you can't reproduce it on your system you're not willing to leave it open for others to check, despite the fact you haven't, as yet, told me if your using the same JDK, Linux environment, and you've not waiting for others to comment. Guess the easiest way to get round this is to move to Jetty. Bye then ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 33339] - Shutdown script down not work
[EMAIL PROTECTED] wrote: Nice to know you care about quality so much. Anytime :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33339] - Shutdown script down not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=9. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=9 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 16:12 --- Disabling the JK connector has no effect on either FC2 or SLES8, the shutdown script does not work on either. Is there not a state saying Unreproducable on our systems, as the bug certainly isn't resolved, and I can assure you it is valid. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33357] - DataSourceRealm leaks connections
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33357. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33357 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 16:17 --- Didn't you mention the problem earlier in another report ? I remember something like this, but didn't see anything obvious in the code (which I'm not too familiar with). Yes, refactoring and removing the need for using two connections would be useful. Be careful not to introduce new bugs, though ;) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33339] - Shutdown script down not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=9. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=9 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 16:22 --- Please use tomcat-user to debug this. There is a much larger pool of people there who are actively ready to help with this sort of issue. From there - if its discovered to be a tomcat bug - the tomcat user conversation can easily cross-referenced and we'd be more than happy to keep the bug open. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33360] New: - Cannot use JNDI datasources in ROOT context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33360. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33360 Summary: Cannot use JNDI datasources in ROOT context Product: Tomcat 5 Version: 5.5.7 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] There appears to be an issue when attempting to use a JNDI datasource when defining a ROOT context. So with the simple server.xml: Server port=8005 shutdown=SHUTDOWN GlobalNamingResources Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / /GlobalNamingResources Service name=Catalina !-- HTTP connector -- Connector port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 connectionTimeout=2 disableUploadTimeout=true compression=on compressionMinSize=2048 noCompressionUserAgents=gozilla, traviata compressableMimeType=text/html,text/xml / !-- HTTPS connector -- Connector port=8443 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false disableUploadTimeout=true acceptCount=100 scheme=https secure=true clientAuth=false sslProtocol=TLS / !-- AJP 1.3 connector (needed?) -- Connector port=8009 enableLookups=false redirectPort=8443 protocol=AJP/1.3 / Engine name=Catalina defaultHost=localhost Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ Host name='localhost' appBase='webapps' unpackWARs='false' autoDeploy='true' deployOnStartup='true' xmlValidation='false' xmlNamespaceAware='false' Context path='/' docBase='ROOT.war' crossContext='true' Resource name='jdbc/myDB' auth='Container' type='javax.sql.DataSource' driverClassName='org.postgresql.Driver' url='jdbc:postgresql://localhost:5432/myDB' username='db-user' password='db-passwd' / /Context /Host /Engine /Service /Server When you do: Context ctx = new InitialContext(); DataSource ds = (DataSource) ctx.lookup(java:comp/env/jdbc/myDB); Connection conn = ds.getConnection(); The following error gets throw: org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create JDBC driver of class '' for connect URL 'null' at org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:780) at org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540) If you move the resource definition to GlobalNamingResources and do a resource link you get the same error. But if you change any of the following, it works fine: - Move the resource definition (or link if defined globally) to $CATALINA_HOME/conf/context.xml and remove it from the context entry in server.xml - Move the context defintion out of server.xml completely to $CATALINA_HOME/conf/Catalina/localhost/ROOT.xml - Move the context defintion out of server.xml completely to webapp/META-INF/context.xml - Keep the context entry and resource definition in server.xml but change the context path to something besides '/' This indicates that web applications mounted on the root context are treated differently from other web applications. I think it should be consistent. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33360] - Cannot use JNDI datasources in ROOT context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33360. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33360 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 16:42 --- A discussion of the topic from TSS: http://theserverside.com/discussions/thread.tss?thread_id=25459#137873 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33360] - Cannot use JNDI datasources in ROOT context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33360. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33360 [EMAIL PROTECTED] changed: What|Removed |Added BugsThisDependsOn||30117 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 16:43 --- The cause of the problem might be described in bug #30117 that notices that resource parameters are ignored under the root context. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30117] - ResourceParams ignored in default context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30117. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30117 [EMAIL PROTECTED] changed: What|Removed |Added OtherBugsDependingO||33360 nThis|| -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33360] - Cannot use JNDI datasources in ROOT context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33360. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33360 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 16:59 --- The right path to be used in server.xml is , not /. What you did would just create another webapp which would never be accessed, while your webapp would be deployed by the auto deployer, without your parameters. We used to have an example in server.xml for this special case (Context path= docBase=ROOT debug=0/), but it's removed as we recommend not using server.xml for declaring contexts. Try to avoid using Context elements in server.xml except for webapps which are outside of the Host appBase. Instead, as you mention, use $CATALINA_HOME/conf/Catalina/localhost/ROOT.xml or whatever_your_war_is.war/META-INF/context.xml, but don't use either docBase or path (which would be ignored anyway) on your Context element. Note: The AJP connector is not needed, if you don't use it. (makes sense, I suppose) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33339] - Shutdown script down not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=9. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=9 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 17:02 --- If your network setup has issues and opening a socket on 127.0.0.1 will just timeout, then you can try native integration using jsvc (http://jakarta.apache.org/tomcat/tomcat-5.5-doc/setup.html). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33360] - Cannot use JNDI datasources in ROOT context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33360. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33360 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 17:10 --- Thanks for the heads up. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33362] New: - setclasspath.bat missing @echo off
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33362. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33362 Summary: setclasspath.bat missing @echo off Product: Tomcat 5 Version: 5.0.30 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] in setclasspath.bat at the first line the @echo off ist missing, preventing this script from running and doing its work, leading to compiler not found errors when trying to use jsp .. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.5.4- ClassNotFoundException:org.apache.commons.dbcp.BasicDataSourceFactory
I'm getting the below WARNING when Tomcat 5.5.4 starts up on Windows 2000 server: Feb 2, 2005 10:50:49 AM org.apache.catalina.core.NamingContextListener addResource WARNING: Failed to register in JMX: javax.naming.NamingException: Could not create resource factory, ClassNotFoundException:org.apache.commons.dbcp.BasicDataSourceFactory I have a webapp that is trying to use JDBC DataSource pooling (context shown below). It's when the webapp is being deployed and it's trying to register the resource that the error is encountered. The only BasicDataSourceFactory class that I can find is in naming-factory-dbcp.jar file in common/lib but that has a package structure of org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory. I've tried using this class instead, but Tomcat still is looking for org.apache.commons.dbcp.BasicDataSourceFactory. If I remove the factory property from the context then the error goes away on Windows 2000 Server. What I find even more puzzling is that this error doesn't occur on my Tomcat 5.5.4 that's running on Windows XP Professional. Where is org.apache.commons.dbcp.BasicDataSourceFactory? Why am I not encountering this on Windows XP? Context debug=0 privileged=true !-- the jdbc driver's jar needs to go into $CATALINA_HOME/common/lib -- Resource name=jdbc/as400 auth=Container type=javax.sql.DataSource factory=org.apache.commons.dbcp.BasicDataSourceFactory maxActive=20 maxIdle=10 maxWait=-1 removeAbandoned=true removeAbandonedTimeout=60 logAbandoned=true driverClassName=com.ibm.as400.access.AS400JDBCDriver url=jdbc:as400://a53pb3;naming=system;libraries=,pgmdbt,caelib;errors=full username=userid password=password/ /Context
DO NOT REPLY [Bug 33357] - DataSourceRealm leaks connections
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33357. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33357 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 20:07 --- (In reply to comment #1) Didn't you mention the problem earlier in another report ? I remember something like this, but didn't see anything obvious in the code (which I'm not too familiar with). You might have confused it with this enhancement proposal: http://issues.apache.org/bugzilla/show_bug.cgi?id=33266 Both issues emerged while trying to setup a self-contained webapp (with its own datasource, realm and database driver in WEB-INF/lib). The one decribed in this report is however far more severe. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33368] New: - swallowOutput causes memory leak
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33368. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33368 Summary: swallowOutput causes memory leak Product: Tomcat 5 Version: 5.0.28 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] SystemLogHandler has a map called logs. The key is a ThreadWithAttributes and the value is a stack of CaptureLogs. Because threads come and go from the thread pool, this map slowly gets bigger and bigger. logs should be a ThreadLocal, not a map. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33369] New: - Unpacking WAR files does not preserve timestamps
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33369. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33369 Summary: Unpacking WAR files does not preserve timestamps Product: Tomcat 5 Version: 5.0.28 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] When a WAR is unpacked, the timestamps of the unpacked files are the unpack date, not the date in the WAR file. This causes clients to believe that their caches are out of date. This is a big problem if you're serving up JAR files to dial-up users for WebStart applications. I realize that preserving timestamps would cause JSP's to not be recompiled (their timestamps might be older than the .java and .class files in the work directory). However, if this directory were cleaned out, it would solve that problem. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33339] - Shutdown script down not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=9. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=9 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 20:42 --- No issues have are shown by any other program when connecting to 127.0.0.1 on either OS on the seperate machines they are installed on -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33369] - Unpacking WAR files does not preserve timestamps
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33369. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33369 [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |enhancement --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 20:48 --- This would seem like some special purpose thing. If you have a problem with that, either: - submit a patch - use unpacked folders -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33370] New: - On Tomcat 4.1.24, this works fine but with Tomcat 5, I experience the following
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33370.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33370
Summary: On Tomcat 4.1.24, this works fine but with Tomcat 5, I
experience the following
Product: Tomcat 5
Version: Unknown
Platform: PC
OS/Version: Windows 2000
Status: NEW
Severity: normal
Priority: P2
Component: Servlet JSP API
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
On Tomcat 4.1.24, this works fine but with Tomcat 5, I experience the following
problem.
In the code below my app knows uid until it reaches the navigation servlet.
In summary:
index.html: uid requested on this page
authenticateUser.java: uid = The provided uid.
frame.java: uid = The provided uid.
navigation.java: uid = null
Code:
Index.HTML:
HTML
HEADTITLEDaTitle/TITLE/HEAD
BODY
CENTER
H1User Login Page/H1
BRPlease provide your user credentials.
BR
FORM ACTION=servlet/authenticateUser METHOD=POST
TABLE ALIGN=center WIDTH=100% CELLSPACING=2
CELLPADDING=2
TR
TD ALIGN=right WIDTH=45%User Name:/TD
TD ALIGN=leftINPUT TYPE=TEXT NAME=uid
ALIGN=left SIZE=20/TD
/TR
TR
TD ALIGN=right WIDTH=45%Password:/TD
TD ALIGN=leftINPUT TYPE=PASSWORD NAME=pwd
ALIGN=left SIZE=20/TD
/TR
/TABLE
HRBR
INPUT TYPE=Submit NAME=login VALUE=Login
/FORM
/CENTER
/BODY
/HTML
authenticateUser.java:
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
import java.util.*;
public class authenticateUser extends HttpServlet {
public void doPost(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
HttpSession session = request.getSession();
String userName = request.getParameter(uid);
String password = request.getParameter(pwd);
session.setAttribute(uid, userName);
try {
ResourceBundle resourceBundle = ResourceBundle.getBundle
(LocalString, request.getLocal());
String storedPassword = resourceBundle.getString(UID.
+ userName + .Password);
if (password.equals(storedPassword)) {
RequestDispatcher rd = getServletContext
().getNamedDispatcher(frame);
rd.forward(request, response);
} else {
RequestDispatcher rd =
request.getRequestDispatcher(/Invalidlogin.html);
rd.forward(request, response);
}
} catch (MissingResourceException ne) {
}
}
}
frame.java:
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
import java.util.*;
public class frame extends HttpServlet {
public void doPost(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
HttpSession session = request.getSession();
StringBuffer frame = new StringBuffer();
String space = nbsp;;
String CRLF = \r\n;
String tab = \t;
ResourceBundle rb = ResourceBundle.getBundle(LocalStrings,
request.getLocale());
PrintWriter out = response.getWriter();
frame.append(HTML + CRLF
+ tab + HEAD + CRLF
+ tab + tab + TITLE + rb.getString
(FrameServlet.title) + /TITLE + CRLF
+ tab + /HEAD + CRLF
+ tab + FRAMESET COLS='250,*' BORDER='0' +
CRLF
+ tab + tab + FRAME NAME='left'
SRC='navigation' SCROLLING='auto' + CRLF
+ tab + tab + FRAME NAME='right'
SRC='todoList' + CRLF
+ tab + tab + NOFRAMES + CRLF
+ tab + tab + tab + BODY + CRLF
+ tab + tab + tab + tab + /PPlease use a
browser that supports frames + CRLF
+ tab + tab + tab + /BODY + CRLF
+ tab + tab + /NOFRAMES + CRLF
+ tab + /FRAMESET + CRLF
+ /HTML);
response.setContentType(text/html);
out.println(frame);
}
}
DO NOT REPLY [Bug 33371] New: - Errors are not reported to user code (servlets).
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33371. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33371 Summary: Errors are not reported to user code (servlets). Product: Tomcat 5 Version: 5.0.28 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Connector:Coyote AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Hi, There is a problem with mod_jk and Tomcat under high load that causes slots to be kept by Apache even though the backend Tomcat links has gone down. This is caused by too eager user aborts, ie. where you have web clients that abort the connection by just closing it. You get a broken pipe on the Tomcat side and eventually that is cleared out - since under less traffic this is not an issue. Now consider that you get hammered with requests and many are aborted, ie. out of 30 per seconds 10 are aborted. There are two issues with that, both I will list as separate reports: 1. Reporting errors to user code 2. Closing connections We use Apache/2.0.52 (Unix) mod_ssl/2.0.52 OpenSSL/0.9.7d mod_jk/1.2.6 and Tomcat 5.0.28 This report is for problem #1 above. Consider this error taken from the catalina.out: Nov 30, 2004 2:51:17 PM org.apache.jk.server.JkCoyoteHandler action SEVERE: Error in action code java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:508) at org.apache.jk.server.JkCoyoteHandler.appendHead(JkCoyoteHandler.java:401) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:416) at org.apache.coyote.Response.action(Response.java:182) at org.apache.coyote.Response.sendHeaders(Response.java:374) at org.apache.jk.server.JkCoyoteHandler.doWrite(JkCoyoteHandler.java:230) at org.apache.coyote.Response.doWrite(Response.java:542) at org.apache.coyote.tomcat5.OutputBuffer.realWriteBytes(OutputBuffer.java:368) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:398) at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:318) at org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:297) at org.apache.coyote.tomcat5.CoyoteOutputStream.flush(CoyoteOutputStream.java:85) at sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:410) at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152) at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213) at java.io.BufferedWriter.flush(BufferedWriter.java:230) at org.apache.axis.Message.writeTo(Message.java:441) at org.apache.axis.transport.http.AxisServlet.sendResponse(AxisServlet.java:1018) at org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:895) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:339) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:474) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:409) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:312) at com.worldlingo.servlet.MSOfficeApi11Servlet.service(MSOfficeApi11Servlet.java:67) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at
DO NOT REPLY [Bug 33371] - Errors are not reported to user code (servlets).
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33371. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33371 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 22:21 --- Since you're looking for design flaws, two which are rather obvious are: - doing explicit flushes is inefficient - wrapping with your own writer is equally inefficient When these are fixed, we can think about doing minor tweaking. I think there's not that much value in reporting exceptions to the servlet, however. With he HTTP connector, the connection is marked as error, and the connection will be closed. Please do not open multiple issues. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 33339] - Shutdown script down not work
[EMAIL PROTECTED] wrote: 3) Cygwin is definatley NOT a good platform for testing Linux bugs on. However testing with all possible linux distributions is not a good choice either. And distributions based on 'latest' version of everything plus all kind of experimental/non stable/vendor specific stuff - like fedora - are not the best choice for a supported platform. Can you reproduce it on RHEL or RH9 ? If not - report the bug on fedora. 4) Do you want to tell the Fedora guys that the Tomcat developers official view of Fedora Core 2 is that its' a crappy distro? It is not 'official view' - but some developers have issues with FC :-) 5) Do you expect me to re-install my system just to get Tomcat working?, It's easier to replace Tomcat with Jetty than it would be to resintall my machine with one of the distros that you don't consider crappy I believe a lot of products ( and not only java ) officially support only few distributions. We can't ask you to re-install your system - but you can't ask us to reinstall and test your favorite distro either. There are just too many incompatible linux distributions. If jetty works on your linux distro - just use it. It's a fine open source product. Or you can use resin or any other server. Now I'd like to help resolve this, but at the moment all I'm seeing is a wall of not interesting, can't be bothered, lets' mark it as invalid because I can't reproduce on my own personal setup. Which kinda Probably the comments should be more explicit - like 'unsupported platform / not reproductible on supported platforms '. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33373] New: - jspc precompiling jsp with absolute uri in taglib fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33373. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33373 Summary: jspc precompiling jsp with absolute uri in taglib fails Product: Tomcat 5 Version: 5.5.7 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Jasper AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] i upgraded from 5.5.4 to 5.5.7 and noticed that my ant jsp precompile task was failing for .jsp files that were referencing taglibs. the message it gives is: org.apache.jasper.JasperException: The absolute uri: http://java.sun.com/jsp/jstl/sql cannot be resolved in either web.xml or the jar files deployed with this application the line in the offending jsp looks like: %@ taglib uri=http://java.sun.com/jsp/jstl/sql; prefix=sql % if i go into the jstl taglib jar file and grab the sql.tld file and put it into my WEB-INF then the jspc task works. in 5.5.4 this worked without having the sql.tld file in WEB-INF (it was just found in the .jar file of the tag library) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33374] New: - Connections are not reset under heavy load with lots of closed remote connections
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33374.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33374
Summary: Connections are not reset under heavy load with lots of
closed remote connections
Product: Tomcat 5
Version: 5.0.28
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Native:JK
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
Hi,
There is a problem with mod_jk and Tomcat under high load that causes slots to
be kept by Apache even though the backend Tomcat links has gone down. This is
caused by too eager user aborts, ie. where you have web clients that abort the
connection by just closing it. You get a broken pipe on the Tomcat side and
eventually that is cleared out - since under less traffic this is not an issue.
Now consider that you get hammered with requests and many are aborted, ie. out
of 30 per seconds 10 are aborted.
There are two issues with that, both I will list as separate reports:
1. Reporting errors to user code
2. Closing connections
We use Apache/2.0.52 (Unix) mod_ssl/2.0.52 OpenSSL/0.9.7d mod_jk/1.2.6 and
Tomcat 5.0.28
This report is for problem #2 above.
For some reason, when we get those broken pipe exceptions as reported in bug
#33371 we are having big problems with Apache. What happens is that the
scoreboard of Apache fills up with connections (see attached file), all slots
show status W which means it the request is in work by the handler, in this
case mod_jk. This only happens if we go over a certain amount of requests per
second, otherwise it does not cause any problems. But when we go over the limit
and the slots fill up, what we notice is that we get heaps of Broken pipe
exceptions on the Tomcat side, where we have 9-10 app servers all running
Tomcat, load balanced by mod_jk. All of these servers start to show these Broken
pipe exceptions. It is not that we never have those exceptions, of course when a
user aborts, then we get that exception in the logs. But at peak time and when
the slots fill up in Apache, then we have heaps of them, ie. a couple of them
per second.
Those errors may be caused because of the too eager calling system closing
connection all the time because we respond a bit to slow, but shouldn't those
connections be closed all the way, ie. also on the Apache side, in other words
the connections between Apache and the user?
That is the part that seem to fail. Furthermore we get heaps of stray
connections on the Tomcat machines. If you do a netstat -p -n you get heaps of
connections to local port 8009 (AJP13) but no process is connected to it. I
tried to fix this by applying a this patch to Tomcat 5.0.28, file:
/jakarta-tomcat-5.0.28-src/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java:
267d266
final int error=8;
507,513c506
try {
os.write( buf, 0, len );
} catch (IOException ex) {
ep.setNote( error, Boolean.TRUE );
log.warn(Flagging endpoint as in error. + ep.getNote(
socketNote ) + \nError was: + ex.getMessage() );
throw ex;
}
---
os.write( buf, 0, len );
522,528c515
try {
os.flush();
} catch (IOException ex) {
ep.setNote( error, Boolean.TRUE );
log.warn(Flagging endpoint as in error. + ep.getNote(
socketNote ) + \nError was: + ex.getMessage() );
throw ex;
}
---
os.flush();
681c668
log.warn(Closing ajp connection + status + - +
ep.getNote( socketNote ));
---
log.warn(Closing ajp connection + status );
691,695d677
break;
}
if ( ep.getNote ( error ) == Boolean.TRUE ) {
log.warn(processConnection: Error reported, closing
connection. + ep.getNote( socketNote ));
ep.setNote( error, null );
What it does is remembering when there was an error during IO and when control
comes back all the way through the call stack it eventually closes this
connection.
This is a problem in itself and as reported in bug #33371, the user code does
not get the error, but even if it does it can swallow the exception just like
the current code does and therefore the low-level code does not handle the
problem at all. My patch makes sure that connections that have caused IO errors
to be thrown to close the connection.
That took care of our stray connections, and things worked better for a while,
but we are getting the problem again. The bottomline seems to be that my patch
is useful and
DO NOT REPLY [Bug 33373] - jspc precompiling jsp with absolute uri in taglib fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33373. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33373 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 22:51 --- I am not aware of any relevant changes. Please provide a ready to test war. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33374] - Connections are not reset under heavy load with lots of closed remote connections
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33374. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33374 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 22:52 --- Created an attachment (id=14161) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14161action=view) Scoreboard dump showing full slots. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33374] - Connections are not reset under heavy load with lots of closed remote connections
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33374. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33374 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 22:53 --- Created an attachment (id=14162) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14162action=view) Patches ChannelSocket to close broken connections. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 33339] - Shutdown script down not work
In answer to your points; on 3) I'm not asking for it tested on all distros, just those where issues have arisen. If no-one has FC2 installed then thats something the group should know about and should be able to say Sorry, no-one has FC2, rather than Closed bug, doesn't work on [insert name of totally different platform here]. The users mail list has a report from Drew Jorgenson if it not working on RHAS 3, and I can confirm I've also seen the behaviour on SLES8 (i.e. a non-redhat product), so I don't think it's distribution specific. on 4) It's never good to write that any other groups efforts off as crappy, I'm sure this group wouldn't be happy if the Fedora group described Tomcat as crappy. We're all doing our best (yes, I have released some open source code in the past), and it worried me that the crappy comment was made and no-one else stepped in to be a bit more helpful. on 5) Given your response I'm happy to offer help with FC2 related problems. I wasn't willing to make this offer before because it seemed the only responses I had were aimed more at getting the bug marked as closed than investigating where the problem was. I'll keep an eye on the -dev list (but unfortunatley I don't have time to look at all the bug report comments) and if I see a problem with FC2 I will attempt to dupluicate it. In case your wondering what my experience is I've been a Linux sys admin for 11 years, and have been programming system in Java for about 8 years with the last 5 spent focused on developing high performance server side applications for Teleco's and Financial institutions, which hopefully will allow me to assist in some way. on the last paragraph - I completely agree. If people know which platforms are fully supported (i.e. if bugs are reported someone can test them easilly) it will make life a lot easier. You'll probably find that in return for listing a platform as full supported the distributor may be receptive to including Tomcat in their product. Costin, I'd like to thank you for the sending the first comprehensive response which makes me feel that users bugs are taken seriously, and not treated as something that should be closed at any costs. Regards, Al. -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache Sent: 02 February 2005 21:22 To: tomcat-dev@jakarta.apache.org Subject: Re: DO NOT REPLY [Bug 9] - Shutdown script down not work [EMAIL PROTECTED] wrote: 3) Cygwin is definatley NOT a good platform for testing Linux bugs on. However testing with all possible linux distributions is not a good choice either. And distributions based on 'latest' version of everything plus all kind of experimental/non stable/vendor specific stuff - like fedora - are not the best choice for a supported platform. Can you reproduce it on RHEL or RH9 ? If not - report the bug on fedora. 4) Do you want to tell the Fedora guys that the Tomcat developers official view of Fedora Core 2 is that its' a crappy distro? It is not 'official view' - but some developers have issues with FC :-) 5) Do you expect me to re-install my system just to get Tomcat working?, It's easier to replace Tomcat with Jetty than it would be to resintall my machine with one of the distros that you don't consider crappy I believe a lot of products ( and not only java ) officially support only few distributions. We can't ask you to re-install your system - but you can't ask us to reinstall and test your favorite distro either. There are just too many incompatible linux distributions. If jetty works on your linux distro - just use it. It's a fine open source product. Or you can use resin or any other server. Now I'd like to help resolve this, but at the moment all I'm seeing is a wall of not interesting, can't be bothered, lets' mark it as invalid because I can't reproduce on my own personal setup. Which kinda Probably the comments should be more explicit - like 'unsupported platform / not reproductible on supported platforms '. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33371] - Errors are not reported to user code (servlets).
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33371. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33371 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 23:13 --- Remy, I am not sure what you mean by that. Shouldn't - in this case - the AXIS servlet have a chance to know that sending the SOAP package has failed? Also, I assume the flush() is called at the end of the writeTo() method, is this what you refer to or the code in the middle with the doFlush etc.? Lars -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 33339] - Shutdown script down not work
On Wed, 2005-02-02 at 16:54, Al Sutton wrote: In answer to your points; on 3) I'm not asking for it tested on all distros, just those where issues have arisen. If no-one has FC2 installed then thats something the group should know about and should be able to say Sorry, no-one has FC2, rather than Closed bug, doesn't work on [insert name of totally different platform here]. The users mail list has a report from Drew Jorgenson if it not working on RHAS 3, and I can confirm I've also seen the behaviour on SLES8 (i.e. a non-redhat product), so I don't think it's distribution specific. Just for the record, I tested on FC2 and posted the shell session on the users list. You responded to my email before writing this message. I've also stated that I'm willing to upgrade both the kernel and the JDK to test under an environment that is closer to yours. Please don't omit these details when when writing to either list. At the very least, it's dishonest, at worst it's misleading and could cause people to waste time repeating things that have already been done. -Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33371] - Errors are not reported to user code (servlets).
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33371. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33371 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 23:43 --- I looked at the HTTP implementation, and it handles the case (I had forgotten about that). It is better to send the servlet an exception. The exception has to be caught at some point and rewrapped, so the signature of action doesn't matter. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33371] - Errors are not reported to user code (servlets).
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33371. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33371 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 23:52 --- OK, sounds good. What did you mean by do not open multiple issues in your initial comment? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33370] - On Tomcat 4.1.24, this works fine but with Tomcat 5, I experience the following
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33370. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33370 --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 00:14 --- It appears the session is not being picked up in the navigation servlet. Why? there isn't enough detail. Please use the tomcat user list to debug this. They will be much more helpful. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33339] - Shutdown script down not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=9. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=9 --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 00:39 --- Per discussion on the users list, here is a screen dump of a test with the same Linux kernel, JDK, and TC release as the original reporter's. Everything seems to be in order. [EMAIL PROTECTED] bin]$ uname -a Linux bsouther 2.6.10-1.9_FC2 #1 Thu Jan 13 17:54:57 EST 2005 i686 athlon i386 GNU/Linux [EMAIL PROTECTED] bin]$ export JAVA_HOME=/usr/local/j2sdk1.4.2_06 [EMAIL PROTECTED] bin]$ ./startup.sh Using CATALINA_BASE: /home/bsouther/tc_test/jakarta-tomcat-5.5.7 Using CATALINA_HOME: /home/bsouther/tc_test/jakarta-tomcat-5.5.7 Using CATALINA_TMPDIR: /home/bsouther/tc_test/jakarta-tomcat-5.5.7/temp Using JRE_HOME: /usr/local/j2sdk1.4.2_06 [EMAIL PROTECTED] bin]$ ./shutdown.sh Using CATALINA_BASE: /home/bsouther/tc_test/jakarta-tomcat-5.5.7 Using CATALINA_HOME: /home/bsouther/tc_test/jakarta-tomcat-5.5.7 Using CATALINA_TMPDIR: /home/bsouther/tc_test/jakarta-tomcat-5.5.7/temp Using JRE_HOME: /usr/local/j2sdk1.4.2_06 Created MBeanServer with ID: e94e92:101d55eb6c4:-8000:bsouther:1 [EMAIL PROTECTED] bin]$ ps -ef | grep java bsouther 4714 4595 0 18:19 pts/000:00:00 grep java [EMAIL PROTECTED] bin]$ -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33371] - Errors are not reported to user code (servlets).
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33371. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33371 --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 00:59 --- I did sound like the issues were basically the same. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33357] - DataSourceRealm leaks connections
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33357. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33357 --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 01:20 --- Created an attachment (id=14165) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14165action=view) Refactored o.a.c.realm.DataSourceRealm -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33373] - jspc precompiling jsp with absolute uri in taglib fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33373. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33373 --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 01:21 --- there were changes to o.a.jasper.jspc.java concerning the classloader. i can't demonstrate this in a ready to run war since the problem doesn't happen if i let jsp's compile at runtime. this is only happening to me at precompile time. i did some more testing and have narrowed the behavior down to a case where if i have 2 .jsp files named a.jsp and b.jsp and the second one alphabetically (b.jsp) has the taglib reference but a.jsp doesn't, then the bug happens. if i rename a.jsp to c.jsp so that the non taglib jsp comes after the taglib one, then it works. it appears that something magic is happening so that precompiling with taglibs only works if the first jsp that is processed by jspc.java contains a taglib reference. if you diff jspc.java between 5.5.4 and 5.5.7 you'll see a number of changes regarding its management of the classloader that may or may not be the culprit. hope this is of some help :) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33357] - DataSourceRealm leaks connections
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33357. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33357 --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 01:25 --- Created an attachment (id=14166) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14166action=view) Modified o.a.c.realm.LocalStrings.properties Fixed two message keys for more consistent look (uppercesed 's' in a word datasourceRealm). The rest of resource bundles do not contain fixed keys. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33373] - jspc precompiling jsp with absolute uri in taglib fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33373. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33373 --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 01:28 --- The jspc changes are not relevant. Without a test war - invalid. BTW, jsp-examples is precompiled as part of the Tomcat build process. It contains JSTL pages, without expanded TLDs. Do you have any explanation as to why it precompiles without errors ? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33357] - DataSourceRealm leaks connections
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33357.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33357
--- Additional Comments From [EMAIL PROTECTED] 2005-02-03 01:38 ---
Why not ...
Do you know the purpose of the
if( !dbConnection.getAutoCommit() ) {
dbConnection.commit();
}
which was in the code before ? I do not see any writes being made.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Yahoo!©_¼¯¦Û°Ê¦^¨ç
[EMAIL PROTECTED]
[EMAIL PROTECTED]@yahoo.com.tw]
¤j®a³Ì¦n«ÊÂê¥Lªº¤Î®É³q¸òe-mail³£n«ÊÂê
¥L·|±H¯f¬rµ¹§O¤H.¤w¸g¦³«Ü¦h¤H¦]¦¹¦Ó¤¤¬r.½Ð¤j®a¤d¸U¤p¤ß¤F
§â³o¨Ç¤º®eÂà±Hµ¹50¤H.±zªºyahoo±N·|¦³600ӹϥÜ.¦P®É±zªºª¬ºA·|°{¬õ¥ú.80®M§K¶O³y«¬ºëÆF.«H½c¤É¯Å1gb.§A³ßÅwªº¤H¤]·|³ßÅw§A
¤j®a§Ö¨Ó¬Ý!¤£¬Ý§A·|[EMAIL PROTECTED]://www.hyemall.com/bbs/get.php?id=138511
[EMAIL PROTECTED]@[EMAIL PROTECTED](¦]¬°¥¦·|»{ip)(ÂI¤§«e¥ýµn¤JYAHOO¤~¦³¥Î³á)
Original Message:
X-YahooFilteredBulk: 218.164.175.240
Authentication-Results: mta162.mail.tpe.yahoo.com
from=jakarta.apache.org; domainkeys=neutral (no sig)
X-Originating-IP: [218.164.175.240]
Return-Path: tomcat-dev@jakarta.apache.org
Received: from 218.164.175.240 (EHLO yahoo.com.tw) (218.164.175.240)
by mta162.mail.tpe.yahoo.com with SMTP; Thu, 03 Feb 2005 08:40:43 +0800
From: tomcat-dev@jakarta.apache.org
To: [EMAIL PROTECTED]
Subject: good morning
Date: Thu, 3 Feb 2005 08:40:39 +0800
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary==_NextPart_000_0012_0030.0C70
X-Priority: 3
X-MSMail-Priority: Normal
This is a multi-part message in MIME format.
--=_NextPart_000_0012_0030.0C70
Content-Type: text/plain;
charset=Windows-1252
Content-Transfer-Encoding: 7bit
here, the introduction
--=_NextPart_000_0012_0030.0C70
Content-Type: application/octet-stream;
name=
_
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33371] - Errors are not reported to user code (servlets).
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33371. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33371 --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 02:54 --- It looks to me like an IOException should be being thrown back to the servlet. Just after sendHeaders returns normally (as it must, since ActionHook.action can't throw), JkCoyoteHandler.doWrite will attempt to send the response body, causing ChannelSocket.send to throw an IOException again, which will be caught, wrapped, and rethrown by OutputBuffer.realWriteBytes. This one gets sent back to the servlet to deal with. Granted, exception handling could be cleaned up a bit, and Jk-Coyote could close the connection a bit sooner. However, neither of these should be causing major problems. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java
billbarker2005/02/02 19:36:57
Modified:jk/java/org/apache/jk/server JkCoyoteHandler.java
Log:
Cleanup exception handling in action, and remember error state so that we can
close the connection without having to attempt another read.
Fix for Bug #33374
Reported By: Lars George [EMAIL PROTECTED]
Revision ChangesPath
1.59 +112 -90
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.58
retrieving revision 1.59
diff -u -r1.58 -r1.59
--- JkCoyoteHandler.java 11 Jan 2005 13:37:45 - 1.58
+++ JkCoyoteHandler.java 3 Feb 2005 03:36:57 - 1.59
@@ -96,6 +96,7 @@
public final int JK_STATUS_NEW=0;
public final int JK_STATUS_HEAD=1;
public final int JK_STATUS_CLOSED=2;
+public final int JK_STATUS_ERROR=3;
/** Set a property. Name is a component.property. JMX should
* be used instead.
@@ -311,11 +312,13 @@
res.finish();
}
-ep.setStatus( JK_STATUS_NEW );
-
req.recycle();
req.updateCounters();
res.recycle();
+if( ep.getStatus() == JK_STATUS_ERROR ) {
+return ERROR;
+}
+ep.setStatus( JK_STATUS_NEW );
rp.setStage(Constants.STAGE_KEEPALIVE);
return OK;
}
@@ -410,106 +413,125 @@
// Coyote Action implementation
public void action(ActionCode actionCode, Object param) {
-try {
-if( actionCode==ActionCode.ACTION_COMMIT ) {
-if( log.isDebugEnabled() ) log.debug(COMMIT );
-org.apache.coyote.Response
res=(org.apache.coyote.Response)param;
-
-if( res.isCommitted() ) {
-if( log.isInfoEnabled() )
-log.info(Response already commited );
-} else {
+if( actionCode==ActionCode.ACTION_COMMIT ) {
+if( log.isDebugEnabled() ) log.debug(COMMIT );
+org.apache.coyote.Response res=(org.apache.coyote.Response)param;
+
+if( res.isCommitted() ) {
+if( log.isInfoEnabled() )
+log.info(Response already commited );
+} else {
+try {
appendHead( res );
+} catch(IOException iex) {
+log.warn(Unable to send headers,iex);
+MsgContext ep=(MsgContext)res.getNote( epNote );
+ep.setStatus(JK_STATUS_ERROR);
}
-} else if( actionCode==ActionCode.ACTION_RESET ) {
-if( log.isDebugEnabled() )
-log.debug(RESET );
-
-} else if( actionCode==ActionCode.ACTION_CLIENT_FLUSH ) {
-if( log.isDebugEnabled() ) log.debug(CLIENT_FLUSH );
-org.apache.coyote.Response
res=(org.apache.coyote.Response)param;
-MsgContext ep=(MsgContext)res.getNote( epNote );
-ep.setType( JkHandler.HANDLE_FLUSH );
+}
+} else if( actionCode==ActionCode.ACTION_RESET ) {
+if( log.isDebugEnabled() )
+log.debug(RESET );
+
+} else if( actionCode==ActionCode.ACTION_CLIENT_FLUSH ) {
+if( log.isDebugEnabled() ) log.debug(CLIENT_FLUSH );
+org.apache.coyote.Response res=(org.apache.coyote.Response)param;
+MsgContext ep=(MsgContext)res.getNote( epNote );
+ep.setType( JkHandler.HANDLE_FLUSH );
+try {
ep.getSource().flush( null, ep );
-
-} else if( actionCode==ActionCode.ACTION_CLOSE ) {
-if( log.isDebugEnabled() ) log.debug(CLOSE );
-
-org.apache.coyote.Response
res=(org.apache.coyote.Response)param;
-MsgContext ep=(MsgContext)res.getNote( epNote );
-if( ep.getStatus()== JK_STATUS_CLOSED ) {
-// Double close - it may happen with forward
-if( log.isDebugEnabled() ) log.debug(Double CLOSE -
forward ? + res.getRequest().requestURI() );
-return;
-}
+} catch(IOException iex) {
+// This is logged elsewhere, so debug only here
+log.debug(Error during flush,iex);
+res.setErrorException(iex);
+ep.setStatus(JK_STATUS_ERROR);
+}
+
+} else if( actionCode==ActionCode.ACTION_CLOSE ) {
+if( log.isDebugEnabled() )
DO NOT REPLY [Bug 33374] - Connections are not reset under heavy load with lots of closed remote connections
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33374. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33374 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 04:38 --- This is fixed in the CVS, and will appear in the next version of TC 5.5, 4.1, and 3.3. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33374] - Connections are not reset under heavy load with lots of closed remote connections
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33374. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33374 --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 06:01 --- William, Wasn't the change meant to fix bug #33371? Lars -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33374] - Connections are not reset under heavy load with lots of closed remote connections
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33374. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33374 --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 06:32 --- (In reply to comment #4) William, Wasn't the change meant to fix bug #33371? Lars Nope. This is the socket not getting closed fast enough. Tomcat still doesn't throw an exception from action. As I stated in 33371, I can't see why the servlet wouldn't get an IOE in this case, so I can't really fix it ;-). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 33339] - Shutdown script down not work
Well, if you can debug this and find the real cause and a fix - I'm sure someone will look at it. But please understand that Remy and the other tomcat developers deal with a lot of bugs, and usually it's frustrating to deal with bugs that happen only on certain situations. If Java code behaves correctly on most platforms - but it doesn't work on few distributions - you may as well report this as a bug to either Sun or the distribution. BTW, we are engineers, not PR people - so 'crappy' comments may happen :-) So if you have a patch or workaround - please reopen the bug and add the fix. It would be a better way to spend the time instead of arguing about closing/not closing it or hurt feelings :-) Costin Al Sutton wrote: In answer to your points; on 3) I'm not asking for it tested on all distros, just those where issues have arisen. If no-one has FC2 installed then thats something the group should know about and should be able to say Sorry, no-one has FC2, rather than Closed bug, doesn't work on [insert name of totally different platform here]. The users mail list has a report from Drew Jorgenson if it not working on RHAS 3, and I can confirm I've also seen the behaviour on SLES8 (i.e. a non-redhat product), so I don't think it's distribution specific. on 4) It's never good to write that any other groups efforts off as crappy, I'm sure this group wouldn't be happy if the Fedora group described Tomcat as crappy. We're all doing our best (yes, I have released some open source code in the past), and it worried me that the crappy comment was made and no-one else stepped in to be a bit more helpful. on 5) Given your response I'm happy to offer help with FC2 related problems. I wasn't willing to make this offer before because it seemed the only responses I had were aimed more at getting the bug marked as closed than investigating where the problem was. I'll keep an eye on the -dev list (but unfortunatley I don't have time to look at all the bug report comments) and if I see a problem with FC2 I will attempt to dupluicate it. In case your wondering what my experience is I've been a Linux sys admin for 11 years, and have been programming system in Java for about 8 years with the last 5 spent focused on developing high performance server side applications for Teleco's and Financial institutions, which hopefully will allow me to assist in some way. on the last paragraph - I completely agree. If people know which platforms are fully supported (i.e. if bugs are reported someone can test them easilly) it will make life a lot easier. You'll probably find that in return for listing a platform as full supported the distributor may be receptive to including Tomcat in their product. Costin, I'd like to thank you for the sending the first comprehensive response which makes me feel that users bugs are taken seriously, and not treated as something that should be closed at any costs. Regards, Al. -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache Sent: 02 February 2005 21:22 To: tomcat-dev@jakarta.apache.org Subject: Re: DO NOT REPLY [Bug 9] - Shutdown script down not work [EMAIL PROTECTED] wrote: 3) Cygwin is definatley NOT a good platform for testing Linux bugs on. However testing with all possible linux distributions is not a good choice either. And distributions based on 'latest' version of everything plus all kind of experimental/non stable/vendor specific stuff - like fedora - are not the best choice for a supported platform. Can you reproduce it on RHEL or RH9 ? If not - report the bug on fedora. 4) Do you want to tell the Fedora guys that the Tomcat developers official view of Fedora Core 2 is that its' a crappy distro? It is not 'official view' - but some developers have issues with FC :-) 5) Do you expect me to re-install my system just to get Tomcat working?, It's easier to replace Tomcat with Jetty than it would be to resintall my machine with one of the distros that you don't consider crappy I believe a lot of products ( and not only java ) officially support only few distributions. We can't ask you to re-install your system - but you can't ask us to reinstall and test your favorite distro either. There are just too many incompatible linux distributions. If jetty works on your linux distro - just use it. It's a fine open source product. Or you can use resin or any other server. Now I'd like to help resolve this, but at the moment all I'm seeing is a wall of not interesting, can't be bothered, lets' mark it as invalid because I can't reproduce on my own personal setup. Which kinda Probably the comments should be more explicit - like 'unsupported platform / not reproductible on supported platforms '. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe,
RE: DO NOT REPLY [Bug 33339] - Shutdown script down not work
Ben, Please re-read my email. It is discussing the initial response I received from the -dev list, and then addressing the issue raised about it being distribution specific. My critisism was that the bug was initially closed when the only attempt to re-produce it I was made aware of was made on a completely different platform and that it initially appeared that the -dev list did not have developers that were willing to investigate the problem. Regards, Al. -Original Message- From: Ben Souther [mailto:[EMAIL PROTECTED] Sent: 02 February 2005 22:25 To: Tomcat Developers List Subject: RE: DO NOT REPLY [Bug 9] - Shutdown script down not work On Wed, 2005-02-02 at 16:54, Al Sutton wrote: In answer to your points; on 3) I'm not asking for it tested on all distros, just those where issues have arisen. If no-one has FC2 installed then thats something the group should know about and should be able to say Sorry, no-one has FC2, rather than Closed bug, doesn't work on [insert name of totally different platform here]. The users mail list has a report from Drew Jorgenson if it not working on RHAS 3, and I can confirm I've also seen the behaviour on SLES8 (i.e. a non-redhat product), so I don't think it's distribution specific. Just for the record, I tested on FC2 and posted the shell session on the users list. You responded to my email before writing this message. I've also stated that I'm willing to upgrade both the kernel and the JDK to test under an environment that is closer to yours. Please don't omit these details when when writing to either list. At the very least, it's dishonest, at worst it's misleading and could cause people to waste time repeating things that have already been done. -Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c
mturk 2005/02/02 23:47:49 Added: jni/native/src ssl.c Log: Add OpenSSL support. Revision ChangesPath 1.1 jakarta-tomcat-connectors/jni/native/src/ssl.c Index: ssl.c === /* Copyright 2000-2004 The Apache Software Foundation * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an AS IS BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ #include apr.h #include apr_pools.h #include apr_file_io.h #include tcn.h #ifdef HAVE_OPENSSL /* OpenSSL headers */ #include openssl/ssl.h #include openssl/err.h #include openssl/x509.h #include openssl/pem.h #include openssl/crypto.h #include openssl/evp.h #include openssl/rand.h #include openssl/x509v3.h /* Avoid tripping over an engine build installed globally and detected * when the user points at an explicit non-engine flavor of OpenSSL */ #if defined(HAVE_OPENSSL_ENGINE_H) defined(HAVE_ENGINE_INIT) #include openssl/engine.h #endif #else #endif - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jni/native/src pool.c shm.c
mturk 2005/02/02 23:48:20
Modified:jni/native/src pool.c shm.c
Log:
Add NIO ByteBuffer direct memory allocation.
Revision ChangesPath
1.2 +30 -0 jakarta-tomcat-connectors/jni/native/src/pool.c
Index: pool.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jni/native/src/pool.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- pool.c14 Jan 2005 13:47:58 - 1.1
+++ pool.c3 Feb 2005 07:48:20 - 1.2
@@ -123,3 +123,33 @@
(*e)-DeleteGlobalRef(e, cb-obj);
free(cb);
}
+
+TCN_IMPLEMENT_CALL(jobject, Pool, alloc)(TCN_STDARGS, jlong pool,
+ jint size)
+{
+apr_pool_t *p = J2P(pool, apr_pool_t *);
+apr_size_t sz = (apr_size_t)size;
+void *mem;
+
+UNREFERENCED(o);
+
+if ((mem = apr_palloc(p, sz)) != NULL)
+return (*e)-NewDirectByteBuffer(e, mem, (jlong)sz);
+else
+return NULL;
+}
+
+TCN_IMPLEMENT_CALL(jobject, Pool, calloc)(TCN_STDARGS, jlong pool,
+ jint size)
+{
+apr_pool_t *p = J2P(pool, apr_pool_t *);
+apr_size_t sz = (apr_size_t)size;
+void *mem;
+
+UNREFERENCED(o);
+
+if ((mem = apr_pcalloc(p, sz)) != NULL)
+return (*e)-NewDirectByteBuffer(e, mem, (jlong)sz);
+else
+return NULL;
+}
1.2 +14 -0 jakarta-tomcat-connectors/jni/native/src/shm.c
Index: shm.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jni/native/src/shm.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- shm.c 14 Jan 2005 13:47:58 - 1.1
+++ shm.c 3 Feb 2005 07:48:20 - 1.2
@@ -108,3 +108,17 @@
UNREFERENCED_STDARGS;
return (jlong)apr_shm_size_get(s);
}
+
+TCN_IMPLEMENT_CALL(jobject, Shm, buffer)(TCN_STDARGS, jlong shm)
+{
+apr_shm_t *s = J2P(shm, apr_shm_t *);
+jlong sz = (jlong)apr_shm_size_get(s);
+void *a;
+
+UNREFERENCED(o);
+
+if ((a = apr_shm_baseaddr_get(s)) != NULL)
+return (*e)-NewDirectByteBuffer(e, a, sz);
+else
+return NULL;
+}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni Pool.java Shm.java
mturk 2005/02/02 23:48:32 Modified:jni/java/org/apache/tomcat/jni Pool.java Shm.java Log: Add NIO ByteBuffer direct memory allocation. Revision ChangesPath 1.3 +20 -2 jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/Pool.java Index: Pool.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/Pool.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- Pool.java 14 Jan 2005 14:42:37 - 1.2 +++ Pool.java 3 Feb 2005 07:48:32 - 1.3 @@ -16,6 +16,8 @@ package org.apache.tomcat.jni; +import java.nio.ByteBuffer; + /** Pool * * @author Mladen Turk @@ -98,7 +100,7 @@ /** * Register a process to be killed when a pool dies. - * @param a The pool to use to define the processes lifetime + * @param a The pool to use to define the processes lifetime * @param proc The process to register * @param how How to kill the process, one of: * PRE @@ -111,4 +113,20 @@ */ public static native void noteSubprocess(long a, long proc, int how); +/** + * Allocate a block of memory from a pool + * @param p The pool to allocate from + * @param size The amount of memory to allocate + * @return The ByteBuffer with allocated memory + */ +public static ByteBuffer alloc(long p, int size); + +/** + * Allocate a block of memory from a pool and set all of the memory to 0 + * @param p The pool to allocate from + * @param size The amount of memory to allocate + * @return The ByteBuffer with allocated memory + */ +public static ByteBuffer calloc(long p, int size); + } 1.3 +13 -4 jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/Shm.java Index: Shm.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/Shm.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- Shm.java 14 Jan 2005 14:42:37 - 1.2 +++ Shm.java 3 Feb 2005 07:48:32 - 1.3 @@ -16,6 +16,7 @@ package org.apache.tomcat.jni; +import java.nio.ByteBuffer; /** Shm * * @author Mladen Turk @@ -105,7 +106,15 @@ * @param m The shared memory segment from which to retrieve *the segment length. */ -public static native long size(long m); - +public static native ByteBuffer buffer(long m); +/** + * Retrieve new ByteBuffer base address of the shared memory segment. + * NOTE: This address is only usable within the callers address + * space, since this API does not guarantee that other attaching + * processes will maintain the same address mapping. + * @param m The shared memory segment from which to retrieve + *the base address. + * @return address, aligned by APR_ALIGN_DEFAULT. + */ -} \ No newline at end of file +} - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jni/native libtcnative.dsp
mturk 2005/02/02 23:48:56 Modified:jni/native libtcnative.dsp Log: Add OpenSSL support. Revision ChangesPath 1.5 +8 -4 jakarta-tomcat-connectors/jni/native/libtcnative.dsp Index: libtcnative.dsp === RCS file: /home/cvs/jakarta-tomcat-connectors/jni/native/libtcnative.dsp,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- libtcnative.dsp 18 Jan 2005 10:23:15 - 1.4 +++ libtcnative.dsp 3 Feb 2005 07:48:56 - 1.5 @@ -43,7 +43,7 @@ # PROP Ignore_Export_Lib 0 # PROP Target_Dir # ADD BASE CPP /nologo /MD /W3 /O2 /D WIN32 /D NDEBUG /D _WINDOWS /FD /c -# ADD CPP /nologo /MD /W3 /Zi /O2 /I ./include /I ../apr/include /I ../apr/include/arch/win32 /I $(JAVA_HOME)/include /I $(JAVA_HOME)/include/win32 /D NDEBUG /D TCN_DECLARE_EXPORT /D WIN32 /D _WINDOWS /FdRelease\libtcnative_src /FD /c +# ADD CPP /nologo /MD /W3 /Zi /O2 /I ./include /I ../apr/include /I ../apr/include/arch/win32 /I $(JAVA_HOME)/include /I $(JAVA_HOME)/include/win32 /I ../openssl/inc32 /D NDEBUG /D TCN_DECLARE_EXPORT /D WIN32 /D _WINDOWS /D WIN32_LEAN_AND_MEAN /D NO_IDEA /D NO_RC5 /D NO_MDC2 /D OPENSSL_NO_IDEA /D OPENSSL_NO_RC5 /D OPENSSL_NO_MDC2 /D HAVE_OPENSSL /D HAVE_SSL_SET_STATE=1 /FdRelease\libtcnative_src /FD /c # ADD BASE MTL /nologo /D NDEBUG /mktyplib203 /o /win32 NUL # ADD MTL /nologo /D NDEBUG /mktyplib203 /o /win32 NUL # ADD BASE RSC /l 0x409 /d NDEBUG @@ -53,7 +53,7 @@ # ADD BSC32 /nologo LINK32=link.exe # ADD BASE LINK32 kernel32.lib advapi32.lib ws2_32.lib mswsock.lib wldap32.lib psapi.lib ole32.lib /nologo /base:0x6EE0 /subsystem:windows /dll /debug /machine:I386 /opt:ref -# ADD LINK32 kernel32.lib advapi32.lib ws2_32.lib mswsock.lib wldap32.lib psapi.lib ole32.lib /nologo /base:0x6EE0 /subsystem:windows /dll /debug /machine:I386 /out:Release/libtcnative-1.dll /opt:ref +# ADD LINK32 kernel32.lib advapi32.lib ws2_32.lib mswsock.lib wldap32.lib psapi.lib ole32.lib libeay32.lib ssleay32.lib /nologo /base:0x6EE0 /subsystem:windows /dll /debug /machine:I386 /out:Release/libtcnative-1.dll /libpath:../openssl/out32dll /libpath:../openssl/out32 /opt:ref !ELSEIF $(CFG) == libtcnative - Win32 Debug @@ -69,7 +69,7 @@ # PROP Ignore_Export_Lib 0 # PROP Target_Dir # ADD BASE CPP /nologo /MDd /W3 /GX /Zi /Od /D WIN32 /D _DEBUG /D _WINDOWS /FD /c -# ADD CPP /nologo /MDd /W4 /GX /Zi /Od /I ./include /I ../apr/include /I ../apr/include/arch/win32 /I $(JAVA_HOME)/include /I $(JAVA_HOME)/include/win32 /D _DEBUG /D TCN_DECLARE_EXPORT /D WIN32 /D _WINDOWS /FdDebug\libtcnative_src /FD /c +# ADD CPP /nologo /MDd /W4 /GX /Zi /Od /I ./include /I ../apr/include /I ../apr/include/arch/win32 /I $(JAVA_HOME)/include /I $(JAVA_HOME)/include/win32 /I ../openssl/inc32 /D _DEBUG /D TCN_DECLARE_EXPORT /D WIN32 /D _WINDOWS /D WIN32_LEAN_AND_MEAN /D NO_IDEA /D NO_RC5 /D NO_MDC2 /D OPENSSL_NO_IDEA /D OPENSSL_NO_RC5 /D OPENSSL_NO_MDC2 /D HAVE_OPENSSL /D HAVE_SSL_SET_STATE=1 /FdDebug\libtcnative_src /FD /c # ADD BASE MTL /nologo /D _DEBUG /mktyplib203 /o /win32 NUL # ADD MTL /nologo /D _DEBUG /mktyplib203 /o /win32 NUL # ADD BASE RSC /l 0x409 /d _DEBUG @@ -79,7 +79,7 @@ # ADD BSC32 /nologo LINK32=link.exe # ADD BASE LINK32 kernel32.lib advapi32.lib ws2_32.lib mswsock.lib wldap32.lib psapi.lib ole32.lib /nologo /base:0x6EE0 /subsystem:windows /dll /incremental:no /debug /machine:I386 -# ADD LINK32 kernel32.lib advapi32.lib ws2_32.lib mswsock.lib wldap32.lib psapi.lib ole32.lib /nologo /base:0x6EE0 /subsystem:windows /dll /incremental:no /debug /machine:I386 /out:Debug/libtcnative-1.dll +# ADD LINK32 kernel32.lib advapi32.lib ws2_32.lib mswsock.lib wldap32.lib psapi.lib ole32.lib libeay32.lib ssleay32.lib /nologo /base:0x6EE0 /subsystem:windows /dll /incremental:no /debug /machine:I386 /out:Debug/libtcnative-1.dll /libpath:../openssl/out32dll /libpath:../openssl/out32 !ENDIF @@ -144,6 +144,10 @@ # End Source File # Begin Source File +SOURCE=.\src\ssl.c +# End Source File +# Begin Source File + SOURCE=.\src\stdlib.c # End Source File # Begin Source File - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni Shm.java
mturk 2005/02/02 23:57:13 Modified:jni/java/org/apache/tomcat/jni Shm.java Log: Fix wrong commit. Deleted size function call by mistake. Revision ChangesPath 1.4 +4 -1 jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/Shm.java Index: Shm.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/Shm.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- Shm.java 3 Feb 2005 07:48:32 - 1.3 +++ Shm.java 3 Feb 2005 07:57:13 - 1.4 @@ -17,6 +17,7 @@ package org.apache.tomcat.jni; import java.nio.ByteBuffer; + /** Shm * * @author Mladen Turk @@ -106,7 +107,8 @@ * @param m The shared memory segment from which to retrieve *the segment length. */ -public static native ByteBuffer buffer(long m); +public static native long size(long m); + /** * Retrieve new ByteBuffer base address of the shared memory segment. * NOTE: This address is only usable within the callers address @@ -116,5 +118,6 @@ *the base address. * @return address, aligned by APR_ALIGN_DEFAULT. */ +public static native ByteBuffer buffer(long m); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
