October 2009 - jboss-osgi-dev - Jboss List Archives

[JBoss OSGi Development] - Re: Extender Patter vs. LifecycleInterceptors

by thomas.diesler＠jboss.com

anonymous wrote : | 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 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262852#4262852 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262852

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Extender Patter vs. LifecycleInterceptors

by alesj

"thomas.diesler(a)jboss.com" wrote : | What code would actually be reused by adding these adaptors? | Any existing Deployer or LI. Vice-versa. "thomas.diesler(a)jboss.com" wrote : | 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. "thomas.diesler(a)jboss.com" wrote : | 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". "thomas.diesler(a)jboss.com" wrote : | 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. "thomas.diesler(a)jboss.com" wrote : | 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 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262751#4262751 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262751

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Extender Patter vs. LifecycleInterceptors

by thomas.diesler＠jboss.com

anonymous wrote : | 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. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262623#4262623 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262623

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Extender Patter vs. LifecycleInterceptors

by alesj

"thomas.diesler(a)jboss.com" wrote : 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); "thomas.diesler(a)jboss.com" wrote : (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. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262610#4262610 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262610

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Extender Patter vs. LifecycleInterceptors

by thomas.diesler＠jboss.com

Could you pls elaborate on the use case for the adaptors? (i.e. what benefit would these adaptors bring) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262608#4262608 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262608

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Extender Patter vs. LifecycleInterceptors

by alesj

"thomas.diesler(a)jboss.com" wrote : Any MC bean can be a LifecycleInterceptor. It simply needs to implement that interface. | Sure. But do you already provide both adapters? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262600#4262600 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262600

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Extender Patter vs. LifecycleInterceptors

by thomas.diesler＠jboss.com

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> | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262591#4262591 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262591

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Extender Patter vs. LifecycleInterceptors

by alesj

"thomas.diesler(a)jboss.com" wrote : | 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? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262396#4262396 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262396

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Extender Patter vs. LifecycleInterceptors

by thomas.diesler＠jboss.com

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. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262341#4262341 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262341

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Change in manifest parser breaks symbolic name

by thomas.diesler＠jboss.com

Folks (Adrian), do we have an update on this? It is scheduled for Beta5 01-Dec-2009 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262328#4262328 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262328

14 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

jboss-osgi-dev October 2009