Re: [Springframework-developer] [Springframework-user] Annotation-based Spring Configuration

[Chris N. <C.N...@AB...>]

Thanks for the reply. You are the only one so far, which I think answers
my question to the demand for such a feature...

I'm not religious about this subject - there are various alternative
ways of configuring Spring these days and each have their pros and cons.
I discussed this very briefly with Alef and Arjen after their JavaPolis
talk - they were unable to offer a solution to code and configuration
getting out of synch (but suggested we added extra tests to our
testsuite).

Our experience with the team repeatedly getting code and Spring
configuration out of synch (at which point Spring won't even start up
and no other developer can do any work) points to the principle of DRY
(don't repeat yourself) being a valuable one. My opinion is that having
separate POJO code and XML configuration *is* repeating yourself,
however that seems to be a minority opinion!

My prototyped solution allows use of user-defined annotations, in which
case no dependency on Spring code is introduced. In principle such POJOs
could be ported to an alternative IoC container without any changes, if
it could also understand the user-defined annotations as well.

I also try to be pragmatic about how truly "portable" POJOs are, and how
useful it is that they are portable. Using IoC features (e.g. setter
injection) ties the code to the subset of IoC containers that support
those features, even if Spring-specific APIs aren't being called. If
Spring MVC or Spring Transaction Annotations are being used, then
obviously that is a dependency on Spring. If you wanted to move from
Spring to an alternative IoC container, or to a completely different
approach (e.g. EJB 3), you are bound to have to review all the code and
change a substantial portion of it.=20

As an Architect I think in layers, so I think it's much more important
to prevent hide the internal implementation details of one layer from
other layers than it is to isolate implementation details inside a
layer. My experience tells me that it is much more common to
re-implement a layer (e.g. moving from JSP to JSF, or iBATIS to
Hibernate) than it is to move an entire application away from Spring. I
welcome any feedback from anyone else that has experience of regularly
porting applications between different POJO frameworks?

We currently use Spring 1.x, Java 1.4 and XDoclet with our own
sub-classed Jakarta Commons Attributes (so no Spring API dependency) for
Transaction demarcation, and our own utility class for obscure
situations where we have to do an explicit dependency lookup (again
hiding the Spring APIs). We put as much Spring configuration as possible
in XDoclet annotations, so our XML configuration just contains:

- "infrastructure" beans (e.g. MVC configuration, DataSources etc)
- abstract beans (e.g. common configuration for all our iBATIS DAOs)
- anything with complex configuration that can't be expressed in XDoclet
(e.g. we have a complex XML processing pipeline with various lists of
lists of beans)

Our experience is that the XDoclet-based configuration is based on our
application's functionality and never tends to change, whereas the XML
configuration is the "plumbing" that does tend to change over time.=20

Chris.

-----Original Message-----
From: Axel Wienberg [mailto:axe...@go...]=20
Sent: 31 January 2007 07:40
To: Chris Nappin
Subject: Re: [Springframework-user] Annotation-based Spring
Configuration

There doesn't seem to be much discussion going on on the list, so I'll
try direct email :-)

My understanding so far is that beans (Java source) should be
reusable, and the spring config defines the wiring. Annotations seem
to mix up this distinction - how would you instantiate the same class
(java source) twice, with different property settings?

For bean properties like initMethod and destroyMethod, if you are
willing to edit your source file, you might as well implement
InitializableBean and DisposableBean. You'll have a spring dependency
either way (annotations can be ignored, but your application will not
work if the annotations are not interpreted).

We're currently using the IDE to connect XML config and Java code - in
IntelliJ Idea, "find usages" on a class will also find occurrences in
a spring XML file, and likewise for property setters, and conversely
for "goto definition".

It could be that your Controller code is very application specific
anyway, so reusability in other configurations is not an issue. Is
that so? I'd be curious to learn when you feel the wiring should be
integrated into the code.

Regards,
Axel

2007/1/30, Chris Nappin <C.N...@ab...>:
> I've been working on an Annotation-based Spring Configuration solution
which
> I'd be happy to donate to the Spring project, so I wanted to determine
> whether there is any interest?
>
>  Such initiatives seem to have received a cool reception in the past,
e.g.
>
http://opensource.atlassian.com/projects/spring/browse/SPR-1987?page=3Dal=
l
.
>
>  I'm an Architect working with a mainly junior development team, and
when we
> first started using Spring we quickly came across the problem of
keeping the
> XML configuration files in step with the code. As we were already
using
> XDoclet for J2EE configuration, we moved to using that for Spring
> configuration as well. It has served us as a very good solution for a
couple
> of years now.
>
>  We're now looking to move to Spring 2.x and Java 5, and it makes
great
> sense for us to use type-safe Annotations instead of XDoclet (which
seems to
> be a dying project). I've put together a prototype that allows for
custom
> (e.g. user-defined) annotations to be used (so no dependency on Spring
code
> is introduced to the POJOs). The default annotations work as follows:
>
>  @Bean(id=3D"createNewPerson")
>  @BaseProperties({
>      @Property(name=3D"formView", value=3D"createPerson"),
>      @Property(name=3D"successView", value=3D"createSucceeded")
>
> })
>  public class CreateNewPersonController extends SimpleFormController {
>
>      @Property(ref=3D"personService")
>      public void setPersonService(PersonService service) {
>          ...
>      }
>  }
>
>  Properties can be configured by annotating the setter method,
base-class
> properties can be added to the class declaration, and so on. I'm
working on
> fleshing out support for all Spring features. I'd be happy for the
shape of
> these default annotations to be further discussed.
>
>  All this is enabled via adding one class (a BeanFactoryPostProcessor)
to
> the XML configuration. XML and Annotation-based configuration can be
mixed
> without restriction - typically just the abtract and "plumbing" bean
> configuration is required in XML.
>
>  Please let me know if this is of interest. I would imagine it would
be a
> useful feature for all existing XDoclet users?
>
>
>
> (PS. All code has been written on my own time and has no relation with
my
> employer)
>
>
>
> Chris Nappin.
>
>
>
> CONFIDENTIALITY NOTICE
>
> This e-mail is confidential to the addressee. It may also be
privileged.
> Neither the confidentiality nor any privilege attaching to this e-mail
is
> waived lost or destroyed by reason that it has been mistakenly
transmitted
> to a person or entity other than the addressee. If you are not the
addressee
> please notify us immediately by telephone or fax at the numbers
provided
> above or e-mail by Reply To Author and return the printed e-mail to us
by
> post at our expense. We believe, but do not warrant, that this e-mail
and
> any attachments are virus-free, but you should check. We may monitor
traffic
> data of both business and personal e-mails. We are not liable for any
> opinions expressed by the sender where this is a non-business e-mail.
If you
> do not receive all the message, or if you have difficulty with the
> transmission, please telephone us immediately.
>
> ABM United Kingdom Ltd
>
> Registered in England & Wales, number 03319098
>
> Registered Office: Peterbridge House, 3 The Lakes, Northampton, UK.
NN4 &HB
>
> ABM America Inc
>
> Registered in Delaware, number 03174068
>
> Registered Office: 1220 N Market Street, Wilmington, Delaware, USA.
19801
>
>
>
------------------------------------------------------------------------
-
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
share your
> opinions on IT & business topics through brief surveys - and earn cash
>
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDE
V
>
> _______________________________________________
> Springframework-user mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-user
>
>
>


CONFIDENTIALITY NOTICE

This e-mail is confidential to the addressee. It may also be privileged. =
Neither the confidentiality nor any privilege attaching to this e-mail is=
=20waived lost or destroyed by reason that it has been mistakenly transmi=
tted to a person or entity other than the addressee. If you are not the a=
ddressee please notify us immediately by telephone or fax at the numbers =
provided above or e-mail by Reply To Author and return the printed e-mail=
=20to us by post at our expense. We believe, but do not warrant, that thi=
s e-mail and any attachments are virus-free, but you should check. We may=
=20monitor traffic data of both business and personal e-mails. We are not=
=20liable for any opinions expressed by the sender where this is a non-bu=
siness e-mail. If you do not receive all the message, or if you have diff=
iculty with the transmission, please telephone us immediately.
ABM United Kingdom Ltd
Registered in England & Wales, number 03319098
Registered Office: Peterbridge House, 3 The Lakes, Northampton, UK. NN4 &=
HB
ABM America Inc
Registered in Delaware, number 03174068
Registered Office: 1220 N Market Street, Wilmington, Delaware, USA. 19801=