[jboss-osgi-issues] [JBoss JIRA] Updated: (JBOSGI-183) Initial implementation of OSGi Deployers

[Thomas Diesler (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBOSGI-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler updated JBOSGI-183:
----------------------------------

        Summary: Initial implementation of OSGi Deployers  (was: Initail implementation of OSGi Deployers)
    Description: 
I would like to see some coverage about where the extender pattern is applicable and where not. As far as I understand the extender pattern works like this.

#1 bundle gets installed/started
#2 framework fires event
#3 extender picks up event (e.g. STARTING) either synchronously or asynchronously
#4 extender reads metadata from bundle and does its "additional" work based on it

This approach has consequences in practice that from the user perspective might be unexpected/undesirable.

For example most blueprint/webapp bundles are meaningless if the their blueprint/web metadata is not processed. Even if they are processed but in the "wrong" order a user might see unexpected results (i.e. the webapp processes the first request before the underlying BP app is wired together). The current usage of the extender pattern allows a bundle to install/start seemingly correctly even if the extender is not present of fails for some reason. I realize that some of this is addressed in E0005.

My main point is that the extender pattern is useful in some cases but not all. IMHO it is mainly useful if a bundle can optionally be extended in the true sense of the word.

If the use case requires the notion of "interceptor" the extender pattern is less useful. For example I might want to intercept the bundle lifecycle at various phases (i.e. BEFORE_INSTALLED, AFTER_INSTALLED, etc.) to do mandatory metadata processing. An interceptor can be used for annotation processing, byte code weaving, and other non-optional/optional metadata processing. Traditionally, among other properties interceptors have an order, can communicate with each other and veto progress in the lifecycle.

In the example above, both the BP and the web metadata would IMHO be candidates for interceptor processing rather than extender processing. From a user's perspective I would like to be sure that when a BP+WebApp bundle fires the STARTED event, it can really start processing the first Http request and their are no hidden gotchas to it.

In RFP-118 we should be careful about specifying requirements for the "multiple extenders" problem only and not try to sole problems that would more adequately be dealt with by an (yet unspecified) interceptor pattern.

This topic has already come up during our meeting in Dublin, and AFAIR Hall and I agreed to work on the notion of deployer/interceptor.


  was:The deployers are currently spread over several modules, please consolidate.



> Initial implementation of OSGi Deployers
> ----------------------------------------
>
>                 Key: JBOSGI-183
>                 URL: https://jira.jboss.org/jira/browse/JBOSGI-183
>             Project: JBoss OSGi
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Core Framework
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For:  JBossOSGi 1.0.0 Beta5
>
>
> I would like to see some coverage about where the extender pattern is applicable and where not. As far as I understand the extender pattern works like this.
> #1 bundle gets installed/started
> #2 framework fires event
> #3 extender picks up event (e.g. STARTING) either synchronously or asynchronously
> #4 extender reads metadata from bundle and does its "additional" work based on it
> This approach has consequences in practice that from the user perspective might be unexpected/undesirable.
> For example most blueprint/webapp bundles are meaningless if the their blueprint/web metadata is not processed. Even if they are processed but in the "wrong" order a user might see unexpected results (i.e. the webapp processes the first request before the underlying BP app is wired together). The current usage of the extender pattern allows a bundle to install/start seemingly correctly even if the extender is not present of fails for some reason. I realize that some of this is addressed in E0005.
> My main point is that the extender pattern is useful in some cases but not all. IMHO it is mainly useful if a bundle can optionally be extended in the true sense of the word.
> If the use case requires the notion of "interceptor" the extender pattern is less useful. For example I might want to intercept the bundle lifecycle at various phases (i.e. BEFORE_INSTALLED, AFTER_INSTALLED, etc.) to do mandatory metadata processing. An interceptor can be used for annotation processing, byte code weaving, and other non-optional/optional metadata processing. Traditionally, among other properties interceptors have an order, can communicate with each other and veto progress in the lifecycle.
> In the example above, both the BP and the web metadata would IMHO be candidates for interceptor processing rather than extender processing. From a user's perspective I would like to be sure that when a BP+WebApp bundle fires the STARTED event, it can really start processing the first Http request and their are no hidden gotchas to it.
> In RFP-118 we should be careful about specifying requirements for the "multiple extenders" problem only and not try to sole problems that would more adequately be dealt with by an (yet unspecified) interceptor pattern.
> This topic has already come up during our meeting in Dublin, and AFAIR Hall and I agreed to work on the notion of deployer/interceptor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira