nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Xforms tied to WCM?

ftoth

Hi,

I've been working with 2.0, and it appears that the ability to enter structured XML via Xforms is tied in with the whole optional WCM feature? Is this necessary? It seems like it would be handy to be able to use Xforms as part of the general CMS, without confusing the issue with web site management.

Is there a way?

Many thanks,

Fred

Find more posts tagged with

Comments

xmaniac

I've been working with 2.0, and it appears that the ability to enter structured XML via Xforms is tied in with the whole optional WCM feature? Is this necessary? It seems like it would be handy to be able to use Xforms as part of the general CMS, without confusing the issue with web site management.

100% agree. I like the XForms / XSLT approach a lot. I like the CMS a lot. I would really love to add content to a space based on the XSDs uploaded. Otherwise I have to redefine the model and upload void files just for the metadata. A better integration between spaces and forms would be nuts for me.

The thing is, I just don't buy the whole WCM / virtualization scheme.. I find it useful when you are creating a simple site with lots of contributors (wikies?, digg?). My sites aren't like that. In fact, I usually have to build overly complex situations (that needs loads of backend logic) managed by a handful of users (it can be later consumed by thousands). The CMS part shines there, offering a good repository, Spring integration and advanced capabilities (WS, search, versatile uploading, ..). WCM is too complex for just..too little? I rather go with a portal approach. Maybe it's just me, of course. I'm no expert here.

kgeis

Please vote for WCM-303 (separate XForms from WCM.)

kvc

The thing is, I just don't buy the whole WCM / virtualization scheme.. I find it useful when you are creating a simple site with lots of contributors (wikies?, digg?). My sites aren't like that. In fact, I usually have to build overly complex situations (that needs loads of backend logic) managed by a handful of users (it can be later consumed by thousands). The CMS part shines there, offering a good repository, Spring integration and advanced capabilities (WS, search, versatile uploading, ..). WCM is too complex for just..too little? I rather go with a portal approach. Maybe it's just me, of course. I'm no expert here.

Please note: Even if you are a single developer working on a site, the concept behind WCM is that sandboxes also act as a source code management environment for your web application … so, you get the benefits of file versioning, snapshoting, preview, deployment (coming with 2.0.1), and rollback. Even if not deploying to large numbers of contributors with lots of distributed publishing via forms, the source code versioning model (Subversion-like, but tailored for web apps with layers and promotion models between repos and deployment and virtualization) is hopefully quite useful.

Please note that we haven't exposed the full power of the underlying repo yet in the web client - branching, merging, cross-repo comparisions, change set integration, etc. - are all available server-side but yet to be exposed. That'll be forthcoming in future releases 2H07.

Kevin

kvc

Please vote for WCM-303 (separate XForms from WCM.)

Yes indeed … do vote!

We do intend to address this issue, likely 2H 2007 post our 2.1 release which is targeted for this May. Forms serve more general ECM use cases outside of a WCM context - that is understood - and we are looking at opening up our XForms support to allow you to create and upload your own custom XForms and use them either inside or outside the context of a Web Project.

Kevin

xmaniac

Please note: Even if you are a single developer working on a site, the concept behind WCM is that sandboxes also act as a source code management environment for your web application … so, you get the benefits of file versioning, snapshoting, preview, deployment (coming with 2.0.1), and rollback. Even if not deploying to large numbers of contributors with lots of distributed publishing via forms, the source code versioning model (Subversion-like, but tailored for web apps with layers and promotion models between repos and deployment and virtualization) is hopefully quite useful.

Yes, of course. I can understand the value but I would rather use Alfresco as the content repository and keep those issues at Subversion. Subversion (coupled with something like Ant or Maven) already offers all those capabilities and just manages Java sources, classes and libraries better (among othe things). I don't know if I really need another tool for this. I don't know if WCM can even compare with other SCM tools out there, really.

Please note that we haven't exposed the full power of the underlying repo yet in the web client - branching, merging, cross-repo comparisions, change set integration, etc. - are all available server-side but yet to be exposed. That'll be forthcoming in future releases 2H07.

Is WCM a SCM then? Do you intend us to drop [Subversion / Ant / CruiseControl] (for example) and use it instead? I think I am a little bit confused on the final goals of WCM. Do you have a document that clarifies this?

ftoth

I can be happy with the new WCM repository as long as it gives me all the basic CM features I need: flexible, configurable meta-data, versioning, the ability to get the stuff in and out in my own terms.

I am less comfortable with the virtualization piece, and also what appears to boil down to "you have to learn to do things the Alfresco way".

Consider:

In the WCM tutorial, there are some basic content management tasks, and some nice sandbox experiments, etc.

But there are two areas where "magic" happens.

1. When you enter a press release, if you have things just right, you will get a set of radio buttons that allow you to choose among the "company footers" that you have already set up. This is very cool, but how does it work? It appears that it somehow depends on virtualization! The document even says something like "if you don't see the check boxes, use the virtualization server to preview a particular jsp file". If you look carefully at the schema, you'll see that the list of available footers comes from a chunk of XSD that is generated on the fly via special URL. And behind that there appears to be some java bean that is part of alfresco source. I haven't even seen it, since I haven't gotten around to getting the full source. This is very interesting, but what a lot of learning I've got to do here! And must I use a virtualization server to accomplish this?

2. Later, when you have entered your press releases, there is a sample jsp that will give you a list of them. Exactly the sort of thing we need, right? We need clever ways to USE this structured data that we've entered. Well, again, it turns out that the mechanism for this is a special bean that is deployed with the rest of alfresco, so I have no idea how simple or complex this might be. I will look there next.

I realize there's lots of work to be done here, and these examples are just a first look at this technology, but I, like many, have complex sites to build with their own constraints and technology requirements. There's no way I can adopt alfresco as a "cradle to grave" system and build ALL of the logic of my sites the alfresco way. At this point, I can't see having the alfresco API involved in my final delivery engine.

As I've posted here before, what if I'm building a PHP site? Or a Rails site? (I'm not, but you get the idea.) I still need world-class CM, but there's no way I can use an Alfresco API bean to list my press releases.

So, I'm not giving up on WCM, but I'm being very cautious, and I'm using only the alfresco features that I understand, and only those that don't force me to create basic sites using all new technology that may or may not paint me into a corner.

Thanks,

Fred

arielb

hi,

you bring up a number of good points. i'll try to give some explanations of what is going on here - and a very limited description of the future direction of wcm to support your use cases.

virtualization is indeed used when populating the company footer repeat within the press release form. there is a simple backing bean, or rather java api - similar to that used for form data functions within xsl and freemarker transforms - that can be used to query the repository for form instance data of a particular form. this is a tiny api that is backed by the AVMRemote api. please remember that forms are in the development environment only - meaning that they have no impact on your production environment or on your choice of technologies for your production environment. that said, within your development environment, if you want to leverage schema includes for dynamic types - you will need to develop against an alfresco api in java.

for your production environment - yes - right now the implication is that you use the same apis for aggregating form instance data in your development environment as in your production environment which does constrain your choice of technologies. however, once the deployment piece is hooked into the product, it will enable alternatives. the goal is that you should be able to leverage forms to generate xml content - and then manage it and utilitize it within your production environment however you wish and wherever you wish. using workflow and deployment you should be able to implement your own method for manipulating form instance data generated within the development environment.

i hope this addresses some of your concerns. i'll let others comment in more detail on the plan for deployment as i'm not all that involved in that.

kvc

Yes, of course. I can understand the value but I would rather use Alfresco as the content repository and keep those issues at Subversion. Subversion (coupled with something like Ant or Maven) already offers all those capabilities and just manages Java sources, classes and libraries better (among othe things). I don't know if I really need another tool for this. I don't know if WCM can even compare with other SCM tools out there, really.

Is WCM a SCM then? Do you intend us to drop [Subversion / Ant / CruiseControl] (for example) and use it instead? I think I am a little bit confused on the final goals of WCM. Do you have a document that clarifies this?

Alfresco can be used as a lightweight SCM for your webapps. It is also designed to be used in conjunction with Subversion or any other SCM system you have. The goal is to ensure we provide (a) proper in-context preview of both code and content (b) single archive of record for snapshot of entire source tree of your website/web app and © single point of deployment and rollback of your runtime environment (coming with our new deployment service in 2.0.1).

To this end, should your developers choose to leverage an existing SCM, the recommended practice is to leverage Alfresco as a staging server and target the output a build to an Alfresco sandbox, where it can be previewed, tested, and then submitted to staging to (a) ensure all contributors on an ongoing basis are testing content against the latest, greatest working version of the site and (b) snapshot and deploy both code and content.

So, the goal is to not eliminate your existing best practice - if you do not have an SCM system today and do need an environment for source code control, you can leverage Alfresco, or you can leverage Alfresco in conjunction with your SCM for improved code and content testing, staging, and release management.

Hope that addresses your concerns. Feedback appreciated.

Kevin

xmaniac

The goal is to ensure we provide (a) proper in-context preview of both code and content (b) single archive of record for snapshot of entire source tree of your website/web app and © single point of deployment and rollback of your runtime environment (coming with our new deployment service in 2.0.1).

To this end, should your developers choose to leverage an existing SCM, the recommended practice is to leverage Alfresco as a staging server and target the output a build to an Alfresco sandbox, where it can be previewed, tested, and then submitted to staging to (a) ensure all contributors on an ongoing basis are testing content against the latest, greatest working version of the site and (b) snapshot and deploy both code and content.

Nicely explained! I was considering Alfresco WCM more as a developer tool than a test server. I think I like the in-context preview and test capabilities and the code & content deployments. I have serious doubts on how to use it though (I'm imaging a Spring based web using WCM for forms and CMS for documents). I will re-read all the documentation again.

I blogged yesterday a little about building a website over Alfresco (http://internna.blogspot.com) and I think I wasn't fair with WCM. I now think it can be useful, probably not to develop but in other stages of the project.

kvc

I think the key to helping you will be the introduction of our deployment module with our upcoming 2.0.1 maintanence release. This will enable you to deploy (replicate) an entire web project to one or more remote Alfresco servers (and later, to remote file servers for a completely static deployment). Then, you can look at deploying Alfresco in as part of a 3-tier production environment: an SCM for development, WCM for content authoring and site staging and test (both code and content), and a standalone Alfresco repo (sans web client) for site hosted (the run-time).

In terms of DM vs. WCM repos, the goal is to enable knowledge workers to create and collaborate on documents in the context of a space, with a content rule that copies (preferrably, a locked down rendition in the form of a PDF) of finalized documents to one or more web projects. This is enabled by executing a custom Javascript action today with 2.0. We are looking to make this more wizard-based via a pre-built action in 2.1 (target May). The key here is that end-users want to be able to set up their own spaces for purposes of collaboration, and the documents they create should be able to transparently be posted to one or multiple sites, which themselves will have unique directory structures that may or may not be known to the end-user that they will need to be "pushed" to one or multiple remote servers.

Let me know if any more questions or comments - good discussion.

Kevin

jcox

From the outside, it's always tough to tell the difference
between what's been implemented for a particular release,
and what's fundamental to the design (or the lack thereof!).

Hopefully, I can shed some light on things so you can evaluate
Alfresco 2.0.x with some additional context. Our goal in 2.0.x
is to provide you with something useful, but it only scratches
the surface of some very powerful new core technologies we've
been developing.

First, let's take a step back from WCM for a moment, and talk more
generally about managing and viewing *any* kind of content. After
that, let's circle back to WCM. The ideas are highly related but
they are distinct.

The AVM manages a forest of Subversion-like object versioning trees.
This is not specific to managing web content; ultimately, the source
code management system we're planning will use it as well, along
with everything else. Transparency can be turned on/off on a per
directory level, so it isn't an all-or-nothing choice. Right now,
what you see on the WCM side is just one configuration tuned for a
specific purpose. Currently, we do not have much direct support
for SCM, but that is in the works, as we plan to develop Alfresco
within Alfresco as soon as it becomes feasible. One of the basic
differences in the default SCM setup is that the user-level
"sandboxes" probably won't be transparent overlays of a "staging" area;
however, each user will still operate within a separate virtual
repository, and all users connected to a common project will be tied
to a staging area via workflows. Thus, the WCM submit/review models
will still apply, but the emphasis will probably be somewhat different;
SCM is typically more concerned with text-based 3-way diffs/merges.

One big improvement coming up in 2.0.1 is that our support for
metadata has been greatly extended within the AVM. This will make
it possible for future releases to do links management and dependency
management, and advisory locking efficiently, as well as support a
variety of deeper customizations (e.g.: displaying custom meta
information on snapshots, fancier workflows, etc.).

The only major "WCM-specific" subsystem in Alfresco's 2.0.0 release
is the virtualization server; this allows you to see your web pages,
servlets, and JSPs in-context… just as if you were browsing the
"real" customer-facing website. Whether you deploy AVM content
to a normal file system and/or serve content to end users directly
from a separate virtualization server is up to you. The layers
between these subsystems are cleanly established, so you can set
things up exactly as you see fit. The 2.0.1 release will include
some built-in deployment features, so hopefully this will become
clearer when you see it.

Ok, that said, our auto-generated XForms *are* currently bound too
tightly bound to the Alfresco webapp itself. This is a byproduct of
trying hit a delivery date for this release.

We'd like to be able to make this fully pluggable so that you can use
our auto-generated forms within *your* webapp if you'd like….
or use some other technology for data collection, such as fully customized
XForms, CGIs, custom servlets, or whatever combination of things suits
your needs best.

Interactive and/or automated data input is the "front end" of content
management in general, not just WCM. As such, making it as modular
and re-usable as possible is essential. The goal is to make it so that the
widgets we use in our webapp can be used in yours (and vice-versa).
We're working on it, but we hope that the current "front end" is at least
somewhat useful to you in its present state.

There are some other areas that we won't get to in the 2.0.1 release
at all, such as improvements to our workflow system, and supplying some
fancier workflows out-of-the-box… such as the ability to delegate
conflicts/merges to a third party. This will be able to take advantage
of the underlying "forest of trees" design inherent in the AVM;
the virtualization server will play nicely with it too, so whether
the final application is WCM or SCM, the operations dealing with
review/modify/merge/submit will be fairly slick.

One inherent difficulty with producing a *platform* for DM/WCM/SCM
collaboration is that any demo that gets shipped can easily be
confused with the product itself.   I think this is inevitable to
some extent, but one thing that would help a lot is if we shipped
more demos & examples.   That way, we'd convey a better sense
of what's possible within what we've already got.   We're working on
that too; in fact, one of our sales engineers just put together a very
pretty demo & showed it off to us today. It's not clear whether this
will end up shipping with the product, or on some sort of online
"demo gallery".    User-contributed demos might be very cool too,
so if you think there would be value in something like this, please
let us know. Creating infrastructure to support this will take a little
bit of time, but if the community expresses a strong interest, we'll
try to accelerate that.

In the meanwhile, I hope I've helped to give you a better picture
of how stuff is set up internally, and where we're headed.    Your
feedback is greatly appreciated. Keep it coming!

Cheers,
-Jon

ftoth

Jon, all,

Thanks very much for your detailed description of your future plans. I've been very happy with Alfresco, and I continue to look forward to new releases.

In the interest of keeping this discussion going, though, I would like to briefly describe my current situation. I am using Alfresco right now in development, and I would be pleased to get any feedback from the group.

First of all, our current choice of "delivery engine" is tomcat with struts2 and freemarker as the view layer. This is powerful, a known quantity, and supports any complexity necessary in our sites.

Right now I have two tomcat instances side by side. One is running alfresco 1.4, and the other is running struts2/freemarker.

One of the key enabling technologies that I get from Alfresco is the CIFS server. I have the Alfresco instance locally mounted, via CIFS. This is huge, because now we can deploy using anything we want!

Within Alfresco, I have a space that is the web root. Within that space I can use Alfresco to manage HTML snippets, freemarker templates, images, etc., in a folder hierarchy that corresponds exactly to the web site.

Outside of either environment, I have an ant script that simply copies from the Alfresco mount to the webapp in the delivery instance of tomcat.

This works perfectly, for now, though I would like to somehow move the functionality of the ant script into Alfresco. Perhaps a custom action of some sort?

So given what I've described above, what should I be thinking about in terms of moving to WCM in 2.0? I think that I understand that alfresco won't support deployment to static files until later this year, so I'm stuck there.

The multiple virtual sites, via sandboxes, is very powerful, but it appears that I can't use that without adopting virtualization and alfresco as the delivery engine? (Though I do remember one note somewhere about virtualization working with any "well behaved" java technology).

I will probably move to 2.0 for xforms if nothing else. But in my current "thought experiments" with this, there are some issues, right? As described above, I can't use all of the cleverness of xforms without the virtualization server, right? (I still don't understand that one!)

But what I can do, it seems, is use xforms to capture XML, and, once captured, use external techniques to process that XML in various ways. For example, if I had 10 XML press release files, it appears that I could transform them, aggregate them, etc., externally to alfresco, using the same techniques I've described above. I could, for example, simply export them to my delivery engine, and there write freemarker and backing beans in struts2 to achieve anything I need.

Again, a key enabler is the CIFS mount, which, from what I can tell, works in 2.0 as well, with the benefit of presenting all of the sandboxes. So once again, I can have the best of both worlds, without adopting alfresco as the delivery engine.

I would be very interested to hear back from folks on this! I keep hoping that I'm missing something fundamental. I would also be very interested in how others are dealing with these same issues.

Many thanks,
Fred

kvc

Fred:

To move to 2.0, you would:

1. Create the directory structure of your website in an authoring sandbox
2. Import any images, code, or other web resources
3. Leverage forms to create your HTML snippets. In the simplest case,
     you can have a single form that captures a title and body text and
     generates an HTML fragment. This simple form can also have a
     "category" element, which would be a dynamic list of values that
     correspond to directories in the website. This category element
     can be used via an output path expression to generate the HTML
     fragment in the appropriate directory. Thus, a single generic "article
     form" can be used to create news articles ("/news/xxx.html"), a
     people article ("/corporate/profile/xxx.html"), an event article
     ("/events/xxx.html"), or anything else you want without having
     to have the end-user navigate around the website to put things
     in the right folder.
4. Import any freemarker templates. You can use continue to
     use freemarker as your view layer. Freemarker templates are
     fully virtualizable and previewable within a sandbox.

Now, the benefits of doing this are five-fold:

1. You now get proper staging of site changes. In a sandbox, you
     can modify multiple things and test as if it were live.

2. You now get support for multi-asset promotion. In a sandbox,
     you can promote an entire change set. This overcomes the
     problems associated with updating the site on an asset-by-asset
     basis.

3. You now get support for task-based review of change sets.
     Reviewers can now preview a future state of the site with all
     changes that will get commited if approved.

4. You now get full site versioning and rollback. Once things
     are approved, they are snapshoted and available for rollback.

5. You now get (with our upcoming 2.0.1 release) integrated
     deployment to push a given snapshot to a remote server or
     servers outside your firewall.

Now, the virtualization server is *not* required for your run-time environment. In fact, we don't intend for you to have to use the virtualization server in your run-time (of course you can, but that's not what's it's target use is for). In the run-time, you can have any servlet engine serving your web app … and in the run-time, you can do this directly off a mounted CIFS drive (remember, web projects - including all snapshots - are viewable through CIFS; and, for the run-time, read performance of assets in a sandbox is signficantly faster (minimal 3x) over a normal Alfresco space.

I highly recommend trying this out. In this model, you can continue to leverage normal spaces as well … those spaces can be used for document collaboration and management, where finalized docs are promoted into a web project, which is responsible for managing the source code (the entire directory tree) of your site and support staging, preview, workflow, snapshoting, and deployment.

Let me know if any more questions. Super good thread here.

Kevin

ftoth

Kevin,

Thanks very much for your helpful guidance. I am learning more about
Alfresco every day, and I'm very pleased.

In the hopes that you and others are still following this thread, I want to
drill just a little deeper on the subject of the virtualization server.

You say above that it's not required for my production environment.

But what I think I'm seeing is that as long as my production environment
is something other than alfresco, the virtualization server can NOT be
used to preview my site.

Again, I can use Alfresco to manage my freemarker templates, content
snippets, etc., but as long as those components require MY environment
(i.e. struts2 and associated custom logic) to operate, the virtualization
server is of no value to me.

To be clear, imagine this simple scenario, a typical "about" page:

In my "about" space, I might have a header, a footer, and a content block.

They are stitched together with freemarker include tags.

So far, so good, right?

But say that my page also has (a silly example) a "quote of the day"
section. And there's all sorts of struts2 logic and database tables and
on and on, to support this incredibly valuable function.

So, somewhere in the content freemarker template, I have something like

${quote.todaysQuote}

The quote bean is in my world (struts2), and not in Alfresco's.

I can still use Alfresco to manage the template that contains
the above snippet, but there's no way the virtualization server is ever
going to be able to preview that page, right?

I keep putting question marks in, because I'm really not completely
sure that you guys don't have yet another trick up your sleeve, so
please dazzle me!

What IS the virtualization server doing, anyway? I think I understand parts of it:

Alfresco builds the "eyeball" links in such a way that the virtualization
server can figure out what page and what sandbox is being requested.
But that's on the Alfresco side.

The virtual server logs give me the impression that there's some RMI
going on, which makes sense. So I'm guessing that the virtualization
server just decodes the URL and then requests the appropriate
documents from Alfresco. But there must be a fair amount of complexity
in there, right? Essentially, the virtualization tomcat instance is using
Alfresco as its resource for content.

So, if I'm right, and I can't use your virtualization server to preview
my site, then why can't I build my own?

What if you gave me the ability to completely customize the URL that's
built for the eyeball? Then the preview could be anything at all! Even
ruby or php!

Again, please tell me what I've missed, and, as always, I appreciate your time.

Thanks,

Fred

kvc

Hmmm … enabling alternative preview environments (PHP, Ruby, .NET, etc.) is definately a good idea … and exactly where we're heading 2H07.

But that shouldn't be required for you to be able to virtualize your web app. Is your bean accessible to the web app (contained in your Alfresco web project in your WEB-INF dir)? There's no Alfresco specific app logic - the examples in the sample content are just that - examples. Nothing is really required there. The only thing that is required now is to use our Java API (or their RMI interface) to fetch assets from your web project for rendering (alternatively, they can of course be read off the CIFS interface).

I'm forwarding this post to our virt server engineer, Jon Cox. We'll get this sorted straight away!

Kevin

ftoth

So you're saying that I can put my complete webapp in Alfresco?

This means lots of jar files, config files, property files, etc., all the stuff
that normally lives in WEB-INF, and it will "just work" with the virtualization
server? I had certainly never thought of that!

Maybe it would help if I understood more about what the virtualization
server is actually doing.

Somehow you've altered tomcat so that all of its requests for resources,
including classloaders, etc., go through to Alfresco?

Is this a change to the tomcat source (i.e. a forked version)?

You may or may not know that in struts2, some or all URLs can be completely
virtual. For example, you might have a request for /a/b/c. And there is
nothing out there content-wise in that location. Instead, a struts action
interprets that path and redirects to the view layer, etc.

All that will work with the virtualization server?

Thanks, I'll look more closely and give it a try.

Fred

ftoth

Well, I had high hopes, but I have to report failure.

I took an existing, working struts2 webapp, zipped it up, and imported it into
a newly created web project.

The import worked flawlessly.

However, the app does not run within the virtualization server. The first
and most obvious problem is that freemarker is not processing the
templates.

If I hit the eyeball on a freemarker template, the virtualization server
displays the raw content (i.e. the freemarker markup).

So, all the content is there, but none of the functionality.

As discussed above, this is what I expected given my current understanding
of how the virtualization server appears to work, though Kevin seemed to
think otherwise.

I look forward to your comments.

Thanks,

Fred

ftoth

One correction to the above:

There is an error in the virtualization server log indicating that
"struts.properties" is not being found:

Mar 29, 2007 10:13:03 AM org.apache.struts2.config.DefaultSettings <init>
WARNING: Could not find or error in struts.properties
Could not load struts.properties:java.io.FileNotFoundException: /media/alfresco/cifs/v/stest/VERSION/v-1/DATA/www/avm_webapps/ROOT/WEB-INF/classes/struts.properties

The file does exist, however, so I have no idea what's going on
(it's in WEB-INF/classes/struts.properties).

Does that complex path look correct?

Thanks,

Fred

ftoth

One more note before I leave this for a bit:

I tried the same test using the minimal sample application,
"struts2-blank-2.0.1.war", which is available from the struts2
distribution.

It also failed with the same error (can't find struts.properties)
and the application does not run within the virtualization server.

Perhaps struts2 is not "well behaved" in some way?

Thanks again for your help.

Fred

jcox

Fred,

Thanks again for all your great input.

I'd like to help figure out exactly what can be done to help you prior
to the upcoming release with the built-in deployment stuff.

As you said, the CIFS projection of the AVM lets you deploy content using
pretty much anything you want (personally, I like to use rsync over ssh).
If you just want to deploy some files from one place to another, what is
the problem you're encountering? When I rsync from Alfresco's CIFS
projection to a remote file system, it works quite well – even for large
sites. The first version of our built-in deployment will be will be able to
take advantage of history information (and deal with meta info nicely),
but there are *lots* of bells & whistles we plan to add later. I want to
be certain that the "core" features in our first release meet your needs,
so if you can elaborate here, it would be very helpful.

I would like to somehow move the functionality of the [deployment]
ant script into Alfresco. Perhaps a custom action of some sort?

Built-in deployment has been under very active development & will
be available quite soon (weeks, not months).

The multiple virtual sites, via sandboxes, is very powerful,
but it appears that I can't use that without adopting virtualization
and alfresco as the delivery engine?

The virtualization server is virtualizing the contents of the AVM itself.
The major components of Alfresco are:

DM repository (used for document management)
AVM repository (used for WCM currently, but may take over completely)
Alfresco webapp (the GUI for creating & manipulating content)
The virtualization server (creates a virtual view of *your* webapp/website)

The virtualization server is a modified version of Tomcat that knows how
to use interpret the area-izing information embedded within a URL
( *.www–sandbox.*:8180/…), and fetch data via AVMRemote. It also
does some fancy footwork with classloaders to allow many users to have
what appears to be a separate version of your webapp in the "staging"
area, and yet still share the jar files they have in common, when possible
(this allows the system to scale).

Whether you fetch data via the CIFS projection of the AVM repository,
or if you use AVMRemote (like the virtualization server does via its
built-in JNDI binding), you're still accessing the AVM. Both end up using
AVMRemote behind the scenes to fetch the data being presented.
Incidentally, the virualization server does not require the CIFS projection
to work for webapps that don't make use of the servlet method
getRealPath(). However, if a webapp *does* call getRealPath(),
then so long as you've mounted CIFS where you've said you will
within $VIRTUAL_TOMCAT_HOME/conf/alfresco-virtserver.properties,
then the JNDI names will coincide with the file system names; thus
even AVM-unaware code will work too.

Put differently, the fact that the virtualization server requires the AVM
is inherent in the fact that the core feature of the virtualization server
is to display the contents *of* the AVM. On the other hand, the fact
that the AVM is bound to the same process as the Alfresco webapp
is just an artifact of its current implementation. Some day, the AVM
may be in a different process (and/or on a different host) than the
one running the Alfresco webapp.

(Though I do remember one note somewhere about virtualization working
with any "well behaved" java technology).

There are some limits to what can be virtualized; for example, if you
have a singleton of any sort (not just a java singleton), then it will be
shared by all virtual webapps based off of the project's staging webapp.

For example, suppose your webapp writes to a database table.
If users Alice and Bob are are viewing their "separate" virtualized
instances of the webapp within their own sandboxes, and Alice does
something that makes this webapp modify the 'moo' table, then Bob
will see the change Alice has made to the 'moo' table immediately.
In other words, the virtualization server can virtualize files but
can't magically restructure arbitrary hard-coded programs.

As described above, I can't use all of the cleverness of xforms without
the virtualization server, right? (I still don't understand that one!)

You can use the data generated by XForms, and the files derived from
them (e.g.: templatized output files) by simply deploying them to
a native file system. From there, any webserver will just be able to
serve them up as ordinary files … because that's exactly what they'll be.

But what I can do, it seems, is use xforms to capture XML, and, once
captured, use external techniques to process that XML in various ways.

Exactly.

Again, a key enabler is the CIFS mount, which, from what I can
tell, works in 2.0 as well, with the benefit of presenting all of the
sandboxes. So once again, I can have the best of both worlds, without
adopting alfresco as the delivery engine.

With the stuff coming in 2.0.1, you won't even need CIFS for deployment.
When you talk about the Alfresco "delivery engine", I think what you
probably mean is "repository".    By the way, for the fun of it, you might
want to try comparing the speed of a vanilla tomcat instance fetching
data from a native file system to the virtualization server fetching data
from the AVM.   In most cases, there isn't a heck of a lot of difference.
When doing a bunch of tests a while back, I was very pleasantly surprised.
Of course, I might not want to use a setup like this for the splash page
of a super high volume website, but then if you slapped a cache in front
of it, it would probably be just fine for that as well. Food for thought.
Another amusing experiment I did was set the docroot of an Apache 2.x
instance to be the /www/avm_webapps directory of the staging area
of a web project using the CIFS projection.   This also worked much better
than I'd anticipated.   The CIFS projection of AVM contents is quite fast
(much faster than the CIFS projection of the older DM repository's data).
Some time soon, I'll take a crack at making a virtualized version of
Apache 2.x, so we can have a full Apache/Tomcat stack (and maybe even
deal with PHP).   My first priority is creating infrastructure for link checking
at submit/update time, but after that I think I'm going to have a look at this.

But what I think I'm seeing is that as long as my production environment
is something other than alfresco, the virtualization server can NOT be
used to preview my site.

The virtualization server's job is to allow data within certain portions of
the AVM repository to be interpreted as a set of virtual webapps. Suppose
that you have a production environment that wishes to access some data
from the native file system, and other data from the AVM. Nothing
prevents you from doing this – it's not an "all or nothing" choice.
There are at least three ways you could proceed:

[1] Invoke AVMRemote APIs directly, where ever you wish.
[2] Make portions of your site act as a reverse proxy to the virt server
[3] Make portions of your site access AVM content via CIFS

So, somewhere in the content freemarker template, I have something like
${quote.todaysQuote}

The quote bean is in my world (struts2), and not in Alfresco's.
I can still use Alfresco to manage the template that contains
the above snippet, but there's no way the virtualization server is ever
going to be able to preview that page, right?

It sure could.
As long as the webapp you are virtualizing contains the jar file
referenced by your function in its WEB-INF/lib dir, then this
becomes logic internal to your webapp. Think of it this way:
the virtualization server just provides a framework for automatically
virtualizing AVM content & serving it up (after all, it's just Tomcat with
a bunch of classes replaced to handle AVMRemote calls, bootstrapping,
webapp notifications, and some extra tap dancing to make it all scale).
Thus, if you can write a webapp to do something, the virtualization
server can (in most cases) just server it up for you. To do this,
you've got to configure *your* webapp with the proper libraries….
but then this is no different from what you'd expect from *any* webapp
whether served via the virtualization server, or a "vanilla" Tomcat.

What IS the virtualization server doing, anyway?

Suppose you have a web project named "mysite",
and two users: Alice and Bob. Within Alice's sandbox, the "eyeball"
icon will have URLs for Alice of the form:

http://alice.mysite.www--sandbox.<virtualization-domain>:8180/…‍

The "eyeball" icon will create URLs for Bob like this:

http://bob.mysite.www--sandbox.<virtualization-domain>:8180/…‍

Let's say your virtualization server is sitting on IP address 192.168.1.5,
and that you're using the EchoDNS server at ip.alfrescodemo.net to
deal with DNS wildcards. Therefore, *.192-168-1-5.ip.alfrescodemo.net
will be resolved as the IP address 192.168.1.5. Consequently, the
following URL will resolve to 192.168.1.5 (on port 8180):

http://alice.mysite.www--sandbox.192-168-1-5.ip.alfrescodemo.net:8180/…‍

Note that the same is true of the following url for Bob:

http://bob.mysite.www--sandbox.192-168-1-5.ip.alfrescodemo.net:8180/…‍

The wiki page entitled Configuring the Virtualization Server covers this in greater detail.

In any event, using the area info embedded into the "virtual host name"
the virtualization server is able to figure out the associated AVM repository
and area-ize the request path accordingly when it makes calls to
AVMRemote behind the scenes. There's a lot of other stuff going on
too, like how it knows when to reload a webapp, how it maps between
JNDI/webapp/CIFS/URL namespaces, and so on… but you get the gist
(I hope).

The virtual server logs give me the impression that there's some RMI
going on, which makes sense. So I'm guessing that the virtualization
server just decodes the URL and then requests the appropriate
documents from Alfresco. But there must be a fair amount of complexity
in there, right?

Interestingly, the amount of code involved is not that large, but in terms
of how and why it is designed the way that it is.. yes, you're right.
Many late nights went into thinking it all through, and making it actually
work. I'm glad you're enjoying it & finding it useful.

Cheers,
-Jon