On 7 Apr 2011, at 13:48, Max Rydahl Andersen wrote: > >>>>> 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.
:-D > >> 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. Over to Shane &co ;-) > >> 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 think the deal would be you would only scan bean archives (those with beans.xml) and ignore those without. Solder annotations will only be picked up if it's a bean archive or the archive author explicitly asks the class to be scanned programmatically (which we are discussing you guys won't support for tooling, in this case a design-beans.xml will be required). > > >>>>>> 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. I think that for this 10% we have to make people write a xml descriptor as well. > > /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 >>>>>>> [email protected] >>>>>>> https://lists.jboss.org/mailman/listinfo/seam-dev >>>>>> >>>>> >>>>> /max >>>>> http://about.me/maxandersen >>>>> >>>>> >>>>> >>>> >>> >>> /max >>> http://about.me/maxandersen >>> >>> >>> >> > > /max > http://about.me/maxandersen > > > _______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
