I've web.xml where tomcat lookup for value
<session-config>
<session-timeout>30</session-timeout>
</session-config>
I want the same value to be fetched into javabean file as variable.
Is there any better way to lookup on this without actually pasing throuh entire xml file to get just a value.
Does this can be implemented by JNDI lookup ?
Again, TY for your help.
One way I think you can do it(though verbose) is to implement your own HttpSessionListener. Override its sessionCreated() method, you can get a reference to the HttpSession from the HttpSessionEvent and by invoking HttpSession#getMaxInactiveInterval(), you can get the session-timeout value in seconds. You can then store the value in your bean. there will be cons to this solutions, I will update it.
Related
I want to call a method on a Filter object after it has been added according to the web.xml definition. All I got is a WebApplicationContext object (let's call it: wac).
I'm able to add new Filter objects via: wac.getServletContext().addFilter("otherfilter", otherFilter);
Also, I can test successfully for its existence via: wac.getServletContext().getFilterRegistration("myfilter")
But how may I access (and possibly modify) Filter objects which have been added before?
I'm not sure how to do it exactly as you want, but this problem is usually solved using different approach.
You can declare your Filter as a bean in your application context and then register a DelegatingFilterProxy in web.xml to delegate filtering to your filter.
In this case your filter will be a regular Spring bean, and you'll be able to access it like any other bean.
The Servlet API does not provide any mechanism to directly access a Filter instance once it has been added to a ServletContext. The best you are going to get with the Servlet API is the FilterRegistration interface you have already found which lets you modify the same set of configuration options as you can via web.xml.
Depending on exactly what you want to do, you might be able to code your way around this problem using init parameters but that is never going to be a particularly clean solution. I'd go with the DelegatingFilterProxy solution suggested by axtavt.
How would I go about passing a reference to the initialization of a servlet?
So, let's say I have something like this in my web.xml:
<servlet>
<servlet-name>RestTestServlet V3.1</servlet-name>
<servlet-class>com.xxx.servlet.RestTestServlet</servlet-class>
<init-param>
<param-name>serviceConsumerKey</param-name>
<param-value>com.xxx.oauth.ConsumerKey</param-value>
</init-param>
</servlet>
When I try to get the parameter, of course I just get the literal string value ("com.xxx... etc).
The com.xxx.oauth.ConsumerKey is a string bean I pull from JNDI, but I'm not sure how to get the servlet to be aware of it. I'm using Spring.
Is there a way to do this via the web.xml? If not, how would you go about doing what I'm trying to do?
The normal Spring approach would be to not write your own servlets, but rather use the Spring WebApplicationCOntext together with a DispatcherServlet. I.e., your servlet would be replaced by a spring bean, configured to handle certain requests and injected with the JNDI object.
I'm studying EJB3.
I have a session bean which provides services to create/update customer accounts.
This session bean offers services on the lines of:
public void addCustomer(Customer c);
public void updateCustomer(Customer c);
Ideally I'd like to have a single servlet: CustomerServlet and it would invoke the session beans that I have listed above.
Problem is that I have two JSPs: UpdateAccount.jsp and CreateAccount.jsp. Both of these JSPs have a form with a method POST and action "CustomerServlet".
How can I distinguish in a customer servlet which operation I should carry out: createAccount or updateAccount?
I guess the alternative is to have a separate servlet for each operation...
Thank you
I'm not really certain about the best practice for this but I have a couple of suggestions that might work:
If your form is being submitted using a submit button, you could distinguish the request on the basis of the value of the <button-name> parameter. So if your buttons had the values Update and Create and were named account-submit, by checking the value you get with request.getParameter('account-submit'), you'd be able to tell which button was clicked to generate this request. If you named them differently, you could also just check which of the two parameters was not null and you'd know which form submit you were handling.
Note that if you have only a single text field in your form and the user hits Enter instead of clicking the button, you'll get a null in your servlet! See my blog post about this behaviour.
Check the Referer header - I wouldn't really recommend this since you wouldn't always know the context of the deployed app, this value may not always be present and it can be easily spoofed.
Add another mapping for your servlet so that it's accessible at both http://myapp.example.com/context/create and http://myapp.example.com/context/update. You can then check the ServletPath (request.getServletPath()) to see what 'servlet' the request came in for. I'd probably go with this one since it seems the most robust to me but you might also want to add the other two checks just to make sure. In your web.xml, you'd want something like
<servlet>
<servlet-name>CreateUpdateServlet</servlet-name>
<servlet-class>my.package.CustomerServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>CreateUpdateServlet</servlet-name>
<url-pattern>/create</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>CreateUpdateServlet</servlet-name>
<url-pattern>/update</url-pattern>
</servlet-mapping>
JSPs are Servlets, just in a different source code form, there is no reason to POST to a different Servlet, you can just POST back to the same JSP.
You don't need the servlet. JSPs (or Facelets) can talk directly to the beans via EL.
In our application we use jsf,we have
to redirect the user to home page
after their session will be expired.For that i need a path of the home page which i kept in my logout managed bean as a managed bean property.But after session expired if i try to access that it will arise null pointer exception(managed bean becomes null).Then
i have decide to try alternative (i.e)create logout class manually and try to access the property, at that time the property which i wants to access is become null.How can i access
that property?
Please help me.
Thanks in advance.
In addition to the previous answer:
You could use (in web.xml)
<error-page>
<exception-type>javax.faces.application.ViewExpiredException</exception-type>
<location>viewexpired.jsp</location>
</error-page>
Or Context Parameters instead of Session Attributes. See:
http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
http://safebox.guisho.com/jsf-how-to-get-webxml-parameters
Or use (in faces-context.xml)
<managed-bean-scope>application</managed-bean-scope>
for your bean, so it will stay independent from the session.
Correct way of doing this is declaring exception handler factory in faces-config.xml, then implementing the factory by subclassing javax.faces.context.ExceptionHandlerFactory, and then overriding handle() method in your implementation of javax.faces.context.ExceptionHandlerWrapper.
There you should analyze the exception for the ViewExpiredException class and redirect to your view expired page in that case.
When using Restlets, how can I read configuration parameters passed in through web.xml? With servlets, context-param can be used. How do I read context parameters from within a Restlet?
From the mailing list:
the init parameters are available in the application's context:
getApplication().getContext().getParameters().
In web.xml:
<context-param>
<param-name>my.context.param</param-name>
<param-value>Hello World</param-value>
</context-param>
In a Restlet's represent method, use:
// => "Hello World"
String result =
getApplication().getContext().getParameters().getFirstValue("my.context.param");
ServerServlet adds all the init parameters from both the servletConfig and from the servletContext to the application context.
So depending on your need, you could either examine the source code for ServerServlet, and read the configuration parameters in the same way, or simply obtain the values from your restlet, or your restlet's application's context.