You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Todor Boev <t....@prosyst.bg> on 2008/11/08 12:52:35 UTC
iPojo: making my pojo constructor injected
Hello,
I managed to make my pojo appear to be constructor injected like so:
@Component(name = "HelloClient", immediate = true)
public class HelloClient {
@Property
private final int delay;
@Requires
private final Hello[] hello;
private Thread thread;
private boolean running;
@SuppressWarnings("unused")
private HelloClient() {
this(null, 0);
}
public HelloClient(Hello[] hello, int delay) {
this.hello = hello;
this.delay = delay;
}
....
}
From the iPojo documentation on the byte code manipulation it appears to be irrelevant if I have my
fields declared final - they are bypassed at runtime anyway right? Still there seems to be potential
for danger here. The code is compiled against final fields but later on is manipulated to run
against a getter, which can return a different value every time it is called. Can this cause any
nasty surprises?
Cheers,
Todor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: iPojo: making my pojo constructor injected
Posted by clement escoffier <cl...@gmail.com>.
Hello,
2008/11/8 Richard S. Hall <he...@ungoverned.org>
>
>
> Todor Boev wrote:
>
>> Richard S. Hall wrote:
>>
>> When a thread enters the POJO, it creates a copy of any services the
>>> thread uses until the thread exits the POJO (even if the thread calls out
>>> from the POJO and re-enters it). When the thread makes a request for a
>>> service it always gets the same copy, so the thread never sees a different
>>> value.
>>>
>>> Of course, it is possible that its copy has departed and stopped working,
>>> so it may throw exceptions, but that is the nature of OSGi programming, so
>>> that is to be expected.
>>>
>>
>> Couple of more questions :)
>>
>> 1) I have wondered for some time now why did you go with this
>> thread-local-like caching?
>>
>
> It was the only way that we could think of to make synchronization
> transparent.
Exactly, the Thread local is used to hide synchronization issues. When a
thread access to a service, a copy of these services is stored inside the
thread local. Then, if the thread re-access to the same service dependency
in the same "method stream", iPOJO reinjects the same service objects.
So, it avoid the most part of synchronized blocks when accessing services as
iPOJO ensures that the same service objects are re-used. Of course, as Rick
explained, if a service departs and "invalidates" itself, accessing to the
service object can throw errors.
>
>
>
>> 2) Is the caching implemented by the "requires" handler? I have some plans
>> to implement my flavor of service tracking handler where I believe this
>> caching will not be required.
>>
>
> Not sure, Clement will have to answer that.
The caching is implemented by the Dependency Handler. However, dependency
management is made inside a helper class managing the iPOJO dependency
model. The handler just manages the injection and the caching, the dynamism
management is mostly managed in the helper class.
So, to provide a new type of service dependency, you can rely on this class
(extend it) and manage your own behavior.
Clement
>
>
> -> richard
>
>
>
>> Todor
>>
>> ---------------------------------------------------------------------
>> 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
>
>
Re: iPojo: making my pojo constructor injected
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Todor Boev wrote:
> Richard S. Hall wrote:
>
>> When a thread enters the POJO, it creates a copy of any services the
>> thread uses until the thread exits the POJO (even if the thread calls
>> out from the POJO and re-enters it). When the thread makes a request
>> for a service it always gets the same copy, so the thread never sees
>> a different value.
>>
>> Of course, it is possible that its copy has departed and stopped
>> working, so it may throw exceptions, but that is the nature of OSGi
>> programming, so that is to be expected.
>
> Couple of more questions :)
>
> 1) I have wondered for some time now why did you go with this
> thread-local-like caching?
It was the only way that we could think of to make synchronization
transparent.
>
> 2) Is the caching implemented by the "requires" handler? I have some
> plans to implement my flavor of service tracking handler where I
> believe this caching will not be required.
Not sure, Clement will have to answer that.
-> richard
>
> Todor
>
> ---------------------------------------------------------------------
> 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
Re: iPojo: making my pojo constructor injected
Posted by Todor Boev <t....@prosyst.bg>.
Richard S. Hall wrote:
> When a thread enters the POJO, it creates a copy of any services
> the thread uses until the thread exits the POJO (even if the thread
> calls out from the POJO and re-enters it). When the thread makes a
> request for a service it always gets the same copy, so the thread never
> sees a different value.
>
> Of course, it is possible that its copy has departed and stopped
> working, so it may throw exceptions, but that is the nature of OSGi
> programming, so that is to be expected.
Couple of more questions :)
1) I have wondered for some time now why did you go with this thread-local-like caching?
2) Is the caching implemented by the "requires" handler? I have some plans to implement my flavor of
service tracking handler where I believe this caching will not be required.
Todor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: iPojo: making my pojo constructor injected
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Todor,
Clement should probably be answering this question, since he knows the
details better than me, but I will answer and he can correct me if I am
wrong.
I don't believe that iPOJO ends up using the fields at all, so it
doesn't matter that they are final. As far as nasty surprises, I don't
think there will be an issue since iPOJO handles synchronization for the
POJO. When a thread enters the POJO, it creates a copy of any services
the thread uses until the thread exits the POJO (even if the thread
calls out from the POJO and re-enters it). When the thread makes a
request for a service it always gets the same copy, so the thread never
sees a different value.
Of course, it is possible that its copy has departed and stopped
working, so it may throw exceptions, but that is the nature of OSGi
programming, so that is to be expected.
-> richard
Todor Boev wrote:
> Hello,
> I managed to make my pojo appear to be constructor injected like so:
>
> @Component(name = "HelloClient", immediate = true)
> public class HelloClient {
> @Property
> private final int delay;
> @Requires
> private final Hello[] hello;
>
> private Thread thread;
> private boolean running;
>
> @SuppressWarnings("unused")
> private HelloClient() {
> this(null, 0);
> }
>
> public HelloClient(Hello[] hello, int delay) {
> this.hello = hello;
> this.delay = delay;
> }
> ....
> }
>
> From the iPojo documentation on the byte code manipulation it appears
> to be irrelevant if I have my fields declared final - they are
> bypassed at runtime anyway right? Still there seems to be potential
> for danger here. The code is compiled against final fields but later
> on is manipulated to run against a getter, which can return a
> different value every time it is called. Can this cause any nasty
> surprises?
>
> Cheers,
> Todor
>
> ---------------------------------------------------------------------
> 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