DO NOT REPLY [Bug 40507] - XML validation fails when xmlValidation="true"

[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=40507





--- Additional Comments From [EMAIL PROTECTED]  2006-12-27 15:33 ---
When you enable xmlValidation="true" you also need to enable
xmlNamespaceAware="true" as well.  If these are both set to true in your
server.xml you should be able to validate correctly.  Works for me anyway.

-- 
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: r490578 - /tomcat/connectors/trunk/jk/native/common/jk_global.h

[rjung]

Author: rjung
Date: Wed Dec 27 14:25:28 2006
New Revision: 490578

URL: http://svn.apache.org/viewvc?view=rev&rev=490578
Log:
Fix global defines for Netware.
Thanks to Guenther.

Modified:
tomcat/connectors/trunk/jk/native/common/jk_global.h

Modified: tomcat/connectors/trunk/jk/native/common/jk_global.h
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_global.h?view=diff&rev=490578&r1=490577&r2=490578
==
--- tomcat/connectors/trunk/jk/native/common/jk_global.h (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_global.h Wed Dec 27 14:25:28 
2006
@@ -290,7 +290,7 @@
 typedef unsigned __int64 jk_uint64_t;
 #define JK_UINT64_T_FMT "I64u"
 #define JK_UINT64_T_HEX_FMT "I64x"
-#elif defined(AS400)
+#elif defined(AS400) || defined(NETWARE)
 typedef unsigned int jk_uint32_t;
 #define JK_UINT32_T_FMT "u"
 #define JK_UINT32_T_HEX_FMT "x"



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

DO NOT REPLY [Bug 40177] - RequestDumperValve causes getCharacterEncoding to be called

[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=40177





--- Additional Comments From [EMAIL PROTECTED]  2006-12-27 11:43 ---
Thanks Yoav.

> I think Valves are largely out-dated and should be phased out in favor
> or portable solutions where possible.

I agree with that, but even if 80% or 90% of Valves are better off as
Filters, some still aren't.  As a developer I have found many cases over the
years where I needed to write code that could not be part of a webapp, or that
had to use Tomcat's code to do something.  Sometimes (rarely, but sometimes)
the code has to run as part of Tomcat, and Valves are better documented at
this point than s are.  Since it's not a servlet, nor a Filter, we
know that it's not portable to other servlet containers.  But, if your company
has already decided to use Tomcat, this is okay.  Not much code needs to go
into a Valve, usually.  And while debugging a webapp that is already packaged,
and/or already deployed, being able to just add a line or two to server.xml
to enable, say, RequestDumperValve (which already exists in Tomcat, ready to
run) helps quite a bit because it is a quick way to investigate a bug.  This
allows us to skip compiling a Filter, installing the class file somewhere,
plus we'd have to add both a  block and a  block to
the webapp's web.xml for it.  This makes the Valve more convenient in some
situations.  I wish Tomcat came with more useful Valve tools like this one,
not less.

I realize that Valves existed first, and that Filters followed.  Tomcat could
completely drop support for Valves and stay servlet compliant, however it
would take away a useful, helpful feature of Tomcat that people do use at
times.

Thanks again.  :)


-- 
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 40220] - Order of jar loading affects packaged resources

[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=40220





--- Additional Comments From [EMAIL PROTECTED]  2006-12-27 11:04 ---
An exhaustive search within any realm seems to me like desired behaviour. So 
consider 3 different 
realms:
1. jvm
2. app-server
3. web-app

I think within every realm an exhaustive search should be performed. This way a 
realm won't have any 
'order of jar loading' issues. But when a realm boundary is crossed, so for 
instance duplicate paths to 
resources exist in the app-server realm and the web-app realm, the upper realm 
should be preferred. 
So in this case that would be the web-app realm. This seems to me both secure 
as desirable. 

So I don't think the current class loading is correct since it ignores 
resources that shouldn't, for 
whatever reason, be ignored.

-- 
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 39728] - Tomcat throws Security Exception when using signed activation.jar

[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=39728





--- Additional Comments From [EMAIL PROTECTED]  2006-12-27 10:48 ---
No I have not and I have also dropped IDM development thus am no longer using
Tomcat.

-- 
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]

Strange jasper bug (Background JSP compilation not working on Fedora?)

[Mon Cab]

I am running Tomcat 5.0.28 (with Sun JDK 1.4.2), and 5.5.20 (with Sun
JDK 1.5.0_10) on Fedora, and am experiencing bizarre behaviour in
jaspers detection/compilation of edited jsp files.  It seems that 
jasper is recompiling edited jsp's randomly (sometimes it recompiles
when a file is edited, and sometimes it doesnt).  

The Fedora box is remote and I am editing the jsp using WinSCP and
checking that the edits have taken place using PUTTY.  

I am testing from Firefox and IE6 browsers locally.  Theres no caching
at the browser (log4j is logging requests being recieved by Struts
action classes).  

I have posted this issue on the Tomcat User group, and no-one has come
across it.  I am not used to playing around with Tomcat source, but
wondered if anyone had come across this before, and if so knows what
might be going on.  




__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

DO NOT REPLY [Bug 39603] - admin application does not display contexts under host when in a Tomcat cluster

[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=39603


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|NEW




--- Additional Comments From [EMAIL PROTECTED]  2006-12-27 07:39 ---
Behavior still exists in clustered 5.5.20 -- does not need to be farm deployed,
as it turns out.  In a cluster, only the / app is revealed, while in a single
instance of tomcat, /manager and all other apps appear.

Tim
12/27/2006


-- 
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 35869] - Can't run as a service on Windows Server 2003 64-Bit Edition

[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=35869





--- Additional Comments From [EMAIL PROTECTED]  2006-12-27 06:52 ---
Yoav... take a look at bug 39327 (against the "Commons" product) for a patch 
devised by Adam Etheredge. We're using a binary, created from this patch, 
successfully in several production Intel Xeon x64-based systems on Win 2003 
Svr 64-bit edition.

-- 
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 35869] - Can't run as a service on Windows Server 2003 64-Bit Edition

[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=35869


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2006-12-27 04:28 ---
Thanks for the detailed explanations.  Would anyone care to provide an actual
patch as I requested on October 17th, 2005?

-- 
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 40177] - RequestDumperValve causes getCharacterEncoding to be called

[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=40177


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-12-27 04:26 ---
I've reluctantly un-deprecated and amended the change log as you request.

However, I mostly disagree with your statements: I think Valves are largely
out-dated and should be phased out in favor or portable solutions where
possible.  They don't exist separately because they're useful: they exist
separately because of the historical timeline in which they were developed.

-- 
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: r490487 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/valves/RequestDumperValve.java webapps/docs/changelog.xml

[yoavs]

Author: yoavs
Date: Wed Dec 27 04:26:07 2006
New Revision: 490487

URL: http://svn.apache.org/viewvc?view=rev&rev=490487
Log:
Bugzilla 40177: un-depracate RequestDumperValve.

Modified:

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/RequestDumperValve.java
tomcat/container/tc5.5.x/webapps/docs/changelog.xml

Modified: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/RequestDumperValve.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/RequestDumperValve.java?view=diff&rev=490487&r1=490486&r2=490487
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/RequestDumperValve.java
 (original)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/RequestDumperValve.java
 Wed Dec 27 04:26:07 2006
@@ -49,14 +49,13 @@
  * For a similar mechanism that is portable to all Servlet 2.4
  * containers, check out the "RequestDumperFilter" Filter in the
  * example application (the source for this filter may be found in
- * $CATALINA_HOME/webapps/examples/WEB-INF/classes/filters.
+ * $CATALINA_HOME/webapps/examples/WEB-INF/classes/filters.
  *
- * @deprecated Use the RequestDumperFilter in the examples webapp instead
  * @author Craig R. McClanahan
  * @version $Revision$ $Date$
  */
 
-public class RequestDumperValve  extends ValveBase {
+public class RequestDumperValve extends ValveBase {
 // - Instance Variables
 
 

Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?view=diff&rev=490487&r1=490486&r2=490487
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Wed Dec 27 04:26:07 2006
@@ -177,7 +177,7 @@
   
   
 40177: add more warnings to documentation about 
RequestDumperValve
-character encoding.  Deprecate this Valve in favor of 
RequestDumperFilter. (yoavs)
+character encoding.  (yoavs)
   
   
 39255: NPE in AuthenticatorBase when logging level is set 
to DEBUG



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

DO NOT REPLY [Bug 40828] - non-working jsp example jsxp svg

[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=40828


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |




--- Additional Comments From [EMAIL PROTECTED]  2006-12-27 02:36 ---
Hi Mark,

Sorry to bother you again but I really want this to work.
Did you test the jsp in IE? because it works in Firefox.
I'm using the adobe v3 (EN) svg plugin.
I tested with 2 tomcat 5.5.20 instances on 2 different win2k3 servers but on 
refresh it doesn't work.
I tested the 6.0.2 beta and it works on refresh with IE. (I tried 5 pc's and 
they all react the same way).
Please tell me what to do or what the differences are so I can alter/patch the 
5.5.20 instances.
If you need any more info than I will provide you those offcourse.
Regards,
Duncan


-- 
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 40220] - Order of jar loading affects packaged resources

[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=40220





--- Additional Comments From [EMAIL PROTECTED]  2006-12-27 02:15 ---
The issue is straight forward and understood, I've come across it before and
unfortunately dont have anything concrete to point at to indicate which
behaviour is correct.


The question that remains "Is it legal to have the same package existing in more
than one source location on the classpath ?"

If the specification is clear that all class loaders MUST perform an exhaustive
search from all source locations.  Then TCs current behaviour is wrong and needs
to be fixed.

Anything less than a "MUST" allows TC to consider current behaviour correct.


Just thinking about this issue for a moment:

 * There maybe some securiry reasons why; when one one or more artifacts of a
package are found on the classpath then it will look no more.  This might stop a
rouge application adding classes into java.util.* package and possibily picking
up wildcard security policy for java.util.*.  Especially in the case of Java Web
Start / Applets, where one source location is the local JVM and another a remote
JAR on the webserver.

 * There are also performance reasons why its not the default, if you are doing
resource lookups and keep missing (resource not found), you are forcing a
complete classpath search everytime.

 * I'd expect the behaviour of generic Java custom class loader may leave this
policy open to allow things to go either way once the lookup has been delegated
away from the system class loader (to ensure java.util.* security).


My belief is that current behaviour can be considered correct.  But if TC wanted
to it could perform an exhaustive search within the web-app realm
WEB-INF/{classes,lib} if it so wished to implement such a class loading policy.


-- 
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]

May Chun Chew/FEA/PEC is out of the office.

[May Chun Chew]

I will be out of the office starting  12/27/2006 and will not return until
12/28/2006.

Contactable at (65)97876648.


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

DO NOT REPLY [Bug 40380] - Potential syncro problem in StandardSession.expire(boolean)

[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=40380





--- Additional Comments From [EMAIL PROTECTED]  2006-12-27 01:42 ---
Just to butt in here.  

The easiest fix is to move or copy the if(expiring) inside the synchronized()
section.

Does such a large block have to be synchronized(this) {} ?  I can't see any
other code using synchronized(this) in the class (or synchronized(session) in
the package), so I guess the only thing being protected is the
if(expiring==false) { expiring=true; } test and set.


As things stand now is the StandardSession author sure there is no issue of
needing to make the JVM perform a memory write barrier ?  To ensure that
expiring=true is flushed for other threads see it immediately.  Otherwise the
JVM maybe free to optimize (and defer) this write to memory (unless you start
getting into declaring 'expiring' volatile).


Suggestion:

if (expiring)
return;

synchronized (this) {
if (expiring)
return;
if (manager == null)
return;
expiring = true;
}

// From here is no need to keep the lock AFAIKS and by closing the
synchronized() we will ensure memory write barrier.

// Towards the end of the function it sets expiring=false; I dont think the any
code in critical to seeing the expiring==false again, not once isValid==false in
anycase.

-- 
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: Smooth applications migration in a J2EE cluster [mod_jk]

[Anthony Vromant]

Hi Rainer,

I wanted to know if you had had time to think on the subject of the 
invalidated session Valve ?


Other informations that you gave us before were very useful.
Thanks a lot.

Regards,
Anthony

Anthony Vromant wrote:

Hi Rainer,

In my test case, i start only with 3 actives workers.
So i think you want me to make a graceful restart of apache in order 
to add the 3 stopped workers ?

Is this that ?
Anyhow, i understand that without changing route, this can be a good 
solution.


But about the invalidated session Valve :

If this Valve invalidates a cookie and redirects users to a login 
page, it is not transparent for the users.


Can we imagine that during an update, if this Valve is activated and 
used, mod_jk detects it (through the response sent by the valve) and 
sends the request to an active worker ?

It would be a kind of transparent fail-over implemented by mod_jk.

Regards,
Anthony

Rainer Jung wrote:

Hi Anthony,

Anthony Vromant schrieb:
 

Here is the explanation about the session validity checking :

This test aims to have users with expired sessions and URL encoded
bookmarks
(or long running browsers with cookies cached) redirected to a node
hosting the new version of the application.
If this test is not done during the update, these users will start a 
new

session on a
node hosting the old version of application (and so, perhaps just 
before

the stop of these node).
Do you agree with this ?



Ah OK, yes I agree. You could use a filter (or Valve) to redirect
requests with an invalid session to the login page without URL encoding
and invalidating the cookie. That way you would destroy the invalid
binding to this node.

If we would try to do that with mod_jk directly, mod_jk would need to
have a shadow copy of the session list, something which doesn't sound
right. OK, mod_jk could ask tomcat about the session, but we can also
simply forward and let the node delete the binding.

 

As a first simple workaround one could use two sets of workers and of
target (tomcat) nodes. One set would be stopped, on active at a time.
The two sets use different jvmRoutes. Replication is not done 
across set

boundaries.

  
When you say "2 sets of workers", you mean using the notion of 
domains ?



With sets I simply mean sets :) Somehow you configure each worker twice,
but with different names. Domains come into play, to define failover
rules between the workers. Failover should not hapen between the sets.
So each set will belong to one domain. A mod_jk domain is nothing else,
than failover information (try another worker in the same domain first,
before trying any other worker).

 
You upgrade the stopped set, test it via an internal 
connector/vhost and
then change its activation to active. Also you change the 
activation of
the formerly active set to disabled. New sessions will go to the 
updated

set, old sessions will still go to the unchanged set. Invalid sessions
will need to redirect to a start page without session information. 
After

some (depending on session use time) you stop the disabled set, to
prevent people with URL encoded bookmarks (or long running browsers 
with

cookies cached) to still reach the old version.


One of our objective is to use as much as possible mod_jk's 
capabilities.

So our prototype is based on using of these features :
- disabling a worker
- session rewriting (with a Valve)
- route modification

I've tried to pass the scenario you explain here, and i had a problem :

Here's my mod_jk (1.2.20) configuration :
worker1 : route = domain1.worker1, domain=domain1
worker2 : route = domain1.worker2, domain=domain1
worker3 : route = domain1.worker3, domain=domain1
Sticky session = true

And here's the test :
1/ Session initialization on worker1 : JSESSIONID.domain1.worker1
2/ Stop worker1
3/ Upgrade worker1
4/ Change route/domain of worker1 : route = domain2.worker1, 
domain=domain2

5/ At the same time : Active worker1 and disable worker 2 and 3
6/ Refresh on JSESSIONID.domain1.worker1
 -> The request still access on worker1

Whereas we want her to be routed to the
old version of application (so workers 2 or 3).
For the requests initialization on worker 2 or 3, it's ok.

Perhaps I missed something.



Active:
worker1a : route = worker1a, domain=domain1
worker2a : route = worker2a, domain=domain1
worker3a : route = worker3a, domain=domain1
Stopped:
worker1b : route = worker1b, domain=domain2
worker2b : route = worker2b, domain=domain2
worker3b : route = worker3b, domain=domain2
Sticky session = true

Then you would follow the above steps.

Regards,

Rainer

-
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]




--

DO NOT REPLY [Bug 40150] - Incorrect User/Role classnames are silently ignored.

[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=40150





--- Additional Comments From [EMAIL PROTECTED]  2006-12-27 00:54 ---
Created an attachment (id=19306)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19306&action=view)
Patch of JAASRealm.java (in diff format)


-- 
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]