Configuring 'eyeball' icon without virtualization server

[ftoth]

Hi all,

For reasons documented elsewhere, we cannot run our application
under the 2.1 virtualization server (we use struts).

We're working on our own preview server that gets around that limitation
by previewing from the AVM CIFS mount. This works fine, but only if we
can type the actual URL in the preview server.

It would be great if we could use the eyeball icon. All we would need to do
is change the IP address and port. But, as far as I can tell, the only documented
way to do that is by configuring the correct values in the virtualization server,
which then registers these values with alfresco at startup.

Is there any other way? It would be useful if there was some way in alfresco
to set the defaults for these values without requiring the virtualization server.

Is there a way?

Many thanks,

Fred Toth

[pmonks]

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

1. (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.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

[ftoth]

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

[pmonks]

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

[ftoth]

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

[kvc]

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

[ftoth]

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‍

[kvc]

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

[kvc]

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

[ftoth]

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