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

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

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
>