You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2010/07/21 21:02:09 UTC

DO NOT REPLY [Bug 49631] New: Custom DatabaseResourceProvider extension cannot get app context JNDI resources

https://issues.apache.org/bugzilla/show_bug.cgi?id=49631

           Summary: Custom DatabaseResourceProvider extension cannot get
                    app context JNDI resources
           Product: Tomcat 6
           Version: 6.0.28
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina
        AssignedTo: dev@tomcat.apache.org
        ReportedBy: matt.helgren@gmail.com


I've written a custom extension to the DatabaseResourceProvider that allows our
application to store some subset of files in the database.  In order to get a
db connection I'm trying to lookup a datasource via JNDI:

    private Connection getConnection() throws SQLException, NamingException {   
        Context initContext = new InitialContext();
        System.out.println("here");
        DataSource ds =
(DataSource)initContext.lookup("java:/comp/env/"+JDBC_SYSTEM_JNDI);
        return ds.getConnection();
    }

I've found that in some cases it does get the datasource and in others it
throws a namingexception that the resource was not found.  I debugged it out
and found that in certain cases it works if the resources is being requested
through a servlet or JSP call but when its a direct request for a static file
such as an image or CSS file it fails.  In those failing cases I've found that
its getting the server naming context and not the web app context.  

More digging into the tomcat naming stuff showed that the way it determines the
naming context to use is derived by the current threads class loader.  Looks
like the class loader is not getting replaced with the web apps class loader in
the case of static resource serving. 

Could something be added to make sure the class loader for the thread is always
updated to the current web app class loader before calling into the DirContext
classes?

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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


DO NOT REPLY [Bug 49631] Custom DatabaseResourceProvider extension cannot get app context JNDI resources

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49631

--- Comment #1 from Matt <ma...@gmail.com> 2010-07-21 17:58:25 EDT ---
Created an attachment (id=25793)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25793)
stack trace

This is a stack trace for the request that fails to find the jndi context
entry.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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


DO NOT REPLY [Bug 49631] Custom DatabaseResourceProvider extension cannot get app context JNDI resources

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49631

--- Comment #2 from Matt <ma...@gmail.com> 2010-07-21 18:01:15 EDT ---
Looking into this a bit more I noticed that when the JNDI lookup fails, its
calling my FileDirContext without having gone through the default servlet (see
attached stack trace).   Looks like CoyoteAdapter.postParseRequest ends up
probing for the file.  I also noticed that since the file is not found it
causes the ProxyDirContext to cache that the file does not exist for a period
of time which might be causing the CoyoteAdpater to then not find the file
subsequently through the default servlet.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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


DO NOT REPLY [Bug 49631] Custom DatabaseResourceProvider extension cannot get app context JNDI resources

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49631

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #3 from Mark Thomas <ma...@apache.org> 2010-09-28 08:21:05 EDT ---
The probing for the file is the result of the code that handles welcome files.

I am reluctant to switch the TCCL in this code due to the potential performance
impact.

What should work is obtaining the DataSource once when the custom
FileDirContext starts and then caching that reference. It should also make your
FileDirContext a little faster. If you need further help with your custom
FileDirContext then the users list is the best place to ask.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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