[seam-dev] Interceptor packaging convention

[Lincoln Baxter, III]

For documentation (not conversation) purposes -- this approach has already
been discussed:

/**
  * A small non-portable Weld PoC enabler that does not take many factors
(incl. class runtime availability) into account:
  */
public class SeamInterceptorEnablerExtension implements Extension
{
   public void beforeBeanDiscovery(@Observes final BeforeBeanDiscovery
event, final BeanManager manager)
   {
      if (manager instanceof BeanManagerImpl)
      {
         BeanManagerImpl impl = (BeanManagerImpl) manager;

         // Enable interceptors in order here
         // enableInterceptor(impl, YourInterceptor1.class);
         // enableInterceptor(impl, YourInterceptor2.class);
         // enableInterceptor(impl, YourInterceptor3.class); ... and more
      }
   }

   private void enableInterceptor(final BeanManagerImpl impl, final Class<?>
type)
   {
      List<Class<?>> list = new ArrayList<Class<?>>();
      list.addAll(impl.getEnabledInterceptorClasses());

      list.add(type);

      impl.setEnabledInterceptorClasses(list);
   }
}

On Mon, Mar 29, 2010 at 4:02 PM, Nicklas Karlsson <nickarls at gmail.com>wrote:

> It would probably work for us but would be non-portable, right?
>
> *IF* we go down the route of auto-enablement, it would probably be easy to
> have the Seam 3 config @Injected into the extension and check from a field
> if the enabling is turned on or off (set in XML or wherever) so no need to
> exclude/include jars.
>
>
> On Mon, Mar 29, 2010 at 10:50 PM, Ales Justin <ales.justin at gmail.com>wrote:
>
>> >> That's why the JAR is included by default via Maven -- or provided in
>> the
>> >> "Dump these jars into your app" folder that we have in the
>> Dist-releases. No
>> >> extra work required to include it.
>> >
>> > And so I repeat my question: how is this better than a pre-written XML
>> > file that is included by default?
>>
>> What is required for a class to be interceptor?
>> (haven't been in JEE world for a while :-))
>>
>> Does it need to implement some interface?
>> Or is proper api enough -- e.g. a plain class which has the right method?
>> (in JBoss AOP, afair, it was enough to have single param method "invoke"
>> with InvocationContext param)
>>
>> Just asking on how to easily recognize the interceptors,
>> since I've just written a single-pass scanning MC lib [1],
>> where it would be trivial to add recognized interceptors by default to
>> Weld' metadata.
>> (we already do/add a bunch of default things for things we recognize as
>> Weld in JBossAS/MC)
>>
>> But I guess we then introduce ordering issue?
>>
>> [1] - no more need to do multiple scans in diff JBossAS components
>> e.g. Hibernate Scanner impl:
>> http://anonsvn.jboss.org/repos/jbossas/projects/scanning/trunk/plugins/src/main/java/org/jboss/scanning/hibernate/
>>
>>
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>
>
>
> --
> ---
> Nik
>
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>


-- 
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20100329/45a82372/attachment-0001.html