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> 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