Btw, doesn't Virgo / Spring-DM Server has the concept of library which does exactly what John is describing ? Those may be solved in the future by using Subsystems maybe.
On Wed, Nov 24, 2010 at 18:07, Justin Edelson <[email protected]> wrote: > On 11/24/10 12:01 PM, Guillaume Nodet wrote: >> On Wed, Nov 24, 2010 at 17:45, Justin Edelson <[email protected]> >> wrote: >>> On 11/24/10 11:28 AM, John Platts wrote: >>>> >>>> I actually want to address issues with Felix and the OSGi specification >>>> that are not specific to the Spring Framework, Spring DM, or Eclipse >>>> Gemini. >>> >>> That's fine. But what you are suggesting IMHO is to break modularity and >>> so whether this is an "issue" in the OSGi spec is *highly* debatable. >>> >>>> >>>> One of the real issues that I want to address is to be able to import >>>> bundles containing certain packages without having to list all of the >>>> packages exported by that bundle and without having to know the symbolic >>>> name of the bundle. >>> >>> So... you want to be able to have: >>> >>> Bundle-Symbolic-Name: com.test.bundle1 >>> Export-Package: foo,bar >>> >>> and >>> >>> Bundle-Symbolic-Name: com.test.bundle2 >>> Import-Package foo >>> >>> And have com.test.bundle2 *also* import package bar just because foo and >>> bar are both exported by com.test.bundle1? >>> >>> >>>> This feature is useful because: >>>> - It eliminates the need to do a dynamic import of the needed packages >>> Dynamic imports are not a general purpose feature. They should only be >>> used in specific cases. >>> >>>> - It allows entire bundles to be imported without having to know the >>>> symbolic names of the bundles >>>> - It does not require the user to know all of the packages exported by a >>>> bundle >>> What's the use case for importing all of the packages a particular >>> bundle exports without knowing either the symbolic name of the bundle or >>> the list of packages? >> >> Maybe I'm wrong, but my first impression is that John is hitting the >> same problems I had with Spring-DM over the past years (see >> http://gnodet.blogspot.com/2010/03/spring-dm-aries-blueprint-and-custom.html >> for more informations). >> One of those problem is that when using a spring custom namespace, the >> namespace does not contribute to the classloader for the blueprint >> application, hence all classes have to come from the bundle itself >> while they are not referenced directly, but indirectly through the >> custom namespace. That's a design problem in the way spring-dm has >> been built imho. >> I have actually hit this problem and fixed that in Aries Blueprint >> along with the other Spring-DM problems I mentionned in my blog. > > This is a legitimate problem, but I don't see how John's proposed > resolution helps this. It isn't necessarily the case that if you use a > custom namespace, you will be importing a package from the bundle which > defines that namespace. > > Justin > > >> >> If John is not referring to those problems, I'd be happy to get back >> to the real problems, but that's really why I asked for the real use >> cases. >> >>> >>> Justin >>> >>> >>>> >>>> ---------------------------------------- >>>>> Date: Wed, 24 Nov 2010 17:02:06 +0100 >>>>> Subject: Re: Issues that need to be addressed in Apache Felix and the >>>>> OSGi specification >>>>> From: [email protected] >>>>> To: [email protected] >>>>> >>>>> On Wed, Nov 24, 2010 at 16:51, John Platts wrote: >>>>>> >>>>>> I have been running into several problems when developing web >>>>>> application bundles that utilize the Spring Framework. The problems that >>>>>> I have been running into are: >>>>>> - The Spring Framework needs to access META-INF/spring.handlers and >>>>>> META-INF/spring.schemas files in JARs that have these files >>>>>> - The Spring Framework needs access to packages that are not in the >>>>>> Import-Package header of web application bundles that utilize the Spring >>>>>> Framework >>>>>> >>>>> >>>>> I agree those are real issues with Spring-DM. But that's not really >>>>> the place for such discussions. >>>>> FWIW, you should give Aries Blueprint a try, as all those problems >>>>> have been solved in it. >>>>> >>>>>> The issues that really need to be addressed in both Apache Felix and the >>>>>> OSGi specification are: >>>>>> - The ability to require bundles by specifying packages that they export >>>>>> instead of by specifying the symbolic names of the bundles. >>>>>> - The ability to make META-INF and its subdirectories visible to class >>>>>> loaders of bundles that meet at least one of the following criteria: >>>>>> - Requires a bundle >>>>>> - Imports all of the packages exported by the bundle (by requiring >>>>>> bundle(s), importing package(s), and/or dynamically importing >>>>>> package(s)) plus has a DynamicImport-Package header that includes >>>>>> META-INF and its subdirectories >>>>>> >>>>>> Addressing the issues above will make it easier to use OSGi bundles from >>>>>> Web Application Bundles without having to rely on workarounds. >>>>> >>>>> What are you underlying problem ? Maybe they already have some >>>>> solutions. For the first one, this is an OSGi good practice and is >>>>> done widely, so not sure what your issue is. The second one might be >>>>> related to various issues which i'm quite sure have been fixed in >>>>> various ways (having solved some myself). >>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Cheers, >>>>> Guillaume Nodet >>>>> ------------------------ >>>>> Blog: http://gnodet.blogspot.com/ >>>>> ------------------------ >>>>> Open Source SOA >>>>> http://fusesource.com >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
