Re: Favicon for resources when using multiple webapps

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rebecca,

On 11/3/16 4:16 PM, Maxfield, Rebecca A wrote:
> Hi there,
> 
> I have a Tomcat installation running a few different web apps 
> (different instances of XTF, if it matters), and each of these has 
> some resources (PDFs, raw XML, etc.) that can be viewed by the
> user in the browser. How can I make sure that the user sees the
> resource with the favicon of the correct site, since there’s
> nowhere for me to put a  tag like there is on the actual
> pages of the site?

You can't. Not really. But you might be able to fake it.

> Looking into support forums beforehand, I found solutions for
> giving a resource a favicon by putting the icon in the web apps
> root folder so that it’s over the whole site (not good with more
> than one webapp/site), and for making sites have different icons by
> using the  tags, but nothing that solves both of these
> problems.

This is why you can't do what you are asking to be able to do: the
favicon "spec" is the the icon is in the root of the domain, unless
overridden by a  element in the HTML document.

> I also tried a solution with htaccess but it didn’t work – not
> sure if I wrote it badly or if that’s not the right way to go.

I have no idea how you might do this with .htaccess.

> This is on Linux; I think the version of Tomcat I’m sandboxing
> this in is version 8, though the production server version is 7.

Have a look at this SO answer:
http://stackoverflow.com/questions/11227661/adding-favicon-through-a-htt
p-header

Here's a way you might be able to fake it:

1. Write a Filter (or you could do this with mod_rewrite I suppose)
2. Hook on the request for /favicon.ico
3. Examine the request headers for the REFERER (yes, it's misspelled)
4. Return the bits you want depending upon the value of that header

This might not work for e.g. PDF files, but it would work for HTML
files that don't specify their own  elements. YMMV.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYHQxbAAoJEBzwKT+lPKRYUD0P/0Pz1xmhSVV/nNUPGBF3qxmj
wWQPsbI+sK5I8X6+Yg19Cr/hjLmflsiENRq7PN7lPZ6S8lxbuCxRWwSlokWDRV8s
7dCaqbs9iPcEhd9Ey0rUwDAhR27H4x75MIA7e4dU0sVIGCsSiMYhw5OD6Td55IcZ
PDfjL5drCI0193wkC+ac5sH56y1iU9KOfaxrzh5woXsQd25rZbPBA8nP5uWmS+Cy
L0dEJ9UnLS3uBd4P4naKIy8Mrxd4OyWr67m03po5AaQwI3NkVLqkdG5fSfg6UN+w
b58aN97cNPsToidIA8sYDOPUKFW1eRroBGLzaBL1JfKAIq/J61WRQ/NpuhugT0IM
eqQ4KAEC1h4zzeAdF+Ak4G9N+AxOg95j7wvLN+c0klnYM5Uzw6ilW07E5tqLqWjM
eOaP8AL2IMfeqg+ANlTIdzFsx3hKXtZchDQ2QGp0epqvW31XefHoLuaK8RH7JtQo
2DekKfJp8ssLun1IshkKYu+SsHH/QTTzhO16ygQc2/vtqJpe4WZ2iuDsfQwbpPEr
NmVmF5WVJIG0ewcTSTz+8sl1NtpcqyMtRYMbikRXGZPXppahYtKyqVViM/SMDqMJ
RB8meG+sFNb3M8NrLiwtbtCFax7rgjM2zbPneCNr8xEPBCF0Rx8XwhuSSiHOEcHY
HfEiCDCsGD+fSvYZrHA7
=rRty
-END PGP SIGNATURE-

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

Re: Apache tomcat concurrency issue

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Miguel Angel,

On 11/3/16 12:52 PM, Roldan, Miguel Angel [Global Data & Content] wrote:

(Moving this up to the top:)

> Httpd apache server on the front-end v. 2.2 connected to apache 
> tomcat using AJP connector 1.3
> 
> Apache tomcat 7.0.56

Thanks.

> We are facing some random concurrency issues in our tomcat
> environments.
> 
> 
> 1.  We have a web application deployed on Tomcat that handles
> requests from browsers (AJAX and non-AJAX) and also from an
> applet.
> 
> 2.  The requests send by the browser and always gets and posts
> (with application/x-www-form-urlencoded format)
> 
> 3.  The requests made by the applet are compressed and send in
> binary, they are handled by a different Servlet that reads the
> content by executing request.getInputStream().

Are you compressing and sending a big blob called "data" or something
similar? Or are you sending multiple parameters separately compressed?

> 4.  Randomly, mainly after opening the applet from the current
> session or in another session executed on the same server (which
> send some requests in parallel) requests send from the browser
> arrives to the server with an empty request.getParameterMap()

If you are calling request.getInputStream, then you will never get
anything in the parameter map. If your code consumes the request body
in a POST, then Tomcat cannot parse it again.

> 5.  We have reviewed that the request was well formed when it
> leaves the browser and also we are able to monitor it with TCP Dump
> and see that arrives correctly to tomcat.

Good.

> 6.  We have introduced a filter on the first position of the
> filter chain: org.apache.catalina.filters.RequestDumperFilter and
> we have validated that at this point we have already lost all of
> the parameters

Good thinking. Are you SURE it's the first filter in the chain? We
aware that the RequestDumperValve will rob the data from your applicatio
n.

> 7.  If we try to execute the request.getInputStream() for this
> problematic requests what we see is that the byte array that
> returns belongs to another request made before to the server.

Obviously, that shouldn't happen.

> 8.  If we re-submit the same request after, it works fine. They
> don't have any kind of special character or exceed a certain
> length.
> 
> 9.  Environment configuration:
> 
> 
> O.S. - Oracle linux
> 
> 
> 
> 10.   Sometimes we are able to reproduce the issue on a
> eclipse-tomcat environment using http connector and we have
> validated that the flag used by the class
> org.apache.catalina.connector.Request parametersParsed is set to
> true.
> 
> 
> 
> Do you have any kind of suggestions on how to further investigate
> the issue?

Are you able to re-test with an updated version of Tomcat 7? Current
version is 7.0.72. Your version is ~2 years old.

Can you post your  configuration?

Thoughts about what might be happening:

1. Application concurrency/request-object retention bug
2. maxPostSize value too low -- Tomcat is rejecting the request in a
way unexpected by the application
3. Edge case/bug in Tomcat that has been fixed in a more-recent version?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYHQsTAAoJEBzwKT+lPKRYUMgP/3vpg67S/g8jGkdNbWz6PhjP
/MJjzV8RnThF+NladYyQrJLjw+29eQ9MiQozf4YaXVC5NOfiYKy0kKz1QPw+Cz8q
Mqc0ExXYkvjX1/0Op2mlkA2GY9OU976VrSFxE0yFqUomWswtar/MCmbB++fqGWdS
8xE8y62ZuW1gi0EoXU/9UiTqz3AI+ni6vxvXOFuTbzES/qudwLe5ojShHVA8DiIB
zityp3gXYvTU0QDPYcVbJBP1PNGGlgqhW0cT4jlujztb8pOieLSpMYb1o1jY00SX
Z2E781GCl63H1avQFr4tNNsRkDn7J2Xlsg0X7ixDyeJ3RDrNG+2WjYs8XoQ8WSEI
pQ1JSCKa8EVjY87jQFocsI/DH3y9LhiMqo+80EWG3tE932JiTcqxfi0ZamPWF0qn
w/fotttCaH638QWQBc4eQErDEFsvBDi0uDP0+lergEptjvduovXmjYTmD0SRtoPM
BdmZNGXdIpQtldhvnP0LwhrnKlryVw+Zo5MB3a2IelwxLAAH8BmDYAyRmKc3RTDH
lPa9gKWLPdq5NrTKpXqSSbrq0UriEiRpZ66XyBe5IKFc1tX+AvJtChj0ss2wQdKY
6WMPoJsKAiUXii6eYJ9uVSEDfvF1LJr31VyQENHOvN7elRxkvo963XQ6esOTSAbd
jEqvpcdkgyz9dvo240kT
=Ycbm
-END PGP SIGNATURE-

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

Re: JNDI look up with tomcat 8.5.6

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ajay,

On 11/3/16 12:41 AM, Ajay Bilotia wrote:
> *Below code is for JNDI look up which is working fine in tomcat 7
> and 8 .*
> 
> InitialContext  initContext = new InitialContext(); DataSource ds =
> (DataSource)initContext.lookup(initContext.getNameParser( ""
> ).parse( "java:/comp/env/jdbc/BFDS" ));

Well, that looks suspicious. What's with the getNameParser stuff? Why
not just:

DataSource ds =
(DataSource)initContext.lookup("java:/comp/env/jdbc/BFDS");

I've never seen any use of Context.getNameParser in the wild. I had to
check the API to see what it did...

> Connection conn = ds.getConnection();
> 
> *Same code is not working in tomcat 8 after setting custom class
> loader as per our requirement. In tomcat 7 it was working.*

Does it work if you DONT have a custom ClassLoader?

> DynamicClassLoader classLoader = ClassLoaderFactory.getHibernat 
> eClassLoader(); 
> Thread.currentThread().setContextClassLoader(classLoader);

This looks like a huge hack. Why do you need to change the CCL?

> My configuration is: *Changes in conf/server.xml is:*

Changes from what?

> 
> 
>  type="javax.sql.DataSource" maxTotal="100" maxIdle="30"
> maxWaitMillis="1" username="db2admin" password="db2@dm1n"
> allowLinking="true" driverClassName="com.ibm.db2.jcc.DB2Driver" 
> url="jdbc:db2://localhost:5/TRUNK" validationQuery="SELECT
> current date FROM sysibm.sysdummy1"/>  auth="Container" type="org.apache.catalina.UserDatabase" 
> description="User database that can be updated and saved" 
> factory="org.apache.catalina.users.MemoryUserDatabaseFactory" 
> pathname="conf/tomcat-users.xml" /> 
> 
> 
> *Changes is conf/context.xml is: * 
> 
> WEB-INF/web.xml 
> ${catalina.base}/conf/web.xml
> 
>  type="javax.sql.DataSource"/> 
> 
> 
> Please let me know if i am missing any configuration for tomcat 8.
> Thanks in advance.

On the face of things, this looks okay.

When you say it "doesn't work", what specifically happens when it
doesn't work?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYHQeRAAoJEBzwKT+lPKRYvCYQAK5s0bYHsizo77jAumDDxOAf
n7haV96t4QXJVuBYGLIi3/hO5mGl9pdGwWZpiPBOhJ2fSIctiJowOQYCgjUPM2AR
t95x313s425OAT4vIQ9LvY9yUZpk6EutnXKuCrR6MrZJmDGDnMlo66w6kF9OY3Ee
CuYDnwDskTKO5oygp1lRx4oRpKmC1ZbAal2D9wLOO4nyI79d9kt3tHIBkrAAa7ba
9F629r3qwd8BMsWFWs2m7GrNpivWOAkCkwHCQonvJRfi0IB4NIys+yRwNMRY08DV
EFVKxw139Hnsir1mzRkWiplwM3OrGYOY+juI34tJIDC8gfC7AmmuIB5Wy8kybLxE
Ffwygr3LrU7RxPom0xB9JqyTH7JTog7HXsRFkZucMJr60N51n1nfWGz4N3gNznu5
yh1VgZKAmlsNCLfVfs1cI2DjauE22TC0OcNfs5BnKZEuGe9Ev5GBHs+hIO5ctyrc
+kiRoOAxoLCbf7vgEsGce1ikYmtobUImRwQYMlB9g8u48t5v9w22at0/O7nTMBug
yQlAaJxyNG46JgJ3i97mhgZYcU5yCHZKlPgtaAQXSP+ueIW63lkI6cCs/1H9IAWd
zWae9+MHF3ArKFLslO/N0lAyV8RAZ/fvyYlzkrVmsIU43OaRLCBJwBzBF7Fqe1HZ
EndPJ77CtnNNnW0DYqp3
=pW9I
-END PGP SIGNATURE-

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

Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions

[Hedrick, Brooke - 43]

Sorry if this has been already asked.   I searched the archives and didn't find 
what I was looking for.

Has anyone else run into an issue with persistent cookies in Tomcat 8.5+ and IE 
not working?

We are seeing an issue where the new default cookie processor, 
org.apache.tomcat.util.http.Rfc6265CookieProcessor, is not writing out the 
expires tag for the cookies.  It is only writing out max-age in the 
generateHeader() method.  This is a change from the previous cookie processing.

Here's the current code:
https://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/tomcat/util/http/Rfc6265CookieProcessor.java

There is documentation at 
https://tomcat.apache.org/tomcat-8.5-doc/config/cookie-processor.html which 
explains the new vs legacy cookie handler and that this behavior is 
intentional.  It doesn't explain that this behavior isn't limited to IE6-7.  It 
also affects IE8-11 and Edge and as a result, by default, Tomcat 8.5+ does not 
create persistent cookies that work with IE on any IE version.

Does it make sense that the shipping configuration would not work with IE for 
persistent cookies?



There are other gotchas like blank/null cookie values cause problems with the 
new default processor and a leading period in the cookie domain causes issues.  
We have fixed these issues across many applications, but weren't expecting 
issues with persistent cookies not working at all in IE.  The documentation on 
the Tomcat page alludes to IE6-7 having the issue.  It doesn't mention the 
other versions.

We are looking into short term solutions (while avoiding the legacy cookie 
processor ) - writing our own headers, creating a filter, ...

Another interesting observation is that the ExpiresFilter included with Tomcat 
still writes both the expires and max-age attributes.  
https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/catalina/filters/ExpiresFilter.html

Here's a page where you can see the issue of IE not reading the max-age 
attribute.  On Chrome, FF, and Safari, the test will complete after a few runs. 
 On IE, it runs indefinitely.
http://mrcoles.com/media/test/cookies-max-age-vs-expires.html

If I have missed some configuration, tested incorrectly, etc., please let me 
know.

Re: MaxInactiveInterval

[Mark Thomas]

On 04/11/2016 15:53, Caldarale, Charles R wrote:
>> From: Mark Thomas [mailto:ma...@apache.org] Subject: Re:
>> MaxInactiveInterval
> 
>> On 04/11/2016 15:07, André Warnier (tomcat) wrote:
>>> A log message in an application running under Tomcat 8 mentions
>>> the "MaxInactiveInterval" setting, saying that it is a bit
>>> short..
>>> 
>>> I think that I understand the meaning of the setting (the time
>>> for which a session remains valid, even without interactions). 
>>> But where in the webapp context, and under what name, should an 
>>> equivalent parameter be specified ?
> 
>> Set it in web.xml. Same with distributable.
> 
> This really appears to be a problem in the servlet spec (not
> surprising), which mentions the getMaxInactiveInterval() and
> setMaxInactiveInterval() APIs but only vaguely ties them to the
> session-timeout element of session-config.  Tomcat doc does not
> normally describe the nuances of the servlet spec, but something that
> associates the config name with the API might be useful.

To be fair, Tomcat isn't helping here. We used to have these attributes
on the (session) manager but we removed with the expectation that they
would be configured in web.xml. We could have done a better job of
pointing to the expected locations.

I did say "patches welcome" to André but since he is a committer that
should have been "commits welcome" ;)

Mark

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

Re: jasper

[Violeta Georgieva]

Hi,

2016-11-04 19:40 GMT+02:00 Jason Hall :
>
> Possible issue with generated source from jsp(s).
>
> I current installed Tomcat 8.5.6 and use it with netbeans.
>
> On one of my JSP files, it is creating a source file with a try/catch
block that is MUCH greater than the 64K limit set by the JVM.   On
glassfish and websphere, this does not occur.
>
> I haven't checked the size of the method in websphere, but did save the
generated source on glassfish and the method is 57K (still under the 64K
limit).  The tomcat one was almost 800K I think.
>
> The older netbeans 8.0 version of tomcat that is bundeled with it does
not have this problem (version 8.0.9.0)

Check this https://bz.apache.org/bugzilla/show_bug.cgi?id=60126

Regards,
Violeta

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

jasper

[Jason Hall]

Possible issue with generated source from jsp(s).

I current installed Tomcat 8.5.6 and use it with netbeans.

On one of my JSP files, it is creating a source file with a try/catch block 
that is MUCH greater than the 64K limit set by the JVM.   On glassfish and 
websphere, this does not occur.

I haven't checked the size of the method in websphere, but did save the 
generated source on glassfish and the method is 57K (still under the 64K 
limit).  The tomcat one was almost 800K I think.

The older netbeans 8.0 version of tomcat that is bundeled with it does not have 
this problem (version 8.0.9.0)

   thanks,
  Jason

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

RE: MaxInactiveInterval

[Caldarale, Charles R]

> From: Mark Thomas [mailto:ma...@apache.org] 
> Subject: Re: MaxInactiveInterval

> On 04/11/2016 15:07, André Warnier (tomcat) wrote:
> > A log message in an application running under Tomcat 8 mentions the
> > "MaxInactiveInterval" setting, saying that it is a bit short..
> > 
> > I think that I understand the meaning of the setting (the time for which
> > a session remains valid, even without interactions).
> > But where in the webapp context, and under what name, should an
> > equivalent parameter be specified ?

> Set it in web.xml. Same with distributable.

This really appears to be a problem in the servlet spec (not surprising), which 
mentions the getMaxInactiveInterval() and setMaxInactiveInterval() APIs but 
only vaguely ties them to the session-timeout element of session-config.  
Tomcat doc does not normally describe the nuances of the servlet spec, but 
something that associates the config name with the API might be useful.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: MaxInactiveInterval

[Mark Thomas]

On 04/11/2016 15:07, André Warnier (tomcat) wrote:
> Hi.
> 
> A log message in an application running under Tomcat 8 mentions the
> "MaxInactiveInterval" setting, saying that it is a bit short..
> 
> The only place in the Tomcat 8 documentation where I find this setting,
> is in
> https://tomcat.apache.org/tomcat-8.0-doc/config/manager.html
> where it says that this is deprecated, and should be set in the Context.
> 
> However, the page at :
> https://tomcat.apache.org/tomcat-8.0-doc/config/context.html
> does not mention that parameter at all.
> 
> Deep puzzlement.
> What is this all about ?
> 
> I think that I understand the meaning of the setting (the time for which
> a session remains valid, even without interactions).
> But where in the webapp context, and under what name, should an
> equivalent parameter be specified ?

Set it in web.xml. Same with distributable.

Docs patches welcome.

Mark

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

MaxInactiveInterval

[tomcat]

Hi.

A log message in an application running under Tomcat 8 mentions the "MaxInactiveInterval" 
setting, saying that it is a bit short..


The only place in the Tomcat 8 documentation where I find this setting, is in
https://tomcat.apache.org/tomcat-8.0-doc/config/manager.html
where it says that this is deprecated, and should be set in the Context.

However, the page at :
https://tomcat.apache.org/tomcat-8.0-doc/config/context.html
does not mention that parameter at all.

Deep puzzlement.
What is this all about ?

I think that I understand the meaning of the setting (the time for which a session remains 
valid, even without interactions).
But where in the webapp context, and under what name, should an equivalent parameter be 
specified ?


Thanks

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

Re: JNDI lookup failure with tomcat 8.5.6

[padma T]

Hi,

Is there a way to add our application's contextclassloader to the list of
tomcat's " Bindings class loader list "  so that
"ContextBindings.isClassLoaderBound()"
returns true?

Please correct me if i'm wrong in understanding the problem!!

Thanks,
Padma

On Fri, Nov 4, 2016 at 4:16 PM, Mark Thomas  wrote:

> On 04/11/2016 10:45, padma T wrote:
> > Hi,
> >
> > Getting ,JNDI lookup failed exception while starting tomcat 8.
> >
> > While debugging it was found that getInitialContext()
> > of org.apache.naming.java.javaURLContextFactory class returns
> NamingContext
> > context instead of the custom ContextClassLoader set by our application
> >  and the reason is "ContextBindings.isClassLoaderBound()"  return false
> for
> > application's custom ContextClassLoader.
> >
> > Code to set custom contextloader :
> >
> > Thread.currentThread().setContextClassLoader(classLoader);
> >
> >
> > Please let me know if i have to do any configurations for tomcat 8, to
> > resolve this issue .
>
> Any custom class loader needs to have the web application class loader
> as a parent to pick up JNDI resources.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: JNDI lookup failure with tomcat 8.5.6

[padma T]

Hi Mark,

Thanks for your quick reply .

Sorry to bug you , I didn't get you. Will you please explain a bit on how
to make the custom loader as parent (any configuration changes )?

Thanks & Regards,
Padma


On Fri, Nov 4, 2016 at 4:16 PM, Mark Thomas  wrote:

> On 04/11/2016 10:45, padma T wrote:
> > Hi,
> >
> > Getting ,JNDI lookup failed exception while starting tomcat 8.
> >
> > While debugging it was found that getInitialContext()
> > of org.apache.naming.java.javaURLContextFactory class returns
> NamingContext
> > context instead of the custom ContextClassLoader set by our application
> >  and the reason is "ContextBindings.isClassLoaderBound()"  return false
> for
> > application's custom ContextClassLoader.
> >
> > Code to set custom contextloader :
> >
> > Thread.currentThread().setContextClassLoader(classLoader);
> >
> >
> > Please let me know if i have to do any configurations for tomcat 8, to
> > resolve this issue .
>
> Any custom class loader needs to have the web application class loader
> as a parent to pick up JNDI resources.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: JNDI lookup failure with tomcat 8.5.6

[Mark Thomas]

On 04/11/2016 10:45, padma T wrote:
> Hi,
> 
> Getting ,JNDI lookup failed exception while starting tomcat 8.
> 
> While debugging it was found that getInitialContext()
> of org.apache.naming.java.javaURLContextFactory class returns NamingContext
> context instead of the custom ContextClassLoader set by our application
>  and the reason is "ContextBindings.isClassLoaderBound()"  return false for
> application's custom ContextClassLoader.
> 
> Code to set custom contextloader :
> 
> Thread.currentThread().setContextClassLoader(classLoader);
> 
> 
> Please let me know if i have to do any configurations for tomcat 8, to
> resolve this issue .

Any custom class loader needs to have the web application class loader
as a parent to pick up JNDI resources.

Mark


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

JNDI lookup failure with tomcat 8.5.6

[padma T]

Hi,

Getting ,JNDI lookup failed exception while starting tomcat 8.

While debugging it was found that getInitialContext()
of org.apache.naming.java.javaURLContextFactory class returns NamingContext
context instead of the custom ContextClassLoader set by our application
 and the reason is "ContextBindings.isClassLoaderBound()"  return false for
application's custom ContextClassLoader.

Code to set custom contextloader :

Thread.currentThread().setContextClassLoader(classLoader);


Please let me know if i have to do any configurations for tomcat 8, to
resolve this issue .


Note : Our application start fine with tomcat 7.