2017-09-11 12 views
0

現在、EE6/JSFアプリケーションをデプロイメントパスsomeserver.com/appから独自のサブドメインapp.someserver.comに移動しています。コンテキストルートが「root」の場合は、どのように#{request.contextPath}を使用しますか?

ほとんどのことがスムーズに行われていますが、基本的に存在しないコンテキストルートをWebレイヤーがどのように処理するかは予想外の問題です。私たちが発見し、早期に固定

ことの一つは、我々が設定されたCookieは、そのパスが"""/app"から短縮していたため、全体ではなくアプリケーションのために、サーバー上のフォルダごとにだけ読めるということでした。私たちは、今、私たちはJSFに発生するハイパーリンクと同様の問題を発見した

<a href="#{request.contextPath}">Go to home page</a> 

これは、以前href="/app"としてレンダリングしないとうまくいきましたが、今href=""とのリンクは、もはや当然のことながらアクティブになってました。私はそれがhref=""/"と言って欲しい。

そのための洗練されたソリューションはありますか?

はそう単純"/"と空のコンテキストパスを交換し、我々はまた、フォーム

<a href="#{request.contextPath}/projects">Go to projects page</a> 

のリンクを持っていることに注意してくださいすることは十分ではありません。

明らかなものがありませんか? here(私たちが経験したものと一致する)の説明を見ましたが、可能な解決策について詳しく説明しませんでした。

答えて

0

私ははっきりと考えていませんでした。私はとても#{request.contextPath}が生成する文字列を修正することに重点を置いていました。私は基本的に間違って使用していました。

最も簡単な解決策は、単にアプリケーションのルートに到達するために

<a href="#{request.contextPath}/">...</a> 

(末尾のスラッシュ)を使用し、全くスラッシュなしhref="#{request.contextPath}"を使用しないことです。

これにより、両方のケースが解決されます。アプリケーションが「some_folder」にデプロイされている場合は、リンクは"some_folder/"になります。アプリケーションがサーバールートにデプロイされている場合、リンクは"/"になります。

これは、同じトラップに遭遇した人に役立ちます。

関連する問題