Thread: [Springframework-developer] Annotations

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

What is the level of annotation support that we are going to see in the 
future for Spring? Can we achieve a level where no XML configuration 
files are needed?

* Janne Kario

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.

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

Rod, Juergen... comments, thoughts?

Cheers,
Mark

             Janne Kario                                                   
             <ka...@me...>                                             
             Sent by:                                                   To 
             springframework-d         spr...@li... 
             eveloper-admin@li         rceforge.net                        
             sts.sourceforge.n                                          cc 
             et                                                            
                                                                   Subject 
                                       [Springframework-developer]         
             08/06/2005 07:50          Annotations                         
             AM                                                            

             Please respond to                                             
             springframework-d                                             
                 eveloper                                                  

What is the level of annotation support that we are going to see in the
future for Spring? Can we achieve a level where no XML configuration
files are needed?

* 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

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

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

Hi ya,

>> 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.

It is an interesting topic. Annotations are highly interesting stuff. But
I dont know if the 'Annotation for everything' speech will hold in the
future. But it is still amazing how far you can push things with
annotations (beside the @SupressWarning and @Override annotations
of cause (I dislike them)).

There is also something like a counter-movement  going on. Skip
all the xml / IOC things and go for the hot cake first. For example
Tapestry, Trails and Rails mostly favour annotations instead of
xml files or even hard-wire the application within the code.

I find hard-wiring it, is the least preferable to do. But it is all
we always do. I always fail by getting where the border is. You
know methods are hardwired, some objects are hard-wired.
For the next granularity level (moduls being formed by
collaborating objects) I would clearly favour annotations. And
on application level, I strongly tend to favour xml.

The fun part is, that by having a complete annotation support,
it would be more relaxing for find the best way to wire everthing
together.

Level     -> Type
Objects / Classes -> hard-wired
Packages/Modules/Layers -> hard + soft (Annotations mainly)
Layers / Application -> soft (XML + Annotation)

Where to apply which kind of wiring depends on the
requirements. But as nearly always, the test-cases are your
saviour in the storm here. I - for example - mostly push
everything from hard-wired to soft to ease my test-cases. That's all.

Using Spring I mostly go for either hard-wired or xml. I would
like to go for complete annotations first.

And about the introducing the logical names stuff to the code, I don't
buy this one fully. I guess I know what the implications are but
it is like the property names. Having a get/setPropertyName method
introduces the logical name propertyName of the property (which
can even be virtual (logical)). So for wiring we mostly end up with
the class DomainModelService implicating the logical name
domainModelService for a service object.

So I think a annotation with that smart thinking, which works
by referring Classes rather than logical names (or better being
able to derieve the names from the class name) would be nice.
But I truely lack knowledge and experience here. It is
just what I feel would ease everyday's pain overhere... .

So I really would appreciate a near to complete annotation support
being able to substitute nearly all the xml-beans definition file(s)
(as best as possible).

Cheers,

Martin (Kersten)

>
>> 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 

On the property name -> bean name topic: This is exactly what autowiring by
name does. Why do we need annotations for that? An annotation on bean
properties that says "I want to be wired with a bean of the same name as the
property" isn't really different from autowiring that bean by name.
Autowiring can even be specified at the <beans> level and by default simply
skips properties that it can't find a matching bean for, so annotations
aren't even more concise.

I strongly believe that putting arbitrary, concrete target bean names into
annotations is a bad idea. Expressing a dependency through the property name
and the service interface of the dependent bean should be perfectly
sufficient: This allows for autowiring by name respectively type. And of
course, there's always the option to explicitly specify the target bean name
in configuration, in particular for cases where autowiring would be
ambiguous.

Juergen

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Martin Kersten
Sent: Monday, August 08, 2005 2:55 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: Annotations

Hi ya,

>> 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.

It is an interesting topic. Annotations are highly interesting stuff. But I
dont know if the 'Annotation for everything' speech will hold in the future.
But it is still amazing how far you can push things with annotations (beside
the @SupressWarning and @Override annotations of cause (I dislike them)).

There is also something like a counter-movement  going on. Skip all the xml
/ IOC things and go for the hot cake first. For example Tapestry, Trails and
Rails mostly favour annotations instead of xml files or even hard-wire the
application within the code.

I find hard-wiring it, is the least preferable to do. But it is all we
always do. I always fail by getting where the border is. You know methods
are hardwired, some objects are hard-wired.
For the next granularity level (moduls being formed by collaborating
objects) I would clearly favour annotations. And on application level, I
strongly tend to favour xml.

The fun part is, that by having a complete annotation support, it would be
more relaxing for find the best way to wire everthing together.

Level     -> Type
Objects / Classes -> hard-wired
Packages/Modules/Layers -> hard + soft (Annotations mainly) Layers /
Application -> soft (XML + Annotation)

Where to apply which kind of wiring depends on the requirements. But as
nearly always, the test-cases are your saviour in the storm here. I - for
example - mostly push everything from hard-wired to soft to ease my
test-cases. That's all.

Using Spring I mostly go for either hard-wired or xml. I would like to go
for complete annotations first.

And about the introducing the logical names stuff to the code, I don't buy
this one fully. I guess I know what the implications are but it is like the
property names. Having a get/setPropertyName method introduces the logical
name propertyName of the property (which can even be virtual (logical)). So
for wiring we mostly end up with the class DomainModelService implicating
the logical name domainModelService for a service object.

So I think a annotation with that smart thinking, which works by referring
Classes rather than logical names (or better being able to derieve the names
from the class name) would be nice.
But I truely lack knowledge and experience here. It is just what I feel
would ease everyday's pain overhere... .

So I really would appreciate a near to complete annotation support being
able to substitute nearly all the xml-beans definition file(s) (as best as
possible).

Cheers,

Martin (Kersten)

>
>> 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

-------------------------------------------------------
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