I'm a bit concerned about you scanning weld* jars - what are you trying to discover by doing this? Do you have a list of beans discovered this way?
BTW Wweld-extensions doesn't exist anymore. No documented way to do this right now, but I'm also not sure of a good way to do this for the reasons below. We do need something though, I agree. Can you make a CDI issue for this, so it doesn't fall off our radar? Thanks! On 25 Mar 2011, at 18:22, Alexey Kazakov wrote: > We are going to support Seam 3 extensions (such as @Veto, generic, ...) so we > don't need to have some extra meta for such beans. > We are going to look at > META-INF/services/javax.enterprise.inject.spi.Extension and handle all the > known extensions properly. > But is it enough for Seam 3? For instance for weld we had to scan > *weld*.jar's in a special way since they don't have beans.xml. But some of > those beans we should not load (for example we don't load > weld-extensions*.jar). How we supposed to recognize such beans in design > time? Is there any documented way to do it? > > > > On 03/25/2011 03:37 AM, Pete Muir wrote: >> I thought the plan was for JBDS to natively understand Solder annotations to >> overcome this problem. >> >> I really don't think that forcing some xml file on extension developers is >> very clever - either they would have to use this as the canonical source of >> info in which case we're back to programming in XML and it doesn't look good >> when people ask for examples of using CDI extensions, or we have to keep >> this stuff in sync. >> >> On 24 Mar 2011, at 20:56, Max Rydahl Andersen 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 ? >>> >>> Something I missed ? >>> >>> /max >>> http://about.me/maxandersen >>> >>> >>> >>> >>> _______________________________________________ >>> seam-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/seam-dev > _______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
