Develop Reference

Servlets in separate WARs - partially sharing their context root

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.

Is the jndi.properties file required for a EJB + web application (JBoss 5)?

In a JBoss 5 JEE project which I have inherited, the web application (WAR) project contains a JNDI configuration file which seems to be unneccessary. Its content is
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
java.naming.provider.url=localhost:1099
Removing it has no obvious effect, deployment and execution works well and unit tests show no errors.
Is it safe to delete this file?

You would create that file if you want to create a -client- that connects to a JNDI context to invoke EJBs remotely. If that war is part of the application that serves the EJB, you indeed do not need it since you already have local access to the JNDI context. Assuming the war is part of an EAR that also holds the EJB module.

Glassfish: modify deployment descriptors for EAR during deployment

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

external configuration on classpath per application in jboss

i'm completely noob with jboss administration. i want to have a few applications (wars) on jboss. each of them should have external configuration - file or better directory, available on classpath. and of course one application must not see configuration of other application. they must have completely different classpath. is it possible to do that? how?

You can configure your server profile to pick up applications from several external folders( https://community.jboss.org/wiki/HowToDeployMyApplicationInAnExternalDirectoryInJBoss-5?_sscc=t ) and then just set permission for each of that folder

Put authentication/login configuration inside PROJECT

I implemented a custom login module I want to use with the JBoss AS 6. I followed some tutorial guidelines on the internet, namely http://x-techteam.blogspot.com/2007/04/jboss-custom-login-module-simple.html.
They write about configuring ${JBOSS_HOME}/server/default/conf/login-config.xml and deploy a JAR with the custom login module, but I don't like the idea of changing a configuration within the JBoss folder.
I really would like to have ALL configurations within my WAR file. The EE application I write will be sent to some customers and they should not have to worry about configuring some security contexts or roles via XML.
So my question is:
Can I have a local login-config.xml within my war that will be picked up by JBoss?
Can the custom login module class remain within my war, without having to deploy it to some JBoss folder?
Thank you in advance.

Use dynamic security domains:
link