Could you add Maven dependency snippets?

Also, are there any updated estimates for a JavaConfig 1.0 release?

I am also curious about that. Did you evaluate the possibility of Git instead of SVN, and in that case, which were the reasons involved in your final decision?

Congratulations on the milestone release

Thanks Chris! I'm then looking forward to the final release of both

Congrats on the release Juergen!

Hi,

I haven't really gone through the source yet, but what I get from comment @Richard 's comment is that in favour of Annotations, the Controller inheritance heirarchy based approach is being deprecated.

I think this is certainly NOT the way to go. Just because the language now supports meta-data in form of annotations, it should not discard old school OO concepts altogether. Personally, I simply do not like mixing configuration with code and hence, I rarely prefer annotations. Now, a majority might not be with me on this, but certainly I would not like myself pushed towards annotations like this.

If at one glance at my config XML, I get an idea about all the controllers in my application, what's the harm? Why should I keep discovering controllers in based on convention (package-name etc.)?

Please consider these views before taking such decisions. Java 5 is great, but not every feature from it appeals to everyone, and there are some good reasons for it.

Thanks & regards,

- Aditya Jha

Can you add it to the Maven repository?

Maven?

I assume by JRuby 1.1 you mean 1.1.x, hopefully 1.1.5ish or so, right? Very excited to see JRuby support finally updated!

While I can understand that developers that are used to the inheritance based controller model are upset, I prefer the annotation based one now. It took me a while to get used to it but it dramatically increases testablity, which is a good thing. I am also quite sceptical regarding annotations, but controllers are mostly build, that no further annotations are contained in that class, so the deal is not that expensive. I can only recommend to play with it a bit.

Besides that, I very much wait for the Maven artifacts…

Regards,
Ollie

@Rossen, @Richard

Yes, they are much more elegant.
Unfortunately the @Controller approach lacks of any validation processing flow:( From my point of view is a big disadvantage. Moreover I don't like the way in which validation is currently handled. Let's consider the form submit use case. First of all we has to pass @ModelAttribute("command") and then the corresponding BindingResult object as a method parameters. The first one is necessary since it does contain business data but the second one is required only for validation purposes. Even if the command's object fields were not filled properly the method will be executed. Then we have to do validation phase by ourself (check if the strings are empty or not etc.). During action execution we are forced to choose which view has to be returned based on the validation results:( Would it be nicer to run validation just after binding but before the method execution? In case of any validation errors just return the input view (the page where user entered data).

I think something should be done in this direction. Keep up the good work.

Regards

BTW. Stripes could be a good example. There are @Validate/@DontValidate annotations that cause that the validation logic is called just before method execution.

@Rossen

I respect all efforts on making Annotations elegent and easy-to-use. My only concern is that restricting other ways doesn't seem so 'open'.

The very nature of Java has been, and still is, being 'open' and 'community-driven'. IMHO, taking stances like these somewhat undermine this basic nature. I can understand favoring one way to another, but keeping only one way of doing things (that too, by binding configuration to code) doesn't seem right.

Please note that even today, class java.lang.Vector has not been deprecated. Even methods like 'elementAt' in this class have not been deprecated. Now, if you know what I mean, going by your logic they should have been deprecated long ago. Fact is, this class and those methods do not have something inherently wrong in them. It's just that they might not be suitable for most purposes. But, if someone wants to use them in spite of considering what they offer, its perfectly fine.

IMHO, Annotations can never be a substitute for external configuration. Its not the question of getting used to another way of working, but its a question of binding configuration to code, and also of having a central repository of config artifacts as opposed to discover them by convention.

Imagine Struts classic coming up with some fancy annotations and asking 'forwards' to be annotated into Actions! I hope you understand the concern.

Frankly, this issue has the potential of stopping me from being an ernest user of latest releases from Spring portfolio. I would rather prefer v2.5 to retain configuration out of code.

Instead of actually deprecating it, you might declare that no work will be done on 'simplifying' XML-configuration any more and future focus will be only on simplifying Annotations. However, please always ensure that any 'new' features in future are also possible through XML config. I, and I'm sure many of us, can live happily with current level of so-called 'complexity' of XML configuration.

Best regards,

- Aditya Jha

To the many folks requesting that the M1 artifacts be made available via Maven, good news – they already are within the SpringSource Enterprise Bundle Repository. Just add the following to your POM files and you're good to go:

<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>org.springframework.core</artifactId>
<version>3.0.0.M1</version>
</dependency>
</dependencies>
<repositories>
<repository>
<id>SpringSource Enterprise Bundle Repository – External Bundle Milestones</id>
<url>http://repository.springsource.com/maven/bundles/milestone</url&gt;
</repository>
<repository>
<id>SpringSource Enterprise Bundle Repository – SpringSource Bundle Releases</id>
<url>http://repository.springsource.com/maven/bundles/release</url&gt;
</repository>
<repository>
<id>SpringSource Enterprise Bundle Repository – External Bundle Releases</id>
<url>http://repository.springsource.com/maven/bundles/external</url&gt;
</repository>
</repositories>

Where the above configuration depends only on org.springframework.core, you are of course free to depend on any / all of the bundles (projects). See here for a list of what's available: https://src.springframework.org/svn/spring-framework/trunk/

If you wish to pull in all the bundles at once (instead of a la carte as above), you can do so by adding one more repository

<repository>
<id>SpringSource Enterprise Bundle Repository – Library Milestones</id>
<url>http://repository.springsource.com/maven/libraries/milestone</url>·······
</repository>

and specifying the following dependency

<dependency>
<groupId>org.springframework</groupId>
<artifactId>org.springframework.spring-library</artifactId>
<type>libd</type>
<version>3.0.0.M1</version>
</dependency>

@Chris
Looks like core depends on asm, and when I view the core pom, no version is specified. It references org.springframework.parent, but I can't seem to find it. Where is the parent pom.xml located?

Anyone else using maven, I was able to figure out what version to put in to get it to work:

org.objectweb.asm
com.springsource.org.objectweb.asm
2.2.3

org.objectweb.asm
com.springsource.org.objectweb.asm.commons
2.2.3

@Juergen

@Qualifier no longer works for me. I created a ticket:
http://jira.springframework.org/browse/SPR-5355

What is the story on the maven repository when hitting the urls directly? Usually you can use a web browser and browse what the artifacts are and even look at the pom files. The names have changed from 2.5 and while many of them can be inferred from the new convention, it's not clear what all the new names are.

Can You change logging library from Jakarta Commons Logging (with its known problems and limitations) to Simple Logging Facade for Java (http://www.slf4j.org).
SLF4J is more robust and flexible than JCL.

And last
Add please Janino (http://janino.net/) to Spring Dynamic language support set (in addition to JRuby, Groovy and BeanShell).

Janino is a compiler that reads a JavaTM expression, block, class body, source file or a set of source files, and generates JavaTM bytecode that is loaded and executed directly. Janino is not intended to be a development tool, but an embedded compiler for run-time compilation purposes, e.g. expression evaluators or "server pages" engines like JSP.

Hi Mark,

Thanks for the reply. I went through the article you mentioned. And though I'm still not convinced that the Controller heirarchy should be deprecated, the article did clear out some of my concerns.

The question that still bothers me is that without using the heirarchy, will we be able to exploit the useful template methods, for example:

1) To perform some activity onBind, but before validation.
2) To decide (in a custom way) whether a request should be considered as a Form-Submit request.

and so on…

Also, I think the ease and simplicity in debugging the application (along with the source from SpringSource, taking it as one complete sequential flow) has some business value as well. This seems to be sacrificed while applying Annotations and convention-over-configuration.

I strongly feel the way to tackle complex configuration is better tooling rather than concise, but unobvious code (like C-language).

Kindly enlighten me if I'm wrong.

Best regards,

- Aditya Jha

Hello everyone,

Is there any possibility of Conversation support in Spring 3?
Jürgen gave an indication of a possibility of conversation support in presentation:

Conversation Management
• Key problem: isolating concurrent windows in same browser
– shared HTTP session
– several independent conversations going on
• Generalized: conversation scope with shorter lifetime than session
– scope="conversation"
– Spring Web Flow providing sophisticated flow navigation management on top

Pls let us know the status/availability of this important feature. Also, is there a possibility of Spring MVC and Web flow being combined into one single MVC framework in a future release?

The certificate on src.springframework.org expired on December 21st.
It is self-signed, which is another issue.

Please update the certificate, thanks.

Regards,
–
Carlo

Can someone explain why you changed the name of the maven artifacts?

What does this means? (from the readme.txt file) "Furthermore, the jar file names follow bundle repository conventions now."

If you look at the huge majority of Maven projects out there, everybody is using the same convention somehow (which is the one used in Spring 2.x artifacts).

Are you planning to setup a relocation so that users can safely upgrade from spring-beans 2.5.6 to 3.0.0 for instance?

I've seen many projects where stable modules use an old version of Spring. If you do this, the maven dependencies mechanism won't be able to resolve the version conflicts and users will get two version of Spring in their applications.

I'm going to guess the new artifact Ids in maven might be something to do with osgi. I think their bundles had notation like that.

juergen, ur a genius! as a developer, u make our life easier..

http://www.mmogstop.com is the leading provider of World of Warcraft Gold, FFXI Gil, RS Gold,EverQuest Platinum, Aion Kinah and EQ2 Plat. Buy WoW Gold cheap,…