On 4/5/06, David Blevins <[EMAIL PROTECTED]> wrote: > > On Apr 5, 2006, at 2:30 AM, James Strachan wrote: > > > On 4/5/06, David Blevins <[EMAIL PROTECTED]> wrote: > >> On Apr 4, 2006, at 11:37 PM, James Strachan wrote: > >> > >>> On 4/4/06, David Blevins <[EMAIL PROTECTED]> wrote: > >>>> > >>> Good point - though before JSR 250 & EJB 3, when Pico was just > >>> starting, I tended to use the convention that contructor arguments > >>> were 'mandatory' properties and setter methods were for optional > >>> stuff > >>> (or stuff that can be configured after construction). > >>> > >>> i.e. its kinda implicit that any constructor arguments must be > >>> injected to be able to construct the object - so they are mandatory > >>> already. I guess a container could shove in null objects or zero > >>> values if it can't find a value, but maybe its easier to just say > >>> that > >>> for constructor injection, the parameters should be considered > >>> mandatory? > >> > >> I get it -- you're using @Resource to imply whether or not an object > >> attribute is optional or required. > > > > Yeah; Ideally there would be an @Mandatory in JSR 250 on properties... > > > >> We're talking about different > >> things then. Was more going after EJB 3 perspective where @Resource > >> is primarily used to label an object attribute with an identifier and > >> optional mapping the injector understands (such as a jndi name, an > >> xml attribute or element name, or whatever). > > > > Yeah. Though the EJB 3 injection is more like auto-JNDI lookup; the > > POJO is kinda pulling resources into itself using the name it defines. > > In Spring style, the XML config injects into the POJO without its > > particular pre-knowledge. So AnDI is a little attempt to reclaim the > > @Resource annotation for non-JNDI style injection where we can just > > use it as a marker for what are the mandatory properties. > > Exactly. Lot's of stuff could fall under the "whatever" category... > kernel references or just about anything could be named via @Resource > (name="foo"). Heck, if you use a URI in there like I know you would, > you could do anything with it :) I'd be likely to endorse something > sick and twisted like that ;)
LOL. I've gone a bit URI crazy lately - they're the crack of strings; quite addictive :) I blame hiram for getting me hooked :) > >> Seems like in your scenario, someone couldn't use the annotation to > >> specify how object attribute would be populated via an injectable > >> resource but still let it be an optional dependency. Guessing you > >> don't really care though :) > > > > This is a good point. I'd assumed in EJB 3 land that @Resource implies > > mandatory injection; what happens if there is no value available in > > JNDI? Is that an error or is null used? If its the latter then maybe > > we do need a @Mandatory or @NotNull or something. > > Right, EJB 3 says they are mandatory. But thinking along your lines > of slightly repurposing it for better use, you could theoretically > allow someone to label an object attribute via @Resource and still > annotate or flag it as optional somehow. Just a thought. Yeah; I guess the only downside is it'd involve changing semantics; the presence of @Resource currently implies mandatory injection, so maybe we should add a new annotation for optional properties? @OptionalResource? I have been musing lately about creating a little library of common annotations we can share across projects - kinda like JSR 250 extensions. Care should be taken to avoid them getting too out of control or loosing their meaning but there's a few on the wiki now... http://docs.codehaus.org/display/XB/Other+Annotations -- James ------- http://radio.weblogs.com/0112098/
