Hi,
Header's value should be either DOM element or marshalable JAXB object, for
example:
Document headerDoc = builder.parse(new ByteArrayInputStream("<test:testValue
xmlns:test=\"test\"/>"
.getBytes()));
Header testHeader = new Header(TEST_HEADER_NAME,
headerDoc.getDocumentElement());
or
List<Header> headers = new ArrayList<Header>();
Header dummyHeader = new Header(new QName("uri:org.apache.cxf", "dummy"),
"decapitated",
new JAXBDataBinding(String.class));
headers.add(dummyHeader);
The problem is that CXF doesn't know how to marshal the message you pass as
header value.
Regards,
Andrei.
> -----Original Message-----
> From: Engelhardt. Julian [mailto:[email protected]]
> Sent: Freitag, 7. März 2014 10:01
> To: [email protected]
> Subject: WG: Calling CXF processing without generating services or clients
>
> Hi there,
>
> A question occured as a result of the answers I got from Andrei. Using
> dispatches seems very promising, however I could not manage to compose the
> message correctly. My current approach looks like this:
>
> Service service = Service.create(new QName("AS4PartnerService"));
> service.addPort(new
> QName("http://schemas.xmlsoap.org/wsdl/soap12/";),
> "http://schemas.xmlsoap.org/wsdl/soap12/";, config.getEndpointUrl());
>
> Dispatch<Object> dispatch = service.createDispatch(new
> QName("http://schemas.xmlsoap.org/wsdl/soap12/";), new
> AS4Marshaller().getContext(),Service.Mode.MESSAGE);
>
> SoapMessage soapMessage = new SoapMessage(Soap12.getInstance());
> soapMessage.getHeaders().add(new Header(new QName("Messaging"),
> message));
>
> dispatch.invoke(soapMessage);
>
> I first tried using the payload mode, but this will, as documented, insert the
> message content into the body of the SOAP message. An AS4 message however
> has to carry all information except for payloads in the header. There can be
> one payload in the SOAP body and several in a SWAref structure.
>
> When running the code above, an Exception occurs which says that
> com.sun.xml.messaging.saaj.soap.SOAPDocumentFragment is not known to the
> JAXBContext. To fix this, I added the class to the JAXB context I use, still
> nothing.
> I found out that the exception occurs in JAXBImpl's getBeanInfo(Class<T>
> clazz,boolean fatal) method since getBeanInfo(Object o) returns null. However,
> when debugging it, the Map containing the BeanInfo objects has an entry with
> the correct classname and a com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl as
> BeanInfo, but it is not retrieved. This occurs in cxf version 3.0.0
> Milestone2 (we
> need this Version for support of WSS4J 2.0) with JAXB-impl 2.2.5.
>
> Is such a problem known to someone else? What would be the best way to set
> the contents of the SOAP message in a dispatch (I need to have access to head,
> body and MIME-Parts)?
>
> Regards,
> Julian
>
> -----Ursprüngliche Nachricht-----
> Von: Engelhardt. Julian
> Gesendet: Mittwoch, 5. März 2014 09:15
> An: [email protected]
> Cc: 'Andrei Shakirin'
> Betreff: AW: Calling CXF processing without generating services or clients
>
> Hi Andrei,
>
> Thanks for the information. You understood correctly what I want to do. Your
> approach for sending the message after processing it in CXF is pretty much
> what I thought of doing, so I think your blog post will be helpful to me. The
> dispatch based clients and providers also sound promising, I will have a
> closer
> look on this.
>
> Regards,
> Julian
>
> -----Ursprüngliche Nachricht-----
> Von: Andrei Shakirin [mailto:[email protected]]
> Gesendet: Dienstag, 4. März 2014 18:10
> An: [email protected]
> Cc: Engelhardt. Julian
> Betreff: RE: Calling CXF processing without generating services or clients
>
> Hi,
>
> As I understand you would like to use CXF as framework to compose, transform
> SOAP messages and apply security features on it.
> However you are going to use own component to physically send the message
> (internal HTTP transport mechanisms).
>
> I would consider to implement custom transport in this case. CXF will be
> responsible to create SOAP message, applying security features, etc - but you
> can implement own transport factory, conduit and destination to physically
> transfer the messages. For more information you can find in this blog:
> http://ashakirin.blogspot.de/2012/02/custom-cxf-transport.html
>
> It is not necessary to have WSDL and generated code/annotated to create CXF
> client and services.
> You can use generic Dispatch based clients and Provider<T> based services and
> work with messages on low level (SAAJ, Source). AEGIS data binding
> (https://cxf.apache.org/docs/aegis-databinding-20x.html) provides a facility
> to
> marshal/unmarshal java classes without annotations.
>
> In result you will have high level business logic to process requests and
> responses and invoke JAX-WS API, then CXF will process messages using
> interceptor chain and call you custom transport component to transfer the
> messages.
> Does it make sense for you?
>
> Regards,
> Andrei.
>
> > -----Original Message-----
> > From: Engelhardt. Julian [mailto:[email protected]]
> > Sent: Dienstag, 4. März 2014 14:30
> > To: [email protected]
> > Subject: Calling CXF processing without generating services or clients
> >
> > Hello everybody,
> >
> > I am currently evaluating CXF as a transport framework for one of our
> > products. Since this will be an implementation of the AS4 protocol,
> > there is no WSDL or such which I can use to generate a Service or
> > Client. Also, the component I am working on will be part of a bigger
> > product which has internal HTTP transport mechanisms I will have to
> > use. So I think it will not be possible to take the “standard”
> > approach. This leads to the question I would like to hear your thoughts
> > about:
> >
> > How can I use CXF to compose, transform (encrypt, sign, compress,
> > etc.) and send a SOAP message without generating a service or a client
> > from a WSDL, annotated classes or such?
> >
> > Since the developed component will only support AS4, there is not much
> > variable configuration apart from URL, processing steps (interceptor
> > chain) and content of the message.
> >
> > Currently, I am looking for a solution on the client side, however I
> > would appreciate any tip. The option that I think would be possible is
> > to create a ClientImpl object which I configure from within my code.
> > However, I haven’t found a good way to set the content of the message,
> > apart from inserting it via an own interceptor (this is not the way
> > CXF does it itself, right?) and it seems like there is very much
> > configuration to be done for which I might be able to use the
> > configuration mechanisms of CXF. Can you recommend a component or
> > approach which will provide a better entry point for this kind of
> implementation?
> >
> > Sincerely,
> > Julian Engelhardt
> > SEEBURGER AG - Edisonstr. 1, D 75015 Bretten, Germany
> > mailto: [email protected]<mailto:[email protected]> -
> > www.seeburger.de<http://www.seeburger.de>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > SEEBURGER AG Vorstand/Seeburger Executive Board:
> > Sitz der Gesellschaft/Registered Office: Bernd Seeburger,
> > Axel Haas,
> > Michael Kleeberg
> > Edisonstr. 1
> > D-75015 Bretten Vorsitzender des Aufsichtsrats/Chairperson of the
> > Seeburger Supervisory Board:
> > Tel.: 07252 / 96 - 0 Dr. Franz Scherer
> > Fax: 07252 / 96 - 2222
> > Internet: http://www.seeburger.de Registergericht/Commercial
> > Register:
> > e-mail: [email protected] HRB 240708 Mannheim
> >
> >
> > Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet
> > ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes
> > Material enthalten. Jegliche darin enthaltene Ansicht oder
> > Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise
> > die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der
> > Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche
> > Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher
> > Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG
> > noch der Absender ( Engelhardt. Julian ) übernehmen die Haftung für
> > Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf
> Viren zu prüfen.
> >
> >
> > The present email addresses only the addressee which it targets and
> > may contain confidential material that may be protected by the professional
> secret.
> > The opinions reflected herein are not necessarily the one of the
> > SEEBURGER AG. If you are not the addressee, you have accidentally got
> > this email and are not enabled to use, publish, forward, copy or print
> > it in any way. Neither SEEBURGER AG , nor the sender (Engelhardt.
> > Julian) are liable for viruses, being your own responsibility to check
> > this email and its attachments for this purpose.
>
>
>
>
>
>
>
>
>
> SEEBURGER AG Vorstand/Seeburger Executive Board:
> Sitz der Gesellschaft/Registered Office: Bernd Seeburger, Axel
> Haas,
> Michael Kleeberg
> Edisonstr. 1
> D-75015 Bretten Vorsitzender des Aufsichtsrats/Chairperson of the
> Seeburger Supervisory Board:
> Tel.: 07252 / 96 - 0 Dr. Franz Scherer
> Fax: 07252 / 96 - 2222
> Internet: http://www.seeburger.de Registergericht/Commercial
> Register:
> e-mail: [email protected] HRB 240708 Mannheim
>
>
> Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und
> kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material
> enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des
> Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der
> SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail
> irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung,
> Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder
> die SEEBURGER AG noch der Absender ( Engelhardt. Julian ) übernehmen die
> Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren
> Anhänge auf Viren zu prüfen.
>
>
> The present email addresses only the addressee which it targets and may
> contain confidential material that may be protected by the professional
> secret.
> The opinions reflected herein are not necessarily the one of the SEEBURGER
> AG. If you are not the addressee, you have accidentally got this email and are
> not enabled to use, publish, forward, copy or print it in any way. Neither
> SEEBURGER AG , nor the sender (Engelhardt. Julian) are liable for viruses,
> being your own responsibility to check this email and its attachments for this
> purpose.
