cancel
Showing results for 
Search instead for 
Did you mean: 

Configuring 'eyeball' icon without virtualization server

ftoth
Champ in-the-making
Champ in-the-making
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
13 REPLIES 13

pmonks
Star Contributor
Star Contributor
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

ftoth
Champ in-the-making
Champ in-the-making
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

pmonks
Star Contributor
Star Contributor
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

pmonks
Star Contributor
Star Contributor
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