Here's a test case that is a boiled down example: http://www.jeremias-maerki.ch/download/osgi/ServiceFactoryAccessibilityTestCase.diff
It didn't get that simple: the test has to create 4 bundles on the fly to run the test. But it demonstrates the case. But given the overall consensus I'm probably going with the proxy/dummy bundle. Nice idea, Holger, to create that on-the-fly. Eases down on the deployment head-aches. Richard, when you say that the "extender" exception is bogus, do you imply that the whole case 2 check should be removed (since nothing would remain of the if after removing that check)? That would mean that only ServiceFactories provided by bundle providing the service are allowed as valid use cases of a ServiceFactory, right? Of course, that would then mean that the RSA specification would have to be amended because it suggests to use a ServiceFactory. On 03.02.2012 15:49:25 Richard S. Hall wrote: > I had talked about this issue with the Equinox team with regards to this > bug: > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=326918 > > It is my understanding that Equinox has a similar set of rules as the > Felix framework. I know for a fact that they do not simply return true > for the existence of any ServiceFactory; that is not a viable solution. > > I also know that the ECF guys ran into this same issue (with Equinox) > and that they solved it by introducing a separate proxy bundle under > which they'd register their service factories. > > However, if you can boil down a simple example test case to reproduce > the issue, I'll gladly take a look at it and see if there is any > refinement in the rules that might help; although, in all honesty I > don't see how...even the "extender" exception is actually bogus since it > opens up the possibility of false positives. > > -> richard > > On 2/3/12 09:38 , Jeremias Maerki wrote: > > Ok, I've just modified Framework 3.0.9 with the proposed change below > > and suddenly, my code works. I've used 3.0.9 because that's what I'm > > currently using in my system. I've tried trunk but that caused the > > following upon startup: > > org.osgi.framework.BundleException: Exported package names cannot be zero > > length. > > at > > org.apache.felix.framework.util.manifestparser.ManifestParser.normalizeExportClauses(ManifestParser.java:729) > > at > > org.apache.felix.framework.util.manifestparser.ManifestParser.<init>(ManifestParser.java:191) > > at > > org.apache.felix.framework.ExtensionManager.<init>(ExtensionManager.java:220) > > at org.apache.felix.framework.Felix.<init>(Felix.java:374) > > at > > org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:28) > > at org.apache.karaf.main.Main.launch(Main.java:265) > > at org.apache.karaf.main.Main.main(Main.java:426) > > But that's a different story. > > > > I've also scaled down my test system so it works with Equinox, and there > > it works, too. > > > > On 03.02.2012 15:08:17 Jeremias Maerki wrote: > >> Thanks for your reply, Richard! > >> > >> I was thinking about removing the following part of the "if" in the > >> "case 2" check: > >> > >> 164&& (m_factory.getClass().getClassLoader() instanceof BundleReference) > >> 165&& !((BundleReference) m_factory.getClass() > >> 166 getClassLoader()).getBundle().equals(m_bundle)) > >> > >> Basically: > >> if (m_factory != null) { > >> return true; > >> } > >> > >> which would mean: rely on the ServiceFactory to produce correct service > >> objects. I'm sorry about the word "arbitrary". I just couldn't figure > >> out where that second part of the "if" came from. The comment above the > >> check talks about extenders which have to be careful about wiring, too. > >> But if you don't really have a target bundle like an extender you can > >> only put the generated ServiceFactories in the distribution provider > >> bundle itself (in my case). > >> > >> I guess, I'll try the modification myself first, before you dive into > >> this. > >> > >> I've tried with Equinox but had so many issues getting my system running > >> that I haven't further pursued it. I guess I can try to scale down the > >> test setup and retry. Knopflerfish worked out of the box. > >> > >> Will report back later... > >> > >> > >> On 03.02.2012 14:50:07 Richard S. Hall wrote: > >>> On 2/3/12 04:23 , Jeremias Maerki wrote: > >>>> Hi everyone, > >>>> > >>>> I'd like to pick up on a discussion that happened in May 2009 on the dev > >>>> list: http://felix.markmail.org/thread/tdowmhihje4c4fza > >>>> > >>>> I think I have a related problem. My use case is this: I'm trying to > >>>> implement a simple Remote Services implementation and have a > >>>> distribution provider that creates service proxies for imported services. > >>>> Since the distribution provider has no wires to the various possible API > >>>> bundles for the imported services, it has to create ServiceFactories so > >>>> it can first load the interface(s) using the caller bundle and provide > >>>> it with a proxy for the right interface for the caller. > >>>> > >>>> Now, Felix doesn't return the imported service (the ServiceFactory), > >>>> probably because of the check for case 2 in > >>>> ServiceRegistrationImpl.isClassAccessible(): > >>>> http://svn.apache.org/viewvc/felix/trunk/framework/src/main/java/org/apache/felix/framework/ServiceRegistrationImpl.java?view=annotate > >>>> That check was introduced in October 2009 (rev 830347). > >>>> > >>>> That check feels a little arbitrary to me. I guess it works for the > >>>> extender case where an extender bundle registers a ServiceFactory under > >>>> the target bundle's BundleContext. But in the case of Remote Services I > >>>> don't have such a target bundle. The only bundle I can register the > >>>> ServiceFactories under is the distribution provider itself. But the case > >>>> 2 check prohibits that. I have a feeling that if I created a "service > >>>> contrainer bundle" next to the distribution provider that receives the > >>>> ServiceRegistrations for the proxies I could probably circumvent this > >>>> check. But that's not elegant. > >>>> > >>>> I've run my code against Knopflerfish to see how it reacts and there my > >>>> approach worked just fine. > >>>> > >>>> The Remote Service Admin spec even hints in 122.5.6 Proxying (4.2. > >>>> Enterprise) at using a ServiceProxy and that it's responsible for > >>>> avoiding ClassCastExceptions. I may have missed something but Felix may > >>>> be too restrictive here. Any thoughts? > >>> I doubt that Felix is too restrictive and certainly not arbitrary...in > >>> fact, by the letter of the spec, Felix isn't restrictive enough. The > >>> spec just says something about if they don't have wires, then fail. > >>> > >>> We could certainly try to improve the heuristic, but do you have a > >>> specific suggestion? It is already pretty complicated. The framework is > >>> responsible for making sure that bundles do not get class cast > >>> exceptions, so we can't allow false positives. > >>> > >>> Did you try this on Equinox? > >>> > >>> -> richard > >>> > >> > >> Thanks, > >> Jeremias Maerki > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > >> For additional commands, e-mail: users-h...@felix.apache.org > > > > > > > > Jeremias Maerki > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > > For additional commands, e-mail: users-h...@felix.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
