Spring in Action: A Question

[Joe San]

I have read the older version of this book and I really enjoyed reading it. Though I was not able to read it cover to cover, I got to understand the basics from this book. Apart from the Spring version that this book covers, how different is this book from the older version?

[visu nallamaru]

HI ..Every One

Even i had the earlier version , but i found the terminology/concept used in example code snippets , was little confusing .But its just my feeling.

So now this "Spring in Action " differs the way it explains the things or its just a book to cover and include latest develpoments along with existing features of the Spring frame work ???.

THanks in Advance
Visu

[Padmarag Lokhande]

Same here. I had read the earlier version in which the configuration was done in XML.
The new Annotation based configuration should be interesting to understand.

[Joe San]

Padmarag Lokhande wrote:The new Annotation based configuration should be interesting to understand.

And tie your source code to Spring.

[Craig Walls]

Joe Harry wrote:

Padmarag Lokhande wrote:The new Annotation based configuration should be interesting to understand.

And tie your source code to Spring.

Nope...doesn't have to tie your code to Spring.

If you use @Component and @Autowired to automatically configure your beans, then yes...you've tied your code to Spring. (Which, BTW, I don't think is that horrible of a thing...but nonetheless.)

But instead of using @Component and @Autowired, you choose to use @Named and @Inject from JSR-330, then your beans can be wired up in Spring, Guice, or (I think) Picocontainer.

[Mark Spritzler]

Another thing to note about those Annotations, your are tying Spring is only at compile time where you need the definition of the annotation in your classpath to compile.

But you don't need anything at runtime in your classpath if you want it to ignore them. If you want something to act on those annotations at runtime, that is when you need the classes from Spring that act on those annotations.

This is the same with any annotation from anyone.

Mark

[Joe San]

Mark Spritzler wrote:Another thing to note about those Annotations, your are tying Spring is only at compile time where you need the definition of the annotation in your classpath to compile.

But you don't need anything at runtime in your classpath if you want it to ignore them. If you want something to act on those annotations at runtime, that is when you need the classes from Spring that act on those annotations.

This is the same with any annotation from anyone.

Mark

What are you trying to say here? It is obvious that if the Anotations are not found in the Classpath and if you have used any one of those Annotations, then you will end up with compilation failures. Annotations are just another type.

[Mark Spritzler]

Joe Harry wrote:

Mark Spritzler wrote:Another thing to note about those Annotations, your are tying Spring is only at compile time where you need the definition of the annotation in your classpath to compile.

But you don't need anything at runtime in your classpath if you want it to ignore them. If you want something to act on those annotations at runtime, that is when you need the classes from Spring that act on those annotations.

This is the same with any annotation from anyone.

Mark

What are you trying to say here? It is obvious that if the Anotations are not found in the Classpath and if you have used any one of those Annotations, then you will end up with compilation failures. Annotations are just another type.

Exactly. But it doesn't throw an exception at runtime if the definition of the Annotation is not found in the classpath at runtime.

Mark