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 <[email protected]> wrote: > On Wed, Nov 24, 2010 at 18:50, John Platts <[email protected]> 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]
