The virtualization server errs on the side of being extremely
permissive with respect to the servlet spec. I'm not sure what
SVN build you're working with, but the most recent versions of
the virtualization server are even able to handle the degenerate
case of a war file created like this:
% mkdir my_empty_dir
% cd my_empty_dir
% jar cvf xxx.war .
To see what's inside you can do this:
% jar tvf xxx.war
0 Sat Jan 27 19:54:04 EST 2007 META-INF/
71 Sat Jan 27 19:54:04 EST 2007 META-INF/MANIFEST.MF
In the future, it might even be possible to lift all servlet
spec requirements. If this is a high priority for you, let me know.
My hope is that by allowing degenerate webapp war files like this,
the relatively infrequent operation of creating a new web project
won't be too onerous for those who only want a static site. Preserving
this skeletal webapp structure has made the implementation simpler,
and on the initial release that's obviously a major consideration.
Once you have a war file, whether it contains a "real" webapp,
or something as minimal as an empty META-INF/MANIFEST.MF,
you can then create a website named "mysite", with users "alice"
and "bob" as invitees, go to the staging sandbox and do a
build import of "xxx.war".
If you tail the virtualization server's log file, you'll actually
see it creating virtual webapp entries for each of the users.
At this point, you can do whatever you wish with static content
and/or JSPs. You can even mount the repository via CIFS, and
edit an index.html file (or anything else) in-place.
Limitations
-----------
The virtualization server is not fully integrated into the webapp yet,
so there are cases when you won't see what you really should.
This will be dealt with in the very near future (this week, I think).
What's currently missing is that the webapp does not notify the
virtualization server in all the places that it should that
webapp-related content has changed. If the virtualization server
does not know about a webapp, it can't virtualize it.
The notification messages it's currently being sent correspond to
the following set of actions within the webapp:
o Bulk import
o Edit (where appropriate)
o Invite Website Project Users
o Delete Sandbox
o Delete Web Project
The points of integration that remain are:
o Submit of jar or web.xml files to staging
o Revert of jar or web.xml files
Therefore, if you do a build import, and you don't import
to staging, it will still work, but if you then submit to
staging, the virtualization server won't know about it.
For now, your workaround is to do bulk imports into staging;
this will trigger a notification message that causes the
virtualization server create virtual webapp contexts
(if needed), and to do whatever classloading/unloading
is required.
The only times the virtualization server actually
needs a notification is when jars change and
when webapps are created or destroyed (or if you
change web.xml). Therefore, as long as you're not
submitting a critical webapp-centric file like this,
the lack of full integration in the "Submit" action
won't be a issue.
Put differently, if you submit something like "moo.html"
from the "Alice" sandbox, everything will work just fine.
If you submit jar files (or a web.xml file) to WEB-INF/lib,
then you'll notice the lack of full integration.
Submitting new jar files or a new web.xml file is a fairly
rare occurrence, so as long as you do your initial bulk
import to staging, you'll be ok.
> We have real concerns about the usability of this approach. Our internal
> customers are not the type of people for whom "create a valid web app,
> build it as a WAR, and bulk import it" is a plausible course of action.
> If Alfresco web sites are expected to be "valid webapps", then it would
> seem that the "create web project" should create the necessary elements
> to meet that definition.
I prefer to keep the repository free of all system-generated clutter.
We virtualizse webapps, and minimize the constraints placed on
what a webapp is down to accepting "empty" war files.
In the future, it might be possible to lift even this constraint.
I'd like to know how important this feature would be for you,
relative to other features.
> We can live with the usability problem – it means that we'll have to
> offer more technical support to our users to get their web sites up and
> going than we had originally expected – this won't be something we
> expect them to do for themselves. We'll have to evaluate a little more
> carefully what types of internal users we point at this solution.
Are they virtualizing webapps, or static sites?
If it's a static site, is it too much for them
to put it into a war file, and do the initial
import into staging?
> But what isn't ok for us is the inconsistency we are seeing with
> virtualization, and the lack of knowledge that we have about what it is
> that we should expect to work and what shouldn't. If the requirement is
> to be a "valid webapp", then it should consistently fail if you try to
> virtualize a directory of plain html files. It shouldn't work sometimes.
Understandable.
Hopefully, with this information, your team can work around
the limitations I've explained for the next week or so.
> We are also concerned about how this will ultimately be deployed to
> production. Our hope had been that the "dynamic" bits would generated as
> part of the workflow, and the site would be largely static when finally
> delivered and could be served from a stock httpd type of setup.
You should be able to do this.
> Our two biggest issues right now are WCM-2 and WCM-4 (which appears to
> be a variation of WCM-2),
Yes, that's right.
Given that you're doing a mostly-static site, my guess is that
just knowing you can do the initial import into staging will
solve your immediate issues. Again, sorry that the docs
are not keeping pace with the code. That will be rectified
soon as well.
I hope this helps,
-Jon