I'm working on Spring MVC with richfaces.
Is there a way to call a method in a managed bean Controller from URL?
e.g: website.com/somecontroller/somemethod?x=1
I tried #RequestMapping but didn't work.
Thanks in advance
When the browser client want to access to an URL, the managed beans declared in the page will be created, the constructor and #PostConstruct methods will be invoked server side.
You can recover the parameters using #ManagedProperty as proposed by BalusC (as he says, the JSF-ish way):
Parameters in URL JSF 2
If that answer doesn't fit for your needs, you can recover the request object and get the parameters one by one, as stated in the question:
HttpServletRequest request = (HttpServletRequest)FacesContext.
getCurrentInstance().getExternalContext().getRequest();
String clipId = request.getParameter("x");
Related
Does anyone know of a way to spy on the Vert.x event bus in Quarkus tests? Ideally I'd like to assert that during a method in the service layer we are sending an event to the correct address, but does anyone know if this is possible?
If I just try to use #InjectMock I get the following error
io.vertx.core.eventbus.impl.EventBusImpl#5769679b is not a normal scoped CDI bean, make sure the bean is a normal scope like #ApplicationScoped or #RequestScoped
I solved this Problem, by creating an ApplicationScoped Delegate around the EventBus. This Delegate can be mocked and inspected as a normal bean in Quarkus. All the Beans which were using the EventBus directly need to use the EventBusDelegate instead. In your test you can use the #InjectMock annotation to inject the EventBusDelegate mocked.
As suggested here https://github.com/quarkusio/quarkus/issues/8983
#InjectMock(convertScopes = true)
should solve your problem. If convertScopes is true, then Quarkus will change Singleton to ApplicationScoped to make the bean mockable.
NOTE: the documentation states that this is an advanced setting and should only be used if you don't rely on the differences between Singleton and ApplicationScoped beans
I've been trying to figure out how to intercept methods defined in a Feign client with CDI (1.2) interceptors. I need to intercept the response value the client is returning, and extract data to log and remove some data prior to it being returned to the calling process.
I'm running a Weld 2.3 container which provides CDI 1.2. In it, I would like to create a CDI interceptor which is triggered everytime a call to filter() is made.
public interface MyRepository {
#RequestLine("POST /v1/data/policy/input_data_filtered")
JsonNode filter(Body body);
}
and a matching Producer method:
#Produces
public MyRepository repositoryProducer() {
return Feign.builder()
.client(new ApacheHttpClient())
.encoder(new JacksonEncoder(mapper))
.decoder(new JacksonDecoder(mapper))
.logger(new Slf4jLogger(MyRepository.class))
.logLevel(feign.Logger.Level.FULL)
.target(MyRepository.class, "http://localhost:9999");
}
I've tried the standard CDI interceptor way by creating an #InterceptorBinding and adding it to the interface definition, but that didn't work. I suspect because the interceptor must be applied to the CDI bean(proxy) and cannot be defined in an interface. I tried applying it to the repositoryProducer() method but that too was non functional.
I've read about the javax.enterprise.inject.spi.InterceptionFactory which is availabel in CDI 2.0, but I don't have access to it.
How can I do this in CDI 1.2? Or alternatively, is there a better interceptor pattern I can use that is built into Feign somehow?
The short, somewhat incorrect answer is: you cannot. InterceptionFactory is indeed how you would do it if you could.
The longer answer is something like this:
Use java.lang.reflect.Proxy to create a proxy implementation of the MyRepository interface.
Create an InvocationHandler that performs the interception around whatever methods you want.
Target Feign at that proxy implementation.
Is it possible to do something like this: When a user session starts I read a certain integral attribute from the database. As the user performs certain activities in this session, I update that variable(stored in session) & when the session ends, then I finally store that value to the DB.
My question is how do I identify using the JSF framework if the user session has ended & I should then store the value back to DB?
Apart from the HttpSessionListener, you can use a session scoped managed bean for this. You use #PostConstruct (or just the bean's constructor) and #PreDestroy annotations to hook on session creation and destroy
#ManagedBean
#SessionScoped
public class SessionManager {
#PostConstruct
public void sessionInitialized() {
// ...
}
#PreDestroy
public void sessionDestroyed() {
// ...
}
}
The only requirement is that this bean is referenced in a JSF page or as #ManagedProperty of any request scoped bean. Otherwise it won't get created. But in your case this should be no problem as you're apparently already using a session scoped managed bean, just adding a #PreDestroy method ought to be sufficient.
My question is how do I identify using
the JSF framework if the user session
has ended & I should then store the
value back to DB?
The JSF framework does not have a separate concept of a session; it uses the underlying session management features of the Servlet specification.
You would have to create a HttpSessionListener that provides hooks for you to capture the session creation and destruction events, where you can read the value and store it back into the DB.
HttpSessionListener, or if you need Dependency Injection for that save, you might use #PostConstruct & #PreDestroy. Remember that the session is destroyed when you call invalidate() or after session timeout, not when the user closes the browser. Why do you use Session Scope anyway, Conversation Scope might fit you better.
I am using jaxrs1.1 jar shipped with Websphere liberty profile 8.5 for creating REST WebService.
Lets suppose we have a method addNewProject as shown below :
If many people call this webservice method to add project concurrently. using link below , are there any concurrency issue? In servlet, each request is a separate thread , is it the same case here or should we handle concurrency by ourselves ?
endpointLink: http://somehost.com/path1/path2/addprojectdetails and POST the JSON object.
#POST
#Path("addprojectdetails")
#Consumes(MediaType.APPLICATION_JSON)
#Produces(MediaType.APPLICATION_JSON)
public Response addNewProject(ProjectDetails projectdetailsObj) {
return Response.status(200).entity("Project"+projectdetailsObj.getProjectname()+"successfully added").build();
}
I'm not sure what kind of concurrency issues you might be thinking of. The object itself can be either a singleton or request scoped (if using CDI) or a stateless session bean (if using EJB). If you're using a singleton, then you may need to be thread aware and not store state within the class.
It would probably help to understand what kind of concurrency issues you had in mind to answer more thoroughly.
I have a simple question, but I'm searching for longer time, but I always found the same answers,which i don't really know how to handle...
i want to get the IP adress of the client, when he registers to my application...
i found something like this:
#ManagedBean(name="testController")
#SessionScoped
public class TestController implements Serializable {
private static final long serialVersionUID = -3244711761400747261L;
protected final HttpServletRequest req;
public TestController(HttpServletRequest req) {
this.req = req;
System.out.println(this.req.getRemoteAddr().toString());
}
}
but i don't have the HttpServletRequest in the constructor....
or i don't know how to use it, all i get are errors....
It's available by the ExternalContext#getRequest().
public TestController() {
HttpServletRequest request = (HttpServletRequest) FacesContext.getCurrentInstance().getExternalContext().getRequest();
System.out.println(request.getRemoteAddr());
}
Note that you're making one major conceptual mistake in your initial attempt. You're attempting to assign the current HTTP request as a property of a session scoped managed bean. The HTTP request instance will expire by the end of the current HTTP response and thus not be valid anymore and throw exceptions in all colors when you try to access its methods in the subsequent requests following the initial request when the session scoped bean was been created.
I'd go for a different approach, also used in the Seam Solder project: Make a servlet filter that captures the servlet request and makes it available via an application scoped producer. See corresponding source code of the solder project.