topic Re: Configuring 'eyeball' icon without virtualization server in Alfresco Archive

Configuring 'eyeball' icon without virtualization server

ftoth — Sun, 06 Apr 2008 16:33:20 GMT

Hi all,For reasons documented elsewhere, we cannot run our applicationunder the 2.1 virtualization server (we use struts).We're working on our own preview server that gets around that limitationby previewing from the AVM CIFS mount. This works fine, but only if wecan type the actual URL in the previ

Re: Configuring 'eyeball' icon without virtualization server

pmonks — Mon, 07 Apr 2008 00:16:12 GMT

I know of at least two ways to get the behaviour you describe:

(2.0+) Develop a micro-webapp that's installed into the Web Project and contains a single "redirector" servlet that responds to all requests (/*). This servlet would contain whatever logic is necessary to convert a virtualisation server URL to the URL of your own standalone server, passing through the sandbox's store id (this is important so that your app knows which subdirectory of the \\alfrescoserver\AVM mount to access). The advantage of this approach is that you can support a large amount of concurrent preview activity from a single server.

(2.2+) Use the new test deployment functionality to deploy content out to a real filesystem that your app needs (see http://wiki.alfresco.com/wiki/Deployment#Live.2FTest_Server_Deployment for more details). The problem with this approach is that you need to configure multiple copies of your web app if you need to support preview from more than one sandbox at a time.

Cheers,
Peter

Re: Configuring 'eyeball' icon without virtualization server

ftoth — Mon, 14 Apr 2008 20:19:21 GMT

Hi Peter,

I really liked your idea #1 when I first read your suggestion. However, I'm just now getting
back to this issue and I find I can't quite connect the dots.

If I write a micro-webapp, then won't that be the application I'm actually previewing?

My actual application is in struts, and it's all imported into the AVM. Even though the
virtualization server can't run it, my preview server can see all the content. I thought
about installing some sort of filter in my main app that could tell whether or not
it's running under the virtualization server, but my app won't run in the virtualization
server because it's struts! I'm caught in some sort of mental loop here…

As for your #2 idea, we are already using the deployment mechanism, but that doesn't
really help with making the eyeball icon work (unless I missed your meaning).

The only way I can think of to get out of this mess is to have my preview server split
it's resources somehow. All content comes from the AVM mount, but the application
comes from outside alfresco. Then I could maybe use your micro-webapp trick, since
that would be the only application installed in the avm. But that's both hard and messy.

Do you see where I'm stuck? What have I missed?

Many thanks,

Fred

Re: Configuring 'eyeball' icon without virtualization server

pmonks — Mon, 14 Apr 2008 21:48:40 GMT

Ok that adds a lot of relevant detail.

For starters, Struts should be virtualisable - can you provide more detail (perhaps in a separate forum post) about what doesn't work and what you see in the various logs (the catalina.out for the virtualisation server in particular) when you try to run your app via the virtualisation server? It would also help to know which version of Struts you're using (v1 vs v2), since the two are basically different codebases.

Continuing on this thread for a moment though, the micro-webapp approach is easiest to configure if your webapp code is not stored in Alfresco. In this model Alfresco is used purely for content management - code management is handled outside of Alfresco in the traditional way (with an SCM, build scripts, test and deploy processes, etc. etc.). Your web app would retrieve content using HTTP, and (in the case of preview) would do so via data Web Scripts that also receive a sandbox id as a parameter (so that they can virtualise content out of any sandbox in the system). In production, this code would simply be pulling file:// URLs directly from disk (the content having been deployed there by a FileSystem Receiver). How you configure your app to distinguish between preview and production is up to you.

The micro-webapp, then, is simply responsible for redirecting previewers from the virtualisation server (which contains content but no code) to a separate standalone preview installation of your web app, thereby ensuring that the "eye of Sauron" functions correctly (sends users to the preview instance of your web app).

Now there are definitely cases where you might want to store both content and code in Alfresco (to obtain consistent snapshot / deployment across both your code and your content, for example), but that either requires use of a web app technology that can be virtualised (which should include most Java-based web frameworks), or it requires Alfresco 2.2 (in order to support test server deployment).

Cheers,
Peter

Re: Configuring 'eyeball' icon without virtualization server

ftoth — Tue, 15 Apr 2008 00:35:48 GMT

Hi again, Peter,

Thanks for your help.

The struts issue (we're using struts 2) has been mentioned in many threads (some by me).
Here's one:

http://forums.alfresco.com/viewtopic.php?f=29&t=7534&hilit=struts+virtualization

Apparently it's fixed in 2.1 enterprise, but I'm on community.

As far as keeping the webapp code outside of Alfresco - I completely agree (though
others have advised otherwise in these discussions).

My problem is rooted in the fact that we tend to build large content-oriented sites,
and we also rely heavily on the tomcat DefaultServlet to handle all the things that
we don't need to handle in our application, such as images, PDFs, etc. It does a great
job, already knows about mime types, etc. If you look at the source you can see that
it was written by somebody WAY smarter than me.

But! It can serve basic content only one of two ways: Either it is serving out of a
war file (which we can't do on large sites because we can't package all of our
content into a war file), or we run the application "unpacked". This is how we're
currently set up with alfresco. The unpacked application is completely inside WCM
and our preview server mounts the entire thing, WEB-INF and all.

I've run into this issue over and over in the past and the only other way I've solved
it is by hacking a configuration parameter into DefaultServlet so that I can point
it outside of the webapp proper. I may go back to that as my way out of this box.
Once I've done that, I can do as you suggest and have WEB-INF outside of alfresco
and just point the default servlet to the CIFS mount.

Although, I'm also tempted to try hacking alfresco so that the default values for
the eyeball can be set without the virtualization server. Then I don't need it at all!
(I've actually never really liked the idea of the virtualization server anyway, as you
can see from my various posts.)

As always, I'd be interested to hear how others might have solved this.

Many thanks,

Fred

Re: Configuring 'eyeball' icon without virtualization server

kvc — Sat, 19 Apr 2008 16:35:43 GMT

Fred:

Yes, the two best options are to either (a) leverage our new Struts virtualization or (b) leverage test server deployments (highlighted by Peter) which enables preview via remote banks of test servers (that users specify check-out and sync their changes to via deployment).

The good news is that this June we will be updating our 2.9 Community release to catch-up all the bug fixes and minor improvements made to the Enterprise code-line since our initial 2.1.0 release. If you can wait until then, you can continue to leverage Community, or, if not, you can switch to an Enterprise distribution.

If you want to be really bold, all of the above changes have already been synced to HEAD and are actually available for check-out from our public SVN. We won't officially build a new Community release, however, until June as I highlighted, and please do know that if you take any random point-in-time build from our source, you will need to vet very, very thoroughly (there is no guarantees on quality - it really is the evolving source base).

Kevin

Re: Configuring 'eyeball' icon without virtualization server

ftoth — Wed, 23 Apr 2008 00:53:47 GMT

Dear Kevin and Peter,

Thanks once again for your attention to this issue.

I have liberated the eyeball! I offer this humble patch (see below). With 8 lines
of code and a couple of system properties, it is possible to set the WCM preview
host and port without using the virtualization server. I suspect you're not patching
2.1, but perhaps others will find this useful.

Clearly this is not an elegant patch.

I spent hours trying to make this work using the alfresco configuration override
system but I was not man enough. There are bugs, according to JIRA, relating
to problems with certain parameters being overridden and others not. So it goes.
I went pretty deep into those woods and eventually cut and ran.

I would respectfully suggest that your new version include the capability of configuring
WCM preview host and port without the virtualization server. To reiterate, I believe
there are problems with the virtualization server concept:

1. It won't run my app. Struts 2 is not particularly rare!
2. It is completely java-centric. So am I, but what if I want to do rails or php someday?
3. It relies on a hacked tomcat. Time marches on. Can you afford to continue
to hack tomcat each time a new version appears? What if someone is developing
in websphere and needs some of their features?
4. Managing app servers is hard enough. And one of the hardest parts is class loading
idiosyncrasies. It appears that the virtualization server is mired in that very tar pit.

Every one of those issues is solved by allowing the WCM preview function to be
configured inside of alfresco, pointing it to an external host and port.

Thanks,

Fred

Patch follows:

Index: projects/web-client/source/java/org/alfresco/web/config/ClientConfigElement.java
===================================================================
— projects/web-client/source/java/org/alfresco/web/config/ClientConfigElement.java    (revision 929)
+++ projects/web-client/source/java/org/alfresco/web/config/ClientConfigElement.java    (working copy)
@@ -510,6 +510,10 @@
     */
    public String getWCMDomain()
    {
+         String sysProp = System.getProperty("wcm-preview-domain");
+         if (sysProp != null)
+               return sysProp;
+
       String value = this.wcmDomain.get();
       if (value == null)
       {
@@ -531,6 +535,10 @@
     */
    public String getWCMPort()
    {
+         String sysProp = System.getProperty("wcm-preview-port");
+         if (sysProp != null)
+               return sysProp;
+
       String value = this.wcmPort.get();
       if (value == null)
       {‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Once the patch is in place, start alfresco with something like this:

-Dwcm-preview-domain=preview.yourdomain.com -Dwcm-preview-port=9999‍

Re: Configuring 'eyeball' icon without virtualization server

kvc — Wed, 23 Apr 2008 01:29:39 GMT

Great suggestion. Add agreed on managing class-loading idiosyncracies.

The overall goal is to enable in-context preview for any past, present, or future (potential) state of the site.
At a minimum, we need to enable preview of Staging before deployment for any type of site. This accomplishes
that nicely. Next best is to enable preview of any store (each sandbox is its own repository) for any type of site
in as automated, non-conflicting way as possible for any type of site. This is what we've done with 2.2.0E with
test servers, pooled sets of remote preview servers, and UI config of preview URLs for those servers (along with
auto-sync, check-out, and check-in). This is particularly good for non-Java and/or non-virtualizable sites, or
specifically for developers who want to sync a specific test server for preview of their modifications.

In the best case, we eliminate unnecessary banks of slave test servers and just enable preview via virtualization,
eliminating unnecessary class loading for things that have already been loaded and sit unmodified via a layer in
any user or workflow store. This isn't possible with non-Java-based web apps, and not always readily support
for all Java web apps frameworks (JSF being a notable example; Struts/Struts2, however, is fixed as of 2.1.1).

If you can file this as an improvement in JIRA, we can see about adding this as an enhancement in our upcoming
June Community release.

Thanks! Hopefully then, we'll have all bases covered from best case to worst case.

Kevin

Re: Configuring 'eyeball' icon without virtualization server

kvc — Wed, 23 Apr 2008 09:11:13 GMT

I've filed a feature improvement in JIRA for a more general solution for this overall problem:

http://issues.alfresco.com/browse/WCM-1173

Please comment as needed, and you can register as a watcher to see any update on status.

Kevin

Re: Configuring 'eyeball' icon without virtualization server

ftoth — Thu, 24 Apr 2008 14:32:27 GMT

Hi Kevin,

I read your JIRA issue and I have a question or two about one particular point.
If I understand correctly, this is the point that most applies to my case:

* If not using Virtualization Server and enable single server preview, specify URL of dedicated server and provide Preview icon for Staging Sandbox only

My question is, why "Staging Sandbox only"?

One of the things I've been working hard on is the "too many clicks" problem of moving
content onto a site. To that end, it seems important to me that as soon as content
is in a user's sandbox, they should be able to see it. I thought that was the whole point
of the AVM and transparent overlays, etc. If the user has to promote content to the
staging sandbox before they can see it, it's more clicks.

Can you explain?

Thanks,

Fred

Re: Configuring 'eyeball' icon without virtualization server

pmonks — Thu, 24 Apr 2008 20:20:31 GMT

It's trivial to pass through the sandbox id as part of the URL to the external web app, so support for previewing any sandbox (whether staging or not) in an external web app is certainly possible - in fact I implemented this approach just last week.

Of course the external web app has to be able to receive that sandbox id parameter and do something sensible with it ie. retrieve content from that specific sandbox only. In last week's case, for example, the app holds on to the sandbox id and passes it to a web script, which then retrieves the content from that sandbox. This effectively means that a single copy of the external web app is capable of surfacing content from any sandbox in the system, and provided the "eye of Sauron" button passes through the sandbox id to the external application correctly, it's as if that single copy of the external app is fully virtualised (even though the virtualisation server is nowhere in the picture).

Cheers,
Peter

Re: Configuring 'eyeball' icon without virtualization server

ftoth — Thu, 24 Apr 2008 23:19:01 GMT

Peter,

How did you do it without the virtualization server? Don't you
need it to configure the eyeball icon (hence my patch)?

Thanks,

Fred

Re: Configuring 'eyeball' icon without virtualization server

pmonks — Fri, 25 Apr 2008 05:44:55 GMT

In this case we did use the virtualisation server but it did nothing more than redirect all requests to the external web app (performing URL translation in the process) This was achieved using a servlet filter that was installed into the Web Project and that was configured for all requests.

It would be preferable to patch the code that generates the URL for the Eye of Sauron to generate the external web app URL directly (since then the virtualisation server would not be needed for preview purposes at all), but in this case we didn't have the luxury of time.

Still, I'd like to investigate this approach further when I do have time, with the intent of adding it as a patch to WCM-1173. I think this will be a reasonably small / easy change if the mapping between Web Projects and external web app URI templates is done outside the UI (eg. via Spring configuration). A more "professional" solution would add the external URI template as metadata to the Web Project (and update the Web Project Wizard UI accordingly), but that's a bit more involved and I figure the primary value is in being able to configure the preview URI somehow, even if it has to be done via a Spring config file.

Cheers,
Peter

Re: Configuring 'eyeball' icon without virtualization server

pmonks — Tue, 13 May 2008 05:50:36 GMT

If anyone's interested, I've just attached a patch to http://issues.alfresco.com/browse/ALFCOM-334 (the renamed version of WCM-1173) that allows the URL for the "Eye of Sauron" to be configured via Spring configuration. It would be great if it could get a bit more real world testing so that we can get some confidence about merging it into the 2.2.1 release. If anyone does take it for a spin and hits issues, please let me know via a private forum message.

Note that the ideal end state is to allow the preview URI to be configured via the Web Project Settings Wizard rather than deep in the bowels of Spring, but in the interest of time I decided to skip the (excessively time consuming!) JSF UI work and simply use Spring - I figure that getting this functionality out there quickly took priority over optimising the usability for such a low volume / one-off type task.

Cheers,
Peter