Re: [ebxmlms-develop] URL and File base document receipt

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

Dear Anthony,

It's great to drill in the source code =3D). The code that I am =
referring to is the current version in CVS source tree (pre-0.9.2.0).

The subtlety of message delivery lies on the fact that the message =
listener that an application register with the Request object is never =
called directly by MSH. For the message polling approach, the message =
listener of the client application is called by the Request object if it =
receives any new message from MSH. If the application is using trusted =
repository, although the message listener seems to be unchanged as =
stated in the following block, the MSH actually has no implementation of =
the client message listener, and it results in a ClassNotFoundException =
error. Therefore, in the trusted repository approach, the only correct =
way is to use the =
hk.hku.cecid.phoenix.message.handler.MessageListenerImpl.

if (this is a file protocol && client url returning a path that is _not_ =
in
trusted repository) {
    ... =20
}
else {
>>>>    - use this clientURL to do registration directly
}

Hope this helps.

--
Frankie Lam
Assistant Technology Officer
Center for E-Commerce Infrastructure Development (CECID)
Dept. of Computer Science and Information Systems
The University of Hong Kong
Tel: (852) 22415737
Fax: (852) 25474611
  ----- Original Message -----=20
  From: ant...@re...=20
  To: 'Frankie Lam'=20
  Cc: ebx...@li...=20
  Sent: Friday, October 25, 2002 7:22 AM
  Subject: RE: [ebxmlms-develop] URL and File base document receipt

  Sorry to keep drilling at this but...

  What version of the code are you looking at? From the downloaded 914 =
version
  the deliverToApplication() in MessageServiceHandler
  has only the following code

      private synchronized void deliverToApplication(ApplicationContext
          appContext, EbxmlMessage ebxmlMessage)
          throws MessageServiceHandlerConnectionException {
          final MessageServiceHandlerConnection mshConnection =3D
              (MessageServiceHandlerConnection) mshConnectionTable.
              get(appContext);

          if (mshConnection =3D=3D null) {
              final String errorMessage =3D "Unknown application =
context: "
                  + appContext.toString() ;
              throw new =
MessageServiceHandlerConnectionException(errorMessage);
          }
          final MessageListener messageListener =3D mshConnection.
              getMessageServiceHandlerConfig().getMessageListener();
          messageListener.onMessage(ebxmlMessage);
      }

  it doesn't have any isDelivered checks as you described below.
  which basically means that the only thing that deliverToApplication =
does is call the onMessage of the message listener, I can't see the code =
that you have provided anywhere? Is there a new version since 914, 913 =
has the same code that I described above.

    -----Original Message-----
    From: ebx...@li... =
[mailto:ebx...@li...]On Behalf Of Frankie =
Lam
    Sent: Thursday, October 24, 2002 7:48 PM
    To: ant...@re...
    Cc: ebx...@li...
    Subject: Re: [ebxmlms-develop] URL and File base document receipt

    Hi Anthony,

    The skeleton of the code in register() is like this:

    if (this is a file protocol && client url returning a path that is =
_not_ in
    trusted repository) {
        - get message listener repository from the properties file
        if (appcontext supplied has not been registered) {
            - use our directory to store messages
        }
        else {
            - use directory name of previously registered connection =
object
        }
        - use our default MessageListenerImpl with the directory name =
returned
    above
        - register using this MessageListenerImpl and application =
contexts
    supplied by user
    }
    else {
        // this is either a URL that is using file protocol and =
returning a
    trusted repository,
        // or http URL etc.
        - use this clientURL to do registration directly
    }

    Then in method deliverToApplication():

            final boolean isDelivered =3D ((clientUrl !=3D null && =
clientUrl.
                getProtocol().equals(MessageListener.PROTOCOL_FILE) &&
                trustedListenerRepository.contains(clientUrl.getPath()) =
=3D=3D
    false) ?
                false : true);
            if (stored) {
                ...
            }
            else if (!isDelivered) {
                =
messageServer.setDeliveryStatus(ebxmlMessage.getMessageId(),
    false);
            }

    That means

        isDelivered =3D (there is a client URL, based on the file =
protocol, and it
    is in trustedRepository).

    So we can divide it into three cases:
    1)  File URL + using trustedRepository
    2)  File URL + not using trustedRepository
    3)  URL based on other protocols

    For case (1), isDelivered =3D true. Thus the message is marked as =
"delivered"
    in the database and cannot be polled by the application through =
Request
    object. This means that the client actually needs to monitor =
consistently
    the trusted repository for any new messages.

    For case (2), isDelivered =3D false. The client can poll the MSH for =
new
    messages through the request object.

    For case (3), the application should not poll for new messages =
through the
    request object, since the messages are delivered directly to the =
specified
    URL.

    Note that the onMessage() method of the client application is called =
by
    Request object only, so onMessage() would not be invoked for case =
(1) and
    (3).

    --
    Frankie Lam
    Assistant Technology Officer
    Center for E-Commerce Infrastructure Development (CECID)
    Dept. of Computer Science and Information Systems
    The University of Hong Kong
    Tel: (852) 22415737
    Fax: (852) 25474611

    ----- Original Message -----
    From: <ant...@re...>
    To: <ebx...@li...>
    Sent: Thursday, October 24, 2002 4:36 PM
    Subject: RE: [ebxmlms-develop] URL and File base document receipt

    > Hi all,
    >
    > Just an update that may interest some,
    > I was still having trouble with this issue (of getting LoopBack to =
write
    to
    > the dir I wanted) and so jumped into the code a little - but I =
think I
    > resolved it - either that or I have messed things up terribly.
    >
    > If getClientUrl() is set to return a file dir url in LoopBack.java
    > (rather than returning null) the submitted file should get written =
to the
    > directory supplied (according to the doco) but I still wasn't =
getting the
    > file written to the dir I wanted it to (even after setting the =
trusted
    > repository property).
    >
    > The code in MessageServiceHandler.register( )
    > states...
    >         if =
(clientUrl.getProtocol().equals(MessageListener.PROTOCOL_FILE)
    &&
    >             =
trustedListenerRepository.contains(clientUrl.getPath()) =3D=3D
    > false)
    > {
    > blah blah blah
    > set up MessageListenerImpl with the clientUrl you have set
    > }
    >
    > Shouldn't the comparison be checking on 'true'
    >         if =
(clientUrl.getProtocol().equals(MessageListener.PROTOCOL_FILE)
    &&
    >             =
trustedListenerRepository.contains(clientUrl.getPath()) =3D=3D
    true)
    >
    > When I changed this to be =3D=3D true
    > I was able to get the file written to the directory that I =
specified.
    >
    > If this wasn't the case, the MessageListener would always call
    > LoopBack.onMessage() rather than calling the
    > MessageListenerImpl.onMessage() - which is the one that will write =
to the
    > file directory.
    > If you don't do this then you have to have the file writing code =
in your
    own
    > onMessage() method, which defeats the purpose of having the =
getClientUrl()
    >
    > If I am totally out of whack here let me know, just an =
observation.....
    >
    >
    > Ants
    >
    > PS. If what I have said is true - then there should be code in the
    > register() method to do the same thing for HTTP protocol as well =
as file
    > protocol as you can't submit to a HTTP port.
    >
    >
    >
    > -----Original Message-----
    > From: ebx...@li...
    > [mailto:ebx...@li...]On Behalf Of =
Gait
    > Boxman
    > Sent: Tuesday, October 22, 2002 6:29 PM
    > To: ant...@re...
    > Cc: ebx...@li...
    > Subject: Re: [ebxmlms-develop] URL and File base document receipt
    >
    >
    > Hi Anthony,
    >
    > the folder you specify needs to be listed as a trusted repository, =
which
    is
    > defined in the msh.properties.xml file at
    > MSH/MessageListener/TrustedRepository.
    > For starters, you could change the location to
    > file://C:/tmp/ebxmlms/trustedRepository1 to see if it's working =
ok. Be
    sure
    > to create the folder.
    >
    > Gait.
    > ----- Original Message -----
    > From: <ant...@re...>
    > To: <ebx...@li...>
    > Sent: Tuesday, October 22, 2002 8:16 AM
    > Subject: [ebxmlms-develop] URL and File base document receipt
    >
    >
    > > I'm having a bit of trouble understanding how the URL and file =
based doc
    > > receipt works.
    > >
    > > The documentation states that for MSH to post the received =
document to a
    > URL
    > > or file system, instead of using the onMessage function
    > > to provide a URL in the getClientUrl function.
    > >
    > > Using the LoopBack Class as an example, if I return a Url such =
as
    > > "file://C:/tmp" in the getClientUrl function, should the message =
that
    the
    > > loopback class has sent to itself be written to the directory =
that I
    > > specified. I have tried this and it seems that this is not the =
case. It
    > > still calls the onMessage function and there are no files =
written to the
    > > directory I specified.
    > >
    > > Any info is appreciated,
    > >
    > > Thanks
    > >
    > > Anthony Ellis
    > >
    > >
    > >
    > > -------------------------------------------------------
    > > This sf.net emial is sponsored by: Influence the future of
    > > Java(TM) technology. Join the Java Community Process(SM) =
(JCP(SM))
    > > program now. http://ad.doubleclick.net/clk;4699841;7576301;v?
    > > http://www.sun.com/javavote
    > > _______________________________________________
    > > ebxmlms-develop mailing list
    > > ebx...@li...
    > > https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
    >
    >
    >
    > -------------------------------------------------------
    > This sf.net emial is sponsored by: Influence the future of
    > Java(TM) technology. Join the Java Community Process(SM) (JCP(SM))
    > program now. http://ad.doubleclick.net/clk;4699841;7576301;v?
    > http://www.sun.com/javavote
    > _______________________________________________
    > ebxmlms-develop mailing list
    > ebx...@li...
    > https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
    >
    >
    >
    > -------------------------------------------------------
    > This sf.net email is sponsored by: Influence the future
    > of Java(TM) technology. Join the Java Community
    > Process(SM) (JCP(SM)) program now.
    >
    =
http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavo=
te
    > _______________________________________________
    > ebxmlms-develop mailing list
    > ebx...@li...
    > https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
    >