avmRemote to local filesystem

[pcuvecle]

Hi all,

I understood that the avmRemote component allows a RMI connection to the Alfresco repository in order to be able to virtualize sites in the Virtualization server but is there a way to automaticaly redirect the avmRemote to the local filesystem ?

Indeed, as long as my website remains in preview / staging states, in other words in the virtualization server, that's great because I can easily access the sandoxes and staging content. But, when my site is published to another alfresco with the site mapped to a CIFS drive mapped to a standalone Tomcat server context, my avmRemote calls fail becaue I'm not connected to an AVM anymore.

I've looked at the WCM exemple from the v2.0.0

in org.alfresco.web.pr.PressReleaseBean
…
public static List getPressReleases(PageContext pageContext)
        throws Exception
    {
        FormDataFunctions ef = new ServletContextFormDataFunctionsAdapter(pageContext.getServletContext());
        Map entries = ef.parseXMLDocuments("press-release", "/media/releases/content");
        List result = new ArrayList(entries.size());
        java.util.Map.Entry entry;
        for(Iterator i$ = entries.entrySet().iterator(); i$.hasNext(); result.add(loadPressRelease((Document)entry.getValue(), (String)entry.getKey())))
            entry = (java.util.Map.Entry)i$.next();

        return result;
    }

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

and the FormDataFunctions.parseXMLDocuments seems to connect to the AVM content in any case

Is there a way to switch transparently to the file system to get the XML contents with the same code  ? Use the AVM content when I am on staging/sandbox and the file system (or CIFS) when I have a published site disconnected from Alfresco (but still running in a java servlet container) ?

(I hope I explained my thoughts clearly enough)

[kvc]

There's two different approaches here:

*  In the authoring environment, generate your web pages accessing files and folders via CIFS (straight FS calls - no AVMRemote).  In this case, you can deploy to a remote file system, with no change in site behavior even though you are running a normal servlet container in the run-time (not the virt server).

*  In the authoring environment, generate your web pages leveraging AVMRemote.  In this case, you can deploy to a remote Alfresco server with 2.0.1E.  Once again, in this case you will have no functional difference upon deployment if push to run-time not running the virt server.  Any servlet container will do.

The one case that is more difficult to support this the case you highlight:  pages that depend on calling AVMRemote, but where you deploy to a normal file-system.    If all you're doing is crawling the file-system, AVMRemote truly is not needed.

Our initial example site - dating back to early October of last year - was built prior to our CIFS implementation being complete.  So all our example where based on virtualizing a website where the pages used AVMRemote to dynamically source content.  In many cases, this could have been done more simply just fetching files and folder from CIFS; CIFS just wasn't available once again when we shipped our first Technology Preview late October 2006.


Kevin

[pcuvecle]

Thanks for this answer

*  In the authoring environment, generate your web pages accessing files and folders via CIFS (straight FS calls - no AVMRemote).  In this case, you can deploy to a remote file system, with no change in site behavior even though you are running a normal servlet container in the run-time (not the virt server).

In this approach, can you still virtualize sandboxes through the virtual server ? from my understanding no, because content access must be done by AVMRemote in order to take advantage of the layered folders features (since CIFS is quite limited). Is it correct ?

*  In the authoring environment, generate your web pages leveraging AVMRemote.  In this case, you can deploy to a remote Alfresco server with 2.0.1E.  Once again, in this case you will have no functional difference upon deployment if push to run-time not running the virt server.  Any servlet container will do.

That approach implies that you are forced to stay connected to an Alfresco repository to get access to the content. I mean that you can't create a totally disconnected website (for ex if you have heavy traffic requirements and static content)

So from my understanding, either you have access to the amazing virtualization feature but you have to remain connected to Alfresco on the live plateform or you loose the virtualization feature to be able to have a disconneted website on your live website.

Moreover I noticed a strange behavior with version 2.0.1E, I tried to push my website from an authoring Alfresco to a Publishing Alfresco (2 different servers) .I created a empty webiste on my target before the deployement as described in the WIKI, then run the deployement. The content has been successfuly copied and a new snapshot was there on the target plateform. However when trying to preview the target sandbox, all the links urls were targeting the authoring server not the live one !

[kvc]

*  In the authoring environment, generate your web pages accessing files and folders via CIFS (straight FS calls - no AVMRemote).  In this case, you can deploy to a remote file system, with no change in site behavior even though you are running a normal servlet container in the run-time (not the virt server).

In this approach, can you still virtualize sandboxes through the virtual server ? from my understanding no, because content access must be done by AVMRemote in order to take advantage of the layered folders features (since CIFS is quite limited). Is it correct ?

Yes, you would still be able to virtualize sandboxes with this approach.  Any file previewed through the virt server, even when making direct file-system calls (do not hard code to a sandbox path; make everything relative to your current file location or to the root of your web app) will virtualize properly.  In this case, all the virt server is doing is ensuring the secondary file requests when loading a file for preview are rooted to the correct sandbox.  If that sandbox is deployed to a remote server, pushed to a filesystem, and preview outside the virt server with the web server rooted at the correct docroot, the site you previewing in Alfresco will be the same site you see outside of Alfresco.

*  In the authoring environment, generate your web pages leveraging AVMRemote.  In this case, you can deploy to a remote Alfresco server with 2.0.1E.  Once again, in this case you will have no functional difference upon deployment if push to run-time not running the virt server.  Any servlet container will do.

That approach implies that you are forced to stay connected to an Alfresco repository to get access to the content. I mean that you can't create a totally disconnected website (for ex if you have heavy traffic requirements and static content).

Yes. this implies that.  For static site or for sites with limited dynamic content, this is not the best approach.  Best oftentimes to just push to the file-system.  However, if you have a heavily dynamic site, this is correct approach.  Please also note that with our upcoming 2.1.0 release, we will also support deployment to a remote file server - one not running Alfresco.  This can be used in conjunction with an Alfresco deployment - web app to remote file server(s), content to remote Alfresco.  More details will be on our wiki with the release of 2.1.0.

Moreover I noticed a strange behavior with version 2.0.1E, I tried to push my website from an authoring Alfresco to a Publishing Alfresco (2 different servers) .I created a empty webiste on my target before the deployement as described in the WIKI, then run the deployement. The content has been successfuly copied and a new snapshot was there on the target plateform. However when trying to preview the target sandbox, all the links urls were targeting the authoring server not the live one !

Sounds screwy.  We need more details; something may be just configured wrong here (this seems too outlandish for a bug).  Can you file a support case (since you are on 2.0.1?).  Thanks.  We'll get this sorted.

Kevin