While fixing all the deprecated api's when upgrading to Spring 4.3.3, I'm facing an issue with the MultiActionController class which is used in multiple locations.
Are there any alternative classes in spring which have the same functionality as MultiActionController?
As per the spring docs:
as of 4.3, in favor of annotation-driven handler methods ,we need to
follow annotation .
Are annotations the only solution or are there any other classes or workarounds?
As far as I'm aware, annotations are the only way now, unless you're willing to use the deprecated MultiActionController class.
In the javadoc for the MultiActionController class, they state that it's deprecated in favor of annotations, so logically there should be an annotation to replace (or at least mimic) the majority on methods within the class. They don't list any other alternatives or workarounds so I doubt there are any. The methods don't specify anything either.
Here is the Spring 4.3.3 framework reference which could aid you in tracking down the annotations you're looking for. Section 30.6 - Annotation-driven listener endpoints would be a good place to start.
Here is a page on Migrating to spring framework 4.x, and finally, a page on Converting a Spring Controller into a #Controller. These links should point you in the right direction.
I'm just starting using swagger following this guide, but I found out something very weird that makes no sense for me.
As far as I remember , the v2/api-docs should be used for when you have docs of the version number 2 of your API.
So, the default should be only api-docs, but for some strange reason I found that the default is v2/api-docs.
Checking the library doc I found this.
How do I override that value without later not being able to use v2? (when my API will reach a v2 but I will also want to show the legacy docs).
Or maybe my concept of using v2 is wrong? Can someone help me with this?
The /v2/api-docs URL is the default that SpringFox uses for documentation. The v2 does not refer to your API's documentation version (which can be changed in the Docket configuration), but the version of the Swagger specification being used. Take a look at the documentation here for customizing the Swagger documentation URL. In short, you need to modify an environment property to change the URL your documentation will appear at:
springfox.documentation.swagger.v2.path=/my/docs
This will change the default URL for the SpringFox Swagger documentation from /v2/api-docs to whatever you specify. To implement this, add the above property to a new or existing properties file, and then add it as a property source in your Springfox configuration class:
#PropertySource("classpath:swagger.properties")
#Configuration
public class SwaggerConfig {...}
I'm new to IOC and learning from source code of Struts2 framework currently.
Through learning, I've got some basic understanding of the framework like how ActionInvocation handlers interceptors etc.
But when I was trying to figure out the mysterious (to me at least) Dependency Injection part, I got completely lost.
The inject mechanism specified in package com.opensymphony.xwork2.inject is hard to comprehend. How exactly does the ContainerImpl.inject(Object) do all the work?
Or, where should I start in order to understand DI?
Personally I found this resource useful. For others who like to dig old, very old user guide can download Guice 1.0 User's Guide.pdf. As Dave mentioned
S2 uses an old (old!), hacked version of Guice for its DI.
So, you can use this page as a starting point for Dependency Injection with Struts2.
P.S.:
About ContainerImpl.inject(Object)
Injects dependencies into the fields and methods of an existing object.
It's not mysterious because Guice like Spring autowires a bean. Spring like Guice can use annotations to wire object dependencies.
I have a web application using spring annotations extensively. Can I switch back from spring annotations to xml configuration files? Encluding controllers,..etc. I need examples of the configuration files please.
Yes you can switch to externalize the configuration using xml's. Initially only xml's were supported by spring. You can get examples from their reference manual.
If you are looking for complete examples then www.springbyexample.org
Yes. Spring supports annotations, configuration classes and xml configuration. It was never the goal of annotations to deprecate the xml configuration, and it is still fully supported today.
At the S2G forum in Amsterdam last year, it was specifically stated that the goal remains for both approaches to be completely equivalent.
As for the details on how to do it, the documentation of Spring is very good. I suggest you start there. Check out the pet store example, and read up on ContextLoaderListener. It should get you started.
Yes, you can switch back and forth to XML and annotations. In fact, if you even need, you can use a combination of both. Additionally, depending on the type of control you are trying to extract from XML configuration, you can also use #Configuration annotations which provides a way of producing XML configuration via Java code. Keep in mind, however, that there are a few obscure configuration constructs that are not representable by any annotations and can only be done via XML files.
From what I can find online, the state of the art for Guice + Jersey integration has stagnated since 2008 when it appears both teams reached an impasse. The crux of the issue is that JAX-RS annotations perform field and method injection and this doesn't play nicely with Guice's own dependency injection.
A few examples which I've found don't go far enough to elucidate:
Iqbalyusuf's post on Jersey + Guice on Google App Engine Java suffers from a lot of boilerplate (manually getting and calling the injector). I want binding and injection should happen behind the scenes via Guice annotations.
Jonathan Curran's article Creating a RESTful service with Jersey, Guice, and JSR-250 gave me hope because it's much more current (2010), but went no further than showing how to start up a Jersey service inside of a Guice ServletModule. However, there are no examples of doing any real dependency injection. I suppose that was left as an exercise for the reader. Curran's post may in fact be the correct first step towards wiring up Guice and Jersey and so I plan on starting with that.
tantalizingly James Strachan writes:
JAX-RS works well with dependency
injection frameworks such as Spring,
Guice, GuiceyFruit or JBossMC - you
can basically pick whichever one you
prefer.
But I see no evidence that is true from a practitioner's point of view.
What I find lacking are practical examples and explanations on how to combine JAX-RS and Guice annotations. For instance:
I believe I cannot use constructor injection with any resource as Jersey wants to control this
I'm uncertain whether I can combine #Inject with #PathParam, #QueryParam, et al.
How to use injection in a MessageBodyWriter implementation
Does anyone have examples, preferably with source, of non-trivial application which combines Jersey and Guice without sacrificing one or the other in the process? I'm keeping on this road regardless, but the bits and pieces on the Jersey and Guice lists makes me think I'm repeating the work of others who came before me.
Guice integration with Jersey has not stagnated. The opposite is true. Thanks to Paul and his cohorts behind Jersey, the latest 1.7 release contains a special JerseyServletModule class to work with Guice-based servlets. Guice-based constructor injection into JAX-RS resource works! The issue is using JAX-RS annotations such as #QueryParam in the constructor of a JAX-RS resource. You don't need it! You use Guice for POJO injection all the way including singletons. Then JAX-RS is just icing on the cake for parsing HTTP-based RESTful APIs such as URL path, query parameters, content-type and etc. You don't need an "industrial strength" example either. Both Guice and Jersey are already battle tested. You just need a complete working example to see how it works. Then you can experiment advanced features on your own. Check out the following link for a complete example using Guice 3.0 and Jersey 1.7, which are all latest releases:
http://randomizedsort.blogspot.com/2011/05/using-guice-ified-jersey-in-embedded.html
I created a Guice/Jersey/Jetty/Jackson sample application here:
http://github.com/sunnygleason/j4-minimal
If you have any questions or suggestions for how to improve the
example, feel free to message me via github. The goal is to make
this a very accessible introduction to REST on the Java stack.
Hope this helps - have a great day!
-Sunny
Inspired by Sunnys sample application I've created a similar sample project that uses standard WAR files for deployment, e.g. in Apache Tomcat. You can find the project here:
https://github.com/danbim/template-guice-jersey-tomcat
Have fun!
Daniel
I believe I cannot use constructor
injection with any resource as Jersey
wants to control this
You cannot use guice's constructor injection because creation of resource is managed by jersey. In this case you can use jersey's #Inject annotation before constructor parameter you want to get injected:
public NewsResource(#Inject NewsService service)
I was having similar problems initially trying to use Guice to do constructor injection on my Jersey annotated classes, but eventually got it working, albeit with a fairly trivial application.
I followed the instructions here: jersey-guice javadoc
The trick in my case was that I needed to remove the standard Jersey configuration from my web.xml (like the Jersey ServletContainer) and keep only the Guice listener and Guice filter. Once I did that Guice was being called to create my JAX-RS annotated object, and Jersey was injecting my JAX-RS annotated methods (like #GET, etc.) as expected.
Although Sunny Gleason's example is great, it is a bit outdated now.
So, after struggling a lot today trying to make Guice and Jersey play nice with each other, I created the following sample project to get you started:
https://github.com/MaliciousMustard/gradle-guice-jersey-jetty
This project is using the following technologies:
Guice for DI
Jersey for the RESTful API
Jackson for POJO to JSON mapping
Jetty for the web-server
Gradle
I guess the most important thing is that you don't have to explicitly specify every new resource class you're adding. As long as you're adding them to the package that is being scanned (look at malicious.mustard.modules.JerseyModule), they will be found automatically!
GWizard includes a module that gives you out-of-the-box integration between Jersey2 and Guice. Here's an example of a complete JAX-RS service:
public class Main {
#Path("/hello")
public static class HelloResource {
#GET
public String hello() {
return "hello, world";
}
}
public static class MyModule extends AbstractModule {
#Override
protected void configure() {
bind(HelloResource.class);
}
}
public static void main(String[] args) throws Exception {
Guice.createInjector(new MyModule(), new JerseyModule()).getInstance(Run.class).start();
}
}
Note that this is based on the Squarespace jersey2-guice adapter, which may not function properly with future point releases of Jersey. GWizard also offers a RESTEasy JAX-RS module, which is preferred.
Here is a blog entry about this that might help: http://blorn.com/post/107397841765/guice-and-jersey-2-the-easy-way
The Jersey-Guice plugin Javadoc provides a pretty good description:
http://jersey.java.net/nonav/apidocs/1.1.5/contribs/jersey-guice/com/sun/jersey/guice/spi/container/servlet/package-summary.html
These examples were all great starts for me, but I wanted a full MVC stack using Jersey-Guice at it's core. I've been working on refining that for sometime. As of this week this MVC stack is fully deployed to Maven Central repository as an archetype. This means you can now create a new Jersey-Guice stack with one Maven command:
mvn archetype:generate \
-DarchetypeGroupId=org.duelengine \
-DarchetypeArtifactId=duel-mvc-archetype \
-DarchetypeVersion=0.2.1
This automatically generates your own project with you specified package naming so you don't have to manually edit a template project.
See the project Readme.md for more details: https://bitbucket.org/mckamey/duel-mvc
Details on the dual-side views (client-side template & server-side views) I use are here: https://bitbucket.org/mckamey/duel but you could replace with whatever you use.
I found an interesting project for lightweight Jetty+Guice+Jackson web services: https://github.com/talis/jersey-common/
I created a Guice 4.2, Jetty 9.4 and Jersey 2.7 sample application:
https://github.com/bnsd55/jetty-jersey-guice-starter-kit
As Sunny said:
If you have any questions or suggestions for how to improve the
example, feel free to message me via github. The goal is to make this
a very accessible introduction to REST on the Java stack.