Hi Alan & Mark, These notes look like the start to some enhanced documentation around setting up DSpace + Tomcat JNDI (hint, hint).
I'm wondering (out loud) if we should take these concepts/ideas and turn them into official documentation in the "Installing DSpace" section (maybe somewhere under "Advanced Installation"?): https://wiki.duraspace.org/display/DSDOC6x/Installing+DSpace Thanks though for sharing the notes and Q&A here. I think this will be very helpful for others who wish to go this route. - Tim On Wed, Jan 3, 2018 at 3:17 PM Mark H. Wood <mwoodiu...@gmail.com> wrote: > Thanks for posting these notes. I'm sure they will be helpful. You've > shown some tools that I didn't know about. > > A pool instantiated by DSpace is probably effectively invisible to other > webapp.s even in the same JVM. The Servlet spec. tries very hard to create > the illusion that each webapp. is floating in a kind of womb, where > everything it needs is mysteriously provided for it from somewhere beyond > its perception. Each has its own classloader, for example, and so things > that a webapp. creates for itself tend to be known only in places that are > not accessible by other webapp.s. I could wish that DSpace made more > thorough use of the Servlet environment rather than behaving as if it is > standalone code. > > You're quite correct that the command-line tools don't share a pool with > any of the webapp.s, because the launcher runs in a different process with > its own address space. This is one reason to continue specifying pool > settings in dspace.cfg -- IMO this should be the *only* use of those > settings. It *is* possible to supply a pool to the command line out of > JNDI -- I've done it -- but you need to supply a directory service to the > process. I can say a little about that if anybody is interested. You > could provide in dspace.cfg settings more appropriate to the command line, > if your webapp.s are set up with pools (tuned for their needs) from JNDI. > > The reason you don't have to tinker with directory services for webapp.s > is that the <Resource> and <ResourceLink> elements are causing your Servlet > container (Tomcat) to populate an internal directory service with objects > such as your connection pool. This is specified by Java EE, but many > Servlet containers implement it even when not required by the relevant > spec.s. > > You *do* need to supply any DBMS drivers to the container itself, because > the pool and connections are created by the container and so must be > visible from *its* classloader(s), which (in Tomcat anyway) are on a branch > of the hierarchy that is parallel to those of the webapp.s. I also would > use the latest released driver. > > It should be simple to provide a log message when the resolution of > jdbc/dspace *succeeds*, and I think we should. There's already a Jira > issue about making the other case less scary, and perhaps this should be > included in that work. > > -- > You received this message because you are subscribed to the Google Groups > "DSpace Technical Support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dspace-tech+unsubscr...@googlegroups.com. > To post to this group, send email to dspace-tech@googlegroups.com. > Visit this group at https://groups.google.com/group/dspace-tech. > For more options, visit https://groups.google.com/d/optout. > -- Tim Donohue Technical Lead for DSpace & DSpaceDirect DuraSpace.org | DSpace.org | DSpaceDirect.org -- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To post to this group, send email to dspace-tech@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
