Re: [VOTE] Release CXF dOSGi 1.0
2009/5/5 Daniel Kulp : > > OK. That kind of make sense (along with what Eoghan said). > > However, I really think there needs to at least be a "README" in the > distributions that describes a little what it is along with pointers to the > walkthroughs and such on the website. I've added a README with an overview of the different distros and pointers to getting started docco, mailing lists, JIRA etc: http://svn.apache.org/viewvc/cxf/dosgi/trunk/distribution/multi-bundle/src/main/release/README?view=markup I've also addressed your other concerns in these two commits: http://svn.apache.org/viewvc?rev=772157&view=rev http://svn.apache.org/viewvc?rev=771670&view=rev So I think we should be good to go with a second cut at this release. Cheers, Eoghan 2009/5/5 Daniel Kulp : > > OK. That kind of make sense (along with what Eoghan said). > > However, I really think there needs to at least be a "README" in the > distributions that describes a little what it is along with pointers to the > walkthroughs and such on the website. > > Right now, I download and unpack the the tarball and I look at it and say > "uhh. what do I do with this?" We definitely need a readme in there to > describe things as well as provide pointers off to the web site, the users@ > list for questions, etc. > > Dan > > > > On Tue May 5 2009 5:31:49 am David Bosschaert wrote: >> Hi Dan, >> >> On the samples, they are not part of the distribution because they can >> be installed straight from the internet. All of the DOSGi >> documentation is available here: >> http://cxf.apache.org/distributed-osgi.html and which contains links >> to the sample source code and a very detailed walkthrough of the >> greeter sample: >> http://cxf.apache.org/distributed-osgi-greeter-demo-walkthrough.html >> As the OSGi containers install stuff straight from the internet, you >> don't have to have the bundles available locally. Once the release is >> out I'm planning to update this page to point straight to the sample >> artefacts in maven. >> >> There is no such page for the spring-dm demo, I'll take an action to >> provide such a page with the DOSGi documentation, but I don't think >> this should hold up the release. >> >> Hope this makes sense to you, >> >> David >> >> 2009/5/4 Daniel Kulp : >> > I think I have to -1 this. Couple legal things need to get ironed out: >> > >> > 1) Since this is a full "distribution" type thing, what parts of that >> > staging area will go into www.apache.org/dist/cxf? I ASSUME the >> > mutimodule bundle, but not really sure. Also, there needs to be a >> > tar.gz or zip of a "source" distribution of the whole contents of the >> > tag. That would also go into dist. >> > >> > 2) I think some stuff in the NOTICE can be removed. For example: DOSGi >> > doesn't ship the MTOSI stuff, that could be removed. Not major, but if >> > a build has to be respun, let's get that cleaned up. >> > >> > 3) For the "distribution" builds, the LICENSE file needs to have at least >> > the pointers to the LICENSES of the bundled deps appended to it. See >> > the LICENSE in the cxf distributions. (remote-resources can do that, I >> > may be able to help out tomorrow if I get out from under my backlog of >> > email. :-( ) >> > >> > 4) Actually, IS there a distribution that includes the samples, possible >> > a readme, etc...? Should there be? Not a big deal either way, but a >> > bit strange. >> > >> > >> > Dan >> > >> > On Fri May 1 2009 12:39:48 pm Eoghan Glynn wrote: >> >> Folks, >> >> >> >> I'm calling a vote to release CXF Distributed OSGi 1.0. >> >> >> >> The dOSGi subproject of CXF provides the Reference Implementation of >> >> the Distribution Software (DSW) component of the Distributed OSGi >> >> Specification[1]. >> >> >> >> The staging area can be found at: >> >> >> >> http://people.apache.org/~eglynn/stage_cxf_dosgi >> >> >> >> This release is tagged with cxf-dosgi-ri-1.0 at: >> >> >> >> http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.0 >> >> >> >> The vote will remain open for at least 72 hours. >> >> >> >> Please consider this call to vote as my +1. >> >> >> >> Cheers, >> >> Eoghan >> >> >> >> [1] See RFC 119 in >> >> http://www.osgi.org/download/osgi-4.2-early-draft3.pdf >> > >> > -- >> > Daniel Kulp >> > dk...@apache.org >> > http://www.dankulp.com/blog > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog >
Re: How to determine whether a soap message have an attachment
Hi I think MTOM message should have the attachment info, we could check that for it. We have some trouble to send the MTOM message if we send the message in Text model, and Liu Cong is working on the patch. Willem Daniel Kulp wrote: > Doesn't it already support MTOM? > > Basically, it provides a OutputSteam to the dispatching and if the runtime > needs to handle attachments and such, it will write it as mime stuff to the > stream. > > Dan > > > > On Tue May 5 2009 12:53:48 am liucong wrote: >> Hi all, >> >> When I want to add MTOM support for SOAP/JMS, I should know whether a >> soap message have an attachment. But I don't know the details how to >> judge wheter the message have an attachment. >> Is anyone give me any prompt about where the code is? Or some code example? >> >> Thank you very much. >> >> Best regards >> >> Liu >
Re: [VOTE] Release CXF dOSGi 1.0
Pretty close. Just mentioned on IRC that the source distro needs the LICENSE/NOTICE things. Other than that, looks much better. Thanks! Dan On Wed May 6 2009 9:10:18 am Eoghan Glynn wrote: > 2009/5/5 Daniel Kulp : > > OK. That kind of make sense (along with what Eoghan said). > > > > However, I really think there needs to at least be a "README" in the > > distributions that describes a little what it is along with pointers to > > the walkthroughs and such on the website. > > I've added a README with an overview of the different distros and > pointers to getting started docco, mailing lists, JIRA etc: > > http://svn.apache.org/viewvc/cxf/dosgi/trunk/distribution/multi-bundle/src/ >main/release/README?view=markup > > I've also addressed your other concerns in these two commits: > > http://svn.apache.org/viewvc?rev=772157&view=rev > http://svn.apache.org/viewvc?rev=771670&view=rev > > So I think we should be good to go with a second cut at this release. > > Cheers, > Eoghan > > 2009/5/5 Daniel Kulp : > > OK. That kind of make sense (along with what Eoghan said). > > > > However, I really think there needs to at least be a "README" in the > > distributions that describes a little what it is along with pointers to > > the walkthroughs and such on the website. > > > > Right now, I download and unpack the the tarball and I look at it and say > > "uhh. what do I do with this?"We definitely need a readme in > > there to describe things as well as provide pointers off to the web site, > > the users@ list for questions, etc. > > > > Dan > > > > On Tue May 5 2009 5:31:49 am David Bosschaert wrote: > >> Hi Dan, > >> > >> On the samples, they are not part of the distribution because they can > >> be installed straight from the internet. All of the DOSGi > >> documentation is available here: > >> http://cxf.apache.org/distributed-osgi.html and which contains links > >> to the sample source code and a very detailed walkthrough of the > >> greeter sample: > >> http://cxf.apache.org/distributed-osgi-greeter-demo-walkthrough.html > >> As the OSGi containers install stuff straight from the internet, you > >> don't have to have the bundles available locally. Once the release is > >> out I'm planning to update this page to point straight to the sample > >> artefacts in maven. > >> > >> There is no such page for the spring-dm demo, I'll take an action to > >> provide such a page with the DOSGi documentation, but I don't think > >> this should hold up the release. > >> > >> Hope this makes sense to you, > >> > >> David > >> > >> 2009/5/4 Daniel Kulp : > >> > I think I have to -1 this. Couple legal things need to get ironed > >> > out: > >> > > >> > 1) Since this is a full "distribution" type thing, what parts of that > >> > staging area will go into www.apache.org/dist/cxf? I ASSUME the > >> > mutimodule bundle, but not really sure. Also, there needs to be a > >> > tar.gz or zip of a "source" distribution of the whole contents of the > >> > tag.That would also go into dist. > >> > > >> > 2) I think some stuff in the NOTICE can be removed. For example: > >> > DOSGi doesn't ship the MTOSI stuff, that could be removed. Not > >> > major, but if a build has to be respun, let's get that cleaned up. > >> > > >> > 3) For the "distribution" builds, the LICENSE file needs to have at > >> > least the pointers to the LICENSES of the bundled deps appended to it. > >> > See the LICENSE in the cxf distributions. (remote-resources can do > >> > that, I may be able to help out tomorrow if I get out from under my > >> > backlog of email. :-( ) > >> > > >> > 4) Actually, IS there a distribution that includes the samples, > >> > possible a readme, etc...? Should there be? Not a big deal > >> > either way, but a bit strange. > >> > > >> > > >> > Dan > >> > > >> > On Fri May 1 2009 12:39:48 pm Eoghan Glynn wrote: > >> >> Folks, > >> >> > >> >> I'm calling a vote to release CXF Distributed OSGi 1.0. > >> >> > >> >> The dOSGi subproject of CXF provides the Reference Implementation of > >> >> the Distribution Software (DSW) component of the Distributed OSGi > >> >> Specification[1]. > >> >> > >> >> The staging area can be found at: > >> >> > >> >> http://people.apache.org/~eglynn/stage_cxf_dosgi > >> >> > >> >> This release is tagged with cxf-dosgi-ri-1.0 at: > >> >> > >> >> http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.0 > >> >> > >> >> The vote will remain open for at least 72 hours. > >> >> > >> >> Please consider this call to vote as my +1. > >> >> > >> >> Cheers, > >> >> Eoghan > >> >> > >> >> [1] See RFC 119 in > >> >> http://www.osgi.org/download/osgi-4.2-early-draft3.pdf > >> > > >> > -- > >> > Daniel Kulp > >> > dk...@apache.org > >> > http://www.dankulp.com/blog > > > > -- > > Daniel Kulp > > dk...@apache.org > > http://www.dankulp.com/blog -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: [VOTE] Release CXF dOSGi 1.0
Thanks Dan, should be sorted in this latest commit: http://svn.apache.org/viewvc?rev=772302&view=rev /Eoghan 2009/5/6 Daniel Kulp : > > > Pretty close. Just mentioned on IRC that the source distro needs the > LICENSE/NOTICE things. Other than that, looks much better. > > Thanks! > Dan > > > On Wed May 6 2009 9:10:18 am Eoghan Glynn wrote: >> 2009/5/5 Daniel Kulp : >> > OK. That kind of make sense (along with what Eoghan said). >> > >> > However, I really think there needs to at least be a "README" in the >> > distributions that describes a little what it is along with pointers to >> > the walkthroughs and such on the website. >> >> I've added a README with an overview of the different distros and >> pointers to getting started docco, mailing lists, JIRA etc: >> >> http://svn.apache.org/viewvc/cxf/dosgi/trunk/distribution/multi-bundle/src/ >>main/release/README?view=markup >> >> I've also addressed your other concerns in these two commits: >> >> http://svn.apache.org/viewvc?rev=772157&view=rev >> http://svn.apache.org/viewvc?rev=771670&view=rev >> >> So I think we should be good to go with a second cut at this release. >> >> Cheers, >> Eoghan >> >> 2009/5/5 Daniel Kulp : >> > OK. That kind of make sense (along with what Eoghan said). >> > >> > However, I really think there needs to at least be a "README" in the >> > distributions that describes a little what it is along with pointers to >> > the walkthroughs and such on the website. >> > >> > Right now, I download and unpack the the tarball and I look at it and say >> > "uhh. what do I do with this?" We definitely need a readme in >> > there to describe things as well as provide pointers off to the web site, >> > the users@ list for questions, etc. >> > >> > Dan >> > >> > On Tue May 5 2009 5:31:49 am David Bosschaert wrote: >> >> Hi Dan, >> >> >> >> On the samples, they are not part of the distribution because they can >> >> be installed straight from the internet. All of the DOSGi >> >> documentation is available here: >> >> http://cxf.apache.org/distributed-osgi.html and which contains links >> >> to the sample source code and a very detailed walkthrough of the >> >> greeter sample: >> >> http://cxf.apache.org/distributed-osgi-greeter-demo-walkthrough.html >> >> As the OSGi containers install stuff straight from the internet, you >> >> don't have to have the bundles available locally. Once the release is >> >> out I'm planning to update this page to point straight to the sample >> >> artefacts in maven. >> >> >> >> There is no such page for the spring-dm demo, I'll take an action to >> >> provide such a page with the DOSGi documentation, but I don't think >> >> this should hold up the release. >> >> >> >> Hope this makes sense to you, >> >> >> >> David >> >> >> >> 2009/5/4 Daniel Kulp : >> >> > I think I have to -1 this. Couple legal things need to get ironed >> >> > out: >> >> > >> >> > 1) Since this is a full "distribution" type thing, what parts of that >> >> > staging area will go into www.apache.org/dist/cxf? I ASSUME the >> >> > mutimodule bundle, but not really sure. Also, there needs to be a >> >> > tar.gz or zip of a "source" distribution of the whole contents of the >> >> > tag. That would also go into dist. >> >> > >> >> > 2) I think some stuff in the NOTICE can be removed. For example: >> >> > DOSGi doesn't ship the MTOSI stuff, that could be removed. Not >> >> > major, but if a build has to be respun, let's get that cleaned up. >> >> > >> >> > 3) For the "distribution" builds, the LICENSE file needs to have at >> >> > least the pointers to the LICENSES of the bundled deps appended to it. >> >> > See the LICENSE in the cxf distributions. (remote-resources can do >> >> > that, I may be able to help out tomorrow if I get out from under my >> >> > backlog of email. :-( ) >> >> > >> >> > 4) Actually, IS there a distribution that includes the samples, >> >> > possible a readme, etc...? Should there be? Not a big deal >> >> > either way, but a bit strange. >> >> > >> >> > >> >> > Dan >> >> > >> >> > On Fri May 1 2009 12:39:48 pm Eoghan Glynn wrote: >> >> >> Folks, >> >> >> >> >> >> I'm calling a vote to release CXF Distributed OSGi 1.0. >> >> >> >> >> >> The dOSGi subproject of CXF provides the Reference Implementation of >> >> >> the Distribution Software (DSW) component of the Distributed OSGi >> >> >> Specification[1]. >> >> >> >> >> >> The staging area can be found at: >> >> >> >> >> >> http://people.apache.org/~eglynn/stage_cxf_dosgi >> >> >> >> >> >> This release is tagged with cxf-dosgi-ri-1.0 at: >> >> >> >> >> >> http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.0 >> >> >> >> >> >> The vote will remain open for at least 72 hours. >> >> >> >> >> >> Please consider this call to vote as my +1. >> >> >> >> >> >> Cheers, >> >> >> Eoghan >> >> >> >> >> >> [1] See RFC 119 in >> >> >> http://www.osgi.org/download/osgi-4.2-early-draft3.pdf >> >> > >> >> > -- >> >> > Daniel Kulp >
Re: How to determine whether a soap message have an attachment
On Wed May 6 2009 9:15:54 am Willem Jiang wrote: > Hi > > I think MTOM message should have the attachment info, we could check > that for it. We have some trouble to send the MTOM message if we send > the message in Text model, and Liu Cong is working on the patch. Hmmthe message won't have the attachment info at "prepare" time. Whether to switch to mtom/mime or not is done later on, in the AttachmentOutInterceptor.The actual creation of the JMS message might need to be deferred until the first call to write on the cached output stream or something. At that point, the Content-Type should be set to the mime version and thus could be determined if it needs to be a binary message or not. Dan > > Willem > > Daniel Kulp wrote: > > Doesn't it already support MTOM? > > > > Basically, it provides a OutputSteam to the dispatching and if the > > runtime needs to handle attachments and such, it will write it as mime > > stuff to the stream. > > > > Dan > > > > On Tue May 5 2009 12:53:48 am liucong wrote: > >> Hi all, > >> > >> When I want to add MTOM support for SOAP/JMS, I should know whether a > >> soap message have an attachment. But I don't know the details how to > >> judge wheter the message have an attachment. > >> Is anyone give me any prompt about where the code is? Or some code > >> example? > >> > >> Thank you very much. > >> > >> Best regards > >> > >> Liu -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: How to determine whether a soap message have an attachment
Hi, It already supports MTOM. But there may be a bug for the MTOM. The current implementation send all the messages as TextMessage because jmsConfig variable in JMSConduit is not initialized according to the MessageType of SOAPMessage. So it is wrong when the message has an attachment. Sorry, I use the wrong word 'add MTOM support'. I just want to make the 'MTOM-support' work right. Yes, I have followed some codes. I think it use a OutputStream to generate the MTOM message. But before I send the message, I want to know whether it is a MTOM message, because I should set ByteMessage or TextMessage for JMS message depends on whether it is a MTOM message. So far, I can't find a way to finish this. Daniel Kulp 写道: > Doesn't it already support MTOM? > > Basically, it provides a OutputSteam to the dispatching and if the runtime > needs to handle attachments and such, it will write it as mime stuff to the > stream. > > Dan > > > > On Tue May 5 2009 12:53:48 am liucong wrote: > >> Hi all, >> >> When I want to add MTOM support for SOAP/JMS, I should know whether a >> soap message have an attachment. But I don't know the details how to >> judge wheter the message have an attachment. >> Is anyone give me any prompt about where the code is? Or some code example? >> >> Thank you very much. >> >> Best regards >> >> Liu >> > >
Re: Writing my own transport
Bharath,
Did you get this working?
Basically, the Conduit extends Observable and the client registers a
MessageObserver with the conduit via the setMessageObserver call. On the
incoming message, you would need to setup a Message and just call the
onMessage call of that observer.That should be it.
Basically, in code:
Message inMessage = new MessageImpl();
exchange.setInMessage(inMessage);
//set things like protocol headers and stuff here
inMessage.setContent(InputStream.class, is);
incomingObserver.onMessage(inMessage);
Dan
On Sat April 25 2009 2:09:44 am Bharath Gargesh wrote:
> Hi Dan and Ulhas,
>
> Thanks to you two, now I can publish messages to Local Transport and
> intercept them.
>
> Now I am able to intercept the messages in the MessageObservers of the
> LocalDestination and the LocalConduit.
>
> I work on a platform which provides Java API for IPC. The API allows
> transfer of bytes from one process to another.
> My plan is as follows:
>
> 1.) Publish a JAX-WS endpoint on a local Transport, Get the LocalConduit
> and register a MessageObserver in it. Wait for IPC messages here, when any
> message is got, convert this to SOAP message and send it to the Local
> JAX-WS Endpoint Impl, get the response and Reply back.
>
> 2.) Now the Client (JAX-WS Client). Get the LocalDestination (register a
> dummy local Endpoint here) and register the MessageObserver. Intercept the
> messages from the Client here and post the messages to the Step 1.) through
> IPC. I can get the response from the JAX-WS Service.
>
> But now I am stuck here. How do I reply the response to the caller/JAX-WS
> Client.
>
> Where should I look into (Interceptors and Phases ?). Kindly provide a
> brief outline of how do I acheive the above. Or simply put, How can I
> propagate the message from LocalDestination's MessageObserver back to the
> caller ?
>
> Kindly reply.
>
> Regards
> Bharath
>
> dkulp wrote:
> > Bharath,
> >
> > It's relatively simple.
> >
> > Service service = new Service(seviceName);
> > service.addPort(portName,
> > "http://schemas.xmlsoap.org/soap/";,
> > "local://localhost:9090/hello");
> > HelloInterface proxy = service.getPort(portName, HelloInterface.class);
> >
> > Basically, use the same URL as you did for the server side publish.
> >
> >
> > Dan
> >
> > On Fri April 24 2009 6:29:07 am Bharath Gargesh wrote:
> >> Hi Dan,
> >> I wanted to write my own transport, but then I saw your reply to this
> >> thread and found out a way to do this.
> >> But only that I was able to go half way through.
> >> On the Server side I did the following:
> >> 1.) Develop a JAX-WS and publish it to a local address.
> >> 2.) Got a handle to the LocalConduit through the Default Bus
> >> 3.) Registered a Listener to the Conduit.
> >> 4.) Prepare a SOAP Message for calling the JAX-WS, publish it
> >> to the Conduit.close() and the reply SOAP Message from the JAX-WS
> >> was got in the Listener.
> >>
> >> This is absolutely fine, the only thing that I need to do is, construct
> >> a SOAP Message to invoke the JAX-WS.
> >> But I want to use the JAX-WS Client generated to be able to publish the
> >> message to the Local transport.
> >> How can I force/use the JAX-WS client to put the message into the Local
> >> transport ?
> >>
> >> Can you please give me an Idea on how to do this for the JAX-WS client
> >> too.
> >>
> >> Regards
> >> Bharath
> >>
> >> dkulp wrote:
> >> > Marcel,
> >> >
> >> > You can actually use the Local transport for this as well. We have
> >> > several tests that do this exact thing.
> >> >
> >> > We have a TestUtilities class:
> >>
> >> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apac
> >>h
> >>
> >> >e/cxf/test/TestUtilities.java Look in the "invokeBytes" message which
> >> > could show you how to invoke a "local" service using raw data. The
> >> > invokeBytes takes a string message in and returns a byte[], but it
> >>
> >> would
> >>
> >> > be very easy to replace that with streams or a DOM or something
> >>
> >> similar.
> >>
> >> > Dan
> >> >
> >> > On May 26, 2008, at 8:09 AM, Heemskerk, Marcel (M.) wrote:
> >> >> Hello Dan and CXF,
> >> >>
> >> >> I've been looking in the documentation and still it's quite fuzy for
> >> >> me.
> >> >>
> >> >> What i need is the following:
> >> >>
> >> >> We work WSDL first, so i have to stick to a certain XML format. From
> >> >> this i generate an HTTP service implementation. It contains (for
> >> >> example) the following pojo:
> >>
> >>
> >>
> >> >>
> >> >> package com.sample;
> >> >> import javax.jws.WebService;
> >> >>
> >> >> @WebService(endpointInterface = "com.sample.WSInterface",
> >> >> targetNamespace = "http://com.sample/Calculator";)
> >> >> public class Calculator {
> >> >> public CalculatorResult calculate(CalculatorQuestion q) {
> >> >> return new CalculatorResult(q);
> >>
Re: How to determine whether a soap message have an attachment
Hi, If we defer the creation of JMS Message until we know the Content-Type for the client, we still need to flight with the miss configuration of MTOM with TextMessage on the server side. Current solution , I discussed with Liu Cong is if the MTOM is enabled, CXF JMS transport will check the configuration of the JMS message type, and make sure the JMS message type is BytesMessage, if not, the JMS transport will throw an Exception for it. Any thought? Willem Daniel Kulp wrote: > On Wed May 6 2009 9:15:54 am Willem Jiang wrote: >> Hi >> >> I think MTOM message should have the attachment info, we could check >> that for it. We have some trouble to send the MTOM message if we send >> the message in Text model, and Liu Cong is working on the patch. > > Hmmthe message won't have the attachment info at "prepare" time. > Whether to switch to mtom/mime or not is done later on, in the > AttachmentOutInterceptor.The actual creation of the JMS message might > need > to be deferred until the first call to write on the cached output stream or > something. At that point, the Content-Type should be set to the mime > version > and thus could be determined if it needs to be a binary message or not. > > Dan > > > >> Willem >> >> Daniel Kulp wrote: >>> Doesn't it already support MTOM? >>> >>> Basically, it provides a OutputSteam to the dispatching and if the >>> runtime needs to handle attachments and such, it will write it as mime >>> stuff to the stream. >>> >>> Dan >>> >>> On Tue May 5 2009 12:53:48 am liucong wrote: Hi all, When I want to add MTOM support for SOAP/JMS, I should know whether a soap message have an attachment. But I don't know the details how to judge wheter the message have an attachment. Is anyone give me any prompt about where the code is? Or some code example? Thank you very much. Best regards Liu >
Re: How to determine whether a soap message have an attachment
After digging the code, I found we could know if the Message has attachments by looking the message in the JMSConduit.sendExchange() method. We can tell if the message is MTOM enabled and has the attachement message, then we just make sure the JMS Message type is BytesMessage that should be OK. BTW, Freeman did some work to make the JMS transport support MTOM[1] [1] http://issues.apache.org/jira/browse/CXF-1760 Willem Willem Jiang wrote: > Hi, > > If we defer the creation of JMS Message until we know the Content-Type > for the client, we still need to flight with the miss configuration of > MTOM with TextMessage on the server side. > > Current solution , I discussed with Liu Cong is if the MTOM is enabled, > CXF JMS transport will check the configuration of the JMS message type, > and make sure the JMS message type is BytesMessage, if not, the JMS > transport will throw an Exception for it. > > Any thought? > > Willem > > Daniel Kulp wrote: >> On Wed May 6 2009 9:15:54 am Willem Jiang wrote: >>> Hi >>> >>> I think MTOM message should have the attachment info, we could check >>> that for it. We have some trouble to send the MTOM message if we send >>> the message in Text model, and Liu Cong is working on the patch. >> Hmmthe message won't have the attachment info at "prepare" time. >> Whether to switch to mtom/mime or not is done later on, in the >> AttachmentOutInterceptor.The actual creation of the JMS message might >> need >> to be deferred until the first call to write on the cached output stream or >> something. At that point, the Content-Type should be set to the mime >> version >> and thus could be determined if it needs to be a binary message or not. >> >> Dan >> >> >> >>> Willem >>> >>> Daniel Kulp wrote: Doesn't it already support MTOM? Basically, it provides a OutputSteam to the dispatching and if the runtime needs to handle attachments and such, it will write it as mime stuff to the stream. Dan On Tue May 5 2009 12:53:48 am liucong wrote: > Hi all, > > When I want to add MTOM support for SOAP/JMS, I should know whether a > soap message have an attachment. But I don't know the details how to > judge wheter the message have an attachment. > Is anyone give me any prompt about where the code is? Or some code > example? > > Thank you very much. > > Best regards > > Liu > >
Re: How to determine whether a soap message have an attachment
If the config doesn't appear in the WSDL of the service. The current implementation of JMS Transport will send MTOM message as TextMessage. So in current implementation, if one wants to use JMS MTOM-support, the config must be set, then the MTOM message will be sent as ByteMessage. Willem Jiang wrote: > After digging the code, I found we could know if the Message has > attachments by looking the message in the JMSConduit.sendExchange() > method. We can tell if the message is MTOM enabled and has the > attachement message, then we just make sure the JMS Message type is > BytesMessage that should be OK. > > BTW, Freeman did some work to make the JMS transport support MTOM[1] > > [1] http://issues.apache.org/jira/browse/CXF-1760 > > Willem > > Willem Jiang wrote: > >> Hi, >> >> If we defer the creation of JMS Message until we know the Content-Type >> for the client, we still need to flight with the miss configuration of >> MTOM with TextMessage on the server side. >> >> Current solution , I discussed with Liu Cong is if the MTOM is enabled, >> CXF JMS transport will check the configuration of the JMS message type, >> and make sure the JMS message type is BytesMessage, if not, the JMS >> transport will throw an Exception for it. >> >> Any thought? >> >> Willem >> >> Daniel Kulp wrote: >> >>> On Wed May 6 2009 9:15:54 am Willem Jiang wrote: >>> Hi I think MTOM message should have the attachment info, we could check that for it. We have some trouble to send the MTOM message if we send the message in Text model, and Liu Cong is working on the patch. >>> Hmmthe message won't have the attachment info at "prepare" time. >>> Whether to switch to mtom/mime or not is done later on, in the >>> AttachmentOutInterceptor.The actual creation of the JMS message might >>> need >>> to be deferred until the first call to write on the cached output stream or >>> something. At that point, the Content-Type should be set to the mime >>> version >>> and thus could be determined if it needs to be a binary message or not. >>> >>> Dan >>> >>> >>> >>> Willem Daniel Kulp wrote: > Doesn't it already support MTOM? > > Basically, it provides a OutputSteam to the dispatching and if the > runtime needs to handle attachments and such, it will write it as mime > stuff to the stream. > > Dan > > On Tue May 5 2009 12:53:48 am liucong wrote: > >> Hi all, >> >> When I want to add MTOM support for SOAP/JMS, I should know whether a >> soap message have an attachment. But I don't know the details how to >> judge wheter the message have an attachment. >> Is anyone give me any prompt about where the code is? Or some code >> example? >> >> Thank you very much. >> >> Best regards >> >> Liu >> >> > > >
Re: How to determine whether a soap message have an attachment
Yes, I confirmed that. Please feel free to add your comments and patch on the JIRA CXF-1760. We can add a check point in the JMSConduit.sendExchange() to show some warning or throw the exception if the user forget to add the messageType configuration. Willem liucong wrote: > If the config doesn't appear in the > WSDL of the service. The current implementation of JMS Transport will > send MTOM message as TextMessage. So in current implementation, if one > wants to use JMS MTOM-support, the config messageType="byte"/> must be set, then the MTOM message will be sent as > ByteMessage. > > Willem Jiang wrote: >> After digging the code, I found we could know if the Message has >> attachments by looking the message in the JMSConduit.sendExchange() >> method. We can tell if the message is MTOM enabled and has the >> attachement message, then we just make sure the JMS Message type is >> BytesMessage that should be OK. >> >> BTW, Freeman did some work to make the JMS transport support MTOM[1] >> >> [1] http://issues.apache.org/jira/browse/CXF-1760 >> >> Willem >> >> Willem Jiang wrote: >> >>> Hi, >>> >>> If we defer the creation of JMS Message until we know the Content-Type >>> for the client, we still need to flight with the miss configuration of >>> MTOM with TextMessage on the server side. >>> >>> Current solution , I discussed with Liu Cong is if the MTOM is enabled, >>> CXF JMS transport will check the configuration of the JMS message type, >>> and make sure the JMS message type is BytesMessage, if not, the JMS >>> transport will throw an Exception for it. >>> >>> Any thought? >>> >>> Willem >>> >>> Daniel Kulp wrote: >>> On Wed May 6 2009 9:15:54 am Willem Jiang wrote: > Hi > > I think MTOM message should have the attachment info, we could check > that for it. We have some trouble to send the MTOM message if we send > the message in Text model, and Liu Cong is working on the patch. > Hmmthe message won't have the attachment info at "prepare" time. Whether to switch to mtom/mime or not is done later on, in the AttachmentOutInterceptor.The actual creation of the JMS message might need to be deferred until the first call to write on the cached output stream or something. At that point, the Content-Type should be set to the mime version and thus could be determined if it needs to be a binary message or not. Dan > Willem > > Daniel Kulp wrote: > >> Doesn't it already support MTOM? >> >> Basically, it provides a OutputSteam to the dispatching and if the >> runtime needs to handle attachments and such, it will write it as mime >> stuff to the stream. >> >> Dan >> >> On Tue May 5 2009 12:53:48 am liucong wrote: >> >>> Hi all, >>> >>> When I want to add MTOM support for SOAP/JMS, I should know whether a >>> soap message have an attachment. But I don't know the details how to >>> judge wheter the message have an attachment. >>> Is anyone give me any prompt about where the code is? Or some code >>> example? >>> >>> Thank you very much. >>> >>> Best regards >>> >>> Liu >>> >>> >> >> > >
