virtualClasspath equivalent in tomcat 8 - java

I am deploying instance of tomcat 8 and trying to find equivalent of virtualClasspath.
Below is the snippet of configuration descriptor I had in Tomcat 7,
<Context path="/path">
<Loader className="org.apache.catalina.loader.VirtualWebappLoader" virtualClasspath="/home/kedar/third_party_jars/*.jar" />
</Context>
How can I specify the similar thing in tomcat 8. To be more specific, how to include multiple third party jars(as above) under classpath in the configuration descriptor of tomcat 8?
We can include each jar one by one in the following way, but I am looking some regex kind of way to include multiple jars.
<Resources className="org.apache.catalina.webresources.StandardRoot">
<PostResources className="org.apache.catalina.webresources.JarResourceSet"
base="/home/kedar//third_party_lib/xyz.jar"
internalPath="/"
webAppMount="/WEB-INF/classes" />
</Resouces>
Thanks in advance

Related

Specify root context for web application in wildfly 8 at deployment

Is it possible to override the root context specified in WEB-INF/jboss-web.xml at deploy time?
I have this jboss-web.xml
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<context-root>my-context</context-root>
</jboss-web>
And I want to be able to deploy the application with different root context in in e.g. /another-context for some of my environments, but keep /my-context in other environments.
You can do this via WildFly Maven Plugin (as part of your CI job) or using the WildFly CLI.
The maven variant would be like the following command:
org.wildfly.plugins:wildfly-maven-plugin:deploy-only
-Dwildfly.deployment.filename=app.war
-Dwildfly.deployment.runtime.name=appcontext.war
The app will be deployed under /appcontext.
Note, you should remove the context-root from your jboss-web.xml otherwise this value will win always.
The CLI variant could look like (documentation):
[dply#as wildfly-8.2.0.Final]$ bin/jboss-cli.sh
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] connect
[standalone#localhost:9990 /] deploy /path/to/app.war --runtime-name=appcontext.war
For doing this, you could combine maven profiles (e.g. "my-context" and "another-context") and maven resource filtering as explained here: Maven resource filters
It certainly takes a little bit of time until everything works as expected.
if you have a EAR file you need to define it at your application.xml
<module>
<web>
<web-uri>webapp.war</web-uri>
<context-root>/my-context</context-root>
</web>
</module>

How to deploy a war file in JBoss AS 7?

I downloaded JBoss Application Server 5 and successfully deployed a war file. I copypasted the Hello.war which has a simple index.jsp file into
\jboss-5.1.0.GA-jdk6\jboss-5.1.0.GA\server\default\deploy
and it worked fine.
However when I used JBoss AS 7 and deployed the war file here, it did not get executed.
jboss-as-7.0.0.Final\jboss-as-7.0.0.Final\standalone\deployments
How to deploy it?
EDIT: I googled it but was not able to find info as JBoss AS 7 is relatively new.
Actually, for the latest JBOSS 7 AS, we need a .dodeploy marker even for archives. So add a marker to trigger the deployment.
In my case, I added a Hello.war.deployed file in the same directory and then everything worked fine.
Hope this helps someone!
Read the file $AS/standalone/deployments/README.txt
you have two different modes : auto-deploy mode and manual deploy mode
for the manual deploy mode you have to placed a marker files as described in the others posts
for the autodeploy mode : This is done
via the "auto-deploy" attributes on the deployment-scanner element in the
standalone.xml configuration file:
<deployment-scanner scan-interval="5000" relative-to="jboss.server.base.dir"
path="deployments" auto-deploy-zipped="true" **auto-deploy-exploded="true"**/>
I built the following ant-task for deployment based on the jboss deployment docs:
<target name="deploy" depends="jboss.environment, buildwar">
<!-- Build path for deployed war-file -->
<property name="deployed.war" value="${jboss.home}/${jboss.deploy.dir}/${war.filename}" />
<!-- remove current deployed war -->
<delete file="${deployed.war}.deployed" failonerror="false" />
<waitfor maxwait="10" maxwaitunit="second">
<available file="${deployed.war}.undeployed" />
</waitfor>
<delete dir="${deployed.war}" />
<!-- copy war-file -->
<copy file="${war.filename}" todir="${jboss.home}/${jboss.deploy.dir}" />
<!-- start deployment -->
<echo>start deployment ...</echo>
<touch file="${deployed.war}.dodeploy" />
<!-- wait for deployment to complete -->
<waitfor maxwait="10" maxwaitunit="second">
<available file="${deployed.war}.deployed" />
</waitfor>
<echo>deployment ok!</echo>
</target>
${jboss.deploy.dir} is set to standalone/deployments
Can you provide more info on the deployment failure? Is the application's failure to deploy triggering a .war.failed marker file?
The standalone instance Deployment folder ships with automatic deployment enabled by default. The automatic deployment mode automates the same functionality that you use with the manual mode, by using a series of marker files to indicate both the action and status of deployment to the runtime. For example, you can use the unix/linux "touch" command to create a .war.dodeploy marker file to tell the runtime to deploy the application.
It might be useful to know that there are in total five methods of deploying applications to AS7. I touched on this in another topic here : JBoss AS7 *.dodeploy files
I tend to use the Management Console for application management, but I know that the Management CLI is very popular among other uses also. Both are separate to the deployment folder processes. See how you go with the other methods to fit your needs.
If you search for "deploy" in the Admin Guide, you can see a section on the Deployment Scanner and a more general deployment section (including the CLI): https://docs.jboss.org/author/display/AS7/Admin+Guide
Just copy war file to standalone/deployments/ folder, it should deploy it automatically. It'll also create your_app_name.deployed file, when your application is deployed. Also be sure that you start server with bin/standalone.sh script.
open up console and navigate to bin folder and run
JBOSS_HOME/bin > stanalone.sh
Once it is up and running just copy past your war file in
standalone/deployments folder
Thats probably it for jboss 7.1

How to configure EAR to access exisiting Websphere Shared Lib?

I am using JSF2 with Websphere 7 . I have created a shared lib successfully and have pointed application using Webpsphere Admin Console and it works successfully . But what we really want to do is to not have to point to that Shared Lib via WAS Admin Console but have some sort of application level configuration e.g in deployment.xml etc which we can point to the name of that Shared Isolated Lib and use it . I have gone through SO and google but not found any thing doing that . I however know that there are commercial application doing it but do not know how . This question from How can I specify a shared library reference at the web module level in Websphere 6.1 deployment descriptors? is closely what I am after but I not want to specify version numbers or jar names as the answer states
I found a way by simply following what WAS Admin Console was actually doing.
Create a deployment.xml in your EAR file if you do not have one already .
You will find a reference to class loader like below
<classloader xmi:id="Classloader_1311552732281" mode="PARENT_FIRST">
Modify it and add reference to the shared Liberary created on server like below
<classloader xmi:id="Classloader_1311552732281" mode="PARENT_FIRST">
<libraries libraryName="JSF2_SHARED_LIB" sharedClassloader="true"/>
</classloader>
#dbreaux has also shown a way .Accpeting my own answer as fits my needs better but big thanks to dbreaux too for advice.
Is the issue just that you don't want to have to configure each application separately, or that you don't want to use the admin console at all? You can associate a shared library with an entire server, which might be preferable to doing it for each app.
The other way to create those application associations is in the WebSphere-specific .xmi deployment files. These are created when you deploy but can also be included in WAR/EAR files. I don't know if that would help you at all. If it would, the official way to create them ahead of time is using one of the Deployment Tools, but since they're just XML, you may feel comfortable creating them manually.
To append extra details to Shahzeb's answer:
My environment: Websphere 8.5; Windows 7;(Eclipse Luna to generate testing .war file)
I have installed the war file exported from eclipse on websphere server by websphere console.
Then exported it again and unpack it to see what websphere automatically add to it to generate EAR.
[folder]META-INF
[folder]ibmconfig
[file]application.xml
[file]ibm-application-bnd.xmi
[file]ibm-application-runtime.props
[file]MANIFEST.MF
[file]was.module
[file]was.policy
[file]was.webmodule
[file]myWAR.war
And the file deployment.xml is placed in
..\ibmconfig\cells\defaultCell\applications\defaultApp\deployments\defaultApp\
whose content in form of
<?xml version="1.0" encoding="UTF-8"?>
<appdeployment:Deployment xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:appdeployment="http://www.ibm.com/websphere/appserver/schemas/5.0/appdeployment.xmi" xmi:id="Deployment_1417052686904">
<deployedObject xmi:type="appdeployment:ApplicationDeployment" xmi:id="ApplicationDeployment_1417052686904" deploymentId="0" startingWeight="1" binariesURL="$(APP_INSTALL_ROOT)/[server service name]Cell/myWAR.ear" useMetadataFromBinaries="false" enableDistribution="true" createMBeansForResources="true" reloadEnabled="false" appContextIDForSecurity="href:[server service name]Cell/myWAR" filePermission=".*\.dll=755#.*\.so=755#.*\.a=755#.*\.sl=755" allowDispatchRemoteInclude="false" allowServiceRemoteInclude="false" asyncRequestDispatchType="DISABLED" standaloneModule="true" enableClientModule="false">
<targetMappings xmi:id="DeploymentTargetMapping_1417052686904" enable="true" target="ServerTarget_1417052686904"/>
<classloader xmi:id="Classloader_1417052686904" mode="PARENT_FIRST"/>
<modules xmi:type="appdeployment:WebModuleDeployment" xmi:id="WebModuleDeployment_1417052686904" deploymentId="1" startingWeight="10000" uri="myWAR.war" containsEJBContent="0">
<targetMappings xmi:id="DeploymentTargetMapping_1417052686905" target="ServerTarget_1417052686904"/>
<classloader xmi:id="Classloader_1417052686905"/>
</modules>
<properties xmi:id="Property_1417052686904" name="metadata.complete" value="true"/>
</deployedObject>
<deploymentTargets xmi:type="appdeployment:ServerTarget" xmi:id="ServerTarget_1417052686904" name="server1" nodeName="[server service name]"/>
</appdeployment:Deployment>
(Since I have no reputation, I have to do it all in text.. )

Can I create a custom classpath on a per application basis in Tomcat

For some applications I use ZK, others Hibernate, other Apache Commons, etc.
I don't want to deploy a 75MB war file, just because it uses lots of libraries.
I don't want to add the libraries to my tomcat lib folder, or nor the classpath to it's configuration as I may have an old application using library x.1 and another application using library x.2
For this reason, it would be great to have something in the web.xml or context.xml where I say something like:
<classpath>/usr/local/tomcat/custom-libs/zk-5.0.4</classpath>
Note: The above is pseudo-code
From Tomcat 7 there is no mention of not being able to use the VirtualWebappLoader in production. I tried it and it works like a dream. Simply add the following to META-INF/context.xml:
<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/websandbox">
<Loader className="org.apache.catalina.loader.VirtualWebappLoader"
virtualClasspath="/usr/.../*.jar;/usr/.../*.jar"/>
</Context>
In Netbeans, under packaging, I just untick all the packages, taking the .war size down to nothing, make sure the dependencies are in the correct folders on the server and upload. Yey! No more 100 MB WAR file.
Addition #Spider answer.
Tomcat Context hold Loader element. According to docs deployment descriptor (what in <Context> tag) can be placed in:
$CATALINA_BASE/conf/server.xml - bad - require server restarts in order to reread config
$CATALINA_BASE/conf/context.xml - bad - shared across all applications
$CATALINA_BASE/work/$APP.war:/META-INF/context.xml - bad - require repackaging in order to change config
$CATALINA_BASE/work/[enginename]/[hostname]/$APP/META-INF/context.xml - nice, but see last option!!
$CATALINA_BASE/webapps/$APP/META-INF/context.xml - nice, but see last option!!
$CATALINA_BASE/conf/[enginename]/[hostname]/$APP.xml - best - completely out of application and automatically scanned for changes!!!
Here my config which demonstrate how to use development version of project files out of $CATALINA_BASE hierarchy (note that I place this file into src/test/resources dir and intruct Maven to preprocess ${basedir} placeholders through pom.xml <filtering>true</filtering> so after build in new environment I copy it to $CATALINA_BASE/conf/Catalina/localhost/$APP.xml):
<Context docBase="${basedir}/src/main/webapp"
reloadable="true">
<!-- http://tomcat.apache.org/tomcat-7.0-doc/config/context.html -->
<Resources className="org.apache.naming.resources.VirtualDirContext"
extraResourcePaths="/WEB-INF/classes=${basedir}/target/classes,/WEB-INF/lib=${basedir}/target/${project.build.finalName}/WEB-INF/lib"/>
<Loader className="org.apache.catalina.loader.VirtualWebappLoader"
virtualClasspath="${basedir}/target/classes;${basedir}/target/${project.build.finalName}/WEB-INF/lib"/>
<JarScanner scanAllDirectories="true"/>
<!-- Use development version of JS/CSS files. -->
<Parameter name="min" value="dev"/>
<Environment name="app.devel.ldap" value="USER" type="java.lang.String" override="true"/>
<Environment name="app.devel.permitAll" value="true" type="java.lang.String" override="true"/>
</Context>
UPDATE Tomcat 8 change syntax for <Resources> and <Loader> elements, corresponding part now look like:
<Resources>
<PostResources className="org.apache.catalina.webresources.DirResourceSet"
webAppMount="/WEB-INF/classes" base="${basedir}/target/classes" />
<PostResources className="org.apache.catalina.webresources.DirResourceSet"
webAppMount="/WEB-INF/lib" base="${basedir}/target/${project.build.finalName}/WEB-INF/lib" />
</Resources>
Another a bit hacky alternative.
You can write a 5-6 line custom class loader which derives from urlclassloader, and simply adds your classpath jars using addUrl() method.
Then set it as the context class loader of the thread in your application code.
Thread.setContextClassLoader(new CustomClassloader(path, parentClassLoader)
where parent class loader typically is
Thread.getContextClassloader()
This is what the META-INF/context.xml file can be used for. You defined your own WebappLoader, which loads classes for your particular webapp. This is the reference I used: http://tomcat.apache.org/tomcat-5.5-doc/config/loader.html (Edit: for Tomcat 6: http://tomcat.apache.org/tomcat-6.0-doc/config/loader.html, for Tomcat 7: http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html)
Also this fellow here seems to post a solution to your exact problem (example included): http://java.dzone.com/articles/extending-tomcat-webapploader

How to deploy the same webapp with different logging? (Tomcat, Solr)

We are using multiple solr instances on tomcat but want that they log into different log files. How could we do this?
We are using the follwing xml file under tomcat/conf/Catalina/localhost to make it working:
<Context docBase="/pathtosolr/dist/apache-solr-1.4.0.war" debug="0" crossContext="true" >
<Environment name="solr/home" type="java.lang.String" value="/pathtosolr/solr" override="true" />
</Context>
Update: From Jems answer I found this documentation:
Tomcat offers a choice between settings for all applications or settings specifically for the Solr application.
To change logging settings for Solr only, edit tomcat/webapps/solr/WEB-INF/classes/logging.properties. You will need to create the classes directory and the logging.properties file. You can set levels from FINEST to SEVERE for a class or an entire package. Here are a couple of examples:
org.apache.commons.digester.Digester.level = FINEST
org.apache.solr.level = WARNING
Alternately, if you wish to change Tomcat’s JDK Logging API settings for every application in this instance of Tomcat, edit tomcat/conf/logging.properties.
See the documentation for the SLF4J Logging API for more information:
http://slf4j.org/docs.html
You might wanna take a look at this page: http://globalgateway.wordpress.com/2010/01/06/configuring-solr-1-4-logging-with-log4j-in-tomcat/
There seems to be no good solution:
2008 and 2010
except repacking the solr.war file with a different logging configuration file.
Update: see accepted answer!

Categories