Let's encrypt SSL config

[ivan]

Hi,

It drives me nuts now.

I have created sym links to the PEM files. I made the PEM files readable for
the tomcat user. I set the server.xml to use SSL. And the connector fails to
start.











 

I did try to change the type to RSA, to no avail. All I see in the log is:

02-Jan-2021 17:40:54.398 INFO [main] org.apache.coyote.AbstractProtocol.init
Initializing ProtocolHandler ["https-openssl-nio-8443"]

02-Jan-2021 17:40:54.466 SEVERE [main]
org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to
initialize component [Connector[HTTP/1.1-8443]]

org.apache.catalina.LifecycleException: Protocol handler
initialization failed

at
org.apache.catalina.connector.Connector.initInternal(Connector.java:1013)

... some lines removed

at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:473)

Caused by: java.lang.IllegalArgumentException

at
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJss
eEndpoint.java:99)

... some lines are removed

at
org.apache.catalina.connector.Connector.initInternal(Connector.java:1010)

... 13 more

Caused by: java.io.IOException

at
org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.java:302)

at
org.apache.tomcat.util.net.openssl.OpenSSLUtil.getKeyManagers(OpenSSLUtil.ja
va:98)

at
org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:247
)

at
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJss
eEndpoint.java:97)

... 20 more

 

I've checked the SSLUtilBase.java code (tomcat 9.0.33):

if (certificate.getCertificateFile() == null) {

throw new IOException(sm.getString("jsse.noCertFile"));

}

 

I did try to copy the files instead of using sym links. No avail. Removed
the comments from the cert files. No avail. It seems tomcat cannot find the
files I've specified in the server.xml.

What do I miss?

 

Best Regards,

Ivan

Tomcat 7, JAX-WS 2.2.5

[Ivan]

Dear All,

We are running JAX-WS web-services using JAX-WS RI under tomcat. First we
upgraded from Tomcat 5.5 to Tomcat 7 and everything was fine. Eventually, we
decided to upgrade to the latest JAX-WS RI and went for 2.2.5 version. 

We faced a problem. Upon requests we started seeing exceptions from JAX-WS
indicating that the body of the request was broken. From the point of view of
TCPMON everything was fine. We enabled request tracing and saw that the JAX-WS
RI was gettting empty requests' input streams which were causing mentioned
exceptions (org.jvnet.mimepull.MIMEParsingException: Missing start boundary;
com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog). 

Also, we tried tomcat 5.5 and JAX-WS RI 2.2.5 and they worked together fine.

After investigation we found out that all versions of JAX-WS RI since 2.2.2 were
causing the same problem. Presumably, the cause of the issue is servlet 3.0
async request processing which has been added in JAX-WS RI 2.2.2. Partly, it
explains why tomcat 5.5 works fine with JAX-WS RI 2.2.5 as the RI falls back to
non-async request processing.

We changed connector's protocol to 'org.apache.coyote.http11.Http11NioProtocol'
and everything started working.

As I understand, both BIO and NIO connectors should be working well with servet
3.0 async. Could you comment on this?

I am really looking forward to your reply.

Best regards,
Ivan


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: getPart()/getParts() invocation in the filter ?

[Ivan]

Thanks, Mark.
OK,  turn to the user mail list.
>From the text I quoted from servlet spec, does it mean that I must
configured the target servlet with multipart (annotation or web.xml), or
those two getPart()/getParts() methods could not be used even the incoming
request is of mutlipart type?  Actually, I tried in the latest Tomcat 7, it
seems to work in this way.

2010/5/13 Mark Thomas 

> On 13/05/2010 03:00, Ivan wrote:
>
>> Hi,
>> While using the new features of getPart()/getParts() in the Servlet
>> 3.0,
>> I found that those methods could not be invoked in filter.
>>
>
> The short answer is that this should work, even from a filter.
>
> The long answer is that this discussion belongs on the users list for now.
> If that discussion identifies a bug in the current Tomcat implementation
> then any discussion around fixing that belongs here.
>
> Mar
>
>
>  After checking the spec, I found some words below :
>> --->
>> File upload
>>  If a request is of type multipart/form-data and if the servlet
>> handling
>> the
>>  request is annotated using the @MultipartConfig as defined in Section
>> 8.1.5,
>>  "@MultipartConfig" on page 8-64, the HttpServletRequest can make
>> available
>>  the various parts of the multipart request via the following methods
>> ■ public Collection  getParts()
>> ■ public Part getPart(String name).
>> <---
>> --->
>> @MultipartConfig
>>  This annotation, when specified on a Servlet, indicates that the
>> request it expects
>>  is of type mime/multipart. The HttpServletRequest object of the
>>  corresponding servlet MUST make available the mime attachments via
>> the
>>  getParts and getPart methods to iterate over the various mime
>> attachments.
>> <---
>>  I am just wondering that :
>>  a. Are those two methods available when the request is of
>> multipart/form-data type AND the servlet handlering it are configured with
>> MultipartConfig (annotation or configurations in web.xml) ? Why not make
>> those methods avaible once it detects the multipart/form-data type ?
>>  b. Are those two methods only available in Servlet ? Seems that the
>> spec expects the users handle the uploading in Servlet ?
>>  Thanks !
>>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


-- 
Ivan

Re: getPart()/getParts() invocation in the filter ?

[Ivan]

Thanks, Mark !

2010/5/13 Mark Thomas 

> On 13/05/2010 15:43, Ivan wrote:
>
>> Thanks, Mark.
>> OK,  turn to the user mail list.
>>  From the text I quoted from servlet spec, does it mean that I must
>> configured the target servlet with multipart (annotation or web.xml), or
>> those two getPart()/getParts() methods could not be used even the incoming
>> request is of mutlipart type?  Actually, I tried in the latest Tomcat 7,
>> it
>> seems to work in this way.
>>
>
> Correct. You *must* define the servlet as multipart in order to use the
> getPart()/getParts() methods.
>
> Mark
>
>
>
>> 2010/5/13 Mark Thomas
>>
>>  On 13/05/2010 03:00, Ivan wrote:
>>>
>>>  Hi,
>>>> While using the new features of getPart()/getParts() in the Servlet
>>>> 3.0,
>>>> I found that those methods could not be invoked in filter.
>>>>
>>>>
>>> The short answer is that this should work, even from a filter.
>>>
>>> The long answer is that this discussion belongs on the users list for
>>> now.
>>> If that discussion identifies a bug in the current Tomcat implementation
>>> then any discussion around fixing that belongs here.
>>>
>>> Mar
>>>
>>>
>>>  After checking the spec, I found some words below :
>>>
>>>> --->
>>>> File upload
>>>>  If a request is of type multipart/form-data and if the servlet
>>>> handling
>>>> the
>>>>  request is annotated using the @MultipartConfig as defined in
>>>> Section
>>>> 8.1.5,
>>>>  "@MultipartConfig" on page 8-64, the HttpServletRequest can make
>>>> available
>>>>  the various parts of the multipart request via the following
>>>> methods
>>>> ■ public Collection   getParts()
>>>> ■ public Part getPart(String name).
>>>> <---
>>>> --->
>>>> @MultipartConfig
>>>>  This annotation, when specified on a Servlet, indicates that the
>>>> request it expects
>>>>  is of type mime/multipart. The HttpServletRequest object of the
>>>>  corresponding servlet MUST make available the mime attachments via
>>>> the
>>>>  getParts and getPart methods to iterate over the various mime
>>>> attachments.
>>>> <---
>>>>  I am just wondering that :
>>>>  a. Are those two methods available when the request is of
>>>> multipart/form-data type AND the servlet handlering it are configured
>>>> with
>>>> MultipartConfig (annotation or configurations in web.xml) ? Why not make
>>>> those methods avaible once it detects the multipart/form-data type ?
>>>>  b. Are those two methods only available in Servlet ? Seems that the
>>>> spec expects the users handle the uploading in Servlet ?
>>>>  Thanks !
>>>>
>>>>
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>>
>>>
>>
>>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Ivan

Correct behavior while checking the thread binding in DirContextURLStreamHandler ?

[Ivan]

Hi, devs, in the get method of DirContextURLStreamHandler class, I saw the
codes below :
--->
public static DirContext get() {

DirContext result = null;

Thread currentThread = Thread.currentThread();
ClassLoader currentCL = currentThread.getContextClassLoader();

// Checking CL binding
result = clBindings.get(currentCL);
if (result != null)
return result;

// Checking thread biding
result = threadBindings.get(currentThread);
<-- Here, the value from threadBindings is always ignored ? is
there something like "if (result != null) return result;" required there ?

// Checking parent CL binding
currentCL = currentCL.getParent();
while (currentCL != null) {
result = clBindings.get(currentCL);
if (result != null)
return result;
currentCL = currentCL.getParent();
}

if (result == null)
throw new IllegalStateException("Illegal class loader binding");

return result;

}

-- 
Ivan

Re: Correct behavior while checking the thread binding in DirContextURLStreamHandler ?

[Ivan]

Yes, but guess that getParent() will not be null in most scenarios :-) And
if the thread binding value is expected to be returned while no classloader
binding, think the codes should be in the end of the method.

2012/1/28 Caldarale, Charles R 

> > From: Ivan [mailto:xhh...@gmail.com]
> > Subject: Correct behavior while checking the thread binding in
> DirContextURLStreamHandler ?
>
> > result = threadBindings.get(currentThread);
> > <-- Here, the value from threadBindings is always ignored ?
>
> No, it's not always ignored.  If
> currentThread.getContextClassLoader().getParent() is null, the value from
> ghreadBindings.get() will be returned.  Of course, I don't know if the
> getParent() call can ever return null; that might well depend on actions
> taken inside the webapp application code.
>
>  - 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 unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Ivan

Re: Correct behavior while checking the thread binding in DirContextURLStreamHandler ?

[Ivan]

So is the current behavior by design, or it is a defect ?

2012/1/28 Ivan 

> Yes, but guess that getParent() will not be null in most scenarios :-) And
> if the thread binding value is expected to be returned while no classloader
> binding, think the codes should be in the end of the method.
>
> 2012/1/28 Caldarale, Charles R 
>
> > From: Ivan [mailto:xhh...@gmail.com]
>> > Subject: Correct behavior while checking the thread binding in
>> DirContextURLStreamHandler ?
>>
>> > result = threadBindings.get(currentThread);
>> > <-- Here, the value from threadBindings is always ignored ?
>>
>> No, it's not always ignored.  If
>> currentThread.getContextClassLoader().getParent() is null, the value from
>> ghreadBindings.get() will be returned.  Of course, I don't know if the
>> getParent() call can ever return null; that might well depend on actions
>> taken inside the webapp application code.
>>
>>  - 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 unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
>
> --
> Ivan
>



-- 
Ivan

Re: Correct behavior while checking the thread binding in DirContextURLStreamHandler ?

[Ivan]

No sure whether I understood you clearly,  if a context is binding on the
current thread, and current context classloader has parent classloader,
current get method will throw an IllegalStateException. So my question is
that, in this scenario, should the context binded on the thread be ignored ?
I did not find too many comments on the svn log, while I guess that the
logic may be :
a. Check whether there is a context binding on the current context
classloader, if does, return it.
b. Check whether there is a context binding on the current thread, if does,
return it.
c. Check whether there is a context binding on the classloader tree of the
current context classloader, if does return it.
d. Throw an IllegalStateException.

2012/2/1 Christopher Schultz 

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Ivan,
>
> On 1/27/12 11:40 PM, Ivan wrote:
> > if (result != null) return result;
> >
> > // Checking thread biding result =
> > threadBindings.get(currentThread); <-- Here, the value
> > from threadBindings is always ignored ? is there something like "if
> > (result != null) return result;" required there ?
> >
> > // Checking parent CL binding currentCL = currentCL.getParent();
> > while (currentCL != null) { result = clBindings.get(currentCL); if
> > (result != null) return result; currentCL = currentCL.getParent();
> > }
> >
> > if (result == null) throw new IllegalStateException("Illegal class
> > loader binding");
> >
> > return result;
>
> That does look fishy.
>
> "result" will be ignored if currentCL.getParent returns non-null. If
> currentCL.getParent returns null, then the method throws an exception.
> It looks like this could be re-written in a more straightforward way
> like this:
>
>  currentCL = currentCL.getParent();
>  if(null == result && null == currentCL)
>throw new IllegalArgumentException(...);
>
>  while(currentCL != null)
>// continue
>
> Of course, you still need to check for null after the loop, so it's
> not like the change really affects anything other than minor readability.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk8oUbUACgkQ9CaO5/Lv0PDGvwCgkELv0wJaVlzVxJc+UkUxi+Vx
> 9vAAnAgQYg0loutHFkxYxEzoJFqZYb3I
> =e8sd
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Ivan

Make the bindThread/unbindThread method proected ?

[Ivan]

Hi,
In the latest Tomcat codes, I saw that a new thread is created for listener
start, filter start and loadOnStartup. But the two methods bindThread and
unbindThread is marked as private, how about making those methods protected
? So that other containers could use those two methods for their own
initialization works.
Thanks.

-- 
Ivan

Re: Make the bindThread/unbindThread method proected ?

[Ivan]

Thanks, an entry in bugzilla is created,
https://issues.apache.org/bugzilla/show_bug.cgi?id=50629

2011/1/21 Mark Thomas 

> On 21/01/2011 01:37, Ivan wrote:
> > Hi,
> > In the latest Tomcat codes, I saw that a new thread is created for
> listener
> > start, filter start and loadOnStartup. But the two methods bindThread and
> > unbindThread is marked as private, how about making those methods
> protected
> > ? So that other containers could use those two methods for their own
> > initialization works.
>
> Seems reasonable. Add an enhancement request to bugzilla so it doesn't
> get forgotten.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Ivan

FileDirContext returns the path directly without checking whether the target file really exists

[Ivan]

Hi,
Seems that the doGetRealPath method in the FileDirContext returns the
path directly without checking the target file or folder exists, so is it
expected or file checking is required ?
--->
@Override
protected String doGetRealPath(String path) {
File file = new File(getDocBase(), path);
return file.getAbsolutePath();
}
   <---
-- 
Ivan

Re: FileDirContext returns the path directly without checking whether the target file really exists

[Ivan]

I copied some words from the spec, the the second paragraph, it says
something about resources in the META-INF/resources directory, if we do not
need to care about whether the real file exists, I think we could never go
into this situation, we might always have a path in the default context.
right ?
--->
The getRealPath method takes a String argument and returns a String
representation of a file on the local file system to which a path
corresponds. The
getPathTranslated method computes the real path of the pathInfo of the
request.
In situations where the servlet container cannot determine a valid file path
for these
methods, such as when the Web application is executed from an archive, on a
remote
file system not accessible locally, or in a database, these methods must
return null.
Resources inside the META-INF/resources directory of JAR file must be
considered only if the container has unpacked them from their containing JAR
file
when a call to getRealPath() is made, and in this case MUST return the
unpacked
location.
<---

2010/7/28 Mark Thomas 

> On 26/07/2010 03:20, Ivan wrote:
> > Hi,
> > Seems that the doGetRealPath method in the FileDirContext returns the
> > path directly without checking the target file or folder exists, so is it
> > expected or file checking is required ?
>
> I don't see anything in the Servlet specification that says that the
> real path has to exist. Do you?
>
> Mark
>
> > --->
> > @Override
> > protected String doGetRealPath(String path) {
> > File file = new File(getDocBase(), path);
> > return file.getAbsolutePath();
> > }
> ><---
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Ivan

Re: FileDirContext returns the path directly without checking whether the target file really exists

[Ivan]

Yes, Caldarale, I do agree that in the spec, there is no word about whether
the file should exist (or I miss something anywhere ?), and the spec is
always ambigurous :-)
As I said in my last post, what makes me feel confusing is that, with
current implementation, we never have chance to consider the resources in
the META-INF/resources folder.

2010/7/28 Caldarale, Charles R 

> > From: Ivan [mailto:xhh...@gmail.com]
> > Subject: Re: FileDirContext returns the path directly without checking
> > whether the target file really exists
> >
> > I copied some words from the spec, the the second paragraph,
> > it says something about resources in the META-INF/resources
> > directory, if we do not need to care about whether the real
> > file exists, I think we could never go into this situation,
> > we might always have a path in the default context.
> > right ?
>
> No.  The resource may or may not exist completely independently of whether
> or not the webapp has some location in the file system; you're confusing the
> situations.  One can use getRealPath() to determine the path for a resource
> the webapp wants to /create/, not just one the webapp wants to read.  If you
> want to see if the path returned points to an existing file, there are ample
> APIs in the JRE to let you do so.
>
>  - 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 unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Ivan

Re: FileDirContext returns the path directly without checking whether the target file really exists

[Ivan]

Thanks, if possible, could you please show me where it is ? I am really
interested in those details :-)

2010/7/28 Mark Thomas 

> On 28/07/2010 03:12, Ivan wrote:
> > Yes, Caldarale, I do agree that in the spec, there is no word about
> whether
> > the file should exist (or I miss something anywhere ?), and the spec is
> > always ambigurous :-)
> > As I said in my last post, what makes me feel confusing is that, with
> > current implementation, we never have chance to consider the resources in
> > the META-INF/resources folder.
>
> That has already been taken care of but the time the code reaches this
> point.
>
> Mark
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Ivan

Re: FileDirContext returns the path directly without checking whether the target file really exists

[Ivan]

Thanks, Mark, if you mean the method getRealPath in BaseDirContext, I have
checked it.

--->
public String getRealPath(String name) {
if (!aliases.isEmpty()) {
AliasResult result = findAlias(name);
if (result.dirContext != null) {
return result.dirContext.doGetRealPath(result.aliasName);
}
}

// Next do a standard getRealPath()
String path = doGetRealPath(name); --> I think this invocation
will never return null in the FileDirContext implementation, right ? So does
it mean that if FileDirContext is used, no need to consider the resources in
the META-INF/resources embed in the jar files.

if (path != null)
return path;

// Check the alternate locations
for (DirContext altDirContext : altDirContexts) {
if (altDirContext instanceof BaseDirContext){
path = ((BaseDirContext) altDirContext).getRealPath(
"META-INF/resources/" + name);
if (path != null)
return path;
}
}

// Really not found
return null;
}
<---

2010/7/29 Mark Thomas 

> On 28/07/2010 14:11, Ivan wrote:
> > Thanks, if possible, could you please show me where it is ? I am really
> > interested in those details :-)
>
> BaseDirContext
>
> Mark
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Ivan

A typo error in WebRuleSet

[Ivan]

Hi,
It seems that there is one typo error on the line 523 of WebRuleSet
file, it should be
configureInjectionRules(digester, "web-app/ejb-local-ref/"); --->
configureInjectionRules(digester, "web-app/resource-env-ref/");
-- 
Ivan

Re: FileDirContext returns the path directly without checking whether the target file really exists

[Ivan]

Thanks, Mark.
So in other words, those descriptions in the spec for META-INF/resources
make no sense. right ?

2010/7/29 Mark Thomas 

> On 29/07/2010 01:45, Ivan wrote:
> > Thanks, Mark, if you mean the method getRealPath in BaseDirContext, I
> have
> > checked it.
> >
> > --->
> > public String getRealPath(String name) {
> > if (!aliases.isEmpty()) {
> > AliasResult result = findAlias(name);
> > if (result.dirContext != null) {
> > return result.dirContext.doGetRealPath(result.aliasName);
> > }
> > }
> >
> > // Next do a standard getRealPath()
> > String path = doGetRealPath(name); --> I think this
> invocation
> > will never return null in the FileDirContext implementation, right ? So
> does
> > it mean that if FileDirContext is used, no need to consider the resources
> in
> > the META-INF/resources embed in the jar files.
>
> Correct. I think the check of META-INF/resourcs below could be removed.
>
> Mark
>
> >
> > if (path != null)
> > return path;
> >
> > // Check the alternate locations
> > for (DirContext altDirContext : altDirContexts) {
> > if (altDirContext instanceof BaseDirContext){
> > path = ((BaseDirContext) altDirContext).getRealPath(
> > "META-INF/resources/" + name);
> > if (path != null)
> > return path;
> > }
> > }
> >
> > // Really not found
> > return null;
> > }
> > <---
> >
> > 2010/7/29 Mark Thomas 
> >
> >> On 28/07/2010 14:11, Ivan wrote:
> >>> Thanks, if possible, could you please show me where it is ? I am really
> >>> interested in those details :-)
> >>
> >> BaseDirContext
> >>
> >> Mark
> >>
> >>
> >>
> >> -----
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
> >
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Ivan

Re: FileDirContext returns the path directly without checking whether the target file really exists

[Ivan]

The below description from the spec says that resources inside the
META-INF/resources directory of JAR files might be consider only if the
container has unpacked them.
Since the getRealPath is used to return a virtual path, when will the
unpackaged location of resources directory be considered ? Only when the war
package is not unpacked, but the META-INF/resources directory are extracted
?
Thanks !
--->
Resources inside the META-INF/resources directory of JAR file must be
considered only if the container has unpacked them from their containing JAR
file
when a call to getRealPath() is made, and in this case MUST return the
unpacked
location.
<---

2010/7/29 Mark Thomas 

> On 29/07/2010 09:08, Ivan wrote:
> > Thanks, Mark.
> > So in other words, those descriptions in the spec for META-INF/resources
> > make no sense. right ?
>
> Not sure what you mean. I don't see any issues with the spec. I do think
> the implementation does something that is guaranteed to never succeed.
> The resource JARs never get expanded so getRealPath() will always return
> null - there is no point checking.
>
> Mark
>
> >
> > 2010/7/29 Mark Thomas 
> >
> >> On 29/07/2010 01:45, Ivan wrote:
> >>> Thanks, Mark, if you mean the method getRealPath in BaseDirContext, I
> >> have
> >>> checked it.
> >>>
> >>> --->
> >>> public String getRealPath(String name) {
> >>> if (!aliases.isEmpty()) {
> >>> AliasResult result = findAlias(name);
> >>> if (result.dirContext != null) {
> >>> return
> result.dirContext.doGetRealPath(result.aliasName);
> >>> }
> >>> }
> >>>
> >>> // Next do a standard getRealPath()
> >>> String path = doGetRealPath(name); --> I think this
> >> invocation
> >>> will never return null in the FileDirContext implementation, right ? So
> >> does
> >>> it mean that if FileDirContext is used, no need to consider the
> resources
> >> in
> >>> the META-INF/resources embed in the jar files.
> >>
> >> Correct. I think the check of META-INF/resourcs below could be removed.
> >>
> >> Mark
> >>
> >>>
> >>> if (path != null)
> >>> return path;
> >>>
> >>> // Check the alternate locations
> >>> for (DirContext altDirContext : altDirContexts) {
> >>> if (altDirContext instanceof BaseDirContext){
> >>> path = ((BaseDirContext) altDirContext).getRealPath(
> >>> "META-INF/resources/" + name);
> >>> if (path != null)
> >>> return path;
> >>> }
> >>> }
> >>>
> >>> // Really not found
> >>> return null;
> >>> }
> >>> <---
> >>>
> >>> 2010/7/29 Mark Thomas 
> >>>
> >>>> On 28/07/2010 14:11, Ivan wrote:
> >>>>> Thanks, if possible, could you please show me where it is ? I am
> really
> >>>>> interested in those details :-)
> >>>>
> >>>> BaseDirContext
> >>>>
> >>>> Mark
> >>>>
> >>>>
> >>>>
> >>>> -
> >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >>>> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
> >
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Ivan

use of default-content-type

[Ivan]

Hi, if default-content-type is configured in the web.xml, and in the jsp
file, a differernt content-type is configured, then an exception below is
thrown.
>From the description of the default-content-type, it should take effect
while no content-type is configured in the jsp file, and it should be
allowed to define a different content-type.
Any comment ?

org.apache.jasper.JasperException: /defaultCtype/page1.jsp(17,1) Page
directive: illegal to have multiple occurrences of contentType with
different values (old: text/xml, new: text/html)

org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)

org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:407)

org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:236)

org.apache.jasper.compiler.Validator$DirectiveVisitor.visit(Validator.java:133)
org.apache.jasper.compiler.Node$PageDirective.accept(Node.java:590)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2376)
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2428)
org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2434)
org.apache.jasper.compiler.Node$Root.accept(Node.java:475)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2376)

org.apache.jasper.compiler.Validator.validateDirectives(Validator.java:1733)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:195)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:360)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:340)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:327)

org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:594)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:314)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)


-- 
Ivan

Re: use of default-content-type

[Ivan]

No, it is just a simple jsp file.
I guess that current codes could not handle the default-content-type and the
scenario you mentioned, it seems that it configured the value of
default-content-type to the content-type attribute while constructing the
PageInfo instance.

2010/7/30 LiuYan 刘研 

>
> Just a guess, does page1.jsp include another page2.jsp and page2.jsp does
> not
> specify content-type(which will be default-content-type)?
>
>
> Ivan Xu wrote:
> >
> > Hi, if default-content-type is configured in the web.xml, and in the jsp
> > file, a differernt content-type is configured, then an exception below is
> > thrown.
> > From the description of the default-content-type, it should take effect
> > while no content-type is configured in the jsp file, and it should be
> > allowed to define a different content-type.
> > Any comment ?
> >
> > org.apache.jasper.JasperException: /defaultCtype/page1.jsp(17,1) Page
> > directive: illegal to have multiple occurrences of contentType with
> > different values (old: text/xml, new: text/html)
> >
> >
> org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> >
> >
> org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:407)
> >
> >
> org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:236)
> >
> >
> org.apache.jasper.compiler.Validator$DirectiveVisitor.visit(Validator.java:133)
> > org.apache.jasper.compiler.Node$PageDirective.accept(Node.java:590)
> > org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2376)
> > org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2428)
> > org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2434)
> > org.apache.jasper.compiler.Node$Root.accept(Node.java:475)
> > org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2376)
> >
> >
> org.apache.jasper.compiler.Validator.validateDirectives(Validator.java:1733)
> > org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:195)
> > org.apache.jasper.compiler.Compiler.compile(Compiler.java:360)
> > org.apache.jasper.compiler.Compiler.compile(Compiler.java:340)
> > org.apache.jasper.compiler.Compiler.compile(Compiler.java:327)
> >
> >
> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:594)
> >
> >
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:314)
> >
> > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
> > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265)
> > javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> >
> >
> > --
> > Ivan
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/use-of-default-content-type-tp29303906p29304084.html
> Sent from the Tomcat - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Ivan

Re: use of default-content-type

[Ivan]

Tomcat 7

2010/7/30 Mark Thomas 

> On 30/07/2010 09:32, Ivan wrote:
> > Hi, if default-content-type is configured in the web.xml, and in the jsp
> > file, a differernt content-type is configured, then an exception below is
> > thrown.
> > From the description of the default-content-type, it should take effect
> > while no content-type is configured in the jsp file, and it should be
> > allowed to define a different content-type.
> > Any comment ?
>
> Tomcat version?
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Ivan

Re: use of default-content-type

[Ivan]

Any comment ?
Thanks !

2010/7/30 Ivan 

> Tomcat 7
>
> 2010/7/30 Mark Thomas 
>
> On 30/07/2010 09:32, Ivan wrote:
>> > Hi, if default-content-type is configured in the web.xml, and in the jsp
>> > file, a differernt content-type is configured, then an exception below
>> is
>> > thrown.
>> > From the description of the default-content-type, it should take effect
>> > while no content-type is configured in the jsp file, and it should be
>> > allowed to define a different content-type.
>> > Any comment ?
>>
>> Tomcat version?
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
>
> --
> Ivan
>



-- 
Ivan

Recursive dependency between the tomcat-catalina-ha and tomcat-catalina

[Ivan]

Hi,
From the pom file of tomcat-catalina-ha, it depends on the
tomcat-catalina. But one class HTMLManagerServlet in the tomcat-catalina has
a reference to a class BackupManager in the tomcat-catalina-ha.  Is there a
way to remove the recursive dependency between those two components ?
By the way, there mightbe a NullPointerException issue while using the
BackupManager in the HTMLManagerServlet.
---> line.523
 Manager manager = ctxt.getManager();
if (manager instanceof BackupManager && showProxySessions) {
args[5] = new Integer(

((BackupManager)manager).getActiveSessionsFull());
} else if (ctxt.getManager() != null){
args[5] = new Integer(manager.getActiveSessions());
} else {
args[5] = new Integer(0);
}
<---
 thanks.

-- 
Ivan

Re: Recursive dependency between the tomcat-catalina-ha and tomcat-catalina

[Ivan]

2010/10/21 Mark Thomas 

> On 20/10/2010 21:39, Ivan wrote:
> > Hi,
> > From the pom file of tomcat-catalina-ha, it depends on the
> > tomcat-catalina. But one class HTMLManagerServlet in the tomcat-catalina
> has
> > a reference to a class BackupManager in the tomcat-catalina-ha.  Is there
> a
> > way to remove the recursive dependency between those two components ?
> Yes. Ugly, but possible.
>

   Could you please show the way, and do the devs plan to work on it ?
Thanks.

>
> > By the way, there mightbe a NullPointerException issue while using
> the
> > BackupManager in the HTMLManagerServlet.
>
> Really? Where?
>
>
   Sorry, please ignore it.


> Mark
>
> > ---> line.523
> >  Manager manager = ctxt.getManager();
> > if (manager instanceof BackupManager &&
> showProxySessions) {
> > args[5] = new Integer(
> >
> > ((BackupManager)manager).getActiveSessionsFull());
> > } else if (ctxt.getManager() != null){
> > args[5] = new Integer(manager.getActiveSessions());
> > } else {
> > args[5] = new Integer(0);
> > }
> > <---
> >  thanks.
> >
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Ivan

destory method is called twice while the child is destoryed directly

[Ivan]

Hi,
While calling the method destory() on the StandardContext directly, it
seems that the method destoryInternal() is called twice in the
LifecycleMBeanBase, the two stacktraces are below :
a.  LifecycleMBeanBase.unregister(ObjectName) line: 191
 LifecycleMBeanBase.destroyInternal() line: 73
 ContainerBase.destroyInternal() line: 1109
 StandardContext.destroyInternal() line: 5114
 LifecycleBase.destroy() line: 271
 ContainerBase.removeChild(Container) line: 963
 ContainerBase.destroyInternal() line: 1106
 StandardContext.destroyInternal() line: 5114
 LifecycleBase.destroy() line: 271
 ...
 b. LifecycleMBeanBase.unregister(ObjectName) line: 191
 LifecycleMBeanBase.destroyInternal() line: 73
 ContainerBase.destroyInternal() line: 1109
 StandardContext.destroyInternal() line: 5114
 LifecycleBase.destroy() line: 271
 ...

 So is it by desgin or some code changes might be needed ? Thanks.

-- 
Ivan

Re: destory method is called twice while the child is destoryed directly

[Ivan]

Thanks for clarifying it, does the devs have plan for it ? Hope it could be
fixed soon.

2010/10/27 Mark Thomas 

> On 27/10/2010 06:43, Ivan wrote:
> > Hi,
> > While calling the method destory() on the StandardContext directly,
> it
> > seems that the method destoryInternal() is called twice in the
> > LifecycleMBeanBase, the two stacktraces are below :
> > a.  LifecycleMBeanBase.unregister(ObjectName) line: 191
> >  LifecycleMBeanBase.destroyInternal() line: 73
> >  ContainerBase.destroyInternal() line: 1109
> >  StandardContext.destroyInternal() line: 5114
> >  LifecycleBase.destroy() line: 271
> >  ContainerBase.removeChild(Container) line: 963
> >  ContainerBase.destroyInternal() line: 1106
> >  StandardContext.destroyInternal() line: 5114
> >  LifecycleBase.destroy() line: 271
> >  ...
> >  b. LifecycleMBeanBase.unregister(ObjectName) line: 191
> >  LifecycleMBeanBase.destroyInternal() line: 73
> >  ContainerBase.destroyInternal() line: 1109
> >  StandardContext.destroyInternal() line: 5114
> >  LifecycleBase.destroy() line: 271
> >  ...
> >
> >  So is it by desgin or some code changes might be needed ? Thanks.
>
> It is a bug - a side effect of the Lifecycle clean-up in Tomcat 7. BTW,
> mentioning which version you are using would be a big help.
>
> Mark
>
> -----
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Ivan

Re: destory method is called twice while the child is destoryed directly

[Ivan]

Thanks for clarifying it, so do the devs have plan for it ?
Hope it could be fixed soon.

2010/10/27 Mark Thomas 

> On 27/10/2010 06:43, Ivan wrote:
> > Hi,
> > While calling the method destory() on the StandardContext directly,
> it
> > seems that the method destoryInternal() is called twice in the
> > LifecycleMBeanBase, the two stacktraces are below :
> > a.  LifecycleMBeanBase.unregister(ObjectName) line: 191
> >  LifecycleMBeanBase.destroyInternal() line: 73
> >  ContainerBase.destroyInternal() line: 1109
> >  StandardContext.destroyInternal() line: 5114
> >  LifecycleBase.destroy() line: 271
> >  ContainerBase.removeChild(Container) line: 963
> >  ContainerBase.destroyInternal() line: 1106
> >  StandardContext.destroyInternal() line: 5114
> >  LifecycleBase.destroy() line: 271
> >  ...
> >  b. LifecycleMBeanBase.unregister(ObjectName) line: 191
> >  LifecycleMBeanBase.destroyInternal() line: 73
> >  ContainerBase.destroyInternal() line: 1109
> >  StandardContext.destroyInternal() line: 5114
> >  LifecycleBase.destroy() line: 271
> >  ...
> >
> >  So is it by desgin or some code changes might be needed ? Thanks.
>
> It is a bug - a side effect of the Lifecycle clean-up in Tomcat 7. BTW,
> mentioning which version you are using would be a big help.
>
> Mark
>
> -----
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Ivan

Re: destory method is called twice while the child is destoryed directly

[Ivan]

Yes, I am using 7.0.4. Will create a entry in the bugzila system
Thanks.

2010/10/28 Mark Thomas 

> On 28/10/2010 02:20, Ivan wrote:
> > Thanks for clarifying it, so do the devs have plan for it ?
>
> Yes. What? Fix it. When? TBD.
>
> Creating a bugzilla entry will ensure it doesn't get forgotten.
>
> I see you still haven't told us which version you are using. I assume
> you've tested 7.0.4.
>
> Mark
>
> > Hope it could be fixed soon.
> >
> > 2010/10/27 Mark Thomas 
> >
> >> On 27/10/2010 06:43, Ivan wrote:
> >>> Hi,
> >>> While calling the method destory() on the StandardContext directly,
> >> it
> >>> seems that the method destoryInternal() is called twice in the
> >>> LifecycleMBeanBase, the two stacktraces are below :
> >>> a.  LifecycleMBeanBase.unregister(ObjectName) line: 191
> >>>  LifecycleMBeanBase.destroyInternal() line: 73
> >>>  ContainerBase.destroyInternal() line: 1109
> >>>  StandardContext.destroyInternal() line: 5114
> >>>  LifecycleBase.destroy() line: 271
> >>>  ContainerBase.removeChild(Container) line: 963
> >>>  ContainerBase.destroyInternal() line: 1106
> >>>  StandardContext.destroyInternal() line: 5114
> >>>  LifecycleBase.destroy() line: 271
> >>>  ...
> >>>  b. LifecycleMBeanBase.unregister(ObjectName) line: 191
> >>>  LifecycleMBeanBase.destroyInternal() line: 73
> >>>  ContainerBase.destroyInternal() line: 1109
> >>>  StandardContext.destroyInternal() line: 5114
> >>>  LifecycleBase.destroy() line: 271
> >>>  ...
> >>>
> >>>  So is it by desgin or some code changes might be needed ? Thanks.
> >>
> >> It is a bug - a side effect of the Lifecycle clean-up in Tomcat 7. BTW,
> >> mentioning which version you are using would be a big help.
> >>
> >> Mark
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
> >
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Ivan

Can Tomcat dump incoming/outgoing HTTP data?

[Ivan Balashov]

Hi all,

I need to monitor HTTP traffic going to/from my web application. Normally I
would use Ethereal, but unfortunately, it doesn't support localhost on
windows. Could I setup tomcat so that (or maybe write my own filter) it would
dump all incoming/outgoing HTTP data to a file?

Thanks!


smime.p7s
Description: S/MIME cryptographic signature

RE: How to disable PUT and DELETE methods in Tomcat 4.1.27?

[Ivan Balashov]

I guess those methods are left to be implemented e.g. by Webdav servlets,
and while no implementation is present they simply return access error.

-Original Message-
From: Emre Ersoz [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 06, 2006 1:53 PM
To: Tomcat Users List
Subject: Re: How to disable PUT and DELETE methods in Tomcat 4.1.27?

added below lines to web.xml:


readonly
true


but actually i see no difference:

DELETE /tcell-um-cc-portal/a HTTP/1.0

HTTP/1.1 403 Forbidden
Content-Type: text/html;charset=ISO-8859-9
Content-Language: tr
Date: Wed, 06 Sep 2006 12:48:33 GMT
Server: Apache Coyote/1.0
Connection: close

Apache Tomcat/4.1.27 - Error
report HTTP Status 403
- type Status reportmessage
descripti
on Access to the specified resource () has been forbidden.Apache Tomcat/4.1.27

I see access error but DELETE seems to be not disabled. wht do you think?

thx,

EE
On 9/6/06, Mark Thomas <[EMAIL PROTECTED]> wrote:
>
> Emre Ersoz wrote:
> > Dear
> > Is this context "read only", so HTTP commands like PUT and DELETE are
> > rejected? [true]
> >
> > What about 4.1.X ? Do we have solution?
>
> Yes. The same one. Take a look at conf/web.xml
>
> Mark
>
>


smime.p7s
Description: S/MIME cryptographic signature

RE: How set a default context

[Ivan Balashov]

But that means the context of application will change, as opposed to making
it default. I'm not sure if this change is harmful to the application, but
if it uses e.g. context name for some reason it might be failing.

-Ivan

-Original Message-
From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 26, 2006 1:38 AM
To: Tomcat Users List
Subject: RE: How set a default context

> From: Gabriel França Campolina [mailto:[EMAIL PROTECTED] 
> Subject: How set a default context
> 
> but I need set the default context (http://localhost:8080)
> that call the /portal context

Delete the existing webapps/ROOT directory, and rename your portal app to
ROOT in the webapps directory.  It can be either ROOT.war or the ROOT
subdirectory.

 - 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]


smime.p7s
Description: S/MIME cryptographic signature

RE: How set a default context

[Ivan Balashov]

I think it should be configurable from somewhere. Moving directories or
writing some custom apps for this IMHo is not quite right.

-Ivan

-Original Message-
From: Mark Thomas [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 26, 2006 11:54 AM
To: Tomcat Users List
Subject: Re: How set a default context

Ivan Balashov wrote:
> But that means the context of application will change, as opposed to
making
> it default. I'm not sure if this change is harmful to the application, but
> if it uses e.g. context name for some reason it might be failing.
> 
> -Ivan

If this is the case then you have a badly written application. In the
short term you can try putting a simple ROOT app that just redirects
to your app .

Mark

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


smime.p7s
Description: S/MIME cryptographic signature

tomcat and naming-common.jar problem.

[Ivan Gonzalez]

Hello everyone!


I have my server using tomcat 6.0.16 and apache 2.2.3 on CentOS 5.1 

When i try to display the content of my page the only thing i get is a blank 
page but when i delete naming-common.jar and restart the tomcat service it 
works great (display all the content of my page).

Does anyone know what's wrong? 

Is it a good idea to remove naming-common.jar and work without it?


Hope somebody help me.

Regards
Ivan.



  

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

Tomcat seems not to send the complete response until it receives an ACK

[Ivan Neto]

Hi,

I'm facing some performance issues with Tomcat. I've deployed a very simple
Web service on Tomcat, and when I call an operation of this Web service, the
HTTP response is fragmented into many TCP segments. This sounds normal,
since the HTTP response is transmitted with the "chunked" transfer coding
(the response is fragmented even though it would fit in just one TCP
segment).

When the HTTP response is split, Tomcat sends just the HTTP header and the
beginning of the response content to the client. It only sends the remaining
parts of the content when the client sends an ACK acknowledging that the
first segments where received correctly. Due the delayed ACK implementation
on Linux, the client will delay the ACK for a quite long period of time.
This causes a long pause in the communication, increasing significantly (up
to 400%) the round trip time for Web service calls.

Here are the TCP segments involved in a HTTP request to a Web service (Time
was 0.0 at the beginning of the segment capture):

Time (absolute)  Direction
Content
0.155986000  client > Tomcat   HTTP
request header
0.156014000  client > Tomcat   HTTP
request body (SOAP envelope)
0.160224000  Tomcat > client   HTTP
response header
0.160255000  Tomcat > client   HTTP
response body (part 1)
0.160265000  Tomcat > client   HTTP
response body (part 2)
0.160276000  Tomcat > client   HTTP
response body (part 3)
0.199794000  client > Tomcat   TCP ACK
0.199817000  Tomcat > client   HTTP
response body (part 4, the last one)
0.202165000  client > Tomcat   TCP ACK

As the data above show, Tomcat doesn't send the last part of the response
until it receives an ACK from the client. And the client delays a lot
(almost 40ms) before sending the (first) ACK. One option to solve this
problem would be to turn off the delayed ACK on the client. Although, as far
as I'm concerned, this is not possible in Linux. I've tried setting
tcpNoDelay="true" on Tomcat, but the problem still persists. Even with
tcpNoDelay enabled, Tomcat still doesn't send the last part of the message
before receiving the ACK.

Is there any way to force Tomcat not to wait the ACK from the client to send
the last part of a HTTP response?

Thanks in advance,

--
Ivan Neto

Re: How to detect database for Tomcat JDBC Realm is down

[Ivan Cheung]

Hi,

>
> I am building a web app and was able to setup digest authentication
>
> I am testing the app when I take the database that contains the username
> password down
>
> The tomcat log file show this
>
> java.sql.SQLException: No operations allowed after connection closed.
> at com.mysql.jdbc.Connection.checkClosed(Connection.java:2647)
> at com.mysql.jdbc.Connection.commit(Connection.java:1039)
> at org.apache.catalina.realm.JDBCRealm.getPassword(JDBCRealm.java:563)
> at org.apache.catalina.realm.RealmBase.getDigest(RealmBase.java:1091)
>
> I have setup the WEB-INF/web.xml to trap this error to show a custom error
> page
>
>   
> java.sql.SQLException
> /server_rdbms_error.html
>   
>
> however tomcat is not showing the custom error page and it keep popping
> the login page over and over again.
>
> I was wondering if someone can tell me what is the proper way to setup the
> custom error page when the database is down and authentication fail.
>
> Please reply to me direct since I am not on the alias.
>
> Thanks,
> Ivan
>

How to detect the database for JDBC Realm is down

[Ivan Cheung]

Hi,

I am building a web app and have setup digest authentication

I am testing the app when I take the database that contains the username
password down

The tomcat log file show this

(http-8443-Processor25) org.apache.catalina.core.ContainerBase.[Catalina]:
Exception performing authentication {
java.sql.SQLException: No operations allowed after connection closed.
at com.mysql.jdbc.Connection.checkClosed(Connection.java:2647)
at com.mysql.jdbc.Connection.commit(Connection.java:1039)
at org.apache.catalina.realm.JDBCRealm.getPassword(JDBCRealm.java:563)
at org.apache.catalina.realm.RealmBase.getDigest(RealmBase.java:1091)

I have setup the WEB-INF/web.xml to trap this exception to show a custom
error page

  
java.sql.SQLException
/server_rdbms_error.html
  

however tomcat is not showing the custom error page and it keep popping up
the login page over and over again.

I was wondering if someone can tell me what is the proper way to setup the
custom error page when the database is down and authentication fail.

Thanks,
Ivan

Re: How to detect the database for JDBC Realm is down

[Ivan Cheung]

reposting to see if I have better luck this time.

On Fri, Apr 18, 2008 at 8:53 AM, Ivan Cheung <[EMAIL PROTECTED]> wrote:

> Hi,
>
> I am building a web app and have setup digest authentication
>
> I am testing the app when I take the database that contains the username
> password down
>
> The tomcat log file show this
>
> (http-8443-Processor25) org.apache.catalina.core.ContainerBase.[Catalina]:
> Exception performing authentication {
> java.sql.SQLException: No operations allowed after connection closed.
> at com.mysql.jdbc.Connection.checkClosed(Connection.java:2647)
> at com.mysql.jdbc.Connection.commit(Connection.java:1039)
> at org.apache.catalina.realm.JDBCRealm.getPassword(JDBCRealm.java:563)
> at org.apache.catalina.realm.RealmBase.getDigest(RealmBase.java:1091)
>
> I have setup the WEB-INF/web.xml to trap this exception to show a custom
> error page
>
>   
> java.sql.SQLException
> /server_rdbms_error.html
>   
>
> however tomcat is not showing the custom error page and it keep popping up
> the login page over and over again.
>
> I was wondering if someone can tell me what is the proper way to setup the
> custom error page when the database is down and authentication fail.
>
> Thanks,
> Ivan
>

custom JDBCRealm in Tomcat 5.5

[Ivan Cheung]

Hi,

I have trying to do some custom authentication

I have written myRealm to extend JDBCRealm

modify server.xml

Hand Authentication to Apache

[Ivan Eulaers]

I have set up a basic "extranet" where clients can browse directories and view 
the files in those directories. Access is handled by basic authentication of 
Apache. In the directories that are open for a specific client I've created a 
.htaccess file (see example below).

Today, Tomcat has been installed on my server. When I now want to access those 
secured directories, I get an error by Tomcat "The requested resource is not 
available". How can I repair this?

I've tried adding tomcatAuthentication="false" to  and restarted Tomcat, but this was not the solution.

Users should be able to browse certain subdirectories as follow:
- User A, B, C should be able to access https://www.../extranet/client1/ and 
its subdirectories
- User A, D, E, F should be able to access https://www.../extranet/client2/ and 
its subdirectories

.htaccess-listing
=

# STRONG HTACCESS PROTECTION

 order allow,deny
 deny from all


# REDIRECT http REQUESTS TO https, BUT AVOID ASKING TWICE FOR PASSWORD
SSLRequireSSL
ErrorDocument 403 https://www.pensionarchitects.be/extranet/docs

AuthType Basic
AuthName "Extranet"
AuthBasicProvider file
AuthUserFile 
Require valid-user

Options +Indexes
  # SET INDEX OPTIONS
  IndexOptions IgnoreCase FancyIndexing FoldersFirst NameWidth=50 
DescriptionWidth=* SuppressHTMLPreamble SuppressLastModified
  
  # SET DISPLAY ORDER
  IndexOrderDefault Descending Name
  
  HeaderName /extranet/header.html
  ReadmeName /extranet/footer.html



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Hand Authentication to Apache

[Ivan Eulaers]

Tomcat 6 has been installed by my hosting provider, and I don't know how it is 
connected to Apache. I'm not a technical expert, and I'm only looking for a 
solution.

This is my server.xml



















www.pa.be


--- On Tue, 11/10/09, Christopher Schultz  wrote:

> From: Christopher Schultz 
> Subject: Re: Hand Authentication to Apache
> To: "Tomcat Users List" 
> Date: Tuesday, November 10, 2009, 9:15 PM
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Ivan,
> 
> On 11/10/2009 2:26 PM, Ivan Eulaers wrote:
> > Today, Tomcat has been installed on my server. When I
> now want to access those secured directories, I get an error
> by Tomcat "The requested resource is not available". How can
> I repair this?
> 
> Are you trying to replace Apache httpd with Tomcat? If so,
> Tomcat
> doesn't support .htaccess files.
> 
> > I've tried adding tomcatAuthentication="false" to
>  > port="21309" protocol="AJP/1.3" /> and restarted
> Tomcat, but this was
> > not the solution.
> 
> tomcatAuthentication="false" will allow any authentication
> information
> from Apache httpd to flow into Tomcat, but you still have
> to configure
> access appropriately based upon roles.
> 
> > Users should be able to browse certain subdirectories
> as follow:
> > - User A, B, C should be able to access https://www.../extranet/client1/ 
> > and its
> subdirectories
> > - User A, D, E, F should be able to access https://www.../extranet/client2/ 
> > and its
> subdirectories
> > 
> > .htaccess-listing
> > =
> > 
> > # STRONG HTACCESS PROTECTION
> > 
> 
> What, no access to .../.htable files?
> 
> It's tough to guess what is being forwarded to Tomcat. Can
> you show us
> your JkMount or  directives that you have
> configured?
> 
> Also, please provide a specific example of a URL that fails
> to load
> properly, what the error is, and what you expected to
> happen.
> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkr5yfYACgkQ9CaO5/Lv0PDPLACeIP2nLA8U8yB2W8BH1rkbswZx
> gYkAnR3q1h80kufY3dZx1dFaCTuXKig/
> =yloJ
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

listing directory content outside tomcat root

[Ivan Longhi]

hi,
I would like to list the content of a directory outside tomcat root
without enabling the listings parameter in default servlet.

conf/web.xml


default

org.apache.catalina.servlets.DefaultServlet

listings
false




conf/server.xml

.

  





..


if I try to get a file inside the dir it works (
http://localhost:8080/test/some_file.txt ) but if I try to list the
content of the directory ( http://localhost:8080/test/ ) I get 404.

any idea?

thanks



ciao,
ivan

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: listing directory content outside tomcat root

[Ivan Longhi]

thanks!!!

this should be the solution (and one more little question at the end of code):

conf/web.xml

   
   default
   
org.apache.catalina.servlets.DefaultServlet
   
   listings
   false 
   
   


conf/server.xml

.

 

   
   
   

..


/path_to_some_dir/WEB-INF/web.xml




test

org.apache.catalina.servlets.DefaultServlet

listings
true

1


test
/





is org.apache.catalina.servlets.DefaultServlet
the right solution?

thanks,
ivan

On Thu, Feb 25, 2010 at 1:19 PM, Tim Funk  wrote:
> Enable listings is "sort of"** a global setting.
>
> Since the default servlet is declared in conf/web.xml - its inherited in
> *every* webapp. So its config is also inherited. (Bummer)
>
> BUT - if you add a WEB-INF/web.xml to EVERY webapp with the default servlet
> settings - then you can remove the default servlet config from conf/web.xml
> and have the default servlet per webapp config.
>
> That means - in docBase="/path_to_some_dir/" --> you need
> /path_to_some_dir/WEB-INF/web.xml
>
> What I forget is - what happens if you only create
> /path_to_some_dir/WEB-INF/web.xml and leave conf/web.xml alone. Which of
> course would be the easiest thing to do.
>
>
> -Tim
>
> On 2/25/2010 6:22 AM, Ivan Longhi wrote:
>>
>> hi,
>> I would like to list the content of a directory outside tomcat root
>> without enabling the listings parameter in default servlet.
>>
>> conf/web.xml
>> 
>>     
>>         default
>>
>> org.apache.catalina.servlets.DefaultServlet
>>         
>>             listings
>>             false
>>         
>>     
>> 
>>
>> conf/server.xml
>> 
>> .
>>
>>       >             unpackWARs="true" autoDeploy="true"
>>             xmlValidation="false" xmlNamespaceAware="false">
>>
>>         
>>             
>>         
>>
>> ..
>> 
>>
>> if I try to get a file inside the dir it works (
>> http://localhost:8080/test/some_file.txt ) but if I try to list the
>> content of the directory ( http://localhost:8080/test/ ) I get 404.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>



-- 
ciao,
ivan

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: listing directory content outside tomcat root

[Ivan Longhi]

ops
 is useless

On Thu, Feb 25, 2010 at 3:14 PM, Ivan Longhi  wrote:
>       
>           
>       

-- 
ciao,
ivan

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: listing directory content outside tomcat root

[Ivan Longhi]

hi christopher,

On Thu, Feb 25, 2010 at 9:33 PM, Christopher Schultz
 wrote:
> You shouldn't declare  elements within conf/server.xml in any
> currently-supported version of Tomcat. Instead, put everything you need
> in your webapp's META-INF/context.xml file. Remember that "path" and
> "docBase" parameters are not allowed.

ok, but since /path_to_some_dir/ is outside tomcat root (
$CATALINA_HOME ), how can I tell tomcat to look for
/path_to_some_dir/META-INF/context.xml file?

-- 
ciao,
ivan

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

POST request hangs hup

[Ivan Longhi]

Hi,
I'm running tomcat 6.0.18 with java 1.6.0_13 on a linux box.
The only webapp deployed is Sun OpenSSO (http://www.opensso.org) built from
source (20090930).
Sometimes a tomcat thread hangs hup while serving a POST request
(/UI/Login): monitoring tomcat
status I see the processing time grows and the thread never ends. When this
happens I am not able to shutdown
tomcat with shutdown.sh and I need to kill -9 the java process.
I think it is not a problem of memory exausted because if I run "top" the
memory usage by java process
is ok (a few hundreds MB despite CATALINA_OPTS="-Xmx6048M") but the cpu
usage is 100%.
Is there a way to kill a single thread in tomcat whitout restarting it?
Is there a way to limit the max execution time for a single thread/request?

thanks,
ivan

-- 
ciao,
ivan

Re: Tomcat 7, JAX-WS 2.2.5

[Ivan Larionov]

Hi Konstantin,

Thank you for your reply.

Please see inline below.

On 17.11.2011 11:57, Konstantin Kolinko wrote:

2011/11/14 Ivan:

Dear All,

We are running JAX-WS web-services using JAX-WS RI under tomcat. First we
upgraded from Tomcat 5.5 to Tomcat 7 and everything was fine. Eventually, we
decided to upgrade to the latest JAX-WS RI and went for 2.2.5 version.

We faced a problem. Upon requests we started seeing exceptions from JAX-WS
indicating that the body of the request was broken. From the point of view of
TCPMON everything was fine. We enabled request tracing and saw that the JAX-WS
RI was gettting empty requests' input streams which were causing mentioned
exceptions (org.jvnet.mimepull.MIMEParsingException: Missing start boundary;
com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog).

Also, we tried tomcat 5.5 and JAX-WS RI 2.2.5 and they worked together fine.

After investigation we found out that all versions of JAX-WS RI since 2.2.2 were
causing the same problem. Presumably, the cause of the issue is servlet 3.0
async request processing which has been added in JAX-WS RI 2.2.2. Partly, it
explains why tomcat 5.5 works fine with JAX-WS RI 2.2.5 as the RI falls back to
non-async request processing.

We changed connector's protocol to 'org.apache.coyote.http11.Http11NioProtocol'
and everything started working.

As I understand, both BIO and NIO connectors should be working well with servet
3.0 async. Could you comment on this?



1. What exact version of Tomcat 7.0.x ?

Tomcat 7.0.14


2. Yes, both should be working, though implementations are
substantially different.

I would expect Nio to be better with async handling iт terms of performance.

3. Bugs might be there, but without a specific test case there is
nowhere to start.
Currently, I cannot provide a test case. The problem manifests itself 
somewhere in the JAX-WS RI execution path, not in our code. I believe 
our management will settle for just disabling async.


4. Consider running with
org.apache.catalina.connector.RECYCLE_FACADES=true
http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html

That option will make your configuration more secure and can reveal
severe bugs with request/response management in web applications (and
frameworks).

Thanks, I'll try it.



Best regards,
Konstantin Kolinko




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Can I deploy war file to the running Tomcat, by using my web application?

[Ivan Mladenović]

Hi,

I am using Tomcat 6.0.26. Manager user is enabled in my tomcat-users.xml
file.

Can I deploy war file to the running Tomcat, by using my web application?

Could I get some examples about this?

Thanks in advance.


Best Regards,

Ivan Mladenovic

Re: Can I deploy war file to the running Tomcat, by using my web application?

[Ivan Mladenović]

Hi,

Thank you for the replay.
I solve the problem by using HTTP client.

Best Regards,

Ivan Mladenovic


On Wed, Jun 2, 2010 at 1:06 PM, Pid  wrote:

> On 02/06/2010 09:30, Ivan Mladenović wrote:
> > Hi,
> >
> > I am using Tomcat 6.0.26. Manager user is enabled in my tomcat-users.xml
> > file.
> >
> > Can I deploy war file to the running Tomcat, by using my web application?
>
> Using the manager application you can deploy applications.
>
> > Could I get some examples about this?
>
>  http://tomcat.apache.org/tomcat-6.0-doc/manager-howto.html
>
> or:
>
>  http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html
>
>
> p
>
>
> > Thanks in advance.
> >
> >
> > Best Regards,
> >
> > Ivan Mladenovic
> >
>
>
>

How can I increase maximum upload size?

[Ivan Mladenović]

Hi,



I am using the Tomcat 6.0.26 and I try to upload file that is larger than
1 bytes from JSP.

I try to increase the maximum upload size (for post request).

I change the Connector element:







But, maximum upload size is 1.



How can I increase maximum upload size?



Thanks in advance.



Best Regards,

Ivan

Re: How can I increase maximum upload size?

[Ivan Mladenović]

Hi,


I solve the problem by defining following bean:







If -1 is set for maximum upload size, then size of file will not be checked.


Best Regards,

Ivan Mladenovic




2010/6/3 Ivan Mladenović 

> Hi,
>
>
>
> I am using the Tomcat 6.0.26 and I try to upload file that is larger than
> 1 bytes from JSP.
>
> I try to increase the maximum upload size (for post request).
>
> I change the Connector element:
>
>
>
>  redirectPort="8444" maxPostSize="50" maxSavePostSize="50" />
>
>
>
> But, maximum upload size is 1.
>
>
>
> How can I increase maximum upload size?
>
>
>
> Thanks in advance.
>
>
>
> Best Regards,
>
> Ivan
>

problem with filters on Tomcat 7.0.16 and above

[Ivan Polak]

Hi!

Recently, we have migrated my web app from Tomcat 6.0.16 to Tomcat
7.0.29. The application works fine for most of the part but gives
problem with URLRewriteFilter. I am using URLRewriteFilter version
4.0.5.

In tomcat 6.0.16 everything is OK,

URLRewriteFilter has status information page on
http://localhost:8080/app/rewrite-status/, with Tomcat 6.0.16 is OK,
but in tomcat 7.0.16 and above, this page show HTTP Status 404 tomcat
error screen.

I use tomcat in eclipse, with debug mode (URLRewriteFilter parameter
logLevel=DEBUG), in console there all messages (the same messages as
with tomcat 6.0.16), so the filter is started correctly.

INFO: org.tuckey.web.filters.urlrewrite.Conf DEBUG: about to parse
conf 24.8.2012 20:09:56 org.apache.catalina.core.ApplicationContext
log
INFO: org.tuckey.web.filters.urlrewrite.ConfHandler
DEBUG: Resolving to DTD
/org/tuckey/web/filters/urlrewrite/dtds/urlrewrite4.0.dtd 24.8.2012
20:09:56 org.apache.catalina.core.ApplicationContext log
INFO: org.tuckey.web.filters.urlrewrite.Conf DEBUG: now
initialising conf 24.8.2012 20:09:56
org.apache.catalina.core.ApplicationContext log
INFO: org.tuckey.web.filters.urlrewrite.RuleBase DEBUG: loaded
rule Rule 0 (/test/status/, %{context-path}/rewrite-status 0)

with Tomcat 7.0.16 and above there are problem with defined filters in web.xml.


UrlRewriteFilter

org.tuckey.web.filters.urlrewrite.UrlRewriteFilter



UrlRewriteFilter
/*
REQUEST
FORWARD


in Tomcat 7.0.10, 7.0.11, 7.0.12, 7.0.14 is everything OK,

but in Tomcat 7.0.16 and above, method:

public void doFilter(final ServletRequest request, final
ServletResponse response, final FilterChain chain)
throws IOException, ServletException {

in filter is called on welcome-screen
(http://localhost:8080/app/index.html), but when I click on link
http://localhost:8080/app/invitations/, method doFilter is not called.

the same situation is with others filters defined in web.xml.

thanks.

Ivan

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: problem with filters on Tomcat 7.0.16 and above

[Ivan Polak]

thank you for your answer.

"invitations" is served by a filter and translated from
http://localhost:8080/app/invitations/ to Spring MVC controller, in
urlrewrite filter configuration is:



/invitations/(.*)
/invitations.html


and in Spring MVC configuration is:




invitationsController
..

after Iset logEffectiveWebXml="true" on  in META-INF in my
application, I have this messages in log file:

..
INFO: web.xml:

http://java.sun.com/xml/ns/javaee";
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
 xsi:schemaLocation="http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd";
 version="3.0"
 metadata-complete="true">

  app
  
contextConfigLocation
/WEB-INF/applicationContext.xml
/WEB-INF/applicationContext-services.xml
/WEB-INF/applicationContext-resources.xml
/WEB-INF/applicationContext-mail.xml
/WEB-INF/applicationContext-business.xml
/WEB-INF/applicationContext-security.xml
/WEB-INF/applicationContext-quartz.xml
  

  
UrlRewriteFilter

org.tuckey.web.filters.urlrewrite.UrlRewriteFilter
false
  
  
encodingFilter

org.springframework.web.filter.CharacterEncodingFilter
false

  encoding
  UTF-8


  forceEncoding
  true

  
  
messageFilter
org.skynetframework.core.filter.MessageFilter
false
  

  
UrlRewriteFilter
/*
FORWARD
REQUEST
  
  
encodingFilter
/*
  
  
messageFilter
/*
FORWARD
REQUEST
  

  
jsp
org.apache.jasper.servlet.JspServlet

  fork
  false


  xpoweredBy
  false

3
  
  
default
org.apache.catalina.servlets.DefaultServlet

  debug
  0


  listings
  false

1
  
  
apps

org.springframework.web.servlet.DispatcherServlet

  contextConfigLocation
  /WEB-INF/app-servlet.xml

1
  
  
pluploadServlet

info.app.servlet.servlets.upload.PluploadServlet
  

  
jsp
*.jsp
  
  
default
*.gif
  
  
default
*.jpg
  
  
apps
*.html
  
  
default
*.png
  
  
jsp
*.jspx
  
  
default
*.css
  
  
default
*.js
  
  
pluploadServlet
/upload
  

  
30


  

  
.


thanks

Ivan

On 25 August 2012 16:34, Konstantin Kolinko  wrote:
> 2012/8/25 Ivan Polak :
>> Hi!
>>
>> Recently, we have migrated my web app from Tomcat 6.0.16 to Tomcat
>> 7.0.29. The application works fine for most of the part but gives
>> problem with URLRewriteFilter. I am using URLRewriteFilter version
>> 4.0.5.
>>
>> In tomcat 6.0.16 everything is OK,
>>
>> URLRewriteFilter has status information page on
>> http://localhost:8080/app/rewrite-status/, with Tomcat 6.0.16 is OK,
>> but in tomcat 7.0.16 and above, this page show HTTP Status 404 tomcat
>> error screen.
>>
>> I use tomcat in eclipse, with debug mode (URLRewriteFilter parameter
>> logLevel=DEBUG), in console there all messages (the same messages as
>> with tomcat 6.0.16), so the filter is started correctly.
>>
>> INFO: org.tuckey.web.filters.urlrewrite.Conf DEBUG: about to parse
>> conf 24.8.2012 20:09:56 org.apache.catalina.core.ApplicationContext
>> log
>> INFO: org.tuckey.web.filters.urlrewrite.ConfHandler
>> DEBUG: Resolving to DTD
>> /org/tuckey/web/filters/urlrewrite/dtds/urlrewrite4.0.dtd 24.8.2012
>> 20:09:56 org.apache.catalina.core.ApplicationContext log
>> INFO: org.tuckey.web.filters.urlrewrite.Conf DEBUG: now
>> initialising conf 24.8.2012 20:09:56
>> org.apache.catalina.core.ApplicationContext log
>> INFO: org.tuckey.web.filters.urlrewrite.RuleBase DEBUG: loaded
>> rule Rule 0 (/test/status/, %{context-path}/rewrite-status 0)
>>
>> with Tomcat 7.0.16 and above there are problem with defined filters in 
>> web.xml.
>>
>> 
>> UrlRewriteFilter
>> 
>> org.tuckey.web.filters.urlrewrite.UrlRewriteFilter
>> 
>>
>> 
>> UrlRewriteFilter
>> /*
>> REQUEST
>> FORWARD
>> 
>>
>> in Tomcat 7.0.10, 7.0.11, 7.0.12, 7.0.14 is everything OK,
>>
>> but in Tomcat 7.0.16 and above, method:
>>
>> public void doFilter(final ServletRequest request, final
>> ServletResponse response, final FilterChain chain)
>> throws IOException, ServletException {
>>
>> in filter is called on welcome-screen
>> (http://localhost:8080/app/index.

Re: problem with filters on Tomcat 7.0.16 and above

[Ivan Polak]

Hi,

I have version 4.0.5 of UrlRewriteFilter, I built it from source code
from svn repository (jar file created by maven build script and
included to project). With version 4.0.3 is also the same problem (jar
file downloaded from UrlRewrite home page).

I have all rules for UrlRewriteFilter defined in urlrewrite.xml config
file (which is in WEB-INF directory) and all rules are loaded
succesfully during Tomcat server start (there were confirmation
messages in log file).

When I started Tomcat server,and then in web browser I show first
page-welcome page, doFilter method in UrlRewriteFitlter class is
called (I have a breakpoint on the first line of this method).

all defined rules for UrlRewriteFilter have the same problem.

and now, my Tomcat debug:

first, I have breakpoint on the first line in method:

public ApplicationFilterChain createFilterChain(ServletRequest
request, Wrapper wrapper, Servlet servlet) in
ApplicationFilterFactory.class,

and when I click in web browser on link
http://localhost:8080/app/invitations/ (or other link, which is served
by UrlRewrite filter, this method was not called, why ?

and when I click in web browser on link
http://localhost:8080/app/user/settings.html, which is 'direct' link
to Spring MVC controller, createFilterChain method was called.

thanks

Ivan

Dne 26.8.2012 17:00 "Konstantin Kolinko"  napsal(a):
>
> 2012/8/26 Ivan Polak :
> > thank you for your answer.
> >
> > "invitations" is served by a filter and translated from
> > http://localhost:8080/app/invitations/ to Spring MVC controller, in
> > urlrewrite filter configuration is:
> >
> > 
> > 
> > /invitations/(.*)
> > /invitations.html
> > 
> >
> > and in Spring MVC configuration is:
> >
> >  > 
> > class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
> > 
> > 
> >  > key="/invitations.html">invitationsController
> > ..
> >
> > after Iset logEffectiveWebXml="true" on  in META-INF in my
> > application, I have this messages in log file:
> >
> > ..
> > INFO: web.xml:
> > 
> > http://java.sun.com/xml/ns/javaee";
> >  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> >  
> > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd";
> >  version="3.0"
> >  metadata-complete="true">
> >
> >   app
> >   
> > contextConfigLocation
> > /WEB-INF/applicationContext.xml
> > /WEB-INF/applicationContext-services.xml
> > /WEB-INF/applicationContext-resources.xml
> > /WEB-INF/applicationContext-mail.xml
> > /WEB-INF/applicationContext-business.xml
> > /WEB-INF/applicationContext-security.xml
> > /WEB-INF/applicationContext-quartz.xml
> >   
> >
> >   
> > UrlRewriteFilter
> > 
> > org.tuckey.web.filters.urlrewrite.UrlRewriteFilter
> > false
> >   
> >   
> > encodingFilter
> > 
> > org.springframework.web.filter.CharacterEncodingFilter
> > false
> > 
> >   encoding
> >   UTF-8
> > 
> > 
> >   forceEncoding
> >   true
> > 
> >   
> >   
> > messageFilter
> > 
> > org.skynetframework.core.filter.MessageFilter
> > false
> >   
> >
> >   
> > UrlRewriteFilter
> > /*
> > FORWARD
> > REQUEST
> >   
> >   
> > encodingFilter
> > /*
> >   
> >   
> > messageFilter
> > /*
> > FORWARD
> > REQUEST
> >   
> >
> >   
> > jsp
> > org.apache.jasper.servlet.JspServlet
> > 
> >   fork
> >   false
> > 
> > 
> >   xpoweredBy
> >   false
> > 
> > 3
> >   
> >   
> > default
> > 
> > org.apache.catalina.servlets.DefaultServlet
> > 
> >   debug
> >   0
> > 
> > 
> >   listings
> >   false
> > 
> > 1
> >   
> >   
> > apps
> > 
> > org.springframework.web.servlet.DispatcherServlet
> > 
> >   contextConfigLocation
> >   /WEB-INF/app-servlet.xml
> > 
> > 1
> >   
> >   
> > pluplo

Re: problem with filters on Tomcat 7.0.16 and above

[Ivan Polak]

I have found, where is the problem.

problem is in StandardContextValve.java in

@Override
public final void invoke(Request request, Response response)
throws IOException, ServletException {



// Select the Wrapper to be used for this Request
Wrapper wrapper = request.getWrapper();
if (wrapper == null || wrapper.isUnavailable()) {
response.sendError(HttpServletResponse.SC_NOT_FOUND);
return;
}
.

if request is : http://localhost:8080/app/index.html (direct link to
Spring MVC controller), object wrapper is not null,

and if request is : http://localhost:8080/app/invitations/ (served by
UrlRewrite filter), object wrapper is NULL!

in CoyoteAdapter.java on line 649:

request.setWrapper((Wrapper) request.getMappingData().wrapper);

is set NULL.

Ivan

On 26 August 2012 22:25, Konstantin Kolinko  wrote:
> 2012/8/26 Ivan Polak :
>> Hi,
>>
>> I have version 4.0.5 of UrlRewriteFilter, I built it from source code
>> from svn repository (jar file created by maven build script and
>> included to project). With version 4.0.3 is also the same problem (jar
>> file downloaded from UrlRewrite home page).
>>
>> I have all rules for UrlRewriteFilter defined in urlrewrite.xml config
>> file (which is in WEB-INF directory) and all rules are loaded
>> succesfully during Tomcat server start (there were confirmation
>> messages in log file).
>>
>> When I started Tomcat server,and then in web browser I show first
>> page-welcome page, doFilter method in UrlRewriteFitlter class is
>> called (I have a breakpoint on the first line of this method).
>>
>> all defined rules for UrlRewriteFilter have the same problem.
>>
>> and now, my Tomcat debug:
>>
>> first, I have breakpoint on the first line in method:
>>
>> public ApplicationFilterChain createFilterChain(ServletRequest
>> request, Wrapper wrapper, Servlet servlet) in
>> ApplicationFilterFactory.class,
>>
>> and when I click in web browser on link
>> http://localhost:8080/app/invitations/ (or other link, which is served
>> by UrlRewrite filter, this method was not called, why ?
>>
>> and when I click in web browser on link
>> http://localhost:8080/app/user/settings.html, which is 'direct' link
>> to Spring MVC controller, createFilterChain method was called.
>>
>
> I cannot reproduce. Using current 7.0.x (dev), UrlRewriteFilter 4.0.3
> and similar configuration with three filters.
>
>> and when I click in web browser on link
>
> Maybe it was served from browser's cache, so no request was sent to Tomcat?
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: problem with filters on Tomcat 7.0.16 and above

[Ivan Polak]

On 26 August 2012 23:05, Konstantin Kolinko  wrote:
> 2012/8/27 Ivan Polak :
>> I have found, where is the problem.
>>
>> problem is in StandardContextValve.java in
>>
>> @Override
>> public final void invoke(Request request, Response response)
>> throws IOException, ServletException {
>>
>> 
>>
>> // Select the Wrapper to be used for this Request
>> Wrapper wrapper = request.getWrapper();
>> if (wrapper == null || wrapper.isUnavailable()) {
>> response.sendError(HttpServletResponse.SC_NOT_FOUND);
>> return;
>> }
>> .
>>
>> if request is : http://localhost:8080/app/index.html (direct link to
>> Spring MVC controller), object wrapper is not null,
>>
>> and if request is : http://localhost:8080/app/invitations/ (served by
>> UrlRewrite filter), object wrapper is NULL!
>>
>> in CoyoteAdapter.java on line 649:
>>
>> request.setWrapper((Wrapper) request.getMappingData().wrapper);
>>
>> is set NULL.
>>
>
> Can you stop top-posting?
> http://en.wikipedia.org/wiki/Posting_style#Choosing_the_proper_posting_style
>
> What is your list of welcome files?
>
> How a wrapper can be null?
> 1) For a directory path like yours,
> the welcome files come into play and the servlet that serves them is
> selected as the wrapper.
> 2) There is always DefaultServlet (servlet mapped to "/") that is
> selected when nothing else matches the request.
>
> When your breakpoint is on "if (wrapper == null ||
> wrapper.isUnavailable()) {" line,
> what is the value of the local variable "requestPathMB" ?
>
>
>> request.setWrapper((Wrapper) request.getMappingData().wrapper);
>
> Mapping is performed in
> org.apache.tomcat.util.http.mapper.Mapper#map(..) (there are two
> public map() methods)
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>


Hi,

1.
local variable requestPathMB = null (in Tomcat 7.0.14 requestPathMB =
"/invitations")

2. 
index.jsp


3.
As I wrote on the last mail, the problem is in
StandardContextValve.java in method:

public final void invoke(Request request, Response response)
throws IOException, ServletException {

...
Wrapper wrapper = request.getWrapper();
...

in Mapper class on line 988

// Rule 7 -- Default servlet
if (mappingData.wrapper == null && !checkJspWelcomeFiles) {
if (contextVersion.defaultWrapper != null) {

contextVersion.defaultWrapper is NULL.

in Tomcat 7.0.14 (where everything is OK) is not null.

in Mapper.java, on line 708, method:

private final void internalMap(CharChunk host, CharChunk uri,
String version, MappingData mappingData) throws Exception {

on line 725: contexts = hosts[pos].contextList.contexts;

there are 2 contexts:

1. [0]:name="", versions.MapperContextVersion.defaultWrapper not null
2. [1]:name="app", versions.MapperContextVersion.defaultWrapper is null

[in Tomcat 7.0.14, there are 2 contexts, too, but all have
defaultWrapper not null]

variable pos=1, context = contexts[pos];

selected context has defaultWrapper null, variable
contextVersion.defaultWrapper is null.

Ivan

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: problem with filters on Tomcat 7.0.16 and above

[Ivan Polak]

Dne 27.8.2012 17:27 "Christopher Schultz" 
napsal(a):
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Ivan,
>
> On 8/26/12 7:00 PM, Ivan Polak wrote:
> > in Tomcat 7.0.14 (where everything is OK) is not null.
>
> Is there any reason you are using 7.0.ancient instead of 7.0.latest?
> How about trying 7.0.29?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAlA7kbwACgkQ9CaO5/Lv0PCcMACgi8N6s5whQjZcaVgktRqEuzxq
> O+0AoKG8noBo1vRGPh7r9pY4JA1SEJbb
> =FR1l
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Hi,
I am using tomcat 7.0.29 and problem is with 7.0.16 and above.

Ivan

Re: problem with filters on Tomcat 7.0.16 and above

[Ivan Polak]

On 27 August 2012 22:13, Konstantin Kolinko  wrote:
> 2012/8/27 Ivan Polak :
>> On 26 August 2012 23:05, Konstantin Kolinko  wrote:
>>> 2012/8/27 Ivan Polak :
>>>> I have found, where is the problem.
>>>>
>>>> problem is in StandardContextValve.java in
>>>>
>>>> @Override
>>>> public final void invoke(Request request, Response response)
>>>> throws IOException, ServletException {
>>>>
>>>> 
>>>>
>>>> // Select the Wrapper to be used for this Request
>>>> Wrapper wrapper = request.getWrapper();
>>>> if (wrapper == null || wrapper.isUnavailable()) {
>>>> response.sendError(HttpServletResponse.SC_NOT_FOUND);
>>>> return;
>>>> }
>>>> .
>>>>
>>>> if request is : http://localhost:8080/app/index.html (direct link to
>>>> Spring MVC controller), object wrapper is not null,
>>>>
>>>> and if request is : http://localhost:8080/app/invitations/ (served by
>>>> UrlRewrite filter), object wrapper is NULL!
>>>>
>>>> in CoyoteAdapter.java on line 649:
>>>>
>>>> request.setWrapper((Wrapper) request.getMappingData().wrapper);
>>>>
>>>> is set NULL.
>>>>
>>>
>>> Can you stop top-posting?
>>> http://en.wikipedia.org/wiki/Posting_style#Choosing_the_proper_posting_style
>>>
>>> What is your list of welcome files?
>>>
>>> How a wrapper can be null?
>>> 1) For a directory path like yours,
>>> the welcome files come into play and the servlet that serves them is
>>> selected as the wrapper.
>>> 2) There is always DefaultServlet (servlet mapped to "/") that is
>>> selected when nothing else matches the request.
>>>
>>> When your breakpoint is on "if (wrapper == null ||
>>> wrapper.isUnavailable()) {" line,
>>> what is the value of the local variable "requestPathMB" ?
>>>
>>>
>>>> request.setWrapper((Wrapper) request.getMappingData().wrapper);
>>>
>>> Mapping is performed in
>>> org.apache.tomcat.util.http.mapper.Mapper#map(..) (there are two
>>> public map() methods)
>>>
>>> Best regards,
>>> Konstantin Kolinko
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>
>>
>> Hi,
>>
>> 1.
>> local variable requestPathMB = null (in Tomcat 7.0.14 requestPathMB =
>> "/invitations")
>>
>> 2. 
>> index.jsp
>> 
>>
>> 3.
>> As I wrote on the last mail, the problem is in
>> StandardContextValve.java in method:
>>
>> public final void invoke(Request request, Response response)
>> throws IOException, ServletException {
>>
>> ...
>> Wrapper wrapper = request.getWrapper();
>> ...
>>
>> in Mapper class on line 988
>>
>> // Rule 7 -- Default servlet
>> if (mappingData.wrapper == null && !checkJspWelcomeFiles) {
>> if (contextVersion.defaultWrapper != null) {
>>
>> contextVersion.defaultWrapper is NULL.
>>
>> in Tomcat 7.0.14 (where everything is OK) is not null.
>>
>> in Mapper.java, on line 708, method:
>>
>> private final void internalMap(CharChunk host, CharChunk uri,
>> String version, MappingData mappingData) throws Exception {
>>
>> on line 725: contexts = hosts[pos].contextList.contexts;
>>
>> there are 2 contexts:
>>
>> 1. [0]:name="", versions.MapperContextVersion.defaultWrapper not null
>> 2. [1]:name="app", versions.MapperContextVersion.defaultWrapper is null
>>
>> [in Tomcat 7.0.14, there are 2 contexts, too, but all have
>> defaultWrapper not null]
>>
>> variable pos=1, context = contexts[pos];
>>
>> selected context has defaultWrapper null, variable
>> contextVersion.defaultWrapper is null.
>>
>> Ivan
>>
>
> If you configure this web application with
> 
>
> (Or, alternatively, you can add
> org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true
> to catalina.properties or to CATALINA_OPTS),
>
> does it give you the desired behaviour?
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>



yes, yes, yes, thank You very, very much, after I add
resourceOnlyServlets="" to context in my context.xml file, everything
is OK.

Thank you very, very much!

Ivan

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Question about undeploying application

[Ivan Mladenović]

Hello,

I’m using Tomcat 6.0.29. Tomcat manager application is enabled. Version of
installed Java is 1.6 update 18. Operating systems used to test this are
Windows 7 and Ubuntu 9.1.

There is one Spring web application that is deployed on Tomcat.  Deployed
application have some threads that are running in background.

Then try to un-deploy application by using Tomcat Manager. Application WAR
file and folder where WAR file is unpacked are removed, but I get this error
in logs:

*Aug 12, 2010 2:35:23 PM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: The web application [] appears to have started a thread named
[scheduler_Worker-6] but has failed to stop it. This is very likely to
create a memory leak.*

When I try to deploy new version of application (also by using Tomcat
Manager)  I get the “Out of memory” exception.

I try to change definition of following listener:

**

And I also try to add following parameters in context.xml:
*

*
Can I configure Tomcat to kill all treads when application is undeployed?

Thanks in advance.

Ivan

Re: Question about undeploying application

[Ivan Mladenović]

Hi,



Thanks for the quick answer.



I try this, but something strange is happening when I try to deploy
application (without the Tomcat restart).



I define ServletContextListener (create my implementation of this listener
and define this listener in web.xml). In method contextDestroyed I try to
shutdown all of the schedulers in following way:


ApplicationContext context = (ApplicationContext)
sce.getServletContext().getAttribute(WebApplicationContext.*
ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE*);



scheduler = (StdScheduler) context.getBean("scheduler");

cbcInterfaceScheduler.shutdown(*true*);



Boolean parameter means: wait for jobs to complete.



I follow the logs, destroy method is called and all schedulers are shutdown.

When I try to deploy same WAR file again, following error appears in
catalina log file:



Aug 13, 2010 12:22:54 PM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads

SEVERE: The web application [] appears to have started a thread named
[scheduler_Worker-8] but has failed to stop it. This is very likely to
create a memory leak.

Aug 13, 2010 12:22:54 PM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads

SEVERE: The web application [] appears to have started a thread named
[Thread-32] but has failed to stop it. This is very likely to create a
memory leak.



I also try to pause all jobs for scheduler and remove all jobs from
scheduler before I shutdown the scheduler, but I get the same error.



This is confusing for me because this is shown in log file when I try to
deploy application.



Could you give me some advice of how I can solve this?



Thanks in advance.





2010/8/12 Caldarale, Charles R 

> > From: Ivan Mladenović [mailto:pif...@gmail.com]
> > Subject: Question about undeploying application
> >
> > Deployed application have some threads that are running
> > in background.
>
> Then deployed application must stop those threads as part of its shutdown
> procedure.  Tomcat can't do it for you.  You should be using a
> ServletContextListener in your webapp, so it can properly manage the threads
> when its contextDestroyed() method is invoked.
>
> > Can I configure Tomcat to kill all treads when application
> > is undeployed?
>
> No, that's the webapp's job.
>
>  - 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 unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Question about undeploying application

[Ivan Mladenović]

Hello,

Problem solved by changing Quartz scheduler version to 1.8.3.

Thanks for the help.



On Fri, Aug 13, 2010 at 9:24 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Ivan,
>
> On 8/13/2010 6:45 AM, Ivan Mladenović wrote:
> > I define ServletContextListener (create my implementation of this
> listener
> > and define this listener in web.xml). In method contextDestroyed I try to
> > shutdown all of the schedulers in following way:
> >
> > ApplicationContext context = (ApplicationContext)
> > sce.getServletContext().getAttribute(WebApplicationContext.*
> > ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE*);
>
> I don't recognize the above, but I suppose you know what you are doing.
>
> > scheduler = (StdScheduler) context.getBean("scheduler");
> >
> > cbcInterfaceScheduler.shutdown(*true*);
>
> Are these the same object? It looks like you are not shutting-down the
> object you got from the context.
>
> > Boolean parameter means: wait for jobs to complete.
> >
> > I follow the logs, destroy method is called and all schedulers are
> shutdown.
>
> Sounds good.
>
> > When I try to deploy same WAR file again, following error appears in
> > catalina log file:
> >
> > Aug 13, 2010 12:22:54 PM org.apache.catalina.loader.WebappClassLoader
> > clearReferencesThreads
> >
> > SEVERE: The web application [] appears to have started a thread named
> > [scheduler_Worker-8] but has failed to stop it. This is very likely to
> > create a memory leak.
>
> Could that be the old version of the webapp? Try a completely clean
> deployment, then re-deploy and see what happens.
>
> > Aug 13, 2010 12:22:54 PM org.apache.catalina.loader.WebappClassLoader
> > clearReferencesThreads
> >
> > SEVERE: The web application [] appears to have started a thread named
> > [Thread-32] but has failed to stop it. This is very likely to create a
> > memory leak.
>
> This is likely to be some /other/ thread - not scheduling related - that
> your webapp created (note that it has a generic name).
>
> > This is confusing for me because this is shown in log file when I try to
> > deploy application.
>
> Maybe ask the people who wrote the scheduler?
>
> You may have to attach a profiler to the server and observe where these
> threads are actually being created, and what actually happens when you
> call the shutdown() method on your scheduler.
>
> Hope that helps,
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkxlm9kACgkQ9CaO5/Lv0PD31gCdGjtqde4FC7a3SWbsDWiggGpo
> SLEAn1EwbJlLaTS17VIVmourUd35/QUJ
> =bgTF
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Information about incident ID 2205106170494020972

[Yin, Ivan]

Hi  experts,

When I tried to click one button in the web application deployed in Tomcat 7, 
it throws an error message as below:

This page can't be displayed. Contact support for additional information.
The incident ID is: 2205106170494020972.

May I know what is the meaning of this incident ID and how I can solve this 
issue?

Thanks in advance.

Regards,
Ivan

答复: Information about incident ID 2205106170494020972

[Yin, Ivan]

Hi,

I am sure this error message doesn't come from that webapp since there is no 
"incident ID" in the webapp.
In addition, I searched this error in google and I found a lot of similar error 
messages coming from different webapps deployed on tomcat so I thought it might 
come from Tomcat.

The original error is:

This page can't be displayed. Contact support for additional information.
The incident ID is: N/A.

I found the following message in http trace:

This page can't be displayed. Contact support for additional information.
The incident ID is: 2205106170494020972.

May I know if there is a concept called "incident ID" in tomcat?

Regards,
Ivan

-邮件原件-
发件人: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] 
发送时间: 2016年4月5日 9:38
收件人: Tomcat Users List 
主题: RE: Information about incident ID 2205106170494020972

> From: Yin, Ivan [mailto:ivan@sap.com] 
> Subject: Information about incident ID 2205106170494020972

> When I tried to click one button in the web application deployed in Tomcat 7, 
> it throws 
> an error message as below:

> This page can't be displayed. Contact support for additional information.
> The incident ID is: 2205106170494020972.

> May I know what is the meaning of this incident ID and how I can solve this 
> issue?

The message does not come from Tomcat itself, but most likely a webapp deployed 
under Tomcat.  As the message says, you'll need to contact the support 
personnel for the webapp.

 - 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 unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Change socket timeout in server side

[Yin, Ivan]

Hi all,

I am using Tomcat7 and have deployed a web server on it.

Currently the client side is running into the error 
"java.net.SocketTimeoutException: Read timed out" after running the web service 
for one minute.

I understand that this can be set in the client side but I would like to change 
this default value in the server side. Is it possible?

I have found a related page as below:
https://axis.apache.org/axis2/java/core/docs/http-transport.html

Two timeout instances exist in the transport level, Socket timeout and 
Connection timeout. These can be configured either at deployment or run time. 
If configuring at deployment time, the user has to add the following lines in 
axis2.xml.
For Socket timeout:
some_integer_value

According to this , I tried to add this line in the axis2.xml file and restart 
tomcat but it didn't work. Has anyone done this before or is there anything way 
to change it in the server side?

Any comment would be appreciated.

Regards,

Ivan Yin

Product Support, GSC China BI Support Team

SAP Beijing Software System Co., Lt 4/F, DLSP16, International Informat, 116023 
Dalian, China, China

T +86 411 8483-6392, M +86 18842622311, E 
ivan@sap.com<mailto:ivan@sap.com>

Re: Instances of org.apache.coyote.RequestInfo accumulate in RequestGroupInfo.processors and eventually result in OOME

[Ivan Lar]

Hello,

Here is the path to GC roots for a single RequestInfo object. However, 
it does not tell me anything. At least I don't see that my application 
is holding up the resources.


Could you see anything relevant here?

Class Name | Shallow Heap | Retained Heap
---
|  |
org.apache.coyote.RequestInfo @ 0xf4a2ce18 |   88 |   105 504
|- [955] java.lang.Object[1234] @ 0xf35b5988 |    4 952 | 4 952
|  '- elementData java.util.ArrayList @ 0xf73df080 |   24 
| 4 976
| '- processors org.apache.coyote.RequestGroupInfo @ 0xf72eaa30 
|   56 | 5 032
|    '- global 
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler @ 
0xf73de248  |   32 |   800
|   |- handler org.apache.tomcat.util.net.NioEndpoint @ 
0xf72eab48 |  288 |    60 232
|   |  |- this$0 org.apache.tomcat.util.net.NioEndpoint$Acceptor 
@ 0xf850f0e0   |   24 
|    24
|   |  |  '- , target java.lang.Thread @ 0xf850ef68  
http-nio-443-Acceptor-0 Thread |  120 |   400
|   |  |- this$0 org.apache.tomcat.util.net.NioEndpoint$Poller @ 
0xf850f320 |   48 
|   632
|   |  |  |- , target java.lang.Thread @ 0xf850f0f8  
http-nio-443-ClientPoller-0 Thread |  120 | 4 752
|   |  |  |- poller 
org.apache.tomcat.util.net.NioEndpoint$KeyAttachment @ 
0xf6506640   |  112 | 57 400
|   |  |  |  '- attachment sun.nio.ch.SelectionKeyImpl @ 
0xf6506788 |   40 |    57 976
|   |  |  | |- value java.util.HashMap$Node @ 0xf65067b0 
|   32 |    32
|   |  |  | |  '- [101] java.util.HashMap$Node[256] @ 
0xf56a40e0    | 1 040 | 
1 136
|   |  |  | | '- table java.util.HashMap @ 0xf8519708 
|   48 | 1 184
|   |  |  | |    '- fdToKey sun.nio.ch.EPollSelectorImpl 
@ 0xf850f2b8   |   72 | 
1 512
|   |  |  | |   |-  java.lang.Thread @ 
0xf850f0f8  http-nio-443-ClientPoller-0 Thread   |  120 
| 4 752
|   |  |  | |   |- this$0 
java.nio.channels.spi.AbstractSelector$1 @ 
0xf8518540 |   16 |    16
|   |  |  | |   |  '- blocker java.lang.Thread @ 
0xf850f0f8  http-nio-443-ClientPoller-0 Thread |  120 
| 4 752

|   |  |  | |   '- Total: 2 entries |  |
|   |  |  | |- key java.util.HashMap$Node @ 0xf65067d0 
|   32 |    32
|   |  |  | |  '- [105] java.util.HashMap$Node[256] @ 
0xf56a44f0    | 1 040 | 
1 136
|   |  |  | | '- table java.util.HashMap @ 0xf8526d88 
|   48 | 1 200
|   |  |  | |    '- map java.util.HashSet @ 0xf85196f8 
|   16 | 1 216
|   |  |  | |   '- c 
java.util.Collections$UnmodifiableSet @ 
0xf850f310 |   16 |    16
|   |  |  | |  '-  java.lang.Thread 
@ 0xf850f0f8  http-nio-443-ClientPoller-0 Thread|  120 | 
4 752

|   |  |  | '- Total: 2 entries |  |
|   |  |  '- Total: 2 entries |  |
|   |  '- Total: 2 entries |  |
|   |- cHandler org.apache.coyote.http11.Http11NioProtocol @ 
0xf72ea530 | 128 |   200

|   '- Total: 2 entries |  |
|- resource org.apache.tomcat.util.modeler.BaseModelMBean @ 0xf4a2fba0 
|   40 |    40

'- Total: 2 entries |  |
---


15.03.2018 11:53, Suvendu Sekhar Mondal пишет:

On Wed, Mar 14, 2018 at 2:19 AM, Industrious  wrote:

Hello, Mark,

Thanks for your attention.

Could you take a look at the class histogram from today's OOME heap dump?
Maybe it could provide some details.
I see a spike in CPU usage at the approximate time the dump was
generated but that might be caused by the garbage collector's futile
attempt to free up memory.

That's correct. Aggressive GCs causes that.


Class Name |   Objects |
Shallow Heap |  Retained Heap
---
|   |
 

Re: Tutorial - How to Set Up Lucee in Tomcat

[Ivan Serdyuk]

Awesome. I shall share that now

On Wed, Sep 5, 2018 at 9:25 AM Igal @ Lucee.org  wrote:

> I published a blog post with an accompanying video tutorial about
> setting up Lucee in Tomcat.  While there are some Lucee-specific
> elements in the tutorial, most of it is applicable to any servlet setup,
> covering CATALINA_HOME, CATALINA_BASE, and the recently added makebase
> utility.
>
> I hope that some users will find it informative and useful. Feedback is
> welcome.
>
> You can read it at
> http://blog.rasia.io/blog/how-to-easily-setup-lucee-in-tomcat.html
>
> Or watch the video at
> https://youtu.be/nuugoG5c-7M
>
> Best,
>
> Igal Sapir
> Lucee Core Developer
> Lucee.org 
>
>

Re: Tutorial - How to Set Up Lucee in Tomcat

[Ivan Serdyuk]

https://www.facebook.com/pg/Kyiv-Scala-Group-223492434893596/posts/?ref=page_internal
-
posted here.

On Wed, Sep 5, 2018 at 1:16 PM Ivan Serdyuk 
wrote:

> Awesome. I shall share that now
>
> On Wed, Sep 5, 2018 at 9:25 AM Igal @ Lucee.org  wrote:
>
>> I published a blog post with an accompanying video tutorial about
>> setting up Lucee in Tomcat.  While there are some Lucee-specific
>> elements in the tutorial, most of it is applicable to any servlet setup,
>> covering CATALINA_HOME, CATALINA_BASE, and the recently added makebase
>> utility.
>>
>> I hope that some users will find it informative and useful. Feedback is
>> welcome.
>>
>> You can read it at
>> http://blog.rasia.io/blog/how-to-easily-setup-lucee-in-tomcat.html
>>
>> Or watch the video at
>> https://youtu.be/nuugoG5c-7M
>>
>> Best,
>>
>> Igal Sapir
>> Lucee Core Developer
>> Lucee.org <http://lucee.org/>
>>
>>

Re: ApacheCon NA is in just under 3 weeks

[Ivan Serdyuk]

I know about some Apache commiters from Montreal - and they do not go to
the conf, this time. Perhaps you should also consider afterparty options
those.

Ivan

On Wed, Sep 5, 2018 at 1:40 PM Mark Thomas  wrote:

> All,
>
> ApacheCon North America starts in Montréal in just under three weeks.
> There are 2 days of Tomcat content starting on the Monday. If you
> haven't registered, now would be a good time to do so ;)
>
> The evening schedule is already looking pretty packed but Monday evening
> has been set aside for project gatherings and there are still rooms
> available.
>
> Thoughts on booking a room for a Tomcat related session?
>
> I've no firm thoughts on an agenda other than talk Tomcat stuff for an
> hour or so followed by moving to the hotel bar / coffee shop / somewhere
> with lots of comfy seats to continue chatting.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

CLASSPATH, .jar files, packages, and so forth

[Mann, Ivan H]

> I have an application  that consists of >150 classes, organized in
> several different packages.
> 
> In the past I have installed the application in
> .../webapps// where the directory tree corresponds
> to the package layout, and this has worked fine.
> 
> I am trying to change this to using .jar files for a couple of
> reasons.  I took one package and created a jar file like this:
> 
> cd webapps//
> jar cvf schedule.jar applet/schedule/*.class
> mv schedule.jar WEB-INF/lib
> rm applet/schedule/*.class
> 
> I modified setupclasspath.sh to read WEB-INF/lib and add all .jar
> files to the CLASSPATH before starting tomcat.  Now when I try to
> access one of the classes that I put into schedule.jar it throws a
> NoClassDefFoundError.
> 
> If I run a test program with CLASSPATH pointing to the webapps/
> directory and WEB-INF/lib/schedule.jar it works fine.  In tomcat it
> doesn't find the class.  I would suspect that there an issue with the
> way I build the jar file, but I can't figure out why it works outside
> of tomcat but not inside.  
> 
> What I would really like is a cookbook document telling me how to
> distribute an application in jar files to the web.  I have Googled
> many combinations of words and can't find one.  If anybody has one of
> those I would really appreciate it.  I thing I am missing a step here,
> possibly making the manifest, but I just don't know what that missing
> step is.
> 
> Thanks for the help.
> 
> Ivan Mann
> 
> 

RE: CLASSPATH, .jar files, packages, and so forth

[Mann, Ivan H]

Yes, I am using applets.

> Why fight the way its meant to be packaged 

So, is there a link somewhere that tells the ways it's meant to be
packaged?

I took out all of the CLASSPATH setting that I done, I moved the .jar
file to the webapps/ directory, and it still doesn't work.  How do
I tell Tomcat when using applets to use a .jar file?

Ivan Mann


-
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: CLASSPATH, .jar files, packages, and so forth

[Mann, Ivan H]

Not being able to find the class may mean that it can't find the jar
file and it may mean that it can find the jar file but the package and
or directory is not done right.  The read/write permission on the jar
file is 777, so I know that it can read the jar file if it can find it. 

The applet specified here appears in the web browser just fine.  The
applet tries to access the BuildSchedule class in response to a menu
item and the exception is not thrown until then.

The applet tag is 



The jar file is located in .../webapps/schedule.jar, which is where the
applet directory in the cod parameter is.

The jar file is built from the same directory using this command:

jar cvf schedule.jar applet/schedule/*.class

The message is 

Exception in thread "AWT-EventQueue-7"
java.lang.NoClassDefFoundError: applet/schedule/BuildSchedule



Ivan Mann

-
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: CLASSPATH, .jar files, packages, and so forth

[Mann, Ivan H]

As we discovered earlier this morning, it is an applet question, not a
servlet question.

I looked in this spec and did not find any mention of applets, which is
not surprising since it is the servlet spec.  

Is there an applet spec?  

Ivan Mann 


 

-Original Message-
From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 01, 2007 10:21 AM
To: Tomcat Users List
Subject: RE: CLASSPATH, .jar files, packages, and so forth

> From: Mann, Ivan H [mailto:[EMAIL PROTECTED]
> Subject: RE: CLASSPATH, .jar files, packages, and so forth
> 
> So, is there a link somewhere that tells the ways it's meant to be 
> packaged?

As we told you before - read the servlet spec:
http://jcp.org/aboutJava/communityprocess/mrel/jsr154/index.html

 - 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: CLASSPATH, .jar files, packages, and so forth

[Mann, Ivan H]

Oops.  I mistyped one item.  Everything is in webapps/.

By now it doesn't matter, because it is working.

Thanks to whomever it was that provided the example.

Ivan Mann


 

-Original Message-
From: Christopher Schultz [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 01, 2007 12:18 PM
To: Tomcat Users List
Subject: Re: CLASSPATH, .jar files, packages, and so forth

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ivan,

Mann, Ivan H wrote:
> Not being able to find the class may mean that it can't find the jar 
> file and it may mean that it can find the jar file but the package and

> or directory is not done right.

Probably.

> The applet specified here appears in the web browser just fine.

>archive="schedule.jar"
> width=600
> height=300>
> 

Okay: that means that the JAR file itself is being loaded properly
(unless you happen to have class files laying around in the webapp's
deployment directory, outside of WEB-INF: make sure you aren't doing
that; I'm pretty sure that archive="" indicates that all code should
come from the specified JAR and classes will not be requested from the
server directly).

> The
> applet tries to access the BuildSchedule class in response to a menu 
> item and the exception is not thrown until then.
>
> java.lang.NoClassDefFoundError: applet/schedule/BuildSchedule

What do you get when you run:

$ unzip -v webapps/schedule.jar

> The jar file is located in .../webapps/schedule.jar, which is where 
> the applet directory in the cod parameter is.

Unless you have written this incorrectly, scheduler.jar shouldn't be in
"webapps/scheduler.jar"... it should be in
webapps/[yourappname]/scheduler.jar. And your applet tag should look
like this:

http://enigmail.mozdev.org

iD8DBQFHKgkv9CaO5/Lv0PARAhz8AKCDi6WbYGHmWSMOwexrqivaOybKtgCgjtul
LjWnGhknf160oyRsjh8G4X4=
=LMdJ
-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]