Struts 1.1, Tomcat and Eclipse - A problem working all together

[Tal Yaari]

Hey,

I hope i've reached the right forum, if not, please let me know...

 

I am using Eclispe 3.2.2 and Tomcat 5.0.28.

In addition I am using Struts 1.1.

 

I have a project in Eclipse, which I want to run on Tomcat using Tomcat
plugin (com.sysdeo.eclipse.tomcat_3.0.0.alpha1). I set the project as a
Tomcat project and run the Tomcat.

I am trying to access my web application and then i get the following
errors:

69234 [http-8090-Processor25] ERROR org.apache.jasper.compiler.Compiler
- Javac exception 

Compile failed; see the compiler error output for details.

at
org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:944)

at
org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:764)

at
org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:382)

at
org.apache.jasper.compiler.Compiler.compile(Compiler.java:472).

 

and it continues:

:\ccm_wa\TICP-core-yaari_3.0.0\TICP\ui.occ\work\org\apache\jsp\Login_jsp
.java:8: org.apache.jsp.Login_jsp is not abstract and does not override
abstract method getIncludes() in org.apache.jasper.runtime.HttpJspBase

public final class Login_jsp extends
org.apache.jasper.runtime.HttpJspBase

 ^

C:\ccm_wa\TICP-core-yaari_3.0.0\TICP\ui.occ\work\org\apache\jsp\Login_js
p.java:35: cannot resolve symbol

symbol  : method getTagHandlerPool (javax.servlet.ServletConfig)

location: class org.apache.jasper.runtime.TagHandlerPool

_jspx_tagPool_uif_out_key_nobody =
org.apache.jasper.runtime.TagHandlerPool.getTagHandlerPool(getServletCon
fig());

 

and, of course, it continues:

C:\ccm_wa\TICP-core-yaari_3.0.0\TICP\ui.occ\work\org\apache\jsp\Login_js
p.java:170:
_jspx_meth_uif_out_1(javax.servlet.jsp.tagext.JspTag,javax.servlet.jsp.P
ageContext) in org.apache.jsp.Login_jsp cannot be applied to
(trivnet.common.uif.taglib.form.FormTag,javax.servlet.jsp.PageContext)

  if (_jspx_meth_uif_out_1(_jspx_th_uif_form_0,
_jspx_page_context))

  ^

C:\ccm_wa\TICP-core-yaari_3.0.0\TICP\ui.occ\work\org\apache\jsp\Login_js
p.java:188:
_jspx_meth_uif_info_0(javax.servlet.jsp.tagext.JspTag,javax.servlet.jsp.
PageContext) in org.apache.jsp.Login_jsp cannot be applied to
(trivnet.common.uif.taglib.form.FormTag,javax.servlet.jsp.PageContext)

  if (_jspx_meth_uif_info_0(_jspx_th_uif_form_0,
_jspx_page_context))

 

 

I think that part of the problem is that Tomcat 5.x is using a newer
Jasper and when it compiles my JSPs, it "expects" to "deal" with JSP 2.0
specification, while the struts which I am using doesn't support it.

Struts 1.1 tags extends: javax.servlet.jsp.tagext.Tag while the generate
Servlet (as a result of my JSP) expects to get
javax.servlet.jsp.tagext.JSPTag.

I didn't find how to set Tomcat to build the JSPs in the old
specification.

 

Maybe there are other problems (please refer the exceptions above) which
I didn't see.

 

is there a way I can solve this issue?

thanks in advance,

Tal.

Thawte SSL certificates

[Lyallex]

Hi

I was wondering if anyone has managed to get the Thawte SSL test
certificate working with Tomcat 5.5.

I have created a CSR and submitted it to Thawte. I got a test certificate back

I have installed the Thawte Root(chain) certificate and tried to
install the test certificate I got a CertificateParsingException:
invalid DER encoded certificate data.

I think this might have something to do with different encoding
schemes I think the certificate I got was PEM encoded not DER encoded
(guess work here)

I got hold of openssl and issued the following

openssl x509 -in my_downloaded_cert.txt -out my_downloaded_cert.der
and got he following error

unable to load certificate
1360:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:632:Expect
ing: TRUSTED CERTIFICATE

I'm sort of lost here really, has anyone got this working ?

Thanks
Duncan

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Problem with Apache/Tomcat/WebDAV/Alfresco

[Frank Gerlach]

Hello folks,
we have a problem with the following setup:

Web Browser ->Apache(mod_jk)->Tomcat->Alfresco

Explanation: we would like to access the Alfresco content management system 
(running in Tomcat) using WebDAV and SSL.
It works, if we expose Tomcat directly to the network. For security 
reasons, we would like to "reverse proxy" with Apache. This does not work for 
some reason. (does not send the WWW-Authenticate header)
We have checked mod_jk documentation without detecting any 
problems on our side. 
Can anybody help ?

Thanks in advance !

regards

Frank


Here are the relevant config settings and software version info:

Apache: Server version: Apache/2.0.59

Tomcat: Apache Tomcat/5.5.20 
  jdk 1.5.0_07-b03 Sun Microsystems Inc. 
  Linux 2.6.5-7.252-default i386


mod_jk in Apache:

JkMount /* alfresco
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel debug
JkWorkersFile "/usr/share/tomcat/conf/workers.properties"

+++

/usr/share/tomcat/conf/workers.properties:

ps=/

# list the workers by name
worker.list=alfresco

# 
# First tomcat server
# 
worker.alfresco.port=8009
worker.alfresco.host=localhost
worker.alfresco.type=ajp13

# Specify the size of the open connection cache.
#worker.tomcat-worker1.cachesize

#
# Specifies the load balance factor when used with
# a load balancing worker.
# Note:
#  > lbfactor must be > 0
#  > Low lbfactor means less work done by the worker.
worker.alfresco.lbfactor=100

++

tomcat server.xml:






Frank Gerlach
Software engineer

dmc digital media center GmbH
Rommelstraße 11
70376 Stuttgart (Germany)
Telefon: +49 711 601747-258
Telefax: +49 711 601747-141
eMail:[EMAIL PROTECTED]
Internet: www.dmc.de

Handelsregister: AG Stuttgart HRB 18974
Geschäftsführer: Andreas Magg, Daniel Rebhorn, Andreas Schwend

 <> 
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: RHEL and Tomcat startup/shutdown scripts

[Andrew R Feller]

Thanks for the reply Ben!

Unfortunately due to needing Java 1.5+ (current distro gcj is Java 1.4.2
equivalent) for CAS (http://www.ja-sig.org/products/cas/) and Tomcat 6
(unicast member discovery via static members), I am unable to reply upon
Redhat's Tomcat 5.5 package.  As such, I have to use the precompiled
binaries of Sun's Java 1.6 and Apache's Tomcat 6.0.

I have no problems compiling and using the jsvc daemon for Tomcat.  I'm
just at a loss about whether that is the right route or not.

Thanks,

Andrew R Feller, Analyst
Subversion Administrator
University Information Systems
Louisiana State University
[EMAIL PROTECTED]
(office) 225.578.3737
-Original Message-
From: Ben Stringer [mailto:[EMAIL PROTECTED] 
Sent: Saturday, August 11, 2007 9:36 AM
To: Tomcat Users List
Subject: Re: RHEL and Tomcat startup/shutdown scripts

On Wed, 2007-08-08 at 15:17 -0500, Andrew R Feller wrote:
> Hello everyone,
> 
>  
> 
> Over the past couple of months, I have been working with some Tomcat
> instances on RHEL 5 and wondered: what is the recommended method to
> startup/shutdown Tomcat?  After reading the Tomcat documentation, they
> talk about compiling the jsvc source under the bin directory and using
> that.

Hi Andrew,

Redhat package tomcat 5.5 as an RPM (or JPackage package it and Redhat
distribute it).

This RPM comes with well written init scripts, creates a tomcat user
etc. I would recommend you use this.

# yum install tomcat5 

Cheers, Ben

> 
>  
> 
> Thanks,
> 
>  
> 
> Andrew R Feller, Analyst
> 
> Subversion Administrator
> 
> University Information Systems
> 
> Louisiana State University
> 
> [EMAIL PROTECTED]
> 
> (office) 225.578.3737
> 
>  
> 


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Problem with Apache/Tomcat/WebDAV/Alfresco

[Rainer Jung]

Hello Frank,

there has been a mod_jk release published for very few days, namely 
1.2.24, which was broken w.r.t. WWW-Authenticate. Although it's not very 
likely, that you use this one, it's my first question.


If you really use 1.2.24, switch to 1.2.25 and the problem should be gone.

Otherwise: what's your version?
If you can easily reproduce the behaviour, how does the jk log file for 
log level debug look like?


Regards,

Rainer
--
kippdata
informationstechnologie GmbH   Tel: 0228 98549 -0
Bornheimer Str. 33aFax: 0228 98549 -50
53111 Bonn www.kippdata.de

HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417
Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann

Frank Gerlach wrote:

Hello folks,
we have a problem with the following setup:

Web Browser ->Apache(mod_jk)->Tomcat->Alfresco

Explanation: we would like to access the Alfresco content management system 
(running in Tomcat) using WebDAV and SSL.
It works, if we expose Tomcat directly to the network. For security 
reasons, we would like to "reverse proxy" with Apache. This does not work for 
some reason. (does not send the WWW-Authenticate header)
We have checked mod_jk documentation without detecting any 
problems on our side. 
Can anybody help ?


Thanks in advance !

regards

Frank


Here are the relevant config settings and software version info:

Apache: Server version: Apache/2.0.59

Tomcat: Apache Tomcat/5.5.20 
  jdk 1.5.0_07-b03 Sun Microsystems Inc. 
  Linux 2.6.5-7.252-default i386



mod_jk in Apache:

JkMount /* alfresco
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel debug
JkWorkersFile "/usr/share/tomcat/conf/workers.properties"

+++

/usr/share/tomcat/conf/workers.properties:

ps=/

# list the workers by name
worker.list=alfresco

# 
# First tomcat server
# 
worker.alfresco.port=8009
worker.alfresco.host=localhost
worker.alfresco.type=ajp13

# Specify the size of the open connection cache.
#worker.tomcat-worker1.cachesize

#
# Specifies the load balance factor when used with
# a load balancing worker.
# Note:
#  > lbfactor must be > 0
#  > Low lbfactor means less work done by the worker.
worker.alfresco.lbfactor=100

++

tomcat server.xml:






Frank Gerlach
Software engineer

dmc digital media center GmbH
Rommelstraße 11
70376 Stuttgart (Germany)
Telefon: +49 711 601747-258
Telefax: +49 711 601747-141
eMail:[EMAIL PROTECTED]
Internet: www.dmc.de

Handelsregister: AG Stuttgart HRB 18974
Geschäftsführer: Andreas Magg, Daniel Rebhorn, Andreas Schwend

 <> 


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

How to run JSF 1.2 with tomcat 5.5.9

[Peter Neu]

Hello,

has anyone managed to get JSF 1.2 to run on tomcat 5.5.9? It seems that I
can't find the right libraries to make it happen. I can't find
com.sun.el.ExpressionFactoryImpl for instance. 

Normally I would just upgrade to tomcat 6 but I can't just switch the
production server.

Cheers,
Pete 




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Thawte SSL certificates

[Hassan Schroeder]

On 8/13/07, Lyallex <[EMAIL PROTECTED]> wrote:

> I was wondering if anyone has managed to get the Thawte SSL test
> certificate working with Tomcat 5.5.
>
> I have created a CSR and submitted it to Thawte. I got a test certificate back

? I'm not sure what "test" certificate you're referring to, but I have a
Thawte cert on a client site, and the installation was by-the-book --
); did
you follow that exactly?

-- 
Hassan Schroeder  [EMAIL PROTECTED]

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Thawte SSL certificates

[Vamsavardhana Reddy]

Can you send me the certificate(s) you received from the Thawte CA?  May be
I can help.  You should be comfortable sending it as there is nothing secret
about Certificates.  It is only your private-key that should not be
transmitted.

Vamsi


On 8/13/07, Lyallex <[EMAIL PROTECTED]> wrote:
>
> Hi
>
> I was wondering if anyone has managed to get the Thawte SSL test
> certificate working with Tomcat 5.5.
>
> I have created a CSR and submitted it to Thawte. I got a test certificate
> back
>
> I have installed the Thawte Root(chain) certificate and tried to
> install the test certificate I got a CertificateParsingException:
> invalid DER encoded certificate data.
>
> I think this might have something to do with different encoding
> schemes I think the certificate I got was PEM encoded not DER encoded
> (guess work here)
>
> I got hold of openssl and issued the following
>
> openssl x509 -in my_downloaded_cert.txt -out my_downloaded_cert.der
> and got he following error
>
> unable to load certificate
> 1360:error:0906D06C:PEM routines:PEM_read_bio:no start
> line:pem_lib.c:632:Expect
> ing: TRUSTED CERTIFICATE
>
> I'm sort of lost here really, has anyone got this working ?
>
> Thanks
> Duncan
>
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

V 4.01 for solaris x86

[Tim.OShea]

Is it possible to get hold of binaries for Tomcat 4.0 (> 4.04) for
Solaris x86?

I need this for a fairly urgent installation, and am aware that there
are incompatibilities with third party applets we are using and Tomcat
versions older than this.

 

Thanks.

 

Tim O'Shea
Technical Manager - Managed Services 

TietoEnator

Banking & Insurance (UK)
Direct +44 1582 845111
Mobile +44 7810 374235
Fax +44 1582 866927
E-mail [EMAIL PROTECTED]  

Gainsborough House, Houghton Hall Park,
Houghton Regis, Beds. LU5 5XF
United Kingdom 

www.tietoenator.co.uk 

TietoEnator (UK No.1) Limited is a limited company registered in England
& Wales.  Registered number 1454835.  Registered office: Gainsborough
House, Houghton Hall Park, Houghton Regis, Beds.  LU5 5XF.

 

Please note: The information contained in this message may be legally
privileged and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, you are hereby notified
that any unauthorised use, distribution or copying of this communication
is strictly prohibited. If you have received this communication in
error, please notify us immediately by replying to the message and
deleting it from your computer. Thank You

 

RE: V 4.01 for solaris x86

[Caldarale, Charles R]

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Subject: V 4.01 for solaris x86
> 
> Is it possible to get hold of binaries for Tomcat 4.0 (> 4.04) for
> Solaris x86?

Tomcat is pure Java, so there are no platform-specific binaries.  Look
here for the 4.0 versions:
http://archive.apache.org/dist/tomcat/tomcat-4/archive/

Make sure you have the necessary Solaris patches for the JVM you're
using.

Why don't you move up to something a more recent?  The levels you're
asking about are over five years old.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: V 4.01 for solaris x86

[Tim.OShea]

Thanks,
There is a binary download for sparc here, but not x86.


Tim O'Shea
Technical Manager - Managed Services 

TietoEnator

Banking & Insurance (UK)
Direct +44 1582 845111
Mobile +44 7810 374235
Fax +44 1582 866927
E-mail [EMAIL PROTECTED]

Gainsborough House, Houghton Hall Park,
Houghton Regis, Beds. LU5 5XF
United Kingdom 

www.tietoenator.co.uk 

TietoEnator (UK No.1) Limited is a limited company registered in England
& Wales.  Registered number 1454835.  Registered office: Gainsborough
House, Houghton Hall Park, Houghton Regis, Beds.  LU5 5XF.

Please note: The information contained in this message may be legally
privileged and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, you are hereby notified
that any unauthorised use, distribution or copying of this communication
is strictly prohibited. If you have received this communication in
error, please notify us immediately by replying to the message and
deleting it from your computer. Thank You


-Original Message-
From: Hassan Schroeder [mailto:[EMAIL PROTECTED] 
Sent: 13 August 2007 15:53
To: Tomcat Users List
Subject: Re: V 4.01 for solaris x86

On 8/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Is it possible to get hold of binaries for Tomcat 4.0 (> 4.04)

archives: 

HTH,
-- 
Hassan Schroeder  [EMAIL PROTECTED]

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: V 4.01 for solaris x86

[Hassan Schroeder]

On 8/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Is it possible to get hold of binaries for Tomcat 4.0 (> 4.04)

archives: 

HTH,
-- 
Hassan Schroeder  [EMAIL PROTECTED]

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

How to apply filter to 404's in servlet 2.3?

[jwboring]

I would like to have a filter invoked when ever a request comes in that does
not represent a valid page/url (404's). What we are doing now is mapping the
error-code to a jsp page that redirects via 
(see code below) but of course that is another round trip and therefore not
optimal.


Code:


  routerRedirectInputFilter
  /unknown.req


.


404
/rr.jsp


I have tried replacing the c:redirect with a jsp:forward but this does not
invoke the filter. I suspect this is not possible with v2.3 but might be
with v2.4. 

Thoughts?
__
Jeff Boring
-- 
View this message in context: 
http://www.nabble.com/How-to-apply-filter-to-404%27s-in-servlet-2.3--tf4261634.html#a12127511
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat and path with pound sign (#) -> ClassNotFoundException

[Len Popp]

There are a few problems caused by "#" in directory names, and it
looks to me like they're at least partly Tomcat's fault.

1. The classloader problem that you reported: Tomcat converts file
pathnames to URLs for URLClassLoader, using File.toURL which handles
"#" poorly. This could be Sun's fault, but following a note in their
docs here:
http://java.sun.com/j2se/1.5.0/docs/api/java/io/File.html#toURL()
I was able to fix this problem in Tomcat by calling File.toURI and
then URI.toURL. (That's the workaround I referred to before.)

2. After fixing problem 1, I found that JSPs don't work because Jasper
screws up the pathname of its output directory. There's some code in
JspCompilationContext that concatenates directories using both URL and
file syntax, truncating it at the "#" and using both "\" and "/"
directory separators (in Windows). It looks screwy to me, I don't see
why it should be using URLs to concatenate file pathnames.

3, etc. There are several other places in Tomcat where File.toURL is
used and I think it could have problems with "#" in pathnames, but I
don't know what the effects are.

So it's pretty clear to me that Tomcat could handle pathnames with "#"
chars better. Is it worth the trouble to find and fix all the related
problems, or is it simpler to tell people not to use unusual directory
names? I could help fix some of the problems, but there are some that
I haven't figured out.
-- 
Len

On 8/12/07, Markus Schiegl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Len Popp wrote:
> > I'm not sure the topic is ready to be nailed shut just yet...
> >
> Oh, i have no objections keeping it alive. Unfortunately my java skills
> are limited so reporting and testing is the best i can do to help.
>
> > The problem is due to the way Tomcat converts pathnames to URLs when
> > it uses URLClassLoader. Tomcat calls the method File.toURL and that
> > fails when there's a "#" in the pathname. But the Javadoc for
> > File.toURL suggests a workaround: Convert the pathname to a URI first,
> > then to a URL.
>
> thanks for your confirmation. Looking through bugs.sun.com this seems to
> be an inherent behaviour with reports starting in 1999. So fixing it in
> Tomcat would be great, but i'm hesitating calling it a "bug" from
> Tomcats POV - more a feature request.
>
> @Len: Do you have a (javadoc)link for this workaround/suggestion? thx!
>
> >
> > I tried that (in ClassLoaderFactory) and it seem to fix the
> > classloader problem. Tomcat starts up fine - but it can't compile any
> > JSPs. So there are other components of Tomcat that have similar
> > problems.
>
> I tried something with a similar result. Just moved CATALINA_HOME to
> some non-#-directory but left CATALINA_BASE as it was. This way Tomcat
> started but webapplications could not be deployed/did not work.
>
> >
> > So, my advice is to see how hard it would be for you to get the #s out
> > of your pathnames. That may be easier than fixing Tomcat.
>
> I'm just waiting for some feedback from sun but avoiding #s in directory
> and file names in the java world is probably the way to go. Otherwise
> every java application must be forced to workaround this problem. And
> the latter is more work - if possible at all - than getting rid of #s.
>
> kind regards,
>Markus
>
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: V 4.01 for solaris x86

[Tim.OShea]

Thanks very much, I'll give it a go.

I am unable to move to something more recent, as the company who
supplied the applets we need to use have identified incompatibilities in
later versions of both java and tomcat, but have not yet addressed them.

Many thanks. 

Tim O'Shea
Technical Manager - Managed Services 

TietoEnator

Banking & Insurance (UK)
Direct +44 1582 845111
Mobile +44 7810 374235
Fax +44 1582 866927
E-mail [EMAIL PROTECTED]

Gainsborough House, Houghton Hall Park,
Houghton Regis, Beds. LU5 5XF
United Kingdom 

www.tietoenator.co.uk 

TietoEnator (UK No.1) Limited is a limited company registered in England
& Wales.  Registered number 1454835.  Registered office: Gainsborough
House, Houghton Hall Park, Houghton Regis, Beds.  LU5 5XF.

Please note: The information contained in this message may be legally
privileged and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, you are hereby notified
that any unauthorised use, distribution or copying of this communication
is strictly prohibited. If you have received this communication in
error, please notify us immediately by replying to the message and
deleting it from your computer. Thank You


-Original Message-
From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] 
Sent: 13 August 2007 15:55
To: Tomcat Users List
Subject: RE: V 4.01 for solaris x86

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Subject: V 4.01 for solaris x86
> 
> Is it possible to get hold of binaries for Tomcat 4.0 (> 4.04) for
> Solaris x86?

Tomcat is pure Java, so there are no platform-specific binaries.  Look
here for the 4.0 versions:
http://archive.apache.org/dist/tomcat/tomcat-4/archive/

Make sure you have the necessary Solaris patches for the JVM you're
using.

Why don't you move up to something a more recent?  The levels you're
asking about are over five years old.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: V 4.01 for solaris x86

[Hassan Schroeder]

On 8/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

> There is a binary download for sparc here, but not x86.

?? You /do/ know Tomcat is written in Java, yes? :-)

Is there a JVM for Solaris x86? Then you're set.

FWIW!
-- 
Hassan Schroeder  [EMAIL PROTECTED]

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANN] Apache Tomcat 6.0.14 released

[Remy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 6.0.14 stable. This release includes bugfixes over Apache Tomcat 
6.0.13.


Apache Tomcat 6.0 includes new features over Apache Tomcat 5.5,
including support for the new Servlet 2.5 and JSP 2.1 specifications, a
refactored clustering implementation, advanced IO features, and
improvements in memory usage.

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

Downloads:
http://tomcat.apache.org/download-60.cgi

Migration guide from Apache Tomcat 5.5.x:
http://tomcat.apache.org/migration.html

Thank you,

-- The Apache Tomcat Team

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANN] New book "Professional Apache Tomcat 6"

[Vivek Chopra]

Announcing the release of a new book "Professional
Apache Tomcat 6" (Wrox Press).

http://www.wrox.com/WileyCDA/WroxTitle/productCd-0471753610.html

This is the third edition in our "Professional Apache
Tomcat" book series.

Who is this book for?

Professional Apache Tomcat 6 is primarily targeted
toward administrators and engineers responsible for
Tomcat configuration, performance tuning, system
security, or deployment architecture. The authors
focus on solving real-world problems encountered in
all phases of server administration.

What's changed from the second edition?

Other than updated content, you will find the
following in the book:

* Complete and updated coverage for Tomcat 6: This
book focuses exclusively on the new Tomcat version.
*  Performance, Performance, Performance: The book has
two chapters on Tomcat performance, including coverage
of the new, high-performance APR and NIO Connectors.
* A new chapter on logging: Both Tomcat server logs as
well as logging from Web applications. The chapter
also covers log file management strategies and log
analysis.
* An enhanced chapter on managing and monitoring
Tomcat using its JMX support.
* A reworked chapter on clustering: Tomcat 6
introduces improvements in its clustering support,
including a new clustering configuration.
* A reworked chapter on securing Tomcat installations
and Web applications.
* Coverage of the Web server Connectors for Tomcat 6 —
mod_proxy and mod_jk.





   

Got a little couch potato? 
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz
 

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [ANN] New book "Professional Apache Tomcat 6"

[Partha Goswami]

here is also one good books.

http://apress.com/book/bookDisplay.html?bID=10216

On 8/13/07, Vivek Chopra <[EMAIL PROTECTED]> wrote:
>
> Announcing the release of a new book "Professional
> Apache Tomcat 6" (Wrox Press).
>
> http://www.wrox.com/WileyCDA/WroxTitle/productCd-0471753610.html
>
> This is the third edition in our "Professional Apache
> Tomcat" book series.
>
> Who is this book for?
>
> Professional Apache Tomcat 6 is primarily targeted
> toward administrators and engineers responsible for
> Tomcat configuration, performance tuning, system
> security, or deployment architecture. The authors
> focus on solving real-world problems encountered in
> all phases of server administration.
>
> What's changed from the second edition?
>
> Other than updated content, you will find the
> following in the book:
>
> * Complete and updated coverage for Tomcat 6: This
> book focuses exclusively on the new Tomcat version.
> *  Performance, Performance, Performance: The book has
> two chapters on Tomcat performance, including coverage
> of the new, high-performance APR and NIO Connectors.
> * A new chapter on logging: Both Tomcat server logs as
> well as logging from Web applications. The chapter
> also covers log file management strategies and log
> analysis.
> * An enhanced chapter on managing and monitoring
> Tomcat using its JMX support.
> * A reworked chapter on clustering: Tomcat 6
> introduces improvements in its clustering support,
> including a new clustering configuration.
> * A reworked chapter on securing Tomcat installations
> and Web applications.
> * Coverage of the Web server Connectors for Tomcat 6 —
> mod_proxy and mod_jk.
>
>
>
>
>
>
>
> 
> Got a little couch potato?
> Check out fun summer activities for kids.
>
> http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz
>
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Regards
Partha Goswami
Solaris/Open solaris User Group
www.solaris-user-group.org

suddenly I cannot run servlets anymore

[Tuomas]

Hi!

With the advice I got from
,
I successfully installed Tomcat 5.5 on my computer
(Ubuntu 7.04). I verified that I can a) start the
server, b) access my own HTML and JSP pages, and c)
compile and run simple servlets.

I created a development dir in my home directory, 
/home/tuope/src/web/servlets. I have created, too,
some shortcuts there:
catalina.sh -> /usr/local/bin/tomcat/bin/catalina.sh
shutdown.sh -> /usr/local/bin/tomcat/bin/shutdown.sh
startup.sh -> /usr/local/bin/tomcat/bin/startup.sh

Having done the tests mentioned above, I issued
$ sudo sh ./shutdown.sh
and then
$ sudo sh ./startup.sh

The result was that *I can no longer run any
servlets*. I get this message

HTTP Status 500 -

type Exception report

message

description The server encountered an internal error
() that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: Cannot allocate
servlet instance for path
/servlet/coreservlets.HelloServlet2

org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:389)

org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:134)

javax.servlet.http.HttpServlet.service(HttpServlet.java:690)

javax.servlet.http.HttpServlet.service(HttpServlet.java:803)

root cause

java.lang.NoClassDefFoundError:
javax/servlet/http/HttpServlet
java.lang.ClassLoader.defineClass1(Native Method)

java.lang.ClassLoader.defineClass(ClassLoader.java:620)

java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)

java.net.URLClassLoader.defineClass(URLClassLoader.java:260)

java.net.URLClassLoader.access$000(URLClassLoader.java:56)

java.net.URLClassLoader$1.run(URLClassLoader.java:195)
java.security.AccessController.doPrivileged(Native
Method)

java.net.URLClassLoader.findClass(URLClassLoader.java:188)
java.lang.ClassLoader.loadClass(ClassLoader.java:306)

sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
java.lang.ClassLoader.loadClass(ClassLoader.java:251)

org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1274)

org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1205)

org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:370)

org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:134)

javax.servlet.http.HttpServlet.service(HttpServlet.java:690)

javax.servlet.http.HttpServlet.service(HttpServlet.java:803)

note The full stack trace of the root cause is
available in the Apache Tomcat/5.5.23 logs.

I rebooted the computer. Didn't help.

$ echo $JAVA_HOME
/usr/lib/jvm/java-6-sun-1.6.0.00
$ echo $CLASSPATH
/usr/local/bin/tomcat/common/lib/jsp-api.jar:/usr/local/bin/tomcat/common/lib/servlet-api.jar:/home/tuope/src/web/servlets:.

Does anyone know what might be causing this odd
behavior? I am unarmed. :-(

Tuomas



-- 
[EMAIL PROTECTED]
http://tuope.mithlond.net

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: suddenly I cannot run servlets anymore

[Caldarale, Charles R]

> From: Tuomas [mailto:[EMAIL PROTECTED] 
> Subject: suddenly I cannot run servlets anymore
> 
> $ echo $CLASSPATH
> /usr/local/bin/tomcat/common/lib/jsp-api.jar:/usr/local/bin/to
> mcat/common/lib/servlet-api.jar:/home/tuope/src/web/servlets:.

Get rid of the CLASSPATH variable - it shouldn't be used.  (For that
matter, it never should have been invented.)

Are you using a real Tomcat download, or some 3rd-party repackeged mess?

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk with jetty strange behaviour

[Andrei Neagoe]

Hello Rainer,

I've let it log with debug log level all night and I managed to get what 
you needed (some [error] lines).

I have the sample at http://www.craiova.ro/mod_jk.log

Cheers,

Andrei Neagoe



Rainer Jung wrote:
OK: you started with an error log entry referring to errno 104 as your 
original problem. I had the impression, you can easily reproduce this 
problem. In the logs you presented - even in the full log download - 
this problem is not present.


The lines you referred to below are normal. They only tell us, that a 
new connection to the backend had to be established. Those log lines 
themselves do not indicate any problem.


Regards,

Rainer

Andrei Neagoe wrote:
Yes, they are. It was my mistake referring to it as an error. I was 
talking about:


[Sun Aug 12 22:38:53 2007] [22781:3079018176] [debug] 
ajp_get_endpoint::jk_ajp_common.c (2498): acquired connection pool 
slot=0
[Sun Aug 12 22:38:53 2007] [22781:3079018176] [debug] 
ajp_marshal_into_msgb::jk_ajp_common.c (551): ajp marshaling done
[Sun Aug 12 22:38:53 2007] [22781:3079018176] [debug] 
ajp_service::jk_ajp_common.c (1935): processing worker1 with 2 retries
[Sun Aug 12 22:38:53 2007] [22781:3079018176] [debug] 
ajp_send_request::jk_ajp_common.c (1199): (worker1) socket 79 is not 
connected any more (errno=11)
[Sun Aug 12 22:38:53 2007] [22781:3079018176] [debug] 
ajp_send_request::jk_ajp_common.c (1231): (worker1) failed sending 
request. Will try another pooled connection


which I sent in the previous mail and you said it stopped right 
before something interesting. That's why I've attached the whole log. 
It doesn't seem anything suspicious to me around those log entries 
tough...


Andrei Neagoe

Rainer Jung wrote:

Andrei Neagoe wrote:
I've archived a portion of the log containing 2 instances of the 
error. You can download it at http://www.craiova.ro/mod_jk.log.bz2

I've tried sending it via mail but there's a limit on mail size.


I downloaded this file, uncompressed and untarred. The resulting log 
file was


-rw-r-   1 jung kippdata 9454912 Aug 12 21:39 mod_jk.log

with md5 sum 4b880aa29a4a9baa478c543cd65dde3a. It does not contain 
any error! All log lines are info or debug.


Regards,

Rainer


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Thawte SSL certificates

[Lyallex]

OK, I think I've figured out what went wrong.
I forgot to click the PKS7 checkbox when generating the test cert.
(I know, I know but it has been a very long day).
I have it working now, I still don't really understand why I had to
install the same cert in my browser as I installed in my Tomcat
keystore but I guess that is for another day.

I have pasted the sequence of events below this message just in case
anyone else is trying to get this working.

Just FYI

The docs state that thawte root certs are at
http://www.thawte.com/certs/trustmap.html This has changed to
https://www.thawte.com/roots.

This is NOT a criticism of the documentation which in all other
respects seems to be spot on.

-
Installing a thawte test cert, please ignore if you are not interested

First of all let me say that I followed the instructuons at
http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html to the letter

Here is the sequence of events.

$> keytool -genkey -alias tomcat -keyalg RSA -keystore
/usr/local/tomcat/sslkeys/.keystore

This generated a self signed certificate. I know this works because I
can access via https
and when the browser pops up the unknown certification authority
message I can see
the values I used to create the keystore.

I then did the following

keytool -certreq -keyalg RSA -alias tomcat -file certreq.csr -keystore
/usr/local/tomcat/sslkeys/.keystore

This created a file certreq.csr in the directory in which I ran the
command (and no doubt did some other stuff as well)

I then went to www.thawte.com and clicked the 'trials' menu item

Under the SSL FREE Trial Certificate heading I clicked 'Download Trial'
I filled in the details, selected the 'immediately' radio button and
clicked 'continue'
Making very sure I clicked the PKS7 check box

under the 'select your trial certificate' heading I selected the
SSL Web Server Certificate (All servers) radio

I pasted in my CSR and clicked continue

I got what I assume to be a certificate

I copied this to a text file called thawte_test_cert.txt and uploaded
it to my server

Next I went and got the Thawt Root certificate bundle

Incidently (and this is NOT a criticism of the documentation) the docs
state that these certs are available at
http://www.thawte.com/certs/trustmap.html This has canged to
https://www.thawte.com/roots. Just FYI

Anyway, after unzipping the thawte-roots.zip file
I selected the ./Thawt Test Roots/thawte test roor.cer file and
installed it thus

keytool -import -alias tomcat -keystore
/usr/local/tomcat/sslkeys/.keystore -trustcacerts -file "thawte test
root.cer" (note the "" required on Debian Linux)

This seemed to work.

I then installed the test certificate generated as described above thusly

keytool -import -alias tomcat -keystore
/usr/local/tomcat/sslkeys/.keystore -trustcacerts -file
thawte_test_cert.txt

this semed to work.

Now I apparently needed to install a Root CA certificate in my browser
(firefox 2.0.0.6)
so I tried adding the Thawte Primary Root CA/Thawte_Primary_Root_CA.cer

I then tried to access my site via https (having restarted Tomcat of course)
I got the (now familiar) Website Certified By An Unknown Authority
message and when I checked
out the certificate it was actually my own self-signed certificate

OK, so I thought I'd try to install the same certificate in the
browser as I installed in the keystore
this time I installed the ./Thawt Test Roots/thawte test roor.cer into
my browser and tried again
(I restarted Tomcat just to be on the safe side) ... success. No more messages
-

On 8/13/07, Hassan Schroeder <[EMAIL PROTECTED]> wrote:
> On 8/13/07, Lyallex <[EMAIL PROTECTED]> wrote:
>
> > I was wondering if anyone has managed to get the Thawte SSL test
> > certificate working with Tomcat 5.5.
> >
> > I have created a CSR and submitted it to Thawte. I got a test certificate 
> > back
>
> ? I'm not sure what "test" certificate you're referring to, but I have a
> Thawte cert on a client site, and the installation was by-the-book --
> ); did
> you follow that exactly?
>
> --
> Hassan Schroeder  [EMAIL PROTECTED]
>
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: suddenly I cannot run servlets anymore

[Tuomas]

> Get rid of the CLASSPATH variable - it shouldn't be
> used.  (For that
> matter, it never should have been invented.)
> 
> Are you using a real Tomcat download, or some
> 3rd-party repackeged mess?

I got my copy from
http://tomcat.apache.org/download-55.cgi.

I shut down the computer, then turned it on again.
Issued 
$ sudo sh /usr/local/bin/tomcat/bin/startup.sh. Bingo.
EVERYTHING is working again. I dont know why.

Can file permissions play a role here? Should *.class
file be executable (for instance, 755)? (I run Linux
(Ubuntu 7.04).)

$ ls -ld apache-tomcat-5.5.23/
drwxr-xr-x 11 root root 4096 2007-08-13 19:11
apache-tomcat-5.5.23/

*.class file are owned by my user account (tuope). My
umask settings give them a '-rw---' permission
mode by default. Should all the class files I put in
/usr/local/bin/tomcat/shared/classes, be owned by
root?

Thanks for your time!

Tuomas

-- 
[EMAIL PROTECTED]
http://tuope.mithlond.net

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

character encodingg problem

[Russo, Joe]

Hi,
This information you provided helped me a lot.  I was able to include
the filter and get the correct data.  The main problem I am having is
the current data is basically corrupt.  

This is what I believe is happening:  some of the data is having the
wrong character encoding into the database and causes those funky
characters.  If I include the filter it does work with the existing data
being encoded properly and no bad or correct data is put into the DB.

Of course, the existing data that is stored incorrectly can not be
viewed correctly.  I thought by changing the filter you sent by
interrupting the charset as ISO-8859-1 for the response would work
correctly.  This would be great if it work that it would have all new
data put in correctly and all the old data would be seen correctly.  

Any ideas or help would be appreciated.
Joe

import javax.servlet.*;
import java.io.*;
import javax.servlet.http.*;

public class ContentTypeFilter
implements Filter{

  public void init(FilterConfig config){}
  public void destroy() {}
  public void doFilter(ServletRequest request, ServletResponse response,
FilterChain filterChain) throws IOException, ServletException{
request = (HttpServletRequest)request;
request.setCharacterEncoding("UTF-8");
response.setCharacterEncoding("ISO-8859-1");
response.setContentType("text/html;charset=ISO-8859-1");

filterChain.doFilter(request, response);
  }
}


-Original Message-
From: Nathan Hook [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 25, 2007 2:13 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat5.0.28 character encodingg problem

Both Chris and Tim are giving great advice.  We're actually just trying
to 
internationalize our application for our next major release.

Here are the things we've learned.

- You have to change the URIEncoding on your Tomcat Connector in your 
server.xml (as Tim pointed out).

We are using mod_jk and had to change our entry in the server.xml to the

following:




- On every request that comes into your tomcat server you have to check
the 
character encoding of your request and your response BEFORE any work is 
actually done.

So like Chris mentioned you want to look up a character encoding filter.
I 
would recommend placing that as the very first filter that gets called
in 
your application.  To do make this filter first in the filter chain is 
simple.  When adding your filter to your applications web.xml file, make

sure is the first one listed in the filter mappings section.

Here is the Filter we are currently using for testing.

public class ContentTypeFilter implements Filter {
  public void init(FilterConfig config) {}
  public void destroy() {}
  public void doFilter(ServletRequest request, ServletResponse response,

FilterChain filterChain) throws IOException, ServletException
  {
 // I've seen some other classes that check to see if the character 
encoding is null and then set
 // the character encoding to utf-8.  I'm not sure which is best at
this 
time.  My guess is doing
 // the null checks because from my understanding the client can
change 
the page encoding on
 // each and every request even though the server sets the page up
to be 
utf-8.
 request = (HttpServletRequest)request;
 request.setCharacterEncoding("UTF-8");

 // Make sure to set the character encoding on the response early 
because once something is
 // sent back to the client (like a jsp), then the character
encoding is 
already set to the default
 // of the server.
 response.setCharacterEncoding("UTF-8");
 // Set the content type in the header of the response.
 response.setContentType("text/html;charset=UTF-8");

 filterChain.doFilter(request, response);
  }
}


- Set the meta type in each and every jsp to be utf-8.  Now, most
browsers 
will ignore this value from my understanding, but it shouldn't hurt to
add 
it.


  test title
  



- Finally for database storage...  Again from my understanding you will
need 
to set all your tables to utf-8 and then inform your JDBC Driver that
you 
want to pass everything back and forth using utf-8.

In mysql you add the following to your jdbc url connection string:
useUnicode=true
characterEncoding=UTF-8


I hope all that information helps.


Original Message Follows
From: Tim Funk <[EMAIL PROTECTED]>
Reply-To: "Tomcat Users List" 
To: Tomcat Users List 
Subject: Re: Tomcat5.0.28 character encodingg problem
Date: Wed, 25 Jul 2007 12:09:07 -0400

http://tomcat.apache.org/faq/misc.html#utf8

And you should first start with in server.xml:
 

-Tim

Joe Russo wrote:
>I am getting the following error in the display of the JSP.  To give a
>little history, this application I am supporting, at the time the
>developers thought they needed to encode the characters to UTF-8 into
>our Oracle DB.  The developers were unaware they could have allowed the
>DB Driver convert it for us.  Therefore, we double encode going into
and
>out of t

Prefix Paths on Servlets

[Ryan Shelley]

I developed a servlet with the package name "idm.war".  Therefore, my  
URL is http://myhost/idm/...


However, it's recently been requested that I add a prefix to my  
servlet.  Now it should be http://myhost/it/idm/...


Does tomcat provide a configuration that would allow me to add "/it"  
to just this servlet as a prefix, without having to repackage my war  
as "it.war" (my package is not all of IT's servlets, so I don't want  
to package it as such)?  I looked at the servlet context, and I don't  
believe that does what I need.  Any other suggestions?


Thanks!

-Ryan

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: suddenly I cannot run servlets anymore

[Caldarale, Charles R]

> From: Tuomas [mailto:[EMAIL PROTECTED] 
> Subject: RE: suddenly I cannot run servlets anymore
> 
> I got my copy from
> http://tomcat.apache.org/download-55.cgi.

That's the proper place.

> Can file permissions play a role here?

Yes.

> Should *.class file be executable (for instance, 755)?

No, they are not directly executable; they're simply read by the JVM.

> Should all the class files I put in
> /usr/local/bin/tomcat/shared/classes, be owned by
> root?

It's a bad idea to run Tomcat (or any application) as root - too much
potential for doing accidental damage.  Tomcat does need at least read
access to all files it will be accessing.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Prefix Paths on Servlets

[Caldarale, Charles R]

> From: Ryan Shelley [mailto:[EMAIL PROTECTED] 
> Subject: Prefix Paths on Servlets
> 
> However, it's recently been requested that I add a prefix to my  
> servlet.  Now it should be http://myhost/it/idm/...

Assuming you're running a reasonably modern version of Tomcat (you
didn't bother to tell us), then place your idm.war file somewhere other
than the  appBase directory (usually webapps).  Then, create a
file in conf/Catalina/[host] named it#idm.xml containing a 
element with a docBase attribute pointing to the location of the idm.war
file.

As long as you haven't hard-coded the path in the html/jsp/java source,
you should be o.k.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: character encodingg problem

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Joe,

Russo, Joe wrote:
> Of course, the existing data that is stored incorrectly can not be
> viewed correctly.  I thought by changing the filter you sent by
> interrupting the charset as ISO-8859-1 for the response would work
> correctly.

No, the problem is that your application thinks that the data in the DB
is in UTF-8 format, but it's not. Here's what you have to do:

1.  Identify the rows that need to be "fixed".
2a. Run a query that reads the data as bytes (not characters), and then
cast it to UTF-8 character data, then write it back.
2b. Write a little Java program to read the data as bytes (not chars),
convert to a String using the suspected encoding (UTF-8, right?),
and then writing it back to the database.

This ought to work, but might be kind of a pain in the neck. Of course,
always test that things are working the way you expect them to before
you COMMIT anything ;)

I would recommend using a Java program. Write a quick test like this:

SELECT my_data ... WHERE ... FOR UPDATE

ResultSet rs = ...;
InputStream in = rs.getBinaryStream("my_data");
int count = 0;
String s = "";
byte[] bytes = new byte[1024];

while(0 <= (c = in.read(bytes))
s = s + new String(bytes, 0, c, "ISO-8859-1"); // or whatever

System.out.println("Read string from database: " + s);

rs.updateString("my_data", s);

rs.close();

SELECT my_data ... WHERE ...

s = rs.getString("my_data");

System.out.println("Read fixed string from database: " + s);

conn.rollback();

Make sure that your terminal is configured to properly display UTF-8
character data, or that you have some other good way of determining that
the test output is correct.

- -chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGwKpM9CaO5/Lv0PARAnjeAKCbLF9KK2gkaVTE0yjbs6YMPRfFUACfUjAR
SIPO2gjeAzdwK8iUreSF3uY=
=FKXu
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Prefix Paths on Servlets

[Ryan Shelley]

My apologies... I'm on Tomcat 5.5.  I'll take a look at it and give  
that a try.  Thanks Chuck!


On Aug 13, 2007, at 11:59 AM, Caldarale, Charles R wrote:


From: Ryan Shelley [mailto:[EMAIL PROTECTED]
Subject: Prefix Paths on Servlets

However, it's recently been requested that I add a prefix to my
servlet.  Now it should be http://myhost/it/idm/...


Assuming you're running a reasonably modern version of Tomcat (you
didn't bother to tell us), then place your idm.war file somewhere  
other

than the  appBase directory (usually webapps).  Then, create a
file in conf/Catalina/[host] named it#idm.xml containing a 
element with a docBase attribute pointing to the location of the  
idm.war

file.

As long as you haven't hard-coded the path in the html/jsp/java  
source,

you should be o.k.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE  
PROPRIETARY

MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e- 
mail

and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk with jetty strange behaviour

[Rainer Jung]

No idea, it really looks like there's a communication problem to the 
backend. Starting with 01:14:22 all connections that are created new are 
able to send a request, but do not receive any response.


I think I would first enable Cpin/Cpong and maybe some other timeouts, 
to make the communication behaviour more defined.


http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html

Regards,

Rainer


Andrei Neagoe wrote:

Hello Rainer,

I've let it log with debug log level all night and I managed to get what 
you needed (some [error] lines).

I have the sample at http://www.craiova.ro/mod_jk.log

Cheers,

Andrei Neagoe


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: character encodingg problem

[Russo, Joe]

Chris,
Thank you very much for you response.  I am going to try and look at how
long it will take to do this type of conversion for 39 databases.  
Joe


-Original Message-
From: Christopher Schultz [mailto:[EMAIL PROTECTED] 
Sent: Monday, August 13, 2007 3:00 PM
To: Tomcat Users List
Subject: Re: character encodingg problem

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Joe,

Russo, Joe wrote:
> Of course, the existing data that is stored incorrectly can not be
> viewed correctly.  I thought by changing the filter you sent by
> interrupting the charset as ISO-8859-1 for the response would work
> correctly.

No, the problem is that your application thinks that the data in the DB
is in UTF-8 format, but it's not. Here's what you have to do:

1.  Identify the rows that need to be "fixed".
2a. Run a query that reads the data as bytes (not characters), and then
cast it to UTF-8 character data, then write it back.
2b. Write a little Java program to read the data as bytes (not chars),
convert to a String using the suspected encoding (UTF-8, right?),
and then writing it back to the database.

This ought to work, but might be kind of a pain in the neck. Of course,
always test that things are working the way you expect them to before
you COMMIT anything ;)

I would recommend using a Java program. Write a quick test like this:

SELECT my_data ... WHERE ... FOR UPDATE

ResultSet rs = ...;
InputStream in = rs.getBinaryStream("my_data");
int count = 0;
String s = "";
byte[] bytes = new byte[1024];

while(0 <= (c = in.read(bytes))
s = s + new String(bytes, 0, c, "ISO-8859-1"); // or whatever

System.out.println("Read string from database: " + s);

rs.updateString("my_data", s);

rs.close();

SELECT my_data ... WHERE ...

s = rs.getString("my_data");

System.out.println("Read fixed string from database: " + s);

conn.rollback();

Make sure that your terminal is configured to properly display UTF-8
character data, or that you have some other good way of determining that
the test output is correct.

- -chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGwKpM9CaO5/Lv0PARAnjeAKCbLF9KK2gkaVTE0yjbs6YMPRfFUACfUjAR
SIPO2gjeAzdwK8iUreSF3uY=
=FKXu
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: character encodingg problem

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Joe,

Russo, Joe wrote:
> Chris,
> Thank you very much for you response.  I am going to try and look at how
> long it will take to do this type of conversion for 39 databases.  

Ouch! Perhaps your database supports a query that might be able to do
this faster -- that is, without writing a Java program to do it.

- -chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGwMvl9CaO5/Lv0PARAnwaAJ4z5jE2pKQv9TEN8cR6nigU3mgu2gCgpkTh
anFJVL+pk7uiubWenulxzVE=
=7teY
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: character encodingg problem

[Ryan Shelley]

So I've been able to deploy the servlet and access it with the "/it"  
prefix, however, I noticed that when I redeploy my war, my custom  
it#idm.war context file is also removed.  Is there a way to keep that  
transient between deployments?  Or package it with the war?


On Aug 13, 2007, at 1:12 PM, Russo, Joe wrote:


Chris,
Thank you very much for you response.  I am going to try and look  
at how

long it will take to do this type of conversion for 39 databases.
Joe


-Original Message-
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Sent: Monday, August 13, 2007 3:00 PM
To: Tomcat Users List
Subject: Re: character encodingg problem

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Joe,

Russo, Joe wrote:

Of course, the existing data that is stored incorrectly can not be
viewed correctly.  I thought by changing the filter you sent by
interrupting the charset as ISO-8859-1 for the response would work
correctly.


No, the problem is that your application thinks that the data in  
the DB

is in UTF-8 format, but it's not. Here's what you have to do:

1.  Identify the rows that need to be "fixed".
2a. Run a query that reads the data as bytes (not characters), and  
then

cast it to UTF-8 character data, then write it back.
2b. Write a little Java program to read the data as bytes (not chars),
convert to a String using the suspected encoding (UTF-8, right?),
and then writing it back to the database.

This ought to work, but might be kind of a pain in the neck. Of  
course,

always test that things are working the way you expect them to before
you COMMIT anything ;)

I would recommend using a Java program. Write a quick test like this:

SELECT my_data ... WHERE ... FOR UPDATE

ResultSet rs = ...;
InputStream in = rs.getBinaryStream("my_data");
int count = 0;
String s = "";
byte[] bytes = new byte[1024];

while(0 <= (c = in.read(bytes))
s = s + new String(bytes, 0, c, "ISO-8859-1"); // or whatever

System.out.println("Read string from database: " + s);

rs.updateString("my_data", s);

rs.close();

SELECT my_data ... WHERE ...

s = rs.getString("my_data");

System.out.println("Read fixed string from database: " + s);

conn.rollback();

Make sure that your terminal is configured to properly display UTF-8
character data, or that you have some other good way of determining  
that

the test output is correct.

- -chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGwKpM9CaO5/Lv0PARAnjeAKCbLF9KK2gkaVTE0yjbs6YMPRfFUACfUjAR
SIPO2gjeAzdwK8iUreSF3uY=
=FKXu
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: character encodingg problem

[Caldarale, Charles R]

> From: Ryan Shelley [mailto:[EMAIL PROTECTED] 
> Subject: Re: character encodingg problem
> 
> however, I noticed that when I redeploy my war, my custom  
> it#idm.war context file is also removed

You can't use the manager app or any other conventional script I know of
to do this.  Remember, your .war file must be placed outside of the
normal webapps directory.  All you need to deploy the app is copy the
it#idm.xml file into conf/Catalina/[host] - nothing else is needed.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

CVE-2007-3382: Handling of cookies containing a ' character

[Mark Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

CVE-2007-3382: Handling of cookies containing a ' character

Severity:
Low (Session Hi-jacking)

Vendor:
The Apache Software Foundation

Versions Affected:
6.0.0 to 6.0.13
5.5.0 to 5.5.24
5.0.0 to 5.0.30
4.1.0 to 4.1.36
3.3 to 3.3.2

Description:
Tomcat incorrectly treats a single quote character (') in a cookie
value as a delimiter. In some circumstances this can lead to the
leaking of information such as session ID to an attacker.

Mitigation:
Upgrade to 6.0.14

Credit:
This issue was discovered by Tomasz Kuczynski, Poznan Supercomputing
and Networking Center, who worked with the CERT/CC to report the
vulnerability.

Example:
http://localost:8080/servlets-examples/servlet/CookieExample?cookiename=BLOCKER&cookievalue=%5C%22A%3D%27%3B+Expires%3DThu%2C+1+Jan+2009+00%3A00%3A01+UTC%3B+Path%3D%2Fservlets-examples%2Fservlet+%3B

References:
http://tomcat.apache.org/security.html

Mark Thomas


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGwSFVb7IeiTPGAkMRAjkwAKDnu+C08WRZazmZfzunFeHcitsvnACg3CtP
6c6FCxbFOcfxhqqayg8kdUI=
=MkDj
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

CVE-2007-3385: Handling of \" in cookies

[Mark Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

CVE-2007-3385: Handling of \" in cookies

Severity:
Low (Session Hi-jacking)

Vendor:
The Apache Software Foundation

Versions Affected:
6.0.0 to 6.0.13
5.5.0 to 5.5.24
5.0.0 to 5.0.30
4.1.0 to 4.1.36
3.3 to 3.3.2

Description:
Tomcat incorrectly handles the character sequence \" in a cookie
value. In some circumstances this can lead to the leaking of
information such as session ID to an attacker.

Mitigation:
Upgrade to 6.0.14

Credit:
This issue was discovered by Tomasz Kuczynski, Poznan Supercomputing
and Networking Center, who worked with the CERT/CC to report the
vulnerability.

Example:
http://localhost:8080/examples/servlets/servlet/CookieExample?cookiename=HAHA&cookievalue=%5C%22FOO%3B+Expires%3DThu%2C+1+Jan+2009+00%3A00%3A01+UTC%3B+Path%3D%2F%3B

References:
http://tomcat.apache.org/security.html


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGwSFlb7IeiTPGAkMRArdPAJ99AXYzSterU7oG+u8UrtQAd2lTZwCbBK2R
hwRixKaYOwWyj5kD+fLT1ls=
=hgTP
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

CVE-2007-3386: XSS in Host Manager

[Mark Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

CVE-2007-3386: XSS in Host Manager

Severity:
Low (Cross-site scripting)

Vendor:
The Apache Software Foundation

Versions Affected:
6.0.0 to 6.0.13
5.5.0 to 5.5.24

Description:
The Host Manager Servlet does not filter user supplied data before
display. This enables an XSS attack.

Mitigation:
Log out (close browser) of the Host Manager application once admin
tasks are complete
Upgrade to 6.0.14

Credit:
This issue was discovered by the NTT OSS CENTER who worked with the
JPCERT/CC to report the vulnerability.

Example:
http://localhost:8080/host-manager/html/add"; method="get">





References:
http://tomcat.apache.org/security.html


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGwSFyb7IeiTPGAkMRAlgMAKCe0hS+c6so9pxK3KfN7LggWv+3uQCfUsAg
95+vMfHDJlrKHP/yKUZ0SYc=
=1pQc
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]