You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by vi...@thomsonreuters.com on 2014/11/10 17:02:06 UTC

JDBCRealm - Works OK but logs errors

Hello
I have Tomcat 8.0.9 running under NetBeans.  An application using JDBCRealm is authenticating and authorising users OK but Tomcat is logging errors.

Errors get logged on Tomcat startup and another each time a user logs in.

Numerous occurrences of this Exception:

10-Nov-2014 15:18:48.108 SEVERE [http-nio-8080-exec-3] org.apache.catalina.realm.JDBCRealm.getPassword Exception performing authentication
java.sql.SQLException: Closed Statement
                at oracle.jdbc.driver.OracleClosedStatement.setString(OracleClosedStatement.java:731)
                at oracle.jdbc.driver.OraclePreparedStatementWrapper.setString(OraclePreparedStatementWrapper.java:289)
                at org.apache.catalina.realm.JDBCRealm.credentials(JDBCRealm.java:484)
                at org.apache.catalina.realm.JDBCRealm.getPassword(JDBCRealm.java:525)
                at org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:387)
                at org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:334)
                at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:111)
                at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:578)
                at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136)
                at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
                at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
                at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
                at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:526)
                at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)
                at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:655)
                at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222)
                at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1566)
                at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1523)
                at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
                at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
                at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
                at java.lang.Thread.run(Thread.java:745)

And just one of this:

10-Nov-2014 15:18:49.249 FINE [http-nio-8080-exec-7] org.apache.catalina.util.LifecycleBase.start The start() method was called on component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/di]] after start() had already been called. The second call will be ignored.
org.apache.catalina.LifecycleException
                at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:127)
                at org.apache.catalina.manager.ManagerServlet.start(ManagerServlet.java:1270)
                at org.apache.catalina.manager.ManagerServlet.doGet(ManagerServlet.java:357)
                at javax.servlet.http.HttpServlet.service(HttpServlet.java:618)
                at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
                at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291)
                at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
                at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
                at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
                at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
                at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
                at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
                at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:615)
                at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136)
                at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
                at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
                at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
                at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:526)
                at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)
                at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:655)
                at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222)
                at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1566)
                at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1523)
                at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
                at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
                at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
                at java.lang.Thread.run(Thread.java:745)


The Realm is defined in server.xml as follows:

    <Realm className="org.apache.catalina.realm.JDBCRealm"
                connectionName="weblogin01"
                connectionPassword="xxxxxx"
                type="javax.sql.DataSource"
                driverName="oracle.jdbc.OracleDriver"
                connectionURL="jdbc:oracle:thin:@10.15.120.29:1522:DGSPC"
                userTable="weblogin.t_user"
                userNameCol="username"
                userCredCol="password"
                userRoleTable="weblogin.t_user_role"
                roleNameCol="rolename"   />


The context.xml file is as follows:

<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/di">

    <ResourceLink name="jdbc/sforum01"
                global="jdbc/sforum01"
                type="javax.sql.DataSource"/>

    <ResourceLink name="jdbc/DonorImports"
                global="jdbc/DonorImports"
                type="javax.sql.DataSource"/>

</Context>


The Oracle driver I'm using is ojdbc7.jar which comes with Oracle 12.1.0.1

It is my intention to replace JDBCRealm with a custom realm but I don't want to embark on writing that until I understand what is wrong with my current setup.

I welcome your thoughts.

Vince




________________________________

This e-mail is for the sole use of the intended recipient and contains information that may be privileged and/or confidential. If you are not an intended recipient, please notify the sender by return e-mail and delete this e-mail and any attachments. Certain required legal entity disclosures can be accessed on our website.<http://thomsonreuters.com/prof_disclosures/>

RE: JDBCRealm - Works OK but logs errors

Posted by vi...@thomsonreuters.com.
I ignored the errors logged by JDBCRealm 
and proceeded to create my custom Realm. 
I extended JDBCRealm overriding the authenticate method and 
using inherited JDBCRealm methods for authorization.

This new Realm works OK but JDBCRealm code was logging errors that 
look related to the ones logged by vanilla JDBCRealm.

16-Nov-2014 14:51:34.251 SEVERE [http-nio-8080-exec-15] 
org.apache.catalina.realm.JDBCRealm.getRoles Exception performing authentication
java.sql.SQLException: Closed Statement
at oracle.jdbc.driver.OracleClosedStatement.setString(OracleClosedStatement.java:731)
at oracle.jdbc.driver.OraclePreparedStatementWrapper.setString(OraclePreparedStatementWrapper.java:289)
at org.apache.catalina.realm.JDBCRealm.roles(JDBCRealm.java:691)
at org.apache.catalina.realm.JDBCRealm.getRoles(JDBCRealm.java:594)
at com.vincewebb.tomcat.realm.SafeRealm.authenticate(SafeRealm.java:141)

The production servers that will eventually run this 
are using Tomcat 7.0.54. With that in mind 
I switched to a different DEV server and 
downgraded it to Tomcat 7.0.54, 
the errors stopped happening.

All these instances are using the same 
Oracle 12.1 JDBC driver (ojdbc7.jar)

They are using different versions of Java, 
this is an additional variable for which I apologise.

The one that runs WITHOUT ERRORS is:

Tomcat 7.0.54
Linux
java version "1.7.0_67"
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

The ones that work OK but WITH ERRORS are:

Tomcat 8.0.14
Linux
java version "1.7.0_65"
OpenJDK Runtime Environment (rhel-2.5.1.2.0.1.el6_5-x86_64 u65-b17)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)

Tomcat 8.0.14
Windows
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b20)
Java HotSpot(TM) Client VM (build 24.65-b04, mixed mode, sharing)

Regards, Vince


> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: 14 November 2014 02:35
> To: Tomcat Users List
> Subject: Re: JDBCRealm - Works OK but logs errors
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Vince,
> 
> On 11/10/14 11:02 AM, vince.webb@thomsonreuters.com wrote:
> > I have Tomcat 8.0.9 running under NetBeans. An application using
> > JDBCRealm is authenticating and authorising users OK but Tomcat is
> > logging errors.
> 
> I don't believe much has changed in the JDBCRealm area since 8.0.9, but
> could you try with 8.0.15 just to be sure?
> 
> > Errors get logged on Tomcat startup and another each time a user logs
> > in.
> >
> > Numerous occurrences of this Exception:
> >
> > 10-Nov-2014 15:18:48.108 SEVERE [http-nio-8080-exec-3]
> > org.apache.catalina.realm.JDBCRealm.getPassword Exception performing
> > authentication java.sql.SQLException: Closed Statement at
> > oracle.jdbc.driver.OracleClosedStatement.setString(OracleClosedStatement.java:731)
> > at oracle.jdbc.driver.OraclePreparedStatementWrapper.setString(OraclePreparedStatementWrapper.java:289)
> > at org.apache.catalina.realm.JDBCRealm.credentials(JDBCRealm.java:484)
> > at org.apache.catalina.realm.JDBCRealm.getPassword(JDBCRealm.java:525)
> > at org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:387)
> > at org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:334)
> > at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:111)
> > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:578)
> > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136)
> > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
> > at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
> > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
> > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:526)
> > at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)
> > at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:655)
> > at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222)
> > at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1566)
> > at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1523)
> > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> > at java.lang.Thread.run(Thread.java:745)
> >
> > And just one of this:
> >
> > 10-Nov-2014 15:18:49.249 FINE [http-nio-8080-exec-7]
> > org.apache.catalina.util.LifecycleBase.start The start() method was
> > called on component
> >
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/di]
> > ] after start() had already been called. The second call will be
> > ignored. org.apache.catalina.LifecycleException at
> > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:127)
> >
> >
> at
> org.apache.catalina.manager.ManagerServlet.start(ManagerServlet.java:12
> 70)
> > at
> >
> org.apache.catalina.manager.ManagerServlet.doGet(ManagerServlet.java:3
> > 57)
> >
> >
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:618)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
> 
> That is very weird... the Manager servlet is calling start()? Have you
> hacked the manager web application at all?
> 
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
> > cationFilterChain.java:291)
> >
> >
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFil
> terChain.java:206)
> > at
> >
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> >
> >
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applic
> ationFilterChain.java:239)
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
> > lterChain.java:206)
> >
> >
> at
> org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetChar
> acterEncodingFilter.java:108)
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
> > cationFilterChain.java:239)
> >
> >
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFil
> terChain.java:206)
> > at
> >
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVa
> > lve.java:219)
> >
> >
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextVal
> ve.java:106)
> > at
> >
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authenticat
> > orBase.java:615)
> >
> >
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.jav
> a:136)
> > at
> >
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.ja
> > va:79)
> >
> >
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccess
> LogValve.java:610)
> > at
> >
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValv
> > e.java:88)
> >
> >
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
> 526)
> > at
> >
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp1
> > 1Processor.java:1078)
> >
> >
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(Ab
> stractProtocol.java:655)
> > at
> >
> org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.pro
> > cess(Http11NioProtocol.java:222)
> >
> >
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoin
> t.java:1566)
> > at
> >
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint
> > .java:1523)
> >
> >
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.ja
> va:1145)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
> > java:615)
> >
> >
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThre
> ad.java:61)
> > at java.lang.Thread.run(Thread.java:745)
> >
> >
> > The Realm is defined in server.xml as follows:
> >
> > <Realm className="org.apache.catalina.realm.JDBCRealm"
> > connectionName="weblogin01" connectionPassword="xxxxxx"
> > type="javax.sql.DataSource" driverName="oracle.jdbc.OracleDriver"
> > connectionURL="jdbc:oracle:thin:@10.15.120.29:1522:DGSPC"
> > userTable="weblogin.t_user" userNameCol="username"
> > userCredCol="password" userRoleTable="weblogin.t_user_role"
> > roleNameCol="rolename"   />
> >
> >
> > The context.xml file is as follows:
> >
> > <?xml version="1.0" encoding="UTF-8"?> <Context antiJARLocking="true"
> > path="/di">
> 
> A context.xml file should not include the "path" attribute. Remove it
> and allow the name of the WAR (or directory, or [context].xml file base
> name) to determine the context path.
> 
> > <ResourceLink name="jdbc/sforum01" global="jdbc/sforum01"
> > type="javax.sql.DataSource"/>
> >
> > <ResourceLink name="jdbc/DonorImports" global="jdbc/DonorImports"
> > type="javax.sql.DataSource"/>
> >
> > </Context>
> 
> The <ResourceLink> is not relevant, as you aren't using a JNDI
> DataSource for your Realm. Some would argue (including me) that the
> JDBCRealm should not be used anymore because it's single-threaded and,
> evidently, possibly buggy. You'd be better off using DataSourceRealm
> instead.
> 
> There are those (I'm not among them) who think that you should not use
> your application's general DataSource for authentication. There are
> good arguments for separating them (DOS prevention, security, etc.) so
> you might consider creating a third JNDI DataSource for authentication
> and using that with your Realm.
> 
> If you don't need your <Realm> for other web applications, I'd
> configure it in your <Context> in META-INF/context.xml instead of in
> server.xml. It's cleaner and won't require a restart. Make sure to use
> localDataSource="true" if you declare your JNDI DataSource in META-
> INF/context.xml as well as your DataSourceRealm.

Chris
Thank you. Putting the Realm into context.xml sounds like 
a good idea but in this case it includes a key which is 
specified on a per environment basis, not per application.

> 
> > The Oracle driver I'm using is ojdbc7.jar which comes with Oracle
> > 12.1.0.1
> >
> > It is my intention to replace JDBCRealm with a custom realm but I
> > don't want to embark on writing that until I understand what is wrong
> > with my current setup.
> >
> > I welcome your thoughts.
> 
> If you are going to write a new Realm it might not be worth trying to
> figure out what's wrong with JDBCRealm. Also, before writing your own
> Realm (I've done it... it's not terribly fun), check out the new
> features available in 8.0.15 to allow you to specify a
> CredentialHandler, plus some updates to the old features. For example,
> you can now enable password salting, iterated hashing, etc. in the out-
> of-the-box Realm (really a new CredentialHandler). There is also a
> PBKDF-based CredentialHandler bundled with Tomcat, and it's trivial to
> write your own that uses bcrypt/scrypt, or your own home-made password-
> handling algorithm that you are free to make as insecure as you'd like.
> :)
> 
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> 
> iQIcBAEBCAAGBQJUZWphAAoJEBzwKT+lPKRYCd8P/j6DtT1SLCkg5A1lPiOjClNB
> P6yibr8xD+uOxIxWggwT0Y3cFLXMdDg+6K+bbGaMbIIkosZ2eSRkaokHGif3Xri6
> 0wMhJKStFJoiQQIs0bRAia4U870wrSZuHFVzN0SqmqCLec4ktEmYGxASpGo6TOYw
> unSvx1TQMJjwFPb8N4/Vx4v/Vkv4zKPS3wZh2dfWS0FASEovBLT5TqVA7XFLLJmf
> 0BzpF5Vat5UNm2ichErWcliQlTtaJj+3Wz9ZiGUqDFRgGh4eAVpMWFhRgGCx+9Tt
> aMIYACYltEO91IioQ+EPcrxkiXLXXXamkqTGCFnrR0v9KmZUPiAbBWOrolN8IuN4
> PHqPmPzP2wC5Br6XJ6+Y3kyQ+Ss9jsSL/g+eD5a6kX3V4HTrwPcR8rOYXWnWgAQH
> BivCfxUqwXw411UaEhLFL8rTRxHl801hN0xLc6HAGPD9agr+C1FhJQfcj/e4RAcv
> 2qPyZYg49kPL+8yQQPR/4ObcMtgDzjG6BTePNFegMOVDWWsWlmCdquMXlg5Kx37z
> QiWGT3AjHBHFVSt+fmei5r/opy8erLNeErXi7TrMyGYFY2yadVY0H8r1Sh//YFo9
> NeE0HYDoNT7A/O1vHndICHrpMPHxui4Zxu1DlglGGX/swrgAxFjhIf88Tk3HekMn
> SKe2ibxYkerYajNxzQZT
> =ctIc
> -----END PGP SIGNATURE-----
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org


Re: JDBCRealm - Works OK but logs errors

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Vince,

On 11/10/14 11:02 AM, vince.webb@thomsonreuters.com wrote:
> I have Tomcat 8.0.9 running under NetBeans. An application using 
> JDBCRealm is authenticating and authorising users OK but Tomcat is 
> logging errors.

I don't believe much has changed in the JDBCRealm area since 8.0.9,
but could you try with 8.0.15 just to be sure?

> Errors get logged on Tomcat startup and another each time a user
> logs in.
> 
> Numerous occurrences of this Exception:
> 
> 10-Nov-2014 15:18:48.108 SEVERE [http-nio-8080-exec-3]
> org.apache.catalina.realm.JDBCRealm.getPassword Exception
> performing authentication java.sql.SQLException: Closed Statement 
> at
> oracle.jdbc.driver.OracleClosedStatement.setString(OracleClosedStatement.java:731)
>
> 
at
oracle.jdbc.driver.OraclePreparedStatementWrapper.setString(OraclePreparedStatementWrapper.java:289)
> at
> org.apache.catalina.realm.JDBCRealm.credentials(JDBCRealm.java:484)
>
> 
at org.apache.catalina.realm.JDBCRealm.getPassword(JDBCRealm.java:525)
> at
> org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:387)
>
> 
at org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:334)
> at
> org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:111)
>
> 
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:578)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136)
>
> 
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
>
> 
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:526)
>
> 
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:655)
>
> 
at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1566)
>
> 
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1523)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>
> 
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>
> 
at java.lang.Thread.run(Thread.java:745)
> 
> And just one of this:
> 
> 10-Nov-2014 15:18:49.249 FINE [http-nio-8080-exec-7]
> org.apache.catalina.util.LifecycleBase.start The start() method was
> called on component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/di]]
> after start() had already been called. The second call will be
> ignored. org.apache.catalina.LifecycleException at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:127)
>
> 
at
org.apache.catalina.manager.ManagerServlet.start(ManagerServlet.java:1270)
> at
> org.apache.catalina.manager.ManagerServlet.doGet(ManagerServlet.java:357)
>
> 
at javax.servlet.http.HttpServlet.service(HttpServlet.java:618)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)

That is very weird... the Manager servlet is calling start()? Have you
hacked the manager web application at all?

> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291)
>
> 
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>
> 
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>
> 
at
org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
>
> 
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
>
> 
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:615)
>
> 
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
>
> 
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
>
> 
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:526)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)
>
> 
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:655)
> at
> org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222)
>
> 
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1566)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1523)
>
> 
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>
> 
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
> 
> 
> The Realm is defined in server.xml as follows:
> 
> <Realm className="org.apache.catalina.realm.JDBCRealm" 
> connectionName="weblogin01" connectionPassword="xxxxxx" 
> type="javax.sql.DataSource" driverName="oracle.jdbc.OracleDriver" 
> connectionURL="jdbc:oracle:thin:@10.15.120.29:1522:DGSPC" 
> userTable="weblogin.t_user" userNameCol="username" 
> userCredCol="password" userRoleTable="weblogin.t_user_role" 
> roleNameCol="rolename"   />
> 
> 
> The context.xml file is as follows:
> 
> <?xml version="1.0" encoding="UTF-8"?> <Context
> antiJARLocking="true" path="/di">

A context.xml file should not include the "path" attribute. Remove it
and allow the name of the WAR (or directory, or [context].xml file
base name) to determine the context path.

> <ResourceLink name="jdbc/sforum01" global="jdbc/sforum01" 
> type="javax.sql.DataSource"/>
> 
> <ResourceLink name="jdbc/DonorImports" global="jdbc/DonorImports" 
> type="javax.sql.DataSource"/>
> 
> </Context>

The <ResourceLink> is not relevant, as you aren't using a JNDI
DataSource for your Realm. Some would argue (including me) that the
JDBCRealm should not be used anymore because it's single-threaded and,
evidently, possibly buggy. You'd be better off using DataSourceRealm
instead.

There are those (I'm not among them) who think that you should not use
your application's general DataSource for authentication. There are
good arguments for separating them (DOS prevention, security, etc.) so
you might consider creating a third JNDI DataSource for authentication
and using that with your Realm.

If you don't need your <Realm> for other web applications, I'd
configure it in your <Context> in META-INF/context.xml instead of in
server.xml. It's cleaner and won't require a restart. Make sure to use
localDataSource="true" if you declare your JNDI DataSource in
META-INF/context.xml as well as your DataSourceRealm.

> The Oracle driver I'm using is ojdbc7.jar which comes with Oracle
> 12.1.0.1
> 
> It is my intention to replace JDBCRealm with a custom realm but I 
> don't want to embark on writing that until I understand what is
> wrong with my current setup.
> 
> I welcome your thoughts.

If you are going to write a new Realm it might not be worth trying to
figure out what's wrong with JDBCRealm. Also, before writing your own
Realm (I've done it... it's not terribly fun), check out the new
features available in 8.0.15 to allow you to specify a
CredentialHandler, plus some updates to the old features. For example,
you can now enable password salting, iterated hashing, etc. in the
out-of-the-box Realm (really a new CredentialHandler). There is also a
PBKDF-based CredentialHandler bundled with Tomcat, and it's trivial to
write your own that uses bcrypt/scrypt, or your own home-made
password-handling algorithm that you are free to make as insecure as
you'd like. :)

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUZWphAAoJEBzwKT+lPKRYCd8P/j6DtT1SLCkg5A1lPiOjClNB
P6yibr8xD+uOxIxWggwT0Y3cFLXMdDg+6K+bbGaMbIIkosZ2eSRkaokHGif3Xri6
0wMhJKStFJoiQQIs0bRAia4U870wrSZuHFVzN0SqmqCLec4ktEmYGxASpGo6TOYw
unSvx1TQMJjwFPb8N4/Vx4v/Vkv4zKPS3wZh2dfWS0FASEovBLT5TqVA7XFLLJmf
0BzpF5Vat5UNm2ichErWcliQlTtaJj+3Wz9ZiGUqDFRgGh4eAVpMWFhRgGCx+9Tt
aMIYACYltEO91IioQ+EPcrxkiXLXXXamkqTGCFnrR0v9KmZUPiAbBWOrolN8IuN4
PHqPmPzP2wC5Br6XJ6+Y3kyQ+Ss9jsSL/g+eD5a6kX3V4HTrwPcR8rOYXWnWgAQH
BivCfxUqwXw411UaEhLFL8rTRxHl801hN0xLc6HAGPD9agr+C1FhJQfcj/e4RAcv
2qPyZYg49kPL+8yQQPR/4ObcMtgDzjG6BTePNFegMOVDWWsWlmCdquMXlg5Kx37z
QiWGT3AjHBHFVSt+fmei5r/opy8erLNeErXi7TrMyGYFY2yadVY0H8r1Sh//YFo9
NeE0HYDoNT7A/O1vHndICHrpMPHxui4Zxu1DlglGGX/swrgAxFjhIf88Tk3HekMn
SKe2ibxYkerYajNxzQZT
=ctIc
-----END PGP SIGNATURE-----

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