Is there anyway to change certain web.xml parameters of an already deployed application in the glassfish?
If you change directly in the file-system, no one will understand later, why and when the changes have been done. So this is bad!
But it's easy: Just change the web.xml of the deployed application and restart the glassfish domain. You will find the web.xml somewhere near
/PATH/TO/glassfish3/glassfish/domains/DOMAIN/applications/APP-NAME/WAR-NAME/WEB-INF/web.xml
if deployed in a standalone instance. Otherwise it is somewhere below the ..../nodes folder.
Edit: In a cluster environment, a sync from the deployment manager will override your changes.
Related
After several days of searching, trying and head-banging, I post this question to SO although it seems to be answered already.
Here is the scenario:
I have an EAR application containing (for the moment) one WAR and one EJB module. The EJB module uses JPA (persistence.xml) and some Stateless Session Beans are exposed via Web Services. The web services use Basic authentication with a jdbc realm. The web module uses form authentication with the same realm.
The requirement:
I need to be able to deploy this application either on different servers (dev/test/prod) or on the same server (or cluster) with different deployment descriptors. The deployment settings that need to be different in each application instance are:
The jta-data-source in persistence.xml
The realm-name in web.xml
The javax.faces.PROJECT_STAGE in web.xml
The webservice-endpoint\endpoint-address-uri and login-config\realm in glassfish-ejb-jar.xml
The context-root in application.xml (i could move it to web.xml if it made any difference, see below)
The realm in glassfish-application.xml
During my research, I managed the following:
I can override the javax.faces.PROJECT_STAGE using asadmin set-web-context-param
I can override all settings in glassfish-ejb-jar.xml using a deployment plan during asadmin deploy
The same applies for glassfish-application.xml
I can probably override context-root during asadmin deploy (I don't know how would this work with more than one web modules in the EAR)
So far so good. This leaves me with the following problems:
How can I easily modify the the realm-name in web.xml?
How can I easily modify the jta-data-source in persistence.xml?
By easily I mean during deployment or using something similar to a deployment plan jar. Maintaining multiple copies of ejb.jar or war just with a modified .xml file is not an option.
Just to be clear, the need is to have different databases (either in different stages of development or for different customers) using the same application. The application uses one persistence-unit but it needs to point to different databases (hence the jta-data-source). The realm is a jdbc realm (on the same database) that also needs to be different per application instance.
Any help or pointer would be greatly appreciated.
Have you thought about preparing templates for the deployment descriptors, and populating them with value from property file during build? If you are using ant, you can use the expandproperties filter.
You can do all those things with a deployment plan jar.
It looks like the content of the deployment plan jar is pushed into archive/directory tree of the application BEFORE any of the heavy lifting associated with deployment happens.
See
http://java.net/projects/glassfish/sources/svn/content/trunk/main/appserver/deployment/javaee-core/src/main/java/org/glassfish/javaee/core/deployment/DolProvider.java
and
http://java.net/projects/glassfish/sources/svn/content/trunk/main/appserver/deployment/dol/src/main/java/com/sun/enterprise/deployment/archivist/Archivist.java
I read about this on Tomcat guide here and some SO questions. And I think I'm pretty much doing the same thing. But in some way cannot manage to succeed.
First of all I have to say that my application is deployed on a shared Tomcat server that I have no control over. I just drop my .war file and it gets deployed.
I tried to package my application as ROOT.war but didn't work. The admin told me to package it as whatever the name I want and they would take care of it.
I packaged it as my-application.war and it got deployed but I have to enter http://my-host/my-application to get to the website.
After contacting the admin they told me that they have put a context elemnt in my host in Tomcat config file like:
<Context path="" docBase="path of my-application deployed folder"/>
which was supposed to set my-application as default application for all the requests coming to my-host. But it didn't and whenever I enter http://my-host I get:
HTTP Status 404 - / The requested resource (/) is not available
But again when I enter http://my-host/my-application it all works fine. Any suggestion on what might be wrong is definitely appreciated.
Updates:
I tried to follow the steps described in tomcat documentation on how to make the application default. 3 ways are described and I tried all three ways and could successfully deploy my application as ROOT on localhost.
I also tried to reproduce the problem I'm facing on remote server so I could find the reason and report it to admin. I find couple of problems.
In server.xml fragment that admin sent me autoDeploy and deployOnStartUp are set to true, whereas they should be false if explicitly defining Context element in server.xml. This will cause double deployment which creates a ROOT folder and a folder with the name of the .war file. Deleting the .war will delete it's corresponding folder and undeploys the application but ROOT remains and must be deleted manually and requires a Tomcat restart. Until it's restarted any deployment of ROOT.war will fail.
I figured there are some reasons preventing ROOT.war from deploying. One could be that a ROOT.xml exists in conf/{engine-name}/{host-name} or a ROOT folder exists in appBase of the host or as I described above a ROOT application from previous deployment is not undeployed and requires Tomcat restart.
Either way I couldn't exactly pinpoint what exactly is preventing ROOT.war from deploying since that requires the access to Tomcat log files and conf files to check the cases I described above.
Also from all I see my the admin seems incapable of maintaining a Tomcat server and finding the problem. So I decided to go with a dedicated Tomcat server after struggling with the shared one.
In your question, you state that the admin set the context as:
<Context path="" docBase="path of my-application deployed folder"/>
Based on the comments above, I would suggest trying to use the relative path of your application rather than the absolute path.
I tried this on my tomcat server with:
<Context path="/" docBase="my-application/" />
and that did the trick.
The Host element which contains the Context element does actually set some parameters that might also impact the context. If it's the default settings, then a relative context should simply point to the webapps folder. If it's been changed, the results may vary.
Usually this can be achieved by the following steps:
Define a ROOT.xml context file in conf/Catalina/localhost
Name your webapp WAR “ROOT.war” or containing folder “ROOT”
However, i doubt you will be able to do that on a shared Tomcat instance. Only one application can run as the default application. The hosting company will probably not allow it as otherwise which application will they allow to be the default out of the many people sharing the same Tomcat instance?
See this link : http://staraphd.blogspot.com/2009/10/change-default-root-folder-in-tomcat.html
The Tomcat Wiki has a section on putting applications into default context.
However, in order to do this it implies some control over the Tomcat server that may not be possible in the shared context you describe.
If you have the ability to install other systems on the server, one alternate solution would be to use a proxy server like NGINX. This is way more complicated than simply naming your war file ROOT.war, but sometimes it's the only option.
If you have NGINX listening on the server and you have your own url, you use the HttpProxyModule with setting such as:
server {
listen 80;
server_name my.domain.com;
location / {
proxy_pass http://my-host/my-application;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
}
}
Also in order to make this work, you'd have to own the "my.domain.com" url and it would need to be separate from the one everyone is using for the shared Tomcat server.
The nginx portion of the solution is free, but if you need to register a new url and then use something like no-ip.com to redirect it to the tomcat server it would cost money.
I would like to know if its possible to deploy java class files without restarting JBoss server. I am using jboss v4.2.2.
Also, when I try to deploy jsp files, it works fine and server picks up the changes almost instantly.
Thanks a lot in advance :)
I'm better with Tomcat than JBoss, but it should be possible (as in Tomcat) to restart the application without restarting the app server. If the server has a "development mode" and this is active, then it should be possible to trigger an app restart simply by touching WEB-INF/web.xml, i.e. updating its timestamp. That should get your previously replaced class file loaded.
Theoretically, you never have to restart the whole server, you only restart specific applications (ear-s). JBoss (with default settings) will automatically redeploy your ear if it notices any changes in it. Just copy the new version over it.
If you're not using it already, check out JBoss Tools set of eclipse plugins, to simplify whole process of deploys during development: http://www.jboss.org/tools
Yes, it is possible to re-deploy your class files without stopping and starting the server each time.
The only thing you have to do is to make a junction or a symbolic link to the application directory (in eclipse is usually "WebContent") and put the name you want in Jboss.
I've made a step-by-step tutorial here.
Deploy the app as exploded (project.war folder), add in your web.xml:
<web-app>
<context-param>
<param-name>org.jboss.weld.development</param-name>
<param-value>true</param-value>
</context-param>
Overwrite the web.xml every-time you deploy:
set PRJ_HOME=C:\Temp2\MyProject\src\main\webapp
set PRJ_CLSS_HOME=%PRJ_HOME%\WEB-INF\classes\com\myProject
set JBOSS_HOME= C:\Java\jboss-4.2.3.GA-jdk6\server\default\deploy\MyProject.war
set JBOSS_CLSS_HOME= %JBOSS_HOME%\WEB-INF\classes\com\myProject
copy %PRJ_CLSS_HOME%\frontend\actions\profile\ProfileAction.class %JBOSS_CLSS_HOME%\frontend\actions\profile\ProfileAction.class
copy %PRJ_CLSS_HOME%\frontend\actions\profile\AjaxAction.class %JBOSS_CLSS_HOME%\frontend\actions\profile\AjaxAction.class
ECHO.>>%JBOSS_HOME%\WEB-INF\web.xml
I know that when a war file is created of my web application, i have to deploy it, that is if i am using JBoss i have to copy it to deploy folder and if using WAS i have to install it.
But i want to know, When i start the server from where the server starts deploying my application. that is which is the entry point to start loading my classes, properties ,DB connections etc..
Thanks.
It's the web.xml file, which is known as the deployment descriptor. This is where you configure your servlets and filters. In particular, you map urls to servlets, and this is the entry point into your application. The classes are loaded on startup, before any requests are handled.
Here is a link to more information about deployment descriptors.
Could anyone please tell me, what the meaning of the word "Deploy" and "Redeploy" in context of Tomcat in the following line:
ServletConfig parameters won't change
for as long as this servlet is
deployed an running. To change them,
you'll have to redeploy the servlet
Thanks very much in advance.
When it says "deployed" that means Tomcat read the Servlet definition (usually a web.xml inside a war) and started the Servlet, which is now available for use. This is when ServletConfig parameters are passed to the Servlet.
When it says "redeploy", it means any way you force it to re-read the Servlet definition (which will re-read the ServletConfig parameters).
The easiest way to redeploy a Servlet is to stop Tomcat and start it again. When Tomcat stops, it undeploys everything that was deployed. When Tomcat starts, it deploys everything again.
Restarting the server may be overkill for you if all you want is to have one Servlet re-read its configuration. A faster way (in server time, not necessarily the time it takes you to figure out how to do it) to redeploy a Servlet is called hot deploy. Hot deploying is when you redeploy a Servlet when Tomcat is still running. See the Tomcat documentation for more info on how to do it in Tomcat.
This means that if your server is deployed and running (i.e. working) then your changes will not show up until you redeploy (i.e. stop the server and deploy the code and start again).