We have a web application which is an ear file containing 1 war and 1 MDB jar.
Problem is that I load some properties file in my servlet when first request for servlet comes. These properties I will also need in my MDB. How can I access my Servlet class(inside war) in the EJB jar classes. Is there any way to use my war file as a utility jar.
Application is running on weblogic server.
You don't as a servlet is invoked through a HTTP call. You could hack it by doing an URLConnection to the servlet, but I would rather refactor your code a bit so you can call the initialization code on server startup in stead of by invoking the servlet. A context listener or an EJB init() could already do it.
Extract out your property management into a common, utility JAR that can be accessed from both tiers of your app.
Related
A java webapp must choose between either static context or "webcontext". Why do we need a webcontext just for a web server like jetty and why must we route everything to the same "webcontext" ?
Because Jetty is a JEE servlet container and in the JEE world there is a one to one relationship between a webapplication and the web context. The intention is to be able to run several independent webapplications within the same servlet container. So it is easy to route to the appropriate webapplication by the first part of the URL path.
Theoretically it would be possible to declare more than one webcontext for a webapplication but it is specified otherwise. See section 10.2 "Relationship to ServletContext" in Java Servlet Specification 3.1:
The servlet container must enforce a one to one correspondence between
a Web application and a ServletContext. A ServletContext object
provides a servlet with its view of the application.
In a JBoss 5 JEE project which I have inherited, the web application (WAR) project contains a JNDI configuration file which seems to be unneccessary. Its content is
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
java.naming.provider.url=localhost:1099
Removing it has no obvious effect, deployment and execution works well and unit tests show no errors.
Is it safe to delete this file?
You would create that file if you want to create a -client- that connects to a JNDI context to invoke EJBs remotely. If that war is part of the application that serves the EJB, you indeed do not need it since you already have local access to the JNDI context. Assuming the war is part of an EAR that also holds the EJB module.
We know that whenever a request for a servlet comes, servlet container will first check web.xml file for url and corresponding servlet classes. This is fine, But the confusion comes after that. Suppose I am using load-on-startup property. SO, the servlet should be ready before first call comes in. In that case container need servlet Config object to make servlet in work. But again load-on-start up and init-parameter for servlet is defined in web.xml file. So when exactly container uses web.xml?( when load-on-startup property is used then container can not obviously wait for first call, again container has to read web.xml file to know whether that property is used with any servlet.)
It will be better if some one can clear my confusion. Please provide some dependable link also if possible.
Loading and Instantiation:
The servlet container is responsible for loading and instantiating servlets. The loading and instantiation can occur when the container is started, or delayed until the container determines the servlet is needed to service a request.
When the servlet engine is started, needed servlet classes must be located by the servlet container. The servlet container loads the servlet class using normal Java class loading facilities. The loading may be from a local file system, a remote file system, or other network services. And as the servlets are declared in the web.xml, this file is loaded and read by the container during container startup.
Initialization:
After the servlet object is instantiated, the container must initialize the servlet before
it can handle requests from clients.The container initializes the servlet instance by calling the init method of the Servlet interface with a unique (per servlet declaration) object implementing the ServletConfig interface.
Ref: JSR-000315 JavaTM Servlet 3.0
web.xml is read as soon as you deploy your application on a web server. For the sake of understanding, you can assume container is nothing but your web server. Although web server has more than just a web container.
Web server reads the web.xml, and loads the context config, load on startup servelts,etc. web.xml is the file through which you tell your container/server about your application. Your web application sits inside the web server, and server intercepts all the incoming requests, decides to which application the request should be forwarded depending on the context.
I want all my .jsp files to be compiled at deploy instead on first access. Anyone knows how to do it in a webserver agnostic way (through web.xml maybe?). If there is not a way to do this through a project configuration I would like to know how to do it on Weblogic.
You can set the server to precompile JSPs on deployment. See section Precompiling JSPs in the WebLogic JSP Reference. From there:
You can configure WebLogic Server to precompile your JSPs when a Web
Application is deployed or re-deployed or when WebLogic Server starts
up by setting the precompile parameter to true in the
element of the weblogic.xml deployment descriptor. To avoid
recompiling your JSPs each time the server restarts and when you
target additional servers, precompile them using weblogic.jspc and
place them in the WEB-INF/classes folder and archive them in a .war
file. Keeping your source files in a separate directory from the
archived .war file will eliminate the possibility of errors caused by
a JSP having a dependency on one of the class files.
For more information on the web.xml deployment descriptor, see
Assembling and Configuring Web Applications.
For weblogic, you have both approaches here (http://m-button.blogspot.com.es/2008/09/using-jsp-precompilation-in-weblogic.html).
I prefer doing it at build time, as it will not impact application deploy time.
One way to get this done is to add the jsp_precompile as a request parameter to the desired jsp as in
http://localhost/myApp/desired_page.jsp?jsp_precompile=true
I personally am not an advocate of sending such a systemic config parameter so obviously in a request, so you should do it within the page (or group of pages) as described in this tutorial
I'm trying to do the following:
Imagine you have a Java EE application running on Tomcat using Spring as the IoC engine.
I have another jar in the application that has full access to all the resources. i.e. I can instantiate the same application context that is running in tomcat but it takes around 30 seconds to instantiate all the dependencies.
Anyone knows if it is feasible to retrieve current tomcats ApplicationContext from the outside?
There is a way to ask for the WebApplicationContext inside a servlet but I'm not on it, I only have a jar with a main method.
No. You have to be running within tomcat (a webapp) to be able to access the servlet context (and from there - the application context). You are not even in the same runtime with the main method.
If you want to get some information from the context, you should expose it as a service. For example:
a restful service, via Spring-MVC
via JMX
via JNDI