Re: Ioc Ordering Contraints
It would be nice just to have some documented "markers". I usually just look at the TapestryModule class to figure out what to do, but having some documented phases would probably solve most issues. It would also solve the problem workers changing between releases. For example what if UnclaimedField goes away. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Ioc-Ordering-Contraints-tp5716154p5716174.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Ioc Ordering Contraints
Would be nice it we could get a printout of services within their constrains somehow. Is there any way to do that presently? On Sep 10, 2012, at 4:09 PM, Howard Lewis Ship wrote: > One thing I have considered in the past is to be able to define > "phases" for an ordered configuration, and place contributions within > a phase, but also ordered relative to other contributions in that > phase. Thus the service author would define (and document) a few > phases, and contributions would go into those phases. The phases > themselves would be ordered. So in your case, there might be a > "FinalValidation" phase that, by default, just contained > "UnclaimedField" and you could add your HasOnActivate contribution > inside that phase. > > Even without code changes, we could create a few null contributions > (that is allowed) that exist just as placeholders. So we could > contribute a "FinalValidation" element, order most things > "before:FinalValidation" an dorder UnclaimedField > "after:FinalValidation". > > Another alternative I've considered is new API that would allow you to > modify existing contribution's constraints. > > Yes, this is complicated, because the basic concept is complicated in > certain edge cases. The complexity is just an outgrown of the design > requirements: handling the addition of any number of modules at > runtime, and the growth of the framework over time. > > On Mon, Sep 10, 2012 at 9:03 AM, trsvax wrote: >> I'd try creating a dummy worker called beforeUnclaimedField and make it >> >> before:UnclaimedField >> >> then change yours to >> >> after:beforeUnclaimedField >> >> >> >> -- >> View this message in context: >> http://tapestry.1045711.n5.nabble.com/Ioc-Ordering-Contraints-tp5716154p5716171.html >> Sent from the Tapestry - User mailing list archive at Nabble.com. >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Ioc Ordering Contraints
One thing I have considered in the past is to be able to define "phases" for an ordered configuration, and place contributions within a phase, but also ordered relative to other contributions in that phase. Thus the service author would define (and document) a few phases, and contributions would go into those phases. The phases themselves would be ordered. So in your case, there might be a "FinalValidation" phase that, by default, just contained "UnclaimedField" and you could add your HasOnActivate contribution inside that phase. Even without code changes, we could create a few null contributions (that is allowed) that exist just as placeholders. So we could contribute a "FinalValidation" element, order most things "before:FinalValidation" an dorder UnclaimedField "after:FinalValidation". Another alternative I've considered is new API that would allow you to modify existing contribution's constraints. Yes, this is complicated, because the basic concept is complicated in certain edge cases. The complexity is just an outgrown of the design requirements: handling the addition of any number of modules at runtime, and the growth of the framework over time. On Mon, Sep 10, 2012 at 9:03 AM, trsvax wrote: > I'd try creating a dummy worker called beforeUnclaimedField and make it > > before:UnclaimedField > > then change yours to > > after:beforeUnclaimedField > > > > -- > View this message in context: > http://tapestry.1045711.n5.nabble.com/Ioc-Ordering-Contraints-tp5716154p5716171.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Ioc Ordering Contraints
I'd try creating a dummy worker called beforeUnclaimedField and make it before:UnclaimedField then change yours to after:beforeUnclaimedField -- View this message in context: http://tapestry.1045711.n5.nabble.com/Ioc-Ordering-Contraints-tp5716154p5716171.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Ioc Ordering Contraints
> I think you are looking for the "ultimate solution" here that doesn't exist. Yeah, maybe. Sigh. :`( I guess I was jus' hoping I'd overlooked something. Nevermind, I'll live! :) Cheers to all for the suggestions. Steve. On 10 September 2012 23:27, Lenny Primak wrote: > Hey, Steve, > > I think you are looking for the "ultimate solution" here that doesn't exist. > I don't think you can make it work in all cases and all configurations. > I think you need to find the last service that's really there and the one you > need to be after, and put that in the constraints. > Since you know what you actually are putting in your app, that will never > change > until you add more modules. > > On Sep 10, 2012, at 10:46 AM, Steve Eynon > wrote: > >> Hi Robert, >> >> I had previously tried "before:UnclaimedField", "after:*" - but >> doesn't matter which way round the constraints go, I still get: >> >> Unable to add 'ContextNotRequiredWorker' as a dependency of >> 'UnclaimedField', as that forms a dependency cycle ('UnclaimedField' >> depends on itself via 'ContextNotRequiredWorker'). The dependency has >> been ignored. >> >> Steve. >> >> On 10 September 2012 19:37, Robert Zeigler >> wrote: >>> Hi Steve, have you tried specifying "after:*", "before:UnclaimedField"? >>> >>> Robert >>> >>> On Sep 9, 2012, at 9/99:33 PM , Steve Eynon wrote: >>> Hi Michael, > just specify as many as are important to you. I kinda want mine to run last, because I need make sure no other workers (in T5 or other modules) add a onActivate() method. The issue here is that both my 'ContextNotRequiredWorker' and T5's 'UnclaimedField' want to run last - which isn't allowed. > the trick is to specify multiple constraints I could specify many "after" clauses for T5 workers as you mention, but that then won't (be guaranteed to) work if some other another module adds an onActivate() method. Stumpted, Steve. -- Steve Eynon --- "If at first you don't succeed, so much for skydiving!" On 10 September 2012 10:13, Michael Prescott wrote: > Michael - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Ioc Ordering Contraints
Hey, Steve, I think you are looking for the "ultimate solution" here that doesn't exist. I don't think you can make it work in all cases and all configurations. I think you need to find the last service that's really there and the one you need to be after, and put that in the constraints. Since you know what you actually are putting in your app, that will never change until you add more modules. On Sep 10, 2012, at 10:46 AM, Steve Eynon wrote: > Hi Robert, > > I had previously tried "before:UnclaimedField", "after:*" - but > doesn't matter which way round the constraints go, I still get: > > Unable to add 'ContextNotRequiredWorker' as a dependency of > 'UnclaimedField', as that forms a dependency cycle ('UnclaimedField' > depends on itself via 'ContextNotRequiredWorker'). The dependency has > been ignored. > > Steve. > > On 10 September 2012 19:37, Robert Zeigler > wrote: >> Hi Steve, have you tried specifying "after:*", "before:UnclaimedField"? >> >> Robert >> >> On Sep 9, 2012, at 9/99:33 PM , Steve Eynon wrote: >> >>> Hi Michael, >>> just specify as many as are important to you. >>> >>> I kinda want mine to run last, because I need make sure no other >>> workers (in T5 or other modules) add a onActivate() method. The issue >>> here is that both my 'ContextNotRequiredWorker' and T5's >>> 'UnclaimedField' want to run last - which isn't allowed. >>> the trick is to specify multiple constraints >>> >>> I could specify many "after" clauses for T5 workers as you mention, >>> but that then won't (be guaranteed to) work if some other another >>> module adds an onActivate() method. >>> >>> Stumpted, >>> >>> Steve. >>> -- >>> Steve Eynon >>> --- >>> "If at first you don't succeed, >>> so much for skydiving!" >>> >>> >>> >>> On 10 September 2012 10:13, Michael Prescott >>> wrote: Michael >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Ioc Ordering Contraints
Hi Robert, I had previously tried "before:UnclaimedField", "after:*" - but doesn't matter which way round the constraints go, I still get: Unable to add 'ContextNotRequiredWorker' as a dependency of 'UnclaimedField', as that forms a dependency cycle ('UnclaimedField' depends on itself via 'ContextNotRequiredWorker'). The dependency has been ignored. Steve. On 10 September 2012 19:37, Robert Zeigler wrote: > Hi Steve, have you tried specifying "after:*", "before:UnclaimedField"? > > Robert > > On Sep 9, 2012, at 9/99:33 PM , Steve Eynon wrote: > >> Hi Michael, >> >>> just specify as many as are important to you. >> >> I kinda want mine to run last, because I need make sure no other >> workers (in T5 or other modules) add a onActivate() method. The issue >> here is that both my 'ContextNotRequiredWorker' and T5's >> 'UnclaimedField' want to run last - which isn't allowed. >> >>> the trick is to specify multiple constraints >> >> I could specify many "after" clauses for T5 workers as you mention, >> but that then won't (be guaranteed to) work if some other another >> module adds an onActivate() method. >> >> Stumpted, >> >> Steve. >> -- >> Steve Eynon >> --- >> "If at first you don't succeed, >> so much for skydiving!" >> >> >> >> On 10 September 2012 10:13, Michael Prescott >> wrote: >>> Michael >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Ioc Ordering Contraints
Hi Steve, have you tried specifying "after:*", "before:UnclaimedField"? Robert On Sep 9, 2012, at 9/99:33 PM , Steve Eynon wrote: > Hi Michael, > >> just specify as many as are important to you. > > I kinda want mine to run last, because I need make sure no other > workers (in T5 or other modules) add a onActivate() method. The issue > here is that both my 'ContextNotRequiredWorker' and T5's > 'UnclaimedField' want to run last - which isn't allowed. > >> the trick is to specify multiple constraints > > I could specify many "after" clauses for T5 workers as you mention, > but that then won't (be guaranteed to) work if some other another > module adds an onActivate() method. > > Stumpted, > > Steve. > -- > Steve Eynon > --- > "If at first you don't succeed, > so much for skydiving!" > > > > On 10 September 2012 10:13, Michael Prescott > wrote: >> Michael > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Ioc Ordering Contraints
Tapestry's ordered constraints need to be like this to allow distributed configuration. If two contributions specify "after:X", tapestry will make sure that they both occur after X. Since it's impossible to order both directly after X, tapestry will (pseudo randomly) decide an ordering which is not guaranteed. Likewise, if two contributions (A and B) specify a constraint of "after:**", tapestry will guarantee that both A and B occur after the other contributions but the ordering of A and B is not guaranteed. If you need more specific ordering, you will need to be more specific ;) -- View this message in context: http://tapestry.1045711.n5.nabble.com/Ioc-Ordering-Contraints-tp5716154p5716159.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Ioc Ordering Contraints
*@Michael* Constraints are very loose; after means 'somewhere after' rather than > 'immediately after' If that was the case, why did cause an issue if it was so loose ? Is this one special case (i.e. after:***) ? What's the advantage of having this behavior over having it strict as being *immediately after* ? I haven't tried this before but if I had to chose, I'd chose it to act as *immediately after*. Thinks would be more clear and I only need to identify the injected transformers order to set mine up correctly. *@Steve* * * Does it fit your needs to specify *UnclaimedField* order as *after:** and then specify the other transformer with less priority to be before * UnclaimedField* as *before: UnclaimedField* ? On Mon, Sep 10, 2012 at 4:33 AM, Steve Eynon wrote: > Hi Michael, > > > just specify as many as are important to you. > > I kinda want mine to run last, because I need make sure no other > workers (in T5 or other modules) add a onActivate() method. The issue > here is that both my 'ContextNotRequiredWorker' and T5's > 'UnclaimedField' want to run last - which isn't allowed. > > > the trick is to specify multiple constraints > > I could specify many "after" clauses for T5 workers as you mention, > but that then won't (be guaranteed to) work if some other another > module adds an onActivate() method. > > Stumpted, > > Steve. > -- > Steve Eynon > --- > "If at first you don't succeed, >so much for skydiving!" > > > > On 10 September 2012 10:13, Michael Prescott > wrote: > > Michael > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Re: Ioc Ordering Contraints
Hi Michael, > just specify as many as are important to you. I kinda want mine to run last, because I need make sure no other workers (in T5 or other modules) add a onActivate() method. The issue here is that both my 'ContextNotRequiredWorker' and T5's 'UnclaimedField' want to run last - which isn't allowed. > the trick is to specify multiple constraints I could specify many "after" clauses for T5 workers as you mention, but that then won't (be guaranteed to) work if some other another module adds an onActivate() method. Stumpted, Steve. -- Steve Eynon --- "If at first you don't succeed, so much for skydiving!" On 10 September 2012 10:13, Michael Prescott wrote: > Michael - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Ioc Ordering Contraints
Apparently, the trick is to specify multiple constraints. Constraints are very loose; after means 'somewhere after' rather than 'immediately after', so just specify as many as are important to you. Someone more informed can weigh in whether you can mix specific constraints with wildcards. In the meantime, give it a shot! Michael On 9 September 2012 22:02, Steve Eynon wrote: > Hi, > > I have a transform worker which I want to run after everything else (it > checks for the existence of an onActive() method) so I have the following > Module method, note the "after:*" > > @Contribute(**ComponentClassTransformWorker2**.class) > @Primary > public static void provideTransformWorkers( > OrderedConfiguration<**ComponentClassTransformWorker2**> configuration) > { > > configuration.addInstance( > "ContextNotRequiredWorker", > NotRequiredWorker.class, > "after:*"); > } > > But then I get the following warning: > > WARN : ConentClassTransformWorker - Unable to add 'UnclaimedField' as a > dependency of 'ContextNotRequiredWorker', as that forms a dependency cycle > ('ContextNotRequiredWorker' depends on itself via 'UnclaimedField'). The > dependency has been ignored. > > because T5 defines UnclaimedField to also be "after:*". How can I define > my config to be "after:* except UnclaimedField", or "before:UnclaimedField > but after:everthing else"? > > Or does anyone know how else may I resolve my ordering problem? > > Cheers, > > Steve. > > --**--**- > To unsubscribe, e-mail: > users-unsubscribe@tapestry.**apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Ioc Ordering Contraints
Hi, I have a transform worker which I want to run after everything else (it checks for the existence of an onActive() method) so I have the following Module method, note the "after:*" @Contribute(ComponentClassTransformWorker2.class) @Primary public static void provideTransformWorkers( OrderedConfiguration configuration) { configuration.addInstance( "ContextNotRequiredWorker", NotRequiredWorker.class, "after:*"); } But then I get the following warning: WARN : ConentClassTransformWorker - Unable to add 'UnclaimedField' as a dependency of 'ContextNotRequiredWorker', as that forms a dependency cycle ('ContextNotRequiredWorker' depends on itself via 'UnclaimedField'). The dependency has been ignored. because T5 defines UnclaimedField to also be "after:*". How can I define my config to be "after:* except UnclaimedField", or "before:UnclaimedField but after:everthing else"? Or does anyone know how else may I resolve my ordering problem? Cheers, Steve. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org