Re: Asking Again: 5.5.12 Broke my 5.5.9 Config

[Remy Maucherat]

On 9/30/05, Trond Hersløv <[EMAIL PROTECTED]> wrote:
> Hi
> I'm also running TC 5.5.9 and planning on installing 5.5.12.
> Twice I have read through the complete Changelog, from 5.5.10 to 5.5.12. I 
> find nothing saying this attribute is now ignored. (Remy has appended his 
> comments at the bottom of this email).
> Is there other things that may have an impact at my current applications - 
> how do I know?
>
> Q: Have I just overlooked it twice or am I looking for this kind of 
> information at the wrong place?
>

The "path" attribute was already ignored in 5.5.9. docBase is now also
ignored if inside the Host's appBase.

--
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Asking Again: 5.5.12 Broke my 5.5.9 Config

[Remy Maucherat]

On 9/30/05, Bob Bronson <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I asked this question a couple days ago but received no helpful
> responses. I thought I'd try one more time. If anyone has had
> experience with this, please let me know. Thanks...
> 
> I've just tried to "upgrade" from TC v5.5.9 to v5.5.12 and it seems my
> (very simple) configuration is now broken.
>
> The following configuration works beautifully under 5.5.9 -- no
> exceptions, no warnings, just utter perfection.
>
> Here's a description of my configuration (BTW, CATALINA_HOME and
> JAvA_HOME are fine, I'm sure they're not causing the problem).
>
> I have CATALINA_BASE set like this:
>C:\Projects\Configs\
>
> Within this "Configs" directory I have two sub-directories: "conf" and
> "Engine_01" like this:
>
>C:\Projects\Configs\
>|
>+-conf\
>|  |
>|  +-server.xml
>|  +-web.xml
>|
>+-Engine01\
>|  |
>|  +-localhost\
>|  |  |
>|  |  +-ROOT.xml
>
>
> Within the "conf" directory I have my "server.xml" and the default
> "web.xml" files. Here is the server.xml contents:
>
> 
>   
> 
> 
>   
> 
>   
> 
>
>
> Notice I have named the engine, "Engine_01".
>
> As you can see, in the "Engine_01" directory I have a subdirectory,
> "localhost", which contains a context fragment file named, "ROOT.xml".
> Here is the contents of ROOT.xml:
>
>
>
>
> In my "server.xml" you'll notice I have my appBase property set to
> "..\Sites\Test 1". Here is the "Sites" directory structure:
>
>C:\Projects\Sites\
>|
>+-Test 1\
>|
>+-index.html
>+-WEB-INF\
>|
>+-web.xml
>+-classes\
>+-root\
>
>
> It's all quite simple, I think. When I run under v5.5.9, this
> configuration works perfectly, as I said.
>
> Using the EXACT SAME configuration, running under v5.5.12, I see this
> WARNING and EXCEPTION when I start TC:
>
> WARNING: A docBase C:\Projects\Sites\Test 1\. inside the host appBase
> has been specified, and will be ignored
> Sep 26, 2005 8:37:22 PM org.apache.catalina.core.StandardContext
> resourcesStart
> SEVERE: Error starting static Resources
> java.lang.IllegalArgumentException: Document base
> C:\Projects\Configs\..\Sites\Test 1\ROOT does not exist or is not a
> readable directory
> at
> org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.java:140)
> at
> org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:3777)
> at
> org.apache.catalina.core.StandardContext.start(StandardContext.java:3948)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
> at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
> at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
> at
> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:603)
> at
> org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:535)
> at
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:470)
> at
> org.apache.catalina.startup.HostConfig.start(HostConfig.java:1118)
> at
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310)
> at
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
> at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1020)
> at
> org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
> at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1012)
> at
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
> at
> org.apache.catalina.core.StandardService.start(StandardService.java:450)
> at
> org.apache.catalina.core.StandardServer.start(StandardServer.java:680)
> at
> org.apache.catalina.startup.Catalina.start(Catalina.java:536)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275)
> at
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
> Sep 26, 2005 8:37:22 PM org.apache.catalina.core.StandardContext start
> SEVERE: Error in resourceStart()
> Sep 26, 2005 8:37:22 PM org.apache.catalina.core.StandardContext start
> SEVERE: Error getConfigured
> Sep 26, 2005 8:37:22 PM org.apache.catalina.core.StandardContext start
> SEVERE: Context [] startup failed due to previous errors
> Sep 26, 2005 8:37:22 PM org.apache.catalina.core.StandardContext stop
> INFO: Container
> org.apache.catalina.core.Containe

Re: Tomcat/JVM hangs in session.getAttribute / HashMap.get()

[Remy Maucherat]

On 9/7/05, GB Developer <[EMAIL PROTECTED]> wrote:
> coming late to the party with:
> 
> http://blogs.opensymphony.com/plightbo/archives/000175.html

I had read your blog when you originally posted it, and thought it was
the most interesting blog I had read in months. IMO, given the average
size of the array in a typical hashmap (very small), they should have
added a robstness check (typically, e != e.next).

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Automatic deploy of updated war deletes the context file

[Remy Maucherat]

On 8/26/05, Paul Austin <[EMAIL PROTECTED]> wrote:
> The test case I am using is running on Tomcat 5.5.9.
> 
> 1. The web application is deployed as a the app.war file, with no
> context.xml file to the wars/ directory
> 2. The Host configuration is as follows.
>deployXML="false">
>prefix="" timestamp="false" />
>   
> 3. In conf/Catalina//app.xml
>   
>reloadable="true" workDir="work/Catalina//app">
>  type="javax.sql.DataSource"/>
>   
> 
> When I copy app.war into wars/ to repeploy using the automatic
> deployer I check the conf/Catalina// and
> http:///manager/list and the app.xml and the /app context are
> deleted.

Yes, this is normal.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Client Deployer 5.5.11 NullPointerException

[Remy Maucherat]

On 8/25/05, Markus Schönhaber <[EMAIL PROTECTED]> wrote:
> Am Donnerstag, 25. August 2005 17:57 schrieb Allistair Crossley:
> > Thanks, that's good to know, it must be something to do with my
> > environment. Are you saying then that you did not have to copy any JDT jars
> > into your deployer?
> 
> No, I didn't have to copy any jars since ant uses sun's javac from tools.jar
> in JAVA_HOME by default. If it doesn't for you, then there's something wrong.

Yes, if you set JAVA_HOME "correctly", then Ant should find javac, and
you don't need to add the other compiler.

> > How have you setup Ant? In any specific manner?
> 
> I extracted the zip, set ANT_HOME accordingly and added %ANT_HOME%\bin to
> PATH.

I'm on Windows too.

Maybe the space in the path for JAVA_HOME is causing problems (mine is
c:\java\jdk1.5.0), but overall the Ant script is hack free, and
there's no .bat to introduce bad behavior (except the Ant one, but
hopefully it is properly done).

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Client Deployer 5.5.11 NullPointerException

[Remy Maucherat]

On 8/25/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> To start with something, I use a known-to-be-working Ant 1.6.2 release.

I just installed and tested with 1.6.5, and it works too. I just added
some debug logging too for the classloading exceptions.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Client Deployer 5.5.11 NullPointerException

[Remy Maucherat]

On 8/25/05, Allistair Crossley <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> Hm :(
> 
> Are you able to clarify what you mean by "a well configured Ant which is able 
> to use a Java compiler." Perhaps this is where the problem lies?
> 
> My Ant setup is such that I have ANT_HOME and JAVA_HOME env vars set. I have 
> ANT_HOME/bin and JAVA_HOME/bin on the PATH. The ant and javac commands work 
> on the command line. I can run the Tomcat build script and many other build 
> scripts with ant to build software (including Tomcat).
> 
> This for me looks like at least a configured Ant. Am I missing some link that 
> you know of?
> 
> In terms of installing the deployer, I literally did the following:
> 
> 1. Downloaded 5.5.11-alpha Deployer
> 2. Unzipped to c:\jakarta-tomcat-5.5.11-deployer
> 3. Created deployer.properties, setting the 4 or 5 properties required for 
> the web application
> 4. Moved to c:\jakarta-tomcat-5.5.11-deployer
> 5. Executed ant compile
> 6. File copy works etc... but then I get the exception with the jasper2 task.
> 
> Then I got your suggestion
> 
> 7. Copy jdt compiler jar frmo common/lib to 
> c:\jakarta-tomcat-5.5.11-deployer\lib
> 8. Executed ant compile
> 
> Same error occurs however. I don't _think_ I have done anything funny but you 
> never know ;)
> 

To start with something, I use a known-to-be-working Ant 1.6.2 release.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Client Deployer 5.5.11 NullPointerException

[Remy Maucherat]

On 8/25/05, Allistair Crossley <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I'd really love to I assure you, but I really don't
> 
> a) have years and years of architecting Tomcat development to trace through 
> how Jasper2 works and
> b) the time whilst I am sat here working for a corporation trying to get 
> Tomcat working for the business
> 
> For what it's worth (which is nothing I realise) I do realise that 
> jspCompiler.init(this, jsw) is throwing the exception because the jspCompiler 
> returned from the compiler = (Compiler) 
> Class.forName(className).newInstance(); is null due to what must be a CNFE 
> (looks like logging is needed there). I also see that this was why you asked 
> me to copy the JDT compiler jar from common/lib into the deployer/lib.
> 
> However, I did just that, and this still does not solve the resolution of the 
> compiler class. Can I clarify that wnated me to copy 
> common/lib/jasper-compiler-jdt.jar into deployer/lib?
> 

Of course. No compiler is found, so you should add one.

> Finally, is it documented anywhere that deployer won't work out of the box? 
> If not, I'd be happy to make a comment on the Deployer doc page.
> 

The deployer does work out of the box, assuming you have a well
configured Ant which is able to use a Java compiler. So you did
something funny :)

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Client Deployer 5.5.11 NullPointerException

[Remy Maucherat]

On 8/25/05, Allistair Crossley <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> No I don't think that's it, both ant and javac work on my command line. I do 
> use Ant for build, I'm just trying deployer for the first time. JAVA_HOME, 
> ANT_HOME are also both defined. Ant is also the latest version 1.6.5
> 

Great. Then go look in the code and try to explain the exception by
something other than "No Java compiler available".

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Client Deployer 5.5.11 NullPointerException

[Remy Maucherat]

On 8/25/05, Allistair Crossley <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I've decided to try out the Deployer tool for the first time to see if it 
> makes like a little easier for deployments to our test servers.
> 
> I've used the 5.5.11 Alpha Deployer as I noted some threads indicating a 
> problem with 5.5.9's version.
> 
> I've come across the following when running it pretty much out of box. I 
> setup a deployer.properties file. Am I missing some kind of classpath or 
> could this be caused by a file in my web application?
> 

No Java compiler available. With the deployer package, you're supposed
to be using Ant+javac (given that Ant wants JAVA_HOME and likes a
JDK). If not, add the JDT JAR that is in common/lib.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: logging tomcat 5.5

[Remy Maucherat]

On 8/23/05, Alain Gaeremynck <[EMAIL PROTECTED]> wrote:
> I read the doc and found out that in tomcat 5.5 we are suppose to use
> log 4 j to handle getServletContext.log.  However i rather liked the old
> ways  Is it stil supported?
> 
> if i put this in my context
> 
>prefix="servlet." suffix=".log" timestamp="true" />
> 
> will it still work?

No, it's not supported anymore. You can look at your logging options here:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/logging.html

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

[ANN] Apache Tomcat v5.5.11-alpha Released

[Remy Maucherat]

The Apache Tomcat team is proud to announce the immediate availability 
of Apache Tomcat 5.5.11-alpha, which includes bugfixes over Apache 
Tomcat 5.5.10-alpha.


The Release notes are available at
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/RELEASE-NOTES

Please refer to the change log for the list of changes:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/changelog.html

Downloads: Binaries: http://jakarta.apache.org/site/binindex.cgi#tomcat-5.5
Sources: http://jakarta.apache.org/site/sourceindex.cgi#tomcat-5.5

The Apache Tomcat Team


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

Re: Deploying ROOT.war indicates missing application web.xml

[Remy Maucherat]

On 8/22/05, Allistair Crossley <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> Just to reconfirm, and also to take into account what you did in your test
> 
> 0. Check server.xml for unpackWARs="true" autoDeploy="true"
> 1. I use Ant's war task to correctly war the web application package.

I used 7zip.

> 2. I clear Tomcat's webapps folder and restart for good measure.

I only deleted the "ROOT" folder.

> 3. I copy the war into webapps
> 4. Tomcat reports
> 
> INFO: Deploying web application archive ROOT.war
> 22-Aug-2005 11:14:02 org.apache.catalina.startup.ContextConfig 
> applicationWebConfig
> INFO: Missing application web.xml, using defaults only 
> StandardEngine[Catalina].StandardHost[localhost].StandardContext[]
> 
> 5. I rename ROOT.war to ROOT.zip and open in WinZip to check file structure, 
> in particular web.xml and to ensure that ROOT is not part of packaged paths.
> 6. I unzip ROOT.zip to webapps\ROOT
> 7. I make a request to the web application which succeeds including filters 
> defined in the web.xml
> 8. Stop Tomcat
> 9. With WinZip, rezip the tested working ROOT folder contents
> 10. Delete webapps\ROOT
> 11. Rename ROOT.zip to ROOT.war
> 12. Cut ROOT.war onto Desktop.
> 13. Start Tomcat
> 14. Cut ROOT.war into webapps
> 15. Get same error.
> 
> INFO: Deploying web application archive ROOT.war
> 22-Aug-2005 11:14:02 org.apache.catalina.startup.ContextConfig 
> applicationWebConfig
> INFO: Missing application web.xml, using defaults only 
> StandardEngine[Catalina].StandardHost[localhost].StandardContext[]
> 
> Could the fact that my ROOT.war is 18MB have anything to do with Tomcat's 
> ability to examine for the web.xml??? (wild guess)

I know you like funny theories, but how about trying with the default
ROOT webapp then ?

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Deploying ROOT.war indicates missing application web.xml

[Remy Maucherat]

On 8/22/05, Allistair Crossley <[EMAIL PROTECTED]> wrote:
> Hi Everyone,
> 
> Just been deploying ROOT.war into webapps and it's failing to explode. The 
> logs indicate;
> 
> INFO: Deploying web application archive ROOT.war
> 22-Aug-2005 09:46:44 org.apache.catalina.startup.ContextConfig 
> applicationWebConfig
> INFO: Missing application web.xml, using defaults only
>   ^^^
> 
> Yet, if I rename ROOT.war to ROOT.zip and open it in WinZip, the web.xml has 
> been correctly packed by the Ant WAR task. Indeed if I unzip the WAR into 
> webapps manually, the web application works fine and is packaged correctly.
> 
> I use an Ant WAR task
> 
>  destFile="${dist.dir}/${app.name}.war"
> webxml="${webroot.dir}/WEB-INF/web.xml"
> duplicate="preserve">
> 
>   
>   
>   
>   
> 
>   
> 
> 
> 
>   
> 
> 
> 
> Any ideas why Tomcat is exhibiting this behaviour?

I just tried it by zipping and removing the ROOT folder, replacing it
with ROOT.war. It gets expanded and deployed correctly.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: JspC compile exception in tomcat-deployer 5.5.10

[Remy Maucherat]

On 8/16/05, Bernhard Slominski <[EMAIL PROTECTED]> wrote:
> Hi Richard,
> 
> the problem is that your classpath for the jasper path is not correct.
> So this Null Pointer exception actually means that some class was not found.
> Note that you need all the tomcat libraries in your jaser classpath, as well
> as your libs as well.
> I post you my script, which is working Ok (on Tomcat 5.5.7).

Yes, the problem is indeed that the task definition had been
mistakingly removed in this build from the catalina.tasks properties
file.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: tomcat 5.5, jdk1.5 on user mode debian stable hangs after a few days

[Remy Maucherat]

On 8/2/05, MDK <[EMAIL PROTECTED]> wrote:
> no, the odd thing is, it wasnt even being used (and its a very simple
> application, of course, thats a relative term)
> 
> i installed the app, tested it once and logged out.
> 
> I came back to it a few days later and the whole thing is hanging.
> 
> If you can recommed any tools i can use to detect what is happening that
> would be much appreciated
> 
> the app itself uses spring, openamf (an open source flash remoting
> connector) with some jdbc (mysql)
> 
> so i guess that any one of these (and my code) could be the culprit.
> 
> I'll look into each of these individually and see if they could be
> causing the problem.

When something like Tomcat is hung, the first thing you should do is
get a thread dump, which may give very useful information.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Tomcat 5.5.10: APR-SSL generates wrong 302 response

[Remy Maucherat]

On 7/25/05, Markus Schönhaber <[EMAIL PROTECTED]> wrote:
> Hello!
> 
> I've configured Tomcat 5.5.10 to use APR. The HTTP-Connector listens on port
> 80, the HTTPS-Connector listens on port 443. A request for
> https://www/tomcat-docs
> generates the following response:
> 
> GET /tomcat-docs HTTP/1.1
> Host: www
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.8b4) Gecko/20050721
> Firefox/1.0+
> Accept:
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
> Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> 
> HTTP/1.x 302 Moved Temporarily
> Server: Apache-Coyote/1.1
> Location: https://www:80/tomcat-docs/
> Transfer-Encoding: chunked
> Date: Mon, 25 Jul 2005 11:57:39 GMT
> 
> Obviously this doesn't work since since the redirection response tells the
> browser to connect to the HTTP port using HTTPS.
> This problem does *not* occur if:
> - The request is for https://www/tomcat-docs/ (no surprise since no redirect
> response is generated in this case).
> - The HTTPS-Connector is configured to listen on port 8443 (or propably any
> other non-standard HTTPS-port - but I haven't tried).
> - APR isn't used at all.

There's indeed a cut & paste error (the default ports for HTTP and
HTTPS are inverted), so you need to add an extra '!':

  Index: Http11AprProcessor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11AprProcessor.java,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- Http11AprProcessor.java   13 Jul 2005 13:03:51 -  1.25
  +++ Http11AprProcessor.java   25 Jul 2005 15:32:48 -  1.26
  @@ -1422,8 +1422,8 @@
   }
   
   if (colonPos < 0) {
  -if (ssl) {
  -// 80 - Default HTTTP port
  +if (!ssl) {
  +// 80 - Default HTTP port
   request.setServerPort(80);
   } else {
   // 443 - Default HTTPS port


Using proxyPort="443" should be a decent workaround.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Servlet Concurrency Issues

[Remy Maucherat]

On 6/8/05, Peter Crowther <[EMAIL PROTECTED]> wrote:
> > From: Remy Maucherat [mailto:[EMAIL PROTECTED]
> > Your statement is completely wrong, STM is fully supported in Tomcat
> > 5.5, with instance pooling for good performance.
> 
> Sorry, Remy - I should have checked rather than relying on memory.

No problem. STM is deprecated in the specification, but support is
mandatory (of course, if the container doesn't do pooling, performance
will be really bad). I hope it doesn't get removed, since it is
sometimes useful (maybe it could be reinstated with a different name).

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Servlet Concurrency Issues

[Remy Maucherat]

On 6/8/05, Peter Crowther <[EMAIL PROTECTED]> wrote:
> Note that SingleThreadModel isn't supported in more recent versions of
> Tomcat.  This may or may not worry you depending on whether you want to
> move to a more recent version :-).

I've posted already about that: if you don't know about something,
please don't make guesses with the tone of someone who knows his
stuff, since you'll just end up confusing people.

Your statement is completely wrong, STM is fully supported in Tomcat
5.5, with instance pooling for good performance. It's usually much
faster than having lots of sync in your servlet, that is. I actually
like the feature, personally. The only reason it got removed is
because it gave users the impression that no additional syncing was
ever needed (which is not the case, as session modification may still
be unsafe).

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Tomcat optimization... saving internal strings with character encoding at compile time.

[Remy Maucherat]

On 5/29/05, Kevin Burton <[EMAIL PROTECTED]> wrote:
> 
> Another area that I'm noticing that Tomcat is spending a LOT of time in
> is with character encoding.  Its not a ton of time but its really
> showing up as one of the top 20 areas of our webapp.
> 
> Internally its either storing text as a java.lang.String or with
> genStrAsCharArray ... a char array
> 
> Most people are probably using a fixed character encoding.  For example
> we use UTF8.  I doubt they're changing charset on the fly.
> 
> Its a waste of CPU to continually encode these strings.  This isn't just
> theoretical as I'm seeing our webapp do this internally via JProfiler.
> 
> Why not have strings fixed to a character coding at runtime?  While this
> would yield inflexibility it would increase performance.
> 
> This could be a new feature called genStrAsEncodedByteArray... which
> would just store the string as a byte[] and output it directly.
> 
> The only thing that would need to be encoded in this setup would be
> dynamic strings from EL.
> 
> It would also save more memory for English text since strings no longer
> are stored in 32bit but just UTF8 encoded 8 bit values.
> 
> It would slow down compile time though because Jasper would now need to
> call toByteArray() on all your strings.
> 
> Thoughts?

This is obvious.

This is not an implementable optimization idea, as you cannot use both
a writer and an out stream in a servlet. If this was doable, then
obviously constant strings would be cached as byte arrays.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: genStrAsCharArray not available in JspC and performance increase?

[Remy Maucherat]

On 5/29/05, Kevin Burton <[EMAIL PROTECTED]> wrote:
> So on:
> 
> http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jasper-howto.html#Production%20Configuration
> 
> It recommends to use genStrAsCharArray when in production.
> 
> This can be set in web.xml but not when using JspC from the command line.
> 
> trimSpaces is there... but not genStrAsCharArray.
> 
> Its in the source but it just doesn't have a command line option.
> 
> 1... does it make sense for me to just recompile my 5.5.4 production
> server with this enabled?  Whats the performance gain?
> 
> 2.  Can we make this an option in JspC moving forward?  I don't see why
> it can't be a command line switch.
> 
> I verified that this is still the case in 5.5.9 btw.

The command line version of jspc has been kind of deprecated for a
while now; we recommend using Ant.

Otherwise, adding code to set the flag is relatively simple.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: The amazingly slow performance of JSP (profiler results)

[Remy Maucherat]

On 5/28/05, Peter Lin <[EMAIL PROTECTED]> wrote:
> as you see already, using JSTL means a single line of code gets
> converted to several lines of JSTL api calls. once you look at how
> many classes are involved in executing JSTL, it's pretty clear it's
> using much more memory and causing more GC. The performance you see is
> the result of JSTL using more memory.

It will obviously use more CPU and make more API calls. However, it
does not allocate any objects, but instead will reuse per page objects
(which is very fast). So overall, it sounds weird to me that the
bottleneck would be on tag invocation.

In the end, it's hard to beat a Java "if" with a generic high level
construct ;) I don't understand how anyone could be surprised by that.

> Back in 2002, I wrote several pages using JSP + java and JSP + JSTL to
> measure the actual cost of from a performance perspective. The
> performance difference isn't noticeable if a page has less than 50
> tags. With 200+ tags, the performance difference does range from 2-5x
> slower for JSTL. It's worse when you use XML with JSTL. It's also one
> of the reasons I like to use JSTL + XML to benchmark. It really gives
> the VM a workout.
> 
> have you tried running JRockit 5?  I did some tests recently and
> JRockit's memory management might give you a 2x improvement in
> performance. That's assuming you can use jdk5

Right, the code for invoking tags seems to be a good candidate to be
optimized by a competent JIT.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: The amazingly slow performance of JSP (profiler results)

[Remy Maucherat]

On 5/28/05, Kevin Burton <[EMAIL PROTECTED]> wrote:
> I've been tuning our application trying to get the maximum performance
> out if the system as possible.
> 
> I've been throwing the system at jprofiler and allowing it to tell me
> where to optimized.
> 
> In short Tomcat is slower than our DB, filesystem,. network and all
> other systems by about 4x.
> 
> I've been able to shave some page load time off by some but not enough.
> 
> The problem I'm starting to see is that we just have a large number of
> c:set and c:if constructs (and so forth) within loops.  These loops then
> get executed 5 times and next thing you know it you have 50k taglib calls.
> 
> The problem comes when you look at the source:
> 
> Let's say you start with:
> 
> > 
> 
> This nice little elegant piece of code gets expanded to:
> 
> >   private boolean _jspx_meth_c_set_0(PageContext _jspx_page_context)
> >   throws Throwable {
> > PageContext pageContext = _jspx_page_context;
> > JspWriter out = _jspx_page_context.getOut();
> > //  c:set
> > org.apache.taglibs.standard.tag.rt.core.SetTag _jspx_th_c_set_0 =
> > (org.apache.taglibs.standard.tag.rt.core.SetTag)
> > _jspx_tagPool_c_set_var_value_nobody.get(org.apache.taglibs.standard.tag.rt.core.SetTag.class);
> > _jspx_th_c_set_0.setPageContext(_jspx_page_context);
> > _jspx_th_c_set_0.setParent(null);
> > _jspx_th_c_set_0.setVar("foo");
> > _jspx_th_c_set_0.setValue(new String("bar"));
> > int _jspx_eval_c_set_0 = _jspx_th_c_set_0.doStartTag();
> > if (_jspx_th_c_set_0.doEndTag() ==
> > javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
> >   return true;
> > _jspx_tagPool_c_set_var_value_nobody.reuse(_jspx_th_c_set_0);
> > return false;
> >   }
> 
> Which explains why JSP alone is so amazingly slow!
> 
> 
> I did a comparison of the page performance here and it was 15x slower than 
> just using Java.  So the same "set" operation in Java was 15x faster.
> 
> ... so in short ... does anyone have any way to speed this up?
> 
> The other thing I noticed is that EL is evaluated at runtime (which has to be 
> parsed) and sometimes uses reflections.  Can anyone shed any more light on 
> this and hopefully provide some performance optimization suggestions?

You already posted on this subject. Can you provide any hard data that
a tag invocation is actually slow this time ? Guesses don't really do
it, and profilers are often not very accurate. I'm asking because
while the code is indeed quite verbose, it does not make it slow (all
operations in the code that is cut & pasted are very cheap). The JIT
is supposed to take care of this kind of code very well.

For production configuration for Jasper, see:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jasper-howto.html#Production%20Configuration

We have a facility in Jasper called tag plugins, which allows
replacing a tag invocation (which cannot be any simpler and still
comply to the specification) by equivalent Java code (so your c:if is
traslated to a regular Java "if"). Support for JSTL is very
incomplete, but you can use that to optimize the few tags that you
think need it. Kin-Man asserted that overall the performance
improvement was small - 10% at most. See package
org.apache.jasper.tagplugins.jstl (which has already an impl for "if"
which could help you out). Feel free to sumit more JSTL tag plugins if
you find it works well.

EL will have to remain interpreted at runtime, but has a cache. I have
not evaluated this performance area yet, however. Other xSP
technologies interpret a lot of things at runtime, and most don't even
rely on compilation (which will likely tend to make them a little
slower, I assume), and the overhead is usually not in the xSP engine,
so I don't see why it would be a major issue here (as long as the impl
is not too stupid, of course).

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Reload on Tomcat 5.5

[Remy Maucherat]

On 5/22/05, Parsons Technical Services <[EMAIL PROTECTED]> wrote:
> Robert,
> 
> Now that Remy has tested it in his perfect world, this gives some direction
> to work in. It would appear that with a basic setup, which we can only
> assume since Remy assured you that it works, that there must be a OS issue.
> I wonder what Remy runs?
> 
> If you decide to dig deeper, I would layout the code for the two versions
> and see where they differ. Then with this information you could submit a bug
> report with all the details. Hopefully it could be changed unless there was
> a compelling reason.
> 
> I am so glad that Remy pointed out that I was wrong, but had no explanation
> for why you were having problems. Considering that I was only suggesting a
> direction to look in. But then again if you had been running Windows then I
> may have been right.
> 
> Don't let the snotty attitude get to you. You encounter those type on the
> list from time to time.

Please try to make sense next time. Writing inaccurate statements
while appearing to "know things" will confuse people, and will be much
worse than posting nothing. If you don't really know, then don't post
funky theories as facts.

Your main assertion is baseless "5.5 has a hard time letting go of the
cache/workfiles". Do you actually know what you are talking about ? I
suppose not.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Reload on Tomcat 5.5

[Remy Maucherat]

On 5/22/05, Robert Parsons <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> Thanks for the reply.
> 
> Well to be more specific then I will give you an example of what I have
> tried as a test. I write a basic servlet that simply prints a line of
> text to the screen. If i compile it and deploy it, all is good. If I
> then make a modification to that that string in the source file,
> recompile then RELOAD (using ant), the servlet still outputs the
> ORIGINAL string (before the modification). The same thing happens If i
> recompile then press 'reload' in the tomcat manager application instead
> of using ant.

I tested this, and it (of course) works fine.

> If i perform the steps above on the latest tomcat 5.0 (rather than 5.5),
> the NEW string would be printed out after the reload.  Any ideas? Coz
> i'm stumped.

Well, don't plan to upgrade ever, because the "bug" will obviously
never be fixed.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Reload on Tomcat 5.5

[Remy Maucherat]

On 5/22/05, Robert Parsons <[EMAIL PROTECTED]> wrote:
> I don't imagine stuff, and I am not currently running tomcat under
> windows. I have used various versions of tomcat 5.0 and 5.5 on many
> different Operating systems (such as redhat, fedora core, ubuntu linux
> and windows xp) and many versions of java (quite a few different 1.4 and
> 1.5's). I have not claimed there is a problem with tomcat, i am asking
> for help as I do not know if I am doing somthing wrong.

Yes, you are doing something wrong, as this works.

> All i can say is that after following tutorials and using very standard
> Ant scripts (or the the tomcat manager application) I can easily
> 'reload' servlet applications on Tomcat 5.0.x. On every installation of
> Tomcat 5.5.x i have found that 'reloading' applications (in the same way
> I have done with 5.0) does nothing. Changes to classes are not reflected
> in the output of the application. To get anything to update I have to
> undeploy and install it again. There is nothing much more I can tell
> you. I could give you source code or my ant script, but source code is
> fairly irellevant and the ant script i am using is straight out of the
> tomcat getting started tutorial. The only configuration changes I have
> made to tomcat was adding a user in the users.xml!

More nonsensical statements. To start with, class reloading is not
enabled by default *and* reloading does work fine. As I said, if you
think otherwise, please post factual data (test cases, whatever)
proving otherwise.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Reload on Tomcat 5.5

[Remy Maucherat]

On 5/22/05, Robert Parsons <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> Thanks for the quick reply. I have the latest stable version i think
> (5.5.9). I have tried this on older version too in the past and just
> given up and gone back to 5.0. I just decided this time to see if it was
> a bug or me missing somthing.
> 
> Basically i'm just trying to get classes to reload. Say i make a change
> in what a particular servlet prints out to the browser, i want to see
> that change. Nothing complex. At the moment i've just gone back to 5.0
> and all is working ok. From time to time i'll download 5.5 and see if it
> works :p

If you're not actually looking for help, and were just trying to
confuse people with your incorrect statements about an imaginary
problem, then please do not bother posting.

BTW, reloading works well, please do not claim otherwise without
posting factual data. Doug's post is also wrong, as there are no such
thing as "cache/workfiles" which would cause updating issues (the only
relevant thing you could be referring to is the locking issues when
redeploying on Windows).

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Apache vs Tomcat WRT Security

[Remy Maucherat]

On 5/19/05, Mark <[EMAIL PROTECTED]> wrote:
> I was very interested in the discussion concerning Apache vs Tomcat
> WRT Performance.  While I cannot argue with the performance numbers, I
> do like putting Apache in front of Tomcat for 2 reasons that I have
> found so far.
> 
> 1. SSL.  If I am going to be serving pages whether they be dynamic or
> static, I think Apache handles the SSL communications and key storage
> better.  In tests that I have run, the crypto that needs to be done to
> support SSL is faster in C than Java.  Also, Tomcat stores any key
> information in a flat file, where Apache will prompt for a password on
> startup.  Now some administrators might like this better, because
> Tomcat will then start automatically at boot time, I would not want
> any password of mine sitting in the clear in a test file.

The next Tomcat 5.5 release will include APR based connectors, where
SSL will (predictably) use OpenSSL.

> 2. If you are hosting your site using port 80 on Unix boxes this means
> running Tomcat as root.  I can think of very few reasons why Tomcat
> needs to be run as root.  Apache has the ability to 'downgrade' user
> privileges once Apache is started.

I think you should have googled for that. You can use either kernel
level redirection (iptables, for example), or use jsvc.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: What are those "No such list!" s and "Illegal IMail List Server Command!" ?

[Remy Maucherat]

On 5/17/05, Will Hartung <[EMAIL PROTECTED]> wrote:
> I'm confident the Powers That Be are working diligently to fix the problem,
> whatever the problem may be, so I'm not taking any dramatic measures.

I don't know about that (at least in the immediate future). Yoav is
away this week, and the ASF email servers are having major problems.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: AW: strange autodeploy behaviour on 5.5.9

[Remy Maucherat]

On 5/13/05, teknokrat <[EMAIL PROTECTED]> wrote:
> I don't understand this. I am packing my MyApp.xml context with the war
> ( in the root ). Is this wrong? Whats are the surefire instructions to
> have your war hot deploy?

The bug linked is not related to your situation in any way (it should
be obvious reading it). You seem to be experiencing file locking
problems, so read the FAQ on Windows file locking.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Autodeploy not working on Tomcat 5.5.9

[Remy Maucherat]

On 5/10/05, Marquez, Omar <[EMAIL PROTECTED]> wrote:
> Hi Luntz,
> 
> Thanks for answering.
> 
> this is from my server.xml
> 
>  appBase="webapps"
>   autodeploy="true"
>   unpackWARs="true"
>   name="localhost">
>  path="/webapp" reloadable="true">
> 
> /usr/local/tomcat/conf/context.xml
>   WEB-INF/web.xml
> 
>  path="/OES2" reloadable="true" >
> 
> /usr/local/tomcat/conf/context.xml
>   WEB-INF/web.xml
> 
>   

Contexts hardcoded in server.xml are not autodeployed or manageable
(except to some extent through the admin webapp). They are hardcoded
and always deployed on startup, and that's it.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: DBCP monitoring tool

[Remy Maucherat]

On 5/9/05, Gabriel Belingueres <[EMAIL PROTECTED]> wrote:
> Hi,
>  Are there any DBCP monitoring tool that allow me to monitor how many open
> connections (and other stats) does DBCP holding?

With Tomcat 5.5.4+, DBCP datasources should have an associated MBean,
with all the useful statistics.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: New logs showing up under Tomcat 5.5.9

[Remy Maucherat]

On 4/29/05, Ryan Daly <[EMAIL PROTECTED]> wrote:
> All:
> 
> Just upgraded to 5.5.9 yesterday.  Can anyone quickly tell me what the
> extra log files are in the logs directory?
> 
> I'm getting: admin.2005-04-28.log, catalina.2005-04-28.log, host-
> manager.2005-04-28.log, localhost.2005-04-28.log, and
> manager.2005-04-28.log
> 
> They're all 0 bytes.  Can I stop them from showing up?

These files shoudn't be empty.

You can read about logging configuration in the docs:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/logging.html

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: TC v5.5.9 Won't Server *.htm Files

[Remy Maucherat]

On 4/27/05, Bob Bronson <[EMAIL PROTECTED]> wrote:
> Hello all,
> 
> I'm sure this must be a configuration issue. I am running TC 5.5.9 as a
> stand-alone server (not w/Apache). The problem I'm seeing is that when
> I point my browser to an "index.htm" file, Tomcat gives me a 404,
> telling me it cannot find "index.jsp".
> 
> Please notice I said, "index.htm" and not "index.html".
> 
> Here's a peek at the HTTP headers as captured by Firefox. I'm only
> showing the relevant headers.
> 
> GET /fred/bob/index.htm HTTP/1.1
> Host: xxx.test1.com
> 
> HTTP/1.x 404 /fred/bob/index.jsp
> Server: Apache-Coyote/1.1
> 
> Is that crazy? I'm asking for index.htm and it  *DOES* exist. If I
> rename it to index.html everything works fine.
> 
> I know what you're thinking -- probably I do not have the "welcome
> files" set right in my default web.xml. Well, here it is:
> 
> 
> index.html
> index.htm
> index.jsp
> 
> 
> And I am *NOT* overriding these in the web app's web.xml.
> 
> Can someone running TC 5.5.9 as a standalone server please see if you
> can serve an index.htm file?

As it did sound funky enough to be verifiable, I tried it. Renamed
index.html -> index.htm in servlet-examples, but it worked fine
(/servlet-examples/ returns the file, as does
/servlet-examples/index.htm, but /servlet-examples/index.html returns
a 404).

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Tomcat 5.5.x returns wrong value for request.getRequestURI()

[Remy Maucherat]

On 4/15/05, Yaakov Chaikin <[EMAIL PROTECTED]> wrote:
> > 1) Applies to the core request class behavior. Cool, it works. The RD
> > has to wrap it using a request wrapper, so it does not apply.
> 
> So, what you are really saying is that the API should have pointed out
> that getRequestURL() does not work the same way every time. Then, I am
> not sure how anyone could have arrived at the conclusion that the
> words "... URL the **client** used to make the request..." really
> means "unless something else happens behind the scene" and the
> returned value is no longer what the **client** used. That doesn't
> seem strange to you, taking only into account what has been said?

I'm just pointing out you're not actually using the same class. The
javadoc for the base class mentions the behavior of the non-wrapped
base request class. After going in the request dispatcher and
wrapping, this behavior is not the same.

> > 2) How about trying things instead of making what-if theories ? (hint:
> > it works fine) ;)
> 
> I haven't tried this particular part. True. I HAVE tried everything
> else I mentioned however. Are you saying that how things really work
> ONCE AGAIN is not the way the servlet spec describes they should?
> Quote 8.4.2:
> "If the forwarded servlet was obtained by using the getNamedDispatcher
> method, these attributes **must not be set.**"

Well, the path values are simply set to the original ones, and,
indeed, there are no attributes.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Tomcat 5.5.x returns wrong value for request.getRequestURI()

[Remy Maucherat]

On 4/15/05, Yaakov Chaikin <[EMAIL PROTECTED]> wrote:
> I checked out the spec section 8.4.2 Forwarded Request Parameters.
> 
> It does seem to me that it implies that the parameters is where one
> would get the original URI from.
> 
> However, there are still 2 problems that I can see:
> 1) The API says: "URL the client used to make the request"
> 2) 8.4.2 says that these parameters are NOT to be set if you obtain
> the RequestDispatcher object using getNamedDispatcher() method. How
> would you get at the original URI/URL then (without custom coding)?

This is not constructive argumentation.

1) Applies to the core request class behavior. Cool, it works. The RD
has to wrap it using a request wrapper, so it does not apply.

2) How about trying things instead of making what-if theories ? (hint:
it works fine) ;)

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Tomcat 5.5.x returns wrong value for request.getRequestURI()

[Remy Maucherat]

On 4/15/05, Yaakov Chaikin <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> Using Tomcat 5.5.7 (tried Tomcat 5.5.9 with the same results) on Windows XP.
> 
> When forwarding to a JSP page that is located in
> /WEB-INF/jsp/success.jsp and calling:
> <%= request.getRequestURI() %> inside the success.jsp page, the result I get 
> is:
> /WEB-INF/jsp/success.jsp
> 
> I am pretty sure that according to the API, this is the wrong result.
> It should have returned the URI of the **request**, not the path to
> the resource.
> 
> Is this a known bug or there is some weird Tomcat setting that I need
> to change. I ran this on Tomcat without changing any of the original
> settings.
> 
> BTW, the same is true of request.getRequestURL(). It returns (peculiar 
> enough):
> http://localhost:8080/WEB-INF/jsp/success.jsp

This is not a bug, as it's intentional, and hasn't been shown to
contrdict the spec. The spec seems to hint that this should use the
path elements (but is very vague). I didn't quite agree with the
change, but didn't actually care about the issue, so you can try
asking for clarifications to Sun or on tomcat-dev.

If you want to change that, hack the request wrapper code a little,
it's very easy.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Way to specify SingleSignOn session timeout?

[Remy Maucherat]

On 4/14/05, Jonathan Eric Miller <[EMAIL PROTECTED]> wrote:
> After looking at the code, it looks like the SSO session doesn't go away
> until all other sessions for the user have expired. So, as far as I can
> tell, the SSO session doesn't have it's own session timeout as far as I can
> tell.

Indeed.

OTOH, if one of the sessions is explicitely invalidated, the SSO will
go away right away. I think that's the most appropriate behavior, but
changing it is very easy using a little code hacking.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: JULI and logging

[Remy Maucherat]

On 4/14/05, Jonathan Eric Miller <[EMAIL PROTECTED]> wrote:
> What I did was change my common/classes/logging.properties file to the
> following. With this setup, everything goes into catalina.out. Note, I found
> that if JULI is enabled, it appears to ignore the
> java.util.logging.config.file property if you passed it in as a system
> property.

It does not ignore it, but virtually no logging will go to the root logger.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: [ANN] Tomcat 5.5.9 voted stable

[Remy Maucherat]

On Apr 11, 2005 9:35 PM, Christoph Kutzinski <[EMAIL PROTECTED]> wrote:
> Yoav Shapira wrote:
> 
> > Please note that while all core features have been tested and voted stable,
> > there is a known issue in this build related to the clustering module. The 
> > fix
> > for this issue is available by itself at Bugzilla, and will be included in
> > subsequent Tomcat releases. Again, this issue only impacts users of Tomcat's
> > native clustering module.
> 
> Where can I find information about this issue? I found nothing in the
> release notes.

It's here:
http://issues.apache.org/bugzilla/show_bug.cgi?id=34389

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Tomcat 5.5.x and Java 1.5

[Remy Maucherat]

On Apr 7, 2005 11:15 AM, Steiner, Stephan <[EMAIL PROTECTED]> wrote:
> Hi
> 
> I'm trying to compile a couple of jsp pages that use Java 1.5 syntax. I
> followed the Jasper how-to and replaced the jdt jar with the latest ant.jar
> (taken from the Ant 1.6.2 distribution). After a restart of Tomcat, Tomcat
> now uses the JDK compiler (I see different error message for my Java 1.5
> code). However, the default is to write code compatible with JDK 1.4.
> 
> So I added the following lines to my web.xml config file (in the jsp servlet
> section) and restarted Tomcat again:
> 
> 
> compilerSourceVM
> 1.5
> 
> 
> compilerTargetVM
> 1.5
> 
> 
> After a restart, trying to access any page yields a 404 error, with no
> entries in the logfiles. Setting the version number to 1.4 instead yields
> the same behavior. Removing those two init-params again and everything is
> back to normal, but I still can't use Java 1.5 features. Is there anything
> I'm missing to run Java 1.5 code on Tomcat 5.5.x?

I updated JDT in Tomcat CVS to 3.1M6, as well as handling of those two
properties (which may or may not fix Ant, as I didn't test it), so you
can try building a new Jasper from CVS.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Threads / Tomcat Lite

[Remy Maucherat]

On Apr 6, 2005 12:43 AM, Steffen Heil <[EMAIL PROTECTED]> wrote:
> Hi
> 
> 1. Question
> 
> I need to store some information which differs for each request.
> My problem: I need it at a place where I have no access to the request, the
> response or the session.
> 
> Now, I can also do it using ThreadLocal variables, but these take time.
> I would prefer to use a custom Thread class for the Processors and to extend
> that by an aditional variable.
> I could then cast Thread.currentThread() to my own Thread class and use the
> variable.
> 
> So, is it possible to specify, which class is used?

Well, you should have looked at the thing returned by
Thread.currentThread() first, I think. This would have answered all
your questions.
However, ThreadLocals are fast and efficient, so I recommend you use them.

> 2. Question
> 
> Is it possible to use the HTTP connector of tomcat only?
> Everything I have is served by a single servlet. I do NOT need logging,
> filters, mappings (other than the single one), and so on.
> Every request goes all the way through tomcat's valves and filters. This
> takes a little time. A little time I'd like to save.
> 
> Any way?

Overhead added is negigible (really, I mean it), so I recommend you
don't bother. Although you may not need some of the features, I think
you are probably using IO.

The Tomcat HTTP core (which is indeed fully independent, so you could
use it as a HTTP server) basically only allows using byte arrays for
IO, which is more restrictive obviously.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Tomcat taking 125 seconds to launch

[Remy Maucherat]

On Apr 3, 2005 11:04 PM, Michael Mehrle <[EMAIL PROTECTED]> wrote:
> Hi Mark:
> 
> Okay, the machine is a P4, 1GB RAM (512MB assigned to tomcat), and besides
> Tomcat 5.5.9, there's Apache running and mysql. Apache is not in use much. I
> have the apache logging set to WARN, so the slowdown is not due to excessive
> logging.
> 
> The site is running an image gallery and there are probably around 100 jps
> for the gallery and image pages. I am not sure if adding jsps does affect
> the startup time.
> 
> The configuration is a modified version of appfuse 1.5 (struts and
> hibernate) - so this should give you a good idea of how it is structured.
> FYI: on my development machine here at home Tomcat starts in 28 seconds -
> identical project and configuration.
> 
> Any help would be greatly appreciated - if you need any configuration files,
> just ask and I'll email them to you.

You didn't post anything really relevant, but maybe it could be caused
by the port binding (for some reason).

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: 5.5.x JDBCRealm problem - wasn't this fixed?

[Remy Maucherat]

On Mon, 28 Mar 2005 09:28:24 -0800, Michael Mehrle <[EMAIL PROTECTED]> wrote:
> Fixed indeed - I was up late yesterday and jumped on that 5.5.9 release like
> it was manna from heaven (best analogy I could think of - I'm not
> religious). Logged in this morning after a night of inactivity and
> everything seems to be working :-)

Good.

> Thanks for taking care of this, guys - please forward my regards to the
> person who fixed this. I also must point out that everything seems to be a
> bit snappier now - have there been any performance increases? I'm running an
> image gallery all through tomcat, so it's hosting *everything* - looks a lot
> faster than before. Good job.

There were no performance improvements since 5.5.4, so Ithere should
not be any difference with the new build.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: 5.5.x JDBCRealm problem - wasn't this fixed?

[Remy Maucherat]

On Sun, 27 Mar 2005 16:57:53 -0800, Michael Mehrle <[EMAIL PROTECTED]> wrote:
> Sorry for reposting this, but I'm really desperate - anyone??

In 5.5.9 (see the changelog). We recommend using the data source
realm, BTW, which does everything much better.

> I just switched from 5.0.28 to 5.5.8 on my Fedora server. The app works fine
> but after some inactivity of approx 7 hours I try to log in and get the
> following error:
> 
> at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
> at java.lang.Thread.run(Thread.java:595)
> [tdx] WARN [http-8080-Processor23] JDBCRealm.getPassword(555) | Exception
> retrieving password for "molecool"
> 
> If I recycle tomcat it works fine and as long as I keep hitting the server I
> don't get this problem. However, if I am gone for a few hours and come back
> I encounter this problem. Now, I did some digging online and others have
> encountered this as well. But I was under the impression that this bug was
> fixed and that 5.5.8 wasn't leaking connections anymore. Just for sh...ts
> and giggles I tried 5.5.7 and it's got the same problem.
> 
> Here's my cofiguration:
> 
>  antiJARLocking="true" antiResourceLocking="true">
> 
>driverName="@DB-DRIVERNAME@"
>connectionURL="@DB-URL@"
>   connectionName="@DB-USERNAME@" connectionPassword="@DB-PASSWORD@"
>userTable="app_user" userNameCol="username"
> userCredCol="password"
>userRoleTable="user_role" roleNameCol="role_name" />
> 
>maxActive="100" maxIdle="30" maxWait="1"
>   driverClassName="@DB-DRIVERNAME@"
>   username="@DB-USERNAME@" password="@DB-PASSWORD@"
>   url="@DB-URL@"
>   defaultAutoCommit="true" removeAbandoned="true"
>   removeAbandonedTimeout="60" logAbandoned="true"/>
> 
> 
> I would really appreciate some help here. There appears to be some
> jakarta-.jar file that fixes this, but I was unable to dig it up. I also
> tried to get tomcat out of cvs, but the build process seems to be more than
> I can handle at this point (missing references).
> 
> This site needs to be up and running by Tuesday - ANY pointers would be very
> welcome ;-)
> 
> Michael

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Trying to disable Coyote gzip compression only when there is a server response status code of 500...

[Remy Maucherat]

On Tue, 22 Mar 2005 13:39:55 -0500, Eric Butler <[EMAIL PROTECTED]> wrote:
> First of all, thanks to all the developers and users that have
> contributed to Tomcat.  It's quite an amazing piece of software.
> 
> I'll start by telling you why I am trying to do this, what approaches I
> have taken in my attempts to do it, and then I'll ask for some
> suggestions on other approaches that may work better.
> 
> *Why*
> We have an MS .Net (1.1) client talking SOAP over HTTP to Webservices
> built on Sun's JWSDP 1.3 (via Tomcat).  There is a pretty strict
> requirement to compress responses as they are usually 200-1000KB.  There
> is a 'lack of feature' in the MS .Net Webservice client implementation
> in that it is not possible to decompress the HTTP response when there is
> a server response code of 500.  The SOAP spec requires that SOAP Faults
> on the server set the response code to 500, and thus we are unable to
> process any SOAP faults on the client.  In all other cases we are cool
> in decompressing the responses.  Since there don't exist any options for
> us on the client we are limited to the server for solutions.
> 
> *Approaches attempted and failed*
> -Servlet filters - a servlet filter only has access to the
> HttpServletRequest and the HttpServletResponse and neither of these is
> aware of the response status code.

Wrap the response object. A servlet like the compression filter has to
wrap anyway to be able to work.

> -Coyote's compression option with a numerical value higher than all Soap
> Fault sizes - it seems that the content-length of the response is always
> set to -1, either by Sun's JWSDP or because the HTTP response is
> chunked.  I'm not sure which is the cause, but when the content-length
> is -1, the response is always compressed.
> -We tried an endless list of things on the .Net client in an attempt to
> decompress the SOAP Fault responses to no avail.
> 
> *Approaches attempted and suceeded*
> -Modifying org.apache.coyote.http11.Http11Processor.class by adding this
> immediately inside of isCompressible()
> if ( response.getStatus() == 500 ) {
>  return false;
> }
> I know this isn't pretty but it works.  This will be acceptable if I
> can't find a better option, but it will require that each time we
> upgrade Tomcat, we'll need to compile a custom Http11Processor.  I'll
> also need to check that we aren't violating the Apache License.

It obviously does not violate the Apache license.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: JDBCRealm changes from Tomcat 5.0.x to 5.5.x

[Remy Maucherat]

On Wed, 09 Mar 2005 17:39:21 -0800, alexander dosher <[EMAIL PROTECTED]> wrote:
> and an
> 
> name="UserDatabase">
> 
> and i get
> java.lang.NullPointerException
>at javax.naming.NameImpl.
>at javax.naming.CompositeName.
>at org.apache.naming.NamingContext.lookup
> (etc.)
> 
> so please accept my application to the Frustration Club.  :(

You get a membership to the RTFM club instead ;)
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/realm-howto.html#DataSourceRealm

The JDBC realm in 5.5.8 obviously still has the bug related to
connection handling, as I only fixed it two days ago.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Tomcat 5.5.7. server.xml doc may be buggy...is it bugzilla time?

[Remy Maucherat]

On Thu, 10 Mar 2005 12:21:29 +0100, David Tonhofer, m-plify S.A.
<[EMAIL PROTECTED]> wrote:
> 00>Exception performing authentication
> 01>  javax.naming.NameNotFoundException: Name jdbc is not bound in this 
> Context
> 02>  at org.apache.naming.NamingContext.lookup(NamingContext.java:769)

Ah, cool, so you did not read the docs for the datasource realm, then ...
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/realm-howto.html#DataSourceRealm
-> localDataSource

> Out of luck? Bugs related to other Tomcat versions helped out:
> 
> 
> 
> 
> I put the "Resource" element inside the "GlobalNamingResources" element, 
> described here:
> 
> ...and it worked!

Makes sense.

> Additionally:
> 
> The 'factory' attribute of the 'Resource' element is mentioned nowhere... o_O
> which is **BAD** because w/o the factory value the Realm Authentication seems 
> to
> reduce to 'Access All Areas' - you don't get no error in the catalina log 
> either.

You indeed should not be specifying the factory, and it works fine.
Please stop whining.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: JDBCRealm changes from Tomcat 5.0.x to 5.5.x

[Remy Maucherat]

On Wed, 9 Mar 2005 10:40:37 -0500, Phillip Qin
<[EMAIL PROTECTED]> wrote:
> Could any one who has tested it post his result? I am really frustrated by
> the "sometime buggy" 5.5 releases and I had to revert to 5.0.28.

You can also use the realms form 5.5.4, as they don't have problems.

The regressions were introduced when adding digest authentication
support to the database realms.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: JDBCRealm changes from Tomcat 5.0.x to 5.5.x

[Remy Maucherat]

On Tue, 8 Mar 2005 16:28:22 -0700, Richard Mixon (qwest)
<[EMAIL PROTECTED]> wrote:
> Remy,
> Thanks - but where do I get the new class file?

The Apache mail server, which, BTW, must be the worst mail server in
existence, chooses to let through all the viruses and spammers of the
world, but is refusing my perfectly legitimate attachement. So sorry,
you have to either build it from CVS (which is easy) or get it from a
nightly build.

I'd like to add that the DataSource realm works differently from the
JDBC realm. As a result, it would reconnect transparently, and the
problem you have won't occur. If you decide to try the data source
realm, I recommend using the version from 5.5.8, unless you expect a
really low amount of authentications (it will take a little time for
the connection pool to reclaim the resources which are not properly
closed by the realm).

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: JDBCRealm changes from Tomcat 5.0.x to 5.5.x

[Remy Maucherat]

On Tue, 08 Mar 2005 15:16:41 -0800, Hassan Schroeder
<[EMAIL PROTECTED]> wrote:
> Richard Mixon (qwest) wrote:
> 
> > We upgraded from Tomcat 5.0.19 to Tomcat 5.5.7 in production and are now
> > getting JDBC connection errors when the site has not been accessed for a
> > while.  This is happening when a user tries to login - we use a
> > JDBCRealm to authenticate the user.
> 
> > Would using the DataSourceReal provide any help here?
> 
> I'm using a DataSourceRealm with 5.5.7 and not seeing any problems
> reconnecting at any time (MySQL 4.1.7 + Connector/J 3.1.6)...

Be careful about this bug with the DataSourceRealm (fixed in 5.5.8):
http://issues.apache.org/bugzilla/show_bug.cgi?id=33357
Similarly, I would appreciate testing of the fix.

I agree there's absolutely no reason to use the regular JDBC realm,
which can be a bottleneck in some cases.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: JDBCRealm changes from Tomcat 5.0.x to 5.5.x

[Remy Maucherat]

On Tue, 08 Mar 2005 14:28:12 -0800, alexander dosher <[EMAIL PROTECTED]> wrote:
> i'm getting the same problem, w/MySQL 4.1.8 & 3.1.6 connector (except my
> error is "Software caused connection abort" rather than "broken pipe -
> but same underlying cause, MySQL timing out the connection).
> autoReconnect doesn't work for me either.  sounds like perhaps i should
> bail on 5.5.* & go to 5.0 for a while?

I'd be extremely glad if you could test this possibly fixed realm.
Replace the existing class in server/lib/catalina-optional.jar.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: 5.5.8 release timeframe?

[Remy Maucherat]

On Mon, 7 Mar 2005 15:07:15 -0500, Andy Kriger <[EMAIL PROTECTED]> wrote:
> I've read the FAQ regarding 'when it's ready' and I haven't seen
> anything about this in the mailing list archives, however, I still
> need to be able to answer this question for my boss.
> 
> We started up the 5.5 path with .4, which had a bug with POST and
> basic auth that required upgrading to .7 which has a bug with
> DataSources not closing connections that is fixed in .8 - can anyone
> give a timeframe for a 5.5.8 release? A rough scale would be fine -
> days? weeks? months?
> 
> Even a guesstimate based on experience with how long previous alpha's
> took to release would help me ease my boss's concerns.

Well, it's not that hard to either:
- use 5.5.8 even if we have a label "alpha"; if you ask me, it's
stable, but we simply didn't vote on it (and since the vote still
hasn't happened, I'd say we'll go with the next build instead)
- get the replacement class you need from 5.5.8, or from CVS, etc :)

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?

[Remy Maucherat]

On Thu, 03 Mar 2005 12:11:27 -0500, Adrian Robert
<[EMAIL PROTECTED]> wrote:
> > That's extremely odd.  What version of Tomcat are you running?  That's
> > a bug
> > because WEB-INF/classes should be put in the classpath before jars in
> > WEB-INF/lib.

I agree it's very odd.

> This is 5.5.7, with the 1.4 compatibility package on MacOS.  I've
> experienced similar issues before with different tomcat versions,
> though I had forgotten that in this case..
> 
> Note I do NOT unpack the app from a war, just copy the full hierarchy
> straight under webapps.  Also, the WEB-INF/classes/log4j.properties
> file was a symblic link.  Maybe one of these makes a difference?

Yes, I think the symlinking is the issue.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?

[Remy Maucherat]

On Wed,  2 Mar 2005 11:09:56 -0600, Jacob Kjome <[EMAIL PROTECTED]> wrote:
> Quoting Adrian Robert <[EMAIL PROTECTED]>:
> exists.  This would continue to make Tomcat-5.5 more involved in logging than
> it should, though.  I think Yoav Shapira has it right when he says that Tomcat
> should not really be directly involved in logging, but use the external
> implementation.  I'm not sure what the solution is.  Probably needs more
> discussion.

That's the idea. Logging services should be "external", rather than
proprietary to Tomcat. the problem comes that we need some kind of
defaults (like the current one, which is "use whatever
java.util.logging defaults are configured").

> > Hmm..  I'm using log4j-1.2.9.  I had the jar in both places but wasn't
> > getting the isolation since my webapp was still pumping things into
> > tomcat.log according to the container's log4j.properties..  However,
> > I'm creating the logger in a static block in one of my webapp's classes
> > -- could that have been the issue?
> 
> Do you have webapp libraries sitting in a shared classloader such as 
> shared/lib
> or common/lib?  That would do it.
> 
> 1.  Make sure all your application classes are in WEB-INF/lib or 
> WEB-INF/classes
> 
> 2.  Make sure log4j.jar is in WEB-INF/lib (remove commons-logging.jar if it is
> there.  If you don't specifically need it, it can, and will, cause problems 
> for
> you)
> 
> 3.  Make sure log4j.jar and commons-logging.jar (not
> commons-logging-api.jar!!!) are in common/lib
> 
> 4.  Make sure you have log4j.properties in both common/classes and
> WEB-INF/classes.  You might even want to switch to using a log4j.xml config
> file for your webapp just to be sure that you aren't picking another log4j.xml
> file improperly distributed in a jar file.
> 
> If you do all the above, logging should work as you expect.  Note that for
> ServletContext.log() statements to go to context-specific files, you will 
> still
> have to define the loggers as detailed in the example log4j.properties that I
> sent in my previous email.

It's a bit tricky sometimes. For example, getting the container logger
a bit too early, when the context CL isn't set to the webapp CL (it
doesn't exist yet) can get you a logger based on the main
configuration. That's an issue with the current CVS code, but I think
it should be ok with the version used here (although it's tough to be
100% sure).

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?

[Remy Maucherat]

On Wed, 02 Mar 2005 09:21:08 -0500, Adrian Robert
<[EMAIL PROTECTED]> wrote:
> 
> On Mar 1, 2005, at 6:45 PM, Remy Maucherat wrote:
> > On Tue, 01 Mar 2005 18:18:49 -0500, Adrian Robert
> > <[EMAIL PROTECTED]> wrote:
> >> However, I can't seem to find the right combination of
> >> log4j.properties
> >> lines, or maybe I'm trying something impossible.  (I can't find good
> >> docs on the uses of log4j.properties when used inside the hierarchical
> >> classloading context that tomcat provides.)  What keeps happening is
> >> that the webapp's log statements keep going into the global tomcat
> >> log.
> >>   Would I be better off with JDK logging instead?
> >
> > I am working at the moment on a small package (which will be an
> > implementation of java.util.logging) which will allow you doing that
> > using the JDK logging. The main issue with it as supplied in the JDK
> > is that there is only one global configuration per JVM. The trick is
> > to make that per classloader, with delegation, so that webapps are
> > isolated. At the moment, I think log4j is your only choice
> > (unfortunately, I'm no expert, so I can't give you tricks with this
> > particular configuration).
> >
> > In the same package, I will also provide a handler with daily rotation.
> >
> > It should be done by the end of the week (it doesn't work at the
> > moment, I'm busy debugging ;) ).
> 
> Great news.  I'm happy to help test this.  I'd rather use JDK logging
> than log4j if possible to avoid an additional deployment dependency.

Actually, this is still an extra dependency: you have to add a JAR
(10KB at the moment, but it'll likely grow to 12KB once I finish the
needed extensions to the standard java.util.logging) for the core (the
LogManager) and the rotating file handler (the JDK impl's handler
don't have anything which rotates).

It works by providing a replacement impementation for the JDK's
LogManager which keeps a per classloader set of loggers. This is
configured using a per classloader logging.properties (same format as
the main logging.properties of the JDK, but with a few additional
tricks to allow more flexibility with defining handlers and assigning
them to loggers whenever needed). Properties files are simple, and are
a good default. If no logging.properties exist anywhere, the JDK
configuration will be used. Support for other configuration sources
can be done using separate LogManager implementations.

At the moment, the code will live in the Tomcat CVS, but the general
consensus is to migrate it to commons eventually. We'll see. I don't
know either if it will be included in the Tomcat binary; at the
moment, I'd say it will not.

The "seed" code for the new LogManager (which is attached to bug
33143) is here:
http://issues.apache.org/bugzilla/attachment.cgi?id=14036
It doesn't actually work, and all it does is separate logger instances
(which is quite good already, as you can programmatically set levels,
assign handlers, etc, but you need to code for java.util.logging to
use that). So I'm working on extending it at the moment to allow non
programmatical configuration, where your webapp can simply be coded
for commons-logging.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?

[Remy Maucherat]

On Wed, 02 Mar 2005 09:22:33 -0500, Adrian Robert
<[EMAIL PROTECTED]> wrote:
> > ...
> >
> > log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localho
> > st].[/myapp]=INFO, MYAPP
> > log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[loc
> > alhost].[/myapp]=false
> 
> I don't understand this bracket notation.  Is it documented anywhere?
> Is interpretation of it something implemented by tomcat or by log4j?
> Would it help me achieve what I'm trying to get without changing my
> webapp's code away from ServletContext.log()?

The logger names used in Tomcat are documented in the configuration
pages. For example for webapps, it's here, in the "Logging" paragraph:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/context.html

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?

[Remy Maucherat]

On Tue, 01 Mar 2005 18:18:49 -0500, Adrian Robert
<[EMAIL PROTECTED]> wrote:
> I'm having trouble approximating the earlier tomcat per-context
>  functionality using log4j under tomcat-5.5.  Basically, I
> would like to have one file coming out under $CATALINA_BASE/logs/ per
> web application context.  This appears to be no longer possible through
> ServletContext.log().  So I tried using log4j:
> 
> 1) put log4j.jar, commons-logging.jar in common/lib AND
> webapps/*/WEB-INF/lib
> 2) put log4j.properties in common/classes AND webapps/*/WEB-INF/classes
> 
> However, I can't seem to find the right combination of log4j.properties
> lines, or maybe I'm trying something impossible.  (I can't find good
> docs on the uses of log4j.properties when used inside the hierarchical
> classloading context that tomcat provides.)  What keeps happening is
> that the webapp's log statements keep going into the global tomcat log.
>   Would I be better off with JDK logging instead?

I am working at the moment on a small package (which will be an
implementation of java.util.logging) which will allow you doing that
using the JDK logging. The main issue with it as supplied in the JDK
is that there is only one global configuration per JVM. The trick is
to make that per classloader, with delegation, so that webapps are
isolated. At the moment, I think log4j is your only choice
(unfortunately, I'm no expert, so I can't give you tricks with this
particular configuration).

In the same package, I will also provide a handler with daily rotation.

It should be done by the end of the week (it doesn't work at the
moment, I'm busy debugging ;) ).

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Tomcat 5.5.7 hangs on startup

[Remy Maucherat]

On Fri, 25 Feb 2005 17:13:41 -0500, Curtis, John G
<[EMAIL PROTECTED]> wrote:
> Having a problem getting Tomcat 5.5.7 to start.  The configuration is
> basicly the default except for  some trival changes to the
> tomcat-user.xml.  The catalina.out leads me to believe it's a problem
> with the ajp, but that's just my best guess 'cause it hangs just prior
> to starting the connector:
> 
> tail catalina.out
> Feb 25, 2005 5:10:10 PM org.apache.catalina.core.ApplicationContext log
> INFO: ContextListener: contextInitialized()
> Feb 25, 2005 5:10:10 PM org.apache.catalina.core.ApplicationContext log
> INFO: SessionListener: contextInitialized()
> Feb 25, 2005 5:10:12 PM org.apache.catalina.core.ApplicationContext log
> INFO: ContextListener: contextInitialized()
> Feb 25, 2005 5:10:12 PM org.apache.catalina.core.ApplicationContext log
> INFO: SessionListener: contextInitialized()
> Feb 25, 2005 5:10:15 PM org.apache.coyote.http11.Http11Protocol start
> INFO: Starting Coyote HTTP/1.1 on http-8080
> Hangs here forever.
> 
> OS is Solaris 8
> Java is version 1.5
> 
> I have the same configuration working fine on a Windows 2000 and Windows
> XP box.

If Tomcat is hung, always try to get a thread dump.
I suppose the problem occurs when binding the server socket.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: How to prevent Context Reload upon changing web.xml

[Remy Maucherat]

On Tue, 22 Feb 2005 14:21:24 -0800, Neeraj Vora <[EMAIL PROTECTED]> wrote:
> I migrated from Tomcat 4.0.2 to Tomcat 5.5.7. The former was not reloading
> the context if I changed application's web.xml file after deployment. The
> latter does that. Is there a way to prevent it? During the searching for
> this I read a post that having a context entry with reloadable attribute set
> to false does not prevent Tomcat from reloading the WebApp upon touching the
> web.xml.

Look in conf/context.xml.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Free online presentation on native webserver integration and Tomcat

[Remy Maucherat]

On Tue, 22 Feb 2005 12:24:28 -, Allistair Crossley
<[EMAIL PROTECTED]> wrote:
> Yep,
> 
> I was just pointing out the the Jboss site is inaccurate and may cause 
> confusion.
> 
> 1300 EDT is 1300-5 = 0800 not 1800, so us Europeans will all have to get up 
> rel early in the morning ;)

No, it's the opposite, it's late ;)

It's 13:00 + 6 for the Paris timezone (= 19:00 = 7 PM), and 6 PM for
London. I suppose the time is more to accomodate the west coast.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Free online presentation on native webserver integration and Tomcat

[Remy Maucherat]

On Tue, 22 Feb 2005 12:50:59 +0100, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Allistair Crossley wrote:
> > February 23, 2005 at 1pm Eastern Daylight Time (GMT -04:00, New York).
> >
> > I believe this should be GMT -5 however? No?
> >
> 
> February 23, 2005 at 18:00 GMT.
> So calculate to your own timezone :).

I think NY is GMT -5 indeed.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Free online presentation on native webserver integration and Tomcat

[Remy Maucherat]

Hi,

Mladen Turk and myself will do a free (registration required)
presentation tomorrow (Wednesday, February 23, 2005 at 1pm Eastern
Daylight Time (GMT -04:00, New York)), mostly on native web server
integration with Tomcat.

http://www.jboss.org/services/online_education

Topics which will be discussed include:
- short intro on Tomcat inside JBoss
- mod_jk configuration
- presentation of upcoming mod_jk features
- mod_proxy presentation

Nearly half of the presentation will focus on ongoing native connector
development and roadmap. It will be concluded by a demo of a failover
scenario featuring the newly added jkstatus. I know there are quite a
few people who are a bit confused about where this part of the Tomcat
development is going ;)

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: ThreadDeath with tomcat 5.5.7 and bouncycastle

[Remy Maucherat]

On Sun, 20 Feb 2005 09:00:58 +1100, Adam Jenkins <[EMAIL PROTECTED]> wrote:
> Hi All,
> 
> I'm getting a really odd error when I try to init a ciphers (or any
> other artifact for that matter) using BC as the provider in tomcat 5.5.7
> (struts application).
> 
> The call is simply
> 
> final Cipher rsaCipher = Cipher.getInstance("RSA/ECB/PKCS1Padding",
> "BC");
> 
> and I get the following:
> 
> java.lang.ThreadDeath
> at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1221)
> at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1181)
> at java.security.Provider
> $Service.getImplClass(Provider.java:1116)
> at java.security.Provider
> $Service.newInstance(Provider.java:1074)
> at javax.crypto.Cipher.getInstance(DashoA12275)
> at javax.crypto.Cipher.getInstance(DashoA12275)
> 
> The bouncy castle libraries are included in the classpath, and are being
> initialized correctly in the servlet init with the call:
> 
> Security.addProvider( new BouncyCastleProvider());
> 
> JVM Details:
> java version "1.5.0-rc"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63)
> Java HotSpot(TM) Client VM (build 1.5.0-rc-b63, mixed mode)
> 
> uname -r:
> 2.6.8-gentoo-r10
> 
> Anyone have any ideas?

Yes, plenty :)

The first one is to not crosspost, especially to lists where it is OT.

The second one is, don't put your security provider in WEB-INF/lib
unless you plan to remove it when the webapp is stopped (or don't
expect to reload your application). Even if you do remove it, it's a
little bit risky, and IMO bad design to do this kind of thing inside a
webapp.

And the third one is to post full stack traces.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: running tomcat using sablevm

[Remy Maucherat]

On Fri, 18 Feb 2005 16:48:36 +0530, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> 
> 
> Where could I find the changes which you merged. Please help me out as I
> need it to fix my sablevm problem.

I think you should give up on sable at the moment. I have never heard
of anyone doing anthing Tomcat related with it, so it doesn't look
good.

Apparently, if you get Kaffe (www.kaffe.org) from CVS and build it,
you might be able to run Tomcat 5.5 (with the usual JDK 1.4 compat for
the jmx.jar, unless they also merged in a JMX impl) out of the box.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: running tomcat using sablevm

[Remy Maucherat]

On Fri, 18 Feb 2005 09:54:30 +0530, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> 
> Hello,
> 
> Has anyone tried running tomcat using sablevm (JVM). I am trying to run
> tomcat but it fails. It gives ClassDefNot Found error. I don't know how
> to go about running the tomcat.
> 
> Any suggestions or any help is appreciated!!!

No idea about Sable, but Kaffe from CVS works, as long as you help it
by adding stuff in the classpath (commons-logging-api.jar and
jmx.jar). Basically it doesn't read the manifest which are in JARs
yet.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Deploying with Tomcat 5.5

[Remy Maucherat]

On Wed, 16 Feb 2005 13:40:12 -0500, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Is there not a way to deploy a WAR file in Tomcat 5.5 to a new virtual
> host without having to use the Admin web module to add the new host
> element and or manually modifying the server.xml file.  I can seem to find
> any documentation on this.
> 
> I know in JBoss you can include an XML file that has the host information
> in it so it deploys properly.

I had plans to do a small host manager webapp similar to the regular
manager. This would be the cleanest solution.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Jasper 2 problem with core taglibs in 5.5.7?

[Remy Maucherat]

On Wed, 16 Feb 2005 16:40:25 +, David Kennedy
<[EMAIL PROTECTED]> wrote:
> Hi folks,
> I have a Ant build which includes pre-compilation of JSPs. This has been
> working happily during prototyping with Tomcat 5.5.4, but has broken now
> that we have moved to Tomcat 5.5.7 as the latest stable build, which
> worries me a lot.
> 
> The error I get during the build is:
> org.apache.jasper.JasperException: The absolute uri:
> http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml
> or the jar files deployed with this application
> 
> The Ant task:
>
>  
>
>  
>
>
>
>
>
>
>
>
>
>
>  
>
>  
>
> 
> ${lib-dir} contains jstl.jar and standard.jar, and the line in
> the JSPs causing trouble is:
> <%@ taglib uri="http://java.sun.com/jsp/jstl/core"; prefix="c" %>
> 
> I understand this sort of error to be typically to do with JSTL1.0/1.1,
> but I don't think this is an issue here, especially as 5.5.4 works fine.
>   The ONLY thing I change is the value of ${tomcat.dir}. Has anyone seen
> this, or can anyone suggest a resolution?

http://issues.apache.org/bugzilla/show_bug.cgi?id=33373

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Tomcat vs Jetty

[Remy Maucherat]

On Sat, 12 Feb 2005 10:51:53 +0100, PA <[EMAIL PROTECTED]> wrote:
> 
> On Feb 12, 2005, at 06:20, Peter Lin wrote:
> 
> > For those who are curious. I decided to run apache AB against jetty to
> > see if there are any differences.
> 
> If you are into this kind of micro-benchmarks, take a look at Simple:
> 
> http://simpleweb.sourceforge.net/
> 
> Niall Gallagher ran some comparisons between Apache, Resin and Tomcat:
> 
> http://simpleweb.sourceforge.net/performance/comparison.php
> 
> Quite instructive :P

Unless Peter does a round of benchmarking on that, I see nothing but
misinformation.

Right now, the test is not very fair (conviniently old Tomcat version;
not the same application code appeared to be running on both servers
as the other one doesn't support the servlet API) and not very well
specified either (there's text about the test, but I don't understand
it in a way that woud allow me to reproduce the test).

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: [OT] Re: Compression in the server.xml

[Remy Maucherat]

On Wed, 09 Feb 2005 06:31:07 -0500, Tim Funk <[EMAIL PROTECTED]> wrote:
> No. They are written in 2 different languages and have 2 different purposes.

Indeed. Integration will improve, though (the Apache/Tomcat connector
will be bundled in Apache and will be compatible with all the other
module combination (such as cache + ssl + gzip).

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Tomcat 5.5.7/DataSourceRealm/Manager app

[Remy Maucherat]

On Tue, 08 Feb 2005 21:49:16 +, Mark Thomas <[EMAIL PROTECTED]> wrote:
> It is a known bug that has been fixed and will be included in 5.5.8. Sorry.

Did it exist in 5.5.4, or is it a regression ?

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Tomcat 5.5.7/DataSourceRealm/Manager app

[Remy Maucherat]

On Tue, 8 Feb 2005 16:39:40 -0500, Phillip Qin
<[EMAIL PROTECTED]> wrote:
> I am having serious issue with Tomcat Manager app using DataSourceRealm
> during upgrading from Tomcat 5.0.28 to 5.5.7. The issue is, after I accessed
> Tomcat Manager app couple of times, I got this exception

It could be this issue:
http://issues.apache.org/bugzilla/show_bug.cgi?id=33357

The patch needs some testing, but you can grab the replacement class
from a nightly build, or build it from CVS.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: MemoryError: PermGen space after several redeployments

[Remy Maucherat]

On Tue, 08 Feb 2005 11:26:50 +0100, Peter Rossbach <[EMAIL PROTECTED]> wrote:
> Hello Matt,
> 
> I hope we have fix that with 5.5.8 see:
> 
>  >http://issues.apache.org/bugzilla/show_bug.cgi?id=26135

You can use a context listener to clean that up.

The container can't always cleanup after the application, so if you
want to really use redeployment, then you need to make sure that
applications are reasonably well designed. Easy example of a leak that
can't be fixed by the container: put a JAR in common with a static
class keeping references to some of the application objects (ex: some
sort of server global cache), and don't clean these up.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Solaris 10 Tomcat 5.5.7

[Remy Maucherat]

On Mon, 7 Feb 2005 12:55:56 -0500, Chad Kellerman
<[EMAIL PROTECTED]> wrote:
> Tomcat Users,
>I thought I would test out Tomcat 5.5.7 on a Solaris 10 (Ultra 60) so see
> how it performs.
> 
> Here is what I did.
> 
> edited /etc/profile
> JAVA_HOME=/usr/java
> export JAVA_HOME
> 
> exploded the tar ball in /opt/
> then created a link to jakarta.XX.XX name tomcat
> 
> I started tomcat, it started but there are messages in the catalina.out file
> that don't make sense.
> 
> catalina.out
> SEVERE: Exception starting filter Compression Filter
> java.lang.ClassNotFoundException: compressionFilters.CompressionFilter
> 
> Then I tried to go to the example pages on http://localhost:8080/jsp-examples/
> and recieved an error.
> 
> Feb 7, 2005 11:12:09 AM org.apache.catalina.core.StandardWrapperValve invoke
> SEVERE: Allocate exception for servlet
> org.apache.jsp.jsp2.el.basic_002darithmetic_jsp
> javax.servlet.ServletException: Wrapper cannot find servlet class
> org.apache.jsp.jsp2.el.basic_002darithmetic_jsp or a class it depends on
> 
> I have java 1.5.0_01 and Tomcat 5.5 installed on a Fedora server and
> everything works fine, but the java on the SOlaris server seems to mess
> things up a bit.
> 
> Anyone else see this?  Anyone else have a fix?

Did you use GNU TAR to extract the .tar.gz ?

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Version control in WebDAV component of Tomcat

[Remy Maucherat]

On Mon, 07 Feb 2005 22:25:20 +0800, Wong Onn Chee <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I am new to the latest version of Tomcat 5.5.
> I know that it has a bundled WebDAV component, but I can't get the
> version control feature working.
> Does any one know how I can do it?

If you mean Delta V, then there's no support for that, and you should
look into using Slide instead.

The Tomcat WebDAV servlet supports WebDAV level 1, with partial level
2 support (some complex locking operations are not supported).

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Updating running WARs?

[Remy Maucherat]

On Fri, 04 Feb 2005 17:45:12 -0600, Jonathan Wilson
<[EMAIL PROTECTED]> wrote:
> Someone else will be able to attest to this better than I, but there is
> a known issue with the classloader [I think] that doesn't release memory
> on a undeploy..eventually you'll run out of memory after a certain
> number of deploy/undeploys. You could try using the jvm's -Xmx modifier
> in your startup/catalina shell, which may buy you more time[guru input
> here, please]...

Do you mean this ?
http://issues.apache.org/bugzilla/show_bug.cgi?id=26135

It turned out to be a JDK feature ;)

> But my app starts up lightweight so I can schedule downtime a couple of
> hours or so in advance, then drop tomcat for a few minutes while I
> deploy manually. Maybe you could use the Manager: Stop the Service,
> undeploy, stop TC, start TC, deploy the service using the Manager, start
> service if necessary.

It is indeed difficult to guarantee that everything will be cleaned
up, unless the application is reasonably well written. In case of
issues like usage of the bean instrospector as mentioned above, some
explicit cleanup is required (now done automatically by Tomcat, but
this will only be in the next release). See the bug report for info on
workarounds.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Is there any option for .rar files on Tomcat 5.5.7

[Remy Maucherat]

On Thu, 03 Feb 2005 18:04:00 -0500, Edmon Begoli <[EMAIL PROTECTED]> wrote:
> I understand that Tomcat is not a full J2EE app. server, but I would
> like to know if there
> are any options to deploy .rar JCA adapters on Tomcat 5.5.7?

No, Tomcat doesn't support JCA, sorry.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: SocketException: Too many open files

[Remy Maucherat]

On Tue, 01 Feb 2005 17:29:51 -0600, Stephen Charles Huey
<[EMAIL PROTECTED]> wrote:
> I'm running some simple but fast-pounding test programs against our
> Tomcat server from a machine on the same network, and we've been tuning
> our database, etc, based on this.  But right now, I'm seeing a new one
> coming out of our Java code whenever we try to open a URL:
> 
> java.net.SocketException: Too many open files

If you're on Linux, use ulimit -a to see what the limits are, and
ulimit -n to change the value. However, only root is allowed to get
more than 1024 files (does somebody knows why ?).


-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: article draft - Summary of benchmark

[Remy Maucherat]

On Tue, 1 Feb 2005 15:18:59 -0500, Peter Lin <[EMAIL PROTECTED]> wrote:
> I've updated the document with more charts from the excel spreadsheet
> and tried to make the explanations more clear.

I'm really interested in the part of your tests which show certain new
CPU architectures showing a big improvement in Java. I suppose it
benefits a lot from large caches (Pentium M, Opteron), and I suppose
more regirsters won't hurt either (x86-64).

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Tomcat'evolution abstract

[Remy Maucherat]

On Sat, 29 Jan 2005 19:02:25 +0100, Philippe Mathieu
<[EMAIL PROTECTED]> wrote:
> Hi,
> I'm a little bit lost in the releases;
> Does anyone could tell me precisely since which release ... :
> 
> - Tomcat takes account of JSP 2.0 ?

5.0+

> - Realms are integrated in Tomcat ?

4.0+ (with API changes)

> - DBCP (pools) are integrated in Tomcat ?

4.1+

> - the invoker servlet in not set by default ? (4.1.12 ?)

Yes.

> - The DataSourceRealm is integrated in Tomcat ?

4.1.something

> - Context description can be put directly in catalina/localhost ?

5.0.0+

> - DBCP syntax has been changed ? (5.5.4 ?)

5.5.0+

> - loggers have disappeared ? (5.5.4 ?)

5.5.0+

> - JDK 1.5 compliant ? (5.5.4 ?)

5.5.0+

- Removal of DefaultContext (replaced by conf/context.xml and other
per host files)

5.5.0+

- JDT as the JSP code compiler

5.5.0+ (but it had very serious bugs in that build ;) )

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: ThreadPool logFull ERROR

[Remy Maucherat]

On Fri, 28 Jan 2005 16:14:10 +0800, fan lianjie <[EMAIL PROTECTED]> wrote:
> i USE tomcat 5.54.
> 
> 2005-1-28 15:59:42 org.apache.tomcat.util.threads.ThreadPool logFull
> äé: All threads (200) are currently busy, waiting. Increase maxThreads
> (200) or check the servlet status

Did you try out what it says ? If you're using the HTTP connector, you
could also try to set strategy="ms" on the Connector element to see if
it helps (I've been looking for people experiencing problems with the
default thread pool to try out the alternate one).

If you think you shouldn't be getting this because your website is low
traffic, could you give more details ?

-- 
x
RÃmy Maucherat
Developer & Consultant
JBoss Group (Europe) SÃRL
x

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

Re: [ANN] Apache Jakarta Tomcat 5.5.7-alpha Released

[Remy Maucherat]

On Fri, 21 Jan 2005 11:15:37 +0100, Lionel Farbos <[EMAIL PROTECTED]> wrote:
> On Thu, 20 Jan 2005 19:05:52 +
> Mark Thomas <[EMAIL PROTECTED]> wrote:
> 
> > Lionel Farbos wrote:
> > > Question :
> > > What is the reference or stable version for servlet 2.4 ?
> > > Is it Tomcat 5.0.28 or Tomcat 5.5.4 ?
> > >
> > > I don't understand why you implement 2 versions (2 branches) for this 
> > > servlet API ...?
> >
> > http://jakarta.apache.org/tomcat/index.html has answers to these
> > questions and more.
> 
> If I post theses questions, it's because theses answers are not clear for 
> me...
> So, I re-post my question differently :
> 
> For production purposes, I want the most stable Tomcat Version (Servlet API 
> 2.3 or 2.4); so, what version should I use ? TC4.1.31, TC5.0.28 or TC5.5.4 ?
> 
> In my memories, TC5.0.x was not usable before 5.0.19 but she was announced 
> stable...
> So I prefer requiring Tomcat developers' point of view.

5.5.4 is quite stable. The place where it had issues is the webapp hot
deployer, which was rewritten (the 5.0.x deployer didn't do hot
deployment very well overall, so I suppose you're losing something,
but not much). I think the problems have now been addressed in the
latest 5.5.7 build (which hasn't been rated stable yet). Virtually all
the other issues were bugs affecting 5.0.x as well, and those weren't
all backported yet.

You can see the changelog here:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/changelog.html

If you're deploying on a new server, I recommend starting your process
using the latest stable branch. If you're updating, and since there's
likely a new stable build coming soon, you could wait for it.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Exploded WAR deployment in Tomcat 5.5

[Remy Maucherat]

On Fri, 21 Jan 2005 10:45:35 +0100, Wouter Boers <[EMAIL PROTECTED]> wrote:
> Hello,
> 
> I have found some strange behaviour in de Tomcat manager. When adding
> an exploded WAR directory, for example file:///c:/java/foo with
> context foo, Tomcat 5.5 starts to copy the *complete* C drive to
> TOMCAT_HOME/conf/Catalina directory. Tomcat 5.0 does not suffer from
> this problem. Is this an known issue? I haven't found it in the bug
> list or mail archive.

This (really stupid) bug has been fixed in build 5.5.6+. The cause is
that a check is missing for the case the path for the config XML file
is empty.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: bug in tomcat 5.5 and sticky sessions because of problem with jvmRoute parameter?

[Remy Maucherat]

On Thu, 20 Jan 2005 13:15:58 +0100, Christian Schuhegger
<[EMAIL PROTECTED]> wrote:
> hello,
> 
> i've just tried to set-up tomcat 5.5 with apache2 and mod_jk version
> 1.2.8 in a load balancing set-up with sticky sessions.
> 
> when i give as jvmRoute parameter the string tc1 my sessionids look like:
> BF20EF21CC52EA0659B1E079015D7B56.tc1.tc1
> and i see in the mod_jk.log file that no worker with the name "tc1.tc1"
> could be found!
> 
> i've circumvented the problem currently by "doubling" the name in the
> workers.properties file as follows:
> -- snip start --
> worker.list=load
> 
> worker.load.type=lb
> worker.load.balance_workers=tc1.tc1,tc2.tc2
> worker.load.sticky_session=True
> 
> worker.tc1.tc1.port=12013
> worker.tc1.tc1.host=localhost
> worker.tc1.tc1.type=ajp13
> 
> worker.tc2.tc2.port=12013
> worker.tc2.tc2.host=remote
> worker.tc2.tc2.type=ajp13
> -- snip end --
> 
> was this problem already noticed? did i do something wrong? or should i
> file a bug report?

- Added jvmRoute="tc1" on Engine
- Accessed http://127.0.0.1:8080/servlets-examples/servlet/SessionExample
- Session ID displayed is 8DBBCECBCAD078E18C07401A076734B0.tc1

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

[ANN] Apache Jakarta Tomcat 5.5.7-alpha Released

[Remy Maucherat]

The Apache Jakarta Tomcat team is proud to announce the immediate 
availability of Tomcat 5.5.7-alpha. This build contains numerous bug 
fixes, documentation updates, and other improvements.

Release notes: 
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/RELEASE-NOTES

Please refer to the change log for the list of changes:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/changelog.html
Downloads: Binaries: http://jakarta.apache.org/site/binindex.cgi#tomcat-5.5
Sources: http://jakarta.apache.org/site/sourceindex.cgi#tomcat-5.5
The Apache Jakarta Tomcat Team
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Expect: 100-continue

[Remy Maucherat]

On Wed, 19 Jan 2005 13:54:36 +0100, Julian Reschke
<[EMAIL PROTECTED]> wrote:
> Remy Maucherat wrote on tomcat-dev:
>  > Tomcat always automatically sends a 100-continue when going into the
>  > filter pipeline if an expectation is requested.
>  >
>  > This should be on tomcat-user, BTW.
> 
> So are there any plans to improve this, for instance by implementing
> options 2b&c?

It's more complex, and the benefits are not that huge, so I'm not very
motivated for doing it ;)

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Running lots of virtual hosts on tomcat

[Remy Maucherat]

On Wed, 19 Jan 2005 15:37:30 +0100, Robbert-Jan Roos <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> Our web department is thinking about moving from coldfusion to tomcat.
> Currently we have about 400 websites using apache's mod_vhost module.
> This works great. The only thing one needs to do is create a new
> directory www.bla.nl and the website is up and running.
> 
> How would one do this in tomcat? I figured putting all the domainnames
> in server.xml is not an option since it would require restarting
> tomcat all the time. Using one Engine with a Context for each website
> seems more usable.
> 
> Does anybody here have this kind of setup? Any pitfalls we might run
> into? Suggestions?

Dynamic aadd/remove of hosts isn't supported through any tool at the
moment (= you have to build some kind of front end webapp and use the
Tomcat API to do it). I plan to add this in a future Tomcat 5.5 build.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

[OT] Tomcat training in Paris

[Remy Maucherat]

Hi,

Sorry for the ad, but maybe it could be of interest to some people here.

I'm doing a 2 day training on Tomcat in Paris in february. The
training is on advanced topics and covers mostly Tomcat 5.5. Details
are available here:
http://www.jboss.com/services/training/EMEAcourses#paris-tom

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: performance/scalability impact of many webapps in one container

[Remy Maucherat]

On Tue, 18 Jan 2005 13:12:06 -, Varley, Roger
<[EMAIL PROTECTED]> wrote:
> >
> > For reasons beyond my control, a web application
> > (apache/Tomcat/PostgreSQL) that I support will need to be partitioned
> > into one context per customer (to support one database per customer).
> > I'm wondering:
> >
> 
> Do you really need one database per customer? In a similair situation, we 
> resolved this by adding a "client code" to all our database tables & indexes. 
> Each customer/client was given their own URL to access the system and a 
> filter used the incoming url to load a client code into the request headers 
> before passing the request to a single servlet.
> 

Obviously, it all depends on the isolation level you want. For
example, you can restrict what web applications can do in a
multi-"user" environment by using the security manager.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: performance/scalability impact of many webapps in one container

[Remy Maucherat]

On Mon, 17 Jan 2005 15:02:28 -0700, Joel McGraw <[EMAIL PROTECTED]> wrote:
> For reasons beyond my control, a web application
> (apache/Tomcat/PostgreSQL) that I support will need to be partitioned
> into one context per customer (to support one database per customer).
> I'm wondering:
> 
> 1. What the performance implications are (if any) of having up to 300
> contexts in one container?

With Tomcat 5.x, it's ok, it will just use more memory. With 4.x, it's
bad (one background thread per context = 300 background threads).

> 2. Are there any scalability issues of which I should be aware?

- You might have tons of sessions, so increase the VM's memory
- And the usual: one application doing bad things could take the whole
server down, which will be a lot more noticeable for users

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: latest set of Benchmark results

[Remy Maucherat]

On Sun, 16 Jan 2005 13:15:01 -0500, Peter Lin <[EMAIL PROTECTED]> wrote:
> Here is the latest set of benchmark results. I discovered an error in
> my test plan for 40K PNG, so the results for that one was off. All of
> the other results should be accurate. I re-ran the tests.
> 
> Server:
> AMD 2ghz
> 1Gb RAM
> Redhat FedoraCore1
> 
> Client:
> Gateway laptop 450
> 1.4ghz centrino
> Windows XP pro
> jdk1.4.2
> jmeter nightly build
> 
> 16 port Switch Linksys 10/100
> CAT5 cables
> 
> All threads ran for 1000 iterations.
> thread scenario: 5, 10, 15, 20, 25, 30
> image/html size: 1, 10, 20, 40, 80, 160
> 
> The test includes 5.0.19 (aka 5.0), 5.5.4, apache 2.0.50, apache
> 1.3.3.  I hope people find it interesting and useful. It will take me
> a week or two to write up the results and generate the graphs.

Does the "-server" option do anything other than use more memory ? ;)

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: more benchmark results

[Remy Maucherat]

On Fri, 14 Jan 2005 08:11:11 -0500, Peter Lin <[EMAIL PROTECTED]> wrote:
> Per Remy's request, I ran some more tests last night with larger
> number of threads. the configuration of the test plan is as follows
> 
> 1K png: 10, 50, 100, 150 threads
> 10K png: 10, 50, 100, 150 threads
> 
> each thread as was to 1000 iterations.
> ramp up times: 1, 5, 10, 20 seconds
> 
> Server:
> Redhat fedora Core1
> AMD 2ghz
> 1Gb RAM
> tomcat 5.0.19
> Sun jdk1.4.2_03
> 
> Client:
> gateway 450 laptop
> 1.4ghz centrino
> 1Gb RAM
> jmeter nightly build
> sun jdk1.4.2
> 
> I plan to re-run these tests with the latest 5.0.x release this
> weekend and per Remy's request I will also test 5.5.4 with jdk5 for
> comparison.

And no FC 3 ? ;) I think it would run fine on your computer, and it's
a higher quality distribution overall (it doesn't have the stupid NPTL
backport that FC 1 has). Or you could try Ubuntu (I plan to switch to
that distro when they release hoary).

Anyway, I'd be interested if you tried stressing a little the thread
pool I added in 5.5 (strategy="ms" threadPriority="7" on the Connector
element) to see if it gives a difference in the error rate (and also
if it's not completely broken). You may want to increase maxThreads as
well for your tests (it's 150 by default, which is dangerously close
of the concurrency used by your client)

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: some TC5 benchmark results for static file

[Remy Maucherat]

On Thu, 13 Jan 2005 10:16:08 -0500, Peter Lin <[EMAIL PROTECTED]> wrote:
> I've started a series of benchmarks to measure tomcat5 performance for
> static files and compare it to apache2. Here are the results I have so
> far. I thought others might find it interesting.
> 
> Server:
> Redhat Fedora Core 1
> AMD 2hgz
> 1Gb ram
> jdk1.4.2
> TC5.0.x ( have to double check the release number)

I would like a quick comparison with the new stuff, and tests with
higher concurrency (if possible):
FC 3 + JRE 5 + Tomcat 5.5.7

Especially if you plan to write an an article, I'd be glad if you used
the best available platform :)

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Tomcat arbitrarily freezes

[Remy Maucherat]

On Tue, 11 Jan 2005 13:51:13 +0100, Oliver Schoenwald
<[EMAIL PROTECTED]> wrote:
> Hi!
> 
> five days after my first question and no answer in sight. To bad.
> So far, we have switched from JDK 1.4.2 to JDK 1.5 and from Tomcat
> 5.0.27 to 5.5.4 and the problem persists.
> However, while under JDK 1.4.2 it was always the thread with id #2 under
> JDK 1.5
> it is still the thread "VM Thread", but now under id #4.
> 
> Using the better debugging features of JDK 1.5 (jstack, jmap) we could
> pin down the problem in more detail:
> whenever the problem starts, the output of jstack and jmap shows that
> these debugging-tools have
> more and more problems to give information about certain memory areas.
> When the problem reaches its
> climax, a bug number of memory areas are marked by jstack with an "Error
> occurred during stack walking:"-Message
> or by jmap with "UnmappedAddressException".
> 
> You see, at the moment we are only guessing what problem we have here.
> 
> Maybe someone has an idea how to analyze the problem more properly or
> even know how to solve it (without changing some of the components like
> using another servlet container engine or another JVM).

If you don't get any answers, it is that people don't have any ideas
and / or nothing useful to say.

For example, this is the first time I hear about a problem with this
internal VM thread. While other "Tomcat arbitrarily freezes" issues
are well known on some OSes, this one is brand new to me. You seem to
assert that this is a common problem encountered by many people, and
you also seem certain that your problems come for that (which means
bad luck, as this is an internal VM thread). Can you give links giving
more details about this ?

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Errors Starting Up Tomcat 5.5

[Remy Maucherat]

On Mon, 10 Jan 2005 16:51:13 -0800, Ryan Austin <[EMAIL PROTECTED]> wrote:
> I just read that you need jre 1.5 or later and I was using
> j2sdk1.4.2_06. Could this be the cause of the errors I am seeing?
> 
> I will update it and give it a try.

You can still use 1.4, if you use the "compat" package which adds a
few JARs. Usually, you notice something is wrong because Tomcat
doesn't start, and displays an error about JMX missing. I suppose you
have JMX somewhere on your classpath already.

I suppose the XML parser in JDK 1.4 will have issues with schemas, so
any 2.4 style web.xml would create problems.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: TC Drops bytes when client uses Chunked Encoding AND specifying Content-Length at the same time.

[Remy Maucherat]

On Thu, 30 Dec 2004 17:58:09 -0800, Ian Huynh <[EMAIL PROTECTED]> wrote:
> We are using TC 5.0.28 on JDK 1.4.2
> 
> We have a client who POST to TC using  header "Transfer-encoding: chunked"  
> and at the same time specify the "Content-Length" header
> when posting to us.
> 
> It seems that if the Content-Length is specified, TC is dropping the last few 
> bytes..??
> This same customer claims that his code works with the Jetty Servlet (which 
> is the old embedded servlet in JBoss 3.2.1 and earlier).
> We have done some prelim testing and confirmed that
> 
> a) if Content-Length is NOT specified and Chunked encoding is used, TC works 
> as specified.
> b) Jetty works either way (with or without Content-Length).
> 
> My questions are:
> 
> 1. what is the correct behavior in HTTP 1.1?  I've read through the spec but 
> am unable to ascertain whether or not Content-Lenght should NOT be
>used when chunked encoding is used.
> 
> 2. Is this a bug in TC?
> 
> Unfortunately, our client isn't able to modify the code to NOT include the 
> Content-Length or NOT use Chunk encoding

This should be fixed in CVS, but your HTTP client is completely
broken. I'm sure it won't be the last problem you'll have with it.
You're lucky that this case is to be explicitely supported ...

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Authentication isn't working with mod_jk 1.7.3 beta.

[Remy Maucherat]

On Fri, 17 Dec 2004 10:55:27 -0500, Jim Lynch <[EMAIL PROTECTED]> wrote:
> The request is making a single entry into the log.
> 
> 198.149.32.31 - - [17/Dec/2004:09:46:27 -0600] "GET /resources/input
> HTTP/1.0" 401 667
> 
> If I go to port 8080 and get validated, then it works without the port 8080.

It's normal that you get a 401 back. Then your browser should display
the auth popup.
Use a telnet to see the reply sent by Tomcat on both ports. Especially
pay attention to the presence of a WWW-Authenticate header. The rest
(except the 401 status code) is almost irrelevant.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Tomcat 5.5.4 Ant Task

[Remy Maucherat]

On Tue, 14 Dec 2004 01:13:04 +0100, Siarhei Dudzin
<[EMAIL PROTECTED]> wrote:
> Yes, antiJARLocking and antiResourceLocking are not enabled by default.
> Unfortunately, non of them (together and separately) did not help to
> solve my problems...

Try harder, it works. Read the FAQ, and verify that they are actually
enabled. If antiResourceLocking is enabled, you should notice it, as
you'll get a cool extended coffee break while Tomcat starts, but you
cannot possibly get any locking (unless you do really crazy stuff,
like accessing files directly yourself using harcoded file paths).

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Tomcat 5.5.4 Ant Task

[Remy Maucherat]

On Mon, 13 Dec 2004 11:34:08 -0600, Gregg <[EMAIL PROTECTED]> wrote:
> I recently migrated from Tomcat 5.0.x to 5.5.4.  Everything seems to
> work great except the Ant Tasks.  Deploy works just fine but when I do
> the undeploy task the folder that contains my webapp does not get
> removed.  So when I go to deploy again, it says it can't because the
> context already exists.  With 5.0.x the context was removed completely.
> Does anyone know if this is a bug or if the behavior of the ant tasks
> have changed?  I couldn't find anything specifically about this in the
> changelog.

There's a FAQ entry on this:
http://jakarta.apache.org/tomcat/faq/windows.html#lock

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: Does TC 5.5 have some type of farm deployer?

[Remy Maucherat]

On Mon, 13 Dec 2004 11:09:43 -0500, Shapira, Yoav <[EMAIL PROTECTED]> wrote:
> 
> Hi,
> This proposal is from Peter Rossbach, who's since become a Tomcat
> committer.  I don't think the proposal was ever formally raised and
> discussed: this is the first time I've seen it.  So it's certainly not
> been implemented, and highly unlikely to be in a Tomcat release any time
> soon, but if he's still working on it then it might eventually make it
> into Tomcat.

Peter has added back farm deployment in 5.5.5. It's quite different
from the farm deployer in 5.0.x, so probably we can assume it replaces
whatever the proposal was.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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