cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config realm.xml

2004-10-10 Thread markt 
markt   2004/10/10 13:38:08

  Modified:catalina/src/share/org/apache/catalina/realm JNDIRealm.java
   webapps/tomcat-docs/config realm.xml
  Log:
  Fix bug 31273. Add support for derefAliases.
  
  Revision  ChangesPath
  1.20  +30 -2 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java
  
  Index: JNDIRealm.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- JNDIRealm.java26 Aug 2004 21:37:21 -  1.19
  +++ JNDIRealm.java10 Oct 2004 20:38:08 -  1.20
  @@ -191,6 +191,17 @@
*/
   protected String contextFactory = com.sun.jndi.ldap.LdapCtxFactory;
   
  +
  +/**
  + * How aliases should be dereferenced during search operations.
  + */
  +protected String derefAliases = null;
  +
  +/**
  + * Constant that holds the name of the environment property for specifying 
  + * the manner in which aliases should be dereferenced.
  + */
  +public final static String DEREF_ALIASES = java.naming.ldap.derefAliases;
   
   /**
* Descriptive information about this Realm implementation.
  @@ -441,6 +452,21 @@
   
   }
   
  +/**
  + * Return the derefAliases setting to be used.
  + */
  +public java.lang.String getDerefAliases() {
  +return derefAliases;
  +}  
  +
  +/**
  + * Set the value for derefAliases to be used when searching the directory.
  + * 
  + * @param derefAliases New value of property derefAliases.
  + */
  +public void setDerefAliases(java.lang.String derefAliases) {
  +  this.derefAliases = derefAliases;
  +}
   
   /**
* Return the protocol to be used.
  @@ -1428,7 +1454,7 @@
*/
   protected String getName() {
   
  -return (this.name);
  +return (name);
   
   }
   
  @@ -1522,6 +1548,8 @@
   env.put(Context.SECURITY_PROTOCOL, protocol);
   if (referrals != null)
   env.put(Context.REFERRAL, referrals);
  +if (derefAliases != null)
  +env.put(JNDIRealm.DEREF_ALIASES, derefAliases);
   
   return env;
   
  
  
  
  1.9   +6 -0  jakarta-tomcat-4.0/webapps/tomcat-docs/config/realm.xml
  
  Index: realm.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/realm.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- realm.xml 12 Jan 2003 17:26:48 -  1.8
  +++ realm.xml 10 Oct 2004 20:38:08 -  1.9
  @@ -298,6 +298,12 @@
   assumes that the standard JNDI LDAP provider will be utilized./p
 /attribute
   
  +  attribute name=derefAliases required=false
  +pA string specifying how aliases are to be dereferenced during
  +search operations. The allowed values are always, never,
  +finding and searching. If not specified, always is used./p
  +  /attribute
  +
 attribute name=protocol required=false
pA string specifying the security protocol to use. If not given
the providers default is used./p
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/webapps/docs/config realm.xml

2004-10-10 Thread markt 
markt   2004/10/10 13:42:32

  Modified:catalina/src/share/org/apache/catalina/realm Tag: TOMCAT_5_0
JNDIRealm.java
   webapps/docs Tag: TOMCAT_5_0 changelog.xml
   webapps/docs/config Tag: TOMCAT_5_0 realm.xml
  Log:
  Fix bug 31273. Add support for derefAliases.
   - Ported from TC4
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.12.2.1  +29 -1 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java
  
  Index: JNDIRealm.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java,v
  retrieving revision 1.12
  retrieving revision 1.12.2.1
  diff -u -r1.12 -r1.12.2.1
  --- JNDIRealm.java26 May 2004 15:51:14 -  1.12
  +++ JNDIRealm.java10 Oct 2004 20:42:32 -  1.12.2.1
  @@ -193,6 +193,17 @@
*/
   protected String contextFactory = com.sun.jndi.ldap.LdapCtxFactory;
   
  +
  +/**
  + * How aliases should be dereferenced during search operations.
  + */
  +protected String derefAliases = null;
  +
  +/**
  + * Constant that holds the name of the environment property for specifying 
  + * the manner in which aliases should be dereferenced.
  + */
  +public final static String DEREF_ALIASES = java.naming.ldap.derefAliases;
   
   /**
* Descriptive information about this Realm implementation.
  @@ -443,6 +454,21 @@
   
   }
   
  +/**
  + * Return the derefAliases setting to be used.
  + */
  +public java.lang.String getDerefAliases() {
  +return derefAliases;
  +}  
  +
  +/**
  + * Set the value for derefAliases to be used when searching the directory.
  + * 
  + * @param derefAliases New value of property derefAliases.
  + */
  +public void setDerefAliases(java.lang.String derefAliases) {
  +  this.derefAliases = derefAliases;
  +}
   
   /**
* Return the protocol to be used.
  @@ -1524,6 +1550,8 @@
   env.put(Context.SECURITY_PROTOCOL, protocol);
   if (referrals != null)
   env.put(Context.REFERRAL, referrals);
  +if (derefAliases != null)
  +env.put(JNDIRealm.DEREF_ALIASES, derefAliases);
   
   return env;
   
  
  
  
  No   revision
  No   revision
  1.70.2.51 +3 -0  jakarta-tomcat-catalina/webapps/docs/changelog.xml
  
  Index: changelog.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
  retrieving revision 1.70.2.50
  retrieving revision 1.70.2.51
  diff -u -r1.70.2.50 -r1.70.2.51
  --- changelog.xml 6 Oct 2004 13:35:51 -   1.70.2.50
  +++ changelog.xml 10 Oct 2004 20:42:32 -  1.70.2.51
  @@ -22,6 +22,9 @@
   
 subsection name=Catalina
   changelog
  +  fix
  +bug31273/bug: Add support for derefaliases in JNDIRealm. (markt)
  +  /fix
   /changelog
 /subsection
   
  
  
  
  No   revision
  No   revision
  1.5.2.1   +6 -0  jakarta-tomcat-catalina/webapps/docs/config/realm.xml
  
  Index: realm.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/config/realm.xml,v
  retrieving revision 1.5
  retrieving revision 1.5.2.1
  diff -u -r1.5 -r1.5.2.1
  --- realm.xml 15 Jan 2003 03:40:44 -  1.5
  +++ realm.xml 10 Oct 2004 20:42:32 -  1.5.2.1
  @@ -300,6 +300,12 @@
   assumes that the standard JNDI LDAP provider will be utilized./p
 /attribute
 
  +  attribute name=derefAliases required=false
  +pA string specifying how aliases are to be dereferenced during
  +search operations. The allowed values are always, never,
  +finding and searching. If not specified, always is used./p
  +  /attribute
  +
 attribute name=protocol required=false
pA string specifying the security protocol to use. If not given
the providers default is used./p
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/webapps/docs/config realm.xml

2004-10-10 Thread markt 
markt   2004/10/10 13:43:49

  Modified:catalina/src/share/org/apache/catalina/realm JNDIRealm.java
   webapps/docs changelog.xml
   webapps/docs/config realm.xml
  Log:
  Fix bug 31273. Add support for derefAliases.
   - Ported from TC4
  
  Revision  ChangesPath
  1.15  +29 -1 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java
  
  Index: JNDIRealm.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- JNDIRealm.java23 Jun 2004 13:51:37 -  1.14
  +++ JNDIRealm.java10 Oct 2004 20:43:49 -  1.15
  @@ -193,6 +193,17 @@
*/
   protected String contextFactory = com.sun.jndi.ldap.LdapCtxFactory;
   
  +
  +/**
  + * How aliases should be dereferenced during search operations.
  + */
  +protected String derefAliases = null;
  +
  +/**
  + * Constant that holds the name of the environment property for specifying 
  + * the manner in which aliases should be dereferenced.
  + */
  +public final static String DEREF_ALIASES = java.naming.ldap.derefAliases;
   
   /**
* Descriptive information about this Realm implementation.
  @@ -443,6 +454,21 @@
   
   }
   
  +/**
  + * Return the derefAliases setting to be used.
  + */
  +public java.lang.String getDerefAliases() {
  +return derefAliases;
  +}  
  +
  +/**
  + * Set the value for derefAliases to be used when searching the directory.
  + * 
  + * @param derefAliases New value of property derefAliases.
  + */
  +public void setDerefAliases(java.lang.String derefAliases) {
  +  this.derefAliases = derefAliases;
  +}
   
   /**
* Return the protocol to be used.
  @@ -1505,6 +1531,8 @@
   env.put(Context.SECURITY_PROTOCOL, protocol);
   if (referrals != null)
   env.put(Context.REFERRAL, referrals);
  +if (derefAliases != null)
  +env.put(JNDIRealm.DEREF_ALIASES, derefAliases);
   
   return env;
   
  
  
  
  1.145 +3 -0  jakarta-tomcat-catalina/webapps/docs/changelog.xml
  
  Index: changelog.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
  retrieving revision 1.144
  retrieving revision 1.145
  diff -u -r1.144 -r1.145
  --- changelog.xml 7 Oct 2004 13:09:17 -   1.144
  +++ changelog.xml 10 Oct 2004 20:43:49 -  1.145
  @@ -40,6 +40,9 @@
 fix
   bug31578/bug: Update Manager configuration documentation. (yoavs)
 /fix
  +  fix
  +bug31273/bug: Add support for derefaliases in JNDIRealm. (markt)
  +  /fix
   /changelog
 /subsection
   
  
  
  
  1.6   +6 -0  jakarta-tomcat-catalina/webapps/docs/config/realm.xml
  
  Index: realm.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/config/realm.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- realm.xml 15 Jan 2003 03:40:44 -  1.5
  +++ realm.xml 10 Oct 2004 20:43:49 -  1.6
  @@ -300,6 +300,12 @@
   assumes that the standard JNDI LDAP provider will be utilized./p
 /attribute
 
  +  attribute name=derefAliases required=false
  +pA string specifying how aliases are to be dereferenced during
  +search operations. The allowed values are always, never,
  +finding and searching. If not specified, always is used./p
  +  /attribute
  +
 attribute name=protocol required=false
pA string specifying the security protocol to use. If not given
the providers default is used./p
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 31273] - JNDIRealm doesn't take care of env params

2004-10-10 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31273.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31273

JNDIRealm doesn't take care of env params

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-10-10 20:47 ---
This has been fixed in CVS for 4.1.x, 5.0.x and 5.5.x and will be included in 
the next respective releases.

Many thanks for the patch. I commited a variation that achieves the same 
result.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 4690] - sessions not scoped according to spec section 7.3

2004-10-10 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=4690.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=4690

sessions not scoped according to spec section 7.3





--- Additional Comments From [EMAIL PROTECTED]  2004-10-10 20:54 ---
I think this is an issue to be resolved between the Portlet Spec people and 
the Servlet Spec people.  Tomcat's implementation is strictly according to the 
Servlet Spec, and is valid (passes all TCKs 100%) according to that Spec.  IF 
the Spec specifies cross-context behavior that we don't support (it doesn't), 
then you'd have a legit Tomcat bug.  

If the Portlet Spec relies on behavior that is unspecified or unclear in the 
Servlet Spec, contact the JSR 154 team ([EMAIL PROTECTED]) to address 
the issue.  The Servlet Spec, like the Portlet Spec, is very much alive.  I 
would not be surprised to see clarification on this cross-context stuff in 
v2.5 of the Servlet Spec.  And needless to say, the next major Tomcat version 
will implement the next Servlet Spec version accurately and fully, just as it 
does now.  But until such a Spec change is made, this is not a Tomcat bug.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application

2004-10-10 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=26372.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=26372

java.lang.ThreadDeath when trying to reload an application





--- Additional Comments From [EMAIL PROTECTED]  2004-10-10 20:56 ---
If you (any of the people following this thread) want, please suggest text 
that I can put in the following places:
- Tomcat's Logging configuration page
- Tomcat's FAQ
- Log4J FAQ
- Other places you find appropriate

Otherwise, I'll come up with some text myself (which will include a link to 
this Bugzilla issue) and place the text at the above locations.  At that time 
I will close this item, as it's not a Tomcat bug and there's no reason for it 
to stay open.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 31201] - Encoding bug when using jsp:include ... action

2004-10-10 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31201.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31201

Encoding bug when using jsp:include ... action





--- Additional Comments From [EMAIL PROTECTED]  2004-10-10 21:02 ---
1a. If you are worried about performance - precompile. If you want ease of 
replacement - don't. You can't have it both ways.

1b. Please state which section of the spec you believe tomcat is not compliant 
with. Without this, I can't invetsigate further.

3. What about different encodings across different webapps on the same server?

There are solutions for this issue with the current versions of tomact. My 
concern about the proposed patch, that it encourages non-portable coding, 
remains.

I am leaving this as REOPENED for now but I am leaning towards resolving it as 
WONTFIX.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 31623] New: - [PATCH] setclasspath.sh script os400 problems

2004-10-10 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31623.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31623

[PATCH] setclasspath.sh script os400 problems

   Summary: [PATCH] setclasspath.sh script os400 problems
   Product: Tomcat 5
   Version: 5.0.28
  Platform: Macintosh
OS/Version: MacOS X
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The setclasspath.sh script contains some questionable syntax in several areas where 
the $os400 
variable is tested.

These errors lead to warnings from bash/sh if os400 is not set, and additionally mean 
that the 
functionality doesn't work as intended (i.e. the test of the os400 variable at one 
point assumes that it 
may have a null/non-null value, and at another assumes that it will always have a 
valid value.

These changes add robustness by not assuming that os400 will always be set to a 
non-null value, and 
test it only against true when testing whether it is true.

Patch is attached.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 31623] - [PATCH] setclasspath.sh script os400 problems

2004-10-10 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31623.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31623

[PATCH] setclasspath.sh script os400 problems





--- Additional Comments From [EMAIL PROTECTED]  2004-10-10 22:36 ---
Created an attachment (id=13014)
Patch to setclasspath.sh

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 31624] New: - Incomplete error message: java.util.zip.ZipException: No such file or directory

2004-10-10 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31624.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31624

Incomplete error message: java.util.zip.ZipException: No such file or directory

   Summary: Incomplete error message: java.util.zip.ZipException: No
such file or directory
   Product: Tomcat 5
   Version: 5.0.27
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


On startup, tomcat bombs out like so:

Bootstrap: Class loader creation threw exception
java.lang.IllegalArgumentException: addRepositoryInternal
at
org.apache.catalina.loader.StandardClassLoader.addRepositoryInternal(StandardClassLoader.java:957)
at
org.apache.catalina.loader.StandardClassLoader.init(StandardClassLoader.java:153)
at
org.apache.catalina.startup.ClassLoaderFactory.createClassLoader(ClassLoaderFactory.java:189)
at
org.apache.catalina.startup.Bootstrap.createClassLoader(Bootstrap.java:160)
at
org.apache.catalina.startup.Bootstrap.initClassLoaders(Bootstrap.java:104)
at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:193)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:399)
Caused by: java.util.zip.ZipException: No such file or directory
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.init(ZipFile.java:112)
at java.util.jar.JarFile.init(JarFile.java:127)
at java.util.jar.JarFile.init(JarFile.java:65)
at
org.apache.catalina.loader.StandardClassLoader.addRepositoryInternal(StandardClassLoader.java:944)
... 6 more

The reason for the error is a missing jar file.

Of course the mystery remains as to WHICH jar file, because the error message
above neglects to mention which jar file.

This leaves the user with the following options:

- Spend hours randomly shooting in the dark trying to find which jar is missing
- Spend hours setting up tomcat in a debugging environment to set a breakpoint
so that it can be seen which jar is missing.

The fix: Include the name of the jar file in the error message.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 31624] - Incomplete error message: java.util.zip.ZipException: No such file or directory

2004-10-10 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31624.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31624

Incomplete error message: java.util.zip.ZipException: No such file or directory

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-10-10 23:07 ---
This was already fixed for 5.0.29.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

2004-10-10 Thread billbarker 
billbarker2004/10/10 16:43:20

  Modified:jk/java/org/apache/jk/server JkMain.java
  Log:
  Make the 'jk2.properties' file entirely optional.
  
  By default, no properties file is read.  Configuration should be done on the 
Connector element.  To get the previous behavior, you need to have:
Connector protocol=AJP/1.3 propertiesFile=conf/jk2.properties /
  
  Revision  ChangesPath
  1.47  +44 -24
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java
  
  Index: JkMain.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java,v
  retrieving revision 1.46
  retrieving revision 1.47
  diff -u -r1.46 -r1.47
  --- JkMain.java   24 Feb 2004 08:48:41 -  1.46
  +++ JkMain.java   10 Oct 2004 23:43:20 -  1.47
  @@ -115,7 +115,7 @@
   }
   System.setProperty(java.protocol.handler.pkgs, value);
   } catch(Exception ex ) {
  -ex.printStackTrace();
  +log.info(Error adding SSL Protocol Handler,ex);
   }
   }
   
  @@ -126,10 +126,8 @@
*/
   public void setPropertiesFile( String p  ) {
   propFile=p;
  -try {
  -props.load( new FileInputStream(propFile) );
  -} catch(IOException ex ){
  -ex.printStackTrace();
  +if( started ) {
  +loadPropertiesFile();
   }
   }
   
  @@ -147,6 +145,9 @@
   if( jkHome.equals( n ) ) {
   setJkHome( v );
   } 
  +if( propertiesFile.equals( n ) ) {
  +setPropertiesFile( v );
  +}
   props.put( n, v );
   if( started ) {
   processProperty( n, v );
  @@ -248,23 +249,10 @@
   if( home==null ) {
   log.info( Can't find home, jk2.properties not loaded);
   }
  -if( home != null ) {
  -File hF=new File(home);
  -File conf=new File( home, conf );
  -if( ! conf.exists() )
  -conf=new File( home, etc );
  +if(log.isDebugEnabled())
  +log.debug(Starting Jk2, base dir=  + home  );
  +loadPropertiesFile();
   
  -propsF=new File( conf, jk2.properties );
  -
  -if( propsF.exists() ) {
  -log.debug(Starting Jk2, base dir=  + home +  conf= + propsF );
  -setPropertiesFile( propsF.getAbsolutePath());
  -} else {
  -log.debug(Starting Jk2, base dir=  + home );
  -if( log.isDebugEnabled() )
  -log.debug( No properties file found  + propsF );
  -}
  -}
   String initHTTPS = (String)props.get(class.initHTTPS);
   if(true.equalsIgnoreCase(initHTTPS)) {
   initHTTPSUrls();
  @@ -435,22 +423,54 @@
   jkMain.init();
   jkMain.start();
   } catch( Exception ex ) {
  -ex.printStackTrace();
  +log.warn(Error running,ex);
   }
   }
   
   //  Private methods 
   
  +
  +private boolean checkPropertiesFile() {
  +if(propFile == null) {
  +return false;
  +}
  +propsF = new File(propFile);
  +if(!propsF.isAbsolute()) {
  +String home = getWorkerEnv().getJkHome();
  +if( home == null ) {
  +return false;
  +}
  +propsF = new File(home, propFile);
  +}
  +return propsF.exists();
  +}
  +
  +private void loadPropertiesFile() {
  +if(!checkPropertiesFile()) {
  +return;
  +}
  +
  +try {
  +props.load( new FileInputStream(propsF) );
  +} catch(IOException ex ){
  +log.warn(Unable to load properties from +propsF,ex);
  +}
  +}
  +
   public  void saveProperties() {
   if( !saveProperties) return;
   
  +if(propsF == null) {
  +log.warn(No properties file specified. Unable to save);
  +return;
  +}
   // Temp - to check if it works
  -String outFile=propFile + .save;
  +File outFile= new File(propsF.getParentFile(), propsF.getName()+.save);
   log.debug(Saving properties  + outFile );
   try {
   props.save( new FileOutputStream(outFile), AUTOMATICALLY GENERATED );
   } catch(IOException ex ){
  -ex.printStackTrace();
  +log.warn(Unable to save to +outFile,ex);
   }
   }
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Bug 4690: sessions not scoped according to spec section 7.3

2004-10-10 Thread Nick Lothian 

Issue 4690 http://issues.apache.org/bugzilla/show_bug.cgi?id=4690 relates
to the Tomcat implementation of cross-context sessions.

The Pluto (JSR-168 Portlet RI) team need the behaviour in this area changed
to be able to properly implement JSR-168. 

I understand that this is an underspecified area of the servlet
specification. I believe that this area will be more completely specified as
part of the servlet 2.5 spec, which will be a good thing.

In the mean time I'd like to suggest that the Tomcat interpretation of the
spec isn't particularly useful, and that there are other interpretations
that would be more useful, and equally as right.

Currently Tomcat's implementation of cross-context sessions means that if
you put an attribute into the session from inside a cross-context dispatcher
it cannot be retrieved.

I would argue that:

Any object bound into a session is available to any other servlet that
belongs to the
same ServletContext and handles a request identified as being a part of the
same
session. -- SRV.7.4

indicates that cross-context sessions should be handled in the same way as
normal sessions - particularly since the alternate interpretation makes
sessions useless when used from a cross context  dispatcher.


What do people think? Have I persuaded anyone yet?

Nick
[EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 31201] - Encoding bug when using jsp:include ... action

2004-10-10 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31201.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31201

Encoding bug when using jsp:include ... action





--- Additional Comments From [EMAIL PROTECTED]  2004-10-11 02:46 ---
1a.No I can't. So, I need this patch is committed.

1b.Please see API spec of RequestDispatcher#include method.
   (Because jsp:include action will be converted into this method.)

   This method must be able to handle any resource(such as a servlet,
   HTML file, or JSP file). But I feel like you said that because Tomcat
   cannot handle HTML file correctly, you ask to convert HTML file into
   JSP file. Isn't it right?

3.It can be resolved by defining DefaultServlet on each web app.


If this patch is committed, we can separate web app from environment(locale)
before fixing JSP spec.

If you don't set file.encoding property, Tomcat will handle it just like 
former. So I believe there will be no demerit at all.

If you say that property of i18n depending on container is a problem, see 
javaEncoding property of JspServlet. This property is also depend on the
container, and assume that ALL JSP files for all webapps have the same 
encoding. Do you think that javaEncoding property is also a problem?

Do you mean that it is not a problem, current Tomcat changes its handling by
environments?

I believe that this patch will be help for i18n problems, as other
properties.

Regards,

Takayuki Kaneko

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]