Michel Erard pisze:
Hello,
Im using cocoon 2.2 and have currently some problems, if there is a
proxy in front of my application.
The application is deployed in a jetty and in my environement I'm usinga
a apache httpd as proxy in front of the application with this configuraion:
<Location /APP_NAME/cocoon-forms-impl>
ProxyPass http://localhost:8888/APP_NAME/cocoon-forms-impl
ProxyPassReverse http://localhost:8888/APP_NAME/cocoon-forms-impl
ProxyPassReverseCookiePath / /
Allow from all
</Location>
<Location /APP_NAME/cocoon-ajax-impl>
ProxyPass http://localhost:8888/APP_NAME/cocoon-ajax-impl
ProxyPassReverse http://localhost:8888/APP_NAME/cocoon-ajax-impl
ProxyPassReverseCookiePath / /
Allow from all
</Location>
<Location /APP_NAME>
ProxyPass http://localhost:8888/APP_NAME
ProxyPassReverse http://localhost:8888/APP_NAME
ProxyPassReverseCookiePath / /
Allow from all
</Location>
This works fine. In my sitemap I make the forms transformation like this:
<map:transform src="stylesheets/forms-style.xsl">
<map:parameter name="dojo-resources"
value="{servlet:ajax:/resource/external/dojo}" />
<map:parameter name="forms-resources"
value="{servlet:forms:/resource/external/forms}" />
</map:transform>
But know my Problem. In the productive installation I've another Proxy
in front of the machine. The users are using an url like this:
https://www.HOST_NAME.com/LOGIN_PATH/APP_NAME/[...]
And now the dojo an forms resources aren't found any more. Because
cocoon works internally with the webapp's name
'/APP_NAME/cocoon-forms/...' and this url
https://www.HOST_NAME.com/APP_NAME/cocoon-forms/.. is blocked by this
WEB-Entry-Server.
My Solution for this problem was to set the dojo and forms resources
relative:
<map:transform src="stylesheets/forms-style.xsl">
<map:parameter name="dojo-resources"
value="../cocoon-ajax-impl/resource/external/dojo" />
<map:parameter name="forms-resources"
value="../corix-forms-impl/resource/external/forms" />
</map:transform>
so the links to the javascripts in the generated html is now:
https://www.HOST_NAME.com/LOGIN_PATH/APP_NAME/main/../cocoon-forms/[...]
this solution works nearly. The dojo.js for example is found by the
browser. But when he makes a request to
/APP_NAME/cocoon-ajax-impl/resource/external/dojo/__package__.js
I'm getting an error in the jetty. So the requests passes correctly
through all the proxys, but cannot be processed by cocoon:
Your problem comes from the mismatch of URLs and this can't be fixed by relative URLs or other
tricks like that. There are many cases where Cocoon uses absolute URLs (like one you mention above)
because only such make sense. They are constructed using following pattern:
/[DispatcherServletMountPath]/[SitemapServletMountPath]/[TheRest]
Where [DispatcherServletMountPath] is being configured in web.xml file from
myCocoonWebapp/src/main/webapp/WEB-INF (assuming myCocoonWebapp has been created using archetype).
The declaration looks following:
<servlet-mapping>
<servlet-name>DispatcherServlet</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
The [SitemapServletMountPath] part comes from SitemapServlet bean configuration (mountPath) and
usually contains block's name. The rest is actual path relative to block's context.
If you want to prefix all absolute URLs with LOGIN_PATH then I would advise to change configuration
of DispatcherServlet to:
<servlet-mapping>
<servlet-name>DispatcherServlet</servlet-name>
<url-pattern>/LOGIN_PATH/*</url-pattern>
</servlet-mapping>
And configuration of proxy, accordingly. General advice is to always have 1-1 mapping between
absolute paths. This way you can be sure that you don't run into some nasty problems.
I hope that helps you.
--
Best regards,
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
