[opencms-dev] importexport question

Edward Zarecor edward_zarecor at harvard.edu
Tue Nov 8 19:45:39 CET 2005

Is it true that static export outside the app-server context root isn't 
possible?  It seems there are workplace dependencies on settings in 
opencms-importexport.xml that make this impossible.

Here's why I think this is true, validation and/or workarounds would be 
greatly appreciated.

What I'd like to do is:

1. Have opencms running on Weblogic accessible by content editors [this 
works just fine after some tweaks.]
2. Weblogic would NOT be available via pass through over the Weblogic 
Apache bridge, but listening on a different port, say 7001, locked down 
with ACL's, etc.
3. The edited site would be staticly exported in it's entirety under an 
apache virtual host.  It's truely static when published and relatively 
small, so this works well for me -- allows webserver farms, etc.

Here's the issue I'm having:

When I change the export path to be outside the context root of the 
application server -- to the webroot of Apache.  And, I change the 
rfs-prefix so my links work in the statically exported copy, opencms 
itself is no longer able to see it's style sheet.  Here's the config:

... snip ...

... snip ...

                        <!--rfs-prefix></rfs-prefix-->   works when I 
export, breaks opencms interface.
interface works, content not where I want it.
... snip ...

Here's the stylesheet link if rfs-prefix is empty:

<link rel="stylesheet" type="text/css" 

Here's the link assuming rf-prefix is: ${CONTEXT_NAME}/export

<link rel="stylesheet" type="text/css" 

This is as expected.

However, since the link has changed in the system resources to not 
include the context name and export folder the style sheet isn't 
resolved.  Although the resource exists under the Apache webroot, it is 
not seen because of the port difference.  I'm connecting to Weblogic on 
7001 and Apache is listening on 80.

Any way to work around this?  Other than, say, rsync?  It seems to me 
this would be a useful feature and that it would be ideal if the 
workplace wasn't dependent on settings the end user might change.



More information about the opencms-dev mailing list