mod_jk 1.2.14.1 Released?

2005-07-26 Thread Jess Holle

Was 1.2.14.1 ever officially released?

If not, will it be soon?

--
Jess Holle

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



Re: mod_jk 1.2.14.1 Released?

2005-07-26 Thread Jess Holle
Where are the zip/tar balls of the sources for those wishing to jump the 
gun?  [I assume they're not changing at this point...]


Jean-frederic Clere wrote:


Jess Holle wrote:


Was 1.2.14.1 ever officially released?



I have to annonce it ;-)




If not, will it be soon?

--
Jess Holle

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



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



Re: Mod_jk 1.2.14 source

2005-06-21 Thread Jess Holle

NormW wrote:


Good evening,
AFAIK there is no 1.2.14 source 'bundle', but rather it exists in 
'head', which is still with CVS rather than SVN. Check out the Jakarta 
Tomcat pages for the CVS CLI commands to get the latest mod_jk source.

Should look similar to the following:


cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login
cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic co 
jakarta-tomcat-connectors

cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic logout


Ah...  I thought this had moved to SVN like Apache itself.  CVS is still 
better supported by IDEs than SVN, so this should actually make Josh's 
task easier.


--
Jess Holle


Jess Holle wrote:


Fenlason, Josh wrote:


Where could I find the 1.2.14-dev source bundle?  Thanks. , Josh.




I'm betting you have to snag it with an SVN client.  Am I right?  If
so, is it just a simple/default latest setting to get this?

-- Jess Holle

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



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



Re: Mod_jk 1.2.14 source

2005-06-20 Thread Jess Holle

Fenlason, Josh wrote:


Where could I find the 1.2.14-dev source bundle?  Thanks.
,
Josh.

 

I'm betting you have to snag it with an SVN client.  Am I right?  If so, 
is it just a simple/default latest setting to get this?


--
Jess Holle

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



Re: Summer of code

2005-06-06 Thread Jess Holle

Out of curiosity, is a mod_jk 1.2.14 vote set to occur at some point?

Or are there known issues with 1.2.13 at this point?  [My understanding 
is that the odd-even release # model is now being followed -- correct?]


--
Jess Holle

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



Re: Tomcat/APR benchmark results

2005-04-21 Thread Jess Holle
Would we expect anything markedly different with Apache 2 worker rather 
than prefork?  This would seem a bit more of an apples-to-apples 
comparison (i.e. comparing multi-threaded low-process count servers).  
Also how many simultaneous workers (threads/processes/whatever) were 
allowewd in each case?

[I stopped using prefork on all platforms when moving to Apache 2.]
--
Jess Holle
Mladen Turk wrote:
Hi,
Here are the brief results for Tomcat HEAD:
Server   Threads Pause (ms) Error(%) Rate (req/sec)
Apache2.0.49500   1000   1.74   124.2
Http11Protocol  500   1000   0.20   139.5
Http11AprProtocol   500   1000   0.00   266.9
Tests has been run on SLES9/64-Bit/Java-1.5.0_02-b09
Client was WINXP/SP2 running JMeter and Peter Lin's test plans.
Those tests simulate 500 concurrent users connecting to a
150 maxClient server. The connection is keep-alive with
1 second delay between the requests.
So our JNI/APR http connectors is almost twice faster then
both Tomcat standard http connector and Apache2/prefork.
What is more important is that the error number is zero,
meaning there were no refused connections, because of
keepalive connection poller.
Regards,
Mladen.
-
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]


Re: Tomcat and APR

2005-04-14 Thread Jess Holle
Overall this seems well and good as long as this is not the default in 
5.5 (i.e. by default Tomcat should be pure Java and run anywhere with a 
good JVM without native code).

To play devil's advocate for a moment, however, would use of Java NIO 
potentially make more sense for Tomcat, i.e. to take a step forward in 
terms of performance, etc, without requiring native code?  [I'm not 
saying NIO covers all the bases APR would or is as fast.  Rather 
wondering whether performance efforts should not remain in the pure Java 
space until that is truly exhausted.]

--
Jess Holle
Remy Maucherat wrote:
Hi,
This has been hinted for a while ;) The purpose of this email is to
propose using APR (Apache Portable Runtime) as the network IO used by
Tomcat, instead of the JVM's IO.
This will provide the following benefits (some small, others more
significant):
- zero GC IO API (APR is not object based)
- flexible handling of socket reads/writes using pollers and non 
blocking IO
- sendfile support

Which will allow:
- better scalability when using HTTP/1.1 keepalive, by eliminating the
need for tying a thread blocked on an IO read (one or more (one on Unix,
plenty on Windows) pollers will be used instead); this will allow
certain single machine servers which couldn't use keealive in order to
limit the amount of threads (to be able to have more simultaneous users)
to benefit from the (large) performance benefits of keepalive
- better performance and easier configuration when using AJP: one
of the issues of AJP at the moment is that the number of AJP processors
in Tomcat must be equal to the number of processors on the front end
native servers, or keepalive has to be disabled (resulting in
performance degradation); the benefit for AJP seems to actually be
greater than for HTTP (special thanks to Mladen who explained to me the
situation in detail)
- efficient static file serving (not done yet)
- (likely) better performance and reliability on free JVMs
- probably slightly better performance (over NIO, Mladen measured 10%, 
while I measured 0%; as classic IO is a bit slower generally, I expect 
a small improvement); unfortunately, maximum throughput suffers 
(maximum throughput is measured by ab with keeplive enabled on 
localhost), as we cannot just block on the read until the next request 
comes; the benchmarks I use usually suck anyway ;)
- SSL support through OpenSSL (not done right now)
- access to certain useful native functions (detailed system status
information, random data generation, etc)

This would effectively make Tomcat more appealing to the lower end
servers and, hopefully, web hosting companies (due to lower resource
usage). Large sites would likely also benefit a little from the AJP
improvements.
The implementation would be an alternate endpoint implementation,
replacing PoolTcpEndpoint. Alternate HTTP/1.1 processor and socket
channel (for AJP) will be provided. Development required is actually
fairly small (significant testing will be required, however). I didn't 
do the updated socket channel yet, but after 3 days of hacking, HTTP 
works (and the AJP stuff should be much faster to do).

Now the tricky points:
- is it appropriate for 5.5 ? I'd say yes, as it will be a separate
independent implementation
- will require APR, and a small JNI friendly wrapper library
tentatively named libtcnative by Mladen (Windows binaries - and likely 
others - will be provided); portability should be good
- we'll need to improve performance (and especially fix the kludge 
that is currently used to decide if a socket should be put inside a 
poller)

Comments ?
Rémy
-
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]


Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler JDTCompiler.java

2005-04-05 Thread Jess Holle
Despite advancements in speed, etc, the notion of Eclipse or Tomcat or 
anything else using it until it is both faster *and* as robust as javac 
is a bit strange.

The notion that Eclipse depends upon it to the point that it's Java 5 
support is held up by JDT development is particularly strange to me.  
javac is not a panacea but it support Java 5 quite nicely right now.  
[I'm using NetBeans 4, so I'm unaffected by Eclipse's move -- it just 
baffles me.]

--
Jess Holle
Remy Maucherat wrote:
Tim Funk wrote:
Is there a reason _jspx_dependants is a Vector - why not an 
ArrayList? This would remove the syncs inside of Vector.

I don't know. It probably wouldn't hurt. It won't help me with my ECJ 
bug, however ;)

Rémy
-
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]


Re: [ANN] JK 1.2.10 Released

2005-04-01 Thread Jess Holle
Mladen Turk wrote:
Günter Knauf wrote:
Hi Mladen,
Also I would like to mention that I'm probably way more frustrated 
about those banana patches than you cause I reported that compiler 
bug directly to the Novell manager who was reponsible for Metrowerks 
connection years ago, I even wrote a sample to demonstrate the 
problem; and after that three more versions of the stupid compiler 
were released and they from Metrowerks werre not able to fix it

H  Metrowerks used to be good back when I used it (early PowerPC 
Mac days).

It was stricter than most compilers -- perhaps even causing some 
warnings to be errors.  I understand how this can cause issues building 
open source software, but for my own development I always appreciated 
the compiler being stricter than others -- it made porting a lot 
easier.  [I now use Java and am dismayed at what C compilers let you get 
away with.]

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


Re: [ANN] JK 1.2.10 Released

2005-03-31 Thread Jess Holle
Remy Maucherat wrote:
Linux is such a mess in large part because people who write software 
treat it as second-class - 'let someone else deal with compiling 
binaries for linux, I'll only do it for windows and mac'. As a result 
linux distributions have the freedom to mess up and 'personalize' 
each package to their own taste ( we all know how painful it is to 
switch from one distro to another or use/support 2 distros - each 
file is in a different place - this is called lock in ). On windows - 
you can get nice binaries, with installer and everything else you 
would expect - distributed by the package authors.
Even if we produce binaries, distributions will use their own. People 
also tend to use what their distribution provides.
I wish there was a way to convince distros not to do their own disparate 
things -- with Tomcat, Apache, etc, etc.  It fragments documentation, 
support, and automation of configuration, etc, and really is a pity.  It 
would be nice if everything was consistently installed in a standard 
layout and then symbolic links created into the standard layout from 
other locations as the distros saw fit -- especially if there was a 
repair script to fix these if needed.  Having the location of the 
original copies of things vary is highly annoying for anyone trying to 
communicate with those on disparate distros and platforms.

On the other hand, it seems that distros tend to feel some need to do 
things that seemingly should be common/standard differently (they're 
almost Microsoft like in that respect...) -- and people obviously use 
the path of least resistance, i.e. whatever their distro provides.

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


Re: cvs commit: jakarta-tomcat-connectors/jk/native CHANGES.txt

2005-03-24 Thread Jess Holle
[EMAIL PROTECTED] wrote:
 +Changes in JK 1.2.8
 +* cachesize has changed from unlimited to limited, so it's basically a pool of connections 
 +  with recycle timeout like in mod_proxy for Apache 2.2.
 

Is the cachesize setting for a per-worker-process pool, so the real pool 
size is (# of worker processes)*(cachesize)?

This is important to understanding how to set cachesize.  Also, I assume 
that one should keep the number of worker processes low then.  Why?  If 
one's Tomcat is throttling connections more than Apache, then one could 
end up with a very small pool in each Apache process -- possibly leading 
to this pool being exhausted far before the Apache worker process' 
threads are exhausted.  The desire is to throttle to a maximum number of 
Tomcat threads -- not throttle as a percentage of the first one or two 
Apache worker process' threads...

Am I misunderstanding something here?  [For now I have been configuring 
to have only 2 worker processes on UNIX for a little redundancy but each 
with a cachesize of 1/2 my Tomcat max threads setting.]

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


Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime JspFactoryImpl.java HttpJspBase.java

2005-03-24 Thread Jess Holle
[EMAIL PROTECTED] wrote:
remm2005/03/21 07:38:13
 Modified:jasper2/src/share/org/apache/jasper/compiler
   TagLibraryInfoImpl.java TldLocationsCache.java
   JspConfig.java JspRuntimeContext.java SmapUtil.java
   JspReader.java Compiler.java
  jasper2/src/share/org/apache/jasper
   EmbeddedServletOptions.java
  jasper2/src/share/org/apache/jasper/servlet JspServlet.java
   JspServletWrapper.java
  jasper2/src/share/org/apache/jasper/xmlparser UCSReader.java
   ParserUtils.java UTF8Reader.java
  jasper2/src/share/org/apache/jasper/runtime
   JspFactoryImpl.java HttpJspBase.java
 Log:
 - Per instance loggers in Jasper.
 

Thanks, Remmy.  I'll have to give this a try once 5.5.9 is out.  [Yes, 
I'm lazy and won't be building/patching my own before this given that 
I'm on vacation with the family.]

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


Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

2005-03-24 Thread Jess Holle
Yoav Shapira wrote:
Hola,
 

If a patch was submitted and committed, I think the name of the
submitter should be mentioned.
   

I usually put the name of the committer only in the changelog.  That seems
to be consistent with past practice.   The bugzilla issue (linked from the
changelog when possible) has the name of the submitter(s).  If they add
themselves as @authors in the code, I also leave that in.  However, if we
want to put submitter names in the changelog, I'm fine with that and will
start doing so from now on.
 

The standard practice for the Apache httpd project is to mention both 
the patch submitter and committer in the change log.

As a sometime patch submitter, I appreciate this.
--
Jess Holle


Re: Web apps vs. Logging vs. Tomcat

2005-03-19 Thread Jess Holle
Remy Maucherat wrote:
Jess Holle wrote:
Jess Holle wrote:
Okay, I did a bit more digging.
*If*:
   * Your web app contains log4j.jar *and* commons-logging.jar.
   * You do not have log4j installed in any of Tomcat's own lib
 directories.
   * You use a JNDI or other contextual classloader based
 LogRepositorySelector.
*Then*:
   * The first Tomcat web application will steal loggers from the
 Tomcat base, i.e. any that happen to be obtained while the first
 web app's contextual classloader is active.
 o In a brief, simple test, whichever web app receives the
   first JSP page request will steal the following Tomcat
   loggers:
   + org.apache.jasper.compiler.Compiler
   + org.apache.jasper.compiler.JspReader
   + org.apache.jasper.runtime.PageContextImpl
   + org.apache.jasper.servlet.JspServletWrapper
   + org.apache.jasper.xmlparser.ParserUtils
   * By steal, I mean that these loggers end up in the
 LoggerRepository of the given web app. Their configuration is thus
 controlled by it.  Also, they use the log4j library from the given
 web app.
There's nothing unexpected here: Jasper is a regular servlet, and thus 
all of its classes will be loaded with the webapp's classloader. It's 
basically like if you had the Jasper JARs inside /WEB-INF/lib. The 
problem then is that Jasper uses static logger instances, while it 
should either log to the servlet context or have per instance loggers, 
as it resides in a classloader shared across webapps. Regardless of 
what happens, we will need to cleanup Jasper's logging behavior.
What's unexpected here is as you say that these loggers are static -- or 
in any event not per-web-app.  Otherwise, this behavior would be fine 
and good!

Another completely different strategy for acquiring loggers is to use 
the CL which loaded the class (ie, to use straight delegation). 
There's the problem that it could cause classcast exceptions, however, 
and it's more annoying to configure.

Both solutions behave differently, but they have their own merits. I 
happen to prefer the context classloader oriented one in a J2EE 
environment (so it was used for the java.util.logging implementation I 
added recently based on some user submitted code that I heavily 
modfied - see http://issues.apache.org/bugzilla/show_bug.cgi?id=33143).
Yes, I now have both approaches coded and as you say both have their 
merits.  If the instances wherein Tomcat loggers configured/obtained 
from one web app are used across web apps are eliminated in Tomcat 
5.5.x, then I could happily use the JNDI/J2EE approach and all Tomcat's 
own loggers for each web app would use that web app's configuration.  
Otherwise I really have to go with the straight delegation approach to 
prevent cross-web-app logger effects.

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


Re: Web apps vs. Logging vs. Tomcat

2005-03-19 Thread Jess Holle
Remy Maucherat wrote:
I also added fixes recently so that loggers are not accessed too 
early, which was a similar issue (some loggers would be have be 
improperly associated with the container classloader). There's lots of 
tweaking needed with logging overall, it's sort of to be expected.
I'll have to check out the latest 5.5 as that's basically the other 
problem I was seeing.  Tomcat using my log4j and my log4j.properties, 
but was doing so before my first ServletContextListener was called, so I 
had not had a chance to install my LoggerRepositorySelector.  Thus these 
loggers were in my web app but not using the LoggerRepository I 
designated for my web app...

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


Re: Web apps vs. Logging vs. Tomcat

2005-03-19 Thread Jess Holle
Remy Maucherat wrote:
Here, I suppose modifying all the loggers to be like this:
private Log log = LogFactory.getLog(JspServlet.class);
would fix the issue without further problems.
Hmm...  Any chance of such a fix in the next few months.  I can search 
out such and suggest patches, but I'm quite sure you have a far greater 
degree of familiarity with the details -- I just saw the configuration 
nightmare as you aptly put it.

It's not the official J2EE way (there's no official J2EE way, as the 
default java.util.logging implementation is one global namespace 
unsuitable for containers), but it's similar to JNDI handling.
Understood.  I've already got reasonable JNDI-based approach -- assuming 
the static loggers are to be cleaned up any time in the near future.

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


Re: Web apps vs. Logging vs. Tomcat

2005-03-18 Thread Jess Holle
Remy Maucherat wrote:
BTW, JBoss (supposedly, I didn't check personally) uses 
commons-logging everywhere, and the logging implementation used is 
log4j.
That works since *everything* uses log4j.  The issue is with Tomcat 
is really one of *not* having log4j at the Tomcat level but having it 
in your web app.  This leads to:

   * whole crop of loggers using java.util.logging (fine, to be
 expected, and there are Java 5 MBeans -- albeit limited -- to
 interact with these)
   * a few core Tomcat loggers that are *not* by nature per web app
 loggers using the log4j jar and configuration of the first web app
 that uses the class enclosing them (e.g. the first web app to get
 a request!)
   * the web app's own classes using whatever you specify
It is the 2nd of these 3 bullet that is so disturbing to me.  I'd 
like to see these either have separate loggers for each web app, or 
behave like the rest the Tomcat loggers and cause a leak of data and 
references between web apps.  This -- and a reasonable set of MBeans 
to control/expose loggers seems quite doable with the approach Yoav 
and Bill laid out.  It's just unfortunate that the out-of-the-box 
behavior with web apps using log4j is so onerous.
The core loggers you talk about are probably the ones used for 
reporting your servlets/filters/etc loading errors. This seems webapp 
related to me.
Considering the classes containing these loggers are not per web app as 
best I can tell I don't believe the loggers are, but I guess more 
thorough debugging on my part is in order.  Perhaps I am mistaken and 
these are Tomcat loggers, but are specific to my web app.

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


Re: Web apps vs. Logging vs. Tomcat

2005-03-18 Thread Jess Holle
Jess Holle wrote:
Remy Maucherat wrote:
BTW, JBoss (supposedly, I didn't check personally) uses 
commons-logging everywhere, and the logging implementation used is 
log4j.
That works since *everything* uses log4j.  The issue is with Tomcat 
is really one of *not* having log4j at the Tomcat level but having 
it in your web app.  This leads to:

   * whole crop of loggers using java.util.logging (fine, to be
 expected, and there are Java 5 MBeans -- albeit limited -- to
 interact with these)
   * a few core Tomcat loggers that are *not* by nature per web app
 loggers using the log4j jar and configuration of the first web app
 that uses the class enclosing them (e.g. the first web app to get
 a request!)
   * the web app's own classes using whatever you specify
It is the 2nd of these 3 bullet that is so disturbing to me.  I'd 
like to see these either have separate loggers for each web app, or 
behave like the rest the Tomcat loggers and cause a leak of data and 
references between web apps.  This -- and a reasonable set of MBeans 
to control/expose loggers seems quite doable with the approach Yoav 
and Bill laid out.  It's just unfortunate that the out-of-the-box 
behavior with web apps using log4j is so onerous.
The core loggers you talk about are probably the ones used for 
reporting your servlets/filters/etc loading errors. This seems webapp 
related to me.
Considering the classes containing these loggers are not per web app 
as best I can tell I don't believe the loggers are, but I guess more 
thorough debugging on my part is in order.  Perhaps I am mistaken and 
these are Tomcat loggers, but are specific to my web app.
Okay, I did a bit more digging.
*If*:
   * Your web app contains log4j.jar *and* commons-logging.jar.
   * You do not have log4j installed in any of Tomcat's own lib
 directories.
   * You use a JNDI or other contextual classloader based
 LogRepositorySelector.
*Then*:
   * The first Tomcat web application will steal loggers from the
 Tomcat base, i.e. any that happen to be obtained while the first
 web app's contextual classloader is active.
 o In a brief, simple test, whichever web app receives the
   first JSP page request will steal the following Tomcat
   loggers:
   + org.apache.jasper.compiler.Compiler
   + org.apache.jasper.compiler.JspReader
   + org.apache.jasper.runtime.PageContextImpl
   + org.apache.jasper.servlet.JspServletWrapper
   + org.apache.jasper.xmlparser.ParserUtils
   * By steal, I mean that these loggers end up in the
 LoggerRepository of the given web app. Their configuration is thus
 controlled by it.  Also, they use the log4j library from the given
 web app.
I could always be mistaken, but my examination of the LoggerRepository's 
involved seems pretty conclusive.

If one has to have log4j and commons-logging in one's web app, then the 
only solution appears to be to put log4j in Tomcat and use a 
non-contextual classloader based LogRepositorySelector.  Avoiding the 
contextual classloader based LogRepositorySelector only keeps Tomcats 
loggers from sharing the web app's intended LoggerRepository -- they 
still use the web app's log4j and its default LoggerRepository.

--
Jess Holle


Re: Web apps vs. Logging vs. Tomcat

2005-03-17 Thread Jess Holle
I had e-mailed this to users mailing list, but I have what I believe is 
a more dev follow-on question:

   Is there a good way to get my own start/stop action called at a
   per-VM level?
   This is assuming I end up having to move log4j up into Tomcat's
   classloaders -- at which point I'll want to install my
   LoggerRepository controlling MBeans up at this level as well -- as
   log4j's MBeans have issues and using log4j loggers means you don't
   get the (admittedly sparse) java.util.logging MBean coverage.
--
Jess Holle
Jess Holle wrote:
I have been trying to get really serious about log4j in web apps.
I note that Tomcat (thanks to commons-logging) uses java.util.logging 
*except* for loggers created while my web app's classloader is the 
current contextual classloader -- at which point it suddenly uses 
log4j (since my web app does) without giving my web app a chance to 
initialize it in any way as best I can tell.

My web app has a ServletContextListener which initializes log4j by 
setting up its own LoggerRepository, configuration file and watcher 
(since log4j's won't shutdown), etc.  Of course, every Tomcat logger 
created within my web app up until this point is now using log4j from 
my web app (!) and using the basic log4j.properties [if present] from 
my web app -- for loggers that apply to all web apps!

How is one supposed to work this?  I am currently using a static 
LoggerRepository reference within my web app so that a log4j loaded 
higher in the classloader tree won't cause LoggerRepository sharing.  
I was using a JNDI-based LoggerRepositorySelector as per log4j author 
recommendations, but this goes a step further than above -- it puts 
all the Tomcat loggers that are errantly using my log4j into my 
LoggerRepository -- which would be fine if these loggers were not 
shared with other web apps.

What's the solution here?  Do I have to put log4j into Tomcat's lib 
directories to force it to use its own centralized log4j?  Is that the 
best solution?

--
Jess Holle



Re: Web apps vs. Logging vs. Tomcat

2005-03-17 Thread Jess Holle
P.S.  Why does Tomcat use Commons Logging rather than UGLI?
Jess Holle wrote:
I had e-mailed this to users mailing list, but I have what I believe 
is a more dev follow-on question:

   Is there a good way to get my own start/stop action called at a
   per-VM level?
   This is assuming I end up having to move log4j up into Tomcat's
   classloaders -- at which point I'll want to install my
   LoggerRepository controlling MBeans up at this level as well -- as
   log4j's MBeans have issues and using log4j loggers means you don't
   get the (admittedly sparse) java.util.logging MBean coverage.
--
Jess Holle
Jess Holle wrote:
I have been trying to get really serious about log4j in web apps.
I note that Tomcat (thanks to commons-logging) uses java.util.logging 
*except* for loggers created while my web app's classloader is the 
current contextual classloader -- at which point it suddenly uses 
log4j (since my web app does) without giving my web app a chance to 
initialize it in any way as best I can tell.

My web app has a ServletContextListener which initializes log4j by 
setting up its own LoggerRepository, configuration file and watcher 
(since log4j's won't shutdown), etc.  Of course, every Tomcat logger 
created within my web app up until this point is now using log4j from 
my web app (!) and using the basic log4j.properties [if present] from 
my web app -- for loggers that apply to all web apps!

How is one supposed to work this?  I am currently using a static 
LoggerRepository reference within my web app so that a log4j loaded 
higher in the classloader tree won't cause LoggerRepository sharing.  
I was using a JNDI-based LoggerRepositorySelector as per log4j author 
recommendations, but this goes a step further than above -- it puts 
all the Tomcat loggers that are errantly using my log4j into my 
LoggerRepository -- which would be fine if these loggers were not 
shared with other web apps.

What's the solution here?  Do I have to put log4j into Tomcat's lib 
directories to force it to use its own centralized log4j?  Is that 
the best solution?

--
Jess Holle


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


Re: Web apps vs. Logging vs. Tomcat

2005-03-17 Thread Jess Holle
Thanks.  That answers that part of the question quite succinctly.
Now what remains is how can I work with log4j and commons logging -- 
commons logging's behavior vis-a-vis the contextual classloader seems 
onerous if not just plain wrong.

The only way I can see to fix this is to deploy log4j in Tomcat's own 
lib directories -- and deploy my log4j controller MBeans there for the 
default LoggeRepository and again in each web app for each web app's 
LoggerRepository.

If that's what I need to do, I'll get on with doing it, but I'd like to 
know I'm not just overlooking the obvious...

--
Jess Holle
Yoav Shapira wrote:
UGLI is far from mature enough to be used by Tomcat at this point.  When
log4j 1.3 is out, we'll see.
Yoav
 

-Original Message-
From: Jess Holle [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 17, 2005 4:17 PM
To: Tomcat Developers List
Subject: Re: Web apps vs. Logging vs. Tomcat
P.S.  Why does Tomcat use Commons Logging rather than UGLI?
Jess Holle wrote:
   

I had e-mailed this to users mailing list, but I have what I believe
is a more dev follow-on question:
  Is there a good way to get my own start/stop action called at a
  per-VM level?
  This is assuming I end up having to move log4j up into Tomcat's
  classloaders -- at which point I'll want to install my
  LoggerRepository controlling MBeans up at this level as well -- as
  log4j's MBeans have issues and using log4j loggers means you don't
  get the (admittedly sparse) java.util.logging MBean coverage.
--
Jess Holle
Jess Holle wrote:
 

I have been trying to get really serious about log4j in web apps.
I note that Tomcat (thanks to commons-logging) uses java.util.logging
*except* for loggers created while my web app's classloader is the
current contextual classloader -- at which point it suddenly uses
log4j (since my web app does) without giving my web app a chance to
initialize it in any way as best I can tell.
My web app has a ServletContextListener which initializes log4j by
setting up its own LoggerRepository, configuration file and watcher
(since log4j's won't shutdown), etc.  Of course, every Tomcat logger
created within my web app up until this point is now using log4j from
my web app (!) and using the basic log4j.properties [if present] from
my web app -- for loggers that apply to all web apps!
How is one supposed to work this?  I am currently using a static
LoggerRepository reference within my web app so that a log4j loaded
higher in the classloader tree won't cause LoggerRepository sharing.
I was using a JNDI-based LoggerRepositorySelector as per log4j author
recommendations, but this goes a step further than above -- it puts
all the Tomcat loggers that are errantly using my log4j into my
LoggerRepository -- which would be fine if these loggers were not
shared with other web apps.
What's the solution here?  Do I have to put log4j into Tomcat's lib
directories to force it to use its own centralized log4j?  Is that
the best solution?
--
Jess Holle
   


 

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




Re: Web apps vs. Logging vs. Tomcat

2005-03-17 Thread Jess Holle
Remy Maucherat wrote:
Yoav Shapira wrote:
UGLI is far from mature enough to be used by Tomcat at this point.  When
log4j 1.3 is out, we'll see.
I already voted on that: -1.
Why out of curiosity?  I don't have a pro-UGLI ax to grind here, but 
Commons-Logging's behavior in Tomcat is really undesirable as is.

Now if you're inside JBoss and it has pre-established log4j and 
configured it prior to Tomcat loading, then I don't see a problem with 
Commons Logging.  Standalone Tomcat's Commons Logging behavior vis-a-vis 
log4j would seem to be an issue, though.  The issues are especially bad 
and bizarre when log4j is used in a web app but Tomcat itself does not 
have log4j installed, but this is only part of the issue.

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


Re: Web apps vs. Logging vs. Tomcat

2005-03-17 Thread Jess Holle
Just one more stupid question:
   How/where would I register/deregister (start/stop) MBeans at the
   Tomcat level for the Tomcat-level log4j LoggerRepository -- rather
   than in my ServletContextListener?
   For per-web-app MBeans, I can use ServletContextListener, of course,
   but given that log4j loggers are not JMX-exposed, I'd like to put
   some MBeans to do this up at the Tomcat application level.  I do
   this in my web app, but I'd like to have the Tomcat-level MBeans
   installed even without any of my web apps installed.
--
Jess Holle
Yoav Shapira wrote:
Hola,
Your approach is right and should work.  You basically have to move
everything up the classloader hierarchy into Tomcat's section, and have a
copy of the MBean stuff in each webapp classloader repository that you want
to manage.
And I agree that it sucks...
Yoav
 

-Original Message-
From: Jess Holle [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 17, 2005 4:30 PM
To: Tomcat Developers List
Subject: Re: Web apps vs. Logging vs. Tomcat
Thanks.  That answers that part of the question quite succinctly.
Now what remains is how can I work with log4j and commons logging --
commons logging's behavior vis-a-vis the contextual classloader seems
onerous if not just plain wrong.
The only way I can see to fix this is to deploy log4j in Tomcat's own
lib directories -- and deploy my log4j controller MBeans there for the
default LoggeRepository and again in each web app for each web app's
LoggerRepository.
If that's what I need to do, I'll get on with doing it, but I'd like to
know I'm not just overlooking the obvious...
--
Jess Holle
Yoav Shapira wrote:
   

UGLI is far from mature enough to be used by Tomcat at this point.  When
log4j 1.3 is out, we'll see.
Yoav
 

-Original Message-
From: Jess Holle [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 17, 2005 4:17 PM
To: Tomcat Developers List
Subject: Re: Web apps vs. Logging vs. Tomcat
P.S.  Why does Tomcat use Commons Logging rather than UGLI?
Jess Holle wrote:

   

I had e-mailed this to users mailing list, but I have what I believe
is a more dev follow-on question:
 Is there a good way to get my own start/stop action called at a
 per-VM level?
 This is assuming I end up having to move log4j up into Tomcat's
 classloaders -- at which point I'll want to install my
 LoggerRepository controlling MBeans up at this level as well -- as
 log4j's MBeans have issues and using log4j loggers means you don't
 get the (admittedly sparse) java.util.logging MBean coverage.
--
Jess Holle
Jess Holle wrote:

 

I have been trying to get really serious about log4j in web apps.
I note that Tomcat (thanks to commons-logging) uses java.util.logging
*except* for loggers created while my web app's classloader is the
current contextual classloader -- at which point it suddenly uses
log4j (since my web app does) without giving my web app a chance to
initialize it in any way as best I can tell.
My web app has a ServletContextListener which initializes log4j by
setting up its own LoggerRepository, configuration file and watcher
(since log4j's won't shutdown), etc.  Of course, every Tomcat logger
created within my web app up until this point is now using log4j from
my web app (!) and using the basic log4j.properties [if present] from
my web app -- for loggers that apply to all web apps!
How is one supposed to work this?  I am currently using a static
LoggerRepository reference within my web app so that a log4j loaded
higher in the classloader tree won't cause LoggerRepository sharing.
I was using a JNDI-based LoggerRepositorySelector as per log4j author
recommendations, but this goes a step further than above -- it puts
all the Tomcat loggers that are errantly using my log4j into my
LoggerRepository -- which would be fine if these loggers were not
shared with other web apps.
What's the solution here?  Do I have to put log4j into Tomcat's lib
directories to force it to use its own centralized log4j?  Is that
the best solution?
--
Jess Holle
   


 

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

 


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




Re: Web apps vs. Logging vs. Tomcat

2005-03-17 Thread Jess Holle
Bill Barker wrote:
- Original Message -
From: Jess Holle [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Thursday, March 17, 2005 2:25 PM
Subject: Re: Web apps vs. Logging vs. Tomcat
 

Just one more stupid question:
   How/where would I register/deregister (start/stop) MBeans at the
   Tomcat level for the Tomcat-level log4j LoggerRepository -- rather
   than in my ServletContextListener?
   

Sounds like a good use for conf/tomcat5-mbeans.xml.  It invokes the standard
Lifecycle methods (e.g. 'init', 'start', 'stop', 'destroy') of your MBeans
at the corresponding points of the Engine's Lifecycle, as well as handling
JMX registration and un-registration.
 

Cool!  Thanks!
Do I have to actually implement Lifecycle or just provide these 
methods?  Will a standard/dynamic MBean do or does it have to be a model 
MBean?  [Mine extend StandardMBean and implement MBeanRegistration at 
the moment.]

--
Jess Holle


Re: Web apps vs. Logging vs. Tomcat

2005-03-17 Thread Jess Holle
Remy Maucherat wrote:
Jess Holle wrote:
Why out of curiosity?  I don't have a pro-UGLI ax to grind here, but 
Commons-Logging's behavior in Tomcat is really undesirable as is.
It would be the same anyway: the loading configuration and the logger 
instances will be tied to the webapp classloader. It has to work this 
way. As I understand it, the thing that does not work for you right 
now is that Tomcat uses your webapp's logger namespace before your 
callbacks are called.
Yes.  The issue is really that Tomcat uses log4j out of my web app for 
loggers that are to be used outside my web app.  Not only is the library 
used out of my web app but so is the configuration -- meaning web app A 
gets core Tomcat log output from web apps B and C...

Yoav confirmed that the solution is to move log4j and a default 
configuration higher in the stack so that everything uses it.  This 
together with a per-web-app ClassLoader (but not contextual 
classloader!) based LoggerRepository will ensure each web app gets its 
own loggers and configuration files and Tomcat core gets its own.

Now if you're inside JBoss and it has pre-established log4j and 
configured it prior to Tomcat loading, then I don't see a problem 
with Commons Logging.  Standalone Tomcat's Commons Logging behavior 
vis-a-vis log4j would seem to be an issue, though.  The issues are 
especially bad and bizarre when log4j is used in a web app but Tomcat 
itself does not have log4j installed, but this is only part of the 
issue.
I don't see any real difference. There should be plenty of container 
listeners and stuff available to configure this.
(I see Bill just mentioned conf/tomcat5-mbeans.xml but I have no clue 
what it is)
The nice thing about this as I understand it is that it would allow me 
to set up my own MBeans for a Tomcat-level / app-wide log4j 
LoggerRepository.

You're right, though, as far as per-web-app MBeans and 
LoggerRepository's -- there are more than enough servlet listeners, etc, 
in the servlet spec to handle this.

BTW, JBoss (supposedly, I didn't check personally) uses 
commons-logging everywhere, and the logging implementation used is log4j.
That works since *everything* uses log4j.  The issue is with Tomcat is 
really one of *not* having log4j at the Tomcat level but having it in 
your web app.  This leads to:

   * whole crop of loggers using java.util.logging (fine, to be
 expected, and there are Java 5 MBeans -- albeit limited -- to
 interact with these)
   * a few core Tomcat loggers that are *not* by nature per web app
 loggers using the log4j jar and configuration of the first web app
 that uses the class enclosing them (e.g. the first web app to get
 a request!)
   * the web app's own classes using whatever you specify
It is the 2nd of these 3 bullet that is so disturbing to me.  I'd like 
to see these either have separate loggers for each web app, or behave 
like the rest the Tomcat loggers and cause a leak of data and references 
between web apps.  This -- and a reasonable set of MBeans to 
control/expose loggers seems quite doable with the approach Yoav and 
Bill laid out.  It's just unfortunate that the out-of-the-box behavior 
with web apps using log4j is so onerous.

--
Jess Holle


Re: Web apps vs. Logging vs. Tomcat

2005-03-17 Thread Jess Holle
Bill Barker wrote:
You just need to provide the methods (if you wanted to code against
Catalina, you'd just create a LifecycleListener :).  This is a hook into
commons-modeler, so you technically could use a plain old JavaBean.
Otherwise, DynamicMBeans probably work best (or, at least give you the most
control).
 

I have gotten used to using my own subclasses to StandardMBean.  This 
allows me to lay out the static portion of my MBean with an interface 
and extend it as necessary -- adding dynamic and open MBean behaviors as 
necessary in my own classes.

Java 1.5's APT turns out to make automated generation of MBean 
descriptions, operation parameter names, impacts, etc, from MBean 
interface Javadoc, formal parmeter names, annotations, etc, quite 
simple.  A little more elbow grease and the descriptions are localized 
(based on the server's locale).

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


StandardSession activate()/passivate() are broken

2005-02-24 Thread Jess Holle
It appears that the activate() and passivate() routines of 
StandardSession are not functioning properly.  [I've only tested 5.0.30, 
but 5.5.x seem to have identical erroneous code.]

These methods /are /called, but do not fire appropriate HttpSessionEvent 
events.  A comparison of these routines to tellNew() and expire() is 
rather telling.

I plan to rework this code along the lines of tellNew() and expire() to 
get proper functionality

--
Jess Holle


[PATCH] Re: StandardSession activate()/passivate() are broken

2005-02-24 Thread Jess Holle




Attached is a patch (against the latest 5.5.x source) that addresses
this issue.

--
Jess Holle

Jess Holle wrote:

  
It appears that the activate() and passivate() routines of
StandardSession are not functioning properly. [I've only tested
5.0.30, but 5.5.x seem to have identical erroneous code.]
  
These methods are called, but do not fire appropriate
HttpSessionEvent events. A comparison of these routines to tellNew()
and expire() is rather telling.
  
I plan to rework this code along the lines of tellNew() and expire() to
get proper functionality
  
--
Jess Holle




--- StandardSession.java-1.49   2005-02-24 10:58:20.184415700 -0600
+++ StandardSession.java2005-02-24 10:59:08.0 -0600
@@ -729,19 +729,20 @@
 public void passivate() {
 
 // Notify ActivationListeners
-HttpSessionEvent event = null;
-String keys[] = keys();
-for (int i = 0; i  keys.length; i++) {
-Object attribute = attributes.get(keys[i]);
-if (attribute instanceof HttpSessionActivationListener) {
-if (event == null)
-event = new HttpSessionEvent(getSession());
+Context context = (Context) manager.getContainer();
+Object listeners[] = context.getApplicationLifecycleListeners();
+if (listeners != null) {
+HttpSessionEvent event =
+new HttpSessionEvent(getSession());
+for (int i = 0; i  listeners.length; i++) {
+if (!(listeners[i] instanceof HttpSessionActivationListener))
+continue;
 try {
-((HttpSessionActivationListener)attribute)
+((HttpSessionActivationListener)listeners[i])
 .sessionWillPassivate(event);
 } catch (Throwable t) {
 manager.getContainer().getLogger().error
-(sm.getString(standardSession.attributeEvent), t);
+(sm.getString(standardSession.sessionEvent), t);
 }
 }
 }
@@ -756,19 +757,20 @@
 public void activate() {
 
 // Notify ActivationListeners
-HttpSessionEvent event = null;
-String keys[] = keys();
-for (int i = 0; i  keys.length; i++) {
-Object attribute = attributes.get(keys[i]);
-if (attribute instanceof HttpSessionActivationListener) {
-if (event == null)
-event = new HttpSessionEvent(getSession());
+Context context = (Context) manager.getContainer();
+Object listeners[] = context.getApplicationLifecycleListeners();
+if (listeners != null) {
+HttpSessionEvent event =
+new HttpSessionEvent(getSession());
+for (int i = 0; i  listeners.length; i++) {
+if (!(listeners[i] instanceof HttpSessionActivationListener))
+continue;
 try {
-((HttpSessionActivationListener)attribute)
+((HttpSessionActivationListener)listeners[i])
 .sessionDidActivate(event);
 } catch (Throwable t) {
 manager.getContainer().getLogger().error
-(sm.getString(standardSession.attributeEvent), t);
+(sm.getString(standardSession.sessionEvent), t);
 }
 }
 }

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

Re: [PATCH] Re: StandardSession activate()/passivate() are broken

2005-02-24 Thread Jess Holle
Also I notice that when PersistentManager is used that my 
sessionDestroyed() method is called multiple times (twice actually) 
whenever a session is being expired from store (i.e. upon removal of old 
passivated session data).

I am patching (crudely) around this for now, but I thought I'd bring 
this to everyone else's attention.

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


5.5 support for Java 5 language features in JSPs

2005-02-18 Thread Jess Holle
Is there any realistic ETA for Java 5 language feature support in Tomcat 
5.5 JSPs?

Tomcat 5.0.30 has a simple web.xml flag to note the target language version.
5.5 does too -- if you force it to use javac rather than JDT.  This is 
sounding better and better the longer Tomcat 5.5 does not bundle a JDT 
that fully supports Java 5.

I realize this is not a Tomcat issue as much as a JDT issue -- except 
that Tomcat 5.5 uses JDT by default.  I also realize scriptlets are 
considered evil -- but they, and hard requirements for Java 5 *now*, are 
a fact of life for some of us.

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


Re: Tomcat roadmap

2005-02-17 Thread Jess Holle
A related question would be when will the JDT embedded in Tomcat 5.5 
support Java 5 language compilation.

--
Jess Holle
Yoav Shapira wrote:
Hi,
Tomcat is not a full J2EE container, only a Servlet and JSP container.
Accordingly, J2EE spec releases don't matter per-se.  They only matter if
they contain new Servlet or JSP spec releases in them.
Tomcat 6 will implement the next version of the JSP and Servlet specs,
whenever those come out.
Yoav
 

-Original Message-
From: Sam Ewing [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 17, 2005 7:46 PM
To: tomcat-dev@jakarta.apache.org
Subject: Tomcat roadmap
J2EE 5.0 releases in the second half of 2005. Will
this be implemented by Tomcat 5.5 too, or will this
result ina new version - say Tomcat 6 (for Servlet
2.4/JSP 2.1?).
I was writing an article on this area, and was curious
about the roadmap..
Thanks,
Sam

__
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_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]
 




Re: Current Connector Development

2005-02-13 Thread Jess Holle
Günter Knauf wrote:
Hi Mladen,
appologies that I couldnt closely follow the connector development in the past 
year, so I'm somewhat suprised about all the recent directions; and cant 
really understand them; so I would greatly appreciate if you could do a 
summarize why you are currently again developing to mod_jk...
well, what I see is this:
after more than one year stagnation on the mod_jk2 connector we started again, 
made it comilable on all platforms, and improved it a lot, cleaned up the code 
cause we made APR mandatory, and did a release. Many users where happy with it, 
and a lot of new users came and saw 'hey, thats the new connector' and tried 
it; others migrated and found mod_jk2 faster over mod_jk.
Few time later you are not lucky with mod_jk2, and you just want to start 
another conenctor; and after some discussion you agreed to create mod_proy_ajp.
Then suddenly, just after mod_proy_ajp is just born - and I cant believe that 
it is only cause I couldnt follow up with development - I see that you state 
that mod_jk2 has come to its end cause of no developers and no users 
interest
really suprised of this all I get mail from Novell asking for help since mod_jk 
is now broken.
we have just fixed it so we could folow up with the 1.2.8 release, and you 
continue to break it ..
If I recall correctly we commonly agreed with last time's discussion that we 
stay with mod_jk _as_is_ and dont move to APR or such, and that mod_jk should 
mainly remain for our Apache 1.3.x users while Apache 2.x users should use 
mod_jk2 or also now mod_proxy_ajp - so what has changed this direction now??
Mladen, if you continue with the mod_jk development I fear that we end up the same as with mod_jk2: you will certainly break Apache 1.3.x support - at least on NetWare, and that's _very_ bad cause it's a shipping product of NetWare 6.
 

I don't see mod_jk ending up the same as mod_jk2 in that:
 1) The configuration is relatively sane as compared to that of mod_jk2
 2) There are many reasonably stable mod_jk versions, so even *if* 
Mladen screws up a release there are plenty of alternative mod_jk versions.
   * On the other hand, there never really was a stable mod_jk2 
release -- every release tested continued to exhibit serious corner case 
issues.

It would be great if everyone could move to mod_proxy_ajp, but I believe 
that still requires Apache 2.1/2.2 -- which means it has not yet arrived 
for the majority of us.

I personally applaud Mladen for his efforts to fix/improve/maintain 
mod_jk given that that is the reality for most of us.

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


ServletRequest to MBean Mapping

2005-02-10 Thread Jess Holle
Is there any way to map from a javax.servlet.ServletRequest (from within 
a filter or whatever) to the JMX data registered on this request by Tomcat?

I am trying to produce some servlet-engine independent MBeans to garner 
a certain level of data in an independent fashion but would like to be 
able to pluck out certain things from the corresponding Tomcat MBeans 
where appropriate, e.g. to jump from ServletRequest to the request 
processor to determine how many bytes are read and written by the 
request without having to try to redo all of this myself (without direct 
access to the buffers).

Ideas?
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [VOTE] Tomcat 5.5.7 Stability

2005-01-28 Thread Jess Holle
You can and have fixed CLASSPATH in the past.
Use of the JRE's lib/ext or lib/endorsed is different -- and not 
reasonably solvable, though.

--
Jess Holle
Remy Maucherat wrote:
Tim Funk wrote:
I'm going to abstain from voting since I am unable to adequately 
test. But I did find one item which could be a PITA for the folks on 
tomcat-user.

In setclasspath.sh - the CLASSPATH isn't always overridden. If the 
user tries to start tomcat with an existing CLASSPATH  - that is 
appended to the bootstrap classpath. You can only guess that wacky 
errors I saw after startup with my legacy 3+ year old CLASSPATH.

I committed the change to setclasspath.sh to fix this.
While this issue is definitely not a blocker, it might cause a lot of 
frustration for the many users who keep their CLASSPATH enironment 
variable set.

Well, JARs in system extensions is an equally common and very similar 
issue, from what I've seen (where the user has an old servlet.jar in 
the booclasspath, for example). We can't fix that one.

Rémy
-
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]


Re: [VOTE] JK 1.2.8 Stability

2005-01-07 Thread Jess Holle
I'm not a commiter, but...
I tried with our app on Windows (didn't get time for Solaris and AIX 
yet) and it worked just fine.

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


Tomcat monitoring

2005-01-05 Thread Jess Holle
I'd like to be able to monitor the maximum requests active (within a 
connector thread pool) that are used at any time (and reset this maximum).

I'd like to be able to monitor the backlog (ala acceptCount) at a given 
point in time and the maximum to date (and reset this maximum).

[I already noticed the ability to monitor the currentThreadsBusy in 
ThreadPool.]

Am I (hopefully) overlooking this in the existing MBean stack?  Or are 
these candidates for addition?

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


Re: [VOTE] JK 1.2.8 Stability

2005-01-04 Thread Jess Holle
For those of us lurking waiting for the outcome of this vote, it would 
seem to be extraordinarily slow

That's not to say I don't appreciate the freely given time of those 
involved or the time they're taking to evaluate 1.2.8.

On the other hand, it would be very good to bring this to some closure.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: JDBCStore Downgrade (Tomcat4 vs. Tomcat 5)

2004-12-29 Thread Jess Holle
Tom Anderson wrote:
TOMCAT 5

I have discovered that the checkInterval values are no longer used 
(despite what the documentation says) and are instead replaced by the 
backgroundProcessorDelay value in the Container class.   This means 
that I now only have one value to set for the equivalent of the 2 
checkInterval values we had in Tomcat 4.   I suspect that this was 
done to decrease the number of threads necessary which seems like a 
noble goal.   But the downside is that I now am forced to run my 
JDBCStore.processExpires() much more often than I'd like (15 times 
more often in my case) which is a hardship on the database.
This seems like something to look into -- at least in 5.5.x where this 
has changed yet again, but the controlling parameters are less clear there.

Furthermore, in Tomcat 4 JDBCStore overrode StoreBase.processExpires() 
to only select older sessions from the database something like this:
SELECT id FROM tomcat_sessions
WHERE app = '/Standalone/localhost/acme' AND 1104288671296  
(lastaccess + maxinactive*1000)))
Please see my recent (rejected) patches in this regard.  The final 
versions (after some discussion) were against 5.5.x, but previous 
versions were against 5.0.30.  I could send you 5.0.30 patches as well.

Remy was unmoved in the end -- and I don't blame him entirely as my 
patches have not yet undergone the stress testing they need due to a 
backlog in the group responsible for such things.  Also my patches were 
on 3 fronts (and thus one might say were all over the map...) -- 
eliminating possible race conditions, passivating sessions on an LRU 
basis, and improving JDBCStore and FileStore behavior in processExpires().

Thus in the end my patches did not go in.
This was a good thing because each session is loaded into memory 
before deciding whether or not to expire it, so you don't want to load 
every Stored session if possible.   In my case we often have tens of 
thousands of sessions in Store so loading all those older sessions 
every 60 seconds is quite a hardship, especially when combined with 
the fact that it is running 15 times as often!
Agreed!  I think the 5.0.30 FileStore and JDBCStore implementations are 
extraordinarily silly in this regard!

Please see my patches to StoreBase, FileStore, and JDBCStore in this regard.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: PersistentManagerBase (etc) Patches

2004-12-17 Thread Jess Holle
Remy Maucherat wrote:
Jess Holle wrote:
[Yes, the Request change would still be necessary to prevent the 
chance of requests randomly getting their sessions passivated and 
recycle after they findSession() but before access().]
A session can be passivated at any (bad) time (which will screw up 
requests), and we already do plenty of on access checks. I don't see 
what it adds.
A session must not be passivated at just *any* bad time -- that's part 
of what I'm fixing.

For the case where one has many valid sessions, many of which are 
passivated due to a maximum active sessions constraint, there is likely 
to be some level of thrashing such that it is entirely too likely that a 
session which has only been idle for a short while is getting passivated 
between the findSession() and the access() call.  This will result in an 
otherwise fine request going horribly wrong from a user's perspective 
(assuming the state data in the session was at all critical).

If Request is left as is, then it user's will inappropriately get new 
sessions in such cases.  If it is changed without the preAccess() 
addition, the user will get an invalidated session instead.

As I said, the patch ideas look fine, but I do have questions:
- Why do you really need methods named preAccess and access on the 
manager ? The first one seems to be designed to do swap ins while the 
second one keeps usage stats, so maybe this could be more elegant. Or 
maybe not.
The attached patch has some clarifying comments.
preAccess() is intended to fix the race condition case.  It should 
rarely do more than check isValid and return, but without it user 
requests can go awry for no reason as they see it.

access() move the accessed session to the front of the LinkedHashMap 
thereby maintaining sorting.  The attached patch also uses this sorting 
to reduce the overhead of processMaxIdleSwaps() by breaking from the 
loop as newer sessions are encountered.  [Yes, I know this may mean some 
old sessions are not passivated when a session access on a very old 
session occurs between findSessions() and this check, but that's better 
than running through all sessions every processing interval.  
processMaxIdleSwaps() should be a best reasonable effort.]

- Keeping session skeletons around will eat resources. I understand 
this will improve performance, but is that really a good idea ? I'm 
asking for your experience after the change here (is memory usage much 
higher, etc). 
I am working all of this on 2 fronts here: trying to get an acceptable 
patch together, incorporate any feedback, etc, and get this tested 
against real world scenarios where we're having issues.

Our issue involves various web apps that keep large amounts of session 
data for all users -- and a corresponding inability to scale beyond a 
few users.  I am certain all of these changes put together will not 
suffice to totally fix this problem -- and efforts to improve the web 
apps are therefore also planned.

I'll certainly provide feedback (and further patches if/where 
appropriate) as I gain more real world experience with this approach.

--
Jess Holle
Index: PersistentManagerBase.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java,v
retrieving revision 1.25
diff -u -r1.25 PersistentManagerBase.java
--- PersistentManagerBase.java  22 Nov 2004 16:35:18 -  1.25
+++ PersistentManagerBase.java  17 Dec 2004 15:41:30 -
@@ -20,6 +20,11 @@
 import java.beans.PropertyChangeEvent;
 import java.beans.PropertyChangeListener;
 import java.io.IOException;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.Comparator;
+import java.util.LinkedHashMap;
+import java.util.Map;
 import java.security.AccessController;
 import java.security.PrivilegedActionException;
 import java.security.PrivilegedExceptionAction;
@@ -204,17 +209,44 @@
 protected long processingTime = 0;
 
 
-// - Properties
+/**
+ * Whether session should be synchronously swapped out immediately upon
+ * exceeding maxActiveSessions.  Defaults to 'false'.
+ */
+protected boolean immediateSwapOnMaxActiveExceeded = false;
+
+
+// - 
Constructors
+
+
+public PersistentManagerBase() {
+sessions = new LinkedHashMap() {
+protected boolean removeEldestEntry(Map.Entry eldest) {
+if ( immediateSwapOnMaxActiveExceeded ) {
+  int  maxActiveSessions = getMaxActiveSessions();
+  if ( maxActiveSessions = 0 )
+  if ( size()  maxActiveSessions )
+  if ( isStarted() )
+  // try to swap out oldest entry; if entry is 
still too fresh then processMaxActiveSwaps() will swap out

Re: PersistentManagerBase (etc) Patches

2004-12-16 Thread Jess Holle
Remy Maucherat wrote:
Jess Holle wrote:
And finally, here are the patches against 5.5.6 (same as HEAD at this 
moment in this case).
Ok, but I still dislike the patch ;)
I'd appreciate comments as to what's wrong with the patch :-)
I am clearly new to this area of Tomcat, but there were clear issues in 
this area of the code that I cannot ignore if I am to depend on 
PersistentManager.

Primary issues encountered were:
   * Race condition previous noted by FIXME.
 o There were no guarantees that a session would not be
   serialized to disk, passivated, and recyled while it was
   being used.
 o There were variations on this. I fixed the more obvious ones
   by the admittedly unfortunately synchronization on access()
   and around use of swapOut() in conjunction with checks on
   accessCount.  The less obvious case required a change
   access(), Request, etc, to allow an already referenced (but
   not accessed) session which has been swapped out (and thus
   recycled) to be swapped back in within access() as
   necessary/appropriate.
   * Lack of any sort of LRU prioritization to what is passivated when
 the maximum number of active sessions has been exceeded.
 o I replaced usage of HashMap with LinkedHashMap in
   PersistentManagerBase (only).
   * Extremely inefficient behavior when trying to expire passivated
 sessions.
 o All passivated sessions were fully deserialized back into
   memory to check if they were stale upon each and every
   processExpires() execution.  For large numbers of large
   sessions (the whole reason you'd bother with passivation!),
   this will be a large drain on performance.
 o My changes make the modification time more accessible in
   FileStore and make more efficient staleness checks in both
   FileStore and JDBCStore.
Additionally there was a discrepancy between lastAccessedTime and 
thisAccessedTime usage in normal isValid(), etc, and the behavior of 
PersistentManagerBase, etc

In all of these cases I may have misunderstood something or overlooked 
more optimal solutions.  I would like to see all of these issues 
addressed in the best fashion possible -- and if possible in the 
standard distribution of Tomcat rather than just in ours.  I am thus 
more than open to suggestions for improvement.  The issue is that right 
now there are clear, unaddressed issues which I believe I have at least 
improved upon though certainly not perfected.

--
Jess Holle
P.S.  I assumed Manager, etc, interfaces should not be extended, hence 
my introduction of some new methods at ManagerBase and my instanceof 
checks.  This may have been a bad assumption, but this can easily be 
amended as needed.



Re: PersistentManagerBase (etc) Patches

2004-12-16 Thread Jess Holle
Remy Maucherat wrote:
Jess Holle wrote:
It is not useful without the rest of the changes as without the rest 
of the changes there are intolerable race conditions.
Right. I suppose that's the end of the discussion then, it would be a 
waste of time to continue. -1 for your patch.

If you really feel insecure, then you could try adding volatile to the 
accessCount field, but it's really useless.
Volatility of accessCount is a minor (though perhaps additionally 
necessary) part.

The bigger issues are that:
   * During a request, between getSession(sessionId) and
 session.access() the session could be passivated and recycled --
 thus lousing up that request.
   * A truly long request (e.g. a streaming dynamic content response)
 can be ongoing and have its session passivated and recycled while
 it is still ongoing -- recycling the session object it already has
 access to.
As I recall there were other race condition possibilities, but these by 
themselves were too problematic to let alone.

If anyone is actually able to get any robust value out of 
PersistentManager as it is, then I believe my changes to the passivated 
session expiration algorithm are a good thing.  I just don't see how the 
whole thing is supposed to really hold water with known race conditions 
(including a FIXME noting them...)

--
Jess Holle


Re: PersistentManagerBase (etc) Patches

2004-12-16 Thread Jess Holle
Remy Maucherat wrote:
Jess Holle wrote:
Where have I faked robustness?  I will not claim I actually achieve 
it, but I certainly tried, fixed real race condition cases, and don't 
know of ones I missed.
The only race condition that I can possibly imagine is on accessCount, 
which I think is something quite unimportant (if you think it is, add 
volatile which will solve the problem). We don't care about the 
exactitude of lastAccessedTime in this case (or you need to tell me 
why we care).
The only race condition after my fix or before it?
I will admit that I added complexity to base classes to support more 
robust operation of special purpose classes for session passivation.  
I loathed doing this, but did not see a good way to avoid this.  As I 
recall if there was a single factory method for creating Session 
objects, then I could have just subclasses StandardSession and done 
everything in more derived classes -- leaving ManagerBase alone.  I'd 
like that much better.  Unfortunately, a static analyzer showed other 
usages of StandardSession's constructors.  If I am in error on this, 
I'd be more than happy to rectify this!
Right, and next time there's an issue, we'll add postAccess, I 
suppose. This is not workable.
I'll put code correctness over code maintainability any day -- but 
that's just me.  Clearly you try to balance both.

[The change to Request is necessary in any case I can see, however -- 
unless a much higher level, and thus more expensive, synchronization 
is done between normal session access and passivation.]
You need to relax a little about this kind of issues. The rest of your 
patch seems like a good start overall :)
So you're proposing excising the preAccess() stuff?  Or what exactly?
I'd happily put most of the patch into the standard distribution and 
maintain the rest on my own if appropriate.  That would lessen the 
maintenance burden on me and hopefully provide some benefit to everyone 
else.

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


Re: PersistentManagerBase (etc) Patches

2004-12-16 Thread Jess Holle
On further analysis it seems that StandardSession is only constructed by 
ManagerBase and indirectly from SimpleTcpReplicationManager via the 
ReplicatedSession subclass.

Given that SimpleTcpReplicationManager is mutually exclusive of 
PersistentManager, it would appear I should move my StandardSession 
changes into a new PersistentSession class and move my ManagerBase 
changes into PersistentManagerBase.

Which portions of my changes woulud be objectionable in this case?  
[Yes, the Request change would still be necessary to prevent the chance 
of requests randomly getting their sessions passivated and recycle after 
they findSession() but before access().]

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


Re: PersistentManagerBase (etc) Patches

2004-12-16 Thread Jess Holle
Attached are a new PersistentManagerBase patch and a new 
PersistentSession class.  Together these eliminate the need for the 
changes to ManagerBase and StandardSession (but not to Request, but this 
change is an innocuous reordering of a couple of lines of code).

I've not had a chance to test these, but this would appear to keep 
almost all substantive effects out of the base classes and limit them to 
the session passivation classes which need these changes.  I also 
managed to eliminate the need for the endAccess() override (which was 
really a workaround for the unbalanced endAccess() call in swapIn() -- 
though other unbalanced calls might benefit from some debug code in 
endAccess() as well...).

--
Jess Holle
Jess Holle wrote:
On further analysis it seems that StandardSession is only constructed 
by ManagerBase and indirectly from SimpleTcpReplicationManager via the 
ReplicatedSession subclass.

Given that SimpleTcpReplicationManager is mutually exclusive of 
PersistentManager, it would appear I should move my StandardSession 
changes into a new PersistentSession class and move my ManagerBase 
changes into PersistentManagerBase.

Which portions of my changes woulud be objectionable in this case?  
[Yes, the Request change would still be necessary to prevent the 
chance of requests randomly getting their sessions passivated and 
recycle after they findSession() but before access().]

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

Index: PersistentManagerBase.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java,v
retrieving revision 1.25
diff -u -r1.25 PersistentManagerBase.java
--- PersistentManagerBase.java  22 Nov 2004 16:35:18 -  1.25
+++ PersistentManagerBase.java  17 Dec 2004 05:53:42 -
@@ -20,6 +20,11 @@
 import java.beans.PropertyChangeEvent;
 import java.beans.PropertyChangeListener;
 import java.io.IOException;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.Comparator;
+import java.util.LinkedHashMap;
+import java.util.Map;
 import java.security.AccessController;
 import java.security.PrivilegedActionException;
 import java.security.PrivilegedExceptionAction;
@@ -204,17 +209,44 @@
 protected long processingTime = 0;
 
 
-// - Properties
+/**
+ * Whether session should be synchronously swapped out immediately upon
+ * exceeding maxActiveSessions.  Defaults to 'false'.
+ */
+protected boolean immediateSwapOnMaxActiveExceeded = false;
+
+
+// - 
Constructors
+
+
+public PersistentManagerBase() {
+sessions = new LinkedHashMap() {
+protected boolean removeEldestEntry(Map.Entry eldest) {
+if ( immediateSwapOnMaxActiveExceeded ) {
+  int  maxActiveSessions = getMaxActiveSessions();
+  if ( maxActiveSessions = 0 )
+  if ( size()  maxActiveSessions )
+  if ( isStarted() )
+  // try to swap out oldest entry; if entry is 
still too fresh then processMaxActiveSwaps() will swap out sessions when 
possible in the background
+  swapOutSessionIfOldEnough( (StandardSession) 
eldest.getValue(), System.currentTimeMillis(), minIdleSwap, 
persistentManager.swapTooManyActive );
+}
+return ( false );
+}
+};
+}
 
 
-  
+// - Properties
+
+
+
 
 
 /**
-* Indicates how many seconds old a session can get, after its last use 
in a
-* request, before it should be backed up to the store. -1 means 
sessions
-* are not backed up.
-*/
+ * Indicates how many seconds old a session can get, after its last use in 
a
+ * request, before it should be backed up to the store. -1 means sessions
+ * are not backed up.
+ */
 public int getMaxIdleBackup() {
 
 return maxIdleBackup;
@@ -314,13 +346,13 @@
 
 
 /**
-* Set the Container with which this Manager has been associated. If it 
is a
-* Context (the usual case), listen for changes to the session timeout
-* property.
-* 
-* @param container
-*The associated Container
-*/
+ * Set the Container with which this Manager has been associated. If it is 
a
+ * Context (the usual case), listen for changes to the session timeout
+ * property.
+ * 
+ * @param container
+ *The associated Container
+ */
 public void setContainer(Container container

Re: PersistentManagerBase (etc) Patches

2004-12-16 Thread Jess Holle
And finally, here are the patches against 5.5.6 (same as HEAD at this 
moment in this case).

--
Jess Holle
Jess Holle wrote:
Here's the patches against 5.5.4
Jess Holle wrote:
For those who tried finding through the patches only to find that 
they did not properly map against CVS (as I just used 'diff -u' in a 
directory not in a proper CVS tool...), please see the attached patch 
files against 5.0.30 (which were donoe with a proper CVS tool).

I have reworked this for 5.5.4 as well, but there are a number of 
changes between 5.5.4 and 5.5.6 in these same files.  I thus plan to 
merge up to 5.5.6 before passing these patches along.  If anyone is 
desparately interested in the 5.5.4 stuff now, let me know.

Overall, I do believe these are a substantial improvement over the 
current code, so I'd appreciate it if someone reviewed them a bit -- 
especially the 5.5.6 versions as it would be good to see this merged 
in to 5.5.x at least.

--
Jess Holle
Jess Holle wrote:
A week or two ago I found I had need of the persistent session 
manager, PersistentManagerBase -- and also noticed its experimental 
status.

Looking at the sources I found FIXME comments regarding: (1) a 
race condition between session passivation and session usage and (2) 
a lack of LRU sorting to passivate oldest sessions first.  I also 
discovered that all passivated sessions are regularly (every minuted 
by default) read back into memory in their entirety to check if they 
should be expired.

The attached set of patches is intended to address all of these 
issues -- and seems to do so to the best of my (admittedly limited) 
testing.

There are additional fixes that should be made to JDBCStore (i.e. in 
general it seems to a trip to the database for every row in many 
cases where 1 per 'n' would suffice), but this was of less interest 
to me for the time being than FileStore, so I have not pursued 
these.  Also, I introduced a new attribute to PersistentManagerBase, 
but have not yet exposed it via JMX.  This is intentional at this 
point as I am uncertain as to the merits of the non-default value of 
this operation as of yet.

Comments and questions are welcome.  All of the patches are against 
5.0.30, but I could update them for 5.5.x if there was sufficient 
interest (e.g. if a committer was interested in committing them).

--
Jess Holle
[EMAIL PROTECTED] 


Index: Request.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Request.java,v
retrieving revision 1.18
diff -u -r1.18 Request.java
--- Request.java20 Nov 2004 21:10:47 -  1.18
+++ Request.java16 Dec 2004 17:47:20 -
@@ -2178,11 +2178,11 @@
 } catch (IOException e) {
 session = null;
 }
-if ((session != null)  !session.isValid())
-session = null;
 if (session != null) {
 session.access();
-return (session);
+if (session.isValid())  // check isValid() *after* access()!
+return (session);
+session = null;
 }
 }
 
Index: JDBCStore.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/JDBCStore.java,v
retrieving revision 1.12
diff -u -r1.12 JDBCStore.java
--- JDBCStore.java  2 Nov 2004 20:05:12 -   1.12
+++ JDBCStore.java  16 Dec 2004 17:47:20 -
@@ -151,6 +151,11 @@
 protected PreparedStatement preparedKeysSql = null;
 
 /**
+ * Variable to hold the codekeysThatMayBeExpired()/code prepared 
statement.
+ */
+protected PreparedStatement preparedKeysThatMayBeExpiredSql = null;
+
+/**
  * Variable to hold the codesave()/code prepared statement.
  */
 protected PreparedStatement preparedSaveSql = null;
@@ -456,7 +461,7 @@
 + sessionTable +  WHERE  + sessionAppCol
 +  = ?;
 preparedKeysSql = _conn.prepareStatement(keysSql);
-   }
+}
 
 preparedKeysSql.setString(1, getName());
 rst = preparedKeysSql.executeQuery();
@@ -491,6 +496,66 @@
 return (keys);
 }
 
+protected String[] keysThatMayBeExpired()
+throws IOException
+{
+int maxInactiveInterval = ((ManagerBase)manager).maxInactiveInterval;
+if ( maxInactiveInterval  0 )
+return new String[0];
+
+ResultSet rst = null;
+String keys[] = null;
+synchronized (this) {
+int numberOfTries = 2;
+while (numberOfTries  0) {
+
+Connection _conn = getConnection();
+if (_conn == null) {
+return (new String[0

Re: PersistentManagerBase (etc) Patches

2004-12-16 Thread Jess Holle
Jess Holle wrote:
Remy Maucherat wrote:
Jess Holle wrote:
And finally, here are the patches against 5.5.6 (same as HEAD at 
this moment in this case).
Ok, but I still dislike the patch ;)
I'd appreciate comments as to what's wrong with the patch :-)
Sorry I missed your previous comments somehow.  I've included them below:
I don't like the foundation on which the patch stands, unfortunately.

I did not get a warm fuzzy this is rock solid stuff feeling about this 
myself...

That said, if there are problems with the foundation, then let's rework 
it.  In the end, I did not see too much glaringly awful about the approach.

I unfortunately need session passivation, so if necessary I'll have just 
keep this in my own distribution if that's what it takes.  I am guessing 
I'm not the *only* one in this boat, so it would be good to work this out...

I also don't quite see the real-world usefulness of some of the new 
features, for example the date usage sorting.

If you have a limit on the maximum active sessions and many more 
sessions than this (when non-expired, passivated sessions are included) 
then it makes sense to have a fairly aggressive minimum idle time prior 
to passivation but to ensure that the oldest non-passivated session will 
be passivated first so as to avoid thrashing between active and passive 
states where it is not necessary.

In particular, all the proposed changes to the base classes (std 
session, manager base, request), which seem to be designed to add 
fake robustness to the mix, and add more complexity. I don't think 
any of these changes bring anything useful, but they do decrease 
performance and maintainability.

Where have I faked robustness?  I will not claim I actually achieve 
it, but I certainly tried, fixed real race condition cases, and don't 
know of ones I missed.

I will admit that I added complexity to base classes to support more 
robust operation of special purpose classes for session passivation.  I 
loathed doing this, but did not see a good way to avoid this.  As I 
recall if there was a single factory method for creating Session 
objects, then I could have just subclasses StandardSession and done 
everything in more derived classes -- leaving ManagerBase alone.  I'd 
like that much better.  Unfortunately, a static analyzer showed other 
usages of StandardSession's constructors.  If I am in error on this, I'd 
be more than happy to rectify this!

All the same the changes to the base classes are fairly minimally 
obtrusive.  If they cannot be avoided, then they seem worth living with 
for some of us to have session passivation...

[The change to Request is necessary in any case I can see, however -- 
unless a much higher level, and thus more expensive, synchronization is 
done between normal session access and passivation.]

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


Re: PersistentManagerBase (etc) Patches

2004-12-16 Thread Jess Holle
Remy Maucherat wrote:
Jess Holle wrote:
Remy Maucherat wrote:
I'd appreciate comments as to what's wrong with the patch :-)
I am clearly new to this area of Tomcat, but there were clear issues 
in this area of the code that I cannot ignore if I am to depend on 
PersistentManager.

   * Extremely inefficient behavior when trying to expire passivated
 sessions.
 o All passivated sessions were fully deserialized back into
   memory to check if they were stale upon each and every
   processExpires() execution.  For large numbers of large
   sessions (the whole reason you'd bother with passivation!),
   this will be a large drain on performance.
 o My changes make the modification time more accessible in
   FileStore and make more efficient staleness checks in both
   FileStore and JDBCStore.
This seems useful.
It is not useful without the rest of the changes as without the rest of 
the changes there are intolerable race conditions.

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


Re: PersistentManagerBase (etc) Patches

2004-12-15 Thread Jess Holle
For those who tried finding through the patches only to find that they 
did not properly map against CVS (as I just used 'diff -u' in a 
directory not in a proper CVS tool...), please see the attached patch 
files against 5.0.30 (which were donoe with a proper CVS tool).

I have reworked this for 5.5.4 as well, but there are a number of 
changes between 5.5.4 and 5.5.6 in these same files.  I thus plan to 
merge up to 5.5.6 before passing these patches along.  If anyone is 
desparately interested in the 5.5.4 stuff now, let me know.

Overall, I do believe these are a substantial improvement over the 
current code, so I'd appreciate it if someone reviewed them a bit -- 
especially the 5.5.6 versions as it would be good to see this merged in 
to 5.5.x at least.

--
Jess Holle
Jess Holle wrote:
A week or two ago I found I had need of the persistent session 
manager, PersistentManagerBase -- and also noticed its experimental 
status.

Looking at the sources I found FIXME comments regarding: (1) a race 
condition between session passivation and session usage and (2) a lack 
of LRU sorting to passivate oldest sessions first.  I also discovered 
that all passivated sessions are regularly (every minuted by default) 
read back into memory in their entirety to check if they should be 
expired.

The attached set of patches is intended to address all of these issues 
-- and seems to do so to the best of my (admittedly limited) testing.

There are additional fixes that should be made to JDBCStore (i.e. in 
general it seems to a trip to the database for every row in many cases 
where 1 per 'n' would suffice), but this was of less interest to me 
for the time being than FileStore, so I have not pursued these.  Also, 
I introduced a new attribute to PersistentManagerBase, but have not 
yet exposed it via JMX.  This is intentional at this point as I am 
uncertain as to the merits of the non-default value of this operation 
as of yet.

Comments and questions are welcome.  All of the patches are against 
5.0.30, but I could update them for 5.5.x if there was sufficient 
interest (e.g. if a committer was interested in committing them).

--
Jess Holle
[EMAIL PROTECTED] 

Index: StoreBase.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StoreBase.java,v
retrieving revision 1.8
diff -b -u -r1.8 StoreBase.java
--- StoreBase.java  22 May 2004 23:23:23 -  1.8
+++ StoreBase.java  15 Dec 2004 18:35:35 -
@@ -204,7 +204,7 @@
 }
 
 try {
-keys = keys();
+keys = keysThatMayBeExpired();
 } catch (IOException e) {
 log (e.toString());
 e.printStackTrace();
@@ -213,13 +213,10 @@
 
 for (int i = 0; i  keys.length; i++) {
 try {
-StandardSession session = (StandardSession) load(keys[i]);
+StandardSession session = (StandardSession) 
loadSessionIfShouldBeExpired(keys[i]);
 if (session == null) {
 continue;
 }
-if (session.isValid()) {
-continue;
-}
 if ( ( (PersistentManagerBase) manager).isLoaded( keys[i] )) {
 // recycle old backup session
 session.recycle();
@@ -240,6 +237,33 @@
 }
 }
 
+protected String[] keysThatMayBeExpired()
+throws IOException
+{
+return ( keys() );
+}
+
+protected StandardSession loadSessionIfShouldBeExpired( String sessionId )
+{
+StandardSession session;
+try
+{
+session = (StandardSession) load(sessionId);
+}
+catch ( ClassNotFoundException e )
+{
+session = null;
+}
+catch ( IOException e )
+{
+session = null;
+}
+if ( session != null )
+if (session.isValid())
+return ( null );
+return ( session );
+}
+
 /**
  * Log a message on the Logger associated with our Container (if any).
  *
Index: PersistentManagerBase.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java,v
retrieving revision 1.19.2.1
diff -b -u -r1.19.2.1 PersistentManagerBase.java
--- PersistentManagerBase.java  18 Nov 2004 22:13:36 -  1.19.2.1
+++ PersistentManagerBase.java  15 Dec 2004 18:35:36 -
@@ -20,6 +20,11 @@
 import java.beans.PropertyChangeEvent;
 import java.beans.PropertyChangeListener;
 import java.io.IOException;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.Comparator;
+import java.util.LinkedHashMap;
+import java.util.Map;
 import java.security.AccessController;
 import java.security.PrivilegedActionException

Re: PersistentManagerBase (etc) Patches

2004-12-15 Thread Jess Holle
Here's the patches against 5.5.4
Jess Holle wrote:
For those who tried finding through the patches only to find that they 
did not properly map against CVS (as I just used 'diff -u' in a 
directory not in a proper CVS tool...), please see the attached patch 
files against 5.0.30 (which were donoe with a proper CVS tool).

I have reworked this for 5.5.4 as well, but there are a number of 
changes between 5.5.4 and 5.5.6 in these same files.  I thus plan to 
merge up to 5.5.6 before passing these patches along.  If anyone is 
desparately interested in the 5.5.4 stuff now, let me know.

Overall, I do believe these are a substantial improvement over the 
current code, so I'd appreciate it if someone reviewed them a bit -- 
especially the 5.5.6 versions as it would be good to see this merged 
in to 5.5.x at least.

--
Jess Holle
Jess Holle wrote:
A week or two ago I found I had need of the persistent session 
manager, PersistentManagerBase -- and also noticed its experimental 
status.

Looking at the sources I found FIXME comments regarding: (1) a race 
condition between session passivation and session usage and (2) a 
lack of LRU sorting to passivate oldest sessions first.  I also 
discovered that all passivated sessions are regularly (every minuted 
by default) read back into memory in their entirety to check if they 
should be expired.

The attached set of patches is intended to address all of these 
issues -- and seems to do so to the best of my (admittedly limited) 
testing.

There are additional fixes that should be made to JDBCStore (i.e. in 
general it seems to a trip to the database for every row in many 
cases where 1 per 'n' would suffice), but this was of less interest 
to me for the time being than FileStore, so I have not pursued 
these.  Also, I introduced a new attribute to PersistentManagerBase, 
but have not yet exposed it via JMX.  This is intentional at this 
point as I am uncertain as to the merits of the non-default value of 
this operation as of yet.

Comments and questions are welcome.  All of the patches are against 
5.0.30, but I could update them for 5.5.x if there was sufficient 
interest (e.g. if a committer was interested in committing them).

--
Jess Holle
[EMAIL PROTECTED] 


Index: Request.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Request.java,v
retrieving revision 1.16
diff -u -r1.16 Request.java
--- Request.java26 Oct 2004 15:42:05 -  1.16
+++ Request.java15 Dec 2004 20:26:16 -
@@ -2173,11 +2173,11 @@
 } catch (IOException e) {
 session = null;
 }
-if ((session != null)  !session.isValid())
-session = null;
 if (session != null) {
 session.access();
-return (session);
+if (session.isValid())  // check isValid() *after* access()!
+return (session);
+session = null;
 }
 }
 
Index: FileStore.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/FileStore.java,v
retrieving revision 1.5
diff -u -r1.5 FileStore.java
--- FileStore.java  23 Jun 2004 13:51:36 -  1.5
+++ FileStore.java  15 Dec 2004 20:26:48 -
@@ -209,8 +209,14 @@
 if (file == null) {
 return (new String[0]);
 }
+
 String files[] = file.list();
 
+// Bugzilla 32130
+if((files == null) || (files.length  1)) {
+return (new String[0]);
+}
+
 // Build and return the list of session identifiers
 ArrayList list = new ArrayList();
 int n = FILE_EXT.length();
@@ -367,8 +373,31 @@
 oos.close();
 }
 
+// give file modification date to match last session access time
+if ( !file.setLastModified( 
((StandardSession)session).thisAccessedTime ) )
+   if (manager.getContainer().getLogger().isDebugEnabled())
+   manager.getContainer().getLogger().debug(Could not set 
last modified date on file store for  + session.getId() );
+
 }
 
+// use file modification date to check if we should bother loading session
+protected StandardSession loadSessionIfShouldBeExpired( String sessionId )
+{
+File file = file(sessionId);
+if (file != null) {
+long sessionAccessTime = file.lastModified();
+if ( sessionAccessTime  0 ) {
+int  maxInactiveInterval = 
((ManagerBase)manager).maxInactiveInterval;
+if ( maxInactiveInterval = 0 ) { 
+long timeNow = System.currentTimeMillis();
+int timeIdle = (int) ((timeNow - sessionAccessTime) / 
1000L);
+if (timeIdle = maxInactiveInterval

PersistentManagerBase (etc) Patches

2004-12-13 Thread Jess Holle
A week or two ago I found I had need of the persistent session manager, 
PersistentManagerBase -- and also noticed its experimental status.

Looking at the sources I found FIXME comments regarding: (1) a race 
condition between session passivation and session usage and (2) a lack 
of LRU sorting to passivate oldest sessions first.  I also discovered 
that all passivated sessions are regularly (every minuted by default) 
read back into memory in their entirety to check if they should be expired.

The attached set of patches is intended to address all of these issues 
-- and seems to do so to the best of my (admittedly limited) testing.

There are additional fixes that should be made to JDBCStore (i.e. in 
general it seems to a trip to the database for every row in many cases 
where 1 per 'n' would suffice), but this was of less interest to me for 
the time being than FileStore, so I have not pursued these.  Also, I 
introduced a new attribute to PersistentManagerBase, but have not yet 
exposed it via JMX.  This is intentional at this point as I am uncertain 
as to the merits of the non-default value of this operation as of yet.

Comments and questions are welcome.  All of the patches are against 
5.0.30, but I could update them for 5.5.x if there was sufficient 
interest (e.g. if a committer was interested in committing them).

--
Jess Holle
[EMAIL PROTECTED]
--- StandardSession-5.0.30.java 2004-12-13 21:28:06.0 -0600
+++ StandardSession.java2004-12-13 21:28:04.0 -0600
@@ -593,7 +593,14 @@
  * should be called by the context when a request comes in for a particular
  * session, even if the application does not reference it.
  */
-public void access() {
+public synchronized void access() {
+
+ManagerBase  managerBase = ( ( manager instanceof ManagerBase ) ? 
(ManagerBase) manager : null );
+if ( managerBase != null )
+managerBase.preAccess( this );
+
+if ( !isValid || expiring )
+  return;
 
 this.lastAccessedTime = this.thisAccessedTime;
 this.thisAccessedTime = System.currentTimeMillis();
@@ -601,7 +608,10 @@
 evaluateIfValid();
 
 accessCount++;
-
+
+if ( isValid )
+if ( managerBase != null )
+managerBase.access( this );
 }
 
 
@@ -611,11 +621,12 @@
 public void endAccess() {
 
 isNew = false;
-accessCount--;
-
+if ( accessCount  0 )
+--accessCount;
+else if ( debug  0 )
+log( Session  + getId() +  accessCount [ + ( accessCount - 1 ) 
+ ]  0  );  // show access count as it would be if we had decremented
 }
 
-
 /**
  * Add a session event listener to this component.
  */
@@ -790,6 +801,20 @@
 
 }
 
+/**
+ * Copy all non-transient fields other than id from 'otherSession' to
+ * this session.
+ */
+protected void copyFieldsOf( StandardSession otherSession )
+{
+  this.attributes = (HashMap) otherSession.attributes.clone();
+  this.creationTime = otherSession.creationTime ;
+  this.lastAccessedTime = otherSession.lastAccessedTime;
+  this.maxInactiveInterval = otherSession.maxInactiveInterval;
+  this.isNew = otherSession.isNew;
+  this.isValid = otherSession.isValid;
+  this.thisAccessedTime = otherSession.thisAccessedTime;
+}
 
 /**
  * Release all object references, and initialize instance variables, in
@@ -802,7 +827,7 @@
 setAuthType(null);
 creationTime = 0L;
 expiring = false;
-id = null;
+// id = null;
 lastAccessedTime = 0L;
 maxInactiveInterval = -1;
 accessCount = 0;
@@ -810,7 +835,7 @@
 setPrincipal(null);
 isNew = false;
 isValid = false;
-manager = null;
+// manager = null;
 
 }
 
--- StoreBase-5.0.30.java   2004-12-13 21:29:12.0 -0600
+++ StoreBase.java  2004-12-13 21:29:08.0 -0600
@@ -204,7 +204,7 @@
 }
 
 try {
-keys = keys();
+keys = keysThatMayBeExpired();
 } catch (IOException e) {
 log (e.toString());
 e.printStackTrace();
@@ -213,13 +213,10 @@
 
 for (int i = 0; i  keys.length; i++) {
 try {
-StandardSession session = (StandardSession) load(keys[i]);
+StandardSession session = (StandardSession) 
loadSessionIfShouldBeExpired(keys[i]);
 if (session == null) {
 continue;
 }
-if (session.isValid()) {
-continue;
-}
 if ( ( (PersistentManagerBase) manager).isLoaded( keys[i] )) {
 // recycle old backup session
 session.recycle();
@@ -239,7 +236,34 @@
 }
 }
 }
+
+protected String[] keysThatMayBeExpired()
+throws IOException

FIXMEs in PersistentManagerBase

2004-12-08 Thread Jess Holle
I have dire need to use PersistentManager, which is experimental at this 
time.

Looking in the source, I note 2 FIXME comments -- one of which seems 
to clearly indicate a race condition.  It actually occurs twice (though 
the comment only occurs once) but the code in both cases looks similar to:

   // Swap out all sessions idle longer than maxIdleSwap
   // FIXME: What's preventing us from mangling a session during
   // a request?
   if (maxIdleSwap = 0) {
   for (int i = 0; i  sessions.length; i++) {
   StandardSession session = (StandardSession) sessions[i];
   if (!session.isValid())
   continue;
   int timeIdle = // Truncate, do not round up
   (int) ((timeNow - session.getLastAccessedTime())
   / 1000L);
   if (timeIdle  maxIdleSwap  timeIdle  minIdleSwap) {
   if (log.isDebugEnabled())
   log.debug(sm.getString
   (persistentManager.swapMaxIdle,
session.getId(), new Integer(timeIdle)));
   try {
   swapOut(session);
   } catch (IOException e) {
   ;   // This is logged in writeSession()
   }
   }
   }
   }
Does anyone have any brilliant ideas/suggestions on how this condition 
should be resolved?  I'm digging around, but my experience with all of 
the pieces involved is rather limited.

--
Jess Holle


Re: FIXMEs in PersistentManagerBase

2004-12-08 Thread Jess Holle
Just a shot in the dark here, but what if:
  1. We synchronize on 'session' for the bulk of the 'for' loop.
  2. We make StandardSession.access() synchronized
 * I'd really like to avoid (2), but I don't see a really good
   alternative.
  3. We fix the other FIXME regarding LRU by creating a treemap sorting
 by access time and then just walk over values().
 * I'd really like to actually just keep a doubly linked list
   in the manager and bump sessions to the front of this in
   StandardSession, but I'm not sure if doing this in access()
   would suffice.
Suggestion would be appreciated!
--
Jess Holle
Jess Holle wrote:
I have dire need to use PersistentManager, which is experimental at 
this time.

Looking in the source, I note 2 FIXME comments -- one of which seems 
to clearly indicate a race condition.  It actually occurs twice 
(though the comment only occurs once) but the code in both cases looks 
similar to:

// Swap out all sessions idle longer than maxIdleSwap
// FIXME: What's preventing us from mangling a session during
// a request?
if (maxIdleSwap = 0) {
for (int i = 0; i  sessions.length; i++) {
StandardSession session = (StandardSession)
sessions[i];
if (!session.isValid())
continue;
int timeIdle = // Truncate, do not round up
(int) ((timeNow -
session.getLastAccessedTime()) / 1000L);
if (timeIdle  maxIdleSwap  timeIdle 
minIdleSwap) {
if (log.isDebugEnabled())
log.debug(sm.getString
(persistentManager.swapMaxIdle,
 session.getId(), new Integer(timeIdle)));
try {
swapOut(session);
} catch (IOException e) {
;   // This is logged in writeSession()
}
}
}
}
Does anyone have any brilliant ideas/suggestions on how this condition 
should be resolved?  I'm digging around, but my experience with all of 
the pieces involved is rather limited.

--
Jess Holle



Re: Tagging JK1_2_27_BETA_2 today 18:00 GMT

2004-12-07 Thread Jess Holle
After no more betas are in order is the plan to release a stable 1.2.7 
or to bump the version up to 1.2.8 at that point?

[Sorry for the question but I seem to recall both possibilities being 
uttered previously.]

--
Jess Holle
P.S. Thanks to all for all the hard work on JK 1.2.7, especially Mladen :-)
Mladen Turk wrote:
Hi,
I'll tag JK1_2_27_BETA_2 later today and release as beta 2.
IMO this will be the latest beta release for 1.2.7. if no
serious bugs found.
Regards,
Mladen.
-
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]


Custom HttpSession passivation?

2004-12-03 Thread Jess Holle
I have a need to passivate HttpSessions on a more aggressive basis than 
that of timing them out.

Default behavior is to time out a sessions after 30 minutes of 
inactivity -- which is fine.

Rather I need to be able to passivate sessions to disk after say 10-15 
minutes or rather passivate all but the last 'n' (e.g. 200) to disk -- 
re-activating these if/when necessary (i.e. when a request comes in for 
the given session).

Am I missing a configuration option for such behavior in Tomcat?  [Is 
this something SunONE or WebSphere add on top of the base code they 
share with Tomcat?]

If not, do APIs exist for:
   * Passivation of individual sessions, i.e. serializing them to disk,
 calling the right listeners, etc?
   * Activation of individual sessions, i.e. re-storing them from disk,
 cleaning files from disk as appropriate, calling the right
 listeners, etc?
 o Is this done automatically on attempts to access the session
   in question?
I'm using Tomcat 5.0.30 and 4.1.24, though I could limit things to 
5.0.30 if that helps.  [I could /possibly/ even pursue 5.5.x if that 
helps enough, but there are significant obstacles to us pursuing this 
direction at this time.]

Any/all pointers in this regard would be appreciated.
Thanks for your time.
--
Jess Holle
[EMAIL PROTECTED]


Re: Custom HttpSession passivation?

2004-12-03 Thread Jess Holle
Remy Maucherat wrote:
Jess Holle wrote:
I have a need to passivate HttpSessions on a more aggressive basis 
than that of timing them out.

Default behavior is to time out a sessions after 30 minutes of 
inactivity -- which is fine.

Rather I need to be able to passivate sessions to disk after say 
10-15 minutes or rather passivate all but the last 'n' (e.g. 200) to 
disk -- re-activating these if/when necessary (i.e. when a request 
comes in for the given session).

Am I missing a configuration option for such behavior in Tomcat?  [Is 
this something SunONE or WebSphere add on top of the base code they 
share with Tomcat?]

If not, do APIs exist for:
   * Passivation of individual sessions, i.e. serializing them to disk,
 calling the right listeners, etc?
   * Activation of individual sessions, i.e. re-storing them from disk,
 cleaning files from disk as appropriate, calling the right
 listeners, etc?
 o Is this done automatically on attempts to access the session
   in question?
I'm using Tomcat 5.0.30 and 4.1.24, though I could limit things to 
5.0.30 if that helps.  [I could /possibly/ even pursue 5.5.x if that 
helps enough, but there are significant obstacles to us pursuing this 
direction at this time.] 
This is the purpose of the persistent manager, which supports a number 
of backends (JDBC and file, at the moment).
Can you give me a brief summary of what is and is not there?  For 
instance, I assume from your answer that there is no simple 
configuration of passivate after 15 minutes and auto-reactivate as 
needed, true?  Is the auto-reactivate there?

These may be stupid questions -- can you give a little more detailed 
pointer, i.e. full class names and/or important method and pointers any 
existing docs beyond Javadoc?

I can root around given the info given so far as well -- but a brief 
high-level overview as to what's there already and where to begin would 
be very helpful.

Note: We won't be accepting any contributions in this area for 4.1, 
and for 5.0, it is unlikely too.
Thanks for the note.  Did this area change much between 4.1 and 5.0?  If 
not, then I could consider doing something against 5.0 and porting to 
5.5 as a contribution.  If this area changed significantly, then I may 
need to consider whether I can just do this once against 5.5 rather 
having to do this against 5.0 and then rework it for 5.5.

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


Re: Custom HttpSession passivation?

2004-12-03 Thread Jess Holle
Remy Maucherat wrote:
It's called persistent manager, and it's the same place as the 
standard manager, in the session package.
There's even docs: 
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/manager.html
Thanks for the pointer!
It appears to have what I need/want except for one feature, though I'd 
like to confirm this.

Is maxActiveSessions the maximum number of sessions at one time?  Or is 
it rather the maximum number which have not been passivated allowed at 
one time?

If it is the latter, then I don't see any gaps between what I need and 
what is already there!  [Unless you see any from the brief description 
I've given...]

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


Re: Custom HttpSession passivation?

2004-12-03 Thread Jess Holle
Remy Maucherat wrote:
Jess Holle wrote:
Remy Maucherat wrote:
It's called persistent manager, and it's the same place as the 
standard manager, in the session package.
There's even docs: 
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/manager.html
Thanks for the pointer!
It appears to have what I need/want except for one feature, though 
I'd like to confirm this.

Is maxActiveSessions the maximum number of sessions at one time?  Or 
is it rather the maximum number which have not been passivated 
allowed at one time?
If maxActiveSessions is reached, it will (at the moment) refuse the 
creation of a new one (like for the StandardManager).
To be really clear does is reached mean there are 'maxActiveSessions' 
*active* (non-passivated) sessions?  Or does it mean there are 
'maxActiveSessions' sessions which have not been invalidated and/or 
destroyed?

[We need the former -- badly enough to add it ourselves if necessary.]
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Custom HttpSession passivation?

2004-12-03 Thread Jess Holle
Jess Holle wrote:
Remy Maucherat wrote:
Jess Holle wrote:
Remy Maucherat wrote:
It's called persistent manager, and it's the same place as the 
standard manager, in the session package.
There's even docs: 
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/manager.html
Thanks for the pointer!
It appears to have what I need/want except for one feature, though 
I'd like to confirm this.

Is maxActiveSessions the maximum number of sessions at one time?  Or 
is it rather the maximum number which have not been passivated 
allowed at one time?
If maxActiveSessions is reached, it will (at the moment) refuse the 
creation of a new one (like for the StandardManager).
To be really clear does is reached mean there are 
'maxActiveSessions' *active* (non-passivated) sessions?  Or does it 
mean there are 'maxActiveSessions' sessions which have not been 
invalidated and/or destroyed?
Sorry for the dumb question.  The docs are ambiguous but the code is not.
[The meaning is the former -- and I so happy, assuming this works.]
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Multiple Tomcat Instance Question

2004-11-09 Thread Jess Holle
I have been experimenting with embedding Tomcat except embedding the 
full normal distribution via Bootstrap rather than fiddling with the 
embedded distribution.  A few questions arise from this:

  1. When using multiple Tomcats, e.g. with CATALINA_BASE, etc, does
 one always need separate 'work' directories?
 * With a huge web app with 1000's of JSPs, it is a bit
   obnoxious to have 'n' copies of all of this.  Yes, I could
   pre-populate this via precompilation and copying, but this
   still consumes a lot of disk.
 * If I could share one 'work' directory across all instances,
   would I then have to disable all further JSP compilation to
   avoid multi-process race conditions, or is this all handled?
  2. Are there any guides out there on how to do this sort of embedding?
 * I'm pretty familiar with server.xml, web.xml, etc, etc, and
   the CATALINA_BASE approach with a full deployment seems
   simple enough -- but I'm unsure what I well known/documented
   alternatives I might be missing.
One note on CATALINA_BASE:
   Without a $CATALINA_BASEE/webapps directory any Context XML files
   defining web apps in conf/** seem to be silently ignored.  I don't
   have anything I want to place in the webapps directory, though. 
   This may be a side-effect of me continuing to use the out-of-the-box
   server.xml to this point, which references 'webapps', but it took me
   some time to discover.

Related note on 5.5.x and Context bearing .xml files:
   These now have to have the same name as the web app (at least in
   5.5.3), whereas one used to be able to name them anything at all and
   just change the web app name in the Context element.  Not a big
   deal, but a surprising change.  [I actually ended up using jconsole
   to visually diff between a working Tomcat instance of an older
   version and 5.5.3.]
--
Jess Holle


Questions on mod_jk, session affinity, etc

2004-11-09 Thread Jess Holle
For cases where the session data is too large and/or volatile to 
replicate without a performance penalty and where session affinity is 
thus required, is there any hope/possibility/interest of trying to 
balance the number of active sessions per Tomcat instance (i.e. sending 
new requests to the instance with the fewest active sessions)?

Or is there any possibility of transfering a session from one Tomcat 
instance to another when one gets overloaded -- rather than continually 
replicating every change to the session across all instances?  [This 
would seem to require changes to Tomcat and mod_jk/mod_proxy_ajp, right?]

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


Re: Newest JK commits

2004-11-08 Thread Jess Holle
Mladen Turk wrote:
Hi all,
I've done some JK commits that I've been testing for a long time.
The major addition is socket timeout that was missing, causing
couple of minutes delays on some platforms if tomcat was down.
Also I've back ported the load balance algorithm from proxy_balancer,
that actually does what it should.
For example the A:lb_factor=5 and B:lb_factor=1 will now give five
times more requests to host A.
I have also changed one very misleading directive (socket_timeout)
to recycle_timeout. The socket_timeout directive is now what it
should be (the timeout for the socket), while the recycle_timeout is
the inactive socket timeout.
Have you updated the docs for the lb_factor and socket_timeout changes?
I have also revert Jean-Frederic's latest map_free changes (by mistake).
Further more IMO we should prefix all public functions using jk_.
That's about it.
I have tested all patches on unix and win32. What I'd like to see is
if I broke something on AIX (Henry ?) and Netware (Norm, Guenter?)
Cheers,
MLaden.

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


Re: Newest JK commits

2004-11-08 Thread Jess Holle
Mladen Turk wrote:
Jess Holle wrote:
Mladen Turk wrote:
I've done some JK commits that I've been testing for a long time.
Have you updated the docs for the lb_factor and socket_timeout changes?
That's the thing I'm planing for the all next week.
I would like to rewrite the entire JK docs using Tomcat's
style and build process.
Also we should make clear what we are going to support
(making JK2 as unsupported), advertising new mod_proxy and proxy_ajp,
etc.
Style is well and good, but the clarity around JK2, etc, is priceless!
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: tomcat 5.5.4 does not start when a single webapp fails

2004-11-01 Thread Jess Holle
Remy Maucherat wrote:
Martin Grotzke wrote:
The Filter includes one statement:
System.setProperty( javax.xml.parsers.DocumentBuilderFactory,
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl );
the webapp contains xerces-1.4.4 in WEB-INF/lib, this jar includes
org/apache/xerces/jaxp/DocumentBuilderFactoryImpl.class.
but the part that's not a tomcat-internals issue does not have to be
discussed here, probably the tomcat-user-list is a better place for
this...
Without a security manager, any application can set system properties, 
which are global. So here the JAXP settings will be changed for the 
whole system, which will produce random results (since only your 
webapp has visibility on the Xerces class) :(
There are clearly better ways to influence JAXP than this...
If there are no other META-INF services entries for document builders in 
the class loader prior to the web app's (which I believe is the case in 
5.5), then just having your Xerces (which should have such a META-INF 
entry) in your web app should suffice.

But honestly, Xerces 1.4.4!?!  That's positively ancient.
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: 5.0.29 JSP compilation fails when using JDK 1.5.0

2004-10-19 Thread Jess Holle
I accidentally got Windows end-of-line sequences in the last set of 
patches.  Here's a better set.

--
Jess Holle
Jess Holle wrote:
Okay, I now (belatedly) understand the problem.
The issue is that by default Jaspper is setting the target release to 
1.3 but leaving the source release unspecified -- resulting in the JDK 
1.5 javac default source release, 1.5 -- and javac won't allow this 
mixture.

I am attaching a set of patches that (1) defaults the source release 
to 1.3 as well and (2) allows this to be controlled in a completely 
independent and analogous manner to target release.

I would appreciate seeing this in 5.0.30 :-)
--
Jess Holle

--- Options.java-5.0.29 2004-10-19 09:56:58.0 -0500
+++ Options.java2004-10-19 09:57:00.0 -0500
@@ -117,11 +117,16 @@
 public String getCompiler();
 
 /**
- * Compiler target VM, e.g. 1.1,1.2,1.3, or 1.4.
+ * Compiler target VM, e.g. 1.1, 1.2, 1.3, 1.4, or 1.5.
  */
 public String getCompilerTargetVM();
 
 /**
+ * Compiler source VM, e.g. 1.3, 1.4, or 1.5.
+ */
+public String getCompilerSourceVM();
+
+/**
  * The cache for the location of the TLD's
  * for the various tag libraries 'exposed'
  * by the web application.
--- Compiler.java-5.0.292004-10-19 09:56:54.0 -0500
+++ Compiler.java   2004-10-19 09:57:08.0 -0500
@@ -386,6 +386,11 @@
 info.append(   compilerTargetVM= + options.getCompilerTargetVM() + 
\n);
 }
 
+if (options.getCompilerSourceVM() != null) {
+javac.setSource(options.getCompilerSourceVM());
+info.append(   compilerSourceVM= + options.getCompilerSourceVM() + 
\n);
+}
+
 // Build includes path
 PatternSet.NameEntry includes = javac.createInclude();
 
--- EmbeddedServletOptions.java-5.0.29  2004-10-19 09:57:12.0 -0500
+++ EmbeddedServletOptions.java 2004-10-19 09:57:06.0 -0500
@@ -144,6 +144,11 @@
 private String compilerTargetVM = 1.3;
 
 /**
+ * The compiler source VM (1.3 by default).
+ */
+private String compilerSourceVM = 1.3;
+
+/**
  * Cache for the TLD locations
  */
 private TldLocationsCache tldLocationsCache = null;
@@ -303,6 +308,14 @@
 return compilerTargetVM;
 }
 
+/**
+ * @see Options#getCompilerSourceVM
+ */
+public String getCompilerSourceVM()
+{
+  return compilerSourceVM;
+}
+
 public boolean getErrorOnUseBeanInvalidClassAttribute() {
 return errorOnUseBeanInvalidClassAttribute;
 }
@@ -571,6 +584,11 @@
 this.compilerTargetVM = compilerTargetVM;
 }
 
+String compilerSourceVM = config.getInitParameter(compilerSourceVM);
+if(compilerSourceVM != null) {
+this.compilerSourceVM = compilerSourceVM;
+}
+
 String javaEncoding = config.getInitParameter(javaEncoding);
 if (javaEncoding != null) {
 this.javaEncoding = javaEncoding;
--- JspC.java-5.0.292004-10-19 09:57:10.0 -0500
+++ JspC.java   2004-10-19 09:57:02.0 -0500
@@ -98,6 +98,8 @@
 private static final String SWITCH_CLASS_NAME = -c;
 private static final String SWITCH_FULL_STOP = --;
 private static final String SWITCH_COMPILE = -compile;
+private static final String SWITCH_SOURCE = -source;
+private static final String SWITCH_TARGET = -target;
 private static final String SWITCH_URI_BASE = -uribase;
 private static final String SWITCH_URI_ROOT = -uriroot;
 private static final String SWITCH_FILE_WEBAPP = -webapp;
@@ -145,6 +147,7 @@
 
 private String compiler = null;
 private String compilerTargetVM = 1.3;
+private String compilerSourceVM = 1.3;
 
 private boolean classDebugInfo = true;
 private Vector extensions;
@@ -276,6 +279,10 @@
 }
 } else if (tok.equals(SWITCH_ENCODING)) {
 setJavaEncoding(nextArg());
+} else if (tok.equals(SWITCH_SOURCE)) {
+setCompilerSourceVM(nextArg());
+} else if (tok.equals(SWITCH_TARGET)) {
+setCompilerTargetVM(nextArg());
 } else {
 if (tok.startsWith(-)) {
 throw new JasperException(Unrecognized option:  + tok +
@@ -479,6 +486,22 @@
 compilerTargetVM = vm;
 }
 
+/**
+ * @see Options#getCompilerSourceVM.
+ */
+public String  getCompilerSourceVM()
+{
+  return compilerSourceVM;
+}
+
+/**
+ * @see Options#getCompilerSourceVM.
+ */
+public void  setCompilerSourceVM( String vm )
+{
+  compilerSourceVM = vm;
+}
+
 public TldLocationsCache getTldLocationsCache() {
 return tldLocationsCache;
 }
@@ -1156,5 +1179,4 @@
 // pass straight through
 }
 }
-
 }

-
To unsubscribe, e

Re: 5.0.29 JSP compilation fails when using JDK 1.5.0

2004-10-18 Thread Jess Holle
Okay, I now (belatedly) understand the problem.
The issue is that by default Jaspper is setting the target release to 
1.3 but leaving the source release unspecified -- resulting in the JDK 
1.5 javac default source release, 1.5 -- and javac won't allow this mixture.

I am attaching a set of patches that (1) defaults the source release to 
1.3 as well and (2) allows this to be controlled in a completely 
independent and analogous manner to target release.

I would appreciate seeing this in 5.0.30 :-)
--
Jess Holle
--- JspC.java   2004-10-05 13:30:36.0 -0500
+++ JspC.java-new   2004-10-18 15:11:30.851472700 -0500
@@ -98,6 +98,8 @@
 private static final String SWITCH_CLASS_NAME = -c;
 private static final String SWITCH_FULL_STOP = --;
 private static final String SWITCH_COMPILE = -compile;
+private static final String SWITCH_SOURCE = -source;
+private static final String SWITCH_TARGET = -target;
 private static final String SWITCH_URI_BASE = -uribase;
 private static final String SWITCH_URI_ROOT = -uriroot;
 private static final String SWITCH_FILE_WEBAPP = -webapp;
@@ -145,6 +147,7 @@
 
 private String compiler = null;
 private String compilerTargetVM = 1.3;
+private String compilerSourceVM = 1.3;
 
 private boolean classDebugInfo = true;
 private Vector extensions;
@@ -276,6 +279,10 @@
 }
 } else if (tok.equals(SWITCH_ENCODING)) {
 setJavaEncoding(nextArg());
+} else if (tok.equals(SWITCH_SOURCE)) {
+setCompilerSourceVM(nextArg());
+} else if (tok.equals(SWITCH_TARGET)) {
+setCompilerTargetVM(nextArg());
 } else {
 if (tok.startsWith(-)) {
 throw new JasperException(Unrecognized option:  + tok +
@@ -479,6 +486,22 @@
 compilerTargetVM = vm;
 }
 
+/**
+ * @see Options#getCompilerSourceVM.
+ */
+public String  getCompilerSourceVM()
+{
+  return compilerSourceVM;
+}
+
+/**
+ * @see Options#getCompilerSourceVM.
+ */
+public void  setCompilerSourceVM( String vm )
+{
+  compilerSourceVM = vm;
+}
+
 public TldLocationsCache getTldLocationsCache() {
 return tldLocationsCache;
 }
@@ -1156,5 +1179,4 @@
 // pass straight through
 }
 }
-
 }
--- Options.java2004-10-05 13:30:36.0 -0500
+++ Options.java-new2004-10-18 14:46:30.631270600 -0500
@@ -117,11 +117,16 @@
 public String getCompiler();
 
 /**
- * Compiler target VM, e.g. 1.1,1.2,1.3, or 1.4.
+ * Compiler target VM, e.g. 1.1, 1.2, 1.3, 1.4, or 1.5.
  */
 public String getCompilerTargetVM();
 
 /**
+ * Compiler source VM, e.g. 1.3, 1.4, or 1.5.
+ */
+public String getCompilerSourceVM();
+
+/**
  * The cache for the location of the TLD's
  * for the various tag libraries 'exposed'
  * by the web application.
--- Compiler.java   2004-10-05 13:30:36.0 -0500
+++ Compiler.java-new   2004-10-18 14:44:05.863104200 -0500
@@ -386,6 +386,11 @@
 info.append(   compilerTargetVM= + options.getCompilerTargetVM() + 
\n);
 }
 
+if (options.getCompilerSourceVM() != null) {
+javac.setSource(options.getCompilerSourceVM());
+info.append(   compilerSourceVM= + options.getCompilerSourceVM() + 
\n);
+}
+
 // Build includes path
 PatternSet.NameEntry includes = javac.createInclude();
 
--- EmbeddedServletOptions.java 2004-10-05 13:30:36.0 -0500
+++ EmbeddedServletOptions.java-new 2004-10-18 14:42:33.480264200 -0500
@@ -144,6 +144,11 @@
 private String compilerTargetVM = 1.3;
 
 /**
+ * The compiler source VM (1.3 by default).
+ */
+private String compilerSourceVM = 1.3;
+
+/**
  * Cache for the TLD locations
  */
 private TldLocationsCache tldLocationsCache = null;
@@ -303,6 +308,14 @@
 return compilerTargetVM;
 }
 
+/**
+ * @see Options#getCompilerSourceVM
+ */
+public String getCompilerSourceVM()
+{
+  return compilerSourceVM;
+}
+
 public boolean getErrorOnUseBeanInvalidClassAttribute() {
 return errorOnUseBeanInvalidClassAttribute;
 }
@@ -571,6 +584,11 @@
 this.compilerTargetVM = compilerTargetVM;
 }
 
+String compilerSourceVM = config.getInitParameter(compilerSourceVM);
+if(compilerSourceVM != null) {
+this.compilerSourceVM = compilerSourceVM;
+}
+
 String javaEncoding = config.getInitParameter(javaEncoding);
 if (javaEncoding != null) {
 this.javaEncoding = javaEncoding;

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

Re: 5.0.29 JSP compilation fails when using JDK 1.5.0

2004-10-14 Thread Jess Holle
Any chance of a 5.0.30 with this resolved in the near future?
[I take it you're back from vacation, Yoav, as I see CVS commit notices 
with your name on them.]

--
Jess Holle
Shapira, Yoav wrote:
Hi,
Thanks for spotting and reporting this issue.  While Tomcat 5.0.x
doesn't officially support J2SE 5.0, we don't want to make things worse
with new releases ;)  So my apologize for this issue.
I'm really busy today and tomorrow at work, and then I'm traveling this
weekend [it's a long holiday weekend in the US].  If someone could at
least post a .diff patch to fix this, I'd be grateful and I'll try to
commit it quickly.  If we wait for me, this issue might have to wait a
few days ;)
Thanks,
Yoav Shapira
Millennium Research Informatics
 

-Original Message-
From: Jess Holle [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 06, 2004 3:55 PM
To: Tomcat Developers List
Subject: 5.0.29 JSP compilation fails when using JDK 1.5.0
Tomcat 5.0.28 compiled JSP pages when run using JDK 1.5.0 just fine
(out-of-the-box). Also, 5.0.28 seems to work fine under JDK 1.5.0 in
general.
Tomcat 5.0.29 can no longer compile JSP pages when running under JDK
1.5.0! Given that 1.5.0 has been released and 5.0.28 works fine, I
believe this is a serious regression in 5.0.29 that should by itself
prevent it from getting a stable rating -- though I'd love to quickly
see a 5.0.30 including a fix for this :-)  [Tomcat 5.0.29 does seem to
work alright under 1.5.0 if you pre-compile all JSP pages via an Ant
project...]
Note that the startup environment, JSP pages, etc, are identical in
   

both
 

cases.  In both cases I use catalina.50.bat start.  Also note that
   

the
 

JSP pages use no 1.5 features whatsoever -- I'm just trying to run with
JDK 1.5.0.  Also, both results hold both for development Jasper
settings (fork=false, development=true, reloading=true) and production
Jasper settings (fork=true, development=false, reloading=false).
The symptom when this fails is the following console message:
  javac: target release 1.3 conflicts with default source release 1.5
I am *guessing* this may have something to do with the following change
log entry:
  30984 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=30984:
  Added compilerTargetVM option to Jasper. (yoavs)
--
Jess Holle
   



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 




Re: JMX Remote connection

2004-10-07 Thread Jess Holle
In general the same-user, same-machine stuff works great (including with 
Tomcat 5) if you specify

   -Dcom.sun.management.jmxremote
as part of the command line.
This is without any special web app or such.
What I really want to see is a nice bit of code that allows you to fire 
up a JMX RMI connector that:

   * Finds the first free port in a range (e.g. assuming you have a
 number of slave processes, this does not apply to Tomcat as it
 does not have such logic for it AJP port, etc).
   * Support user/password and SSL
   * Does not rely on implementation internals, i.e. requiring Java 5
 is fine, but having hooks into sun.* or MX4J or whatever classes
 is no good
--
Jess Holle
Remy Maucherat wrote:
Dominik Drzewiecki wrote:

I couldn't get the attach to process thing to work, though (= 
without a port). Is it supposed to be doable ?

Neither have I (I am talking of tomcat running as Windows service). 
It seems that both processes : tomcat JVM and jconsole JVM have to be 
owned by the same user. Maybe that is the case with you? Hovewer, 
starting tomcat from my system account solves the problem.
For more info see:
http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html

cut
Both jconsole and the application must by executed by the same user 
name. The management and monitoring system uses the operating 
system's file permissions.
/cut

I'm running both with the same usename on Windows, and it doesn't 
work. Since it's Windows and I like to be able to do stuff, I of 
course run with root privileges. Seems to me it would work on Unix, 
but is currently broken on Windows (I use XP pro SP 2), or something. 
Over a TCP port, it works good.

I couldn't find a comprehensive guide on all these nice system 
properties, while there's tons of docs on the new command line commands.

If I use the service, which runs with the SYSTEM account, it of course 
doesn't work any better ;)

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



Re: JMX Remote connection

2004-10-07 Thread Jess Holle
Remy Maucherat wrote:
For those interested in not wasting their time the way I just did, I 
just found this: 
http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html

quote
*Limitation*: On Windows, for security reasons, local monitoring and 
management is only supported if your default Windows temporary 
directory is on a file system that supports persistent access control 
lists (for example, on an NTFS file system). It is not supported on a 
FAT file system that provide insufficient access controls.
/quote

I obviously use FAT32, and I have to add that this limitation is quite 
stupid. No multi user setup would run FAT and expect security, so you 
are fine allowing anything you want on FAT (at least, I can't see how 
it makes stuff more secure). 
Ah...
All my file systems are NTFS...
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: JMX Remote connection

2004-10-07 Thread Jess Holle
Costin Manolache wrote:
Jess Holle wrote:
In general the same-user, same-machine stuff works great (including 
with Tomcat 5) if you specify

   -Dcom.sun.management.jmxremote
as part of the command line.
Again - remember not everyone is using Sun JDK1.5 implementation.
My understanding is Macs don't have 1.5 yet, neither most other 
platforms.
Sorry.  Windows, Solaris, and Linux do, and HPUX will soon.
AIX and Mac OS X will lag as always, though if recent history is any 
guide AIX will lag further than Mac OS X.

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


5.0.29 JSP compilation fails when using JDK 1.5.0

2004-10-06 Thread Jess Holle
Tomcat 5.0.28 compiled JSP pages when run using JDK 1.5.0 just fine 
(out-of-the-box). Also, 5.0.28 seems to work fine under JDK 1.5.0 in 
general.

Tomcat 5.0.29 can no longer compile JSP pages when running under JDK 
1.5.0! Given that 1.5.0 has been released and 5.0.28 works fine, I 
believe this is a serious regression in 5.0.29 that should by itself 
prevent it from getting a stable rating -- though I'd love to quickly 
see a 5.0.30 including a fix for this :-)  [Tomcat 5.0.29 does seem to 
work alright under 1.5.0 if you pre-compile all JSP pages via an Ant 
project...]

Note that the startup environment, JSP pages, etc, are identical in both 
cases.  In both cases I use catalina.50.bat start.  Also note that the 
JSP pages use no 1.5 features whatsoever -- I'm just trying to run with 
JDK 1.5.0.  Also, both results hold both for development Jasper 
settings (fork=false, development=true, reloading=true) and production 
Jasper settings (fork=true, development=false, reloading=false).

The symptom when this fails is the following console message:
   javac: target release 1.3 conflicts with default source release 1.5
I am *guessing* this may have something to do with the following change 
log entry:

   30984 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=30984:
   Added compilerTargetVM option to Jasper. (yoavs)
--
Jess Holle


Re: [5.5] Packaging

2004-08-25 Thread Jess Holle
I would *guess* that those not bothering to move from 1.3 (for whatever 
reason) are mostly the same folk who won't upgrade to a more recent 
Tomcat version anyway.

--
Jess Holle
Shapira, Yoav wrote:
Hola,
 

Write once, run anywhere - why would you choose a target that will
   

not
 

run for a (significant) number of people, and try to force them to
choose between upgrading tomcat and upgrading other software ?
   

I don't think the number is significant.  It's very subjective, and I
have no empirical data, just opinion from the tomcat-user list.  If
someone could show, for example, that more than a tenth of Tomcat users
run with JDK 1.3 in production, I'd be convinced me JDK 1.3 is still
significant.
I completely agree WORA is essential, possibly the biggest advantage of
the Java language/platform.  But then why aren't we coding/building to
JDK 1.1 or J2ME?  It's a question of tradeoffs.  Maybe we should have a
vote on whether Tomcat 5.5 should require JDK 1.5?
This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 



Re: [5.5] Packaging

2004-08-25 Thread Jess Holle
Jeanfrancois Arcand wrote:
+1 for the vote. :-) I'm in favor of requiring j2se 5.0 (but I work at 
Sun so I might have a couple of bad habits ;-) )
Is the vote to be only on whether to continue to support 1.3?  Or the 
same for 1.4?

Also, is it just a commiters vote?
Every platform of *any* note has a stable 1.4.2 now and there is 
precious little excuse to keep using it.  On the other hand, if history 
is any indicator it will be up to 1 full year before 1.5 is available 
*and* stable on all platforms.(including various versions of UNIX, 
etc).  Perhaps this will somehow only be 6 months, but I'd guess that 
though 1.5 could be the default, 1.4 support will be needed for up to 12 
months after Sun's initial 1.5.0 release.

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


Re: [5.5] Packaging

2004-08-25 Thread Jess Holle
Costin Manolache wrote:
Shapira, Yoav wrote:
It depends how you define support, right?  Does support mean by
default everything is configured for JDK 1.3, and Tomcat is built with
target=1.3 ?  Or does it means there's an easy way to set this target
parameter (e.g. a build.properties setting) and build your own Tomcat
for 1.3?
What is the cost of having target=1.3 by default ? It means the class
files and the release will work with jdk1.3 - and it will also run on 
1.4 or 1.5.

What is the benefit of having target=1.4 and forcing people who use 1.3
to recompile the entire tomcat ?
Despite my own feeling that 1.3 has gone the way of the dodo bird, this 
is a good question.  The only thing I know of offhand is that 1.4 gives 
you assert().

Stability versus featurism is much more of a judgment call IMHO.  Does
stability mean we stick with an old platform (JDK 1.3) and jump through
hoops (e.g. runtime detection) to use newer (JDK 1.4, JDK 1.5) features?
If so, then at what point does the cost (e.g. performance) become higher
than the benefit (ease of use for old platform users)?  It's a
subjective call I think.
That's a question for Sun :-), who is forcing people to jump through 
the hoops by bundling all features with the VM.
Most of the features that are interesting in 1.5 have to be to be done 
right...

Tomcat core already works with 1.3 - and you can have optional 
connectors/valves/etc that only work with 1.5 or 1.6 - with just a 
simple conditional compilation.

I understand why MSFT is forcing people to upgrade windows - they make 
a lot of money from that, and don't care how much the users will 
suffer to upgrade. But we don't gain that much by forcing people to 
upgrade the VM to use the latest version of tomcat. I wish Sun would 
sell and make money on the VM - so at least someone would gets some 
benefit from this forced upgrade cycle :-)
The reasons to force upgrades are:
  1. Ability to fully leverage compelling runtime features for end-user
 benefit (e.g. in the case of 1.5, better concurrency utilities,
 built-in JMX, etc; in the case of 1.4 this might possibly include
 NIO stuff for loading static files or some such)
  2. Ability to use compelling development features (e.g. generics in
 the case of dropping releases prior to 1.5, improved/easier-to-use
 APIs in cases, etc)
  3. Narrower platform mix to mess with supporting / answering
 questions on, etc.
--
Jess Holle


Re: endorsed directory (WAS: 5.0.28 next week?)

2004-08-24 Thread Jess Holle
Agreed.  Isn't the issue that the JAXP in Tomcat's endorsed is 
incompatible with 1.5?

Joseph Shraibman wrote:
I don't know why you want to get rid of endorsed.  Sure java 5.0 will 
have an up to date xerces, but it will get out of date in the future, 
so you might as well keep the endorsed directory.

Amy Roh wrote:
+1
I'd like to add startup scripts that don't use endorsed so that tomcat
5.0.28 can be run on JDK 5.0 if needed to be.  People can test it out by
switching the scripts.  I'm running TCKs to see if there're any 
problems but
will commit soon.

Let me know if anyone has issues with this.

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


Re: common/endorsed classLoader

2004-08-20 Thread Jess Holle
Costin Manolache wrote:
To make things a bit more interesting, I believe there are some checks 
in JDK1.4 to prevent you to override rt.jar classes. That's what 
endorsed really does, allow you to bypass those checks.

I don't think we managed to get xerces and jaxp to load from a 
classloader even with delegation disabled.
Xerces would certainly load.
Do you really need Xerces' JAXP rather than that in 1.4?
--
Jess Holle


Re: common/endorsed classLoader

2004-08-20 Thread Jess Holle
Jeanfrancois Arcand wrote:

Jess Holle wrote:
Costin Manolache wrote:
To make things a bit more interesting, I believe there are some 
checks in JDK1.4 to prevent you to override rt.jar classes. That's 
what endorsed really does, allow you to bypass those checks.

I don't think we managed to get xerces and jaxp to load from a 
classloader even with delegation disabled.

Xerces would certainly load.
Do you really need Xerces' JAXP rather than that in 1.4?
Yes, because in 1.4, Crimson is used and doesn't support XML schema. 
That's the only good reason we have to use Xerces when validating a 
web.xml. Note thatn in 1.5, Xerces packages have been renamed to 
com.sun.org.apache.xerces.*, which will resolve a lot of problem (ex: 
you should be able to bundle any xerces version in your war). I didn't 
test it yet
Xerces does not have to be endorsed or even be *the* endorsed JAXP XML 
implementation to be used for purposes like validating XML schema.  One 
can simply directly use the given JAXP factory class -- or better yet 
use a loader that first tries for the 1.5 repackaged JAXP factory and 
then reverts to the standard Xerces class naming or some such.  If this 
is not feasible (e.g. if the digester, etc, code involved simply grabs 
the currently defined JAXP implementation), one could always just have a 
given classloader force Xerces to be the JAXP implementation for 
everything within it (by redirecting request for the given 
meta-inf/services entries to define Xerces as the XML implementation).  
Such a classloader could also have the smarts not to do this in Java 1.5

Now if the 1.5 JAXP interfaces themselves render the current Xerces 
inoperable that is a bigger issue -- and one which I would have to chalk 
up as a serious design flaw in JAXP, i.e. one should not grow interfaces 
in such a way as to break all existing implementations -- rather one 
should add a sub-interface and provide APIs to request the 
sub-interface, etc.  I sincerely hope Sun has not mis-stepped in such a 
major way with something as central as JAXP...

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


Re: Where's 4.1.31?

2004-08-20 Thread Jess Holle
The offer to do this is great, but I am more than a little curious:
Why would anyone bother with a 4.1.x upgrade at this point?  5.0.27 is 
faster, more stable, etc, at this point as best I can tell.

--
Jess Holle
Keith Wannamaker wrote:
Yoav, I haven't RM'd a release yet but if you or another RM-pro
is willing to show me what is involved I might be willing to wear
the hat for 4.1.31.  Here is how I understand the process:
- tag and create a release canidate
- email to announce@
- wait 48 hours for show stoppers
- delcare the RC a release
- email to announce@, update jakarta site
I'd even be willing to document this process if it is not already.
[EMAIL PROTECTED]
-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Friday, August 20, 2004 9:13 AM
To: Tomcat Developers List
Subject: RE: Where's 4.1.31?

Hi,
You can't expect a 4.1.31 anytime soon.  It's in a maintenance mode
where only Spec violations and security flaws are the things that would
get a new release out.  We suggest the same thing we've been suggesting
for a while now, upgrade to 5.x.
Yoav Shapira
Millennium Research Informatics
-
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]


Re: Where's 4.1.31?

2004-08-20 Thread Jess Holle
Keith Wannamaker wrote:
Hi Jess, in our case we don't have the resources at this point in
time to certify our product with a completely new code base.
 

Hmmm...  As someone who distributes Tomcat 4.1.x and 5.0.x to a broad 
customer base I see Tomcat 5.0.x certification as a 100% necessity for 
the future/present and see the incremental effort of verifying a new 
4.1.x release as wasted when it could be focused on a 5.0.x verification 
against past and current releases of our own product.

Then again I believe I have a pretty good record of all changes that 
were required to our product for Tomcat 5 for future releases that could 
be backed into previous ones...

I'm sure different people have different reasons.
 

Yes, I echo Yoav's sentiment, though that the community needs to focus 
on 5.0.x and beyond and really help push mindshare away from 3.x and 4.x 
releases.

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


Re: Where's 4.1.31?

2004-08-20 Thread Jess Holle
Cox, Charlie wrote:
Because a 4.1.x upgrade is not an api change. There is much more testing
involved in upgrading to a new major version than a point release. The
problem is finding the time to review the (possible)effects of 5.x on your
installation and all your applications when you could roll out a point
release with much less effort.
 

Unless your app is not moving into the future this should have already 
been done with 5.x by this point (just possibly not yet deployed) -- right?

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


Re: Where's 4.1.31?

2004-08-20 Thread Jess Holle
I've said too much on this already, but if you really need 4.1.x and bug 
fixes thereto, then why not take Tomcat 4.1.30 and patch it as necessary 
to address bugs of sufficient concern and deliver that to your 
customer/user base?

That seems like a better solution for all than a 4.1.31 release.
--
Jess Holle
Shapira, Yoav wrote:
Hi,
I agree with Jess, this is the wrong direction in principle.  We're
encouraging users to stick with 4.1.x if we do this release.
Normally we have just an informal if everyone is OK with this, I'd like
to push out release X on this day and then a vote on labeling it as
stable.  The latter being the only official vote.  But in this case, I'd
want to have a more general vote of should we have 4.1.x maintenance
releases, given the reasons stated earlier in this thread.
If we have such a vote, and if it passes, and if you decide to go ahead
with this release, then you will probably assume responsibility for bugs
filed against 4.1.x.  This is of course unofficial, but nonetheless this
type of arrangement exists with Tomcat 3.3.x.  None of us care much for
the 4.1.x issues now, except that Mark moved the relevant
Connector-related issues from 4.1.x to 5.0.x so that they don't get
dropped.  This type of move, which I didn't like originally, should
definitely be stopped if 4.1.x is still in active development as
indicated by regular releases.
Man this is a bummer going into the weekend ;)
Yoav Shapira
Millennium Research Informatics
 


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


Re: Where's 4.1.31?

2004-08-20 Thread Jess Holle
Cox, Charlie wrote:
I really hate comments like this. I'm glad you have plenty of free time to
upgrade to 5.x.
Sorry to rankle you, but let's be honest -- if you want to be able to 
move forward you have to keep looking ahead.  Either your app is so 
portable (and likely thus rather simple) that feel you can just snag the 
latest servlet engine du jour and use it -- or you keep an eye to (and 
some testing time slated for) future versions of servlet engines (and 
other components) you use.

If your app is in pure maintenance mode and you're not moving it 
forward, then by all means pull back 1 patch at a time as appropriate.

So right now from a business perspective, upgrading because it's there is
not a reason to upgrade. If I perceive that 4.x is slow for my application,
then I have a reason to upgrade. If I need the new listeners, status
monitor, or other enhancements, then I will consider an upgrade.
 

Getting all the bug fixes that would be in a hypothetical 4.1.31 (and 
setting yourself up to get those that would be in a hypothetical 4.1.32 
and those that are already in 5.0.27 for that matter) are quite possibly 
ample reasons for one to upgrade -- and are a lot more than because it 
is there.

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


Re: Tomcat 5.0.28 release

2004-08-19 Thread Jess Holle
Overall, JAXP is a very painful thing to those deploying any intensive 
XML or XSLT that might care what implementation is used and not having 
the luxury of dictating this implementation to everything else in the 
JVM.  For instance, JAXP requires a separate classloader to change the 
XML or XSLT implementation used (i.e. to override the meta-inf/services 
entries as needed) -- yet one can't just create one's own classloader 
with a rigid security manager in place (e.g. in an applet).  Even for 
per-JVM manipulation, JAXP requires fairly intrusive screwing with one's 
jars (to remove unwanted meta-inf entries) or command lines or creation 
of endorsed directories.

In the end, I've resorted to using my own static factories to look up 
and instantiate JAXP implementation.  From there on out, the JAXP APIs 
are fairly nice and easy to use, so the result is having only a single 
non-standard line of code per XML or XSLT factory.

--
Jess Holle
Shapira, Yoav wrote:
Hola,
 

I must say I don't fully understand the above. So what exactly will
happen if the common/endorsed directory is removed? What will stop
working and on which platform(s)? Are there any specific pointers to
   

bug
 

ids or discussions, that would explain why the endorsed directory was
added in the first place? I know configuring the XML parser and JAXP
   

was
 

always pain, but I don't know what specifically was the problem. Any
insights you can bring into this will be appreciated.
   

JDK 1.4 was the first one to include JAXP and an XML parser
implementation (Crimson) in the JDK itself.  This presented difficulties
to all container writers, including Tomcat, because they had to jump
through special hoops to allow user web applications to override the
parser and JAXP interfaces that shipped with the JDK.
The typical use-case is a user wishing to use Xerces version X, which
provides new features not available in Crimson and not accessible via
the JAXP APIs, but relying on new DOM or SAX classes.  The user needs
both the xml-apis.jar and the xercesImpl.jar from his WAR file to be
loaded, overriding those in the JDK itself (old JAXP and old Crimson
parser).
The endorsed classloading mechanism is the approach suggested by Sun and
adopted by Tomcat.  Endorsed means that classes from that repository
can override those classes with the same name that ship with the JDK.
The XML parsers are the classic example, but there are others.
Our classloader how-to
(http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html
) and Sun's documentation on the mechanism in general
(http://java.sun.com/j2se/1.4.2/docs/guide/standards/) contain
additional explanations.
Yoav Shapira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 




Re: Tomcat 5.0.28 release

2004-08-19 Thread Jess Holle
Jeanfrancois Arcand wrote:
[back from vacation :-)]
Costin Manolache wrote:
Shapira, Yoav wrote:
Hi,
I have a couple of only-slightly-related comments, but related
nonetheless so I'll put them here.
Re: endorsed directories.  Do we still want to support JDK 1.3 in 
Tomcat
5.1?  Since we're gearing up for JDK 1.5, we might want to make 1.4 the
minimum.  I'm +0.5 on this.
First, endorsed directories are _not_ for 1.3, but for 1.4 ( to 
override the build-in parser and the check they do on load ).
1.3 works fine with just having the parser in classpath, or in 
/jre/lib/ext, and it's quite simple to add code to the loader to add 
the parser packages only if 1.3 is detected.
Except if you turn validation on, which will not works since XML 
schema is not supported in Crimson or early version of Xerces 
(remember the nightmare)

I'm using JDK1.3 most of the time, and I think a lot of other people 
and companies are still using it. I don't mind having the default 
distribution built for 1.4+ ( no xerces ), with instructions on how 
to get the additional jars for 1.3. But I think it would be very bad 
to not be able to run in 1.3 - and I don't see any good reason to 
justify forcing the users to upgrade.
One question we should explore is do we really wants to have a 
dependencies on Xerces? Like you already said, a pull parser might be 
better, smaller and more stable than having to rely on Xerces. Not 
sure if pull parser supports schema yet...

+1 of dropping Xerces ;-)
Couldn't the use of XML be forced in a manner that is completely 
independent of JAXP?  This could try for the 1.5 Xerces (once at 
startup) and then fail over to the 1.4 Xerces which it would always 
deliver, etc.

Just a thought
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Tomcat 5.0.28 release

2004-08-10 Thread Jess Holle
I would have to agree with the gentlemen from Sun and NetBeans that it 
is preferable to have a standard stable version bundled with other 
products as opposed to some other file set which one cannot 
independently reproduce.

Why?
Users of NetBeans, etc, would like to know that they can reproduce the 
same behavior outside the IDE by grabbing the same version label from 
Jakarta.  If NetBeans uses its own set of source versions, then users 
never know what might differ between the NetBeans Tomcat behavior and 
standard Tomcat releases.  I happen to be responsible for the 
redistribution of a modified Tomcat and have come to noting each and 
every deviation (change or addition) from the standard Tomcat release 
upon which I'm based for this reason.

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


IIS-Tomcat connector bugs

2004-07-21 Thread Jess Holle
I have been pounding my head into the wall trying to get 
isapi_redirect.dll working on IIS 6.0.

There are 3 bugs here with isapi_redirect and its docs as they stand 
today -- only one directly of Microsoft's making, it appears:

*1) The URI handed to map_uri_to_worker() in jk_isapi_plugin.c always 
contains the host and port screwing up virtual host-independent 
URI-to-worker mappings.*

I did a little digging and discovered that this has apparently been 
broken since revision 1.19 (i.e. 1.18 worked).  The apparent fix is as 
follows:

   --- jk_isapi_plugin.orig.c  2004-02-24 01:45:50.0 -0600
   +++ jk_isapi_plugin.c   2004-07-21 12:11:50.0 -0500
   @@ -718,14 +718,13 @@
jk_log(logger, JK_LOG_DEBUG,
   In HttpFilterProc Virtual Host redirection
   of %s\n,
   snuri);
   -} else {
   - strncpy(snuri, uri, sizeof(snuri));
   -   }
   +worker = map_uri_to_worker(uw_map, snuri, logger);
   +}
if (!worker) {
jk_log(logger, JK_LOG_DEBUG,
   In HttpFilterProc test Default redirection
   of %s\n,
   uri);
   -worker = map_uri_to_worker(uw_map, snuri, logger);
   +worker = map_uri_to_worker(uw_map, uri, logger);
}
if (worker) {
I have filed this as bug 30236 
http://issues.apache.org/bugzilla/show_bug.cgi?id=30236.

Just to add an example:
   /examples/*=ajp13
will no longer work with the current code but
   /fullhostname/examples/*=ajp13
does.
*2) isapi_install.vbs has hard-wired references throughout to 
isapi_redirector.dll.  Unfortunately, the default name of the DLL and 
that used throughout all the documentation bundled and otherwise is 
isapi_redirect.dll.*

This leads to *very* confusing failures to load the connector into IIS.  
Once this apparent typo is corrected, this script works great.

I have filed this as bug 30238 
http://issues.apache.org/bugzilla/show_bug.cgi?id=30238.

*3) Connector documentation is not up-to-date for IIS 6 Changes*
The IIS portion of the Tomcat connector documentation makes no mention 
of the extra steps required to get the connectors working with IIS 6.  
These are clearly documented elsewhere on the web 
(http://www.rit.edu/~ack5504/tomcat-iis6-howto/tomcat-iis6-howto.html 
http://www.rit.edu/%7Eack5504/tomcat-iis6-howto/tomcat-iis6-howto.html 
amongst other places), so there is little reason not to incorporate this 
information.  Not bundling this information leaves most people 
attempting this configuration completely lost -- and they just give up.

I have filed this as bug 30239 
http://issues.apache.org/bugzilla/show_bug.cgi?id=30239.

That's it for the moment
--
Jess Holle


Re: Some JK2 ideas

2004-07-20 Thread Jess Holle
I actually built this yesterday upon rediscovering it -- and it seems to 
work fine.

Unfortunately:
  1. The licensing is unclear.
  2. There appears to be no active maintenance or support of this module.
I'm thus more than a little reluctant to put too many eggs in this basket.
--
Jess Holle
Günter Knauf wrote:
Hi,
 

A good number desparately want NTLM-based authentication.  [They like
the single-sign on for Windows clients, but they love the notion of
better security than clear-text name/password, etc, without having to
buy a server certificate or use HTTPS on their intranet.]  If Apache 2
had a stable module for this (whether or not it was from the ASF
itself), I would think this would be a good step to get these folk to
shift to Apache.
   

then shift them - this module is available since first Apache2 days:
http://www.gknw.net/development/apache/httpd-2.0/win32/modules/mod_auth_sspi-1.0.1-2.0.49.zip
and also for Apache 2.1:
http://www.gknw.net/development/apache/httpd-2.1-dev/win32/modules/mod_auth_sspi-1.0.1-2.1-dev.zip
Guenter.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 



WebappClassLoader.getURLs Bug!

2004-07-20 Thread Jess Holle
In Tomcat 4.1.x, I discovered that RMI calls from Tomcat failed when the 
any of the full file paths of the web app jars contained a space (' ') 
character.

At the time, I was told this would be fixed in Tomcat 5 and to work 
around it in Tomcat 4.1.x, which I did.

Unfortunately, now that I've moved to Tomcat 5, I discover that the bug 
is still quite present.  There is now a nice getURI() method along with 
the previous getURL() method.  Unfortunately, getURLs() does not use 
getURI( file ).toURL() or any such as it would need to for the RMI 
runtime's sake (as it calls getURLs()).

I can clearly patch WebappClassLoader.getURLs() to make such calls 
myself, but:

  1. I'm left wondering about the broader implications of doing just this.
 * In Tomcat 4.1.x, I changed getURL() to do
   canonicalFile.toURI().toURL() under Java 1.4 and a hand
   coded equivalent in previous JVMs.
 * This works quite robustly in my experience, but I'm left
   wondering what the overall best, safest, and most performant
   fix is.
  2. I don't want to keep having to maintain my own fix.  An overall
 optimal fix should be integrated into Tomcat 5 so that this issue
 ceases to be an issue for everyone using Tomcat.
--
Jess Holle


Re: WebappClassLoader.getURLs Bug!

2004-07-20 Thread Jess Holle
Shapira, Yoav wrote:
Hi,
 

Unfortunately, now that I've moved to Tomcat 5, I discover that the bug
is still quite present.  There is now a nice getURI() method along with
the previous getURL() method.  Unfortunately, getURLs() does not use
getURI( file ).toURL() or any such as it would need to for the RMI
runtime's sake (as it calls getURLs()).
   

The getURI method returns a URL object, not a URI object, as the latter
is JDK 1.4-only and we still officially support building and running on
JDK 1.3.
 

So getURI is essentially doing a file.toURI().toURL() anyway?
If so, can we just switch getURLs() to call getURI() rather than getURL()?
Or should we switch getURL() to call getURI after attempting to get the 
canonical file object (which is all it does apart from toURL(), whose 
results are broken as far as the RMI runtime is concerned)?

If need be, I can keep either of these patches in my own distribution, 
but I always like to see a single, consistent fix for everyone.

--
Jess Holle


Re: WebappClassLoader.getURLs Bug!

2004-07-20 Thread Jess Holle
Remy Maucherat wrote:
Shapira, Yoav wrote:
Hi,
Unfortunately, now that I've moved to Tomcat 5, I discover that the bug
is still quite present.  There is now a nice getURI() method along with
the previous getURL() method.  Unfortunately, getURLs() does not use
getURI( file ).toURL() or any such as it would need to for the RMI
runtime's sake (as it calls getURLs()).
The getURI method returns a URL object, not a URI object, as the latter
is JDK 1.4-only and we still officially support building and running on
JDK 1.3.
I agree: you really should be complaining about Sun (who wrote the bad 
URL handling in the first place).
Agreed -- but that won't fix the issue.
So can we fix it in 5.0.x or not?
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Invitation to HTTPD commiters in tomcat-dev

2004-07-20 Thread Jess Holle
Remy Maucherat wrote:
Costin Manolache wrote:
Well, the mod_proxy + enhancements for sticky session + enhancements 
for passing auth info sounds reasonable - and if nobody wants the JMX 
support, then maybe we won't need to write a new connector anyway :-)

Remy will be happy - we'll only use the http connector.
I think AJP has advantages, but if the HTTPd folks only accept a 
simple solution based on mod_proxy, then so be it, it'll be our entry 
level connector.
One issue here:
When Apache and Tomcat are used together via AJP13:
  1. The host, port, protocol, etc, are exactly that at the Apache
 level, i.e. one's web app sees Apache and Tomcat as 1 entity. 
 This is a very good thing overall compared to reverse proxying (if
 that's the mod_proxy proposal).
  2. The body content, query string, etc, are reported to one's web
 application precisely as sent, whereas Tomcat pre-processes them a
 bit more than picky, low-level request parsing code can accept. 
 [Yes, the picky code is *too* picky, but it isn't mine :-)]

--
Jess Holle


Re: Invitation to HTTPD commiters in tomcat-dev

2004-07-20 Thread Jess Holle
Costin Manolache wrote:
Graham Leggett wrote:
In all my deployments of tomcat I have never seen the point of a 
custom protocol that did exactly what HTTP does, so all my tomcat 
deployments are all HTTP, with a simple mod_proxy frontend.

Even the get Apache to server static content feature wasn't enough 
of a drawcard, as proper HTTP cache handling and a suitable cache 
solved this problem. It was far more important for me to arrange the 
web application as a self contained unit - I would rather be more 
tidy with an install at the expense of a slightly higher load, than 
sacrifice a clean install to save some cycles.
There is a bit more - we want to be able to have Apache authenticate 
and pass this info to tomcat for example. I don't know if this can be 
done with mod_proxy ( maybe have it add an extra header - but that may 
have security problems ).
That is a hard requirement for us as well.
And in fine, we like to have some JMX like functionnalities in 
Apache 2,
in our case MX for C Management Extension, a way to update Apache 2.x
configuration while the server is running...
This is possibly a whole separate project in itself.

Agreed.  It sounds like a great project, but a *separate* project and 
module.

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


Re: Invitation to HTTPD commiters in tomcat-dev

2004-07-20 Thread Jess Holle
Graham Leggett wrote:
Henri Gomez wrote:
It's now time to refactor and redesign it with Apache 2.x (APR/AP) in
mind to follow Apache 2.x admins habbits and try to make something
simpler.
We came on httpd-dev for advice from experts, and may be an
extended mod_proxy could be the solution. But we also want to keep
the AJP/1.3 and AJP/1.4 protocols since it works well and so a pure
HTTP proxy is only part of the game.
I think any module that speaks ajp/1.X should be called mod_ajp, keeps 
things simple and clean.

- Could mod_proxy be open to support AJP/1.x as tomcat connections ?
I don't think mod_proxy should support ajp, rather a dedicated ajp 
module should.

But I'm still not convinced a separate protocol is needed when HTTP 
exists and is supported already.

The httpd serves the static content feature can be implemented 
through extending ProxyPass to support regular expressions, for example:
That would be a hard requirement for our usage as well.  A huge reason 
for using Apache is to serve the static content at that level.

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


Re: Invitation to HTTPD commiters in tomcat-dev

2004-07-20 Thread Jess Holle
Henri Gomez wrote:
Wayne Frazee wrote:
Please pardon me for attempting to marshall the obvious however what is
the advantage of AJP/1.x over HTTP?  
- Persistant connections, mod_jk use a pool of socket connections
  to avoid reopening connections between Apache and Tomcats.
  You could set socket timeout to make these sockets more or less
  persistant. Also socket keep alive could be specified to avoid
  firewall cut connexions without activity.
The keep alive stuff turns out to be a hard requirement for many 
deployments.

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


Re: Invitation to HTTPD commiters in tomcat-dev

2004-07-20 Thread Jess Holle
Remy Maucherat wrote:
Jess Holle wrote:
One issue here:
When Apache and Tomcat are used together via AJP13:
  1. The host, port, protocol, etc, are exactly that at the Apache
 level, i.e. one's web app sees Apache and Tomcat as 1 
entity.  This is a very good thing overall compared to reverse 
proxying (if
 that's the mod_proxy proposal).
I have no idea how to get around that ;) This seems a showstopper: the 
user will have to read the connector's documentation.
Certainly things function in a reverse proxy environment and so the more 
complex situation is handled.  The issue is that individual developers 
*can* do bad things by assuming that the request protocol is that they 
should use in base tags, etc.

Overall, that would just be life, though and is insufficient reason not 
to leverage mod_proxy.

  2. The body content, query string, etc, are reported to one's web
 application precisely as sent, whereas Tomcat pre-processes them a
 bit more than picky, low-level request parsing code can accept. 
 [Yes, the picky code is *too* picky, but it isn't mine :-)]
I have no idea what your webapp is doing, but it's not portable. All 
the trasformations done respect the HTTP and servlet specifications.
Actually it is rather portable and does not break any spec to the best 
of my knowledge.  It just assumes it can get at the original content 
body stream, request string, etc, as an alternative to getParameter() 
without missing anything.  Why this is the case is a long story.  I also 
miss forget exactly where things fall down, but Apache, iPlanet (with 
embedded servlet engine), and IIS (with Tomcat) all work (except config 
issues with IIS 6...)

This appears to be far removed from most folks' experience, so I guess 
Tomcat's httpd is good enough for most.

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


Re: WebappClassLoader.getURLs Bug!

2004-07-20 Thread Jess Holle
Remy Maucherat wrote:
Jess Holle wrote:
Agreed -- but that won't fix the issue.
So can we fix it in 5.0.x or not?
Possibly, but it's risky.
So you'd recommend that I just patch my own distribution, then?
[Changing getURL() to convert to a URI first worked fine in 4.1.24...]
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: WebappClassLoader.getURLs Bug!

2004-07-20 Thread Jess Holle
Okay, I'll just change getURL() to be identical to getURI() and all 
should be well for me.

Shapira, Yoav wrote:
Hi,
And wait for a 5.1 release, which may not be long in the making.
Yoav Shapira
Millennium Research Informatics
 

-Original Message-
From: Jess Holle [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 20, 2004 12:40 PM
To: Tomcat Developers List
Subject: Re: WebappClassLoader.getURLs Bug!
Remy Maucherat wrote:
   

Jess Holle wrote:
 

Agreed -- but that won't fix the issue.
So can we fix it in 5.0.x or not?
   

Possibly, but it's risky.
 

So you'd recommend that I just patch my own distribution, then?
[Changing getURL() to convert to a URI first worked fine in 4.1.24...]
--
Jess Holle
-
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]
 




Re: Some JK2 ideas

2004-07-19 Thread Jess Holle
mod_jk with Apache is not that hard.
Actually I believe it is fairly easy
mod_jk2 is much harder for me to understand.
Getting the IIS connectors to work with IIS 6 appears to be rocket 
science though.  [Dang thing just shows a red down arrow on the filter 
whatever you do without giving any real error!]

--
Jess Holle
Cavan Morris wrote:
Andy Armstrong wrote:
I have concrete examples of people giving up on Tomcat altogether for 
no other reason than the fact that they couldn't get JK configured. 
By comparison the rest of the task of configuring Tomcat is a walk in 
the park. Please let's not be so up ourselves that we forget that 
it's nice for people to actually be able to use the software.

As a lurker on this list I can give myself and everyone I've ever 
worked with as concrete examples of some people that have given up on 
4.1+ tomcat because of JK configuration.

I can count at least 12 projects I have worked on, or am working on, 
that are still on Tomcat 4.0.6 with mod_webapp because we could never 
get JK to do what we wanted.  That is, mount this webapp at that URI 
in one line and be done with it.  All the other JK features are great 
but 90% of the configurations are going to be like the one I just 
described and no one can figure out how to do it.

I love what you guys are doing.  I think you should strive to make the 
most common configuration as simple as mod_webapp and allow people to 
add complexity if their needs require it.

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


Re: Some JK2 ideas

2004-07-19 Thread Jess Holle
Andy Armstrong wrote:
Jess Holle  Getting the IIS connectors to work with IIS 6 appears to 
be rocket

science though.  [Dang thing just shows a red down arrow on the 
filter whatever you do without giving any real error!]
Heh. Having spent two days getting the filter to work on IIS I'm 
thinking about starting to sell a consultancy service based on getting 
JK2 working. I actually wrote, debugged, documented and delivered a 
non trivial ISAPI filter for a different project in less time than it 
took me to get JK2 working.
This is the JK, nor JK2, based connector in my case, but:
  1. There are documented missing configuration steps out on the web
 for IIS 6 that should be verified and placed in the Tomcat isapi
 documentation.
  2. Any hint as to what to do other than start over again and hope for
 better luck would be great appreciated.  [I used the
 'isapi_install.vbs' script in hopes of having fewer error-prone
 manual steps.  Was that a bad idea?]
I'd have kept this off the 'dev' group, but item (1) is quite glaring at 
this point in that there are many reports that one cannot use the Tomcat 
connectors with IIS 6 without extra configuration steps beyond what the 
Tomcat docs provide.

--
Jess Holle


Re: Some JK2 ideas

2004-07-19 Thread Jess Holle
Costin Manolache wrote:
Jess Holle wrote:
Andy Armstrong wrote:
Jess Holle  Getting the IIS connectors to work with IIS 6 appears 
to be rocket

science though.  [Dang thing just shows a red down arrow on the 
filter whatever you do without giving any real error!]
Heh. Having spent two days getting the filter to work on IIS I'm 
thinking about starting to sell a consultancy service based on 
getting JK2 working. I actually wrote, debugged, documented and 
delivered a non trivial ISAPI filter for a different project in less 
time than it took me to get JK2 working.
This is the JK, nor JK2, based connector in my case, but:
  1. There are documented missing configuration steps out on the web
 for IIS 6 that should be verified and placed in the Tomcat isapi
 documentation.
  2. Any hint as to what to do other than start over again and hope for
 better luck would be great appreciated.  [I used the
 'isapi_install.vbs' script in hopes of having fewer error-prone
 manual steps.  Was that a bad idea?]
I'd have kept this off the 'dev' group, but item (1) is quite glaring 
at this point in that there are many reports that one cannot use the 
Tomcat connectors with IIS 6 without extra configuration steps beyond 
what the Tomcat docs provide.
Maybe the best response to this would be to update the docs and say
tomcat IIS 6 is not supported, plese contact microsoft and ask them 
to do it. They have plenty of developers and money - they could send 
a check to Andy and Henri, or do it themself :-)
I'm quite certain that they're ecstatic that it is problematic to make 
these things work together.

Personally, I despise IIS.
However, when customers insist on using IIS for all HTTP(S) traffic and 
your product relies on a servlet engine, what are you supposed to do?

Do quality commercial offering exist that integrate with IIS *well*?  
JRun is completely untenable.  Most of the big guys have their own web 
server, app server, etc, etc, to push -- causing still more problems.  
Moreover, we don't want still more engines to test everything with

It's better then having people struggle with mod_jk config and feeling 
it's tomcat developer's job to support IIS.
In a way I agree, Microsoft is happily creating an unworkable environment.
Unfortunately, either Java as a whole backs out of this arena or it 
fights for it.  If Tomcat backs out, then it seems unlikely that many 
using IIS will even bother trying Java servlets and/or JSP pages (as 
they'll have no free way to do so).

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


Re: Some JK2 ideas

2004-07-19 Thread Jess Holle
Henri Gomez wrote:
It's better then having people struggle with mod_jk config and 
feeling it's tomcat developer's job to support IIS.
You could also suggest IIS users to switch to Apache 2.0.50 for 
Windows :)
I'd love to -- and have.
Unfortunately, some have drank too much Microsoft Kool-Aid.
A good number desparately want NTLM-based authentication.  [They like 
the single-sign on for Windows clients, but they love the notion of 
better security than clear-text name/password, etc, without having to 
buy a server certificate or use HTTPS on their intranet.]  If Apache 2 
had a stable module for this (whether or not it was from the ASF 
itself), I would think this would be a good step to get these folk to 
shift to Apache.

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


  1   2   >