October 2009 - jboss-dev-forums - Jboss List Archives

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

by alesj

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. 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 compare two deployers. Wtr "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? The reality is that apart from you we haven't had any deployers ordering issues. 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. If something is a clear example of a cycle, perhaps you can somehow "avoid" it per example use case, but I doubt there is any nice non-complex aka human readable algorithm to solve it. And that's what it matters at the end - users should be able to order deployers with simple paper drawing. In my mind this definitely excludes your fuzzy/custom logic, otherwise we would have to have a RichardO book of custum rules to follow. ;-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262386#4262386 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262386

16 years, 1 month

1
0
0 / 0

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

by richard.opalka＠jboss.com

"richard.opalka(a)jboss.com" wrote : | Q1) Is Domino Sorting algorithm a good choice? | IMHO no "richard.opalka(a)jboss.com" wrote : | Q2) Does it cover all sorting usecases? | IMHO no "richard.opalka(a)jboss.com" wrote : | Q3) Shouldn't we incorporate stages into account when comparing deployers? | IMHO yes "richard.opalka(a)jboss.com" wrote : | Q4) Shoudn't we validate deployer inputs? | IMHO yes What do you Ales think? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262384#4262384 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262384

16 years, 1 month

1
0
0 / 0

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

by richard.opalka＠jboss.com

So the questions I'd like to discuss here are: Q1) Is Domino Sorting algorithm a good choice? Q2) Does it cover all sorting usecases? Q3) Shouldn't we incorporate stages into account when comparing deployers? Q4) Shoudn't we validate deployer inputs? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262382#4262382 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262382

16 years, 1 month

1
0
0 / 0

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

by richard.opalka＠jboss.com

"alesj" wrote : | I don't think we're here to solve every possible ordering issue, | mostly just the most natural/simple one's. | Hence sometimes adding some order number / changing name is still a valid option. | Yes, we're here to solve the problems especially for "key JBoss AS abstractions" like deployers ;) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262377#4262377 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262377

16 years, 1 month

1
0
0 / 0

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

by 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

16 years, 1 month

1
0
0 / 0

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

by alesj

Initial arguments on how to "order" cyclic configuration. "richard.opalka(a)jboss.com" wrote : | I consider it wrong because: | | WSTypeDeployer sets output 7 | WSDeploymentDeployer expects input 7 and sets output 8 (thus WSDeploymentDeployer follows WSTypeDeployer) | Finally WSDeploymentAspectDeployer expects input 8 (and thus it follows WSDeploymentDeployer and shouldn't be name compared with WSTypeDeployer because of 8 input expectation) | Just ignore 6 (in both inputs and outputs as they are not important | in this case, because they're specified on both input and output) | | Richard | | PS: Maybe I'm missing something? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262371#4262371 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262371

16 years, 2 months

1
0
0 / 0

[JBoss Microcontainer Development] - Deployers Ordering Issue Reopened

by richard.opalka＠jboss.com

Opening discussion to public AlesJ wrote: Hmmm ... I think the pattern is too simplistic. Or too non-deterministic. The problem is that once we fill in initial relations, we check for transitions, but details like "ignore 6 as it's input/output for all" are too specific. Previous use case we had was more deterministic, this one isn't. Or at least I don't see it as such. e.g. We should then take the cycle, try to remove all dots that are in all deployers and in both input/output. If all deployers fall into this "removal" + could be then re-ordered, then it's OK. I don't think we're here to solve every possible ordering issue, mostly just the most natural/simple one's. Hence sometimes adding some order number / changing name is still a valid option. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262368#4262368 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262368

16 years, 2 months

1
0
0 / 0

[jBPM Development] - Re: feature suggestion: add a description for transitions

by sebastian.s

Thanks for giving your view on this, Bernd. There is no doubt that are still lots of additional requirements not implemented in jBPM yet. However I don't see the point of confusing people. Because the way I described it seems quite clear to me: There are transition names which are obligatory since they are used for the actual execution and there are description or long-names which are optional. Generating process diagrams shows the transition names unless descriptions / long names have been given. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262347#4262347 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262347

16 years, 2 months

1
0
0 / 0

[JBoss OSGi Development] - Extender Patter vs. LifecycleInterceptors

by thomas.diesler＠jboss.com

There is a new blogpost in the diary that discusses Extenders/Interceptors http://jbossosgi.blogspot.com/2009/10/extender-pattern-vs-lifecycle.html As far as integration with the MC Framework goes, you can add interceptors as part of the bootstrap config like this | <bean name="WebXMLVerifier" class="org.jboss.osgi.framework.deployers.WebXMLVerifierInterceptor"/> | Interceptors can of course also be added dynamically via the related LifecycleInterceptorService. In case of of the MC Framework the interceptor attachment API delegates to the DeploymentUnit, so that interceptor attachments are visible by the deployers and vice versa. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262341#4262341 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262341

16 years, 2 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Change in manifest parser breaks symbolic name

by thomas.diesler＠jboss.com

Folks (Adrian), do we have an update on this? It is scheduled for Beta5 01-Dec-2009 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262328#4262328 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262328

16 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2009