FW: [Ethereal-announce] Ethereal 0.9.5 sources and Windows installer released
ajp support included in latest ethereal ;) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 Ethereal 0.9.5 has been released. This version fixes several potential security problems revealed since the release of 0.9.4. See the security advisory at http://www.ethereal.com/appnotes/enpa-sa-5.html for more details. New Features: The ability to read packet data from a pipe was enhanced. Printing under Windows now works. New Protocols 802.3 LACP, Apache JServ, AODV6, DCERPC Browser, Java RMI, TAPI Updated Protocols ATM, BGP, BOOTP, DCE RPC, EPM, Frame Relay, GTP, L2TP, LMP, MAPI, MIP, MMSE, MTP3, NCP, NFS, NSPI, PPP, Q2931, RADIUS, RSVP, SCSI, SMB, SNA, SOCKS, SPOOLSS, SRVSVC, SunATM, TFTP, TNS, Token Ring, UCP, VJ TCP/IP, WCP, WEP, WSP, WTP Capture File Updates Ethereal can now write LANalyzer files. The Sniffer, nettl, snoop, NetXRay, and libpcap code all received updates. Download Sites The source code and Windows installer can be downloaded immediately from the following locations: Main site: Source: http://www.ethereal.com/distribution/ethereal-0.9.5.tar.gz Windows installer: http://www.ethereal.com/distribution/win32/ethereal-setup-0.9.5.exe SourceForge: http://sourceforge.net/project/showfiles.php?group_id=255 The mirror sites listed at http://www.ethereal.com/download.html#sources should be updated shortly. ___ Ethereal-announce mailing list [EMAIL PROTECTED] http://www.ethereal.com/mailman/listinfo/ethereal-announce -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Valves, requests and getting the session
Mmm. It would appear I can only get the session if the value is defined in the Context in server.xml. Ie I cannot define it in the default location in server.xml (where the catalina SingleSIgnOn is commented) and expect it to work. Is this correct? And if so, can I achieve what I want to, ie a valve for all contexts? John On Sunday 30 June 2002 21:38, John Baker wrote: On Sunday 30 June 2002 9:35 pm, Craig R. McClanahan wrote: Hmm ... this is baslically how the standard form-based login implementation creates a session, except that it goes on and gets the internal Session object ... That's what I thought. I presume you're trying to create the session *before* calling context.invokeNext(), right? If you don't the response will have already been committed so creating a new session would be ineffective. Yes, I am. I need to check to see if certain objects are in the session and if not, see if they are in another session that is pointed to by the Cookie id. It's like SingleSignOn, but slightly different. However I'm a bit confused to why I can't get a session, even when the rest of the app (the jsp pages etc) are making good use of it., The headers also show the session id, but oddly enough calling HttpServletRequest.SessionIdFromCookie() returns true, but HttpServletRequest.isRequestSessionIdvalid() returns false! John -- John Baker, BSc CS. Java Developer, TEAM/Slb. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: PROPOSAL: Jasper34 removal
+1 - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, June 28, 2002 6:43 PM To: List Tomcat-Dev Subject: PROPOSAL: Jasper34 removal Since jasper2 now has support for tag pooling and most of the optimizations in jasper34, I would like to remove 34. 34 is a refactoring attempt of jasper1 ( the version included in 3.3 ). It was never released. Given the plans for 5.0 there is no point on keeping unused code around. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10328] - Rpm doesn't install with correct ownership/permissions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10328. 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=10328 Rpm doesn't install with correct ownership/permissions --- Additional Comments From [EMAIL PROTECTED] 2002-07-01 08:30 --- Thanks to specify which rpm release (there is a second release available) and which directories are faulty owned -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/xdocs configweb.xml index.xml style.css.in style.xsl.in
Hey, it seems Nacho goes to bug hunting in xsl, good news, since I'm working on using xdocs for jk 1.2.0. BTW, how could we have xdocs handling at both time between jk and jk2 ? I was thinking at the following layout : xdocs xdocs/common(ajp13) xdocs/jk1 (buildingap, buildingiis, buildingiplanet, configap, configiis, configiplanet, faq) xdocs/jk2 (buildingap, buildingiis, buildingiplanet, configap, configiis, configiplanet, faq) The goal could be : Having a full jk/jk2 on jakarta, and only jk in a mod_jk tarball and only jk2 in a mod_jk2 tarball. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
4.0/4.1: Session handling without cookies broken
Hi Guys,
I recently had the pleasure to work more with web applications and am now
finding my way back to the server source. First impression: tomcat grew
big, compared to JServ times .. but it seems, that its actual main aim,
being a small, robust and fast servlet engine - isn't as dominant as it
used to be ... (any folks here from the good ol' JServ times ? At least I
see Pier quite often in the list).
Anyway, while making the wingS application framework
(http://wings.mercatis.de/) work with Tomcat 4.x, I've
found two bugs in TC, that go hand in hand, but basically make
working with URL encoded sessions unpredictable or basically not working.
(If applications rely on URL-encoding, then these can be regarded as
critical bugs).
Both bugs show up, if invalidated sessions come via cookies from the
browser.
Bug #2 can have an impact as well if multiple session cookies for
different servlet contextes on that hosts are available: only the first
cookie is accepted. Didn't verify this, but if failing as expected,
then this is a severe bug, because only the first servlet context will
work with a session ...
These bugs are in both CVS versions of tomcat 4.0 and 4.1.
One of the bugs can be easily fixed (fix given), the other bug
probably needs a bit more work.
An example servlet that exposes both bugs is available.
*
Bug #1 ; fix available
*
The logic to determine whether a URL needs to be encoded in
HttpServletResponse.encodeURL() is broken. In
HttpServletResponseBase.isEncodeable(String location), it
decides, that the URL needn't be encoded in the URL, if the
current ID comes from the cookie; see code-snippet from
HttpServletResponseBase:
---
if (hreq.isRequestedSessionIdFromCookie()) {
return (false);
}
--
However, this does not take into account, that the session ID we got
might have been from some previous session that already is invalidated,
i.e. is not valid. In this case isRequestedSessionIdFromCookie() will
return true, but this does not say anything if future (valid) sessions
will come through the cookie.
The fix is easy: So the only way to check this correctly is:
-
if (hreq.isRequestedSessionIdFromCookie()
hreq.isRequestedSessionIdValid()) {
return (false);
}
-
*
Bug #2 ; detailed explanation but no fix yet
*
There is a bug in the way, the session id is grabbed
from the request. If there is more than one session id in the request
-- in the URL and a Cookie, for instance -- the session id found in the
cookie _always_ wins. This is a problem, if the browsers sends an
invalidated cookie and you choose to use URL-encoding in a later session:
even if the session id from the URL (via encodeURL(), that works only
after fixing Bug #1) is valid, the application always gets the old
and invalid session from the cookie instead of the valid session from the
URL.
The expected behaviour of course is: give preference to valid session
id's if we get more than one session id.
The current session id grabbing-from-http-request algorithm is as follows
(from HttpProcessor.java)
1. get the session ID from the URL, if any.
[HttpProcessor.parseRequest()]
2. go through the cookies. If there is _any_
jsessionid - grab the _first one_ and
override the jsession-id found in the
URL unconditionally. And set
request.setRequestedSessionCookie(true);
request.setRequestedSessionURL(false);
even if the jsession id found in the
cookie is the _same_ as found in the URL,
in that case it should be
setRequestedSessionURL(true).
[HttpProcessor.parseHeaders()]
-
However, it should be something like:
-
1. get the jsessionid from the URL, if any.
if found there, setRequestedSessionURL(true)
else setRequestedSessionURL(false)
2. go through the cookies.
FOREACH jsessionid found in the cookies:
IF the sessionid found is valid in that context
IF found session id equals id already in request
setRequestedSessionCookie(true)
ELSE (* see below)
override the session id in request with the cookie-value
setRequestedSessionCookie(true)
setRequestedSessionURL(false)
ENDIF
BREAK FOREACH
ELSE IF we have not found any session id before
(either from URL or a previous cookie)
// set at least some session id
set the session id from the cookie
setRequestedSessionCookie(true)
END FOREACH
-
This makes sure, that we find the valid session id, if there is more than
one session.
discussion
I'd even suggest to give a higher priority to the
URL encoded session: if the session id found in the URL is _valid_,
then ignore any valid session id in the cookies unless it is the same.
This enables to have two independant web-application instances in the
RE: isapi_redirector2 build using static APR
I strongly agree with costin, and it has been a point we discuss many times before with Pier for mod_webapp. Even if APR is a library used mainly by Apache 2.0, nothing prevent it to be used elsewhere and for example under Windows and IIS. The only problem is that there is still no official APR, release, and as such APR came out which each Apache 2.0 release, that's why you could find APR_APACHE_2... tarballs in jakarta-tomcat-connectors. So I'd like to have apr.so or apr.dll for windows, distributed together with future jk2 (jk didn't need it). - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Sunday, June 30, 2002 11:15 PM To: Tomcat Developers List Subject: RE: isapi_redirector2 build using static APR I'm close to -1 on this, but if everyone else is +1 I'll change it to -0. Apr is a library, just like glib or libc, and I hope soon more modules and programs will use it - including in IIS or other environments. I see no problem with having apr.dll - it is actually easier to get it from an Apache installation ( or pre-built whenever they have a release ) Maybe having the dll around will encourage other uses as well :-) Costin On Sun, 30 Jun 2002, Mladen Turk wrote: -Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] Sent: 30. lipanj 2002 18:45 To: '[EMAIL PROTECTED]' Subject: RE: isapi_redirector2 build using static APR De: Mladen Turk [mailto:[EMAIL PROTECTED]] Enviado el: 30 de junio de 2002 7:28 hmmm, this will force us to make a binary everytime Apache2 has a release too? in this case -1, if not +1 Only if the APR changes itself (in the API way), but then we have to rebuild it in any case. All the Apache utils itself use the static APR if they don't need to go to the httpd directly. Since we are using apr in the IIS connector only as a common library for things like pools, tables, network io, etc. The only rebuild needed would be in the case of some sort of discovered bug. The apr itself is quite stable, and since we are not building apache module, versioning is not an issue here. Actually we'll be less dependent. Other benefit will be simply the elimination of things like various libapr.dll's flying around. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PROPOSAL] removing outdated makefile/buildfile for mod_jk 1.2.0
Ok, I'll remove them so, and will update the build documentation (in xdocs). BTW, who could tell us more about mod_jk 1.2.x static build ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Saturday, June 29, 2002 5:19 AM To: Tomcat Dev List Subject: Re: [PROPOSAL] removing outdated makefile/buildfile for mod_jk 1.2.0 As long as configure/make works I'm +1. Bojan On Fri, 2002-06-28 at 22:39, GOMEZ Henri wrote: Hi, What about removing all the outdated makefile and build.platform.sh present in jk/native now that we have a working configure/makefile or ant/jkant ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Valves, requests and getting the session
Hi, Yes, I am. I need to check to see if certain objects are in the session and if not, see if they are in another session that is pointed to by the Cookie id. It's like SingleSignOn, but slightly different. However I'm a bit confused to why I can't get a session, even when the rest of the app (the jsp pages etc) are making good use of it., The headers also show the session id, but oddly enough calling HttpServletRequest.SessionIdFromCookie() returns true, but HttpServletRequest.isRequestSessionIdvalid() returns false! Maybe this is a similar problem I had when trying to fix the bug described in my previous posting: the Context is not yet set (HttpRequestBase.setContext()) at that stage - thus HttpServletRequest.isRequestSessionIdValid() will return false (see implementation of isRequestSessionIdValid()). Henner. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Valves, requests and getting the session
On Monday 01 July 2002 10:43, Henner Zeller wrote: Hi, Yes, I am. I need to check to see if certain objects are in the session and if not, see if they are in another session that is pointed to by the Cookie id. It's like SingleSignOn, but slightly different. However I'm a bit confused to why I can't get a session, even when the rest of the app (the jsp pages etc) are making good use of it., The headers also show the session id, but oddly enough calling HttpServletRequest.SessionIdFromCookie() returns true, but HttpServletRequest.isRequestSessionIdvalid() returns false! Maybe this is a similar problem I had when trying to fix the bug described in my previous posting: the Context is not yet set (HttpRequestBase.setContext()) at that stage - thus HttpServletRequest.isRequestSessionIdValid() will return false (see implementation of isRequestSessionIdValid()). Yes, I was thinking this when I read your mail. I'm now putting a valve in each relevant Context and using a static Hashtable. Sick, I know, but it seems I have no other choice for now. John -- John Baker, BSc CS. Java Developer, TEAM/Slb. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
4.1/5.0 Status
I've tried to update the proposal draft according to the comments I got, including benchmarking, and adding more details about the changes which will be introduced. After looking at the release management duties that will have to be done for 5.0, it turns out neither Larry nor myself have enough time to do it alone, because of the sheer amount of modules Tomcat will have. So, instead, it is proposed that the release management duties are shared (how exactly they will be shared has yet to be determined) between Larry and me. I plan to call for a vote on the proposal very soon. Some links to the new specs: Servlet 2.4 Public Review: http://jcp.org/aboutJava/communityprocess/review/jsr154/index.html JSP 2.0 Public Review: http://jcp.org/aboutJava/communityprocess/review/jsr152/index.html On the 4.1.x side, 4.1.6 looks like a decent test release so far (with the problem of the memory leak having been confirmed to be fixed); I'll be doing some bughunting this week (and I encourage other committers to do the same ;-)). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Cookies
Hi, Has anyone found that browsers refuse to delete cookies when you do Cookie.setMaxAge(0); ? I can not get any browser to delete a cookie! Having looked at the response the Set-Cookie: header appears correctly formed. John -- John Baker, BSc CS. Java Developer, TEAM/Slb. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native BUILDING
hgomez 2002/07/01 04:01:24
Added: jk/native BUILDING
Log:
Updated build documentation for mod_jk, replace README.configure
Revision ChangesPath
1.1 jakarta-tomcat-connectors/jk/native/BUILDING
Index: BUILDING
===
Building from the cvs tree: (for developers only).
---
When using a cvs tree buildconf.sh must be run before configure.
The today version of buildconf.sh build the following files:
libtool files in scripts/build/unix (should copy them?).
Makefile.in from Makefile.am
aclocal.m4 from different m4 files located in the local machine.
configure from configure.in and aclocal.m4.
If you see error message from automake, don't care about them.
Building using configure
It is possible to use autoconf for configuration and installation.
To create jakarta-tomcat-connectors's autoconf script, you will need libtool
1.3.3 or higher, and autoconf 2.13 or newer.
Those tools will not be required if you are just
using a package downloaded from apache.org, they are only required for
developers.
To configure jakarta-tomcat-connectors run the following commands.
./buildconf.sh (not required unless you are a developer)
./configure [autoconf arguments] [jakarta-tomcat-connectors arguments]
make
It is possible to set CFLAGS and LDFLAGS to add some platform specifics:
LDFLAGS=-lc \
./configure -with-apxs=/home2/local/apache/bin/apxs
Build for both Apache 1.3 and 2.0
-
If you want to build mod_jk for Apache 1.3 and 2.0, you should :
use configure and indicate Apache 1.3 apxs location (--with-apxs)
use make
copy the mod_jk binary to the apache modules location
make clean (to remove all previously compiled modules)
use configure and indicate Apache 2.0 apxs location,
then make.
./configure --with-apxs=/usr/sbin/apxs
make
cp ./apache-1.3/mod_jk.so /usr/lib/apache
make clean
./configure --with-apxs=/usr/sbin/apxs2
make
cp ./apache-2.0/mod_jk.so /usr/lib/apache2
Examples
Apache2.0, JNI support:
./configure --with-apxs=/opt/apache2/bin/apxs --with-java-home=${JAVA_HOME}
--with-java-platform=2 -enable-jni
Apache 1.3, no JNI support:
./configure --with-apxs=/usr/sbin/apxs
jakarta-tomcat-connectors arguments
---
JVM related parameters:
--with-java-home=DIR
DIR is the patch to the JDK root directory. Something like: /opt/java/jdk12
--with-os-type[=SUBDIR]
SUBDIR is the os-type subdirectory, normaly configure should guess it
correctly.
--with-arch-type[=SUBDIR]
SUBDIR is the arch subdirectory, normaly configure should guess it correctly.
--with-java-platform=VAL
VAL is the Java platform 1 is 1.1.x and 2 is 1.2.x. It is guessed correctly.
Apache related parameters:
--with-apxs[=FILE]
FILE is the location of the apxs tool. Default is finding apxs in PATH.
It builds a shared Apache module. It detects automaticly the Apache version.
(2.0 and 1.3)
* --with-apache=DIR
DIR is the path where apache sources are located.
The apache sources should have been configured before configuring mod_jk.
DIR is something like: /home/apache/apache_1.3.19
It builds a static Apache module.
--enable-EAPI
This parameter is needed when using Apache-1.3 and mod_ssl, otherwise you
will get the error message: this module might crash under EAPI! when
loading libjk.so in httpd.
JNI support:
--enable-jni
Build the jni_connect.so and the JNI worker.
* Static build need more tests, and we strongly recommand dynamic build
using DSO/APXS.
Installation
The mod_jk binary will be in :
./apache-1.3/mod_jk.so if you select to build mod_jk for apache 1.3
./apache-2.0/mod_jk.so if you select to build mod_jk for apache 2.0
Misc notes
--
HP-UX build notes :
If you plan to use GCC on HP-UX to build mod_jk, be sure to
have -DHPUX11GCC defined (usually by setting CLAGS before configure)
Reports are that the stripped down cc version that ships with
HP-UX won't be able to works, you should habe the HP add-on ANSI C
Compiler package.
A good repository for HP-UX gnu tools is :
http://gatekeep.cs.utah.edu/
Solaris build notes :
the build should works with the GNU gcc compiler, on both
SPARC and x86 architecture systems.
A good repository for Solaris gnu tools is :
http://www.sunfreeware.com/
Be carefull when mixing native compiler and gnu compiler, and
ensure that apache and mod_jk will be
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 build-unix.sh install-unix.sh
hgomez 2002/07/01 04:01:52 Modified:jk/native README Removed: jk/native README.configure jk/native/apache-1.3 Makefile.freebsd Makefile.linux README.hpux README.solaris build-hpux-cc.sh build-hpux.sh build-solaris.sh build-unix.sh jk/native/apache-2.0 build-unix.sh install-unix.sh Log: Remove old build files, since there is now a working configure/make solution Revision ChangesPath 1.4 +2 -2 jakarta-tomcat-connectors/jk/native/README Index: README === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/README,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- README27 Jun 2002 15:13:42 - 1.3 +++ README1 Jul 2002 11:01:51 - 1.4 @@ -27,4 +27,4 @@ * Direct access to Tomcat 3.2/3.3/4.0/4.1 servlet engine via ajp13 protocol. -* OK, then how do I build web-connector ? Just take a look at README.configure +* OK, then how do I build web-connector ? Just take a look at BUILDING -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/iis README
hgomez 2002/07/01 04:08:35 Added: jk/native/iis README Log: Initial README for IIS, may be Nacho could put more informations in it. Revision ChangesPath 1.1 jakarta-tomcat-connectors/jk/native/iis/README Index: README === ABOUT - The Tomcat redirector was developed using Visual C++ Ver.6.0, so having this environment is a prerequisite if you want to perform a custom build. REQUIREMENT --- MS VC 6.0 (+ update, latest service pack is sp5) MS PLATFORM SDK BUILDING The steps that you need to take are: 1. Change directory to the isapi redirector plugins source directory. 2. Execute the following command: MSDEV isapi.dsp /MAKE ALL If msdev is not in your path, enter the full path to msdev.exe This will build both release and debug versions of the redirector plugin. An alternative will be to open the isapi workspace file (isapi.dsw) in msdev and build it using the build menu. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10372] New: - SingleSignOn toString() throws NullPointerException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10372.
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=10372
SingleSignOn toString() throws NullPointerException
Summary: SingleSignOn toString() throws NullPointerException
Product: Tomcat 4
Version: 4.0 Beta 1
Platform: Macintosh
URL: N/A
OS/Version: MacOS X
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
when the toString method is called when the container fields is null, a
NullPointerException is thrown. (this is annoying since this exception is prevents use
in
jboss.)
this is caused by the toString() method not checking for a null value. at the moment
we
have:
/**
* Return a String rendering of this object.
*/
public String toString() {
StringBuffer sb = new StringBuffer(SingleSignOn[);
sb.append(container.getName());
sb.append(]);
return (sb.toString());
}
a simple check for null prevents this exception occuring. for example:
/**
* Return a String rendering of this object.
*/
public String toString() {
StringBuffer sb = new StringBuffer(SingleSignOn[);
if (container != null) {
sb.append(container.getName());
}
sb.append(]);
return (sb.toString());
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/netscape README
hgomez 2002/07/01 04:16:35 Added: jk/native/netscape README Log: Very minimal README for iplanet/netscape build, we have little information about it Revision ChangesPath 1.1 jakarta-tomcat-connectors/jk/native/netscape/README Index: README === ABOUT - The redirector was originally developed using Visual C++ Ver.6.0, so having this environment is a prerequisite if you want to perform a custom build on Windows systems On Unix system, a Makefile.solaris is provided and should be adapted to tailor to your own configuration. REQUIREMENT for Windows build - MS VC 6.0 (+ update, latest service pack is 5) BUILDING on Windows --- The steps that you need to take are: 1. Change directory to the nsapi redirector plugins source directory. 2. Execute the following command: MSDEV nsapi.dsp /MAKE ALL If msdev is not in your path, enter the full path to msdev.exe This will build both release and debug versions of the redirector plugin. An alternative will be to open the isapi workspace file (nsapi.dsw) in msdev and build it using the build menu. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
mod_jk 1.2.0 - release notes
Hi to all, I'm finalizing the mod_jk 1.2.0 release. I updated the Apache build instruction, removed outdated Makefile and build files. I added a minimal IIS build document, from what it's present in tomcat-iis-howto.html. Same thing for netscape/iplanet build instructions. Since the previous release, there was update in : Load-Balancing and keep-alive/timeout and I need more documentation on it from commiters. I recall that Load-Balancing was updated to handle failure only mode. Regards - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/netscape README
See typo below ;) On Mon, 2002-07-01 at 13:16, [EMAIL PROTECTED] wrote: hgomez 2002/07/01 04:16:35 Added: jk/native/netscape README Log: Very minimal README for iplanet/netscape build, we have little information about it Revision ChangesPath 1.1 jakarta-tomcat-connectors/jk/native/netscape/README Index: README === ABOUT - The redirector was originally developed using Visual C++ Ver.6.0, so having this environment is a prerequisite if you want to perform a custom build on Windows systems On Unix system, a Makefile.solaris is provided and should be adapted to tailor to your own configuration. REQUIREMENT for Windows build - MS VC 6.0 (+ update, latest service pack is 5) BUILDING on Windows --- The steps that you need to take are: 1. Change directory to the nsapi redirector plugins source directory. 2. Execute the following command: MSDEV nsapi.dsp /MAKE ALL If msdev is not in your path, enter the full path to msdev.exe This will build both release and debug versions of the redirector plugin. An alternative will be to open the isapi workspace file (nsapi.dsw) in msdev and isapi should nsapi I guess ;) Mvgr, Martin build it using the build menu. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10373] New: - Wrong response status code for custom error page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10373. 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=10373 Wrong response status code for custom error page Summary: Wrong response status code for custom error page Product: Tomcat 4 Version: 4.0.4 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi If I don't specify error-page for code 401 (unauthorized) in web.xml - all works fine. But if I specify it then the server sends the page with code 200 (I see it in log), and browser does not show the name/password popup. That is because org.apache.catalina.valves.ErrorDispatcherValve resets state of response in method custom. I've tried to comment the call out and it works, but I'm not sure that I don't need the reset really. It would be better to call reset and then restore state/message, but javax.servlet.http.HttpServletResponse has no getState() method. So, problem is in file org/apache/catalina/valves/ErrorDispatcherValve.java, line 384. Hope, you can find a better solution :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
That Cookie thing
It appears if you don't set a path on the cookie (setPath), it doesn't default to anything and therefore doesn't place anything in the response header. Browsers then ignore it ;-) Perhaps Cookie by default should have a path of /. John -- John Baker, BSc CS. Java Developer, TEAM/Slb. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
if you want the cookies to be readable by all pages, you should set it to /. That's standard practice. Also, if you have multiple webserver with names like www1, www2, www3., you should also set the cookie to use yourbiz.com. peter John Baker wrote: It appears if you don't set a path on the cookie (setPath), it doesn't default to anything and therefore doesn't place anything in the response header. Browsers then ignore it ;-) Perhaps Cookie by default should have a path of /. John -- John Baker, BSc CS. Java Developer, TEAM/Slb. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk 1.2.0 - release notes
-Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: 1. srpanj 2002 13:20 To: [EMAIL PROTECTED] Subject: mod_jk 1.2.0 - release notes I'm finalizing the mod_jk 1.2.0 release. Load-Balancing and keep-alive/timeout and I need more documentation on it from commiters. Firewall support options: socket_keepalive=0[1] Using the keep-alive socket option the mod_jk connector can request that a TCP/IP provider enable the use of keep-alive packets on TCP connections. socket_timeout=seconds The socket_timeout forces the socket disconnection if the connection has not been used for specified number of seconds. Performance options: cache_timeout=seconds This option used together with cachesize, enables the errorless peek server loads. To be able to use that option the cachesize must be set for threaded servers (IIS/Apache WIN32) to the value that is slightly higher then the maximum number of concurrent users. After the cache_timeout all unused connections will be forcibly dropped. Example: #This directive will handle up to the 100 concurent users for threaded servers worker.ajp13.cachesize=100 #When the server load drops all the extra connections will be recycled worker.ajp13.cache_timeout=15 #Set the keep-alive option if the TC is behind the firewall worker.ajp13.socket_keepalive=1 #Set the 30 minute timeout (check with the firewall settings) worker.ajp13.socket_timeout=900 Sorry, It's not much ;) MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
On Monday 01 July 2002 12:59, peter lin wrote: if you want the cookies to be readable by all pages, you should set it to /. That's standard practice. Also, if you have multiple webserver with names like www1, www2, www3., you should also set the cookie to use yourbiz.com. I know this ;-) But I'd forgotten to put the / there, and assumed the browser would assume this if no / was passed to it. However they don't, so I was suggesting that if a Cookie has no path set then one should be written by default as a totally useless header is currently written in the form: Set-Cookie: someName=someValue; expires and due to the lack of a path, every browser ignores it. peter John Baker wrote: It appears if you don't set a path on the cookie (setPath), it doesn't default to anything and therefore doesn't place anything in the response header. Browsers then ignore it ;-) Perhaps Cookie by default should have a path of /. John -- John Baker, BSc CS. Java Developer, TEAM/Slb. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- John Baker, BSc CS. Java Developer, TEAM/Slb. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
that's the problem with assumptions :) Actually I believe the W3C spec says the path will default to directory the pages resides in. So that page /hello/greeting.jsp will have /hello as the path. Only files under /hello can read the cookie. Atleast that's my understanding of how cookie path is supposed to be set. Some one correct me if I am wrong. peter John Baker wrote: On Monday 01 July 2002 12:59, peter lin wrote: if you want the cookies to be readable by all pages, you should set it to /. That's standard practice. Also, if you have multiple webserver with names like www1, www2, www3., you should also set the cookie to use yourbiz.com. I know this ;-) But I'd forgotten to put the / there, and assumed the browser would assume this if no / was passed to it. However they don't, so I was suggesting that if a Cookie has no path set then one should be written by default as a totally useless header is currently written in the form: Set-Cookie: someName=someValue; expires and due to the lack of a path, every browser ignores it. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk 1.2.0 - release notes
Sorry, It's not much ;) Not so bad ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
On Monday 01 July 2002 13:16, peter lin wrote:
that's the problem with assumptions :)
Actually I believe the W3C spec says the path will default to directory
the pages resides in. So that page /hello/greeting.jsp will have
/hello as the path. Only files under /hello can read the cookie.
Atleast that's my understanding of how cookie path is supposed to be
set. Some one correct me if I am wrong.
Well a reliable source tells me that there is no w3c spec for Cookies, and
infact the concept was conjured by Netscape. There is an RFC spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without a path, it
might be handy to add it by default so other people don't spend an hour or
two sitting there thinking Why doesn't this work?. The current context path
would be handy, so the response code could look like this:
public void addCookie(Cookie c)
{
// whatever
if (c.getPath() == null)
c.setPath(getContextPath());
// etc
}
Just a thought :)
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should set it
to /. That's standard practice. Also, if you have multiple webserver
with names like www1, www2, www3., you should also set the cookie
to use yourbiz.com.
I know this ;-) But I'd forgotten to put the / there, and assumed the
browser would assume this if no / was passed to it. However they don't,
so I was suggesting that if a Cookie has no path set then one should be
written by default as a totally useless header is currently written in
the form:
Set-Cookie: someName=someValue; expires
and due to the lack of a path, every browser ignores it.
--
John Baker, BSc CS.
Java Developer, TEAM/Slb. http://www.teamenergy.com
Views expressed in this mail are my own.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
http://wp.netscape.com/newsref/std/cookie_spec.html
OR
http://www.ietf.org/rfc/rfc2109.txt
OR
http://www.ietf.org/rfc/rfc2965.txt
PATH=path
Optional. The Path attribute specifies the subset of URLs to which this
cookie applies.
John Baker wrote:
On Monday 01 July 2002 13:16, peter lin wrote:
that's the problem with assumptions :)
Actually I believe the W3C spec says the path will default to directory
the pages resides in. So that page /hello/greeting.jsp will have
/hello as the path. Only files under /hello can read the cookie.
Atleast that's my understanding of how cookie path is supposed to be
set. Some one correct me if I am wrong.
Well a reliable source tells me that there is no w3c spec for Cookies, and
infact the concept was conjured by Netscape. There is an RFC spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without a path, it
might be handy to add it by default so other people don't spend an hour or
two sitting there thinking Why doesn't this work?. The current context path
would be handy, so the response code could look like this:
public void addCookie(Cookie c)
{
// whatever
if (c.getPath() == null)
c.setPath(getContextPath());
// etc
}
Just a thought :)
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should set it
to /. That's standard practice. Also, if you have multiple webserver
with names like www1, www2, www3., you should also set the cookie
to use yourbiz.com.
I know this ;-) But I'd forgotten to put the / there, and assumed the
browser would assume this if no / was passed to it. However they don't,
so I was suggesting that if a Cookie has no path set then one should be
written by default as a totally useless header is currently written in
the form:
Set-Cookie: someName=someValue; expires
and due to the lack of a path, every browser ignores it.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
On Monday 01 July 2002 13:29, Tim Funk wrote:
http://wp.netscape.com/newsref/std/cookie_spec.html
OR
http://www.ietf.org/rfc/rfc2109.txt
OR
http://www.ietf.org/rfc/rfc2965.txt
PATH=path
Optional. The Path attribute specifies the subset of URLs to which this
cookie applies.
But as IE/Moz/Konqueror (anyone else fancy trying some others?) ignore this,
would it be more useful to provide a default in some way so it isn't ignored?
The chances of getting all those three to stick to the spec are low ;-) Or
even a warning in the logs that your code is not likely to work?
Of course, normally I'd say follow the spec, but sadly if your target
audience doesn't, there isn't really much you can do.
John Baker wrote:
On Monday 01 July 2002 13:16, peter lin wrote:
that's the problem with assumptions :)
Actually I believe the W3C spec says the path will default to directory
the pages resides in. So that page /hello/greeting.jsp will have
/hello as the path. Only files under /hello can read the cookie.
Atleast that's my understanding of how cookie path is supposed to be
set. Some one correct me if I am wrong.
Well a reliable source tells me that there is no w3c spec for Cookies,
and infact the concept was conjured by Netscape. There is an RFC spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without a
path, it might be handy to add it by default so other people don't spend
an hour or two sitting there thinking Why doesn't this work?. The
current context path would be handy, so the response code could look like
this:
public void addCookie(Cookie c)
{
// whatever
if (c.getPath() == null)
c.setPath(getContextPath());
// etc
}
Just a thought :)
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should set it
to /. That's standard practice. Also, if you have multiple webserver
with names like www1, www2, www3., you should also set the cookie
to use yourbiz.com.
I know this ;-) But I'd forgotten to put the / there, and assumed the
browser would assume this if no / was passed to it. However they don't,
so I was suggesting that if a Cookie has no path set then one should be
written by default as a totally useless header is currently written in
the form:
Set-Cookie: someName=someValue; expires
and due to the lack of a path, every browser ignores it.
--
John Baker, BSc CS.
Java Developer, TEAM/Slb. http://www.teamenergy.com
Views expressed in this mail are my own.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
John Baker wrote: Well a reliable source tells me that there is no w3c spec for Cookies, and infact the concept was conjured by Netscape. There is an RFC spec for Cookies, but it's largely ignored. So as the useful browsers out there ignore Cookie requests without a path, it might be handy to add it by default so other people don't spend an hour or two sitting there thinking Why doesn't this work?. The current context path would be handy, so the response code could look like this: http://wp.netscape.com/newsref/std/cookie_spec.html http://www.ietf.org/rfc/rfc2109.txt Too many specs to keep track of. I disagree the default should be set to /, since that isn't how other web/app servers handle it. I know both websphere and weblogic follow netscapes suggestion. The spec might be bad and probably is, but since that's how most browsers handle it, changing might cause more problems than it solves. just my .2 peter -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
On Monday 01 July 2002 13:38, peter lin wrote: John Baker wrote: Well a reliable source tells me that there is no w3c spec for Cookies, and infact the concept was conjured by Netscape. There is an RFC spec for Cookies, but it's largely ignored. So as the useful browsers out there ignore Cookie requests without a path, it might be handy to add it by default so other people don't spend an hour or two sitting there thinking Why doesn't this work?. The current context path would be handy, so the response code could look like this: http://wp.netscape.com/newsref/std/cookie_spec.html http://www.ietf.org/rfc/rfc2109.txt Too many specs to keep track of. I disagree the default should be set to /, since that isn't how other web/app servers handle it. I know both websphere and weblogic follow netscapes suggestion. The spec might be bad and probably is, but since that's how most browsers handle it, changing might cause more problems than it solves. just my .2 Yes, / is bad, I think I'll forget that. The default context would be more handy, and a warning would be very handy. But most browsers don't handle it, infact, I can't find one that does (although I've only tried IE/Moz1.0/Konq). But if that collection don't handle it, any cookie sent without a path is almost totally useless. I vote a warning. Warnings are great, they save wasting time. John -- John Baker, BSc CS. Java Developer, TEAM/Slb. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: That Cookie thing
I have to disagree with the default as well.. as that can be dangerous
to someone who simply forgot to supply the path.. this could cause
security issues with where the cookie can be read.. the way is
currently works if you forgot to provide the path a you will find out
quickly that something is not working in the same manor that you did and
can fix it.
-Original Message-
From: John Baker [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 01, 2002 8:33 AM
To: Tomcat Developers List
Subject: Re: That Cookie thing
On Monday 01 July 2002 13:29, Tim Funk wrote:
http://wp.netscape.com/newsref/std/cookie_spec.html
OR
http://www.ietf.org/rfc/rfc2109.txt
OR
http://www.ietf.org/rfc/rfc2965.txt
PATH=path
Optional. The Path attribute specifies the subset of URLs to which
this
cookie applies.
But as IE/Moz/Konqueror (anyone else fancy trying some others?) ignore
this,
would it be more useful to provide a default in some way so it isn't
ignored?
The chances of getting all those three to stick to the spec are low ;-)
Or
even a warning in the logs that your code is not likely to work?
Of course, normally I'd say follow the spec, but sadly if your target
audience doesn't, there isn't really much you can do.
John Baker wrote:
On Monday 01 July 2002 13:16, peter lin wrote:
that's the problem with assumptions :)
Actually I believe the W3C spec says the path will default to
directory
the pages resides in. So that page /hello/greeting.jsp will have
/hello as the path. Only files under /hello can read the
cookie.
Atleast that's my understanding of how cookie path is supposed to be
set. Some one correct me if I am wrong.
Well a reliable source tells me that there is no w3c spec for
Cookies,
and infact the concept was conjured by Netscape. There is an RFC
spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without a
path, it might be handy to add it by default so other people don't
spend
an hour or two sitting there thinking Why doesn't this work?. The
current context path would be handy, so the response code could look
like
this:
public void addCookie(Cookie c)
{
// whatever
if (c.getPath() == null)
c.setPath(getContextPath());
// etc
}
Just a thought :)
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should
set it
to /. That's standard practice. Also, if you have multiple
webserver
with names like www1, www2, www3., you should also set the
cookie
to use yourbiz.com.
I know this ;-) But I'd forgotten to put the / there, and assumed
the
browser would assume this if no / was passed to it. However they
don't,
so I was suggesting that if a Cookie has no path set then one
should be
written by default as a totally useless header is currently written
in
the form:
Set-Cookie: someName=someValue; expires
and due to the lack of a path, every browser ignores it.
--
John Baker, BSc CS.
Java Developer, TEAM/Slb. http://www.teamenergy.com
Views expressed in this mail are my own.
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
On Monday 01 July 2002 13:53, John Trollinger wrote:
I have to disagree with the default as well.. as that can be dangerous
to someone who simply forgot to supply the path.. this could cause
security issues with where the cookie can be read.. the way is
currently works if you forgot to provide the path a you will find out
quickly that something is not working in the same manor that you did and
can fix it.
No, you don't find out quickly if you don't know what you're doing and you're
newish to web programming. You only find out if you've got a good knowledge
of web browsers and you realise that although path is optional, the majority
of browsers ignore it in some cases. For example, this problem only occurs if
a Cookie will be deleted (setting maxAge to 0) and it has no path. Even the
best web programmers will take some time to figure out that's wrong.
Therefore although a default is a bad idea, a warning should be provided
clearly in the logs that you've not provided a path, and although the
wishy-washy (noone takes any notice of) spec says that's ok, most browsers
will totally ignore it.
Therefore you've just made many developers very happy with you for providing
such a sensible warning.
John
-Original Message-
From: John Baker [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 01, 2002 8:33 AM
To: Tomcat Developers List
Subject: Re: That Cookie thing
On Monday 01 July 2002 13:29, Tim Funk wrote:
http://wp.netscape.com/newsref/std/cookie_spec.html
OR
http://www.ietf.org/rfc/rfc2109.txt
OR
http://www.ietf.org/rfc/rfc2965.txt
PATH=path
Optional. The Path attribute specifies the subset of URLs to which
this
cookie applies.
But as IE/Moz/Konqueror (anyone else fancy trying some others?) ignore
this,
would it be more useful to provide a default in some way so it isn't
ignored?
The chances of getting all those three to stick to the spec are low ;-)
Or
even a warning in the logs that your code is not likely to work?
Of course, normally I'd say follow the spec, but sadly if your target
audience doesn't, there isn't really much you can do.
John Baker wrote:
On Monday 01 July 2002 13:16, peter lin wrote:
that's the problem with assumptions :)
Actually I believe the W3C spec says the path will default to
directory
the pages resides in. So that page /hello/greeting.jsp will have
/hello as the path. Only files under /hello can read the
cookie.
Atleast that's my understanding of how cookie path is supposed to be
set. Some one correct me if I am wrong.
Well a reliable source tells me that there is no w3c spec for
Cookies,
and infact the concept was conjured by Netscape. There is an RFC
spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without a
path, it might be handy to add it by default so other people don't
spend
an hour or two sitting there thinking Why doesn't this work?. The
current context path would be handy, so the response code could look
like
this:
public void addCookie(Cookie c)
{
// whatever
if (c.getPath() == null)
c.setPath(getContextPath());
// etc
}
Just a thought :)
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should
set it
to /. That's standard practice. Also, if you have multiple
webserver
with names like www1, www2, www3., you should also set the
cookie
to use yourbiz.com.
I know this ;-) But I'd forgotten to put the / there, and assumed
the
browser would assume this if no / was passed to it. However they
don't,
so I was suggesting that if a Cookie has no path set then one
should be
written by default as a totally useless header is currently written
in
the form:
Set-Cookie: someName=someValue; expires
and due to the lack of a path, every browser ignores it.
--
John Baker, BSc CS.
Java Developer, TEAM/Slb. http://www.teamenergy.com
Views expressed in this mail are my own.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
Just add something to the docs.. At least we can see rtfm ;) (with
some nice pointers to the specs)
Mvgr,
Martin
On Mon, 2002-07-01 at 14:55, John Baker wrote:
On Monday 01 July 2002 13:53, John Trollinger wrote:
I have to disagree with the default as well.. as that can be dangerous
to someone who simply forgot to supply the path.. this could cause
security issues with where the cookie can be read.. the way is
currently works if you forgot to provide the path a you will find out
quickly that something is not working in the same manor that you did and
can fix it.
No, you don't find out quickly if you don't know what you're doing and you're
newish to web programming. You only find out if you've got a good knowledge
of web browsers and you realise that although path is optional, the majority
of browsers ignore it in some cases. For example, this problem only occurs if
a Cookie will be deleted (setting maxAge to 0) and it has no path. Even the
best web programmers will take some time to figure out that's wrong.
Therefore although a default is a bad idea, a warning should be provided
clearly in the logs that you've not provided a path, and although the
wishy-washy (noone takes any notice of) spec says that's ok, most browsers
will totally ignore it.
Therefore you've just made many developers very happy with you for providing
such a sensible warning.
John
-Original Message-
From: John Baker [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 01, 2002 8:33 AM
To: Tomcat Developers List
Subject: Re: That Cookie thing
On Monday 01 July 2002 13:29, Tim Funk wrote:
http://wp.netscape.com/newsref/std/cookie_spec.html
OR
http://www.ietf.org/rfc/rfc2109.txt
OR
http://www.ietf.org/rfc/rfc2965.txt
PATH=path
Optional. The Path attribute specifies the subset of URLs to which
this
cookie applies.
But as IE/Moz/Konqueror (anyone else fancy trying some others?) ignore
this,
would it be more useful to provide a default in some way so it isn't
ignored?
The chances of getting all those three to stick to the spec are low ;-)
Or
even a warning in the logs that your code is not likely to work?
Of course, normally I'd say follow the spec, but sadly if your target
audience doesn't, there isn't really much you can do.
John Baker wrote:
On Monday 01 July 2002 13:16, peter lin wrote:
that's the problem with assumptions :)
Actually I believe the W3C spec says the path will default to
directory
the pages resides in. So that page /hello/greeting.jsp will have
/hello as the path. Only files under /hello can read the
cookie.
Atleast that's my understanding of how cookie path is supposed to be
set. Some one correct me if I am wrong.
Well a reliable source tells me that there is no w3c spec for
Cookies,
and infact the concept was conjured by Netscape. There is an RFC
spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without a
path, it might be handy to add it by default so other people don't
spend
an hour or two sitting there thinking Why doesn't this work?. The
current context path would be handy, so the response code could look
like
this:
public void addCookie(Cookie c)
{
// whatever
if (c.getPath() == null)
c.setPath(getContextPath());
// etc
}
Just a thought :)
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should
set it
to /. That's standard practice. Also, if you have multiple
webserver
with names like www1, www2, www3., you should also set the
cookie
to use yourbiz.com.
I know this ;-) But I'd forgotten to put the / there, and assumed
the
browser would assume this if no / was passed to it. However they
don't,
so I was suggesting that if a Cookie has no path set then one
should be
written by default as a totally useless header is currently written
in
the form:
Set-Cookie: someName=someValue; expires
and due to the lack of a path, every browser ignores it.
--
John Baker, BSc CS.
Java Developer, TEAM/Slb. http://www.teamenergy.com
Views expressed in this mail are my own.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
On Monday 01 July 2002 14:03, Martin van den Bemt wrote:
Just add something to the docs.. At least we can see rtfm ;) (with
some nice pointers to the specs)
Quite. Documentation is everything.
But the more I think about it, a newbie logger of some kind could be a great
sell point in terms of making people trust and use Tomcat over other products
(believe it or not, people like http://www.barclays.co.uk and
http://www.elephant.co.uk have picked silly Java servers over Tomcat).
Getting more business using Tomcat would be ace, and stuff like
localhost_moron_log.txt would be a great way to make development even
quicker and businesses happier (ie lower costs).
I'll do some work now ;-)
John
Mvgr,
Martin
On Mon, 2002-07-01 at 14:55, John Baker wrote:
On Monday 01 July 2002 13:53, John Trollinger wrote:
I have to disagree with the default as well.. as that can be dangerous
to someone who simply forgot to supply the path.. this could cause
security issues with where the cookie can be read.. the way is
currently works if you forgot to provide the path a you will find out
quickly that something is not working in the same manor that you did
and can fix it.
No, you don't find out quickly if you don't know what you're doing and
you're newish to web programming. You only find out if you've got a good
knowledge of web browsers and you realise that although path is optional,
the majority of browsers ignore it in some cases. For example, this
problem only occurs if a Cookie will be deleted (setting maxAge to 0) and
it has no path. Even the best web programmers will take some time to
figure out that's wrong.
Therefore although a default is a bad idea, a warning should be provided
clearly in the logs that you've not provided a path, and although the
wishy-washy (noone takes any notice of) spec says that's ok, most
browsers will totally ignore it.
Therefore you've just made many developers very happy with you for
providing such a sensible warning.
John
-Original Message-
From: John Baker [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 01, 2002 8:33 AM
To: Tomcat Developers List
Subject: Re: That Cookie thing
On Monday 01 July 2002 13:29, Tim Funk wrote:
http://wp.netscape.com/newsref/std/cookie_spec.html
OR
http://www.ietf.org/rfc/rfc2109.txt
OR
http://www.ietf.org/rfc/rfc2965.txt
PATH=path
Optional. The Path attribute specifies the subset of URLs to which
this
cookie applies.
But as IE/Moz/Konqueror (anyone else fancy trying some others?) ignore
this,
would it be more useful to provide a default in some way so it isn't
ignored?
The chances of getting all those three to stick to the spec are low ;-)
Or
even a warning in the logs that your code is not likely to work?
Of course, normally I'd say follow the spec, but sadly if your target
audience doesn't, there isn't really much you can do.
John Baker wrote:
On Monday 01 July 2002 13:16, peter lin wrote:
that's the problem with assumptions :)
Actually I believe the W3C spec says the path will default to
directory
the pages resides in. So that page /hello/greeting.jsp will have
/hello as the path. Only files under /hello can read the
cookie.
Atleast that's my understanding of how cookie path is supposed to
be set. Some one correct me if I am wrong.
Well a reliable source tells me that there is no w3c spec for
Cookies,
and infact the concept was conjured by Netscape. There is an RFC
spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without
a path, it might be handy to add it by default so other people
don't
spend
an hour or two sitting there thinking Why doesn't this work?. The
current context path would be handy, so the response code could
look
like
this:
public void addCookie(Cookie c)
{
// whatever
if (c.getPath() == null)
c.setPath(getContextPath());
// etc
}
Just a thought :)
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should
set it
to /. That's standard practice. Also, if you have multiple
webserver
with names like www1, www2, www3., you should also set the
cookie
to use yourbiz.com.
I know this ;-) But I'd forgotten to put the / there, and assumed
the
browser would assume this if no / was passed to it. However they
don't,
so I was suggesting that if a Cookie has no path set then one
should be
written by default as a totally useless header is currently
written
in
the form:
cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_vm.h
mturk 2002/07/01 08:42:52 Modified:jk/native2/include jk_vm.h Log: Added destroy callback function. Revision ChangesPath 1.4 +2 -0 jakarta-tomcat-connectors/jk/native2/include/jk_vm.h Index: jk_vm.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_vm.h,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- jk_vm.h 12 Apr 2002 23:00:45 - 1.3 +++ jk_vm.h 1 Jul 2002 15:42:52 - 1.4 @@ -102,6 +102,8 @@ void *(*attach)(struct jk_env *env, struct jk_vm *p); void (*detach)(struct jk_env *env, struct jk_vm *p); + +void (*destroy)(struct jk_env *env, struct jk_vm *p); }; typedef struct jk_vm jk_vm_t; -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_jni.c
mturk 2002/07/01 08:44:16
Modified:jk/native2/common jk_worker_jni.c
Log:
On worker destroy call the TomcatStarter with the stop arg
to gracefuly shutdown the Tomcat.
Revision ChangesPath
1.21 +36 -23jakarta-tomcat-connectors/jk/native2/common/jk_worker_jni.c
Index: jk_worker_jni.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_jni.c,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- jk_worker_jni.c 29 Jun 2002 18:29:09 - 1.20
+++ jk_worker_jni.c 1 Jul 2002 15:44:16 - 1.21
@@ -152,6 +152,10 @@
} else {
jniWorker-className = value;
}
+/* XXX Instead of ARG=start split to something like:
+ * startup=start
+ * shutdown=stop
+ */
} else if( strcmp( name, ARG )==0 ) {
jniWorker-args[jniWorker-nArgs]=value;
jniWorker-nArgs++;
@@ -308,7 +312,14 @@
jk_worker_t *_this=bean-object;
jni_worker_data_t *jniWorker;
jk_vm_t *vm=_this-workerEnv-vm;
-
+JNIEnv *jniEnv;
+jstring cmd_line = NULL;
+jstring stdout_name = NULL;
+jstring stderr_name = NULL;
+jclass jstringClass;
+jarray jargs;
+jstring arg=NULL;
+
if(!_this || ! _this-worker_private) {
env-l-jkLog(env, env-l, JK_LOG_EMERG,
In destroy, assert failed - invalid parameters\n);
@@ -317,28 +328,30 @@
jniWorker = _this-worker_private;
-/* A MUCH better solution is to use the standard JDK1.3 mechanism.
- Or Ajp13 shutdown.
- I'll implement JDK1.3 after I check if I do need to do anything
- on the C side ( i.e. call System.exit() explicitely - I have a feeling
- the smart VM guys have added a hook to at_exit ).
-*/
-
-/* if(! jniWorker-jk_shutdown_method) { */
-/* env-l-jkLog(env, env-l, JK_LOG_EMERG, */
-/* In destroy, Tomcat not intantiated\n); */
-/* return JK_ERR; */
-/* } */
-
-/* if((jniEnv = vm-attach(env, vm))) { */
-/* env-l-jkLog(env, env-l, JK_LOG_INFO, */
-/* jni.destroy(), shutting down Tomcat...\n); */
-/* (*jniEnv)-CallStaticVoidMethod(jniEnv, */
-/* jniWorker-jk_java_bridge_class, */
-/* jniWorker-jk_shutdown_method); */
-/* vm-detach(env, vm); */
-/* } */
-
+if((jniEnv = vm-attach(env, vm))) {
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+ jni.destroy(), shutting down Tomcat...\n);
+
+jstringClass=(*jniEnv)-FindClass(jniEnv, java/lang/String );
+jargs=(*jniEnv)-NewObjectArray(jniEnv, 1, jstringClass, NULL);
+
+/* XXX Need to make that arg customizable
+*/
+arg=(*jniEnv)-NewStringUTF(jniEnv, stop );
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+ jni.destroy() ARG stop\n);
+(*jniEnv)-SetObjectArrayElement(jniEnv, jargs, 0, arg );
+
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+ jni.destroy() calling main()...\n);
+
+(*jniEnv)-CallStaticVoidMethod(jniEnv,
+jniWorker-jk_java_bridge_class,
+jniWorker-jk_main_method,
+jargs,stdout_name,stderr_name);
+
+vm-destroy(env, vm);
+}
env-l-jkLog(env, env-l, JK_LOG_INFO, jni.destroy() done\n);
return JK_OK;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_vm_default.c
mturk 2002/07/01 08:45:20
Modified:jk/native2/common jk_vm_default.c
Log:
Add the destroy callback that calls the DestroyJavaVM
Revision ChangesPath
1.19 +20 -0 jakarta-tomcat-connectors/jk/native2/common/jk_vm_default.c
Index: jk_vm_default.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_vm_default.c,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- jk_vm_default.c 11 Jun 2002 21:19:31 - 1.18
+++ jk_vm_default.c 1 Jul 2002 15:45:20 - 1.19
@@ -613,6 +613,25 @@
return JK_OK;
}
+static void jk2_vm_destroy(jk_env_t *env, jk_vm_t *jkvm)
+{
+int err;
+JavaVM *jvm = (JavaVM *)jkvm-jvm;
+
+if( jvm == NULL ) {
+return;
+}
+
+err= (*jvm)-DestroyJavaVM(jvm);
+if(err == 0 ) {
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+ vm.destroy() ok\n);
+} else {
+env-l-jkLog(env, env-l, JK_LOG_ERROR,
+ vm.destroy() cannot destroy the JVM.\n);
+}
+}
+
static int JK_METHOD
jk2_jk_vm_setProperty(jk_env_t *env, jk_bean_t *mbean, char *name, void *valueP )
{
@@ -649,6 +668,7 @@
jkvm-init=jk2_vm_initVM;
jkvm-attach=jk2_vm_attach;
jkvm-detach=jk2_vm_detach;
+jkvm-destroy=jk2_vm_destroy;
result-object=jkvm;
result-setAttribute=jk2_jk_vm_setProperty;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
mturk 2002/07/01 08:46:20
Modified:jk/native2/server/apache2 mod_jk2.c
Log:
Register child_init pool cleanup function jk2_shutdown
Revision ChangesPath
1.38 +13 -1 jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c
Index: mod_jk2.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- mod_jk2.c 19 Jun 2002 18:27:25 - 1.37
+++ mod_jk2.c 1 Jul 2002 15:46:20 - 1.38
@@ -370,6 +370,17 @@
return overrides;
}
+static apr_status_t jk2_shutdown(void *data)
+{
+jk_env_t *env;
+if (workerEnv) {
+env=workerEnv-globalEnv;
+workerEnv-close(env, workerEnv);
+workerEnv = NULL;
+}
+return APR_SUCCESS;
+}
+
/** Initialize jk, using worker.properties.
We also use apache commands ( JkWorker, etc), but this use is
@@ -387,6 +398,7 @@
workerEnv-server_name = (char *)ap_get_server_version();
/* Should be done in post config instead (cf DAV2) */
/* ap_add_version_component(pconf, JK_EXPOSED_VERSION); */
+apr_pool_cleanup_register(pconf, NULL, jk2_shutdown, apr_pool_cleanup_null);
return NULL;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10378] New: - loadbalancing with mod_jk fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10378. 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=10378 loadbalancing with mod_jk fails Summary: loadbalancing with mod_jk fails Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Connector:JK/AJP (deprecated) AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello, I use apache 1.3.24 tomcat 3.3.1 with mod_jk/ajp13 for the load_balancing and it works fine for my applications with servlets and static contents When I try to use the same architecture with tomcat 4.0.4, the load-balancing fails rapidly. My config : apache 1.3.24 tomcat 4.0.4 with mod_jk/ajp13 (compiled in tomcat 3.3 arborescence). I have 2 machines : Yo and Go. On the 1st (Yo), in server.xml : Engine jvmRoute=Yo name=Standalone defaultHost=localhost debug=0 On the 2nd (Go), in server.xml : Engine jvmRoute=Go name=Standalone defaultHost=localhost debug=0 So, my session_ids are like it : E65D5A60F291CBF91C36AEAC06CC4E87.Yo or 30D7FE49F1DC64EA680F21CE2A2DC2B3.Go If this solution is deprecated, what is the solution working for loadbalancing in tomcat 4 ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c
mturk 2002/07/01 09:53:55
Modified:jk/native2/server/isapi jk_isapi_plugin.c
Log:
Grecefully shutdown the Tomcat when IIS service stops.
Revision ChangesPath
1.31 +7 -4
jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c
Index: jk_isapi_plugin.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- jk_isapi_plugin.c 29 Jun 2002 14:17:27 - 1.30
+++ jk_isapi_plugin.c 1 Jul 2002 16:53:55 - 1.31
@@ -524,11 +524,14 @@
{
if (is_inited) {
is_inited = JK_FALSE;
-
-/* XXX Here goes a graceful shutdown of jk2, Free resources and pools
-*/
+if (workerEnv) {
+jk_env_t *env = workerEnv-globalEnv;
+workerEnv-close(env, workerEnv);
+}
+apr_pool_destroy(jk_globalPool);
+workerEnv=NULL;
+is_mapread = JK_FALSE;
}
-
return TRUE;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Jk2 shutdown
Hi, There are few things left with the gracefull TC shutdown. 1. The Apache version works ok. 2. The IIS shutdowns the TC but the dll is still left loaded. Think that the TomcatStarter is left hanging, cause stdout/stderr redirection files stays opened. I would like to make the TomcatStarter to be aware of the thing that he is doing (starting or stopping). Could be done through args but I would like to hear other ideas. Second thing is the 'ARG' parameter that IMO should be split in two params, (startup and shutdown) like [worker.jni:jniCmd1] ... startup=start shutdown=stop MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jk2 shutdown
On Mon, 1 Jul 2002, Mladen Turk wrote: I would like to make the TomcatStarter to be aware of the thing that he is doing (starting or stopping). Could be done through args but I would like to hear other ideas. Second thing is the 'ARG' parameter that IMO should be split in two params, (startup and shutdown) like [worker.jni:jniCmd1] ... startup=start shutdown=stop What I tried in jniCmd and jni worker is to make it as simple as possible - just call main(String[]) with all the standard arguments. It is the protocol and the exposed API who should provide any aditional callback - the jni worker should do one thing, load the VM and start a standard program. We already have a mechanism/API for shutdown - and I don't see any good reason to add another one for the JNI call. The fewer 'special' APIs we have for JNI, the better it is for maintainance. What I would do is just use the existing ajp13 shutdown. If there's anything the TomcatStarter must do on shutdown, we can add another hook (== coyote ActionCode ) for shutdown, but use the normal callback mechansim from JNI ( with the ajp13 shutdown message ). If this is too complicated - I'm +0 on a temporary solution, but long term I think we should keep the API consistent and as simple as possible. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Valves, requests and getting the session
On Mon, 1 Jul 2002, John Baker wrote: Date: Mon, 1 Jul 2002 09:20:44 +0100 From: John Baker [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: Valves, requests and getting the session Mmm. It would appear I can only get the session if the value is defined in the Context in server.xml. Ie I cannot define it in the default location in server.xml (where the catalina SingleSIgnOn is commented) and expect it to work. Ack, you're right ... placement is important, and I missed that subtlety in your original problem description. The SingleSignOn valve is embedded in the Host element, so that it sees all the requests for all the webapps installed on that host. As a consequence of this, the valve is invoked before the appropriate Context has been selected (which is done by StandardHostValve, which is always last on the valves used by the Host). Therefore, you won't be able to directly access the session for this request yet, because we don't yet know which webapp will process the request (and therefore what set of sessions are relevant). One workaround is to put your valve inside each Context element (either directly or -- I think this works, but have never tried it -- by embedding them in a DefaultContext that sets the properties for all contexts in that host. Is this correct? And if so, can I achieve what I want to, ie a valve for all contexts? You can see how SingleSignOn had to deal with this to identify the relevant sessions (register itself as a session event listener). I don't know how applicable this is to your specific requirements -- but placement of the SingleSignOn valve under the host is one of the considerations that led me to the use of a second cookie to carry the user identity across the webapps that it applies to. John Craig On Sunday 30 June 2002 21:38, John Baker wrote: On Sunday 30 June 2002 9:35 pm, Craig R. McClanahan wrote: Hmm ... this is baslically how the standard form-based login implementation creates a session, except that it goes on and gets the internal Session object ... That's what I thought. I presume you're trying to create the session *before* calling context.invokeNext(), right? If you don't the response will have already been committed so creating a new session would be ineffective. Yes, I am. I need to check to see if certain objects are in the session and if not, see if they are in another session that is pointed to by the Cookie id. It's like SingleSignOn, but slightly different. However I'm a bit confused to why I can't get a session, even when the rest of the app (the jsp pages etc) are making good use of it., The headers also show the session id, but oddly enough calling HttpServletRequest.SessionIdFromCookie() returns true, but HttpServletRequest.isRequestSessionIdvalid() returns false! John -- John Baker, BSc CS. Java Developer, TEAM/Slb. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
On Mon, 1 Jul 2002, John Baker wrote:
Date: Mon, 1 Jul 2002 13:20:31 +0100
From: John Baker [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: That Cookie thing
On Monday 01 July 2002 13:16, peter lin wrote:
that's the problem with assumptions :)
Actually I believe the W3C spec says the path will default to directory
the pages resides in. So that page /hello/greeting.jsp will have
/hello as the path. Only files under /hello can read the cookie.
Atleast that's my understanding of how cookie path is supposed to be
set. Some one correct me if I am wrong.
Well a reliable source tells me that there is no w3c spec for Cookies, and
infact the concept was conjured by Netscape. There is an RFC spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without a path, it
might be handy to add it by default so other people don't spend an hour or
two sitting there thinking Why doesn't this work?. The current context path
would be handy, so the response code could look like this:
public void addCookie(Cookie c)
{
// whatever
if (c.getPath() == null)
c.setPath(getContextPath());
// etc
}
IMHO, Tomcat should ensure that cookies *it* creates always have a path
(they do), but it's a breach of faith to go messing around with cookies
hand crafted by the application. Those should be assumed to have been set
up exactly the way that the app wanted them. How can the server blindly
assume that the client is a browser that is broken in this respect, and
that all future browser versions will suffer from the same problem?
Just a thought :)
Craig
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should set it
to /. That's standard practice. Also, if you have multiple webserver
with names like www1, www2, www3., you should also set the cookie
to use yourbiz.com.
I know this ;-) But I'd forgotten to put the / there, and assumed the
browser would assume this if no / was passed to it. However they don't,
so I was suggesting that if a Cookie has no path set then one should be
written by default as a totally useless header is currently written in
the form:
Set-Cookie: someName=someValue; expires
and due to the lack of a path, every browser ignores it.
--
John Baker, BSc CS.
Java Developer, TEAM/Slb. http://www.teamenergy.com
Views expressed in this mail are my own.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [4.1.6] New milestone release soon
Costin, This problem still happens with 4.1.6. Dave. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 26 June 2002 16:57 To: Tomcat Developers List Subject: RE: [4.1.6] New milestone release soon On Wed, 26 Jun 2002, David Oxley wrote: Remy, Bug 10018 is pretty serious. Coyote-JK2 won't serve a resource (might apply to dynamic content as well as static) that's bigger than 8k. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10018 Are you using a nightly ? I fixed the bug few days ago, I'm constantly doing large posts with jk2 in my day job. Please let me know ASAP if you still have this problem ! Costin Dave. -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 26 June 2002 12:14 To: Tomcat Developers List Subject: [4.1.6] New milestone release soon There are only a few issues remaining: - Updating JNDI resources with the admin webapp is not dynamic (for reasons currently beyond my understanding). Doing a stop/start on the context allows to pick up the changes, so the bug is only minor. - Nacho's IIS issues with JK 2. - Costin's bug with Jasper 2. None of these are showstoppers IMO, but it would be best to have them fixed before the release is tagged (the objective being to get back to beta status). By friday maybe ? Remy -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2 shutdown
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 1. srpanj 2002 19:40 To: Tomcat Developers List Subject: Re: Jk2 shutdown On Mon, 1 Jul 2002, Mladen Turk wrote: We already have a mechanism/API for shutdown - and I don't see any good reason to add another one for the JNI call. The fewer 'special' APIs we have for JNI, the better it is for maintainance. Yes, but It doesn't work, at least I wasn't been able to invoke it. And it isn't API, it just calls the TomcatStarter with the stop param, and the change of ARG init param, enables that 'stop' to be customizable (if its gonna be changed someday). What I would do is just use the existing ajp13 shutdown. If there's anything the TomcatStarter must do on shutdown, we can add another hook (== coyote ActionCode ) for shutdown, but use the normal callback mechansim from JNI ( with the ajp13 shutdown message ). We still need to destroy the jvm on shutdown, and since we are using the TomcatStarter for starting I'm pretty much in favor for using it for shutdown too, cause that's our application entry point when used inprocess. If something else provoke the shutdown then we'll need another callback or jkSetAttribute, to signal the jni worker to destroy the jvm. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Valves, requests and getting the session
I don't know if you've considered this, but why not just make a Filter (ala Servlet 2.3) instead of a valve? They are more portable to other containers and should have less quirky behavior than you see now with valves. I use a filter to do a very similar operation where I check the session for certain values and load it up with other things to send downstream to the target servlet. russ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2 shutdown
On Mon, 1 Jul 2002, Mladen Turk wrote: On Mon, 1 Jul 2002, Mladen Turk wrote: We already have a mechanism/API for shutdown - and I don't see any good reason to add another one for the JNI call. The fewer 'special' APIs we have for JNI, the better it is for maintainance. Yes, but It doesn't work, at least I wasn't been able to invoke it. And it isn't API, it just calls the TomcatStarter with the stop param, and the change of ARG init param, enables that 'stop' to be customizable (if its gonna be changed someday). I was thinking that 'stop' should be done by sending the ajp13 stop message, instead of calling main(). worker.jni should just execute a program by calling static main(String args[]). What about having a separate worker.jni: that will execute the stop command ? In theory we can have as many worker.jni we want, each executing different programs - in this case we'll just add a flag to the worker.jni indicating when do we want the program executed ( on start, on stop - maybe on other stages too ). This would still keep the worker.jni: as a simple run-java-program-and-nothing-else, and we could open some interesting tricks. What I would do is just use the existing ajp13 shutdown. If there's anything the TomcatStarter must do on shutdown, we can add another hook (== coyote ActionCode ) for shutdown, but use the normal callback mechansim from JNI ( with the ajp13 shutdown message ). We still need to destroy the jvm on shutdown, and since we are using the TomcatStarter for starting I'm pretty much in favor for using it for shutdown too, cause that's our application entry point when used inprocess. Not sure about that - I would like to keep TomcatStarter as simple as possible. I don't agree that the same class that starts a program should also stop it - we don't do it in standalone case ( where the stopper sends a message to either ajp12/13 in 3.3, or the 8005 port in catalina - but that's different code than the starter code ). As allways, if adding a stop solves your problem - I'm +0, but I don't think this is the best solution, and long term I would like very much to have the stop done via the same code regardless of execution mode. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/iis README
nacho 2002/07/01 12:33:59 Modified:jk/native/iis README Log: * More on build i_r.dll from command line. Revision ChangesPath 1.2 +21 -3 jakarta-tomcat-connectors/jk/native/iis/README Index: README === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/iis/README,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- README1 Jul 2002 11:08:35 - 1.1 +++ README1 Jul 2002 19:33:59 - 1.2 @@ -8,8 +8,26 @@ REQUIREMENT --- -MS VC 6.0 (+ update, latest service pack is sp5) -MS PLATFORM SDK +* MS VC 6.0 (+ update, latest service pack is sp5) + isapi_redirector.dll can be built using the command line tools, or + from within the Visual Studio IDE Workbench. The command line build + requires the environment to reflect the PATH, INCLUDE, LIB and other + variables that can be configured with the vcvars32 batch file: + + c:\Program Files\DevStudio\VC\Bin\vcvars32.bat + +* MS PLATFORM SDK + Visual C++ 6.0 builds require an updated Microsoft Windows Platform SDK + (http://www.microsoft.com/msdownload/platformsdk/sdkupdate/) to enable + some isapi_redirector.dll features. For command line builds, + the Platform SDK environment is prepared by the setenv batch file: + + c:\Program Files\Microsoft Platform SDK\setenv.bat + + Note that the Windows Platform SDK is only needed if you want authenticate + using IIS to compile a isapi_redirector.dll.. + + BUILDING @@ -17,7 +35,7 @@ The steps that you need to take are: 1. Change directory to the isapi redirector plugins source directory. - + 2. Execute the following command: MSDEV isapi.dsp /MAKE ALL If msdev is not in your path, enter the full path to msdev.exe -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: SSI Servlet has big problems
(Resending from my older address in hopes that it will help avoid some confusion.) Hmmm... This is what I get for ignoring the list for a while. ;) Note: I completely rewrote the SSI support in 4.x HEAD and had Bip apply the patches (Amy also did some patching) for exactly the same reasons you originally mention. I did this around Oct/Nov 2001. On most of the 4.0 bug reports for SSI (which I agree was a bad implementation on that branch) I commented that my changes should probably have been back-ported from head. I even had test cases for all of the SSI commands, including the conditionals which I added support for. My only guess is that you were looking at an older version when finding the problem. My rewrite solved all of these problems and was completely compatible with all mod_include commands except for the regex stuff. Of course, now it seems that my version has been completely blown away. Which is unfortunate since that means we lose conditionals... and possibly some of the more esoteric nesting behavior that I copied from Apache (I haven't tested this yet.) It's too bad that SSI on head was blown away for changes to an older version. Any chance we can nicely merge the two good versions into one more good version? -Paul Speed Dan Sandberg wrote: Hi everyone. Here are more changes to the SSI code. I have a test case ( comparing SSI behavior to Apache by using .shtml files in different tomcat webapps / apache directories ) which I have not included because I'm not sure where to put manual test cases like this. If there is an apprioriate place for these kinds of things, please let me know. I also have not yet updated package.html in the o.a.c.ssi directory. I will do this when I come back from a weekend trip. Here are the instructions for installing the new code, using the jakarta-tomcat-4.0 dir as the base dir. delete files in ( and dir ) : catalina/src/share/org/apache/catalina/util/ssi delete file: catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java unjar the jar -this puts SSIServlet.java into catalina/src/share/org/apache/catalina/servlets -this puts the rest of the files in catalina/src/share/org/apache/catalina/ssi Since the name of the SSI servlet class changes, and since I added some notes to it, patch web.xml according to the included patch. Since I'm planning on maintaining this for a while, commit access might be a good idea, as it makes things easier for everyone. Thanks have a great weekend! -Dan Index: web.xml === RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/conf/web.xml,v retrieving revision 1.34 diff -r1.34 web.xml 150d149 157a157 !-- This will generally SLOW-DOWN processing. -- 169c169,170 !-- the server root? (0=false, 1=true) [0]-- --- !-- the server root? See note below. -- !-- (0=false, 1=true) [0] -- 171,174c172,177 !-- ignoreUnsupportedDirective -- !-- Should unknown or misspelled Ssi directives-- !-- be ignored and no errors shown?-- !-- (0=false, 1=true) [1] -- --- !-- NOTE : If you set isVirtualWebappRelative to 1 (true), -- !--you probably want to set crossContext=true on the -- !--context that contains the server-side include files -- !--because otherwise the default security will prevent -- !--access to other contexts. The file to change is -- !-- server.xml. -- 181,207c184,204 servlet servlet-namessi/servlet-name servlet-class org.apache.catalina.servlets.SsiInvokerServlet /servlet-class init-param param-namebuffered/param-name param-value1/param-value /init-param init-param param-namedebug/param-name param-value0/param-value /init-param init-param param-nameexpires/param-name param-value666/param-value /init-param init-param param-nameisVirtualWebappRelative/param-name param-value0/param-value /init-param init-param param-nameignoreUnsupportedDirective/param-name param-value1/param-value /init-param load-on-startup4/load-on-startup /servlet --- servlet servlet-namessi/servlet-name servlet-classorg.apache.catalina.servlets.SSIServlet/servlet-class init-param
Re: Valves, requests and getting the session
On Monday 01 July 2002 6:49 pm, Craig R. McClanahan wrote: One workaround is to put your valve inside each Context element (either directly or -- I think this works, but have never tried it -- by embedding them in a DefaultContext that sets the properties for all contexts in that host. That's what I did, with a static Hashtable to bridge the different instances. Not perfect, but it works very nicely now! John -- John Baker, BSc CS. Java Developer, TEAM Slb. (http://www.teamenergy.com/) The views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10383] New: - Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10383. 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=10383 Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely Summary: Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Connector:JK/AJP (deprecated) AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, when using Apache, mod_jk 1.2.0 (the one delivered with Tomcat 4.0.4) and the AJP13 Connector of Tomcat 4.0.4, I encounter the problem, that a specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely. I. Details on my enviroment: OS: Linux Webserver: Apache mod_jk: 1.2.0 (The one delivered with Tomcat 4.0.4) Tomcat: 4.0.4 JDK: 1.4.0_01-b03 Remark: This problem was also discovered with Tomcat 4.0.1 running on Solaris and JDK 1.3.1 II. How to reproduce the problem: 1. Setup a standard Apache, make mod_jk.so available to the modules directory of Apache (/usr/lib/apache in my case) and add the following configuration to your httpd.conf: LoadModule jk_module /usr/lib/apache/mod_jk.so AddModule mod_jk.c IfModule mod_jk.c Namevirtualhost 192.168.2.2:80 JkWorkersFile /etc/httpd/workers.properties JkLogFile /var/log/httpd/mod_jk.log JkLogLevel warn VirtualHost 192.168.2.2:80 ServerName jktest.com DocumentRoot /tmp Transferlog /var/log/httpd/test.log JkMount /* ajp13 #JkMount /*.jsp ajp13 #JkMount /servlet/* ajp13 #JkMount /examples/* ajp13 /VirtualHost /IfModule 2. Use the following /etc/httpd/workers.properties: worker.list=ajp13 worker.ajp13.port=8009 worker.ajp13.host=localhost worker.ajp13.type=ajp13 worker.ajp13.lbfactor=1 3. Ensure that the AJP13 connector is configured the following way in server.xml: Connector className=org.apache.ajp.tomcat4.Ajp13Connector port=8009 minProcessors=5 maxProcessors=75 acceptCount=10 debug=1/ 4. Start Tomcat and Apache. 5. Send the following request to the webserver (e.g. via telnet 192.168.2.2 80): GET / HTTP/1.0 Host: jktest.com Cookie: domain=blah III. What can be observed: 1. The telnet process does not return with any answer, but hangs indefinitely. 2. The anserwering httpd process is still connected to the telnet process Taking a look to the Apache server-status page says that this process is currently writing the response. 3. Doing a strace to the answering httpd process delivers the following: recv(10, (where 10 is the filedescriptor for the AJP13 TCP/IP connection) 4. The situation of the answering httpd process does not change, even when telnet is killed. The Apache server-status still says that this process is currently writing the response. 5. Tomcat throws the following exception to catalina_log.2002-07-01.txt: 2002-07-01 20:36:10 Ajp13Connector[8009] accepted socket, assigning to processor. 2002-07-01 20:36:10 Ajp13Connector[8009] about to create a processor, available=5, created=5, maxProcessors=75 2002-07-01 20:36:10 Ajp13Processor[8009][4] An incoming request is being assigned 2002-07-01 20:36:10 Ajp13Processor[8009][4] The incoming request has been awaited 2002-07-01 20:36:10 Ajp13Processor[8009][4] socket assigned. 2002-07-01 20:36:10 Ajp13Connector[8009] accepting socket... 2002-07-01 20:36:10 Ajp13Processor[8009][4] [Ajp13] setSocket() 2002-07-01 20:36:10 Ajp13Processor[8009][4] waiting on next request... 2002-07-01 20:36:10 Ajp13Processor[8009][4] [Ajp13] receiveNextRequest() 2002-07-01 20:36:10 Ajp13Processor[8009][4] [Ajp13] receive() 2002-07-01 20:36:10 Ajp13Processor[8009][4] [Ajp13] receive: total read = 89 2002-07-01 20:36:10 Ajp13Processor[8009][4] [Ajp13] Received 2 JK_AJP13_FORWARD_REQUEST 2002-07-01 20:36:10 Ajp13Processor[8009][4] [Ajp13] [RequestHandler] decodeRequest() 2002-07-01 20:36:10 Ajp13Processor[8009][4] received next request, status=200 2002-07-01 20:36:11 Ajp13Processor[8009][4] process: invoke java.lang.IllegalArgumentException: Cookie name domain is a reserved token at javax.servlet.http.Cookie.init(Cookie.java:185) at org.apache.ajp.tomcat4.Ajp13Request.addCookies(Ajp13Request.java:189) at org.apache.ajp.tomcat4.Ajp13Request.setAjpRequest(Ajp13Request.java:148) at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:446) at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:551) at
RE: Jk2 shutdown
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 1. srpanj 2002 21:31 To: Tomcat Developers List Subject: RE: Jk2 shutdown What about having a separate worker.jni: that will execute the stop command ? In theory we can have as many worker.jni we want, each executing different programs - in this case we'll just add a flag to the worker.jni indicating when do we want the program executed ( on start, on stop - maybe on other stages too ). This would still keep the worker.jni: as a simple run-java-program-and-nothing-else, and we could open some interesting tricks. Cool idea! I was thinking to use it just for something like that. Not sure about that - I would like to keep TomcatStarter as simple as possible. I don't agree that the same class that starts a program should also stop it - we don't do it in standalone case ( where the stopper sends a message to either ajp12/13 in 3.3, or the 8005 port in catalina - but that's different code than the starter code ). Well, I was thinking to customize and use the TomcatStarter mainClasses[] so we can start not only Bootstrap but other classes too, making extra call param to the main and put those classes to be either fixed or customizable. That way the existing code would be kept as much usable, with the minor adjustments. So, using the TomcatStarter calling some classes main() with the start/stop is a nice and clean interface to as many loaded classes as they are. Instead of customizing the TomcatStarter class in the worker.jni: I'd like to make the actual called class to be customized, but the problem is with those multiple mainClasses[] (perhaps semicolon separated?). As allways, if adding a stop solves your problem - I'm +0, but I don't think this is the best solution, and long term I would like very much to have the stop done via the same code regardless of execution mode. Ok, I agree. It works for now, but I'll look a way to make the clean shutdown using ajp (and TomcatStarter :). MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10385] New: - SSI-Servlet produces invalid character encoding information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10385. 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=10385 SSI-Servlet produces invalid character encoding information Summary: SSI-Servlet produces invalid character encoding information Product: Tomcat 4 Version: 4.0.3 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Servlets:SSI AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] On 2001-11-06 Bug 4674 was submitted ... the 'Content-Encoding' header SSI-Servlet generates has always the value 'UTF-8'. ... It was fixed on 2001-11-12 --- Additional Comments From Amy Roh 2001-11-12 16:36 --- Fixed. Should be available in the next nightly build. However, if you check the source code of this servlet on releases 4.03 and 4.04 the code still shows Line 251: res.setContentType(text/html;charset=UTF-8); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2 shutdown
On Mon, 1 Jul 2002, Mladen Turk wrote: Well, I was thinking to customize and use the TomcatStarter mainClasses[] so we can start not only Bootstrap but other classes too, The mainClasses[] is just a hack - so I can start any of 3.3, 4.0 and 4.1 by just changing TOMCAT_HOME variable. It should work fine by just editing workers.properties and using the 'real' Main.java/Startup.java/whatever has a main()/. So, using the TomcatStarter calling some classes main() with the start/stop is a nice and clean interface to as many loaded classes as they are. I think you should be able to call any java class with main() with any arguments - TomcatStarter is just one case, which detects the version and re-dispatch. Instead of customizing the TomcatStarter class in the worker.jni: I'd like to make the actual called class to be customized, but the problem is with those multiple mainClasses[] (perhaps semicolon separated?). I think it is already customizable - you can set the name of the class to be executed by worker.jni, and any of the arguments. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2 shutdown
It should work fine by just editing workers.properties and using the 'real' Main.java/Startup.java/whatever has a main()/. How we can deal with stdout and stderr redirection?, just now jk2 is passing the file names as params to TomcatStarter, and this will not work if using standard main methods, i will change it to be defined properties at vm level, and using them in TomcatStarter for now.. Is there are a standard way to redirect stderr and stdout in 4.1.X at container level ? Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2 shutdown
On Mon, 1 Jul 2002, Ignacio J. Ortega wrote: It should work fine by just editing workers.properties and using the 'real' Main.java/Startup.java/whatever has a main()/. How we can deal with stdout and stderr redirection?, just now jk2 is passing the file names as params to TomcatStarter, and this will not work if using standard main methods, i will change it to be defined properties at vm level, and using them in TomcatStarter for now.. Can we move the stdout/stderr redirection to some static util method, in AprImpl ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10385] - SSI-Servlet produces invalid character encoding information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10385. 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=10385 SSI-Servlet produces invalid character encoding information [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-07-01 21:19 --- Nightlies != 4.0.x. This bug won't be addressed in the 4.0.x releases, as they do not include the refactored SSI code. Please try the 4.1.6 test release instead to check the progress of the SSI code. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2 shutdown
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: 1 de julio de 2002 23:16 Can we move the stdout/stderr redirection to some static util method, in AprImpl ? Any reason to so? i think this would be and overkill, i think pasing the file names as properties is the cleanest way.., in fact i like much more this way, than the way i did it.. org.apache.jk.stdout, org.apache.jk.stderr are ok, as system properties names ? Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/xdocs configweb.xml index.xml style.css.in style.xsl.in
xdocs xdocs/common (ajp13) xdocs/jk1 (buildingap, buildingiis, buildingiplanet, configap, configiis, configiplanet, faq) xdocs/jk2 (buildingap, buildingiis, buildingiplanet, configap, configiis, configiplanet, faq) +1, but i would like to see JFC opinion prior to change.. I would like to have an independent build.xml at xdocs too.. Saludos , Ignacio J. Ortega msg29927/bin0.bin Description: application/ms-tnef -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: SSI Servlet has big problems
Yes, let's merge them together. How do I get to the code that you fixed? Were the test cases in CVS? I'd say lets get all the test cases setup, and see where my code fails your tests. Then we can use your code wherever functionality is missing. I thought I had checked out the head revision. Did I make a mistake with the cvs check out command? -Dan Paul Speed wrote: (Resending from my older address in hopes that it will help avoid some confusion.) Hmmm... This is what I get for ignoring the list for a while. ;) Note: I completely rewrote the SSI support in 4.x HEAD and had Bip apply the patches (Amy also did some patching) for exactly the same reasons you originally mention. I did this around Oct/Nov 2001. On most of the 4.0 bug reports for SSI (which I agree was a bad implementation on that branch) I commented that my changes should probably have been back-ported from head. I even had test cases for all of the SSI commands, including the conditionals which I added support for. My only guess is that you were looking at an older version when finding the problem. My rewrite solved all of these problems and was completely compatible with all mod_include commands except for the regex stuff. Of course, now it seems that my version has been completely blown away. Which is unfortunate since that means we lose conditionals... and possibly some of the more esoteric nesting behavior that I copied from Apache (I haven't tested this yet.) It's too bad that SSI on head was blown away for changes to an older version. Any chance we can nicely merge the two good versions into one more good version? -Paul Speed Dan Sandberg wrote: Hi everyone. Here are more changes to the SSI code. I have a test case ( comparing SSI behavior to Apache by using .shtml files in different tomcat webapps / apache directories ) which I have not included because I'm not sure where to put manual test cases like this. If there is an apprioriate place for these kinds of things, please let me know. I also have not yet updated package.html in the o.a.c.ssi directory. I will do this when I come back from a weekend trip. Here are the instructions for installing the new code, using the jakarta-tomcat-4.0 dir as the base dir. delete files in ( and dir ) : catalina/src/share/org/apache/catalina/util/ssi delete file: catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java unjar the jar -this puts SSIServlet.java into catalina/src/share/org/apache/catalina/servlets -this puts the rest of the files in catalina/src/share/org/apache/catalina/ssi Since the name of the SSI servlet class changes, and since I added some notes to it, patch web.xml according to the included patch. Since I'm planning on maintaining this for a while, commit access might be a good idea, as it makes things easier for everyone. Thanks have a great weekend! -Dan Index: web.xml === RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/conf/web.xml,v retrieving revision 1.34 diff -r1.34 web.xml 150d149 157a157 !-- This will generally SLOW-DOWN processing. -- 169c169,170 !-- the server root? (0=false, 1=true) [0]-- --- !-- the server root? See note below. -- !-- (0=false, 1=true) [0] -- 171,174c172,177 !-- ignoreUnsupportedDirective -- !-- Should unknown or misspelled Ssi directives-- !-- be ignored and no errors shown?-- !-- (0=false, 1=true) [1] -- --- !-- NOTE : If you set isVirtualWebappRelative to 1 (true), -- !--you probably want to set crossContext=true on the -- !--context that contains the server-side include files -- !--because otherwise the default security will prevent -- !--access to other contexts. The file to change is -- !-- server.xml. -- 181,207c184,204 servlet servlet-namessi/servlet-name servlet-class org.apache.catalina.servlets.SsiInvokerServlet /servlet-class init-param param-namebuffered/param-name param-value1/param-value /init-param init-param param-namedebug/param-name param-value0/param-value /init-param init-param param-nameexpires/param-name param-value666/param-value /init-param init-param param-nameisVirtualWebappRelative/param-name param-value0/param-value /init-param init-param param-nameignoreUnsupportedDirective/param-name
PROPOSAL: 5.0 configuration
The basic idea is to use a 2-layer configuration mechansim, with a pluggable repository for preferene storage and JMX-based component configuration. For config storage, we should be able to use: - current XML files ( with few minor changes in the 3-4 classes that deal with reading config ) - JNDI - for config stored in a directory service ( ldap, active directory, nds, etc). - JDK1.4 preference API, if running in JDK1.4 ( that means registry on windows, well-defined xml files on unix ). - registry - using jk2 native calls - if tomcat is embeded in another application, the application-specific config repository. The config layer will be similar with the JDK1.4 preferences (which we can't use directly - we still have to support older versions ), and will be mostly independent of tomcat ( eventually move to commons - but after we get it stable and to do what we need in tomcat). There are few big benefits in this: - better scalability ( with directory services, in case of large site ). - consistent configuration with the applications embeding tomcat. - consistent configuration with the OS ( i.e. registry can be used on windows, etc ). - simpler API for configuration ( the XmlMapper/Digester are still a bit tricky, and is very difficult to make changes ) - allow us to capture what the user directly changes - the current mechanism for saving will just read all the properties from all beans. - we'll be able to use a single config storage/format for all components ( instead of server.xml, policy, jk2.properites, user.xml,etc) The implementation will actually use the same mechanism as today - except that instead of reading the XML file and using XmlMapper/Digester, we'll get the data from the repository. In addition, any change will be made via the configurator and JMX, and will be recorded and saved ( with a bit of work it is even possible to save the xml files preserving the comments and with the same structure, and only what is modified will be written ). The second layer will be based on the JMX patterns - and will not require any change in the current code. The configurator will just set the attributes and create the components - using either direct introspection or JMX. As more components will be JMX-instrumented, we should be able to use the new configuration to setup those components as well ( log4j for example ) - without any special change in the code. There is nothing very new in this proposal - having pluggable config has been a goal since tomcat3.0, and the proposal itself will change very little as code. A basic implementation of this model is already part of mod_jk2 ( in jk_config.c - the java version will follow, if we agree on this proposal :-). Both layers will be based on existing standards and common patterns. JMX ( and the current java bean patterns ) are clearly the best way to configure components, and JNDI/prefs provide an excelent API for storing config data ( and XML can use that easily ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2 shutdown
On Mon, 1 Jul 2002, Ignacio J. Ortega wrote: De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: 1 de julio de 2002 23:16 Can we move the stdout/stderr redirection to some static util method, in AprImpl ? Any reason to so? i think this would be and overkill, i think pasing the file names as properties is the cleanest way.., in fact i like much more this way, than the way i did it.. worker.jni would call AprImpl and have System.out, System.err redirected. This will allow us to execute any existing java program, without the need to change it to interpret some system properties or do anything special. Well, the current code is not doing that - we do call static void main( String args[], String stdout, String stderr ). I personally think we should call the 'real' main(String args[]), there is little value in creating another startup mechanism. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: SSI Servlet has big problems
Dan Sandberg wrote: Yes, let's merge them together. How do I get to the code that you fixed? Were the test cases in CVS? It's all in CVS. If you checkout the source code from some time in December you should get it all back in util and util/ssi. It looks like my last check-in was on November 29th or so. I too made some pretty significant changes. It looks like my final test.xml never made it in, but I'm attaching it here. (Only the SSI parts are relevant of course.) All of the golden files look like they're still there. I'd say lets get all the test cases setup, and see where my code fails your tests. Then we can use your code wherever functionality is missing. The motivation for my original changes was to fix the nesting of .shtml files (ie: a .shtml file including another .shtml file) and to add support for set, variable substitution, conditionals, etc.. When I looked at the original version and saw it was such a mess, I did pertty much a complete rewrite. Some of my changes are similar to yours, but I got rid of classes like SsiMediator and such. All of this included fixing how variables were kept for includes and such, as well as parsing fixes and the addition of some new commands. It's all pretty significant and may not naturally fit some of your refactoring. To be honest, it might be easier to redo your changes against my stuff than it would be to graft my stuff onto yours. Even though I know that's probably a real pain in the a**. In it's current state, I think the current fixed version has much less functionality than the previous fixed version. Hopefully we can work something out. I thought I had checked out the head revision. Did I make a mistake with the cvs check out command? Must have. The fact that you even have an SsiMediator means you were changing an older version. Unfortunately, Bill didn't notice this when he committed your stuff and probably just whole-sale nuked the older files. Don't feel too bad about that, though. My original rewrite did something similar. Only in my case, it was only a small bug fix that was reverted. Still a little disconcerting from my point of view. Probably my own fault for taking a two-month break from the lists. And I had no idea I could have parlayed those patches into committer access. :) -Paul -Dan Paul Speed wrote: (Resending from my older address in hopes that it will help avoid some confusion.) Hmmm... This is what I get for ignoring the list for a while. ;) Note: I completely rewrote the SSI support in 4.x HEAD and had Bip apply the patches (Amy also did some patching) for exactly the same reasons you originally mention. I did this around Oct/Nov 2001. On most of the 4.0 bug reports for SSI (which I agree was a bad implementation on that branch) I commented that my changes should probably have been back-ported from head. I even had test cases for all of the SSI commands, including the conditionals which I added support for. My only guess is that you were looking at an older version when finding the problem. My rewrite solved all of these problems and was completely compatible with all mod_include commands except for the regex stuff. Of course, now it seems that my version has been completely blown away. Which is unfortunate since that means we lose conditionals... and possibly some of the more esoteric nesting behavior that I copied from Apache (I haven't tested this yet.) It's too bad that SSI on head was blown away for changes to an older version. Any chance we can nicely merge the two good versions into one more good version? -Paul Speed Dan Sandberg wrote: Hi everyone. Here are more changes to the SSI code. I have a test case ( comparing SSI behavior to Apache by using .shtml files in different tomcat webapps / apache directories ) which I have not included because I'm not sure where to put manual test cases like this. If there is an apprioriate place for these kinds of things, please let me know. I also have not yet updated package.html in the o.a.c.ssi directory. I will do this when I come back from a weekend trip. Here are the instructions for installing the new code, using the jakarta-tomcat-4.0 dir as the base dir. delete files in ( and dir ) : catalina/src/share/org/apache/catalina/util/ssi delete file: catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java unjar the jar -this puts SSIServlet.java into catalina/src/share/org/apache/catalina/servlets -this puts the rest of the files in catalina/src/share/org/apache/catalina/ssi Since the name of the SSI servlet class changes, and since I added some notes to it, patch web.xml according to the included patch. Since I'm planning on maintaining this for a while, commit access might be a good idea, as it makes things easier for everyone. Thanks have a great weekend! -Dan Index: web.xml
Re: [PATCH] Re: SSI Servlet has big problems
Ugh this is painful. I'll checkout your stuff within the next few days. If the architecture looks good and does have significantly greater functionality I will merge my changes into your code. I also fixed the included variable problem and the nested include problems. The conditional stuff was the only thing I thought I was missing. I'm curious: How could I have checked out an older version accidently? Wouldn't I have had to explicitly specify a date or tag or something? ... This is all quite depressing ... -Dan Paul Speed wrote: Dan Sandberg wrote: Yes, let's merge them together. How do I get to the code that you fixed? Were the test cases in CVS? It's all in CVS. If you checkout the source code from some time in December you should get it all back in util and util/ssi. It looks like my last check-in was on November 29th or so. I too made some pretty significant changes. It looks like my final test.xml never made it in, but I'm attaching it here. (Only the SSI parts are relevant of course.) All of the golden files look like they're still there. I'd say lets get all the test cases setup, and see where my code fails your tests. Then we can use your code wherever functionality is missing. The motivation for my original changes was to fix the nesting of .shtml files (ie: a .shtml file including another .shtml file) and to add support for set, variable substitution, conditionals, etc.. When I looked at the original version and saw it was such a mess, I did pertty much a complete rewrite. Some of my changes are similar to yours, but I got rid of classes like SsiMediator and such. All of this included fixing how variables were kept for includes and such, as well as parsing fixes and the addition of some new commands. It's all pretty significant and may not naturally fit some of your refactoring. To be honest, it might be easier to redo your changes against my stuff than it would be to graft my stuff onto yours. Even though I know that's probably a real pain in the a**. In it's current state, I think the current fixed version has much less functionality than the previous fixed version. Hopefully we can work something out. I thought I had checked out the head revision. Did I make a mistake with the cvs check out command? Must have. The fact that you even have an SsiMediator means you were changing an older version. Unfortunately, Bill didn't notice this when he committed your stuff and probably just whole-sale nuked the older files. Don't feel too bad about that, though. My original rewrite did something similar. Only in my case, it was only a small bug fix that was reverted. Still a little disconcerting from my point of view. Probably my own fault for taking a two-month break from the lists. And I had no idea I could have parlayed those patches into committer access. :) -Paul -Dan Paul Speed wrote: (Resending from my older address in hopes that it will help avoid some confusion.) Hmmm... This is what I get for ignoring the list for a while. ;) Note: I completely rewrote the SSI support in 4.x HEAD and had Bip apply the patches (Amy also did some patching) for exactly the same reasons you originally mention. I did this around Oct/Nov 2001. On most of the 4.0 bug reports for SSI (which I agree was a bad implementation on that branch) I commented that my changes should probably have been back-ported from head. I even had test cases for all of the SSI commands, including the conditionals which I added support for. My only guess is that you were looking at an older version when finding the problem. My rewrite solved all of these problems and was completely compatible with all mod_include commands except for the regex stuff. Of course, now it seems that my version has been completely blown away. Which is unfortunate since that means we lose conditionals... and possibly some of the more esoteric nesting behavior that I copied from Apache (I haven't tested this yet.) It's too bad that SSI on head was blown away for changes to an older version. Any chance we can nicely merge the two good versions into one more good version? -Paul Speed Dan Sandberg wrote: Hi everyone. Here are more changes to the SSI code. I have a test case ( comparing SSI behavior to Apache by using .shtml files in different tomcat webapps / apache directories ) which I have not included because I'm not sure where to put manual test cases like this. If there is an apprioriate place for these kinds of things, please let me know. I also have not yet updated package.html in the o.a.c.ssi directory. I will do this when I come back from a weekend trip. Here are the instructions for installing the new code, using the jakarta-tomcat-4.0 dir as the base dir. delete files in ( and dir ) : catalina/src/share/org/apache/catalina/util/ssi delete file: catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java
RE: [PROPOSAL] removing outdated makefile/buildfile for mod_jk 1.2.0
If you're referring to statically linking mod_jk into Apache 1.3.x, then I can confirm that it works just fine. I've been running that configuration for quite some time now. Bojan On Mon, 2002-07-01 at 18:53, GOMEZ Henri wrote: Ok, I'll remove them so, and will update the build documentation (in xdocs). BTW, who could tell us more about mod_jk 1.2.x static build ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Saturday, June 29, 2002 5:19 AM To: Tomcat Dev List Subject: Re: [PROPOSAL] removing outdated makefile/buildfile for mod_jk 1.2.0 As long as configure/make works I'm +1. Bojan On Fri, 2002-06-28 at 22:39, GOMEZ Henri wrote: Hi, What about removing all the outdated makefile and build.platform.sh present in jk/native now that we have a working configure/makefile or ant/jkant ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [4.1.6] New milestone release soon
On Mon, 1 Jul 2002, David Oxley wrote: Costin, This problem still happens with 4.1.6. Ok, I need more details then. Are you sure the mod_jk is recent ? Are you using mod_jk or mod_jk2 ( on apache side )? Any stack traces or message ? As I said, I'm doing large uploads/downloads currently, and it works fine. Costin Dave. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 26 June 2002 16:57 To: Tomcat Developers List Subject: RE: [4.1.6] New milestone release soon On Wed, 26 Jun 2002, David Oxley wrote: Remy, Bug 10018 is pretty serious. Coyote-JK2 won't serve a resource (might apply to dynamic content as well as static) that's bigger than 8k. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10018 Are you using a nightly ? I fixed the bug few days ago, I'm constantly doing large posts with jk2 in my day job. Please let me know ASAP if you still have this problem ! Costin Dave. -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 26 June 2002 12:14 To: Tomcat Developers List Subject: [4.1.6] New milestone release soon There are only a few issues remaining: - Updating JNDI resources with the admin webapp is not dynamic (for reasons currently beyond my understanding). Doing a stop/start on the context allows to pick up the changes, so the bug is only minor. - Nacho's IIS issues with JK 2. - Costin's bug with Jasper 2. None of these are showstoppers IMO, but it would be best to have them fixed before the release is tagged (the objective being to get back to beta status). By friday maybe ? Remy -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_jni.c
nacho 2002/07/01 16:11:42
Modified:jk/native2/common jk_worker_jni.c
Log:
* set the stdout and stderr files using statics methods from AprImpl
Revision ChangesPath
1.22 +46 -12jakarta-tomcat-connectors/jk/native2/common/jk_worker_jni.c
Index: jk_worker_jni.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_jni.c,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- jk_worker_jni.c 1 Jul 2002 15:44:16 - 1.21
+++ jk_worker_jni.c 1 Jul 2002 23:11:42 - 1.22
@@ -81,7 +81,10 @@
struct jni_worker_data {
jclass jk_java_bridge_class;
+jclass jk_java_bridge_apri_class;
jmethodID jk_main_method;
+jmethodID jk_setout_method;
+jmethodID jk_seterr_method;
char *className;
char *stdout_name;
char *stderr_name;
@@ -102,14 +105,32 @@
p-jk_main_method =
(*jniEnv)-GetStaticMethodID(jniEnv, p-jk_java_bridge_class,
main,
-
([Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)V);
+ ([Ljava/lang/String;)V);
+if(!p-jk_main_method) {
+ env-l-jkLog(env, env-l, JK_LOG_EMERG, Can't find main(String [])\n);
+ return JK_ERR;
+}
-
+p-jk_setout_method =
+(*jniEnv)-GetStaticMethodID(jniEnv, p-jk_java_bridge_apri_class,
+ setOut,
+ (Ljava/lang/String;)V);
if(!p-jk_main_method) {
- env-l-jkLog(env, env-l, JK_LOG_EMERG, Can't find main()\n);
- return JK_ERR;
+ env-l-jkLog(env, env-l, JK_LOG_EMERG, Can't find
AprImpl.setOut(String));
+ return JK_ERR;
}
+p-jk_seterr_method =
+(*jniEnv)-GetStaticMethodID(jniEnv, p-jk_java_bridge_apri_class,
+ setErr,
+ (Ljava/lang/String;)V);
+if(!p-jk_main_method) {
+ env-l-jkLog(env, env-l, JK_LOG_EMERG, Can't find
AprImpl.setErr(String)\n);
+ return JK_ERR;
+}
+
+
+
return JK_OK;
}
@@ -178,7 +199,6 @@
char *str_config = NULL;
jk_map_t *props=_this-workerEnv-initData;
jk_vm_t *vm=_this-workerEnv-vm;
-jclass aprImplClass;
jclass jstringClass;
jarray jargs;
int i=0;
@@ -251,19 +271,18 @@
XXX Need the way to customize JAVA_BRIDGE_CLASS_APRI, but since
it's hardcoded in JniHandler.java doesn't matter for now.
*/
-aprImplClass =
+jniWorker-jk_java_bridge_apri_class =
(*jniEnv)-FindClass(jniEnv, JAVA_BRIDGE_CLASS_APRI );
-if( aprImplClass == NULL ) {
+if( jniWorker-jk_java_bridge_apri_class == NULL ) {
env-l-jkLog(env, env-l, JK_LOG_ERROR,
Can't find class %s\n, JAVA_BRIDGE_CLASS_APRI );
/* [V] the detach here may segfault on 1.1 JVM... */
vm-detach(env, vm);
return JK_ERR;
}
-rc = jk_jni_aprImpl_registerNatives( jniEnv, aprImplClass);
-
- if( rc != 0) {
+rc = jk_jni_aprImpl_registerNatives( jniEnv,
jniWorker-jk_java_bridge_apri_class);
+if( rc != 0) {
env-l-jkLog(env, env-l, JK_LOG_ERROR,
Can't register native functions for %s \n,
JAVA_BRIDGE_CLASS_APRI );
vm-detach(env, vm);
@@ -293,13 +312,28 @@
(*jniEnv)-SetObjectArrayElement(jniEnv, jargs, i, arg );
}
+/* Set out and err stadard files */
+
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+ jni.init() setting stdout=%s...\n,jniWorker-stdout_name);
+(*jniEnv)-CallStaticVoidMethod(jniEnv,
+jniWorker-jk_java_bridge_apri_class,
+jniWorker-jk_setout_method,
+stdout_name);
+
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+ jni.init() setting stderr=%s...\n,jniWorker-stderr_name);
+(*jniEnv)-CallStaticVoidMethod(jniEnv,
+jniWorker-jk_java_bridge_apri_class,
+jniWorker-jk_seterr_method,
+stderr_name);
+
env-l-jkLog(env, env-l, JK_LOG_INFO,
jni.init() calling main()...\n);
-
(*jniEnv)-CallStaticVoidMethod(jniEnv,
jniWorker-jk_java_bridge_class,
jniWorker-jk_main_method,
-jargs,stdout_name,stderr_name);
+jargs);
vm-detach(env, vm);
--
To
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/apr TomcatStarter.java AprImpl.java
nacho 2002/07/01 16:12:33
Modified:jk/java/org/apache/jk/apr TomcatStarter.java AprImpl.java
Log:
* set the stdout and stderr files using statics methods from AprImpl
Revision ChangesPath
1.11 +2 -12
jakarta-tomcat-connectors/jk/java/org/apache/jk/apr/TomcatStarter.java
Index: TomcatStarter.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/apr/TomcatStarter.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- TomcatStarter.java30 Jun 2002 09:59:11 - 1.10
+++ TomcatStarter.java1 Jul 2002 23:12:33 - 1.11
@@ -24,21 +24,11 @@
// If someone has time - we can also guess the classpath and do other
// fancy guessings.
-public static void main( String args[], String stdout, String stderr ) {
+public static void main( String args[] ) {
System.err.println(TomcatStarter: main());
try {
-try{
-if( stdout!=null ){
-System.setOut( new PrintStream(new FileOutputStream(stdout)));
-}
-if( stderr!=null ){
-System.setErr( new PrintStream(new FileOutputStream(stderr)));
-}
-}catch (Throwable th){
-}
-AprImpl.jniMode();
-
+AprImpl.jniMode();
// Find the class
Class c=null;
for( int i=0; imainClasses.length; i++ ) {
1.24 +21 -0 jakarta-tomcat-connectors/jk/java/org/apache/jk/apr/AprImpl.java
Index: AprImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/apr/AprImpl.java,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- AprImpl.java 30 Jun 2002 09:59:02 - 1.23
+++ AprImpl.java 1 Jul 2002 23:12:33 - 1.24
@@ -68,6 +68,27 @@
this.nativeSo=nativeSo;
}
+/** Sets the System.out stream */
+
+public static void setOut( String filename ) {
+try{
+if( filename !=null ){
+System.setOut( new PrintStream(new FileOutputStream(filename )));
+}
+}catch (Throwable th){
+}
+}
+/** Sets the System.err stream */
+
+public static void setErr( String filename ) {
+try{
+if( filename !=null ){
+System.setErr( new PrintStream(new FileOutputStream(filename )));
+}
+}catch (Throwable th){
+}
+}
+
// Apr generic utils
/** Initialize APR
*/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2 shutdown
worker.jni would call AprImpl and have System.out, System.err redirected. Done, seems much better, thanks. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: SSI Servlet has big problems
I'm trying to checkout an old version of tomcat with the following command: [dan@oogie tmp]$ cvs co -D 4 months ago jakarta-tomcat-4.0 And I'm getting the following error: Core dumped; preserving /tmp/cvs-serv41751 on server. CVS locks may need cleaning up. My version is (on Linux): [dan@oogie tmp]$ cvs --version Concurrent Versions System (CVS) 1.11.1p1 (client/server) I tried the same thing on Solaris, and had the same problem. Any idea? Am I doing something stupid? -Dan Dan Sandberg wrote: Yes, let's merge them together. How do I get to the code that you fixed? Were the test cases in CVS? I'd say lets get all the test cases setup, and see where my code fails your tests. Then we can use your code wherever functionality is missing. I thought I had checked out the head revision. Did I make a mistake with the cvs check out command? -Dan Paul Speed wrote: (Resending from my older address in hopes that it will help avoid some confusion.) Hmmm... This is what I get for ignoring the list for a while. ;) Note: I completely rewrote the SSI support in 4.x HEAD and had Bip apply the patches (Amy also did some patching) for exactly the same reasons you originally mention. I did this around Oct/Nov 2001. On most of the 4.0 bug reports for SSI (which I agree was a bad implementation on that branch) I commented that my changes should probably have been back-ported from head. I even had test cases for all of the SSI commands, including the conditionals which I added support for. My only guess is that you were looking at an older version when finding the problem. My rewrite solved all of these problems and was completely compatible with all mod_include commands except for the regex stuff. Of course, now it seems that my version has been completely blown away. Which is unfortunate since that means we lose conditionals... and possibly some of the more esoteric nesting behavior that I copied from Apache (I haven't tested this yet.) It's too bad that SSI on head was blown away for changes to an older version. Any chance we can nicely merge the two good versions into one more good version? -Paul Speed -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs configweb.xml
nacho 2002/07/01 16:42:24
Modified:jk/xdocs configweb.xml
Log:
* Borrow :) some text from original costin's texts in html..
Revision ChangesPath
1.4 +79 -219 jakarta-tomcat-connectors/jk/xdocs/configweb.xml
Index: configweb.xml
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/configweb.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- configweb.xml 30 Jun 2002 03:32:01 - 1.3
+++ configweb.xml 1 Jul 2002 23:42:24 - 1.4
@@ -6,9 +6,12 @@
author email=[EMAIL PROTECTED]Jean-Frederic
Clere/author
/properties
section name=Intro
+pJk2 uses a config file ( workers2.properties ) in the style of a
.properties or ini
+ file. It can be configured to use any other backend that provides similar
+ capabilities.
+ /p
p
- This document describes the configuration file used by mod_jk2 on the
- Web Server site. Its default name is ${serverRoot}/conf/workers2.properties,
+ This document describes the format of this configuration file. Its default name
is ${serverRoot}/conf/workers2.properties,
where ${serverRoot} is something like /opt/apache.
/p
/section
@@ -17,30 +20,60 @@
subsection name=Apache 2/
subsection name=IIS/
/section
-section name=Config file/
-section name=Components
-pCommon properties for all components/p
-p
-table
-tr
-thProperty name/th
-thDefault/th
-thDescription/th
-/tr
-tr
-tddisabled/td
-td0 (false)/td
-tddisabled state for the component, 1=true 0=false/td
-/tr
-tr
-tddebug/td
-td0 (false)/td
-tddebug state for the component, 1=true 0=false/td
-/tr
-/table
+section name=Config file
+p The default config file is user editable, but mod_jk will persist the
+changes requested by protocol( not implemented). If you manually change the file
while jk2 is
+working, your changes will be lost.
+ /p
+pThe default configuration format . . Each setting consists of an object
+name and a property, with the associated value. The property name is a simple
+ string, with no '.' in it. The name can be anything, but it must have a
+known 'type' as prefix.
+ /p
+p2 formats are supported:
+source
+TYPE:NAME.PROPERTY=VALUE
+/source
+/p
+pand
+source
+[TYPE:NAME]
+PROPERTY=VALUE
+/source
/p
+/section
+section name=ComponentspEach component instance has a name, that is used
for configuration and at runtime. Each component has a number of configurable
properties. The following rules are used:
+ulliThe name is composed from the type and a local part, separated with a ':' (
example: channel.unixsocket:/tmp/jk.socket ) /li
+liThe 'type' consist of '.' and ascii characters. It is mapped to a JMX
'domain'. /li
+liThe local part consists of ascii characters and .:/;
+pNote that '=,' are not currently allowed - a future version may support the jmx
syntax by using quotes to separate the local part from the property and value ( in
.properties mode we must use '=' to separate the value from type, local name and
property name ). /p/li
+liThe property is a simple name, with no dots. /li
+liA simple form of substitution is used in values, where $(property) will be
replaced with a previously defined setting. If the property has ':' in it, it'll take
the value from the object, if not it'll take the value from a global map./li/ul/p
+subsection name=Common properties
+pCommon properties for all components/p
+p
+table
+tr
+thProperty name/th
+thDefault/th
+thDescription/th
+/tr
+tr
+tddisabled/td
+td0 (false)/td
+tddisabled state for the component, 1=true 0=false/td
+/tr
+tr
+tddebug/td
+td0 (false)/td
+tddebug state for the component, 1=true 0=false/td
+/tr
+/table
+/p
+/subsection
subsection name=workerEnv
-pThis component represent the core jk2, this has the default logger
cvs commit: jakarta-tomcat-connectors/jk/conf workers2.properties
nacho 2002/07/01 16:53:08
Modified:jk/conf workers2.properties
Log:
* add some more examples of config..
Revision ChangesPath
1.14 +14 -1 jakarta-tomcat-connectors/jk/conf/workers2.properties
Index: workers2.properties
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/conf/workers2.properties,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- workers2.properties 19 May 2002 20:56:13 - 1.13
+++ workers2.properties 1 Jul 2002 23:53:07 - 1.14
@@ -10,6 +10,11 @@
info=Maps the requests. Options: debug
debug=0
+# Alternate file logger
+#[logger.file:0]
+#level=DEBUG
+#file=${serverRoot}/logs/jk2.log
+
[shm:]
info=Scoreboard. Required for reconfiguration and status with multiprocess servers
file=${serverRoot}/logs/jk2.shm
@@ -21,6 +26,10 @@
info=Global server options
timing=1
debug=0
+# Default Native Logger (apache2 or win32 )
+# can be overriden to a file logger, useful
+# when tracing win32 related issues
+#logger=logger.file:0
[lb:lb]
info=Default load balancer.
@@ -58,10 +67,12 @@
[vm:]
info=Parameters used to load a JVM in the server process
-OPT=-Djava.class.path=${TOMCAT_HOME}/bin/tomcat-jni.jar
+#JVM=C:\jdk\jre\bin\hotspot\jvm.dll
+OPT=-Djava.class.path=${TOMCAT_HOME}/lib/tomcat-jni.jar;${TOMCAT_HOME}/lib/tomcat.jar
OPT=-Dtomcat.home=${TOMCAT_HOME}
OPT=-Dcatalina.home=${TOMCAT_HOME}
OPT=-Xmx128M
+#OPT=-Djava.compiler=NONE
disabled=1
[worker.jni:jniCmd1]
@@ -69,6 +80,8 @@
class=org/apache/jk/apr/TomcatStarter
ARG=start
disabled=1
+stdout=${serverRoot}/logs/stdout.log
+stderr=${serverRoot}/logs/stderr.log
[uri:/jkstatus/*]
info=Display status information and checks the config file for changes.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: SSI Servlet has big problems
(resending from my progeeks.com address to avoid being filtered/delayed by moderation.) Don't know... have you tried an absolute date or is 4 months ago just an example for the list's benefit. Any date in feb/april should be sufficiently late enough. Hope it works, -Paul Dan Sandberg wrote: I'm trying to checkout an old version of tomcat with the following command: [dan@oogie tmp]$ cvs co -D 4 months ago jakarta-tomcat-4.0 And I'm getting the following error: Core dumped; preserving /tmp/cvs-serv41751 on server. CVS locks may need cleaning up. My version is (on Linux): [dan@oogie tmp]$ cvs --version Concurrent Versions System (CVS) 1.11.1p1 (client/server) I tried the same thing on Solaris, and had the same problem. Any idea? Am I doing something stupid? -Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: SSI Servlet has big problems
(resending from my progeeks.com address to avoid being filtered/delayed by moderation.) Dan Sandberg wrote: Ugh this is painful. I'll checkout your stuff within the next few days. If the architecture looks good and does have significantly greater functionality I will merge my changes into your code. I also fixed the included variable problem and the nested include problems. The conditional stuff was the only thing I thought I was missing. Hmmm... maybe it isn't as bad as I thought? I don't know. I know there were some parsing problems that kept variable substituation from working correctly. I'm curious: How could I have checked out an older version accidently? Wouldn't I have had to explicitly specify a date or tag or something? Well, if you started working from a tarball of the source, that might have done it. I think that's what happened in my case originally. I can't remember exactly, but the tarball I had might have even had CVS directories in it with sticky tags already set... ie: keeping me from easily getting the latest without checking out the whole source tree from scratch. ... This is all quite depressing ... Indeed. Thanks for being so gracious about all of this. I really felt quite sick when I saw what I missed. That'll teach me to ignore my inbox. :) -Paul -Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: SSI Servlet has big problems
I tried an absolute date first. April didn't work. Does this work on your end? have even had CVS directories in it with sticky tags already set... ie: keeping me from easily getting the latest without checking out the whole source tree from scratch. Hmm. That is a possibility. Definitely not a mistake I'll make twice ( assuming I made it at all! ) Indeed. Thanks for being so gracious about all of this. I really felt quite sick when I saw what I missed. That'll teach me to ignore my inbox. :) Pitty that no one mentioned that you had last updated things when I asked about the SSI stuff initially. I would have e-mailed you. -Dan Paul Speed wrote: (resending from my progeeks.com address to avoid being filtered/delayed by moderation.) Don't know... have you tried an absolute date or is 4 months ago just an example for the list's benefit. Any date in feb/april should be sufficiently late enough. Hope it works, -Paul Dan Sandberg wrote: I'm trying to checkout an old version of tomcat with the following command: [dan@oogie tmp]$ cvs co -D 4 months ago jakarta-tomcat-4.0 And I'm getting the following error: Core dumped; preserving /tmp/cvs-serv41751 on server. CVS locks may need cleaning up. My version is (on Linux): [dan@oogie tmp]$ cvs --version Concurrent Versions System (CVS) 1.11.1p1 (client/server) I tried the same thing on Solaris, and had the same problem. Any idea? Am I doing something stupid? -Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: SSI Servlet has big problems
-r tomcat_4_1_2 should work. You could also add the files back from the Attic, since it's a completely different directory. - Original Message - From: Dan Sandberg [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, July 01, 2002 4:25 PM Subject: Re: [PATCH] Re: SSI Servlet has big problems I'm trying to checkout an old version of tomcat with the following command: [dan@oogie tmp]$ cvs co -D 4 months ago jakarta-tomcat-4.0 And I'm getting the following error: Core dumped; preserving /tmp/cvs-serv41751 on server. CVS locks may need cleaning up. My version is (on Linux): [dan@oogie tmp]$ cvs --version Concurrent Versions System (CVS) 1.11.1p1 (client/server) I tried the same thing on Solaris, and had the same problem. Any idea? Am I doing something stupid? -Dan Dan Sandberg wrote: Yes, let's merge them together. How do I get to the code that you fixed? Were the test cases in CVS? I'd say lets get all the test cases setup, and see where my code fails your tests. Then we can use your code wherever functionality is missing. I thought I had checked out the head revision. Did I make a mistake with the cvs check out command? -Dan Paul Speed wrote: (Resending from my older address in hopes that it will help avoid some confusion.) Hmmm... This is what I get for ignoring the list for a while. ;) Note: I completely rewrote the SSI support in 4.x HEAD and had Bip apply the patches (Amy also did some patching) for exactly the same reasons you originally mention. I did this around Oct/Nov 2001. On most of the 4.0 bug reports for SSI (which I agree was a bad implementation on that branch) I commented that my changes should probably have been back-ported from head. I even had test cases for all of the SSI commands, including the conditionals which I added support for. My only guess is that you were looking at an older version when finding the problem. My rewrite solved all of these problems and was completely compatible with all mod_include commands except for the regex stuff. Of course, now it seems that my version has been completely blown away. Which is unfortunate since that means we lose conditionals... and possibly some of the more esoteric nesting behavior that I copied from Apache (I haven't tested this yet.) It's too bad that SSI on head was blown away for changes to an older version. Any chance we can nicely merge the two good versions into one more good version? -Paul Speed -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: SSI Servlet has big problems
Hi Bill. Didn't have any luck with that either (see below). Does it work for you? Any idea what the message about the CVS locks means / how to fix it? Yeah, I see what you mean re: files in the attic. I'm curious how things looked before I started changing things, to better understand what caused this code collision... -Dan Here's what I got when I tried to do the -r thing: [dan@oogie tmp]$ echo $CVSROOT :ext:[EMAIL PROTECTED]:/home/cvs [dan@oogie tmp]$ cvs co -r tomcat_4_1_2 jakarta-tomcat-4.0 Protocol error: uncounted data discarded Bill Barker wrote: -r tomcat_4_1_2 should work. You could also add the files back from the Attic, since it's a completely different directory. - Original Message - From: Dan Sandberg [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, July 01, 2002 4:25 PM Subject: Re: [PATCH] Re: SSI Servlet has big problems I'm trying to checkout an old version of tomcat with the following command: [dan@oogie tmp]$ cvs co -D 4 months ago jakarta-tomcat-4.0 And I'm getting the following error: Core dumped; preserving /tmp/cvs-serv41751 on server. CVS locks may need cleaning up. My version is (on Linux): [dan@oogie tmp]$ cvs --version Concurrent Versions System (CVS) 1.11.1p1 (client/server) I tried the same thing on Solaris, and had the same problem. Any idea? Am I doing something stupid? -Dan Dan Sandberg wrote: Yes, let's merge them together. How do I get to the code that you fixed? Were the test cases in CVS? I'd say lets get all the test cases setup, and see where my code fails your tests. Then we can use your code wherever functionality is missing. I thought I had checked out the head revision. Did I make a mistake with the cvs check out command? -Dan Paul Speed wrote: (Resending from my older address in hopes that it will help avoid some confusion.) Hmmm... This is what I get for ignoring the list for a while. ;) Note: I completely rewrote the SSI support in 4.x HEAD and had Bip apply the patches (Amy also did some patching) for exactly the same reasons you originally mention. I did this around Oct/Nov 2001. On most of the 4.0 bug reports for SSI (which I agree was a bad implementation on that branch) I commented that my changes should probably have been back-ported from head. I even had test cases for all of the SSI commands, including the conditionals which I added support for. My only guess is that you were looking at an older version when finding the problem. My rewrite solved all of these problems and was completely compatible with all mod_include commands except for the regex stuff. Of course, now it seems that my version has been completely blown away. Which is unfortunate since that means we lose conditionals... and possibly some of the more esoteric nesting behavior that I copied from Apache (I haven't tested this yet.) It's too bad that SSI on head was blown away for changes to an older version. Any chance we can nicely merge the two good versions into one more good version? -Paul Speed -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
servlet authentication
To test servlet-based authentication, I have a two
line servlet.
response.sendError(response.SC_UNAUTHORIZED);
response.setHeader(WWW-Authenticate, BASIC
realm=\test\);
Here is the output I get:
$ telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /myapp/servlet
htmlheadtitleApache Tomcat/4.0.3 - Error
report/titleSTYLE!--H1{font-family :
sans-serif,Arial,Tahoma;color : white;background-color
: #0086b2;} BODY{font-family :
sans-serif,Arial,Tahoma;color : black;background-color
: white;} B{color : white;background-color : #0086b2;}
HR{color : #0086b2;} --/STYLE
/headbodyh1Apache Tomcat/4.0.3 - HTTP Status 401
- Unauthorized/h1HR size=1 noshadepbtype/b
Status report/ppbmessage/b
uUnauthorized/u/ppbdescription/b uThis
request requires HTTP authentication
(Unauthorized)./u/pHR size=1
noshade/body/htmlConnection closed by foreign
host.
The output contains no HTTP headers, just some Tomcat
generated HTML. Is this a bug in my servlet test or
what?
Thanks,
Mike
__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10389] New: - jsp:plugin doesn't accept parameters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10389. 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=10389 jsp:plugin doesn't accept parameters Summary: jsp:plugin doesn't accept parameters Product: Tomcat 4 Version: 4.1.3 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, It seems the jsp:plugin tag doesn't accept nested parameters. Eg, take the file examples/jsp/plugin/plugin.jsp: jsp:plugin type=applet code=Clock2.class codebase=/examples/jsp/plugin/applet jreversion=1.2 width=16 0 height=150 jsp:fallback Plugin tag OBJECT or EMBED not supported by browser. /jsp:fallback /jsp:plugin Then add this under the jsp:plugin element: jsp:params jsp:param name=foo value=bar/ /jsp:params After this addition, I get this error: rg.apache.jasper.JasperException: /jsp/plugin/plugin.jsp(9,12) Expected param tag with name and value attributes without the params tag. at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:94) at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:417) at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:126) at org.apache.jasper.compiler.Parser.parseParam(Parser.java:443) at org.apache.jasper.compiler.Parser.parseParams(Parser.java:468) at org.apache.jasper.compiler.Parser.parseJspParams(Parser.java:589) at org.apache.jasper.compiler.Parser.parsePlugin(Parser.java:627) at org.apache.jasper.compiler.Parser.parseAction(Parser.java(Compiled Code)) at org.apache.jasper.compiler.Parser.parseElements(Parser.java(Compiled Code)) at org.apache.jasper.compiler.Parser.parse(Parser.java(Compiled Code)) at org.apache.jasper.compiler.ParserController.parse(ParserController.java:199) at org.apache.jasper.compiler.ParserController.parse(ParserController.java:153) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:179) at org.apache.jasper.JspEngineContext.compile(JspEngineContext.java:356) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:157) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:289) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240) at javax.servlet.http.HttpServlet.service(HttpServlet.java(Compiled Code)) --Jeff -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
