You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Steven E. Harris" <se...@panix.com> on 2007/03/01 22:21:34 UTC
iPOJO lifecycle callbacks -- getting a "context" in hand
The Declarative Services lifecycle callbacks "activate()" and
"deactivate()" provide the managed component access to a
ComponentContext, from which one can retrieve a BundleContext, as well
as read the properties attached to that component instance.
I see that iPOJO offers INVALID-to-VALID state transition callback,
but its signature as described in the tutorial is a no-argument
function, providing no context information to the bundle.
Is there some other means to receive or retrieve a context analogous
to the DS component context? Or is this a matter of defining a member
variable in my component of type BundleContext, expecting it to be
assigned/injected by iPOJO when appropriate?
--
Steven E. Harris
Re: iPOJO callback access level modifiers
Posted by "Steven E. Harris" <se...@panix.com>.
Clement Escoffier <cl...@gmail.com> writes:
> The patch is attached. It will allows the use of protected and
> private callbacks both for lifecycle callbacks and dependency
> callbacks.
Thanks. I'll give it a try.
--
Steven E. Harris
Re: iPOJO callback access level modifiers
Posted by Clement Escoffier <cl...@gmail.com>.
Hello,
I open the " bugs " (improvement) :
https://issues.apache.org/jira/browse/FELIX-220
The patch is attached. It will allows the use of protected and private
callbacks both for lifecycle callbacks and dependency callbacks.
Clement
Steven E. Harris a écrit :
> Clement Escoffier <cl...@gmail.com> writes:
>
>
>> It is a bug. I will write a Jira Issue.
>>
>
> You're too cruel. It's a desired feature.
>
>
>> I should be fixed in the next commit (monday). Thank you for the
>> feedback.
>>
>
> Thank you for your prompt work. There's no rush.
>
>
--
Clement Escoffier
Grenoble University
LSR - Bat. C
220, Rue de la Chimie
BP 53
38041 GRENOBLE CEDEX 9
04.76.51.40.24
http://clement.plop-plop.net
Re: iPOJO callback access level modifiers
Posted by "Steven E. Harris" <se...@panix.com>.
Clement Escoffier <cl...@gmail.com> writes:
> It is a bug. I will write a Jira Issue.
You're too cruel. It's a desired feature.
> I should be fixed in the next commit (monday). Thank you for the
> feedback.
Thank you for your prompt work. There's no rush.
--
Steven E. Harris
Re: iPOJO callback access level modifiers
Posted by Clement Escoffier <cl...@gmail.com>.
Steven E. Harris a écrit :
> In DS, the lifecycle callbacks tolerate the methods being declared as
> "protected" access, but I noticed that iPOJO requires these methods to
> be public. Would it be technically feasible for iPOJO to permit
> declaration of non-public callback methods?
>
> I guess this would require use of Class.getDeclaredMethod() rather
> than just Class.getMethod() in org.apache.felix.ipojo.util.Callback,
> the latter of which appears to only search for public methods.
>
>
It is a bug. I will write a Jira Issue. I should be fixed in the next
commit (monday). Thank you for the feedback.
Clement
--
Clement Escoffier
Grenoble University
LSR - Bat. C
220, Rue de la Chimie
BP 53
38041 GRENOBLE CEDEX 9
04.76.51.40.24
http://clement.plop-plop.net
iPOJO callback access level modifiers (was: iPOJO lifecycle callbacks -- getting a "context" in hand)
Posted by "Steven E. Harris" <se...@panix.com>.
In DS, the lifecycle callbacks tolerate the methods being declared as
"protected" access, but I noticed that iPOJO requires these methods to
be public. Would it be technically feasible for iPOJO to permit
declaration of non-public callback methods?
I guess this would require use of Class.getDeclaredMethod() rather
than just Class.getMethod() in org.apache.felix.ipojo.util.Callback,
the latter of which appears to only search for public methods.
--
Steven E. Harris
Re: iPOJO lifecycle callbacks -- getting a "context" in hand
Posted by Clement Escoffier <cl...@gmail.com>.
Steven E. Harris a écrit :
> Clement Escoffier <cl...@gmail.com> writes:
>
>
>> Lifecycle callbacks can be without any argument or with the bundle
>> context.
>>
>
> Are you saying that the INVALID->VALID callback can take a
> BundleContext argument? When looking at the code for
> LifecycleCallback.call(), it looks like it will only call a
> no-argument method.
>
> This isn't such a big issue, as the constructor is really a better
> place to receive the BundleContext, but I want to make sure I'm
> understanding you correctly here.
>
>
You're right. I remove (long time ago) this "feature" to force to get
the bundle context in the constructor. However, DS supports it, so
perhaps I need to re-allow this feature.
Clement
PS : You know iPOJO better than me ;-)
--
Clement Escoffier
Grenoble University
LSR - Bat. C
220, Rue de la Chimie
BP 53
38041 GRENOBLE CEDEX 9
04.76.51.40.24
http://clement.plop-plop.net
Re: iPOJO lifecycle callbacks -- getting a "context" in hand
Posted by "Steven E. Harris" <se...@panix.com>.
Clement Escoffier <cl...@gmail.com> writes:
> Lifecycle callbacks can be without any argument or with the bundle
> context.
Are you saying that the INVALID->VALID callback can take a
BundleContext argument? When looking at the code for
LifecycleCallback.call(), it looks like it will only call a
no-argument method.
This isn't such a big issue, as the constructor is really a better
place to receive the BundleContext, but I want to make sure I'm
understanding you correctly here.
--
Steven E. Harris
Re: iPOJO lifecycle callbacks -- getting a "context" in hand
Posted by Clement Escoffier <cl...@gmail.com>.
Steven E. Harris a écrit :
> "Steven E. Harris" <se...@panix.com> writes:
>
>
>> Is there some other means to receive or retrieve a context analogous
>> to the DS component context? Or is this a matter of defining a member
>> variable in my component of type BundleContext, expecting it to be
>> assigned/injected by iPOJO when appropriate?
>>
>
> After some digging, I see there's a way. The class
> org.apache.felix.ipojo.InstanceManager's createPojoObject() method
> detects the presence of a constructor with a single BundleContext
> argument, around line 355, and calls that if available.
>
>
Exactly, Lifecycle callbacks can be without any argument or with the
bundle context. To avoid component model dependency, iPOJO does not
provides an iPOJO Component Context, but inject a Bundle Context.
Clement
--
Clement Escoffier
Grenoble University
LSR - Bat. C
220, Rue de la Chimie
BP 53
38041 GRENOBLE CEDEX 9
04.76.51.40.24
http://clement.plop-plop.net
Re: iPOJO lifecycle callbacks -- getting a "context" in hand
Posted by "Steven E. Harris" <se...@panix.com>.
"Steven E. Harris" <se...@panix.com> writes:
> Is there some other means to receive or retrieve a context analogous
> to the DS component context? Or is this a matter of defining a member
> variable in my component of type BundleContext, expecting it to be
> assigned/injected by iPOJO when appropriate?
After some digging, I see there's a way. The class
org.apache.felix.ipojo.InstanceManager's createPojoObject() method
detects the presence of a constructor with a single BundleContext
argument, around line 355, and calls that if available.
--
Steven E. Harris