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

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.