Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Users List" <user@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of rahul.akolkar@gmail.com
 designates 209.85.221.177 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=A916XXhEpB7uHKau9HsPSdpNuW+yPP2S5Mub4EQNf5YD+GEiIbPu6Mv8Y8AtFsC8+T
         ovM6enNEcWvLT4FCpbvPbXaANPUt3oMe2nf8cwJ1xqfUemYCzzSbCbMqFrvuvpuYGIPf
         48r6GyAKFbzCQWjTOEckGzZLY2jq/oTJy/Xw8=
MIME-Version: 1.0
In-Reply-To: <4917B331-FE38-46D1-800C-F06B8C98336D@openmethods.com>
References: <4B61B65D.8030004@googlemail.com>
	 <4917B331-FE38-46D1-800C-F06B8C98336D@openmethods.com>
Date: Thu, 28 Jan 2010 14:51:26 -0500
Message-ID: <ce1f2ea81001281151o5756576djb888a17caba71e96@mail.gmail.com>
Subject: Re: [SCXML] Modifying classloader for SCXML digester?
From: Rahul Akolkar <rahul.akolkar@gmail.com>
To: Commons Users List <user@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 28, 2010 at 1:16 PM, Bill Herring <bherring@openmethods.com> wr=
ote:
> I'm developing an Eclipse plugin application and have Commons SCXML and
> Digester in a plugin/bundle separate from my main project bundle. =A0The
> problem with this is that if I'm submitting a list of custom actions to
> SCXMLParser.parse() the classloader that digester is using can't find the
> custom action classes and throws an exception. =A0The offending line is i=
n
> digester.ObjectCreateRule.begin():
>
> =A0 =A0 Class<?> clazz =3D digester.getClassLoader().loadClass(realClassN=
ame);
>
> The docs for getClassLoader() indicate that I can use setClassLoader() to
> use another class loader, which might solve my problem. =A0However, I can=
't
> find a simple way to invoke that function before SCXMLParser.parse()
> generates the error. =A0I can use SCXMLParser.getInstance() to get a dige=
ster
> instance, and then I can call setClassLoader() and then invoke parse() on
> the digester directly. Doing that, I have to set up the digester rules
> manually before parsing, which appears doable but non-trivial...
>
<snip/>

Thats one way, if you choose that as a reminder there is a post
digester parsing step that needs to be invoked in such scenarios (as
mentioned in the Javadoc).


> Is there a simpler way to coax the digester used in SCXMLParser.parse() t=
o
> employ a different class loader?
>
<snap/>

Indirectly, by resolving this at the framework (OSGi) level. This is a
classic example from a set of valid scenarios that are faced when
using bundles that expect to see both application / client code as
well as their own code (obviously). For such scenarios, its usually
possible to use the Eclipse buddy class loading mechanisms. Look up
the Eclipse-BuddyPolicy and Eclipse-RegisterBuddy manifest entries to
see if that works for you.

-Rahul


> =A0Thanks,
> Bill
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org