Well SCR could synthesize such an object using java.lang.reflect.Proxy.
But the user of such an object may themselve fail if they call a method on
it which does not return some expected object. So null object is not a
universal solution. It just avoid the need for the null check in your
code.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
Office: +1 407 849 9117 Mobile: +1 386 848 3788
Roy Paterson/Austin/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
2006-05-11 02:25 PM
Please respond to
OSGi Developer Mail List <osgi-dev@bundles.osgi.org>
To
OSGi Developer Mail List <osgi-dev@bundles.osgi.org>
cc
Subject
Re: [osgi-dev] Declarative Services implementation guidelines?
How could SCR generically implement a null object? In the case of
logservice it makes sense to have the methods not do anything and return
null, but I don't think that is universally valid for all interfaces.
-----------------------------------------
Roy Paterson
IBM Pervasive Computing
Austin, TX
Phone: (512) 838-8898
BJ
Hargrave/Austin/I
[EMAIL PROTECTED]
To
Sent by: OSGi Developer Mail List
osgi-dev-bounces@ <osgi-dev@bundles.osgi.org>
bundles.osgi.org cc
Subject
05/11/2006 12:25 Re: [osgi-dev] Declarative Services
PM implementation guidelines?
Please respond to
OSGi Developer
Mail List
<[EMAIL PROTECTED]
.osgi.org>
Yes. I dont think SCR could bind these null objects by default. The
component itself would have to chose to do this in its unbind method.
However, an option could be added to SCR, where the programmer, could
request null objects when otherwise unbound. Assuming the service is
referenced via an interface, then a null object can be synthesized via a
dynamic proxy.
If some feels this is interesting, please open a bug on the
bundles.osgi.org bugzilla system to request this feature.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
Office: +1 407 849 9117 Mobile: +1 386 848 3788
"Kevin Riff" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
2006-05-11 12:56 PM
Please respond to
OSGi Developer Mail List <osgi-dev@bundles.osgi.org>
To
"OSGi Developer Mail List" <osgi-dev@bundles.osgi.org>
cc
Subject
Re: [osgi-dev] Declarative Services implementation guidelines?
Would that be legal? If no service is available the SCR should be
binding that reference to null so that the component knows that it's
unbound. It might be able to make alternate arrangements, like sending
log messages to System.out instead. But if you give it a "null" object,
then it won't know that its logging messages are being discarded.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of BJ Hargrave
Sent: Thursday, May 11, 2006 10:35 AM
To: OSGi Developer Mail List
Subject: Re: [osgi-dev] Declarative Services implementation guidelines?
So by null object, you mean an object which implements the LogService
interface but whose methods are no-ops?
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
Office: +1 407 849 9117 Mobile: +1 386 848 3788
Marcel Offermans <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
2006-05-11 10:16 AM
Please respond to
OSGi Developer Mail List <osgi-dev@bundles.osgi.org>
To
OSGi Developer Mail List <osgi-dev@bundles.osgi.org>
cc
Subject
Re: [osgi-dev] Declarative Services implementation guidelines?
Kevin Riff wrote:
>Copying to a local variable first would also work, but only if the log
>field is volatile. Otherwise you risk having your threads see a stale
>copy of that field.
>
>
>-----Original Message-----
> // ...
> if(log != null) {
> log.log(LogService.INFO, "Did something");
> }
> // ...
>
>
In the dependency manager I've used the null object pattern to make this
a bit easier for the user. Instead of "nulling" the field when the
service is not available, I create a null object so you don't have to
check for null everywhere. Of course you should use this combined with
the volatile keyword, like Kevin suggested.
The null object implementation I've used should be pretty easy to re-use
(even if you don't use the dependency manager).
Greetings, Marcel
_______________________________________________
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
