springframework-developer

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

[Oliver H. <Ol...@ou...>]

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);
?=20

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.

There's also the issue of how you express more complex constraints using
annotations. From Andy's example there's this (rewritten to use Assert):

=09
Assert.true(!getBeanFactory().containsBean(getViewPrototypeBeanName()),
"View bean '" + getViewPrototypeBeanName() + "' must be a prototype
(singleton=3D\"false\").");

To express this in an annotation you'd probably have to introduce some
kind of expression language (Groovy, OGNL?) for the constraint checking
and some kind of template processor for the exception message generation
- suddenly something that was reasonably simple to do in Plain Old Java
is requiring a considerable amount of support code. I'd imagine your
annotation would look something like this:

	@@RequiredDependency("!
beanFactory.containsBean(viewPrototypeBeanName)", "View bean
'${viewPrototypeBeanName}' must be a prototype =
(singleton=3D\"false\").")

I hope I'm not giving you ideas here ;-)

Just my 2c.

Ollie

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

[Oliver H. <Ol...@ou...>]

What are the constraints you're interested in and what are you doing
with them?

Ollie

PS.  I assume you've looked at using Keith's Rules package. I have an
implementation of Rules driven using annotation in the Spring Rich
sandbox (AttributesRulesSource) (given my previous post this might
surprise you :-).=20
=20

> -----Original Message-----
> From: spr...@li...=20
> [mailto:spr...@li...]
>  On Behalf Of Andy Depue
> Sent: Friday, 17 June 2005 9:05 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Annotation to=20
> validate required bean attributes
>=20
> OK, so I've had a hidden agenda all along. :)  My main reason=20
> for wanting to annotate properties with their constraints is=20
> to provide "smart" handling of these in other areas of the=20
> application.  There are various places in my application=20
> where having knowledge of the constraints on a property can=20
> come in handy.  As it is now, this knowledge is typically=20
> coded in one lump in one method, with no way to "introspect"=20
> those constraints on a per-property basis.
>=20
>    - Andy
>=20
> On Thursday 16 June 2005 03:54 pm, Oliver Hutchison wrote:
> > Are you really saving that much using annotations to=20
> validate required=20
> > bean attributes? Since the introduction of the Assert class coding=20
> > these afterPropertiesSet constraint checks has been made really=20
> > simple. What's the difference between typing
> >
> > 	@@RequiredDependency()
> > And
> > 	Assert.notNull(property);
> > ?
> >
> > Not much. Slightly less typing is required, but by using the=20
> > annotations you introduce a set of dependencies that your=20
> POJO would=20
> > never have had before. If you're only going to be creating=20
> the object=20
> > using a bean factory this is acceptable, however if you want=20
> > instantiate these annotated objects outside of a bean=20
> factory (say in=20
> > a test) your also going to have to create all=20
> infrastructure needed to=20
> > do the required validation.
> >
> > There's also the issue of how you express more complex constraints=20
> > using annotations. From Andy's example there's this=20
> (rewritten to use Assert):
> >
> >
> >=20
> Assert.true(!getBeanFactory().containsBean(getViewPrototypeBeanName())
> > , "View bean '" + getViewPrototypeBeanName() + "' must be a=20
> prototype=20
> > (singleton=3D\"false\").");
> >
> > To express this in an annotation you'd probably have to=20
> introduce some=20
> > kind of expression language (Groovy, OGNL?) for the constraint=20
> > checking and some kind of template processor for the=20
> exception message=20
> > generation
> > - suddenly something that was reasonably simple to do in Plain Old=20
> > Java is requiring a considerable amount of support code.=20
> I'd imagine=20
> > your annotation would look something like this:
> >
> > 	@@RequiredDependency("!
> > beanFactory.containsBean(viewPrototypeBeanName)", "View bean=20
> > '${viewPrototypeBeanName}' must be a prototype=20
> > (singleton=3D\"false\").")
> >
> > I hope I'm not giving you ideas here ;-)
> >
> > Just my 2c.
> >
> > Ollie
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration=20
> Strategies from IBM. Find simple to follow Roadmaps,=20
> straightforward articles, informative Webcasts and more! Get=20
> everything you need to get up to speed, fast.=20
> 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
>=20

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

[Andy D. <an...@ma...>]

OK, so I've had a hidden agenda all along. :)  My main reason for wanting to 
annotate properties with their constraints is to provide "smart" handling of 
these in other areas of the application.  There are various places in my 
application where having knowledge of the constraints on a property can come 
in handy.  As it is now, this knowledge is typically coded in one lump in one 
method, with no way to "introspect" those constraints on a per-property 
basis.

   - Andy

On Thursday 16 June 2005 03:54 pm, Oliver Hutchison 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.
>
> There's also the issue of how you express more complex constraints using
> annotations. From Andy's example there's this (rewritten to use Assert):
>
>
> Assert.true(!getBeanFactory().containsBean(getViewPrototypeBeanName()),
> "View bean '" + getViewPrototypeBeanName() + "' must be a prototype
> (singleton=\"false\").");
>
> To express this in an annotation you'd probably have to introduce some
> kind of expression language (Groovy, OGNL?) for the constraint checking
> and some kind of template processor for the exception message generation
> - suddenly something that was reasonably simple to do in Plain Old Java
> is requiring a considerable amount of support code. I'd imagine your
> annotation would look something like this:
>
> 	@@RequiredDependency("!
> beanFactory.containsBean(viewPrototypeBeanName)", "View bean
> '${viewPrototypeBeanName}' must be a prototype (singleton=\"false\").")
>
> I hope I'm not giving you ideas here ;-)
>
> Just my 2c.
>
> Ollie

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

[Seth L. <set...@gm...>]

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
>=20
>         @@RequiredDependency()
> And
>         Assert.notNull(property);
> ?
>=20
> 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

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

[Magnus H. <ma...@fi...>]

 

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

This is the main reason why I want this too. Spring reminds me if I try to
inject something that doesn't have a setter, I want it to tell me when I
forget to inject something too.

I don't want to pollute afterPropertiesSet with these kind of things. And
even if I did, I probably would forget to add checks for some attributes at
some point. It's more easy to remember to add something at the source, with
an annotation imho.

> You bring up good points.  I don't think the annotations 
> method is perfect for all cases, but I do think it handles 

I agree. One size does not fit all.

Things like this would fit nice in a Spring Wiki Cookbook though...

/Magnus

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

[Juergen H. <ju...@in...>]

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

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

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

[Juergen H. <ju...@in...>]

Agreed on that advantage of constructor initialization: it can't be
forgotten in plain Java setup code. Of course, that difference doesn't
really matter in a container: the container won't forget to call the init
method...

Annotations for dependency checking don't help here, though. Annotations
won't be checked in plain Java setup code automatically either. And in
contrast to "afterPropertiesSet", you need external helper code to check
them explictly.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Keith Donald
Sent: Sunday, June 19, 2005 5:31 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Annotation to validate required
bean attributes


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_id492&op=ick
_______________________________________________
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=7477&alloc_id=16492&op=click
_______________________________________________
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_idt77&alloc_id492&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer