2

同じユーザー セッションへの 2 つの呼び出しに対して @SessionScoped Bean の異なるインスタンスを取得しています。何がこれにつながる可能性がありますか？

@SessionScoped アノテーションが付けられた Bean がサーブレットと RESTEasy JAX-RS Web サービス エンドポイントに注入されます。ユーザーは、証明書を使用して HTTPS を使用してログインします。最初の呼び出しは RESTEasy エンドポイントに行きます。ブラウザからの次の呼び出しはサーブレットに行きます。両方の呼び出しで同じ Bean インスタンスが期待されますが、それらは異なります。... 何か案は？

JBoss 7.0.1 の使用

豆：

@Stateful
@SessionScoped
public class MyBean implements Serializable { ... }

REST エンドポイント:

@Path("/one")
public class MyService extends JAXRSPlugin { 
   @Inject MyBean myBean;
   ... 
}

サーブレット:

@WebServlet(urlPatterns = "/two", asyncSupported = true)
public class MyServlet extends HttpServlet { 
   @Inject MyBean myBean;
   ... 
}
4

1 に答える 1

1

REST サービス メソッドは、状態を共有するための HttpSession を持つことを実際には想定していないことがわかりました。REST サービスはステートレスであると想定されています。@SessionScoped Bean は、設計上 @RequestScoped であるかのように与えられます。

この場合、私が望んでいることではありませんが、これらの呼び出しに REST を使用しない方がよいかもしれません。主に、REST サービス クラスのメソッドへの URL パスの便利なマッピングが必要でした。私の知る限り、サーブレットにはそのようなパスからメソッドへのマッピングはありません。

基本的には、(1) 1 つのサーブレットで使用するディスパッチ メカニズムを見つける、(2) 複数のサーブレットを使用する、(3) @Context HttpServletRequest を悪用して HttpSession にアクセスすることで REST を誤用する、の 3 つのオプションがあります。API を悪用するのは好きではないので、オプション 3 は使用しません。CDI はオプション 2 をクールにするかもしれませんが、オプション 1 はおそらくより一般的です (したがって、他の人が保守しやすいかもしれません)。

于 2012-09-02T16:28:30.780 に答える