[seam-dev] Interceptor packaging convention

[Nicklas Karlsson]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20100329/ead8d460/attachment-0001.html