We Keep Coding

How to access spring mvc properties value in websocket onopen event?

I am using spring mvc + websocket. I have created application.properties to store configuration data of project. Now I want to use that properties values in websockets #onOpent() event. I am able to access those properties in simple rest controller #RequestMapping() but unfortunately I am not able to access those properties in in websockets #onOpent() event, I am getting null value for the same. How can I achieve this?

This happens because Websocket server class in not spring component.
you can mark websocket handler class as component using #Component annotation on class. Then you will be able to access properties.
Hope this helps you.

Seems like you are using Java websockets. you can use spring 4 websockets here is sample

JSF with Spring Controllors

I am new to Spring and JSF,and I want to integrate JSF for the front end, and use Spring controller. Can Anyone give me a explanation or an example how this can be done?. Basically what I want is a form submission (which will create a Business object and feed it to the database) and navigate using controllers.
The required xml files ? and its element?
A Basic form( ex: Like a User registration )
Spring class with #Controller, and #RequestMapping etc.
I just want to know how the form submission works and the flow of that.

If you want to integrate Spring with JSF you don't need to use #Controller and #RequestMapping, those are for SpringMVC. JSF itself has navigation mechanism use that.
If you need example check Integrate Spring into JSF 2

Dynamically extend Spring MVC powered REST api with access to application jar only

I am in a situation where I have a nascent rest api architecture where each method has tons of ceremony (validation, db connection acquisition/release, authentication), raw request/response objects as the parameters, and hard-coded json strings as the output. I want to use spring mvc to help with at least some of these issues (auth & db stuff i'll need to hold off on). This would render a lot of the current architecture unnecessary. This is pretty easy except for one feature of the current architecture: dynamically adding api calls.
The entry point (servlet) for the architecture reads from an xml file that contains the path for a request and a corresponding class to load. The class must implement an interface that contains an 'execute' method which has the logic for the request. The servlet calls this execute method after loading the class. This allows dynamic extension of the api as follows. The app is packaged as a jar together with the associated config (xml) files and given to a client. The client includes this jar in his project, creates a class that implements the aforementioned interface, and adds a mapping from request url to that class in the included xml file. He then runs the app and gets access to both the original api and his custom api.
Example:
Client is given app.war, interface.jar and custom-mappings.xml. app.war contains the implementation of the core api (rest webservice), and interface.jar exposes the interface BaseController that has the method 'execute' (app.jar also uses this interface in its controller). Client then defines his own class as follows.
package custapi.controllers;
public class ExtendedController implements BaseController {
public void execute(HttpServletRequest request, HttpServletResponse response) {
// LOGIC
}
}
He compiles this class and adds it to app.war. Next, he updates custom-mappings.xml with the following entry.
/custcall/mycall
custapi.controllers.ExtendedController
He then deploys the app. The controller provided with the core api receives the request /custcall/mycall, looks it up in custom-mappings.xml, finds the class is custapi.controllers.ExtendedController, loads that class, and finally runs its 'execute' method. This allows the logic defined by the client to be run.
Ideal:
Current architecture is replaced with spring-mvc. That is, there is no more 'super' controller that parses requests and delegates to the appropriate class and, finally, method. Spring handles this. For the app that uses this new architecture, the client would receive the app.war and the spring mvc deps that expose controller annotations. The client would then create a new spring mvc controller (taking advantage of validation, parameter -> pojo mapping, object -> json conversion), compile it, and add the resulting class file to app.war. His controller would then become an extension to the core api exposed by the app. When the app is deployed, he would be able to make a request /custcall/mycall like before and have it execute the logic he defined. This ideal scenario allows clean code for the core api (which I and others programmed) and an extended api. (A downside to this approach is that the client is tied to spring. In an even more ideal scenario, the client would use framework-agnostic annotations which are mapped to spring annotations by the app. I'm not sure how easy this would be.)
I'm not sure how the above would be realized with a spring-aware controller without sacrificing the benefits of spring. I don't believe the client could simply define another spring-aware controller (correct me if I'm wrong on this). The only solution I can think of is to have a spring-aware controller that has a wildcard path (e.g., /cust_rest/*) which acts exactly the same as the current controller. The client would not get any advantages that spring has to offer, but the core api would be a lot cleaner. I was hoping there was a better solution, however. Ideally the client would get the benefits of spring without having access to the core api source code. Any ideas on this, or is my solution the best that can be hoped for?
Thanks.
(NOTE: For both scenarios, I am only guessing how the client actually gains access to the dependencies/interfaces and deploys. I have only had access to the core api project for one day, and so my understanding of it is not complete.)
Related: Runtime loading of Controllers for Spring MVC and dynamically mapping requests/URLs
The above question looks pretty similar to mine. Replies are sparse (second one is just off topic, I believe).

Provided you setup classpath scanning properly there's no need for interface. Your clients can just annotate classes with #Controller #RequestMapping("/foo/bar"). Even if this class is located in its own jar it will still be scanned. If this is a REST service consider using #RestController instead to avoid having to place #ResponseBody on each handler method.
Use spring security to do declarative authentication & authorization (what you're doing now is programmatic security)

url-action mapping & routing in Spring MVC 3.0

I'm developing a web application using Spring MVC 3.0 and looking for a ready-made solution, if any, or a "best practices" reference for a url/action mapping and routing system that can achieve the following:
REST-friendly controller / method name to view mapping. The current mapping implementation translates the request to a view name, which may be problematic when using several parameters and is incompatible with REST urls
A service that accepts the name of a controller, a method and arguments values and renders the URL that's represented by them
Integration with Spring Security that can allow me to check for a given URL whether the current user is allowed to access it, so that I can decide whether or not to render a URL
A menuing system based on the above that can define menues composed of these actions and render them to page
Basically what I need is the ability to define URLs in one centralized place, so that changing a URL (during development; I'm aware of the don't-change-live-urls idea :) ) does not mean looking up and changing that URL in a zillion pages.
Any directions to such an existing solution / tutorial / guide would be great.
Thanjs

This is a feature I really miss in Spring MVC.
That's why I created the springmcv-router project, basically a port of PlayFramework's Router implementation in Spring MVC (HandlerMapping + HandlerAdapter).
I'm heavily using it in several real-world projects and the Router implementation itself is reliable.

Try using Spring Roo. It utilizes many best practices for spring MVC, and it has a scaffolding feature that automatically maintains a menu, jsp's and all the CRUD methods of a controller.
Setting up Spring Security with Roo is as simple as typing "security setup".
Hope this is helpful.

Spring 3 JSON with MVC

Is there a way to build Spring Web calls that consume and produce application/json formatted requests and responses respectively?
Maybe this isn't Spring MVC, I'm not sure. I'm looking for Spring libraries that behave in a similar fashion to Jersey/JSON. The best case would be if there was an annotation that I could add to the Controller classes that would turn them into JSON service calls.
A tutorial showing how to build Spring Web Services with JSON would be great.
EDIT: I'm looking for an annotation based approach (similar to Jersey).
EDIT2: Like Jersey, I am looking for REST support (POST,GET,DELETE,PUT).
EDIT3: Most preferably, this will be the pom.xml entries and some information on using the spring-js with jackson Spring native version of things.

In case other ppl get here later:
http://blog.springsource.com/2010/01/25/ajax-simplifications-in-spring-3-0/
was the most useful link for me. That finally made me understand the model (after less than a day of searching).

You can certainly have controllers that return a View which is in JSON output. Take a look at the Spring-JSON project.
To consume requests in JSON I would assume you would just want a controller to pass a request parameter off to a JSON library which could parse the data?

There is no pre-packaged way to do what you want as Jersey is nicely integrated with Spring via the Jersey-Spring API so there's really no reason to re-invent the wheel.

Check this one out
Adding support for JSON and XML views
Source code for Spring Finance Manager

Since spring-mvc 3.0 official support for Ajax remoting with JSON is provided as part of Spring MVC. This includes support for generating JSON responses and binding JSON requests using the Spring MVC #Controller programming model.
see here

This feature is now part of Spring since version 3.0. You can simply use the #ResponseBody annotation to specify that you want the return value from your request handler methods to be serialized to JSON and sent as the response body. See http://blog.springsource.com/2010/01/25/ajax-simplifications-in-spring-3-0/

It seems that DWR framework looks very close to what you want to get.

You can configure Spring MVC interceptors through handler mappings and then use the mappings to transform the returning data to JSON. The handler configuration can be done in xml (no need to recompile), and this can be completely transparent to the rest of the application.
It's fairly easy to annotate controllers with some annotation, and then hook up the BeanFactory bootstrap process to register the controllers within some handler mapping process.
I have used this approach to transform the result from spring controllers into GWT RPC calls.
You can also use Spring AOP to intercept controller method calls and unwrap/wrap the requests from/to JSON.