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

[<ant...@re...>]

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 =
            (MessageServiceHandlerConnection) mshConnectionTable.
            get(appContext);

        if (mshConnection == null) {
            final String errorMessage = "Unknown application context: "
                + appContext.toString() ;
            throw new
MessageServiceHandlerConnectionException(errorMessage);
        }
        final MessageListener messageListener = 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 = ((clientUrl != null && clientUrl.
              getProtocol().equals(MessageListener.PROTOCOL_FILE) &&
              trustedListenerRepository.contains(clientUrl.getPath()) ==
  false) ?
              false : true);
          if (stored) {
              ...
          }
          else if (!isDelivered) {
              messageServer.setDeliveryStatus(ebxmlMessage.getMessageId(),
  false);
          }

  That means

      isDelivered = (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 = 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 = 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()) ==
  > 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()) ==
  true)
  >
  > When I changed this to be == 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/javavote
  > _______________________________________________
  > ebxmlms-develop mailing list
  > ebx...@li...
  > https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
  >