On Thu, Mar 24, 2011 at 16:56, Max Rydahl Andersen
<max.andersen(a)redhat.com>wrote:
Hi,
Talking with Seam/CDI tooling team at EclipseCon and we are still in the
dark on how tooling are supposed to identify CDI extensions that are
registered programmatically and often does not have a beans.xml to "mark"
them.
Today we do it by simply scanning jars with *weld*.jar naming pattern (very
brittle and not good for 3rd party extensions).
Furthermore we also have a list of classes to include/exclude since some
components in these jars aren't CDI compliant.
How do we go about identifying these things ?
The idea discussed with Dan/Pete on this topic previously were to add a
design-beans.xml
and use that as a marker + list the classes we should load/configure as
possible injection/navigation candidates in the tooling.
I was hoping this were settled before Seam 3 GA but it seem to fallen
through the cracks ?
I can say that settling anything before Seam 3.0.0 is darn near an
impossibility. We'll have to do everything we can just to complete what we
already have before that date.
For now, the best we can do is make sure we @Veto beans that should not be
injectable. We can ask module leads to do a quick review and try to use that
annotation in obvious places to clean up suggestions in JBoss Tools as much
as possible. Otherwise, we'll have to just communicate to you as much as
possible about how to grok the logic that Solder is applying to the
programming model (such as generic and default beans).
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction