Extender Patter vs. LifecycleInterceptors

[thomas.diesler]

There is a new blogpost in the diary that discusses Extenders/Interceptors

http://jbossosgi.blogspot.com/2009/10/extender-pattern-vs-lifecycle.html

As far as integration with the MC Framework goes, you can add interceptors as part of the bootstrap config like this

 <bean name="WebXMLVerifier" class="org.jboss.osgi.framework.deployers.WebXMLVerifierInterceptor"/>

Interceptors can of course also be added dynamically via the related LifecycleInterceptorService.

In case of of the MC Framework the interceptor attachment API delegates to the DeploymentUnit, so that interceptor attachments are visible by the deployers and vice versa.

[alesj]

In case of of the MC Framework the interceptor attachment API delegates to the DeploymentUnit, so that interceptor attachments are visible by the deployers and vice versa.

So this means you have those two adapters we talked about?
* OSGi interceptors --> VDF deployers
* VDF deployers --> OSGi interceptors
And one can easily (to some extent) port/exchange the two?

[thomas.diesler]

Any MC bean can be a LifecycleInterceptor. It simply needs to implement that interface. The LifecycleInterceptorService plugin picks those up at bean install time.

 <bean name="LifecycleInterceptorService" class="org.jboss.osgi.framework.service.internal.LifecycleInterceptorServiceImpl">
 <constructor><parameter><inject bean="OSGiBundleManager" /></parameter></constructor>

In any case (MCBean or registered programatically), the attachment handling is delegated to the DeploymentUnit.
 <incallback method="addInterceptor" />
 <uncallback method="removeInterceptor" />
 </bean>

[alesj]

Any MC bean can be a LifecycleInterceptor. It simply needs to implement that interface.

Sure.
But do you already provide both adapters?

[thomas.diesler]

Could you pls elaborate on the use case for the adaptors? (i.e. what benefit would these adaptors bring)

[alesj]

Could you pls elaborate on the use case for the adaptors?

Deployer deployer = ...;
LifecycleInterceptor interceptor = new DeployerToLifecycleInterceptorAdaptor(deployer);

LifecycleInterceptor interceptor = ...;
Deployer deployer = new LifecycleInterceptorToDeployerAdaptor(interceptor);

(i.e. what benefit would these adaptors bring)

Re-use of code. ;-)

I already have a feeling you're re-inventing things a bit too much with this LI farmework,
where you should actually just have this and other adaptors in the first place.
But I trust your judgment, nevertheless adaptors should exist, in order to prove both concepts, LI and VDF, right.

[thomas.diesler]

Re-use of code. ;-)

What code would actually be reused by adding these adaptors?

Perhaps you think an interceptor *is* a deployer and the invocation and ordering should be done by the deployer framework.

This is something I'm not so sure about. considering how the deployers are being invoked on the various bundle state changes. Also, how would that work in Felix and other frameworks when it becomes standard.

I'd still like to see a use case or actual code that could be reused by the adaptors that yo have in mind.

[alesj]

What code would actually be reused by adding these adaptors?

Any existing Deployer or LI. Vice-versa.

Perhaps you think an interceptor *is* a deployer and the invocation and ordering should be done by the deployer framework.

No, I don't think that.
I just wanna re-use the Deployer/LI logic I once wrote.

e.g. I don't wanna copy/paste some huge/large Deployer I once wrote,
which has zero custom logic and could easily be reused in LI.

This is something I'm not so sure about. considering how the deployers are being invoked on the various bundle state changes.

What's so different?
Our VDF has, imho, similar linear lifecycle/state system,
so mapping existing DeploymentStages against OSGi lifecycle integers shouldn't be a problem.
Or even if it is, you simply report that: "Cannot adapt Deployer to LI, illegal deployment stage".

Also, how would that work in Felix and other frameworks when it becomes standard.

For any non-MC_OSGi_facade I don't care.
This is impl detail of MC's VDF.

I would go even further, and simply provide spi/api for this LI framework,
where most of the work would again just delegate to our VDF via some facade/adaptors.

I'd still like to see a use case or actual code that could be reused by the adaptors that yo have in mind.

Take any existing Deployer that works just on top of plain resources and attachments.

e.g. grab something out from attachments, add custom logic, and put it back in

[thomas.diesler]

I just wanna re-use the Deployer/LI logic I once wrote.

Ok, that is a good enough use case

https://jira.jboss.org/jira/browse/JBOSGI-195
https://jira.jboss.org/jira/browse/JBOSGI-196