On Thu, Mar 24, 2011 at 16:56, Max Rydahl Andersen <max.andersen@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