RE: Active Directory User Authentication Apache Tomcat 5.5 Struts Servlets JSP
Date: Tue, 24 Feb 2015 20:45:09 +0100
From: a...@ice-sa.com
To: users@tomcat.apache.org
Subject: Re: Active Directory User Authentication Apache Tomcat 5.5 Struts
Servlets JSP
Seema Patel wrote:
Hi,
We are using Apache Tomcat 5.5, JDK 1.5 and have a internal portal on our
intranet which is written in java jsp struts and jsp.
I know that the tomcat and Java versions are old, but upgrading isn't a
quick thing to do without lots of testing.
The issue we have is that the users keep getting the authentication box
popping up asking for username and password when using the portal in
Internet Explorer.
One of the users has noticed that when they use Chrome, they don't seem to
get this popup constantly. Authentication is against the Active Directory
using JCIFS (I know it's discontinued, but to re-write and test is not
feasible at the moment). The users are meant to be using Internet Explorer
as not everything works in Chrome.
We have been trying to work out this issue for some time, with no success.
The user saying that it works in Chrome makes us wonder if there's
something within Internet Explorer that is possibly dropping the connection
or something for it to keep asking the user for username and password. Or
is there something that Internet Explorer doesn't like with Apache Tomcat?
Any help/guidance on this issue is greatly appreciated.
Hi.
Tomcat 5.5 is old.
The JCIFS http/NTLM authentication filter is old and deprecated and does not
work anymore
in any recent Windows Domain setup, because it only works with NTLM v1.
Please read the first paragraph in blue here :
http://jcifs.samba.org/src/docs/ntlmhttpauth.html
and *believe what it says, it is true*.
(Look at Jespa @ www.ioplex.com for a painless replacement)
(look at a more recent version of Tomcat and the SPNEGO authentication valve
for another
possible replacement)
A login dialog that pops up in the browser when it should not, indicates one
thing for
sure : /something/ is not working in the WIA (Windows Integrated
Authentication).
But what that something is in your case, is impossible to say from outside of
your network.
It is almost certainly not a browser problem.
It may be things like :
- some of the clients are running newer versions of Windows and/or browsers
which will not
accept NTLMv1 authentication anymore
- in your network, there are multiple Domain Controllers, some of which
younger than
others. Some still accept to do NTLMv1 authentication, some do not. As your
clients get
one or the other (quasi randomly) it sometimes works, and sometimes not.
- and a large number of possible other reasons
The one certainty is : you are using obsolete software and solutions, and
nobody will be
able to give you any miracle solution for that. The sooner you accept that,
the less
time you will lose in the end.
Thanks Andre. I think we do use NTLM v2, so that could be why we're getting
the issues.
I have been looking into upgrading, on and off, so not sure if what I have done
is right or not as I've not looked at it in a while.
I do remember looking into Jespa and SPNEGO but I don't think we want to go
down those routes.
I have been looking at and trying to get traditional LDAP authentication, but I
don't know much about this (previous developers have said to use this method
but are no longer available to assist).
I am hoping if you could guide/assist me in knowing if what I have done and am
trying to do is right.
So in my server.xml I now have:
Realm className=org.apache.catalina.realm.LockOutRealm
!-- This Realm uses the UserDatabase configured in the global JNDI
resources under the key UserDatabase. Any edits
that are performed against this UserDatabase are immediately
available for use by the Realm. --
Realm className=org.apache.catalina.realm.UserDatabaseRealm
resourceName=UserDatabase/
Realm className=org.apache.catalina.realm.JNDIRealm
connectionName=xxx@xxx.local
connectionPassword=xxx connectionURL=xxx referrals=follow
roleBase=dc=xxx,dc=local roleName=cn roleSearch=(member={0})
roleSubtree=true userBase=dc=vtlwavenet,dc=local
userSearch=(sAMAccountName={0}) userSubtree=true/
/Realm
I have also removed all JCIFS and NTLM filters etc from my web.xml, I now have:
filter
filter-nameADGroupFilter/filter-name
filter-classcom.xxx.xxx.ADGroupFilter/filter-class
init-param
param-nameAllowedGroups/param-name
param-valuexxx,xxx,xxx/param-value
/init-param
/filter
filter
filter-nameAuth Filter/filter-name
filter-classcom.xxx.xxx.RequestFilter/filter-class
init-param
param-nameLogonPage/param-name
param-valuexxx.do/param-value
/init-param
init-param
Active Directory User Authentication Apache Tomcat 5.5 Struts Servlets JSP
Hi, We are using Apache Tomcat 5.5, JDK 1.5 and have a internal portal on our intranet which is written in java jsp struts and jsp. I know that the tomcat and Java versions are old, but upgrading isn't a quick thing to do without lots of testing. The issue we have is that the users keep getting the authentication box popping up asking for username and password when using the portal in Internet Explorer. One of the users has noticed that when they use Chrome, they don't seem to get this popup constantly. Authentication is against the Active Directory using JCIFS (I know it's discontinued, but to re-write and test is not feasible at the moment). The users are meant to be using Internet Explorer as not everything works in Chrome. We have been trying to work out this issue for some time, with no success. The user saying that it works in Chrome makes us wonder if there's something within Internet Explorer that is possibly dropping the connection or something for it to keep asking the user for username and password. Or is there something that Internet Explorer doesn't like with Apache Tomcat? Any help/guidance on this issue is greatly appreciated. Thanks Seema
RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
Thanks for the explanation Chris. Seema Date: Thu, 20 Mar 2014 14:34:05 -0400 From: ch...@christopherschultz.net To: users@tomcat.apache.org Subject: Re: HttpServletRequest Tomcat 5.5.29 to 7.0.52 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Seems, On 3/20/14, 1:52 PM, Seema Patel wrote: Date: Thu, 20 Mar 2014 21:12:09 +0400 Subject: Re: HttpServletRequest Tomcat 5.5.29 to 7.0.52 From: knst.koli...@gmail.com To: users@tomcat.apache.org 2014-03-20 20:55 GMT+04:00 Seema Patel seema...@hotmail.com: I think I have fixed the error I had. I have downgraded to Java 6 update 45, to see if it worked on there, but it didn't. I stayed with Java 6 to try and resolve the issue. Basically in my WEB-INF/web.xml file I have the following: filter-mapping filter-nameAuth Filter/filter-name url-pattern*.jsp/url-pattern url-pattern*.do/url-pattern dispatcherREQUEST/dispatcher /filter-mapping All requests go to the doFilter() function. In Java 5.5.29 it wasn't sending .jsp requests to the the doFilter, even though the above is in the web.xml file. In Java 6 and above, it sends the .jsp file to be processed as well. So if I comment out or take out the url-pattern*.jsp/url-pattern line, my code works. I don't know what's changed in the Java 6 code for this to not work. Does anyone know why this is so I have an understanding of it? Thanks again to all that have helped with this, I know I threw out multiple questions, just didn't want to leave anything out :) I guess s/Java/Tomcat/ in several places above. Support for multiple url-patterns did not exist in old versions of Servlet Specification, so only one of the patterns would work. Support for dispatcher also did not exist in old versions, but REQUEST is the default value here, so there is no difference. If dispatcher didn't exist and support for multiple url-patterns did not exist in older versions, then I don't know why the previous developers used it (I know this is nothing to do with you all). You can validate your web.xml file against DTD or schema it uses in any decent XML editor. My knowledge of all this isn't very good, could you please tell me what you mean by DTD or schema and could you give me an example of some XML editors I could use? Thanks XML uses DTDs or Schemas for semantic validation. http://en.wikipedia.org/wiki/Document_type_definition http://en.wikipedia.org/wiki/XML_Schema_%28W3C%29 Your XML files should either have a !DOCTYPE at the top indicating which DTD to use for validation or an xmlns[:namespace] definition at the top to use for Schema validation. Example of DTD: !DOCTYPE mbeans-descriptors PUBLIC -//Apache Software Foundation//DTD Model MBeans Configuration File http://jakarta.apache.org/commons/dtds/mbeans-descriptors.dtd; (Note that the SYSTEM id above -- the URL -- actually does not point to a valid DTD, so it may not work. Tomcat's mbeans-descriptors.xml files do not actually declare any DTD, but this is the DTD to which those files are expected to adhere.) Example of Schema: web-app xmlns=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 http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd; version=2.5 metadata-complete=true Many XML editors will already know how to validate as long as the definitions are in the files. Eclipse already does this, but sometimes it's just stupid and tells you there is no DTD/Schema even though there clearly is one. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTKzSdAAoJEBzwKT+lPKRYjVEP/3/sP9tCM/pL+7H7Ani8GKdk bYGCMbO08+VBVHr8eoU8dc33ScQ7jwqw86fGmvTjzJEtsZQyHtL1jkouTxiSMd9U Qsv/sZcnR/JlY9rixo4wO05Oh/pqX6QQ3QSlaKTvKYELS0dN2RFTRcHYfWB99tll wdHE5mgytreUG8wpURGjCroftQLvrw+NxlD1GqAL6x+tt9kScEe1skWO2E95QKjG 5VtabDQJusfPzjCA0vj4bRILJdFPf5q9hEpBumvqXoMC2pJbYXdLWCtTB8JbVRtn FKex92ygdZhnIhzVgjAFNNbc/QacXgwdT33FmhpLBeMm9ZVOhQWehLtRBu/Ugdni 6af60lU6ScGJ7cDZZS1uVvGdXsnlg3up9Fy9GXokHlI91GoBE5sar7BzdsA+OMzb At+evpXwuhbyiyDbumoqdLZFb7xIXur4diw04UeSIaFNJVUdtkF2VoOrNW0+8W/V vEzj0b2V5CPJTPgg3AIuuF//2r0FLdRSZMUVaF0/idneyujtH4o3Uc5jBWcVZqCU 2eDNuDVUdTXwUlwOmL6jgF4C8dC9REJ5Lw5A9scwiaFaXt+c70UCKIXfI0LCdBsT k19KaBjbyRJyb5u9qE2bQQBQETvz4iCTJ/lUj3GDVtnsjeoeQxzJx0AtzAgSyVL5 U+Gxnbt3JejhsCmkGfib =tcq7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
I think I have fixed the error I had. I have downgraded to Java 6 update 45,
to see if it worked on there, but it didn't.
I stayed with Java 6 to try and resolve the issue. Basically in my
WEB-INF/web.xml file I have the following:
filter-mapping
filter-nameAuth Filter/filter-name
url-pattern*.jsp/url-pattern
url-pattern*.do/url-pattern
dispatcherREQUEST/dispatcher
/filter-mapping
All requests go to the doFilter() function. In Java 5.5.29 it wasn't sending
.jsp requests to the the doFilter, even though the above is in the web.xml file.
In Java 6 and above, it sends the .jsp file to be processed as well. So if I
comment out or take out the url-pattern*.jsp/url-pattern line, my code
works.
I don't know what's changed in the Java 6 code for this to not work.
Does anyone know why this is so I have an understanding of it?
Thanks again to all that have helped with this, I know I threw out multiple
questions, just didn't want to leave anything out :)
Seema
From: mgai...@hotmail.com
To: users@tomcat.apache.org
Subject: RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
Date: Tue, 18 Mar 2014 21:18:37 -0400
Seema-
You've asked about 10 different questions on 10 different aberrancies on your
upgrade
zip up the whole project up and stick it on driveway or any other free site
That way anyone building/running the code on TC7.0.52 can at least observe
same behaviour you are experiencing
Martin --
From: seema...@hotmail.com
To: users@tomcat.apache.org
Subject: RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
Date: Tue, 18 Mar 2014 14:10:19 +
Any update on this Chris Schultz or anyone else? I know the images I added
to the email didn't show up, so if you want me to email them directly to
you, I can.
Could really do with help on this, as it is not something I know much about.
Thanks
Seema
From: seema...@hotmail.com
To: users@tomcat.apache.org
Subject: RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
Date: Fri, 14 Mar 2014 15:15:04 +
Date: Fri, 14 Mar 2014 08:36:08 -0400
From: ch...@christopherschultz.net
To: users@tomcat.apache.org
Subject: Re: HttpServletRequest Tomcat 5.5.29 to 7.0.52
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Seema,
On 3/14/14, 7:53 AM, Seema Patel wrote:
I have upgraded my tomcat (5.5.29 to 7.0.52) and Java (1.5 to 1.7)
for my struts servlet jsp application. I have also removed all
JCIFS authentication from the WEB-INF/web.xml file and have tried
to do BASIC authentication through Tomcat and the AD (it
authenticates me, but not sure if I've missed anything out, as I've
never done this before).
One question at a time, please ;)
Sorry for the off-loading of multiple questions :-)
I have a doFilter function in my code, which contains
httpServletRequest.getServletPath() call. In the Tomcat 5.5.29 Java
1.5 version, this will work, as when I print
httpServletRequest.getServletPath() i get the following:
P1_00.do P5_0_0.do P5_0_1.do
But in Tomcat 7.0.52 Java 1.7 I get the following from
httpServletRequest.getServletPath() call:
P1_00.do P5_0_0.do P5_0_1.do includes/tab_defaultsettings.jsp
includes/P1_00.do
How are you printing this? Do you just have a Filter that wraps
everything and dumps-out the ServletPath for every request? Can you
post the code for that Filter as well as the filter and
filter-mapping configuration you have in web.xml?
I'm just doing a System.out.println() in the doFilter function in the
RequestFilter class to show which page it is. The doFilter function is:
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
if (request instanceof HttpServletRequest) {
final HttpServletRequest httpRequest = (HttpServletRequest)request;
final Object userBeanObject =
httpRequest.getSession().getAttribute(GenConstants.LOGGED_IN_USER_BEAN);
final String pageName = httpRequest.getServletPath().replaceAll(/,);
System.out.println(Request Page = + httpRequest.getServletPath());
if (unsecuredPages.contains(pageName)) {
// don't need any protection
chain.doFilter(request, response);
} else if (!(userBeanObject instanceof UserBean)) {
// no user bean in session do need one, invalidate session and redirect
to login
if (httpRequest.getSession(false) != null) {
httpRequest.getSession().invalidate();
}
((HttpServletResponse)response).sendRedirect(logonPage);
} else {
final UserBean user = (UserBean) userBeanObject;
MapString,LogicalOperation permissions =
(MapString,LogicalOperation)context.getAttribute(GenConstants.PERMISSIONS_MAP);
if(permissions == null) {
PermissionsUtil.setupPermissions(context
RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
Date: Thu, 20 Mar 2014 21:12:09 +0400 Subject: Re: HttpServletRequest Tomcat 5.5.29 to 7.0.52 From: knst.koli...@gmail.com To: users@tomcat.apache.org 2014-03-20 20:55 GMT+04:00 Seema Patel seema...@hotmail.com: I think I have fixed the error I had. I have downgraded to Java 6 update 45, to see if it worked on there, but it didn't. I stayed with Java 6 to try and resolve the issue. Basically in my WEB-INF/web.xml file I have the following: filter-mapping filter-nameAuth Filter/filter-name url-pattern*.jsp/url-pattern url-pattern*.do/url-pattern dispatcherREQUEST/dispatcher /filter-mapping All requests go to the doFilter() function. In Java 5.5.29 it wasn't sending .jsp requests to the the doFilter, even though the above is in the web.xml file. In Java 6 and above, it sends the .jsp file to be processed as well. So if I comment out or take out the url-pattern*.jsp/url-pattern line, my code works. I don't know what's changed in the Java 6 code for this to not work. Does anyone know why this is so I have an understanding of it? Thanks again to all that have helped with this, I know I threw out multiple questions, just didn't want to leave anything out :) I guess s/Java/Tomcat/ in several places above. Support for multiple url-patterns did not exist in old versions of Servlet Specification, so only one of the patterns would work. Support for dispatcher also did not exist in old versions, but REQUEST is the default value here, so there is no difference. If dispatcher didn't exist and support for multiple url-patterns did not exist in older versions, then I don't know why the previous developers used it (I know this is nothing to do with you all). You can validate your web.xml file against DTD or schema it uses in any decent XML editor. My knowledge of all this isn't very good, could you please tell me what you mean by DTD or schema and could you give me an example of some XML editors I could use? Thanks (You can enable validation of web.xml in any version of Tomcat 7 and later. E.g., by setting org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Specification When validation is enabled, Tomcat will refuse to deploy an application with broken web.xml ) Thanks for this, I'll set it and see what happens. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
Martin,
When Chris Schultz said I was asking multiple questions, I did apologize to him.
My knowledge of all this is limited as I'm new to it, so please don't make
sarcastic comments to a newbie, we all have to start somewhere and I thought
the purpose of this user list was to help everyone out, no matter their skill
level (or lack of).
Again I apologize to anyone who thinks I'm asking too many questions.
My last email (with actual issue related info) was in reply to Chris Schultz
asking me for the information.
I really do appreciate any help anyone can give me.
Thanks
Seema
From: mgai...@hotmail.com
To: users@tomcat.apache.org
Subject: RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
Date: Tue, 18 Mar 2014 21:18:37 -0400
Seema-
You've asked about 10 different questions on 10 different aberrancies on your
upgrade
zip up the whole project up and stick it on driveway or any other free site
That way anyone building/running the code on TC7.0.52 can at least observe
same behaviour you are experiencing
Martin --
From: seema...@hotmail.com
To: users@tomcat.apache.org
Subject: RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
Date: Tue, 18 Mar 2014 14:10:19 +
Any update on this Chris Schultz or anyone else? I know the images I added
to the email didn't show up, so if you want me to email them directly to
you, I can.
Could really do with help on this, as it is not something I know much about.
Thanks
Seema
From: seema...@hotmail.com
To: users@tomcat.apache.org
Subject: RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
Date: Fri, 14 Mar 2014 15:15:04 +
Date: Fri, 14 Mar 2014 08:36:08 -0400
From: ch...@christopherschultz.net
To: users@tomcat.apache.org
Subject: Re: HttpServletRequest Tomcat 5.5.29 to 7.0.52
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Seema,
On 3/14/14, 7:53 AM, Seema Patel wrote:
I have upgraded my tomcat (5.5.29 to 7.0.52) and Java (1.5 to 1.7)
for my struts servlet jsp application. I have also removed all
JCIFS authentication from the WEB-INF/web.xml file and have tried
to do BASIC authentication through Tomcat and the AD (it
authenticates me, but not sure if I've missed anything out, as I've
never done this before).
One question at a time, please ;)
Sorry for the off-loading of multiple questions :-)
I have a doFilter function in my code, which contains
httpServletRequest.getServletPath() call. In the Tomcat 5.5.29 Java
1.5 version, this will work, as when I print
httpServletRequest.getServletPath() i get the following:
P1_00.do P5_0_0.do P5_0_1.do
But in Tomcat 7.0.52 Java 1.7 I get the following from
httpServletRequest.getServletPath() call:
P1_00.do P5_0_0.do P5_0_1.do includes/tab_defaultsettings.jsp
includes/P1_00.do
How are you printing this? Do you just have a Filter that wraps
everything and dumps-out the ServletPath for every request? Can you
post the code for that Filter as well as the filter and
filter-mapping configuration you have in web.xml?
I'm just doing a System.out.println() in the doFilter function in the
RequestFilter class to show which page it is. The doFilter function is:
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
if (request instanceof HttpServletRequest) {
final HttpServletRequest httpRequest = (HttpServletRequest)request;
final Object userBeanObject =
httpRequest.getSession().getAttribute(GenConstants.LOGGED_IN_USER_BEAN);
final String pageName = httpRequest.getServletPath().replaceAll(/,);
System.out.println(Request Page = + httpRequest.getServletPath());
if (unsecuredPages.contains(pageName)) {
// don't need any protection
chain.doFilter(request, response);
} else if (!(userBeanObject instanceof UserBean)) {
// no user bean in session do need one, invalidate session and redirect
to login
if (httpRequest.getSession(false) != null) {
httpRequest.getSession().invalidate();
}
((HttpServletResponse)response).sendRedirect(logonPage);
} else {
final UserBean user = (UserBean) userBeanObject;
MapString,LogicalOperation permissions =
(MapString,LogicalOperation)context.getAttribute(GenConstants.PERMISSIONS_MAP);
if(permissions == null) {
PermissionsUtil.setupPermissions(context);
permissions =
(MapString,LogicalOperation)context.getAttribute(GenConstants.PERMISSIONS_MAP);
}
final LogicalOperation requiredOp =
permissions.get(pageName.replaceAll(\\.do,));
if (user.isOperationAllowed(requiredOp)) {
chain.doFilter(request, response);
} else {
if (httpRequest.getSession(false) != null) {
httpRequest.getSession().invalidate();
}
((HttpServletResponse)response
RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
Any update on this Chris Schultz or anyone else? I know the images I added to
the email didn't show up, so if you want me to email them directly to you, I
can.
Could really do with help on this, as it is not something I know much about.
Thanks
Seema
From: seema...@hotmail.com
To: users@tomcat.apache.org
Subject: RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
Date: Fri, 14 Mar 2014 15:15:04 +
Date: Fri, 14 Mar 2014 08:36:08 -0400
From: ch...@christopherschultz.net
To: users@tomcat.apache.org
Subject: Re: HttpServletRequest Tomcat 5.5.29 to 7.0.52
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Seema,
On 3/14/14, 7:53 AM, Seema Patel wrote:
I have upgraded my tomcat (5.5.29 to 7.0.52) and Java (1.5 to 1.7)
for my struts servlet jsp application. I have also removed all
JCIFS authentication from the WEB-INF/web.xml file and have tried
to do BASIC authentication through Tomcat and the AD (it
authenticates me, but not sure if I've missed anything out, as I've
never done this before).
One question at a time, please ;)
Sorry for the off-loading of multiple questions :-)
I have a doFilter function in my code, which contains
httpServletRequest.getServletPath() call. In the Tomcat 5.5.29 Java
1.5 version, this will work, as when I print
httpServletRequest.getServletPath() i get the following:
P1_00.do P5_0_0.do P5_0_1.do
But in Tomcat 7.0.52 Java 1.7 I get the following from
httpServletRequest.getServletPath() call:
P1_00.do P5_0_0.do P5_0_1.do includes/tab_defaultsettings.jsp
includes/P1_00.do
How are you printing this? Do you just have a Filter that wraps
everything and dumps-out the ServletPath for every request? Can you
post the code for that Filter as well as the filter and
filter-mapping configuration you have in web.xml?
I'm just doing a System.out.println() in the doFilter function in the
RequestFilter class to show which page it is. The doFilter function is:
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
if (request instanceof HttpServletRequest) {
final HttpServletRequest httpRequest =
(HttpServletRequest)request;
final Object userBeanObject =
httpRequest.getSession().getAttribute(GenConstants.LOGGED_IN_USER_BEAN);
final String pageName =
httpRequest.getServletPath().replaceAll(/,);
System.out.println(Request Page = +
httpRequest.getServletPath());
if (unsecuredPages.contains(pageName)) {
// don't need any protection
chain.doFilter(request, response);
} else if (!(userBeanObject instanceof UserBean)) {
// no user bean in session do need one, invalidate session
and redirect to login
if (httpRequest.getSession(false) != null) {
httpRequest.getSession().invalidate();
}
((HttpServletResponse)response).sendRedirect(logonPage);
} else {
final UserBean user = (UserBean) userBeanObject;
MapString,LogicalOperation permissions =
(MapString,LogicalOperation)context.getAttribute(GenConstants.PERMISSIONS_MAP);
if(permissions == null) {
PermissionsUtil.setupPermissions(context);
permissions =
(MapString,LogicalOperation)context.getAttribute(GenConstants.PERMISSIONS_MAP);
}
final LogicalOperation requiredOp =
permissions.get(pageName.replaceAll(\\.do,));
if (user.isOperationAllowed(requiredOp)) {
chain.doFilter(request, response);
} else {
if (httpRequest.getSession(false) != null) {
httpRequest.getSession().invalidate();
}
((HttpServletResponse)response).sendRedirect(logonPage);
}
}
}
}
To give you a better idea of what was in the web.xml, here is what's been
taken out:
filter
filter-nameNtlmHttpFilter/filter-name
filter-classjcifs.http.NtlmHttpFilter/filter-class
init-param
param-namejcifs.smb.client.soTimeout/param-name
param-value3/param-value
/init-param
!-- always needed for preauthentication / SMB signatures --
init-param
param-namejcifs.smb.client.domain/param-name
param-valueXXX.LOCAL/param-value
/init-param
!-- SMB message signing requires a valid existing login --
init-param
param-namejcifs.smb.client.username/param-name
param-valueusername/param-value
/init-param
init-param
param-namejcifs.smb.client.password/param-name
param
RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
From: seema...@hotmail.com
To: users@tomcat.apache.org
Subject: RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
Date: Fri, 14 Mar 2014 15:15:04 +
Date: Fri, 14 Mar 2014 08:36:08 -0400
From: ch...@christopherschultz.net
To: users@tomcat.apache.org
Subject: Re: HttpServletRequest Tomcat 5.5.29 to 7.0.52
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Seema,
On 3/14/14, 7:53 AM, Seema Patel wrote:
I have upgraded my tomcat (5.5.29 to 7.0.52) and Java (1.5 to 1.7)
for my struts servlet jsp application. I have also removed all
JCIFS authentication from the WEB-INF/web.xml file and have tried
to do BASIC authentication through Tomcat and the AD (it
authenticates me, but not sure if I've missed anything out, as I've
never done this before).
One question at a time, please ;)
Sorry for the off-loading of multiple questions :-)
I have a doFilter function in my code, which contains
httpServletRequest.getServletPath() call. In the Tomcat 5.5.29 Java
1.5 version, this will work, as when I print
httpServletRequest.getServletPath() i get the following:
P1_00.do P5_0_0.do P5_0_1.do
But in Tomcat 7.0.52 Java 1.7 I get the following from
httpServletRequest.getServletPath() call:
P1_00.do P5_0_0.do P5_0_1.do includes/tab_defaultsettings.jsp
includes/P1_00.do
How are you printing this? Do you just have a Filter that wraps
everything and dumps-out the ServletPath for every request? Can you
post the code for that Filter as well as the filter and
filter-mapping configuration you have in web.xml?
I'm just doing a System.out.println() in the doFilter function in the
RequestFilter class to show which page it is. The doFilter function is:
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
if (request instanceof HttpServletRequest) {
final HttpServletRequest httpRequest =
(HttpServletRequest)request;
final Object userBeanObject =
httpRequest.getSession().getAttribute(GenConstants.LOGGED_IN_USER_BEAN);
final String pageName =
httpRequest.getServletPath().replaceAll(/,);
System.out.println(Request Page = +
httpRequest.getServletPath());
if (unsecuredPages.contains(pageName)) {
// don't need any protection
chain.doFilter(request, response);
} else if (!(userBeanObject instanceof UserBean)) {
// no user bean in session do need one, invalidate session
and redirect to login
if (httpRequest.getSession(false) != null) {
httpRequest.getSession().invalidate();
}
((HttpServletResponse)response).sendRedirect(logonPage);
} else {
final UserBean user = (UserBean) userBeanObject;
MapString,LogicalOperation permissions =
(MapString,LogicalOperation)context.getAttribute(GenConstants.PERMISSIONS_MAP);
if(permissions == null) {
PermissionsUtil.setupPermissions(context);
permissions =
(MapString,LogicalOperation)context.getAttribute(GenConstants.PERMISSIONS_MAP);
}
final LogicalOperation requiredOp =
permissions.get(pageName.replaceAll(\\.do,));
if (user.isOperationAllowed(requiredOp)) {
chain.doFilter(request, response);
} else {
if (httpRequest.getSession(false) != null) {
httpRequest.getSession().invalidate();
}
((HttpServletResponse)response).sendRedirect(logonPage);
}
}
}
}
To give you a better idea of what was in the web.xml, here is what's been
taken out:
filter
filter-nameNtlmHttpFilter/filter-name
filter-classjcifs.http.NtlmHttpFilter/filter-class
init-param
param-namejcifs.smb.client.soTimeout/param-name
param-value3/param-value
/init-param
!-- always needed for preauthentication / SMB signatures --
init-param
param-namejcifs.smb.client.domain/param-name
param-valueXXX.LOCAL/param-value
/init-param
!-- SMB message signing requires a valid existing login --
init-param
param-namejcifs.smb.client.username/param-name
param-valueusername/param-value
/init-param
init-param
param-namejcifs.smb.client.password/param-name
param-valuepassword/param-value
/init-param
!-- Set the logging level --
init-param
param-namejcifs.util.loglevel/param-name
param-value2/param-value
/init-param
!-- allow non-IE browsers
HttpServletRequest Tomcat 5.5.29 to 7.0.52
Hi, I have upgraded my tomcat (5.5.29 to 7.0.52) and Java (1.5 to 1.7) for my struts servlet jsp application. I have also removed all JCIFS authentication from the WEB-INF/web.xml file and have tried to do BASIC authentication through Tomcat and the AD (it authenticates me, but not sure if I've missed anything out, as I've never done this before). I have a doFilter function in my code, which contains httpServletRequest.getServletPath() call. In the Tomcat 5.5.29 Java 1.5 version, this will work, as when I print httpServletRequest.getServletPath() i get the following: P1_00.do P5_0_0.do P5_0_1.do But in Tomcat 7.0.52 Java 1.7 I get the following from httpServletRequest.getServletPath() call: P1_00.do P5_0_0.do P5_0_1.do includes/tab_defaultsettings.jsp includes/P1_00.do This is for the same page I'm calling. I would like to know if something has changed in the way Tomcat 7.0.52 handles this call from the way it used to in 5.5.29. I'm trying to eliminate either Tomcat or Java from this issue, as nothing else has been changed besides the upgrade of these two (except for WEB-INF/web.xml, which may also be the cause, if so, is this something that this group could help me with?). Thanks Seema
RE: HttpServletRequest Tomcat 5.5.29 to 7.0.52
Date: Fri, 14 Mar 2014 08:36:08 -0400
From: ch...@christopherschultz.net
To: users@tomcat.apache.org
Subject: Re: HttpServletRequest Tomcat 5.5.29 to 7.0.52
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Seema,
On 3/14/14, 7:53 AM, Seema Patel wrote:
I have upgraded my tomcat (5.5.29 to 7.0.52) and Java (1.5 to 1.7)
for my struts servlet jsp application. I have also removed all
JCIFS authentication from the WEB-INF/web.xml file and have tried
to do BASIC authentication through Tomcat and the AD (it
authenticates me, but not sure if I've missed anything out, as I've
never done this before).
One question at a time, please ;)
Sorry for the off-loading of multiple questions :-)
I have a doFilter function in my code, which contains
httpServletRequest.getServletPath() call. In the Tomcat 5.5.29 Java
1.5 version, this will work, as when I print
httpServletRequest.getServletPath() i get the following:
P1_00.do P5_0_0.do P5_0_1.do
But in Tomcat 7.0.52 Java 1.7 I get the following from
httpServletRequest.getServletPath() call:
P1_00.do P5_0_0.do P5_0_1.do includes/tab_defaultsettings.jsp
includes/P1_00.do
How are you printing this? Do you just have a Filter that wraps
everything and dumps-out the ServletPath for every request? Can you
post the code for that Filter as well as the filter and
filter-mapping configuration you have in web.xml?
I'm just doing a System.out.println() in the doFilter function in the
RequestFilter class to show which page it is. The doFilter function is:
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
if (request instanceof HttpServletRequest) {
final HttpServletRequest httpRequest = (HttpServletRequest)request;
final Object userBeanObject =
httpRequest.getSession().getAttribute(GenConstants.LOGGED_IN_USER_BEAN);
final String pageName =
httpRequest.getServletPath().replaceAll(/,);
System.out.println(Request Page = +
httpRequest.getServletPath());
if (unsecuredPages.contains(pageName)) {
// don't need any protection
chain.doFilter(request, response);
} else if (!(userBeanObject instanceof UserBean)) {
// no user bean in session do need one, invalidate session and
redirect to login
if (httpRequest.getSession(false) != null) {
httpRequest.getSession().invalidate();
}
((HttpServletResponse)response).sendRedirect(logonPage);
} else {
final UserBean user = (UserBean) userBeanObject;
MapString,LogicalOperation permissions =
(MapString,LogicalOperation)context.getAttribute(GenConstants.PERMISSIONS_MAP);
if(permissions == null) {
PermissionsUtil.setupPermissions(context);
permissions =
(MapString,LogicalOperation)context.getAttribute(GenConstants.PERMISSIONS_MAP);
}
final LogicalOperation requiredOp =
permissions.get(pageName.replaceAll(\\.do,));
if (user.isOperationAllowed(requiredOp)) {
chain.doFilter(request, response);
} else {
if (httpRequest.getSession(false) != null) {
httpRequest.getSession().invalidate();
}
((HttpServletResponse)response).sendRedirect(logonPage);
}
}
}
}
To give you a better idea of what was in the web.xml, here is what's been taken
out:
filter
filter-nameNtlmHttpFilter/filter-name
filter-classjcifs.http.NtlmHttpFilter/filter-class
init-param
param-namejcifs.smb.client.soTimeout/param-name
param-value3/param-value
/init-param
!-- always needed for preauthentication / SMB signatures --
init-param
param-namejcifs.smb.client.domain/param-name
param-valueXXX.LOCAL/param-value
/init-param
!-- SMB message signing requires a valid existing login --
init-param
param-namejcifs.smb.client.username/param-name
param-valueusername/param-value
/init-param
init-param
param-namejcifs.smb.client.password/param-name
param-valuepassword/param-value
/init-param
!-- Set the logging level --
init-param
param-namejcifs.util.loglevel/param-name
param-value2/param-value
/init-param
!-- allow non-IE browsers to use basic auth --
init-param
param-namejcifs.http.insecureBasic/param-name
param-valuetrue/param-value
/init-param
/filter
filter-mapping
filter-nameNtlmHttpFilter/filter-name
url-pattern*.do/url-pattern
/filter
HTTP Status 304 on GET
Hi, I've just upgraded my java from 1.5 to 1.7, tomcat from 5.5.29 to 7.0.50 on the test environment. I have removed all JCIFs authentication from my application and am authenticating users against LDAP through tomcat. I have managed to get my application to load and allow me access, but when I go to different pages I'm getting HTTP 304 in my localhost_access_log file. The log file contains: [12/Feb/2014:12:03:56 +] GET / HTTP/1.1 200 11444 [12/Feb/2014:12:04:23 +] GET /my_application/ HTTP/1.1 200 20972 [12/Feb/2014:12:04:23 +] GET /my_application/css/main.css HTTP/1.1 304 - [12/Feb/2014:12:04:24 +] GET /my_application/css/main.css HTTP/1.1 304 - [12/Feb/2014:12:04:24 +] GET /my_application/js/common.js HTTP/1.1 200 1296 [12/Feb/2014:12:04:24 +] GET /my_application/js/common.js HTTP/1.1 200 1296 [12/Feb/2014:12:04:24 +] GET /my_application/yui/yuiloader-dom-event/yuiloader-dom-event.js HTTP/1.1 304 - [12/Feb/2014:12:04:24 +] GET /my_application/yui/yuiloader/yuiloader-min.js HTTP/1.1 304 - [12/Feb/2014:12:04:24 +] GET /my_application/yui/yahoo/yahoo-min.js HTTP/1.1 304 - [12/Feb/2014:12:04:24 +] GET /my_application/yui/event/event-min.js HTTP/1.1 304 - [12/Feb/2014:12:04:24 +] GET /my_application/yui/dom/dom-min.js HTTP/1.1 304 - [12/Feb/2014:12:04:24 +] GET /my_application/yui/element/element-beta-min.js HTTP/1.1 304 - [12/Feb/2014:12:04:24 +] GET /my_application/yui/dragdrop/dragdrop-min.js HTTP/1.1 304 - [12/Feb/2014:12:04:24 +] GET /my_application/yui/resize/resize-min.js HTTP/1.1 304 - [12/Feb/2014:12:04:24 +] GET /my_application/yui/animation/animation-min.js HTTP/1.1 304 - [12/Feb/2014:12:04:24 +] GET /my_application/yui/layout/layout-min.js HTTP/1.1 304 - etc.. etc... When looking in webapps/my_application/.. at the paths shown above, they all exist. Why is it then showing a 304 error and not loading the pages properly? FYI...YUI version is 2.6.0 in case that makes any difference to this (though in the above error, even the css files are showing the 304 error) Thanks Seema
RE: HTTP Status 304 on GET
Date: Wed, 12 Feb 2014 12:38:33 + From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: HTTP Status 304 on GET On 12/02/2014 12:31, Seema Patel wrote: When looking in webapps/my_application/.. at the paths shown above, they all exist. Why is it then showing a 304 error and not loading the pages properly? FYI...YUI version is 2.6.0 in case that makes any difference to this (though in the above error, even the css files are showing the 304 error) Did you bother to check what an HTTP 304 status code actually means before sending this e-mail? I'll give you a hint, it is NOT an error code. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org I have checked, but when I say error, what I meant is that it's not loading the yui stuff in my application (hence to me an error). Sorry for the confusion, I'm quite new to yui, as it was developed by previous developers and now I've just upgraded the java and tomcat, but can't get the application to work properly Seema
RE: HTTP Status 304 on GET
Subject: Re: HTTP Status 304 on GET From: dmik...@gopivotal.com Date: Wed, 12 Feb 2014 08:02:01 -0500 To: users@tomcat.apache.org On Feb 12, 2014, at 7:48 AM, Seema Patel seema...@hotmail.com wrote: Date: Wed, 12 Feb 2014 12:38:33 + From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: HTTP Status 304 on GET On 12/02/2014 12:31, Seema Patel wrote: When looking in webapps/my_application/.. at the paths shown above, they all exist. Why is it then showing a 304 error and not loading the pages properly? FYI...YUI version is 2.6.0 in case that makes any difference to this (though in the above error, even the css files are showing the 304 error) Did you bother to check what an HTTP 304 status code actually means before sending this e-mail? I'll give you a hint, it is NOT an error code. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org I have checked, but when I say error, what I meant is that it's not loading the yui stuff in my application (hence to me an error). Sorry for the confusion, I'm quite new to yui, as it was developed by previous developers and now I've just upgraded the java and tomcat, but can't get the application to work properly It doesn’t seem like there’s a problem with your server. As Mark mentioned 304 is not an error code. You probably want to debug this through your browser. Try Chrome Dev Tools or Firebug, inspect the requests and see if there are any JS errors. Dan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Ok thanks Dan. I'm using IE 9, as the application seems to work on that when live. Just not working after I updated the java and tomcat versions. Will look at the IE developer tools Seema
RE: Upgrade to Tomcat 7 Issues
Date: Fri, 9 Aug 2013 09:07:12 -0700 From: its_toas...@yahoo.com To: users@tomcat.apache.org Subject: Re: Upgrade to Tomcat 7 Issues On 8/9/2013 8:46 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chuck, On 8/9/13 10:08 AM, Caldarale, Charles R wrote: From: Seema Patel [mailto:seema...@hotmail.com] Subject: RE: Upgrade to Tomcat 7 Issues In my WEB-INF/lib I have the following (sorry the list is quite long): activation.jar In Tomcat7.0/lib directory I have (I have grouped them alphabetically so it doesn't make the list too long downwards, like the above list) activation.jar j2ee.jar You must never, never, never have the same class files in multiple locations in the class loader hierarchy (e.g., activation.jar and several others). I don't think activation is something provided by servlet containers. I don't see it in a stock Tomcat, for example. JavaBeans activation framework (activation.jar) was required for Java mail when running on older versions of the JRE. It has been included since JRE 6 (can't remember the minor version). Since the original poster has upgraded to JRE 7, there should be no need for this JAR either in $CATALINA_HOME/lib or WEB-INF/lib of the application. Also, j2ee.jar must never be present anywhere in any Tomcat installation. I'm not sure what's in this particular j2ee.jar, but you're probably right that it does not belong. The container should provide all services to the webapp. If you want a more fully-functional J2EE container, consider Apache TomEE. You need to start over, not adding anything to Tomcat's lib directory, and try running your webapp. Absolutely. - -chris . . . . just my two cents. /mde/ Right, I've re-installed Tomcat 7.0.42. The only things I've changed are in the server.xml file, here is what's in the server.xml file (what I have added/changed are in red, one being the connector port - from 8080 to 8088 and the other is adding the realm tag/element just before the Host tag/element): Server port=8005 shutdown=SHUTDOWN !-- Security listener. Documentation at /docs/config/listeners.html Listener className=org.apache.catalina.security.SecurityListener / -- !--APR library loader. Documentation at /docs/apr.html -- Listener SSLEngine=on className=org.apache.catalina.core.AprLifecycleListener/ !--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html -- Listener className=org.apache.catalina.core.JasperListener/ !-- Prevent memory leaks due to use of particular java/javax APIs-- Listener className=org.apache.catalina.core.JreMemoryLeakPreventionListener/ Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener/ Listener className=org.apache.catalina.core.ThreadLocalLeakPreventionListener/ !-- Global JNDI resources Documentation at /docs/jndi-resources-howto.html -- GlobalNamingResources !-- Editable user database that can also be used by UserDatabaseRealm to authenticate users -- Resource auth=Container description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory name=UserDatabase pathname=conf/tomcat-users.xml type=org.apache.catalina.UserDatabase/ /GlobalNamingResources !-- A Service is a collection of one or more Connectors that share a single Container Note: A Service is not itself a Container, so you may not define subcomponents such as Valves at this level. Documentation at /docs/config/service.html -- Service name=Catalina !--The connectors can use a shared executor, you can define one or more named thread pools-- !-- Executor name=tomcatThreadPool namePrefix=catalina-exec- maxThreads=150 minSpareThreads=4/ -- !-- A Connector represents an endpoint by which requests are received and responses are returned. Documentation at : Java HTTP Connector: /docs/config/http.html (blocking non-blocking) Java AJP Connector: /docs/config/ajp.html APR (HTTP/AJP) Connector: /docs/apr.html Define a non-SSL HTTP/1.1 Connector on port 8080 -- Connector connectionTimeout=2 port=8088 protocol=HTTP/1.1 redirectPort=8443/ !-- A Connector using the shared thread pool-- !-- Connector executor=tomcatThreadPool port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / -- !-- Define a SSL HTTP/1.1 Connector on port 8443 This connector uses the JSSE configuration, when using APR, the connector should be using the OpenSSL style configuration described in the APR documentation -- !-- Connector port=8443 protocol=HTTP/1.1 SSLEnabled=true maxThreads=150 scheme=https secure=true clientAuth=false sslProtocol=TLS
RE: Upgrade to Tomcat 7 Issues
Sorry, I didn't realise it wouls remove the highlighted red. This is what I
have changed from 8080 to 8088:
Connector connectionTimeout=2 port=8088 protocol=HTTP/1.1
redirectPort=8443/
This is what I have added just above the Host tag/element:
Realm className=org.apache.catalina.realm.JNDIRealm
connectionURL=xxx://xxx:3268
connectionName=xxx@xxx.local connectionPassword=xxx
referrals=follow userBase=dc=xxx,dc=local
userSearch=(sAMAccountName={0}) userSubtree=true
roleBase=dc=xxx,dc=local roleSearch=(member={0})
roleName=cn roleSubtree=true /
Sorry again about that.
Date: Mon, 12 Aug 2013 12:05:51 +0200
From: a...@ice-sa.com
To: users@tomcat.apache.org
Subject: Re: Upgrade to Tomcat 7 Issues
Seema Patel wrote:
...
Right, I've re-installed Tomcat 7.0.42. The only things I've changed are
in the server.xml file, here is what's in the server.xml file (what I have
added/changed are in red,
Not the easiest to spot, for a list which works only with plain text messages
and strips
most attachments.
Please check the recommendations in http://tomcat.apache.org/lists.html
...
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Upgrade to Tomcat 7 Issues
: a...@ice-sa.com To: users@tomcat.apache.org Subject: Re: Upgrade to Tomcat 7 Issues Seema Patel wrote: ... Right, I've re-installed Tomcat 7.0.42. The only things I've changed are in the server.xml file, here is what's in the server.xml file (what I have added/changed are in red, Not the easiest to spot, for a list which works only with plain text messages and strips most attachments. Please check the recommendations in http://tomcat.apache.org/lists.html ... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Upgrade to Tomcat 7 Issues
Date: Mon, 12 Aug 2013 14:00:12 +0200 From: ognjen.d.blagoje...@gmail.com To: users@tomcat.apache.org Subject: Re: Upgrade to Tomcat 7 Issues Seema, On 12.8.2013 13:09, Seema Patel wrote: org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC driver class 'com.mysql.jdbc.Driver' ... Caused by: java.lang.ClassNotFoundException: com.mysql.jdbc.Driver You are doing fine. You correctly removed all the jar files as Chuck suggested. Now you need to add them one by one EITHER to Tomcat lib folder or webapp WEB-INF/lib folder. Since your configuration implies that Tomcat will be managing your DB connection pool, add mysql-connector jar to Tomcat lib folder, and try to restart Tomcat. -Ognjen Thanks for the advise. I have now fixed the issue and it is working. I added the mysql-connector-java-5.0.8-bin to my project's lib directory, which has put it into WEB-INF/lib directory when built and deployed. Thanks to all that have helped me with this, its appreciated. Seema - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Upgrade to Tomcat 7 Issues
Hi, I've upgraded my tomcat from 5.5 to 7.0. I've also upgraded the jre from 1.5 to 7. I'm trying to get my existing struts/servlets projects to run, but I'm getting the following error when running tomcat in my tomcat7-stderr...log file: INFO: Deploying configuration descriptor C:\Tomcat 7.0\conf\Catalina\localhost\common.xml 09-Aug-2013 10:11:44 org.apache.catalina.core.ContainerBase addChildInternal SEVERE: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/common]] at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:656) at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1635) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.NoSuchMethodError: javax.servlet.ServletContext.getSessionCookieConfig()Ljavax/servlet/SessionCookieConfig; at org.apache.catalina.deploy.WebXml.configureContext(WebXml.java:1374) at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1346) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:878) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:376) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5322) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) ... 11 more Any ideas? Have I missed something? Thanks Seema
RE: Upgrade to Tomcat 7 Issues
In my WEB-INF/lib I have the following (sorry the list is quite long):
activation.jar
axis.jar
BTDslCheckerLib.jar (this is one of our java projects)
commons-beanutils.jar
commons-codec-1.3.jar
commons-collections.jar
commons-digester.jar
commons-discovery-0.2.jar
commons-fileupload.jar
common-httpclient-3.0.1.jar
commons-logging-1.0.4.jar
commons-validator.jar
ditchnet-tabs-taglib.jar
itext-1.4.jar
jaxen-core.jar
jaxen-jdom.jar
jaxrpc.jar
jbossall-client.jar
jcifs-1.2.17dynamic-dc.jar
jcifs-1.3.17.jar
jdom.jar
jstl.jar
log4j-1.2.13.jar
mail.jar
poi-2.5.1-final-20040804.jar
poi-3.7-20101029.jar
poi-contrib-2.5.1-final-20040804.jar
saaj.jar
saxpath.jar
SOPortalCommon.jar (this is one of our java projects)
standard.jar
struts.jar
struts-el.jar
commonlib.jar (this is one of our java projects)
portalcommonlib.jar (this is one of our java projects)
wsclients.jar (this is one of our java projects)
wsdl4j-1.5.1.jar
yahoo-toolkit.jar (this is one of our java projects that uses the yahoo toolkit
yui stuff)
In terms of upgrading, I downloaded jre7 and installed it, changed the projects
to use jre7 and in eclipse I pointed the installed JREs to use jre7.
I then downloaded Tomcat7, changed the server.xml file to have the Resource
tags/elements in GlobalNamingResources tag to point to my databases (9 Resource
tags in total, all taken from the server.xml file in Tomcat 5.5). In Service
tag/element, I have added the following:
Connector port=8088
maxHttpHeaderSize=8192 maxThreads=150 minSpareThreads=10
enableLookups=false redirectPort=8443
acceptCount=100 connectionTimeout=2
disableUploadTimeout=true /
I have commented out:
Connector connectionTimeout=2 port=8088 protocol=HTTP/1.1
redirectPort=8443/
In the Engine tag/element I have added:
Realm className=org.apache.catalina.realm.JNDIRealm
connectionURL=ldap://xxx:3268;
connectionName=xxx@xxx.local connectionPassword=xxx
referrals=follow userBase=dc=xxx,dc=local
userSearch=(sAMAccountName={0}) userSubtree=true
roleBase=dc=xxx,dc=local roleSearch=(member={0})
roleName=cn roleSubtree=true /
which is just before the Host tag/element.
In Tomcat7.0/lib directory I have (I have grouped them alphabetically so it
doesn't make the list too long downwards, like the above list) (some of which I
have added, but not sure if they're needed):
activation.jar, annotations-api.jar
catalina.jar, catalina-ant.jar, catalina-ha.jar, catalina-tribes.jar
ecj-4.2.2.jar, el-api.jar
j2ee.jar
jasper.jar, jasper-el.jar
jaxen-core.jar, jaxen-jdom.jar, jdom.jar, jsp.jar, jtds-1.2.jar
log4j-1.2.13.jar
mysql-connector-java-5.0.8-bin.jar
naming-factory.jar, naming-facotry-dbcp.jar, naming-resources.jar
servlet-api.jar
tomcat-api.jar, tomcat-coyote.jar, tomcat-dbcp.jar, tomcat-i18n-es.jar,
tomcat-i18n-fr.jar, tomcat-i18n-ja.jar, tomcat-jdbc.jar, tomcat-util.jar
xmlrpc-1.2-b1.jar
I believe that's everything I have done, but I may have left something out, as
I have been trying to get it working for the pass 2 days and may have changed
something that I don't remember. If there is anything more you need to know
then please let me know.
Thanks
Seema
Date: Fri, 9 Aug 2013 09:07:48 -0400
From: ch...@christopherschultz.net
To: users@tomcat.apache.org
Subject: Re: Upgrade to Tomcat 7 Issues
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Seema,
On 8/9/13 5:17 AM, Seema Patel wrote:
I've upgraded my tomcat from 5.5 to 7.0. I've also upgraded the jre
from 1.5 to 7.
I'm trying to get my existing struts/servlets projects to run, but
I'm getting the following error when running tomcat in my
tomcat7-stderr...log file:
INFO: Deploying configuration descriptor C:\Tomcat
7.0\conf\Catalina\localhost\common.xml 09-Aug-2013 10:11:44
org.apache.catalina.core.ContainerBase addChildInternal SEVERE:
ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/common]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:656)
at
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1635)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at
java.util.concurrent.FutureTask.run(Unknown Source) at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source) at
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source
RE: Upgrade to Tomcat 7 Issues
Ok thanks for the help. I'll redo it again. If I get any further errors I'll post a new question. Thanks again. Seema From: chuck.caldar...@unisys.com To: users@tomcat.apache.org Date: Fri, 9 Aug 2013 09:08:55 -0500 Subject: RE: Upgrade to Tomcat 7 Issues From: Seema Patel [mailto:seema...@hotmail.com] Subject: RE: Upgrade to Tomcat 7 Issues In my WEB-INF/lib I have the following (sorry the list is quite long): activation.jar In Tomcat7.0/lib directory I have (I have grouped them alphabetically so it doesn't make the list too long downwards, like the above list) activation.jar j2ee.jar You must never, never, never have the same class files in multiple locations in the class loader hierarchy (e.g., activation.jar and several others). Also, j2ee.jar must never be present anywhere in any Tomcat installation. You need to start over, not adding anything to Tomcat's lib directory, and try running your webapp. If it fails, determine why, and decide where the necessary .jar file should go (the answer is almost always WEB-INF/lib, except for JDBC drivers when Tomcat is handling the connection pooling). - 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
java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for xxx
Hi,
I am not sure if this is the right List to post this on, please advise if it
isn't and let me know where is best to post.
I am getting the following error on one of our applications running on our
intranet:
2013-07-31 17:15:11,180 [http-xxx.xxx.x.xxx-xx-x] ERROR
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/forms].[action]
- Servlet.service() for servlet action threw exception
java.net.UnknownHostException: Failed to negotiate with a suitable domain
controller for xxx.LOCAL
at jcifs.smb.SmbSession.getChallengeForDomain(SmbSession.java:187)
at jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:150)
at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:114)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:465)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:393)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at
org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:837)
at
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:640)
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1287)
at java.lang.Thread.run(Unknown Source)
In my tomcat/conf/server.xml file I have:
Realm className=com.viatel.tomcatrealms.ADJNDIRealm
debug=01 resourceName=ActiveDirectory
connectionURL=ldap://xxx:xxx;
alternativeURL=ldap://xxx:xxx;
connectionName=LDAP@xxx.local connectionPassword=xxx
referrals=follow userBase=dc=vtlwavenet,dc=local
userSearch=(sAMAccountName={0}) userSubtree=true
roleBase=dc=xxx,dc=local roleSearch=(member={0})
roleName=cn roleSubtree=true /
I have 2 .war files running from this tomcat - 1) intranet portal A, 2)
intranet helpdesk page and also another intranet portal B (both run from
slightly different URLs).
When tomcat was restarted the intranet portal A runs, intranet portal B runs
but the intranet helpdesk portal doesn't run. For this we get the error
message shown above.
I don't know if it is the java code, some setting in the tomcat catalina base
or if it is a tomcat network issue.
We are running Tomcat 5.5.29.
java version 1.5.0_22
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_22-b03)
Java HotSpot(TM) Client VM (build 1.5.0_22-b03, mixed mode, sharing)
It is on a Windows Server 2003 R2 SP2 VM box.
Any help on this is appreciated.
Thanks in advance
Seema
RE: java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for xxx
Date: Thu, 1 Aug 2013 12:06:39 +0200 From: a...@ice-sa.com To: users@tomcat.apache.org Subject: Re: java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for xxx Seema Patel wrote: Hi, I am not sure if this is the right List to post this on, please advise if it isn't and let me know where is best to post. I am getting the following error on one of our applications running on our intranet: 2013-07-31 17:15:11,180 [http-xxx.xxx.x.xxx-xx-x] ERROR org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/forms].[action] - Servlet.service() for servlet action threw exception java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for xxx.LOCAL at jcifs.smb.SmbSession.getChallengeForDomain(SmbSession.java:187) at jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:150) at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:114) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:465) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:393) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:837) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:640) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1287) at java.lang.Thread.run(Unknown Source) I believe that you should read this page carefully, in particular the blue text at the beginning : http://jcifs.samba.org/src/docs/ntlmhttpauth.html Can you have a look at the WEB-INF/web.xml file *of your application*, and check if there is a servlet filter configured there, which matches the name above ? If so, make a backup copy of that web.xml file, and then edit it to remove that filter from it, and try again. I am not quite sure, but it looks possible to me that you have a duplicate authentication mechanism in use : one at the container (Tomcat) level, and one at the application level. And the one used at the application level is obsolete, unsupported, unmaintained etc.. I have found out that JCIFS is no longer supported, but it will take a lot of time, development and resources to update it to the recommended Jespa. In my web.xml file I have the following: filter filter-nameNtlmHttpFilter/filter-name filter-classjcifs.http.NtlmHttpFilter/filter-class !-- always needed for preauthentication / SMB signatures -- init-param param-namejcifs.smb.client.domain/param-name param-valuexxx/param-value /init-param !-- SMB message signing requires a valid existing login -- init-param param-namejcifs.smb.client.username/param-name param-valuexxx/param-value /init-param init-param param-namejcifs.smb.client.password/param-name param-valuexxx/param-value /init-param !-- Set the logging level -- init-param param-namejcifs.util.loglevel/param-name param-value3/param-value /init-param !-- allow non-IE browsers to use basic auth -- init-param param-namejcifs.http.insecureBasic/param-name param-valuetrue/param-value /init-param /filter filter filter-nameHRADGroupFilter/filter-name filter-classxxx.ADGroupFilter/filter-class init-param param-nameAllowedGroups/param-name param-valueG-HR,G-MIS/param-value /init-param /filter filter filter-nameSuggestionsGroupFilter/filter-name filter-classxxx.ADGroupFilter/filter-class init-param param-nameAllowedGroups/param-name param-valuexxx, xxx/param-value /init-param /filter filter-mapping filter-nameNtlmHttpFilter/filter-name url-pattern/suggestions/*/url-pattern /filter-mapping filter-mapping filter-nameSuggestionsGroupFilter/filter-name url-pattern/suggestions/*/url-pattern /filter-mapping filter-mapping filter
RE: java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for xxx
Date: Thu, 1 Aug 2013 15:55:37 +0200 From: a...@ice-sa.com To: users@tomcat.apache.org Subject: Re: java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for xxx Seema Patel wrote: Date: Thu, 1 Aug 2013 12:06:39 +0200 From: a...@ice-sa.com To: users@tomcat.apache.org Subject: Re: java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for xxx Seema Patel wrote: Hi, I am not sure if this is the right List to post this on, please advise if it isn't and let me know where is best to post. I am getting the following error on one of our applications running on our intranet: 2013-07-31 17:15:11,180 [http-xxx.xxx.x.xxx-xx-x] ERROR org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/forms].[action] - Servlet.service() for servlet action threw exception java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for xxx.LOCAL at jcifs.smb.SmbSession.getChallengeForDomain(SmbSession.java:187) at jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:150) at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:114) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:465) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:393) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:837) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:640) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1287) at java.lang.Thread.run(Unknown Source) I believe that you should read this page carefully, in particular the blue text at the beginning : http://jcifs.samba.org/src/docs/ntlmhttpauth.html Can you have a look at the WEB-INF/web.xml file *of your application*, and check if there is a servlet filter configured there, which matches the name above ? If so, make a backup copy of that web.xml file, and then edit it to remove that filter from it, and try again. I am not quite sure, but it looks possible to me that you have a duplicate authentication mechanism in use : one at the container (Tomcat) level, and one at the application level. And the one used at the application level is obsolete, unsupported, unmaintained etc.. I have found out that JCIFS is no longer supported, but it will take a lot of time, development and resources to update it to the recommended Jespa. In my web.xml file I have the following: filter filter-nameNtlmHttpFilter/filter-name filter-classjcifs.http.NtlmHttpFilter/filter-class !-- always needed for preauthentication / SMB signatures -- init-param param-namejcifs.smb.client.domain/param-name param-valuexxx/param-value /init-param !-- SMB message signing requires a valid existing login -- init-param param-namejcifs.smb.client.username/param-name param-valuexxx/param-value /init-param init-param param-namejcifs.smb.client.password/param-name param-valuexxx/param-value /init-param !-- Set the logging level -- init-param param-namejcifs.util.loglevel/param-name param-value3/param-value /init-param !-- allow non-IE browsers to use basic auth -- init-param param-namejcifs.http.insecureBasic/param-name param-valuetrue/param-value /init-param /filter filter filter-nameHRADGroupFilter/filter-name filter-classxxx.ADGroupFilter/filter-class init-param param-nameAllowedGroups/param-name param-valueG-HR,G-MIS/param-value /init-param /filter filter filter-nameSuggestionsGroupFilter/filter-name filter-classxxx.ADGroupFilter/filter-class init-param param-nameAllowedGroups/param-name param-valuexxx, xxx/param
