Re: Why are we still using JAXP and ProjectX???(proprietary==evil)

[Christopher K. St. John]

James Duncan Davidson wrote:
> 
> On 1/3/01 10:24 PM, "Kevin A. Burton" <[EMAIL PROTECTED]> wrote:
> 
> > Why are we using JAXP and ProjectX which are both Closed Source and
> > proprietary
>
> Then why are you using Java which is composed of code most of which isn't
> under a free license 
>

 There are non-Sun implementations of Java, some of which are
Free or Open. (I kinda suspect you knew that :-)

 The JAXP license is a legitimate pain-in-the-a** for those
of us without special dispensations (which evidently includes
projects that would like to reuse bits of Tomcat code, but
can't)

 Or are you saying that it's ok to, for example: take some of
the Tomcat web.xml/servlet.xml loader code, and reuse it in
a non-Apache product that does a fancy GUI interface? The Apache
license allows (encourages!) this, but the JAXP license does
not, right?


-cks

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

Re: NullPointerException from HttpSessionFacade.invalidate()

[Christopher K. St. John]

Hans Bergsten wrote:
>
> The spec may not be explicit enough about this, but the session object
> you get back from the getSession() object is a container-managed object
> that the application is not supposed/allowed to keep long-lived
> references
> to. It's the same as with all other container-objects made available to
> the
> application; request, response, JSP tag handlers, etc.
> 

 I would have agreed with you before I read the
following in the 2.3PFD spec:

  7.3 Session Scope

  HttpSession objects must be scoped at the
  application / servlet context level. The
  underlying mechanism, such as the cookie
  used to establish the session, can be shared
  between contexts, but the object exposed, and
  more importantly the attributes in that object,
  must not be shared between contexts.

 By mentioning that the HttpSession object cannot
be shared outside the ServletContext, it strongly
implies that it can be shared within the context.
If that sort of thing isn't allowed, then 7.3 might
need to be clarified.


-cks

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

Re: NullPointerException from HttpSessionFacade.invalidate()

[Christopher K. St. John]

Hans Bergsten wrote:
> 
> "Christopher K. St. John" wrote:
> >
> >   7.3 Session Scope
> >
> >   HttpSession objects must be scoped at the
> >   application / servlet context level. The
> >   underlying mechanism, such as the cookie
> >   used to establish the session, can be shared
> >   between contexts, but the object exposed, and
> >   more importantly the attributes in that object,
> >   must not be shared between contexts.
> >
> >  By mentioning that the HttpSession object cannot
> > be shared outside the ServletContext, it strongly
> > implies that it can be shared within the context.
> > If that sort of thing isn't allowed, then 7.3 might
> > need to be clarified.
> 
> This section refers to the fact that a servlet in one context should
> not be able to gain access to the same session data as a servlet
> in another context (i.e., resources in two different context's can
> not "be part" of the same session) for security reasons .
> 
> It has nothing to do with whether a servlet in one context is allowed
> to hold on to the actual session object or not, which has to do with
> how much freedom the spec gives to container vendors in terms of
> pooling and life-cycle management for the internal objects.
> 

 Because Section 7.3 explicity discusses the HttpSession
object itself (as opposed to the objects it contains), it
suggests that the HttpSession object has an identity. 

 I don't think there is any question that after the end
of the lifecycle of an HttpSession object, it can be
recycled. But what earlier messages in this thread suggested
was that JServ was recycling HttpSession objects _during_
the lifetime of the session, so that req.getSession(false) could
return two different objects even within the same session.

 That would mean that the practice of synchronzing on the
HttpSession object was also not kosher? Since two servlets
within the same session at the same time could not be sure
of getting the same HttpSession object? Are you really
suggesting that that behavior is allowed by the spec?

 If so, I find that very unintuitive.


-cks

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

Re: NullPointerException from HttpSessionFacade.invalidate()

[Christopher K. St. John]

Hans Bergsten wrote:
> 
> But in a container that
> saves sessions to disk to conserve memory, or during server restart,
> you will most definitely see more than one instance. Same thing
> for a distributable application, where the session may migrate
> to another server.
> 

 You can see more than one instance, but you will always
be notified by an HttpSessionEvent. That's part of the
"normal session lifecyle" I mentioned, and I think that
we agree there is no ambiguity in that case.


> and that I'm pretty sure that
> whatever it is you want to do can be done in a way that's more
> likely to be portable
>

 You may very well be right, but that's irrelevant. It
doesn't matter if there's a better way, it matters that
according to a reasonable interpretation of the current
spec, it should be legal. 


> All I'm saying is that it's dangerous to rely on behavior
> that's not clearly defined by the spec, 
>

 Well, yes, but you have to be able to make _some_ 
assumptions, or the spec would be 12 feet thick. In
general, you can assume that if the spec doesn't
specifically allow counterintuitive behavior, then
it's disallowed. 

 There is admittedly a very fine balancing act that the
spec has to pull off: it must be loose enough to allow
innovative implementations, but strict enough to allow
interoperability.

 But give me a break: what JServ is doing in this case
is just fantastically counterintiutive.

 This probably needs to be summarized and sent as 
spec feedback, but unless he says otherwise I will
assume Gokul Singh is going to do it (Gokul?)


-cks

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

Re: NullPointerException from HttpSessionFacade.invalidate()

[Christopher K. St. John]

"Craig R. McClanahan" wrote:
> 
> If your server implements session swapping or distribution (as we are currently
> developing in the 4.1 repository), it is pretty much guaranteed that different
> session object instances may be used during the lifetime of the same session.
> 

 But don't you get session lifecycle events if that happens?


-cks

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

PersistentManagerBase.processMaxActiveSwaps()

[Christopher K. St. John]

 I've been messing around with PersistentManager,
trying to get sessions to swap out based on maxActiveSessions.
There's a check in processMaxActiveSwaps():

Session sessions[] = findSessions();
// FIXME: Smarter algorithm (LRU)
if (getMaxActiveSessions() >= sessions.length)
return;

 And also one in createSession():

  if ((maxActiveSessions >= 0) &&
  (sessions.size() >= maxActiveSessions))
throw new IllegalStateException
(sm.getString("standardManager.createSession.ise"));

 I'm not seeing any way that the check in processMaxActiveSwaps()
could ever fail, since createSessions() will refuse to 
create more than maxActiveSession Sessions. Which would
mean that processMaxActiveSwaps() never gets any farther
than that check, and never swaps anything out.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH][4.0] remove spurious casts in ApplicationFilterChain

[Christopher K. St. John]

 The "fall off the end of the chain" code in
ApplicationFilterChain.internalDoFilter checks if the
passed in request and response are HttpServletRequest/
Response objects. Based on the test, it casts the 
objects and invokes servlet.service(). However, since
the servlet member has a static type of javax.servlet.Servlet,
the exact same method is called in both cases. The code
operates correctly (since the non-http version of the 
service() method eventually invokes the correct version
of service()), but the test and cast are redundant and
confusing. The following patch removes them:


Index: ApplicationFilterChain.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationFilterChain.java,v
retrieving revision 1.11
diff -u -r1.11 ApplicationFilterChain.java
--- ApplicationFilterChain.java 2001/10/11 23:30:58 1.11
+++ ApplicationFilterChain.java 2001/12/28 19:06:24
@@ -242,13 +242,7 @@
 try {
 support.fireInstanceEvent(InstanceEvent.BEFORE_SERVICE_EVENT,
   servlet, request, response);
-if ((request instanceof HttpServletRequest) &&
-(response instanceof HttpServletResponse)) {
-servlet.service((HttpServletRequest) request,
-(HttpServletResponse) response);
-} else {
-servlet.service(request, response);
-}
+servlet.service(request, response);
 support.fireInstanceEvent(InstanceEvent.AFTER_SERVICE_EVENT,
   servlet, request, response);
 } catch (IOException e) {




-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH][4.0] Server javadoc fix

[Christopher K. St. John]

 The javadoc comments for o.a.c.Server weren't updated
when the Service level was added. I removed the old bad
bits and inserted some uninspired but correct new bits.

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com


server-javadoc.patch
Description: Binary data

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH][4.0] StandardPipeline javadocs typo fix

[Christopher K. St. John]

 The javadoc comment for o.a.c.c.StandardPipeline's state
member refers to the "values" array instead of the "valves"
array, which appears to be a typo. The following patch 
fixes it.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com


stdpipjdocs.patch
Description: Binary data

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

StandardPipeline and ThreadLocal

[Christopher K. St. John]

 The first thing that pops into my head when I see the
Pipeline pattern (and read Craig's [PROPOSAL] Tomcat
4.0-beta API Change: Valve APIs post), is something
along the lines of the psuedocode at the end of the
message.

 The semantics are subtly different from the current
StandardPipeline, but I think only in bizarre cases
like if a Valve spawned a thread and then both threads
tried to call invokeNext on the same ValveContext.

 It's not like the existing code is exactly broken,
but the use of ThreadLocal is certainly a little
unexpected. It violates the "avoid suprising code"
rule. (Well, it suprised me, anyway)

 Do the semantics differ in some other way that makes
the implementation below incorrect? (Ignore bugs, you
get the idea) If not, would whoever's responsible for
that code be willing to accept a patch to get rid of
the ThreadLocal?


 class ValveContext {
   Pipeline p;
   int i;
   public void invokeNext(req, rsp) {
 if (i==p.valves.length)
   if (p.basic)
 v = p.basic;
 else 
   v = p.valves[i++];
 if (!v) throw exception;
 v.invoke(req, rsp, this);
   }
 }

 class StandardPipeline {
   Vector valves = new Vector();
   Valve basic;
   public void invoke(req, rsp) {
 ctx = new ValveContext(0, this);
 ctx.invokeNext(req, rsp);
   }
 } 



-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH][4.0] ApplicationFilterChain Ctr

[Christopher K. St. John]

 ApplicationFilterChain has a constructor that doesn't do
anything useful. It's call to super() is a bit confusing,
since it leads to the assumption that FilterChain is a 
class. Other interface implementations in Catalina don't
bother with placeholder constructors, this patch removes
the one in ApplicationFilterChain.

 I've been posting patches as I come across bits of code
and documentation that look iffy. None of them have been
showstoppers and none of them are the kind of thing normal
people can work up much enthusiam about. But crappy little
cleanup patches really do help in the long run. Especially
documentation cleanup. I was under the impression that
stuff like this didn't go through the normal code-change
voting process, it just got picked up (or not) by a
committer and merged in. Is that correct? Would it be more
appropriate to submit bug reports?


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH][4.0] ApplicationFilterChain Ctr

[Christopher K. St. John]

 


afiltcctr.patch
Description: Binary data

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH][4 HEAD] ContainerBase javadoc typo fix

[Christopher K. St. John]

Comment typos, you think "awww, who cares", and then
you notice one. And it starts to gnaw at you, just a
little bit at first, but then it gets worse and you
can't think of anything else and your marriage
falls apart and you end up frozen to death in the
gutter.

Best to avoid the whole thing and just fix them.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com


cbasecmnt.patch
Description: Binary data

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: nbio connector

[Christopher K. St. John]

Remy Maucherat wrote:
> 
> > With my design, you still need one thread/request but only for the
> > time required to process container.invoke()
> 
> In the real world, the servlets and JSPs are the thing which take by far the
> most time to complete, so I'm not sure you wouldn't end up spending a lot of
> time in the threaded part.
>

 There was a long discussion on the advanced-servlets list 
a while back. That discussion concluded that the NIO looked
most promising for:

 - Cleanly waiting for persistent connections (which take
   up a connector thread but don't really need to) You
   can kinda sorta do this already with the existing java.io
   classes, but NIO is better. This is a relatively easy
   win.

 - Serving static content. It's not just the non-blocking
   io, serving from memory mapped files is a beguilingly
   easy (but maybe not always the best) way to improve file
   serving performance.

 Using NIO to reduce the time service() needed to tie up
a thread is fun, but seemed unlikely to help very much in
practice. And of course the optimized char conversion
stuff, but that's obviously useful and therefore boring.

 I'm pretty sure newesh versions of Jetty include a first
pass at integrating NIO, so anybody that's interested
might want to take a look.

 There's some fairly bogus (but still kinda interesting)
benchmark results using NIO-like routines to serve static
files at distributopia.com. (Sun says no NIO-bmarks until
it's out of beta, so I used Matt Welsh's NBIO code)

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: nbio connector

[Christopher K. St. John]

[EMAIL PROTECTED] wrote:
> 
> I'm not very sure about nbio - most of the time there's a lot
> of complexity ( and a different programming model, etc )
>

 Yes.


> - and  the benefits seems pretty small. 
>

 It depends. Using NIO, you can serve static content as fast
or faster than Apache 1.3 in pure Java, which means one less
reason to use a separate front-end web server. (Of course,
performance isn't the only reason to run Apache as a front
end to Tomcat, but it seems to be perceived as the biggest
reason)


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: nbio connector

[Christopher K. St. John]

Attila Szegedi wrote:
> 
> (as it stands now in JDK 1.4, a single thread can manage up to 63
> channels so you still need multiple threads, only less than with
> blocking approach),
>

 The 63 channel limit is a Windows-only bug in the Beta,
designing code  around it probably isn't a good idea.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Minimalistic Docs

[Christopher K. St. John]

Anthony Holland wrote:
> 
> "Tomcat - A Minimalistic User's Guide"
> 
> There is no such word as 'minimalistic'. 
>


 In the style of a member of the art movement Minimalism.
 In the style of a minimalist.
 Minimalistic.

 Works for me.

 "Minimalist User's Guide" would imply that the user's
guide has to do with the art movement (or communism),
while "Minimalistic" implies that the guide is in the
style of, but not actually about, Minimalism.

 "A Minimalist's Guide" might work.

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

ApplicationFilterChain, doPrivileged()

[Christopher K. St. John]

 When a SecurityManager is intalled, ApplicationFilterChain.doFilter()
wraps its internalDoFilter() call with AccessController.doPrivileged(),
but I'm having trouble figuring out why.

 doFilter() gets called from:

  a) StandardWrapperValve.invoke(), in which case (presumably) the
 container and all its ancestors in the call chain have a
 superset of the permissions of the Filter code, so the call
 to doPrivileged() doesn't matter.

  b) A user filter. The user filter (presumably) is in the same
 domain as any other filters and the servlet. And the doFilter()
 code is (presumably) in a domain with more permissions than
 the webapp code. So the call to doPrivileged wouldn't matter.

 I'm still fuzzy on many of the practical aspects of the 1.2
Security Architecture, and I cheerfully admit the possibility
that I'm missing something obvious. Can anyone enlighten me? Or
point me to some catalina specific docs? I'm clear on the other
uses of doPrivileged() (like in HttpRequestBase), it's just the
call in ApplicationFilterChain that has me puzzled.

 TIA.

 
> Minimalistic is clearly not a word.
>

 Just because a word isn't in (your) dictionary doesn't
mean it isn't "real". There also may be some word play
involved :-)


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

StandardSession.expire() race?

[Christopher K. St. John]

 There's code in StandardSession that looks like this:

  public void expire(boolean notify)
if (expiring)
return;
expiring = true;

 The test isn't thread safe, and it looks like it's 
possible to have expire() called from the StandardManager
reaper thread and a servlet thread (through invalidate)
simultaneously.

 'expiring' is tested in other places in StandardSession,
but I'm not sure enough of the possible call paths to tell
offhand if they're also dangerous.

 I think it would be enough to declare expire volatile
and put a synchronized block around the test-and-set
in expire(), but I wanted to double check my logic 
before I submitted a patch...
  

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

IOException, , etc.

[Christopher K. St. John]

 Tomcat 4 will never match:

  
 java.io.IOException 
 /ioexception.html 
  

 because all servlet-generated IOExceptions are silently
swallowed up by StandardWrapperValve before they get a
chance to be handled by the ErrorReportValve. (or the
ErrorReportValve, you don't even get the default stack
trace page)

 This strikes me as bad, but there are comments in the
StandardWrapperValve code that indicate it's intentional.

 I've searched fruitlessly (google, list archives, cvs
comments, etc) for any hints about why Tomcat would
want to do this. 

 Is is a bug or a feature? If it's a bug, I'll happily
submit a bugreport and patch. If it's a feature,  what's
the rationale?

 Thanks,

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

NanoCatalina

[Christopher K. St. John]

 I'd like to embed Catalina in a distributed tool that uses
servlets for its admin interface. I'm currently using a very
small hand-rolled 'container' that supports just enough of 
the servlet spec to handle my current crop of servlets.

 o.a.c.s.Embedded is a start, but it's a little heavy, both
in code size (lots of required jars) and resource usage (extra
threads, extra objects, etc)

 For example: HostConfig insists on creating an extra thread
to do reloadable webapps, even if no webapps are reloadable
and autoDeploy is false. Not really a big a deal, but that
sort of thing adds up.

 Before I start ripping things apart, I wanted to double
check that somebody else hadn't already done the work for
me. I googled around and found references to using Catalina
as the servlet engine for J2EE containers, etc., but that's
a slightly different thing.

 Does anyone have references to an existing 'NanoCatalina'?
Is anyone else interested in such a beast? I suspected it
might be a generally useful sort of thing to have around,
but I could be wrong...


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Java home autodiscovery add-on

[Christopher K. St. John]

GOMEZ Henri wrote:
> 
> What about adding this part in tomcat.sh (TC 3.3) and
> catalina.sh/jasper.sh to help them discover JAVA_HOME on
> at least Linux systems ?
> 

 If someone forgets to set JAVA_HOME and has multiple JDK's
installed, they could get a suprise. I suspect most non-beginners
would rather see an error message than be suprised. I ran into
this problem with a configure script that tried to be too smart
about finding a JDK to use.

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Java home autodiscovery add-on

[Christopher K. St. John]

GOMEZ Henri wrote:
> 
> >> What about adding this part in tomcat.sh (TC 3.3) and
> >> catalina.sh/jasper.sh to help them discover JAVA_HOME on
> >> at least Linux systems ?
> >
> > If someone forgets to set JAVA_HOME and has multiple JDK's
> >installed, they could get a suprise. 
>
> That's why you could still tune the JAVA_HOME is tomcat_cfg
> which is read at start of script (not shown here).
> 

 You're presumably trying to reduce configuration problems
for beginners, but trying to find JAVA_HOME automatically
is likely to increase overall confusion.

 Current situation: beginner (or forgetful expert) doesn't
have JAVA_HOME set, trys to start catalina, gets an error
message, sets JAVA_HOME, everything is fine.

 New situation: beginner (or forgetful expert) doesn't 
have JAVA_HOME set, trys to start catalina, and catalina
starts. Either:

  1) You got lucky, the script found the right JDK, 
  the code runs for the moment, and the user thinks
  everything is ok. Until they install another JDK and
  suddenly catalina stops working. The user is confused.

  2) You don't get lucky, the script finds and silently
  runs with the wrong JDK, and the user is confused.

 As I said, I ran into this problem with a ./configure
script that was too smart for its own good. It caused
more problems than it fixed.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Java home autodiscovery add-on

[Christopher K. St. John]

GOMEZ Henri wrote:
> 
> Did you take a look at my scripts ?
> 

 I thought I did, although I concentrated on the proposed
changes to catalina.sh.


> This config stuff came from discution on this this list with
> Keith Irwin and Nicolas Mailhot :)
> 

 It looks like I missed some background discussion, but the
tomcat-dev archives at metronet appear to be out of date,
and google didn't turn up anything. If this has all been
gone over in detail before, then a pointer to a copy of the
thread in the archives would probably shut me up.

 I was assuming:

 - An rpm installation would set up a series of scripts in
   the appropriate LSB-compliant directories. One of those
   scripts would be tomcat4. A user wanting to start Catalina
   would run tomcat4 (or put it in their rc directories to be
   started automatically) 

 - A non-rpm installation would still be started by running
   bin/catalina.sh, just like before. This would be typical
   of a developer just getting started with Tomcat.


> So experienced and beginner will JUST have to :
> 
> - Comment JAVA_HOME="/opt/IBMJava2-13" in config file
>   for auto-exploration
> 
> - Set JAVA_HOME in config file to specify WHICH JVM they
>   want to be used with Tomcat3 (and since TC 4 use another
>   config file, it could be used at the same time with the
>   same or a different JVM).
> 

 But that's only if you're running using a full-on RPM based
installation?

 I doesn't really matter, though. My objection is based on
the "principle of least suprise", which in this case means
that an installation that works should not suddenly stop
working because of an unrelated change to another part of
the system.

 If the answer is "it's unwise to run with auto-discovery
turned on", then why have it at all? Systems that need to
run totally without configuration (from a cdrom?) would
presumably need custom configuration scripts in any case.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

o.a.c.mbeans.*

[Christopher K. St. John]

 It looks like the current mbeans code is mostly boilerplate.
Is there a technical problem with using the information from
mbeans-descriptors.xml to create dynamic mbeans that don't
require hand-coded mbeans wrappers?


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH] Bug 6592: hostjdoc.patch

[Christopher K. St. John]

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com


hostjdoc.patch
Description: Binary data

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: o.a.c.mbeans.*

[Christopher K. St. John]

"Craig R. McClanahan" wrote:
> 
> >  It looks like the current mbeans code is mostly boilerplate.
> 
> In what respect? 
>

 Well, taking StandardHostMBean as an example, many of the
methods take a String argument, convert it to an ObjectName,
get the underlying object using getAttribute(), and then call
the actual operation on the wrapped Catalina objects. That can
all be done using introspection and the info in
mbeans-descriptors.xml. I think the other methods could
be similarly automated.

 Note that I'm clear that the normal JMX mechanisms do not
provide this. RequiredModelMBean is a start, but there would
need to be extra code to do the mappings between Strings,
ObjectNames, and Objects. I'm suggesting that that code is
for the most part boilerplate, and there's enough information 
available through introspection and the modeler Registry to
implement a completely generic Catalina MBean that could be
used in place of many/most of the existing hand-coded Catalina
MBeans.


> Consider the following method on the o.a.c.UserDatabase interface:
> 
> public Iterator getUsers();
> 

 You're right, automatically converting between the version of
getUsers() that returns an Iterator and the version that
returns a String[] would take an overly clever mechanism.
MemoryUserDatabase MBean would be hard to get rid of.

 But it looks like most of the objects that need to be managed
already use easy-to-recognize bean patterns for their interfaces.
I'm pretty sure StandardHostMBean, for example, could be entirely
eliminated.

 It matters in general because it adds an extra burden to
Catalina developers to have to write a new hand-coded MBean
every time they want to add a new kind of object. I suspect
most people won't bother, especially if it's an in-house sort
of thing. That still leaves the issue of adding entries to
mbeans-descriptors.xml, and possibly having to rewrite parts
of the admin webapp, but every little bit helps.

 I care because I'm trying looking at hacking up a debloated
(excuse me, "slimmed down" :-) configuration of Catalina for
use inside a tool I'm writing. Although there's a good chance
there wouldn't be room for JMX, I'd like to maintain as much
compatibility as possible with the standard Catalina tools.
That's easy if MBeans are automagically created for me...
 
-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670

[Christopher K . St . John]

 I posted to the dev list earlier about needing a small,
relatively lightweight version of Catalina to embed into
another program. I spent the weekend putting together
something that more of less fits my needs. (My needs 
include a relatively small jar, plus no use of the local
file system) I ended up with a 260k jarfile of the catalina
classes, plus another 75k or so of new Container classes.
I suspect there's at least another 100k that can be
trimmed.

 I ran into a troubling amount of coupling between the
various bits of Catalina. The o.a.catalina.* classes were
fairly clean, but the implementation classes tended to know
a lot about each other. That made reuse difficult, since
inheriting from one of the core classes ended up bringing
in pretty much every class (and external dependency) in
Catalina.

 The implementation classes obviously need to know
something about each other, but there are an awful lot of
hardcoded assumptions. The large number of casts makes
it very hard to figure out what depends on what.

 Instead of trying to make the core classes more generic,
I ended up writing a new set of Containers and support
classes. Using the existing Catalina code made that fairly
easy, but much of the code re-use was necessarily of the
cut-and-paste variety.

 There were a couple of especially inconvenient couplings
that are probably worth fixing, one trivial and one a little
more serious. I've submitted both of these as bugs.

 First, there's an uneeded import of org.xml.sax.AttributeList
in o.a.c.realm.RealmBase. That one's not such a big deal
since it doesn't matter at run time. The first of the
attached patches removes it.

 Second, there's a cast to StandardContext in AuthenticatorBase.
The cast is needed because AuthenticatorBase wants to use
the same debug level as its associated Context, but Container
doesn't expose the any set/getDebug methods. It would be good
to get rid of the cast because it's the only place that
BasicAuthenticator makes assumptions about the exact type of
its Context. The second patch just gets rid of the StandardContext
import and cast. A better solution might be to move set/getDebug
up into Container. Adding a Debug interface would work too, but
that seems like overkill. 

The MinimalTomcat code is definitely alpha quality, and it's
only meant to support the particular subset of Catalina that I
happen to need right at the moment. It is not, and is not
intended to be, a complete reimplementation of the Catalina
core classes. On the other hand, it's substantially smaller
and less complicated, while retaining the same basic architecture.
If anyone's interested, feel free to email me at the address
below, or respond on the list.



-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com


AuthBaseCast.patch
Description: Binary data


RealmBaseImport.patch
Description: Binary data

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670

[Christopher K . St . John]

Aaron Smuts wrote:
> 
> I'm very interested.  We should call it HouseCat.  I'd
> like to find a home for it if it doesn't fit into tomcat.
> 

 I detest housecats, but I suppose that's not really the
point :-)

 I'm not sure my is generally useful. The basic approach
probably is, but maybe not the code.

 I personally don't really need all the
run-time event stuff (not the servlet-spec events, the
Catalina internal events). I don't need JSP. I don't
need run-time parsing of the config server.xml and
web.xml files. I don't need the full-on security
architecture (so I don't need facades and I don't
need SecurityManager code). I don't need (but kinda
want) the JMX management interfaces. Etc.

 The code I've written is only useful if you're
eliminating the exact same set of things I am. Otherwise,
you bloat out until you're full-on Catalina again.
(OTOH, projects like Galeon managed to find generally
useful subsets of Mozilla, so there's an existence proof
that such a thing is possible.)

 But if I'm the only one use Catalina as a framework 
instead of as a monolithic servlet container, it isn't
going to work. There's too much pressure on developers
to 'cheat' and tightly couple all the implementation
classes. It's just easier that way. Right now, MinimalTomcat
basically can't use anything  within o.a.catalina.core,
but eventually all the packages will be tightly linked
unless there's some sort of incentive not to.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670

[Christopher K . St . John]

Aaron Smuts wrote:
> 
> What I'd like would be a Jakarta version of something small
> and simple like the oldest available Jetty version.
> 

 I'll take a look.


> Sounds like you'll have trouble when the parent package
> changes.  You need something new and separate.
> 

 Well, the org.apache.catalina package is fairly clean,
and gives the impression that it will stay that way. It
does depend on o.a.c.deploy, but those are mostly little
struct-like utility classes for use during Digestion.

 It's classes like StandardWrapper that worry me. It
comes very close to being generic, but has a hardcoded
cast of its Context to StandardContext. It looks an 
awful lot like the cast was introduced during the 
addition of Filters in order to avoid an api change
to the Context interface. Coupling StandardWrapper to
StandardContext isn't necessarily unreasonable,
especially if StandardWrapper was never meant to be
used outside the whole StandardEngine/Host/Context/Wrapper
setup, but it does signal that the Catalina core 
classes are not meant to be used outside the normal
Catalina channels.

 I'm worried that the same sort of thing will happen
with, for example, the realm and authorization packages.
If it does, there's really no point in having MinimalTomcat
use any of the Catalina classes at all except through cut
and paste. 

 Can one of the Catalina architects (Craig?) comment?
Is it reasonable to try to use Catalina as a framework
like that? Or am I swimming against the tide?


 In any case, tomorrow I'll whip up a sourceball of the
current MinimalTomcat code and stick it out on the net
somewhere.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670

[Christopher K . St . John]

Remy Maucherat wrote:
> 
> Well, it's not that I want to advocate the "competition", but it seems to me
> that Tomcat 3 is more useful for a "MiniTomcat", mainly because it requires
> only JDK 1.1 (smaller JDK; J2ME is based on JDK 1.1, so maybe it could end
> up being a "target"; that was one of Costin's pet projects, actually).
> 

 For my purposes, it's ok to assume 1.2, so that's not
an issue. 

 If Tomcat 4 isn't meant to be used like I'm using it,
then I don't really understand the point of the generic
interfaces in o.a.catalina. If StandardContext is the
only possible Context implementation, what's the
justification for a generic Context interface?

 The current architecture requires an awful lot of
casts, and if the only configuration allowed is:

 StandardEngine/StandardHost/StandardContext/StandardWrapper

 then most of them are unnessary. What's the point
of going through hoops with the generic interfaces
if you know the exact types in advance?

 I understand that project goals can change, but the
design of the apis (not to mention the javadocs)
do seem to strongly imply that something like MinimalTomcat
should be legit.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

MinimalTomcat code

[Christopher K . St . John]

>  In any case, tomorrow I'll whip up a sourceball of the
> current MinimalTomcat code and stick it out on the net
> somewhere.
> 

 http://www.distributopia.com/servlet_stuff/mtc-0_1.tar.bz2

 It's a bzipped tar file. If you've just got to have a zip,
email me. The directions assume you've got a copy of Tomcat 4
built from source. If you're not the kind of person who 
builds Tomcat from source, you probably won't be interested
in this code. The code is alpha, and has never been tried
outside my build environment. The included demo webapp uses 
basic authentication. The user is "scott", the password 
is "tomcat". I'd appreciate feedback. 

Good luck.

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

o.a.c.Context.*RoleMapping() ?

[Christopher K . St . John]

  I can't find anyplace that that these routines from Context
are used:

   public void addRoleMapping(String role, String link)
   public String findRoleMapping(String role)
   public void removeRoleMapping(String role)

 A grep through the dev archives shows that they used to be
used in HttpRequestBase.isUserInRole(), but were removed and
replaced with some similiar code that uses the Conext
SecurityRole routines instead (see below for cvs notification). 
I get the  /*SecurityRole() thing.

 Are the *RoleMapping() methods still used? If so, any hints
as to how and where? 


--8<8<--

craigmcc01/03/26 12:02:17

  Modified:catalina/src/share/org/apache/catalina/connector
HttpRequestBase.java
  Log:
  Correct the implementation of HttpServletRequest.isUserInRole() so that it
  properly respects role name aliases defined with .
  
  PR: Bugzilla #1086
  Submitted by: [EMAIL PROTECTED]

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670

[Christopher K . St . John]

"Craig R. McClanahan" wrote:
> 
> Internal references from one package to another (say,
> org.apache.catalina.realm to org.apache.catalina.core) are much less
> desireable. 
> ...
> Is it appropriate to go through the exercise of identifying the
> offending cases and defining proposed changes to implement them?
> Yah, it's definitely time for that to happen.
> 

 Currently, AuthenticatorBase depends on StandardContext. It's
not some deep dependency. AuthenticatorBase just wants to set
its debug level to be the same as its Context. There's an
instanceof check before the cast, so AuthenticatorBase doesn't
actually require that its parent be a StandardContext, but
it does require that StandardContext exists. It produces a 
'mystery dependency' that is invisible from the outside. 

 I may be preaching to the converted, but mystery dependencies
are bad. They make the code brittle and hard to understand.
They lead to spaghetti.

 I reported the dependency as a bug (with a patch) and the
bug was changed to a feature request. I suppose it depends
on how you look at it. It's certainly a bug for me. 

 There are a couple of ways to fix the problem:

 1) Delete the offending code. Easiest, and in this case
 probably reasonable. You'll lose the debug-setting 
 propagation, but you can always set that manually. It's for
 debugging so presumably you're messing with the settings
 any case. My patch did this, I'd like to see it applied.

 2) Move setDebug() up to the Context or Container level.
 They all implement setDebug() anyway, right? And it doesn't
 break compatibility with old code. Med/long term, this would
 probably be a good solution.

 3) Create a Debug interface. Pretty much everything in 
 Catalina has set/getDebug() methods, not just Containers.
 But it's overkill. Each new class or interface adds
 conceptual overhead to the system. I don't think it's
 worth it.

 Whether you like the idea of something like MimimalTomcat
or not, I suspect writing it will turn up some problems
(and solutions) that will improve all of the Catalina code.


 While we're on the subject of interfaces, what is
Context.findRoleMapping() for? I've got it stubbed out in
MinimalTomcat, but I'd like to know what I'm stubbing out.
It used to be used in HttpRequestBase.isUserInRole(), but
the call was replaced by a call to Context.findSecurityRole().
 

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Etiquette, MinimalTomcat, Bug 6670

[Christopher K . St . John]

 I'm stuck, and not sure how to proceed. MinimalTomcat really
needs AuthenticatorBase to be core-clean.

 It may be that this is an unrealistic requirement, and it's
impossible to make any use of o.a.c.Authenticator package
outside of o.a.c.core.*. That would be a shame, but, as they
say, you can't fight city hall.

 But my reading of Craig McClanahan's posting on the subject
was that I should, in theory, be able to make use of the
Authenticator classes. There may be practical difficulties
(like the one reported in Bug 6670), but those difficulties
are flaws that are a legitimate target for fixes.

 Here are my etiquette questions: (1) What's the deal with
"request for enhancement"? I read this as "blackhole", but
I'm honestly not sure. (2) Can I change this back to being
a bug? Or is that an abuse of bugzilla? (3) Is bringing
up the topic in email after email until I get a response
considered (a) legitimate lobbying for an important issue 
that affects a minority of developers and is thus overlooked,
or (b) spamming.

 Thanks,
 
-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Etiquette, MinimalTomcat, Bug 6670

[Christopher K . St . John]

"Craig R. McClanahan" wrote:
> 
> On 1 Mar 2002, Christopher K.St.John wrote:
> 
> > I'm stuck, and not sure how to proceed. MinimalTomcat
> > really needs AuthenticatorBase to be core-clean.
>
> It should be pretty easy to change this particular use
> of StandardContext to use reflection instead. 
>

Got the new version from CVS, it works for me, thanks
Craig.


> I'm constrained at the moment by product requirments on
> my day job
>

My assumption was that if I'm complaining about it, I
ought to be providing patches.


> In the mean time, persistence is good.
> 

 :-)


Speaking of persistence, what are Context.*RoleMapping()
for?  They look to be unused duplicates of
Context.*SecurityRole() methods. I've stubbed them out in
MinimalTomcat, but it's unsettling to not know what
they're used for.  Does anybody use them? If so, what for?


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Custom Realm implementations

[Christopher K . St . John]

"Dettling, Ingo" wrote:
> 
> Do you see a chance to make GenericPrincipal a public class in the
> next release?
> 

 It's public in 4.0.3.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: How To Add a Scheduler Program Working With A Webapp In Tomcat?

[Christopher K . St . John]

Rock Luiss wrote:
> 
> The scheduler program start to run when tomcat start,and exit when
> tomcat stop.The scheduler can send email and maintenance data in
> the DB. The scheduler must access other classes in the webapp.
>

 When you say "must access other classes in the webapp", what
do you mean exactly? Would it be enough to have a Scheduler
Service that could make a normal request to the servlet at
prescheduled times? 


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: problem with catalina for 'non-web' application

[Christopher K . St . John]

Pier Fumagalli wrote:
> 
> "Jerome Bouat" <[EMAIL PROTECTED]> wrote:
> 
> > What is wrong ?
> 
> That tomcat is an web-application container, so, if you want
> to do something different, you're on your own, you shouldn't
> be using Tomcat...
>

 This comment puzzles me. It's generally a very good thing when
people want to use your code, and it's especially good when 
they want to use it for something the original authors never 
thought of. 

 Of course, that isn't really the case here. Tomcat 4 was (at
least according to the original proposal) intended for this sort
of thing.

 Since most of the current set of developers don't want to use
it that way, it's perfectly fair to tell people they're on their own.
They've got the source, right? If somebody wants something, 
they can implement it themselves. But to tell them "Don't use
Tomcat" gives them a (hopefully) very wrong impression.

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Running tomcat as an embedded servlet engine

[Christopher K . St . John]

"WATKINS, Andy, FM" wrote:
> 
> Has anyone else tried to do this (run an embedded servlet
> engine without swathes of configuration files)?
> 

 Yes, although I suspect you're looking for something
a little different than what I needed. You might check
out:

 http://www.distributopia.com/servlet_stuff/catalina_mtc.html

 It's not ready for prime time, but it might give you
some ideas. 

 I can't seem to find it right now, but somewhere
I've got an example of using regular-old Catalina 
completely without config files. It was what I was 
trying to use before MinimalTomcat. You can do it, but
it's fighting against the tide, I don't really suggest
it. (Email me privately and I'll try to find the code)
 
-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[ANNOUNCE] MinimalTomcat Alpha 0.2

[Christopher K. St. John]

 MinimalTomcat is a special-purpose servlet container
designed to be embedded within distributed
applications. It's meant to have a very small footprint,
both in the size of its classfiles, and in its resources
usage. It's built with framework code from Catalina
(Tomcat 4), but uses alternate implementations of the core
Catalina interfaces.

 This second alpha release includes a deployment tool that
uses an XSLT transformation to convert web.xml directly
into Java source code that does the equivalent series of
initialization calls. Also included is a Jakarta Watchdog
conformance report: "207 TEST(S) PASSED! 141 TEST(S)
FAILED!" You've been warned.

 It is available at:

  http://www.distributopia.com/servlet_stuff/catalina_mtc.html

 MinimalTomcat requires a full installation of Catalina. It has
only guaranteed to work with the latest from CVS. Feedback
about the build and install process is especially appreciated.

 Thanks.

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

servlet.jar, /ext, MANIFEST.MF

[Christopher K. St. John]

The JDK documentation indicates that servlet.jar, as an
official optional package, should be placed in the
/lib/ext directory. [1] However, the Tomcat 4 documentation
(well, the mailing list) indicates that servlet.jar should
not be placed in /lib/ext. [2]

Catalina should be able to detect problems using
java.lang.Package methods to query the version of the
provided javax.servlet packages.

 It looks like this would require:

  1) jakara-servletapi-4 to provide a manifest with the
 appropriate version information.

  2) Catalina to check the version information at some
 point, perhaps optionally.

Is this a reasonable thing to do? I admit to a cosiderable
amount of confusion over the balance between theory
[3],[4],[5] and practice. Any feedback/clarification
greatly appreciated.


[1] http://java.sun.com/products/jdk/1.2/docs/guide/extensions/spec.html
 4th paragraph of the Introduction uses servlet.jar as an
 example of something that definitely belongs in /ext. I'm
 not trying to argue about it, I'm just pointing out that
 the documentation conflicts with common practice. I've
 gotten into arguments with people who insist it's ok because
 of the extensions spec says, specifically, that it is.

[2] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5523,
 ref "Additional Comments", also:
 http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg15098.html
 ref para starting "TOMCAT-USER gets 10 or so messages a week".

[3] http://java.sun.com/products/jdk/1.2/docs/guide/extensions/spec.html

[4] 
http://java.sun.com/j2se/1.3/docs/guide/versioning/spec/VersioningSpecification.html

[5] SRV.9.7.1 "Dependencies On Extensions". Yes, I know,
it isn't quite the same thing.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: servlet.jar, /ext, MANIFEST.MF

[Christopher K. St. John]

Patrick Luby wrote:
> 
> we can put "-Djava.ext.dirs=" as an argument in the Tomcat scripts.
> This argument causes the JVM to ignore any jars in its jre/lib/ext
> directory ...
> 

 But wouldn't that mean that "legitimate" exetensions were 
ignored? 


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: servlet.jar, /ext, MANIFEST.MF

[Christopher K. St. John]

Patrick Luby wrote: 
> "Christopher K. St. John" wrote:

> >  But wouldn't that mean that "legitimate" exetensions were
> > ignored?

> Yes, they would be ignored. 


 That seems a bit hostile. The majority of stuff that could
go into /ext is harmless. Ignoring it punishes users who
correctly install the "right" extensions. 

 My proposal was based on idea that if you can't solve a
hard-to-diagnose problem, you ought to at least make it
obvious. I'd be worried that ignoring /ext solves one
such problem but replaces it with another.

 jakarta-servletapi-4 packages ought to have version info
in any case. jakarta-tomcat-connector packages already do.
Is there a maintainer for the servletapi stuff?


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

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

Re: servlet.jar, /ext, MANIFEST.MF

[Christopher K. St. John]

Patrick Luby wrote:
> 
> I can't help but think that there might be a way to point Tomcat
> to its bundled jars without losing access to any non-conflicting
> extensions.


 That would be better. (but the servletapi still should have
the appropriate version info :-)


> ... have the class loaders in Bootstrap.java add the jars in
> the JVM's jre/lib/ext directory to the end of its search list. 


 Hmm. To match the spec, I think there would need to be a new
classloader on top of all of those. Something like:

   ExtClassLoader (pithed)
   |
   AppClassLoader (as normal)
   |
  Catalina /ext   (new: loads /ext classes)
   |
Common(as normal)
  ...

 Which means that stuff loaded from the classpath won't have
access to extensions, so that's still not quite right. Since
Tomcat closely controls what's on the classpath I'm not sure
how much of an issues that is, but it's definitely a bit
different than normal.

 I'd settle for just having Tomcat print an error message if
there was a conflict, but if the classloader hacks can be
made to work that would obviously be better.

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[ANN] MinimalTomcat Alpha 0.3 "It's got moxie!"

[Christopher K. St. John]

  http://www.distributopia.com/servlet_stuff/catalina_mtc.html

Includes a new "single jar" configuration. An entire
servlet container, with all dependencies and webapps, can
be packaged into and run from one small jar. Updated
Watchdog spec conformance report: "217 TEST(S) PASSED! 131
TEST(S) FAILED!"

MinimalTomcat is a special-purpose servlet container
designed to be embedded within distributed applications.
It's meant to have a very small footprint, both in the
size of its classfiles, and in its resources usage. It's
built with framework code from Catalina (Tomcat 4), but
uses alternate implementations of the core Catalina
interfaces.

This is an alpha release for developers, MinimalTomcat
is not ready for production use.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh

[Christopher K. St. John]

Remy Maucherat wrote:
> 
> Adding another CL layer is dangerous and makes CL slower;
> unless other people think this is useful I don't think we
> should add the feature)
> 

 Another option is to use the manifest version tags to
identify which versions of the servletapi (and other
sensitive classes) are being used, and print out an
error message if they don't match what Tomcat requires.


Patrick Luby wrote:
> 
> My first concern is that Tomcat always can at least run no matter what
> extensions that user has installed. Whether or not those extensions are
> accessible to Tomcat is, IMHO, a feature that we may or may not want to
> include.

 Quitely dropping extensions that the user has installed
is unintuitve, and in some ways worse than the current
situation. 

 Perhaps a combination? Normal behavior is to check api
versions, exit if they don't match. Fallback if it's
impossible to remove the extensions is to use the
"java.ext.dirs=" hack? That lets a user get Tomcat
running no matter what, but with full awareness of the
tradeoff.


 Either way, the current situation is a problem for many
people, as can be seen by a quick scan of the tomcat-users
list. 


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardPipeline.java

[Christopher K. St. John]

Arvind Srinivasan wrote:
> 
> I think the performance related change that you made to StandardPipeline can
> be improved upon in that it can avoid using a HashMap to store/retrieve the
> pipeline stage and instead simply store/retrieve it from an integer variable
> in the RequestBase class. Since this codepath (StandardPipeline.invokeNext)
> is executed many times per request, replacing the request.getNote() call
> with something like request.getPipelineStage() will benefit performance.
> I've attached a patch that implements this suggestion.
> 

 The obvious implementation is to have have ValveContext hold
the index.

 That's how I assumed it worked the first time I
saw the Pipeline, Valve and ValveContext classes. I was suprised
to see a ThreadLocal. Using ValveContext has the appropriate
threading semantics, and it avoids hiding the index in a
"mystery attribute" in the Request. And, (although none of this
will result in a measurable performance gain) using 
ValveContext to hold the index should be faster, since it
avoids a hashtable lookup.

 Using a Request note is much like using a global variable:
it's  hidden state. Long term that's bad, for obvious
reasons.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardPipeline.java

[Christopher K. St. John]

Arvind Srinivasan wrote:
> 
> Christopher St. John wrote:
> >
> >  The obvious implementation is to have have ValveContext hold
> > the index.
> 
> But isn't a ValveContext (Pipeline) shared across requests ?
>

 It's shouldn't be, but it is now. StandardPipeline
implements VavleContext, but there's no particular reason
to do it that way.


> I think the stage has to be maintained in the Request object.
> 

 No, definitely not. Here's how MinTC (MinimalTomcat) does
it (this is alpha code, and I've deleted some of the methods
to keep the size down):


public class MinimalPipeline implements Pipeline {

  class MinimalValveContext implements ValveContext {
protected int pos = 0;
public void invokeNext(Request req, Response rsp)
  throws IOException, ServletException
{
  Valve v = null;
  if (pos == valves.size())
v = basicValve;
  else
v = (Valve)valves.elementAt(pos++);
  if (v!=null)
v.invoke(req, rsp, this);
}
  }

  protected Valve basicValve = null;
  protected Vector valves = new Vector();
  protected Valve[] valve_array = null;
  protected Container container = null;

  public void invoke(Request req, Response rsp)
throws IOException, ServletException
  {
MinimalValveContext ctx = new MinimalValveContext();
ctx.invokeNext(req, rsp);
  }

}


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[ANN] MinimalTomcat Alpha 0.4 "Small Container, Big Attitude"

[Christopher K. St. John]

MinTC used to be MinimalTomcat, but MinTC is shorter.

  http://www.distributopia.com/servlet_stuff/catalina_mtc.html

New DefaultServlet implementation allows serving files
from within the jar. Now runs under IBM's J2ME/CDC
environment (see website for details). Many more Watchdog
tests passed: "333 TEST(S) PASSED! 15 TEST(S) FAILED!"

MinTC is a special-purpose servlet container designed to
be embedded within distributed applications. It's meant to
have a very small footprint, both in the size of its
classfiles, and in its resource usage. It can be deployed
along with all your webapp classes and content as a single
executable jar.

MinTC is built with framework code from Catalina (Tomcat
4), but uses alternate implementations of the core
Catalina interfaces.

This is an alpha release for developers, MinimalTomcat
is not ready for production use.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[ANN] MinTC 0.5 Alpha "It Wants to be Your Friend"

[Christopher K. St. John]

 MinTC needs adventurous testers.

 http://www.distributopia.com

 Changes for 0.5 include: Initial support for error pages,
better support for RequestDispatcher, more testing with
J2ME/CDC, a start on supporting precompiled jsp's, and
general cleanup. Watchdog conformance testing results:
"342 TEST(S) PASSED! 6 TEST(S) FAILED!"

 MinTC is a special-purpose servlet container designed to
run from inside your application's jar file. It requires
no local file system access, and can execute servlets and
serve static content from within the jar. It's ideal for
web-enabling an application's admin interface, or for
packaging a webapp as a standalone application.

 MinTC is cool because it uses XSLT to transform web.xml
and server.xml into startup and initialization code.

 MinTC makes use of framework classes from Tomcat 4, and is
released under an Apache-style Open Source license.
 
 Note that MinTC is still in alpha, so it's a little early
to be using it for production work. Testers are very
welcome, however.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Corrupted Ouput - Tomcat 4.0.3

[Christopher K. St. John]

Remy Maucherat wrote:
> 
> > There seems to be a bug in the servlet output.
>
> Tomcat 4 does not corrupt images, binaries, or anything like that. This has
> been proven on and on by many people using it (like myself) on various
> websites.
>

 That logic doesn't work. The fact that it works for
some people, even the vast majority of people, is no
proof at all that it works for everyone.


Claude Montpetit wrote:
>
> I may try to play with this to prove  myself that the
> problem is in my network (clues on how to change output
> buffer size on V3 and V4 would be appreciated).
>

 If you have a network analyzer (like ethereal) you might
want to try to get a dump of the actual IP packets.
Sometimes jumping down to the lowest possible level is
easier than trying to debug things from the top down.

 This thread might be better over on tomcat-users, or
if you're actively working on it, you might try the
#tomcat channel on irc.openprojects.net.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Tomcat 4 target JDK is 1.2? but ShutdownHook is 1.3?

[Christopher K. St. John]

 cvs HEAD o.a.c.startup.Catalina has a Runtime.addShutdownHook()
call, but ShutdownHooks are a 1.3 thing. I was assuming (based on
the website docs) that 4.1 was supposed to be JDK 1.2+. Is that
incorrect? Is JDK 1.3 the target?


 In an amusing (and perhaps useless) twist, MinTC (embeddable
servlet container based on the Tomcat 4 architecture) now
appears to run under PersonalJava. PJ is a 1.1.8 variant (it
has Collections classes, plus some other stuff). Catalina
based servers expand to cover the entire gamut? Java Card
anyone? 

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH] Small fix for StandardServer ctr

[Christopher K. St. John]

 o.a.c.core.StandardServer's ctr calls super(), but the
class does not extend anything. The call is legal, but
misleading. The following patch removes it. The patch is
against HEAD, but it's also an issue in 4.0.x.

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com


stdsrvctr.patch
Description: Binary data

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

o.a.c.startup.EngineConfig doesn't do anything?

[Christopher K. St. John]

 I can't figure out what EngineConfig is for. It doesn't
appear to do anything at all. The docs say it "configures
the properties of the engine and the associated defined
contexts". But it doesn't.

 Craig? You and Pier are the only people to have touched
this, and Pier just re-indented.

 I know it seems trivial, but dead code (that's getting
maintained!) is evil. Especially when it's something as
confusing as Catalina startup code. The alternative is
that I'm wrong, and it is used for something. In that
case, the comments should be better. 

 I'm willing to either patch it out (should just be 
EngineRuleSet), or write some better comments, either
way.



-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[ANN] MinTC 0.6 Alpha "It's JSP-alicious"

[Christopher K. St. John]

 Big news for this release: initial JSP support, a
sucessful test of MinTC running a simple Apache XML-RPC
demo, and confirmation that MinTC will run on a Sharp
Zaurus. Watchdog results: "345 TEST(S) PASSED! 3 TEST(S)
FAILED!". This should be the last alpha.

Check it out at:

  http://www.distributopia.com

 MinTC is sort of a bizarro-world Catalina implementation.
Instead of being maxed out with features, it's small and
special-purpose. It requires no local file system access,
and can execute servlets and serve static content from
within its jar. Think web-enabling an application's admin
interface, or packaging a webapp as a zero-installation
standalone application.

 MinTC is good for Tomcat 4 because it keeps the Catalina
interfaces honest. If you're a Tomcat 4 developer it's
probably worth a look just to see other implementation
options.

MinTC is hard to compile, and probably will remain that
way until fairly late in the beta release cycle. If your
webapp runs with Tomcat 4, and you'd like to see if it
runs under MinTC, then drop me an email and we'll see
about getting you a special build.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

MinTC, "terrible rudeness", persistence

[Christopher K. St. John]

 I've been informed by private email that I am "terribly
rude" for making announcements of MinTC releases on the
tomcat-dev list, and that I should not make any futher
announcements. 

 So that's it then? I've been kicked off tomcat-dev (how
does that work on an open source project!?) because I've
offended someone by writing code they don't like!?!?

 This is a bit of a problem for me, as MinTC is, technically,
a version of Catalina, and should be a perfectly appropriate
topic for tomcat-dev. Especially when it's one message every
few weeks.

 MinTC is certainly not a mainline version of Tomcat 4, but
it shares a significant amount of (unforked) code, and that
makes it important to seek a close relationship with the
people maintaining the codebase. It's a bit like sharing a
telephone booth with an 800 lb gorilla: it's a bit much to
hope to have any influence over what phone calls are made,
but at least you can hope to make your presence know so that
you don't get sat on.

 It's a dilemma: there's no point in having an antagonistic
relationship with the core Tomcat developers, that's worse
than nothing. But good grief! This is an opensource project!
MinTC is a version of Catalina, where the heck else am I 
going to discuss it? I'm contributing bug fixes and code back
to the core implementation, I'm helping to clean up the core
interfaces, I'm using the Catalina code, I'm doing documentation
work, but I'm not welcome? That seems so strange, and so sad.

 I'd like to get some feedback from someone other than the
person who wrote me privately. Craig? Could you give me an
opinion please? You seem to have the moral leadership role
here. Anybody else, please chime in. I'm horrified that I might
have been being unknowingly rude, but I'm at a loss to explain
how exactly I've caused such awful offense. I honestly don't
get it.

 Thanks, and please, as you think about your response, keep in
mind that the Catalina proposal docs specifically talk about 
people doing exactly what MinTC does under the Catalina umbrella.

 Thanks, and sorry for any inadvertant rudeness,

-cks

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Pandora's box / can of worms etc.

[Christopher K. St. John]

Paul Wallace wrote:
> 
> What is MinTC? Where can I get information on it?
> 

 So as not to add flames to the fire, I'm replying privately :-)

 http://www.distributopia.com/

 It's sort of a bizarro world Tomcat. It takes the Catalina
interfaces (Container,Connector,Valve,all the stuff in
the org.apache.catalina package) and reimplements it for use
in embedded (as in embedded-in-your-application, not embedded
in-your-toaster) environments. It's substantially smaller,
but it gets that by having substantially fewer features than
Tomcat 4.

 It's in alpha. And I mean serious, dirt-under-your-fingernails
after-you-compile-it-if-it-even-compiles alpha. But it's a lot
of fun, and you should check it out (it's got an Apache-style
license, Open Source, etc, etc)


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Pandora's box / can of worms etc.

[Christopher K. St. John]

 Sh*t. That was supposed to be private, I wasn't trying
to be cute. Apologies.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: MinTC, "terrible rudeness", persistence

[Christopher K. St. John]

"Craig R. McClanahan" wrote:
> 
> a discussion of whether you'd want
> to propose contributing MinTC to the standard distribution (so that it
> could be built from the same source repository, and probably packaged
> separately) -- either now or when you get a little further along at
> complete success in passing all the tests.
> 

 I was planning to bring it up after version 1.0 was out. That
makes it easier to judge the code. And, to be honest, until a
couple days ago I wasn't really sure MinTC could be made fully
spec compliant. Multiple classloaders hitting the same jar is
kind of funky around the edges (especially on bleeping PJAE,
which has the crazy 1.1 "classloaders will not expose .class files
through getResource()" restriction. They'll give you .clazz files,
though )

 I was thinking something like a "contrib" directory might be
neat, but that's getting a little ahead of things.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: MinTC, "terrible rudeness", persistence

[Christopher K. St. John]

[EMAIL PROTECTED] wrote:
> 
> The point is not about developing multiple implementations - but about
> beeing a part of the community and proposing/discussing changes instead
> of posting announcements of a fork's releases.
> 

 Costin,

 My response got to be way too long, so here's just a summary.
It comes off as a bit clipped, but that's because it's short,
not because the questions were unreasonable :-)

 - I did discuss MinTC/MinimalTomcat on the dev list, check the
   archives. The topic didn't seem very popular, but I took that
   to mean I had weird requirements that few others shared. Later
   on, I started making announcements as a way to generate
   discussion and keep the core developers up-to-date.

 - It's not a fork. If it were a fork, I wouldn't care about the
   core code. But it's not, so I do. It's not Tomcat 4, but it
   is, by any reasonable definition, a version of Catalina.

 - It was always my intention to propose donating the code back
   to Apache, I should have been more clear about this. But I
   wanted to wait for the 1.0 release, for obvious reasons.

 - MinTC is not competition for Tomcat. You would have to be
   frigging insane to use MinTC if you could possibly use
   Tomcat 4 instead. But sometimes Tomcat 4 is difficult or
   impossible to use. That's not because Tomcat 4 is bad, it's
   just that it's full featured. I didn't think a patch
   to remove MBeans, JNDI and auto-deployment from the core
   would be well received :-) If you're interested, there's
   more detail on the MinTC page.

 Thanks for your feedback,


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

MinTC/Tomcat 4/Catalina. Conflict? No.

[Christopher K. St. John]

GOMEZ Henri wrote:
> 
> > I don't consider me a Tomcat 4.0 "core" committer, but that
> > patch would have my biggest +1 on Earth! :)
> >
> but a lighter TC 4.x will have my +1 and the current TC 4.0.x
> 'LE' mode is allready a good step in that direction.
> 

 Ok, time to change the subject line.

 I know this isn't what you all were talking about, but
I'm worried it could be confusing for those who haven't
followed the whole thread:

 MinTC is an insanely special-purpose container. Despite
the name, it isn't really a minimal-version of Tomcat 4,
it's something different (see the MinTC web page for
details). That's one reason I changed the name from
"MinimalTomcat" to "MinTC". Maybe the change wasn't big
enough.

 It's open source, and I will certainly provide help to
anyone who wants to do other stuff with it, but my personal
focus is on one or two very specific kinds of usage. If
things learned while developing MinTC turn out to be useful
for the next version of Tomcat, that would be really cool,
but I personally want to concentrate on keeping MinTC in
its (comfortable little) niche.

 Again: It's open source, I'm open to suggestions on other
uses, but my personal focus is very specific.


 Thanks for all the feedback. Even the negative stuff is
good (as long as it isn't so bizarrely rude and contemptuous
that I can't read it with a clear head!)


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: MinTC, "terrible rudeness", persistence

[Christopher K. St. John]

 Skip ahead to the "" section if
you're bored with the other topics in this thread.


[EMAIL PROTECTED] wrote:
> 
> But what you are doing is a fork by all definitions that
> I know.
>

 It's an alternative implementation of some of the Catalina
interfaces, but it's clearly not a fork. I'm using this as a
working definition: A fork refers to what you do in a revision
control system when you want to work independently on two
versions of the same code. By extension, on Open Source projects
it means taking a copy of the code base and  making your own
copy that isn't kept synchronized with the mainline branch. 

 MinTC steals a little bit of code from some of the 
o.a.c.core classes, but it doesn't copy any of them. What
it uses of the Catalina code, it uses completely intact
(I'm currently tracking CVS HEAD).

 So it's not a fork. Forks suck. Alternative API implementations,
on the other hand, are generally considered a good thing.
Some spec processes even require them!


> You must at least try first.
> 

 I did. Don't take my word for it, it's in the archives.




 I rejected the idea not because it was met with hostility
(I got good feedback), but because the discussion (on
tomcat-dev) convinced me that it was not the right
technical solution.

 It comes down to the fact that totally
generic code has some rather extreme practical drawbacks.
The classes within o.a.c.core,for example, need to be
able to depend to some degree on each other's innards.
As Craig said:

  "Within a particular package (org.apache.catalina.core),
   I don't see a problem with the classes depending on
   each other's insides -- the package as a whole is
   designed, as a unit, to provide the required functionality
   for that package."

 o.a.c.core's required functionality is simply very 
different than that of MinTC.  MinTC has such a different
audience that it didn't seem reasonable to
saddle Tomcat 4 with MinTC's requirements. Integrating
the two would require that every last bit of functionality
was somehow modularized out of Tomcat 4 core, and that's
undesirable.

 It's like making a combination jackhammer and framing
hammer just because they both have the word "hammer" in
their name. Sure, you could do it, but it would be silly.
Right tool for the right job, and all that.

 The whole "write very specific tools but make them
interoperate" thing ("The Unix Philosophy") isn't for
everyone. Some people prefer other approaches, like
extreme factoring and adding loads of hooks. It's all
good. Knowing MinTC is a Unix-philosophy sort of project
might make it easier to understand where I'm going
with it.



 Again, the feedback is good. It all helps, especially
the architecture discussion, even if it's negative.
(Although I can't help but wish some of the people 
commenting now would have piped up earlier :-)


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: MinTC, "terrible rudeness", persistence

[Christopher K. St. John]

Remy Maucherat wrote:
> 
> It has been developed separately (by you alone), with
> zero input from the Tomcat community
>

 Good grief Remy, it _was_ discussed on tomcat-dev, as
a quick search of the archives will show. You're spouting
complete BS here, and I wish you wouldn't.

 You're also obviously confused about what MinTC
is. It's all explained on the web page, and would be
obvious to anybody who had tried to run the code, but
I guess that's a bit much to expect.

 This is partially my fault for originally naming it
"MinimalTomcat". In retrospect, knowing more about the
awful destructive politics on this list, the name choice
was a terrible mistake. MinTC IS NOT a complete-but-minimal
replacement for org.apache.catalina.core, ok? 

 If you want to rant about MinTC, I'd appreciate it
if your rants were correct in the details. So go read
the web page, check the archives, take a look at the
code, and _then_ come back and tell me I'm an
anti-community idiot with stupid ideas, ok? 


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Using InstallAnywhere for Tomcat installer

[Christopher K. St. John]

GOMEZ Henri wrote:
> 
> I don't refuse anything, just expose that I'd rather like
> an OSS Java installer.
> 

 I've recently been pointedly reminded that I'm "not even a
committer", but as the project guidelines encourage developers
to comment and cast a nonbinding vote, I'll put on my
flameproof suite and agree that I would prefer an OSS installer
if at all possible.

 Using propriatary code has drawbacks like:

 - Unless the license is more liberal than I suspect, nobody
   but "official" Apache projects will be able to use the
   installer. Sometimes non-Apache projects do use Apache code,
   that's sort of half the advantage of being Open Source.
   Diluting that advantage would be a shame.

 - Contributing time and $$$ to a project that's being used
   as an advertisement for a potential competitor (that isn't
   contributing source code) is troubling. In this case not
   enough to make me (or probably anyone else) leave, but its
   annoying. If they want to participate, why don't they 
   make plans to donate source code like everyone else?

 - If you aren't on the official list of supported platforms,
   you're hosed. With an OSS solution, a frustrated user of
   an obscure platform can make it work and then contribute
   the solution back to the community.

 - Although perhaps a verboten topic for discussion, there's
   the whole Open Source thing. Using a commercial installer
   if Open Source options are available is troubling from
   a philisophical standpoint. If you really buy into the
   advantage of Open Source, why dilute those advantages?

 If there's currently not an OSS solution available, then in
the interest of expedience, I withdraw any objections. Which
sounds sort of funny since it's nonbinding anyway, but what
the heck.

 (Any personal email on this topic to /dev/null, keep it
public please.)


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Using InstallAnywhere for Tomcat installer

[Christopher K. St. John]

Kevin Grey wrote:
> 
> So in essence it works on any platform that has a JVM. 
>
 
 Nah, it only works fully on "officially supported" platforms.
Which makes sense, because the whole advantage of using a good
installer is that it paves over the nasty platform-specific
install issues. There's a list at:

  http://www.zerog.com/products_ia_01.html

 The key words are "Support for nearly every platform".


> InstallAnywhere is the best for Java apps, regardless of whether
> its proprietary or not.
> 

 I won't argue, I've never heard a bad thing said about
InstallAnywhere. But totally ignoring ethical issues is a bad
long-term strategy. Certainly Tomcat wouldn't exist at all if
it weren't for people considering some philisophical issues.

 Costin's suggestion to try it out in parallel with some of the
Open Source options seemed pretty reasonable. 


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Replacing WebappClassLoader

[Christopher K. St. John]

Volker Leidl wrote:
> 
> I tried to configure tomcat 4.0.2 to use my own class loader implementation
> for web-app class loading. The documentation implies that this can be done
> by secifying a "loaderClass" attribute in my Context/Loader element in
> server.xml.
>

 "Loader" specifies an org.apache.catalina.Loader object, not an
java.lang.ClassLoader. You'd need to do something like this:

package com.distributopia.mtc;

import java.io.*;
import org.apache.catalina.*;
import org.apache.catalina.loader.*;

public class TestLoader extends WebappLoader {
  public TestLoader(ClassLoader parent) {
super(parent);
System.out.println("TestLoader.TestLoader("+parent+")");
  }
  public void setDebug(int debug) {
System.out.println("TestLoader.setDebug("+debug+")");
super.setDebug(debug);
  }
  public void start() throws LifecycleException {
System.out.println("TestLoader.start()");
// instead of super.start(), do your own thing here
super.start();
  }
}

 Compile it, jar it up, copy it over to $TOMCAT_HOME/server/lib,
and you're set. Sort of.


> Stepping through the code of org.apache.catalina.loader.WebappLoader (which
> i still want to use) I found out that the loaderClass Property does get set,
> but it seems to be ignored since
> org.apache.catalina.loader.WebappClassLoader gets instantiated explicitly
> (line 615-, cvs revision 1.12.2.5).
> Is this intended? Perhaps I missed something in the code.
> 

 What the example above does is override the start() method. It
just re-dispatches it to the original, but what you'd need to do
is reimplement it to use your classloader, instead of the one
WebAppClassLoader uses.


> This does not work.
>

 Actually, neither does my suggestion, at leat not on HEAD. I
could have sworn it used to work, but maybe I just wasn't paying
enough attention to the log messages. Anyway, running the above
I get this:

ServerLifecycleListener: createMBeans: MBeanException
java.lang.Exception: ManagedBean is not found with TestLoader
at org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:374)

 I'll test further, but first I wanted to get some feedback on
whether I've made some stupid mistake. I kinda sorta half
suspect this is related to the way Tomcat hardcodes all the
MBeans  instead of generating them dynamically using reflection,
but I'm very unsure about it.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Replacing WebappClassLoader

[Christopher K. St. John]

"Christopher K. St. John" wrote:
> 
>  "Loader" specifies an org.apache.catalina.Loader object, not an
> java.lang.ClassLoader. You'd need to do something like this:
> 

 Ack. You were talking about the "loaderClass" attribute, not the
"className" attribute. I wasn't paying close enough attention,
sorry. But what I suggested is probably still your best bet if
you need to get this done without fixing WebappLoader to properly
use the "classLoader" attribute.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

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

jakarta-tomcat-connectors documentation/summaries

[Christopher K. St. John]

 A while back, I responded to Henri Gomez's email:

  "We will create really soon webpages for
   jakarta-tomcat-connectors"

 with an offer to summarize some of the recent discussion
about the various connectors currently available for 
Tomcat. Not to write new docs, just summarize the existing
docs and mailing list dicussions into a page with stuff
like:

  for each connector:
   pointer to source, any existint docs
   brief (one line) summary of the idea behind it
   brief (one line) history
   underlying protocol, pointers to definition
   who's working on it
   stable/development
   versions of tomcat it works with
   standalone or front end webserver?
   which webservers? for each: status
   popularity ranking
   pointers to comments about it on mailing lists

 I need to do the research anyway, in order to decide which
connectors to use, so I thought I'd offer to write it up.

 But ... I made the offer almost a month ago, and I wanted
to double check that somebody hadn't gone out and done all
the work in the meantime.

 So: Am I (hopefully :-) too late? Has anyone done this yet?
If not, I wanted to get most of it done this weekend.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: jakarta-tomcat-connectors documentation/summaries

[Christopher K. St. John]

 The following document is very incomplete, and in many
cases factually incorrect. The idea is to post it now, while
it's obviously in draft form, get feedback, and then clean it
up and publish it wherever would be most useful (jakarta-tomcat
connectors page, or the Tomcat FAQ)

 I'm currently tracking down user-level instructions for all the
connector/webserver/container combinations I can find, so pointers
to those are especially welcome. I'm not wedded to any of the listing
categories, or the format, or pretty much anything else, so if you
don't like it, speak up.





mod_jserv

 why it was written:
   it was there first. 

 where to get the source:
   java-jserv repository

 where to get documentation:
   java-jserv repository

 unerlying protocol:
   AJP11   

 works with:
   servlet containers:
 JServ
   web servers:
 old versions of Apache httpd
   operating systems:
 ???

 underlying protocol:
   AJP11


mod_jk

   should jk2 be listed out separately?

   why it was written:
 originally, clean-up of mod_jserv. 

   status:
 in production for tomcat 3, 4

   where to get the source:
 jakarta-tomcat-connectors/jk

   where to get documentation:
 jakarta-tomcat-connectors/jk
 tomcat-dev mailing list archives
 http://jakarta.apache.org/tomcat/tomcat-3.3-doc/mod_jk-howto.html
 http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/jk.html
 http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/jk2.html

   primary developers:
 evolved from mod_jserv (see above)
 Gal Shachor, IBM Research, Haifa Lab. refactored mod_jserv
 many others?

   works with:
 servlet containers:
   jserv?
   tomcat-3
   tomcat-4
 web servers:
   domino
   apache 1.3
   apache 2.0?
   netscape
   others?
 platforms:
   lots?

   it's big thing:
 production use

   underlying protocol:
 AJP, see mod_jserv
 evolution:
   AJP12, binary
   AJP13, better SSL support. the current protocol.
   AJP14, in testing. see "comments" below.

   special powers:
 load balancing with both tomcat 3 and tomcat 4

   documentation/mailing-list/cvs comments of interest:

   "Mod_jk v/s mod_webapp" on tomcat-dev: 

 Bill Barker wrote: "mod_jk2 is the next generation of mod_jk.  It
 is currently barely Alpha quality for Apache 2.x (and still
 subject to major changes from day-to-day)"

 <[EMAIL PROTECTED]>: "It works ( barely :-) with Apache2.x and
 1.3. The connector for apache1.3 can be used as a basis for
 updating IIS/iPlanet."

 costin: "Mod_jk works on all web servers and with all tomcat
 versions. Mod_jk2 will do the same."
 
 <[EMAIL PROTECTED]> : "What we called "ajp14" are a set of new
 APIs for config, shutdown, MD5 auth - added by Henri. Ajp14 API
 is not 'released', and the current plan is to postpone it after
 the first release of jk2"
 
 <[EMAIL PROTECTED]> : "it started with ajp11 and ajp12 ( first
 text based, second binary ).  Ajp12 evolved into ajp13 - using
 same encoding but with some extensions ( to deal with persistent
 connections ).

 "GOMEZ Henri" <[EMAIL PROTECTED]> : using jk instead of warp depend
 on webserver you want to have it.  If need today, or tomorrow
 IIS/NES/DOMINO, use mod_jk, if you only need to use Apache
 1.3/2.0 and have APR ready, you can use also mod_warp.

 costin: "jk had many developers contributing to it, more than any
 other tomcat component ( AFAIK ). It's also a matter of evolution
 - mod_jk started by implementing the ajp12 protocol and beeing
 backward compatible with mod_jserv ( actually a lot of code has
 been refactored from it ). You can still use mod_jserv with 3.x,
 and you can use mod_jk with anything from jserv to tomcat4."


 webapp

   you might see the terms "mod_webapp", "webapp" and "WARP", being
   used in a confusingly similiar way, but properly: mod_webapp - the
   apache module portion of webapp, WARP - the underlying protocol

   why it was written:
uses APR, tight tomcat 4 intergration

   status:
 ???

   where to get the source:
 jakarta-tomcat-connectors/webapp

   where to find documentation:
 jakarta-tomcat-connectors/webapp
 http://nagoya.apache.org/~pier/
 http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/webapp.html

   works with:
 tomcat versions:
   tomcat-4
   others?
 web servers:
   apache 1.3
   others?
 operating systems:
   "not windows"?

   underlying protocol:
 WARP

   special powers:
 tight webserver/container integration means simple deployments
 are very easy

   primary developers:
 Pier Fumagalli <[EMAIL PROTECTED]>
 others?

   mailing list/documentation comments:

   Pier Fumagalli <[EMAIL PROTECTED]> : "I just said that for what
   matters to me (meaning, for what I use 

Re: jakarta-tomcat-connectors documentation/summaries

[Christopher K. St. John]

 Ok, I'm maybe being thick here, but I want to make sure I've got this
straight. The idea is that anyone who's clueful enough to search the
archives is likely to come across the term "AJP14", so it's best to 
give them a hint (even if term isn't going to mean anything to somebody
who just wants to evaluate the current set of connectors)

 So, to confirm:

 AJP13 defines marshalling protocols. It also has
a command set that uses those marshalling protocols. AJP14 uses the
same marshalling protocol as AJP13, but extends the command set.
The distinction is important, because in the past major version
number changes in AJP meant an entirely new binary protocol.

 AJP14 is for the future, sometime after the release of jk2. It's
still being discussed.




-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com


 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: jakarta-tomcat-connectors documentation/summaries

[Christopher K. St. John]

 Another update. Same disclaimers as before.




FAQ's (just an idea, these don't have to be included)

 Q: Is mod_webapp replacing mod_jk?
 A: No. See below for links to documentation, then choose the one that
best suits your needs.

 Q: Is Coyote replacing mod_jk?
 A: Coyote isn't the same sort of thing as mod_jk, see below in the
"Coyote" section for more details.

 Q: It's all very confusing.
 A: Yes. A good strategy is to read through the summaries below and
follow some of the documentation links. If you still have
questions, try searching the tomcat-user mailing list archives,
someone has probably answered the question already, there may even
be a HOWTO already prepared. If that doesn't help, then you might
consider posting your question to tomcat-users.


non-jakarta howto's:

 these were culled from recent posts to tomcat-users. i have no way to
 judge if they are any good. it would be nice to only include the ones
 that someone can vouch for, but that may be too much work. the list
 is evolving...

 http://www.acg-gmbh.de/mod_jk/
   Apache 2.0/Tomcat 4/mod_jk/Win32

 http://www.pubbitch.org/jboss/
   Apache 2.0/Tomcat 4/mod_jk2/JBoss
   Apache 2.0/Tomcat 4/mod_webapp/JBoss

 http://bruno.vernay.free.fr/HowTo/bWebServerHowTo/index.html
   Apache ?.?/Tomcat 4/mod_webapp/Win32
   "references" link has list of other HOWTO's




mod_jserv

 although it's probably still in production use at some sites,
 mod_jserv generally shouldn't be considered for new installations.

 why it was written:
   it was there first. 

 where to get the source:
   jakarta-tomcat repository
   src/native/mod_jserv/

 where to get documentation:
   http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-apache-howto.html

   [ed] In tomcat-3.3-doc/index.html, it looks like mod_jserv is the
   suggested connector, and mod_jk is optional or alternative or
   something. It's my understanding that this is incorrect, and mod_jk
   should be used for new installations. It's a little confusing.

 unerlying protocol:
   AJP11 - original protocol
   Ajp12 - also supported in mod_jk1.

 works with:
   servlet containers:
 JServ
 Tomcat3.x as well ( which supports ajp12 )
   web servers:
 All apache1.3 versions
   operating systems:
 ???


mod_jk

   why it was written:
 originally, clean-up of mod_jserv. Refactoring of mod_jserv to
 better abstract the server and protocol.

   features:
 many production users. load balancing with both tomcat 3 and
 tomcat 4 <[EMAIL PROTECTED]> "Pretty good OO model, good
 abstraction for server and protocol, etc."

   future: 
 mod_jk2, as of [30 Apr 2002] still in pre-alpha.

   status:
 in production for tomcat 3, 4. see also webapp connector.

   where to get the source:
 jakarta-tomcat-connectors/jk

   where to get documentation:
 jakarta-tomcat-connectors/jk
 tomcat-dev mailing list archives
 http://jakarta.apache.org/tomcat/tomcat-3.3-doc/mod_jk-howto.html
 http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/jk.html
 http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/jk2.html

   works with:
 servlet containers:
   jserv?
   tomcat-3
   tomcat-4
 web servers:
   domino
   apache 1.3
   apache 2.0 (HEAD)
   netscape
   AOLServer ( not in the main tree ).
   IIS
 platforms:
   many.

   underlying protocol:
 AJP, see mod_jserv
 evolution:
   AJP12, binary
   AJP13, better SSL support. the current protocol.
   AJP14, there is no AJP14, it's a shelved experiment. AJP13 is
 flexible enough for future growth, and there's the
 possibility of eventually moving to an industry-standard
 marshalling protocol like XDR or CDR. see comments below.

   documentation/mailing-list/cvs comments of interest:

   Re: [NITPICK] didn't see this one coming...
   Mon, 29 Apr 2002 07:54:09 -0700 (PDT)
   <[EMAIL PROTECTED]>
... Note that mod_jk2 is not and will not be ready
for 4.1 ...

   <[EMAIL PROTECTED]> "Also - it's [mod_jk -ed] the area/component of
   tomcat with the largest number of individual commiters ( by my
   count at least ). And more important - one of the things that 3.x
   and 4.x share and seem to bring cooperation from both sides."

   "Mod_jk v/s mod_webapp" on tomcat-dev: 

 Bill Barker wrote: "mod_jk2 is the next generation of mod_jk.  It
 is currently barely Alpha quality for Apache 2.x (and still
 subject to major changes from day-to-day)"

 costin: "Mod_jk works on all web servers and with all tomcat
 versions. Mod_jk2 will do the same."
 
 <[EMAIL PROTECTED]> : "it started with ajp11 and ajp12 ( first
 text based, second binary ).  Ajp12 evolved into ajp13 - using
 same encoding but with some extensions ( to deal with persistent
 connections ).

 "GOMEZ Henri" <[EMAIL PROTECTED]> : using jk ins

RE: jakarta-tomcat-connectors documentation/summaries

[Christopher K. St. John]

 Another update. Same disclaimers as before.




FAQ's (just an idea, these don't have to be included)

 Q: Is mod_webapp replacing mod_jk?
 A: No. See below for links to documentation, then choose the one that
best suits your needs.

 Q: Is Coyote replacing mod_jk?
 A: Coyote isn't the same sort of thing as mod_jk, see below in the
"Coyote" section for more details.

 Q: It's all very confusing.
 A: Yes. A good strategy is to read through the summaries below and
follow some of the documentation links. If you still have
questions, try searching the tomcat-user mailing list archives,
someone has probably answered the question already, there may even
be a HOWTO already prepared. If that doesn't help, then you might
consider posting your question to tomcat-users.


non-jakarta howto's:

 these were culled from recent posts to tomcat-users. i have no way to
 judge if they are any good. it would be nice to only include the ones
 that someone can vouch for, but that may be too much work. the list
 is evolving...

 http://www.acg-gmbh.de/mod_jk/
   Apache 2.0/Tomcat 4/mod_jk/Win32

 http://www.pubbitch.org/jboss/
   Apache 2.0/Tomcat 4/mod_jk2/JBoss
   Apache 2.0/Tomcat 4/mod_webapp/JBoss

 http://bruno.vernay.free.fr/HowTo/bWebServerHowTo/index.html
   Apache ?.?/Tomcat 4/mod_webapp/Win32
   "references" link has list of other HOWTO's




mod_jserv

 although it's probably still in production use at some sites,
 mod_jserv generally shouldn't be considered for new installations.

 why it was written:
   it was there first. 

 where to get the source:
   jakarta-tomcat repository
   src/native/mod_jserv/

 where to get documentation:
   http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-apache-howto.html

   [ed] In tomcat-3.3-doc/index.html, it looks like mod_jserv is the
   suggested connector, and mod_jk is optional or alternative or
   something. It's my understanding that this is incorrect, and mod_jk
   should be used for new installations. It's a little confusing.

 unerlying protocol:
   AJP11 - original protocol
   Ajp12 - also supported in mod_jk1.

 works with:
   servlet containers:
 JServ
 Tomcat3.x as well ( which supports ajp12 )
   web servers:
 All apache1.3 versions
   operating systems:
 ???


mod_jk

   why it was written:
 originally, clean-up of mod_jserv. Refactoring of mod_jserv to
 better abstract the server and protocol.

   features:
 many production users. load balancing with both tomcat 3 and
 tomcat 4 <[EMAIL PROTECTED]> "Pretty good OO model, good
 abstraction for server and protocol, etc."

   future: 
 mod_jk2, as of [30 Apr 2002] still in pre-alpha.

   status:
 in production for tomcat 3, 4. see also webapp connector.

   where to get the source:
 jakarta-tomcat-connectors/jk

   where to get documentation:
 jakarta-tomcat-connectors/jk
 tomcat-dev mailing list archives
 http://jakarta.apache.org/tomcat/tomcat-3.3-doc/mod_jk-howto.html
 http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/jk.html
 http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/jk2.html

   works with:
 servlet containers:
   jserv?
   tomcat-3
   tomcat-4
 web servers:
   domino
   apache 1.3
   apache 2.0 (HEAD)
   netscape
   AOLServer ( not in the main tree ).
   IIS
 platforms:
   many.

   underlying protocol:
 AJP, see mod_jserv
 evolution:
   AJP12, binary
   AJP13, better SSL support. the current protocol.
   AJP14, there is no AJP14, it's a shelved experiment. AJP13 is
 flexible enough for future growth, and there's the
 possibility of eventually moving to an industry-standard
 marshalling protocol like XDR or CDR. see comments below.

   documentation/mailing-list/cvs comments of interest:

   Re: [NITPICK] didn't see this one coming...
   Mon, 29 Apr 2002 07:54:09 -0700 (PDT)
   <[EMAIL PROTECTED]>
... Note that mod_jk2 is not and will not be ready
for 4.1 ...

   <[EMAIL PROTECTED]> "Also - it's [mod_jk -ed] the area/component of
   tomcat with the largest number of individual commiters ( by my
   count at least ). And more important - one of the things that 3.x
   and 4.x share and seem to bring cooperation from both sides."

   "Mod_jk v/s mod_webapp" on tomcat-dev: 

 Bill Barker wrote: "mod_jk2 is the next generation of mod_jk.  It
 is currently barely Alpha quality for Apache 2.x (and still
 subject to major changes from day-to-day)"

 costin: "Mod_jk works on all web servers and with all tomcat
 versions. Mod_jk2 will do the same."
 
 <[EMAIL PROTECTED]> : "it started with ajp11 and ajp12 ( first
 text based, second binary ).  Ajp12 evolved into ajp13 - using
 same encoding but with some extensions ( to deal with persistent
 connections ).

 "GOMEZ Henri" <[EMAIL PROTECTED]> : using jk ins

Re: jakarta-tomcat-connectors documentation/summaries

[Christopher K. St. John]

"Christopher K. St. John" wrote:
> 
>  Another update. Same disclaimers as before.
>

 Mail client mishap, second one's a duplicate, sorry.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com



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

Re: jakarta-tomcat-connectors documentation/summaries

[Christopher K. St. John]

"Ignacio J. Ortega" wrote:
> 
> >Re: jakarta-tomcat-connectors documentation/summaries pier: "There
> >were some other motivations when it all started...

 Hmmm. The theory is that the document should be absolutely 100%
non-controversial. Other parts of the entry already emphasize ease
of use, so I don't think removing the quote would change the 
meaning. Is that acceptable to everyone, including Pier? If not,
let me know, otherwise the quote goes. 


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: jakarta-tomcat-connectors documentation/summaries

[Christopher K. St. John]

"Ignacio J. Ortega" wrote:
> 
> > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Enviado el: jueves 2 de mayo de 2002 5:16
> 
> For me is controversial to have a document at jakarta, that affirms
>

 Speaking of having a document at jakarta, it isn't there yet.
And it won't go live unless everyone likes it (think "We are the
world" as sung by a chorus of tomcat developers, all holding
hands, etc). So no worries. 

 I think it may have reached the "better than nothing" stage,
and I'd like to start formatting and cleanup. That presupposes
a destination. I originally talked to Henri Gomez about hanging
it off a jakarta-tomcat-connectors page, but Glenn Nielsen also
mentioned a Tomcat FAQ. 

 Where should it go?


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Using NIO package for Tomcat connector?

[Christopher K. St. John]

"Setera, Craig" wrote:
> 
> Using NIO would lower the number of required threads and
> buffers/objects that would need to be created.
>

 The core servlet model can't really be converted to
using non-blocking I/O. The whole point is that your
servlet gets its own thread. On the other hand, other
servlet containers have been doing things like using
NIO to watch idle persistent connections, and there
look to be great opportunities for improving standalone
Tomcat's performance in sending static files.

 There are some threads in the tomcat-dev archives you
might want to check out.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Ethereal AJP13 dissector?

[Christopher K. St. John]

 I was doing some debugging and sort of accidentally ended
up writing most of an AJP13 dissector for ethereal. A proper
dissector is much easier to deal than raw ethereal captures
if you're not an AJP13 guru. It didn't occur to me until
afterwards that somebody else might have already done it.

 If nobody has already written one (and anyone is interested)
I'll clean it up and publish it. I suspect it belongs in
with the rest of the dissectors over in the ethereal tree
rather than in with the tomcat connector code, but I'm open
to suggestions.

 If anyone is interested in helping to test, or wants to get
a preview of AJP13 all dissected and gui'ed up, I can post
the code wherever's appropriate.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Ethereal AJP13 dissector? [Ethereal patch attached]

[Christopher K. St. John]

jean-frederic clere wrote:
> 
> I am rewritting the Ajp protocol documentation. A protocol
> analyser would help me.
>

 The analyzer was written using the existing docs, so
if there are problems in the docs the analyzer will
be wrong as well.


> So please send it. (Even if it is not run and not clean).
>

 Some of the code is a bit iffy, and it's definitely a
work in progress, but it runs. I did some cleanup and put
in some comments. I've attached a patch to Ethereal 0.9.4,
which you can get at:

 http://www.ethereal.com/

 Make sure you have a recent version of libpcap. If you
want to hack on it, there are Ethereal developer docs in
docs/README.developer, but they are very out of date.

Notes:

 It autodetects 8009 as AJP traffic. It doesn't decode FORWARD_REQUEST
attributes (the optional stuff at the end). There are problems with
the protocol hierarchy display. There are probably memory leaks. The
protocol display could be easier to read. You need ethereal-0.9.4,
I'm confident it won't work with earlier versions, and I haven't
tested against CVS. There are lots of compiler warnings, many of them
legitimate.

Install:

 
 $ cd $PATH_TO_ETHEREAL/ethereal-0.9.4
 $ patch < $PATH_TO_PATCH/eth-ajp13.patch
 patching file Makefile.am
 patching file Makefile.nmake
 patching file packet-ajp13.c
 patching file packet-ajp13.h
 patching file register-static.c
 $ ./configure
 $ make 
   
 $ su
 # ./ethereal
   < make sure that Edit -> Preferences -> Protocols -> TCP 
 "Allow subdissectors to desegment TCP streams" is set
 to true >
Start -> Ok> # try "update packets in real time"
   
   


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com


eth-ajp13.patch.gz
Description: Binary data

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: mx for jk

[Christopher K. St. John]

[EMAIL PROTECTED] wrote:
> 
> In case you didn't noticed, I checked in a small 'magic' util that
> turns Jk components into dynamic MBeans.
> 
> It still doesn't support the 'descriptions' and the ability to
> fine tune the exposed attributes/methods, that will be added later
> ( and will probably require xdoclet or a similar tool ).
>

 This sounds a bit like o.a.commons.modeler. (modeler
provides code to fill in MBean meta-data based on an external
xml file, see o.a.catalina.mbeans.mbeans-descriptors.xml)

 Is the magic jk code related, a replacement, or just something
completely different?


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Can we write our own connector

[Christopher K. St. John]

Chandra Talluri wrote:
> 
> Is it possible to write our own connector using catalina. If so
> can some one point me to the proper documentation
> 

 It depends on exactly what you're trying to do. There are 
two (closely connected) ways that the term "connector" is
used. First, Catalina has an interface called "Connector"
that is the external hook for all request processing. 

 Second, small-c "connector" normally means the code that
allows a servlet container to talk to a front-end web server
like Apache. Small-c connectors are generally made up of 
some native code that hooks into the front-end web server
(like mod_jk for Apache) and some Java code over on the
servlet container side.

 Which one do you mean? And why, exactly, do you want to
do this? There may be a better way. Writing a new connector
(or Connector) is certainly possible, but it's not for the
faint of heart :-)

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Can we write our own connector

[Christopher K. St. John]

Chandra Talluri wrote:
> 
> We have our own server which accepts the data either on a TCP
> port or a UDP port. 
>

 "the data" is a little vague. What does the data look
like? What does the server actually do, right now? What's
it for? The more specific you can be about what you're
trying to do, the more likely it is you'll get an answer.


> Basically we want to integrate the catalina.jar and other
> required jars in our server so that our server can invoke
> the servlets.
>

 So you want two things:

  1) To embed Tomcat 4 inside your application.

  2) To replace Tomcat 4's default HTTP and JK
 connectors with your own, custom Connector
 that deals with your custom, unspecified,
 non-HTTP protocol.

 Is that correct? Both of those things are certainly
possible (assuming your secret protocol is more or less
similiar to HTTP), but neither one of them is a beginner
level project. Check out the code for:

 org.apache.catalina.Connector
 org.apache.catalina.startup.Embedded

 Documentation-wise, what you see is what you get. 
You're much more likely to get an answer if you
ask very specific, closed-end questions, esp. if
you refer to actual code.

 
-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

watchdog, servletapi, karma

[Christopher K. St. John]

 I'd like to check in some (fairly minor) fixes to
jakarta-servletapi-4 and jakarta-watchdog-4.0, but I don't have
the karma. Is it a big deal to get added?

 I wasn't sure if servletapi and watchdog were closely tied to
tomcat or their own whole "thing" with separate administration.
It looks like there's been no recent traffic to servletapi-dev,
and minimal traffic to watchdog-dev, instead everybody just
posts to tomcat-dev, so...

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: watchdog, servletapi, karma

[Christopher K. St. John]

GOMEZ Henri wrote:
> 
> > I'd like to check in some (fairly minor) fixes to
> >jakarta-servletapi-4 and jakarta-watchdog-4.0, but I don't have
> >the karma. Is it a big deal to get added?
> 
> Will you apply some patches to jakarta-servletapi-4 code ?
>

 Well, I wanted to apply a patch for a bug I reported a while
back where GenericServlet.init() and destroy() send messages
(saying "init" and "destroy") to log(). It's not a showstopper,
but it's very annoying. If someone else wants to remove the
two log() statments, that would be great.

 Or do you mean "you (Henri Gomez) have some patches and want
somebody to apply them? If I had the karma, and the patches
were righteous (and I suspect they would be), then sure.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: watchdog, servletapi, karma

[Christopher K. St. John]

GOMEZ Henri wrote:
> 
> No, I saw a problem here since servlet-api-4.0 is the OFFICIAL
> servlet 2.3/jsp1.2 API and may not change without (wide) notice.
> 

 Yes, but there's a difference between changing the API (which
is the job of the servlet spec jsr team) and fixing bugs in the
implementation classes. I'd be perfectly happy if somebody else
would just fix the bug, but nobody seems to be maintaining the
code at the moment.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PROPOSAL] Minor fix for servletapi-4 GenericServlet

[Christopher K. St. John]

GOMEZ Henri wrote:
>
> I propose you to make a PROPOSAL for servletapi4 patch
> to tomcat-dev list.
> 

 In the jakarta-servletapi-4 repository, the class:

   javax.servlet.GenericServlet

 has init() and destory() methods that call log(). While
not specifically prohibited in the 2.3 spec, it results
in unncessary output into logs. Also, it's annoying.

 My proposal is to remove the two log() statements from
GenericServet.init() and GenericServlet.destory(). If
somebody needs them for debugging, they can add them
back into their local copy.

 This was reported as bug #7190. I've included a patch
as an attachment to this message (it just removes the
two log messages and updates the copyright date)

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com


jsa4-gensrv.patch
Description: Binary data

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Minor fix for servletapi-4 GenericServlet

[Christopher K. St. John]

"Christopher K. St. John" wrote:
> 
> GOMEZ Henri wrote:
> >
> > I propose you to make a PROPOSAL for servletapi4 patch
> > to tomcat-dev list.
> >
>  My proposal is ... [delete log() msgs in GenerisServlet]
>

 From my reading of the project guidelines, minor fixes like
this normally go the commit-then-review route, so I'm unclear
if there need to be 3 +1's before any action is taken. There's
just been the one (by Remy) so far.

 I realize it isn't a very exciting patch :-), but minor
bugs need love too, so a couple more +1's (or a -1 if there
is some problem) would be nifty.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

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

Re: watchdog, servletapi, karma

[Christopher K. St. John]

Ryan Lubke wrote:
> 
> You can send me the Watchdog patches and I'll look them over.
> 

My original failed tests turned out to be my fault. I
didn't update my servlet-test.war. I downgraded the
severity of 9794 from "Blocker" to "Normal", since it
turns out there really are problems.

The Watchdog GTest "HTTP" engine reads body content
through a filter that maps CRLF into a single LF. That
means a golden file (which uses plain LF as EOL) can be
compared with a response that was generated using
PrintWriter.println() on an O/S that uses either LF or
CRLF as EOL. That leads to some weirdness.

First off, systems that use plain CR as EOL, like old
Macs, will presumably fail tests. That isn't such a big
deal, because old Macs don't run Java 2, but it isn't good
for a conformance testing tool to have that sort or
problem built in.

More importantly, systems that use single char EOL's are
now generating illegal HTTP but still passing the
tests. For example, on Unix, the SetContentLength servlet
indicates a content-length of 33 but only sends 32
characters. This works because all the tests are currently
hardcoded to be HTTP/1.0, which closes the stream at the
end of the body. But's it's wrong. Try:

  $ wget http://localhost:8080/servlet-tests/SetContentLengthTest

Long term, Watchdog probably needs to move to a proper
HTTP client library.

Medium term the places where Watchdog servlets use
println("data") need to be changed to use
print(data+"\r\n") or print(data+"\n") or whatever, as
long as they do it consistently, and the number of magic
constants needs to be minimzied.

Short term, I fixed SetContentLengthTestServlet and
ServletResponseWrapperSetContentLengthTestServlet to both
hardcode CRLF instead of depending on println(). (see the
attached patches)

I'd like to get rid of the mystery constants "2" and "48",
but that would involve a further rewrite, and I wanted to
hold off until there was some discussion about the
appropriate med/long term solution.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com


sclt_eol.patch
Description: Binary data


srwsclt_eol.patch
Description: Binary data

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: What is the Container implementation for HttpConnector

[Christopher K. St. John]

Chandra Talluri wrote:
> 
> I am having trouble finding out the Container implementation for
> HttpConnector or any connector.
>

 I'm not sure what you mean. Connector doesn't implement 
Container. Or are you asking something else?


> Can some one tell me which is the Container and where the
> connector.setContainer being called
> 

 org.apache.catalina.core.StandardService.setContainer()
calls setContainer() on all its Connector children. 
Grep+xarg is a good combo if you're on Unix, or there
are IDE's that will let you search the code. But that
may just move your question up a level, "how does 
StandardService.setContainer() get called", etc, etc.

 It's all driven off conf/server.xml using code based
in org.apache.catalina.startup. The server.xml docs
are a good intro to how it all fits together:

 http://jakarta.apache.org/tomcat/tomcat-4.0-doc/config/index.html

 In theory, you can set up server.xml with any sort of
Container hierarchy you want. In practice, your object
structure is going to look like the examples in the
config docs.

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Minor fix for servletapi-4 GenericServlet

[Christopher K. St. John]

GOMEZ Henri wrote:
> 
> Did we have to make a general announce about this API
> changes ?
> 

 There are only 5 committers for servletapi-4, and 
none of them appears to be active right at the moment.
I agree that there has been way too much discussion
about what is basically a trivial fix, but I'm not
clear on how bugs (as opposed to actual API changes
from the JSR group) are supposed to get fixed.


> Which make me think we need a stable tarball/jar/zip
> for servlet-api4
> 

 +1, I dislike having "download the latest nightly
snapshot" in build docs. But how does that happen?


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Apache 1.3/jk2, redirects, redux

[Christopher K. St. John]

 jk/java/org/apache/jk/JkCoyoteHandler ACTION_CLOSE is getting
called with no call to ACTION_COMMIT when:

 - jk2 is being using with Apache 1.3 and
 - there's a redirect (like with a welcome page)

 Quick fix is to have JkCoyoteHandler CLOSE commit if the
response hasn't already been committed:


  } else if( actionCode==ActionCode.ACTION_CLOSE ) {
org.apache.coyote.Response res=(org.apache.coyote.Response)param;
if (!res.isCommitted())
  this.action(ActionCode.ACTION_COMMIT, param);

 But the code is (presumably, I haven't checked) working fine
for non-Apache 1.3 setups, and I hate to make a change without
understanding where the real root of the problem is. Hints
appreciated.

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Proposal draft for Tomcat 5.0

[Christopher K. St. John]

Remy Maucherat wrote:
> 
> I'm committing a draft for a Tomcat 5 proposal.
> It is a draft, so it is not in final form yet (it needs feedback for that).
> 

 Re-architecting Tomcat yet again is a bad step if it's not
absolutely necessary. I have some reservations. To keep from
confusing the issue, I'll list them in separate messages.

  "In criticism I will be bold, and as sternly,
   absolutely just with friend and foe. From
   this purpose nothing shall turn me." - Edgar
   Allen Poe


> while at the same time adding support for the new Servlet
> API 2.4 and JSP 2.0 specifications
>

 Reservation #1: There is a new architecture being proposed,
but since the 2.4 API isn't out yet, all the requirements aren't
available. So there's no intelligent way to judge if the
architecture fits well with the primary requirement (which is
being a good 2.4 container)

 Tomcat 5 isn't some sort of generic server framework, it's
the reference implementation for the 2.4 spec. The spec is
central.



-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Proposal draft for Tomcat 5.0 : #1: 2.4 spec

[Christopher K. St. John]

[EMAIL PROTECTED] wrote:
> 
> I hope the 2.4 API will not do any crazy things
>

 Me too.

 One of the things I heard mentioned was tighter integration
with the NIO api's, which could affect both low and high level
layers. OTOH, maybe not, I haven't seen the spec. But that's
the whole point.



-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Proposal draft for Tomcat 5.0 : #2 Tradeoffs

[Christopher K. St. John]

 Ok, second round.

 People are +1'ing the _goals_ of the proposal, but I
the proposal itself doesn't give sufficient detail to
determine if the recommended actions will actually 
lead to those goals being accomplished.

 Some of the goals even appear to be contradictory,
but there's no discussion of the inevitable engineering
tradeoffs. Simplicity vs Flexibility is a big issue.

 For example, the Coyote framework is compatible with
Tomcat 3 and Tomcat 4. This is admirable, and may lead
to closer ties between the two groups of developers.

 BUT Coyote is also more complicated and harder to
understand than the HTTP connector code in Tomcat 4 that
it replaces. It does more, too, but let's face it, it's
an integrated framework for writing connectors, and
frameworks are harder to understand and build than
single-purpose code.

 That isn't to say it wasn't worth it, but you've gone
from only needing to understand o.a.c.connector to having
to understand a whole slew of packages and patterns and
conventions. There's more buy-in required.

 I'd like to see considerably more discussion about
tradeoffs before the proposal is approved.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Proposal draft for Tomcat 5.0 : #2 Tradeoffs

[Christopher K. St. John]

[EMAIL PROTECTED] wrote:
> 
> On Fri, 21 Jun 2002, Christopher K.  St.  John wrote:
> 
> >  People are +1'ing the _goals_ of the proposal, but I
> > the proposal itself doesn't give sufficient detail ...
> 
> That's exactly the target - to set the goals and the overal
> direction ( it's a 'long-term plan' ).
>

 The proposal lists a set of goals (like "simpler" and
"more flexibile") and a set of actions to acheive those
goals (like "make Coyote the core of Tomcat 5").

 I (more or less) agree with the goals, but I have some
reservations about the proposed course of action.

 I would hope that many others on this list would also
have questions, since the proposal itself is too vague to 
base a decision on. (Although your answers to my questions
are helping, thanks)


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

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

Re: Proposal draft for Tomcat 5.0 : #2 Tradeoffs

[Christopher K. St. John]

[EMAIL PROTECTED] wrote:
> 
> But most of the stuff is needed to get decent
> performance - and to be able to support other protocols
> and have better integration with the server.
> 

 - What are the peformance goals? Actual numbers or a 
   percentage improvement goal is something that I would
   really like to see in the proposal. 
 
 - Conventional wisdom is that performance tuning code makes
   it more complex, not simpler.

 - Layering the code, so that different protocol implementation
   can be plugged in, is likely to reduce performance. And make
   the code more complicated. For best  performance, you want
   to skip the layering and framework code entirely and make
   everything special-purpose.

 - Better integration with the server makes the code more
   complex. Integration with multiple servers (like Tomcat 3,
   Tomcat 4 and Tomcat 5) would normally add quite a bit
   of complexity.

 Performance, flexibility and simplicity are at odds with
one another. This is a basic engineering truth, and you're
going to have a tough time convincing me it doesn't apply
here.


> There are many things that are hard or impossible with o.a.ajp.
> ...
> the point is
> you can't get too much performance without good buffer management,
> byte[], optimized conversions, etc.
> 

 Ok, but that's an argument for rewriting o.a.ajp, not for
making Coyote the core of Tomcat 5. Is there something about
the interfaces defined in Catalina that makes optimizations
impossible? 

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Proposal draft for Tomcat 5.0 : #3 Straw Man

[Christopher K. St. John]

[EMAIL PROTECTED] wrote:
> 
> If you can clarify your concerns - do you disagree with Coyote
> entirely ( and why ), is it something missing that you want
> added or something that is there and you feel shouldn't ?
> 

 Fair enough. I think part of the problem is that one
of the primary goals of the proposal appears to be to 
find common ground between the Tomcat 3 and Tomcat 4 
camps. I have the sneaking suspicion that the code should
be the primary concern.

 A straw-man proposal might help to clarify my worries.
(it's not a real proposal, I'm looking to be told what
my incorrect assumptions are)

 From the standpoint of supporting the 2.4 spec (totally
ignoring the 3/4 thing), it seems like this might make
more sense:

 - A represenative set of benchmarks is agreed upon,
   in advance, and tests are run to determine what
   Tomcat 4 performance is like now, where the
   bottlenecks are (based on profiling, not intuition),
   and performance goals are set for Tomcat 5. What
   needs to be faster? Static file serving? HelloWorld?
   JSP's? How much faster? Exactly? etc, etc.

 - The most ugly bits of Tomcat 4 are listed, and a
   subset of them is set aside to be fixed. I've chosen
   the startup code and tomcat events/listeners as my
   biggest concerns for this straw-man, but I'm sure
   there are others. It's mainly the process of choosing
   actual, concrete problems (instead of generalities)
   that I think it important.

 - Tomcat 5 is Tomcat 4 with lots of cleanup work and
   modifications for whatever the 2.4 spec comes up
   with. There are no major architectural changes. OTOH,
   the 2.4 spec could be bizarre, in which case all bets
   are off :-)

 - Coyote is not part of Tomcat 5. Instead, Tomcat 5
   moves to having 2 (and only 2) connectors that are
   single-purpose no-compromise performance demons:

 - A special-purpose HTTP connector built to take
   full advantage of Tomcat 4, with a few layers
   of abstraction as possible, using the existing
   o.a.c.Connector API. This results in the smallest,
   fasted code possible. 

 - A special-purpose AJP connector. Again, single
   purpose, build for Tomcat 5 only, using the 
   existing o.a.c.Connector API, and again,this
   results in the least possible amount of code.

 - Other connectors can be implement in j-t-c as 
   needed, maybe as Coyote. Experiments like JNI, etc
   shouldn't be a consideration for the core Tomcat 5
   design. There should probably also be some work
   with the NIO api's non-blocking stuff, ala what
   Greg Wilkins has done with Jetty, but again this
   is non-core.

 - Tomcat 5 cleans up the current startup spaghetti
   by going through each and every Tomcat event listener
   and deciding if it needs to be made into a real,
   explicitly called API. Listeners should be hooks
   for extensions, making them them implement core
   functionality makes for a tangled mass of pointers
   and a very confusing startup sequence. Pretty much
   everything but the management listeners need to go.

   After most of the listeners are removed, the set
   of Tomcat events is rationalized and documented.
   This is a big deal. This code is an undocumented
   mess.

 - There are places where the Standard* classes make
   ugly assumptions about one another. This needs to
   be examined on a case-by-case basis, and most of
   the really ugly stuff needs to be removed, or the
   assumptions need to be made into real method calls
   in the top-level interfaces.

 - Other stuff, but since this is a straw man only,
   I think you get the idea.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Proposal draft for Tomcat 5.0 : #3 Straw Man

[Christopher K. St. John]

[EMAIL PROTECTED] wrote:
> 
> I can tell I spent
> few months with almost daily runs in OptimizeIt and
> several 'ab' per day.
> 

 Hold on. It sounds like you think I'm saying you
didn't do your homework. I'm not saying you don't
know this stuff, I'm saying that there aren't pointers
to this work in the proposal.

 What I'm definitely not doing it taking your word
for it. I don't even take my own word for stuff
like this, so it has nothing to do with you
personally.

 ab really isn't sufficent for what I'm taking about,
though. It produces extremely skewed results. It's
something of a blunt instrument.

 How about this for a concrete suggestion: Add "come
up with a set of benchmarks and performance goals" as
part of the proposal. (And yes, I'm volunteering to
help)


> Let me ask a question - how much time have you spent
> benchmarking and profiling tomcat ? 
>

 Part time over the course of about 4 weeks. I was
investigating how much of a performance improvement
I could get out of using the NIO api's for serving
static files, and part of that was comparing against
the performance of other servers written in Java.
That was pre-Coyote, though. 

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Proposal draft for Tomcat 5.0 : #3 Straw Man

[Christopher K. St. John]

Remy Maucherat wrote:
> 
> >  - Tomcat 5 is Tomcat 4 with lots of cleanup work and
> >modifications for whatever the 2.4 spec comes up
> >with. There are no major architectural changes. OTOH,
> >the 2.4 spec could be bizarre, in which case all bets
> >are off :-)
> 
> My proposal is not very different from that.
>

 Maybe I'm just hung up on some of the wording, then. I'd
like to see specifically:

 - An item about coming up with a set of benchmarks and
   performance goals as a priority. My BS alarms go off
   when people discuss performance outside of an agreed
   upon set of benchmarks (even if I know them to be 
   smart developers who probably have really done the
   bencharks and profiling)

 - Details about how the existing Catalina JXM management
   interfaces will be merged with Coyote JXM management
   code. Or at least an acknowledgement that it's an issue.

 - A listing of specific issues with Tomcat 4's current
   implementation. for example, the startup code is opaque,
   it's unclear what events get sent when, etc. The 
   important thing is that there's a specific list of
   problems that need to be solved.

 - And (I may be reaching here), Coyote is moved from being
   "core" to being "the connector architecture".



> BTW, maybe you consider all that ugly, but I don't. I find
> the XML Mapper / Digester pretty cool 
>

 I really like the Digester. I was referring specifically
to how non-optional parts of the core implementation (like
ContextConfig) are added as listeners instead of being
called explicitly. They look like they should be pluggable,
but the way they're implemented right now, they're not.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Proposal draft for Tomcat 5.0 : #3 Straw Man

[Christopher K. St. John]

Remy Maucherat wrote:
> 
> >  - Details about how the existing Catalina JXM management
> >interfaces will be merged with Coyote JXM management
> >code. Or at least an acknowledgement that it's an issue.
> 
> The beauty about JMX is that you don't have to merge anything. 
>

 It's obviously a bit silly to have part of Tomcat 5
using one set of utilities for JXM, and part using
something else. It definitely makes the code harder
to understand and maintain.

 A good, higher level goal might be:

 - Move towards a single framework for JMX management
   of Tomcat 5 components.

 Note how this give you something concrete to shoot for
(or argue with). 

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: