Re: [ebxmlms-develop] Setup of ApplicationContexts

[Patrick Y. <kc...@ce...>]

RE: [ebxmlms-develop] Setup of ApplicationContextsIn that case, there =
will be only one error handler. This would be fine for your application. =
But in the case of multiple clients connecting to the same hermes =
server, we should make it more flexible. That's the argument for us to =
find the AppContext based on ref to message ID.

How about we solve it this way:
1. Set up a receiver with app context (*,*,*,*) and a normal message =
listener. This way, the request will poll hermes server from time to =
time for new messages and call onMessage() to deliver the message to =
application.
2. Set up a sender with app context (*,*,*,*) and pass =
NoMessageListenerImpl as message listener. This is a newly created =
message listener implementation which is "compatible" with a normal =
message listener. But it will stop the request from polling hermes =
server. The good thing is that even you will "override" the receiver's =
registration by this action, the receiver can still poll the messages =
successfully. This is what we mean by "compatible". :-)

What do you think about this? You can find NoMessageListenerImpl in the =
latest source. We will work on a nightly source tarball and put it onto =
our web site tomorrow.

Regards, -Patrick

  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Wednesday, April 02, 2003 12:40 PM
  Subject: RE: [ebxmlms-develop] Setup of ApplicationContexts


  If I modify MessageServiceHandler.onMessage(EbxmlMessage ebxmlMessage, =
Map requestProperty) by changing the last statement of=20

              if (isError) {=20
                  logger.info("Error message received");=20
                  final String refToMessageId =3D =
ebxmlMessage.getMessageHeader().=20
                      getRefToMessageId();=20
                  logger.info("RefToMessageId: " + refToMessageId);=20
                  if (refToMessageId !=3D null) {=20
                      final ApplicationContext refToAppContext =3D=20
                          =
messageServer.getApplicationContext(refToMessageId);=20

  to hard code my universal ApplicationContext:=20

                      final ApplicationContext refToAppContext =3D=20
                          new ApplicationContext("*","*","*","*");=20

  I get what I want: errors are sent to my universal listener, instead =
of back to the sender.=20

  However, is this a good thing to do? If so, should there be some way =
of specifying the ApplicationContext that errors are to be delivered to, =
rather than hardcoding it like this? (I don't think it would be =
difficult to add this to the msh.properties.xml file. I'll try it if =
anyone thinks it's worth the effort.) And should there be a way of =
sending messages without having an ApplicationContext registered for =
each message? (I suspect this would be a bit much to change.)

  If this isn't a good thing to do, is my application architecture =
broken? If errors are supposed to return to the sender, how long must =
the sender (and therefore possibly the user) wait for the error?

  What is the right way of doing this?=20

  PJDM=20
  --=20
  Peter Mayne=20
  Technology Consultant=20
  Spherion Technology Solutions=20
  Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602=20
  T: 61 2 62689727  F: 61 2 62689777=20

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

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