[jboss-dev-forums] [JBoss Microcontainer Development] - Re: Deployers Ordering Issue Reopened

[richard.opalka@jboss.com]

This thread is related to: JBDEPLOY-201

Some facts:
---
F1) Deployer is key JBoss AS abstraction
with essential ordering feature based
on stages, inputs and outputs.

F2) It is also possible to specify relative
order for particular deployer to
workaround "by name" deployers comparison
if it doesn't fit our needs.

F3) For deployers it is really important
to be executed in correct order.

Some complains:
---
Here's the list of problems of
current deployers ordering impl:

P1) Deployer inputs are not validated at all.

Usecase:

I can have PARSING deployer that produces
some meta data and REAL deployer consuming it.
If I'd forgot to "register" PARSING deployer and
would "register" REAL deployer, there'd be no
problem reported by AS about missing deployer
producing required input (to satisfy dependency).

Reality:

Deployer developers don't specify inputs (requirements)
just for fan. Inputs are there to specify dependencies
and to ensure correct deployers ordering.

P2) Domino sorting tries to compare uncomparable deployers.

Usecase:

Deployer1(outputs="1")
Deployer2(inputs="1",outputs="2")
Deployer3(inputs="2",outputs="3")

What should be the result of Comparator.compare(Deployer1,Deployer2)?

Reality:

Currently name comparison is used for such deployer comparison
(or relative order if specified).
How current domino storing algorighm works is it creates matrix
and fills in relative order for every deployer combination.
This is broken IMHO because two deployers are not comparable
in general (without knowing inputs/outputs of other deployers).
IOW deployer inputs/outputs don't represent context less grammar.

Some suggestions:
---
If I could be you
 ad1) I would bring in shiny deployers code after rainy prototype
 ad2) I would say good bye to the past and hello to the future
 ad3) I would fix deployers ordering in AS trunk to ensure F1)

ad1) Doesn't mean your code is bad. It means you were probably out of
resources with bloody deadlines when writing it. IOW I understand the
reason of deployers code/architecture quality, but I think it's time
for review/rewrite (although it will affect BC) to ensure F1).

ad2) Means you shouldn't be aware to do things right.
Sometimes its really painful to fix some bugs, but when you postpone
bugs in critical abstrations, you're calling for serious problems
in the future.

ad3) You'd fix it in AS trunk ASAP because EAP5 is comming out soon
and you can be sure there will be many deployer developers that
will complain about this ordering issue and you'll need to fix it after all.

Conclusion:

Let's discuss this deployers ordering problem here and let's find the correct/proper solution for it. Forget about BC (especially if it's broken).
We're here to solve the problems and IMHO JBoss AS trunk is the best candidate for such fix to be incorporated in ;)

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262374#4262374

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262374