"alesj" wrote : We've been down this road before, only to find out you had one valid argument. | And that was implemented as part of domino ordering. | | Wrt P1), we've already discussed that, and my decision still stands. | Doing across stages checks is nothing more to me than supporting | someone else's laziness by not taking the time to do proper check or testing before. | We (i.e. JBossWS) don't need cross deployers stages to be taken into account. I've been just wondering universal solution that would work for all the usecases. IOW I've been thinking about your code trying to help you to make it generic and covering not just trivial usecases. "alesj" wrote : | As for P2) why would you even need to compare two deployers? | CompareTo code really comes in use when you as a user | actually get a hold of two instances and try to compare them. | Users/devs should never have to explicitly compare two deployers. | Just FYI we don't compare deployers. It's deployers impl job. The above compareTo was just an abstraction of your DominoOrdering.init() method (the abstration you're executing in every cycle). Again I was talking about your code ;) "alesj" wrote : | Wrt "suggestions". You came up with a clear case of cycle dependency, proposed some fuzzy logic solution, | put "bugs" label on existing code and you now expect us to drop everything to support your claims? | Why is our usecase so special? We're expecting/providing e.g. JBossWebMetadata in both inputs/outputs because we're reading web MD and modifying MD. There's nothing wrong with it. It's exactly deployer inputs/outputs are intended for, don't they? "alesj" wrote : | The reality is that apart from you we haven't had any deployers ordering issues. | And? Does it mean deployers ordering is correct? This is strange implication:( "alesj" wrote : | I do give you credit for previous example and suggestion for a fix, | but in this case, not only you're repeating yourself, I think you're just plain wrong. | Thanks for the credits. We've been using the workaroud suggestion already for months. We know about relative order workaround and we don't like it. We'd rather to see it fixed in deployers impl code where it should be fixed. Why we should do workarounds in our code if we're regularly using deployers and doing nothing special with them? If you don't wanna fix this issue, just mark JBDEPLOY-201 as WON'T FIX and I won't waste my free time trying to help you. For me deployers are "key abstraction" of AS and the fact is its input/output based ordering doesn't work for non trivial usecases. PS: If you can live with it then you're lucky man. My problem is I'm perfectionist and thus I don't like partial solutions :( View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262411#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...