I judge it to be a best practice based on my personal experience and
the experience of my peers who have tried both approaches in their
projects, but I do think that Spring rubber-stamping it is good
validation of the approach. Their recommendation doesn't seem to have
anything to do with support contracts, but rather seems based in their
real-world experience working with clients and what they have found
works best.
Things like data sources, session factories, etc. are part of your
contextual environment and make sense to be configured in XML
differently for different environments. However, application code
rarely changes in different environments, so it makes more sense to
just annotate this. It also makes your code more readable, since the
stereotype annotations used by Spring help to self-document the
purpose of code, what is expected to be injected by the container,
what methods run after initialization, etc.
Jeremy
On Mar 11, 2009, at 1:52 PM, Les Hazlewood wrote:
That's fine, but that's not what they've said for a long time.
They're
changing their position. Rod has held for a long time that keeping
your
_source_ decoupled from container/integration APIs was the ideal.
Interesting to see the winds change. Don't you find it convenient
that they
can change 'best practices' now that they have support contracts and a
product to sell?
I love Spring more than any other DI mechanism out there, so don't
get me
wrong. I very well may use annotations moving to 3.0. I just don't
take it
as an industry best practice because SpringSource has rubber stamped
it.
I would like to find out how to do the changes I speak of without
re-building the project. If they have tricks up their sleeve for
that, let
me know! If you can ask that at DevNexus, that'd be awesome :)
On Wed, Mar 11, 2009 at 1:29 PM, Jeremy Haile <[email protected]>
wrote:
I don't have time to do a point-by-point response to this at the
moment,
but I'm currently at the DevNexus conference in Atlanta. I was
just talking
to Keith Donald of SpringSource and watching his presentation, and
he spent
considerable time talking about how they view annotations as the best
practice when using Spring. From Spring 3.0 going forward,
annotations will
be the best practice and will be communicated as such in their
documentation. There are definitely ways to work around the
concerns you
brought up, such as configuring your application differently in
different
contexts. If you want, I can try to do a point-by-point analysis
later, but
the SpringSource guys know their stuff and are very clear that
annotations
are the best practice.
On Mar 11, 2009, at 11:10 AM, Les Hazlewood wrote:
Yeah, I didn't mean the example per se, but you had mentioned best
(or
maybe
just current) practices before.
Of course annotations clean up xml significantly, but I'm not so
sure that
they are a 'best practice'. It is convenient for many, sure, but
it has
downsides that might preclude it from being used.
For example, I encountered something just 2 days ago that required a
configuration change from something that was running in a publicly
available
beta environment. We were stuck for time and we couldn't re-build
the
project. We were able to go in, change a config file, restart
Tomcat, and
the stake holder was quite happy. We couldn't have done that with
annotations.
And there is another thing about annotations that I'm not too keen
on -
the
required mix of XML and Annotations. For large projects, some of
your
beans
can be annotation configured, while many others cannot (Hibernate
session
factory, connection pool, 'frameworky' proxy stuff, prototype scoped
beans,
etc). Then you'll have to hunt down which objects are configured
in one
way
vs another. I like consistency, especially when 20+ developers
have their
hands in the mix.
I honestly haven't made up my mind about this issue. I like the
cleanliness
of annotations, but I wonder what would happen if dynamic
configuration
would be required in a pinch. That it saved my team's arse only 2
days
ago
leads me to believe it might happen again, and having that in my
back
pocket
is really comforting...
On Wed, Mar 11, 2009 at 10:28 AM, Jeremy Haile <[email protected]>
wrote:
I think using annotations to configure Spring singletons is very
nice -
it
minimizes XML while still allowing you to configure things in XML
when
desired. This seems to be the trend in Spring usage as well, as
Spring
3.0
will be very focused on the annotation configuration support - in
fact
Spring MVC will be deprecating all XML configuration of
controllers in
favor
of annotations.
Look how simple the Spring XML files are in the project. I think
it's
nice
to have an example app that shows off the latest Spring
technology as
well.
I think it's debatable as to whether annotations "couple" you to
Spring -
obviously the JAR file is required, but there's no reason I
couldn't
dependency inject them using some other framework. Spring won't
even
create
these singletons unless I tell it to in the XML file using the
context:component-scan tag, so they can be configured differently
in a
"unit
test" context, etc.. That being said, I'm not worried about it
being
"coupled to Spring" since it is the spring-hibernate example.
Jeremy
On Mar 9, 2009, at 10:09 AM, Les Hazlewood wrote:
Hi Jeremy,
Why did you decide to use Spring Annotations to wire your objects
instead
of
autowiring? Now most of the business objects/DAOs in the sample
app are
coupled to Spring's API. I'm curious as to why you went down that
road...
Les
