svn commit: r326850 - in /tomcat/container/tc5.5.x: modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaSession.java webapps/docs/changelog.xml

[pero]

Author: pero
Date: Thu Oct 20 00:34:58 2005
New Revision: 326850

URL: http://svn.apache.org/viewcvs?rev=326850&view=rev
Log:
Fix bug 34984
HttpSessionBindingEvent.getValue() get now correct value

Modified:

tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaSession.java
tomcat/container/tc5.5.x/webapps/docs/changelog.xml

Modified: 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaSession.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaSession.java?rev=326850&r1=326849&r2=326850&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaSession.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaSession.java
 Thu Oct 20 00:34:58 2005
@@ -1214,6 +1214,10 @@
 return;
 }
 
+// Validate our current state
+if (!isValid())
+throw new IllegalStateException(sm
+.getString("standardSession.setAttribute.ise"));
 if (!(value instanceof java.io.Serializable)) {
 throw new IllegalArgumentException("Attribute [" + name
 + "] is not serializable");
@@ -1222,32 +1226,28 @@
 if (addDeltaRequest && (deltaRequest != null))
 deltaRequest.setAttribute(name, value);
 
-// Validate our current state
-if (!isValid())
-throw new IllegalStateException(sm
-.getString("standardSession.setAttribute.ise"));
-if ((manager != null) && manager.getDistributable()
-&& !(value instanceof Serializable))
-throw new IllegalArgumentException(sm
-.getString("standardSession.setAttribute.iae"));
 
 // Construct an event with the new value
 HttpSessionBindingEvent event = null;
 
 // Call the valueBound() method if necessary
 if (value instanceof HttpSessionBindingListener && notify) {
-event = new HttpSessionBindingEvent(getSession(), name, value);
-try {
-((HttpSessionBindingListener) value).valueBound(event);
-} catch (Exception x) {
-log.error(smp.getString("deltaSession.valueBound.ex"), x);
+// Don't call any notification if replacing with the same value
+Object oldValue = attributes.get(name);
+if (value != oldValue) {
+event = new HttpSessionBindingEvent(getSession(), name, value);
+try {
+((HttpSessionBindingListener) value).valueBound(event);
+} catch (Exception x) {
+log.error(smp.getString("deltaSession.valueBound.ex"), x);
+}
 }
 }
 
 // Replace or add this attribute
 Object unbound = attributes.put(name, value);
 // Call the valueUnbound() method if necessary
-if ((unbound != null) && notify
+if ((unbound != null) && (unbound != value) && notify
 && (unbound instanceof HttpSessionBindingListener)) {
 try {
 ((HttpSessionBindingListener) unbound)
@@ -1290,7 +1290,7 @@
 "beforeSessionAttributeAdded", listener);
 if (event == null) {
 event = new HttpSessionBindingEvent(getSession(),
-name, unbound);
+name, value);
 }
 listener.attributeAdded(event);
 fireContainerEvent(context,
@@ -1566,15 +1566,16 @@
 }
 
 // Call the valueUnbound() method if necessary
-HttpSessionBindingEvent event = new HttpSessionBindingEvent(
+ HttpSessionBindingEvent event = null;
+ if (value instanceof HttpSessionBindingListener) {
+event = new HttpSessionBindingEvent(
 (HttpSession) getSession(), name, value);
-if ((value != null) && (value instanceof HttpSessionBindingListener))
 try {
 ((HttpSessionBindingListener) value).valueUnbound(event);
 } catch (Exception x) {
 log.error(smp.getString("deltaSession.valueUnbound.ex"), x);
 }
-
+}
 // Notify interested application event listeners
 Context context = (Context) manager.getContainer();
 //fix for standalone manager without container
@@ -1589,6 +1590,10 @@
 try {
 fireContainerEvent(context,
 "beforeSessionAttributeRemoved", listener);
+if (event == null) {
+event = new HttpSessionBi

DO NOT REPLY [Bug 34984] - HttpSessionBindingEvent.getName() returns null in cluster and distributal

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-10-20 09:37 ---
Hola,

your war is wrong bundled, but after I moved the test at correct directory
structure I see the problem and fix it :-) See changes at DeltaSession Revision
326850!

Many thanks to pointing out this
Peter

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 34984] - HttpSessionBindingEvent.getName() returns null in cluster and distributal

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2005-10-20 14:22 ---
(In reply to comment #4)
> Hola,
> 
> your war is wrong bundled, but after I moved the test at correct directory
> structure I see the problem and fix it :-) See changes at DeltaSession 
> Revision
> 326850!
> 
> Many thanks to pointing out this
> Peter

You are right, sorry for the problems in the war.
Now it is fixed. 
Thanks a lot

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

[JK] Status -- was [VOTE] JK 1.2.15

[Mladen Turk]

Hi,

Seems there is low interest on JK 1.2.15 although it resolves
lots of issues compared with released 1.2.14.1 :(

So far, seems only Henri voted +1 (I hope I read his vote
properly).

Do you guys find something that would prevent 1.2.15 to
be declared as stable that I'm missing?

If not, please, let's vote that since it's the latest
release from CVS, so we can move to the SVN releases and
create a JK 1.3 branch we spoke so many times about.


Regards,
Mladen.


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

DO NOT REPLY [Bug 37164] - JkShmFile Directive and jk-runtime-status

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-10-20 15:55 ---
Sorry my fault I had the ownership mod_jk.shm file root:other and run Apache as
nobody:nobody. Changed ownership to nobody:nobody and it fixed the problem.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36681] - 2 Tomcat 5.5.7 clusters come to a grinding hault and generate errors

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




--- Additional Comments From [EMAIL PROTECTED]  2005-10-20 16:11 ---
Thanks for your help,  the tomcat 5.5.9 with cluster-fix has helped resolve the 
issue.  

Zubair

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

common/lib jars and classpath

[Brad O'Hearne]

Hello,

I have a really bizarre problem -- I have a JAAS login module  
configured via a JAASRealm in the server.xml file, and this login  
module relies on mail.jar (JavaMail API). I have placed the mail.jar  
and required activation.jar, and my login module jar in the common/ 
lib directory. In Tomcat 5.0.28, all resources are found, and  
authentication works fine. But in Tomcat 5.5.28 (and keep in mind I'm  
using the Java 1.4 compatibility kit), my login module is found, and  
invoked properly, but I'm experiencing a "NoSuchProviderException"  
for the resource "imap" which comes from javamail.providers file that  
comes from a  mail.jar. Now oddly, unless it is being loaded  
elsewhere by default by Tomcat (which I'm not aware of), the mail.jar  
must be getting found, because I'm able to propertly resolve some of  
the javax.mail classes I'm using in my login module -- lines of code  
that execute properly prior to the line of code that's throwing the  
Exception.


I'm sure this must be something simple, and probably not related  
specifically to the mail API, but probably just Tomcat classloading  
in general. Is there anything regardling classloading and/or  
classpath and/or resource loading that anyone knows that has changed  
from Tomcat 5.0.28 to 5.5.12?


Help!

Thanks,

Brad

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

DO NOT REPLY [Bug 37054] - NoClassDefFoundError using ServletContextListener

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2005-10-20 18:18 ---
Please attach the war, I'll try it against my installation and check why it
doesn't work.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36968] - jasper2 Ant task fails when executed more than once

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2005-10-20 18:27 ---
I tried the Jasper out of Tomcat versions:

5.0.28 - does not work (throws the error I reported)
5.0.30 - gives another error and won't compile anything

The absolute uri: http://java.sun.com/jstl/core cannot be resolved in either 
web.xml or the jar files deployed with this application

5.5.12 - works

It appears Jetty bundles the Jasper from either Tomcat 5.0.27 or 5.0.28 (not 
sure if they are any different).  I am not sure why Tomcat has a 5.0 and 5.5 
version so maybe you can explain the Jasper differences between each.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

svn commit: r326935 - in /tomcat/site/trunk: docs/index.html xdocs/index.xml

[yoavs]

Author: yoavs
Date: Thu Oct 20 09:28:06 2005
New Revision: 326935

URL: http://svn.apache.org/viewcvs?rev=326935&view=rev
Log:
A bit more marketing pizzazz.

Modified:
tomcat/site/trunk/docs/index.html
tomcat/site/trunk/xdocs/index.xml

Modified: tomcat/site/trunk/docs/index.html
URL: 
http://svn.apache.org/viewcvs/tomcat/site/trunk/docs/index.html?rev=326935&r1=326934&r2=326935&view=diff
==
--- tomcat/site/trunk/docs/index.html (original)
+++ tomcat/site/trunk/docs/index.html Thu Oct 20 09:28:06 2005
@@ -181,6 +181,11 @@
 participate in this open development project.  To learn more about getting 
 involved, click here.   
 
+Apache Tomcat powers numerous large-scale, mission-critical web applications
+across a diverse range of industries and organizations.  Some of these users
+and their stories are listed on the 
+http://wiki.apache.org/jakarta-tomcat/PoweredBy";>PoweredBy wiki 
page.
+
 
 
 

Modified: tomcat/site/trunk/xdocs/index.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/site/trunk/xdocs/index.xml?rev=326935&r1=326934&r2=326935&view=diff
==
--- tomcat/site/trunk/xdocs/index.xml (original)
+++ tomcat/site/trunk/xdocs/index.xml Thu Oct 20 09:28:06 2005
@@ -26,6 +26,11 @@
 participate in this open development project.  To learn more about getting 
 involved, click here.   
 
+Apache Tomcat powers numerous large-scale, mission-critical web applications
+across a diverse range of industries and organizations.  Some of these users
+and their stories are listed on the 
+http://wiki.apache.org/jakarta-tomcat/PoweredBy";>PoweredBy wiki 
page.
+
 
 
 



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

Re: Sandbox ?

[Costin Manolache]

Thanks !

I'll add few things I've worked on in the past - if people don't mind,
I'll create a sandbox/java and put everything in one tree, ant and
IDEs are smart enough to exclude/include different packages.

Let me know if any of this seems wrong:
- a smaller commons-logging impl, without any discovery tricks ( for runtime )
- attempt to refactor util.buf to use ByteBuffers
- coyote standalone
- a small demo for coyote standalone, using a rhino adapter.
- some additions to coyote - to make it a bit easier to use in standalone mode.

Costin

On 10/19/05, Mark Thomas <[EMAIL PROTECTED]> wrote:
> Done. See http://svn.apache.org/repos/asf/tomcat/sandbox/
>
> Mark
>
> > -Original Message-
> > From: Costin Manolache [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, October 19, 2005 6:33 AM
> > To: Tomcat Developers List
> > Subject: Sandbox ?
> >
> > Hi,
> >
> > Could someone who understand svn make a /sandbox or /experimental
> > directory ? I undertand it should be top level, and linked somehow
> > into tc5.5 - or do we want to be downloaded separately ?
> > Or can I just create it directly under tc5.5 ? I'm lost.
> >
> > Thanks,
> > Costin
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>

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

Help: Off topic big picture Question (Xforms vs JFS) ??

[Bovy, Stephen J]

Can anyone out there give me some opinion or perspective or web links
that explain how Xforms and JFS fit together in the big picture,

 (I.E.) yes, they are complementary and they do fit together
no, they conflict and are separate competing technologies  

Thanks in advance for any answers (:

Please feel free to reply to me privately, so as not to clutter the
mailing list (: 


Stephen Bovy
Computer Associates
6100 Center Drive
Suite 700
Los Angeles, CA 90045
Tel: (310) 957-3930
Fax: (310) 957-3917
Mobile: (818) 352-9917
e-mail: [EMAIL PROTECTED]

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

Re: [JK] Status -- was [VOTE] JK 1.2.15

[William A. Rowe, Jr.]

Mladen Turk wrote:

Hi,

Do you guys find something that would prevent 1.2.15 to
be declared as stable that I'm missing?


I'll try to find cycles to test myself, next week.  I know I'm having
alot of trouble with the apache 1.3 build on odd architectures, probably
because the clash of a libtool-based mod_jk.so.1.2 v.s. non-libtool based
httpd 1.3.  I'm working on cleaner autoconf against httpd-2.0 already for 
building mod_ftp, which will probably apply very cleanly here as well.



If not, please, let's vote that since it's the latest
release from CVS, so we can move to the SVN releases and
create a JK 1.3 branch we spoke so many times about.


Lesson learned in httpd-land, don't let this stop you.  One thing we had
learned, if you don't have a sandbox/new dev branch ready, then lots of
good 'new ideas' get forgotton months later when the new branch is finally
created.  Go ahead and branch already, if you don't place the files in the
http://www.apache.org/dist/jakarta/ tree till they are truly ready, users
won't be confused.

Creating http://tomcat.apache.org/dev/dist/ is a good convention for such
snapshots and pre-alpha tarballs, so the bleeding-edge users can begin to
play in that playground.

Bill

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

DO NOT REPLY [Bug 37186] New: - blank line at start at start of tomcat-users.xml file leads to failure of UserDatabase

[bugzilla]

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

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

   Summary: blank line at start at start of tomcat-users.xml file
leads to failure of UserDatabase
   Product: Tomcat 5
   Version: 5.5.9
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I accidentally added a blank line to the start of my conf/tomcat-users.xml 
file (i.e., above the "

  
  




Trimmed stack trace from stdout log follows:

20-Oct-2005 19:49:50 org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080

20-Oct-2005 19:49:50 org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 3875 ms

20-Oct-2005 19:49:50 org.apache.tomcat.util.digester.Digester fatalError
SEVERE: Parse Fatal Error at line 2 column 6: The processing instruction 
target matching "[xX][mM][lL]" is not allowed.
org.xml.sax.SAXParseException: The processing instruction target matching "[xX]
[mM][lL]" is not allowed.
at 
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseExcep
tion(ErrorHandlerWrapper.java:236)

20-Oct-2005 19:49:50 org.apache.naming.NamingContext lookup
WARNING: Unexpected exception resolving reference
org.xml.sax.SAXParseException: The processing instruction target matching "[xX]
[mM][lL]" is not allowed.
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse
(AbstractSAXParser.java:1269)

20-Oct-2005 19:49:50 
org.apache.catalina.mbeans.GlobalResourcesLifecycleListener createMBeans
SEVERE: Exception processing Global JNDI Resources
javax.naming.NamingException: The processing instruction target matching "[xX]
[mM][lL]" is not allowed.
at org.apache.naming.NamingContext.lookup(NamingContext.java:804)

20-Oct-2005 19:49:50 org.apache.catalina.core.StandardService start
INFO: Starting service Catalina

20-Oct-2005 19:49:50 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/5.5.9

20-Oct-2005 19:49:50 org.apache.tomcat.util.digester.Digester fatalError
SEVERE: Parse Fatal Error at line 2 column 6: The processing instruction 
target matching "[xX][mM][lL]" is not allowed.
org.xml.sax.SAXParseException: The processing instruction target matching "[xX]
[mM][lL]" is not allowed.
at 
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseExcep
tion(ErrorHandlerWrapper.java:236)

20-Oct-2005 19:49:50 org.apache.naming.NamingContext lookup
WARNING: Unexpected exception resolving reference
org.xml.sax.SAXParseException: The processing instruction target matching "[xX]
[mM][lL]" is not allowed.
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse
(AbstractSAXParser.java:1269)

20-Oct-2005 19:49:51 org.apache.catalina.realm.UserDatabaseRealm start
SEVERE: Exception looking up UserDatabase under key UserDatabase
javax.naming.NamingException: The processing instruction target matching "[xX]
[mM][lL]" is not allowed.
at org.apache.naming.NamingContext.lookup(NamingContext.java:804)

20-Oct-2005 19:49:51 org.apache.catalina.startup.Catalina start
SEVERE: Catalina.start: 
LifecycleException:  No UserDatabase component found under key UserDatabase
at org.apache.catalina.realm.UserDatabaseRealm.start
(UserDatabaseRealm.java:230)

20-Oct-2005 19:49:51 org.apache.catalina.startup.Catalina start
INFO: Server startup in 859 ms


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 37186] - blank line at start at start of tomcat-users.xml file leads to failure of UserDatabase

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2005-10-20 22:02 ---
(In reply to comment #0)
> I accidentally added a blank line to the start of my conf/tomcat-users.xml 
> file (i.e., above the " logs\stdout[date].log on startup (see below), and failure of "standard" Realm 
> authentication.  This seems a very tiny error to cause a failure, and the 
> error message did not help to find it.

In an XML file, the XML declaration (http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 37100] - SEGV in mod_proxy_ajp

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||tomcat-
   ||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2005-10-20 22:21 ---

> Sorry, but you are confusing me. I guess you mean ((ajp_msg_t *)conn->data)-
>buf
> instead of conn->data->buffer. ((ajp_msg_t *)conn->data)->buf gets allocated 
out
> of the request pool. This pool and thus the buffer remain valid for the 
livetime
> of the request. In line 212 conn->data is set to NULL. As we only use

My bad.  I didn't read the warning about the style-cleanup until too late, 
tried to fix the patch by hand, and didn't do a good job :(.  Getting a nice, 
pretty, new copy of httpd and applying the patch works very well.

> I admit it is a bandaid until we have an improved protocol. The questions are
> - Can we live with this bandaid
> - When do we get the protocol update

Well, Mladen wants to get started on mod_jk-1.3, so it seems like a good time.
> > It wouldn't be that hard 
> > to add a CMD_AJP13_FLUSH to Tomcat (with a Tomcat configuration option to 
turn 
> > it off so it doesn't freak-out mod_jk :).  But as Will says, that 
discussion 
> > belongs on [EMAIL PROTECTED]
> > 
> Yes, this belongs to [EMAIL PROTECTED] Are you willing to introduce this 
discussion to 
> [EMAIL PROTECTED] That would be very nice. On the other hand from my personal 
point of
> view I do not think that it is a good idea to extend the Tomcat connectors in
> this way without having this in a spec of an AJP protocol whatever version it
> has. This would subvert the AJP spec.

Adding [EMAIL PROTECTED] to the CC list to start a discussion :).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

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

DO NOT REPLY [Bug 37100] - SEGV in mod_proxy_ajp

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2005-10-20 23:12 ---
(In reply to comment #15)

[..cut..]

> My bad.  I didn't read the warning about the style-cleanup until too late, 
> tried to fix the patch by hand, and didn't do a good job :(.  Getting a nice, 
> pretty, new copy of httpd and applying the patch works very well.

Ok. Sounds good.

> 
> > I admit it is a bandaid until we have an improved protocol. The questions 
> > are
> > - Can we live with this bandaid
> > - When do we get the protocol update
> 
> Well, Mladen wants to get started on mod_jk-1.3, so it seems like a good time.

This is good to hear and makes hope that the protocol shortcoming will be
resolved in the near future. I will attach an improved patch in a couple of
minutes. It does not contain functional changes, but

- All code used for the bandaid is now conditional code
- I made a comment about the whole bandaid, why we are doing it and that it
  should be removed once the protocol shortcoming is fixed.
- I referenced this report in the comment

So if you would give the patch a final test, this would be great.
If I hear no problems from you about the patch and no objections from others
I will commit it tomorrow afternoon to the trunk.

[..cut..]
 
> Adding [EMAIL PROTECTED] to the CC list to start a discussion :).

Thanks for doing that.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

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

DO NOT REPLY [Bug 37100] - SEGV in mod_proxy_ajp

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #16756|0   |1
is obsolete||




--- Additional Comments From [EMAIL PROTECTED]  2005-10-20 23:14 ---
Created an attachment (id=16768)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16768&action=view)
Patch against trunk with poll bandaid as conditional code


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

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

DO NOT REPLY [Bug 37186] - blank line at start at start of tomcat-users.xml file leads to failure of UserDatabase

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2005-10-21 01:23 ---
(In reply to comment #1)

Markus, you might well be right that I broke the XML syntax by adding that 
newline char before the XML declaration.  I really don't know.  But I accept 
what you say.  I did look up some XML syntax docs on the web before posting 
the original report, but I could not find anywhere that mentioned the xml 
declaration having to begin at the first char in the file.  If you have a 
moment to point me to a webpage that describes this, I would be grateful :)

I made three separate suggestions in my original report.  You have responded 
to point 2 (thank you), but please do not mark the whole 
report "resolved,invalid" unless all 3 points are invalid.  I don't think that 
they are ;)

PS regarding my point 3, I'm not sure whether the files are re-written by the 
org.xml.sax classes or by TC classes.  If by org.xml.sax, then obviously there 
is nothing the TC team can do about it.  If not, I think this would be useful 
to fix.

Thanks!


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: Tomcat fails to service requests after period of time

[Filip Hanik - Dev lists]

try your same test case with mod_proxy, after that switch to the tomcat 
user list


Steve Gaunt wrote:


HI,

Has anyone else had any issue using mod_jk under heavy load..  

It seems after a period of time(or large no. opf requests) under heavy load AJP connetor just hangs.  It's crazy.  
All the ajp connections seem to be hanging in service mode, and the only way to recover this is to restart tomcat. I'm really stuck with this.  
Has anyone got success stories with jk2(mod)jk) under heavey load.  Around 1/2-1 million hits/day. 


Steve

	-Original Message- 
	From: Steve Gaunt 
	Sent: Wed 19/10/2005 18:51 
	To: Tomcat Developers List; Tomcat Developers List 
	Cc: 
	Subject: Tomcat fails to service requests after period of time




HI,



Please, can any one help.  I've googled but to no success.

There seems also to be a problem in mod_jk , tomcat5, the  jap 
connections build up slowly over the day.
The problem seems to be that the connection via mod_jk (Port 8009) does
not close, so the java/tomcat processes
will not quit after responding to the request (or the other way
around?). This problem occurs only in
heavy load situations. After that I see many open socket connections an
some tomcat processes that will not quit.

Has any one suffered a similar problem??

these are the worker.property settings

worker.insight.port=8009
worker.insight.type=ajp13
worker.insight.cachesize=200

# worker.insight.cache_timeout=60
# worker.insight.recycle_timeout=60
worker.insight.socket_keepalive=1
worker.insight.socket_timeout=60

# if the "retries" value is greater than three,
# there will be a pause of 100 ms between each retry
# so this would be a good value if your average response
# time is 1.7 seconds:
worker.insight.retries=20


Property for tomcat







Steve




__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__



__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__
 




No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.12.4/143 - Release Date: 10/19/2005
 




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

Re: [JK] Status -- was [VOTE] JK 1.2.15

[David Rees]

On 10/20/05, Mladen Turk <[EMAIL PROTECTED]> wrote:
>
> Seems there is low interest on JK 1.2.15 although it resolves
> lots of issues compared with released 1.2.14.1 :(
>
> Do you guys find something that would prevent 1.2.15 to
> be declared as stable that I'm missing?

I found 1.2.15 to be stable under all loads I've been able to throw at
it on Fedora Core 1 and 4, RHEL 3 and SGI IRIX.

I would give it a +1 if I were a committer.

-Dave

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

Error

[alex]

The message contains Unicode characters and has been sent as a binary 
attachment.



Norton AntiVirus Deleted1.txt
Description: plain/text
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Error

[alex]

The message contains Unicode characters and has been sent as a binary 
attachment.



Norton AntiVirus Deleted1.txt
Description: plain/text
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 37186] - blank line at start at start of tomcat-users.xml file leads to failure of UserDatabase

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2005-10-21 03:26 ---
(In reply to comment #2)
> declaration having to begin at the first char in the file.  If you have a 
> moment to point me to a webpage that describes this, I would be grateful :)

http://www.w3.org/TR/2004/REC-xml-20040204/#sec-well-formed

> I made three separate suggestions in my original report.  You have responded 
> to point 2 (thank you), but please do not mark the whole 
> report "resolved,invalid" unless all 3 points are invalid.  I don't think 
> that 
> they are ;)

As you can see, I have not changed this bug's status. Since I'm not a tomcat
commiter - I simply proposed to do so. And I simply expressed my opinion (which
is in no way "official") as I do here:
You may have made three suggestions but you made only one bug report ;-). And
that one report is either valid or not. I don't think it is.
IMO you could file your 1st suggestion (report the name of the broken file) in
an enhancement request - or change this bug's status and description 
appropriately.

> PS regarding my point 3, I'm not sure whether the files are re-written by the 
> org.xml.sax classes or by TC classes.  If by org.xml.sax, then obviously 
> there 
> is nothing the TC team can do about it.  If not, I think this would be useful 
> to fix.

This is already fixed. Add the attribute readonly="true" to the Resource element
declaring the UserDatabase:

I haven't found this documented in the changelog (may be blind) but I seem to
remember that you need some tomcat version > 5.5.9. In 5.5.12 this definitely 
works.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Tomcat 5.5.12 common/lib jars and classpath

[Brad O'Hearne]

I just configured a JAASRealm and a login module for it that authenticates 
users. I've gotten that to work just fine. But in the process I discovered 
something very strange. My loging module relies on mail.jar, the JavaMail 
API. I put my login module and its dependency jars into the common/lib 
directory to be loaded there, but I was getting NoSuchProviderException when 
trying to create a store using the "imap" protocol. I know for a fact my 
mail.jar was being loaded, because Tomcat found and executed classes 
successfully which were contained within the mail.jar. After spending hours 
with logs and API docs, I finally just put mail.jar on Tomcat's classpath, 
and it resolved the problem. Stranger still, all worked fine without putting 
mail.jar in the classpath in Tomcat 5.0.28. 

Can anyone shed light on why putting this Jar on the literal Tomcat classpath 
would have a different effect than putting jars into common/lib? I am 
guessing that this has something to do with other resources (property files 
and the like) which might be contained in the jar. The reason this is a 
concern for me, is that it leads me to believe that there's no point in 
placing jars into any of the directories governed by Tomcat's classloader 
hierarchy, but rather that I ought to place all jars on the classpath? 

Help!  I need to get to the bottom of this problem!

Brad


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

Bug in RealmBase, JAASRealm, and/or Requestt object preventing proper role authorization

[Brad O'Hearne]

All,

I have discovered a bug in role authorization when using a JAASRealm and 
custom user / role principals. In a nutshell, successful authentication in 
the JAASRealm over a custom JAAS login module results in the JAASRealm 
pulling the user principal and role principals out of the authenticated 
subject and wrapping them inside a GenericPrincipal object. The generic 
principle object is then stored in the request. Then, when permissions are 
being checked in RealmBase.hasResourcePermission(), the following line of 
code is executed to retrieve the user principal:

Principal principal = request.getUserPrincipal();

This method didn't return the wrapping generic principle, it returned my 
custom user principle. The code for the requests getUserPrincipal() method is 
as follows:

public Principal getUserPrincipal() {
if (userPrincipal instanceof GenericPrincipal) {
return ((GenericPrincipal) userPrincipal).getUserPrincipal();
} else {
return (userPrincipal);
}
}

Everything looks great so far, until you get to the logic which actually 
checks the permissions. The RealmBase.hasRole() method starts with this block 
of code (with an interesting opening comment):

// Should be overriten in JAASRealm - to avoid pretty inefficient 
conversions
if ((principal == null) || (role == null) ||
!(principal instanceof GenericPrincipal))
return (false);

When this statement executes, principal is not a GenericPrincipal, by merits 
of the request's getUserPrincipal() method executed prior to calling this 
method -- it is instead a custom user principal. This causes the third part 
of the if condition to be true, causing the method to return false, and the 
method to fail, and authorization to fail. So in other words, whenever a 
custom principal is used, role authorization should be failing, and since 
this is in RealmBase, not the JAASRealm subclass, I am assuming that anyone 
with a custom principal isn't able to authorize any roles properly. 

The quick response might be to just use a GenericPrincipal type as your custom 
principle. But this doesn't make sense either, because the hasRole method is 
seeking the roles within the GenericPrincpal object (the user principal) 
which must contain all the roles.  This is what is done by the Realm code 
already. The problem is that the hasRole method needs the GenericPrincipal 
wrapper that contains the roles, NOT the custom user principal which does not 
contain the roles. 

It would be great if I am missing something But if not, I don't know if where 
you want to consider the culprit for the bug, but it is certainly a bug, and 
it breaks authorization. Please let me know what the options are for getting 
this bug fixed, as it prevents container managed security in Tomcat using 
JAAS. 

Thanks,

Brad

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

Re: Bug in RealmBase, JAASRealm, and/or Requestt object preventing proper role authorization

[Bill Barker]

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

- Original Message - 
From: "Brad O'Hearne" <[EMAIL PROTECTED]>

To: "Tomcat Developers List" 
Sent: Thursday, October 20, 2005 8:35 PM
Subject: Bug in RealmBase, JAASRealm, and/or Requestt object preventing 
proper role authorization




All,

I have discovered a bug in role authorization when using a JAASRealm and
custom user / role principals. In a nutshell, successful authentication in
the JAASRealm over a custom JAAS login module results in the JAASRealm
pulling the user principal and role principals out of the authenticated
subject and wrapping them inside a GenericPrincipal object. The generic
principle object is then stored in the request. Then, when permissions are
being checked in RealmBase.hasResourcePermission(), the following line of
code is executed to retrieve the user principal:

   Principal principal = request.getUserPrincipal();

This method didn't return the wrapping generic principle, it returned my
custom user principle. The code for the requests getUserPrincipal() method 
is

as follows:

   public Principal getUserPrincipal() {
   if (userPrincipal instanceof GenericPrincipal) {
   return ((GenericPrincipal) userPrincipal).getUserPrincipal();
   } else {
   return (userPrincipal);
   }
   }

Everything looks great so far, until you get to the logic which actually
checks the permissions. The RealmBase.hasRole() method starts with this 
block

of code (with an interesting opening comment):

   // Should be overriten in JAASRealm - to avoid pretty inefficient
conversions
   if ((principal == null) || (role == null) ||
   !(principal instanceof GenericPrincipal))
   return (false);

When this statement executes, principal is not a GenericPrincipal, by 
merits

of the request's getUserPrincipal() method executed prior to calling this
method -- it is instead a custom user principal. This causes the third 
part
of the if condition to be true, causing the method to return false, and 
the

method to fail, and authorization to fail. So in other words, whenever a
custom principal is used, role authorization should be failing, and since
this is in RealmBase, not the JAASRealm subclass, I am assuming that 
anyone

with a custom principal isn't able to authorize any roles properly.

The quick response might be to just use a GenericPrincipal type as your 
custom
principle. But this doesn't make sense either, because the hasRole method 
is

seeking the roles within the GenericPrincpal object (the user principal)
which must contain all the roles.  This is what is done by the Realm code
already. The problem is that the hasRole method needs the GenericPrincipal
wrapper that contains the roles, NOT the custom user principal which does 
not

contain the roles.

It would be great if I am missing something But if not, I don't know if 
where
you want to consider the culprit for the bug, but it is certainly a bug, 
and
it breaks authorization. Please let me know what the options are for 
getting

this bug fixed, as it prevents container managed security in Tomcat using
JAAS.

Thanks,

Brad

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







This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication 
in error, please notify us immediately by e-mail and then delete all copies of 
this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through 
the Internet is not secure. Do not send confidential or sensitive information, 
such as social security numbers, account numbers, personal identification 
numbers and passwords, to us via ordinary (unencrypted) e-mail.


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

Re: Bug in RealmBase, JAASRealm, and/or Requestt object preventing proper role authorization

[Brad O'Hearne]

Bill,

If I am reading this right, it says the bug is fixed. When will there  
be a new release that contains this fix? (Sorry for my ignorance on  
the organization of Tomcat builds).


B

On Oct 20, 2005, at 9:15 PM, Bill Barker wrote:


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

- Original Message - From: "Brad O'Hearne"  
<[EMAIL PROTECTED]>

To: "Tomcat Developers List" 
Sent: Thursday, October 20, 2005 8:35 PM
Subject: Bug in RealmBase, JAASRealm, and/or Requestt object  
preventing proper role authorization





All,

I have discovered a bug in role authorization when using a  
JAASRealm and
custom user / role principals. In a nutshell, successful  
authentication in
the JAASRealm over a custom JAAS login module results in the  
JAASRealm
pulling the user principal and role principals out of the  
authenticated
subject and wrapping them inside a GenericPrincipal object. The  
generic
principle object is then stored in the request. Then, when  
permissions are
being checked in RealmBase.hasResourcePermission(), the following  
line of

code is executed to retrieve the user principal:

   Principal principal = request.getUserPrincipal();

This method didn't return the wrapping generic principle, it  
returned my
custom user principle. The code for the requests getUserPrincipal 
() method is

as follows:

   public Principal getUserPrincipal() {
   if (userPrincipal instanceof GenericPrincipal) {
   return ((GenericPrincipal)  
userPrincipal).getUserPrincipal();

   } else {
   return (userPrincipal);
   }
   }

Everything looks great so far, until you get to the logic which  
actually
checks the permissions. The RealmBase.hasRole() method starts with  
this block

of code (with an interesting opening comment):

   // Should be overriten in JAASRealm - to avoid pretty  
inefficient

conversions
   if ((principal == null) || (role == null) ||
   !(principal instanceof GenericPrincipal))
   return (false);

When this statement executes, principal is not a GenericPrincipal,  
by merits
of the request's getUserPrincipal() method executed prior to  
calling this
method -- it is instead a custom user principal. This causes the  
third part
of the if condition to be true, causing the method to return  
false, and the
method to fail, and authorization to fail. So in other words,  
whenever a
custom principal is used, role authorization should be failing,  
and since
this is in RealmBase, not the JAASRealm subclass, I am assuming  
that anyone

with a custom principal isn't able to authorize any roles properly.

The quick response might be to just use a GenericPrincipal type as  
your custom
principle. But this doesn't make sense either, because the hasRole  
method is
seeking the roles within the GenericPrincpal object (the user  
principal)
which must contain all the roles.  This is what is done by the  
Realm code
already. The problem is that the hasRole method needs the  
GenericPrincipal
wrapper that contains the roles, NOT the custom user principal  
which does not

contain the roles.

It would be great if I am missing something But if not, I don't  
know if where
you want to consider the culprit for the bug, but it is certainly  
a bug, and
it breaks authorization. Please let me know what the options are  
for getting
this bug fixed, as it prevents container managed security in  
Tomcat using

JAAS.

Thanks,

Brad

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







This message is intended only for the use of the person(s) listed  
above as the intended recipient(s), and may contain information  
that is PRIVILEGED and CONFIDENTIAL.  If you are not an intended  
recipient, you may not read, copy, or distribute this message or  
any attachment. If you received this communication in error, please  
notify us immediately by e-mail and then delete all copies of this  
message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail  
sent through the Internet is not secure. Do not send confidential  
or sensitive information, such as social security numbers, account  
numbers, personal identification numbers and passwords, to us via  
ordinary (unencrypted) e-mail.



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





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