Re: Tagging JK2_2_0_1?

[jean-frederic clere]

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:   
> For additional commands, e-mail: 
> 
> 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c

[jean-frederic clere]

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:   
For additional commands, e-mail: 

Re: Weird seg fault on Mac OS X for mod_jk2 + Apache2

[jean-frederic clere]

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:
> 
> 
> JkSet "config.file" "/usr/local/apache2/conf/workers2.properties"
> 
> 
> 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 
> --

Re: Strange problem with tomcat 4.1.2

[Henri Gomez]

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 or

Re: [VOTE] JK2 2.1

[Henri Gomez]

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:   
For additional commands, e-mail: 

Re: Tagging JK2_2_0_1?

[Henri Gomez]

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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 8107] - uninstall mod_jk2-2.0 rpm not possible

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

Re: isapi_redirect.dll file

[Henri Gomez]

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:   
For additional commands, e-mail: 

Re: Tagging JK2_2_0_1?

[Henri Gomez]

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:   
For additional commands, e-mail: 

Re: [VOTE] JK2 2.1

[jean-frederic clere]

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:   
> 
> For additional commands, e-mail: 
> 
> 
> 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tagging JK2_2_0_1?

[jean-frederic clere]

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:   
> 
> For additional commands, e-mail: 
> 
> 
> 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13240] New: - CGI works only with Java version 1.3+

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13033] - Unable to pass Request Time Parameters for the XML View of JSP file

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10683] - some problems with JSP documents in xml syntax

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13223] - JSP pages in XML syntax do not compile properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10683] - some problems with JSP documents in xml syntax

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:18 
---
*** Bug 13223 has been marked as a duplicate of this bug. ***

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] [5.0] Milestones

[Remy Maucherat]

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:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_uriMap.c

[mturk]

mturk   2002/10/03 03:32:29

  Modified:jk/native2/common jk_uriMap.c
  Log:
  Fix and rewrite the hostMap. It was a real mess.
  There was also a bug in the code that casused host mapping to be
  sensitive to the order of directives in the config.
  
  Revision  ChangesPath
  1.50  +34 -16jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c
  
  Index: jk_uriMap.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c,v
  retrieving revision 1.49
  retrieving revision 1.50
  diff -u -r1.49 -r1.50
  --- jk_uriMap.c   3 Oct 2002 01:33:14 -   1.49
  +++ jk_uriMap.c   3 Oct 2002 10:32:29 -   1.50
  @@ -254,44 +254,62 @@
   static jk_uriEnv_t *jk2_uriMap_hostMap(jk_env_t *env, jk_uriMap_t *uriMap,
  const char *vhost, int port)
   {
  -int i, j;
  +int i, j, n;
   char *name;
  -char vs[1024] = {0};
  -char vv[1024] = {0};
  +char hostame[1024] = {0};
   
  -int n = uriMap->vhosts->size(env, uriMap->vhosts);
   if (port) {
  -if (vhost && strchr(vhost, ':'))
  -strcpy(vs, vhost);
  +if (vhost) {
  +if (strchr(vhost, ':'))
  +strcpy(hostame, vhost);
  +else
  +   sprintf(hostame, "%s:%d", vhost, port);
  +}
   else
  -sprintf(vs, "%s:%d", vhost ? vhost : "*", port);
  -sprintf(vv, "*:%d", port);
  +sprintf(hostame, "*:%d", port);
   }
  -else
  -strcpy(vs, vhost ? vhost : "*"); 
  -
  +else if (vhost)
  +strcpy(hostame, vhost); 
  +else /* Return default host if vhost and port wasn't suplied */
  +return uriMap->vhosts->get(env, uriMap->vhosts, "*");
  +
  +n = uriMap->vhosts->size(env, uriMap->vhosts);
  +/* Check the hostnames first */
   for (i = 0 ; i < n ; i++) {
   jk_uriEnv_t *uriEnv = uriMap->vhosts->valueAt(env, uriMap->vhosts, i);
   name = uriMap->vhosts->nameAt(env, uriMap->vhosts, i);
   /* Host name is not case sensitive */
  -if (strcasecmp(name, vs) == 0) {
  +if (strcasecmp(name, hostame) == 0) {
   if (port == 0 || port == uriEnv->port)
   return uriEnv;
   }
  -else if (uriEnv->aliases) {
  +}
  +/* Then for each vhost, check the aliases */
  +for (i = 0 ; i < n ; i++) {
  +jk_uriEnv_t *uriEnv = uriMap->vhosts->valueAt(env, uriMap->vhosts, i);
  +name = uriMap->vhosts->nameAt(env, uriMap->vhosts, i);
  +if (uriEnv->aliases && vhost) {
   int m = uriEnv->aliases->size(env, uriEnv->aliases);
   for (j = 0; j < m; j++) {
   name = uriEnv->aliases->nameAt(env, uriEnv->aliases, j);
  -if (strcasecmp(name, vhost) == 0) {
  +if (strcasecmp(name, hostame) == 0) {
   if (port == 0 || port == uriEnv->port)
   return uriEnv;
   }
   }
   }
  -else if (port && strcasecmp(name, vv) == 0) {
  -return uriEnv;
  +}
  +/* Finally, check aginst *:port hostname */
  +if (port) {
  +for (i = 0 ; i < n ; i++) {
  +jk_uriEnv_t *uriEnv = uriMap->vhosts->valueAt(env, uriMap->vhosts, i);
  +name = uriMap->vhosts->nameAt(env, uriMap->vhosts, i);
  +if ((strncmp(name, "*:", 2) == 0) && uriEnv->port == port) {
  +return uriEnv;
  +}
   }
   }
  +/* Return default host if none found */
   return uriMap->vhosts->get(env, uriMap->vhosts, "*");
   }
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk2 configweb.xml

[mturk]

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 @@
   
   Special case is a default server named as [uri:*] 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.
  +host name belongs to this default server making global mappings.
  +
  +
  +Addition wild char scheme id [uri:*:port] 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.
  +
  +
   The order how the host names are resolved is :
   
   Exact host name and optional non default port number
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [VOTE] [5.0] Milestones

[Kevin Jones]

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:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tagging JK2_2_0_1?

[Henri Gomez]

jean-frederic clere wrote:
> 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.
> 

Would you recommand scandoc or doxygen.

Did there is something available which could generate
XML so that we could apply our own styles ?




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Is Compile Failure? was Re: Need some clarifications

[Christian Gross]

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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13241] New: - Tomcat 4.1.12 / Webapps:Examples / Disabled

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

[PROPOSAL] Splitting docs for JK2

[Mladen Turk]

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:   
For additional commands, e-mail: 

Re: [PROPOSAL] Splitting docs for JK2

[Henri Gomez]

Mladen Turk wrote:
> 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.

+0 (Ok but can't help right now)




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12978] - Tomcat doesn't pick up error pages.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13241] - Tomcat 4.1.12 / Webapps:Examples / Disabled

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:16 ---
I've got exactly the same problem while working on tomcat 4.1.2 rpms and it
seems related to xerces-2.2.0.

Are you using jikes ?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13241] - Tomcat 4.1.12 / Webapps:Examples / Disabled

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 13241] - Tomcat 4.1.12 / Webapps:Examples/ Disabled

[Henri Gomez]

[EMAIL PROTECTED] wrote:
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> .
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
> INSERTED IN THE BUG DATABASE.
> 
> http://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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13241] - Tomcat 4.1.12 / Webapps:Examples / Disabled

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13241] - Tomcat 4.1.12 / Webapps:Examples / Disabled

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:49 ---
I agree with you but the parser failed since their is something incorrect 
somewhere in an XML (or DTD or TLD).

I spent hours on it and couldn't find where it is.

I'm using the original 4.1.12 tarball and it works unless you change the xerces 
2.0.2 with 2.2.0.

I think you should include the latest xerces available since it will show up 
this kind of problem quickly.

I'll try to locate the problem in my IDE.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-5 build.properties.default

[remm]

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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13241] - Tomcat 4.1.12 / Webapps:Examples / Disabled

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13241] - Tomcat 4.1.12 / Webapps:Examples / Disabled

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13164] - Compliance issue - VariableResolver.resolveVariable() fails to throw an ELException for an unresolvable variable.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13173] - NPE thrown by ELException.toString() if not originally created with a root cause exception.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13241] - Tomcat 4.1.12 / Webapps:Examples / Disabled

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c

[Costin Manolache]

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  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:   
For additional commands, e-mail: 

Re: Is Compile Failure? was Re: Need some clarifications

[Steve Downey]

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:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/xdocs menu.jk2.idx

[mturk]

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 @@
   
   
   
  -
  -
   
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  \ No newline at end of file
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk2 configwebex.xml configwebcom.xml configtcex.xml

[mturk]

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
  ===
  
  
  
  Examples
  Costin Manolache
  Jean-Frederic Clere
  $Date: 2002/10/03 15:33:41 $
  
  
  
  The examples below are working when the Tomcat is configured according the 
  examples described in the configtc file.
  
  
   
  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).
  
  
  
  [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
  
  
  
  
  
  Map /jkstatus to the status worker.
  
  
  
  [shm]
  file=${serverRoot}/logs/shm.file
  size=1048576
  
  # define the worker
  [status:status]
  
  # Uri mapping
  [uri:/jkstatus/*]
  worker=status:status
  
  
  
  
  
  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:
  
  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
  
  Here the Tomcat user and the Web Server user must be in the same group.
  
  
  
  [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
  
  
  
  
  
  
  
  
  
  
  1.1  jakarta-tomcat-connectors/jk/xdocs/jk2/configwebcom.xml
  
  Index: configwebcom.xml
  ===
  
  
  
  Components
  Costin Manolache
  Jean-Frederic Clere
  $Date: 2002/10/03 15:33:41 $
  
  Each 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:
  The name is composed from the type and a local part, separated with a ':' ( 
example: channel.unixsocket:/tmp/jk.socket ) 
  The 'type' consist of '.' and ascii characters.  It is mapped to a JMX 'domain'. 
 
  The local part consists of ascii characters and .:/; 
  Note 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 ). 
  The property is a simple name, with no dots. 
  A 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.
  
  
  Common properties for all components
  
  
  
  Property name
  Default
  Description
  
  
  disabled
  0 (false)
  "disabled" state for the component, 1=true 0=false
  
  
  debug
  0 (false)
  "debug" state for the component, 1=true 0=false
  
  
  
  
  
  This 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
  
  
  
  Property name
  Default
  Description
  
  
  logger
  logger
  Default loger used by jk2 components, can be changed in 
the config file, normally it d

cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk2 configweb.xml configtc.xml

[mturk]

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 @@
   
   
   
  -Configuration in the Web Server
  +Configuration file
   Costin Manolache
   Jean-Frederic Clere
   $Date$
  @@ -37,596 +37,5 @@
   PROPERTY=VALUE
   
   
  -
  -Each 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:
  -The name is composed from the type and a local part, separated with a ':' ( 
example: channel.unixsocket:/tmp/jk.socket ) 
  -The 'type' consist of '.' and ascii characters.  It is mapped to a JMX 
'domain'.  
  -The local part consists of ascii characters and .:/; 
  -Note 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 ). 
  -The property is a simple name, with no dots. 
  -A 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.
  -
  -Common properties for all components
  -
  -
  -
  -Property name
  -Default
  -Description
  -
  -
  -disabled
  -0 (false)
  -"disabled" state for the component, 1=true 0=false
  -
  -
  -debug
  -0 (false)
  -"debug" state for the component, 1=true 0=false
  -
  -
  -
  -
  -
  -This 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
  -
  -
  -
  -Property name
  -Default
  -Description
  -
  -
  -logger
  -logger
  -Default 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.
  -
  -
  -timing
  -0
  -Will jk2 get request timing (needs APR?)
  -
  -
  -
  -
  -
  -The config component, hold the detail of the conifg system, such 
config file name, create global defines
  -
  -
  -
  -   Property name
  -   Default
  -   Description
  -
  -
  -file
  -${serverRoot}/conf/workers2.properties
  -Location of the workers2.properties file
  -
  -
  -debug
  -0
  -Set the debug level of the config component
  -
  -
  -debugEnv
  -0
  -Set the debug level of the hidden env component 
  -
  -
  -
  -
  -
  -
  -Shared memory descriptor
  -
  -
  -
  -Property name
  -Default
  -Description
  -
  -
  -file
  -No default value
  -Name of the file that will be mmapped to use as shared 
memory.
  -
  -
  -size
  -

probably bug in JSP in tomcat 4.0.5??

[Tuukk4 |[:)<-<| p4s4n3n]

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 JSP 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:


ShowContent
com.ilmi.net.content.AContentShowTag
JSP
Show content
...continues



Print
com.ilmi.net.content.AContentPrintTag
JSP
Show just some Content
.. continues


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:


 
   CONTENT TAGS EXAMPLES
 
 
 


<%-- First we must import some Tag libraries --%>
<%@ taglib uri="ilmi/ilmi-content" prefix="content"%>

Testing content tags separated

<%-- Then we create some content handler. with database connection --%>


<%-- This is for adding content if we want to this isn't 'must' --%>


test.




test2.

Add new message




 



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 != 
javax.servlet.jsp.tagext.Tag.SKIP_BODY) {
  try {
  if (_jspx_eval_content_AddContent_0 != 
javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE) {
  out = pageContext.pushBody();
  
_jspx_th_content_AddContent_0.setBodyContent((javax.servlet.jsp.tagext.BodyContent) 
out);
  _jspx_th_content_AddContent_0.doInitBody();
  }
  do {
  // end
  // begin 
[file="/content_tags_example.jsp";from=(20,8);to=(20,30)]
  } while (_jspx_th_content_AddContent_0.doAfterBody() == 
javax.servlet.jsp.tagext.Bo

Re: Is Compile Failure? was Re: Need some clarifications

[Henri Gomez]

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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13081] - ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13132] - missing declaration of variable

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c

[jean-frederic clere]

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  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:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime JspContextWrapper.java

[luehe]

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:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-5 build.properties.default

[Steve Downey]

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:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk2 configwebcom.xml

[costin]

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.
   
   
  -The newest JK2 is a rewrite of JK.
  +The newest JK2 is a refactoring of JK.
   The native part has been completly
   restructured and the configuration has been simplified a lot.
   
  @@ -75,19 +75,35 @@
   
   
   
  -JK2 is a full rewrite of JK and is much more powerfull.
  +JK2 is a refactoring of JK and is much more powerfull.
   
   
   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.
   
   
  -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.
   
   
  -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. .
  +
  +
  +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.
  +
  +
  +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.
   
   
   
  
  
  
  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 @@
   
   debug
   0 (false)
  -"debug" state for the component, 1=true 0=false
  +Debug level for the component, 0=disabled, 1..10 
enabled. Higher levels
  +generate more debug.
   
  +
  +version
  +0
  +'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.
  + 
   
   
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-5 build.properties.default

[remm]

remm2002/10/03 10:08:24

  Modified:.build.properties.default
  Log:
  - Update to c-l 1.0.2 (and Ant 1.5.1 is now recommended for building Tomcat).
  
  Revision  ChangesPath
  1.39  +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.38
  retrieving revision 1.39
  diff -u -r1.38 -r1.39
  --- build.properties.default  3 Oct 2002 12:56:39 -   1.38
  +++ build.properties.default  3 Oct 2002 17:08:24 -   1.39
  @@ -80,11 +80,11 @@
   
   
   # - Commons Logging, version 1.0.1 or later -
  -commons-logging.home=${base.path}/commons-logging-1.0.1
  +commons-logging.home=${base.path}/commons-logging-1.0.2
   commons-logging.lib=${commons-logging.home}
   commons-logging-api.jar=${commons-logging.lib}/commons-logging-api.jar
   commons-logging.jar=${commons-logging.lib}/commons-logging.jar
  
-commons-logging.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-logging/v1.0.1/commons-logging-1.0.1.tar.gz
  
+commons-logging.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-logging/v1.0.2/commons-logging-1.0.2.tar.gz
   
   
   # - Java Naming and Directory Interface (JNDI), version 1.2 or later -
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12694] - POST requests fail after server failover

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13253] New: - Migration problems with Tomcat 4.1.10. Please help.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12870] - CoyoteInputStream does not implement the available() method

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

Re: Is Compile Failure? was Re: Need some clarifications

[Jean-Francois Arcand]

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:   
> 
> For additional commands, e-mail: 
> 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteInputStream.java

[costin]

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:   
For additional commands, e-mail: 

[5.0] [VOTE] Removal of the LE distribution

[Remy Maucherat]

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).


+1 [ ] Yes, remove the LE distribution
-1 [ ] No, keep both distributions


Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13253] - Migration problems with Tomcat 4.1.10. Please help.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

Re: Weird seg fault on Mac OS X for mod_jk2 + Apache2

[Costin Manolache]

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:   
For additional commands, e-mail: 

Re: Is Compile Failure? was Re: Need some clarifications

[Remy Maucherat]

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:   
For additional commands, e-mail: 

Re: [5.0] [VOTE] Removal of the LE distribution

[Bob Herrmann]

On Thu, 2002-10-03 at 13:24, Remy Maucherat wrote: 
> 
> +1 [X] Yes, remove the LE distribution
> -1 [ ] No, keep both distributions
> 

simpler is better.




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PROPOSAL] Splitting docs for JK2

[Costin Manolache]

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:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c

[Costin Manolache]

jean-frederic clere wrote:
 
>> :-) Sorry about 'horrible'.
>> 
>> What I meant is - the elements like  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:   
For additional commands, e-mail: 

Re: [5.0] [VOTE] Removal of the LE distribution

[Costin Manolache]

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).
> 
> 
> +1 [X] Yes, remove the LE distribution
> -1 [ ] No, keep both distributions
> 

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:   
For additional commands, e-mail: 

Re: Is Compile Failure? was Re: Need some clarifications

[Steve Downey]

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:   
For additional commands, e-mail: 

RE: [5.0] [VOTE] Removal of the LE distribution

[iasandcb]

First all, I vote

+1 [ ] Yes, remove the LE distribution
-1 [ ] No, keep both distributions


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).


+1 [ ] Yes, remove the LE distribution
-1 [ ] No, keep both distributions


Remy


--
To unsubscribe, e-mail:

For additional commands, e-mail:


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [5.0] [VOTE] Removal of the LE distribution

[iasandcb]

Oops! sorry, I missed my vote.

+1 [X] Yes, remove the LE distribution
-1 [ ] No, keep both distributions


-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

+1 [ ] Yes, remove the LE distribution
-1 [ ] No, keep both distributions


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).


+1 [ ] Yes, remove the LE distribution
-1 [ ] No, keep both distributions


Remy


--
To unsubscribe, e-mail:

For additional commands, e-mail:


--
To unsubscribe, e-mail:

For additional commands, e-mail:


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13223] - JSP pages in XML syntax do not compile properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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 < and >) 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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13223] - JSP pages in XML syntax do not compile properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13254] New: - Page compilation errors missing resource entries

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13254] - Page compilation errors missing resource entries

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

RE: [5.0] [VOTE] Removal of the LE distribution

[Costin Manolache]

iasandcb wrote:

> First all, I vote
> 
> +1 [ ] Yes, remove the LE distribution
> -1 [ ] No, keep both distributions
> 
> 
> 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).
> 
> 
> +1 [ ] Yes, remove the LE distribution
> -1 [ ] No, keep both distributions
> 
> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 

-- 
Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13223] - JSP pages in XML syntax do not compile properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-10-03 18:43 ---
1. The first test case is not a valid XML document.  XML disallows another tag
in the value for an attribute.  For instance, this is illegal:



Therefore you cannot use  as the attribute to 

2. Spec is clear about only supporting expressions in custom tags and standard
actions, but not in other tags.  This 'hole' has been plugged in JSP2.0, which
Tomcat 5 implements.  You can now use


mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

Re: Is Compile Failure? was Re: Need some clarifications

[Han Ming Ong]

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:   
> 
> For additional commands, e-mail: 
> 
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13256] New: - jk2.socket not created in 4.1.12 connector

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13256

jk2.socket not created in 4.1.12 connector

   Summary: jk2.socket not created in 4.1.12 connector
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The jk2.socket is not created correctly under connector 4.1.12 with Tomcat
4.1.12. I have found that the 4.1.10 connector works fine and creates the socket
as expected. 
This happens in RH Linux 7.3 native and running under VMWare on W2k with SP3. 
Apache version is 2.0.40.

Catalina.out contains the message "SEVERE: Can't create apr" - seems like a
missing class.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java

[kinman]

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:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java

[costin]

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:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java

[kinman]

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:   
For additional commands, e-mail: 

RE: [5.0] [VOTE] Removal of the LE distribution

[Craig R. McClanahan]

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
> > 
> > +1 [ ] Yes, remove the LE distribution
> > -1 [ ] No, keep both distributions
> > 
> >
> > 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).
> >
> > 
> > +1 [ ] Yes, remove the LE distribution
> > -1 [ ] No, keep both distributions
> > 
> >
> > Remy
> >
> >
> > --
> > To unsubscribe, e-mail:
> > 
> > For additional commands, e-mail:
> > 
>
> --
> Costin
>
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx DynamicMBeanProxy.java

[costin]

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:   
For additional commands, e-mail: 

Re: [5.0] [VOTE] Removal of the LE distribution

[Jean-Francois Arcand]

+1 [X] Yes, remove the LE distribution
-1 [ ] No, keep both distributions


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:   
> 
> For additional commands, e-mail: 
> 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13144] - Scriplet comment breaks JSPs silently

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10267] - Comments in scriptlets break subsequent sections

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13144] - Scriplet comment breaks JSPs silently

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

Re: [5.0] [VOTE] Removal of the LE distribution

[Bill Barker]

- 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
> > 
> > +1 [ ] Yes, remove the LE distribution
> > -1 [ ] No, keep both distributions
> > 
> >
> > 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.

J2SE 1.2 is the minimum version of the underlying Java platform with which
servlet containers must be built.


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).
> >
> > 
> > +1 [ ] Yes, remove the LE distribution
> > -1 [ ] No, keep both distributions
> > 
> >
> > Remy
> >
> >
> > --
> > To unsubscribe, e-mail:
> > 
> > For additional commands, e-mail:
> > 
>
> --
> Costin
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13258] New: - During form-based authentication a POST turns into a GET

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

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.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13144] - Scriplet comment breaks JSPs silently

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java

[Ignacio J. Ortega]

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:   

For additional commands, e-mail:



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Is Compile Failure? was Re: Need some clarifications

[Steve Downey]

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:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java

[Bill Barker]

- 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:
> 
> For additional commands, e-mail:
> 
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13223] - JSP pages in XML syntax do not compile properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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  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,  is just a way of avoiding "%=
... %". The spec quote above clearly states that  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 -Tag) is invalid. Also, all examples for  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:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java

[Ignacio J. Ortega]

> 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:   
For additional commands, e-mail: 

SSL Client-Auth

[Bob Herrmann]

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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13263] New: - javax.servlet.request.key_size not following servlet spec

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13263

javax.servlet.request.key_size not following servlet spec

   Summary: javax.servlet.request.key_size not following servlet
spec
   Product: Tomcat 4
   Version: 4.0.2 Final
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Major
  Priority: Other
 Component: Connector:JK/AJP (deprecated)
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


According SRV.4.7 of Servlet Spec 2.3, the javax.servlet.request.key_size 
attribute is supposed to be of type java.lang.Integer.  

When using a Connector of type org.apache.ajp.tomcat4.Ajp13Connector, in Tomcat 
4.0.1, getAttribute("javax.servlet.request.key_size") properly returns a 
java.lang.Interger (or null).

In Tomcat 4.0.2 (and higher), the same call returns a java.lang.String, which 
violates the spec.  This causes a ClassCastException for code that attempts to 
use the key_size attribute as an Integer.

Attached is a jsp that can be used in a Apache+mod_ssl+mod_jk+Tomcat webapp to 
show that the class changes to java.lang.String starting in Tomcat 4.0.2, and 
is correctly a java.lang.Integer in Tomcat 4.0.1.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13263] - javax.servlet.request.key_size not following servlet spec

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13264] New: - JspWriter.clear()/clearBuffer() don't reset the remaining buffer size as returned by JspWriter.getRemaining().

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java

[Costin Manolache]

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 find&fix 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:
>> 
>> For additional commands, e-mail:
>> 
>>
>>
>> --
>> To unsubscribe, e-mail:
> 
>> For additional commands, e-mail:
> 
>>

-- 
Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13264] - JspWriter.clear()/clearBuffer() doesn't reset the remaining buffer size as returned by JspWriter.getRemaining().

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://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:   
For additional commands, e-mail: 

please show me how to download the DBCP API jar file

[Shih, John]

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:   
For additional commands, e-mail: