note, because majority of Seam 3 extensions aren't native CDI beans but rather Seam Solder extensions this is rather crucial to have good tooling for Seam 3....otherwise all validation and navigation is just very broken. /max On Mar 24, 2011, at 13: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 > seam-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev /max http://about.me/maxandersen

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 > seam-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev

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 >> seam-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev

We have an issue in Weld Jira - https://issues.jboss.org/browse/WELD-815 Should we create another one against CDI?

> 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? See the list here http://pastebin.com/U902Din1 And see related JBT issues https://issues.jboss.org/browse/JBIDE-8017 and https://issues.jboss.org/browse/JBIDE-8019

> 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? We have an issue in Weld Jira - https://issues.jboss.org/browse/WELD-815 Should we create another one against CDI? > 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 >>>> seam-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/seam-dev

> I thought the plan was for JBDS to natively understand Solder annotations to overcome this problem. That does not solve the problems. We got two of them: 1) finding which jar's to scan (haven't checked this but using the service declaration in META-INF might be enough)

2) when scanning the jar knowing which classes in the jar's that looks like compliant CDI beans really aren't beans.

> 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. Since the annotations aren't descriptive enough we'll need to come up with something ;)

/max > > 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 >> seam-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev > /max http://about.me/maxandersen

>> 1) finding which jar's to scan (haven't checked this but using the service declaration in META-INF might be enough) > > I think it should > >> 2) when scanning the jar knowing which classes in the jar's that looks like compliant CDI beans really aren't beans. > > I think this is simple. If it has beans.xml, as normal. If it doesn't look for Solder annotations and register those beans... that sounds like a plan. and just to be sure - you mean beans.xml as normal + scan solder annotations and if no beans.ml and just service declaration in manifest.mf only scan solder annotations ?

and this will also mean that if an archive actually contains "normal" CDI beans they would not be picked up. Correct?

>>> 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. >> >> Since the annotations aren't descriptive enough we'll need to come up with something ;) > > I think we need to revisit why the annotations aren't descriptive enough... Last time it was that the beans simply didn't have annotations or any metadata when registered programmatically.

/max > >> >> /max >> >>> >>> 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 >>>> seam-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/seam-dev >>> >> >> /max >> http://about.me/maxandersen >> >> >> > /max http://about.me/maxandersen

>>>> 1) finding which jar's to scan (haven't checked this but using the service declaration in META-INF might be enough) >>> >>> I think it should >>> >>>> 2) when scanning the jar knowing which classes in the jar's that looks like compliant CDI beans really aren't beans. >>> >>> I think this is simple. If it has beans.xml, as normal. If it doesn't look for Solder annotations and register those beans... >> >> that sounds like a plan. >> >> and just to be sure - you mean beans.xml as normal + scan solder annotations and if no beans.ml and just service declaration in manifest.mf only scan solder annotations ? > > Yes. For now just solder, but if any other such libs come up consider adding those? Not unless there is a need.

> For JBoss stuff, it will be Solder though. This will mean that people have the option of using CDI annotations OR Solder annotations to define their beans, which I think should mean that 90% of extensions can be done declaratively if authors try hard (this is a good incentive to do just that). We will need to consider a design-beans.xml or something for the remaining beans I think - perhaps for now based on seam config? That's what we discussed yes - but would be good to have some example definition of these we could use/explore.

> Anyway, that can't go in the spec until there is an xml dialect there... yes - thus focusing on Solder annotations and eventually seamconfg xml support sounds like the best plan to me. >> and this will also mean that if an archive actually contains "normal" CDI beans they would not be picked up. Correct? > > An archive without beans.xml? yes, one that only has the manifest-mf service to say "enable Solder scanning"

>>>>> 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. >>>> >>>> Since the annotations aren't descriptive enough we'll need to come up with something ;) >>> >>> I think we need to revisit why the annotations aren't descriptive enough... >> >> Last time it was that the beans simply didn't have annotations or any metadata when registered programmatically. > > Right, as above, I hope Solder + CDI can cover 90% of cases... Well, its the darnest 10% that is tricky....i.e. noticing that UserTransaction, PersistenceContext and any other new "thing" will have to be somehow registered as "available". If not, you get annoying warnings.

/max > >> >> /max >> >>> >>>> >>>> /max >>>> >>>>> >>>>> 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 >>>>>> seam-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/seam-dev >>>>> >>>> >>>> /max >>>> http://about.me/maxandersen >>>> >>>> >>>> >>> >> >> /max >> http://about.me/maxandersen >> >> >> > /max http://about.me/maxandersen