Gavin, The spec imho says nothing about the visibility of constructors (e.g. in 3.1.1. and others). But the TCK sometimes assumes that even package scoped classes (e.g. MissileInterceptor) which can _not_ be constructed with new must be injected. This feels a bit unnatural to me since there may be a very good reason to hide e.g. private constructors or even whole classes. Have I overseen something in the spec or do we need to clarify some parts? Txs and LieGrue, strub __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

Von: Gavin King <gavin.king(a)gmail.com&gt; Betreff: Re: [weld-dev] non-visable classes and constructors An: "Pete Muir" <pmuir(a)redhat.com&gt; CC: "Mark Struberg" <struberg(a)yahoo.de&gt;, "Weld-Dev" <weld-dev(a)lists.jboss.org&gt; Datum: Montag, 30. November 2009, 16:04 Huh? The spec does not in any way limit the visibility of the bean constructor. So any visibility must be supported! Sent from my iPhone On Nov 30, 2009, at 6:21 AM, Pete Muir <pmuir(a)redhat.com&gt; wrote: > Yes, the spec makes no statements here I know of. I don't think the TCK should restrict the impl like that anyway, so please file a CDKTCK issue (and say the FQCN, as there are multiple classes called MissileInterceptor). > > Thanks! > > On 30 Nov 2009, at 09:13, Mark Struberg wrote: > >> Gavin, >> >> The spec imho says nothing about the visibility of constructors (e.g. in 3.1.1. and others). >> But the TCK sometimes assumes that even package scoped classes (e.g. MissileInterceptor) which can _not_ be constructed with new must be injected. This feels a bit unnatural to me since there may be a very good reason to hide e.g. private constructors or even whole classes. >> >> Have I overseen something in the spec or do we need to clarify some parts? >> >> Txs and LieGrue, >> strub >> >> __________________________________________________ >> Do You Yahoo!? >> Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. >> http://mail.yahoo.com >> >> _______________________________________________ >> weld-dev mailing list >> weld-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev > > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev

A minor detail but do you think it would be handy if Weld would support some kind of module info metadata that could be displayed on bootstrap? It could be handy to see which modules are present and have been picked up correctly... Something in the line of a <module-info>Weld-Excel 3.0.1</module> in beans.xml so that a list of enabled modules and extensions could be listed when the container boots. It could even be extended to cover possible dependencies. -- --- Nik _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

Yes, the manifest would absolutely be the right choice. Remember there are already some standard keys such as Implementation-Version. - Dan Allen Sent from my Android-powered phone: An open platform for carriers, consumers and developers. On Nov 30, 2009 6:20 AM, "Pete Muir" <pmuir(a)redhat.com&gt; wrote: Not a bad idea, want to prototype something? Note that if you put it in beans.xml it will leak into user configuration too, probably something we don't want. It would better to do this using the Manifest IMO. On 30 Nov 2009, at 06:38, Nicklas Karlsson wrote: > A minor detail but do you think it would be ha...