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 =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
>