Re: [Springframework-developer] Annotations

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

The problem with dependency injection annotations is that you're coding some
level of symbolic name into your Java classes: either JNDI names or logical
names from some container's namespace. Neither of the two belongs in there,
as it introduces a logical dependency on a naming system that really
shouldn't be of any concern to the implementation class.

Keep in mind that you will have to define your service implementation
classes in some configuration file anyway: How else would the container know
which component implementation classes to instantiate and under which names
to expose? Arguably, references between those components belong into that
same file, as they're expressed at the same level - named components.

Configuration properties (booleans, ints, Strings) belong into such a
configuration file as well. After all, the very point of a configuration
bean property is to allow specifying values in configuration files: Default
values can be defined by the bean implementation class itself anyway. Hence,
no need for annotations for such configuration properties - they would be
completely pointless.

If you define your service implementation classes in a Spring bean
definition file, maybe with some configuration properties, and want to keep
the definition of explicit references to a minimum, why not use autowiring?
In terms of separation of concerns, this is much cleaner than polluting your
implementation classes with configuration annotations that point to concrete
bean names in a specific namespace.

Regarding JNDI names: You will typically only have very few JNDI names in an
application, even in a large one, so it's hardly a concern to define them in
such a configuration file and let your application classes only deal with
the type of object that they want to talk to. Wiring a JNDI-located
DataSource into bean properties of type DataSource is hardly a major burden,
even if done explicitly. And JNDI names do tend to change on a
per-deployment basis, from server to server: Would you really want to have
multiple versions of your class sources, just for different JNDI names?

A JNDI lookup annotation like EJB3's Inject simply doesn't add any value
other than syntactic sugar: In all other respects, this is hardly different
from hardcoding a programmatic JNDI lookup (to be executed when no explicit
reference has been passed into your object). Externalized JNDI names in a
configuration file, on the other hand, separate such configuration
information from implementation classes: allowing to adapt the concrete JNDI
names names on a per-deployment basis (while that need doesn't arise often,
it does arise, even if you don't anticipate it).

As a concrete example for some further added value of a configuration file,
consider a JNDI-located DataSource that you need to proxy, for example to
seamlessly inject specific default user credentials (needed when you can't
control the JNDI DataSource's default credentials; see Spring's
UserCredentialsDataSourceAdapter). This is straightforward in a Spring bean
definition file, with your application objects simply getting wired to that
DataSource proxy rather than the raw JNDI DataSource. With JNDI lookups
hard-coded into your DAOs, you'd lose that flexibility.

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Janne Kario
Sent: Saturday, August 06, 2005 5:32 PM
To: spr...@li...
Subject: [Springframework-developer] Re: Annotations

Mark St Godard wrote:
> 
> 
> 
> Speaking as a non-Spring developer....(i.e. wait for Rod, Juergen, etc..
> comments)...
> 
> Is this something that you really want?   There are valid uses of
> Annotations...(i.e. transactions, security)...
> but I dont think its a good idea to use it for everything (i.e.  IoC)
> 
> EJB3 is annotation-"crazy"... for lack of a better word.... I still 
> really do not think @Inject is appropriate.

Inject is probably one of the things I'm looking for. That is being able to
do the assembly level stuff using annotations. The reason that we have the
XML configuration file is because we can change assembly level things easily
(right?). However, this can just as easily be achieved using annotations
which retain code locality. Majority of applications are pretty static in
nature and there's no need to change the assembly stuff once the app if
finished. And if you do need to change something you need to tear open the
WAR archive anyways which is not far from doing a full recompile.

> I still think there will be some sort of level of configuration that 
> you cannot get away from.

Ofcourse.

* Janne Kario



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile &
Plan-Driven Development * Managing Projects & Teams * Testing & QA Security
* Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer