Re: [ebxmlms-develop] Request musings (including nasty catch)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

<!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>
Peter, 
 
getPendingMessages() is for admin purpose. It lets you see how many
messages are in the "outbox" and lets you make a correct decision on
whether you should stop Hermes or not. 
 
getReceivedMessageIds() is for message receiving purpose. That is, if
you use NoMessageListenerImpl, there will be no URL posting to you, nor
onMessage() callback. You have to call that function to find out how
many messages are in the "inbox". 
 
So as you see, they are in two different categories. We don't see
inconsistency here. 
 
If I got it right, you want 2 independent components, one for message
receiving, another for status query. In that case, how about using
NoMessageListenerImpl in both. In the message receiving component, you
can call getReceivedMessageIds() and receive() to get the message. In
the status query component, you can always getReceivedMessageIds() and
check the status, and you never get the message out. What do you think
about this? 
 
The reason for using string for retry interval is historical. We want
to support string like "P2M" initially. Of course, it's still pending. 
 
getSentMessageIds() and getGivenUpMessageIds() do not exist now. 
 
Regards, -Patrick 
 
 
 
Mayne, Peter wrote: 
<blockquote type="cite"
 cite="mid...@s-...">
 <meta http-equiv="Content-Type" content="text/html; ">
 <meta name="Generator"
 content="MS Exchange Server version 5.5.2654.45">
 <title>Request musings (including nasty catch)</title>
 I've just written a status servlet so I can display
the status of messages. There seems to be a rather nasty catch. 
 Request.getPendingMessages() ignores the
ApplicationContext, whereas Request.getReceivedMessageIds() requires
the ApplicationContext. In particular, getReceivedMessageIds() seems to
only return the messages that match the Request's ApplicationContext.
 Firstly, this seems to be inconsistent. Why should
getPendingMessages() return all the messages, whereas
getReceivedMessageIds() returns only what matches the
ApplicationContext?
 Secondly, and much more importantly, if I want to
discover all of the received messages, I have to specify the
ApplicationContext("*","*","*","*"). However, creating a Request with
this ApplicationContext registers this servlet as the global message
listener. Since this servlet only exists to look at the status of
messages, and particularly since I'm using the NoMessageListenerImpl
listener, all incoming messages are now thrown away until I reregister
my proper global listener.
 I really need a version of Request that doesn't
register the ApplicationContext, because without it, I can't look at
message statuses. Looking through the code, I see that I get registered
in Request if appContext!=null, and I also get registered when I send a
message using send()/sendReliably(), whether I like it or not (and I'm
pretty sure I don't like it).
 It would be much better if registering an
ApplicationContext was a separate function that is only done when I
want it to be, and not when something else feels like it. How about
making Request.register() a public method taking MessageListener and
ApplicationContext arguments, and not calling it from anywhere in
Hermes, including send()/sendReliably()?
 Other musings: 
 Why is the retryInterval passed to Request a
String? Why not just make it a long? 
 Request has a getPendingMessages() and
getReceivedMessageIds() (slightly inconsistent naming). Am I missing a
getSentMessageIds() and getGivenUpMessageIds(), or do they just not
exist?
 Request requires that I pass a toMSHUrl, even
though it is ovbiously not required. Passing null causes a
RequestException later. I'm not entirely sure that a message listener
and a transport type are required, either.
 PJDM 
 -- 
 Peter Mayne 
 Technology Consultant 
 Spherion Technology Solutions 
 Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602 
 T: 61 2 62689727&nbsp; F: 61 2 62689777 
 
 <pre>The information contained in this email and any attachments to it:

(a) may be confidential and if you are not the intended recipient, any interference with, 
use, disclosure or copying of this material is unauthorised and prohibited; and

(b) may contain personal information of the recipient and/or the sender as defined 
under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
collect, hold and use such information and any personal information contained in a 
response to this email, for any reasonable purpose in the ordinary course of 
Spherion's 
business, including forwarding this email internally or disclosing it to a third party. All 
personal information collected by Spherion will be handled in accordance with 
Spherion's Privacy Policy. If you have received this email in error, please notify the 
sender and delete it.

(c) you agree not to employ or arrange employment for any candidate(s) supplied in 
this email and any attachments without first entering into a contractual agreement with 
Spherion. You further agree not to divulge any information contained in this document 
to any person(s) or entities without the express permission of Spherion.

  </pre>
  </font> </blockquote>
</body>
</html>