2 つのクライアント (A と B) とサーブレットがあります。クライアントがリクエストをSERVLETに送信すると、SERVLETはリクエストをクライアントBにリダイレクトし、クライアントBはクライアントAに応答を返します.クライアントはサーブレットではありません!!! これらは通常のソケット クライアントであるため、従来のサーブレット リダイレクトは不可能です。
トラブルシューティングに関する提案はありますか???
どうもありがとう!!!!
2 つのクライアント (A と B) とサーブレットがあります。クライアントがリクエストをSERVLETに送信すると、SERVLETはリクエストをクライアントBにリダイレクトし、クライアントBはクライアントAに応答を返します.クライアントはサーブレットではありません!!! これらは通常のソケット クライアントであるため、従来のサーブレット リダイレクトは不可能です。
トラブルシューティングに関する提案はありますか???
どうもありがとう!!!!
まず、Java シリアライゼーションを使用して HttpServletRequest または HttpServletResponse をシリアライズすることはできません。これらの API に準拠するオブジェクトには通常、本質的にシリアル化できないサーブレット実装スタック内の「スタッフ」への参照が含まれます。
次に、リクエストを別のクライアントに「リダイレクト」することはできません。HTTP プロトコルの観点からは意味がありません。
リダイレクトは、クライアントがサーバーにリクエストを送信し、サーバーの応答に「そのリクエストを別の場所で試してください」という 3xx ステータス コードが含まれている場合に発生します。これは、別のクライアントではなく、別のサーバーへのリダイレクトです。
リダイレクトが何を意味するかの詳細を無視することさえあります。HTTP クライアント ロールにあるものに HTTP 要求を送信することはできません。それを予期せず (聞いて)、どうすればよいかわかりません。(実際、それは HTTP プロトコルの違反になります。)
第 3 に、「通常のソケット クライアント」は HTTP サービス (サーブレットなどを使用して実装) と通信できません。クライアントは、HTTP サービスによって認識されるようにするために、少なくとも HTTP プロトコルのサブセットを実装する必要があります。それを「手動で」実装することは可能ですが、それは悪い考えです...無料で使用できる高品質の実装がある場合。
要するに、あなたがしようとしているように見えることは、不可能/無意味です。(私があなたの質問を正しく理解していれば...これは議論の余地があります。)
ここで実際に何をしようとしているのかを説明していただければ、賢明な代替アプローチを提案できるかもしれません。
サーバー全体で 2 つの Java クライアント アプリケーションを接続しようとしています。クライアントは、他のクライアントと直接通信できるようになります。
文字通り、HTTP を使用してそれを行うことはできません。しかし、あるクライアントから別のクライアントにメッセージを転送する HTTP サーバー/サーブレットを構築することはできます。例えば
ただし、プレーンなソケット クライアントではそれができないことに注意してください。クライアントは HTTP クライアントである必要があります。
サーバーが HTTP サーバー/サーブレットであるという要件を捨てる準備ができている場合は、「単純なソケット」クライアントがサーバーへの二重接続を開き、サーバーがクライアント間で「メッセージ」を渡すようにすることができます。これには、メッセージング用のカスタム「プロトコル」の実装が必要です。
3 番目の選択肢は、既存の RPC またはオブジェクト ブローカー テクノロジを使用することです。例: RMI、CORBA、ICE など