I am using Spring Swagger library v1.0.2
Maven:
<dependency>
<groupId>com.mangofactory</groupId>
<artifactId>swagger-springmvc</artifactId>
<version>1.0.2</version>
</dependency>
I am able to scan my REST APIs and view it on the Swagger UI. I have even implemented OAuth and it is working great.
However, there is one feature that I need to implement. I want to hide some of the REST APIs. I need to do this at the class level as well as on the method level. I read about an 'hidden' attribute in the #Api annotation. I set it to 'true' but I can still see my class and all its method being displayed in the Swagger UI.
Example:
#Api(
description="This class is not covered by Spring security.",
value="/unauthorize",
hidden=true)
#RequestMapping("/unauthorize")
#Controller
public class UnauthorizeResource {}
Can someone please tell me how I can prevent the 'UnauthorizeResource' class from being displayed?
You can utilize the #ApiIgnore annotation:
#ApiIgnore
#RequestMapping("/unauthorize")
#Controller
public class UnauthorizeResource {}
Related
we are documenting our JAX-RS API with swagger. By using the swagger-jaxrs2 package, we can create an build our api documentation very well.
The only thing we want to change: the default "openapi"-Url.
By registering Swaggers OpenApiResource Class, our application produces everytime the default "[host]/openapi" Endpoint.
We are able to create our own endpoint which serves the openapi-spec, but we cannot disable this default endpoint.
Every hint is welcome! Tank you in advance.
We solved with a workaround: Modifing javax.ws.rs.core.Application to load just the Endpoints which we provide by our own, ignoring any other 3rdParty endpoint like the swagger-jaxrs2 openapi or openapi.{type:json|yaml}
#ApplicationPath("")
public class OurApplication extends javax.ws.rs.core.Application {
#Override
public Set<Class<?>> getClasses() {
// Start detecting only classes in your package! provided 3rdParty packages
// (like io.swagger.v3.jaxrs2.integration.resources) won't be provided
Reflections ourClasses = new Reflections("our.package.naming");
// Scan your classed for #javax.ws.rs.Path Annotaion. We need just collect
// API-Endpoints
Set<Class<?>> ourEndpoints = ourClasses.getTypesAnnotatedWith(Path.class);
// fyi - log the registered classes / endpoints
System.out.println("Providing "+ ourEndpoints);
// return endpoints to provide it in your application
return ourEndpoints;
}
}
HINT: Due to #ApplicationPath annotation there is no need to modify web.xml.
The Reflections we used are provided by maven:
<dependency>
<groupId>org.reflections</groupId>
<artifactId>reflections</artifactId>
<version>0.9.12</version>
</dependency>
Watch https://github.com/ronmamo/reflections for more information about the reflections package.
We didn't find a better solution but this is what worked for us. Enjoy it.
I used to integrate Service and DAO beans in Jersey REST resources by annotating them with #Path following Java EE tutorial
In general, for JAX-RS to work with enterprise beans, you need to annotate the class of a bean with #Path to convert it to a root resource class. You can use the #Path annotation with stateless session beans and singleton POJO beans.
So my code used to be something like this:
#Path("/")
public class ServiceResource {
#Inject
private AccountService accountService;
#GET
#Path("/account/get")
public Account getAccount(#QueryParam("id") String id) {
return accountService.get(id);
}
}
#javax.inject.Singleton
#Path("")
public class AccountService {
public Account get(String id){...}
}
Now, I started integrating a Quartz Job into my application, and I wanted to find a way to inject my AccountService inside a job like this
public class AccountJob implements Job {
#Inject
private AccountService accountService;
#Override
public void execute(JobExecutionContext jec) throws JobExecutionException {
accountService.updateAllAccounts();
}
}
I found this answer that tells to use DeltaSpike to do the Job, so I added the following dependencies to my pom.xml, and without adding any more lines of code to any class the inejection of accountService to my Job works fine
<dependency>
<groupId>org.apache.deltaspike.modules</groupId>
<artifactId>deltaspike-scheduler-module-api</artifactId>
<version>1.7.2</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.apache.deltaspike.modules</groupId>
<artifactId>deltaspike-scheduler-module-impl</artifactId>
<version>1.7.2</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.deltaspike.cdictrl</groupId>
<artifactId>deltaspike-cdictrl-api</artifactId>
<version>1.7.2</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.apache.deltaspike.cdictrl</groupId>
<artifactId>deltaspike-cdictrl-weld</artifactId>
<version>1.7.2</version>
<scope>runtime</scope>
</dependency>
However, I realized that when I remove the #Path("") from AccountService, its instance is still injected fine inside ServiceResource, so my questions are the following:
Why adding DeltaSpike dependencies made it possible to inject my beans without using #Path on them?
By searching more, I understood that DeltaSpike internally uses Weld to do the injection, and since I am already using GlassFish 4.0, I know that Weld is already there, so why the injection is not working by default in my Job class and in ServiceResource class without adding #Path on my beans? Actually why adding #Path is even suggested in the Java tutorial?
Is there any bad side effects that I don't see in my code, because I think that I am mixing multiple DI methods here without really understanding how do they work?
Update: After more search, I realize that Jersey doesn't use Weld for dependency injection, instead it uses HK2, a different framework that also happens to be a part of GlassFish, when I try to inject AccountService without using #Path it shows the following exception
org.glassfish.hk2.api.UnsatisfiedDependencyException: There was no object available for injection at SystemInjecteeImpl(requiredType=AccountService,parent=ServiceResource,qualifiers={}...
So this updates the questions to the following:
How to make HK2 injections works? // Without using #Path as mentioned in the Java EE Tutorial
If I managed to to do DI with HK2, will it be safe to use DeltaSpike to do DI for the Quartz Job? Is it okay to mix two CDI framewroks together to scan the classes and do the injection?
I put my my source code on pastebin; pom.xml is here and the Java is here
You do not need to set the Path annotation on your AccountService CDI bean. If CDI is enabled on your application (either with empty beans.xml in CDI 1.0 or discovery-mode=all in CDI > 1.0), you can #Inject any CDI bean in your JAX-RS resource.
So you just have to write the following class:
#Path("/")
public class ServiceResource {
#Inject
private AccountService accountService;
#GET
#Path("/account/get")
public Account getAccount(#QueryParam("id") String id) {
return accountService.get(id);
}
}
#javax.inject.Singleton
public class AccountService {
public void Account get(String id){...}
}
The article you linked in your post deals with mixing EJB and CDI annotations. For example you can mix #Stateless and #Path annotations. It's interesting for example because you can :
Benefit of EJB transaction in your Rest resource (even if now you can use #Transactional interceptor binding)
Set a pool of resources
etc.
Note that all of this works without the help of deltaspike dependency.
For your second question, as Quartz manages its own threads, classes are not handled by CDI so you can not inject beans in Quartz classes. The aim of the deltaspike module is to allow injecting CDI beans in Quartz Jobs. Internally, deltaspike controls CDI Contexts.
EDIT
For your last questions:
Your HK2 problem comes pretty sure from a missing dependency (in your application or server). As said in a previous comment, I managed to deploy your App on Glassfish 4 (build 89) with the source files you provided.
Regarding the integration of CDI with Quartz, I think the best is to implement your own JobFactory and instanciate your jobs using BeanManager. Take a look at this link : https://devsoap.com/injecting-cdi-managed-beans-into-quarz-jobs/
First of all injected resources(beans) and Jersey Endpoint class(point of injection) must be CDI-Aware. It must be detecteable by CDI. We can use bean-discovery-mode="all" - then CDI scan ALL classes or
bean-discovery-mode="annotated" and MARK our class with PROPER annotation: from here : Bean defining annotations. I prefer#Dependent or #RequestScoped
Then we must use Jersey Extension
<dependency>
<groupId>org.glassfish.jersey.ext.cdi</groupId>
<artifactId>jersey-cdi1x-servlet</artifactId>
<version>{version}</version>
<scope>runtime</scope>
</dependency>
`
to connect CDI with HK2 discovery mechanism.
Here is Official oracle Guideline
The default beans.xml discovery-mode (in Java EE 7) is "annotated". Which means only beans that have CDI annotations are recognized and managed by CDI.
Your AccountJob class is not annotated. If you want CDI to be able to inject the service into it then you need to annotate it with some scope annotation, e.g. #ApplicationScoped.
Your other option is to create CDI producer for creating AccountJob beans. See:
http://docs.jboss.org/weld/reference/latest/en-US/html_single/#_producer_methods
I am running a web-app, which has one exposed class ( available to other POJO classes) and that has one autowired private member.
Spring managed class
public class EPSQueueSender {
#Autowired
private AmqpTemplate epsMessageTemplate;
public void dosomething(...){
epsMessageTemplate.convertAndSend(...); // Here epsMessageTemplate is null if instance of EPSQueueSender taken from other POJO
}
}
POJO class
public class Test{
EPSQueueSender sender = new EPSQueueSender();
sender.dosomething(....); // gives null exception on epsMessageTemplate
}
Spring code ( running as WebApp) and POJO class code( different Jar) are on same JVM. The POJO is not able to get initialized autowired object. However it is initialized if I use it in webApp project.
Can someone please give some suggestion how can I overcome this problem?
Last thing I would like to try is to hit webserver as http request from POJO.
beans can be pojo or xml many examples might help. You already have #autowired but you did not create the #bean method itself that belongs in a class annotated with #Configuration
Your problem could be overcome using #Configurable feature of spring. For it you have configure in xml with a code like belove
<context:annotation-config/>
<context:spring-configured/>
<context:load-time-weaver/>
in Java Congiguration like below:
#Configuration
#EnableAspectJAutoProxy
#EnableSpringConfigured
#EnableLoadTimeWeaving
public class ConfigApplicationContext {
}
with this configuration you can benefit of the load-waving aspect technique that througth the build-in Spring bean AnnotationBeanConfigureAspect you can inject Spring bean in a pojo that is annotated with #Configurable. you colud be have a code like below:
#Configurable
public class Test{
#Autowired
private EPSQueueSender sender;
public void method(){
sender.dosomething(....); // gives null exception on epsMessageTemplate
}
}
of course, since that you are using a load-wave technique you have configure an agent that will perform the istruments. the configuration is very simple and you have add a line like below in the start of the jvm or tomcat:
java -javaagent:path of the jar with the agent/spring-instrument.jar
remember of course of insert the aop and spring aop maven dependency:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aop</artifactId>
<version>yourVersion</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aspects</artifactId>4
<version>yourVersion</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-instrument</artifactId>
<version>yourVersion</version>
</dependency>
I hope that this can help you
I want a Feign client to consume a Spring Boot controller, and I want the contract between them to be specified in a common Interface to the degree possible.
The interface with method would look something like this:
#RequestMapping
public interface RuleManager {
#RequestMapping(value = "/addRule", method = RequestMethod.POST, consumes = {"application/json"}, produces = {"application/json"})
#ResponseBody Rule addRule(#RequestBody Rule rule);
}
The Feign client would look like:
#FeignClient(url = "http://localhost:8080")
public interface RuleManagerClient extends RuleManager { }
and the Spring boot controller:
#RestController
public class RuleManagerService implements RuleManager {
#Override
#Transactional
public Rule addRule(#RequestBody Rule rule) {
return rule;
}
}
It's nice that I don't have to specify #RequestMapping in two places, but unfortunately it seems I do have to specify #RequestBody twice. When #RequestBody is omitted from either the controller or the shared interface, the Rule object is instantiated but with all members set to null.
Is there a way around this ? Perhaps this is addressed in a newer version ? My dependencies include:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-feign</artifactId>
<exclusions>
<exclusion>
<groupId>com.netflix.feign</groupId>
<artifactId>feign-core</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.netflix.feign</groupId>
<artifactId>feign-core</artifactId>
<version>8.14.3</version>
</dependency>
I discovered this technique required at least feign-core 8.6 here:
https://jmnarloch.wordpress.com/2015/08/19/spring-cloud-designing-feign-client/
Thanks for any help.
Apparently this does work--#RequestBody need only appear in the shared Interface. The problem was that I had the following property set in application.properties for the controller but not for the client:
spring.jackson.property-naming-strategy=CAMEL_CASE_TO_LOWER_CASE_WITH_UNDERSCORES
That's why the object was instantiated on the server side but with all members null--effectively, the wrong properties were sent across the wire, for example "ruleName" instead of the expected "rule_name".
I am new to Spring boot. I was trying to create RESTful web service which also plugs into MongoDB.
Everything works fine as the guide explains except for this.
package hello.requests;
import java.util.List;
import org.springframework.data.mongodb.repository.MongoRepository;
import org.springframework.data.repository.query.Param;
import org.springframework.data.rest.core.annotation.RepositoryRestResource;
import hello.models.CustomerModel;
#RepositoryRestResource(collectionResourceRel = "people", path = "people")
public interface CustomerRepository extends MongoRepository<CustomerModel, String> {
List<CustomerModel> findByLastName(#Param("name") String name);
}
Here I am trying to change the RESTful endpoint for the repository from the default /customerModels to /people. But when I run this, I get 404 if I try /people but works fine for /customerModels.
In a broader sense how does #RepositoryRestResource work?
What am I doing wrong here?
You can't use slash inside the path attribute, but you can set base path in application.properties:
# DATA REST (RepositoryRestProperties)
spring.data.rest.base-path=/my/base/uri
# Base path to be used by Spring Data REST to expose repository resources.
Without seeing your entire configuration it is hard to know exactly what is going on in your situation. However using the latest guide at https://github.com/spring-guides/gs-accessing-data-mongodb.git I am able to get it working by making the following changes:
Adding spring-boot-starter-data-rest as a dependency in the POM file.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-rest</artifactId>
</dependency>
Adding this annotation to the CustomerRepository class.
#RepositoryRestResource(path = "people")
Setting up getters and setters in the Customer class for the 2 name fields in the constructor to avoid a Jackson serialization error.
Using this when I run the application I am able to access the repository at http://localhost:8080/people. If I remove the annotation then the CustomerRepository is accessed at http://localhost:8080/customers. Let me know if you want me to post a fork on GitHub.
To answer your question about what RepositoryRestResource is that it overrides the attributes for the ResourceMapping that is created by default. It's attributes are used in creating the mapping and change the related return values of the methods on the mapping class. By default Spring Data Rest creates defaults based on the class names of the objects used in the repository definition.
/customerModels is generated by default because your default method returns a list of CustomerModel. So you may try to add this #RestResource(path = "names") to your method and then access it like:
http://localhost:8080/yourapp/people/search/names. Look here: Spring data docs