felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Ström <jo...@stromnet.se>
Subject Re: Some questions regarding iPOJO
Date Wed, 18 Feb 2015 09:00:53 GMT
Okay, too bad.

For the moment I've have let go of iPojo, it didn't really fit what I'd
like to do. Instead I'm going with bnd's DS annotations (which I've used
before).

In my case, the main reason is that BND supports the inherited behavior
I was looking at in my first question. I also have better possibilities
for nested configuration using BND's @Meta.OCD/AD annotations, more
specificially I can "parse" a third-party configuration in Activate and
actually throw an exception telling DS that it failed to activate. In
iPOJO any exceptions are ignored, it seems.
I don't use standalone services for the reused functionality, but rather
just instantiate classes manually. It isn't as decoupled as OSGI/iPojo
would allow, but that is not something I need in this case. It allows me
to reuse classes and config-parsing classes and actually have bad config
fail to activate though, and that is more important right now.


A note on my previous property propagation question; I've missunderstod
totally, it only has to do with propagating properties from the config
file to the OSGI service registration, which I found after re-reading
the docs.. :)


All in all, I'm looking forward to using iPojo for future projects, but
for the moment I cannot spend more time to "making it work" for my
purposes, when BND DS annotations works good enough for me.

Regards
Johan

On 16/02/15 16:26, Endo Alejandro wrote:
> Well, not really sadly. I think the good solution was, as Clement mentioned in his last
email of that thread, to create my own creation policy. This is something that I might try
at some point in the future since I find the current instantiation mechanism cumbersome. Unless
you use @Instantiate, that works like a charm.
>
> -----Original Message-----
> From: Johan Ström [mailto:johan@stromnet.se] 
> Sent: Saturday, February 14, 2015 10:22 AM
> To: users@felix.apache.org
> Subject: Re: Some questions regarding iPOJO
>
> Hi,
>
> that seems similar, yes. Did you find any good solution?
>
> Johan
>
> On 2/13/15 19:46 , Endo Alejandro wrote:
>> Johan, it seems that your point is then related to what I asked a 
>> couple of months ago
>>
>> https://www.mail-archive.com/users%40felix.apache.org/msg15540.html
>> Check the whole thread, it might be of use to you
>>
>> -----Original Message-----
>> From: Johan Ström [mailto:johan@stromnet.se]
>> Sent: Friday, February 13, 2015 11:13 AM
>> To: users@felix.apache.org
>> Subject: Re: Some questions regarding iPOJO
>>
>> On 13/02/15 16:54, Endo Alejandro wrote:
>>> I am no iPojo expert so I might be raising more questions than I'm 
>>> answering
>>>
>>> You said
>>>> I've been playing with Provides/Requires, and Provides strategy 
>>>> "instance". As long as I have @Instantiate on my service impl, it 
>>>> will create one instance at startup, and then one new for every 
>>>> iPOJO object which requests the service, as expected. However, I'd 
>>>> like to avoid creating that extra instance on startup, but without 
>>>> @Instantiate, the component does not become available at all and my 
>>>> depending components will stay invalid
>>> I don’t think that's how instantiation works or, at least to me, you 
>>> seem to be mixing two different concepts. If you don't want that 
>>> initial instance then you need to just remove @Instantiate. Then, as 
>>> you say, the component does not become available, that's expected.
>>> Then you have to instantiate the component using one of the 
>>> techniques discussed here 
>>> http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/
>>> a pache-felix-ipojo-userguide/apache-felix-ipojo-instances.html
>>> You see the first one is @Instantiate, which doesn't work for you 
>>> since you don't want a single instance Just use one of the other 
>>> techniques, they are more imperative/less declarative than 
>>> @Instantiate
>>>
>>> My question/surprise is that I didn't know you could use @Instantiate with strategy
"instance". I always saw @Instantiate more for singleton services. Is that incorrect??
>>  From what I've understood from the docs, @Instantiate would be for singletons only.
So, no it doesn't make much sense to use it here. I was just experimenting with it, and for
some reason it triggers *almost* the behavior I was trying to get (i.e. create new instances
for each dependent instance).
>>
>> I suppose/hope there is a "correct"  way to get that working, the question is how?
:) I've done some more experimentation, and I can manage to create my instances dynamically,
with my own properties, using the Factory.createComponentInstance pattern.. But that seems
pretty messy to me. Especially when it at least seems to work like above (although not with
properties, hence my questions regarding propagation).
>>
>> Johan
>>
>>> Alejandro
>>>
>>> -----Original Message-----
>>> From: Johan Ström [mailto:johan@stromnet.se]
>>> Sent: Friday, February 13, 2015 10:19 AM
>>> To: users@felix.apache.org
>>> Subject: Some questions regarding iPOJO
>>>
>>> Hi,
>>>
>>> I'm a new user in iPOJO land. Having used declarative services before, I must
say its quite nice!
>>>
>>> I have a few questions which I have not been able to find any answers to:
>>>
>>> a) What's the status on iPOJO 2.0? Last message I can find was from 2013.
>>> My main interest for 2.0 is the support for inherited annotations, which brings
me to my second question.
>>>
>>> b) Since annotation inheritance is not possible in iPOJO 1.x, I cannot have a
"base class" with @Updated, @Validated etc.
>>> Are there any good design patterns which allows me do have as simple implementation
classes as possible?
>>>
>>> What I'm after is something like this:
>>>
>>> @Component(managedservice = "my.pid", immediate = true) public class 
>>> MyComponent extends MyBaseComponent {
>>>
>>>      @Override
>>>      protected void addResources(...) {
>>>          ....
>>>      }
>>> }
>>>
>>> public abstract class MyBaseComponent {
>>>      @Validate
>>>      public void validate() {
>>>          // start up some magic server and configure it with default stuff, lots
of code which I dont want to repeat
>>>          // in every "real" component
>>>          addResources(...);
>>>          // done!
>>>      }
>>>      @Invalidate
>>>      public void invalidate() {
>>>          // teardown...
>>>      }
>>> }
>>>
>>>
>>> The base component does lots of stuff which is shared among components, triggered
on @Validate/@Invalidate.
>>> The subclass (which there will be several implementations of) just does the specifics
for that particular component, but since it inherits form the base class it will automatically
get calls to validate etc.
>>>
>>> I realize this is not possible today due to the use of compile-time-only annotations
et all, and if the base component would be in compiled form, the manipulator has no way of
seeing those annotations.
>>> I could just implement the methods in every class and call
>>> super.<method>() but if possible, I'd like to avoid that.
>>>
>>> Any suggestions?
>>>
>>>
>>> c) Concerning the component instance lifecycle, more specifically the call order
of Validate/Invalidate/Updated.
>>> On startup, it seems Updated is called, then Validate, then Updated again (but
not in all cases? Think I saw other order once..).
>>> I see two approaches:
>>>
>>> 1) Ignore first Updated if validate has not yet been called. Start my stuff in
Validate. Reconfigure my stuff in Updated. Downside is that i reconfigure it once directly
after startup, which I'd like to avoid.
>>> 2) Ignore Updated unless Validate has been called. In Validate, just mark "valid".
In following Updated, reconfigure/startup as necessary.
>>>
>>> Version 2 is what I'll go for I guess, but I wonder, is there any way to detect
if my component is valid or invalid, besides implementing Validate/Invalidate which would
just update a boolean?
>>>
>>> d) Final question: I'm trying to wrap my head around services and property propagation..
>>> I've been playing with Provides/Requires, and Provides strategy "instance". As
long as I have @Instantiate on my service impl, it will create one instance at startup, and
then one new for every iPOJO object which requests the service, as expected. However, I'd
like to avoid creating that extra instance on startup, but without @Instantiate, the component
does not become available at all and my depending components will stay invalid.
>>>
>>> When it comes to property propagation, I cannot really find any examples which
makes us of this or any description on how this actually is supposed to work. My made up idea
of how it could work is something like this:
>>>
>>> Service component ZServerImpl provides ZServer interface, with strategy=instance.
It requires property "listenPort" to start.
>>> Component Y, which Requires an ZServer instance.
>>> Y is instantiated via config admin, and the config has property "listenPort =
1234".
>>> When ZServer var is accessed (or when Y is instantiated), the property "listenport"
is propagated down to XServerImpl when it is instantiated solely for my Y instance.
>>>
>>> Basically, a way to reuse the ZServerImpl service, separately instantiated for
each user, with params inherited from each config.
>>>
>>> Is this at all how property propagation is supposed to work? If not, any other
patterns to archieve this?
>>>
>>>
>>>
>>>
>>> Thanks for your efforts on iPojo (and all other Felix projects), and 
>>> for replies to these lengthy questions :)
>>>
>>> Regards
>>> Johan
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>> DISCLAIMER:
>>> Privileged and/or Confidential information may be contained in this 
>>> message. If you are not the addressee of this message, you may not 
>>> copy, use or deliver this message to anyone. In such event, you 
>>> should destroy the message and kindly notify the sender by reply 
>>> e-mail. It is understood that opinions or conclusions that do not 
>>> relate to the official business of the company are neither given nor 
>>> endorsed by the company.
>>> Thank You.
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>> DISCLAIMER:
>> Privileged and/or Confidential information may be contained in this 
>> message. If you are not the addressee of this message, you may not 
>> copy, use or deliver this message to anyone. In such event, you should 
>> destroy the message and kindly notify the sender by reply e-mail. It 
>> is understood that opinions or conclusions that do not relate to the 
>> official business of the company are neither given nor endorsed by the 
>> company.
>> Thank You.
>>
>> ---------------------------------------------------------------------
>> 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
>
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message