You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Benson Margulies <bi...@gmail.com> on 2011/06/22 15:47:55 UTC
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Adding a webapp to a running embedded tomcat 7 with an 'improved'
class loader results in missing classes?
Posted by Benson Margulies <bi...@gmail.com>.
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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Adding a webapp to a running embedded tomcat 7 with an 'improved'
class loader results in missing classes?
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Adding a webapp to a running embedded tomcat 7 with an 'improved'
class loader results in missing classes?
Posted by Benson Margulies <bi...@gmail.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Adding a webapp to a running embedded tomcat 7 with an 'improved'
class loader results in missing classes?
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org