Alasdair
On 24 Nov 2010, at 17:18, John Platts <[email protected]> wrote: > > Other real use cases where offline inspection would not be sufficient include: > - Some libraries rely on META-INF/services to discover implementations of > interfaces. Although these implementations can be exposed as OSGi services, > many of these libraries must work outside of the OSGi environment. Many of > these libraries implement custom service discovery code because they support > J2SE 1.4 or Java SE 5. The java.util.ServiceLoader class requires Java SE 6 > or later, and it is also not OSGi-aware. In addition, the > org.osgi.util.tracker.ServiceTracker class can only be used in the OSGi > environment, and requires a valid BundleContext. > - Web Application Bundles running in a servlet container implementing the > Servlet 3.0 specification or later require access to resources in the > META-INF directory of bundles referenced by Web Application Bundles Sooty if this a bit blunt, but why? What does it need from these other bundles? Are these resources spec mandated in some way? > > ---------------------------------------- >> Date: Wed, 24 Nov 2010 17:52:54 +0100 >> Subject: Re: Issues that need to be addressed in Apache Felix and the OSGi >> specification >> From: [email protected] >> To: [email protected] >> >> If you're referring to the fact that using spring custom namespaces in >> osgi forces you to actually import a lot of packages, this is indeed a >> problem specific to the way Spring-DM handles custom namespaces. >> Do you have use cases for that other than when using SPring-DM ? If >> so, can you explicit the real use cases where offline inspection would >> not be sufficient ? >> >> On Wed, Nov 24, 2010 at 17:28, 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. >>> >>> 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. This feature is useful because: >>> - It eliminates the need to do a dynamic import of the needed packages >>> - 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 >>> >>> ---------------------------------------- >>>> 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] >>> >>> >> >> >> >> -- >> 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]
