2

ページ名を PathParam として指定すると、安らかなサービスから特定の jsp ページを返せるようにしたいと考えています。これらのページは、アプリケーションのデプロイ後に別のグループの人々によって追加および削除されます。

Viewableオブジェクトを使用することは適切な方法だと思います (私はより良い/正しい方法を受け入れています)。

@GET
@Produces(MediaType.TEXT_HTML)
@Path("{page}") 
public Response showJSP(@PathParam("page") String page) {
    Viewable loadPage = null;

    try {
      loadPage = new Viewable("/" + page, null);
    } catch (Exception e) {
        return Response.status(404).build();
    }

  Response ret = Response.ok(loadPage).build();

//    if (ret.getStatus() == 500){
//          ret = Response.status(404).build();
//      }

 return ret;
}

上記は私の実験的なコードであり、エラーを処理する試みが含まれています。

ページ名が有効な jsp ページである限り、これは正常に機能します。無効なページを渡すと、

500 Internal Server Error

java.io.IOException: The template name, /someWrongFileName, could not be resolved to a fully qualified template name.....

私が理解したのは、このエラーは Viewable オブジェクトの内部で生成されるため、例外はスローされず、もちろん応答は有効なページであるため、500 ステータスのチェックは機能しません。

間違っていると確信しているいくつかのことをハックすることができます。

ページが無効であることを検出して、単に 404 を返すようにしたいと考えています。

私は正しい道を進んでいますか、それとももっと良い方法がありますか?

正しいパスにいる場合、どうすれば悪いページ名を検出できますか?

4

2 に答える 2

2

あなたのようにエラーをキャッチしようとしましたが、かなり難しいようです。クラスがこのように使用されることは決して意図されていなかったと思います。

Viewable インターフェースを使用すると、アプリケーションのリソースの表現を視覚化する手段として JSP を使用できます。一般に、リソースは、JSON、XML にシリアライズするか、Viewable コンストラクターに渡す POJO によって表されます。

私が理解している限り、ここでやろうとしていることは少し異なります。あなたのリソースは JSP そのものであり、オブジェクトを Viewable コンストラクターに渡さずに、クライアントがページを利用できるようにしたいだけのようです。

HTTP 404 エラーは、リソースが見つからないことを意味します。あなたの場合（JSPをリソースとして扱いながら）、JSPへのパスが正しくない場合、これがまさに起こるので、ステータスコードを使用したい理由を理解しています。

ただし、使用しようとしているインターフェイスの作成者は、この問題について別の意見を持っていたと思います. 彼らは、JSP をリソースとしてではなく、それらを表現するためのツールと見なしていました。ビューの構築は、ここではまったく別のものとして見られます。サーバー内部の問題であり、クライアントから隠されるべきもの。クライアントは、HTML 文字列を含む応答を受信する必要があります。それがどのように起こるかはまったく問題ではありません。このようなコンテキストでは、HTTP 500 は完全に理解できます。

JSP のコンテンツをフェッチするために GET リクエストのみを使用したい場合は、Viewable インターフェイスまたは Jersey 自体を無視することができます。web.xml が適切に設定されていれば、いずれにしてもページにアクセスできるはずです。アノテーション付きメソッドに JSP 名を渡す必要はありません。ドキュメント自体へのパスを使用するだけです。カスタム 404 も web.xml で処理できます。

MyApp というプロジェクトがあり、パスにデプロイされているとします。<host>:<port>/MyApp

その Web ページ ディレクトリの構造は次のとおりです。

-Web pages
|-META-INF
|-WEB-INF
|-error
|\-error404.jsp
|-package1
||-ResourceClass
||\-page1.jsp
|-pages
||-plainpage1.jsp
|\-plainpage2.jsp
\-index.jsp

ここで、web.xml が次のようになっているとします。

<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
<servlet>
    <servlet-name>ServletAdaptor</servlet-name>
    <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>ServletAdaptor</servlet-name>
    <url-pattern>/resources/ *</url-pattern>
</servlet-mapping>
<error-page>
    <error-code>404</error-code>
    <location>/err/err404.jsp</location>
</error-page>
<session-config>
    <session-timeout>
        30
    </session-timeout>
</session-config>

Viewable インターフェイスを使用して、実際のリソースのページを表示できます。これが、インターフェイスの使用方法です。リソース自体ではなく、リソースの html 表現を表示する手段として。

package package1;

@Path("/")
public class ResourceClass {    

@Path("/POJO/{id}")
@GET
public Response tryToGetBadView(@PathParam("id") String id) {
    MyPOJOClass entity = null;
    //fetch your POJO from database/file/whatever          
    return Response.ok().entity(new Viewable("page1",entity)).build();        
}
}

次のようなパスを使用して、適切なビューを取得できます。

<host>:<port>/MyApp/resources/POJO/1

また、Jersey Servlet Container の助けを借りずにプレーンな JSP を取得することもできます。ファイルはそこにあり、それ自体以外の表現は必要ありません。Jersey Servletコンテナへのパスは次のように指定されています

<host>:<port>/resources/*

そのため、コンテナーを省略して、Web Apps フォルダーから通常のファイルにアクセスできます。画像、CSS、および JSP。このような：

<host>:<port>/MyApp/pages/plainpage1.jsp

あなたが得るのと同じ方法

<host>:<port>/MyApp/index.jsp

Viewable オブジェクトを構築するために通常使用するページでさえ (POJO を渡さなくても適切に動作するという保証はありません)

<host>:<port>/MyApp/package1/ResourceClass/page1.jsp

これらの「静的」ファイルの場合、存在しないページの名前を選択するたびに 404 が返されます。表示されるエラー ページは、web.xml で指定されたものになります。

これは私がそれを行う方法です。Jersey を使用してプレーンな JSP を提供するのはやり過ぎのように思われ、不要な複雑さをもたらします。意図したとおりでない場合は、デザインを再考することをお勧めします。

Jersey が使用されていない場合でも、RESTful と見なすことができる方法でページにアクセスできることに注意してください。

実験的なコードに固執したい場合は、IO API を使用して Web ページ フォルダー内のディレクトリにアクセスし、要求されたファイルが存在するかどうかを手動で確認することもできます。それは醜いでしょうが、うまくいくかもしれません。

于 2012-06-01T19:14:13.207 に答える
2

別の投稿で探しているものを見つけ、以下の方法を変更しました。

@GET
@Produces("text/html")
@Path("{page}") 
public void showJSP(@Context HttpServletResponse response,
                    @Context HttpServletRequest request,
                    @PathParam("orderId") String orderId) throws ServletException, IOException {
    request.getRequestDispatcher(page + ".jsp").forward(request, response);
}

これにより、探している 404 が得られ、すべてのサービスが引き続き機能します。

これがこれを行う「間違った」方法である場合、私はまだアイデアを受け入れていますが、今のところうまくいきます。

于 2012-06-05T22:10:37.770 に答える