[
https://jira.jboss.org/jira/browse/JBOSGI-183?page=com.atlassian.jira.plu...
]
Thomas Diesler updated JBOSGI-183:
----------------------------------
Description:
In the context of Multiple Extenders I'd like to see some coverage about when the
extender pattern is applicable and when 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 solve 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:
In the context of Multiple Extenders I'd like to see some coverage about when the
extender pattern is applicable and when 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.
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
In the context of Multiple Extenders I'd like to see some coverage about when the
extender pattern is applicable and when 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 solve 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