This follows along the same lines as my current thinking. Annotations
are great to describe canonical information that never changes from
one contextual environment to another.
To help those of us who are trying to keep up with this thread, it
might be helpful to discuss specific classes.
Regards,
Alan
On Mar 11, 2009, at 11:01 AM, Jeremy Haile wrote:
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
