Actually, I may be understanding why it's not working for you. So if you have a policy embedded in WSDL and PolicyBasedWSS4JInInterceptor usually does all the work. However, if it's only a UsernameToken policy that is used then UsernameTokenInterceptor is used to do the actual processing, as an optimization.
So here is a summary : 1. WSS4JInInterceptor is configured directly in java-first cases 2. PolicyBasedWSS4JInInterceptor is used when the policy is embedded in WSDL 3. UsernameTokenInterceptor is used when the policy which is embedded in WSDL contains only a UT assertion As it happens, the "ws-security.ut.no-callbacks" property is ignored in case 3. Can you add yet another breakpoint in UsernameTokenInterceptor ? If you confirm UsernameTokenInterceptor is used then I'll let you know how to intercept the flow with a UsernameTokenInterceptor subclass (hack really) and will do a minor fix to ensure the "ws-security.ut.no-callbacks" works for 3. as well Cheers, Sergey On Fri, Feb 4, 2011 at 11:52 AM, Sergey Beryozkin <[email protected]>wrote: > Hi Anand > > On Fri, Feb 4, 2011 at 6:50 AM, Anand R <[email protected]> wrote: > >> Hi Sergey, >> >> As you mentioned, I added a breakpoint within >> WSS4JInInterceptor.handleMessage(). The web service invocation didn't >> hit the breakpoint. >> WSS4JInInterceptor wasn't present in the chain of interceptors. I added >> this interceptor explicitly in my beans.xml. >> > > > I think I know what is happening. Given a policy is contained in WSDL, > PolicyBasedWSS4JInInterceptor is used, it extends WSS4JInInterceptor, CXF > adds it itself. Can you give it another try please, remove the explicit > WSS4JInInterceptor and add a breakpoint in > PolicyBasedWSS4JInInterceptor.handleMessage ? > > > Now I am getting the following exception. >> >> I also tried extending AbstractUsernameTokenAuthenticatingInterceptor. I >> am getting the same exception(No security action was defined!). >> I tried setting ws-security.ut.no-callbacks on and off. Both result in the >> same exception. >> >> I didn't understand what action is being referred here. I am attaching my >> wsdl for your reference. Is this problem anything to do with my policy >> specification? >> >> The wsdl is fine. As I briefly mentioned, the older >> AbstractUsernameTokenAuthenticatingInterceptor > does not work well with the wsdl first case. It is actually a > WSS4JInInterceptor > subclass and does all sort of hacks to hide the complexity from the user and > provide an (unwrapped) UT to the concrete implementations. However > PolicyBasedWSS4JInInterceptor is used instead when the actions are > 'embedded' inside a given policy, so registering > AbstractUsernameTokenAuthenticatingInterceptor duplicates > PolicyBasedWSS4JInInterceptor > (you still need to configure the actions even though > PolicyBasedWSS4JInInterceptor knows them from WSDL). I updated it to > continue working in the wsdl-first case (provided the no-callbacks property > is set) just to minimize the side-effects for the users already doing > concrete AbstractUsernameTokenAuthenticatingInterceptor impls. > AbstractUsernameTokenAuthenticatingInterceptor > is ok for java-first cases but the newer AbstractUsernameTokenInterceptor > will work for all the cases. > > Check please PolicyBasedWSS4JInInterceptor.handleMessage > > thanks, Sergey > > >> >> >> org.apache.cxf.binding.soap.SoapFault: No security action was defined! >> at >> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.getAction(WSS4JInInterceptor.java:471) >> at >> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:196) >> at >> org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor.handleMessage(AbstractUsernameTokenAuthenticatingInterceptor.java:96) >> at >> org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor.handleMessage(AbstractUsernameTokenAuthenticatingInterceptor.java:67) >> at >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255) >> at >> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113) >> at >> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97) >> at >> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461) >> at >> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188) >> at >> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148) >> at >> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179) >> at >> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) >> at >> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159) >> at >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) >> at >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) >> at >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) >> at >> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) >> at >> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) >> at >> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) >> at >> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) >> at >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) >> at >> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) >> at >> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) >> at >> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) >> at java.lang.Thread.run(Thread.java:595) >> >> >> Thanks and regards, >> Anand >> >> >> >> From: Sergey Beryozkin <[email protected]> >> To: [email protected] >> Date: 03-02-11 07:28 PM >> Subject: Re: Problem with AbstractUsernameTokenInInterceptor >> ------------------------------ >> >> >> >> Hi - I do not understand why it not works. I've checked the code and I see >> that no test involving a hashed password exists. Likewise I don't >> understand >> why it works at the same time with clear passwords and no callbacks. >> I'm a bit busy right now, is there any chance that you could download the >> source for CXF 2.3.2, remove the ServerCallback property and just add a >> breakpoint in WSS4JInInterceptor.handleMessage() ? >> >> I think you're on the right track. I do not see other options for dealing >> with *hashed passwords*, well, unless you;re prepared to do some hacks by >> doing the container-managed authentication from the callback itself but >> that >> would not let you register the proper security context because the one >> which >> is created by the WSS4JInInterceptor has only a (WSS4J-created) Principal >> registered, i.e, no info about roles is available. >> >> I'd definitely follow this route myself. >> Note that AbstractUsernameTokenAuthenticatingInterceptor (in the >> ws-security >> module) is the other, legacy interceptor that you may also extend - as far >> as I know, a 3rd-party container has a test for a hashed UT involving this >> particular interceptor. No need to set the "ws-security.ut.no-callbacks", >> unless you have a wsdl-first case. Concrete implementations need to extend >> a >> method with several UT-related parameters which is a bit brittle in that >> adding more parameters to the >> AbstractUsernameTokenAuthenticatingInterceptor >> will break the users' interceptors. >> >> Thus extending AbstractUsernameTokenInterceptor (in rt/core/.../security) >> is >> recommended because we can easily update CXF UsernameToken bean with the >> new >> properties ((say the UT salt property, etc)) without the existing users >> noticing. >> >> Debug it if you can - it would help >> >> Sergey >> >> >> >> On Thu, Feb 3, 2011 at 1:02 PM, Anand R <[email protected]> wrote: >> >> > Hi Sergey, >> > >> > As you had mentioned earlier, the namespace is >> > >> > >> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd >> > >> > Please find the SOAP request message below. >> > >> > Actually, my requirement is to obtain the username and password from the >> > SOAP header to perform container authentication and then associate the >> > Subject with the current thread of execution. Am I using the correct >> > approach or do I just need to write a SOAPHeaderInterceptor and get the >> > required headers. >> > >> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> >> > <soap:Header> >> > <wsse:Security soap:mustUnderstand="1" >> > xmlns:wsse=" >> > >> > >> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd >> > "> >> > <wsse:UsernameToken xmlns:wsse=" >> > >> > >> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd >> > " >> > xmlns:wsu=" >> > >> > >> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd >> > " >> > wsu:Id="UsernameToken-1"> >> > <wsse:Username>libuser</wsse:Username> >> > <wsse:Password >> > Type=" >> > >> > >> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest >> > ">K8k05oxjNDqbmQZjg33bwa9/oX0=</wsse:Password> >> > <wsse:Nonce EncodingType=" >> > >> > >> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary >> > ">L1Y86osooUEy96lwoEzpGQ==</wsse:Nonce> >> > <wsu:Created>2011-02-03T12:32:27.752Z</ >> > wsu:Created> >> > </wsse:UsernameToken> >> > </wsse:Security> >> > </soap:Header> >> > <soap:Body> >> > <ns2:doEcho xmlns:ns2=" >> http://types.echo.wssecurity.learn/ >> > "> >> > <arg0> >> > <echoString>Hello >> WS-Security</echoString> >> > </arg0> >> > </ns2:doEcho> >> > </soap:Body> >> > </soap:Envelope> >> > Thanks and regards, >> > Anand R >> > >> > >> > >> > From: Sergey Beryozkin <[email protected]> >> > To: [email protected] >> > Date: 03-02-11 05:13 PM >> > Subject: Re: Problem with AbstractUsernameTokenInInterceptor >> > >> > >> > >> > Hi >> > >> > WSS4JInInterceptor is already registering a custom UT processor if the >> > "ws-security.ut.no-callbacks" is set to true. >> > So the hashed UTs should be supported with your configuration, without >> the >> > need to register a callback. >> > Can you give me a favor and check the actual WS-Security namespace that >> is >> > used to qualify the security header ? You can add a CXF logging feature >> to >> > the list of jaxws:features >> > >> > thanks, Sergey >> > >> > On Thu, Feb 3, 2011 at 11:33 AM, Anand R <[email protected]> >> wrote: >> > >> > > Thanks Sergy. I will try the custom UsernameTokenProcessor. >> > > Thanks and regards, >> > > Anand R >> > > >> > > >> > > >> > > From: Sergey Beryozkin <[email protected]> >> > > To: [email protected] >> > > Date: 03-02-11 04:39 PM >> > > Subject: Re: Problem with AbstractUsernameTokenInInterceptor >> > > >> > > >> > > >> > > Hi >> > > >> > > What WS-Security namespace is being used in the request ? >> > > If the "ws-security.ut.no-callbacks" is set to true then the >> > > org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor should not >> be >> > > invoked because it does currently require a callback for hashed UTs. >> So >> > if >> > > the property is set then the WSS4JInInterceptor registers a custom >> > > UsernameTokenProcessor for >> > > >> > > " >> > > >> > > >> > >> > >> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd >> > >> > > >> > > " >> > > and >> > > "http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd";. >> > > >> > > Thanks, Sergey >> > > >> > > On Thu, Feb 3, 2011 at 10:51 AM, Anand R <[email protected]> >> wrote: >> > > >> > > > Hi Sergey, >> > > > >> > > > Thanks for your response. I used to get the following exception when >> I >> > > did >> > > > not configure a callback handler. This exception does not come if >> the >> > > > password is plain text instead of a digest. >> > > > >> > > > org.apache.cxf.interceptor.Fault: General security error >> > > > (WSSecurityEngine: No password callback supplied) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:154) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:114) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.handleMessage(UsernameTokenInterceptor.java:72) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103) >> > > > at >> javax.servlet.http.HttpServlet.service(HttpServlet.java:710) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) >> > > > at >> > > > >> > > >> > >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) >> > > > at >> > > > >> > > >> > >> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) >> > > > at >> > > > >> > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) >> > > > at java.lang.Thread.run(Thread.java:595) >> > > > Caused by: org.apache.ws.security.WSSecurityException: General >> > security >> > > > error (WSSecurityEngine: No password callback supplied) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:91) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.getPrincipal(UsernameTokenInterceptor.java:167) >> > > > at >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processUsernameToken(UsernameTokenInterceptor.java:129) >> > > > ... 24 more >> > > > >> > > > >> > > > Thanks and regards, >> > > > Anand R >> > > > System Architect >> > > > IBS Software Services Private Limited >> > > > 2nd Floor - Left Wing, IBS Towers, Technopark Campus, Trivandrum - >> > > 695581, >> > > > Kerala, India >> > > > Telephone - +91-471-6614291, Mobile - +91-9846324022 >> > > > E-Mail - [email protected], www.ibsplc.com >> > > > >> > > > >> > > > >> > > > >> > > > From: Sergey Beryozkin <[email protected]> >> > > > To: [email protected] >> > > > Date: 03-02-11 04:08 PM >> > > > Subject: Re: Problem with AbstractUsernameTokenInInterceptor >> > > > >> > > > >> > > > >> > > > Hi >> > > > >> > > > On Thu, Feb 3, 2011 at 6:37 AM, Anand R <[email protected]> >> > wrote: >> > > > >> > > > > Hi, >> > > > > >> > > > > My requirement is to perform a custom authentication on the >> username >> > > and >> > > > > password that I receive as part of the UsernameToken header in the >> > > > > incoming SOAP request. I discovered that cxf-2.3.2 provides an >> > > > > AbstractUsernameTokenInInterceptor to perform this. I extended >> this >> > > > class >> > > > > and created my interceptor that overrides the createSubject >> method. >> > > When >> > > > I >> > > > > configure my interceptor in my beans.xml as shown below, I am >> > getting >> > > an >> > > > > exception. >> > > > > >> > > > > This exception comes up when I use a password digest. The plain >> text >> > > > > password works fine. Is there any problem in the way I have >> > configured >> > > > my >> > > > > interceptor? >> > > > > >> > > > > >> > > > > Entry in beans.xml >> > > > > >> > > > > <jaxws:endpoint id="echo" >> > > > > implementor="learn.wssecurity.echo.EchoServiceImpl" >> > > > > wsdlLocation="wsdl/echo/EchoService.wsdl" >> > > > > address="/EchoService"> >> > > > > <jaxws:inInterceptors> >> > > > > <bean >> > > > > class="learn.wssecurity.echo.WSSUsernameTokenInterceptor"/> >> > > > > </jaxws:inInterceptors> >> > > > > <jaxws:properties> >> > > > > <entry key="ws-security.callback-handler" >> > > > > value="learn.wssecurity.echo.ServerPasswordCallback" /> >> > > > > <entry key="ws-security.ut.no-callbacks" >> > > > > value="true" /> >> > > > > </jaxws:properties> >> > > > > </jaxws:endpoint> >> > > > > >> > > > > >> > > > >> > > > What is the purpose of registering ServerPasswordCallback ? If you >> set >> > a >> > > > "ws-security.ut.no-callbacks" property then you only need a callback >> > if >> > > > you >> > > > have an encrypted UT, so that the UT can be decrypted. >> > > > So this callback that you're registering may be interfering in the >> > case >> > > > when >> > > > you have a hashed UT token, can you remove it please and see what >> > > happens >> > > > ? >> > > > >> > > > Cheers, Sergey >> > > > >> > > > >> > > > >> > > > >> > > > > >> > > > > Exception >> > > > > >> > > > > java.lang.SecurityException: Security Token is not available on >> the >> > > > > current message >> > > > > at >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.reportSecurityException(AbstractSecurityContextInInterceptor.java: >> > > > > 88) >> > > > > at >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor.handleMessage(AbstractSecurityContextInInterceptor.java:47) >> > > > > at >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255) >> > > > > at >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113) >> > > > > at >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97) >> > > > > at >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461) >> > > > > at >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188) >> > > > > at >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148) >> > > > > at >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179) >> > > > > at >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103) >> > > > > at >> > javax.servlet.http.HttpServlet.service(HttpServlet.java:710) >> > > > > at >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159) >> > > > > at >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) >> > > > > at >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) >> > > > > at >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) >> > > > > at >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) >> > > > > at >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) >> > > > > at >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) >> > > > > at >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) >> > > > > at >> > > > > >> > > > >> > > >> > >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) >> > > > > at >> > > > > >> > > > >> > > >> > >> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) >> > > > > at >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) >> > > > > at >> > > > > >> > > >> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) >> > > > > at java.lang.Thread.run(Thread.java:595) >> > > > > >> > > > > Thanks and regards, >> > > > > Anand R >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > DISCLAIMER: >> > > > > >> > > > > "The information in this e-mail and any attachment is intended >> only >> > > for >> > > > > the person to whom it is addressed and may contain confidential >> > and/or >> > > > > privileged material. If you have received this e-mail in error, >> > kindly >> > > > > contact the sender and destroy all copies of the original >> > > communication. >> > > > > IBS makes no warranty, express or implied, nor guarantees the >> > > accuracy, >> > > > > adequacy or completeness of the information contained in this >> email >> > or >> > > > any >> > > > > attachment and is not liable for any errors, defects, omissions, >> > > viruses >> > > > > or for resultant loss or damage, if any, direct or indirect." >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > DISCLAIMER: >> > > > >> > > > "The information in this e-mail and any attachment is intended only >> > for >> > > > the person to whom it is addressed and may contain confidential >> and/or >> > > > privileged material. If you have received this e-mail in error, >> kindly >> > > > contact the sender and destroy all copies of the original >> > communication. >> > > > IBS makes no warranty, express or implied, nor guarantees the >> > accuracy, >> > > > adequacy or completeness of the information contained in this email >> or >> > > any >> > > > attachment and is not liable for any errors, defects, omissions, >> > viruses >> > > > or for resultant loss or damage, if any, direct or indirect." >> > > > >> > > > >> > > > >> > > > >> > > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > DISCLAIMER: >> > > >> > > "The information in this e-mail and any attachment is intended only >> for >> > > the person to whom it is addressed and may contain confidential and/or >> > > privileged material. If you have received this e-mail in error, kindly >> > > contact the sender and destroy all copies of the original >> communication. >> > > IBS makes no warranty, express or implied, nor guarantees the >> accuracy, >> > > adequacy or completeness of the information contained in this email or >> > any >> > > attachment and is not liable for any errors, defects, omissions, >> viruses >> > > or for resultant loss or damage, if any, direct or indirect." >> > > >> > > >> > > >> > > >> > > >> > >> > >> > >> > >> > >> > >> > >> > DISCLAIMER: >> > >> > "The information in this e-mail and any attachment is intended only for >> > the person to whom it is addressed and may contain confidential and/or >> > privileged material. If you have received this e-mail in error, kindly >> > contact the sender and destroy all copies of the original communication. >> > IBS makes no warranty, express or implied, nor guarantees the accuracy, >> > adequacy or completeness of the information contained in this email or >> any >> > attachment and is not liable for any errors, defects, omissions, viruses >> > or for resultant loss or damage, if any, direct or indirect." >> > >> > >> > >> > >> > >> >> >> >> >> >> >> >> DISCLAIMER: >> >> "The information in this e-mail and any attachment is intended only for >> the person to whom it is addressed and may contain confidential and/or >> privileged material. If you have received this e-mail in error, kindly >> contact the sender and destroy all copies of the original communication. IBS >> makes no warranty, express or implied, nor guarantees the accuracy, adequacy >> or completeness of the information contained in this email or any attachment >> and is not liable for any errors, defects, omissions, viruses or for >> resultant loss or damage, if any, direct or indirect." >> >> >> >> >> >
