Hi,
2015-02-13 16:18 GMT+01:00 Johan Ström <[email protected]>:
> 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.
>
We have an initial implementation design. Hopefully it will be implemented
soon. Actually, it will just be a 1.13 or 1.14 version.
>
> 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?
>
Unfortunately no. This is why supporting inheritance is the major task on
the iPOJO roadmap.
>
>
> 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.
>
It depends how many (re-) configuration you have. Normally, the updated
called is called before validate to inject the configuration. If the
callback is called after the validate callback it's because you have a
reconfiguration. If it's not the case, it's a bug.
>
> 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.
>
The Instance strategy create one implementation class object per requesting
instance. So you need the @Instantiate creating the component instance. If
you don't have validate callbacks and not mark the component as immediate,
the instance won't create an object. The object will only be created when
the service will be used, and one different object will be create per
requesting instance.
If you want to create a component instance per requesting instance, you can
implement your own creation strategy and rely on the iPOJO Factory service.
>
> 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?
>
Property are propagated by default. That means that all valued properties
are exposed as system property. Did you try:
@Property(name="port", value="1234")
int listPort;
Cheers,
Clement
>
>
>
>
> Thanks for your efforts on iPojo (and all other Felix projects), and for
> replies to these lengthy questions :)
>
> Regards
> Johan
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
