Return of the Bug?: File upload does not work with with Apache/Tomcat using the ajp13 connector

[Ken]

I have an application under development on webappcabaret.com. It includes a
file upload page which uses the oreilly servlet package.
I recently discovered that the file upload was failing (previously having
worked OK) with the log reporting
"Corrupt form data: premature ending". A visit to servlet.com revealed that
this is a known bug, with the recommended workaround being an upgrade to
Tomcat 3.2 or 4.0.
The webappcabaret hosting environment offers a choice of Tomcat 3.1, 3.2 or
4.0, and I had recently decided to upgrade to 4.0. When I reset the
environment to use Tomcat 3.2, the file upload worked successfully again.
The environment options are set through a console, so I've checked the
system logs to confirm that the host was really deploying Tomcat 4.0 and
3.2. It looks like the upload bug that was fixed in 3.2 may have returned in
4.0?
Cheers
Ken


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

Re: Jasper performance

[ken . horn]

We use Jasper (from a 3.1 build!) in another container. How big is the
change if we wanted to move to the 3.3 version to get the tag pooling. I'm
about to start performance testing our app, and currently the pages are
taking ages to render (we build up to 1Meg of html.. :o), so we'll be
looking at this area soon.

In terms of a quick hit, anybody got opinions / experience of changing the
generation to use an unsynchronized version of StringBuffer, I think this
may show up as a possible easy enhancement.

Ken.





[EMAIL PROTECTED] on 15/05/2001 15:22:17

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:    (bcc: Ken X Horn)
Subject:  Re: Jasper performance




> Jasper performance has already been identified as an area needing
> improvement.
>
> Discussions and work on this has already started in the main tomcat
> branch in CVS jakarta-tomcat/proposals/jasper34, but this may be
> moving to the CVS repository jakarta-tomcat-jasper.
>
> This work just started recently, I don't know when it will be ready.

It will take few months - it's not that easy.

We already added tag pooling in tomcat3.3, and that have a significant
effect on performance if you are using tags - but that's just the
beginning.

The first step is to reorganize the code. Then we'll try to make the code
generator more customizable ( probably by using XSLT for some of the
operations ). The real performance enhancement will come when we start
tunning the generated code - there are many ideas around, but we need the
refactoring first.

BTW, jasper will share most of the code for the 1.1 and 1.2 APIs, so all
enhancements will be available in both 3.x and 4.x ( and other containers
as well ).

If you have ideas, code or opinions - please get involved, we need you :-)


Costin



>
> Rickard Öberg wrote:
> >
> > Hi!
> >
> > We are using Tomcat/JBoss and are pleased with the actual
functionality.
> > What is killing us right now is the performance of the code generated
by
> > Jasper, especially when using taglibs in complex ways. The generated
> > code is way too unoptimized.
> >
> > So, if this has not been asked before (in which case a RTFA is ok,
> > although I've looked already), my question is:
> > When will Jasper be rewritten?
> > Are there any such projects underway now?
> > Have there been any discussions about this yet?
> > Am I the only one seeing this problem, or are more people concernced
> > about it?
> >
> > Thanks,
> >   Rickard
> >
> > --
> > Rickard Öberg
> > Software Development Specialist
> > xlurc - Xpedio Linköping Ubiquitous Research Center
> > Author of "Mastering RMI"
> > Email: [EMAIL PROTECTED]
>
>

Re: httprequest fired twice

[ken . horn]

IE firing off multiple requests is quite common - esp when it's trying to
download something - we had it with PDF's. Typically it'll use different
headers each time too if only it would pay attention to the headers
provided instead..





[EMAIL PROTECTED] on 14/06/2001 13:10:00

Please respond to [EMAIL PROTECTED]; Please respond to
  [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:(bcc: Ken X Horn)
Subject:  httprequest fired twice



[JBoss-user] httprequest fired twiceJust wondering whether anyone faced the
problem of Jboss / Tomcat combination firing two HTTPRequest events from MS
Internet Explorer?
Regards,
Jee Meng.


Title: [JBoss-user] httprequest fired twice



Just wondering whether anyone faced the problem of 
Jboss / Tomcat combination firing two HTTPRequest events from MS Internet 
Explorer?
Regards, Jee 
Meng. 

Jasper performance query (circa 3.1 code)

[ken . horn]

I'm using Jasper in Weblogic from tomcat 3.1 (ish, we've patched a couple
of things too). While profiling some of my JSP's, I see the
JspRuntimeLibrary.introspectHelper consuming between 40-70% of the time,
and a large %age of the object creation. Drilling down, most of the time is
the line (which is still in Jasper34)

 java.beans.BeanInfo info
  = java.beans.Introspector.getBeanInfo(bean.getClass());

Which in turn is slow due to the construction of the BeanInfo (concrete class: 
GenericBeanInfo)

So my question is: why isn't this cached? Or rather, if I were to cache this object, 
what are my problems?
Those I see so far are:
1) If it's cached, where is the cache held?
(a) If within JspRuntimeLibrary, I must synchronize the Map --
may cause a bottleneck between threads, since this is called hundreds of times per JSP.
(b)If not here, then perhaps on the thread -- we're using our own subclass at this 
point (most of the time)
so I could store it as a thread local there, or change the generation to pass in a 
storage object / cache.

2) Will this prevent class reloading from GC'ing the old classes, unless the map is 
released? For our app,
reloading is only a dev feature so not too worried about this.

3) Am I reading my profiler wrong and this shouldn't be a bottleneck?

I don't think we can wait long enough for the Jasper refactoring to happen, so am 
looking for smallish
changes currently.

Ken.




This e-mail message is CONFIDENTIAL and may contain legally privileged
information.  If you are not the intended recipient you should not  read,
copy, distribute, disclose or otherwise use the information in this e-mail.
Please also telephone or fax us immediately and delete the message from
your system.  E-mail may be susceptible to data corruption, interception
and unauthorised amendment, and we do not accept liability for any such
corruption, interception or amendment or the consequences thereof.

Re: Servlet instance variables .. (was Hello!)

[ken . horn]

Hi,

Two things.
1) Your servlet implements SingleThreadModel -- which means Tomcat *may*
create multiple instances of your class -- how do other servlets get hold
of the instance? The public method is not static - did you mean it to be?

2) In order to flush the (instance) variables to other threads (according
to the Java memory model)  your should synchronize all access to them.

Ken.





[EMAIL PROTECTED] on 12/07/2001 13:50:11

Please respond to [EMAIL PROTECTED]; Please respond to
  [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:(bcc: Ken X Horn)
Subject:  Hello !



I am a new user in this list, and i'm French so please forgive my
mistakes !

I am developing a project with Tomcat and servlets technology, and i
have the following problem i would like to submit to you:

I have a basic servlet S1 who includes several methods useful for all
the other servlets.
The appli works fine... but suddenly, i get a loss of context that i
can't explain.
One of the servlets who calls a S1's method sees all the global
variables have a NULL value, while a few moments before these values
were correctly defined.
These values are config parameters read from the web.xml file of the
appli. They are initialized in the init() method of the S1 servlet.

So i wonder what's going on...
Is there any config or servlet memory timeout that raises ? or what ?...

It is a serious problem because all the application becomes
unpredictably unusable, until i restart Tomcat.

Here is a bit of my S1 servlet code :

/**
public class S1 extends HttpServlet implements SingleThreadModel {

private static String P1;
...

//


// methode d'initialisation: recuperation des parametres de conf
public void init(ServletConfig sc) throws ServletException {

 if (sc == null) {
 System.out.println("ServletConfig = null");
 System.exit(1);
 }

 super.init(sc);
 try {
 P1 = sc.getInitParameter("P1");
...

 if (P1 == null) {
  System.out.println("Paramètres de configuration de l'application
incorrectement renseignés.");
  System.exit(1);
 }
 else System.out.println("Contexte Base de signalements chargé.");
 }
 catch (Exception e) {
 e.printStackTrace();
 System.out.println("Lecture des paramètres de configuration de
l'application impossible.");
 System.exit(1);
 }
}

// method called by other servlets
public String m1(ServletOutputStream out) {

// uses init parameters such as P1 and returns a result
...
}
/**

thanks for any help

Stéphane

RE: [ANNOUNCEMENT] Tomcat 4.0-beta-6 Released

[Ken Torimaru]

Have I done something wrong or do the directory
listing still read "Apache Tomcat/4.0-b5"?

-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 20, 2001 12:21 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: [ANNOUNCEMENT] Tomcat 4.0-beta-6 Released


The Tomcat team is proud to announce the availability of the latest beta
release of Tomcat 4.0.  This next-generation servlet and JSP container
boasts the following new and improved features:
* Fix for the security vulnerability reported on July 16, 2001.
* Support for the "Proposed Final Draft 3" versions of the Servlet 2.3
  and JSP 1.2 Specifications.
* Many bug fixes and performance improvements.
* Support for executing external CGI scripts and programs.
* An updated version of the Apache web connector (binaries for various
  platforms will be available soon)
* A new experimental installer for the Windows platform that lets you
  download and install Tomcat 4.0 in a manner typical of other Windows
  based programs (including installation of Tomcat as an NT service).

Binary distributions of Tomcat 4.0-beta-6 are available at:

  http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b6/

and source distributions are available at:

  http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b6/src/

Please see the included RELEASE-NOTES-4.0-B6.txt file for details about
the changes included in this release.

Craig McClanahan

RE: [ANNOUNCEMENT] Tomcat 4.0-beta-6 Released

[Ken Torimaru]

NEVER MIND
I just need to recompile my applications.

-Original Message-
From: Ken Torimaru [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 20, 2001 1:49 PM
To: [EMAIL PROTECTED]
Subject: RE: [ANNOUNCEMENT] Tomcat 4.0-beta-6 Released


Have I done something wrong or do the directory
listing still read "Apache Tomcat/4.0-b5"?

-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 20, 2001 12:21 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: [ANNOUNCEMENT] Tomcat 4.0-beta-6 Released


The Tomcat team is proud to announce the availability of the latest beta
release of Tomcat 4.0.  This next-generation servlet and JSP container
boasts the following new and improved features:
* Fix for the security vulnerability reported on July 16, 2001.
* Support for the "Proposed Final Draft 3" versions of the Servlet 2.3
  and JSP 1.2 Specifications.
* Many bug fixes and performance improvements.
* Support for executing external CGI scripts and programs.
* An updated version of the Apache web connector (binaries for various
  platforms will be available soon)
* A new experimental installer for the Windows platform that lets you
  download and install Tomcat 4.0 in a manner typical of other Windows
  based programs (including installation of Tomcat as an NT service).

Binary distributions of Tomcat 4.0-beta-6 are available at:

  http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b6/

and source distributions are available at:

  http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b6/src/

Please see the included RELEASE-NOTES-4.0-B6.txt file for details about
the changes included in this release.

Craig McClanahan

Non-graceful shutdown a problem in 3.2.3?

[Ken Grigg]

I am running Tomcat 3.2.3 on NT/IIS with the Jikes compiler,
and noticed if the server is reset (i.e. power glitch) without
a normal shutdown, Tomcat comes back up non-operational. The
symptoms are that the JSPs can't be accessed until the class
files from the previous run are deleted from the work directory.

The log I get is:
2001-07-26 11:33:06 - Ctx( /admin ): JasperException: R( /admin +
/contextAdmin/contextAdmin.jsp + null) Unable to compile class for JSP

The beginning of the root cause trace is:
java.lang.ArrayIndexOutOfBoundsException
at
org.apache.jasper.compiler.ClassName.processClassData(ClassName.java:89)
at
org.apache.jasper.compiler.ClassName.getClassName(ClassName.java:191)
at
org.apache.jasper.compiler.JspCompiler.getRealClassName(JspCompiler.java:136
)

I was concerned it might be something to do with Jikes, but
it works fine if I manually recompile the .java source
that Tomcat creates just before the above logs.

I can fix this with a startup script that deletes the class
files, but I'm hoping there's a proper fix somewhere.

I couldn't find any discussion on this problem in the archives
or the web, except for the possibly related discussion at:

http://www.javaclue.org/tomcat/patch32b6/letspatch.html#step5

I was surprised to see that this patch (against 3.2.1) hadn't
been applied to 3.2.3, but it didn't work for me anyway.

Does any have any ideas?

...Ken.
---
Ken Grigg
AmikaNow! Corporation
mailto:[EMAIL PROTECTED]

Non-graceful shutdown a problem? (3.2.3)

[Ken Grigg]

I am running Tomcat 3.2.3 on NT/IIS with the Jikes compiler,
and noticed if the server is reset (i.e. power glitch) without
a normal shutdown, Tomcat comes back up non-operational. The
symptoms are that the JSPs can't be accessed until the class
files from the previous run are deleted from the work directory.

The log I get is:
2001-07-26 11:33:06 - Ctx( /admin ): JasperException: R( /admin +
/contextAdmin/contextAdmin.jsp + null) Unable to compile class for JSP

The beginning of the root cause trace is:
java.lang.ArrayIndexOutOfBoundsException
at
org.apache.jasper.compiler.ClassName.processClassData(ClassName.java:89)
at
org.apache.jasper.compiler.ClassName.getClassName(ClassName.java:191)
at
org.apache.jasper.compiler.JspCompiler.getRealClassName(JspCompiler.java:136
)

I was concerned it might be something to do with Jikes, but
there is no problem when I manually recompile the .java source
that Tomcat creates but can't compile.

I can fix this with a startup script that deletes the class
files, but I assume if this is a real problem someone would
have logged it at least (and I don't like patchy solutions!)

I couldn't find any discussion on this problem in the archives
or the web, except for the possibly related discussion at:

http://www.javaclue.org/tomcat/patch32b6/letspatch.html#step5

I was surprised to see that this patch (against 3.2.1) hadn't
been applied to 3.2.3, but it didn't work for me anyway.

Does any have any ideas?

...Ken.
---
Ken Grigg
AmikaNow! Corporation
mailto:[EMAIL PROTECTED]

Re: Multiple requests get generated for a single request

[ken . horn]

Are you using IE ? It sometimes has a tendency to request multiple times,
with slightly different headers each time. I've never tracked down exactly
what triggers this.

You can sometimes also get it if you have multiple submit fields on a form,
some with Javascript, and then you hit  ...






[EMAIL PROTECTED] on 08/08/2001 21:21:32

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:(bcc: Ken X Horn)
Subject:  Multiple requests get generated for a single request



Hi all
I have a servlet generating   a PDF document of approx 1. MB size streaming
its content into the browser of the client. The single request I make to
the
servlet spawns 2 more requests to the web-server/servlet. Can I configure
and make it only one request for this document.

Any ideas
Shankar


>From: "Pier P. Fumagalli" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: <[EMAIL PROTECTED]>
>Subject: Re: cvs commit:
>jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http
>SocketInputStream.java
>Date: Wed, 08 Aug 2001 21:11:47 +0100
>
>[EMAIL PROTECTED] at [EMAIL PROTECTED] wrote:
> >
> > Log:
> > - A HT (tab) is also considered a leading white space. It was a bit
>hidden in
> >   the HTTP spec, so I had missed it.
>
>Told you it was something regarding tabs/spaces on the second line of the
>header :) :) :) Great job for hunting that down :)
>
> Pier
>


_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

RE: Problems building Tomcat 4.0.1

[Ken . Horn]

I seem to remember getXMLReader is a SAX2 method. What SAX/XML parser 
are you linking with in the build?

-Original Message-
From: JLupo 
Sent: 20 December 2001 20:39
To: tomcat-dev
Cc: JLupo
Subject: Problems building Tomcat 4.0.1


When I try to build Tomcat 4.0.1 on my system, I get the following 
error and
it fails:

build-main:
[javac] Compiling 93 source files to
/opt/jakarta-tomcat-4.0.1-src/jasper/build/classes
[javac]
/opt/jakarta-tomcat-4.0.1-src/jasper/src/share/org/apache/jasper/compile
r/Pa
rserXJspSax.java:147: Method getXMLReader() not found in class
javax.xml.parsers.SAXParser.
[javac] XMLReader parser = saxParser.getXMLReader();
[javac]  ^
[javac] 1 error

I've verified that I've followed the BUILDING.txt directions to no 
avail.
Searching the Internet revealed the following link to the archives of 
this
list, http://w6.metronet.com/~wjm/tomcat/2000/Oct/msg00402.html but the
response doesn't help me because I've never had any other versions of 
JAXP
installed other than v1.1.

By the by, I'm running Solaris 8 x86 with JDK 1.2.2 installed.
thanks.

--
To unsubscribe, e-mail:   

For additional commands, e-mail: 




Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.


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

RE: setting up tomcat to accept client certificate

[Ken . Horn]

tomcat-user question... but:

Can your server reach the CA for the client certificate? AFAICR it must 
check the cert is valid..

-Original Message-
From: patrick.luby 
Sent: 15 March 2002 17:11
To: tomcat-dev
Cc: patrick.luby
Subject: Re: setting up tomcat to accept client certificate


Kunal,

This is exactly how the code is supposed to work: the certificate is 
*not*
fetched from the client if the parameter is set to 'false'.

Patrick

kunal kaviraj wrote:
> 
> Hi All,
> Whenever I try to set the parameter clientAuth="true" in the 
server.xml to
> accept client certificate from the user, after restarting Tomcat 
starts up
> well, but then I get 'Cannot find server' error when I try to access 
the
> https sites. But the http sites work perfectly.
> But when this parameter is set to 'false' https and http both works
> perfectly, though the client is not asked for certificate.
> The server certificate I am using has been generated by keytool.
> The client certificate is a third party one.
> I am using Tomcat standalone version 4.0.1 with jdk1.3.1
> I have downloaded the jsse1.0.2 and put the 3 jar files in the jdk 
ext path.
> Any pointer will be really helpful.
> Thanks
> Kunal
> 
> _
> Get your FREE download of MSN Explorer at 
http://explorer.msn.com/intl.asp.
> 
> --
> To unsubscribe, e-mail:   

> For additional commands, e-mail: 


-- 
_
Patrick Luby  Email: [EMAIL PROTECTED]
Sun Microsystems  Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_

--
To unsubscribe, e-mail:   

For additional commands, e-mail: 




Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.


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

RE: tag pooling question

[Ken . Horn]

As a quick note, I did some Jasper profiling on a previous project (it 
was Jasper from 3.1, running inside weblogic 5.1). The single biggest 
runtime cost, was all the calls to Introspector.getBeanInfo(). I 
created a cache of these using a similar technique to FastHashMap in 
commons collections (in Fast mode), and lowered the runtime costs 
significantly (for the calls i looked at say, 60%! (I think)). It was a 
trivial fix for the large benefit. Introspector does all the work every 
time, and instantiates a new BeanInfo for each call. Also, the cache 
only needs to expand to contain all the tag classes - a fairly small, 
finite set.

I didn't submit it before, as it was at the time of Jasper4 / tag 
pooling being touted and thought the heavy runtime reflection stuff 
would be obsolete soon...

-Original Message-
From: costinm 
Sent: 27 March 2002 22:54
To: tomcat-dev; Kin-Man.Chung
Cc: costinm
Subject: Re: tag pooling question


On Wed, 27 Mar 2002, Kin-Man Chung wrote:

> Pulling codes out of iteration tag bodies is very high on my list of
> optimizations that I wnat to do.  I don't think we can do much about
> general scriplets that contain loops, though.
> 
> But before we start on jasper optimization work, we'll need benchmarks
> and performance analysers.  I have learnt from experience that 
performance
> improvement often comes from surprising places, and that optimizations
> done at the wrong time and place often do more harm than good.  
Benchmarks
> would give us some real metric for us to measure our optimization 
work,
> and analyzing tools would let us identify hot spots that need to be 
improved.
> 
> I'd appreciate comments, suggestions, and pointers on these two 
subjects.
> I'd also appreciate if anyone can donate some real life applications 
that
> I can use for benchmarking jasper performance.

The most usefull tools are OptimizeIt and ab. 

Simple pages would help much better then complex pages - first find
out what's the overhead of executin a simple JSP page, with no tags,
compare it with the equivalent servlet ( HelloWorld ), and find out
what's wrong. 

Then use a simple hello world Tag, compare it with the equivalent 
servlet ( or JSP not using tags ), and find what's wrong.

Same for a simple iteration tag, compared with a scriptlet

If you solve those simple problems, and get the tag version 
in a reasonable limit, I think we'll all be very happy  ( 30% slower 
would be acceptable for me, even 1/2 the speed of the equivalent 
scriptlet ).

Going after 'real life applications' when the simple hello world tag,
or a simple empty jsp page has a clear performance penalty would be a 
waste of time.

( all that with a reasonable load - I sugest 80 concurent requests )

Costin


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 




Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.


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

RE: Mod_jk v/s mod_webapp

[Ken . Horn]

Maybe I've not kept up on the docs enough but ... 

I do think this thread, highlights a general confusion around tomcat. 
Over the last couple of years, there have been many 
mod_jk/jk2/webapp/warp/?? implementations, ajp versions etc, and even 
when the discussions are on the list, it's still hard to be able to say 
(for lowly thread lurkers/tomcat users like myself), tomcat X.x can use 
mod_??, on ajp?.? because they provide xyz..

It would be nice to have a page in the docs, on the general tomcat 
site, that gives a summary of what each native connector does in terms 
of features, config, performance, load balancing, web servers 
supported, whether still in development etc.

-Original Message-
From: pier 
Sent: 28 March 2002 12:52
To: tomcat-dev
Cc: pier
Subject: Re: Mod_jk v/s mod_webapp


David Graff <[EMAIL PROTECTED]> wrote:

> Thanks for the pointer on that documentation.  I was wondering where 
the
> Javadoc style comments were being used at.

You welcome...

> I still don't think the question was really answered though as to the
> motivation of mod_webapp versus mod_jk/mod_jk2 development?  Are 
there any
> goals that have been made available to the public so that we 
understand what
> the spawned these two different integration modules?

Motivation? I don't like mod_jk, I wanted to use APR as a portable 
runtime
for an Apache 1.3 module, I believe that the WARP protocol with built-in
support for auto-deployment and web-application configuration is the 
way to
go (rather than using mod_rewrite rules all the way around), and 
because I
don't like Costin :) :) :) :)

1.2.3. (BTW, all those "goals" passed over on this mailing list in the 
past
2/3 years, check the archives...)

Pier


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 




Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.


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

RE: MinTC, "terrible rudeness", persistence

[Ken . Horn]

Another (non-committer) +1 for keeping MinTC on tomcat-dev. Having a (perhaps limited) 
web/servlet server in a jar is a great idea. If Catalina core, migrates to allow this 
without a MinTC, other than a special server.xml, then that's OK. MinTC will probably 
have served it's purpose, and will die having had an effect probably on the core.

The only problem I see, is NOT discussing MinTC issues on tomcat-dev - having two 
solutions for this problem is not a bad thing.

-Original Message-
From: Rolf Veen [mailto:[EMAIL PROTECTED]]
Sent: 19 April 2002 12:01
To: Tomcat Developers List
Subject: Re: MinTC, "terrible rudeness", persistence


Remy Maucherat wrote:

> If many people want to see MinTC here, then it will happen even if I may not
> like it.


+1 to MinTC here. Lets be friendly. And open.
[ +1 * notCommiter == 0, I know ]

Rolf.


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


Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
should not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses.  The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission.  If
verification is required please request a hard-copy version.  This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.


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

RE: MinTC, "terrible rudeness", persistence

[Ken . Horn]

I have to admit not having read the MinTC source, however, I thought the tomcat 
community uses/develops multiple implementations of many interfaces. Most of the 
http/socket/auth?/config (xml file/ajp-webapp/admin) code is effectively multiple 
implementations of the same interfaces. Isn't the whole design of catalina intended to 
allow different implementations of practically every concrete class? 

I get the impresssion MinTC is developing different config/bootstrap/resource-location 
implementations, but that much of the code is shared as is?

If MinTC was replacing the core processing of Tomcat 3.3 i'd be more inclined to take 
your point, as the request chain is much more dedicated and part of the whole, whereas 
catalina is just a bunch of nested containers isn't it?

-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
Sent: 19 April 2002 13:24
To: Tomcat Developers List
Subject: Re: MinTC, "terrible rudeness", persistence


> Another (non-committer) +1 for keeping MinTC on tomcat-dev.
> Having a (perhaps limited) web/servlet server in a jar is a great idea.
> If Catalina core, migrates to allow this without a MinTC, other than a
> special server.xml, then that's OK. MinTC will probably have served
> it's purpose, and will die having had an effect probably on the core.

> The only problem I see, is NOT discussing MinTC issues on tomcat-dev -
> having two solutions for this problem is not a bad thing.

I will veto this (or vote against, if it's a majority vote). It has been
very clear for a while that the Tomcat project has to provide one and only
one servlet container for a particular version of the specifications.

If the Tomcat project wants to provide MinTC, it has to be as a proposal for
Tomcat 5.

Note: MinTC is not the same as Catalina. It just happens to use the same
interfaces. It is otherwise a completely different implementation.

Remy


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


Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
should not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses.  The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission.  If
verification is required please request a hard-copy version.  This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.


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

RE: Jasper2: serious problem with tag declarations

[Ken . Horn]

The scope of scripting variables from tags is specified in the Tag. From the 1.1 spec:

The defined values for scope are:
· NESTED, if the scripting variable is available between the start tag and the end tag 
of the
action that defines it.
· AT_BEGIN, if the scripting variable is available from the start tag of the action 
that
defines it until the end of the page.
· AT_END, if the scripting variable is available after the end tag of the action that 
defines
it until the end of the page.
The scope value for a variable implies what methods may affect its value...


So while declaring two id's the same is an error IMO, the specific tag  
should probably be NESTED rather than AT_BEGIN (which is what's happening). 

Checking the struts code (org.apache.struts.taglib.logic.IterateTei), it is indeed 
declared as NESTED. Looks like a Jasper 2 bug then. Time for a few extra {}'s?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 18 June 2002 06:44
To: Tomcat Developers List; Kin-Man Chung
Subject: Re: Jasper2: serious problem with tag declarations


On Mon, 17 Jun 2002, Kin-Man Chung wrote:

> Costin,
> 
> I am not aware that "id" attribute is handled differently in a tag.
> Can you give a test case for this?  I can look into it more.  Thanks.

I'll try to extract a test case.

There is nothing special about 'id' - just 2 consecutive struts 
 . This generates a variable 'foo'
( via TLD/TagInfo/etc ), and the problem is that the variable foo is
declared twice ( there are 2 'Object foo;' in the same scope ).

I'm not very familiar with struts ( but you may find some
experts on this list :-), but unless I'm doing something very
stupid in the page, this issue may be serious.

Costin 


> 
> - Kin-man
> 
> > Date: Mon, 17 Jun 2002 10:41:07 -0700 (PDT)
> > From: [EMAIL PROTECTED]
> > Subject: Jasper2: serious problem with tag declarations
> > X-X-Sender: [EMAIL PROTECTED]
> > To: List Tomcat-Dev <[EMAIL PROTECTED]>
> > MIME-version: 1.0
> > Delivered-to: mailing list [EMAIL PROTECTED]
> > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> > X-Antivirus: nagoya (v4198 created Apr 24 2002)
> > X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
> > X-Authentication-warning: costinm.sfo.covalent.net: costin owned process doing 
> -bs
> > List-Post: 
> > List-Subscribe: 
> > List-Unsubscribe: 
> > List-Help: 
> > List-Id: "Tomcat Developers List" 
> > 
> > 
> > I see some errors, not sure yet if it's an error in the taglibs or
> > jasper but seems serious. ( the taglibs are from struts ).
> > 
> > There are few  tags in the page, using the 
> > same id, and the generated code has:
> >   Object foo;
> >   
> > 
> >   Object foo;
> >   ...
> > 
> > That obviously doesn't compile.
> > 
> > I don't know too much about struts, but I suppose it is valid to use
> > the same value in 2 tag attributes, couldn't find any reference on 
> > the contrary in the spec.
> > 
> > It workes fine with older jasper.
> > 
> > Costin
> > 
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
> > 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 


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


Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
should not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses.  The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission.  If
verification is required please request a hard-copy version.  This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.


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

RE: Include directive in Tomcat4

[Ken . Horn]

This question should really be asked on tomcat-users.

You cannot use the context path in an include. If you want to deploy this with the 
full paths, deploy it as the default webapp, ie with "/" as the context path (into 
webapps/ROOT).

-Original Message-
From: Alfian Hadi [mailto:[EMAIL PROTECTED]]
Sent: 10 July 2002 05:17
To: [EMAIL PROTECTED]
Subject: Include directive in Tomcat4


Hi all,

I am facing problem using include directive in tomcat 4.0.4. Here is the
situation:

I create a new folder named: test under webapps (webapps/test). The folder
test contains two files:
- index.jsp
- hello.html

In index.jsp, this is what I have for the directive:
<%@ include file = "/test/hello.html" %>

Then I received this error:
org.apache.jasper.compiler.CompileException: /index.jsp(3,38) File
"/test/hello.html" not found

It seems that I cannot use the absolute path for include directive with
tomcat. This is just a simple sample. Actually I have a working JSP
application that I need to deploy on tomcat 4 and it cannot work because the
application use a lot of absolute path for the include directive. Any ideas
? Thanks.


- Alfian -




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


Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
should not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses.  The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission.  If
verification is required please request a hard-copy version.  This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.


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

RE: [vote] Possible logos for mod_jk documentation

[Ken . Horn]

(non-committer) 5 & 6 as Bojan suggested.

-Original Message-
From: Bojan Smojver [mailto:[EMAIL PROTECTED]]
Sent: 02 September 2002 21:55
To: Tomcat Dev List
Subject: Re: [vote] Possible logos for mod_jk documentation


On Mon, 2002-09-02 at 23:35, jean-frederic clere wrote:

> 
> I prefer to use: (Please put X in the [ ] of file you like most).
> mod_jk-logo11.gif [ ]
> mod_jk-logo11.png [ ]
> mod_jk-logo12.png [ ]
> mod_jk-logo13.gif [ ]
> mod_jk-logo13.png [ ]
> mod_jk-logo14.png [ ]
> mod_jk-logo15.png [ ]
> mod_jk-logo16.png [ ]
> mod_jk-logo3.jpg [ ]
> mod_jk-logo4.jpg [ ]
> mod_jk-logo5.jpg [X]
> mod_jk-logo6.jpg [ ]
> 
> As logo for mod_jk documentation.
> 

The surfing Tomcat!

Bojan

PS. Actually, I think we should adopt both 5 and 6 and let people use
them as they see fit (i.e. with or without the text).


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


Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
should not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses.  The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission.  If
verification is required please request a hard-copy version.  This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.


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

Re: Tomcat 4.1.x: Jasper 2 backwards compat with Jasper 1?

[Ken Horn]

I think the answer is no -- you should recompile all JSPs. Would defo be 
the safest option anyway.

Eddie Ruvinsky wrote:

Resending this.  Does anyone happen to know the answer
to this?  Is this supported?

Thanks in advance,
Eddie

--- Eddie Ruvinsky <[EMAIL PROTECTED]> wrote:
 

In Tomcat 4.1.x, is the Jasper 2 runtime supposed to
be backwards compatible the Jasper 1 runtime (i.e.,
from Tomcat 4.0.x), so that existing precomiled JSPs
using the Jasper 1 compiler would work as-is with
Jasper 2 in Tomcat 4.1.x?

Thanks,
Eddie

--- Remy Maucherat <[EMAIL PROTECTED]> wrote:
   

A new test milestone of Tomcat 4.1 has just been
released. Please help 
test this upcoming Tomcat release for compliance
issues and other problems.

Downloads:

 

http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.13/
 

Significant changes over 4.1.12 include some
performance improvements as 
well as bugfixes.

The full list of changes is available in the
 

release
   

notes.

 

http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.13/RELEASE-NOTES
 

IMPORTANT NOTE: Security manager functionality is
broken in this 
milestone. This will be fixed in the next
 

milestone.
   

This milestone will 
not be proposed for official release, and should
 

be
   

used for testing 
purposes only.

Remy
 



__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

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




 



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

Re: [5.0] Input optimization

[Ken Horn]

chop() / cut() ?



   

  Jerome "Lacoste  

  (Frisurf)"   To:   Tomcat Developers List 
<[EMAIL PROTECTED]>
   Subject:  Re: [5.0] Input optimization  

   

  06/01/2003 08:37 

  Please respond to

  "Tomcat  

  Developers List" 

   

   





On Sun, 2003-01-05 at 18:40, Remy Maucherat wrote:
> Costin Manolache wrote:
> > Great !
>
> If you could come up with a better name for the "substract" method ;-)
> It's supposed to be the opposite of append.

I found this:
>From The Collaborative International Dictionary of English v.0.44
[gcide]:

  Disappendent \Dis`ap*pend"ent\, a.
 Freed from a former connection or dependence; disconnected.
 [R.]
 [1913 Webster]

But I don't like it much.

untie() neither. Perhaps changing append() would make it easier to find
an opposite ?

J


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





--

This e-mail may contain confidential and/or privileged information. If you are not the 
intended recipient (or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail. Any unauthorized copying, disclosure or 
distribution of the material in this e-mail is strictly forbidden.



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

j_security_check Problems

[Ken Masters]

Hello everyone,

I am new to Tomcat and servlets. I am running Tomcat as my Servlet 
container. Im not sure if this is the correct place for the following 
question:
I use tomcat 4.1.18 with JDK 1.4, and I have set up a servlet (in the 
web.xml) to constrain users from entering to a website by directly typing in 
the URL. Once the user enters the URL, they are redirected to a html form 
(using jsecurity_check).
My problem is that when someone logs in successfully, then presses the back 
button, the j_security_check does not work the second time round.

Does anyone have any idea?

Thanking you in advance

Ken



_
Stay in touch with MSN Messenger http://messenger.msn.co.uk
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Jasper used for Tomcat 4.0.6

[Ken Sipe]

There are uses with the currect Jasper JspC compiler in the current Tomcat
4.1.x.  It works fine in Tomcat 4.0.x.  I was looking to see the diff on
them and I can't find a label in CVS that maps to code for Tomcat 4.0.x.

Could someone explain where the JspC code is for Tomcat 4.0 stuff.  It
doesn't appear to be under the jasper code base.  Although I see tomcat 33
and 4.1 references.

Thanks,
Ken


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

org.apache.catalina.authenticator.SSLAutheticator

[Ken Sims]

I am curious why SSLAuthenticator does not/cannot compare some attribute
of the client cert with the remote address (requestor)?  Without such a
check, it seems to me that certificates are as easily shared as the
credentials used in basic authentication.

Also, why do the realm implementations always return null for
getPrincipal?  Couldn't they lookup the user on the  users database,
ignoring password, to establish authorized roles?

The combination of these two things seems to me to really limit the
usefulness of client certificate authentication because authentication
provides little guarantee of who the client is, and even if it did, the
client is denied access to any protected resources.

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

RE: org.apache.catalina.authenticator.SSLAutheticator

[Ken Sims]

Thank you for your thoughts.  I have done a lot of reading on the topic
of CLIENT-CERT/SSL and Tomcat from Google searches as well as the source
code of SSLAuthenticator.  However I see nothing to indicate how a
server would know you from me if I gave you my keystore and keystore
password.  The server would authenticate you as me.  Many tests on my
part indicate that is so.  Funny that the client does this against the
server's cert by default.

I modified a version of SSLAuthenticator to do hostname verification
with success, but it seemed to me like something that is either a real
omission in Tomcat (perhaps on the basis of adherence to a standards
spec.?) or some conceptual misunderstanding on my part.  In deference to
the thought that I was missing something, I was hoping to hear what I
might look at specifically to revert to stock code for SSLAuthenticator.

-Original Message-
From: Bill Barker [mailto:[EMAIL PROTECTED] 
Sent: Monday, November 08, 2004 12:05 PM
To: Tomcat Developers List
Subject: Re: org.apache.catalina.authenticator.SSLAutheticator



- Original Message -
From: "Ken Sims" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 08, 2004 8:25 AM
Subject: org.apache.catalina.authenticator.SSLAutheticator


>I am curious why SSLAuthenticator does not/cannot compare some 
>attribute of the client cert with the remote address (requestor)?  
>Without such a check, it seems to me that certificates are as easily 
>shared as the credentials used in basic authentication.
>
There are plenty of tutorials on CLIENT-CERT auth out there.  I suggest
that you read one :).

>Also, why do the realm implementations always return null for 
>getPrincipal?  Couldn't they lookup the user on the  users database, 
>ignoring password, to establish authorized roles?
>
Usually when you seriously want CLIENT-CERT, you find that you need a
custom Realm anyway.  There isn't really a one-size-fits-all solution.
Where it is implemented in TC (MemoryRealm, and UDBRealm in 5.5.x), it
authenticates against the Subject.  In a lot of cases, you really only
want the CN, or the
CN+EMAIL fields.  In other cases (e.g. JNDI, JAAS) you might want the 
CN+entire
cert.  You can look through BZ for TC 4 to find several examples of
proposed implementations.

That said, patches are always welcome :).


>The combination of these two things seems to me to really limit the 
>usefulness of client certificate authentication because authentication 
>provides little guarantee of who the client is, and even if it did, the

>client is denied access to any protected resources.
>




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

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



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

Re: Proposal draft for Tomcat 5.0

[Nicola Ken Barozzi]

Remy Maucherat wrote:
> Hi,
> 
> 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).
> 
> I'm attaching the document to the mail, in case people don't want to 
> checkout the repository.

What about using Avalon as a framework?
This way we would have a unified server environment, and reusable server 
components.

If the Tomcat connectors were Avalon-aware, we could reuse them for 
James, Cocoon (directly, so we don't need to make Cocoon a servlet, 
which it's not), etc.

I'm a committer in POI, Forrest, Avalon and Cocoon, so as you imagine 
I'm a bit biased ;-) , but I also use Tomcat heavily, and I think that 
cooperation in this area would be nice and bring additional value to the 
users and to the projects themselves.

Tomcat4 is excellent in it's framework, and in many aspects is more 
Avalon than Avalon itself, as both came from the Jserv effort.

Now that Turbine is working on using Avalon (also FOP, POI, and others), 
  IMHO it would be excellent to also have the talented Tomcat developers 
work together with us.

-- 
Nicola Ken Barozzi   [EMAIL PROTECTED]
 - verba volant, scripta manent -
(discussions get forgotten, just code remains)
-


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

Re: Proposal draft for Tomcat 5.0

[Nicola Ken Barozzi]

Remy Maucherat wrote:
 > Nicola Ken Barozzi wrote:
 >
 >>
 >> Remy Maucherat wrote:
 >>
 >>> Hi,
 >>>
 >>> 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).
 >>>
 >>> I'm attaching the document to the mail, in case people don't want to
 >>> checkout the repository.
 >>
 >> What about using Avalon as a framework?
 >> This way we would have a unified server environment, and reusable
 >> server components.
 >
 > -1.
 > (I'm tired of replying to this)

I'm sorry, wasn't aware that I would cause distress.
I searced in the archives of tomcat-dev with "Avalon" and couldn't find
recent answers on this topic.

 > Avalon is the contrary of flexibility, so it will not be considered (at
 > least not by me).

Avalon is a project, not the contrary of flexibility.

Tomcat is a project too, and AFAIK it wants to be usable in different
environments.

Taken that you are against using Avalon directly, I don't want to table
a discussion with you on it.
When you'll want to take another look at Avalon and give us suggestions,
you're welcome.

Anyway, for my personal information, what's the current status of this?
What's the plan for T5?


List: tomcat-dev
Subject:  Re: [PATCH] CatalinaBlock.java
From: "Sam Ruby" <[EMAIL PROTECTED]>
Date: 2001-02-12 11:29:53

Remy Maucherat wrote:
 >
 > For these reasons, I'd like to see an official Avalon wrapper
 > introduced in Tomcat 4.1, but not in Tomcat 4.0.  I also
 > propose to remove the current Avalon wrapper from the Tomcat
 > 4.0 repository, to avoid the maintenance related issues.

Thank you.

-- 
Nicola Ken Barozzi   [EMAIL PROTECTED]
  - verba volant, scripta manent -
 (discussions get forgotten, just code remains)
-



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

Re: Proposal draft for Tomcat 5.0

[Nicola Ken Barozzi]

Remy, I hear you.
Current Avalon is what you say.
Next Avalon will be what it was supposed to be in the first place.

I respect you and your judgement; if you could give me additional hints 
on what the problem is about for using Avalon here, I would sincerely be 
grateful.

Anyway, as I tried to say in my last post, the only fact that you think 
this about Avalon is IMHO enough to not use it ATM.

Remy Maucherat wrote:

> For all the things it gives you, Avalon is a framework, and makes you 
> feel like it. It imposes contracts between components / patterns, 
> packaging, etc. All things which aren't compatible with 5.0. 

Hmmm... imposing good contracts is a good thing. Every API is a 
contract, and good APIs help make good software.
Hmmm...

 > And more
> importantly, the API changes often, to the extent that all the projects 
> which use Avalon work off a specific snapshot, and don't upgrade too often.

This is not that true. Avalon framework API 4 is stable for quite some 
time. What really changed fast are the implementations.

We are now working on make a single reference implementation and focus 
on that.

> Also, most of the utility provided by Avalon are available from the 
> commons without any string attached, and/or are of a better quality.

Utilities provided by Avalon are lifecycle management and component 
reusability+management.
All the other things are not Avalon, and are currently being moved to 
Commons, or wherelse where they belong.

> There has been plenty of discussion on that with Paul, and during the 
> whole commons-logging incident, at which point I thought it would be 
> best if I didn't have anything to do with Avalon.

I wasn't here when the logging incident took place, luckily ;-) , but I 
must say that it was a bad thing for all of us.

Currently there has been a proposal of using commons logging APIs, but 
there is still a bit of resistence from both parts.

I'm confident we will get through them, because if we don't I'll ask 
Pier some spiritual karma and have some kicking to do ;-)

> OTOH, we could have optional Avalon wrappers again, as long as there is 
> someone to write them *and* maintain them when the API changes. 

This is certainly nice.
I hoped that someone did some work on them, but it's ok.

When we'll be ready for that stage, I'll post again.

> So +0.1 
> to work nice with Avalon, but -1 for basing the architecture on Avalon.

We'll talk about this when we've finished our spring-cleaning.

Could you kindly summarize the things that Avalon needs to do before you 
would even consider taking it in consideration as a framework?

Thanks :-)

-- 
Nicola Ken Barozzi   [EMAIL PROTECTED]
 - verba volant, scripta manent -
(discussions get forgotten, just code remains)
-


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

Re: Proposal draft for Tomcat 5.0

[Nicola Ken Barozzi]

[EMAIL PROTECTED] wrote:
> I'm also -1 on Avalon - same reasons as Remy, plus more ( 
> the IoC madness/obsession,

? madness?

It's a pattern, would you say that someone has a "Factory" obsession?

> the over-design,

Please explain.

> ever-changing interfaces, 

The Avalon 4 interfaces are stable.
They are not everchanging.

> logkit, etc.)

?
What does logkit have to do with framework?

> Some components are good, and the move to commons is great - but
> I'm strongly -1 on using the framework.

Please give me some more insight.
What you say seems to me like: Avalon is too good to be of any use.
If it were a bit more "hacky" I would use it.

-- 
Nicola Ken Barozzi   [EMAIL PROTECTED]
 - verba volant, scripta manent -
(discussions get forgotten, just code remains)
-


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

Re: Proposal draft for Tomcat 5.0

[Nicola Ken Barozzi]

[EMAIL PROTECTED] wrote:
> On Fri, 21 Jun 2002, Nicola Ken Barozzi wrote:
> 
> 
>>Remy, I hear you.
>>Current Avalon is what you say.
>>Next Avalon will be what it was supposed to be in the first place.
> 
> 
> I think next avalon should start by looking for a problem to solve
> before proposing the solution to all the problems :-)

We have a charter.

> And it should start looking at what APIs are already used ( JMX, 
> JNDI, etc ).

We know them.

Phoenix is MBean compatible (baxter is currently being put in 
Commons-sandbox), JNDI is not incompatible with Avalon, since Avalon 
itself has no alternative to give for it; excalibur even has a "naming" 
package for it.

>>>Also, most of the utility provided by Avalon are available from the 
>>>commons without any string attached, and/or are of a better quality.
>>
>>Utilities provided by Avalon are lifecycle management and component 
>>reusability+management.
> 
> 
> I don't think we have problems with the lifecycle management or 
> component management ( for the last JMX seems to solve the problem ).

I never said you have a problem.
But since you are redesigning, I would think you would consider using 
the "Java Apache Server Framework" which Avalon is.

As commons is a common package repo, Avalon should be the common server 
framework.

James runs on it, Cocoon soon, Turbine is working on it, we have an FTP 
server, HSQLDB, FOP component, POI component in the works...

>>Could you kindly summarize the things that Avalon needs to do before you
>>would even consider taking it in consideration as a framework? 
> 
> I suppose finding the problem to solve would be a good first step.

This project goals are:
 >  - Design and documentation of the Java Apache Server Framework.
 >  - Creation and implementation of this framework
 >(interfaces, abstract classes, and shared modules).
 >  - Centralized management of the evolution/fixing/patching
 >    of both the shared code and the framework design.

We are reorganizing to refocus on our original goal, and become more 
tight focused.

-- 
Nicola Ken Barozzi   [EMAIL PROTECTED]
 - verba volant, scripta manent -
(discussions get forgotten, just code remains)
-


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

Re: Proposal draft for Tomcat 5.0

[Nicola Ken Barozzi]

+1

We'll work making "how make tighers links between
  Avalon and TC 5.0".

It makes perfect sense :-)

GOMEZ Henri wrote:
> I hope that Tomcat 5.0 proposal draft won't turn in
> a battle or flame war between Tomcat and Avalon commiters.
> 
> Why ?
> 
> Because we had just too many flams wars in tomcat-dev
> between tomcat 3.3 and tomcat 4.x teams.
> 
> Tomcat 5.0 appears to be a way to have both teams
> works again together to make a better tomcat,
> which will be profitable to the whole jakarta 
> community.
> 
> Tomcat 5.0 will be Coyote 2.0 based, a small and
> efficient core.
> 
> The question shouldn't be to use Avalon as framework, 
> but how make tighers links between Avalon and TC 5.0.
> 
> That core will link to catalina 2.0, jasper 3, 
> why not avalon 4 or 5 ? 
> 
> Others goal of TC 5.0 will be to be faster than TC 3.3
> or 4.x, better integration with web-servers, better
> management via JMX.
> 
> TC 5.0 is a normal evolution on works conducted on 
> TC 3.3 and 4.x, and a merge of ideas and commiters.
> 
> That's not so bad.
> 
> -
> Henri Gomez ___[_]
> EMAIL : [EMAIL PROTECTED](. .) 
> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 
> 

-- 
Nicola Ken Barozzi   [EMAIL PROTECTED]
 - verba volant, scripta manent -
(discussions get forgotten, just code remains)
-


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

Re: 5.0 proposal

[Nicola Ken Barozzi]

Remy Maucherat wrote:
> [EMAIL PROTECTED] wrote:
> 
>> It seems we have 3 -1 votes so far. While majority is required, I think
>> we all agree that getting everyone ( reasonable ) involved and 
>> comfortable
>> with the proposal is very important ( and one of the goals of 5.0 ).
> 
> 
> +1.
> 
>> Christopher: I think we should add your requirement for performance 
>> testing to the proposal. In fact, we should add a whole section about 
>> testing for 5.0. Would this satisfy you ? 
> 
> 
> +1 to start a new commons subproject.

How about making it part of JMeter?

-- 
Nicola Ken Barozzi   [EMAIL PROTECTED]
 - verba volant, scripta manent -
(discussions get forgotten, just code remains)
-


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

Re: [5] [TODO] Config first task

[Nicola Ken Barozzi]

Costin Manolache wrote:
...
> Sure. Just trying to get feedback and maybe get other people interested.
> So far only 2 people seem interested in 'common-discovery'.
> I want to use it for an antlib 'experiment', but it would also help
> for tomcat. Something like ant's ProjectHelper hook to plug in 
> different jndi config drivers ? 

OT: I am. I may use it to make Morphers available to apps. *And* if you 
tell me about your Antlib 'experiment', I'd be more than happy :-)
-> switching conversation to private or ant-dev

-- 
Nicola Ken Barozzi   [EMAIL PROTECTED]
 - verba volant, scripta manent -
(discussions get forgotten, just code remains)
-


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