On 28/10/2013 21:41, Francesco Bassi wrote:
> I confirm that using the 7.0 trunk from SVN
> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk
> everything is working fine, now.
> (ie: the current thread classloader is WebappClassLoader and the JNDI
> context is properly loaded)
>
> Thanks a lot for the quick response.
Great. Thanks for the feedback.
Mark
> On Mon, Oct 28, 2013 at 11:07 AM, Mark Thomas <ma...@apache.org> wrote:
>
>> On 28/10/2013 08:49, Mark Thomas wrote:
>>> On 27/10/2013 22:41, Konstantin Kolinko wrote:
>>>> 2013/10/28 Francesco Bassi <fvba...@gmail.com>:
>>>>> Hello everybody.
>>>>>
>>>>> I just downloaded 7.0.47 and updated one web application that I
>> developed
>>>>> in order to use the new standard JSR 356 websocket implementation.
>>>>>
>>>>> With this new implementation, I noticed that during the processing of
>>>>> incoming websocket events, it's not possible to access the JNDI
>> resources.
>>>>>
>>>>> ie:
>>>>>
>>>>> Context initCtx = new InitialContext();
>>>>> Context c = (Context) initCtx.lookup("java:comp/env");
>>>>>
>>>>> gives
>>>>>
>>>>> javax.naming.NameNotFoundException: Name [comp/env] is not bound in
>> this
>>>>> Context. Unable to find [comp].
>>>>>
>>>>> I'm using a custom ServerEndpointConfig.Configurator.
>>>>>
>>>>> Everything used to work properly with the old custom tomcat
>> implementation.
>>>>>
>>>>> Is it an expected behaviour?
>>>>>
>>>>
>>>> I think it means that the thread where you process those events does
>>>> not have its Thread.getContextClassLoader() (aka TCCL) configured and
>>>> thus JNDI does not know to what web application this thread belongs.
>>>>
>>>> Can you provide the stack trace of the place where you access JNDI
>>>> and check what is the value of
>>>> Thread.currentThread().getContextClassLoader() there?
>>>>
>>>> If the class loader is not a o.a.c.loader.WebappClassLoader one, I
>>>> think it is OK to create a bugzilla issue.
>>>
>>> Agreed. I'll see if I can find the bug by code inspection but a stack
>>> trace would be quicker.
>>
>> I think I've found all the places this can happen and I've fixed them
>> for 8.0.x and 7.0.x. If you could test with either of those (you'll need
>> to build the latest 7.0.x or 8.0.x from svn) to confirm that the fix
>> works for you that would be very helpful.
>>
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
