Populating JNDI entirely in Java code
When embedding Tomcat, I'd like to create some objects purely from code -- I don't want to bother to express them as XML -- and then pick them up inside webapps. Now, calling enableNaming() on Tomcat sets up a bunch of environment, but does not actually create and JNDI objects. If I call enableNaming(), and then make JNDI calls before calling start(), should I expect that to work?
Re: Populating JNDI entirely in Java code
After an hour or so of debugging, I've reached the conclusion that this is more trouble that it is worth to me. The problem is that the naming resources are setup in the middle of the START process. So, there's no very good way to arrange for some code to run after the JNDI structure is in place, but before other things from the initialization process go to use it. It was easier to just setup the webapp class loader to share some classes with the program that embeds tomcat and just use singleton. On Mon, Apr 1, 2013 at 3:10 PM, Konstantin Kolinko knst.koli...@gmail.comwrote: 2013/4/1 Benson Margulies ben...@basistech.com: When embedding Tomcat, I'd like to create some objects purely from code -- I don't want to bother to express them as XML -- and then pick them up inside webapps. Now, calling enableNaming() on Tomcat sets up a bunch of environment, but does not actually create and JNDI objects. If I call enableNaming(), and then make JNDI calls before calling start(), should I expect that to work? 1. No, JNDI binds to TCCL (Thread.currentThread().getContextClassLoader()). Before you call start() the webapp classloader is not initialized and has not been started. So you cannot bind your JNDI to it. 2. The magic that translates XML into java calls is called Digester (http://commons.apache.org/digester) You may start a standalone Tomcat and try to debug it. https://wiki.apache.org/tomcat/FAQ/Developing#Debugging The place to look into is org.apache.catalina.core.NamingContextListener That is the component that translates configuration objects created when parsing context.xml into JNDI objects. 3. See thread Register static JNDI env entry dynamically from 2 weeks ago. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can't seem to get metadata-complete turned on
On Fri, Sep 14, 2012 at 1:06 PM, Mark Thomas ma...@apache.org wrote: On 14/09/2012 17:36, Benson Margulies wrote: On Fri, Sep 14, 2012 at 12:27 PM, Mark Thomas ma...@apache.org wrote: Benson Margulies ben...@basistech.com wrote: Apologies for the accidental use of HTML. The problem below is triggered by the facts that: a) spring-web contains a ServletContainerInitializer b) even with metadata-complete, tomcat does annotation scanning once it sees one of those Yes, this is a mandatory requirement of the servlet spec. Yes, it is a PITA. Your best bet is to add the spring jar to jarsToSkip which should stop it being scanned for the SCI in the first place. If you need features provided by the SCI, then you can add the other jars to the skip list. Mark, this leads me to a related question. If I'm launching tomcat embedded, I have no catalina.properties, right? So I don't even have the lengthy normal list of jarsToSkip. Would you recommend settings that Tld-scan-limiting property by just calling System.setProperty for my embedded application? See how you get on with 7.0.30. If you still see issues, then yes. all better with 7.0.30. 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
Can't seem to get metadata-complete turned on
I'm using tomcat 7.0.29, embedded. My web.xml web-app element looks like: web-app xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd; version=3.0 metadata-complete=true Yet, in ContextConfig.webConfig, isMetadataComplete() returns false, and annotation processing happens. And, to make my day, it runs out of memory.
Re: Can't seem to get metadata-complete turned on
Apologies for the accidental use of HTML. The problem below is triggered by the facts that: a) spring-web contains a ServletContainerInitializer b) even with metadata-complete, tomcat does annotation scanning once it sees one of those c) In my embedded environment, there's a lot of real estate to potentially scan in the classpath. Is (b) really correct? Unfortunately, I need spring-web in order to get the log4j support, even though I don't want any of that other stuff in there. On Fri, Sep 14, 2012 at 11:56 AM, Benson Margulies ben...@basistech.com wrote: I'm using tomcat 7.0.29, embedded. My web.xml web-app element looks like: web-app xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd; version=3.0 metadata-complete=true Yet, in ContextConfig.webConfig, isMetadataComplete() returns false, and annotation processing happens. And, to make my day, it runs out of memory. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can't seem to get metadata-complete turned on
On Fri, Sep 14, 2012 at 12:27 PM, Mark Thomas ma...@apache.org wrote: Benson Margulies ben...@basistech.com wrote: Apologies for the accidental use of HTML. The problem below is triggered by the facts that: a) spring-web contains a ServletContainerInitializer b) even with metadata-complete, tomcat does annotation scanning once it sees one of those Yes, this is a mandatory requirement of the servlet spec. Yes, it is a PITA. Your best bet is to add the spring jar to jarsToSkip which should stop it being scanned for the SCI in the first place. If you need features provided by the SCI, then you can add the other jars to the skip list. Mark, does the OOM suggest something worth trying to track down? I gave it 0.5G of memory and it still filled it up whilst looking for annotations. Making you a test case of this is not impossible but not trivial. Also, I was surprised to note that tomcat seems to do annotation scanning even for a version 2.4 webapp, which has no metadata-complete option in the schema. Mark c) In my embedded environment, there's a lot of real estate to potentially scan in the classpath. Is (b) really correct? Unfortunately, I need spring-web in order to get the log4j support, even though I don't want any of that other stuff in there. On Fri, Sep 14, 2012 at 11:56 AM, Benson Margulies ben...@basistech.com wrote: I'm using tomcat 7.0.29, embedded. My web.xml web-app element looks like: web-app xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd; version=3.0 metadata-complete=true Yet, in ContextConfig.webConfig, isMetadataComplete() returns false, and annotation processing happens. And, to make my day, it runs out of memory. - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can't seem to get metadata-complete turned on
On Fri, Sep 14, 2012 at 12:27 PM, Mark Thomas ma...@apache.org wrote: Benson Margulies ben...@basistech.com wrote: Apologies for the accidental use of HTML. The problem below is triggered by the facts that: a) spring-web contains a ServletContainerInitializer b) even with metadata-complete, tomcat does annotation scanning once it sees one of those Yes, this is a mandatory requirement of the servlet spec. Yes, it is a PITA. Your best bet is to add the spring jar to jarsToSkip which should stop it being scanned for the SCI in the first place. If you need features provided by the SCI, then you can add the other jars to the skip list. Mark, this leads me to a related question. If I'm launching tomcat embedded, I have no catalina.properties, right? So I don't even have the lengthy normal list of jarsToSkip. Would you recommend settings that Tld-scan-limiting property by just calling System.setProperty for my embedded application? Mark c) In my embedded environment, there's a lot of real estate to potentially scan in the classpath. Is (b) really correct? Unfortunately, I need spring-web in order to get the log4j support, even though I don't want any of that other stuff in there. On Fri, Sep 14, 2012 at 11:56 AM, Benson Margulies ben...@basistech.com wrote: I'm using tomcat 7.0.29, embedded. My web.xml web-app element looks like: web-app xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd; version=3.0 metadata-complete=true Yet, in ContextConfig.webConfig, isMetadataComplete() returns false, and annotation processing happens. And, to make my day, it runs out of memory. - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Minimal persistent storage for a webapp
I'm fairly certain that I know the answer to the question here, but I want to pose it just in case I've missed something. In a web application, I'd like to store a bit of data without configuring a database, or, indeed anything that has to be edited into an XML file or typed into a container-level gui. As far as I know, the entire servlet/webapp spec has nothing for me here, since the Snoracle thinking was that this sort of thing was the job of JEE descriptors. Have I missed something all these years? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Minimal persistent storage for a webapp
On Fri, Nov 25, 2011 at 4:36 PM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2011/11/26 Benson Margulies bimargul...@gmail.com: I'm fairly certain that I know the answer to the question here, but I want to pose it just in case I've missed something. In a web application, I'd like to store a bit of data without configuring a database, or, indeed anything that has to be edited into an XML file or typed into a container-level gui. As far as I know, the entire servlet/webapp spec has nothing for me here, since the Snoracle thinking was that this sort of thing was the job of JEE descriptors. Have I missed something all these years? Define store. What is proposed lifetime of that information? Forever. Sorry about the snide vendor remark. I have to think about whether redeployment is good enough. Is that ServletContext.TEMPDIR guaranteed to stick around across container reboots as long as the app isn't specifically redeployed? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Adding an additional static resource directory to a webapp via API
I'm launching Tomcat 7 via the API. One of the uses of this is that I can launch from Eclipse and 'live-edit' my static files, without tangling myself up in the Eclipse JEE facilities, which I have never succeeded in using very well. Now, I want to meld some shared content into the webapp. In the maven build, I use the maven 'overlay' concept. For live development, I'm looking to do the same thing. Essentially, I want to map in a directory of additional static resources into the Context. I see addResourceJarUrl, and I wonder what it does with a file:/ url, though the comment in the javadoc about META-INF/resources suggests that I'd need to conform to that directory structure. (and reading the code in BaseDirContext confirms this). Is 'addAlias' the way to go here? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Adding an additional static resource directory to a webapp via API
Yes. It's a jquery theme at the moment. I just posted a bz with code I wrote involving subclasses of StandardContext and also FileDirContext that pulls this off. https://issues.apache.org/bugzilla/show_bug.cgi?id=52236. What do you think? On Wed, Nov 23, 2011 at 2:29 PM, Pid p...@pidster.com wrote: On 23/11/2011 18:06, Benson Margulies wrote: I'm launching Tomcat 7 via the API. One of the uses of this is that I can launch from Eclipse and 'live-edit' my static files, without tangling myself up in the Eclipse JEE facilities, which I have never succeeded in using very well. Now, I want to meld some shared content into the webapp. In the maven build, I use the maven 'overlay' concept. For live development, I'm looking to do the same thing. Essentially, I want to map in a directory of additional static resources into the Context. I see addResourceJarUrl, and I wonder what it does with a file:/ url, though the comment in the javadoc about META-INF/resources suggests that I'd need to conform to that directory structure. (and reading the code in BaseDirContext confirms this). Is 'addAlias' the way to go here? What is the shared content? Static files? p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- [key:62590808] - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Adding a webapp to a running embedded tomcat 7 with an 'improved' class loader results in missing classes?
The equivalent basic scheme worked perfectly fine in tomcat6. In Tomcat7, it looks like: solrContext = tomcat.addWebapp(/solr, solrWebapp.getCanonicalPath()); WebappLoader solrLoader = new WebappLoader(LSHDemoLauncher.class.getClassLoader()); solrContext.setLoader(solrLoader); I am pulling my hair out because some classes sitting in the WEB-INF/lib dir of the solr webapp are not found. I've debugged into the class loader sufficiently to see that the right jars are in the right place. It occurs to me that this might be just as silly as that I need to get the class loader set inside of addWebapp so that it is in place before the call to host.addChild(). If anyone happens to have any advice, I'd be grateful, else I'll be going ahead to perform experiments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Adding a webapp to a running embedded tomcat 7 with an 'improved' class loader results in missing classes?
Solr has a particularly bizarre class loading environment. The class causes the problem is the FileUploadServlet from commons-fileupload. I doubt that the problem is validation, but I'll check. My experience is that, in the stock Tomcat class, the new context gets called through .start() before the addWebapp function returns, if the container is already running. I made a subclass of Tomcat which accepted a loader as another argument to addWebapp, and sets it before calling addChild on the host. That cured the problem. Would you be interested in a patch containing this additional overload? Or would it make more sense to have a function createWebapp that left out the addChild and left that to the caller? On Wed, Jun 22, 2011 at 10:00 AM, Mark Thomas ma...@apache.org wrote: On 22/06/2011 14:47, Benson Margulies wrote: The equivalent basic scheme worked perfectly fine in tomcat6. In Tomcat7, it looks like: solrContext = tomcat.addWebapp(/solr, solrWebapp.getCanonicalPath()); WebappLoader solrLoader = new WebappLoader(LSHDemoLauncher.class.getClassLoader()); solrContext.setLoader(solrLoader); I am pulling my hair out because some classes sitting in the WEB-INF/lib dir of the solr webapp are not found. I've debugged into the class loader sufficiently to see that the right jars are in the right place. Some classes or all classes? If some, which ones? Are some JARs falling foul of WebappClassLoader#validateJarFile()? It occurs to me that this might be just as silly as that I need to get the class loader set inside of addWebapp so that it is in place before the call to host.addChild(). If anyone happens to have any advice, I'd be grateful, else I'll be going ahead to perform experiments. Unlikely. As long as the class loader is set before the Context starts you should be fine. 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
Re: Adding a webapp to a running embedded tomcat 7 with an 'improved' class loader results in missing classes?
I agree with your preference. Patch to follow later today. On Wed, Jun 22, 2011 at 10:27 AM, Mark Thomas ma...@apache.org wrote: On 22/06/2011 15:18, Benson Margulies wrote: Solr has a particularly bizarre class loading environment. The class causes the problem is the FileUploadServlet from commons-fileupload. I doubt that the problem is validation, but I'll check. My experience is that, in the stock Tomcat class, the new context gets called through .start() before the addWebapp function returns, if the container is already running. Ah, if the container is already running then that would explain it. I'm fairly sure (without looking at the code) that any change to the loader will be ignored. I made a subclass of Tomcat which accepted a loader as another argument to addWebapp, and sets it before calling addChild on the host. That cured the problem. Would you be interested in a patch containing this additional overload? Or would it make more sense to have a function createWebapp that left out the addChild and left that to the caller? I'd be happy with either with a slight preference for the second. (I have an aversion to methods that gather more and more parameters over time.) Mark On Wed, Jun 22, 2011 at 10:00 AM, Mark Thomas ma...@apache.org wrote: On 22/06/2011 14:47, Benson Margulies wrote: The equivalent basic scheme worked perfectly fine in tomcat6. In Tomcat7, it looks like: solrContext = tomcat.addWebapp(/solr, solrWebapp.getCanonicalPath()); WebappLoader solrLoader = new WebappLoader(LSHDemoLauncher.class.getClassLoader()); solrContext.setLoader(solrLoader); I am pulling my hair out because some classes sitting in the WEB-INF/lib dir of the solr webapp are not found. I've debugged into the class loader sufficiently to see that the right jars are in the right place. Some classes or all classes? If some, which ones? Are some JARs falling foul of WebappClassLoader#validateJarFile()? It occurs to me that this might be just as silly as that I need to get the class loader set inside of addWebapp so that it is in place before the call to host.addChild(). If anyone happens to have any advice, I'd be grateful, else I'll be going ahead to perform experiments. Unlikely. As long as the class loader is set before the Context starts you should be fine. 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 - 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
Adding a webapp via the API to a running instance
I'm using import org.apache.catalina.startup.Tomcat to embed tomcat. After it is running, I'm trying to add another webapp with .addWebapp. The addWebapp call logs: 2011-06-20 11:23:23,385 [http-bio-9167-exec-2] INFO org.apache.catalina.util.LifecycleBase - The start() method was called on component [Realm[Simple]] after start() had already been called. The second call will be ignored. 2011-06-20 11:23:23,387 [http-bio-9167-exec-2] INFO org.apache.catalina.startup.ContextConfig - No global web.xml found This second message is odd, since there is a global web.xml sitting in the conf subdirectory of the pathname I passed to Tomcat.setBaseDir. However, this is followed in quick succession by an NPE. In ContextConfig.java, jspServlet is null. Does it make sense that the problem is the failure to find the global web.xml, since it would define the jsp servlet? And, if so, why does this work for my first webpp (defined before 'start') and not for my second? java.lang.NullPointerException at org.apache.catalina.startup.ContextConfig.convertJsp(ContextConfig.java:1360) at org.apache.catalina.startup.ContextConfig.convertJsps(ContextConfig.java:1339) at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1330) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:881) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:316) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:89) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5103) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:812) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:787) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:607) at org.apache.catalina.startup.Tomcat.addWebapp(Tomcat.java:509) at org.apache.catalina.startup.Tomcat.addWebapp(Tomcat.java:483) at org.apache.catalina.startup.Tomcat.addWebapp(Tomcat.java:171) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Adding a webapp via the API to a running instance
Reading org.apache.catalina.startup.Tomcat.addWebapp(Host, String, String, String), I don't understand the following: // prevent it from looking ( if it finds one - it'll have dup error ) ctxCfg.setDefaultWebXml(org/apache/catalin/startup/NO_DEFAULT_XML); Why is this being used to prevent the code from seeing a web.xml in the basedir/conf? On Mon, Jun 20, 2011 at 11:31 AM, Benson Margulies bimargul...@gmail.com wrote: I'm using import org.apache.catalina.startup.Tomcat to embed tomcat. After it is running, I'm trying to add another webapp with .addWebapp. The addWebapp call logs: 2011-06-20 11:23:23,385 [http-bio-9167-exec-2] INFO org.apache.catalina.util.LifecycleBase - The start() method was called on component [Realm[Simple]] after start() had already been called. The second call will be ignored. 2011-06-20 11:23:23,387 [http-bio-9167-exec-2] INFO org.apache.catalina.startup.ContextConfig - No global web.xml found This second message is odd, since there is a global web.xml sitting in the conf subdirectory of the pathname I passed to Tomcat.setBaseDir. However, this is followed in quick succession by an NPE. In ContextConfig.java, jspServlet is null. Does it make sense that the problem is the failure to find the global web.xml, since it would define the jsp servlet? And, if so, why does this work for my first webpp (defined before 'start') and not for my second? java.lang.NullPointerException at org.apache.catalina.startup.ContextConfig.convertJsp(ContextConfig.java:1360) at org.apache.catalina.startup.ContextConfig.convertJsps(ContextConfig.java:1339) at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1330) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:881) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:316) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:89) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5103) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:812) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:787) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:607) at org.apache.catalina.startup.Tomcat.addWebapp(Tomcat.java:509) at org.apache.catalina.startup.Tomcat.addWebapp(Tomcat.java:483) at org.apache.catalina.startup.Tomcat.addWebapp(Tomcat.java:171) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
A servlet named jsp
This is related to another thread I started, but it's a different question. Some experimentation shows that Tomcat.java disables the default web.xml for a good reason; if I force one back into place, I get a duplicate name error. However, whatever it ends up using does not include a servlet named 'jsp', and then org.apache.catalina.startup.ContextConfig.convertJsps(WebXml) ends up with an NPE with a webapp (in this case solr) that has any jsp servlets. I'm continuing to dig. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Adding a webapp via the API to a running instance
Hi, I set up a testcase at https://github.com/bimargulies/Tomcat-Solr-Test-Case. Note that this is NOT a 3.0 webapp. I read the code, and the failing path is in the if statement for 'pre-3.0'. Please have a look at the single Java class in there and tell me what is wrong, since it seems quite straightforward to me. On Mon, Jun 20, 2011 at 12:56 PM, Rainer Jung rainer.j...@kippdata.de wrote: Hi Benson, On 20.06.2011 17:51, Benson Margulies wrote: Reading org.apache.catalina.startup.Tomcat.addWebapp(Host, String, String, String), I don't understand the following: // prevent it from looking ( if it finds one - it'll have dup error ) ctxCfg.setDefaultWebXml(org/apache/catalin/startup/NO_DEFAULT_XML); Why is this being used to prevent the code from seeing a web.xml in the basedir/conf? I'd say it is not. Have a look at ourr test suite. It uses the jsp servlet without programmatically configuring. I'm pretty sure it comes from the global web.xml. The test suite also logs ... org.apache.catalina.startup.ContextConfig webConfig ... INFO: No global web.xml found but that doesn't keep it from executing JSPs. For instance TestAbstractHttp11Processor deploys test/webapp-3.0 and calls /echo-params.jsp. The basics are in TomcatBaseTest. So I'd say there's something wrong in your setup. HTH. Rainer On Mon, Jun 20, 2011 at 11:31 AM, Benson Margulies bimargul...@gmail.com wrote: I'm using import org.apache.catalina.startup.Tomcat to embed tomcat. After it is running, I'm trying to add another webapp with .addWebapp. The addWebapp call logs: 2011-06-20 11:23:23,385 [http-bio-9167-exec-2] INFO org.apache.catalina.util.LifecycleBase - The start() method was called on component [Realm[Simple]] after start() had already been called. The second call will be ignored. 2011-06-20 11:23:23,387 [http-bio-9167-exec-2] INFO org.apache.catalina.startup.ContextConfig - No global web.xml found This second message is odd, since there is a global web.xml sitting in the conf subdirectory of the pathname I passed to Tomcat.setBaseDir. However, this is followed in quick succession by an NPE. In ContextConfig.java, jspServlet is null. Does it make sense that the problem is the failure to find the global web.xml, since it would define the jsp servlet? And, if so, why does this work for my first webpp (defined before 'start') and not for my second? java.lang.NullPointerException at org.apache.catalina.startup.ContextConfig.convertJsp(ContextConfig.java:1360) at org.apache.catalina.startup.ContextConfig.convertJsps(ContextConfig.java:1339) at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1330) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:881) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:316) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:89) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5103) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:812) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:787) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:607) at org.apache.catalina.startup.Tomcat.addWebapp(Tomcat.java:509) at org.apache.catalina.startup.Tomcat.addWebapp(Tomcat.java:483) at org.apache.catalina.startup.Tomcat.addWebapp(Tomcat.java:171) - 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
Re: Adding a webapp via the API to a running instance
Ranier, I don't have a problem executing jsps. I have a problem configuring a webapp with entire servlets defined by jsps. My code works perfectly fine launching another webapp with jsps in it which are not declared in servlet elements. --benson On Mon, Jun 20, 2011 at 12:56 PM, Rainer Jung rainer.j...@kippdata.de wrote: Hi Benson, On 20.06.2011 17:51, Benson Margulies wrote: Reading org.apache.catalina.startup.Tomcat.addWebapp(Host, String, String, String), I don't understand the following: // prevent it from looking ( if it finds one - it'll have dup error ) ctxCfg.setDefaultWebXml(org/apache/catalin/startup/NO_DEFAULT_XML); Why is this being used to prevent the code from seeing a web.xml in the basedir/conf? I'd say it is not. Have a look at ourr test suite. It uses the jsp servlet without programmatically configuring. I'm pretty sure it comes from the global web.xml. The test suite also logs ... org.apache.catalina.startup.ContextConfig webConfig ... INFO: No global web.xml found but that doesn't keep it from executing JSPs. For instance TestAbstractHttp11Processor deploys test/webapp-3.0 and calls /echo-params.jsp. The basics are in TomcatBaseTest. So I'd say there's something wrong in your setup. HTH. Rainer On Mon, Jun 20, 2011 at 11:31 AM, Benson Margulies bimargul...@gmail.com wrote: I'm using import org.apache.catalina.startup.Tomcat to embed tomcat. After it is running, I'm trying to add another webapp with .addWebapp. The addWebapp call logs: 2011-06-20 11:23:23,385 [http-bio-9167-exec-2] INFO org.apache.catalina.util.LifecycleBase - The start() method was called on component [Realm[Simple]] after start() had already been called. The second call will be ignored. 2011-06-20 11:23:23,387 [http-bio-9167-exec-2] INFO org.apache.catalina.startup.ContextConfig - No global web.xml found This second message is odd, since there is a global web.xml sitting in the conf subdirectory of the pathname I passed to Tomcat.setBaseDir. However, this is followed in quick succession by an NPE. In ContextConfig.java, jspServlet is null. Does it make sense that the problem is the failure to find the global web.xml, since it would define the jsp servlet? And, if so, why does this work for my first webpp (defined before 'start') and not for my second? java.lang.NullPointerException at org.apache.catalina.startup.ContextConfig.convertJsp(ContextConfig.java:1360) at org.apache.catalina.startup.ContextConfig.convertJsps(ContextConfig.java:1339) at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1330) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:881) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:316) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:89) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5103) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:812) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:787) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:607) at org.apache.catalina.startup.Tomcat.addWebapp(Tomcat.java:509) at org.apache.catalina.startup.Tomcat.addWebapp(Tomcat.java:483) at org.apache.catalina.startup.Tomcat.addWebapp(Tomcat.java:171) - 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
Running an old servlet with Tomcat 7.0.16 embedded API
Ranier, I've now demonstrated that this is not about 'deferred launch' but rather about an old servlet failing to be configured with the embedded Tomcat class. https://github.com/bimargulies/Tomcat-Solr-Test-Case has been simplified. It makes the few required calls to set up the Tomcat object. Then it calls addWebapp for the solr webapp, and it failed with an NPE, due to the lack of the 'jsp' servlet from the usual global web.xml. The test cases you mentioned didn't bear on this case at all, I'll look for some others. --benson On Mon, Jun 20, 2011 at 12:56 PM, Rainer Jung rainer.j...@kippdata.de wrote: Hi Benson, On 20.06.2011 17:51, Benson Margulies wrote: Reading org.apache.catalina.startup.Tomcat.addWebapp(Host, String, String, String), I don't understand the following: // prevent it from looking ( if it finds one - it'll have dup error ) ctxCfg.setDefaultWebXml(org/apache/catalin/startup/NO_DEFAULT_XML); Why is this being used to prevent the code from seeing a web.xml in the basedir/conf? I'd say it is not. Have a look at ourr test suite. It uses the jsp servlet without programmatically configuring. I'm pretty sure it comes from the global web.xml. The test suite also logs ... org.apache.catalina.startup.ContextConfig webConfig ... INFO: No global web.xml found but that doesn't keep it from executing JSPs. For instance TestAbstractHttp11Processor deploys test/webapp-3.0 and calls /echo-params.jsp. The basics are in TomcatBaseTest. So I'd say there's something wrong in your setup. HTH. Rainer On Mon, Jun 20, 2011 at 11:31 AM, Benson Margulies bimargul...@gmail.com wrote: I'm using import org.apache.catalina.startup.Tomcat to embed tomcat. After it is running, I'm trying to add another webapp with .addWebapp. The addWebapp call logs: 2011-06-20 11:23:23,385 [http-bio-9167-exec-2] INFO org.apache.catalina.util.LifecycleBase - The start() method was called on component [Realm[Simple]] after start() had already been called. The second call will be ignored. 2011-06-20 11:23:23,387 [http-bio-9167-exec-2] INFO org.apache.catalina.startup.ContextConfig - No global web.xml found This second message is odd, since there is a global web.xml sitting in the conf subdirectory of the pathname I passed to Tomcat.setBaseDir. However, this is followed in quick succession by an NPE. In ContextConfig.java, jspServlet is null. Does it make sense that the problem is the failure to find the global web.xml, since it would define the jsp servlet? And, if so, why does this work for my first webpp (defined before 'start') and not for my second? java.lang.NullPointerException at org.apache.catalina.startup.ContextConfig.convertJsp(ContextConfig.java:1360) at org.apache.catalina.startup.ContextConfig.convertJsps(ContextConfig.java:1339) at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1330) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:881) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:316) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:89) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5103) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:812) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:787) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:607) at org.apache.catalina.startup.Tomcat.addWebapp(Tomcat.java:509) at org.apache.catalina.startup.Tomcat.addWebapp(Tomcat.java:483) at org.apache.catalina.startup.Tomcat.addWebapp(Tomcat.java:171) - 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
Embedded tomcat contexts confusion
I'm using tomcat 7.0.14. I create a org.apache.catalina.startup.Tomcat;. I call 'addWebapp' lshContext = tomcat.addWebapp(/lsh, docBase.getCanonicalPath());. The webapp in question has a Listener. The listener happens to belong to Spring. contextInitialized has a try/catch block. In the catch, it call: servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, ex); and then rethrows the exception. Out in my application, I am trying to find that attribute value. If I ask lshContext (the context returned by addWebapp) for servletContext(), I get a *different* object that has no attributes. How can I navigate from the Context returned from addWebapp to the context passed into the Listener? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Xalan classpath problem
i don't suppose you've had time to look at the test case? On Tue, Nov 3, 2009 at 9:22 AM, Rainer Jung rainer.j...@kippdata.de wrote: Just to make sure w.r.t. it being working in Jetty: You use the same Java version? Sun changed an important bit between Java 5 and Java 6, where they are now caching something detected during runtime in a global static thus partially breaking the dynamics of XML parser detection when using mutiple classloaders. The usual indication is a class cast exception, which is not the case in your situation, but nevertheless I wanted to check, whether there's a relation to Java 6 vs. Java 5 (handling in Java 6 is broken). Regards, Rainer On 03.11.2009 14:00, Benson Margulies wrote: Here's the relevant log traffic of the missing method. I can get past this problem by putting xalan into the endorsed directory, but I should not have to do that when using the JAXP 1.4 API to create XPathFactory. Caused by: java.lang.NoSuchMethodError: org.apache.xpath.XPathContext.init(Z)V at org.apache.xpath.jaxp.XPathImpl.eval(XPathImpl.java:207) at org.apache.xpath.jaxp.XPathImpl.evaluate(XPathImpl.java:281) at com.basistech.vws.env.GazetteerConfigManager.initialGazetteerConfiguration(GazetteerConfigManager.java:67) at com.basistech.vws.env.RLPEnvironmentManager.initialGazetteerConfiguration(RLPEnvironmentManager.java:400) at com.basistech.vws.env.RLPEnvironmentManager.initialConfiguration(RLPEnvironmentManager.java:358) at com.basistech.vws.env.RLPEnvironmentManager.initialize(RLPEnvironmentManager.java:182) ... 48 more org.apache.cxf.common.injection.ResourceInjector - method annotated by @PostConstruct throws exception when invoked java.lang.reflect.InvocationTargetException On Tue, Nov 3, 2009 at 7:48 AM, André Warnier a...@ice-sa.com wrote: Benson Margulies wrote: I have a webapp that makes calls to the JAXP 1.4/Java 1.6 APIs that allow the caller to pass in the class name of implementation classes. It all works find standalone. It works fine in Jetty. It fails in Tomcat 6.0.20. The error is a missing method in a Xalan class; as if Tomcat has somehow gotten an older version of Xalan into the classpath. I don't see any likely suspects in the Tomcat tree, so I'm momentarily mystified. A piece of the logfile where the error messages occur may help someone to help you. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat Xalan classpath problem
I have a webapp that makes calls to the JAXP 1.4/Java 1.6 APIs that allow the caller to pass in the class name of implementation classes. It all works find standalone. It works fine in Jetty. It fails in Tomcat 6.0.20. The error is a missing method in a Xalan class; as if Tomcat has somehow gotten an older version of Xalan into the classpath. I don't see any likely suspects in the Tomcat tree, so I'm momentarily mystified.
Re: Tomcat Xalan classpath problem
Here's the relevant log traffic of the missing method. I can get past this problem by putting xalan into the endorsed directory, but I should not have to do that when using the JAXP 1.4 API to create XPathFactory. Caused by: java.lang.NoSuchMethodError: org.apache.xpath.XPathContext.init(Z)V at org.apache.xpath.jaxp.XPathImpl.eval(XPathImpl.java:207) at org.apache.xpath.jaxp.XPathImpl.evaluate(XPathImpl.java:281) at com.basistech.vws.env.GazetteerConfigManager.initialGazetteerConfiguration(GazetteerConfigManager.java:67) at com.basistech.vws.env.RLPEnvironmentManager.initialGazetteerConfiguration(RLPEnvironmentManager.java:400) at com.basistech.vws.env.RLPEnvironmentManager.initialConfiguration(RLPEnvironmentManager.java:358) at com.basistech.vws.env.RLPEnvironmentManager.initialize(RLPEnvironmentManager.java:182) ... 48 more org.apache.cxf.common.injection.ResourceInjector - method annotated by @PostConstruct throws exception when invoked java.lang.reflect.InvocationTargetException On Tue, Nov 3, 2009 at 7:48 AM, André Warnier a...@ice-sa.com wrote: Benson Margulies wrote: I have a webapp that makes calls to the JAXP 1.4/Java 1.6 APIs that allow the caller to pass in the class name of implementation classes. It all works find standalone. It works fine in Jetty. It fails in Tomcat 6.0.20. The error is a missing method in a Xalan class; as if Tomcat has somehow gotten an older version of Xalan into the classpath. I don't see any likely suspects in the Tomcat tree, so I'm momentarily mystified. A piece of the logfile where the error messages occur may help someone to help you. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Xalan classpath problem
I am sure that I'm using the MacOS JDK 1.6 at all points. Also, if you look closely at the below, you will see that the problem is that one part of Xalan is failing to call another part ... of Xalan. If I had JDK 1.5 I'd be missing the newInstance APIs that take the class name, and if I had other problems I'd have a mixture of sun. classes and org.apache. classes. But this is 100% org.apache. I shouldn't need to use endorsed at all with JDK 1.6, I claim, if I use the new newInstances APIs that take class names. But somehow Tomcat prevents that from working, I don't know how. On Tue, Nov 3, 2009 at 9:22 AM, Rainer Jung rainer.j...@kippdata.de wrote: Just to make sure w.r.t. it being working in Jetty: You use the same Java version? Sun changed an important bit between Java 5 and Java 6, where they are now caching something detected during runtime in a global static thus partially breaking the dynamics of XML parser detection when using mutiple classloaders. The usual indication is a class cast exception, which is not the case in your situation, but nevertheless I wanted to check, whether there's a relation to Java 6 vs. Java 5 (handling in Java 6 is broken). Regards, Rainer On 03.11.2009 14:00, Benson Margulies wrote: Here's the relevant log traffic of the missing method. I can get past this problem by putting xalan into the endorsed directory, but I should not have to do that when using the JAXP 1.4 API to create XPathFactory. Caused by: java.lang.NoSuchMethodError: org.apache.xpath.XPathContext.init(Z)V at org.apache.xpath.jaxp.XPathImpl.eval(XPathImpl.java:207) at org.apache.xpath.jaxp.XPathImpl.evaluate(XPathImpl.java:281) at com.basistech.vws.env.GazetteerConfigManager.initialGazetteerConfiguration(GazetteerConfigManager.java:67) at com.basistech.vws.env.RLPEnvironmentManager.initialGazetteerConfiguration(RLPEnvironmentManager.java:400) at com.basistech.vws.env.RLPEnvironmentManager.initialConfiguration(RLPEnvironmentManager.java:358) at com.basistech.vws.env.RLPEnvironmentManager.initialize(RLPEnvironmentManager.java:182) ... 48 more org.apache.cxf.common.injection.ResourceInjector - method annotated by @PostConstruct throws exception when invoked java.lang.reflect.InvocationTargetException On Tue, Nov 3, 2009 at 7:48 AM, André Warnier a...@ice-sa.com wrote: Benson Margulies wrote: I have a webapp that makes calls to the JAXP 1.4/Java 1.6 APIs that allow the caller to pass in the class name of implementation classes. It all works find standalone. It works fine in Jetty. It fails in Tomcat 6.0.20. The error is a missing method in a Xalan class; as if Tomcat has somehow gotten an older version of Xalan into the classpath. I don't see any likely suspects in the Tomcat tree, so I'm momentarily mystified. A piece of the logfile where the error messages occur may help someone to help you. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Xalan classpath problem
I've attached a self-contained test case to bz 48116, so you can see this for yourself. On Tue, Nov 3, 2009 at 9:22 AM, Rainer Jung rainer.j...@kippdata.de wrote: Just to make sure w.r.t. it being working in Jetty: You use the same Java version? Sun changed an important bit between Java 5 and Java 6, where they are now caching something detected during runtime in a global static thus partially breaking the dynamics of XML parser detection when using mutiple classloaders. The usual indication is a class cast exception, which is not the case in your situation, but nevertheless I wanted to check, whether there's a relation to Java 6 vs. Java 5 (handling in Java 6 is broken). Regards, Rainer On 03.11.2009 14:00, Benson Margulies wrote: Here's the relevant log traffic of the missing method. I can get past this problem by putting xalan into the endorsed directory, but I should not have to do that when using the JAXP 1.4 API to create XPathFactory. Caused by: java.lang.NoSuchMethodError: org.apache.xpath.XPathContext.init(Z)V at org.apache.xpath.jaxp.XPathImpl.eval(XPathImpl.java:207) at org.apache.xpath.jaxp.XPathImpl.evaluate(XPathImpl.java:281) at com.basistech.vws.env.GazetteerConfigManager.initialGazetteerConfiguration(GazetteerConfigManager.java:67) at com.basistech.vws.env.RLPEnvironmentManager.initialGazetteerConfiguration(RLPEnvironmentManager.java:400) at com.basistech.vws.env.RLPEnvironmentManager.initialConfiguration(RLPEnvironmentManager.java:358) at com.basistech.vws.env.RLPEnvironmentManager.initialize(RLPEnvironmentManager.java:182) ... 48 more org.apache.cxf.common.injection.ResourceInjector - method annotated by @PostConstruct throws exception when invoked java.lang.reflect.InvocationTargetException On Tue, Nov 3, 2009 at 7:48 AM, André Warnier a...@ice-sa.com wrote: Benson Margulies wrote: I have a webapp that makes calls to the JAXP 1.4/Java 1.6 APIs that allow the caller to pass in the class name of implementation classes. It all works find standalone. It works fine in Jetty. It fails in Tomcat 6.0.20. The error is a missing method in a Xalan class; as if Tomcat has somehow gotten an older version of Xalan into the classpath. I don't see any likely suspects in the Tomcat tree, so I'm momentarily mystified. A piece of the logfile where the error messages occur may help someone to help you. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
