Thanks for the quick response, Richard. I'll clarify my 'extender model' comment a little more. We're writing a web application which is sold as an installable software product. There are two use cases right now, and maybe more in the feature, where there are bundles which we would like to deliver to customers as a subscription service. These bundles don't provide new versions of existing services, or completely new services, they only provide additional implementations of existing interfaces (where the interfaces already exist in the classpath).
One of these use cases is deploying new reports to the server, where the bundle for the report would contain some proprietary files related to our report engine, a POJO implementing an interface in the classpath, some resources such as images. As these bundles are deployed, we'll be listening for their deployment and maintaining a registry of their availability, so that when users go to find which reports are available the newly deployed reports will show up. We'll also be extracting the report-engine files and resources to a location on disk, which is required for the report engine. The report POJO might need access to any number of packages which may or may not already be on the classpath. When I write the code (which lives in the classpath) to instantiate Felix, I don't want to have to predetermine which packages future report bundles will and will not need access to. I also don't want to export packages A and B to the system classpath, and end up with the unforeseen dependency on package C in future bundles. I could always include package C in those bundles, but then I would run into the problem where there were two instances of package C running. If I'm thinking incorrectly about this, please let me know. I think the answer you gave me (setting boot delegation to *) gives me the answer I need, but I at least wanted to talk through the use case in case it gives you an additional use case for Felix. Again, thanks for your help! Matt -----Original Message----- From: Richard S. Hall [mailto:[EMAIL PROTECTED] Sent: Thursday, August 30, 2007 8:52 AM To: [email protected] Subject: Re: osgi.parentClassLoader That is Equinox-specific...we had talked briefly about allowing a class loader to be passed into the Felix constructor for delegation purposes, but didn't really have a compelling reason to do so. Anyhow, Felix doesn't separate the framework classes from the application class loader, like Equinox does. So, if you want to expose everything on the class path to your bundles, then I am pretty sure it is sufficient to just set boot delegation to "*". I do not really understand your comment about using the extender model instead of the service model and therefore isolation is not necessary. Use of the extender model is orthogonal to isolation. It is probably still better to set the framework system packages property to explicitly list the packages to expose from the class path, that way your bundles can explicitly import them so you know their dependencies. The system packages list only needs to be maintained in a single place in the framework for all bundles and most bundle development tools will automatically calculate your bundle imports, so you don't have to do anything there... -> richard Matt Clark wrote: > Hi all, > > > > Does Felix support the property osgi.parentClassLoader, or is that an > Equinox-specific configuration setting? I am embedding Felix in a webapp to > register extensions to our application, and would like to be able to use the > 'fwk' setting to expose all packages known by the classloader that loaded > the Felix framework to bundles. I've read that this could also be done > through extension bundles, but 1) I've read about some recent bugs with > those (http://www.mail-archive.com/[EMAIL PROTECTED]/msg01283.html), and > 2) the thought of having to maintain a list of all packages which we would > like to be available to the bundles scares me. > > > > FWIW, our use case is pretty simple. We would like to be able to hot-deploy > extensions (classes and resources) to our application, and these will all > follow the 'extender' model rather than the 'service' model. As such, I > really don't care about the bundles being isolated from the classpath. > > > > Any help is appreciated :-) > > > > Thanks, > > Matt Clark > > > --------------------------------------------------------------------- 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]
