Re: [jboss-as7-dev] Deployment Chain/Service interaction
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.