I am using Jersey 2.27 on Google App Engine so I am also using the Objectify library which manages my entity classes. I want to be able to get the SecurityContext in one of those classes but Injecting it does not work since the POJO is not managed by Jersey itself.
Is their a way similar to Spring's way via SecurityContextHolder in Jersey 2.27?
#Entity
public class Item {
...
private String modifiedBy;
...
#OnSave
private void onSave() {
this.modifiedBy = SecurityContextHolder.getContext().getUserPrincipal();
}
}
Related
Building an endpoint and client with Spring MVC and Feign Client (with spring cloud). I had the thought that since both ends need to have the same annotations - and that they have to be pretty much in sync. Maybe I could define them in an interface and have the two ends implement that.
Testing it out I was somewhat surprised that it actually works for the Spring Web end.
But it I cannot find a way to do the same for a Feign client.
I basically have the interface:
#RequestMapping("/somebaseurl")
public interface ServiceInterface {
#RequestMapping(value = "/resource/{identifier}", method = RequestMethod.POST)
public SomeResource getResourceByIdentifier(String identifier);
}
And then the RestController
#RestController
public class ServiceController implements ServiceInterface {
public SomeResource getResourceByIdentifier(#PathVariable("identifier") String identifier) {
// Do some stuff that gets the resource
return new SomeResource();
}
}
And then finally the Feign Client
#FeignClient("serviceName")
public interface ServiceClient extends ServiceInterface {
}
The Feign client seems to not read the inherited annotations. So is there some other way I can accomplish the same thing? Where I can make the ServiceInterface into Feign client without annotating it directly?
This is possible as of Feign 8.6.0. From the Spring Cloud docs:
Feign Inheritance Support
Feign supports boilerplate apis via single-inheritance interfaces. This allows grouping common operations
into convenient base interfaces. Together with Spring MVC you can
share the same contract for your REST endpoint and Feign client.
UserService.java
public interface UserService {
#RequestMapping(method = RequestMethod.GET, value ="/users/{id}")
User getUser(#PathVariable("id") long id);
}
UserResource.java
#RestController
public class UserResource implements UserService {
}
UserClient.java
#FeignClient("users")
public interface UserClient extends UserService {
}
I am trying to understand the spring data solr showcase project.
https://github.com/christophstrobl/spring-data-solr-showcase
After spending quite a bit of time, I could not find how the productRepository is implemented and injected in https://github.com/christophstrobl/spring-data-solr-showcase/blob/master/src/main/java/org/springframework/data/solr/showcase/product/ProductServiceImpl.java
#Service class ProductServiceImpl implements ProductService {
private static final Pattern IGNORED_CHARS_PATTERN = Pattern.compile("\\p{Punct}");
private ProductRepository productRepository;
#Autowired
public void setProductRepository(ProductRepository productRepository) {
this.productRepository = productRepository;
}
The ProductRepository is defined as interface (https://github.com/christophstrobl/spring-data-solr-showcase/blob/master/src/main/java/org/springframework/data/solr/showcase/product/ProductRepository.java) and I did not find any code implementing this interface
interface ProductRepository extends SolrCrudRepository<Product, String> {
#Highlight(prefix = "<b>", postfix = "</b>")
#Query(fields = { SearchableProductDefinition.ID_FIELD_NAME,
SearchableProductDefinition.NAME_FIELD_NAME,
SearchableProductDefinition.PRICE_FIELD_NAME,
SearchableProductDefinition.FEATURES_FIELD_NAME,
SearchableProductDefinition.AVAILABLE_FIELD_NAME },
defaultOperator = Operator.AND)
HighlightPage<Product> findByNameIn(Collection<String> names, Pageable page);
#Facet(fields = { SearchableProductDefinition.NAME_FIELD_NAME })
FacetPage<Product> findByNameStartsWith(Collection<String> nameFragments, Pageable pagebale);
}
Below is how the spring context is configured:
https://github.com/christophstrobl/spring-data-solr-showcase/blob/master/src/main/java/org/springframework/data/solr/showcase/Application.java
If anyone could point me to the direction where this interface is implemented and injected, that would be great.
The showcase makes use of Spring Data repository abstractions using query derivation from method name. So the infrastructure provided by Spring Data and the Solr module take care of creating the required implementations for you. Please have a look at the Reference Documentation for a more detailed explanation.
The showcase itself is built in a way that allows you to step through several stages of development by having a look at the diffs transitioning from one step to the other. So having a look at Step 2 shows how to make use of Custom Repository Implementation, while Step 4 demonstractes how to enable Highlighting using #Highlight.
The goal of Spring Data is to reduce the amount of boilerplate coding (means to reduce repetition of code).
For the basic methods like save,find the implementation will provide by spring and spring will create beans(Objetcs) for these interfaces. To tell the spring that these are my repositories inside this package, we are writing #EnableJpaRepositories(basePackeges="com.spring.repositories") or <jpa:repositories base-package="com.acme.repositories"/> for JPA repositories
Foring solr repositores we have to write #EnableSolrRepositories(basePackages="com.spring.repositories" or <solr:repositories base-package="com.acme.repositories" /> Spring will create objetcs for these interfaces, we can inject these interface objetcs using #Autowire annotation.
Example:
#Service
Pulic class SomeService{
#Autowire
private SampleRepository;
/* #postConstruct annotation is used to execute method just after creating bean
and injecting all dependencies by spring*/
#PostConstruct
public void postConstruct(){
System.out.println("SampleRepository implementation class name"+ SampleRepository.getClass());
}
}
The above example is to see the implementation class of SampleRepository interface (This class is not user defined, it is class given by spring).
For reference documentation link http://docs.spring.io/spring-data/solr/docs/2.0.2.RELEASE/reference/html/. Try to read this simple documentation you can get more knowlede on spring-data.
I am using JBoss 7.1 and Java 1.6.
I would like to integrate a Guice service with by JAX-WS endpoint. Using the interceptor pattern described by Gunnar.Morling I am able to properly instantiate the Guice modules when using a stateless bean as a webservice. However i am not able to do the same with a simple POJO annotated webservice. Is this possible has anyone found a workaround. Below is a summary of my efforts so far.
#UsesGuice #Interceptor
public class GuiceInterceptor {
#Inject
private GuiceInjectorHolderBean injectorHolder;
#AroundInvoke
public Object aroundAdvice(final InvocationContext ctx) throws Exception {
if (ctx.getTarget().getClass().isAnnotationPresent(UsesGuice.class)) {
final Injector injector = injectorHolder.getInjector();
injector.injectMembers(ctx.getTarget());
}
return ctx.proceed();
}
}
The GuiceInjectorHolderBean is the a sinlgeton bean responsible for triggering the guice wiring. The annotation class required follows
#Retention(RUNTIME)
#Target(TYPE)
#InterceptorBinding
public #interface UsesGuice {}
the JAX-WS POJO class
#UsesGuice
#WebService(serviceName = "EchoServiceService", portName = "EchoServicePort", ame = "EchoServiceImpl", targetNamespace = "lala")
public class EchoServiceImpl implements EchoService
{
#Inject
MyGuiceInjection injection;
#Override
#WebMethod
public String sayHello(final String msg)
{
return "Hello " + injection.call(msg);
}
}
Thanks in advance
Dimitri
Your Current Approach
In your code, javax.interceptor annotations #Interceptor, #InterceptorBinding and #AroundInvoke are supported by CDI and EJB standards and not by Guice. Guice uses proprietary AOP interception via org.aopalliance.intercept.MethodInterceptor interface and calling the method AbstractModule.bindInterceptor.
So you're trying to bootstrap Guice injection on your endpoint by:
using a non-Guice interceptor on the endpoint's method
within the #AroundInvoke method, programmatically invoking the Guice Injector, with injection target being the intercepted endpoint
That begs the Q, what to use for 1?
'Bootrap' Interception Mechanism for Your Current Approach
Obviously, an EJB interceptor works, as you've stated.
Other than an EJB or Guice AOP interceptor... an obvious alternative would be the standard, a CDI interceptor.
But that would make it all rather circular and heavy-weight... Why use CDI just to boostrap, so that you can configure and execute to your desired DI competitor: Guice?
Suggested Alternative Solution - JAX-WS Support for Manual Endpoint Instance Initialisation
If you want POJO web services, maybe consider back-tracking a bit, instead of interceptor-driven Guice initialisation, maybe this could be what you need:
javax.xml.ws.Endpoint.publish(String address, Object implementor)
Endpoint.publish javadoc
Initialise Guice in the standard way, use injector.getInstance() to construct your endpoint instance, and then use Endpoint.publish to set the endpoint instance against the port. The following gives a good example:
Using Guice 3 with JAX-WS in Java 6 outside web container
I'm getting different instances of a #SessionScoped bean for two calls to the same user session. What can lead to this?
A bean annotated #SessionScoped is injected into a servlet, and a RESTEasy JAX-RS web service endpoint. A user logs in using HTTPS with a certificate. First call goes to the RESTEasy endpoint. The next call from the browser goes to the servlet. I'd expect the same bean instance in both calls, but they are different. ... Any ideas?
Using JBoss 7.0.1
bean:
#Stateful
#SessionScoped
public class MyBean implements Serializable { ... }
REST endpoint:
#Path("/one")
public class MyService extends JAXRSPlugin {
#Inject MyBean myBean;
...
}
Servlet:
#WebServlet(urlPatterns = "/two", asyncSupported = true)
public class MyServlet extends HttpServlet {
#Inject MyBean myBean;
...
}
Turns out the REST service methods are not really supposed to have an HttpSession to share state. REST services are supposed to be stateless. They are given #SessionScoped beans as if they were #RequestScoped by design.
It's not what I want for this case, but maybe I should just not use REST for these calls. Mainly I just wanted the handy mapping of URL paths to methods in my REST service class. Servlets don't have path-to-method-mapping like that, as far as I know.
Basically I see 3 options: (1) make of find a dispatching mechanism to use in one Servlet, (2) use multiple Servlets, or (3) mis-use the REST by abusing the #Context HttpServletRequest to get to the HttpSession. I don't like abusing APIs, so option 3 is out. CDI might make option 2 cool, but option 1 is probably more common (and so might be easier to maintain by others).
#Path(value = "/user")
#Stateless
public class UserService {
#Inject
private UserManager manager;
#Path(value = "/create")
#GET
#Produces(value = MediaType.TEXT_PLAIN)
public String doCreate(#QueryParam(value = "name") String name) {
manager.createUser(name);
return "OK";
}
}
here is the user manager impl
public class UserManager {
#PersistenceContext(unitName = "shop")
private EntityManager em;
public void createUser(String name) {
User user = new User();
user.setName(name);
// skip some more initializations
em.persist(user);
}
}
the problem is if i do not mark UserService as #Stateless then the manager field is null
but if i mark #Stateless, i can have the manager field injected, and the application works as i can get the data saved into db
just wondering, what is the reason behind this?
and is this the preferred way to wiring the application?
well, i am thinking to pull out the EntityManager to a producer, so that it can be shared
the problem is if I do not mark UserService as #Stateless then the manager field is null
For injection to occur, the class has to be a managed component such as Enterprise Beans, Servlets, Filters, JSF managed beans, etc or CDI managed bean (this is the new part with Java EE 6, you can make any class a managed bean with CDI).
So, if you don't make your JAX-RS endpoint an EJB, how to enable injection? This is nicely explained in JAX-RS and CDI integration using Glassfish v3:
There are two ways CDI managed beans
are enabled:
instantiated by CDI, life-cycle managed by Jersey. Annotate with
#ManagedBean and optionally annotate
with a Jersey scope annotation.
instantiated and managed by CDI. Annotate with a CDI scope annotation,
like #RequestScoped (no #ManagedBean
is required)
I also suggest checking the resources below.
and is this the preferred way to wiring the application?
I'd say yes. CDI is very nice and... don't you like injection?
well, I am thinking to pull out the EntityManager to a producer, so that it can be shared
Shared between what? And why? In you case, you should use an EntityManager with a lifetime that is scoped to a single transaction (a transaction-scoped persistence context). In other words, don't share it (and don't worry about opening and closing it for each request, this is not an expensive operation).
References
JPA 2.0 Specification
Section 7.6 "Container-managed Persistence Contexts"
Section 7.6.1 "Container-managed Transaction-scoped Persistence Context"
Section 7.6.2 "Container-managed Extended Persistence Context"
Resources
Dependency Injection in Java EE 6 - Part 1
Introducing the Java EE 6 Platform: Part 1
TOTD #124: Using CDI + JPA with JAX-RS and JAX-WS
The #Singleton annotation will help: http://www.mentby.com/paul-sandoz/jax-rs-on-glassfish-31-ejb-injection.html