Precedence level

[bill.burke]

I'm looking at the Seam component model to see how it could be merged with MC. Here's an interesting feature they got.

When you deploy a component, it can have both dependencies as well as a precedence level. Basically the precedence level is a numerical value of where in the chain the component should be deployed. Gavin uses this so that somebody could say: "I want this component deployed after all Seam BUILT IN components".

Maybe we could translate this into logical groupings of beans:

<bean name="Foo" group="BUILT IN" .../>
<bean name="Bar" group="BUILT IN" .../>


<bean name="MyStuff">
 <depends-group>BUILT IN</depends-group>
</bean>

"MyStuff" would have a logical dependency to Foo and Bar through the "BUILT IN" tag.

[adrian.brock]

The problem with this is that it works fine for Seam or Spring where you
are only dealing with a single application with a fixed set of deployments.

The MC has to deal with hotdeployment where beans can be added at anytime.

e.g. suppose we define a jboss-jca group so you can depend upon
all of jca being deployed, but then you add a new rar to the jboss-jca group?

[starksm64]

A dependency + an order is just introduces an implicit dependency on the components in the dependency tree with a lower order. The problem is defining the dependency tree as Adrian points out. We would need some alternate dependency scope notion that could be restricted to the current top-level deployment, as an example.

[bill.burke]

e.g. suppose we define a jboss-jca group so you can depend upon
all of jca being deployed, but then you add a new rar to the jboss-jca group?

I see your point. The aliased dependent components would not be allowed to start until a complete scan was complete. So, you couldn't resolve dependencies until every single deployment in the system had been at least described.

[adrian.brock]

So, you couldn't resolve dependencies until every single deployment in the system had been at least described.

Which is something that could only be defined with reference to something
like the profile service.

[pmuir]

When you deploy a component, it can have both dependencies as well as a precedence level. Basically the precedence level is a numerical value of where in the chain the component should be deployed. Gavin uses this so that somebody could say: "I want this component deployed after all Seam BUILT IN components".

Just to clarify, precedence is actually used to say "I want this component used INSTEAD OF this other component (with the same name)". So if I had a built-in-to-seam component foo (precedence 0) and a component I had developed also called foo, but with precedence 40, my component would get used instead of the built in one (both by Seam and by my app).

[starksm64]

That is an mc supplies notion with duplicate resolution based on the precedence number. It still leaves the problem of knowing what the universe of suppliers is. I suppose if seam components are deployed at the application phase in terms of the profile service notions of bootstrap, deployers, application phases, the phase deployer processing defines the supplier universe.