I really agree with what you are trying to say. I am experiencing the issue in Web Application Bundles that use the Spring Framework, even ones that do not import or require Spring DM. One workaround I used is to create a special class loader that will find the Spring bundles imported by the web application bundle using the Package Admin service, and then having the application context using that class loader. This has performance overhead, but allows Web Application Bundles that rely on the Spring Framework, but not on Spring DM, to work correctly when the Spring Framework bundles are installed as OSGi bundles in OSGi-based application servers.
I can understand where using a Require-Bundle-Containing header could be worse and create ClassNotFoundErrors. This problem already exists with DynamicImport-Package. Furthermore, bytecode analysis can be used to ensure that all required packages, excluding those included in the bundle or part of Java SE, are included in Import-Package or Require-Bundle-Containing. There will normally be only one version of the Servlet API classes available in the Java SE environment, and the Java Servlet Specification requires classes that are part of the Servlet API to be present. Also, the OSGi framework will enforce non-dynamic dependencies. A ClassNotFoundError will normally not occur when classes that are part of the Servlet 2.5 specification are used in a Servlet 2.5 or later environment. But this problem might exist with other libraries. ---------------------------------------- > Date: Wed, 24 Nov 2010 20:19:12 +0100 > Subject: Re: Issues that need to be addressed in Apache Felix and the OSGi > specification > From: [email protected] > To: [email protected] > > Sorry if I'm being a bit harsh. I'm really the first one to try to > make things easier for osgi users. I'm just a bit fed up because > Spring-DM has a lot of problems that lead to solutions that don't > really solve the real problems. I have spent a huge amount of time > trying to deal with those issues, then making sure I won't hit those > again while enhancing the Aries Blueprint implementation. > > But please, give a real use case we could work on, and I'd be happy to help. > > On Wed, Nov 24, 2010 at 19:27, Guillaume Nodet wrote: > > On Wed, Nov 24, 2010 at 18:50, John Platts wrote: > >> > >> Importing bundles by the packages they export instead of by their symbolic > >> names would be accomplished by a new manifest header instead of altering > >> the semantics of Import-Package and Require-Bundle. This ensures both > >> backwards and forwards compatibility, and also ensures that Import-Package > >> only imports packages that are specified in the Import-Package list. > >> > >> To require the bundles exporting javax.servlet and javax.servlet.http, you > >> would do the following: > >> Require-Bundle-Containing: > >> javax.servlet;javax.servlet.http;version="[2.5,4.0)" > >> > >> This tells an OSGi framework supporting the Require-Bundle-Containing > >> header to import all of the packages in the bundles that export the > >> javax.servlet and javax.servlet.http package. It also tells the OSGi > >> framework that version 2.5 or later of the javax.servlet and > >> javax.servlet.http packages are also required, and will ensure that > >> version 2.5 or later of the javax.servlet and javax.servlet.http packages > >> are imported. One of the real reasons to use Require-Bundle-Containing is > >> that it finds the bundles exporting packages in the same manner as the > >> Import-Package header, but it imports all of the packages exported by the > >> bundle instead of importing only the packages listed in the Import-Package > >> header. The advantage that Require-Bundle-Containing provides over > >> Require-Bundle is that you do not have to know the symbolic name of the > >> bundles that have to be imported. It also allows the necessary packages to > >> be imported without having to use DynamicImport-Package or list all of the > >> exported packages of a bundle in the Import-Package header. > > > > Can you please explain a real use case ? If the javax.servlet bundle > > is installed, you won't get more than those two packages, so not sure > > how it would solve. Actually, it would be worse, as it would be > > dependant on what is deployed and you could run into > > ClassNotFoundError without any real way to ensure how your bundle has > > been resolved. > > > >> > >> ---------------------------------------- > >>> Date: Wed, 24 Nov 2010 12:07:50 -0500 > >>> From: [email protected] > >>> To: [email protected] > >>> Subject: Re: Issues that need to be addressed in Apache Felix and the > >>> OSGi specification > >>> > >>> On 11/24/10 12:01 PM, Guillaume Nodet wrote: > >>>> On Wed, Nov 24, 2010 at 17:45, Justin Edelson 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] > >>> > >> > >> --------------------------------------------------------------------- > >> 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 > > > > > > -- > 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]
