DO NOT REPLY [Bug 10312] New: - JNDI Resource Params are not being set
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10312. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10312 JNDI Resource Params are not being set Summary: JNDI Resource Params are not being set Product: Tomcat 4 Version: 4.0.4 Final Platform: All OS/Version: Other Status: NEW Severity: Critical Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I've added a custom JNDI resource factory to the server.xml: Resource auth=Container name=test type=com.ibm.test.Test / ResourceParams name=test parameter namefactory/name valuecom.ibm.test.TestFactory/value /parameter /ResourceParams And I've added the appropriate lines to my web.xml: resource-ref res-ref-nametest/res-ref-name res-typecom.ibm.test.Test/res-type res-authContainer/res-auth /resource-ref Then, when I run my code: InitialContext ctx = new InitialContext(); Test test = (Test)ctx.lookup(java:comp/env/test); I get an error stating that the resource instance could not be created. After digging through the code, I found the following problem: In org.apache.naming.factory.ResourceFactory, the following code returns a null when it should return the value of the factory resource param. RefAddr factoryRefAddr = ref.get(Constants.FACTORY); Digging in a bit further, it would appear as if the ResourceParams are not being properly set at all for resources in the server.xml. While they appear to be parsed and digested well enough, they never seem to make it to the context. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
xdocs for jkjk2 / ant 1.5.1
Hi,
I was playing with xdocs in jk and tried to use it
to generate both jk and jk2.
I choose the following layout :
xdocs/common(menu.idx, Ajp13.xml)
xdocs/jk(menu.idx, index.xml, building.xml, configtc.xml, configweb.xml)
xdocs/jk2 (menu.idx, index.xml, building.xml, configtc.xml, configweb.xml)
xdocs (menu.idx, index.xml)
But there is fatal error in style task, located somewhere in the XSL.
Did the current style works well with subdirectories ?
ant 1.5b2, xerces 2.0.1, xalan 2.3.1 (into latest eclipse 2.0)
!-- Add some style to our otherwise utterly ugly XML files --
style
basedir=${source.docs}
destdir=${build.docs}
style=${source.docs}/style.xsl
force=true
includes=**/**.xml/
---
docs.check:
docs.init:
docs.color:
docs.color:
docs:
[mkdir] Created dir: D:\eclipse\workspace\jkdocs\build\docs
[style] Transforming into D:\eclipse\workspace\jkdocs\build\docs
[style] Processing D:\eclipse\workspace\jkdocs\xdocs\index.xml to
D:\eclipse\workspace\jkdocs\build\docs\index.html
[style] Loading stylesheet D:\eclipse\workspace\jkdocs\xdocs\style.xsl
[style] Processing D:\eclipse\workspace\jkdocs\xdocs\jk2\configtc.xml to
D:\eclipse\workspace\jkdocs\build\docs\jk2\configtc.html
[style] D:/eclipse/workspace/jkdocs/xdocs/style.xsl:486:51: Fatal Error! Unknown
error in XPath Cause: java.lang.NullPointerException
[style] : Fatal Error! Fatal error during transformation Cause: Fatal error during
transformation
[style] Failed to process D:\eclipse\workspace\jkdocs\xdocs\jk2\configtc.xml
BUILD FAILED
D:\eclipse\workspace\jkdocs\build.xml:101: Fatal error during transformation
Total time: 6 seconds
Same things when using xsl from tomcat 4.1 docs :
-- with tomcat4 docs
build-main:
[style] Transforming into D:\eclipse\workspace\tomcat4docs\build\tomcat-docs
[style] Processing D:\eclipse\workspace\tomcat4docs\security-manager-howto.xml to
D:\eclipse\workspace\tomcat4docs\build\tomcat-docs\security-manager-howto.html
[style] Loading stylesheet D:\eclipse\workspace\tomcat4docs\tomcat-docs.xsl
[style] Processing D:\eclipse\workspace\tomcat4docs\introduction.xml to
D:\eclipse\workspace\tomcat4docs\build\tomcat-docs\introduction.html
[style] Transforming into D:\eclipse\workspace\tomcat4docs\build\tomcat-docs\appdev
[style] Processing D:\eclipse\workspace\tomcat4docs\appdev\installation.xml to
D:\eclipse\workspace\tomcat4docs\build\tomcat-docs\appdev\installation.html
[style] Loading stylesheet D:\eclipse\workspace\tomcat4docs\tomcat-docs.xsl
[style] Processing D:\eclipse\workspace\tomcat4docs\appdev\deployment.xml to
D:\eclipse\workspace\tomcat4docs\build\tomcat-docs\appdev\deployment.html
[style] Processing D:\eclipse\workspace\tomcat4docs\appdev\processes.xml to
D:\eclipse\workspace\tomcat4docs\build\tomcat-docs\appdev\processes.html
[style] Processing D:\eclipse\workspace\tomcat4docs\appdev\source.xml to
D:\eclipse\workspace\tomcat4docs\build\tomcat-docs\appdev\source.html
[style] : Fatal Error! java.lang.NullPointerException Cause:
java.lang.NullPointerException
[style] Failed to process D:\eclipse\workspace\tomcat4docs\appdev\source.xml
BUILD FAILED
D:\eclipse\workspace\tomcat4docs\build.xml:90: Fatal error during transformation
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk 1.2.0 release poll
I have one question, what is the target JVM version for the java side of things? I noticed that org.apache.ajp.tomcat4.Ajp13Connector uses Socket.setKeepAlive() which was introduced in java 1.3. Yep, we may have to remove/condition this, since Tomcat4 only require JDK 1.2 (for now) Regards, Glenn GOMEZ Henri wrote: Ok, I think we're near release now. The last thing to do will be to add documentation, there is allready README.configure which explains how to build for apache 1.3/2.0 via configure. Needed now : - Configuration for Apache 1.3/2.0 httpd.conf/workers.properties - Build procedures for IIS/iPlanet. - Configuration for IIS/iPlanet These could be for now simple text files, which will be translated to JK xml docs at a later time (don't want to delay the release until all documentation is passed to xml format). If nobody could works on IIS/iPlanet build/conf, I'll grab the stuff from TC 3.3 html doc. I'll take care of Apache's - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat ANT Task patch
Hi, i committed a patch for my own feature request in bugzilla regarding tomcat ANT tasks. They are a little bit more ANT Task Guidelines compliant in supporting failonerror attribute (meaning that for instance when you try to start an webapp which is allready started, with failonerror=false, you wont get an BuildException in your ANT process) I also fixed an optical bug in ListTask, when outputting on win32 systems. I would love to hear if there is a chance that these fixes get into the tree... --- greetings from Marc Logemann Homebase @ www.logemann.info -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core MappingRequest.java ApplicationContext.java
Glenn Nielsen wrote: Your commit mentions fixing a memory leak in HttpRequestBase, but I never saw that file committed. HttpRequestBase does create a lot of dates objects when it is instantiated. For some reason it was also never GCed properly, at least on JDK 1.3, which leaked a ton of memory. It was also very inefficient, as the object was only used to find the wrapper associated with the RD. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.6] New milestone release soon
I think we were each tracking down a different memory leak. The one I found is in DBCP, I should have that patched sometime tomorrow. Oh, ok. I'll wait a bit for your commit (and I'll apply the Tyrex 1.0 bug I fixed). It is definitely not as critical that the memory leak I fixed (using the RD was leaking memory, although it really looks like a JDK bug instead of a TC bug). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [4.1.6] New milestone release soon
I haven't had a chance to work out how to compile from CVS yet. To save me time, is there anywhere I can download a recent 4.1.6-dev build so I can quickly test it before it is tagged? Thanks. Dave. -Original Message- From: Dave [mailto:[EMAIL PROTECTED]] Sent: 26 June 2002 20:04 To: [EMAIL PROTECTED] Subject: RE: [4.1.6] New milestone release soon Remy, Bug 10018 is pretty serious. Coyote-JK2 won't serve a resource (might apply to dynamic content as well as static) that's bigger than 8k. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10018 Are you using a nightly ? I fixed the bug few days ago, I'm constantly doing large posts with jk2 in my day job. Please let me know ASAP if you still have this problem ! Costin I'm using 4.1.5. I will try a nightly tonight. Thanks. Dave. -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
BUG in Tomcat??? Tomcat 4.0 and UTF-8
Hi, I'm using Tomcat 4.0 and I have some problems with requests containing UTF-8 characters. I have my servlet named 'delta' which is properly deployed and running. When I try to invoke it in the following way: http://myserver:8080/delta/Test/%D0%AE%D1%80%D0%B8%D0%B9%20%D0%9A%D0%BE%D0%B 2%D0%B0%D0%BB%D1%91%D0%B2.doc where /Test/%D0%AE%D1%80%D0%B8%D0%B9%20%D0%9A%D0%BE%D0%B2%D0%B0%D0%BB%D1%91%D0%B2. doc is a path to the resource in my repository, in my servlet I try to obtain that path using method: request.getPathInfo() The string which I get from this method is illegible. I've tried to decode it with URLDecoder, tried to use something like this: path = new String(path.toByteArray(iso-8859-1),UTF-8); but nothing works :( Please note that it works with Tomcat 3.2.2... What should I do? Please help, Artur Pozdrawiam, AJ mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Erroneous Chained JSP Ordering with getRequestDispatcher
The Jasper Engine is messing around with JSP ordering. If in a servlet called FROM a JSP via a taglib, the servlet then passes the control to anothr JSP, the latter JSP is output first. Note that output from the servlet IS correctly placed. Initial JSP: %@ taglib uri=Common prefix=common % htmlbodycommon:FormDay //body/html Say, in the Common servlet there is: pageContext.getOut().print(foo); request.getRequestDispatcher(/secondary.jsp).include(request, response); and secondary.jsp is: bsometext/b Then the output will be: bsometext/b htmlbodyfoo/body/html See how the secondary.jsp has been popped off the JSP stack first, yet the servlet code is correctly positioned? I trawled the archives, and there was a similar report back in 2001. See: http://mikal.org/interests/java/tomcat/archive/view?mesg=48825 From: [EMAIL PROTECTED] Subject: Order of execution - JSP/RequestDispatcher include problem Date: Wed, 5 Dec 2001 14:20:02 -0600 No answer though. Plenty of others have expressed similar problems, but they have differing problem domains, so express their questions differently. They boil down to the same JSP ordering issue though. Any thoughts? -- Terry Alexis Lurie Software Engineer Weboutcome Ltd. t: +44 (0)20 7953 7457 f: +44 (0)7092 123 230 m: +44 (0)7980 768 142 e: [EMAIL PROTECTED] w: http://www.weboutcome.com Unit 302, The Chandlery 50 Westminster Bridge Road London SE1 7QY ***This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you receive this message in error, please return it to the sender.*** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
