Hi Yes, +1 for moving to util. Also agree that some of the generic osgi tools move to util like manifest processing related. I know it can be used at least in subsystems, besides the current application project.
Thanks Lin On Tue, Oct 26, 2010 at 7:09 AM, Timothy Ward <[email protected]> wrote: > > Hi, > > I would also be +1 for this, but I'd prefer the implementation not to > override loadclass(). > > I think that at the same time we should move some of the other generic OSGi > tools such as the ManifestHeaderProcessor. The function there would be great > for JPA and for blueprint, but at the moment they would have to import from > the application utils bundle which would bloat the dependency graph. > > Regards, > > Tim > > ---------------------------------------- >> Subject: Re: Utility for making a Bundle look like a ClassLoader >> From: [email protected] >> Date: Tue, 26 Oct 2010 07:36:07 +0100 >> To: [email protected] >> >> + 1 >> >> I think those were duplicated for short-term convenience more than anything >> else. >> >> Valentin >> >> On 25 Oct 2010, at 22:39, Alasdair Nottingham wrote: >> >> > It appears that we have multiple classes which basically create a >> > ClassLoader that delegates to a Bundle. Ones I know of are: >> > >> > /blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/utils/BundleDelegatingClassLoader.java >> > /util/src/main/java/org/apache/aries/util/BundleToClassLoaderAdapter.java >> > /jpa/jpa-container/src/main/java/org/apache/aries/jpa/container/unit/impl/BundleDelegatingClassLoader.java >> > >> > There may be others. I was wondering if it would make sense to try to >> > common these up into one place? >> > >> > Thoughts? >> > Alasdair >> > >> > -- >> > Alasdair Nottingham >> > [email protected] >> >
