Dislike about Controller class deprecation

[camelo]

Hi All,

Well this post is only to communicate my disagreement in one of the changes made from Spring 2.5.x to Spring 3.x specifically the deprecation of traditional Controller class.

Basically I work for clients that have many Spring based applications, sometimes our clients require changes like "The url to products must change from x.html to y.html", in Spring 2.5 I only need to telnet the servers, change the url in the HandlerMapping and maybe restart the server, since all the (traditional) controller classes were deprecated in 3.0 (and will be removed in further revisions in favor to annotated controllers) this will force me to change the source code, compile and deploy each time I need to change a URL. And belive me, for my client, change a class file in a production enviroment requires a whole process that make me the things difficult.

Outside what I expose above, I have several concerns about this change:

1) I think annotations broke the object - oriented paradigm in many ways, so I use annotations only in some special cases.
2) It's ok to have both options, traditional Controller and annotated controller, so each developer can choose the best alternative according particular requirements, but I think is not cool to force the whole community to use annotated based controllers when this approach may not fit requirements in all cases. Deprecating / Removing traditional controllers is against the "choice" spirit that should be followed by any open - source framework.
3) This approach also broke one of the main Spring beliefs "JavaBeans loosely coupled through interfaces is a good model" - Where is the loosely coupled if I need to tie methods to URL patterns in the code?

Not sure why this dessition was made, but I created this thread for three reasons:

1) Express my disagreement into deprecate traditional and useful classes (In general Deprecation should be used only in favor of fixing / improving code, not changing design for existing working components). Expecting the Spring developers to rollback this dessition.
2) Look for a good explanation about why this dessition was made (other than "were deprecated in favor of annotated controllers").
3) Get opinions of other users affected by this change.

I found other threads with similar concerns:

http://forum.springsource.org/showthread.php?t=81949
http://forum.springsource.org/showthread.php?t=94398

Also I think the most elegant solution for this is to split spring-web in two different bundles: spring-web & spring-web-annotations, so each developer can import the needed package into his/her projects without adding unused class to his/her path.

Please share your toughts.

Kindly Regards.

[myzhijie]

hello everyone,i am a chinese boy.this is my first time replay at forums.my english is poor. i think this poll is very good. and i like remove.

[Enrico Pizzi]

Hi,

I voted for coexistence of both methods, because I too, think that, in an ideal world, choice is better. But in th real world, there are some problems connected:

1) Supporting both strategies for future releases, for Spring developers, means an additional burden of work. Just think that from their perspective: they have found a way that they think is better suited to do things, they could spend all their energies in exploring the potentiality of that path, but instead they must lose time and effort to continue adapting and testing a strategy that they consider old and dead. Believe me, maintaining legacy code is a true nuisance.

2) The coexistence of both strategies could bring confusion to newbies in Spring web mvc. There are examples of that in some threads in the forum which I answered personally.

So, to sum it up, I would like the Spring team to keep both strategies up and running, but I totally understand them if they don't want to and don't blame them if they won't.

Also, I have to disagree with some of your points:

Basically I work for clients that have many Spring based applications, sometimes our clients require changes like "The url to products must change from x.html to y.html", in Spring 2.5 I only need to telnet the servers, change the url in the HandlerMapping and maybe restart the server, since all the (traditional) controller classes were deprecated in 3.0 (and will be removed in further revisions in favor to annotated controllers) this will force me to change the source code, compile and deploy each time I need to change a URL. And belive me, for my client, change a class file in a production enviroment requires a whole process that make me the things difficult.

"change the url in the handler mapping" means you have to open up the war and change an xml configuration file. I don't see the difference between changing an xml or a class in the war, changing the class needs a redeploy but changing the xml needs at least a stop and restart of the application (because the Spring context is read and created at startup), so in both cases you will create disservice to your clients and in both cases you will have to switch a file in production environment.

1) I think annotations broke the object - oriented paradigm in many ways, so I use annotations only in some special cases.

not true, in fact annotations can exist only in an object oriented world and they use that paradigm to work (because they are based on reflection), so they cooperate with oo and don't disrupt it in any way.

3) This approach also broke one of the main Spring beliefs "JavaBeans loosely coupled through interfaces is a good model" - Where is the loosely coupled if I need to tie methods to URL patterns in the code?

I think you didn't understand fully the meaning of this sentence. "javabeans loosely coupled" means simple objects that have no tight coupling BETWEEN THEM. That is what dependency injection exist for: if you put a new MyObject() inside another object you don't have loose coupling but instead tight coupling, that is the meaning of it and it has nothing to do with annotations.

In general Deprecation should be used only in favor of fixing / improving code, not changing design for existing working components

not true. "Deprecated" means "this works, but I think you'd better do that. If you still want to stick to this, you can and I guarantee to that it will work, but I don't guarantee that it will be supported, or even that it will exist, in future releases". That is exactly what Spring team means to do with controllers, so I think deprecation in this case applies perfectly.

Hope I explained myself clearly.

Regards,

Enrico

[ctapobep]

"change the url in the handler mapping" means you have to open up the war and change an xml configuration file. I don't see the difference between changing an xml or a class in the war, changing the class needs a redeploy but changing the xml needs at least a stop and restart of the application (because the Spring context is read and created at startup), so in both cases you will create disservice to your clients and in both cases you will have to switch a file in production environment.

In the case of annotations you should recompile application, this impacts on spent time much more seriously.

not true, in fact annotations can exist only in an object oriented world and they use that paradigm to work (because they are based on reflection), so they cooperate with oo and don't disrupt it in any way.

Just look from another side. Let's consider Hibernate annotations, this example is much more explicit: you put the very entity and it's mapping to the database in the single class, which breaks both Open Closed Principle (OCP) and Single Responsibility Principle (SRP). If something changes in mapping, you should change class. There are some cases when I'm calm about annotations (e.g. unit testing), but people should realize what pros and cons this approach gives and not just blindly use everything that dictates fashion.
I fully agree with camelo about XML based approach though Enrico's words are truly as well. Will hope for better

[macbeth]

"The url to products must change from x.html to y.html", in Spring 2.5 I only need to telnet the servers, change the url in the HandlerMapping and maybe restart the server, since all the (traditional) controller classes were deprecated in 3.0 (and will be removed in further revisions in favor to annotated controllers) this will force me to change the source code, compile and deploy each time I need to change a URL.

You are not required to use @RequestMapping to map URL patterns to controllers. You can continue to use a HandlerMapping definition. Then use @RequestMapping to demarcate GET/POST methods. For multiaction controllers a MethodNameResolver can probably work.

I am abstaining from voting. I would prefer to see a unified and more complete web framework solution whether annotation driven or not.

The current lack of conversational support renders Spring MVC incomplete. Spring Webflow fills this void but then I am stuck using two different styles (annotations-based controllers and XML-based flow definitions).

[camelo]

"change the url in the handler mapping" means you have to open up the war and change an xml configuration file. I don't see the difference between changing an xml or a class in the war, changing the class needs a redeploy but changing the xml needs at least a stop and restart of the application (because the Spring context is read and created at startup), so in both cases you will create disservice to your clients and in both cases you will have to switch a file in production environment.
Enrico

Not if you use exploded war .

not true. "Deprecated" means "this works, but I think you'd better do that. If you still want to stick to this, you can and I guarantee to that it will work, but I don't guarantee that it will be supported, or even that it will exist, in future releases". That is exactly what Spring team means to do with controllers, so I think deprecation in this case applies perfectly.Enrico

I don't fully agree with you here, but, assuming your definition is correct, is out of the point. In 3.0 the release note explicity states that traditional controllers will be removed in further versions of spring. That's my real concern, not the deprecation itself.

Thanks for contribute!.