There's a lot of jargon in your explanation below. For example,
"collect distributed configurations". Not sure what that exactly
means though I have some hunches. Could you restate what you've said
for those of us who are not Guice or Tapestry users?
Regards,
Alan
On Mar 11, 2009, at 12:27 PM, Kalle Korhonen wrote:
Yes, for single types using @Autowired in case of annotations, but
still
missing being able to collect distributed configurations. In
essence, this
is how the the ki/tapestry integration library I'm working on is
meant to be
used; the library configures some defaults and users of the
integration
library can add their own; they'll all be collected and injected to
the
constructor of the same security service. But this is getting off-
topic.
Kalle
On Wed, Mar 11, 2009 at 11:43 AM, Les Hazlewood
<[email protected]>wrote:
I'm not sure what you mean by that Kalle - Spring supports type and
constructor-based wiring...
On Wed, Mar 11, 2009 at 1:55 PM, Kalle Korhonen
<[email protected]>wrote:
Annotations can make Spring easier, but please don't assume Spring
is the
best it can be. Until you've used Guice or tapestry-ioc you won't
know
how
much simpler IoCs and autowiring can still be with type and
constructor-based injection.
Kalle
On Wed, Mar 11, 2009 at 10:29 AM, 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
