DO NOT REPLY [Bug 20300] New: - HttpServletRequest getRemoteUser() does not return user authenticated by Apache
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=20300. 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=20300 HttpServletRequest getRemoteUser() does not return user authenticated by Apache Summary: HttpServletRequest getRemoteUser() does not return user authenticated by Apache Product: Tomcat 4 Version: 4.1.18 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Using Apache 2.0.45 with mod_sspi (NTLM) and Tmocat 4.1.18 The user is being proprly authenticated by the Apache. However, the HttpServletRequest.getRemoteUser() return null. I tried setting request.tomcatAuthentication to true in jk.properties but that didn't work as well - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20305] New: - ANT build - managing application
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=20305.
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=20305
ANT build - managing application
Summary: ANT build - managing application
Product: Tomcat 4
Version: 4.0 Beta 1
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Webapps:Administration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Error with building web application: What is fals in the build.xml ?
/home/t441313/jakarta-ant-1.5ant
Buildfile: build.xml
BUILD FAILED
Target `build' does not exist in this project. It is used from target `deploy'.
the build.xml file
?xml version='1.0' encoding='utf-8'?
project name=HelloApp default=compile basedir=.
property name=src value=./
property name=build value=${basedir}/build/
property name=path value=/hello/
property name=url value=http://defx0ybf.bank.dresdner.net:8480/manager/
property name=username value=t441313/
property name=password value=tasse/
taskdef name=deploy
classname=org.apache.catalina.ant.DeployTask/
taskdef name=install
classname=org.apache.catalina.ant.InstallTask/
taskdef name=list
classname=org.apache.catalina.ant.ListTask/
taskdef name=reload
classname=org.apache.catalina.ant.ReloadTask/
taskdef name=remove
classname=org.apache.catalina.ant.RemoveTask/
taskdef name=resources
classname=org.apache.catalina.ant.ResourcesTask/
taskdef name=roles
classname=org.apache.catalina.ant.RolesTask/
taskdef name=start
classname=org.apache.catalina.ant.StartTask/
taskdef name=stop
classname=org.apache.catalina.ant.StopTask/
taskdef name=undeploy
classname=org.apache.catalina.ant.UndeployTask/
!-- create build-directory --
target name=init
mkdir dir=${build}/
mkdir dir=${build}/hello/
mkdir dir=${build}/hello/WEB-INF/
build.xml 80 lines, 2606 characters
remove url=${url} username=$username} password=${password}
path={$path}/
/target
directory
drwxr-x--- 7 t441313 tivas512 May 28 16:08 ..
-rw-r- 1 t441313 tivas462 May 28 16:08 index.html
-rw-r- 1 t441313 tivas371 May 28 16:08 hello.jsp
-rw-r- 1 t441313 tivas 1051 May 28 16:10 hello.war
-rw-r- 1 t441313 tivas 2606 May 28 16:10 build.xml
drwxr-x--- 2 t441313 tivas512 May 28 16:10 .
/home/t441313/jakarta-ant-1.5/hello
target name=deploy description=deploy all applications
depends=build
deploy url=${url} username=$username} password=${password}
path={$path} war=file:${build}/hello.war/
/target
target name=undeploy description=undeploy all applications
undeploy url=${url} username=$username} password=${password}
path={$path}/
/target
/project
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20305] - ANT build - managing application
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=20305. 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=20305 ANT build - managing application [EMAIL PROTECTED] changed: What|Removed |Added Priority|Other |High Version|4.0 Beta 1 |4.1.24 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20305] - ANT build - managing application
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=20305. 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=20305 ANT build - managing application [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-05-28 14:35 --- This is not a place to ask question. Please ask you question on [EMAIL PROTECTED] and I will be happy to help you. -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContext.java
jfarcand2003/05/28 08:08:33
Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
Log:
Fix for bug 20217: restartContext doesn't work when a context configuration file
maps a path to two levels.
Revision ChangesPath
1.62 +25 -6
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.61
retrieving revision 1.62
diff -u -r1.61 -r1.62
--- StandardContext.java 26 May 2003 22:03:59 - 1.61
+++ StandardContext.java 28 May 2003 15:08:33 - 1.62
@@ -258,6 +258,11 @@
/**
+ * The default context name used for config file
+ */
+private String defaultConfigFile = context.xml;
+
+/**
* The display name of this web application.
*/
private String displayName = null;
@@ -3873,11 +3878,25 @@
if (name.equals()) {
name = ROOT;
}
-File file = new File(appBase);
-file = new File(file, name + .xml);
-if( log.isDebugEnabled() )
-log.debug( Set config file + file);
-setConfigFile(file.getPath());
+File fileBase = new File(appBase);
+File file = new File(fileBase, name + .xml);
+
+/*
+ * Try to save the context information using a default file name.
+ */
+if (!file.exists()){
+file = new File(fileBase, getDocBase() + File.separator +
defaultConfigFile);
+}
+
+// Make sure the file exist before setting it.
+if (file.exists()){
+setConfigFile(file.getPath());
+if( log.isDebugEnabled() )
+log.debug( Set config file + file);
+} else {
+if( log.isDebugEnabled() )
+log.debug( Config file doesn't exists: + file);
+}
}
// Add missing components as necessary
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20307] New: - Setting content length causes Tomcat to ignore response status
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=20307.
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=20307
Setting content length causes Tomcat to ignore response status
Summary: Setting content length causes Tomcat to ignore response
status
Product: Tomcat 5
Version: Nightly Build
Platform: All
OS/Version: All
Status: NEW
Severity: Minor
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Setting the content length causes Tomcat to ignore subsequent status changes.
As an example:
import java.io.*;
import javax.servlet.http.*;
public class Test extends HttpServlet {
protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws IOException {
response.setContentLength(0);
response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
response.flushBuffer();
}
}
This results in a response code of 200 (OK) rather than 401 (Unauthorized).
Doing:
response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
response.setContentLength(0);
results in the correct response code being sent.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20314] New: - Wrapped request object not the same when forwarding to a web resource in a filter
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=20314. 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=20314 Wrapped request object not the same when forwarding to a web resource in a filter Summary: Wrapped request object not the same when forwarding to a web resource in a filter Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] SRV.6.2.2 Wrapping Requests and Responses in Servlet 2.3 specification not fully implemented??? The same requirement of wrapper object identity applies to the case where the developer passes a wrapped request or response object into the request dispatcher; the request and response objects passed into the servlet invoked must be the same objects as were passed in. When I tried wrapping of a request object in a filter and then forwarding the request to a web resource I got another request object at the destination. Worked fine when I used the doFilter() method. /Nils Flemström, Sweden - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20317] New: - tomcat 4.1.24 can't work for symbolic link
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=20317. 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=20317 tomcat 4.1.24 can't work for symbolic link Summary: tomcat 4.1.24 can't work for symbolic link Product: Tomcat 4 Version: 4.1.22 Platform: Sun OS/Version: Solaris Status: UNCONFIRMED Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] i used some symbolic link for webapps/examples/WEB-INF/classes and webapps/examples/WEB-INF/lib in tomcat 4.06 and it worked fine... when i upgraded it to tomcat 4.1.24 all these symbolic links don't work anymore... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20317] - tomcat 4.1.24 can't work for symbolic link
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=20317. 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=20317 tomcat 4.1.24 can't work for symbolic link [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-05-28 23:04 --- This is a faq item. http://tomcatfaq.sourceforge.net/configure.html Context path=/myApp docBase=myApp debug=0 Resources className=org.apache.naming.resources.FileDirContext allowLinking=true / /Context - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bugzilla dups for Handling of Wrapped Responses
From the recent bug report about wrapped responses vs .forward() I did this query: Search on description wrapped request forward http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=RESOLVEDbug_status=VERIFIEDbug_status=CLOSEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Tomcat+4short_desc=short_desc_type=allwordssubstrlong_desc=wrapped+request+forwardlong_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitnewqueryname=order=Reuse+same+sort+as+last+time Turned up each of the bugs in question ... http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8566 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11335 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16032 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9754 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11366 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20314 Are all of there dups of one another? -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20319] New: - mod_jk2 has no method to pass non-standard env variables
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=20319. 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=20319 mod_jk2 has no method to pass non-standard env variables Summary: mod_jk2 has no method to pass non-standard env variables Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: Enhancement Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I use rewrite rules to fool users into thinking my .jsp pages are .html files. I am using mod_jk and use the directive JkEnvVar SCRIPT_URL SCRIPT_URL to pass the URL seen in the client browser to my jsp pages. I really want to upgrade to mod_jk2 but need to find a way of supporting this first. I've searched all over the web for hours and can't find any information regarding this. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20266] - Tomcat memory profiler
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=20266. 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=20266 Tomcat memory profiler --- Additional Comments From [EMAIL PROTECTED] 2003-05-29 00:13 --- I have had similar experience with memory use of tomcat growing. The connector code in 4.1.24 (not sure about 4.1.18) times out the listen socket after 1 second. I submitted a bug fix for this and it will be in the next 4.1.x release I assume. If you are worried about the memory performance when tomcat is idle I suggest commenting out the SSL connector (if you can). My tests showed that with the SSL connector disabled and tomcat not actively processing requests around 1K of memory a second was being allocated (even with the socket timing out). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Reg: HttpSession
Hi, I have a requirement where i need to access some variables across applications. I have my own class to store/retrieve the values. But for this the user should use myClass.setAttribute(); Instead i want the user to use normal session.setAttribute(). This has to be done by extending the StandardSession and overriding the get/set/remove Attribute methods. How can I configure tomcat to use the extended StandardSession instead of the default StandardSession. The requirement is because we have a framework that can be used in an application and across applications. In both the cases the user should be using session.setAttribute alone. Internally the implementation should alone change. Hope I am clear. Are there some other way by which i can achieve this functionality. Thanks in Advance Shanmugam PL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContext.java
jfarcand2003/05/28 21:13:24
Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
Log:
Revert back my latest changes since it did not fix the problem completely.
Revision ChangesPath
1.63 +7 -25
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.62
retrieving revision 1.63
diff -u -r1.62 -r1.63
--- StandardContext.java 28 May 2003 15:08:33 - 1.62
+++ StandardContext.java 29 May 2003 04:13:24 - 1.63
@@ -257,12 +257,7 @@
private boolean crossContext = false;
-/**
- * The default context name used for config file
- */
-private String defaultConfigFile = context.xml;
-
-/**
+ /**
* The display name of this web application.
*/
private String displayName = null;
@@ -3878,25 +3873,12 @@
if (name.equals()) {
name = ROOT;
}
-File fileBase = new File(appBase);
-File file = new File(fileBase, name + .xml);
-
-/*
- * Try to save the context information using a default file name.
- */
-if (!file.exists()){
-file = new File(fileBase, getDocBase() + File.separator +
defaultConfigFile);
-}
+File file = new File(appBase);
+file = new File(file, name + .xml);
-// Make sure the file exist before setting it.
-if (file.exists()){
-setConfigFile(file.getPath());
-if( log.isDebugEnabled() )
-log.debug( Set config file + file);
-} else {
-if( log.isDebugEnabled() )
-log.debug( Config file doesn't exists: + file);
-}
+setConfigFile(file.getPath());
+if( log.isDebugEnabled() )
+log.debug( Set config file + file);
}
// Add missing components as necessary
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/coreStandardContext.java
[EMAIL PROTECTED] wrote: jfarcand2003/05/28 21:13:24 Modified:catalina/src/share/org/apache/catalina/core StandardContext.java Log: Revert back my latest changes since it did not fix the problem completely. Don't worry about that IMO. I'll have to rewrite that code for the deployer refactoring I'll do (today). I hope I'll be done in one day :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bugzilla dups for Handling of Wrapped Responses
Tim Funk wrote: From the recent bug report about wrapped responses vs .forward() I did this query: Search on description wrapped request forward http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=RESOLVEDbug_status=VERIFIEDbug_status=CLOSEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Tomcat+4short_desc=short_desc_type=allwordssubstrlong_desc=wrapped+request+forwardlong_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitnewqueryname=order=Reuse+same+sort+as+last+time Turned up each of the bugs in question ... http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8566 The resolution and comments are correct, apparently. We don't quite do that right now, and it seems fixed if you looks at 4.1.x behavior. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11335 That one seems bad with respect to the spec (no wrapping is supposed to occur, so we reflect whatever path the wrapped request wants to). There's a contradiction, though. That bug probably doesn't exist anymore with 4.1.x since we wrap. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16032 That's probably fixed now (not too sure). http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9754 That's a dupe. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11366 This likely doesn't exist in 4.1.x. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20314 Are all of there dups of one another? The spec contradicts itself, basically (I'm reading Servlet 2.4 PFD 3). I posted messages complaining about it, and (unsurprisingly) got ignored. Sun spec folks are really good about ignoring people (even if you're a coworker) unless: - you're on their expert group, and start complaining really loud (I'm not on the expert group - no time) - you have access to the Sun Bugtraq and file a P1 bug (that one works so great, it's amazing :-D unfortunately, I have no access to it :-( ) There are RD requirements that would be hard to implement without wrapping (all those special attributes, and parameter isolation). IMO the parameter isolation is impossible if the request is not ours (or I don't know, maybe we have to extract everything before invoking the pipeline if a request, and then restore them one by one). So having a query string will make the RD dead slow (but the general case will be faster if we can get rid of wrapping). Section's 6.2.2 wording is bad with respect to the new spec: the request dispatcher now invokes a filter pipeline, not the servlet itself. I'm -1 for trying to change the RD behavior in TC 4.1.x (reaslistically, we'd break things trying to fix it, and it is clearly not worth the pain for the stable branch). If the spec is clarified, then we can implement the specified behavior in TC 5, otherwise I'd prefer keeping the current behavior. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
