felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: ServiceFactory not returned on getServiceReferences()
Date Sat, 04 Feb 2012 13:41:24 GMT
Not sure I get the terminology right:
- The client/consumer bundle imports the service API (separate API
bundle).
- The distribution provider does not know the service API or the
consumer, or vice versa.

On 03.02.2012 16:11:06 Richard S. Hall wrote:
> Just a follow up after talking with Tom Watson (the Equinox lead), there 
> is certainly at least one difference between Felix and Equinox in this 
> area. On Equinox, if the consumer bundle doesn't import or export the 
> service package, then Equinox will always assume it is compatible (i.e., 
> return true). Felix, on the other hand, will actually try to load the 
> class from the consumer bundle and if it has no access at all (i.e., it 
> doesn't import, export, or have it in a private package) then it will 
> true, but if it has access then it requires that the provider have the 
> same class unless the "extender exception" applies.
> 
> So, if it is working under Equinox, is it because you didn't 
> import/export it in your consumer bundle? Otherwise, it sounds like 
> Equinox should work the same way as Felix and you'd be required to use a 
> separate proxy bundle to gain the "extender exception".
> 
> -> 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-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >
> >
> >
> > Jeremias Maerki
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org




Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message