felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Endo Alejandro <Alejandro.E...@grassvalley.com>
Subject RE: Some questions regarding iPOJO
Date Fri, 13 Feb 2015 15:54:15 GMT
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/apache-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??

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.
Mime
View raw message