The idea behind the redefiner was to allow the use of a limited form of a 
closure to work over the class. Every annotation on the class will receive a 
callback to the function, in which you can decide how to use the annotation 
(replace, keep etc). This gives you access to the context in which the 
redefinition takes place.

For example:

public void redefine() {
      
      AnnotatedTypeBuilder<Foo> builder = new 
AnnotatedTypeBuilder<Foo>().readFromType(Foo.class);
      
      builder.redefine(Bar.class, new AnnotationRedefiner<Bar>() {
         
         @Override
         public void redefine(RedefinitionContext<Bar> ctx) {
            if 
(ctx.getAnnotationBuilder().getAnnotation(Bar.class).name().equals("Pete")) {
               ...
            }
         }
         
      });
      
   }

I don't believe this is possible using the imperative commands (at least, not 
so concisely).

I would be against dropping this feature, as I think it is useful and has a 
common precedent (e.g. common programming pattern books).

On 17 Jan 2012, at 23:14, Gerhard Petracek wrote:

> hi @ all,
> 
> today i reviewed it. my findings:
> 
> #1:
> imo we shouldn't have public impl classes in the api module >if< we can
> avoid it. i made a small refactoring to reduce the visibility of those
> classes and i attached a patch which shows the suggestion at [1].
> 
> #2:
> i had a short talk with pete about AnnotationRedefiner. it looks like that
> it was introduced to provide an alternative syntax to the other builder
> methods esp. for complex cases.
> imo we should re-visit it (esp. if there are really that many cases which
> really benefit from it - compared to using the other builder methods).
> 
> regards,
> gerhard
> 
> [1]  https://issues.apache.org/jira/browse/DELTASPIKE-45
> 
> 
> 
> 2012/1/7 Jason Porter <lightguard...@gmail.com>
> 
>> I have the classes all checked into my branch [1]. Please review. I know
>> many of them need Javadoc, so you can forget that part. Mainly the
>> AnnotatedTypeBuilder needed many classes that were in Solder Impl. As I
>> believe AnnotatedTypeBuilder is pretty helpful for everyone doing CDI
>> Extension development I put them all in api, so we'll have some *Impl
>> classes in api. If everyone is okay with that, great. Otherwise we may need
>> to find a new place to put them as we can't put them in impl and keep
>> AnnotatedTypeBuilder in api.
>> 
>> [1] https://github.com/LightGuard/incubator-deltaspike/tree/DELTASPIKE-45
>> 
>> --
>> Jason Porter
>> http://lightguard-jp.blogspot.com
>> http://twitter.com/lightguardjp
>> 
>> Software Engineer
>> Open Source Advocate
>> Author of Seam Catch - Next Generation Java Exception Handling
>> 
>> PGP key id: 926CCFF5
>> PGP key available at: keyserver.net, pgp.mit.edu
>> 

Reply via email to