On 3/31/2014 9:43 AM, Sebastien Tardif wrote:
I understand that Tomcat currently doesn't always support specifying
the context root to be used in a file inside the War.
Extract from:
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html When
autoDeploy or deployOnStartup operations are performed by a Host, the
name and context path of the web application are derived from the
name(s) of the file(s) that define(s) the web application.
Consequently, the context path may not be defined in a
META-INF/context.xml embedded in the application and there is a close
relationship between the context name, context path, context version
and the base file name (the name minus any .war or .xml extension) of
the file.
Other web server handle this better, like GlassFish and it's very
convenient. Usability is something we should try to achieve.
Since, in all cases, the War will need to be "read" anyway, how hard
or costly that can be to lookup a configuration file and read it?
I think we cannot mentions "performance" reasons for current behavior
since everything else that need to be done will always be x factor
way slower. It's like optimizing string concatenation become calling
a database, that makes me laugh in each project I work on.
That issue is the only one that makes the infamous GlassFish looks
better so I wanted to raise it.
I humbly disagree. What follows is my (somewhat rambling) opinion.
If I remember correctly, the decision to derive a context path from the
WAR file name was driven by lots of not so fun deployment race
conditions, double deployment issues, and non-obvious deployment
difficulties.
The Tomcat users mailing list archive is littered with examples.
If you want to name your WAR file or exploded directory 'foo.war' or
'foo/', but want your context to be '/bar', then deploy outside of
appBase, name the context file bar.xml, and set docBase to the absolute
path of the application.
This is for example, what NetBeans does when working with Tomcat. It's
nice, avoids copying lots of information around, and makes IDE updates
immediately available (OK - libraries and class updates trigger a
reload) all in the confines of the 'Tomcat way'.
I don't see any good use cases for this, and lots of room for confusion.
It's much easier to fix your build and deploy tools to create rational
names matching the desired context. If that's not possible, deploy
outside of appBase, and use a context file named context-name.xml in
$CATALINA_BASE/conf/host-name/.
As far as Glassfish versus Apache Tomcat goes, they address different
use cases. Glassfish is a J2EE application server. Apache Tomcat is a
servlet container. While you can convince Apache Tomcat to do a lot of
things, at some point it's better to run an application server if your
requirements dictate it. Apache TomEE is a good choice.
BTW, I like Glassfish and Apache TomEE. It just depends on my use case.
Concerning string concatenation, I think you would be surprised. Since
strings are immutable, concatenating strings is very expensive if you're
doing more than a few. I believe I read somewhere that concatenating 'n'
strings is proportional to the quadratic of n. In short, ouch. Are there
better places to spend time on optimization? Probably, but this depends
on your application. Is concatenating 100 strings using the
concatenation operator needlessly expensive? Most probably.
. . . just my two cents.
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
