ebxmlms-develop — Development discussions

Re: [ebxmlms-develop] mailto problems

[Ng C. Y. [Cyng] <cy...@cs...>]

Hi,

> We changed the Content-Type from
>
> "multipart/related" to "multipart/mixed" and it solved the problem !
> Do you think that "multipart/mixed" is an acceptable  Content-Type
> value for EbXMLMessages ?

        "multipart/related" is specified in ebMS 2.0 specification
for ebXML message, though "multipart/mixed" is commonly used in
general MIME multipart mail message.

Regards,
CY

----------------------------------------------------------------------------
Ng Chi Yuen, CY.       cy...@ce...       http://www.cecid.hku.hk/
Technology Officer,
Centre for E-Commerce Infrastructure Development,
The University of Hong Kong
----------------------------------------------------------------------------

Re: [ebxmlms-develop] mailto problems

[Jean-Baptiste G. <jbg...@re...>]

We changed the Content-Type from

"multipart/related" to "multipart/mixed" and it solved the problem !
Do you think that "multipart/mixed" is an acceptable  Content-Type value for EbXMLMessages ?
Jean-Baptiste Gadenne


Jean-Baptiste Gadenne wrote:

> We are facing the same problem : we see only the first attachment in 
> Mozilla. Pine is doing better, but we
> are wondering why the mail messages beeing sent via Hermes have a 
> strange behaviour in Mozilla and OutLook Mail.
> Do you have further informations regarding this problem ?
>
> Jean-Baptiste Gadenne
>
>
> Patrick Yee wrote:
>
>> Will this be related to mail server? In our experience, different 
>> mail servers do have different behaviours... :-(
>>
>> When testing internally, we can see 2 parts (one for SOAP and the 
>> other for attachment) using common mail clients.
>>
>> Regards, -Patrick
>>
>>
>> Mayne, Peter wrote:
>>
>>> > The other problem is that the attachment is not attached in the 
>>> email. Yesterday I blamed ebmail for this,
>>> > but it appears to be something in Hermes. I'll investigate further.
>>>
>>> Curiouser and curiouser.
>>>
>>> The mail seems to be sent correctly, but both Mozilla Mail and 
>>> Outlook only see the first attachment (the SOAP envelope), which is 
>>> what led me astray. Neither of them see the second attachment (the 
>>> payload).
>>>
>>> PJDM
>>> -- 
>>> Peter Mayne
>>> Technology Consultant
>>> Spherion Technology Solutions
>>> Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
>>> T: 61 2 62689727 F: 61 2 62689777
>>>
>>> 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, 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 under the Privacy Act 1988 (Cth). Consent is 
>>> hereby given by the recipient(s) to collect, hold and use such 
>>> information and any personal information contained in a response to 
>>> this email, for any reasonable purpose in the ordinary course of 
>>> Spherion's business, including forwarding this email internally or 
>>> disclosing it to a third party. All personal information collected 
>>> by Spherion will be handled in accordance with Spherion's Privacy 
>>> Policy. If you have received this email in error, please notify the 
>>> sender and delete it.
>>>
>>> (c) you agree not to employ or arrange employment for any 
>>> candidate(s) supplied in this email and any attachments without 
>>> first entering into a contractual agreement with Spherion. You 
>>> further agree not to divulge any information contained in this 
>>> document to any person(s) or entities without the express permission 
>>> of Spherion.
>>>
>>>
>>>
>>>
>> ------------------------------------------------------- This SF.net 
>> email is sponsored by: Etnus, makers of TotalView, The best thread 
>> debugger on the planet. Designed with thread debugging features 
>> you've never dreamed of, try TotalView 6 free at www.etnus.com. 
>> _______________________________________________ ebxmlms-develop 
>> mailing list ebx...@li... 
>> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>>
>>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>

Re: [ebxmlms-develop] mailto problems

[Jean-Baptiste G. <jbg...@re...>]

We are facing the same problem : we see only the first attachment in 
Mozilla. Pine is doing better, but we
are wondering why the mail messages beeing sent via Hermes have a 
strange behaviour in Mozilla and OutLook Mail.
Do you have further informations regarding this problem ?

Jean-Baptiste Gadenne


Patrick Yee wrote:

>Will this be related to mail server? In our experience, different mail servers 
>do have different behaviours... :-(
>
>When testing internally, we can see 2 parts (one for SOAP and the other for 
>attachment) using common mail clients.
>
>Regards, -Patrick
>
>
>Mayne, Peter wrote:
>
>> > The other problem is that the attachment is not attached in the email. 
>> Yesterday I blamed ebmail for this,
>> > but it appears to be something in Hermes. I'll investigate further.
>>
>> Curiouser and curiouser.
>>
>> The mail seems to be sent correctly, but both Mozilla Mail and Outlook only 
>> see the first attachment (the SOAP envelope), which is what led me astray. 
>> Neither of them see the second attachment (the payload).
>>
>> PJDM
>> -- 
>> Peter Mayne
>> Technology Consultant
>> Spherion Technology Solutions
>> Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
>> T: 61 2 62689727  F: 61 2 62689777
>>
>>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, 
>>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 
>>under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
>>collect, hold and use such information and any personal information contained in a 
>>response to this email, for any reasonable purpose in the ordinary course of 
>>Spherion's 
>>business, including forwarding this email internally or disclosing it to a third party. All 
>>personal information collected by Spherion will be handled in accordance with 
>>Spherion's Privacy Policy. If you have received this email in error, please notify the 
>>sender and delete it.
>>
>>(c) you agree not to employ or arrange employment for any candidate(s) supplied in 
>>this email and any attachments without first entering into a contractual agreement with 
>>Spherion. You further agree not to divulge any information contained in this document 
>>to any person(s) or entities without the express permission of Spherion.
>>
>>
>>  
>>
>------------------------------------------------------- This SF.net email is 
>sponsored by: Etnus, makers of TotalView, The best thread debugger on the 
>planet. Designed with thread debugging features you've never dreamed of, try 
>TotalView 6 free at www.etnus.com. 
>_______________________________________________ ebxmlms-develop mailing list 
>ebx...@li... 
>https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>  
>

Re: [ebxmlms-develop] CertResolver questions

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><font face="Arial" size="2"><span class="402203306-06062003">(I
presume you meant "public key", not "private key".)</span></font></div>
  <div><font face="Arial" size="2"><span class="402203306-06062003"></span></font></div>
</blockquote>
<br>
Oops.. you are right. :-)<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <div>&nbsp;<font face="Arial" size="2"><span class="402203306-06062003">How
would client A trigger the CertResolver to use client A's key? If the
message appears to come from client B, the resolver should return
client B's key, and therefore the message won't verify. If the
resolver returned A's key for a message that appeared to come from B,
it would be a very bad resolver.</span></font></div>
</blockquote>
It depends on which part in the EbxmlMessage is used. It is dangerous
to use ToPartyID alone.<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><font face="Arial" size="2"><span class="402203306-06062003">An
SSL client certificate would not always be sufficient for resolving
the message sender. Imagine a university that has multiple departments
which sign their own messages with their own keys, but all of the
messages are sent to a supplier through a single university-wide
message handler using its own client certificate. </span></font></div>
</blockquote>
Agree.<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><font face="Arial" size="2"><span class="402203306-06062003">In
fact, it wouldn't really make sense to use a client certificate anyway:
if the message is signed, then the sender's public key should be
freely available, and therefore cached locally anyway.</span></font></div>
</blockquote>
I am not sure about your meaning. At least, I think using DSig and
SSL-Client Cert are independent issues.<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><font face="Arial" size="2"><span class="402203306-06062003"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="402203306-06062003">Using
remote addresses is definitely not a good idea.</span></font></div>
  <div><font face="Arial" size="2"><span class="402203306-06062003"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="402203306-06062003">I'm
not sure about the current ordering of the resolving ("first use the
resolver, then look in the message"). I had it as "look in&nbsp;the
message: if it isn't there then use the resolver". How come you did it
that way?</span></font></div>
</blockquote>
Need to check code. It seems to me that it is hard to find a perfect
key for resolving cert...<br>
<br>
-Patrick
</body>
</html>

Re: [ebxmlms-develop] configureLogger() bug

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Yes, my fault. It was fixed. -Patrick<br>
<br>
Mayne, Peter wrote:<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator"
 content="MS Exchange Server version 5.5.2654.45">
  <title>configureLogger() bug</title>
  <p><font size="2">If an ExternalProperties file is defined in
msh.properties.xml, then the first if(...) will be true,
loggingConfigured will be set to false; and the method will return.</font></p>
  <p><font size="2">The second time configureLogger() is called,
!loggingConfigured in the first if(...) will be false, so the
ExternalProperties if(..) will be false, and configureLogging will go
ahead and call setLogger when it shouldn't, which confuses log4j. (I
got a swag of "Attempted to append to closed appender named
chainsawClient" errors.)</font></p>
  <p><font size="2">The fix is to remove the "&amp;&amp;
!loggingConfigured" check from the first if(...), and insert</font> </p>
  <p><font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if(loggingConfigured)</font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {</font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return;</font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }</font> </p>
  <p><font size="2">at the beginning of the method. Ditto for
configureClientLogger().</font> </p>
  <p><font size="2">PJDM</font> <br>
  <font size="2">-- </font> <br>
  <font size="2">Peter Mayne</font> <br>
  <font size="2">Technology Consultant</font> <br>
  <font size="2">Spherion Technology Solutions</font> <br>
  <font size="2">Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602</font> <br>
  <font size="2">T: 61 2 62689727&nbsp; F: 61 2 62689777</font> </p>
  <font size="3" color="BLUE">
  <pre>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, 
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 
under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
collect, hold and use such information and any personal information contained in a 
response to this email, for any reasonable purpose in the ordinary course of 
Spherion's 
business, including forwarding this email internally or disclosing it to a third party. All 
personal information collected by Spherion will be handled in accordance with 
Spherion's Privacy Policy. If you have received this email in error, please notify the 
sender and delete it.

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


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

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

[ebxmlms-develop] configureLogger() bug

[Mayne, P. <Pet...@ap...>]

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

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

RE: [ebxmlms-develop] CertResolver questions

[Mayne, P. <Pet...@ap...>]

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

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

Re: [ebxmlms-develop] CertResolver questions

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Because we are not sure about the type of that parameter now. :-)<br>
<br>
Use of EbxmlMessage seems to be straightforward, but not secure enough.
What if both Client A and Client B are valid clients to Hermes, and bad
Client A wants to pretend to be Client B. He can generate a message
from Client B in the surface but triggers the CertResolver to use
Client A's private key to verify. Then Hermes will "think" that the
message is from Client B.<br>
<br>
So, if we have Remote object, which contains for example the remote
address, SSL client cert information, etc., it will be a better
candidate for resolving the certificate. Since we don't have that
object yet, we pass Object as key for compatibility.<br>
<br>
Regards, -Patrick<br>
<br>
<br>
Mayne, Peter wrote:<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator"
 content="MS Exchange Server version 5.5.2654.45">
  <title>CertResolver questions</title>
  <p><font size="2">Why does CertResolver.resolve() take an Object
parameter rather than an EbxmlMessage?</font> </p>
  <p><font size="2">PJDM</font> <br>
  <font size="2">-- </font> <br>
  <font size="2">Peter Mayne</font> <br>
  <font size="2">Technology Consultant</font> <br>
  <font size="2">Spherion Technology Solutions</font> <br>
  <font size="2">Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602</font> <br>
  <font size="2">T: 61 2 62689727&nbsp; F: 61 2 62689777</font> </p>
  <font size="3" color="BLUE">
  <pre>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, 
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 
under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
collect, hold and use such information and any personal information contained in a 
response to this email, for any reasonable purpose in the ordinary course of 
Spherion's 
business, including forwarding this email internally or disclosing it to a third party. All 
personal information collected by Spherion will be handled in accordance with 
Spherion's Privacy Policy. If you have received this email in error, please notify the 
sender and delete it.

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


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

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

[ebxmlms-develop] CertResolver questions

[Mayne, P. <Pet...@ap...>]

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

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

Re: [ebxmlms-develop] JMS receiver

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><span class="644313705-05062003"><font face="Arial" size="2">What
are the technical and security reasons for not allowing this?
Technically, if I write a MessageListener that goes berserk, it's my
fault, like any other plugin. Security-wise, if I have authentication
turned on, I have to know the username/password before I can register
my server-side MessageListener, so that's not a problem either.</font></span></div>
  <div><span class="644313705-05062003"></span></div>
</blockquote>
<br>
The technical reason hold when using Hermes in ASP mode. Consider
Hermes set up and allowing the client to connect, the implementation of
MessageListener is submitted by the client, and thus the Hermes server
does not have any idea about the class definition of the
implementation. After object serialization of the implementation,
Hermes server even cannot reconstruct the MessageListener
implementation.<br>
<br>
I agree that authentication is solving the security problem. But, to
run code from remote is always sensitive. The current authentication
mechanism is the least secure way.<br>
<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><span class="644313705-05062003"><font face="Arial" size="2">I
just want to bypass&nbsp;all of the&nbsp;built-in MessageListener&nbsp;stuff (which I
find&nbsp;rather confusing), and simply use my own server-side
MessageListener.onMessage()&nbsp;which Hermes calls for all messages to be
delivered to clients. Although you say that "<font face="Times New Roman"
 size="3">any MessageListener implementation sumbitted to Request will
be "interpreted" as either MessageListenerImpl or
ClientMessageListenerImpl in Hermes server</font>",&nbsp;my server-side
MessageListener&nbsp;is clearly neither of those. Hermes is presumably not
being strict enough in figuring out what kind of MessageListener it is
dealing with, which is why I'm suggesting removing getClientUrl() from
MessageListener and adding a UrlMessageListener (maybe a better name
would be ClientMessageListener)&nbsp;interface with getClientUrl(). This
will make the division between the different kinds of MessageListeners
clearer, and force Hermes to do the right thing: if it's not a
ClientMessageListener, just call its onMessage(), else do all the stuff
you describe.</font></span></div>
  <div><span class="644313705-05062003"></span>&nbsp;</div>
  <div><span class="644313705-05062003"><font face="Arial" size="2">I'd
also like to be able to create a Request without specifying a
MessageListener at all, and letting my server-side MessageListener
accept all the responses, but I can't remember if you've fixed that
one already.</font></span></div>
  <div><span class="644313705-05062003"></span></div>
</blockquote>
This is possible. But still, we have to consider the effect to ASP mode
(our common use-case). Maybe again, a hook should be used to deal with
any customized MessageListener first. But the hook should be
per-AppContext. Any idea?<br>
<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <div>&nbsp;</div>
  <div><span class="644313705-05062003"><font face="Arial" size="2">I
suspect my version of Hermes may have diverged slightly over the last
few weeks. </font></span><span class="644313705-05062003"><font
 face="Arial" size="2">As soon as you give me CVS access, I'll
download the latest version and try my MessageListener again. (The
nightly build seems to have disappeared from the download page.)</font></span></div>
  <div>&nbsp;</div>
</blockquote>
Our mistake. Will add that back soon.<br>
<br>
Regards, -Patrick<br>
</body>
</html>

Re: [ebxmlms-develop] mailto problems

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><span class="926525904-05062003"><font face="Arial" size="2">I
agree that the address should be configurable by the client (in this
case ebmail),&nbsp;possibly with a default from msh.properties.xml, but I
don't think that the fromPartyId should be used to attempt to build an
InternetAddress. PartyIds are multi-part (type attribute + string
value) logical names that represent the sender of the ebXML message,
whereas the SMTP from address is a string defined by an RFC that
specifies the sender of the email. These aren't necessarily the same
thing.</font></span></div>
  <div><span class="926525904-05062003"></span></div>
</blockquote>
<br>
Ideally, this should pass through ToMshUrlResolver also. But we have to
take care of ebMail usage. I guess we have to change the signature of
Mail.send() to add the outgoing email address. Let me discuss with my
colleague internally to determine any bad effect to do this.<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><span class="926525904-05062003"><font face="Arial" size="2">As
it stands at the moment, I cannot send ebXML messages via mail from
the&nbsp;PartyId <a class="moz-txt-link-rfc2396E" href="urn:MyBusiness">"urn:MyBusiness"</a>, because Mail.send() is hardcoded to
create an InternetAddress from <a class="moz-txt-link-rfc2396E" href="urn:MyBusiness">"urn:MyBusiness"</a>, which just doesn't
work.</font></span></div>
  <div><span class="926525904-05062003"></span>&nbsp;</div>
  <div><span class="926525904-05062003"><font face="Arial" size="2">I
keep re-reading your first paragraph and I haven't got it yet. Can you
explain a bit more please?</font></span></div>
</blockquote>
I just mean ebMail is required to set the sender address per message
send (and not by default value), because the other side (e.g. another
ebMail) will use that sender address for reply purpose.<br>
<br>
Regards, -Patrick<br>
</body>
</html>

Re: [ebxmlms-develop] mailto problems

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
ebMail is using this function. One requirement is that we should let
ebMail configure this address, as ebMail is using that "sender" address
for reply purpose. Therefore, ebMail would "receive" from that address
for getting replies.<br>
<br>
Therefore, I think we cannot mandate that properties in
msh.properties.xml as the sender address. Instead, I suggest we should
keep the current approach to use from party id by default. If the from
party id does not look valid as an email address, we will use the
default value in that property. Comment?<br>
<br>
Regards, -Patrick<br>
<br>
<br>
Mayne, Peter wrote:<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator"
 content="MS Exchange Server version 5.5.2654.45">
  <title>mailto problems</title>
  <p><font size="2">I've just tried registering a mailto: receiver to
accept incoming messages and run across a couple of problems.</font> </p>
  <p><font size="2">In Mail.send(), the from address of the mail
message is set using</font> </p>
  <p><font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mimeMessage.setFrom(new
InternetAddress(fromPartyId));</font> </p>
  <p><font size="2">This assumes that the frompartyId is a valid
RFC2822 (or whatever InternetAddress accepts) address. However, this is
not necessarily so, which is why we now have UrlFinder, for instance.</font></p>
  <p><font size="2">Suppose our business partner (PartyId (ABN)123)
exchanges messages with us(PartyId (ABN)456) over HTTP. We have a URL
mapping so that when we send an ebXML message to (ABN)123, Hermes can
map this to a physical address of&nbsp; <a
 href="http://our.business.partner/msh" target="_blank">http://our.business.partner/msh</a>.
(The physical from address is irrelevant, since HTTP has no such
concept.)</font></p>
  <p><font size="2">Now, suppose a message arrives over HTTP from
(ABN)123, and we have a mailto receiver registered for Hermes to pass
it to. The SMTP From address obviously can't be "(ABN)123", nor
obviously can it be "<a href="http://our.business.partner/msh"
 target="_blank">http://our.business.partner/msh</a>". We could have
yet another mapping, but that gets confusing.</font></p>
  <p><font size="2">Not having searched the specs yet (so I'm open to
contradiction), I would say that the only sensible thing to do here is
to use a fixed From address for all SMTP messages sent by Hermes, both
to other MSHs and receivers. After all, the SMTP From address is
irrelevant to the MSH, since it looks in the ebXML message to find out
who the sender is.</font></p>
  <p><font size="2">The above line should therefore be something like</font> </p>
  <p><font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mimeMessage.setFrom(new
InternetAddress(PROPERTY_SMTP_SENDER));</font> </p>
  <p><font size="2">where PROPERTY_SMTP_SENDER is obtained from
msh.properties.xml.</font> </p>
  <p><font size="2">Comments?</font> </p>
  <p><font size="2">The other problem is that the attachment is not
attached in the email. Yesterday I blamed ebmail for this, but it
appears to be something in Hermes. I'll investigate further.</font></p>
  <p><font size="2">PJDM</font> <br>
  <font size="2">-- </font> <br>
  <font size="2">Peter Mayne</font> <br>
  <font size="2">Technology Consultant</font> <br>
  <font size="2">Spherion Technology Solutions</font> <br>
  <font size="2">Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602</font> <br>
  <font size="2">T: 61 2 62689727&nbsp; F: 61 2 62689777</font> </p>
  <font size="3" color="BLUE">
  <pre>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, 
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 
under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
collect, hold and use such information and any personal information contained in a 
response to this email, for any reasonable purpose in the ordinary course of 
Spherion's 
business, including forwarding this email internally or disclosing it to a third party. All 
personal information collected by Spherion will be handled in accordance with 
Spherion's Privacy Policy. If you have received this email in error, please notify the 
sender and delete it.

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


  </pre>
  </font> </blockquote>
</body>
</html>

Re: [ebxmlms-develop] mailto problems

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Will this be related to mail server? In our experience, different mail
servers do have different behaviours... :-(<br>
<br>
When testing internally, we can see 2 parts (one for SOAP and the other
for attachment) using common mail clients.<br>
<br>
Regards, -Patrick<br>
<br>
<br>
Mayne, Peter wrote:<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator"
 content="MS Exchange Server version 5.5.2654.45">
  <title>RE: [ebxmlms-develop] mailto problems</title>
  <p><font size="2">&gt; The other problem is that the attachment is
not attached in the email. Yesterday I blamed ebmail for this,</font> <br>
  <font size="2">&gt; but it appears to be something in Hermes. I'll
investigate further.</font> </p>
  <p><font size="2">Curiouser and curiouser.</font> </p>
  <p><font size="2">The mail seems to be sent correctly, but both
Mozilla Mail and Outlook only see the first attachment (the SOAP
envelope), which is what led me astray. Neither of them see the second
attachment (the payload).</font></p>
  <p><font size="2">PJDM</font> <br>
  <font size="2">--</font> <br>
  <font size="2">Peter Mayne</font> <br>
  <font size="2">Technology Consultant</font> <br>
  <font size="2">Spherion Technology Solutions</font> <br>
  <font size="2">Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602</font> <br>
  <font size="2">T: 61 2 62689727&nbsp; F: 61 2 62689777</font> </p>
  <font size="3" color="BLUE">
  <pre>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, 
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 
under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
collect, hold and use such information and any personal information contained in a 
response to this email, for any reasonable purpose in the ordinary course of 
Spherion's 
business, including forwarding this email internally or disclosing it to a third party. All 
personal information collected by Spherion will be handled in accordance with 
Spherion's Privacy Policy. If you have received this email in error, please notify the 
sender and delete it.

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


  </pre>
  </font> </blockquote>
</body>
</html>

Re: [ebxmlms-develop] JMS receiver

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Peter,<br>
<br>
Are you writing your MessageListener implementation and passing it to
Request? I presume you are implementing the interface MessageListener.
In our design, any MessageListener implementation sumbitted to Request
will be "interpreted" as either MessageListenerImpl or
ClientMessageListenerImpl in Hermes server. The former one is for
storing received messages in the repository/file system in the Hermes
server side. The client will be accessing that file system directly for
incoming messages. The latter one implies polling from Hermes client
side to Hermes server. Once a message is polled, the implementation
will either store it in the file system in client side or calling the
onMessage() method to deliver the message.<br>
<br>
In other words, we don't currently allow the implementation passing to
Request to be executed in Hermes server. This is due to both technical
and security concerns. Therefore, in your case, you may write your own
MessageListener implementation which pass null as client URL. The
Hermes server will interpret this as "poll needed", and start a poller
automatically. Then, once a message is polled, your onMessage() will be
called and you can do your logic for delivery of message.<br>
<br>
Any comment?<br>
<br>
Regards, -Patrick<br>
<br>
<br>
Mayne, Peter wrote:<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator"
 content="MS Exchange Server version 5.5.2654.45">
  <title>RE: [ebxmlms-develop] JMS receiver</title>
  <p><font size="2">I've written an MessageListener (not based on
MessageListenerImpl) that doesn't use a URL, so I just returned null
from getClientUrl(). However, Hermes assumes that if getClientUrl()
returns null, there's nothing to do, so my MessageListener doesn't get
called. Therefore it has to return a random URL (such as <a
 href="http://1.1.1.1/" target="_blank">http://1.1.1.1/</a>) just to
get the messages. This seems very untidy to me.</font></p>
  <p><font size="2">Here's an alternative suggestion for
MessageListener. Define the following:</font> </p>
  <p><font size="2">public interface MessageListener extends
Serializable</font> <br>
  <font size="2">{</font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp; void onMessage(EbxmlMessage ebxmlMessage);</font> <br>
  <font size="2">}</font> </p>
  <p><font size="2">public interface UrlMessageListener extends
MessageListener</font> <br>
  <font size="2">{</font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp; public static final String PROTOCOL_xxxx = "xxxx";</font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp; ...</font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp; URL getClientUrl();</font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp; void onMessage(EbxmlMessage ebxmlMessage);</font> <br>
  <font size="2">}</font> </p>
  <p><font size="2">public class MessageListenerImpl implements
UrlMessageListener</font> <br>
  <font size="2">{</font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp; ...</font> <br>
  <font size="2">}</font> </p>
  <p><font size="2">Remove "URL getClientUrl()" from the
MessageListener interface. Within Hermes, check to see if the
MessageListener that is being dealt with is an instanceof
UrlMessageListener. (This already happens in MessageServiceHandler,
which checks for MessageListenerImpl.) If so, cast the MessageListener
to UrlMessageListener and continue as present, calling getClientUrl()
as required. If not, just call the MessageListener.</font></p>
  <p><font size="2">This seems neater than forcing MessageListener to
use a URL/URI, because a MessageListener doesn't necessarily have one.</font></p>
  <p><font size="2">PJDM</font> <br>
  <font size="2">--</font> <br>
  <font size="2">Peter Mayne</font> <br>
  <font size="2">Technology Consultant</font> <br>
  <font size="2">Spherion Technology Solutions</font> <br>
  <font size="2">Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602</font> <br>
  <font size="2">T: 61 2 62689727&nbsp; F: 61 2 62689777 </font> <br>
  <font size="2">-----Original Message-----</font> <br>
  <font size="2">From: Mayne, Peter </font> <br>
  <font size="2">Sent: Thursday, 22 May 2003 4:10 PM</font> <br>
  <font size="2">To: '<a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a>'</font> <br>
  <font size="2">Subject: RE: [ebxmlms-develop] JMS receiver</font> </p>
  <br>
  <p><font size="2">My tentative suggestion for MessageListener is that
it use a URI rather than a URL. The MessageListener class *identifies*
a message listener, but it is up to implementations of the
MessageListener to *locate* a message listener.</font></p>
  <p><font size="2">Therefore, MessageListener's getURL() becomes
getURI(). </font> <br>
  <font size="2">A URI is easily converted to a URL (with toURL()), so
users of MessageListener that want to interpret the URI as a URL can do
so. In some cases, the only interesting part of the URL seems to be the
protocol, so URI.getScheme() could be used directly without having to
convert to a URL first.</font></p>
  <p><font size="2">It could be possible to implement a MessageListener
that uses a scheme other than http and file, but there's at least one
place in the code that goes something like:</font></p>
  <p><font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if(clientUrl==null) </font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { .... </font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } </font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else if(protocol.equals(FILE)) </font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { .... </font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } </font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else </font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { .... </font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } </font> <br>
  <font size="2">which means that a non-http MessageListener would have
to use a dummy http URL (like "<a href="http://1.1.1.1/" target="_blank">http://1.1.1.1/</a>"
for instance) just to get Hermes to do the right thing, and more than
one dummy http URL to indicate different delivery instances. This seems
rather illogical to me: using an http URL to indicate a JMS queue just
isn't right. I'd much rather be able to create a MessageListener
instance with a URI such as <a class="moz-txt-link-rfc2396E" href="jms:...">"jms:..."</a> or <a class="moz-txt-link-rfc2396E" href="tcp:...">"tcp:..."</a> or whatever.</font></p>
  <p><font size="2">Given the addition of an initialisation hook into
Hermes, an alternative MessageListener (eg JmsMessageListener) could be
registered whenever Hermes starts.</font></p>
  <p><font size="2">The current MessageListenerImpl would be better
named asUrlMessageListener or somesuch. </font> <br>
  <font size="2">Comments? </font> <br>
  <font size="2">PJDM</font> </p>
  <font size="3" color="BLUE">
  <pre>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, 
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 
under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
collect, hold and use such information and any personal information contained in a 
response to this email, for any reasonable purpose in the ordinary course of 
Spherion's 
business, including forwarding this email internally or disclosing it to a third party. All 
personal information collected by Spherion will be handled in accordance with 
Spherion's Privacy Policy. If you have received this email in error, please notify the 
sender and delete it.

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


  </pre>
  </font> </blockquote>
</body>
</html>

Re: [ebxmlms-develop] Request musings (including nasty catch)

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
I see your point. By the way, are you (and anybody reading this
message) calling those methods in your system? Will changing the method
signatures breaks your code?<br>
<br>
Regards, -Patrick<br>
<br>
<br>
<br>
<br>
Mayne, Peter wrote:<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator"
 content="MS Exchange Server version 5.5.2654.45">
  <title>RE: [ebxmlms-develop] Request musings (including nasty catch)</title>
  <p><font size="2">&lt;quote&gt;</font> <br>
  <font size="2">getPendingMessages() is for admin purpose. It lets you
see how many messages are in the "outbox" and lets you make a correct
decision on whether you should stop Hermes or not. </font></p>
  <p><font size="2">getReceivedMessageIds() is for message receiving
purpose. That is, if you use NoMessageListenerImpl, there will be no
URL posting to you, nor onMessage() callback. You have to call that
function to find out how many messages are in the "inbox".</font></p>
  <p><font size="2">So as you see, they are in two different
categories. We don't see inconsistency here.</font> <br>
  <font size="2">&lt;quote&gt;</font> </p>
  <p><font size="2">The inconsistency I was referring to is in the
naming. getPendingMessages() should really be called
getPendingMessageIds().</font></p>
  <p><font size="2">Also, getPendingMessages() returns a String[], but
getMessageStatus() takes an ArrayList. No big deal, but slightly
awkward.</font></p>
  <p><font size="2">PJDM</font> <br>
  <font size="2">--</font> <br>
  <font size="2">Peter Mayne</font> <br>
  <font size="2">Technology Consultant</font> <br>
  <font size="2">Spherion Technology Solutions</font> <br>
  <font size="2">Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602</font> <br>
  <font size="2">T: 61 2 62689727&nbsp; F: 61 2 62689777</font> </p>
  <font size="3" color="BLUE">
  <pre>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, 
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 
under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
collect, hold and use such information and any personal information contained in a 
response to this email, for any reasonable purpose in the ordinary course of 
Spherion's 
business, including forwarding this email internally or disclosing it to a third party. All 
personal information collected by Spherion will be handled in accordance with 
Spherion's Privacy Policy. If you have received this email in error, please notify the 
sender and delete it.

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


  </pre>
  </font> </blockquote>
</body>
</html>

Re: [ebxmlms-develop] Digital signatures

[Gait B. <gai...@ti...>]

RE: [ebxmlms-develop] Digital signaturessorry, you're right, it occurred =
to me this morning as well before I got to e-mail again. What a short =
holiday can do :-)
  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Wednesday, May 28, 2003 8:13 AM
  Subject: RE: [ebxmlms-develop] Digital signatures


  An XML signature has a Reference containing a DigestValue for each =
message part (envelope + payloads), and a single SignatureValue.

  When I tried signing a document with and without an attachment, the =
DigestValue for the SOAP envelope remained unchanged.

  Are you sure we're referring to the same thing?=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
  -----Original Message-----=20
  From: Gait Boxman [mailto:gai...@ti...]=20
  Sent: Wednesday, 28 May 2003 4:03 PM=20
  To: ebx...@li...=20
  Subject: Re: [ebxmlms-develop] Digital signatures=20



  It is, the digest is based on the transformed envelope plus all the =
payloads, that's why you must do addDocument before computing the =
signature.

  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Wednesday, May 28, 2003 1:03 AM=20
  Subject: RE: [ebxmlms-develop] Digital signatures=20



  I know, but the DigestValue for the SOAP envelope isn't affected by =
the presence of payloads (is it?). If I can't get my SOAP envelope's =
DigestValue to match the one that Hermes produces for the same envelope, =
then there's not much point worrying about the final signature value =
yet.

  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
  -----Original Message-----=20
  From: Gait Boxman [mailto:gai...@ti...]=20
  Sent: Tuesday, 27 May 2003 5:43 PM=20
  To: ebx...@li...=20
  Subject: Re: [ebxmlms-develop] Digital signatures=20



  Hi Peter,=20
  you'll need to add the payloads as well, they get computed into the =
digest. Either send yourself a signed message w/o payloads, or add the =
payloads in the test routine with addDocument.

  --Gait.=20
  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Tuesday, May 27, 2003 8:34 AM=20
  Subject: RE: [ebxmlms-develop] Digital signatures=20



  I've written (borrowing heavily from one of the samples) the attached =
rather crude program that takes an ebXML envelope and signs it. For =
input, I'm trapping a signed message from Hermes, editing out the =
headers, mime boundaries, attachments, etc, removing the signature, and =
using the remaining envelope.

  I've compared it to ApacheXMLDSigner.sign() and they look similar as =
far as I can tell.=20
  Unfortunately, the DigestValue I get is not the same as the one that =
Hermes generates. (I'm not worried about attachments or signature values =
yet.) Would someone care to have a quick look and spot the differences?

  I'm not sure where XSLT comes in to it.=20
  Thanks.=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
   =20
  The information contained in this email and any attachments to it:=20
  (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=20
  (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.=20
  (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.=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.

Re: [ebxmlms-develop] Duplicate DuplicateElimination

[Ng C. Y. [Cyng] <cy...@cs...>]

Hi,

        Sorry. Fixed in the latest CVS.

Regards,
CY

----------------------------------------------------------------------------
Ng Chi Yuen, CY.       cy...@ce...       http://www.cecid.hku.hk/
Technology Officer,
Centre for E-Commerce Infrastructure Development,
The University of Hong Kong
----------------------------------------------------------------------------

Re: [ebxmlms-develop] Duplicate DuplicateElimination

[Ng C. Y. [Cyng] <cy...@cs...>]

Hi,

> Is there a specified order for setting header parameters? If I set them in
> the order below, "<eb:DuplicateElimination/>" appears twice in the resulting
> message.
>
>         header.setAction(action);
>         header.setCpaId(cpaID);
>         header.setConversationId(conversationID);
>         header.setService(service, "Order");
>         header.setDuplicateElimination();
>         header.setTimestamp(Utility.toUTCString(now.getTime()));

        This order should be ok. And sorry that I do not see two
<eb:DuplicateElimination/>. I simply new an EbxmlMessage() and set
the headers in your specified order.

Regards,
CY

----------------------------------------------------------------------------
Ng Chi Yuen, CY.       cy...@ce...       http://www.cecid.hku.hk/
Technology Officer,
Centre for E-Commerce Infrastructure Development,
The University of Hong Kong
----------------------------------------------------------------------------

Re: [ebxmlms-develop] Bug in ApacheXMLDSigner?

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

Thanks for pointing it out. We have fixed this bug as you suggested.
Regards, -Patrick


Joris Van den Bogaert wrote:

>In the method [ApacheXMLDSigner].verify() verifying the certificate chain:
>
>  CertPathVerifier.verify(certs, trusted);
>
>Shouldn't this be:
>
>  ret = CertPathVerifier.verify(certs, trusted);
>
>
>Cheers,
>Joris
>
>__________________________________
>Do you Yahoo!?
>Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
>http://calendar.yahoo.com
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: eBay
>Get office equipment for less on eBay!
>http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
>_______________________________________________
>ebxmlms-develop mailing list
>ebx...@li...
>https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>  
>

[ebxmlms-develop] Bug in ApacheXMLDSigner?

[Joris V. d. B. <jor...@ya...>]

In the method [ApacheXMLDSigner].verify() verifying the certificate chain:

  CertPathVerifier.verify(certs, trusted);

Shouldn't this be:

  ret = CertPathVerifier.verify(certs, trusted);


Cheers,
Joris

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

Re: [ebxmlms-develop] Digital signatures

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
But the SOAP Body of a message w/ attachment will have Manifest and
References point to the attachment. Those elements will be absent in a
message without attachment.<br>
<br>
Does this imply the DigestValue will be different?<br>
<br>
Regards, -Patrick<br>
<br>
<br>
<br>
Mayne, Peter wrote:<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator"
 content="MS Exchange Server version 5.5.2654.45">
  <title>RE: [ebxmlms-develop] Digital signatures</title>
  <p><font size="2">An XML signature has a Reference containing a
DigestValue for each message part (envelope + payloads), and a single
SignatureValue.</font></p>
  <p><font size="2">When I tried signing a document with and without an
attachment, the DigestValue for the SOAP envelope remained unchanged.</font></p>
  <p><font size="2">Are you sure we're referring to the same thing?</font> </p>
  <p><font size="2">PJDM</font> <br>
  <font size="2">--</font> <br>
  <font size="2">Peter Mayne</font> <br>
  <font size="2">Technology Consultant</font> <br>
  <font size="2">Spherion Technology Solutions</font> <br>
  <font size="2">Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602</font> <br>
  <font size="2">T: 61 2 62689727&nbsp; F: 61 2 62689777 </font> <br>
  <font size="2">-----Original Message-----</font> <br>
  <font size="2">From: Gait Boxman [<a href="mailto:gai...@ti...">mailto:gai...@ti...</a>]</font> <br>
  <font size="2">Sent: Wednesday, 28 May 2003 4:03 PM</font> <br>
  <font size="2">To: <a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a></font> <br>
  <font size="2">Subject: Re: [ebxmlms-develop] Digital signatures</font> </p>
  <br>
  <p><font size="2">It is, the digest is based on the transformed
envelope plus all the payloads, that's why you must do addDocument
before computing the signature.</font></p>
  <p><font size="2">----- Original Message ----- </font> <br>
  <font size="2">From: Mayne, Peter </font> <br>
  <font size="2">To: '<a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a>' </font> <br>
  <font size="2">Sent: Wednesday, May 28, 2003 1:03 AM</font> <br>
  <font size="2">Subject: RE: [ebxmlms-develop] Digital signatures</font> </p>
  <br>
  <p><font size="2">I know, but the DigestValue for the SOAP envelope
isn't affected by the presence of payloads (is it?). If I can't get my
SOAP envelope's DigestValue to match the one that Hermes produces for
the same envelope, then there's not much point worrying about the final
signature value yet.</font></p>
  <p><font size="2">PJDM </font> <br>
  <font size="2">-- </font> <br>
  <font size="2">Peter Mayne </font> <br>
  <font size="2">Technology Consultant </font> <br>
  <font size="2">Spherion Technology Solutions </font> <br>
  <font size="2">Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602 </font> <br>
  <font size="2">T: 61 2 62689727&nbsp; F: 61 2 62689777 </font> <br>
  <font size="2">-----Original Message----- </font> <br>
  <font size="2">From: Gait Boxman [<a href="mailto:gai...@ti...">mailto:gai...@ti...</a>]</font> <br>
  <font size="2">Sent: Tuesday, 27 May 2003 5:43 PM </font> <br>
  <font size="2">To: <a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a> </font> <br>
  <font size="2">Subject: Re: [ebxmlms-develop] Digital signatures </font> </p>
  <br>
  <p><font size="2">Hi Peter, </font> <br>
  <font size="2">you'll need to add the payloads as well, they get
computed into the digest. Either send yourself a signed message w/o
payloads, or add the payloads in the test routine with addDocument.</font></p>
  <p><font size="2">--Gait. </font> <br>
  <font size="2">----- Original Message ----- </font> <br>
  <font size="2">From: Mayne, Peter </font> <br>
  <font size="2">To: '<a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a>' </font> <br>
  <font size="2">Sent: Tuesday, May 27, 2003 8:34 AM </font> <br>
  <font size="2">Subject: RE: [ebxmlms-develop] Digital signatures </font> </p>
  <br>
  <p><font size="2">I've written (borrowing heavily from one of the
samples) the attached rather crude program that takes an ebXML envelope
and signs it. For input, I'm trapping a signed message from Hermes,
editing out the headers, mime boundaries, attachments, etc, removing
the signature, and using the remaining envelope.</font></p>
  <p><font size="2">I've compared it to ApacheXMLDSigner.sign() and
they look similar as far as I can tell. </font> <br>
  <font size="2">Unfortunately, the DigestValue I get is not the same
as the one that Hermes generates. (I'm not worried about attachments or
signature values yet.) Would someone care to have a quick look and spot
the differences?</font></p>
  <p><font size="2">I'm not sure where XSLT comes in to it. </font> <br>
  <font size="2">Thanks. </font> <br>
  <font size="2">PJDM </font> <br>
  <font size="2">-- </font> <br>
  <font size="2">Peter Mayne </font> <br>
  <font size="2">Technology Consultant </font> <br>
  <font size="2">Spherion Technology Solutions </font> <br>
  <font size="2">Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602 </font> <br>
  <font size="2">T: 61 2 62689727&nbsp; F: 61 2 62689777 </font> <br>
  <font size="2">&nbsp; </font> <br>
  <font size="2">The information contained in this email and any
attachments to it: </font> <br>
  <font size="2">(a) may be confidential and if you are not the
intended recipient, any interference with, </font> <br>
  <font size="2">use, disclosure or copying of this material is
unauthorised and prohibited; and </font> <br>
  <font size="2">(b) may contain personal information of the recipient
and/or the sender as defined </font> <br>
  <font size="2">under the Privacy Act 1988 (Cth). Consent is hereby
given by the recipient(s) to </font> <br>
  <font size="2">collect, hold and use such information and any
personal information contained in a </font> <br>
  <font size="2">response to this email, for any reasonable purpose in
the ordinary course of </font> <br>
  <font size="2">Spherion's </font> <br>
  <font size="2">business, including forwarding this email internally
or disclosing it to a third party. All </font> <br>
  <font size="2">personal information collected by Spherion will be
handled in accordance with </font> <br>
  <font size="2">Spherion's Privacy Policy. If you have received this
email in error, please notify the </font> <br>
  <font size="2">sender and delete it. </font> <br>
  <font size="2">(c) you agree not to employ or arrange employment for
any candidate(s) supplied in </font> <br>
  <font size="2">this email and any attachments without first entering
into a contractual agreement with </font> <br>
  <font size="2">Spherion. You further agree not to divulge any
information contained in this document </font> <br>
  <font size="2">to any person(s) or entities without the express
permission of Spherion. </font> </p>
  <font size="3" color="BLUE">
  <pre>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, 
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 
under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
collect, hold and use such information and any personal information contained in a 
response to this email, for any reasonable purpose in the ordinary course of 
Spherion's 
business, including forwarding this email internally or disclosing it to a third party. All 
personal information collected by Spherion will be handled in accordance with 
Spherion's Privacy Policy. If you have received this email in error, please notify the 
sender and delete it.

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


  </pre>
  </font> </blockquote>
</body>
</html>

Re: [ebxmlms-develop] Digital signatures

[Gait B. <gai...@ti...>]

RE: [ebxmlms-develop] Digital signaturesIt is, the digest is based on =
the transformed envelope plus all the payloads, that's why you must do =
addDocument before computing the signature.
  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Wednesday, May 28, 2003 1:03 AM
  Subject: RE: [ebxmlms-develop] Digital signatures


  I know, but the DigestValue for the SOAP envelope isn't affected by =
the presence of payloads (is it?). If I can't get my SOAP envelope's =
DigestValue to match the one that Hermes produces for the same envelope, =
then there's not much point worrying about the final signature value =
yet.

  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
  -----Original Message-----=20
  From: Gait Boxman [mailto:gai...@ti...]=20
  Sent: Tuesday, 27 May 2003 5:43 PM=20
  To: ebx...@li...=20
  Subject: Re: [ebxmlms-develop] Digital signatures=20



  Hi Peter,=20
  you'll need to add the payloads as well, they get computed into the =
digest. Either send yourself a signed message w/o payloads, or add the =
payloads in the test routine with addDocument.

  --Gait.=20
  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Tuesday, May 27, 2003 8:34 AM=20
  Subject: RE: [ebxmlms-develop] Digital signatures=20



  I've written (borrowing heavily from one of the samples) the attached =
rather crude program that takes an ebXML envelope and signs it. For =
input, I'm trapping a signed message from Hermes, editing out the =
headers, mime boundaries, attachments, etc, removing the signature, and =
using the remaining envelope.

  I've compared it to ApacheXMLDSigner.sign() and they look similar as =
far as I can tell.=20
  Unfortunately, the DigestValue I get is not the same as the one that =
Hermes generates. (I'm not worried about attachments or signature values =
yet.) Would someone care to have a quick look and spot the differences?

  I'm not sure where XSLT comes in to it.=20
  Thanks.=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
   =20
  The information contained in this email and any attachments to it:=20

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

  (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.=20

  (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.=20

RE: [ebxmlms-develop] RE: Version of Tomcat

[Jeff A. M. <Je...@VM...>]

Peter, Patrick,
 
Thank you both for your replies. I'd originally configured my server
with 4.1.24 le and was unable to loopback. 
I'd read in one of the early posts that 4.0.6 worked, so I switched, and
it worked.
 
I'll give 4.1.24 another try later today.
 
I do appreciate your time & help with my mundane question(s).
 
Best regards,
 
Jeff Manning

-----Original Message-----
From: ebx...@li...
[mailto:ebx...@li...] On Behalf Of Mayne,
Peter
Sent: Monday, May 26, 2003 4:23 PM
To: 'ebx...@li...'
Subject: RE: [ebxmlms-develop] RE: Version of Tomcat


I've been using 4.1.24 LE since it came out to successfully host Hermes.
Did you do the xalan.jar thing?
 
PJDM
--
Peter Mayne
Technology Consultant
Spherion Technology Solutions
Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
T: 61 2 62689727  F: 61 2 62689777 

-----Original Message-----
From: Jeff A. Manning [mailto:Je...@VM...] 
Sent: Tuesday, 27 May 2003 4:06 AM
To: ebx...@li...
Subject: RE: [ebxmlms-develop] RE: Version of Tomcat


Hi Patrick,
 
Thanks for your time to reply to my question.
 
I'm currently using qmail and am most interested in knowing the version
of Tomcat
you recommend for ebxmlms? 
 
I have been unable to use 4.1.24 but successful if I down grade to 4.0.6
Tomcat.
 
I'd appreciate your insights on the version you're currently using.
 
Thanks!
 
Jeff Manning

-----Original Message-----
From: ebx...@li...
[mailto:ebx...@li...] On Behalf Of
Patrick Yee
Sent: Monday, May 26, 2003 3:37 AM
To: ebx...@li...
Subject: Re: [ebxmlms-develop] RE: Version of Tomcat


In our testing environment, we use the IMAP package from Washington U. 
http://www.washington.edu/imap/

And we have confidence that Hermes can work with QMail also. That part
is pretty standard.

Regards, -Patrick


Jeff Manning wrote:


Hi CY,



Which email server are you using?



Jeff



-----Original Message-----

From: Ng Chi Yuen [Cyng] [mailto:cy...@cs...] 

Sent: Wednesday, May 21, 2003 8:30 AM

To: ebx...@li...

Cc: Jeff Manning

Subject: RE: Version of Tomcat





Hi Jeff,



  

I'm fairly new (48 hrs) with Postgres. I'm an Oracle person.



Since my last email I found the tables under supplier, have dropped 

them, and rerun the RunLoop script.



Now I'm fighting with qmail user logins and passwords. I'm trying to 

setup vmailmgr (what a pain) to have a simpler gui for dealing with 

qmail - though I am about to toss qmail for something simpler.

    



        Would you share with us how your project makes use of Hermes and

qmail? I know nothing about qmail at all



  

I'm cautiously optimistic that I'll have this running

shortly - due in large part to your help!



I appreciate your time to reply to my pitiful pleas!

    



        From now on, you can simply email to

ebx...@li... or

ebx...@li...

We have all friends around and we can share our experience and problems.



        Hope you will like Hermes.



  

Discovering this, I've restarted tomcat and initially found that 

postgres was not running. After restarting postgres I now receive 

(I've only included the 'root cause' portion of the trace):

        

        root cause

hk.hku.cecid.phoenix.message.handler.MessageServiceHandlerExceptio

n:

ERROR:  Relation 'mshconfig' already exists

        

        This is due to the fact that some tables have already exist 

in your DB with old table schema. Please drop all tables and restart

      



  

Tomcat and Hermes and the new tables will be created again.

      



Regards,

CY



------------------------------------------------------------------------

----

Ng Chi Yuen, CY.       cy...@ce...       http://www.cecid.hku.hk/

Technology Officer,

Centre for E-Commerce Infrastructure Development,

The University of Hong Kong

------------------------------------------------------------------------

----











-------------------------------------------------------

This SF.net email is sponsored by: ObjectStore.

If flattening out C++ or Java code to make your application fit in a

relational database is painful, don't do it! Check out ObjectStore.

Now part of Progress Software. http://www.objectstore.net/sourceforge

_______________________________________________

ebxmlms-develop mailing list

ebx...@li...

https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop

  

------------------------------------------------------- This SF.net
email is sponsored by: ObjectStore. If flattening out C++ or Java code
to make your application fit in a relational database is painful, don't
do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge
_______________________________________________ ebxmlms-develop mailing
list ebx...@li...
https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop 


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, 

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 

under the Privacy Act 1988 (Cth). Consent is hereby given by the
recipient(s) to 

collect, hold and use such information and any personal information
contained in a 

response to this email, for any reasonable purpose in the ordinary
course of 

Spherion's 

business, including forwarding this email internally or disclosing it to
a third party. All 

personal information collected by Spherion will be handled in accordance
with 

Spherion's Privacy Policy. If you have received this email in error,
please notify the 

sender and delete it.



(c) you agree not to employ or arrange employment for any candidate(s)
supplied in 

this email and any attachments without first entering into a contractual
agreement with 

Spherion. You further agree not to divulge any information contained in
this document 

to any person(s) or entities without the express permission of Spherion.

Re: [ebxmlms-develop] Digital signatures

[Gait B. <gai...@ti...>]

RE: [ebxmlms-develop] Digital signaturesHi Peter,=20
you'll need to add the payloads as well, they get computed into the =
digest. Either send yourself a signed message w/o payloads, or add the =
payloads in the test routine with addDocument.

--Gait.
  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Tuesday, May 27, 2003 8:34 AM
  Subject: RE: [ebxmlms-develop] Digital signatures


  I've written (borrowing heavily from one of the samples) the attached =
rather crude program that takes an ebXML envelope and signs it. For =
input, I'm trapping a signed message from Hermes, editing out the =
headers, mime boundaries, attachments, etc, removing the signature, and =
using the remaining envelope.

  I've compared it to ApacheXMLDSigner.sign() and they look similar as =
far as I can tell.=20

  Unfortunately, the DigestValue I get is not the same as the one that =
Hermes generates. (I'm not worried about attachments or signature values =
yet.) Would someone care to have a quick look and spot the differences?

  I'm not sure where XSLT comes in to it.=20

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

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

Re: [ebxmlms-develop] Request musings (including nasty catch)

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
<blockquote type="cite"
 cite="mid...@s-...">
  <p><font size="2">Request requires that I pass a toMSHUrl, even
though it is ovbiously not required. Passing null causes a
RequestException later. I'm not entirely sure that a message listener
and a transport type are required, either.</font></p>
</blockquote>
We fixed the issue when passing null as toMshUrl in the nightly build.
We assume to ToMshUrlResolver mechanism will be used. At the end, if it
fails to resolve the outgoing URL, an exception will be thrown.<br>
<br>
Message listener and transport type are still required at the moment.<br>
<br>
Regards, -Patrick<br>
</body>
</html>