Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of bimargulies@gmail.com
 designates 209.85.214.45 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=c5mtWbkMfiNC+ps2Z2ODGqF2Drb/f5X8cR4aMxF18q2/gvXKQXlinX+3LN5P7JwxUP
         4Glgw4m7Jes0XGsi6U7Tpb8zv/JqfbGwFQpl7ZHacLbcr6vP6Z2CuG+S4jZqrUh06Hhg
         mowv41F8iqbBmpxNzR9ogkAPaLDBBqUBcXX8M=
MIME-Version: 1.0
In-Reply-To: <4E01FBB7.3020606@apache.org>
References: <BANLkTi=-2QbtfQi5y3PWpa4sLL7O1C3pzA@mail.gmail.com>
	<4E01F579.70808@apache.org>
	<BANLkTin0CsgQ47NkfbRH8u4+kagPvMtQxw@mail.gmail.com>
	<4E01FBB7.3020606@apache.org>
Date: Wed, 22 Jun 2011 10:36:52 -0400
Message-ID: <BANLkTiknqoaDudNrWSkp4Zz0PHmd-oPyeQ@mail.gmail.com>
Subject: Re: Adding a webapp to a running embedded tomcat 7 with an 'improved'
 class loader results in missing classes?
From: Benson Margulies <bimargulies@gmail.com>
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I agree with your preference. Patch to follow later today.


On Wed, Jun 22, 2011 at 10:27 AM, Mark Thomas <markt@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 tim=
e.)
>
> Mark
>
>> On Wed, Jun 22, 2011 at 10:00 AM, Mark Thomas <markt@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:
>>>>
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 solrContext =3D tomcat.addWe=
bapp("/solr",
>>>> solrWebapp.getCanonicalPath());
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 WebappLoader solrLoader =3D =
new
>>>> WebappLoader(LSHDemoLauncher.class.getClassLoader());
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 solrContext.setLoader(solrLo=
ader);
>>>>
>>>>
>>>> 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