cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk2 configweb.xml
mturk 2002/10/02 23:58:24 Modified:jk/xdocs/jk2 configweb.xml Log: Add the channel.apr and explain new options for the load balancer. Revision ChangesPath 1.10 +87 -3 jakarta-tomcat-connectors/jk/xdocs/jk2/configweb.xml Index: configweb.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk2/configweb.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- configweb.xml 26 Sep 2002 07:37:21 - 1.9 +++ configweb.xml 3 Oct 2002 06:58:24 - 1.10 @@ -287,6 +287,66 @@ /table /p /subsection +subsection name=channel.apr +p +A communication transport to a remote Engine using APR library +bMagic:/b The local part of the name will be the Engine name, +to use when defining the uri mappings. For example +channel.apr.local_9009 will automatically define an engine named +local_9009, and if no other setting is set ajp13 will be used for +communication. +bMagic:/b If no channel is defined in the config, a default channel +will be constructed with port=8009, engine=DEFAULT, worker=ajp13 - +named 'channel.apr.DEFAULT' +/p +p +table +tr +thProperty name/th +thDefault/th +thDescription/th +/tr +tr +tdport/td +td8009/td +tdPort where Tomcat is listening/td +/tr +tr +tdhost/td +tdlocalhost/td +tdRemote host/td +/tr +tr +tdkeepalive/td +td0 (disabled)/td +tdIf set to 1 then it enables the use of keep-alive packets on TCP connection /td +/tr +tr +tdtimeout/td +td0 (infinite)/td +tdSocket timeout for sending and receiving/td +/tr +tr +tdndelay/td +td0/td +tdIf set to 1 Disables the Nagle algorithm for send coalescing/td +/tr +tr +tdlbfactor/td +td1/td +td +Load balancing factor to use. At this moment, it'll be set on the worker, +but in future it should be possible to use lb on a channel level. + /td +/tr +tr +tdgroup/td +tdlb:0/td +tdloadbalanced groups to which this channel and the associated worker will be added, multivalued/td +/tr +/table +/p +/subsection subsection name=channel.jni pThe jni channel, used if tomcat is started inprocess/p /subsection @@ -296,9 +356,9 @@ For the moment 4 worker types are supported: worker.jni,ajp13,status,lb. /p subsection name=worker.jni -pworker used in inprocess, holds the details of the Tomcat class to startup, and paramters to pass/p +pworker used in inprocess, holds the details of the Tomcat class to startup, and parameters to pass/p pThere are two predefined jni workers bonStartup/b and bonShutdown/b. Those two workers are executed -during sturtup and shutdown phase of the connector. Both must exsist in the configuration to be able to start +during startup and shutdown phase of the connector. Both must exists in the configuration to be able to start and shutdown Tomcat. /p p @@ -409,6 +469,30 @@ td/ td/ /tr +tr +tdtimeout/td +td0 (disabled)/td +tdIf all the workers are in the error state, probably by Tomcat +refusing any new connections due to the overload, you can set the timeout forcing lb to wait that some +worker becomes available, instead of immediately returning error to the
Re: Tagging JK2_2_0_1?
Mladen Turk wrote: There has been some major fixes inside the uriMap, uriEnv, apr_socket and lb that makes the 2_0_0 IMO unusable, and personally I'm ashamed as a RM that this was a release after all :(. Do not! That is a lot of work to make a release and all of us will benefit to the fact you are now fitted to be the next RM :-)) Since we tagged and released JK2 as beta, seems to me that we could easily do the same for the 2.0.1, and just pretend that 2.0.0 ewer existed :) The question is are we going to wait for a Apache1.3/APR/JNI builds or just go without that. But before going to the 2_0_1 (What doesn't kill you makes you stronger ;) could you guys do the testing against current CVS for all the discussed items. Do not hurry too much if you think that 2_0_0 is a very bad we should not loose time producing binaries for it. But we must make sure 2_0_1 will be good enough for beta. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
Costin Manolache wrote: Mladen Turk wrote: -Original Message- On Behalf Of Costin Manolache Are we documenting all those settings - and the details on why/how :-) ? Sure, like everyone else ;). Yes, I know :-) I'll try to get over the horrible and nonstandard DTD that we use I agree for not standard DTD but horrible... Well it needs a lot of improvements but that means the xml files need to be reviewed carefully I would suggest to output messages when using weird elements to have time to rewrite the files. and start documenting what I can still remember, and anything new that I add. And I won't write any new jk code until I finish at least reviewing all the bugs ( 80 ? ) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Weird seg fault on Mac OS X for mod_jk2 + Apache2
Han Ming Ong wrote: Folks, I'm trying to trace down a TCP_NODELAY problem and wanted to see if it exists on the latest connector mod_jk2. So I configured Apache 2.0.42, Tomcat 4.1.12 and downloaded jakarta-tomcat-connectors-4.1.12-src. I managed to use GNU's libtoolize to configure (./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-apr-lib=/usr/local/apache2/lib --with-apr-include=/usr/local/apache2/include --with-tomcat1=/usr/local/jakarta-tomcat-4.1.12). The compilation was successful and I copied mod_jk2.so to /usr/local/apache2/modules. I configured httpd.conf to load the module and appended the following: IfModule mod_jk2.c JkSet config.file /usr/local/apache2/conf/workers2.properties /IfModule I added a super simple workers2.properties file in the same dir and tried to start apache. I got a seg fault. Here's the stacktrace from Mac OS X default crash logger: Command:httpd PID:853 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x736f0028 Thread 0 Crashed: #0 0x90001600 in strlen #1 0x900023e0 in vfprintf #2 0x90015ee0 in __sbprintf #3 0x900018a8 in vfprintf #4 0x900017ec in fprintf #5 0x0060fdbc in jk2_map_default_get (jk_map.c:97) -- it's '97' because I added printf #6 0x0060df50 in jk2_env_createBean2 (jk_env.c:218) #7 0x0061ee0c in jk2_create_config (mod_jk2.c:351) #8 0x0002214c in ap_single_module_configure (config.c:1845) #9 0x7ad8 in load_module (mod_so.c:337) #10 0x00020308 in invoke_cmd (config.c:749) #11 0x000213d0 in execute_now (config.c:1347) #12 0x00020a40 in ap_build_config_sub (config.c:944) #13 0x00020f68 in ap_build_config (config.c:1151) #14 0x000218f0 in ap_process_resource_config (config.c:1556) #15 0x000220e8 in ap_read_config (config.c:1834) #16 0xc184 in main (main.c:615) #17 0x1ae0 in _start (crt.c:267) #18 0x1960 in start Here's output with some printf statements inserted in jk_map.c: entering for threadMutex (no. maps: 25) 0: logger.file (°Z°Z°Z°Z°Z°Z) - funny output is from fprintf(stderr,%s, mPriv-values[i]) 1: logger.win32 (°Z°Z°Z°Z°Z) 2: workerEnv (°Z°ZA°Z°Z) 3: uriMap (°Z°Za°Z°Z) 4: uriEnv (°Z°ZA°Z°Z) 5: endpoint (°Z°ZA°Z°Z) 6: uri (°Z°ZA°Z°Z) 7: config (°Z°Z°Z°Z°Z°Z) 8: ajp13 (°Z°ZA°Z°Z) 9: lb (,) 10: status (°Z°Z°Z°Z°Z) 11: run (,) 12: channel.un (°Z°ZA°Z°Z) 13: channel.apr (°Z°ZA°Z°Z) 14: shm (°Z°Z°Z°Z°Z°Z) 15: channel.socket (°Z°ZA°Z°Z) 16: handler.response (°Z°Z°Z°Z°Z°Z) 17: handler.logon (°Z°Z°Z°Z°Z°Z) 18: threadMutex (°Z°Z°Z°Z°Z°Z) done for threadMutex entering for logger.apache2: (no. maps: 1) 0: threadMutex:0 () done for logger.apache2: ... ... entering for uri:/examples/* (no. maps: 19) 0: threadMutex:0 () 1: logger.apache2: () 2: logger.apache2 () 3: logger () 4: uriMap: () 5: uriMap () 6: config: () 7: config () 8: shm: () 9: shm () 10: workerEnv: () 11: workerEnv () 12: uri: () 13: uri () 14: threadMutex:1 () 15: threadMutex:2 () 16: threadMutex:3 () 17: ajp13:localhost:8009 () 18: channel.socket:localhost:8009 () done for uri:/examples/* entering for uri (no. maps: 26) 0: logger.file (°Z°Z°Z°Z°Z°Z) 1: logger.win32 (°Z°Z°Z°Z°Z) 2: workerEnv (°Z°ZA°Z°Z) 3: uriMap (°Z°Za°Z°Z) 4: uriEnv (°Z°ZA°Z°Z) 5: endpoint (°Z°ZA°Z°Z) 6: uri (°Z°ZA°Z°Z) done for uri entering for workerEnv (no. maps: 19) 0: threadMutex:0 () 1: logger.apache2: () 2: logger.apache2 () 3: logger () 4: uriMap: () 5: uriMap () 6: config: () 7: config () 8: shm: () 9: shm () 10: workerEnv: () 11: workerEnv () done for workerEnv entering for ver (no. maps: 1) 0: worker (ajp13:localhost:8009) done for ver [here it churns for a few seconds before segfaulting] bin/apachectl: line 87: 853 Segmentation fault $HTTPD -k $ARGV Anyone has a clue on what could be wrong? Just pointers would help. I tried following the stack trace but am temporarily thrown off by how jk2_env_createBean2() gets to jk2_map_default_get(), especially the second parameter's type. It seems to be casted from (char *) to (jk_map_t *), which is kind of weird. mPriv is NULL or wrongly align. Appreciate it. Han Ming # workers2.properties # Shared memory handling. Needs to be set. [shm] file=/usr/local/apache2/logs/shm.file
Re: Strange problem with tomcat 4.1.2
Matt Fury wrote: I BELIEVE that is due to some incorrect commenting in your server.xml file. I had this problem once and I thats what caused it. Double check your server.xml file. I triple checked ALL xml files, and they are correct and the error show up first in digester. I suspect something elsewhere, since the error is also present when you're using the original tarball if you replace the bundled xercesImpl.jar by a xerces 2.2.0.jar The difference is that the same error didn't prevent tomcat to load example, admin or manager webapps. I attached a log done using tomcat 4.1.12 tarball (full) and with xerces 2.2.0 replacing the original xercesImpl.jar I does the change before launching tomcat for the first time. 2002-10-03 10:09:18 WebappLoader[/admin]: Deploying class repositories to work directory /home/root/jakarta-tomcat-4.1.12/work/Standalone/localhost/admin 2002-10-03 10:09:18 WebappLoader[/admin]: Deploy class files /WEB-INF/classes to /home/root/jakarta-tomcat-4.1.12/webapps/../server/webapps/admin/WEB-INF/classes 2002-10-03 10:09:18 WebappLoader[/admin]: Deploy JAR /WEB-INF/lib/struts.jar to /home/root/jakarta-tomcat-4.1.12/webapps/../server/webapps/admin/WEB-INF/lib/struts.jar 2002-10-03 10:09:19 ContextConfig[/admin]: Configured an authenticator for method FORM 2002-10-03 10:09:19 StandardManager[/admin]: Seeding random number generator class java.security.SecureRandom 2002-10-03 10:09:19 StandardManager[/admin]: Seeding of random number generator has been completed 2002-10-03 10:09:19 StandardWrapper[/admin:default]: Loading container servlet default 2002-10-03 10:09:19 StandardWrapper[/admin:invoker]: Loading container servlet invoker 2002-10-03 10:09:21 action: null org.xml.sax.SAXParseException: The string -- is not permitted within comments. at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at javax.xml.parsers.SAXParser.parse(SAXParser.java:363) at javax.xml.parsers.SAXParser.parse(SAXParser.java:137) at org.apache.struts.digester.Digester.parse(Digester.java:755) at org.apache.struts.action.ActionServlet.initServlet(ActionServlet.java:1434) at org.apache.struts.action.ActionServlet.init(ActionServlet.java:474) at org.apache.webapp.admin.ApplicationServlet.init(ApplicationServlet.java:152) at javax.servlet.GenericServlet.init(GenericServlet.java:256) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:924) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:813) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3341) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3534) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:579) at org.apache.catalina.core.StandardHostDeployer.addChild(StandardHostDeployer.java:529) at java.lang.reflect.Method.invoke(Native Method) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java:228) at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:260) at org.apache.commons.digester.Digester.endElement(Digester.java(Compiled Code)) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse(Digester.java:1514) at org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:335) at org.apache.catalina.core.StandardHost.install(StandardHost.java:803) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:452) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:409) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:879) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:368) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1196) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at
Re: [VOTE] JK2 2.1
Costin Manolache wrote: Henri Gomez wrote: More comments on APR and JK2. While making tomcat-connectors rpm for jk2, and also jk2 binaries for Linux, I wanted to have apache 1.3 jk2 built with JNI support. Do you have a multithreaded apache1.3 ? It's very important to compile it as multithreaded and link pthread ! No but added the LoadModule pthread directive. For the apr issues - I still think that apr should be treated as a general-purpose library, and we shouldn't have more than one varaiant in the system. Yes Probably some APR expert could clarify this - but my opinion is that on linux the right place for apr is /usr/lib/libapr.so.0.9.2 and /usr/include/apr. When you create an Apache 2.0.42, apr shared lib goes in /usr/lib, with /usr/lib/libapr.so.0.9.2. The includes goes in /usr/include/apache2. When you're just build apr/apr-util, you should put them elsewhere to avoid collision with the one which are provided by apache2. If you don't do this, you'll have a strange situation where you have to specify that you need apache2 to build apache 1.3 jk2 ! Also as I said the shared/static libs which came from apr 0.9.1 have major version in name, libapr-0.so, libaprutil-0.so... And I think Apache2.0 RPM should just depend on libapr.rpm, and same for mod_jk2.rpm I seems you could build Apache 2.0.42 against an allready present APR shared lib, and trying it right now but I still wonder why Apache 2.0.42 bundle an APR 0.9.2 where only APR 0.9.1 is available as release. It's just too confusing to have 2 variants of the same library, and it should be a portability library that can be used outside apache - without apache having a special copy. I agree, but it's something which should be fixed by Apache 2.0 and APR teams, ie make Apache 2.0 use the latest APR release (0.9.1 or 0.9.2 ?). May be JF could do something for us and also ask why the apr goes with the -0 in names -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tagging JK2_2_0_1?
Mladen Turk wrote: There has been some major fixes inside the uriMap, uriEnv, apr_socket and lb that makes the 2_0_0 IMO unusable, and personally I'm ashamed as a RM that this was a release after all :(. Since we tagged and released JK2 as beta, seems to me that we could easily do the same for the 2.0.1, and just pretend that 2.0.0 ewer existed :) As JF said, we should wait a little more before releasing a 2.0.1 (even beta). The question is are we going to wait for a Apache1.3/APR/JNI builds or just go without that. But before going to the 2_0_1 (What doesn't kill you makes you stronger ;) could you guys do the testing against current CVS for all the discussed items. I think Apache 1.3 / APR / JNI should be resolved before 2.0.1 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8107] - uninstall mod_jk2-2.0 rpm not possible
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=8107. 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=8107 uninstall mod_jk2-2.0 rpm not possible [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 08:50 --- fixed in latest rpms which should be provided soon from jk 2.0.0 release BTW, these rpma are pretty outdated, so better wait the one which will come with jk and jk2 release -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: isapi_redirect.dll file
Ashley Huang Wanyi wrote: Hello, Can you email me this file isapi_redirect.dll , as i couldn't find it. Thank You. http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/bin/win32/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tagging JK2_2_0_1?
Something which should done will be to tag in C sources for use by scandoc (or doxygen). I'll try to do this for jk/native. Comments ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] JK2 2.1
Henri Gomez wrote: Costin Manolache wrote: Henri Gomez wrote: More comments on APR and JK2. While making tomcat-connectors rpm for jk2, and also jk2 binaries for Linux, I wanted to have apache 1.3 jk2 built with JNI support. Do you have a multithreaded apache1.3 ? It's very important to compile it as multithreaded and link pthread ! No but added the LoadModule pthread directive. For the apr issues - I still think that apr should be treated as a general-purpose library, and we shouldn't have more than one varaiant in the system. Yes For the moment that is not the case. For example you may need an APR with threads and another without. Probably some APR expert could clarify this - but my opinion is that on linux the right place for apr is /usr/lib/libapr.so.0.9.2 and /usr/include/apr. When you create an Apache 2.0.42, apr shared lib goes in /usr/lib, with /usr/lib/libapr.so.0.9.2. The includes goes in /usr/include/apache2. When you're just build apr/apr-util, you should put them elsewhere to avoid collision with the one which are provided by apache2. If you don't do this, you'll have a strange situation where you have to specify that you need apache2 to build apache 1.3 jk2 ! Also as I said the shared/static libs which came from apr 0.9.1 have major version in name, libapr-0.so, libaprutil-0.so... And I think Apache2.0 RPM should just depend on libapr.rpm, and same for mod_jk2.rpm I seems you could build Apache 2.0.42 against an allready present APR shared lib, and trying it right now but I still wonder why Apache 2.0.42 bundle an APR 0.9.2 where only APR 0.9.1 is available as release. We should ask httpd dev list. It's just too confusing to have 2 variants of the same library, and it should be a portability library that can be used outside apache - without apache having a special copy. I agree, but it's something which should be fixed by Apache 2.0 and APR teams, ie make Apache 2.0 use the latest APR release (0.9.1 or 0.9.2 ?). May be JF could do something for us and also ask why the apr goes with the -0 in names To allow different versions of apr. For example if you could have Apache 2.0 using APR 0.9.2 and subversion using APR 1.0.0. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tagging JK2_2_0_1?
Henri Gomez wrote: Something which should done will be to tag in C sources for use by scandoc (or doxygen). I'll try to do this for jk/native. Comments ? That is some work... The scandoc templates were prepared for mod_webapp. doxygen is what is most communily used in Apache. -- 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]
DO NOT REPLY [Bug 13240] New: - CGI works only with Java version 1.3+
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=13240. 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=13240 CGI works only with Java version 1.3+ Summary: CGI works only with Java version 1.3+ Product: Tomcat 4 Version: 4.1.12 Platform: HP OS/Version: HP-UX Status: NEW Severity: Normal Priority: Other Component: Catalina:Modules AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] java version 1.2.2.07 HotSpot VM (1.0.1fcs, mixed mode, PA2.0 build 1.2.2.07-00/12/08-PA_RISC2.0) When executing a CGI, Tomcat gives me the following error: ... -- root cause java.lang.NoSuchMethodError at org.apache.catalina.servlets.CGIServlet$CGIRunner.run (CGIServlet.java:1583) ... Reason is CGIServlet.java line 1583: proc = rt.exec(cmdAndArgs.toString(), hashToStringArray(env), wd); This method is only available since 1.3. See http://java.sun.com/j2se/1.4/docs/api/java/lang/Runtime.html#exec (java.lang.String, java.lang.String[], java.io.File) The documentation http://jakarta.apache.org/tomcat/tomcat-4.1-doc/RUNNING.txt tells me that I can use this version of Tomcat with java version 1.2+. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13033] - Unable to pass Request Time Parameters for the XML View of JSP file
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=13033. 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=13033 Unable to pass Request Time Parameters for the XML View of JSP file [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 10:10 --- This is a problem with the spec, not with Tomcat (see comments for bug 10683). *** This bug has been marked as a duplicate of 10683 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10683] - some problems with JSP documents in xml syntax
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=10683. 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=10683 some problems with JSP documents in xml syntax [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 10:10 --- *** Bug 13033 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13223] - JSP pages in XML syntax do not compile properly
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=13223. 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=13223 JSP pages in XML syntax do not compile properly [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 10:18 --- This is a problem with the spec, not with Tomcat (see comments for bug 10683). The exception you get seems indeed unrelated. Feel free to reopen the bug if you think there's really a problem besides the known XML/attribute spec issue. (Note: I'm not a Tomcat developer, but I've spent quite some time fighting with the XML syntax...) *** This bug has been marked as a duplicate of 10683 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] [5.0] Milestones
Kevin Jones wrote: Not a vote, just wondered when we can expect to see the milestone builds appearing? I would say sometimes next week for 5.0.0 if everyone is ok with that. Keep in mind this is not feature complete yet. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk2 configweb.xml
mturk 2002/10/03 03:52:16 Modified:jk/xdocs/jk2 configweb.xml Log: Add the explanation about uri:*:port scheme. Revision ChangesPath 1.11 +8 -1 jakarta-tomcat-connectors/jk/xdocs/jk2/configweb.xml Index: configweb.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk2/configweb.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- configweb.xml 3 Oct 2002 06:58:24 - 1.10 +++ configweb.xml 3 Oct 2002 10:52:16 - 1.11 @@ -151,7 +151,14 @@ p Special case is a default server named as b[uri:*]/b that is used when the virtual host cannot be found inside the configuration. All the uri directives not containing -host name belongs to this default server making global mappings.br / +host name belongs to this default server making global mappings. +/p +p +Addition wild char scheme id b[uri:*:port]/b that is used when you wish to +match any virtual host having specified (non-default) port number, like [uri:*:443]. +This will map all the virtual hosts no mather what is their name but that have port number 443. +/p +p The order how the host names are resolved is : ul liExact host name and optional non default port number/li -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] [5.0] Milestones
Thanks Remy, Kevin Jones Developmentor www.develop.com -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 03 October 2002 11:22 To: Tomcat Developers List Subject: Re: [VOTE] [5.0] Milestones Kevin Jones wrote: Not a vote, just wondered when we can expect to see the milestone builds appearing? I would say sometimes next week for 5.0.0 if everyone is ok with that. Keep in mind this is not feature complete yet. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
Thank-you, but I still seem to get errors.
Namely the logkit from Avalon is referencing an old verion. I fixed it up
to the following
logkit.home=${base.path}/LogKit-1.1
logkit.lib=${logkit.home}
logkit.jar=${logkit.lib}/logkit-1.1.jar
logkit.loc=http://jakarta.apache.org/builds/jakarta-avalon/release/logkit/latest/LogKit-1.1-bin.tar.gz
xerces.home=${base.path}/xerces-2_2_0
xerces.lib=${xerces.home}
xercesImpl.jar=${xerces.lib}/xercesImpl.jar
xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.2.0.tar.gz
I do not know if you can commit changes, but these worked for me, since the
old versions either do not exist or the references have been made updated.
Christian Gross
At 09:40 PM 02/10/2002 -0400, you wrote:
You need to be using the HEAD version of digester. It should have been built
in the directory specified by base.path. Double check that it was built
correctly. I just recreated it in my depends directory, and the system built
fine.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13241] New: - Tomcat 4.1.12 / Webapps:Examples / Disabled
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=13241. 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=13241 Tomcat 4.1.12 / Webapps:Examples / Disabled Summary: Tomcat 4.1.12 / Webapps:Examples / Disabled Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Webapps:Examples AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hi!, I am currently working with the source code for Tomcat 4.1.12 and compiling it on a Linux / Redhat environment (v6.2, v7.1) and although the complete package can be compiled/installed without any problems, when I try to access the Webapps:Examples (specifically the JSP/Servlet) section I am told that the /examples directory is not available. Consulting the log file shows the following problem: 2002-10-03 16:52:27 WebappLoader[/examples]: Reloading checks are enabled for th is Context 2002-10-03 16:52:29 ContextConfig[/examples] Exception processing TLD at resourc e path /WEB-INF/jsp/debug-taglib.tld javax.servlet.ServletException: Exception processing TLD at resource path /WEB-I NF/jsp/debug-taglib.tld at org.apache.catalina.startup.ContextConfig.tldScanTldContextConfig.java:1010) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:870) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEventContextConfig.java :243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent (LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3493) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2189) at org.apache.catalina.startup.Catalina.start(Catalina.java:510) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) 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.main(Bootstrap.java:203) - Root Cause - org.xml.sax.SAXParseException: The string -- is not permitted within comments. at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse(Digester.java:1514) at org.apache.catalina.startup.ContextConfig.tldScanStream (ContextConfig.java:977) at org.apache.catalina.startup.ContextConfig.tldScanTld (ContextConfig.java:1006) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:870) [...] 2002-10-03 16:52:29 ContextConfig[/examples]: Marking this application unavailab le due to previous error(s) 2002-10-03 16:52:29 StandardManager[/examples]: Seeding random number generator class java.security.SecureRandom 2002-10-03 16:52:30 StandardManager[/examples]: Seeding of random number generat or has been completed 2002-10-03 16:52:30 StandardContext[/examples]: Context startup failed due to pr evious errors I have compiled Tomcat previously and haven't had any problems. The build made use of: JDK-1.4.1(Beta) - Blackdown, and was compiled in a full distribution mode. Libraries which were used during the compile were those recommended in the building.txt document and were: jakarta-tomcat-connectors, jakarta-structs-1.1-b2, jakarta-regexp-1.2, mx4j-1.1 commons-digester-1.3, tyrex-1.0, jndi-1.2.1, jaxp-1.1.3, jakarta-servletapi-4 commons-daemon-1.1, commons-logging-1.0.2, xerces-2_2_0, commons-beanutils-1.4.1 commons-pool-1.0.1, commons-dbcp-1.0, commons-modeler-1.0, commons-collections-2 jdbc2_0-stdext, junit 3.7, javamail-1.2, jsse-1.0.2, jaf-1.0.1, jta-spec1_0_1 Would changing the xerces-2_2_0 library back to xerces-1_4_4 help, or does it mean that a small modification is required to the xerces package to remove the -- string ? Any information which you can provide would be greatly appreciated. See ya Dean Thompson -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PROPOSAL] Splitting docs for JK2
Hi, I propose that we split the: 1. configtc.xml to the 2 documents: a. configtc.xml b. configtcex.xml (having the examples section) 2. configweb.xml to the 3 (or perhaps more) documents: a. configweb.xml (having intro and config section) b. configwebcom.xml (having components section) This could be even splitted by the component level. c. configwebex.xml (having examples section) The reason? IMO the files are too big (not even having half the context they should), and are allready segmented by bookmarks. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12978] - Tomcat doesn't pick up error pages.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12978. 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=12978 Tomcat doesn't pick up error pages. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13241] - Tomcat 4.1.12 / Webapps:Examples / Disabled
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=13241. 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=13241 Tomcat 4.1.12 / Webapps:Examples / Disabled --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 11:28 --- At this point, I am not using Jikes (at least I haven't got it defined or compiled anywhere in the project). When I downgraded to xerces-1_4_4 rather than use xerces-2_2_0, I am able to get a clean compile and I am able to use the Servlets and JSPExamples page. Looks like there might be a slight problem/incompatability in the xerces-2_2_0 library. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 13241] - Tomcat 4.1.12 / Webapps:Examples/ Disabled
[EMAIL PROTECTED] wrote: 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=13241. 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=13241 Tomcat 4.1.12 / Webapps:Examples / Disabled --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 11:28 --- At this point, I am not using Jikes (at least I haven't got it defined or compiled anywhere in the project). When I downgraded to xerces-1_4_4 rather than use xerces-2_2_0, I am able to get a clean compile and I am able to use the Servlets and JSPExamples page. Looks like there might be a slight problem/incompatability in the xerces-2_2_0 library. Yes, the comment check was not present in previous xerces release (or disabled by default) and I still wonder where digester find problem with --. Any help will be welcomed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13241] - Tomcat 4.1.12 / Webapps:Examples / Disabled
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=13241. 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=13241 Tomcat 4.1.12 / Webapps:Examples / Disabled --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 12:44 --- The XML parsing is done by the XML parser. If the parser doesn't like your XML, it will throw an exception. Whether or not it is the right thing to do or a bug in the parser is another question, but it's not a Tomcat bug. Tomcat 4.1.12 includes Xerces 2.0.2 (by accident). Tomcat 4.1.13 was supposed to include Xerces 2.1.0. The question is now: which version should I include ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.properties.default
remm2002/10/03 05:56:39
Modified:.build.properties.default
Log:
- New Xerces version.
Revision ChangesPath
1.38 +3 -3 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- build.properties.default 18 Sep 2002 11:44:21 - 1.37
+++ build.properties.default 3 Oct 2002 12:56:39 - 1.38
@@ -104,11 +104,11 @@
# - Xerces XML Parser, version 2.1.0 or later -
-xerces.home=${base.path}/xerces-2_1_0
+xerces.home=${base.path}/xerces-2_2_0
xerces.lib=${xerces.home}
xercesImpl.jar=${xerces.lib}/xercesImpl.jar
xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
-xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.1.0.tar.gz
+xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.2.0.tar.gz
# --
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13241] - Tomcat 4.1.12 / Webapps:Examples / Disabled
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=13241. 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=13241 Tomcat 4.1.12 / Webapps:Examples / Disabled --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 13:13 --- I can certainly say that Xerces-2_1_0 is compatible as servlets and JSP pages work without any problems. Perhaps one option would be to recommend xerces- 2_1_0 for the time being until the problem is discovered with xerces-2_2_0. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13241] - Tomcat 4.1.12 / Webapps:Examples / Disabled
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=13241. 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=13241 Tomcat 4.1.12 / Webapps:Examples / Disabled --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 13:30 --- From xerces-j2 2.2.0 announce : - Many conformance bugs have been fixed and the parser's performance enhanced in many situations. [Elena Litani, Sandy Gao, Neil Graham] So we may have some invalid xmls into 4.1.12 which should be discovered ? Did you try with others parser, ie crimson ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13164] - Compliance issue - VariableResolver.resolveVariable() fails to throw an ELException for an unresolvable variable.
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=13164. 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=13164 Compliance issue - VariableResolver.resolveVariable() fails to throw an ELException for an unresolvable variable. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13173] - NPE thrown by ELException.toString() if not originally created with a root cause exception.
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=13173. 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=13173 NPE thrown by ELException.toString() if not originally created with a root cause exception. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 14:39 --- Closing as the toString() method will be removed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13241] - Tomcat 4.1.12 / Webapps:Examples / Disabled
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=13241. 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=13241 Tomcat 4.1.12 / Webapps:Examples / Disabled --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 14:45 --- Okay, just tried Tomcat 4.1.12 with the XML being handled with crimson.jar and jaxp.jar and it worked like a charm. It certainly looks like the parsing in xerces-2_2_0 is causing a problem. While looking through the source code for XMLScanner.java in xerces (v2.2.0) I noticed that a slight rework had been performed in the scanComment function but there is nothing there which should cause the problem. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
jean-frederic clere wrote: Costin Manolache wrote: Mladen Turk wrote: -Original Message- On Behalf Of Costin Manolache Are we documenting all those settings - and the details on why/how :-) ? Sure, like everyone else ;). Yes, I know :-) I'll try to get over the horrible and nonstandard DTD that we use I agree for not standard DTD but horrible... Well it needs a lot of improvements but that means the xml files need to be reviewed carefully I would suggest to output messages when using weird elements to have time to rewrite the files. :-) Sorry about 'horrible'. What I meant is - the elements like section and almost everything else have an identical meaning as the standard XHTML or docbook element. It's a mix of elements - to do something that is already done and standard and accepted. What I find horrible is the fragmentation and missuse of XML ( not only here, but all over ). What's wrong with a subset of XHTML or Docbook ? Do we plan to beat W3C and Oasis in setting a standard for document dtd ? ( well, that's just me ranting - this has little to do with our xdocs, as I said I'll try to get over it and add to them ) -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
Actually, with the recent release of commons-logging, we should be able to get
rid of the explicit LogKit and Log4J. They're there so as to get a complete
build of commons-logging. Tomcat 5 itself doesn't use either directly.
Xerces is a different issue. There was a bug that was preventing Tomcat from
migrating to the latest version. Unfortunately, I no longer remember the
details. Anyone know why we're using 2.1.0 instead of 2.2.0?
On Thursday 03 October 2002 06:43 am, Christian Gross wrote:
Thank-you, but I still seem to get errors.
Namely the logkit from Avalon is referencing an old verion. I fixed it up
to the following
logkit.home=${base.path}/LogKit-1.1
logkit.lib=${logkit.home}
logkit.jar=${logkit.lib}/logkit-1.1.jar
logkit.loc=http://jakarta.apache.org/builds/jakarta-avalon/release/logkit/l
atest/LogKit-1.1-bin.tar.gz
xerces.home=${base.path}/xerces-2_2_0
xerces.lib=${xerces.home}
xercesImpl.jar=${xerces.lib}/xercesImpl.jar
xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.2.0.tar.gz
I do not know if you can commit changes, but these worked for me, since the
old versions either do not exist or the references have been made updated.
Christian Gross
At 09:40 PM 02/10/2002 -0400, you wrote:
You need to be using the HEAD version of digester. It should have been
built in the directory specified by base.path. Double check that it was
built correctly. I just recreated it in my depends directory, and the
system built fine.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs menu.jk2.idx
mturk 2002/10/03 08:32:51 Modified:jk/xdocs menu.jk2.idx Log: Split the jk2 menu. Revision ChangesPath 1.2 +12 -2 jakarta-tomcat-connectors/jk/xdocs/menu.jk2.idx Index: menu.jk2.idx === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/menu.jk2.idx,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- menu.jk2.idx 20 Sep 2002 15:43:01 - 1.1 +++ menu.jk2.idx 3 Oct 2002 15:32:51 - 1.2 @@ -1,6 +1,16 @@ ?xml version=1.0 encoding=ISO-8859-1? section name=JK2 -document href=jk2/configtc.xml/ -document href=jk2/configweb.xml/ /section +section name=Configuration in the Tomcat +document href=jk2/configtc.xml/ +document href=jk2/configtcex.xml/ +/section +section name=Configuration in the Web Server +document href=jk2/configweb.xml/ +document href=jk2/configwebcom.xml/ +document href=jk2/configwebex.xml/ +/section +section name=Installation +document href=jk2/installhowto.xml/ +/section \ No newline at end of file -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk2 configwebex.xml configwebcom.xml configtcex.xml
mturk 2002/10/03 08:33:41
Added: jk/xdocs/jk2 configwebex.xml configwebcom.xml configtcex.xml
Log:
Add new splitted documents
Revision ChangesPath
1.1 jakarta-tomcat-connectors/jk/xdocs/jk2/configwebex.xml
Index: configwebex.xml
===
?xml version=1.0?
document
properties
titleExamples/title
author email=[EMAIL PROTECTED]Costin Manolache/author
author email=[EMAIL PROTECTED]Jean-Frederic Clere/author
date$Date: 2002/10/03 15:33:41 $/date
/properties
section name=Sockets
p
The examples below are working when the Tomcat is configured according the
examples described in the configtc file.
/p
subsection name=/example using normal socket
p
Map /examples to the Tomcat /examples context using a normal socket. Note the
IP instead localhost (The JVM listens on the IPV4 address not no the IPV6).
/p
p
source
[shm]
file=${serverRoot}/logs/shm.file
size=1048576
# Example socket channel, override port and host.
[channel.socket:localhost:8019]
port=8019
host=127.0.0.1
# define the worker
[ajp13:localhost:8019]
channel=channel.socket:localhost:8019
# Uri mapping
[uri:/examples/*]
worker=ajp13:localhost:8019
/source
/p
/subsection
subsection name=/jkstatus
p
Map /jkstatus to the status worker.
/p
p
source
[shm]
file=${serverRoot}/logs/shm.file
size=1048576
# define the worker
[status:status]
# Uri mapping
[uri:/jkstatus/*]
worker=status:status
/source
/p
/subsection
subsection name=/example using AF_UNIX socket
p
Map /examples to the Tomcat /examples context using a AF_UNIX socket.
Socket file is create by the Tomcat becarefull when the Web Server runs in
a different user than the Tomcat with the permission of the socket file:
source
apache20@jfcexpert:~/apache ls -l
/home1/jakarta/jakarta-tomcat-4.1/dist/work/jk2.socket
srw-rw1 jakarta jakarta 0 Jun 20 08:27
/home1/jakarta/jakarta-tomcat-4.1/dist/work/jk2.socket
/source
Here the Tomcat user and the Web Server user must be in the same group.
/p
p
source
[shm]
file=${serverRoot}/logs/shm.file
size=1048576
# Example unixsocket channel.
[channel.un:unixsocket]
file=/home1/jakarta/jakarta-tomcat-4.1/dist/work/jk2.socket
# define the worker
[ajp13:unixsocket]
channel=channel.un:unixsocket
# Uri mapping
[uri:/examples/*]
worker=ajp13:unixsocket
/source
/p
/subsection
/section
section name=JNI
/section
/document
1.1 jakarta-tomcat-connectors/jk/xdocs/jk2/configwebcom.xml
Index: configwebcom.xml
===
?xml version=1.0?
document
properties
titleComponents/title
author email=[EMAIL PROTECTED]Costin Manolache/author
author email=[EMAIL PROTECTED]Jean-Frederic Clere/author
date$Date: 2002/10/03 15:33:41 $/date
/properties
section name=IntropEach component instance has a name, that is used for
configuration and at runtime. Each component has a number of configurable properties.
The following rules are used:
ulliThe name is composed from the type and a local part, separated with a ':' (
example: channel.unixsocket:/tmp/jk.socket ) /li
liThe 'type' consist of '.' and ascii characters. It is mapped to a JMX 'domain'.
/li
liThe local part consists of ascii characters and .:/;
pNote that '=,' are not currently allowed - a future version may support the jmx
syntax by using quotes to separate the local part from the property and value ( in
.properties mode we must use '=' to separate the value from type, local name and
property name ). /p/li
liThe property is a simple name, with no dots. /li
liA simple form of substitution is used in values, where $(property) will be
replaced with a previously defined setting. If the property has ':' in it, it'll take
the value from the object, if not it'll take the value from a global map./li/ul/p
/section
section name=Common properties
pCommon properties for all components/p
p
table
tr
thProperty name/th
thDefault/th
thDescription/th
/tr
tr
tddisabled/td
td0 (false)/td
tddisabled state for the component, 1=true 0=false/td
/tr
tr
tddebug/td
td0 (false)/td
tddebug state
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk2 configweb.xml configtc.xml
mturk 2002/10/03 08:34:10
Modified:jk/xdocs/jk2 configweb.xml configtc.xml
Log:
Add new splitted documents
Revision ChangesPath
1.12 +1 -592jakarta-tomcat-connectors/jk/xdocs/jk2/configweb.xml
Index: configweb.xml
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk2/configweb.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- configweb.xml 3 Oct 2002 10:52:16 - 1.11
+++ configweb.xml 3 Oct 2002 15:34:10 - 1.12
@@ -1,7 +1,7 @@
?xml version=1.0?
document
properties
-titleConfiguration in the Web Server/title
+titleConfiguration file/title
author email=[EMAIL PROTECTED]Costin Manolache/author
author email=[EMAIL PROTECTED]Jean-Frederic Clere/author
date$Date$/date
@@ -37,596 +37,5 @@
PROPERTY=VALUE
/source
/p
-/section
-section name=ComponentspEach component instance has a name, that is used
for configuration and at runtime. Each component has a number of configurable
properties. The following rules are used:
-ulliThe name is composed from the type and a local part, separated with a ':' (
example: channel.unixsocket:/tmp/jk.socket ) /li
-liThe 'type' consist of '.' and ascii characters. It is mapped to a JMX
'domain'. /li
-liThe local part consists of ascii characters and .:/;
-pNote that '=,' are not currently allowed - a future version may support the jmx
syntax by using quotes to separate the local part from the property and value ( in
.properties mode we must use '=' to separate the value from type, local name and
property name ). /p/li
-liThe property is a simple name, with no dots. /li
-liA simple form of substitution is used in values, where $(property) will be
replaced with a previously defined setting. If the property has ':' in it, it'll take
the value from the object, if not it'll take the value from a global map./li/ul/p
-subsection name=Common properties
-pCommon properties for all components/p
-p
-table
-tr
-thProperty name/th
-thDefault/th
-thDescription/th
-/tr
-tr
-tddisabled/td
-td0 (false)/td
-tddisabled state for the component, 1=true 0=false/td
-/tr
-tr
-tddebug/td
-td0 (false)/td
-tddebug state for the component, 1=true 0=false/td
-/tr
-/table
-/p
-/subsection
-subsection name=workerEnv
-pThis component represent the core jk2, it has the default logger for
all other components. Is the central controller, it controls global properties
-and provides access to all other objects/p
-p
-table
-tr
-thProperty name/th
-thDefault/th
-thDescription/th
-/tr
-tr
-tdlogger/td
-tdlogger/td
-tdDefault loger used by jk2 components, can be changed in
the config file, normally it defaults to logger the Alias for the default logger for
the Server/platform./td
-/tr
-tr
-tdtiming/td
-td0/td
-tdWill jk2 get request timing (needs APR?)/td
-/tr
-/table
-/p
-/subsection
-subsection name=config
-pThe config component, hold the detail of the conifg system, such
config file name, create global defines/p
-p
-table
-tr
- thProperty name/th
- thDefault/th
- thDescription/th
-/tr
-tr
-tdfile/td
-td${serverRoot}/conf/workers2.properties/td
-tdLocation of the workers2.properties file/td
-/tr
-tr
-tddebug/td
-td0/td
-tdSet the debug level of the config component/td
-/tr
-tr
-tddebugEnv/td
-td0/td
-tdSet the debug level of the hidden env component /td
-/tr
-/table
-
probably bug in bodycontent JSP in tomcat 4.0.5??
hi,
I got little problem with Tomcat 4.0.5 (I don't know if this version is still in
develoment) it appears in taglibs, specially in bodycontentJSP/bodycontent and i
think it's bug.. before i report i'm asking you is it (I hope i'm wrong this time)
It goes like this:
i have this kind of tags:
tag
nameShowContent/name
tagclasscom.ilmi.net.content.AContentShowTag/tagclass
bodycontentJSP/bodycontent
infoShow content/info
...continues
/tag
tag
namePrint/name
tagclasscom.ilmi.net.content.AContentPrintTag/tagclass
bodycontentJSP/bodycontent
infoShow just some Content/info
.. continues
/tag
with this (if i read specifcation right) all the HTML and other stuff should be
printed allso not just JSP output (Right??)
So i have JSP page:
HTML
HEAD
TITLECONTENT TAGS EXAMPLES/TITLE
/HEAD
BODY
%-- First we must import some Tag libraries --%
%@ taglib uri=ilmi/ilmi-content prefix=content%
h1Testing content tags separated/h1
%-- Then we create some content handler. with database connection --%
content:ShowContent mode=local upload=content_example.jsp
connector=/home/tuukka/src/java/common/pdf_example.xml
contenttable=contents articletable=articles filetable=files
imagetable=images
key=test language=en
%-- This is for adding content if we want to this isn't 'must' --%
content:AddContent /
test.
content:Print type=header prefix=h1Header/h1 suffix=BR /
content:Print type=teaser prefix=h1Teaser/h1 suffix=BR /
content:Print type=content prefix=h1Content/h1 suffix=BR
/
content:Print type=date prefix=h1Date/h1 suffix=BR /
test2.
A HREF=content_example.jsp?control=addAdd new message/A
/content:ShowContent
/BODY
/HTML
it's for testing so it's looks stupid.. i can get JSP output put not those test and
test2.. (Now comes fun part) they appears in jasper parsed code like this..
[SNIP]
// end
// begin [file=/content_tags_example.jsp;from=(14,1);to=(17,29)]
/* content:ShowContent */
com.ilmi.net.content.AContentShowTag _jspx_th_content_ShowContent_0 =
new com.ilmi.net.content.AContentShowTag();
_jspx_th_content_ShowContent_0.setPageContext(pageContext);
_jspx_th_content_ShowContent_0.setParent(null);
_jspx_th_content_ShowContent_0.setMode(local);
_jspx_th_content_ShowContent_0.setUpload(content_example.jsp);
_jspx_th_content_ShowContent_0.setConnector(/home/tuukka/src/java/common/pdf_example.xml);
_jspx_th_content_ShowContent_0.setContenttable(contents);
_jspx_th_content_ShowContent_0.setArticletable(articles);
_jspx_th_content_ShowContent_0.setFiletable(files);
_jspx_th_content_ShowContent_0.setImagetable(images);
_jspx_th_content_ShowContent_0.setKey(test);
_jspx_th_content_ShowContent_0.setLanguage(en);
try {
int _jspx_eval_content_ShowContent_0 =
_jspx_th_content_ShowContent_0.doStartTag();
if (_jspx_eval_content_ShowContent_0 !=
javax.servlet.jsp.tagext.Tag.SKIP_BODY) {
try {
if (_jspx_eval_content_ShowContent_0 !=
javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE) {
out = pageContext.pushBody();
_jspx_th_content_ShowContent_0.setBodyContent((javax.servlet.jsp.tagext.BodyContent)
out);
_jspx_th_content_ShowContent_0.doInitBody();
}
do {
// end
// HTML // begin
[file=/content_tags_example.jsp;from=(17,29);to=(19,1)]
out.write(\n\n\t);
// end
// HTML // begin
[file=/content_tags_example.jsp;from=(19,69);to=(20,8)]
out.write(\n);
// end
// begin
[file=/content_tags_example.jsp;from=(20,8);to=(20,30)]
/* content:AddContent */
com.ilmi.net.content.AContentAddTag
_jspx_th_content_AddContent_0 = new com.ilmi.net.content.AContentAddTag();
_jspx_th_content_AddContent_0.setPageContext(pageContext);
_jspx_th_content_AddContent_0.setParent(_jspx_th_content_ShowContent_0);
try {
int _jspx_eval_content_AddContent_0 =
_jspx_th_content_AddContent_0.doStartTag();
if (_jspx_eval_content_AddContent_0 !=
Re: Is Compile Failure? was Re: Need some clarifications
Steve Downey wrote: Actually, with the recent release of commons-logging, we should be able to get rid of the explicit LogKit and Log4J. They're there so as to get a complete build of commons-logging. Tomcat 5 itself doesn't use either directly. Xerces is a different issue. There was a bug that was preventing Tomcat from migrating to the latest version. Unfortunately, I no longer remember the details. Anyone know why we're using 2.1.0 instead of 2.2.0? From what I experienced with Xerces j 2.2.0 it seems it does much more validity check and for instance found a '--' somewhere in comments (1 EUR to the first who find where). Previous version of Xerces or crimson didn't got that problem. if we could see which xml/dtd/tld is reported buggy, which will able to see if it's a bug or a features (ie a more strict check of xml rules) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13081] - ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes
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=13081. 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=13081 ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 16:18 --- *** This bug has been marked as a duplicate of 13132 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13132] - missing declaration of variable
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=13132. 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=13132 missing declaration of variable [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 16:18 --- *** Bug 13081 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
Costin Manolache wrote: jean-frederic clere wrote: Costin Manolache wrote: Mladen Turk wrote: -Original Message- On Behalf Of Costin Manolache Are we documenting all those settings - and the details on why/how :-) ? Sure, like everyone else ;). Yes, I know :-) I'll try to get over the horrible and nonstandard DTD that we use I agree for not standard DTD but horrible... Well it needs a lot of improvements but that means the xml files need to be reviewed carefully I would suggest to output messages when using weird elements to have time to rewrite the files. :-) Sorry about 'horrible'. What I meant is - the elements like section and almost everything else have an identical meaning as the standard XHTML or docbook element. It's a mix of elements - to do something that is already done and standard and accepted. What I find horrible is the fragmentation and missuse of XML ( not only here, but all over ). What's wrong with a subset of XHTML or Docbook ? The first idea was to save us from writing XML tags and concentrate in the text. We have ended defining a dtd that fits our needs with typing the minimum... Do we plan to beat W3C and Oasis in setting a standard for document dtd ? No, but extending one dtd would be better than reinventing everything. I will try to make a cleanup as soon as I have time. (docs need a lot of time). ( well, that's just me ranting - this has little to do with our xdocs, as I said I'll try to get over it and add to them ) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime JspContextWrapper.java
luehe 2002/10/03 09:50:05 Modified:jasper2/src/share/org/apache/jasper/runtime JspContextWrapper.java Log: Changed class comment Revision ChangesPath 1.4 +9 -5 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspContextWrapper.java Index: JspContextWrapper.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspContextWrapper.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- JspContextWrapper.java12 Sep 2002 20:48:17 - 1.3 +++ JspContextWrapper.java3 Oct 2002 16:50:05 - 1.4 @@ -84,8 +84,12 @@ import javax.servlet.jsp.el.VariableResolver; /** - * A wrapper class for PageContext class used for providing a tempory - * page scope for invoking a fragment + * Implementation of a JSP Context Wrapper. + * + * The JSP Context Wrapper is a JspContext created and maintained by a tag + * handler implementation. It wraps the Invoking JSP Context, that is, the + * JspContext instance passed to the tag handler by the invoking page via + * setJspContext(). * * @author Kin-man Chung */ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-5 build.properties.default
This causes all 181 Watchdog JSP tests to fail.
I don't know why yet, and it's probably something simple, but it's not a good
sign.
On Thursday 03 October 2002 08:56 am, [EMAIL PROTECTED] wrote:
remm2002/10/03 05:56:39
Modified:.build.properties.default
Log:
- New Xerces version.
Revision ChangesPath
1.38 +3 -3 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- build.properties.default18 Sep 2002 11:44:21 - 1.37
+++ build.properties.default3 Oct 2002 12:56:39 - 1.38
@@ -104,11 +104,11 @@
# - Xerces XML Parser, version 2.1.0 or later -
-xerces.home=${base.path}/xerces-2_1_0
+xerces.home=${base.path}/xerces-2_2_0
xerces.lib=${xerces.home}
xercesImpl.jar=${xerces.lib}/xercesImpl.jar
xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
-xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.1.0.tar.gz
+xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.2.0.tar.gz
# --
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk2 configwebcom.xml
costin 2002/10/03 09:57:49 Modified:jk/xdocs index.xml jk/xdocs/jk2 configwebcom.xml Log: Added the 'version' common property. Few addition and fixes in the description of jk2. Revision ChangesPath 1.11 +23 -7 jakarta-tomcat-connectors/jk/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/index.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- index.xml 23 Sep 2002 14:59:39 - 1.10 +++ index.xml 3 Oct 2002 16:57:49 - 1.11 @@ -13,7 +13,7 @@ It was a completely new Tomcat-Apache plug-in that handles the communication between Tomcat and Apache. /p p -The newest bJK2/b is a rewrite of bJK/b. +The newest bJK2/b is a refactoring of bJK/b. The native part has been completly restructured and the configuration has been simplified a lot. /p @@ -75,19 +75,35 @@ section name=What's the difference between JK and JK2 ? p -JK2 is a full rewrite of JK and is much more powerfull. +JK2 is a refactoring of JK and is much more powerfull. /p p Even if it works with Apache 1.3, JK2 has been developed with Apache 2.0 in mind, -and sus is better suited for multi-threaded servers like IIS, NES/iPlanet. +and is better suited for multi-threaded servers like IIS, NES/iPlanet. It can also +be embeded in other applications and used from java. /p p -JK2 has a better separation between protocol and physical layer. +JK2 improves the modularity and has a better separation between protocol and physical layer. As such JK2 support fast unix-socket, and could be extended to support others communications -channels. Better it's suited for JNI and JDK 1.4 fast IO APIs +channels. It is better suited for JNI and may use (in a future version) JDK 1.4 NIO. /p p -JK2 could be monitored via special URLs (like mod_status) +There is additional support for monitoring, similar with JMX in java. A module similar +with mod_status is provided, and additional adapters can be used to interface and +provide status and runtime configuration. . +/p +p +The configuration has been changed to follow the component models. Multiple configuration +sources can be supported ( in additon to file ) providing better integration with +the embeding application. The config layer uses the management layer APIs and it can +support persistence for changes done via runtime configuration. +/p +p +Another feature is the JNI mode. Jk2 can be used as a JNI library and provide access to +native features to java. For example it provides access to shared memory ( used for +config and monitoring in a multiprocess environment ), unix domain sockets. It can +also provide access to signals, chuid, win registry. All using the same communication +mechansim, and supporting both in-process and out-of process modes. /p /section 1.2 +11 -2 jakarta-tomcat-connectors/jk/xdocs/jk2/configwebcom.xml Index: configwebcom.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk2/configwebcom.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- configwebcom.xml 3 Oct 2002 15:33:41 - 1.1 +++ configwebcom.xml 3 Oct 2002 16:57:49 - 1.2 @@ -31,8 +31,17 @@ tr tddebug/td td0 (false)/td -tddebug state for the component, 1=true 0=false/td +tdDebug level for the component, 0=disabled, 1..10 enabled. Higher levels +generate more debug./td /tr +tr +tdversion/td +td0/td +td'Generation' of the component config. Important for runtime reconfiguration. +If you edit the config file or set the shmem properties, you need to also +upgrade the version of the modified component. The config layer will detect +the change and call the setter method./td + /tr /table /p /section -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12694] - POST requests fail after server failover
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=12694. 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=12694 POST requests fail after server failover [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 17:13 --- I fixed this bug in mod_jk2. Not sure how difficult it is to backport to jk1, the error handling and recovery was reorganized ( to get around other bugs). I'll mark this as fixed - please reopen it if you still have problems ( with jk2) or if you need it backported. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13253] New: - Migration problems with Tomcat 4.1.10. Please help.
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=13253. 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=13253 Migration problems with Tomcat 4.1.10. Please help. Summary: Migration problems with Tomcat 4.1.10. Please help. Product: Tomcat 4 Version: 4.1.10 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Product:Java Web Application Operating system: Redhat Linux 7.3 Web Server: Apache 1.3.x Application server: Tomcat 4.1.10 Database server:MySQL 3.23.x Java Architecture: JSP (presentation) + Java Bean (Business logic) JDK version:1.3.1_04 Hi, When we tried to migrate our application from Tomcat 4.0.4 to Tomcat 4.1.10, we found that the relative path references like ../xyz/ab.jsp are not properly interpreted by Netscape and the url seen on the address bar is something like this (http://www.sww.com/../xyz/ab.jsp. Also dynamic jsp forwarding support seems to have changed. While forwarding, the dynamic parameters attached are automatically url encoded. We have tested our application on Tomcat 4.0.4, there were no such issues. Since we have used these sort of things in many places in our application it will be difficult for us to change in all those places. Can anybody tell us what we can do about it? thanks in advance, Srikanth. S. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12870] - CoyoteInputStream does not implement the available() method
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=12870. 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=12870 CoyoteInputStream does not implement the available() method [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 17:19 --- Added available() for tomcat4 and 5. Tomcat3 does have it already. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
Henri Gomez wrote: Steve Downey wrote: Actually, with the recent release of commons-logging, we should be able to get rid of the explicit LogKit and Log4J. They're there so as to get a complete build of commons-logging. Tomcat 5 itself doesn't use either directly. Xerces is a different issue. There was a bug that was preventing Tomcat from migrating to the latest version. Unfortunately, I no longer remember the details. Anyone know why we're using 2.1.0 instead of 2.2.0? Because, I think, Xerces 2.2.0 was relased two weeks ago. I'm actually testing Xerces 2.2.knowing how much problem we have with Xerces 2.0.1 - 2.0.2 and XML Schema, I just want to be sure there is no regression ;-) -- Jeanfrancois From what I experienced with Xerces j 2.2.0 it seems it does much more validity check and for instance found a '--' somewhere in comments (1 EUR to the first who find where). Previous version of Xerces or crimson didn't got that problem. if we could see which xml/dtd/tld is reported buggy, which will able to see if it's a bug or a features (ie a more strict check of xml rules) -- 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]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteInputStream.java
costin 2002/10/03 10:20:52
Modified:coyote/src/java/org/apache/coyote/tomcat4
CoyoteInputStream.java
coyote/src/java/org/apache/coyote/tomcat5
CoyoteInputStream.java
Log:
Added available().
PR: 12870
Revision ChangesPath
1.2 +4 -0
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteInputStream.java
Index: CoyoteInputStream.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteInputStream.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- CoyoteInputStream.java7 Mar 2002 04:27:23 - 1.1
+++ CoyoteInputStream.java3 Oct 2002 17:20:52 - 1.2
@@ -133,6 +133,10 @@
}
+public int available() throws IOException {
+if( pos end ) return end-pos;
+return 0;
+}
public int read(byte[] b) throws IOException {
1.2 +4 -0
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteInputStream.java
Index: CoyoteInputStream.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteInputStream.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- CoyoteInputStream.java4 Aug 2002 19:39:49 - 1.1
+++ CoyoteInputStream.java3 Oct 2002 17:20:52 - 1.2
@@ -133,6 +133,10 @@
}
+public int available() throws IOException {
+if( pos end ) return end-pos;
+return 0;
+}
public int read(byte[] b) throws IOException {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5.0] [VOTE] Removal of the LE distribution
Hi all, Before starting to release 5.0.x milestones, I would like to propose having only one distribution for Tomcat 5.0.x, and standardize on what the LE distribution contains (so well, it's more the other distribution which gets removed). It has some advantages: - it is slightly smaller (less these days now that the XML parser has to be shipped again with Tomcat) - runs as-is on JDK 1.3 (because of the Xerces inclusion) - 99% Apache or Apache-style licence (the JDBC 2 standard extension is needed for JDK 1.3 DataSource support :-() - less user confusion The main problem is that the user will need additional downloads for some of the more advanced features, and the package will also not run on JDK 1.2 as is (but from what I've seen, JDK 1.2 compatibility may not be a priority for developers). ballot +1 [ ] Yes, remove the LE distribution -1 [ ] No, keep both distributions /ballot Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13253] - Migration problems with Tomcat 4.1.10. Please help.
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=13253. 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=13253 Migration problems with Tomcat 4.1.10. Please help. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 17:28 --- Please do not file user questions as bugs (only report specific issues, with a test case, or detailed instructions on how to reproduce the problem). Use one of the support channels for that. Also, try to test with the latest available release when possible. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Weird seg fault on Mac OS X for mod_jk2 + Apache2
Han Ming Ong wrote: I added a super simple workers2.properties file in the same dir and tried to start apache. I got a seg fault. Here's the stacktrace from Mac OS X default crash logger: Command:httpd PID:853 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x736f0028 Thread 0 Crashed: #0 0x90001600 in strlen #1 0x900023e0 in vfprintf #2 0x90015ee0 in __sbprintf #3 0x900018a8 in vfprintf #4 0x900017ec in fprintf #5 0x0060fdbc in jk2_map_default_get (jk_map.c:97) -- it's '97' because I added printf Are you using the commented-out printf ? It is possible that one of name or value is null - printf is not checking for null on many OS. Try using apr printf, or check for null. Here's output with some printf statements inserted in jk_map.c: entering for threadMutex (no. maps: 25) 0: logger.file (°Z°Z°Z°Z°Z°Z) - funny output is from fprintf(stderr,%s, mPriv-values[i]) Can you add printf to map_put also ? The value in this case is the jk_env structure ( or jk_log ?), it's normal to be 'funny'. I would print it as %p, it's a struct *. ( at least for the object map ) entering for ver (no. maps: 1) 0: worker (ajp13:localhost:8009) done for ver [here it churns for a few seconds before segfaulting] bin/apachectl: line 87: 853 Segmentation fault $HTTPD -k $ARGV Anyone has a clue on what could be wrong? Just pointers would help. I tried following the stack trace but am temporarily thrown off by how jk2_env_createBean2() gets to jk2_map_default_get(), especially the second parameter's type. It seems to be casted from (char *) to (jk_map_t *), which is kind of weird. Not sure what you mean. The second parameter of env-getBean2( ) is string. jk2_env_getBean2 will call jk2_map_default_get ( actually, env-_objects-get ) with env-_objects as second param, which is a jk_map. Please check first the printf() params for null. Costin Appreciate it. Han Ming # workers2.properties # Shared memory handling. Needs to be set. [shm] file=/usr/local/apache2/logs/shm.file size=1048576 # Example socket channel, explicitly set port and host. [channel.socket:localhost:8009] port=8009 host=127.0.0.1 #keepalive=1 # define the worker [ajp13:localhost:8009] #channel=channel.un:/usr/local/tomcat/work/jk2.socket # To use the TCP/IP socket instead, just comment out the above # line, and uncomment the one below channel=channel.socket:localhost:8009 # Announce a status worker [status:status] # Uri mapping [uri:/examples/*] worker=ajp13:localhost:8009 #worker=ajp13:/usr/local/tomcat/work/jk2.socket [uri:/jkstatus/*] worker=status:status # end of workers2.properties -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
Jean-Francois Arcand wrote: Henri Gomez wrote: Steve Downey wrote: Actually, with the recent release of commons-logging, we should be able to get rid of the explicit LogKit and Log4J. They're there so as to get a complete build of commons-logging. Tomcat 5 itself doesn't use either directly. Xerces is a different issue. There was a bug that was preventing Tomcat from migrating to the latest version. Unfortunately, I no longer remember the details. Anyone know why we're using 2.1.0 instead of 2.2.0? Because, I think, Xerces 2.2.0 was relased two weeks ago. I'm actually testing Xerces 2.2.knowing how much problem we have with Xerces 2.0.1 - 2.0.2 and XML Schema, I just want to be sure there is no regression ;-) I upgraded the properties file (sorry, didn't know you hadn't done it on purpose), as IMO it's a good idea to test as much as possible since we're still in pre-alpha stages. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [VOTE] Removal of the LE distribution
On Thu, 2002-10-03 at 13:24, Remy Maucherat wrote: ballot +1 [X] Yes, remove the LE distribution -1 [ ] No, keep both distributions /ballot simpler is better. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PROPOSAL] Splitting docs for JK2
Mladen Turk wrote: -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED]] +0 (Ok but can't help right now) Could you check: http://jakarta.apache.org/~mturk/docs/ Looks good. Can you check in ? Henri: would you mind if we remove the reference to ajp14 ? I thought we decided we'll stick with ajp13 and just add new message types for the extra functions - so we should at least rename it to 'future extensions to ajp13'. In particular the config stuff should be also changed - to match with the current jk2 api ( i.e. generic get/set, etc ). All functionality can be added in some extra components - without affecting the current stability ( too much ), so if someone has time we can move this to a TODO list for future releases. -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
jean-frederic clere wrote: :-) Sorry about 'horrible'. What I meant is - the elements like section and almost everything else have an identical meaning as the standard XHTML or docbook element. It's a mix of elements - to do something that is already done and standard and accepted. What I find horrible is the fragmentation and missuse of XML ( not only here, but all over ). What's wrong with a subset of XHTML or Docbook ? The first idea was to save us from writing XML tags and concentrate in the text. We have ended defining a dtd that fits our needs with typing the minimum... I'm not sure I understand. How is this 'saving us' from writing XML tags? We still have to write XML tags, and what's worse - to learn a set of tags that we'll never use outside jk. As oposed to write the same thing using the tags we already know - subset of XHTML - or learn a set of tags that we'll likely use - a subset of docbook. And both XHTML and Docbook have editors and tools that would actually 'save us from writing XML' and concentrate on text. And plenty of stylesheets to generate pdf or whatever else. Do we plan to beat W3C and Oasis in setting a standard for document dtd ? No, but extending one dtd would be better than reinventing everything. I will try to make a cleanup as soon as I have time. (docs need a lot of time). ??? We do reinvent everything aparently - yet another non-standard document DTD. W3C and Oasis define some reasonable and widely used DTDs for that. If someone feels docbook is too complex - we can restrict ourselfs to a subset ( like linuxdoc did for a while ) , but we'll still benefit from some of the existing tools and what we already know. As I said, that's just me ranting - if the majority is happy with our private DTD for docs - I'll have to use it ( but that doesn't mean I have to like it ). -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [VOTE] Removal of the LE distribution
Remy Maucherat wrote: Hi all, Before starting to release 5.0.x milestones, I would like to propose having only one distribution for Tomcat 5.0.x, and standardize on what the LE distribution contains (so well, it's more the other distribution which gets removed). It has some advantages: - it is slightly smaller (less these days now that the XML parser has to be shipped again with Tomcat) - runs as-is on JDK 1.3 (because of the Xerces inclusion) - 99% Apache or Apache-style licence (the JDBC 2 standard extension is needed for JDK 1.3 DataSource support :-() - less user confusion The main problem is that the user will need additional downloads for some of the more advanced features, and the package will also not run on JDK 1.2 as is (but from what I've seen, JDK 1.2 compatibility may not be a priority for developers). ballot +1 [X] Yes, remove the LE distribution -1 [ ] No, keep both distributions /ballot What would it take to be 100% Apache-style licence ? Can we do some introspection tricks or conditional compilation to solve this ? -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
On Thursday 03 October 2002 12:14 pm, Henri Gomez wrote: Steve Downey wrote: Actually, with the recent release of commons-logging, we should be able to get rid of the explicit LogKit and Log4J. They're there so as to get a complete build of commons-logging. Tomcat 5 itself doesn't use either directly. Xerces is a different issue. There was a bug that was preventing Tomcat from migrating to the latest version. Unfortunately, I no longer remember the details. Anyone know why we're using 2.1.0 instead of 2.2.0? From what I experienced with Xerces j 2.2.0 it seems it does much more validity check and for instance found a '--' somewhere in comments (1 EUR to the first who find where). Previous version of Xerces or crimson didn't got that problem. if we could see which xml/dtd/tld is reported buggy, which will able to see if it's a bug or a features (ie a more strict check of xml rules) Going through my old mail, I was remembering the 2.0.1/2.0.2 problems that were keeping us on xerces nightly for a while. 2.1.0 fixed those problems. This seems to be a problem in parsing the 1.2 taglibs DTD. This one fails http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd where this one http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd succeeds. Failure is at line 307, column 39. But I don't see anything significant there. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [5.0] [VOTE] Removal of the LE distribution
Oops! sorry, I missed my vote. ballot +1 [X] Yes, remove the LE distribution -1 [ ] No, keep both distributions /ballot -Original Message- From: iasandcb [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 3:06 AM To: 'Tomcat Developers List' Subject: RE: [5.0] [VOTE] Removal of the LE distribution First all, I vote ballot +1 [ ] Yes, remove the LE distribution -1 [ ] No, keep both distributions /ballot Next, I'd like to make this clear: Tomcat 5 is based on JSP 2.0 spec, which requires J2SE 1.4. Therefore Tomcat 5 also can't run without J2SE 1.4 ideally. However, I found that the new catalina engine and jasper 2 compiler for Tomcat 5 don't mandate so. Is J2SE 1.4(or later) necessary for Tomcat 5? Or does Tomcat 5 support J2SE 1.3(or earlier) for backward compatibitity with disabled JSP 2 feature? My opinion on this issue is that Tomcat 5 should have J2SE 1.4 in compliance with JSP 2.0 spec basically. IAS -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 2:24 AM To: Tomcat Developers List Subject: [5.0] [VOTE] Removal of the LE distribution Hi all, Before starting to release 5.0.x milestones, I would like to propose having only one distribution for Tomcat 5.0.x, and standardize on what the LE distribution contains (so well, it's more the other distribution which gets removed). It has some advantages: - it is slightly smaller (less these days now that the XML parser has to be shipped again with Tomcat) - runs as-is on JDK 1.3 (because of the Xerces inclusion) - 99% Apache or Apache-style licence (the JDBC 2 standard extension is needed for JDK 1.3 DataSource support :-() - less user confusion The main problem is that the user will need additional downloads for some of the more advanced features, and the package will also not run on JDK 1.2 as is (but from what I've seen, JDK 1.2 compatibility may not be a priority for developers). ballot +1 [ ] Yes, remove the LE distribution -1 [ ] No, keep both distributions /ballot Remy -- 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]
DO NOT REPLY [Bug 13223] - JSP pages in XML syntax do not compile properly
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=13223. 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=13223 JSP pages in XML syntax do not compile properly [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 18:15 --- On reading the spec more closely, I do not agree with the comment that this is (entirely) a spec bug. The spec, section 5.2.1 clearly states that the XML model supports a special attribute syntax for request-time expressions. The spec in 5.3.11 clarifies what that syntax is. The spec also clearly states, in section 5.3.1 that only 2 transformations are performed to map a JSP page in XML syntax to the XML view of that page. As far as the custom actions are concerned, the fact that they work in the non-XML syntax, coupled with the Spec' expression that they are equally valid within the XML syntax, implies that they should work in the same manner. Granted, the spec is unclear as to how non-expression items should be handled in XML syntax for attribute values, and this should be brought to the specification lead's attention, but it would seem reasonable to have Tomcat either document an expected manner of handling them (perhaps replacing the with lt; and gt;) and permit this usage while the spec group works out how this mechanism should be handled... If Tomcat is to be fully compliant with JSP 1.2, at the very least the specified XML expression syntax (attribute='%=item.getValue%') should be supported; as it is even this path is closed(the page processor completely ignores the expression and passes it through unprocessed). As a maximally useful tool, Tomcat would be best with the mechanism for handling standard actions within attribute values in the JSP syntax linked into the processing path for the XML syntax until the 1.2 spec can be clarified (or the issue is resolved in JSP 2.0). The notes on the similar bug 10683 indicate that something was brought up to the Spec group, but no response was heard. Since Tomcat is considered the reference implementation for the spec; would it perhaps be wise to keep a separate low-priority bug open here to ensure that the specification issue is tracked to resolution(and the clarification implemented) and to help regularly remind the specification group of the problem? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13223] - JSP pages in XML syntax do not compile properly
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=13223. 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=13223 JSP pages in XML syntax do not compile properly --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 18:16 --- Created an attachment (id=3337) Here's an additional test case for the expression syntax. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13254] New: - Page compilation errors missing resource entries
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=13254. 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=13254 Page compilation errors missing resource entries Summary: Page compilation errors missing resource entries Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When Jasper throws an exception while attempting to compile a JSP page to a Java file, it attempts to look up error strings in a resource file and cannot find the the resource ID. Attached is an example error message, note that the root cause is a failure in the resource lookup. This makes it quite difficult to debug JSP page compilation issues as the source of the issue is masked by this issue. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13254] - Page compilation errors missing resource entries
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=13254. 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=13254 Page compilation errors missing resource entries --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 18:25 --- Created an attachment (id=3338) Sample Error Report showing the issue -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [5.0] [VOTE] Removal of the LE distribution
iasandcb wrote: First all, I vote ballot +1 [ ] Yes, remove the LE distribution -1 [ ] No, keep both distributions /ballot Next, I'd like to make this clear: Tomcat 5 is based on JSP 2.0 spec, which requires J2SE 1.4. Therefore Tomcat 5 also can't run without J2SE 1.4 ideally. However, I found that the new catalina engine and jasper 2 compiler for Tomcat 5 don't mandate so. Is J2SE 1.4(or later) necessary for Tomcat 5? Or does Tomcat 5 support J2SE 1.3(or earlier) for backward compatibitity with disabled JSP 2 feature? My opinion on this issue is that Tomcat 5 should have J2SE 1.4 in compliance with JSP 2.0 spec basically. What ??? Where did you find this info ? I read the JSP2.0 draft and didn't find such thing. It would be just stupid - I don't know any other spec to require more than Java2 (i.e. JDK1.2+). If the final spec is aproved and includes JDK1.4 requirements - then there's nothing we can do, we'll have to stop supporting 1.3 in the official tomcat distibution. But given that now the 2 specs are distinct - and some people use only the servlet spec, I think the servlet engine and connectors should remain JDK1.2+. Costin IAS -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 2:24 AM To: Tomcat Developers List Subject: [5.0] [VOTE] Removal of the LE distribution Hi all, Before starting to release 5.0.x milestones, I would like to propose having only one distribution for Tomcat 5.0.x, and standardize on what the LE distribution contains (so well, it's more the other distribution which gets removed). It has some advantages: - it is slightly smaller (less these days now that the XML parser has to be shipped again with Tomcat) - runs as-is on JDK 1.3 (because of the Xerces inclusion) - 99% Apache or Apache-style licence (the JDBC 2 standard extension is needed for JDK 1.3 DataSource support :-() - less user confusion The main problem is that the user will need additional downloads for some of the more advanced features, and the package will also not run on JDK 1.2 as is (but from what I've seen, JDK 1.2 compatibility may not be a priority for developers). ballot +1 [ ] Yes, remove the LE distribution -1 [ ] No, keep both distributions /ballot Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
On Thursday, October 3, 2002, at 09:14 AM, Henri Gomez wrote: Steve Downey wrote: Actually, with the recent release of commons-logging, we should be able to get rid of the explicit LogKit and Log4J. They're there so as to get a complete build of commons-logging. Tomcat 5 itself doesn't use either directly. Xerces is a different issue. There was a bug that was preventing Tomcat from migrating to the latest version. Unfortunately, I no longer remember the details. Anyone know why we're using 2.1.0 instead of 2.2.0? From what I experienced with Xerces j 2.2.0 it seems it does much more validity check and for instance found a '--' somewhere in comments (1 EUR to the first who find where). :-) I scanned though quite a lot of xml/dtd/tld in 4.1.12, hoping to get that elusive 1 EUR. Not such luck. The only thing that I can come up with is: the TLDs are referring an DTD that has been moved by Sun. Here's what you get when you go to http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_2.dtd The file named http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_2.dtd has been renamed to http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd in the most current version of the specification. Please update your application to use the new name. Thus, if the parser has been set to be validating, it would fail (albeit with a different error). Maybe updating the DOCTYPE in the TLDs should help? Previous version of Xerces or crimson didn't got that problem. if we could see which xml/dtd/tld is reported buggy, which will able to see if it's a bug or a features (ie a more strict check of xml rules) -- 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]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
kinman 2002/10/03 12:25:19
Modified:jasper2/src/share/org/apache/jasper/compiler Tag:
tomcat_4_branch Generator.java
Log:
- Fix 13144: Ending comment eats up line following.
Revision ChangesPath
No revision
No revision
1.35.2.9 +4 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.35.2.8
retrieving revision 1.35.2.9
diff -u -r1.35.2.8 -r1.35.2.9
--- Generator.java10 Sep 2002 00:36:23 - 1.35.2.8
+++ Generator.java3 Oct 2002 19:25:18 - 1.35.2.9
@@ -625,6 +625,7 @@
public void visit(Node.Scriptlet n) throws JasperException {
n.setBeginJavaLine(out.getJavaLine());
out.printMultiLn(new String(n.getText()));
+ out.println();
n.setEndJavaLine(out.getJavaLine());
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
costin 2002/10/03 12:31:31
Modified:jk/java/org/apache/jk/server JkMain.java
Log:
If only Ajp connector is used, nobody will initialize the https: handler
and redirects for https sites will fail ( a URL constructor is used somewhere ).
PR: 11657
Submitted by: [EMAIL PROTECTED]
Revision ChangesPath
1.30 +20 -0
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java
Index: JkMain.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- JkMain.java 9 Aug 2002 20:54:23 - 1.29
+++ JkMain.java 3 Oct 2002 19:31:31 - 1.30
@@ -124,12 +124,32 @@
modules.put(shm, org.apache.jk.common.Shm);
modules.put(request,org.apache.jk.common.HandlerRequest);
modules.put(container,org.apache.jk.common.HandlerRequest);
+
+initHTTPSUrls();
}
public static JkMain getJkMain() {
return jkMain;
}
+private static String DEFAULT_HTTPS=com.sun.net.ssl.internal.www.protocol;
+private void initHTTPSUrls() {
+try {
+// 11657: if only ajp is used, https: redirects need to work ( at least
for 1.3+)
+String value = System.getProperty(java.protocol.handler.pkgs);
+if (value == null) {
+value = DEFAULT_HTTPS;
+} else if (value.indexOf(DEFAULT_HTTPS) = 0 ) {
+return; // already set
+} else {
+value += | + DEFAULT_HTTPS;
+}
+System.setProperty(java.protocol.handler.pkgs, value);
+} catch(Exception ex ) {
+ex.printStackTrace();
+}
+}
+
// Setting
/** Load a .properties file into and set the values
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
kinman 2002/10/03 12:29:38
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
- Fix 13144.
Revision ChangesPath
1.105 +4 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.104
retrieving revision 1.105
diff -u -r1.104 -r1.105
--- Generator.java25 Sep 2002 19:15:24 - 1.104
+++ Generator.java3 Oct 2002 19:29:37 - 1.105
@@ -818,6 +818,7 @@
public void visit(Node.Scriptlet n) throws JasperException {
n.setBeginJavaLine(out.getJavaLine());
out.printMultiLn(new String(n.getText()));
+ out.println();
n.setEndJavaLine(out.getJavaLine());
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [5.0] [VOTE] Removal of the LE distribution
On Thu, 3 Oct 2002, Costin Manolache wrote: Date: Thu, 03 Oct 2002 11:30:47 -0700 From: Costin Manolache [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: [5.0] [VOTE] Removal of the LE distribution iasandcb wrote: First all, I vote ballot +1 [ ] Yes, remove the LE distribution -1 [ ] No, keep both distributions /ballot Next, I'd like to make this clear: Tomcat 5 is based on JSP 2.0 spec, which requires J2SE 1.4. Therefore Tomcat 5 also can't run without J2SE 1.4 ideally. However, I found that the new catalina engine and jasper 2 compiler for Tomcat 5 don't mandate so. Is J2SE 1.4(or later) necessary for Tomcat 5? Or does Tomcat 5 support J2SE 1.3(or earlier) for backward compatibitity with disabled JSP 2 feature? My opinion on this issue is that Tomcat 5 should have J2SE 1.4 in compliance with JSP 2.0 spec basically. What ??? Where did you find this info ? I read the JSP2.0 draft and didn't find such thing. It would be just stupid - I don't know any other spec to require more than Java2 (i.e. JDK1.2+). If the final spec is aproved and includes JDK1.4 requirements - then there's nothing we can do, we'll have to stop supporting 1.3 in the official tomcat distibution. But given that now the 2 specs are distinct - and some people use only the servlet spec, I think the servlet engine and connectors should remain JDK1.2+. The J2EE 1.4 (PFD) Platform Spec requires JDK 1.4. That is not directly relevant for Tomcat standalone releases. The Servlet 2.4 (PFD) Spec still says JDK 1.2 is the minimum (Section 1.2, last paragraph). This affects Catalina and Coyote code for Tomcat 5. The JSP 2.0 (PFD) Spec has implied dependencies on JDK 1.4, but I could not find any specific assertion to that effect -- cc'ing the JSP Spec feedback address above to suggest that this be clarified. This affects Jasper code in Tomcat 5. Personally, I think it would make Catalina/Coyote development, and Tomcat 5 packaging, a lot easier if we adopted JDK 1.4 as the minimum platform for Tomcat 5, but that is a separate decision from what the spec requirements are. Costin Craig IAS -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 2:24 AM To: Tomcat Developers List Subject: [5.0] [VOTE] Removal of the LE distribution Hi all, Before starting to release 5.0.x milestones, I would like to propose having only one distribution for Tomcat 5.0.x, and standardize on what the LE distribution contains (so well, it's more the other distribution which gets removed). It has some advantages: - it is slightly smaller (less these days now that the XML parser has to be shipped again with Tomcat) - runs as-is on JDK 1.3 (because of the Xerces inclusion) - 99% Apache or Apache-style licence (the JDBC 2 standard extension is needed for JDK 1.3 DataSource support :-() - less user confusion The main problem is that the user will need additional downloads for some of the more advanced features, and the package will also not run on JDK 1.2 as is (but from what I've seen, JDK 1.2 compatibility may not be a priority for developers). ballot +1 [ ] Yes, remove the LE distribution -1 [ ] No, keep both distributions /ballot Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx DynamicMBeanProxy.java
costin 2002/10/03 12:34:47
Modified:util/java/org/apache/tomcat/util/mx DynamicMBeanProxy.java
Log:
A fix in the object name ( ',' needs to be used as separator ).
Also added unregister - need for reloads.
Revision ChangesPath
1.7 +19 -5
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx/DynamicMBeanProxy.java
Index: DynamicMBeanProxy.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx/DynamicMBeanProxy.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- DynamicMBeanProxy.java18 Sep 2002 11:03:06 - 1.6
+++ DynamicMBeanProxy.java3 Oct 2002 19:34:47 - 1.7
@@ -129,10 +129,10 @@
} else {
instances.put( name, new Integer( 0 ));
}
-return name= + name + seq= + seq;
+return name= + name + ,seq= + seq;
}
-public static void createMBean( Object proxy, String domain, String name ) {
+public static String createMBean( Object proxy, String domain, String name ) {
try {
DynamicMBeanProxy mbean=new DynamicMBeanProxy();
mbean.setReal( proxy );
@@ -142,24 +142,38 @@
mbean.setName( generateName( proxy.getClass() ));
}
-mbean.registerMBean( domain );
+return mbean.registerMBean( domain );
} catch( Throwable t ) {
log.error( Error creating mbean , t );
+return null;
}
}
-public void registerMBean( String domain ) {
+public String registerMBean( String domain ) {
try {
// XXX use aliases, suffix only, proxy.getName(), etc
-ObjectName oname=new ObjectName( domain + : + getName());
+String fullName=domain + : + getName();
+ObjectName oname=new ObjectName( fullName );
if( getMBeanServer().isRegistered( oname )) {
log.info(Unregistering + oname );
getMBeanServer().unregisterMBean( oname );
}
getMBeanServer().registerMBean( this, oname );
+return fullName;
} catch( Throwable t ) {
log.error( Error creating mbean , t );
+return null;
+}
+}
+
+public static void unregisterMBean( Object o, String name ) {
+try {
+ObjectName oname=new ObjectName( name );
+
+getMBeanServer().unregisterMBean( oname );
+} catch( Throwable t ) {
+log.error( Error unregistering mbean , t );
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [VOTE] Removal of the LE distribution
ballot +1 [X] Yes, remove the LE distribution -1 [ ] No, keep both distributions /ballot But...The only problem I see is the Xerces version included in 1.3 doesn't support XML Schema. So if people turn on validation, the parser will not work for Servlet 2.4/JSP 2.0I recommend we make it clear in the installation note (or in another place). We can also display a warning message. -- Jeanfrancois Remy Maucherat wrote: Hi all, Before starting to release 5.0.x milestones, I would like to propose having only one distribution for Tomcat 5.0.x, and standardize on what the LE distribution contains (so well, it's more the other distribution which gets removed). It has some advantages: - it is slightly smaller (less these days now that the XML parser has to be shipped again with Tomcat) - runs as-is on JDK 1.3 (because of the Xerces inclusion) - 99% Apache or Apache-style licence (the JDBC 2 standard extension is needed for JDK 1.3 DataSource support :-() - less user confusion The main problem is that the user will need additional downloads for some of the more advanced features, and the package will also not run on JDK 1.2 as is (but from what I've seen, JDK 1.2 compatibility may not be a priority for developers). Remy -- 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]
DO NOT REPLY [Bug 13144] - Scriplet comment breaks JSPs silently
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=13144. 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=13144 Scriplet comment breaks JSPs silently [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 19:46 --- Fix in TC 4.1.x and 5. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10267] - Comments in scriptlets break subsequent sections
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=10267. 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=10267 Comments in scriptlets break subsequent sections [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 19:50 --- *** This bug has been marked as a duplicate of 13144 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13144] - Scriplet comment breaks JSPs silently
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=13144. 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=13144 Scriplet comment breaks JSPs silently [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 19:50 --- *** Bug 10267 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [VOTE] Removal of the LE distribution
- Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 03, 2002 11:30 AM Subject: RE: [5.0] [VOTE] Removal of the LE distribution iasandcb wrote: First all, I vote ballot +1 [ ] Yes, remove the LE distribution -1 [ ] No, keep both distributions /ballot Next, I'd like to make this clear: Tomcat 5 is based on JSP 2.0 spec, which requires J2SE 1.4. Therefore Tomcat 5 also can't run without J2SE 1.4 ideally. However, I found that the new catalina engine and jasper 2 compiler for Tomcat 5 don't mandate so. Is J2SE 1.4(or later) necessary for Tomcat 5? Or does Tomcat 5 support J2SE 1.3(or earlier) for backward compatibitity with disabled JSP 2 feature? My opinion on this issue is that Tomcat 5 should have J2SE 1.4 in compliance with JSP 2.0 spec basically. What ??? Where did you find this info ? I read the JSP2.0 draft and didn't find such thing. It would be just stupid - I don't know any other spec to require more than Java2 (i.e. JDK1.2+). If the final spec is aproved and includes JDK1.4 requirements - then there's nothing we can do, we'll have to stop supporting 1.3 in the official tomcat distibution. But given that now the 2 specs are distinct - and some people use only the servlet spec, I think the servlet engine and connectors should remain JDK1.2+. I can't find this either. And if true, would create big problems in that the 2.4 servlet spec mandates only Java 2. spec-quote spec=servlet version=2.4 section=1.2 J2SE 1.2 is the minimum version of the underlying Java platform with which servlet containers must be built. /spec-quote The only mention of 1.4 I see in either spec is that any 1.4 J2EE implementation must implement Servlet-2.4 JSP-2.0. Please give a cite for the 1.4 requirement. Costin IAS -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 2:24 AM To: Tomcat Developers List Subject: [5.0] [VOTE] Removal of the LE distribution Hi all, Before starting to release 5.0.x milestones, I would like to propose having only one distribution for Tomcat 5.0.x, and standardize on what the LE distribution contains (so well, it's more the other distribution which gets removed). It has some advantages: - it is slightly smaller (less these days now that the XML parser has to be shipped again with Tomcat) - runs as-is on JDK 1.3 (because of the Xerces inclusion) - 99% Apache or Apache-style licence (the JDBC 2 standard extension is needed for JDK 1.3 DataSource support :-() - less user confusion The main problem is that the user will need additional downloads for some of the more advanced features, and the package will also not run on JDK 1.2 as is (but from what I've seen, JDK 1.2 compatibility may not be a priority for developers). ballot +1 [ ] Yes, remove the LE distribution -1 [ ] No, keep both distributions /ballot Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13258] New: - During form-based authentication a POST turns into a GET
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=13258. 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=13258 During form-based authentication a POST turns into a GET Summary: During form-based authentication a POST turns into a GET Product: Tomcat 4 Version: 4.1.10 Platform: All OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Using form-based container managed security, when your session times out and you submit a POST form you get correctly redirected to the login page. If you correctly authenticate, your POST becomes a GET, and all of your parameters are lost. 127.0.0.1 - - [03/Oct/2002:13:40:19 -0500] POST /cm/blah HTTP/1.1 302 - 127.0.0.1 - - [03/Oct/2002:13:40:19 -0500] GET /cm/login HTTP/1.1 200 1647 127.0.0.1 - - [03/Oct/2002:13:40:29 -0500] POST /cm/j_security_check HTTP/1.1 302 - 127.0.0.1 - admin [03/Oct/2002:13:40:29 -0500] GET /cm/blah HTTP/1.1 200 4577 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13004] - Error in page compilation when comment is place at the end of scriptlet and the scriptlet is the last line in the jsp page.
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=13004. 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=13004 Error in page compilation when comment is place at the end of scriptlet and the scriptlet is the last line in the jsp page. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 19:56 --- *** This bug has been marked as a duplicate of 13144 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13144] - Scriplet comment breaks JSPs silently
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=13144. 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=13144 Scriplet comment breaks JSPs silently [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 19:56 --- *** Bug 13004 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
I doesnt have any problems with redirs with Coyote/jk2 using https in
IIS, AFAIK the only use URL class had, was to try to get a absolute RUL
or something like that, with a Method Craig did many time ago this
should be unnecssary...
I wonder how do you did the tests?
Saludos ,
Ignacio J. Ortega
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Enviado el: 3 de octubre de 2002 21:32
Para: [EMAIL PROTECTED]
Asunto: cvs commit:
jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
costin 2002/10/03 12:31:31
Modified:jk/java/org/apache/jk/server JkMain.java
Log:
If only Ajp connector is used, nobody will initialize the
https: handler
and redirects for https sites will fail ( a URL constructor
is used somewhere ).
PR: 11657
Submitted by: [EMAIL PROTECTED]
Revision ChangesPath
1.30 +20 -0
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java
Index: JkMain.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/serv
er/JkMain.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- JkMain.java 9 Aug 2002 20:54:23 - 1.29
+++ JkMain.java 3 Oct 2002 19:31:31 - 1.30
@@ -124,12 +124,32 @@
modules.put(shm, org.apache.jk.common.Shm);
modules.put(request,org.apache.jk.common.HandlerRequest);
modules.put(container,org.apache.jk.common.HandlerRequest);
+
+initHTTPSUrls();
}
public static JkMain getJkMain() {
return jkMain;
}
+private static String
DEFAULT_HTTPS=com.sun.net.ssl.internal.www.protocol;
+private void initHTTPSUrls() {
+try {
+// 11657: if only ajp is used, https:
redirects need to work ( at least for 1.3+)
+String value =
System.getProperty(java.protocol.handler.pkgs);
+if (value == null) {
+value = DEFAULT_HTTPS;
+} else if (value.indexOf(DEFAULT_HTTPS) = 0 ) {
+return; // already set
+} else {
+value += | + DEFAULT_HTTPS;
+}
+
System.setProperty(java.protocol.handler.pkgs, value);
+} catch(Exception ex ) {
+ex.printStackTrace();
+}
+}
+
// Setting
/** Load a .properties file into and set the values
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
On Thursday 03 October 2002 12:14 pm, Henri Gomez wrote: Steve Downey wrote: Actually, with the recent release of commons-logging, we should be able to get rid of the explicit LogKit and Log4J. They're there so as to get a complete build of commons-logging. Tomcat 5 itself doesn't use either directly. Xerces is a different issue. There was a bug that was preventing Tomcat from migrating to the latest version. Unfortunately, I no longer remember the details. Anyone know why we're using 2.1.0 instead of 2.2.0? From what I experienced with Xerces j 2.2.0 it seems it does much more validity check and for instance found a '--' somewhere in comments (1 EUR to the first who find where). Previous version of Xerces or crimson didn't got that problem. if we could see which xml/dtd/tld is reported buggy, which will able to see if it's a bug or a features (ie a more strict check of xml rules) OK, from the 'this shouldn't work department', this patch 'fixes' the problem: Index: ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 web-jsptaglibrary_1_2.dtd --- ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd13 Aug 2002 16:20:58 - 1.1.1.1 +++ ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd3 Oct 2002 20:42:30 - @@ -304,6 +304,7 @@ java.lang.String is default. declare Whether the variable is declared or not. + True is the default. scopeThe scope of the scripting varaible Something quite strange is going on. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
- Original Message -
From: Ignacio J. Ortega [EMAIL PROTECTED]
To: 'Tomcat Developers List' [EMAIL PROTECTED]
Sent: Thursday, October 03, 2002 1:36 PM
Subject: RE: cvs commit:
jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
I doesnt have any problems with redirs with Coyote/jk2 using https in
IIS, AFAIK the only use URL class had, was to try to get a absolute RUL
or something like that, with a Method Craig did many time ago this
should be unnecssary...
I wonder how do you did the tests?
It seems that o.a.c.tomcat4/5.CoyoteResponse is using java.net.URL instead
of Craig's o.a.c.u.URL or (the same class for 3.3) o.a.t.u.net.URL. AFAIK,
changing the import statement in CoyoteResponse should remove the need for
JSSE with Coyote/jk2 for TC 4/5 (3.3 shouldn't be affected).
Saludos ,
Ignacio J. Ortega
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Enviado el: 3 de octubre de 2002 21:32
Para: [EMAIL PROTECTED]
Asunto: cvs commit:
jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
costin 2002/10/03 12:31:31
Modified:jk/java/org/apache/jk/server JkMain.java
Log:
If only Ajp connector is used, nobody will initialize the
https: handler
and redirects for https sites will fail ( a URL constructor
is used somewhere ).
PR: 11657
Submitted by: [EMAIL PROTECTED]
Revision ChangesPath
1.30 +20 -0
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java
Index: JkMain.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/serv
er/JkMain.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- JkMain.java 9 Aug 2002 20:54:23 - 1.29
+++ JkMain.java 3 Oct 2002 19:31:31 - 1.30
@@ -124,12 +124,32 @@
modules.put(shm, org.apache.jk.common.Shm);
modules.put(request,org.apache.jk.common.HandlerRequest);
modules.put(container,org.apache.jk.common.HandlerRequest);
+
+initHTTPSUrls();
}
public static JkMain getJkMain() {
return jkMain;
}
+private static String
DEFAULT_HTTPS=com.sun.net.ssl.internal.www.protocol;
+private void initHTTPSUrls() {
+try {
+// 11657: if only ajp is used, https:
redirects need to work ( at least for 1.3+)
+String value =
System.getProperty(java.protocol.handler.pkgs);
+if (value == null) {
+value = DEFAULT_HTTPS;
+} else if (value.indexOf(DEFAULT_HTTPS) = 0 ) {
+return; // already set
+} else {
+value += | + DEFAULT_HTTPS;
+}
+
System.setProperty(java.protocol.handler.pkgs, value);
+} catch(Exception ex ) {
+ex.printStackTrace();
+}
+}
+
// Setting
/** Load a .properties file into and set the values
--
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]
DO NOT REPLY [Bug 13223] - JSP pages in XML syntax do not compile properly
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=13223. 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=13223 JSP pages in XML syntax do not compile properly --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 20:54 --- Unfortunately, the hole is not plugged by JSP 2.0! From the spec (emphasis by me): The jsp:attribute standard action allows the page author to define the value of a ***tag handler*** attribute in the body of an XML element instead of in the value of an XML attribute. The action may only appear as a subelement of a ***standard or custom action*** invocation. (Source: jsp-2_0-prd-spec.pdf, JSP.5.10, page 133) If I'm not completely mistaken, jsp:attribute is just a way of avoiding %= ... %. The spec quote above clearly states that jsp:attribute cannot be used for ordinary XML tags (i.e. body content in contrast to standard or custom actions). Thus, I think Kin-Man's example (dynamically setting the attribute of a td-Tag) is invalid. Also, all examples for jsp:attribute in the spec refer to a custom action. If what you suggest really works in Tomcat 5, then Tomcat is (unfortunately) wrong. I sent a message about this to [EMAIL PROTECTED] some time ago, but never got an answer. Maybe it would help if a Tomcat developer brought this up once again (Kin-Man?)... This is a _very annoying, very ugly_ spec issue IMHO. Either you don't use the XML syntax, or you're forced to use strange and/or hard-to-implement workarounds. Oh well, I will stop ranting now ;-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
De: Bill Barker [mailto:[EMAIL PROTECTED]] Enviado el: 3 de octubre de 2002 22:52 It seems that o.a.c.tomcat4/5.CoyoteResponse is using java.net.URL instead of Craig's o.a.c.u.URL or (the same class for 3.3) o.a.t.u.net.URL. AFAIK, changing the import statement in CoyoteResponse should remove the need for JSSE with Coyote/jk2 for TC 4/5 (3.3 shouldn't be affected). Ok.. this should be fixed too, but i doenst understand why it works for me using Coyote/JK2.. because i have the JSSE jars on my ext dir simply? Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
SSL Client-Auth
Hi. I have been looking into a problem with Tomcat5, ClientAuth=false, and JSSE in JDK1.4 and it seems like the JSSE has a problem. Namely if you build an SSL socket, then later decide you need to exchange certs with the client (ie. CLIENT-CERT), then the SSlSocket.startHandshake() method is called. Unfortunately this method is asynchronous, and waits for a read() or write() to occur before it does it's work. TC5 processes requests kinda like this; a Request comes in, TC5 checks to see if the Resource is protected, then a negotiation may start. However JSSE won't initiate a cert exchange unless a Read() or a Write() happens on the socket, but TC5 doesn't have anything it wants to write or read when the 'startHandshake()' is called I have been playing around with using a sendRedirect() back to the same page, but boy does that seem messy. Any ideas? -bob P.S. I tweaked the JSSE sample programs to demonstrate the problem outside of Tomcat. If anyone wants a copy - just ask. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13263] - javax.servlet.request.key_size not following servlet spec
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=13263. 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=13263 javax.servlet.request.key_size not following servlet spec --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 21:28 --- Created an attachment (id=3342) example jsp -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13264] New: - JspWriter.clear()/clearBuffer() don't reset the remaining buffer size as returned by JspWriter.getRemaining().
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=13264. 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=13264 JspWriter.clear()/clearBuffer() don't reset the remaining buffer size as returned by JspWriter.getRemaining(). Summary: JspWriter.clear()/clearBuffer() don't reset the remaining buffer size as returned by JspWriter.getRemaining(). Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Given a buffer of say, the default of 8KB, and one writes the the buffer. A call to out.getRemaining() will return a size less than 8KB. Next call out.clear() or out.clearBuffer(), and then call JspWriter.getRemaining(). The buffer size isn't reset to 8KB. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Bill Barker wrote:
I doesnt have any problems with redirs with Coyote/jk2 using https in
IIS, AFAIK the only use URL class had, was to try to get a absolute RUL
or something like that, with a Method Craig did many time ago this
should be unnecssary...
I wonder how do you did the tests?
It seems that o.a.c.tomcat4/5.CoyoteResponse is using java.net.URL instead
of Craig's o.a.c.u.URL or (the same class for 3.3) o.a.t.u.net.URL.
AFAIK, changing the import statement in CoyoteResponse should remove the
need for JSSE with Coyote/jk2 for TC 4/5 (3.3 shouldn't be affected).
Unless some other piece of code is using URLs.
I think it is safer to just set the system property - I don't think it
can hurt anyone, and it would allow https:// URLs to work. And it'll
eliminate a difference between running tomcat standalone and with a web
server.
If you think it's a better idea to findfix the uses of URL - I can roll
back.
Costin
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Enviado el: 3 de octubre de 2002 21:32
Para: [EMAIL PROTECTED]
Asunto: cvs commit:
jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
costin 2002/10/03 12:31:31
Modified:jk/java/org/apache/jk/server JkMain.java
Log:
If only Ajp connector is used, nobody will initialize the
https: handler
and redirects for https sites will fail ( a URL constructor
is used somewhere ).
PR: 11657
Submitted by: [EMAIL PROTECTED]
Revision ChangesPath
1.30 +20 -0
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java
Index: JkMain.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/serv
er/JkMain.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- JkMain.java 9 Aug 2002 20:54:23 - 1.29
+++ JkMain.java 3 Oct 2002 19:31:31 - 1.30
@@ -124,12 +124,32 @@
modules.put(shm, org.apache.jk.common.Shm);
modules.put(request,org.apache.jk.common.HandlerRequest);
modules.put(container,org.apache.jk.common.HandlerRequest);
+
+initHTTPSUrls();
}
public static JkMain getJkMain() {
return jkMain;
}
+private static String
DEFAULT_HTTPS=com.sun.net.ssl.internal.www.protocol;
+private void initHTTPSUrls() {
+try {
+// 11657: if only ajp is used, https:
redirects need to work ( at least for 1.3+)
+String value =
System.getProperty(java.protocol.handler.pkgs);
+if (value == null) {
+value = DEFAULT_HTTPS;
+} else if (value.indexOf(DEFAULT_HTTPS) = 0 ) {
+return; // already set
+} else {
+value += | + DEFAULT_HTTPS;
+}
+
System.setProperty(java.protocol.handler.pkgs, value);
+} catch(Exception ex ) {
+ex.printStackTrace();
+}
+}
+
// Setting
/** Load a .properties file into and set the values
--
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]
--
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13264] - JspWriter.clear()/clearBuffer() doesn't reset the remaining buffer size as returned by JspWriter.getRemaining().
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=13264. 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=13264 JspWriter.clear()/clearBuffer() doesn't reset the remaining buffer size as returned by JspWriter.getRemaining(). [EMAIL PROTECTED] changed: What|Removed |Added Summary|JspWriter.clear()/clearBuffe|JspWriter.clear()/clearBuffe |r() don't reset the |r() doesn't reset the |remaining buffer size as|remaining buffer size as |returned by |returned by |JspWriter.getRemaining(). |JspWriter.getRemaining(). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
please show me how to download the DBCP API jar file
Dear Sir, I like to use DBCP to connect to Oracle JDBC driver. Would you please show me how to download the DBCP API jar file? So I can put it into $CATALINA_HOME/common/lib DBCP uses the Jakarta-Commons Database Connection Pool. It relies on number of Jakarta-Commons componenets: Jakarta-Commons DBCP 1.0 Jakarta-Commons Collections 2.0 Jakarta-Commons Pool 1.0 Thanks for your help John Shih -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Fwd: Weird seg fault on Mac OS X for mod_jk2 + Apache2
On Thursday, October 3, 2002, at 10:28 AM, Costin Manolache wrote:
Command:httpd
PID:853
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0x736f0028
Thread 0 Crashed:
#0 0x90001600 in strlen
#1 0x900023e0 in vfprintf
#2 0x90015ee0 in __sbprintf
#3 0x900018a8 in vfprintf
#4 0x900017ec in fprintf
#5 0x0060fdbc in jk2_map_default_get (jk_map.c:97) -- it's '97'
because I added printf
#6 0x0060df50 in jk2_env_createBean2 (jk_env.c:218)
#7 0x0061ee0c in jk2_create_config (mod_jk2.c:351)
Anyone has a clue on what could be wrong? Just pointers would help. I
tried following the stack trace but am temporarily thrown off by how
jk2_env_createBean2() gets to jk2_map_default_get(), especially the
second parameter's type. It seems to be casted from (char *) to
(jk_map_t *), which is kind of weird.
Not sure what you mean. The second parameter of env-getBean2( ) is
string. jk2_env_getBean2 will call jk2_map_default_get ( actually,
env-_objects-get ) with env-_objects as second param, which is
a jk_map.
I understand now why the stack trace looks weird. The default
configuration adds a '-O2' flag during compilation and Mac OS X GCC 3.1
optimized certain functions out.
Here's the correct stack trace:
Thread 0 Crashed:
#0 0x90001600 in strlen
#1 0x900023e0 in vfprintf
#2 0x900017ec in fprintf
#3 0x0061dd18 in jk2_map_default_get (jk_map.c:104) - see codes
below for the statement
#4 0x0061bbb4 in jk2_env_getBean2 (jk_env.c:423) - this was
missing originally
#5 0x0061af40 in jk2_env_createBean2 (jk_env.c:218)
#6 0x00636754 in jk2_create_config (mod_jk2.c:344)
#7 0x0002214c in ap_single_module_configure (config.c:1845)
Are you using the commented-out printf ? It is possible that
one of name or value is null - printf is not checking for null on
many OS. Try using apr printf, or check for null.
I'm adding my own printf's. For completeness, here's the function
static void *jk2_map_default_get(jk_env_t *env, jk_map_t *m,
const char *name)
{
int i;
jk_map_private_t *mPriv;
void *result=NULL;
if(name==NULL )
return NULL;
fprintf(stdout, \nentering for %s , name);
mPriv=(jk_map_private_t *)m-_private;
fprintf(stdout, (no. maps: %d)\n, mPriv-size);
for(i = 0 ; i mPriv-size ; i++) {
fprintf(stdout, \t%d: , i);
if ((mPriv-names[i]) == NULL) {
fprintf(stdout, null mPriv-names[]);
return NULL;
}
fprintf(stdout, %p , (mPriv-names[i]));
fflush(stdout);
fprintf(stdout, %s , mPriv-names[i]); /* this is line 104 */
fprintf(stdout, (%p) \n, mPriv-values[i]);
if(0 == strcmp(mPriv-names[i], name)) {
result = mPriv-values[i];
break;
}
}
fprintf(stdout, done for %s\n, name);
return result;
}
And as per requested by Costin, I added the printf in the put function:
...
if(mPriv-size mPriv-capacity) {
mPriv-values[mPriv-size] = value;
/* XXX this is wrong - either we take ownership and copy both
name and value,
or none. The caller should do that if he needs !
Sure, but we should have our copy...
mPriv-names[mPriv-size] = (char *)name;
*/
mPriv-names[mPriv-size] = m-pool-pstrdup(env,m-pool, name);
printf(put '%s' (addr: %p) with value: %p \n,
mPriv-names[mPriv-size], (mPriv-names[mPriv-size]), value);
mPriv-size ++;
rc = JK_OK;
}
...
And finally, here's the output:
put 'logger.file' (addr: 0x19b948) with value: 0x61d984
put 'logger.win32' (addr: 0x19b94c) with value: 0x61dac8
put 'workerEnv' (addr: 0x19b950) with value: 0x62c698
put 'uriMap' (addr: 0x19b954) with value: 0x62a3d4
put 'uriEnv' (addr: 0x19b958) with value: 0x627fa4
put 'endpoint' (addr: 0x19b95c) with value: 0x61a65c
put 'uri' (addr: 0x19b960) with value: 0x627fa4
put 'config' (addr: 0x19b964) with value: 0x61a028
put 'ajp13' (addr: 0x19b968) with value: 0x62f168
put 'lb' (addr: 0x19b96c) with value: 0x6308dc
put 'status' (addr: 0x19b970) with value: 0x632c2c
put 'run' (addr: 0x19b974) with value: 0x630d60
put 'channel.un' (addr: 0x19b978) with value: 0x617dc8
put 'channel.apr' (addr: 0x19b97c) with value: 0x615644
put 'shm' (addr: 0x19b980) with value: 0x626ee8
put 'channel.socket' (addr: 0x19b984) with value: 0x616c64
put 'handler.response' (addr: 0x19b988) with value: 0x61cff0
put 'handler.logon' (addr: 0x19b98c) with value: 0x61c578
put 'threadMutex' (addr: 0x19b990) with value: 0x620da8
put 'procMutex' (addr: 0x19b994) with value: 0x6209fc
put 'channel.jni' (addr: 0x19b998) with value: 0x6157b0
put 'worker.jni' (addr: 0x19b99c) with value: 0x62f3f4
put 'vm' (addr: 0x19b9a0) with value: 0x62a864
put 'signal' (addr: 0x19b9a4) with value: 0x627038
put 'user' (addr: 0x19b9a8) with value:
Re: please show me how to download the DBCP API jar file
Look here, http://jakarta.apache.org/builds/jakarta-commons/release/commons-dbcp/v1.0/ On Thu, 2002-10-03 at 17:44, Shih, John wrote: Dear Sir, I like to use DBCP to connect to Oracle JDBC driver. Would you please show me how to download the DBCP API jar file? So I can put it into $CATALINA_HOME/common/lib DBCP uses the Jakarta-Commons Database Connection Pool. It relies on number of Jakarta-Commons componenets: Jakarta-Commons DBCP 1.0 Jakarta-Commons Collections 2.0 Jakarta-Commons Pool 1.0 Thanks for your help John Shih -- 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]
[PATCH] jakarta-servletapi-5: javadocs, API changes and new file
NEW FILE (in jakarta-servletapi-5.newfiles.tar):
- jsr154/src/share/dtd/j2ee_web_services_1_1.xsd
(Required by latest j2ee_1_4.xsd)
CHANGED FILES:
jsr152/src/share/javax/servlet/jsp/JspContext.java:
- getAttribute(name): Remove IllegalArgumentException
for non-existent scope parameter.
- Added javadoc for IllegalArgumentException for
removeAttribute(name, scope)
- Added javadoc for IllegalArgumentException for
getAttributeNamesInScope(scope)
- Added 'public JspWriter pushBody( java.io.Writer writer );'
- Moved 'public JspWriter popBody()' from PageContext to JspContext.
jsr152/src/share/javax/servlet/jsp/PageContext.java:
- forward(path): Remove IllegalArgumentException and
SecurityException, which are not declared in the RequestDispatcher
counterpart methods.
- include(path): Remove IllegalArgumentException and
SecurityException, which are not declared in the RequestDispatcher
counterpart methods.
- include(path, flush): Remove IllegalArgumentException and
SecurityException, which are not declared in the RequestDispatcher
counterpart methods.
- Moved 'public JspWriter popBody()' from PageContext to JspContext.
jsr152/src/share/javax/servlet/jsp/el/ELException.java:
- Removed toString() method, and constructors pass in localized
message of root cause Throwable.
jsr152/src/share/javax/servlet/jsp/el/VariableResolver.java:
- resolveVariable( name, context ): Add description for
context parameter.
jsr152/src/share/javax/servlet/jsp/el/ExpressionEvaluator.java:
- Elaborate on description of what should be passed for the
expression parameter. The expression parameter includes
the tokens '${' and '}', which can appear more than once.
For example, parseExpression( Version ${major}.${minor}, ... )
is valid.
- Elaborate on caller requirements for passing in a FunctionMapper
to evaluate() and parseExpression().
jsr152/src/share/dtd/web-jsptaglibrary_2_0.xsd:
- Escape markup in documentation with CDATA instead of lt;
jsr154/src/share/dtd/web-jsptaglibrary_2_0.xsd:
- Escape markup in documentation with CDATA instead of lt;
jsr154/src/share/dtd/j2ee_1_4.xsd:
- Escape markup in documentation with CDATA instead of lt;
- Make CDATA sections use a consistent style
- Make xsd:include schemaLocation point to IBM site
jsr154/src/share/dtd/web-app_2_4.xsd:
- Escape markup in documentation with CDATA instead of lt;
- Added ERROR to list of legal values for request dispatcher
As usual, please let me know if there are any questions or concerns.
--
Mark Roth, Java Software
JSP 2.0 Co-Specification Lead
Sun Microsystems, Inc.
Index: jsr152/src/share/dtd/web-jsptaglibrary_2_0.xsd
===
RCS file:
/home/cvspublic/jakarta-servletapi-5/jsr152/src/share/dtd/web-jsptaglibrary_2_0.xsd,v
retrieving revision 1.3
diff -u -r1.3 web-jsptaglibrary_2_0.xsd
--- jsr152/src/share/dtd/web-jsptaglibrary_2_0.xsd 20 Sep 2002 01:56:44 -
1.3
+++ jsr152/src/share/dtd/web-jsptaglibrary_2_0.xsd 3 Oct 2002 21:59:54 -
@@ -10,7 +10,7 @@
xsd:annotation
xsd:documentation
-@(#)web-jsptaglibrary_2_0.xsds 1.18 09/19/02
+@(#)web-jsptaglibrary_2_0.xsds 1.19 09/30/02
/xsd:documentation
/xsd:annotation
xsd:annotation
@@ -50,6 +50,7 @@
xsd:annotation
xsd:documentation
+![CDATA[
This is the XML Schema for the JSP Taglibrary deployment
descriptor. All Taglibrary deployment descriptors must
@@ -61,12 +62,12 @@
and by indicating the version of the schema by
using the version element as shown below:
-lt;taglib xmlns=http://java.sun.com/xml/ns/j2ee;
- xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
- xsi:schemaLocation=...
- version=2.0
-...
-lt;/taglib
+taglib xmlns=http://java.sun.com/xml/ns/j2ee;
+ xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
+ xsi:schemaLocation=...
+ version=2.0
+ ...
+/taglib
The instance documents may indicate the published
version of the schema using xsi:schemaLocation attribute
@@ -74,6 +75,7 @@
http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd
+]]
/xsd:documentation
/xsd:annotation
Index: jsr152/src/share/javax/servlet/jsp/JspContext.java
===
RCS file:
/home/cvspublic/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/JspContext.java,v
retrieving revision 1.2
diff -u -r1.2 JspContext.java
--- jsr152/src/share/javax/servlet/jsp/JspContext.java 19 Aug 2002 16:29:49 -
1.2
+++ jsr152/src/share/javax/servlet/jsp/JspContext.java 3 Oct 2002 21:59:54 -
@@ -78,6 +78,12 @@
* scripting environment
* /ul
*
+ * pBMethods Intended for Container Generated Code/B
+ * p
+ * The following methods enable the Bmanagement of nested/B JspWriter
+ *
DO NOT REPLY [Bug 12346] - Constant Refreshes crash Framed Web Applications in TOMCAT
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=12346. 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=12346 Constant Refreshes crash Framed Web Applications in TOMCAT --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 22:09 --- We also have this bug. Our environment is W2K, IIS 5, JK 2, Tomcat 4.1.12 Our application has one group of pages that use quite a few nested pages. It all goes haywire after a while. I have tried increasing all the parameters in the connector section of server.xml by an order of magnitude to no avail. If anyone is working on this I will happily run a version of the code in a debugging mode and report back as I can easily get the failure at the moment. However, I have zero C skills and no C compiler. Thanks Dave -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/s erver JkMain.java
De: news [mailto:[EMAIL PROTECTED]]En nombre de Costin Manolache Enviado el: 3 de octubre de 2002 23:40 Ok.. this should be fixed too, but i doenst understand why it works for me using Coyote/JK2.. because i have the JSSE jars on my ext dir simply? Are you using JDK1.4 ( in jdk1.4 this is set automatically in jre/lib/security ) ? JSSE jars shouldn't matter - you need the property set somehow in order for https URLs to work. It may be in user code - some webapp that is using https: connections may set it. Hmmm, it works for me for the redirection from https://localhost/examples/jsp to https://localhost/examples/jsp/ so it's tomcat who is doing the redirect, So what? Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
- Original Message -
From: Costin Manolache [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, October 03, 2002 2:37 PM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Bill Barker wrote:
I doesnt have any problems with redirs with Coyote/jk2 using https in
IIS, AFAIK the only use URL class had, was to try to get a absolute RUL
or something like that, with a Method Craig did many time ago this
should be unnecssary...
I wonder how do you did the tests?
It seems that o.a.c.tomcat4/5.CoyoteResponse is using java.net.URL
instead
of Craig's o.a.c.u.URL or (the same class for 3.3) o.a.t.u.net.URL.
AFAIK, changing the import statement in CoyoteResponse should remove the
need for JSSE with Coyote/jk2 for TC 4/5 (3.3 shouldn't be affected).
Unless some other piece of code is using URLs.
I think it is safer to just set the system property - I don't think it
can hurt anyone, and it would allow https:// URLs to work. And it'll
eliminate a difference between running tomcat standalone and with a web
server.
If you think it's a better idea to findfix the uses of URL - I can roll
back.
This seems to be the only place in j-t-c it's being used (at least with a
quick check). I was planning to fix it if only because I'd rather continue
not having to install JSSE. A little less selfish reason is that it also
keeps people from complaining that weird things like:
response.sendRedirect(response.encodeURL(news://));
aren't working. ;-)
I agree that you're patch is harmless, and is a fall-back for systems with
JSSE installed. Personally, I don't see any reason to roll back.
Costin
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Enviado el: 3 de octubre de 2002 21:32
Para: [EMAIL PROTECTED]
Asunto: cvs commit:
jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
costin 2002/10/03 12:31:31
Modified:jk/java/org/apache/jk/server JkMain.java
Log:
If only Ajp connector is used, nobody will initialize the
https: handler
and redirects for https sites will fail ( a URL constructor
is used somewhere ).
PR: 11657
Submitted by: [EMAIL PROTECTED]
Revision ChangesPath
1.30 +20 -0
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java
Index: JkMain.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/serv
er/JkMain.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- JkMain.java 9 Aug 2002 20:54:23 - 1.29
+++ JkMain.java 3 Oct 2002 19:31:31 - 1.30
@@ -124,12 +124,32 @@
modules.put(shm, org.apache.jk.common.Shm);
modules.put(request,org.apache.jk.common.HandlerRequest);
modules.put(container,org.apache.jk.common.HandlerRequest);
+
+initHTTPSUrls();
}
public static JkMain getJkMain() {
return jkMain;
}
+private static String
DEFAULT_HTTPS=com.sun.net.ssl.internal.www.protocol;
+private void initHTTPSUrls() {
+try {
+// 11657: if only ajp is used, https:
redirects need to work ( at least for 1.3+)
+String value =
System.getProperty(java.protocol.handler.pkgs);
+if (value == null) {
+value = DEFAULT_HTTPS;
+} else if (value.indexOf(DEFAULT_HTTPS) = 0 ) {
+return; // already set
+} else {
+value += | + DEFAULT_HTTPS;
+}
+
System.setProperty(java.protocol.handler.pkgs, value);
+} catch(Exception ex ) {
+ex.printStackTrace();
+}
+}
+
// Setting
/** Load a .properties file into and set the values
--
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]
--
Costin
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13223] - JSP pages in XML syntax do not compile properly
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=13223. 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=13223 JSP pages in XML syntax do not compile properly --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 22:49 --- Ah, but your are referring to a spec that's already out of date! The latest version, yet to be made public, allows jsp:attribute to be used for any attribute values; and this is implemented in Tomcat 5. Unfortunately, XML part in the spec is not quite complete, and Tomcat 5 is very broken in this aspect also, so I don't know if jsp:attribute (in XML) works the way it should. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-servletapi-5/jsr154/src/share/dtd j2ee_web_services_1_1.xsd j2ee_1_4.xsd web-app_2_4.xsd web-jsptaglibrary_2_0.xsd
kinman 2002/10/03 16:01:44
Modified:jsr152/src/share/dtd web-jsptaglibrary_2_0.xsd
jsr152/src/share/javax/servlet/jsp JspContext.java
PageContext.java
jsr152/src/share/javax/servlet/jsp/el ELException.java
ExpressionEvaluator.java VariableResolver.java
jsr152/src/share/javax/servlet/jsp/tagext .nbattrs
jsr154/src/share/dtd j2ee_1_4.xsd web-app_2_4.xsd
web-jsptaglibrary_2_0.xsd
Added: jsr154/src/share/dtd j2ee_web_services_1_1.xsd
Log:
- Patch submitted by Mark Roth
NEW FILE (in jakarta-servletapi-5.newfiles.tar):
- jsr154/src/share/dtd/j2ee_web_services_1_1.xsd
(Required by latest j2ee_1_4.xsd)
CHANGED FILES:
jsr152/src/share/javax/servlet/jsp/JspContext.java:
- getAttribute(name): Remove IllegalArgumentException
for non-existent scope parameter.
- Added javadoc for IllegalArgumentException for
removeAttribute(name, scope)
- Added javadoc for IllegalArgumentException for
getAttributeNamesInScope(scope)
- Added 'public JspWriter pushBody( java.io.Writer writer );'
- Moved 'public JspWriter popBody()' from PageContext to JspContext.
jsr152/src/share/javax/servlet/jsp/PageContext.java:
- forward(path): Remove IllegalArgumentException and
SecurityException, which are not declared in the RequestDispatcher
counterpart methods.
- include(path): Remove IllegalArgumentException and
SecurityException, which are not declared in the RequestDispatcher
counterpart methods.
- include(path, flush): Remove IllegalArgumentException and
SecurityException, which are not declared in the RequestDispatcher
counterpart methods.
- Moved 'public JspWriter popBody()' from PageContext to JspContext.
jsr152/src/share/javax/servlet/jsp/el/ELException.java:
- Removed toString() method, and constructors pass in localized
message of root cause Throwable.
jsr152/src/share/javax/servlet/jsp/el/VariableResolver.java:
- resolveVariable( name, context ): Add description for
context parameter.
jsr152/src/share/javax/servlet/jsp/el/ExpressionEvaluator.java:
- Elaborate on description of what should be passed for the
expression parameter. The expression parameter includes
the tokens '${' and '}', which can appear more than once.
For example, parseExpression( Version ${major}.${minor}, ... )
is valid.
- Elaborate on caller requirements for passing in a FunctionMapper
to evaluate() and parseExpression().
jsr152/src/share/dtd/web-jsptaglibrary_2_0.xsd:
- Escape markup in documentation with CDATA instead of lt;
jsr154/src/share/dtd/web-jsptaglibrary_2_0.xsd:
- Escape markup in documentation with CDATA instead of lt;
jsr154/src/share/dtd/j2ee_1_4.xsd:
- Escape markup in documentation with CDATA instead of lt;
- Make CDATA sections use a consistent style
- Make xsd:include schemaLocation point to IBM site
jsr154/src/share/dtd/web-app_2_4.xsd:
- Escape markup in documentation with CDATA instead of lt;
- Added ERROR to list of legal values for request dispatcher
Revision ChangesPath
1.4 +9 -7
jakarta-servletapi-5/jsr152/src/share/dtd/web-jsptaglibrary_2_0.xsd
Index: web-jsptaglibrary_2_0.xsd
===
RCS file:
/home/cvs/jakarta-servletapi-5/jsr152/src/share/dtd/web-jsptaglibrary_2_0.xsd,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- web-jsptaglibrary_2_0.xsd 20 Sep 2002 01:56:44 - 1.3
+++ web-jsptaglibrary_2_0.xsd 3 Oct 2002 23:01:43 - 1.4
@@ -10,7 +10,7 @@
xsd:annotation
xsd:documentation
-@(#)web-jsptaglibrary_2_0.xsds 1.18 09/19/02
+@(#)web-jsptaglibrary_2_0.xsds 1.19 09/30/02
/xsd:documentation
/xsd:annotation
xsd:annotation
@@ -50,6 +50,7 @@
xsd:annotation
xsd:documentation
+![CDATA[
This is the XML Schema for the JSP Taglibrary deployment
descriptor. All Taglibrary deployment descriptors must
@@ -61,12 +62,12 @@
and by indicating the version of the schema by
using the version element as shown below:
-lt;taglib xmlns=http://java.sun.com/xml/ns/j2ee;
- xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
- xsi:schemaLocation=...
- version=2.0
-...
-lt;/taglib
+taglib xmlns=http://java.sun.com/xml/ns/j2ee;
+ xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
+ xsi:schemaLocation=...
+ version=2.0
+ ...
+/taglib
The instance documents may indicate the published
version of the schema using xsi:schemaLocation attribute
@@ -74,6 +75,7 @@
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime BodyContentImpl.java JspContextWrapper.java PageContextImpl.java
luehe 2002/10/03 16:50:11
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
jasper2/src/share/org/apache/jasper/runtime
BodyContentImpl.java JspContextWrapper.java
PageContextImpl.java
Log:
Fixed 12558: Unable to capture fragment evaluation in a Writer if the
fragment writes to the default 'out'
Revision ChangesPath
1.106 +18 -6
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.105
retrieving revision 1.106
diff -u -r1.105 -r1.106
--- Generator.java3 Oct 2002 19:29:37 - 1.105
+++ Generator.java3 Oct 2002 23:50:11 - 1.106
@@ -3516,7 +3516,7 @@
}
// Generate postamble:
-out.printil( public void invoke( java.io.Writer out, +
+out.printil( public void invoke( java.io.Writer writer, +
java.util.Map params ) );
out.pushIndent();
out.printil( throws javax.servlet.jsp.JspException );
@@ -3529,10 +3529,15 @@
out.printil( _jspx_originalValues = preparePageScope( params ););
out.popIndent();
out.printil( } );
-out.printil( if( out == null ) { );
+ out.printil( java.io.Writer out = null; );
+out.printil( if( writer != null ) { );
out.pushIndent();
-out.printil( out = this.jspContext.getOut(); );
+ out.printil( out = this.jspContext.pushBody(writer); );
out.popIndent();
+out.printil( } else { );
+ out.pushIndent();
+out.printil( out = this.jspContext.getOut(); );
+ out.popIndent();
out.printil( } );
out.printil( try { );
out.pushIndent();
@@ -3558,6 +3563,13 @@
out.printil( } ); // catch
out.printil( finally { );
out.pushIndent();
+
+out.printil( if( writer != null ) { );
+out.pushIndent();
+out.printil( this.jspContext.popBody(););
+out.popIndent();
+out.printil( } );
+
out.printil( if( params != null ) { );
out.pushIndent();
out.printil( restorePageScope( _jspx_originalValues ););
1.6 +253 -176
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/BodyContentImpl.java
Index: BodyContentImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/BodyContentImpl.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- BodyContentImpl.java 15 Aug 2002 19:12:09 - 1.5
+++ BodyContentImpl.java 3 Oct 2002 23:50:11 - 1.6
@@ -55,16 +55,10 @@
package org.apache.jasper.runtime;
-import java.io.IOException;
-import java.io.Writer;
-import java.io.Reader;
-import java.io.CharArrayReader;
-import java.io.PrintWriter;
-
+import java.io.*;
import javax.servlet.ServletResponse;
import javax.servlet.jsp.JspWriter;
import javax.servlet.jsp.tagext.BodyContent;
-
import org.apache.jasper.Constants;
/**
@@ -75,56 +69,53 @@
* Provide support for discarding for the output that has been buffered.
*
* @author Rajiv Mordani
+ * @author Jan Luehe
*/
public class BodyContentImpl extends BodyContent {
+private static final String LINE_SEPARATOR = System.getProperty(
+line.separator);
+
private char[] cb;
-protected int bufferSize = Constants.DEFAULT_TAG_BUFFER_SIZE;
private int nextChar;
-static String lineSeparator = System.getProperty(line.separator);
-private boolean closed = false;
+private boolean closed;
-public BodyContentImpl (JspWriter writer) {
-super(writer);
+// Enclosed writer to which any output is written
+private Writer writer;
+
+/*
+ * Indicates whether this BodyContentImpl is returned as the result of a
+ * call to JspContext.pushBody(java.io.Writer) (FALSE) or
+ * PageContext.pushBody() (TRUE)
+ */
+private boolean isBodyContent;
+
+private int bufferSizeSave;
+
+/**
+ * Constructor.
+ */
+public BodyContentImpl(JspWriter enclosingWriter) {
+super(enclosingWriter);
+ bufferSize = Constants.DEFAULT_TAG_BUFFER_SIZE;
cb = new char[bufferSize];
nextChar = 0;
-}
-
-
DO NOT REPLY [Bug 12558] - Unable to capture fragment evaluation in a Writer if the fragment writes to the default 'out'
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=12558. 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=12558 Unable to capture fragment evaluation in a Writer if the fragment writes to the default 'out' [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
