Jesse Kuhnert wrote:
> I had a few thoughts.
>
> For some reason throwing exceptions sends a red flag up for me.
Maybe i'm influenced by continuations + it was the easiest way for this
without changing any APIs at all.
> 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.. ?
Yea, my initial thought was to look for something like this.
But, this isn't an issue of configuring a worker to run
before another one.
It's an issue of ordering the methods that a *single* worker processes.
Anyway, let me try to explain this. It might eventually be important + allow
more annotation tricks.
So, here's how the current implementation for
AnnotationEnhancementWorker works:
for (Annotation a : clazz.getAnnotations()) {
performClassEnhancement(op, spec, clazz, a, classResource); }
for (Method m : clazz.getMethods()) {
for (Annotation a : method.getAnnotations()) {
performMethodEnhancement(op, spec, m, a, classResource); }
for (SecondaryAnnotationWorker worker : _secondaryAnnotationWorkers) {
worker.peformEnhancement(); }
}
Note that the order of methods returned by clazz.getMethods is undetermined.
So, in the case of a class containing
@Component(bindings='...') public TextField getEmail();
@Component(copyOf="email") public TextField getSecondEmail();
if method getSecondEmail() is processed first we're in trouble cause we
need getEmail() already processed so we can grab and copy its bindings.
What I propose actually adds the processing of getSecondEmail() in a queue
and re-process it later on.
But ...
>
> 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.
... you're probably right!
For the copyOf case, I can see that I can add a new worker at the chain
which will clean up any leftovers, i.e. copy the bindings. I haven't tested
this, but it should work.
So, I don't see a use case where my changes make sense... but i'm still
sending
this...
Perhaps it'll inspire someone :)
> 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]
>>
>>
>
>
--
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]
