RE: [Springframework-developer] Annotation to validate required bean attributes

[Keith D. <ke...@in...>]

The problem with relying on afterPropertiesSet() is it's easy to forget =
to
call it from Java code; constructor initialization is just so much safer =
and
more elegant _most of the time_.  And in a system with a nicely =
partitioned
set of roles, the number of constructor args to fulfill for a given bean
typically stays small (say 1 or 2).

I fully agree the body of afterPropertiesSet init method is a great =
place to
go to see what "pre use" checks are made -- and these checks may contain
more complex logic.

So I think use of constructor based initialization for required
collaborators delegating to an init callback for more complex pre-use =
checks
really is the ideal situation.  I personally think people should avoid =
use
of default constructors where possible.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Juergen Hoeller
Sent: Sunday, June 19, 2005 8:41 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Annotation to validate required
bean attributes

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_id=16492&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
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_id=3D7477&alloc_id=3D16492&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer