ebxmlms-develop — Development discussions

Re: [ebxmlms-develop] Problem using axis with hermes

[Ronald v. K. <rv...@ab...>]

It seems that sun is not following the specs:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18050

SOAPHeader requires child elements to be of type SOAPHeaderElement.  If 
we do not change this, AXIS will never work (I think). 

Ng Chi Yuen [Cyng] probeerde het volgende duidelijk te maken op 03-04-03 
12:43:

> Hi,
>
> > I understand why AXIS throws an exception, but the way they check the
> > instance type isn't a bad thing to do.
>
Seems required even, see above

>         Yeah... it's not a bad thing. I just wonder we may somehow be 
> tempted
> to create a SOAPElement instance directly using one API method and add 
> it to
> SOAPHeader but get exception finally.
>
Seems a good idea. Using the SOAPEnvelope to create a SOSOAPElement, 
like is done done now, caused us some trouble in our application... we 
use an elementFactory now

>
> > I'm still figuring out why the Sun implementation throws an 
> exception when
> > a SOAPHeaderElement is passed to it (via a cast). Then it would be 
> possible
> > to have the ExtensionElement not only return a SOAPElement, but a
> > SOAPHeaderElement when the ExtensionElement is an instance of 
> MessageHeader.
>
>         This is also a good idea. Maybe, I should be more precise in
> ExtensionElementImpl, i.e., the construction of ExtensionElementImpl 
> should
> call addHeaderElement() and addBodyElement() instead of SOAPFactory.
> createElement().
>
Depending on the instance type you mean? Doesn't this require a rewrite 
of a large part of ExtensionElementImpl?
Any tips? then I'll be willing to look into this

> > If you have more information on your problems with axis, we can prevent
> > doing duplicate work. I'll draw up a list with our problems tonight
> > (CET+2).
>
>         Thanks a lot for your investigation. Please go on.
>
Other issues we ran into when moving van sun to axis:
- SOAPEnvelope.createName had some problems with namespaces (should look 
how we solved this)
- SOAPFactory.newInstance().createElement(....)   Now done with a 
elementFactory...(works in axis, not tested in sun)
- .....

Regards,

Ronald

RE: [ebxmlms-develop] Problem using axis with hermes

[Ronald v. K. <rv...@ab...>]

I don't mean to use the bug/tracker to give my requests priority, just as an
add-on to this mailing-list so things are written-down somewhere and a
centralised issue list is available. You could also choose to implement
bugzilla (quite easy to install) on your local host. Works like a charm.

> -----Oorspronkelijk bericht-----
> Van: Ng Chi Yuen [Cyng] [mailto:cy...@cs...]
> Verzonden: donderdag 3 april 2003 12:43
> Aan: 'ebx...@li...'
> Onderwerp: RE: [ebxmlms-develop] Problem using axis with hermes
> 
> 
> Hi,
> 
> > I understand why AXIS throws an exception, but the way they 
> check the
> > instance type isn't a bad thing to do.
> 
>         Yeah... it's not a bad thing. I just wonder we may 
> somehow be tempted
> to create a SOAPElement instance directly using one API 
> method and add it to
> SOAPHeader but get exception finally.
> 
> 
> > I'm still figuring out why the Sun implementation throws an 
> exception when
> > a SOAPHeaderElement is passed to it (via a cast). Then it 
> would be possible
> > to have the ExtensionElement not only return a SOAPElement, but a
> > SOAPHeaderElement when the ExtensionElement is an instance 
> of MessageHeader.
> 
>         This is also a good idea. Maybe, I should be more precise in
> ExtensionElementImpl, i.e., the construction of 
> ExtensionElementImpl should
> call addHeaderElement() and addBodyElement() instead of SOAPFactory.
> createElement().
> 
> > If you have more information on your problems with axis, we 
> can prevent
> > doing duplicate work. I'll draw up a list with our problems tonight
> > (CET+2).
> 
>         Thanks a lot for your investigation. Please go on.
> 
> 
> > The bug/tracker thing of SourceForge does not seem to be used.
> > Do you guys have another system for this, accessible by 
> external people?
> 
>         You may post to bug/tracker on SF and we will keep a look. But
> due to our limited resources, we may not be able to fulfill 
> all requests
> as promptly as possible. Please don't mind.
> 
> 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: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
ebxmlms-develop mailing list
ebx...@li...
https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop

RE: [ebxmlms-develop] Problem using axis with hermes

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

Hi,

> I understand why AXIS throws an exception, but the way they check the
> instance type isn't a bad thing to do.

        Yeah... it's not a bad thing. I just wonder we may somehow be tempted
to create a SOAPElement instance directly using one API method and add it to
SOAPHeader but get exception finally.


> I'm still figuring out why the Sun implementation throws an exception when
> a SOAPHeaderElement is passed to it (via a cast). Then it would be possible
> to have the ExtensionElement not only return a SOAPElement, but a
> SOAPHeaderElement when the ExtensionElement is an instance of MessageHeader.

        This is also a good idea. Maybe, I should be more precise in
ExtensionElementImpl, i.e., the construction of ExtensionElementImpl should
call addHeaderElement() and addBodyElement() instead of SOAPFactory.
createElement().

> If you have more information on your problems with axis, we can prevent
> doing duplicate work. I'll draw up a list with our problems tonight
> (CET+2).

        Thanks a lot for your investigation. Please go on.


> The bug/tracker thing of SourceForge does not seem to be used.
> Do you guys have another system for this, accessible by external people?

        You may post to bug/tracker on SF and we will keep a look. But
due to our limited resources, we may not be able to fulfill all requests
as promptly as possible. Please don't mind.

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] Client authentication remote user

[Ronald v. K. <rv...@ab...>]

In our current server (not hermes based, but like hermes uses jaxm) we've
changed the httpservlet servlet so it passes it on to other classes. It is
something we are going to need as well in Hermes, due to the fact that we
have to do some billing based on the value of the remote user, that cannot
only take place in the httpservlet.

 -----Oorspronkelijk bericht-----
Van: Mayne, Peter [mailto:Pet...@ap...]
Verzonden: donderdag 3 april 2003 5:02
Aan: 'ebx...@li...'
Onderwerp: [ebxmlms-develop] Client authentication remote user



If client authentication is used when connecting to Hermes using HTTP/HTTPS,
is it possible to pass the value of request.getRemoteUser() to the message
listener?

I can't think of a way to do it. 

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.

RE: [ebxmlms-develop] Problem using axis with hermes

[Ronald v. K. <rv...@ab...>]

I understand why AXIS throws an exception, but the way they check the
instance type isn't a bad thing to do. I'm still figuring out why the Sun
implementation throws an exception when a SOAPHeaderElement is passed to it
(via a cast). Then it would be possible to have the ExtensionElement not
only return a SOAPElement, but a SOAPHeaderElement when the ExtensionElement
is an instance of MessageHeader. 

I'll look into that further.

If you have more information on your problems with axis, we can prevent
doing duplicate work. I'll draw up a list with our problems tonight (CET+2).
The bug/tracker thing of SourceForge does not seem to be used. Do you guys
have another system for this, accessible by external people?

Ronald

> -----Oorspronkelijk bericht-----
> Van: Ng Chi Yuen [Cyng] [mailto:cy...@cs...]
> Verzonden: donderdag 3 april 2003 4:22
> Aan: freebxml
> Onderwerp: Re: [ebxmlms-develop] Problem using axis with hermes
> 
> 
> Hi,
> 
> > We've been looking into using apache-axis instead of the Sun
> > implementation of jaxm/saaj because it has more functionality (works
> > better with proxies, http keep-alive etc.) and is open-source.
> 
>         For your information, we have also been testing with 
> Apache Axis
> for sometimes. The goal is we can finally support Axis but we 
> still find a
> number of problems in it.
> 
> 
> > org.apache.axis.message.SOAPHeader:
> > --
> >     public SOAPElement* addChildElement*(SOAPElement element)
> >       throws SOAPException
> >     {
> >       if (!(element instanceof* 
> javax.xml.soap.SOAPHeaderElement*)) {
> >        * throw new 
> SOAPException*(Messages.getMessage("badSOAPHeader00"));
> >       }
> >       return super.addChildElement(element);
> >     }
> > --
> >
> > Since I'm not allowed to decompile the Sun implementation 
> ;-) I tried
> > casting extensionElement.getSOAPElement() to 
> SOAPHeaderElement, without
> > success. I get a classcast exception then in the default 
> hermes (without
> > axis).
> 
>         Ideally speaking, since both JAXM and Axis implement 
> javax.xml.soap.*,
> there is no need to change a line of codes in Hermes and 
> simply switching
> between the two libraries should work smoothly.
> 
>         Of course, the world is not so ideal. The 
> ClassCastException thrown
> by Axis is due to the fact that when a SOAPElement is added 
> to SOAPHeader,
> the SOAPHeader would regard this SOAPElement as 
> SOAPHeaderElement (which is
> subtype of SOAPElement) when an iterator of children is retrieved from
> SOAPHeader. We have reported this to Apache and see if this 
> problem will
> be fixed in the coming Axis release.
> 
> 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: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
ebxmlms-develop mailing list
ebx...@li...
https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop

Re: [ebxmlms-develop] nightly build

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

Messagehttp://www.freebxml.org/download.htm

after 0.9.2.0 section

Need reload? -Patrick

  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Thursday, April 03, 2003 12:22 PM
  Subject: RE: [ebxmlms-develop] nightly build


  Where? The downloads page only has 0.9.2.0 and 0.9.3.0.

  PJDM
  --
  Peter Mayne
  Technology Consultant
  Spherion Technology Solutions
  Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
  T: 61 2 62689727  F: 61 2 62689777=20
    -----Original Message-----
    From: Patrick Yee [mailto:kc...@ce...]=20
    Sent: Thursday, 3 April 2003 2:07 PM
    To: ebx...@so...
    Subject: [ebxmlms-develop] nightly build


    For those who cannot access CVS, you can download the latest source =
code of Hermes at http://www.freebxml.org. It will be updated daily.

    Regards, -Patrick

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] Signed message debugging

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

RE: [ebxmlms-develop] Signed message debuggingPeter,

It is strange, isn't it? How come it works without change in keystore =
and Hermes? I will try your keystore anyway.. will update you later.

-Patrick
  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Thursday, April 03, 2003 11:39 AM
  Subject: RE: [ebxmlms-develop] Signed message debugging


  Never mind.=20

  I was looking at the new Ant view in Eclipse 2.1 and discovered the =
gentestkey target. I generated the test keystore, tried that, and it =
worked. I put my keystore back, and it worked too.

  I was concentrating on the server side, and it turned out the =
msh.properties.xml that Loopback was using was similar to the server =
one, but not similar enough.

  Some extra debug logs would be good, though. :-)=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

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.

[ebxmlms-develop] nightly build

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

For those who cannot access CVS, you can download the latest source code =
of Hermes at http://www.freebxml.org. It will be updated daily.

Regards, -Patrick

Re: [ebxmlms-develop] Setup of ApplicationContexts

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

MessageYou can download the latest source at http://www.freebxml.org/.

How stable? It depends. Generally, we will test Hermes against quite a =
number of test cases before making a release. And the nightly build of =
course hasn't run through those test cases. On the other hand, you can =
obtain prompt bug fix in nightly build.

BTW, we want to setup a testbed to check the nightly build against test =
cases. But due to resource limitation, we are slow on that. :-(

Regards, -Patrick

  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Thursday, April 03, 2003 7:14 AM
  Subject: RE: [ebxmlms-develop] Setup of ApplicationContexts


  Sounds excellent. I'm looking forward to getting the nightly build. =
How stable is it in general?

  PJDM
  --
  Peter Mayne
  Technology Consultant
  Spherion Technology Solutions
  Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
  T: 61 2 62689727  F: 61 2 62689777=20
    -----Original Message-----
    From: Patrick Yee [mailto:kc...@ce...]=20
    Sent: Wednesday, 2 April 2003 8:24 PM
    To: ebx...@li...
    Subject: Re: [ebxmlms-develop] Setup of ApplicationContexts


    In that case, there will be only one error handler. This would be =
fine for your application. But in the case of multiple clients =
connecting to the same hermes server, we should make it more flexible. =
That's the argument for us to find the AppContext based on ref to =
message ID.

    How about we solve it this way:
    1. Set up a receiver with app context (*,*,*,*) and a normal message =
listener. This way, the request will poll hermes server from time to =
time for new messages and call onMessage() to deliver the message to =
application.
    2. Set up a sender with app context (*,*,*,*) and pass =
NoMessageListenerImpl as message listener. This is a newly created =
message listener implementation which is "compatible" with a normal =
message listener. But it will stop the request from polling hermes =
server. The good thing is that even you will "override" the receiver's =
registration by this action, the receiver can still poll the messages =
successfully. This is what we mean by "compatible". :-)

    What do you think about this? You can find NoMessageListenerImpl in =
the latest source. We will work on a nightly source tarball and put it =
onto our web site tomorrow.

    Regards, -Patrick
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] Problem using axis with hermes

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

Hi,

> We've been looking into using apache-axis instead of the Sun
> implementation of jaxm/saaj because it has more functionality (works
> better with proxies, http keep-alive etc.) and is open-source.

        For your information, we have also been testing with Apache Axis
for sometimes. The goal is we can finally support Axis but we still find a
number of problems in it.


> org.apache.axis.message.SOAPHeader:
> --
>     public SOAPElement* addChildElement*(SOAPElement element)
>       throws SOAPException
>     {
>       if (!(element instanceof* javax.xml.soap.SOAPHeaderElement*)) {
>        * throw new SOAPException*(Messages.getMessage("badSOAPHeader00"));
>       }
>       return super.addChildElement(element);
>     }
> --
>
> Since I'm not allowed to decompile the Sun implementation ;-) I tried
> casting extensionElement.getSOAPElement() to SOAPHeaderElement, without
> success. I get a classcast exception then in the default hermes (without
> axis).

        Ideally speaking, since both JAXM and Axis implement javax.xml.soap.*,
there is no need to change a line of codes in Hermes and simply switching
between the two libraries should work smoothly.

        Of course, the world is not so ideal. The ClassCastException thrown
by Axis is due to the fact that when a SOAPElement is added to SOAPHeader,
the SOAPHeader would regard this SOAPElement as SOAPHeaderElement (which is
subtype of SOAPElement) when an iterator of children is retrieved from
SOAPHeader. We have reported this to Apache and see if this problem will
be fixed in the coming Axis release.

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] Minor Eclipse warnings

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

Minor Eclipse warningsThanks Peter. We will install it later. -Patrick
  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Thursday, April 03, 2003 7:37 AM
  Subject: [ebxmlms-develop] Minor Eclipse warnings


  I installed Eclipse 2.1 last night. The compiler in this version is =
able to analyse source code a bit more thoroughly than the previous =
version.

  In particular, it shows a lot of warnings of the form "The import **** =
is never used".=20

  There are a few of "The assignment to variable **** has no effect". =
For instance, refToMessage shouldn't be assigned to here.

      public EbxmlValidationException(String errorCode, String severity, =

          String errorString, String location) {=20
          super(ERROR_EBXML, errorCode, errorString);=20
          this.severity =3D severity;=20
          this.refToMessage =3D refToMessage;=20
          this.location =3D location;=20
      }=20

  And a couple of other things as well.=20

  It would be nice to get these things dealt with so the tasks list =
isn't cluttered up. If you don't want to install Eclipse, I could email =
a list. Or you could just ignore them. :-)

  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

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.

[ebxmlms-develop] Problem using axis with hermes

[Ronald v. K. <rv...@ab...>]

Hi,

We've been looking into using apache-axis instead of the Sun 
implementation of jaxm/saaj because it has more functionality (works 
better with proxies, http keep-alive etc.) and is open-source. We've run 
into one to many bug with the Sun libraries, that if we run into a bug, 
we want to be able to fix it ourselves and give this back to the 
community, hence freebxml, apache-axis, boucycastle for encryption etc...

One of my collegues initially concentrated on the 
hk.hku.cecid.phoenix.message.packaging package andran into the following 
problem.

hk.hku.cecid.phoenix.message.packaging.HeaderContainer, in 
addExtensionElement(...):
-- 
        if (extensionElement instanceof HeaderElement) {
            final SOAPHeader soapHeader;
            soapHeader = soapEnvelope.getHeader();
           * 
soapHeader.addChildElement*(extensionElement.getSOAPElement());
--

The last call shown above adds a SOAPElement to the header, which throws 
an exeption in AXIS. The reason for this is in the code below. AXIS 
expects this SOAPElement to be of type SOAPHeaderElement, which it is not.

org.apache.axis.message.SOAPHeader:
-- 
    public SOAPElement* addChildElement*(SOAPElement element)
      throws SOAPException
    {
      if (!(element instanceof* javax.xml.soap.SOAPHeaderElement*)) {
       * throw new SOAPException*(Messages.getMessage("badSOAPHeader00"));
      }
      return super.addChildElement(element);
    }
--

Since I'm not allowed to decompile the Sun implementation ;-) I tried 
casting extensionElement.getSOAPElement() to SOAPHeaderElement, without 
success. I get a classcast exception then in the default hermes (without 
axis).

java.lang.ClassCastException: 
com.sun.xml.messaging.saaj.soap.dom4j.ElementImpl
    at 
hk.hku.cecid.phoenix.message.packaging.HeaderContainer.addExtensionElement(HeaderContainer.java:296)
    at 
hk.hku.cecid.phoenix.message.packaging.EbxmlMessage.addMessageHeader(EbxmlMessage.java:343)

Maybe axis will work then, but the default hermes does not :-(

Any suggestion by anyone to get around this?
I do know however that all hermes uses standard extensionElements which 
all are a SOAPElement.

Re: [ebxmlms-develop] Signed message debugging

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

RE: [ebxmlms-develop] Signed message debuggingPeter,

Sorry I am not too familiar with the keytool listing. Can you generate a =
keystore with disclosable details (e.g. password) and send it to me for =
testing? I need the keystore for signing (with public & private keys) =
and the certificate (public key) of your signing CA. Please email to =
kc...@ce.... Thank you.

Regards, -Patrick

  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Wednesday, April 02, 2003 8:19 AM
  Subject: RE: [ebxmlms-develop] Signed message debugging


  > Are you generating your own certificate?=20

  Yes.=20

  > Is the certificate self-signed?=20

  No.=20

  > Any certificate path is included in the certificate?=20

  Yes. keytool -list -v shows:=20

  <keytool>=20
  Alias name: pjdmca=20
  Creation date: 18/03/2003=20
  Entry type: trustedCertEntry=20

  Owner: CN=3DPJDM CA, OU=3DTechnology, O=3DSpherion Group Ltd, =
L=3DLyneham, ST=3DACT, C=3DAU=20
  Issuer: CN=3DPJDM CA, OU=3DTechnology, O=3DSpherion Group Ltd, =
L=3DLyneham, ST=3DACT, C=3DAU=20

  Serial number: 0=20
  Valid from: Tue Mar 04 21:36:25 EST 2003 until: Wed Mar 03 21:36:25 =
EST 2004=20
  Certificate fingerprints:=20
           MD5:  C3:55:8C:B5:DE:89:E8:48:3E:4C:BB:49:A3:84:E9:67=20
           SHA1: =
90:87:14:CE:0F:EE:A3:C6:6C:7E:95:3C:DE:F4:CB:FB:07:F5:0D:34=20



  *******************************************=20
  *******************************************=20



  Alias name: chmeeehermes=20
  Creation date: 18/03/2003=20
  Entry type: keyEntry=20
  Certificate chain length: 2=20
  Certificate[1]:=20
  Owner: CN=3Dchmeee Hermes, OU=3Db2b, O=3Debusiness, L=3DCanberra, =
ST=3DACT, C=3DAU=20
  Issuer: CN=3DPJDM CA, OU=3DTechnology, O=3DSpherion Group Ltd, =
L=3DLyneham, ST=3DACT, C=3DAU=20

  Serial number: 4=20
  Valid from: Tue Mar 18 22:56:13 EST 2003 until: Wed Mar 17 22:56:13 =
EST 2004=20
  Certificate fingerprints:=20
           MD5:  69:D9:46:50:B5:F0:FB:B6:85:34:F9:E6:D1:AF:92:3E=20
           SHA1: =
8E:2B:B6:9C:5D:DC:AC:C6:47:91:68:6D:18:9E:02:79:93:EF:41:C8=20
  Certificate[2]:=20
  Owner: CN=3DPJDM CA, OU=3DTechnology, O=3DSpherion Group Ltd, =
L=3DLyneham, ST=3DACT, C=3DAU=20
  Issuer: CN=3DPJDM CA, OU=3DTechnology, O=3DSpherion Group Ltd, =
L=3DLyneham, ST=3DACT, C=3DAU=20

  Serial number: 0=20
  Valid from: Tue Mar 04 21:36:25 EST 2003 until: Wed Mar 03 21:36:25 =
EST 2004=20
  Certificate fingerprints:=20
           MD5:  C3:55:8C:B5:DE:89:E8:48:3E:4C:BB:49:A3:84:E9:67=20
           SHA1: =
90:87:14:CE:0F:EE:A3:C6:6C:7E:95:3C:DE:F4:CB:FB:07:F5:0D:34=20
  </keytool>=20

  > Have you included the root certificate that sign your certificate =
into a trusted store file and point the file=20
  > by the properties MSH/DigitalSignature/TrustAnchor/KeyStore/* ?=20

  Yes. I'm using a different keystore containing the same "PJDM CA" =
certificate as above. (I've also tried using the same keystore.)

  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: Patrick Yee [mailto:kc...@ce...]=20
  Sent: Tuesday, 1 April 2003 6:52 PM=20
  To: ebx...@li...=20
  Subject: Re: [ebxmlms-develop] Signed message debugging=20



  Sorry for the unclear log messages. We are now trying to make the log =
messages more informative. But as you can guess, that is a tough job. =
:-)

  Meanwhile, I can help to track down the problem here. So, let me ask =
you several questions:=20

  Are you generating your own certificate? Is the certificate =
self-signed? Any certificate path is included in the certificate?

  Have you included the root certificate that sign your certificate into =
a trusted store file and point the file by the properties=20

  MSH/DigitalSignature/TrustAnchor/KeyStore/* ?=20




  Regards, -Patrick=20

  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Tuesday, April 01, 2003 1:16 PM=20
  Subject: [ebxmlms-develop] Signed message debugging=20



  I'm sending a signed message to myself using Request.setSign(). =
However, I get the following in the log.=20
  2003-04-01 15:03:27,134 DEBUG [Thread-12]: =3D> MessageServiceHandler =
verify=20
  2003-04-01 15:03:27,134 INFO  [Thread-12]: Verify the XML signature=20
  2003-04-01 15:03:27,575 INFO  [Thread-12]: Received SOAPMessage cannot =
be verified!=20
  2003-04-01 15:03:27,575 DEBUG [Thread-12]: <=3D MessageServiceHandler =
verify=20
  2003-04-01 15:03:27,575 WARN  [Thread-12]: Signature verification =
failed=20
  There doesn't seem to be any indication of why the message couldn't be =
verified.=20
  Is there a straightforward method of debugging verification failures =
to figure out what's going wrong?=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
  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] Setup of ApplicationContexts

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

RE: [ebxmlms-develop] Setup of ApplicationContextsIn that case, there =
will be only one error handler. This would be fine for your application. =
But in the case of multiple clients connecting to the same hermes =
server, we should make it more flexible. That's the argument for us to =
find the AppContext based on ref to message ID.

How about we solve it this way:
1. Set up a receiver with app context (*,*,*,*) and a normal message =
listener. This way, the request will poll hermes server from time to =
time for new messages and call onMessage() to deliver the message to =
application.
2. Set up a sender with app context (*,*,*,*) and pass =
NoMessageListenerImpl as message listener. This is a newly created =
message listener implementation which is "compatible" with a normal =
message listener. But it will stop the request from polling hermes =
server. The good thing is that even you will "override" the receiver's =
registration by this action, the receiver can still poll the messages =
successfully. This is what we mean by "compatible". :-)

What do you think about this? You can find NoMessageListenerImpl in the =
latest source. We will work on a nightly source tarball and put it onto =
our web site tomorrow.

Regards, -Patrick

  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Wednesday, April 02, 2003 12:40 PM
  Subject: RE: [ebxmlms-develop] Setup of ApplicationContexts


  If I modify MessageServiceHandler.onMessage(EbxmlMessage ebxmlMessage, =
Map requestProperty) by changing the last statement of=20

              if (isError) {=20
                  logger.info("Error message received");=20
                  final String refToMessageId =3D =
ebxmlMessage.getMessageHeader().=20
                      getRefToMessageId();=20
                  logger.info("RefToMessageId: " + refToMessageId);=20
                  if (refToMessageId !=3D null) {=20
                      final ApplicationContext refToAppContext =3D=20
                          =
messageServer.getApplicationContext(refToMessageId);=20

  to hard code my universal ApplicationContext:=20

                      final ApplicationContext refToAppContext =3D=20
                          new ApplicationContext("*","*","*","*");=20

  I get what I want: errors are sent to my universal listener, instead =
of back to the sender.=20

  However, is this a good thing to do? If so, should there be some way =
of specifying the ApplicationContext that errors are to be delivered to, =
rather than hardcoding it like this? (I don't think it would be =
difficult to add this to the msh.properties.xml file. I'll try it if =
anyone thinks it's worth the effort.) And should there be a way of =
sending messages without having an ApplicationContext registered for =
each message? (I suspect this would be a bit much to change.)

  If this isn't a good thing to do, is my application architecture =
broken? If errors are supposed to return to the sender, how long must =
the sender (and therefore possibly the user) wait for the error?

  What is the right way of doing this?=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

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] EbxmlMessage: Manifest, Reference, role

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

Hi,

> How do I check out the latest CVS?

        Please refer to http://sourceforge.net/cvs/?group_id=56612

> Also, the Reference class doesn't appear to have an "xlink:role"
> accessor. (The ebXML we're getting from our business partner
> uses the role.)

        role has been added in the lastest CVS as well.

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] Signed message debugging

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

RE: [ebxmlms-develop] Signed message debuggingPeter, before I go into =
details to study your cert structure, may I ask you a quick question? =
:-)

How are you signing the message? Are you calling ebxmlMessage.sign(...)? =
Or calling request.setSign(...)? It is a trap there. Let me explain in =
details.=20

Here is the correct way of signing a message:

1. construct ebxmlMessage in client app
2. instruct hermes to sign by calling request.setSign(...)
3. send out using request.sendReliably(...)

Here is a wrong way:

1. construct ebxmlMessage in client app
2. sign the ebxmlMessage in client app using ebxmlMessage.sign(...)
3. send out using request.sendReliably(...)

The reason is: before request send the message to hermes server, it will =
modify the message header (e.g. add AckRequest header, etc.). If you =
sign the message before request.sendReliably(), any newly added header =
will invalidate the signature. So, the correct way is to call =
setSign(...). Then, request will sign the message *after* adding all =
necessary headers.

Seems we have to add an exception there to reject signed message as =
parameter to sendReliably().

Regards, -Patrick

  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Wednesday, April 02, 2003 8:19 AM
  Subject: RE: [ebxmlms-develop] Signed message debugging


  > Are you generating your own certificate?=20

  Yes.=20

  > Is the certificate self-signed?=20

  No.=20

  > Any certificate path is included in the certificate?=20

  Yes. keytool -list -v shows:=20

  <keytool>=20
  Alias name: pjdmca=20
  Creation date: 18/03/2003=20
  Entry type: trustedCertEntry=20

  Owner: CN=3DPJDM CA, OU=3DTechnology, O=3DSpherion Group Ltd, =
L=3DLyneham, ST=3DACT, C=3DAU=20
  Issuer: CN=3DPJDM CA, OU=3DTechnology, O=3DSpherion Group Ltd, =
L=3DLyneham, ST=3DACT, C=3DAU=20

  Serial number: 0=20
  Valid from: Tue Mar 04 21:36:25 EST 2003 until: Wed Mar 03 21:36:25 =
EST 2004=20
  Certificate fingerprints:=20
           MD5:  C3:55:8C:B5:DE:89:E8:48:3E:4C:BB:49:A3:84:E9:67=20
           SHA1: =
90:87:14:CE:0F:EE:A3:C6:6C:7E:95:3C:DE:F4:CB:FB:07:F5:0D:34=20



  *******************************************=20
  *******************************************=20



  Alias name: chmeeehermes=20
  Creation date: 18/03/2003=20
  Entry type: keyEntry=20
  Certificate chain length: 2=20
  Certificate[1]:=20
  Owner: CN=3Dchmeee Hermes, OU=3Db2b, O=3Debusiness, L=3DCanberra, =
ST=3DACT, C=3DAU=20
  Issuer: CN=3DPJDM CA, OU=3DTechnology, O=3DSpherion Group Ltd, =
L=3DLyneham, ST=3DACT, C=3DAU=20

  Serial number: 4=20
  Valid from: Tue Mar 18 22:56:13 EST 2003 until: Wed Mar 17 22:56:13 =
EST 2004=20
  Certificate fingerprints:=20
           MD5:  69:D9:46:50:B5:F0:FB:B6:85:34:F9:E6:D1:AF:92:3E=20
           SHA1: =
8E:2B:B6:9C:5D:DC:AC:C6:47:91:68:6D:18:9E:02:79:93:EF:41:C8=20
  Certificate[2]:=20
  Owner: CN=3DPJDM CA, OU=3DTechnology, O=3DSpherion Group Ltd, =
L=3DLyneham, ST=3DACT, C=3DAU=20
  Issuer: CN=3DPJDM CA, OU=3DTechnology, O=3DSpherion Group Ltd, =
L=3DLyneham, ST=3DACT, C=3DAU=20

  Serial number: 0=20
  Valid from: Tue Mar 04 21:36:25 EST 2003 until: Wed Mar 03 21:36:25 =
EST 2004=20
  Certificate fingerprints:=20
           MD5:  C3:55:8C:B5:DE:89:E8:48:3E:4C:BB:49:A3:84:E9:67=20
           SHA1: =
90:87:14:CE:0F:EE:A3:C6:6C:7E:95:3C:DE:F4:CB:FB:07:F5:0D:34=20
  </keytool>=20

  > Have you included the root certificate that sign your certificate =
into a trusted store file and point the file=20
  > by the properties MSH/DigitalSignature/TrustAnchor/KeyStore/* ?=20

  Yes. I'm using a different keystore containing the same "PJDM CA" =
certificate as above. (I've also tried using the same keystore.)

  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: Patrick Yee [mailto:kc...@ce...]=20
  Sent: Tuesday, 1 April 2003 6:52 PM=20
  To: ebx...@li...=20
  Subject: Re: [ebxmlms-develop] Signed message debugging=20



  Sorry for the unclear log messages. We are now trying to make the log =
messages more informative. But as you can guess, that is a tough job. =
:-)

  Meanwhile, I can help to track down the problem here. So, let me ask =
you several questions:=20

  Are you generating your own certificate? Is the certificate =
self-signed? Any certificate path is included in the certificate?

  Have you included the root certificate that sign your certificate into =
a trusted store file and point the file by the properties=20

  MSH/DigitalSignature/TrustAnchor/KeyStore/* ?=20




  Regards, -Patrick=20

  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Tuesday, April 01, 2003 1:16 PM=20
  Subject: [ebxmlms-develop] Signed message debugging=20



  I'm sending a signed message to myself using Request.setSign(). =
However, I get the following in the log.=20
  2003-04-01 15:03:27,134 DEBUG [Thread-12]: =3D> MessageServiceHandler =
verify=20
  2003-04-01 15:03:27,134 INFO  [Thread-12]: Verify the XML signature=20
  2003-04-01 15:03:27,575 INFO  [Thread-12]: Received SOAPMessage cannot =
be verified!=20
  2003-04-01 15:03:27,575 DEBUG [Thread-12]: <=3D MessageServiceHandler =
verify=20
  2003-04-01 15:03:27,575 WARN  [Thread-12]: Signature verification =
failed=20
  There doesn't seem to be any indication of why the message couldn't be =
verified.=20
  Is there a straightforward method of debugging verification failures =
to figure out what's going wrong?=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
  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] EbxmlMessage: Manifest, Reference, role

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

Hi,

> How do I get the ebXML manifest and references, and the reference role,
> from an EbxmlMessage?

        Please use the latest CVS in which Manifest can be retrieved.

> There is a public Reference class, but the Manifest class (which does have a
> getReferences() method) isn't public, and EbxmlMessage doesn't have a
> getManifest() method. Also, the Reference class doesn't appear to have an
> "xlink:role" accessor. (The ebXML we're getting from our business partner
> uses the role.)

        For role attribute, I'll fix it soon.

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] EbxmlMessage: Manifest, Reference, role

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

EbxmlMessage: Manifest, Reference, roleThe getReferences() method in =
Manifest class has been made public some time ago. Also the =
getManifest() method has been added to EbxmlMessage class. Please check =
out latest CVS.

We will add "xlink:role" attribute the Reference element later. Thanks =
for point this out.

Regards, -Patrick

  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Wednesday, April 02, 2003 7:54 AM
  Subject: [ebxmlms-develop] EbxmlMessage: Manifest, Reference, role


  How do I get the ebXML manifest and references, and the reference =
role, from an EbxmlMessage?=20

  There is a public Reference class, but the Manifest class (which does =
have a getReferences() method) isn't public, and EbxmlMessage doesn't =
have a getManifest() method. Also, the Reference class doesn't appear to =
have an "xlink:role" accessor. (The ebXML we're getting from our =
business partner uses the role.)

  (The Sun ebxml classes have these as public.)=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

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] Signed message debugging

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

Signed message debuggingSorry for the unclear log messages. We are now =
trying to make the log messages more informative. But as you can guess, =
that is a tough job. :-)

Meanwhile, I can help to track down the problem here. So, let me ask you =
several questions:

Are you generating your own certificate? Is the certificate self-signed? =
Any certificate path is included in the certificate?
Have you included the root certificate that sign your certificate into a =
trusted store file and point the file by the properties=20
MSH/DigitalSignature/TrustAnchor/KeyStore/* ?



Regards, -Patrick

  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Tuesday, April 01, 2003 1:16 PM
  Subject: [ebxmlms-develop] Signed message debugging


  I'm sending a signed message to myself using Request.setSign(). =
However, I get the following in the log.=20

  2003-04-01 15:03:27,134 DEBUG [Thread-12]: =3D> MessageServiceHandler =
verify=20
  2003-04-01 15:03:27,134 INFO  [Thread-12]: Verify the XML signature=20
  2003-04-01 15:03:27,575 INFO  [Thread-12]: Received SOAPMessage cannot =
be verified!=20
  2003-04-01 15:03:27,575 DEBUG [Thread-12]: <=3D MessageServiceHandler =
verify=20
  2003-04-01 15:03:27,575 WARN  [Thread-12]: Signature verification =
failed=20

  There doesn't seem to be any indication of why the message couldn't be =
verified.=20

  Is there a straightforward method of debugging verification failures =
to figure out what's going wrong?=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

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] Setup of ApplicationContexts

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

RE: [ebxmlms-develop] Setup of ApplicationContextsPeter,

This is a normal behaviour. For error messages, we tried our best to =
deliver them to the sender. We do that by following the trace of =
RefToMessageID.

In your case, we suggest you to send out the messages using the Request =
with AppContext (*,*,*,*). You can send out any messages using Request =
with any AppContext. The AppContext only governs the receiving patterns.

For the ToPartyID bug, please check out the latest CVS copy. We have =
fixed that some time ago.

Regards, -Patrick
  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Tuesday, April 01, 2003 2:47 PM
  Subject: RE: [ebxmlms-develop] Setup of ApplicationContexts


  I have a listener servlet registered with Hermes using =
ApplicationContext("*", "*", "*", "*"). I want this servlet to receive =
*all* incoming messages.

  In the Loopback application (which I've augmented over time), I create =
a Request using=20

  ApplicationContext("__"+cpaID, "__"+conversationID, "__"+service, =
"__"+action);=20

  The underlines are there to create an ApplicationContext that I should =
never receive. I then create a message with=20

              header.setCpaId(cpaID);=20
              header.setConversationId(conversationID);=20
              header.setService("myService", "myType");=20
              header.setAction("myAction");=20

          mshReq.setSign("alias", "password".toCharArray(), "keystore"); =


  and send the message. Because the message isn't verified (which is a =
separate problem), I get an error response. However, the error message =
(with action "MessageError" and service =
"urn:oasis:names:tc:ebxml-msg:service" as per the specification) is =
getting delivered to my Loopback program, *not* to my listener servlet. =
Since my Loopback program runs only long enough to send the message, I =
don't want it to ever receive a message.

  From previous discussion in this thread, my assumption is that the =
Loopback program should *not* be getting  the incoming error message =
delivered to it, particularly since I can guarantee that I have never =
registered for action "MessageError" or service =
"urn:oasis:names:tc:ebxml-msg:service" in Loopback.

  What's going on here?=20

  (Incidentally, there's a possible bug here. I use=20

  header.addToPartyId("99999999999", "ABN");=20

  to build the message, but the error message I get back has a null =
type. Ditto for the frompartyId.)=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

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] signed acknowledgments

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

Hi,

> per ebMS2, when signed acknowledgments are requested, the
> acknowledgment must contain the digests of the original (signed or
> unsigned) message. AFAICT, this is currently not implemented. Is there
> an easy way to add it? I've tracked down signing as far as the Apache
> XML security libs, but I was hoping of an easier and faster way to add
> the digests than going through three levels of API's...

        This has been the problem in my mind for a long time. The answer
is that there is no easy way to add such a digest. Personally speaking,
I don't find the Apache XML security lib easy to use. At least, some
element classes that should not be accessed directly somehow go public
while some elements I want cannot be retrieved via its API. I will
follow this again but we focus on the release this week.

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

[ebxmlms-develop] signed acknowledgments

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

Hi team,=20

per ebMS2, when signed acknowledgments are requested, the acknowledgment =
must contain the digests of the original (signed or unsigned) message. =
AFAICT, this is currently not implemented. Is there an easy way to add =
it? I've tracked down signing as far as the Apache XML security libs, =
but I was hoping of an easier and faster way to add the digests than =
going through three levels of API's...

thnx, Gait.

RE: [ebxmlms-develop] Client certificate authentication

[Ronald v. K. <rv...@ab...>]

exactely... and using an alias is only needed if all the fowllowing are met:
- you have to connect to 2 different mhs
- the both accept certificates by the same root issuer and there is not a
different intermediate CA
- you have 2 certificates from this issuer (e.g. because both mhs are a
separate community and require the subject of the certificate to have a
specific value in it)
- ....
 
So it probably will not occur to often in real life.
 
Ronald

-----Oorspronkelijk bericht-----
Van: Mayne, Peter [mailto:Pet...@ap...]
Verzonden: maandag 31 maart 2003 5:45
Aan: 'ebx...@li...'
Onderwerp: RE: [ebxmlms-develop] Client certificate authentication



> Anybody know how to select a specific keystore alias in Java? 

Aha! 

Custom SSL for advanced JSSE developers 
Use JSSE to customize the properties of your SSL connections 

http://www-106.ibm.com/developerworks/java/library/j-customssl/index.html
<http://www-106.ibm.com/developerworks/java/library/j-customssl/index.html>


So, all we need now is HermesHttpSoapConnectionImpl. :-) 

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.

Re: [ebxmlms-develop] logging remark

[Ronald v. K. <rv...@ab...>]

If you want to log the complete messages going in and out (at debug 
level) you have to convert them in a way (xml -> string)

Ronald

Patrick Yee probeerde het volgende duidelijk te maken op 29-03-03 06:36:

>Thank you for you suggestion. We are doing logging restrucuring recently. So
>it is the right time to take care this.
>
>I am not too sure at one point: why xml -> string conversion is needed when
>using logger? Is this specific to your messaging system only?
>
>Cheers, -Patrick
>
>----- Original Message -----
>From: "Ronald van Kuijk" <rv...@ab...>
>To: "freebxml" <ebx...@li...>
>Sent: Saturday, March 29, 2003 08:29 AM
>Subject: [ebxmlms-develop] logging remark
>
>
>  
>
>>Hi,
>>
>>I've seen that all logging is done without checking whether the
>>specified loglevel is even configured. We've seen in our Messaging
>>System that first checking if a certain loglevel is configured gave us
>>3-7% performance gain. This was due to the fact that on man ocasions xml
>>-> string conversions were needed as well as string
>>    
>>
>creation/concatenation.
>  
>
>>So instead of
>>
>>logger.debug("A message");
>>
>>we now do
>>
>>if (logger.isDebugEnabled()) {
>>    logger.debug("A message");
>>}
>>
>>I do not know what the gain will be in hermes since i've not looked
>>through all the code. It's probably not that much since debug info is
>>not that detailed, but I thought I'd just mention it.
>>
>>Ronald
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by:
>>The Definitive IT and Networking Event. Be There!
>>NetWorld+Interop Las Vegas 2003 -- Register today!
>>http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
>>_______________________________________________
>>ebxmlms-develop mailing list
>>ebx...@li...
>>https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>>
>>    
>>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by:
>The Definitive IT and Networking Event. Be There!
>NetWorld+Interop Las Vegas 2003 -- Register today!
>http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
>_______________________________________________
>ebxmlms-develop mailing list
>ebx...@li...
>https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>  
>

Re: [ebxmlms-develop] Design questions

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

The original design philosophy of Hermes is "simple". That's why we use only
servlet container, but not J2EE server. In the very beginning, we even tried
to get rid of database! So, you can see that, only minimal data, i.e. meta
data, is stored in DB. Another concern is JDBC. We are in favour of
supporting multiple DB servers via JDBC. That's why our SQLs are all SQL-92
compliant, and it is relatively hard to get the message stored in DB.
Transaction is a big issue, and to make Hermes run on servlet container
only, we paid the price of doubled effort to implement our own transaction
object. :-)

Regards, -Patrick


----- Original Message -----
From: "Ronald van Kuijk" <rv...@ab...>
To: "freebxml" <ebx...@li...>
Sent: Saturday, March 29, 2003 09:16 AM
Subject: [ebxmlms-develop] Design questions


> Hi,
>
> Hermes is now more or less an atomic application. I you build or use a
> servletcontainer (e.g. embedded tomcat or so) nothing else is needed.
> This is good in many cases, but we like to make as much use of features
> of a full j2ee application server as possible. The parts that come to
> mind are:
>
> - Authentication
> - DBConnectionpooling, based on JNDI
> - Transactions
> - File based persistence
>
> I can imagine that doing this, means that it can run in simple servlet
> engines and that the performance is probably higher. In our case however
> it has to run in a Weblogic server at an ASP. They do not allow us to
> configure database connections outside the appserver connectionpools.
> The same goes for the ba accounts and certificates. They have to be
> checked against an ldap server, so the username/password file is not an
> option for us.
>
> For High Availability reasons file based persistence is not an option.
> I've seen that all the meta information is stored in a database, but the
> messages themselves are not. Correct me if i'm wrong.
>
> Again, I do not mean this as an attack on your choices, but making this
> configurable in one way or another, would benefit all (well at least us
> ;-)). There are several developers in our company that could spend time
> on this once we get permission/funding to redesign our messaging server
> a little (it's now partly ebms 1.092 compliant, with extensions to
> backwards compatible with our previous x.400 system)
>
> We also like to extend the system with several other options, many of
> which need tapping into the message flow in our central MHS (is muli-hop
> supported?)
> - EDI2XML and XML2EDI, depending of customer profiles
> - Virusscanning (yes, even with application to application communication
> and pure xml/edi documents customers want this)
> - Generating Management Information based on the envelope and/or content
> of the attachments
>
> We are thinking of implementing this in a kind of a 'bus' way, where the
> bus is a jms queue and a kind of a businessrule/processflow component to
> decide in which queue to place the message. We do not like to have this
> tightly coupled with ejb's but loosly with queue's and mdb's.
>
> Does anyone of you have any ideas on these subjects?
>
> Regards,
>
> Ronald
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>