OK thanks Yoav. Interesting insights.
PS I hope my comments on warfiles didn't come across as saying that there is
no point in them. That certainly wasn't what I meant. I very much see the
point of warfiles, I just meant to explain why I haven't used them so far:
for me personally, webapp portability has never been a big issue, so it has
been easier not to use warfiles when making lots of changes during
development.
I hadn't appreciated that there were subtle functional differences between
using a warfile and just storing the files in the "open"/"unpacked"
directory tree, such as the ability to include a context.xml in the webapp.
I also hadn't realised that the servlet spec does not require support for
the "unpacked" mode that I have been using, and that only packed war files
need to be supported. Where does the spec say this - I've looked at it
again just now, but can't find it.
>From previous readings of the servlet spec, I thought that whether packed
into a warfile or deployed in an "open" directory tree, the webapp would
work the same, so both of the points in my last paragraph were surprises.
I've just been through the spec again quickly, but the only bits that I can
find which seem relevant are section SRV.9.6 ("Web Application Archive
File") and the "web application" glossary entry, which both seem to imply
that using warfiles is optional...?
Also, the servlet spec doc does not seem to refer to "context.xml" files at
all, which seems odd given that they seem to be designed to increase
portability. Are they spec'd/recommended somewhere else than in the jsr154
docs, or are they in fact a TC feature?
> -----Original Message-----
> From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
> Sent: Tuesday 26 October 2004 18:11
> To: Tomcat Users List
> Subject: RE: JNDI DataSource GlobalResources problem
>
>
>
> Hi,
>
> >So, I am currently including my webapp's <Context> in
> >conf/Catalina/localhost/mywebapp.xml, which is sub-optimal for 2
> reasons:
> >1. it's outside the webapp directory
> >2. the path depends on the server configuration - not predictable
>
> These server-specific configuration files, unlike web.xml,
> are not yours
> to control from the J2EE/Servlet Spec point of view. They
> belong to the
> server admin. So their location, contents, and handling need not be
> predictable for the application developer. They're server-specific,
> implementation-dependent, not portable.
>
> >It seems that it would be neater if the context xml file were within
> the
> >webapp directory. Is there a reason why it is in fact read from
> >conf/Catalina/localhost at atartup? Why not from within a defined
> location
> >in each webapp?
>
> We like to keep Tomcat's configuration info inside the conf directory.
> The reason it's nested in conf/[engine]/[host] is to allow
> webapps with
> the same names within different engines or hosts on the same server.
>
> >PS the reason I don't use wars is that while developing, I can't see
> the
> >point in packaging a war up after every change, only then to
> unpack it
> when
> >I restart TC. Might as well change the files directly.
>
> Whether you can see the point or not is irrelevant, as Tomcat
> offers you
> the choice of deploying and developing in both packed and unpacked WAR
> formats. The Servlet Spec only requires us to support deploying and
> running packed WAR archives, so again this is an example of something
> we've provided by request of the user community to ease
> *some* people's
> lives.
>
> The point in always deploying and running from a packed WAR
> is to ensure
> portability. If you don't see that point, disagree with it,
> or find it
> inefficient, that's fine, you're obviously free to do as you
> want. But
> the point is there and it's important to those of us who have to deal
> with heterogeneous server environments all the time.
>
> >PS what does TC do with the context.xml file when it reads it from a
> war,
> >does it copy it somewhere?
>
> Yes, into the conf/[engine]/[host]/appname.xml file.
>
> Yoav
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
