Develop Reference

is it possible to add jar(with web-fragment.xml) at runtime(means after startup)

I want to add pluggable jar i.e. the jar with web-fragment.xml after server is up-and-running. and perform the scanning of this jar and initialize servlet components defined in web-fragment.xml of newly added jar.
If this is not possible please explain the reason.

Each Java EE application is atomic. It is deployed and undeployed entirely. You can't change application without redeploy. So it is not possible.
Correct solution is differ. You should deploy independent application and provide pluggable interfaces between main application and such plugins. Technical details are depends from situation. E.g. JSF has resource-handler. You can write special class (need be registered in faces-config.xml) for loading JSF pages from nonstandard place.

Can I have two web.xml files in a single web application?

Can i Have a single application with more than one web.xml files? And can two applications have a parent child relationship so that there are two web.xml?

For below servlet 3.0 you cannot.
If you are using 3.0 there is a possibility.
In JSR 315: Java Servlet 3.0 Specification, web-fragment.xml is introduced for pluggability of library jars which are packaged under WEB-INF/lib. The content of web.xml and web-fragment.xml are almost the same. One can define servlets, filters and listeners there. One can also specify metadata-complete=true in a given web-fragment.xml. In the latter case, the annotation processing of classes in that jar would be skipped. With web-fragment.xml, library jars can be self-contained and provide web related metadata information.
For sure, having two xml creates confusion and besides all, If you explain whats your exact requirement, you'l get a good/standard solution for your problem.

Can i Have a single application with more than one web.xml files?
It depends on the approach.
Approach 1
If you are working in an environment where there are certain servlets (I remember I worked on an old project where there was a Minification servlet and its purpose was to minify the JS/CSS at deploy time) and settings like e.g certain user-contraints and realms that you don't want configured on your development environment since you will be working with exploded JS/CSS and you want to bypass basic secuirty constraints configured in the application just for ease of development but you want them all tested out on QA , so it "sort of" of makes sense to have 2 different deployment descriptors configured for the same application. One in which you have only the basic settings to just deploy the application for development and on the other you have all your production settings that you want tested out on QA from A to Z.
But again, I want to make it clear that you can deploy you application using only ONE deployment descriptor.
Approach 2
Lets say you want your deployment descriptor to be broken down into small parts for plugg-ability purpose like you define your Servlets in one file and you define your securutiy constraints in other file. These files or web-fragments.xml can only work with Servlet3.0. If you look closely to how these fragments are used, at deploy time all these fragments are merged and read by the container as a "single" file (the deployment descriptor).
So in the end , we again wind up with a SINGLE deployment descriptor for the application.

How to run one JSF WAR file in second JSF project?

I am working on project in JSF, using Tomcat 7. The application will have two parts - the presentation and the administration, main part is about the administration. What I want to do is to create something like a web library.
To have this more clear, I'll try to show structure of the project:
The main application project (let's call it admin) that is builed into WAR file.
Second project using the first one (let's call it presentation).
Presentation is using the admin WAR file.
both projects are typical JSFs - admin has pages, beans, etc.
In NetBeans, I have no problem with adding WAR file as a library, but, there are two things. The first: are all ManagedBeans in admin initialized together with presentation run, so I can use them in presentation? The second: how do I access pages from presentation that are located in admin?
Maybe I am wrong about this idea and I should use different way how to achieve this - so just tell me please.
Also, I probably will not be able to deploy two war files and run them - most of the hostings where the application will run allow deploying of one WAR file only.

Make it a common JAR instead of WAR, so that you can include it in both WARs. This way you can share managed beans and templates between both WARs. The Facelets resources can just be placed in /META-INF/resources of the JAR. The JSF artifacts like managed beans will be auto-discovered if you provide a /META-INF/faces-config.xml file.
See also:
Structure for multiple JSF projects with shared code

Sharing JSPs between EARs

Is it possible to share JSPs between EARs, similar to the way that we can share Java files between EARs by using .jar files?
I have a large J2EE app on JBoss with many different EARs, and they all should have the same header, footer, etc... I would rather not copy and paste these files a dozen times whenever a change needs to be made.

Tag files can be packaged in a jar.
They are JSP files with a ".tag" extension. They can be parameterized.

I have never tried but logically speaking you can very well do it by putting all your JSP's into a common folder

I think of it as accessing a different servlet context from the one you are in. Something like
Enterprise.ear
WAR1 /somewhere
WAR2 /somewhereElse
WAR3 /shared
Assuming a JSP in WAR1 bound to /somewhere:
Reference the shared context with the optional 'context' attribute of the c:import tag (Standard JSTL tag). By default c:import uses the context it is in, which in war1 is /somewhwere.
<c:import url="/header.jsp" context="/shared"/>
There are probably other ways... Perhaps just ignore your ear and just go with a full http request:
<c:import url="http://www.somewhere.com/header.jsp"/>
I'm not certain on the syntax of the context attribute on the c:import tag. But I believe that is the correct syntax (with the slash verse without, it might not matter).

Use sitemesh.
There is no need to change anything in the existing application. Create a fresh war with sitemesh. It can decorate content from multiple urls dynamically.
http://raibledesigns.com/rd/entry/use_sitemesh_to_decorate_multiple
--Kiran.kumar

Tomcat parent webapp shared by configurable children webapps

Currently, we support many clients using the same web app, but each client has a different configuration for accessing their database, setting files etc. As the client list grows, updating the web apps is becoming increasingly arduous, and the duplication of resources is a waste of memory, file space, etc..
What we'd like to do is have a parent web app which is shared by all children web apps. Then have each child web app carry only files specific to them. When the child web app starts up, Tomcat loads the web app from the parent web app and then overrides any files defined in the child web app following an identical package structure.
We've been googling around and haven't found a ready or complete solution. Solutions we've looked at:
Tomcat common/share - could handle class and JAR files, but we don't see a way to handle static and JSP resources residing above the WEB-INF dir.
CATALINA_BASE appears to be more suited for running multiple instances of Tomcat which we'd rather avoid
A Maven possible solution, but we are not big fans of Maven, so would rather avoid it also.
Anybody have suggestions or ideas on how to solve this? If Tomcat configuration is not possible, what about a different application server (such as Glassfish) or a tool for doing dynamic file updated (such as OSGi, rsync). Would like to remove the resource duplication if possible.
Thank you.

There is no such thing as "parent" or "child" webapps. It's not part of J2EE spec and AFAIK it's not supported by any application server.
That said, your problem is twofold:
1) Having shared resources. This part is pretty easy assuming "resources" means static resources (images / CSS / javascript / etc...).
If they are truly shared (e.g. you don't need to have a separate version in some of your webapps), host them elsewhere (separate "common" webapp or put Apache in front of your Tomcat and host them there.
If you do need to have "local" versions of some of those resources you may be able to do some clever conditional URL rewriting or simply write a servlet that would check whether particular resource exists locally and, if not, take it from "common" location.
Precompile your JSPs so you only have to deal with JARs.
If your Tomcat instance only hosts your apps, you can indeed put your JARs in shared (or lib in the latest version); otherwise you can deploy them with each application .
2) Simplifying deployment. I'm not really sure what the big problem is here... It's rather trivial to write an Ant (batch, shell, what have you) script that would assemble and deploy WARs based on "common" and "per-app" directory structures.
Alternatively, you may want to take a look at using JNDI to severely reduce the number of files that have to be deployed (in theory, to a single context.xml for each application).

You can build parent-child hierarchy if you use Spring at your web-apps - Using a shared parent application context in a multi-war Spring application.
I.e. you can define all shared stuff at the 'parent' context and have 'child' contexts just to use it.

If all you had was setting file and configuration changes you could manage these through the context.xml and then you can point the docBase of each application context at a common directory for all the applications to share the same source.
the drawback to this is changes to the application will require a tomcat restart.
This does not however solve your problem if you want to override logic.
A option that I am exploring for a similar scenario is to move the client custom portion into ajax widgets / gadgets. Then have it be part of the configuration files to tell the application which version of the gadget to pull for which client.
you can review documentation for having applications share a docbase here http://tomcat.apache.org/tomcat-5.5-doc/config/context.html