Servlet specification SRV.3.2 says
Servlets in a container that were not deployed as part of aWeb
application are implicitly part of a “default” Web application and
have a default ServletContext.
so how can we create serlvets those are not part of web application and what is the use of them?
Take a look at section SRV.9.1:
SRV.9.1 Web Applications Within Web Servers
A web application is rooted at a specific path within a web server. For
example, a catalog application could be located at
http://www.example.com/catalog. All requests that start with this prefix will be routed to the
ServletContext which represents the catalog application.
Servlets that are not part of a web application are therefore servlets that are not rooted at a specific path. In other words, they're rooted at the / path, and their use is to serve content from there.
Note that this is pretty awkward to begin with (as the verbose text already shows), so most web application servers let you designate an application to run at the 'root' context path in some other way.
Related
For a web service project, I need to install two API versions of a Java EE web on my web server at
example.com/myservice/v1 and
example.com/myservice/v2
The safest way to separate the different versions seems to be deploying them in different WAR files, one for v1 and one for v2.
I created and deployed two JBoss 6 Java EE 6 Web Profile applications with these entries in jboss-web.xml:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<context-root>/test/v1</context-root>
</jboss-web>
and
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<context-root>/test/v2</context-root>
</jboss-web>
Both war files deployed and ran without errors. JBoss did not complain that they use the same root context part /test.
Is this a standard behaviour of a servlet container (specified) or just a JBoss feature and not guaranteed to be portable?
For example, Oracle docs for Glassfish say that A context root must start with a forward slash (/); and end with a string - no restrictions of slash inside the context root.
Another example is JBoss docs where there is an example of two web applications with nested context roots (paragraph 1).
Tomcat also supports nested context paths - see Naming section of Apache Context Configuration doc.
There is no requirement of not having slash inside the context root in the specification also. I think it means that as well as any other feature you may assume that it works on your application server, but the way it is configured may differ, and of course you have to test your application before moving to another container.
Regarding context root JBoss says:
The context root of a web application determines which URLs Tomcat
will delegate to your web application. If your application's context
root is myapp then any request for /myapp or /myapp/* will be handled
by your application unless a more specific context root exists. If a
second web application were assigned the context root myapp/help, a
request for /myapp/help/help.jsp would be handled by the second web
application, not the first.
Two context root that you have defined in jboss-web.xml are i) /test/v1 and ii) /test/v2. These two are entirely different since they specify two different URLs.
So your apprehension that:
JBoss did not complain that they use the same root context part /test.
does not hold good as they are different from one another.
I am trying to migrate an enterprise application from JBoss to Websphere 8.5. The application is configured with Spring MVC and tiles. The application is hosted in the server root of the JBoss Server, i.e. to access the application we just type https://localhost/ in the browser.For this reason all the links and association in the applications are currently written as follows:
<link href="/resources/jQuery.js" .../>
...
Home
etc.
But in WebSphere the application needs to be in a context root viz. https://localhost:9443/MigratedApplication.
The problem is that all the links and resources mapped in the application now are inside https://localhost:9443/MigratedApplication/resources but they are still looked for in https://localhost:9443/resources resulting in errors on the application throughout.
Any ways to resolve the issue by configuration in WebSphere?
Unfortunately you have hardcoded paths in your application, so you have 2 choices:
change the context root of the application on WebSphere to / as in JBoss (probably easier one, as doesnt require changes in application)
change all links to relative ones (this should be done in the first place during application development to make it independent of context root)
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.
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'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