Hi Steve,
You're missing something rather non-obvious!
The short answer is:
Here's a more detailed answer:
Internally, Tomcat fetches "resources from the file system" via an
abstract interface called "JNDI" (Java Naming and Directory Interface).
JNDI is geared towards accessing "resources" in a hierarchy,
but says as neutral as possible about what those "resources"
actually are. It's possible to write a JNDI binding that reaches
into LDAP, a file system, zip files, etc. This allows application
code (e.g.: Tomcat) to use a consistent interface for accessing
very different sources of data.
This design allows Tomcat to fetch information from normal files
in a file system, or directly from .war files (which are compressed)
by using different JNDI bindings.
To answer your question: "Where are the files?", answer is:
"Typically, they're accessed via AVMRemote via a custom JNDI binding".
In other words, they're not present in the virt server's 'work' dir at all,
for the most part. There are a small number of places where the
virt server is forced to make local copies of things, but this is kept
to an absolute minimum for efficiency & scalability reasons
(e.g.: the .jar files in staging must be copied locally).
There are a lot of things about the servlet spec & Tomcat that could have
been a lot better (e.g.: even the Valve comes a bit too late in request
processing… and the spec itself only has Filter, which comes much too late),
but the design decision to use JNDI rather than direct access was an
extremely good one. By writing a JNDI binding for AVMRemote,
I was able to allow Tomcat to fetch data from the AVM without requiring
a AVM CIFS mount to be present on the virt server box. It also let me
take advantage of the much richer AVMRemote API.
That said, if your webapp itself accesses a "file system"
via depreciated servlet methods like getRealPath(), or if you
also have an Apache2 instance pointing at "the files", then
clearly you need the AVM CIFS mount on the virt server machine.
If this is the case, then then everything that can be accessed via
the JNDI/AVMRemote binding will still be done that way, but if
you've got application-level code that really wants to see "a file",
the CIFS mount gives you that. How you ask? Well… because
the JNDI naming scheme used by the virt server was designed
to line-up with the AVM file system projection used by our
CIFS projection. Thus, getRealPath() returns a "file name"
that's actually real if you've mounted CIFS in the place you've
declared via the attribute:
The virtualization server is also playing a lot of games when it comes
to transparent overlays, classloaders, area-specific filters, JMX,
and so on, but I think getting into that stuff would be better done
in a whitepaper (one of these days!).
I hope the "terse" and/or "more detailed" answers were helpful.
Thanks for the great question.
Cheers,
-Jon
PS:
For a quick primer on JNDI see:
http://www.javaworld.com/javaworld/jw-01-2000/jw-01-howto.html
You're missing something rather non-obvious!
The short answer is:
"The tomcat virtualization server is accessing files via a JNDI/AVMRemote binding"
Here's a more detailed answer:
Internally, Tomcat fetches "resources from the file system" via an
abstract interface called "JNDI" (Java Naming and Directory Interface).
JNDI is geared towards accessing "resources" in a hierarchy,
but says as neutral as possible about what those "resources"
actually are. It's possible to write a JNDI binding that reaches
into LDAP, a file system, zip files, etc. This allows application
code (e.g.: Tomcat) to use a consistent interface for accessing
very different sources of data.
This design allows Tomcat to fetch information from normal files
in a file system, or directly from .war files (which are compressed)
by using different JNDI bindings.
To answer your question: "Where are the files?", answer is:
"Typically, they're accessed via AVMRemote via a custom JNDI binding".
In other words, they're not present in the virt server's 'work' dir at all,
for the most part. There are a small number of places where the
virt server is forced to make local copies of things, but this is kept
to an absolute minimum for efficiency & scalability reasons
(e.g.: the .jar files in staging must be copied locally).
There are a lot of things about the servlet spec & Tomcat that could have
been a lot better (e.g.: even the Valve comes a bit too late in request
processing… and the spec itself only has Filter, which comes much too late),
but the design decision to use JNDI rather than direct access was an
extremely good one. By writing a JNDI binding for AVMRemote,
I was able to allow Tomcat to fetch data from the AVM without requiring
a AVM CIFS mount to be present on the virt server box. It also let me
take advantage of the much richer AVMRemote API.
That said, if your webapp itself accesses a "file system"
via depreciated servlet methods like getRealPath(), or if you
also have an Apache2 instance pointing at "the files", then
clearly you need the AVM CIFS mount on the virt server machine.
If this is the case, then then everything that can be accessed via
the JNDI/AVMRemote binding will still be done that way, but if
you've got application-level code that really wants to see "a file",
the CIFS mount gives you that. How you ask? Well… because
the JNDI naming scheme used by the virt server was designed
to line-up with the AVM file system projection used by our
CIFS projection. Thus, getRealPath() returns a "file name"
that's actually real if you've mounted CIFS in the place you've
declared via the attribute:
alfresco.virtserver.cifs.avm.versiontree.win=…alfresco.virtserver.cifs.avm.versiontree.unix=…$VIRTUAL_TOMCAT_HOME/conf/alfresco-virtserver.propertiesThe virtualization server is also playing a lot of games when it comes
to transparent overlays, classloaders, area-specific filters, JMX,
and so on, but I think getting into that stuff would be better done
in a whitepaper (one of these days!).
I hope the "terse" and/or "more detailed" answers were helpful.
Thanks for the great question.
Cheers,
-Jon
PS:
For a quick primer on JNDI see:
http://www.javaworld.com/javaworld/jw-01-2000/jw-01-howto.html
You're welcome.
Exactly what is it you're trying to do?
Most of the time, when people are curious about this stuff
it's because they either have a webapp that uses getRealPath()
or they want to use Apache2 in addition to tomcat & want to know
the best place to do a CIFS mount – the answer there is simple:
make the CIFS mount point match where ever you said it was going to be
in $VIRTUAL_TOMCAT_HOME/conf/alfresco-virtserver.properties
On the other hand, if you were just curious, that's fine too.
Exactly what is it you're trying to do?
Most of the time, when people are curious about this stuff
it's because they either have a webapp that uses getRealPath()
or they want to use Apache2 in addition to tomcat & want to know
the best place to do a CIFS mount – the answer there is simple:
make the CIFS mount point match where ever you said it was going to be
in $VIRTUAL_TOMCAT_HOME/conf/alfresco-virtserver.properties
On the other hand, if you were just curious, that's fine too.
