I have been supplied a WAR that contains a servlet. In the source of that servlet there are default initialization parameters ... for example:
#WebInitParam(
name = "proxyHttpsPort",
value = "9445",
description = "EPS Proxy HTTPS port"
),
My puzzle is how to over-ride these defaults in my local WebSphere Liberty environment. Does anyone know how to set the values of the initialization parameters such that when the servlet is loaded/started, my locally supplied values will be used rather than the default values baked into the application?
When we define a Servlet, we can do so through Java annotation. For example:
#WebServlet
We can also define initialization parameters:
#WebInitParam(name="name", value="value")
The notion behind an initialization parameter is to provide run-time configuration parameter that may be distinct by location where the solution is deployed. For example, on one system, an initialization parameter may have:
name="passwordFile", value="/etc/mypasswords.txt"
while on a different system, we may have:
name="passwordFile", value="/tmp/test_passwords.txt"
We don't want to hard-code these values in our applications but, instead, provide a default value that can be over-ridden at run-time.
When we build a Dynamic Web App for deployment on Java EE, we can define the servlet exclusively through annotations in code and this is the preferred style these days. However, before annotations, one defined the characteristics of a dynamic web project (including its servlets) through an XML file called web.xml. Within this file, one could supply a large set of configuration parameters including servlets and, for a servlet, the initialization parameters.
It appears that the web.xml technique is still available to us and can be used in conjunction with the Java annotations. What this means is that we can declare our Servlet and initialization parameters via annotations and at the same time, create a web.xml file. Where a value is found through annotation and there is no corresponding web.xml value, then the annotation will be used. However, if both an annotation and the same web.xml definition are present, then the web.xml definition will be the one actually used. Since the web.xml is an "exposed" configuration file, at deployment, we can edit web.xml to set the desired value for anything we wish to over-ride … including initialization parameters.
Related
I have a scenario where I am sending a generic Command like: AddRequest.
When I configure routing using Assembly, it doesn't work (error: no destination specified):
routeSettings.RouteToEndpoint(assembly, "App2.Endpoint");
However the command gets sent successfully when configuring routing via type:
var genericType = Type.GetType("SharedApp.AddRequest`1[[SharedApp,MyObject]],SharedApp");
routeSettings.RouteToEndpoint(genericType, "App2.Endpoint");
Is something wrong/missing while configuring it via assembly ?
When NServiceBus scans the assembly it looks for message types but all it finds is an open generic type AddRequest<T>.When you send a message, you send an instance of AddRequest<MyObject> which is a closed generic type, so different from the one discovered.
Unfortunately NServiceBus routing system is not aware of generic types and uses type equality to determine the route. Because of that it does not know where to sent AddRequest<MyObject>.
The reason why NServiceBus routing system has been designed this way is it already uses one mechanism for group route registration which is based on assembly and namespace. You can register one route for a set of types provided they are defined in same assembly and/or namespace. If you introduced yet another mechanism for grouping e.g. based on generic types or based on type inheritance (i.e. route for base type is used for derived types) we would end up in a situation where a type can have multiple routes associated with no clear way to pick one over the others.
I am studying up on EJB 3 from the book EJB in Action and this book in chapter 5 discusses about environment naming context(ENC). It says this :
If you know how JNDI references worked in EJB 2, you’re familiar with
the environment naming context (ENC). ENC allows portability of the
application without having to depend on global JNDI names. Global JNDI
names for resources differ between application server implementations,
and ENC allows you to use a JNDI location that starts with
java:comp/env/ instead of hard-coding the actual global JNDI name. EJB
3 essentially assumes that all JNDI names used in code are local
references and automatically prepends names with the java:comp/env/
prefix.
I am not getting what is meant by global JNDI name? Why does it have to be different across app servers?
I am tagging the question as both EJB2 and EJB 3 since the quote references both the versions. Please feel free to edit if you think otherwise.
A global JNDI name uses a name in the default JNDI context. For example, on WebSphere Application Server, remote EJBs are bound by default to ejb/<app>/<module>/<bean>#<interface>. If you hardcode this lookup string in your application, then the application won't be portable to other application servers (which might use a different scheme for the default name) or even the same WebSphere Application Server if the target application or module name changes.
The solution in EE is for your application to declare an EJB reference, which will be in the java:comp/env context with a name that you choose. When a deployer installs your application on the server, they can bind the java:comp/env name to a global JNDI name that is appropriate for the environment. This same pattern is actually used by all EE resources (data sources, String/int/boolean configuration values, etc.), and when used properly, it is one of the strengths of the EE platform.
I can't tell what the excerpt above is trying to say without more context. Perhaps it's referring to the EJBContext.lookup method, which is effectively a shortcut of doing a lookup relative to java:comp/env.
As a final aside, I'll note that EJB 3.1 defines a standard location of java:global/<app>/<module>/<bean>!<interface> for EJB bindings. Regardless, it is still a best practice to use EJB references when doing lookups across applications (or even across modules if you're not in full control of the application that will contain the EJB client).
In servlets for mapping I use #WebServlet("/path")
It means, that I can write in form's action "/path" and button click would be handled by my servlet.
In spring mvc I map controller's method as
#RequestMapping("/path")
It means, that I must write in form's action "/webAppName/path" and button click would be handled by my method. But if name of my war file will be change, I must been change mapping on html/jsp. I think it very bad.
Can You help me?
Firstly, you are absolutely wrong. Secondly, what you have mentioned as war file name, is actually context path which even remotely has no relationship with the war name.
Context path is used by the server to refer the webapp running on it. It can be possible that there are multiple applications deployed on your server so, for server to figure out which request is related to which web application context path is required.
The context path of the web application, which is matched against the beginning of each request URI to select the appropriate web application for processing. All of the context paths within a particular Host must be unique. If you specify a context path of an empty string (""), you are defining the default web application for this Host, which will process all requests not assigned to other Contexts.
The value of this field must not be set except when statically defining a Context in server.xml, as it will be inferred from the filenames used for either the .xml context file or the docBase.
And moreover, it has nothing to do with the architecture of the application weather it be Spring MVC or Java Dyanamic Web Application the same thing applies.
Why does the Servlet specification define two distinct ways (context parameters and environment entries) to provide a web application with configuration parameters?
What are the respective advantages of these approaches (when should which be preferred)?
Environment entries are available via JNDI which may be useful when you don't have a ServletContext directly at hands, such as in EJBs. The one in the web.xml is actually the last in precedence chain as to overridding environment entires. They are usually definied in server's own configuration. So if one intends to override a server-specified environment entry from the webapp on, then that could be done via web.xml.
Context parameters are really specific to the webapp itself. They are only available when you have a ServletContext directly at hands, usually only inside filters, servlets (and inherently also JSPs via ${initParam.someName} in EL) and listeners. They are supposed to be used to provide configuration parameters for filters, servlets and/or listeners running in the webapplication. It wouldn't make much sense to provide them by JNDI which is an overcomplicated process for the simple purpose.
When we create Servlet object on JSP page or in Java class, How it works internally ? How it will effect on performance ?
you should not call the servlet explicitly by the new keyword as we normally do.In the case of servlet, servlet container is responsible for instantiating the servlet.
For each servlet defined in the deployment descriptor of the Web application, the servlet container locates and loads a class of the type of the servlet. This can happen when the servlet engine itself is started, or later when a client request is actually delegated to the servlet.
There is only a single instance which answers all requests concurrently. This saves memory and allows a Servlet to easily manage persistent data.
When one create Servlet object on JSP page or in Java class,
You cannot expect to work it as a Servlet.
For More in details answer, Refer BalusC's answer here.
We can create an object of our servlet class. But because servlet operation depends on the servlet context, request, response, etc provided by the web container, there is nothing to be gained by creating one outside the container environment.
In one sentence - By doing so, we cannot expect to work as a servlet.