|
From: Juergen H. <ju...@in...> - 2005-06-19 12:40:55
|
Technically speaking, a container-specific annotation is just as much of a
container dependency as a container-specific callback interface. In both
cases, the corresponding container classes need to reside on the classpath
for loading your application class.
I simply see this as two different styles of validating dependencies. They
achieve exactly the same, just in different ways and with different minor
advantages/disadvantages.
One advantage of the "afterPropertiesSet" style is that it can easily be
called in a programmatic fashion, actually. Plain POJO usage of a bean does
not give you an easy way to check annotations, but you can easily call
"myBean.afterPropertiesSet" in any sort of Java code. And as mentioned
before, "afterPropertiesSet" can check arbitrarily complex relations between
the dependencies.
In any case, annotations for dependency checking should remain simple and
straightforward. Once a scripting language such as OGNL or the like creeps
into those annotations, they become very questionable. For complex checks, I
see no viable reason to replace a Java callback method with an annotation
scriptlet.
Finally, don't forget that there's also the option of declaratively
specifying an "init-method" on a Spring bean definition. This does not
impose _any_ container dependency on the object. Simply write an arbitrary
no-arg method that validates your dependencies and specify its name ("init"
or whatever) in the bean definition.
Such declarative init methods are the least intrusive you could get: no
container callback interface to be implemented, no container-specific
annotations to be compiled into the class. The disadvantage being that that
method won't be autodetected and thus needs to be specified explicitly.
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Seth Ladd
Sent: Friday, June 17, 2005 1:45 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Annotation to validate required
bean attributes
On 6/16/05, Oliver Hutchison <Ol...@ou...> wrote:
> Are you really saving that much using annotations to validate required
> bean attributes? Since the introduction of the Assert class coding these
> afterPropertiesSet constraint checks has been made really simple. What's
> the difference between typing
>
> @@RequiredDependency()
> And
> Assert.notNull(property);
> ?
>
> Not much. Slightly less typing is required, but by using the annotations
> you introduce a set of dependencies that your POJO would never have had
> before. If you're only going to be creating the object using a bean
> factory this is acceptable, however if you want instantiate these
> annotated objects outside of a bean factory (say in a test) your also
> going to have to create all infrastructure needed to do the required
> validation.
Well, that's just the issue, right? I'm not overly concerned if my
bean is created outside of the bean factory. If so, I still have to
call afterPropertiesSet() for verification.
It's not so much an issue of saving typing, it's an issue of
minimizing the need to implement container specific interfaces. For
me, I think it's less intrusive to add a few annotations for this use
case. But that's certainly a subjective opinion.
I like the ideas of attributes to help the container perform some of
my work for me. That is, I'm already asking the container to inject
my dependencies. It's logical (to me) to also ask the container to
let me know if I've misconfigured the dependencies somehow.
And of course, you can always implement afterPropertiesSet() if you
don't like the dependencies.
You bring up good points. I don't think the annotations method is
perfect for all cases, but I do think it handles much of what
afterPropertiesSet() is used for in a simple way.
Seth
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|