I concur; throwing exceptions is a problem. I'd rather split the pipeline into multiple pipelines to support finer grained scheduling of the operations.
On 10/4/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
I had a few thoughts. For some reason throwing exceptions sends a red flag up for me. Is this something that could be more easily solved by using patterns available through HiveMind? Maybe something like how the chain of command workers are able to say before="" after="" etc.. ? My head isn't fully around what you are doing, but my instinct tells me that this kind of problem is best solved via some kind of hivemind construct. It may involve a little more overhead at first to change the service configurations around to use something new, but hey...That's the cost of developing against a very popular ~framework~ API. ;) On 10/4/06, andyhot <[EMAIL PROTECTED]> wrote: > > I got this working locally. > Code coverage remains at the extraordinary 100% level (both > for lines and branches) > > To recap, this addition allows > MethodAnnotationEnhancementWorkers to throw a > (new) RetryAnnotationEnhancementException. > In this way, they get re-processed after all other > annotations from all other methods have. > > BTW, this is very different from SecondaryAnnotationWorkers. > It also allows retries based on runtime conditions. > > > andyhot wrote: > > Currently, for a given annotated class: > > - class-level workers are applied first. > > - for each method : > > 1) all its method-level workers are applied, then > > 2) all secondary workers are tested and applied > > 3) move on to the next method. > > > > While taking a look at copy-of > > http://tapestry.apache.org/tapestry4/UsersGuide/spec.html#spec.component > > and adding it to the @Component annotation, there is the need to apply a > > worker > > after all the other workers (from all other methods) have run. > > > > That's because we have to capture all bindings from the original > > component before > > copying them to the copyOf component. And perhaps other annotations can > > make use > > of this scheduling. > > > > Now, what i have in mind involves the > > AnnotationEnhancementWorker.performMethodEnhancement method which in > > turn calls > > MethodAnnotationEnhancementWorker.performEnhancement > > > https://svn.apache.org/repos/asf/tapestry/tapestry4/trunk/tapestry-annotations/src/java/org/apache/tapestry/annotations/MethodAnnotationEnhancementWorker.java > > > > The idea is that if that last method throws a new > > RetryLaterKindOfException, we grab all its arguments in a queue > > and run it at the end. > > > > So, will this be useful? Am i missing an easy way out of this? > > > > > > > > > > > -- > Andreas Andreou - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr > Tapestry / Tacos developer > Open Source / J2EE Consulting > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
-- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com
