Re: [seam-dev] Interceptor packaging convention

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(a)gmail.com&gt;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/sr... > > > _______________________________________________ > seam-dev mailing list > seam-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > -- --- Nik _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev