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? 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]
