RE: [ANNOUNCEMENT] Tomcat 3.2 Beta 8

[GOMEZ Henri]

>The outstanding bug reports are in our interim bug tracking system at
>
>http://znutar.cortexity.com
>
>The BugRat bug report #s on AJP13 and MOD_JK include at least 
>the following ones:  408,
>390, 373, 371, 367.

BUG 367 : the AJP13 BUG when posting date > 8k : Fixed now ;-)
BUG 390 : Could be fixed to BUG 367.

Could you test ([EMAIL PROTECTED]) TC 3.2B8 and told us more.

>There have also been some bug reports in email messages on 
>TOMCAT-USER and TOMCAT-DEV.  I
>think all of the reports are also included in the bug reports 
>listed above, but I have
>not tried to make an exhaustive comparison.
>
>>
>> Dave.
>> [EMAIL PROTECTED]
>>
>
>Craig McClanahan
>
>

RE: [ANNOUNCEMENT] Tomcat 3.2 Beta 8

[GOMEZ Henri]

The 'secure flag' is not used any more. 

I've included in my RPM a documentation with more information on SSL stuff.
Take a look at it and tell me if I could add it to TC 3.2 

Regards


 TOMCAT.README.RPM

RE: [TC4] multiple certificates

[GOMEZ Henri]

Apache (with mod_ssl) use VirtualHost directive :

Basically you give a certificate to a server, a server is 
an IP adress and a listen port number.

Tomcat will handle Virtual Host and the SSL certificate support
must be there.

One virtual host, one certificate.

You could also add different listen port :



 



 
 



 



 
 


Alternate question. I didn't see in the code TC3 where the 
multiple alias present in a keystore are used.
Could be nice to have all server certificate in the same keystore
and have access to them via another parameter :


 

>-Original Message-
>From: Warner Onstine [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, November 22, 2000 6:37 AM
>To: [EMAIL PROTECTED]
>Subject: Re: [TC4] multiple certificates
>
>
>
>- Original Message -
>From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Tuesday, November 21, 2000 7:43 PM
>Subject: Re: [TC4] multiple certificates
>
>
>> Warner Onstine wrote:
>>
>> > Hi all,
>> > It's been a while since I looked at the SSL stuff and I 
>just received a
>> > request which I'm not sure how it would be handled in TC4. 
> Would it be
>> > possible to handle multiple certificates for SSL per 
>servlet?  If this
>needs
>> > further clarification let me know.
>> >
>>
>> I guess I don't quite get what you are after.
>>
>> Are you talking about a certificate chain that authenticates 
>an individual
>> user?  If so, that is already supported -- the request 
>attribute that you
>get is
>> an array of certificate objects, with the first one being 
>the certificate
>of the
>> client principal, and the subsequent ones being the 
>certificates of the
>> certificate authorities vouching for the previous certificate in the
>chain.
>
>Sure, what we're working with is possibly using different server
>certificates for different servlets, is this at all possible? 
>From what I
>can tell right now, no.
>
>Basically what I see right now is if we turn on ssl support it uses the
>certificate that you specify for each connection from the
>SSLServerSocketFactory.  The only way I can see doing this is 
>to specify a
>different port for different certificates, correct?
>
>> If that's not what you are after, could you please explain further?
>>
>>
>> Craig
>
>Thanks,
>-warner
>

Regarding problem with tomcat.

[Bala Iyer/MUM/IN/STTL]

I have installed tomcat and also its plug in for IIS 4.0, when I open the
site, the index page shows, but when i click on any of the JSP executable
lists, I either gives me whole page as html code or it is executes the html
code, but the JSP variables are not shown. For example, if I click on the
date execute link on the index page, it just gives The page with only the
html page ie.,  days of the month is : blank

I would be obliged if anybody could help me resolve the same for me. I am
working for a company whose site is going to hosted on IIS but developed in
JSP.

With Regards

Bala

Jasper: Thread-safety in generated _jspService code

[Vanlerberghe, Luc]

Hi,

I've taken a look at the servlet code that jasper generates when compiling
my jsp pages.

I noticed the following code fragment near the start of each _jspService
method:
if (_jspx_inited == false) {
_jspx_init();
_jspx_inited = true;
}

This code is not thread-safe: unless the page is marked as being
SingleThreadModel, multiple threads can attempt to execute the _jspx_init
body. No problem for my pages since _jspx_init happens to be empty, but I
guess I'm just lucky.

I see two solutions: 
1. synchronize access to the flag (with a possible acceleration)
if (_jspx_inited == false) {
synchronized(this) { // Any object will do, it just has to be the
same for all threads, forcing them to re-read _jspx_inited from main memory
if (_jspx_inited == false) {
_jspx_init();
_jspx_inited = true;
}
}
}
Note: this double-test trick is only thread-safe if the flag never ever
returns to the false state, otherwise you have to synchronize on every
access to the flag.

2. Move the call to _jspx_init() to the init method of the generated
servlet.  That way it becomes the container's responsibility to make sure
that only one thread runs the initialisation code.



Further browsing through the jasper sources showed that this part of the
code is (for now) only used for cases where a StoredCharDataGenerator is
used.  In that case jasper generates a _jspx_init method that loads a
String[][] object from a file.  It won't hurt Tomcat if this code is called
multiple times, but it's not proper behaviour.


Another suggestion:
By adding a simple test in
org.apache.jasper.compiler.JspParseEventListener.generateHeader(), this part
of the generated code could be skipped for what I guess are the majority of
jsp pages.  Something like:
if (hasGenerator(InitMethodPhase.class))
{
...
}
around the relevant parts.
with
private boolean hasGenerator(Class phase) {
for(int i = 0; i < generators.size(); i++) {
Generator gen = (Generator) generators.elementAt(i);
if (phase.isInstance(gen)) {
return true;
}
}
return false;
}

Luc Vanlerberghe

P.s.: One day I'll have everything set up properly so that I can suggest
changes using the proper diff files, I promise :) ...

P.p.s.: My config:
Tomcat 3.2b7
Apache 1.3.12
Sun jdk 1.3 standard edition
NT 4.0 SP6a
PIII 500MHz, 256MB

[BUG TRACKING] BugRat core

[Nick Bauman]

BugRat blew chunks last night. I had a core dump and a down znutar this
morning with 32b7. This has never happened before.

[PATCH] WOOPS (Was RE: EmbededTomcat.java requires jsse)

[Stefan F. Stefansson]

Woopsie... I have to take this one on me... sorry guys.

Well... that's what you get when you let bozos like me mess with your
code ;o)

Costin: you were right... all it took was what you mentioned.  I've
changed the file and it's compiling. I've done a little testing on it
and it seems to be working ok.  At least it's compiling (with and
without JSSE jars in the classpath) and it's making the secure endpoints
correctly (when compiled with JSSE.  If you don't compile tomcat with
JSSE you can't make the secure endpoints but that's normal and ok).  I
haven't done any exhaustive testing and I don't know when/if I'm gonna
have time to do that, but I've done a little testing and everything
seems to be working fine.

In the meantime, here is the updated file and once again... I'm really
sorry about this.

Kind regards, Stefan Freyr


-Original Message-
From: Costin Manolache [mailto:[EMAIL PROTECTED]]
Sent: 22. november 2000 01:18
To: [EMAIL PROTECTED]
Subject: Re: EmbededTomcat.java requires jsse


I don't like that - tomcat is supposed to depend
only on JDK1.1  and a minimal number of extensions
( jaxp is the only required extension ).

All non-jdk1.1, non-standard extensions can be used,
but shouldn't be required to build standalone tomcat.

I don't know if it's too late to change this - it
seems 
we just need to replace 

   sc.setSocketFactory(new
org.apache.tomcat.net.SSLSocketFactory());

with 
sc.setAttribute( "socketFactory",   
"org.apache.tomcat.net.SSLSocketFactory");

and remove the import line.

I know it's not the the easiest solution, but I think
it's worth the added complexity - it is still a
requirement to support JDK1.1 and work with a minimal
set of library ( and JSSE is a very special one
anyway, export, etc).

Costin

--- Mike Anderson <[EMAIL PROTECTED]> wrote:
> I updated my source from CVS yesterday and all of
> the sudden I couldn't build.  I got an error saying
> javax.net.ServeSocketFactory not found in import
> when trying to build
>
src\share\org\apache\tomcat\net\SSLSocketFactory.java.
>  I looked at the build.xml and it looked like it
> shouldn't even be trying to build
> SSLSocketFactory.java since I didn't have the jsse
> classes in my classpath.  However, looking in the
> EmbededTomcat.java that was checked in on 11/17, it
> now does an import of org.apache.tomcat.net.* and
> directly references
> org.apache.tomcat.net.SSLSocketFactory.  Is there a
> way to fix this or are we now going to need to add
> the jsse jars to the build classpath?  If I do need
> to add the jsse jars, we should probably update the
> README to mention this so that others don't pull
> their hair out like I did for a while today.
> 
> Thanks,
> 
> Mike Anderson
> Senior Software Engineer
> Platform Services Group
> [EMAIL PROTECTED]
> Novell, Inc., the leading provider of Net services
> software
> www.novell.com
> 


__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

 EmbededTomcat.java

RE: No revolution today

[Andrew Cowie]

Joseph Chiu [mailto:[EMAIL PROTECTED]] wrote:
> In my environment, I wanted to force all contexts to be in 
> the root context.
> 
> So, my point is -- if you only need the root context (one 
> context only!), my
> kludge works.

We are presently employing Joseph's elegant (we force root context only)
solution in a production environment running 3.1. As I've mentioned
elsewhere, it's critical to us that the load balancing mechanism not be
mucked up in future releases; indeed, I'm often very worried that there
seems little commitment to maintaining the mod_jserv connector. Everyone
loves to say "oh, just use mod_jk" but unless the functionality of the
balance sets and routes of mod_jserv are maintained, we can't migrate.

$0.02

Andrew

--
Andrew Frederick Cowie
Director of Operations
Upoc, Inc

cell: 917-217-4578  office: 212-405-1044
[EMAIL PROTECTED]

cvs commit: jakarta-tomcat-4.0/invocation/src/share/org/apache/invocation InvocationAbstraction.java InvocationException.java package.html

[pier]

pier00/11/22 11:20:14

  Removed: invocation README
   invocation/src/native/windows/resources menu-quit.bmp
menu-restart.bmp menu-start.bmp menu-stop.bmp
tomcat.ico tray-default.ico tray-running.ico
tray-stopped.ico
   invocation/src/share/org/apache/invocation
InvocationAbstraction.java InvocationException.java
package.html
  Log:
  Removed the invocation package (now is service)

cvs commit: jakarta-tomcat-4.0/service - New directory

[pier]

pier00/11/22 11:21:25

  jakarta-tomcat-4.0/service - New directory

cvs commit: jakarta-tomcat-4.0/service/native - New directory

[pier]

pier00/11/22 11:23:04

  jakarta-tomcat-4.0/service/native - New directory

cvs commit: jakarta-tomcat-4.0/service/share - New directory

[pier]

pier00/11/22 11:23:05

  jakarta-tomcat-4.0/service/share - New directory

cvs commit: jakarta-tomcat/src/etc server.xml

[nacho]

nacho   00/11/22 11:23:18

  Modified:src/etc  server.xml
  Log:
  a typo
  
  Revision  ChangesPath
  1.53  +1 -1  jakarta-tomcat/src/etc/server.xml
  
  Index: server.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/etc/server.xml,v
  retrieving revision 1.52
  retrieving revision 1.53
  diff -u -r1.52 -r1.53
  --- server.xml2000/11/22 01:10:29 1.52
  +++ server.xml2000/11/22 19:23:17 1.53
  @@ -99,7 +99,7 @@
   
 
   
  +className="org.apache.tomcat.context.DefaultCMSetter" />
   
   

cvs commit: jakarta-tomcat-4.0/service/native/windows - New directory

[pier]

pier00/11/22 11:23:28

  jakarta-tomcat-4.0/service/native/windows - New directory

cvs commit: jakarta-tomcat-4.0/service/share/org - New directory

[pier]

pier00/11/22 11:24:01

  jakarta-tomcat-4.0/service/share/org - New directory

cvs commit: jakarta-tomcat-4.0/service/share/org/apache - New directory

[pier]

pier00/11/22 11:24:14

  jakarta-tomcat-4.0/service/share/org/apache - New directory

cvs commit: jakarta-tomcat-4.0/service/share/org/apache/service - New directory

[pier]

pier00/11/22 11:24:25

  jakarta-tomcat-4.0/service/share/org/apache/service - New directory

cvs commit: jakarta-tomcat-4.0/service/share/org/apache/service/helpers - New directory

[pier]

pier00/11/22 11:24:49

  jakarta-tomcat-4.0/service/share/org/apache/service/helpers - New directory

cvs commit: jakarta-tomcat-4.0/service/share/org/apache/service/helpers NativeServiceHelper.java NativeServiceManager.java SimpleService.java

[pier]

pier00/11/22 11:26:12

  Added:   service  README
   service/native jsvc.h jsvc_help.c jsvc_parse.c
jsvc_service.c jsvc_unix.c
   service/native/windows menu-quit.bmp menu-restart.bmp
menu-start.bmp menu-stop.bmp tomcat.ico
tray-default.ico tray-running.ico tray-stopped.ico
   service/share/org/apache/service Service.java
ServiceException.java ServiceManager.java
   service/share/org/apache/service/helpers
NativeServiceHelper.java NativeServiceManager.java
SimpleService.java
  Log:
  Added new "service" package (more structured version of the old invocation)
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-4.0/service/README
  
  Index: README
  ===
  
  -
  APACHE INVOCATION README
  -
  
  Abstract:
  -
  
  Invocation is an abstraction of a generic invocation mechanism for
  Java based services. It is composed of two major parts: a set of Java
  classes (interfaces and exceptions) to be implemented by the service
  provider, and some native code dealing with the underlying operating
  system, accessing to the service thru JNI.
  
  The Java portion of Invocation:
  ---
  
  While the usual main(String args[]) method is well suited for generic
  applications, having only one entry point when developing networked
  services is not enough.
  
  In UNIX based operating systems, for example, a set of signals to be
  sent to running processes expands the invocation paradigm, so that,
  after the service process is usually started with a call to the
  main(int argc, char *argv[]) function, signal handling provides
  alternate ways to trigger events inside the process.
  
  For example, it usually happens that UNIX daemons upon reception of
  the HUP signal, the service is stopper, configuration are re-read
  from disk, and the service is started againg with the new
  configurations, or, upon reception of a TERM signal, the service is
  stopped (freeing all resources allocated) and the process is
  terminated.
  
  The org.apache.invocation.InvocationAbstraction interface works in
  the same way. It defines three major entry points:
  
  - start(String args[])  is the parallel to the main(String args[])
  method used by applications. Command line
  parameters are passed to the instance and the
  service is started.
  
  - restart()  this method is called when the service must be stopped,
   configurations re-read from the disk, and the service
   brought back on line with the new configuration. It's
   behaviour is similar to the usual behaviour of the HUP
   signal in unix daemons.
  
  - stop()  this method is called before the Java VM is terminated. The
service should release all resources allocated during its
execution, save temporary data, and be prepared to exit.
It's behaviour is similar to the usual behaviour of the
TERM signal in unix daemons.
  
  For more information on the behaviour of those methods and how they
  work, please consult the JavaDOC documentation included into the
  org.apache.invocation package.
  
  The native portion of Invocation:
  -
  
  The native portion of Invocation is made of two major components:
  
  A system-indipendant library based on JNI handling the creation and
  destruction of the Java Virtual Machine, and providing an easy way to
  access to the service start(String argv[]), restart() and stop()
  methods as described above.
  
  An Operating-System dependant set of sources dealing with calls from
  the underlying operating system:
  
  - in UNIX operating systems we listen for TERM and HUP sinals, and
appropriate calls are made in the system-indipendant library to
access to the appropriate Java method in the service. This will
make the Java service behave like a standard UNIX daemon.
  
  - in Microsoft Windows operating systems we provide two different
modes of operation: a GUI based one that will allow the user to
access to the above-mentioned methods thru a standard tray-icon
menu (there's no console allocated for the Java Process, wich is
for most of us Windows users a major pain). Another mode to operate
under Windows is thru the Wi

Re: No revolution today

[Paul Frieden]

I've done some work with this, and session routing now works fine for
both root and non-root contexts as far as I can tell.  These changes
were committed for 3.2b7.  I've done my testing with mod_jk and AJP12. 
mod_jk provides the lbworker type which seems to work perfectly for me
but there is no reason why mod_jserv shouldn't work also.

Paul Frieden

Andrew Cowie wrote:
> 
> Joseph Chiu [mailto:[EMAIL PROTECTED]] wrote:
> > In my environment, I wanted to force all contexts to be in
> > the root context.
> >
> > So, my point is -- if you only need the root context (one
> > context only!), my
> > kludge works.
> 
> We are presently employing Joseph's elegant (we force root context only)
> solution in a production environment running 3.1. As I've mentioned
> elsewhere, it's critical to us that the load balancing mechanism not be
> mucked up in future releases; indeed, I'm often very worried that there
> seems little commitment to maintaining the mod_jserv connector. Everyone
> loves to say "oh, just use mod_jk" but unless the functionality of the
> balance sets and routes of mod_jserv are maintained, we can't migrate.
> 
> $0.02
> 
> Andrew
> 
> --
> Andrew Frederick Cowie
> Director of Operations
> Upoc, Inc
> 
> cell: 917-217-4578  office: 212-405-1044
> [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-4.0/service README

[jon]

jon 00/11/22 12:10:16

  Modified:service  README
  Log:
  ENGLISH :-)
  
  Revision  ChangesPath
  1.2   +7 -7  jakarta-tomcat-4.0/service/README
  
  Index: README
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/service/README,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- README2000/11/22 19:26:04 1.1
  +++ README2000/11/22 20:10:15 1.2
  @@ -26,8 +26,8 @@
   alternate ways to trigger events inside the process.
   
   For example, it usually happens that UNIX daemons upon reception of
  -the HUP signal, the service is stopper, configuration are re-read
  -from disk, and the service is started againg with the new
  +the HUP signal, the service is stopped, configuration is re-read
  +from disk, and the service is started again with the new
   configurations, or, upon reception of a TERM signal, the service is
   stopped (freeing all resources allocated) and the process is
   terminated.
  @@ -61,12 +61,12 @@
   
   The native portion of Invocation is made of two major components:
   
  -A system-indipendant library based on JNI handling the creation and
  -destruction of the Java Virtual Machine, and providing an easy way to
  +A system-independent library based on JNI handling the creation and
  +destruction of the Java Virtual Machine and providing an easy way to
   access to the service start(String argv[]), restart() and stop()
   methods as described above.
   
  -An Operating-System dependant set of sources dealing with calls from
  +An Operating-System dependent set of sources dealing with calls from
   the underlying operating system:
   
   - in UNIX operating systems we listen for TERM and HUP sinals, and
  @@ -77,7 +77,7 @@
   - in Microsoft Windows operating systems we provide two different
 modes of operation: a GUI based one that will allow the user to
 access to the above-mentioned methods thru a standard tray-icon
  -  menu (there's no console allocated for the Java Process, wich is
  +  menu (there's no console allocated for the Java Process, which is
 for most of us Windows users a major pain). Another mode to operate
 under Windows is thru the Win32 Service API (WinNT and Win2K only)
 thru the standard Control-Panel Service tab.
  @@ -90,5 +90,5 @@
   
   -
   Copyright (c) 2000  The Apache Software Foundation.  All rights reserved.
  -$Revision: 1.1 $ $Date: 2000/11/22 19:26:04 $
  +$Revision: 1.2 $ $Date: 2000/11/22 20:10:15 $
   -
  
  
  

Re: cvs commit: jakarta-tomcat-4.0/service/share/org/apache/service/helpers NativeServiceHelper.java NativeServiceManager.java SimpleService.java

[Remy Maucherat]

I think it would be a good idea if compiled versions of the service, and other
native components were committed in the tree, esp for Windows.

All of this looks great (I like the NT service thing :))) !

Remy

Re: cvs commit: jakarta-tomcat-4.0/service/share/org/apache/service/helpers NativeServiceHelper.java NativeServiceManager.java SimpleService.java

[Craig R. McClanahan]

Remy Maucherat wrote:

> I think it would be a good idea if compiled versions of the service, and other
> native components were committed in the tree, esp for Windows.
>

I am not a fan of checking in binaries like this, for the same reason I don't want
to check in JARs.  I've seen too many cases where the developers forget to update
the JARs, or don't remember what version it is or where they got it.

I *am* a big fan of building the binaries and making them available for download,
coordinated with releases.  For example, the binaries for the 3.2 native stuff can
be found (for at least a couple of platforms) at:

http://jakarta.apache.org/builds/tomcat/release/v3.2-beta-8/bin

and I would be happy to post compiled binaries for other platforms if people want
to send them to me.

>
> All of this looks great (I like the NT service thing :))) !
>

Pier, can you build the Windows binaries for me (for 4.0) on your machine once we
cut the next milestone?

>
> Remy

Craig

[PROPOSAL] Tomcat 4.0 Milestone 5

[Craig R. McClanahan]

Folks,

I plan to cut a "milestone 5" release of Tomcat 4.0 this coming Friday (or,
worst case, on Saturday).  As a sneak preview of coming attractions, the
following cool stuff will be included:

* Initial version of the web connector for Apache

* Substantial performance optimizations on the
  stand alone HTTP connector

* Support for a JNDI naming context (like J2EE
  servers provide) even for Tomcat stand-alone.

* Support for the new invocation service -- among
  other things, this lets you bind Tomcat stand-alone
  to port 80 without having to run as root!

* The usual assortment of bug fixes.

After milestone 5, I propose that we consider Tomcat 4.0 to be "feature
complete", so that we can commence with a beta cycle, and focus on shaking out
remaining bugs -- aiming for a final release either late December or early
January.  At the same time, we can start talking about features and
functionality we'd like to see in Tomcat 4.1.

Craig McClanahan

Re: [PROPOSAL] Tomcat 4.0 Milestone 5

[Jason Brittain]

Craig R. McClanahan wrote:

> Folks,
> 
> I plan to cut a "milestone 5" release of Tomcat 4.0 this coming Friday (or,
> worst case, on Saturday).  


*clap*  *clap*

> As a sneak preview of coming attractions, the
> following cool stuff will be included:
> 
> * Initial version of the web connector for Apache


Lots of people have been eagarly awaiting this one..

> 
> * Substantial performance optimizations on the
>   stand alone HTTP connector


This is great stuff too!

Just so you know, I've been looking at the AccessLogValve,
and am working on getting it into shape to be re-enabled
in the default config.  In the process, I'm writing a Valve
tester so we can test and benchmark Valves.  It's already
running, but it's not quite ready for release yet..

> 
> * Support for a JNDI naming context (like J2EE
>   servers provide) even for Tomcat stand-alone.
> 
> * Support for the new invocation service -- among
>   other things, this lets you bind Tomcat stand-alone
>   to port 80 without having to run as root!


These are nice bonuses that I hadn't yet expected.  :)

> 
> * The usual assortment of bug fixes.
> 
> After milestone 5, I propose that we consider Tomcat 4.0 to be "feature
> complete", so that we can commence with a beta cycle, and focus on shaking out
> remaining bugs -- aiming for a final release either late December or early
> January.  At the same time, we can start talking about features and
> functionality we'd like to see in Tomcat 4.1.
> 
> Craig McClanahan


Sounds great!

Cheers.

-- 
Jason Brittain
Software Engineer, Olliance Inc.http://www.Olliance.com
Current Maintainer, Locomotive Project  http://www.Locomotive.org

Re: [PROPOSAL] Tomcat 4.0 Milestone 5

[Remy Maucherat]

> Just so you know, I've been looking at the AccessLogValve,
> and am working on getting it into shape to be re-enabled
> in the default config.  In the process, I'm writing a Valve
> tester so we can test and benchmark Valves.  It's already
> running, but it's not quite ready for release yet..

I would like that by default it doesn't do any kind of pattern matching at
all (unless one is explicitely specified), and just output the standard log.

Remy

Re: [PROPOSAL] Tomcat 4.0 Milestone 5

[Jason Brittain]

Remy Maucherat wrote:

>> Just so you know, I've been looking at the AccessLogValve,
>> and am working on getting it into shape to be re-enabled
>> in the default config.  In the process, I'm writing a Valve
>> tester so we can test and benchmark Valves.  It's already
>> running, but it's not quite ready for release yet..
> 
> 
> I would like that by default it doesn't do any kind of pattern matching at
> all (unless one is explicitely specified), and just output the standard log.


You're talking about the AccessLogValve itself, right?  You want an
AccessLogValve that doesn't do any fancy pattern stuff, but built only
to do the common log format?  Yes, that would sure help it to perform,
wouldn't it?  And, we could have another Valve that does the fancy log
patterns of people want that feature.

-- 
Jason Brittain
Software Engineer, Olliance Inc.http://www.Olliance.com
Current Maintainer, Locomotive Project  http://www.Locomotive.org

Re: cvs commit: jakarta-tomcat-4.0/service/share/org/apache/service/helpers NativeServiceHelper.java NativeServiceManager.java SimpleService.java

[Pier P. Fumagalli]

"Craig R. McClanahan" wrote:
> 
> > All of this looks great (I like the NT service thing :))) !
> 
> Pier, can you build the Windows binaries for me (for 4.0) on your machine once we
> cut the next milestone?

Nope, as I don't have a copy of MSVC (apart from an old 4.2 version I
brought from Italy). Sun surely does, but aparently we don't own a
site-wide license (Mr. Chinnici, our MS guru told me that).
I'm going to order one on monday...

Pier

--
Pier Fumagalli <[EMAIL PROTECTED]> 

Re: cvs commit: jakarta-tomcat-4.0/service/share/org/apache/service/helpers NativeServiceHelper.java NativeServiceManager.java SimpleService.java

[Pier P. Fumagalli]

"Craig R. McClanahan" wrote:
> 
> Remy Maucherat wrote:
> 
> > I think it would be a good idea if compiled versions of the service, and other
> > native components were committed in the tree, esp for Windows.
> >
> 
> I am not a fan of checking in binaries like this, for the same reason I don't want
> to check in JARs.  I've seen too many cases where the developers forget to update
> the JARs, or don't remember what version it is or where they got it.
> 
> I *am* a big fan of building the binaries and making them available for download,
> coordinated with releases.

+1 ... No binaries in CVS, please :)

Pier

--
Pier Fumagalli <[EMAIL PROTECTED]> 

[Tomcat 3.2 beta 8] jsse ?

[Pilho Kim]

How can I test JSSE ?
I have installed Tomcat 3.2 beta 8 on Win98.

Please give me AJP1.3

[???]

I need AJP1.3
Send me AJP1.3! Please 

Re: [PROPOSAL] Tomcat 4.0 Milestone 5

[Remy Maucherat]

> > I would like that by default it doesn't do any kind of pattern matching
at
> > all (unless one is explicitely specified), and just output the standard
log.
>
>
> You're talking about the AccessLogValve itself, right?

Yes.

> You want an
> AccessLogValve that doesn't do any fancy pattern stuff, but built only
> to do the common log format?

Let's say something like :
if (pattern.equals(COMMON_ALIAS)) {
   log something hard coded which looks like the default pattern
} else {
   do the old stuff (which could perhaps be optimized more)
}

> Yes, that would sure help it to perform,
> wouldn't it?  And, we could have another Valve that does the fancy log
> patterns of people want that feature.

We should be able to do both in the same Valve, IMO. Of course, two valves
would get the job done too.

Remy

BugRat Report #424 has been filed.

[BugRat Mail System]

Bug report #424 has just been filed.

You can view the report at the following URL:

   

REPORT #424 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment: 
   Release: 3.1
   JVM Release: 1.2
   Operating System: Windows NT
   OS Release: 4.0
   Platform: Intel

Synopsis: 
Tomcat does not see derived setter methods of tag handlers

Description:
Let's say that I have two classes. The first one is the base class to provide basic 
attributes for the tag handler I'm implementing. The second one is the actual tag 
handler to be used in the page. Here is how the code will look like.

class A extends TagSupport {
   public void setAttrib(int x) { ... }
}

class B extends A {
   ...
}

Assume further that I have the proper TLD file to specify tat "Attrib" is a 
translation-time attribute. Tomcat does not see the method setAttrib() in class B. 
What I'm getting is just IllegalAccessException.

If I were to override the setAttrib() method in B, then Tomcat can see it.


Title: 
BugRat Report #
424





BugRat Report #
424




Project:
Tomcat


Release:
3.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
critical




Confidence:
public





Submitter:
_Anonymous ( [EMAIL PROTECTED] )

Date Submitted:
Nov 23 2000, 02:07:02 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

Tomcat does not see derived setter methods of tag handlers


 Environment: (jvm, os, osrel, platform)

1.2, Windows NT, 4.0, Intel



Additional Environment Description:





Report Description:

Let's say that I have two classes. The first one is the base class to provide basic attributes for the tag handler I'm implementing. The second one is the actual tag handler to be used in the page. Here is how the code will look like.

class A extends TagSupport {
   public void setAttrib(int x) { ... }
}

class B extends A {
   ...
}

Assume further that I have the proper TLD file to specify tat "Attrib" is a translation-time attribute. Tomcat does not see the method setAttrib() in class B. What I'm getting is just IllegalAccessException.

If I were to override the setAttrib() method in B, then Tomcat can see it.




View this report online...

Loadbalncing......^^

[박대화]

Hello
 
I'm a beginner using Tomcat
And I'm wondering to loadbalance with Tomcat.
Is it pssible and if it is How?
 
Sorry for my poor English.
bye!