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

Reply via email to