Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (athena.apache.org: domain of samindaa@gmail.com designates
 209.85.198.248 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=l4RieH8CrFcc3zl0TLguaetYBBP8NoOZDQT1eR/27keX6ZRpiVtyh3mup95NPggW+oTCWjGuEJh6GhvTjm07evvSwUpd24Q75dpPaV5m0rMNGNyUA/PLkRMueMop1HlvK+r+aR1NpVJDJi3nExmVLUey9snmmbmPAe6wqmbMhKo=
Message-ID: <aa8fdb10805220408kad0cd49g47f22d6a5e077d31@mail.gmail.com>
Date: Thu, 22 May 2008 16:38:13 +0530
From: "Saminda Abeyruwan" <samindaa@gmail.com>
To: dev@felix.apache.org
Subject: Re: Bundle class loader
In-Reply-To: <81f0d9c0805220313u20b46416hd6c05148176abf34@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_11546_20197896.1211454493107"
References: <aa8fdb10805220109r108a6e01r8e091aaafb8592f0@mail.gmail.com>
	 <C069C4D2-E46E-463C-BF1A-EBDB53EFAED3@luminis.nl>
	 <aa8fdb10805220214j722fa13cx26afa063240aa7fb@mail.gmail.com>
	 <4A635829-B8DE-4460-8B9F-81A5CE173AF1@luminis.nl>
	 <aa8fdb10805220246l5d55ced6qa8f4b2281ac8faa5@mail.gmail.com>
	 <81f0d9c0805220313u20b46416hd6c05148176abf34@mail.gmail.com>

------=_Part_11546_20197896.1211454493107
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Stuart,

When users need to get code from legacy jars and load from TCCL,  wouldn't
it be useful to give them the option of setting the OSGi aware classloader
to TCCL. May be a Felix specific manifest header will be suffix.

When we design and implement OSGi aware code, we are always focus on writing
code to tally with OSGi semantics, such as using service registry,
class/resources load from bundle etc. But when we depend on 3rd part
dependencies, where the programmer has no control over or licence wouldn't
allow to change the code, if those jars try to load classes from TCCL , in
Felix OSGi implementation, this scenario will fail. IMHO loading classes
from TCCL is a very heavily used use case.

On the contrary, if TCCL reference to the root classpath, IMHO the
classloader isolation and version also fail. If we think parallel to  host
Vs  embed scenario of Felix, if the  classpath  where the system start
contains unwanted jars or if someone accidently  set CLASSPATH global
variable, theses classes and resources will be visible from TCCL. Thus, the
whole purpose of classloader isolation will be lost.

IMHO if the TCCL and this.getClassloader() would be set sync, I believe in
programming perspective, it will really helpful for programmers to visualize
the classloading and classloder delegation mechanism more clearly.

Thank you!

Saminda

On Thu, May 22, 2008 at 3:43 PM, Stuart McCulloch <
stuart.mcculloch@jayway.net> wrote:

> 2008/5/22 Saminda Abeyruwan <samindaa@gmail.com>:
>
> > Did some debuging further. Class not found exception  occurs when the
> > required class is loaded from TCCL.
> > "Thread.currentThread().getContextClassLoader()"
> > When I checked the TCCL, it's not OSGi aware (it's not create from
> Felix).
> > TCCL contains the classloader coming from the boot classpath. Is this the
> > accepted behaviour ?
> >
>
> from what I remember the OSGi spec doesn't mandate
> setting TCCL to the bundle classloader, although some
> frameworks like Equinox do set it to help legacy code
> (they set it to a ContextFinder, which != bundle loader)
>
> if you want access to the bundle classloader, select a
> class, or instance, that was loaded by that bundle (like
> the activator) and use class.getClassLoader()
>
> or alternatively use loadClass() method from the bundle
> object, which you get from the getBundle() method on
> the bundle context, and this will use the right loader.
>
> btw, you can also use services to support loading of
> classes or instances from other bundles (just register
> your own service to do this that provides some sort
> of builder API)
>
> HTH
>
> Saminda
> >
> > On Thu, May 22, 2008 at 2:48 PM, Marcel Offermans <
> > marcel.offermans@luminis.nl> wrote:
> >
> > > Can you strip the example up to the point where we can have a look at
> it?
> > > It could be that the class that refuses to load needs something that is
> > not
> > > available.
> > >
> > > Greetings, Marcel
> > >
> > >
> > > On May 22, 2008, at 11:14 , Saminda Abeyruwan wrote:
> > >
> > >  "." is present
> > >>
> > >> Saminda
> > >>
> > >> On Thu, May 22, 2008 at 2:33 PM, Marcel Offermans <
> > >> marcel.offermans@luminis.nl> wrote:
> > >>
> > >>  On May 22, 2008, at 10:09 , Saminda Abeyruwan wrote:
> > >>>
> > >>> Bundle A exports some package "a.b". In addition to this, this bundle
> > >>>
> > >>>> embed
> > >>>> a foo.jar and manifest has Bundle-Classpath: foo.jar
> > >>>>
> > >>>> Bundle B imports package "a.b". Say the activator of bundle B calls
> a
> > >>>> class
> > >>>> of this package. When this happen, I'm seen a class not found
> > exception
> > >>>> from
> > >>>> a.b class, which is available in foo.jar. When bundle B's class
> loader
> > >>>> delegates to bundle A's class loader, this shouldn't be a problem.
> Am
> > I
> > >>>> doing something wrong ?
> > >>>>
> > >>>>
> > >>> If my memory serves me well, you need to explicitly include "." in
> the
> > >>> bundle classpath, so:
> > >>>
> > >>> Bundle-Classpath: ., foo.jar
> > >>>
> > >>> Greetings, Marcel
> > >>>
> > >>>
> > >>>
> > >>
> > >> --
> > >> Saminda Abeyruwan
> > >>
> > >> Senior Software Engineer
> > >> WSO2 Inc. - www.wso2.org
> > >>
> > >
> > >
> >
> >
> > --
> > Saminda Abeyruwan
> >
> > Senior Software Engineer
> > WSO2 Inc. - www.wso2.org
> >
>
>
>
> --
> Cheers, Stuart
>


-- 
Saminda Abeyruwan

Senior Software Engineer
WSO2 Inc. - www.wso2.org

------=_Part_11546_20197896.1211454493107--