|
From: Patrick Y. <kc...@ce...> - 2003-06-11 02:48:29
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body>
<blockquote type="cite"
cite="mid...@s-...">
<div><span class="691385723-09062003"><font face="Arial" size="2">When
using Hermes in ASP mode, how do you stop client A from registering an
application context to receive client B's messages?</font></span></div>
<div><span class="691385723-09062003"></span></div>
</blockquote>
<br>
That requires a more sophisticated authorization mechanism to avoid the
clients to register arbitrary AppContext.<br>
<br>
<blockquote type="cite"
cite="mid...@s-...">
<div> <span class="691385723-09062003"><font face="Arial" size="2">If
I use a ClientMessageListenerImpl, my message sender has to wait until
it receives a response (which could be a long time, depending on the
request parameters) before it can exit. This could be inconvenient.
(In my case, I have a servlet that accepts user input and sends a
message. I don't really want to spin off background threads just to
wait for a status reply when I have a perfectly good listener already
waiting on the server.)</font></span></div>
<div> </div>
<div><font face="Arial"><font size="2">I spent much of yesterday
trying to figure out a way of telling the Request to use the existing <span
class="691385723-09062003">registered </span>MessageListener for th<span
class="691385723-09062003">e given</span> ApplicationContext, but
Requests, ApplicationContexts, MessageListeners, and message
parameters all appear to be very intertwined and confusing.<span
class="691385723-09062003"> Any ideas on how to do this?</span></font></font></div>
</blockquote>
<br>
Sigh... I must admit that, there is no clean way, if not none, to
achieve your use case currently. It's time to re-engineer the current
registration mechanism.<br>
<br>
<blockquote type="cite"
cite="mid...@s-...">
<div><font face="Arial" size="2"><span class="691385723-09062003"><font
face="Times New Roman" size="3">> Maybe again, a hook should be
used to deal with any customized MessageListener first. But the hook</font></span></font></div>
<div><font face="Arial" size="2"><span class="691385723-09062003"><font
face="Times New Roman" size="3">> should be per-AppContext. Any
idea?</font><br>
</span></font></div>
<div><font face="Arial" size="2"><span class="691385723-09062003">Maybe
something like the following in msh.properties.xml:</span></font></div>
<div><font face="Arial" size="2"><span class="691385723-09062003"></span></font> </div>
<div><font face="Arial" size="2"><span class="691385723-09062003">
<div><font face="Arial" size="2"><span class="691385723-09062003"><MessageListeners></span></font></div>
<div><font face="Arial" size="2"><span class="691385723-09062003">
<ApplicationContext cpaId="A" conversationId="B" service="C"
action="D"></span></font></div>
<div><font face="Arial" size="2"><span class="691385723-09062003">
<Class name="local.ListenerE" parameter="F"/> </span></font></div>
<div><font face="Arial" size="2"><span class="691385723-09062003">
</ApplicationContext></span></font></div>
</span> </font>
<div><font face="Arial" size="2"><font face="Arial" size="2"><span
class="691385723-09062003"> <ApplicationContext cpaId="*"
conversationId="*" service="*" action="*"></span></font></font></div>
<div><font face="Arial" size="2"><font face="Arial" size="2"><span
class="691385723-09062003"> <Class name="local.ListenerG"
parameter="H"/> </span></font></font></div>
<div><font face="Arial" size="2"><font face="Arial" size="2"><span
class="691385723-09062003"> </ApplicationContext></span></font></font></div>
<font face="Arial" size="2"></MessageListeners></font></div>
<div><font face="Arial" size="2"><span class="691385723-09062003"></span></font> </div>
<div><font face="Arial" size="2"><span class="691385723-09062003">When
Hermes starts, it will create an instance of ListenerE using the
default constructor, call init("F"), and serialise that instance for
ApplicationContext("A","B","C","D"). Ditto for ListenerG with the
global ApplicationContext (and for as many others as are specified).</span></font></div>
<div><font face="Arial" size="2"><span class="691385723-09062003"></span></font> </div>
<div><font face="Arial" size="2"><span class="691385723-09062003">It
is an error not to provide a listener for the global
ApplicationContext. (A ClientMessageListenerImpl with a file URL may
be used, of course.) Any attempt by a client to register a listener
with one of these ApplicationContexts is an error. It must be possible
for a client to specify that one of these MessageListeners be used
when creating a new Request and sending a message, including for
Hermes-generated messages.</span></font></div>
</blockquote>
It's a good idea to have registrations done statically. We will keep
the current dynamic registration mechanism through Request object.
Both static registration through properties file and dynamic
registration through Request object will be recorded in MSHConfig
table, so that Hermes can remember all registrations after restart.<br>
<br>
We still havn't solved the problem for specifying server side
MessageListener through dynamic registration. Or we may have to give
up. The same applies to UrlResolver and CertResolver, which we may need
to get it to be AppContext-wide settings instead of global settings.
When doing dynamic registration, it is impossible to get the hook to
run on server by only specifying a class name by Request object,
without the JAR files being deployed to the Hermes server.<br>
<br>
Regards, -Patrick<br>
<br>
<br>
<br>
</body>
</html>
|