Re: [Springframework-developer] Re: Annotations

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

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