>>>> 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 >>>>>> [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
