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]
