Re: [Tomcat-JDBC] RemovedAbandoned doesn't trigger JdbcInterceptors

[Robert Anderson]

Thanks, Keiichi.

2015-12-18 3:21 GMT-03:00 Keiichi Fujino :

> 2015-12-17 22:25 GMT+09:00 Robert Anderson :
>
> > Hi,
> >
> > When a connection is closed by "ResetAbandoned" the invoke() method from
> > JdbcInterceptor is not called. Is it the expected behaviour?
> >
> >
> Yes.
>
> The JdbcInterceptor.invoke() method is not called when removeAbandoned.
> The Connection(PooledConnection) is directly released without going through
> the JdbcInterceptors.
> (see PooledConnection.release())
>
> If you want to capture the close of the connection,
> you can use JdbcInterceptor.disconnected or reset (null, null).
>
>
>
>
> > -->server.xml
> >
> > > type="javax.sql.DataSource" removeAbandoned="true"
> > removeAbandonedTimeout="30"
> >maxActive="5" maxIdle="1"
> > initialSize="0" minIdle="0" maxWait="5000"
> >validationQuery="select 1"
> >maxAge="1"
> >testOnBorrow="true"
> >factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
> >alternateUsernameAllowed="true"
> >  jdbcInterceptors="pool.ExampleInterceptor"
> >username="tomcat" password="example"
> > driverClassName="com.intersys.jdbc.CacheDriver"
> >url="jdbc:Cache://serverip:1972/NS"/>
> >
> > --> pool.ExampleInterceptor
> >
> > public class ExampleInterceptor extends JdbcInterceptor {
> >
> >
> > public Object invoke(Object proxy, Method method, Object[] args)
> throws
> > Throwable {
> > if (method.getName() == CLOSE_VAL) {
> > System.out.println("Interceptor called."); //Doesn't happen
> but
> > connection is really closed (checked via JMX)
> > }
> > return super.invoke(proxy, method, args);
> > }
> >
> > --> JSP to simulate long running query
> >
> > <%@ page session="false" import="java.sql.*,javax.naming.*, javax.sql.*,
> > java.util.*" contentType="text/html" %><%
> > Connection conn = null;
> > try {
> > Context ctx = new InitialContext();
> > DataSource ds =
> > (DataSource)ctx.lookup("java:comp/env/jdbc/cacheapp");
> > conn = ds.getConnection();
> > Thread.sleep(6);
> > } catch (Exception e) {
> > out.print(e.getMessage());
> > } finally {
> > if (conn != null) {
> > try {
> > //conn.close(); //Don't close to force
> > RemovedAbandonedTimeout
> > } catch (Exception e) {}
> > }
> > }
> > %>
> >
> >
> > Server version: Apache Tomcat/7.0.65
> > Server built:   Oct 9 2015 08:36:58 UTC
> > Server number:  7.0.65.0
> > OS Name:Linux
> > OS Version: 2.6.18-194.32.1.el5
> > Architecture:   amd64
> > JVM Version:1.7.0_80-b15
> > JVM Vendor: Oracle Corporation
> >
> > Thanks in advance.
> >
> > P.S: Sorry, the subject was wrong.
> >
> > --
> > Keiichi.Fujino
> >
>

Re: Determining parallely deployed versions of a webapp programmatically

[S.Booth]

On 16/12/15 14:58, l.pe...@senat.fr wrote:
> I have in some of my apps cron-like tasks, scheduled by libs such as
> quartz.
> 
> As I am also an happy user of the parallel deployment feature of tomcat,
> I was wondering whether, without special privileges such as those of the
> "admin" webapps, I could programatically determine if a webapp is the
> "top" version of a family of webapps.
> 
> So, if webapp versions :
> * 1.2.1
> * 1.2.2
> * 1.2.3
> 
> are deployed, I should be capable to determine that 1.2.3 is the latest
> and only run the scheduled task in this last one.
> 
> Is there any API to achieve that ?
> 
> Thanks in advance,
> 
> Ludovic

I would expect a scheduler like Quartz to run background threads that
might give you class-loader leaks when you un-deploy the application.

I had a similar requirement to yours but compounded by having redundant
tomcat servers. I went the low-tech route of having a heartbeat servlet
pinged by an external cron job that way only a single server (and the
most up-to-date parallel deploy) runs the heartbeat code.

Stephen


==
|epcc| Dr Stephen P Booth Principal Architect   |epcc|
|epcc| s.bo...@ed.ac.uk   Phone 0131 650 5746   |epcc|
==
-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


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

Tomcat 8.0.29-30 context root redirect changes break application

[Jason Rivard]

I'm not sure if I'm posting this in the right place, but I thought I would
start here.  It seems that changes to tomcat 8.0.29-30 partially described
in the following bug break my application, and probably others:

https://bz.apache.org/bugzilla/show_bug.cgi?id=58660

And here is my test application:

https://github.com/jrivard/tomcat-root-redir-test

Behaviors seen:

The issue is that in 8.0.28, a request to the application context
"/context" would result in a redirect to "/context/".  This handling was
handed in a way that was invisible to the application code.

In 8.0.29, this request is processed and the application generates a
response.

In 8.0.30, this request is processed by the application, but generates a
302 to "/context/"

8.0.29-30 both break my test application in similar but distinct ways.  The
issue is that the application processes the initial request in a filter,
modifies the session object, and then issues a redirect to itself.  Because
the JSESSION cookie path is set to "/context/" and not "/context", the
session seen on the subsequent handling of the redirect does not have
access to the same session object as on the first request.  In a real
application that depends on similar behavior this breaks the application in
significant ways.

Another way to think of this is that it shouldn't be possible for the
application to access an HttpSession that doesn't match the browser's
session cookie.  As of 8.0.30 this implied contract is broken because on
the initial request to the "/context" url, application code has access to
an effectively bogus HttpSession instance.

I understand this can be worked around by setting context parameters
('mapperContextRootRedirectEnabled' for example), but it seems to me the
default behavior shouldn't break existing apps - unless there is a
significant security reason - which I don't think is the case here.
Perhaps this new behavior could be reverted in 8.x and prior, and only
adopted in 9.x.

If I've posted this in the wrong place, or if I should open a bug, please
advise.

Re: Tomcat 8.0.29-30 context root redirect changes break application

[Jason Rivard]

On Fri, Dec 18, 2015 at 4:36 PM, Mark Thomas  wrote:

> On 18 December 2015 20:21:12 GMT+00:00, Jason Rivard 
> wrote:

[snip]
>

> You can use sessionCookiePathUsesTrailingSlash on the Context to fix the
> session problem but be aware of the security risks if you have contexts
> with common prefixes.
>
> We might need to rethink the defaults of these inter-related Context
> options to get a set that it self-consistent and secure.
>
> Mark


Yes, I'm pretty sure that would fix the problem as well, but has the
security risks you mention.  From my perspective, this is more an issue
about the default behavior changing.  My existing binary app releases are
broken when a newer version of tomcat is used - and that shouldn't happen.
Should I open a bug for this?

Re: Tomcat 8.0.29-30 context root redirect changes break application

[Mark Thomas]

On 18 December 2015 20:21:12 GMT+00:00, Jason Rivard  wrote:
>I'm not sure if I'm posting this in the right place, but I thought I
>would
>start here.  It seems that changes to tomcat 8.0.29-30 partially
>described
>in the following bug break my application, and probably others:
>
>https://bz.apache.org/bugzilla/show_bug.cgi?id=58660
>
>And here is my test application:
>
>https://github.com/jrivard/tomcat-root-redir-test
>
>Behaviors seen:
>
>The issue is that in 8.0.28, a request to the application context
>"/context" would result in a redirect to "/context/".  This handling
>was
>handed in a way that was invisible to the application code.
>
>In 8.0.29, this request is processed and the application generates a
>response.
>
>In 8.0.30, this request is processed by the application, but generates
>a
>302 to "/context/"
>
>8.0.29-30 both break my test application in similar but distinct ways. 
>The
>issue is that the application processes the initial request in a
>filter,
>modifies the session object, and then issues a redirect to itself. 
>Because
>the JSESSION cookie path is set to "/context/" and not "/context", the
>session seen on the subsequent handling of the redirect does not have
>access to the same session object as on the first request.  In a real
>application that depends on similar behavior this breaks the
>application in
>significant ways.
>
>Another way to think of this is that it shouldn't be possible for the
>application to access an HttpSession that doesn't match the browser's
>session cookie.  As of 8.0.30 this implied contract is broken because
>on
>the initial request to the "/context" url, application code has access
>to
>an effectively bogus HttpSession instance.
>
>I understand this can be worked around by setting context parameters
>('mapperContextRootRedirectEnabled' for example), but it seems to me
>the
>default behavior shouldn't break existing apps - unless there is a
>significant security reason - which I don't think is the case here.
>Perhaps this new behavior could be reverted in 8.x and prior, and only
>adopted in 9.x.
>
>If I've posted this in the wrong place, or if I should open a bug,
>please
>advise.

You can use sessionCookiePathUsesTrailingSlash on the Context to fix the 
session problem but be aware of the security risks if you have contexts with 
common prefixes.

We might need to rethink the defaults of these inter-related Context options to 
get a set that it self-consistent and secure.

Mark

Re: Regarding User in Host Manager

[Konstantin Kolinko]

2015-12-19 5:13 GMT+03:00 Divya Modi :
> hi chris,
>
> We had been working with tomcat-users.xml, we had even updated username and
> password of admin-gui and manager-gui lot many times but didnt worked.
>
> And still we are unble to login into tomcate admin or manager...!!
>

1. Rules
http://tomcat.apache.org/lists.html#tomcat-users
-> 6. Top-posting is bad.

2. Commons mistakes:
a) Did you restart Tomcat after changing the file?

If you do not restart Tomcat, it won't read the file.

b) Is you tomcat-users file correct (well-formed) XML?

A typical mistake is forgetting to remove an XML comment.

Other typical mistake is not closing an XML tag properly.
Syntax errors are fatal. That is a feature of XML technology.

https://en.wikipedia.org/wiki/XML#Well-formedness_and_error-handling

c) The default configuration uses a LockOutRealm. If you type a wrong
password for 5 times, your account is locked for 5 minutes.

d) Are you accessing the correct Tomcat instance?

Are your requests logged in access log file?

Is your IP address (in access log file) the same as you expect?
Is such an IP address allowed to access the Manager/HostManager web
application. Usually those web applications are protected by a
RemoteAddrValve.

Have you looked in other log files as well?

https://wiki.apache.org/tomcat/FAQ/Troubleshooting_and_Diagnostics#Common_Troubleshooting_Scenario

> GoDaddy

https://wiki.apache.org/tomcat/FAQ/Linux_Unix#Q5


Best regards,
Konstantin Kolinko

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

Re: 8.0.30 500 error - redirect

[Konstantin Kolinko]

2015-12-18 2:33 GMT+03:00 Konstantin Kolinko :
> 2015-12-17 23:23 GMT+03:00 Anthony Biacco :
>
>> mod_proxy_balancer/ajp. For asthetics, i rewrite / for my URL (e.g.
>> https://dashboard.domain.com) to the tomcat context uri /db, and then
>> ProxyPass/ProxyPassReverse /db to tomcat (so esentially
>> https://dashboard.domain.com/db/). No problem.
>> The app, upon this request, will redirect the user with a 301 redirect to
>> the main page. If there's no session, the app then redirects the user with
>> a 302 to the sign in page.
>>
>> Problem:
>> Upon updating to tomcat 8.0.30, instead of receiving a 301 response back,
>> tomcat returns a 500 error.
>> I've included the error w/stack trace, along with my app's context.xml and
>> web.xml below.
>> I assume this has to do with
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=56917 that was introduced in
>> 8.0.30.
>>
>> I have added the parameters mapperContextRootRedirectEnabled="true"
>> and mapperDirectoryRedirectEnabled="true"
>> that were mentioned in the "CSRF errors after upgrade of tomcat 8
>> 
>> "  mailing list thread to my server context.xml file (they didn't have any
>> effect in the app's context.xml) and this has resolved my problem.
>> It's interesting that now, instead of the 301 (on /), then the 302 (on main
>> page), now I get a 302 (on /), then the 301 (on /db/), and then the 302 (on
>> main page). Curl output is below for 8.0.29, 8.0.30 without changes and
>> 8.0.30 with changes.
>>
>> My questions are:
>> 1. Should the problem be occuring without the parameters added?
>
> Usually such configurations do not use mod_rewrite, but use only
> mod_proxy ProxyPass/ProxyPassReverse to add/remove application name to
> request.
>
> It is known that ProxyPassReverse cannot process Location header in
> 30n responses if its value is not a complete URL. So if you use
> ProxyPassReverse directive, you need those parameters.

Correction:

My response above and below is about "useRelativeRedirects" setting on Context.
It is that setting that can affect ProxyPassReverse.

A new feature in 8.0.30. You have to pay attention to it and may try
setting it to false.


You were asking about mapperContextRootRedirectEnabled,
mapperDirectoryRedirectEnabled parameters. They are a different
feature. If changing those parameters changes the behaviour in your
web application, it is likely your web application's fault.  It is
hard to say what happens here without knowing your application /
debugging it to see how those redirects are generated.

https://wiki.apache.org/tomcat/FAQ/Troubleshooting_and_Diagnostics#Common_Troubleshooting_Scenario

> In your configuration you are exposing the application both as "/*"
> and as "/db/*". As such, you have no need to process Location headers
> in responses. Thus you do not need the ProxyPassReverse directive.
> (And thus you should have no need for those parameters).
>
>> 2. Is there a way to configure apache/tomcat so i don't need the added
>> parameters, and don't incur the extra request? I realize that may be
>> outside the scope of the list, if apache.
>
> If you just want to expose the app as "/", rename it db -> ROOT.
> https://wiki.apache.org/tomcat/HowTo#How_do_I_make_my_web_application_be_the_Tomcat_default_application.3F
>
>> Error
>> ---
>> Dec 16, 2015 1:13:06 PM org.apache.catalina.core.StandardWrapperValve invoke
>> SEVERE: Servlet.service() for servlet [default] in context with path [/db]
>> threw exception
>> java.lang.IllegalArgumentException: The resource path [index.html] is not
>> valid
>>  at
>> org.apache.catalina.webresources.StandardRoot.validate(StandardRoot.java:250)
>
> Configure an AccessLogValve at Tomcat side and show what is logged there.
>
> https://wiki.apache.org/tomcat/FAQ/Troubleshooting_and_Diagnostics#Common_Troubleshooting_Scenario
>
> The examples webapp has index.html, and it works successfully. So
> something goes wrong elsewhere.
>
> Note: you can also configure the log pattern in AccessLogValve at
> Tomcat side to log the value of Location header that is sent in
> responses and compare it with the one shown by curl.
>
>
>> apache
>> --
>> # Rewrite / to /db so the proxypass works
>> RewriteRule ^/$ /db  [NC,PT,L]
>
> I think the above shall be
> RewriteRule ^/$ /db/  [NC,PT,L]
>
> If original URL ends with '/', the resulting URL shall end with '/' as well.
>
>> # Check if a non-/db request doesn't exist as an apache asset, if so
>> rewrite to /db and pass through
>> RewriteCond %{REQUEST_URI} !^(/db$|/db/)
>
> !^/db($|/)
>
>> RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
>> RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d
>> RewriteRule ^/(.*)$ /db/$1  [NC,PT,QSA,L]
>> # Proxy to tomcat
>> ProxyPass /db balancer://loadbalancer/db
>> ProxyPassReverse /db balancer://loadbalancer/db
>
> I think the above shall be
> 

Re: Regarding User in Host Manager

[Divya Modi]

hi chris,

We had been working with tomcat-users.xml, we had even updated username and
password of admin-gui and manager-gui lot many times but didnt worked.

And still we are unble to login into tomcate admin or manager...!!

With Regards,

Mr Divya Modi,
(M) +1 (510) 458 1462.

On Mon, Dec 14, 2015 at 5:20 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Divya,
>
> On 12/14/15 1:55 PM, Divya Modi wrote:
> > I am facing problem in login Host Manager I am trying to login but it
> does
> > not authenticate so any suggestion how i should access Host Manager in my
> > VPS of GoDaddy so kindly let me know the solution.
> >
> > Even i tried to add in tomcat-users.xml still i am facing the problem so
> > let me know if any alternative.
>
> What have you actually tried so far?
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>