[jboss-as7-dev] Deployment Chain/Service interaction

[Scott Stark]

I think the introduction of a proper service per deployment phase is a 
good idea.

Can the DPU phase notion be more typed than currently in the jboss-as 
trunk so that the DPU phase is self describing?

I had the same question as Brian regarding module annotations resulting 
in additional dependencies. I'm not following the answer, so to clarify 
how a deployment would happen, consider:

ejb1.jar: exports Bean1 interface, imports Bean2 interface
@Stateless public class Bean1Impl implements Bean1 {
+ @EJB Bean2 bean2;

ejb2.jar : exports Bean2 interface, imports Bean2 interface
@Stateless public class Bean2Impl implements Bean2 {
+ @EJB Bean1 bean1;

First of all, how are implicit module dependencies like these identified?
j.d.ejb1.jar.modularize -> depends on exporter of Bean2
j.d.ejb2.jar.modularize -> depends on exporter of Bean1

Does the ejb1.jar module metadata have to express the import of Bean2, 
and likewise ejb2.jar the import of Bean1?

Assuming yes, and classpaths between ejb1.jar and ejb2.jar include each 
others exported classes after "modularize", what is the rest of the 
deployment path for ejb1.jar and ejb2.jar through the install phase?



On 12/2/10 12:55 PM, David M. Lloyd wrote:
> On 12/02/2010 02:50 PM, Brian Stansberry wrote:
>>> 3. Phase: "parse" ->    "jboss.deployment.\"myapp-foo.war\".parse"
>>>
>>> In this phase, all descriptors which are available via the file system
>>> are processed.  This includes XML descriptors, manifest information,
>>> etc.  When processing of this phase is complete, all descriptors should
>>> be parsed and stored in the DUP context.
>>>
>>> 4. Phase "dependencies" ->    "jboss.deployment.\"myapp-foo.war\".dependencies"
>>>
>>> In this phase, the data collected is used to assemble the list of
>>> dependencies and class path resource roots.
>> I assume what you mean here are module dependencies, not service
>> dependencies.
> Yes.  Well, it ends up being both: there's a service dependency from
> j.d.source.modularize ->  j.d.dependency.structure.  This dependency is
> used to create the module dependency (which is really a resource root
> dependency as opposed to a module->module dependency).
>
>>> Class-path dependencies on
>>> other deployments will be added to this deployment's "modularize" phase
>>> as MSC dependencies on the dependency deployments' "structure" phase.
>>> When processing of this phase is complete, all the information necessary
>>> to construct the module for this deployment is available.
>>>
>> Can annotations, which aren't read until the "modularize" phase, result
>> in module dependencies?
> No.  See the section in "Missing Stuff" (#3) about this.  Since you
> can't read annotations until you have classloading, if you need to make
> additional classloading changes, it has to happen in a second phase
> where dependencies are recalculated, and the processor has to be aware
> of that fact; in addition the proper module dependencies (and thus the
> corresponding MSC dependencies) have to be established between the
> deployments.
>