When multiple versions of packages was introduced in R4.0 we came
across some scenarios where client bundles were getting service
objects and never casting them to a service type. Instead they would
just use reflection to call the service methods. In these cases the
bundle is not wired to the package for the service type. We did not
want to break these types of bundles in R4.0. You are correct that
the bundle still could load the class from its own private class
path if it is not wired to another package. But this is no different
than in OSGi R3. In R3 we did not support multiple versions of
exported packages but we still could have different bundles load
private versions of the package from their own private class path.
The introduction of isAssignableTo() in R4.0 is to solve the issues
with multiple exporters of the same package. For better or worse it
is not intended to solve the incompatibility possible from loading
classes from a bundle's private class path. That has always been a
possible issue since OSGi R1 and at the time of R4.0 the Alliance
did not feel that the issue was important enough to introduce an
incompatible change in R4.0 to address the issue.
HTH.
Tom
<graycol.gif>"Alan D. Cabrera" ---04/15/2009 09:39:38 AM---Ok, I
think we're getting to the crux of my misunderstanding. To my mind
stopping when there are not wires is dangerous becaus
<ecblank.gif>
From: <ecblank.gif>
"Alan D. Cabrera" <[email protected] <mailto:[email protected]>>
<ecblank.gif>
To: <ecblank.gif>
OSGi Developer Mail List <[email protected]
<mailto:[email protected]>>
<ecblank.gif>
Date: <ecblank.gif>
04/15/2009 09:39 AM
<ecblank.gif>
Subject: <ecblank.gif>
Re: [osgi-dev] isAssignableTo() and the system bundle
------------------------------------------------------------------------
Ok, I think we're getting to the crux of my misunderstanding. To my
mind stopping when there are not wires is dangerous because the
other bundle could still technically load an interface with the same
name from its classloader even if there are no wires and, so, you
will get a class cast exception.
Now, you state "we assume reflection is being used if the consuming
bundle is not wired to the package of the service class". Can you
explain what this means?
Regards,
Alan
On Apr 15, 2009, at 6:57 AM, Thomas Watson wrote:
Equinox behaves the same as Felix here.
Personally I find the term "not incompatible" hard to
understand in section 5.9.1. Seem "not incompatible" is
just "compatible".
Section 6.1.23.6 is the JavaDoc for isAssignableTo() but
I don't think it necessarily reflects the intent of
section 5.9.1. By "last sentence" I assume you mean the
sentence in 5.9.1 "That is, it is either wired to the
same source
class loader or it has no wire for that package at
all.". For the case where the consuming bundle is not
wired to the package at all it is "compatible" with the
service because it can never cast that service to the
service type. The point of this method is to avoid
ClassCastExceptions in the consuming bundle. As Richard
points out we assume reflection is being used if the
consuming bundle is not wired to the package of the
service class.
Tom
<graycol.gif>"Alan D. Cabrera" ---04/14/2009 10:26:23
PM---The JavaDoc reflects section 6.1.23.6 and more
accurately reflects the intent of section 5.9.1. That
last sentence, to my mind
<ecblank.gif>
From: <ecblank.gif>
"Alan D. Cabrera" <[email protected]_
<mailto:[email protected]>>
<ecblank.gif>
To: <ecblank.gif>
OSGi Developer Mail List <[email protected]_
<mailto:[email protected]>>
<ecblank.gif>
Date: <ecblank.gif>
04/14/2009 10:26 PM
<ecblank.gif>
Subject: <ecblank.gif>
Re: [osgi-dev] isAssignableTo() and the system bundle
------------------------------------------------------------------------
The JavaDoc reflects section 6.1.23.6 and more
accurately reflects the intent of section 5.9.1. That
last sentence, to my mind, is just plain inaccurate and
dangerous.
Regards,
Alan
On Apr 14, 2009, at 8:13 PM, Richard S. Hall wrote:
Maybe the JavaDoc needs to be
updated to more closely resemble
the spec text.
-> richard
On 4/14/09 10:44 PM, Stuart
McCulloch wrote:
2009/4/15 Richard
S. Hall
<[email protected]_
<mailto:[email protected]>>
I think
you
are
not
correct.
If
a bundle
has
no
wire
to
the
package,
which
system
bundle
shouldn't
since
it
cannot
import,
then
it
should
get
back
all
service
references.
I think
the
spec
assumes
you
are
using
reflection
if
you
have
no
wire
to
the
package.
I cannot
remember
if
this
behavior
is
spec'ed
some
place
but
I
thought
so.
At
least
that's
what
we
do
in
Felix
(and
Equinox,
I
believe).
ah...
5.9.1 of
the core
spec:
"The
service
registry
must
therefore ensure
that
bundles
can only
see
services
that are not
incompatible
with
them. A
service
is not
incompatible
with the
bundle
getting
the
service
when
that
bundle
is not
wired to
another
source
class
loader
for this
interface package
than the
bundle
registering
the
service.
That is,
it is
either
wired to
the same
source
class
loader or
it has
no wire
for that
package
at all."
but I
think
Alan has
a point
that if
you read
the
javadoc
for
ServiceReference.isAssignableTo()
it does
seem to
apply a
stronger
rule:
that is
it
returns
true if
both
bundles
use the
same source
for the
package,
otherwise false
so if
the
bundle
providing the
service
has a
wire,
and the
bundle
using
the
service
doesn't have
a wire,
does
that
mean
they use
the
"same
source"
for the
package?
(isAssignableTo()
== true)
->
richard
On
4/14/09
8:09
PM,
Alan
D.
Cabrera
wrote:
After
reading
the
core
spec
it
seems
that
if
I look
for
service
using
the
system
bundle
context,
I will
never
be
able
to
find
any
application
specific
service.
Let
me
explain
my
reasoning
and
maybe
someone
can
show
me
where
my
disconnect
is
occurring.
Upon
reading
the
definition
of
the
getServiceReferences()
method
I see
that
isAssignableTo()
must
be
called
with
all
the
service
interfaces
and
the
bundle
that
is
being
used
to
perform
the
"call"
to
getServiceReferences().
It
seems
to
me
that
if
I pass
the
system
bundle
to
isAssignableTo()
I will
get
false
for
just
about
all
the
application
specific
service
interfaces.
If
that
is
true
then
it
seems
that
I will
not
be
able
to
retrieve
most
service
references
with
the
system
bundle.
Am
I
correct?
Regards,
Alan
_______________________________________________
OSGi
Developer
Mail
List_
[email protected]_
<mailto:[email protected]>_
__https://mail.osgi.org/mailman/listinfo/osgi-dev_
_______________________________________________
OSGi
Developer
Mail
List_
[email protected]_
<mailto:[email protected]>_
__https://mail.osgi.org/mailman/listinfo/osgi-dev_
--
Cheers,
Stuart
------------------------------------------------------------------------
_______________________________________________
OSGi
Developer Mail
List_
[email protected]_
<mailto:[email protected]>_
__https://mail.osgi.org/mailman/listinfo/osgi-dev_
_______________________________________________
OSGi Developer Mail List_
[email protected]_
<mailto:[email protected]>_
__https://mail.osgi.org/mailman/listinfo/osgi-dev_
_______________________________________________
OSGi Developer Mail List_
[email protected]_ <mailto:[email protected]>_
__https://mail.osgi.org/mailman/listinfo/osgi-dev_
_______________________________________________
OSGi Developer Mail List_
[email protected]_ <mailto:[email protected]>_
__https://mail.osgi.org/mailman/listinfo/osgi-dev_
_______________________________________________
OSGi Developer Mail List
[email protected] <mailto:[email protected]>
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected] <mailto:[email protected]>
https://mail.osgi.org/mailman/listinfo/osgi-dev
