Re: SOAP/TCP project status...

[Daniel Kulp]

On Sat July 4 2009 4:31:32 pm Krzysztof Wilkos wrote:
> 2009/7/3 Krzysztof Wilkos :
> > Finally I've got working client. Sun's pdf it's not enought so I ended
> > with sniffing .Net communication. Tomorrow I'll clean up some code and
> > submit patch.

Your comment actually got me looking at the pdf.   You're right.  Definitely 
some stuff missing there.

> https://issues.apache.org/jira/browse/CXF-2257
>
> I'm submiting a patch that adds soap over tcp client support. It still
> needs more error handling end more tests but seems to work. I've
> tested this with .Net service which is in SoapTcp.zip package. There
> is also .Net client which I used as a reference as Sun's pdf was not
> enough. Wireshark can't sniff over looback interface on Windows so I
> used CommView trial, than save log as .cap and decode in wireshark.

The patch is definitely a good start, but definitely needs some work before we 
get it integrated into the builds.   Apart from the legal issue you mentioned 
off list, there's a bunch of formatting things, header things, maven poms, 
etc... that we need to tackle.  The XPP dep also is an issue.  You probably 
should just be able to call our StaxUtils.createXmlStreamReader to get a 
standard StAX stream reader to accomplish that. 

Once we get that cleaned up a bit, I'd definitely like to get it into trunk 
where it will be easier to collaborate on it and review things a bit better.   
With the framing stuff in place, we should be able to start extending it for 
the more advanced things (like the FastInfoSet optimizations).


-- 
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog

Re: An Exception occurs when use wsdl extension in the port

[liucong]

Hi Dan,

Thank you for your good advice. I think keeping the "soap" stuff in the
soap binding is a very good idea.
https://issues.apache.org/jira/browse/CXF-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12727756#action_12727756


liu

Daniel Kulp wrote:
> A test case (attached to a JIRA) would be good if you cannot figure this out.
>
> However, here is a pointer:
> When CXF looks in the WSDL to determine the transport factory, it looks at 
> the 
> FIRST extensor on the port that has a namespace that matches a transport 
> factory.  In your first example, it would be "soap" and thus would match the 
> "soap" transport.
>
> In the second, it would be "soapjms" and thus probably matches the JMS 
> transport and not the soap transport.   The jms transport probably doesn't 
> look for "soap:address".
>
> Not sure on the best course of action to solve this.   :-( Possibly the 
> soap binding could reset the address on the transport or something.   Would 
> be 
> good to check if this is the case before diving in too deep.  
>
> Dan
>
>
>
>
>
> On Sat July 4 2009 7:51:40 am liucong wrote:
>   
>> Hi all,
>> When I implement the WSDL usage for SOAP/JMS, I encountered an exception.
>> I create an service and invoke it using wsdl-first.
>>
>> If the wsdl file looks like this[1] :
>> 
>> 
>> 
>> > location="jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialCon
>> textFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory&jndiC
>> onnectionFactoryName=ConnectionFactory&jndiURL=tcp://localhost:61616&
>> ;targetService=greeterService" />
>> 1000
>> 
>> 
>> 
>>
>> This service works well.
>>
>> But if the wsdl file looks like this[2] :
>> 
>> 
>> 
>> 1000
>> > location="jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialCon
>> textFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory&jndiC
>> onnectionFactoryName=ConnectionFactory&jndiURL=tcp://localhost:61616&
>> ;targetService=greeterService" />
>> 
>> 
>> 
>>
>> The service is created correctly, but there is an error happen when I
>> invoke this service.
>> By debugging, I find that JMSTransportFactory.getConduit(EndpointInfo
>> endpointInfo, EndpointReferenceType target)'s target parameter is null.
>> It should be
>> "jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialContextFacto
>> ry=org.apache.activemq.jndi.ActiveMQInitialContextFactory&jndiConnection
>> FactoryName=ConnectionFactory&jndiURL=tcp://localhost:61616&targetSe
>> rvice=greeterService".
>>
>> I think there are someting wrong with port parsing in wsdl.
>> Any ideas?
>>
>> best regards
>> liu
>> 
>
>   

Re: Nonce at Server Side

[rahul.soa]

Many Thanks Colm for the updated information about Nonce. Perhaps, in near
future I might have some questions regarding this as I am working on
configuring ws-security in geronimo.

Thanks again.
Rahul

On Mon, Jul 6, 2009 at 4:23 PM, Colm O hEigeartaigh
wrote:

>
> It's supported in so far as it'll get processed correctly to create the
> nonce+created+password digest. But nonce-caching for replay detection
> isn't supported as of yet...there's a jira open in WSS4J for it.
>
> Feel free to submit a patch :-)
>
> https://issues.apache.org/jira/browse/WSS-187
>
> Colm.
>
> -Original Message-
> From: rahul.soa [mailto:rahul@googlemail.com]
> Sent: 06 July 2009 11:56
> To: dev@cxf.apache.org
> Cc: Jarek Gawor
> Subject: Nonce at Server Side
>
> Hello CXF Devs,
>
> Does CXF have the support for processing nonce at *server* side?
>
> As I understand from some posts CXF creates the nonce automatically when
> password digest is used at client side.
>
> If it does not have support yet at server side so does that mean we
> cannot
> use "password digest" at server side as combination of timestamp,
> *nonce*
> and password text are used to calculate the password digest. May be I
> read
> some old post or I am wrong. Kindly correct me.
>
> Thanks in advance.
>
> Best Regards,
> Rahul
>

Re: Schema generation issues

[Sergey Beryozkin]

Hi Dan

thanks... I'm looking now at JAXBDatabinding's JAXBBeanInfo which looks like exactly what I need - I'm thinking of moving 
JAXBBeanInfo and JAXBContextProxy into common/utils/jaxb as at the moment it's not quite feasible to reuse JAXBDataBinding as is 
from JAX-RS due to different models. I'll be revisiting it once/if we do some WSDL2 generation


cheers, Sergey



Sergey,

On Thu July 2 2009 12:59:10 pm Sergey Beryozkin wrote:

I have problems with the JAXB schema generation.

Consider this bean :

@XmlRootElement(name="thebook", namespace="http://books";)
public class Book {
  private int id;
  public Book() { }
  public int getId() { return id; }
  public void setId(int ident) { id = ident; }
}



I think you should just add an
@XmlType(name = "book", namespace="http://books";)
Attribute to it as well.The XmlRootElement defines a root element, but
doesn't do anything to specify how the type is mapped in.The XmlType
annotation does that.

Dan





JAXBContext generates these 2 schemas :


http://www.w3.org/2001/XMLSchema"; version="1.0"
targetNamespace="http://books";> 




http://www.w3.org/2001/XMLSchema"; version="1.0">







The first problem I guess is to check if  in the first schema has
no 'namespace' attribute in which case I can have 'book' complex type
injected directly into the first schema. with the whole  being
removed. It can get quiote hairy if 'book' type improts some other types,
but it can be handled.

What I'm sure about is how to figure out that when we have say a method

public Resource() {
   public Book getBook() {}
}

then how to ensure that Book is represented by {http://books}thebook
qualified name in the generated doc such as wadl...

it's not obvious to me how a link between Book and 'thebook' element can be
established given that this info (in XmlRootElement at the moment) may come
from various sources

thanks, Sergey


--
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog 

Re: Schema generation issues

[Daniel Kulp]

Sergey,

On Thu July 2 2009 12:59:10 pm Sergey Beryozkin wrote:
> I have problems with the JAXB schema generation.
>
> Consider this bean :
>
> @XmlRootElement(name="thebook", namespace="http://books";)
> public class Book {
>   private int id;
>   public Book() { }
>   public int getId() { return id; }
>   public void setId(int ident) { id = ident; }
> }
>

I think you should just add an 
@XmlType(name = "book", namespace="http://books";)
Attribute to it as well.The XmlRootElement defines a root element, but 
doesn't do anything to specify how the type is mapped in.The XmlType 
annotation does that.

Dan




> JAXBContext generates these 2 schemas :
>
> 
> http://www.w3.org/2001/XMLSchema"; version="1.0"
> targetNamespace="http://books";> 
> 
> 
>
> 
> http://www.w3.org/2001/XMLSchema"; version="1.0">
> 
> 
> 
> 
> 
> 
>
> The first problem I guess is to check if  in the first schema has
> no 'namespace' attribute in which case I can have 'book' complex type
> injected directly into the first schema. with the whole  being
> removed. It can get quiote hairy if 'book' type improts some other types,
> but it can be handled.
>
> What I'm sure about is how to figure out that when we have say a method
>
> public Resource() {
>public Book getBook() {}
> }
>
> then how to ensure that Book is represented by {http://books}thebook
> qualified name in the generated doc such as wadl...
>
> it's not obvious to me how a link between Book and 'thebook' element can be
> established given that this info (in XmlRootElement at the moment) may come
> from various sources
>
> thanks, Sergey

-- 
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog

Re: An Exception occurs when use wsdl extension in the port

[liucong]

Thank you, Dan.

I just found the problem as you said.
I can make the JMSTransportFactory implement WSDLEndpointFactory
interface. And then the SOAPAddress can be used to create
createEndpointInfo. Then the problem will be solved. I'm trying to do this.

liu

Daniel Kulp wrote:
> A test case (attached to a JIRA) would be good if you cannot figure this out.
>
> However, here is a pointer:
> When CXF looks in the WSDL to determine the transport factory, it looks at 
> the 
> FIRST extensor on the port that has a namespace that matches a transport 
> factory.  In your first example, it would be "soap" and thus would match the 
> "soap" transport.
>
> In the second, it would be "soapjms" and thus probably matches the JMS 
> transport and not the soap transport.   The jms transport probably doesn't 
> look for "soap:address".
>
> Not sure on the best course of action to solve this.   :-( Possibly the 
> soap binding could reset the address on the transport or something.   Would 
> be 
> good to check if this is the case before diving in too deep.  
>
> Dan
>
>
>
>
>
> On Sat July 4 2009 7:51:40 am liucong wrote:
>   
>> Hi all,
>> When I implement the WSDL usage for SOAP/JMS, I encountered an exception.
>> I create an service and invoke it using wsdl-first.
>>
>> If the wsdl file looks like this[1] :
>> 
>> 
>> 
>> > location="jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialCon
>> textFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory&jndiC
>> onnectionFactoryName=ConnectionFactory&jndiURL=tcp://localhost:61616&
>> ;targetService=greeterService" />
>> 1000
>> 
>> 
>> 
>>
>> This service works well.
>>
>> But if the wsdl file looks like this[2] :
>> 
>> 
>> 
>> 1000
>> > location="jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialCon
>> textFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory&jndiC
>> onnectionFactoryName=ConnectionFactory&jndiURL=tcp://localhost:61616&
>> ;targetService=greeterService" />
>> 
>> 
>> 
>>
>> The service is created correctly, but there is an error happen when I
>> invoke this service.
>> By debugging, I find that JMSTransportFactory.getConduit(EndpointInfo
>> endpointInfo, EndpointReferenceType target)'s target parameter is null.
>> It should be
>> "jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialContextFacto
>> ry=org.apache.activemq.jndi.ActiveMQInitialContextFactory&jndiConnection
>> FactoryName=ConnectionFactory&jndiURL=tcp://localhost:61616&targetSe
>> rvice=greeterService".
>>
>> I think there are someting wrong with port parsing in wsdl.
>> Any ideas?
>>
>> best regards
>> liu
>> 
>
>   

Re: Properties Overriding in WSDL usage

[Daniel Kulp]

On Mon July 6 2009 3:02:00 am Willem Jiang wrote:
> Hi,
>
> I think this is a bug of CXF, if the user define the extension in the
> service and binding,
>  we should use the service's value.

Agreed.   Good catch.

Dan


>
> Willem
>
> liucong wrote:
> > Hi all,
> >
> > In the
> > SOAP/JMS(http://www.w3.org/TR/2008/WD-soapjms-20081121/#wsdl-11-propertie
> >s). If a property is specified at multiple levels, the most specific
> > setting will take precedence (port first, then service, then binding).
> >
> > But I invetigate the code of CXF. I find someting int
> > org.apache.cxf.service.model.EndpointInfo.getTraversedExtensor(T
> > defaultValue, Class type):
> > @Override
> > public  T getTraversedExtensor(T defaultValue, Class type) {
> > T value = getExtensor(type);
> >
> > if (value == null) {
> > if (value == null && binding != null) {
> > value = binding.getExtensor(type);
> > }
> >
> > if (service != null && value == null) {
> > value = service.getExtensor(type);
> > }
> >
> > if (value == null) {
> > value = defaultValue;
> > }
> > }
> >
> > return value;
> > }
> >
> > The code shou that:port first, then binding, then service.
> >
> > Now. Which is right?
> >
> > thanks.

-- 
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog

Re: An Exception occurs when use wsdl extension in the port

[Daniel Kulp]

A test case (attached to a JIRA) would be good if you cannot figure this out.

However, here is a pointer:
When CXF looks in the WSDL to determine the transport factory, it looks at the 
FIRST extensor on the port that has a namespace that matches a transport 
factory.  In your first example, it would be "soap" and thus would match the 
"soap" transport.

In the second, it would be "soapjms" and thus probably matches the JMS 
transport and not the soap transport.   The jms transport probably doesn't 
look for "soap:address".

Not sure on the best course of action to solve this.   :-( Possibly the 
soap binding could reset the address on the transport or something.   Would be 
good to check if this is the case before diving in too deep.  

Dan





On Sat July 4 2009 7:51:40 am liucong wrote:
> Hi all,
> When I implement the WSDL usage for SOAP/JMS, I encountered an exception.
> I create an service and invoke it using wsdl-first.
>
> If the wsdl file looks like this[1] :
> 
> 
> 
>  location="jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialCon
>textFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory&jndiC
>onnectionFactoryName=ConnectionFactory&jndiURL=tcp://localhost:61616&
>;targetService=greeterService" />
> 1000
> 
> 
> 
>
> This service works well.
>
> But if the wsdl file looks like this[2] :
> 
> 
> 
> 1000
>  location="jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialCon
>textFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory&jndiC
>onnectionFactoryName=ConnectionFactory&jndiURL=tcp://localhost:61616&
>;targetService=greeterService" />
> 
> 
> 
>
> The service is created correctly, but there is an error happen when I
> invoke this service.
> By debugging, I find that JMSTransportFactory.getConduit(EndpointInfo
> endpointInfo, EndpointReferenceType target)'s target parameter is null.
> It should be
> "jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialContextFacto
>ry=org.apache.activemq.jndi.ActiveMQInitialContextFactory&jndiConnection
>FactoryName=ConnectionFactory&jndiURL=tcp://localhost:61616&targetSe
>rvice=greeterService".
>
> I think there are someting wrong with port parsing in wsdl.
> Any ideas?
>
> best regards
> liu

-- 
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog

RE: Nonce at Server Side

[Colm O hEigeartaigh]

It's supported in so far as it'll get processed correctly to create the
nonce+created+password digest. But nonce-caching for replay detection
isn't supported as of yet...there's a jira open in WSS4J for it. 

Feel free to submit a patch :-)

https://issues.apache.org/jira/browse/WSS-187

Colm.

-Original Message-
From: rahul.soa [mailto:rahul@googlemail.com] 
Sent: 06 July 2009 11:56
To: dev@cxf.apache.org
Cc: Jarek Gawor
Subject: Nonce at Server Side

Hello CXF Devs,

Does CXF have the support for processing nonce at *server* side?

As I understand from some posts CXF creates the nonce automatically when
password digest is used at client side.

If it does not have support yet at server side so does that mean we
cannot
use "password digest" at server side as combination of timestamp,
*nonce*
and password text are used to calculate the password digest. May be I
read
some old post or I am wrong. Kindly correct me.

Thanks in advance.

Best Regards,
Rahul

Re: How to add wsdl extension for SOAP/JMS.

[Daniel Kulp]

Liu,

I just want to say this is very nice work.   Thanks for tackling this.   It 
almost makes  me want to go through the rest of the wsdl extension schemas and 
make them not subclass the old TExensibilityElementImpl thing.   Would 
simplify that stuff quite a bit.  

Again, nice job.

Dan


On Fri July 3 2009 9:10:04 am liucong wrote:
> Hi,
> I am writing a plugin for xjc.
> First I just modify the cxf-xjc-ts and cxf-xjc-ts-test, and make it
> work with the -Xwsdlextension, not -Xts. The pom file is also changed.
> And it works rightly.
> Then I copy the modified projects into cxf-xjc-wsdlextension and
> cxf-xjc-wsdlextension-test, and make the cxf-xjc-ts the same with the
> subversion.
> It failed. The exception is:
> [INFO]
> 
> [INFO] Building Apache CXF XJC WSDL Extension Plugin Tests
> [INFO]task-segment: [install]
> [INFO]
> 
> [INFO] [cxf-xml2fastinfoset:xml2fastinfoset {execution: xml2fastinfoset}]
> [INFO] [jaxb2:xjc {execution: default}]
> [INFO] Generating source...
> [INFO]
> 
> [ERROR] BUILD ERROR
> [INFO]
> 
> [INFO] unrecognized parameter -Xwsdlextension
>
> What's wrong? Do I need to do more configuration for ths xjc plugin?
>
> thanks!
>
> Daniel Kulp wrote:
> > Liu,
> >
> > I think for stuff that are "simple" (basically, complexTypes with
> > simpleContent and simpleType object), you cannot extend
> > TExtensibilityElementImpl.   Instead, you would need to make it implement
> > ExtensibilityElement interface and add the QName and required fields and
> > such.
> >
> > Dan
> >
> > On Wed July 1 2009 12:18:15 pm liucong wrote:
> >> Hi,
> >>
> >> I do a simple experiment about the design sugguest by Dan.
> >> First, I use jaxb, not xjc. I think they have the principle.
> >>
> >> The schema like this[1]:
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >>
> >> The generated class for DeliveryModeType like this[2]:
> >> @XmlAccessorType(XmlAccessType.FIELD)
> >> @XmlType(name = "deliveryModeType", propOrder = {
> >> "value"
> >> })
> >> public class DeliveryModeType{
> >>
> >> @XmlValue
> >> protected String value;
> >>
> >> /**
> >>  * Gets the value of the value property.
> >>  *
> >>  * @return
> >>  * possible object is
> >>  * {...@link String }
> >>  *
> >>  */
> >> public String getValue() {
> >> return value;
> >> }
> >>
> >> /**
> >>  * Sets the value of the value property.
> >>  *
> >>  * @param value
> >>  * allowed object is
> >>  * {...@link String }
> >>  *
> >>  */
> >> public void setValue(String value) {
> >> this.value = value;
> >> }
> >>
> >> public boolean isSetValue() {
> >> return (this.value!= null);
> >> }
> >> }
> >>
> >> The DeliveryModeType doesn't extend TExtensibilityElementImpl. So I just
> >> modify the class and make it look like this[3]:
> >> @XmlAccessorType(XmlAccessType.FIELD)
> >> @XmlType(name = "deliveryModeType", propOrder = {
> >> "value"
> >> })
> >> public class DeliveryModeType extends TExtensibilityElementImpl{
> >>
> >> @XmlValue
> >> protected String value;
> >>
> >> /**
> >>  * Gets the value of the value property.
> >>  *
> >>  * @return
> >>  * possible object is
> >>  * {...@link String }
> >>  *
> >>  */
> >> public String getValue() {
> >> return value;
> >> }
> >>
> >> /**
> >>  * Sets the value of the value property.
> >>  *
> >>  * @param value
> >>  * allowed object is
> >>  * {...@link String }
> >>  *
> >>  */
> >> public void setValue(String value) {
> >> this.value = value;
> >> }
> >>
> >> public boolean isSetValue() {
> >> return (this.value!= null);
> >> }
> >> }
> >>
> >> Then when I publish a service, I get an exception[4]
> >> Creating Service {http://cxf.apache.org/jms_greeter}JMSGreeterService
> >> from WSDL: file:./wsdl/jms_greeter.wsdl
> >> Exception in thread "main" javax.xml.ws.WebServiceException:
> >> org.apache.cxf.service.factory.ServiceConstructionException: Failed to
> >> create service.
> >> at
> >> org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:275) at
> >> org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:209) at
> >> org.apache.cxf.jaxws.spi.ProviderImpl.createAndPublishEndpoint(ProviderI
> >>mpl .java:84) at javax.xml.ws.Endpoint.publish(Endpoint.java:47)
> >> at demo.jms_greeter.server.Server.(Server.java:30)
> >> at demo.jms_greeter.server.Server.main(Server.java:34)
> >> Caused by: org.apache.cxf.service.factory.ServiceCo

Nonce at Server Side

[rahul.soa]

Hello CXF Devs,

Does CXF have the support for processing nonce at *server* side?

As I understand from some posts CXF creates the nonce automatically when
password digest is used at client side.

If it does not have support yet at server side so does that mean we cannot
use "password digest" at server side as combination of timestamp, *nonce*
and password text are used to calculate the password digest. May be I read
some old post or I am wrong. Kindly correct me.

Thanks in advance.

Best Regards,
Rahul

Re: Supprot for wrapped/unwrapped styles in Mapped convention for JSON

[Sergey Beryozkin]

In fact, I can probably update JSON provider to do it. If it is set to
operate in 'unwrapped' mode then it will append a class name to the stream,
will do it shortly

cheers, Sergey


Sergey Beryozkin wrote:
> 
> Hi
> 
> I'm not sure yet - it appears JSONProvider may need to be updated to
> handle unwrapped cases.
> Does anyone know, is it already possible to do somehow in CXF ?
> 
> Perhaps one workaround is to register a RequestFilter which will replace
> an InputStream on the inbound message with another stream which will
> present
> 
> {"name":"abc"}
> 
> as
> 
> {"employee":{"name":"abc"}}
> 
> for small streams (JSON ones are probably all quite small) this should
> work quite well. what do you think ?
> 
> cheers, Sergey
> 
> 
> 
> Chaitanya-10 wrote:
>> 
>> Hi, 
>> 
>> I have a JAX-RS method which takes an Employee object as a param.
>> Employee class is given below.
>> 
>> @XmlRootElement
>> public class Employee {
>> private String name;
>> 
>> public String getName() {
>> return name;
>> }
>> 
>> public void setName(String name) {
>> this.name = name;
>> }
>> }
>> 
>> Unmarshalling of the JSON
>> 
>> {"employee":{"name":"abc"}}
>> 
>> works fine and gives an Employee object, but if the JSON input is
>> 
>> {"name":"abc"} 
>> 
>> unmarshalling fails.
>> 
>> Does CXF support both wrapped and unwrapped styles in Mapped convention
>> for JSON?
>> If yes what should be done to make the second case work?
>> 
>> Thank you
>> Chaithanya.
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Supprot-for-wrapped-unwrapped-styles-in-Mapped-convention-for-JSON-tp24319534p24353228.html
Sent from the cxf-dev mailing list archive at Nabble.com.

Re: Supprot for wrapped/unwrapped styles in Mapped convention for JSON

[Sergey Beryozkin]

Hi

I'm not sure yet - it appears JSONProvider may need to be updated to handle
unwrapped cases.
Does anyone know, is it already possible to do somehow in CXF ?

Perhaps one workaround is to register a RequestFilter which will replace an
InputStream on the inbound message with another stream which will present

{"name":"abc"}

as

{"employee":{"name":"abc"}}

for small streams (JSON ones are probably all quite small) this should work
quite well. what do you think ?

cheers, Sergey



Chaitanya-10 wrote:
> 
> Hi, 
> 
> I have a JAX-RS method which takes an Employee object as a param. Employee
> class is given below.
> 
> @XmlRootElement
> public class Employee {
> private String name;
> 
> public String getName() {
> return name;
> }
> 
> public void setName(String name) {
> this.name = name;
> }
> }
> 
> Unmarshalling of the JSON
> 
> {"employee":{"name":"abc"}}
> 
> works fine and gives an Employee object, but if the JSON input is
> 
> {"name":"abc"} 
> 
> unmarshalling fails.
> 
> Does CXF support both wrapped and unwrapped styles in Mapped convention
> for JSON?
> If yes what should be done to make the second case work?
> 
> Thank you
> Chaithanya.
> 

-- 
View this message in context: 
http://www.nabble.com/Supprot-for-wrapped-unwrapped-styles-in-Mapped-convention-for-JSON-tp24319534p24353159.html
Sent from the cxf-dev mailing list archive at Nabble.com.

Re: An Exception occurs when use wsdl extension in the port

[Willem Jiang]

Hi,

Can you submit a test case for it ?
BTW, is there anything wrong with creating the server from this WSDL ?

Willem

liucong wrote:
> Hi all,
> When I implement the WSDL usage for SOAP/JMS, I encountered an exception.
> I create an service and invoke it using wsdl-first.
> 
> If the wsdl file looks like this[1] :
> 
> 
> 
>  location="jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialContextFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory&jndiConnectionFactoryName=ConnectionFactory&jndiURL=tcp://localhost:61616&targetService=greeterService"
> />
> 1000
> 
> 
> 
> 
> This service works well.
> 
> But if the wsdl file looks like this[2] :
> 
> 
> 
> 1000
>  location="jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialContextFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory&jndiConnectionFactoryName=ConnectionFactory&jndiURL=tcp://localhost:61616&targetService=greeterService"
> />
> 
> 
> 
> 
> The service is created correctly, but there is an error happen when I
> invoke this service.
> By debugging, I find that JMSTransportFactory.getConduit(EndpointInfo
> endpointInfo, EndpointReferenceType target)'s target parameter is null.
> It should be
> "jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialContextFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory&jndiConnectionFactoryName=ConnectionFactory&jndiURL=tcp://localhost:61616&targetService=greeterService".
> 
> I think there are someting wrong with port parsing in wsdl.
> Any ideas?
> 
> best regards
> liu
> 

Re: Properties Overriding in WSDL usage

[Willem Jiang]

Hi,

I think this is a bug of CXF, if the user define the extension in the
service and binding,
 we should use the service's value.

Willem

liucong wrote:
> Hi all,
> 
> In the
> SOAP/JMS(http://www.w3.org/TR/2008/WD-soapjms-20081121/#wsdl-11-properties).
> If a property is specified at multiple levels, the most specific setting
> will take precedence (port first, then service, then binding).
> 
> But I invetigate the code of CXF. I find someting int
> org.apache.cxf.service.model.EndpointInfo.getTraversedExtensor(T
> defaultValue, Class type):
> @Override
> public  T getTraversedExtensor(T defaultValue, Class type) {
> T value = getExtensor(type);
> 
> if (value == null) {
> if (value == null && binding != null) {
> value = binding.getExtensor(type);
> }
> 
> if (service != null && value == null) {
> value = service.getExtensor(type);
> }
> 
> if (value == null) {
> value = defaultValue;
> }
> }
> 
> return value;
> }
> 
> The code shou that:port first, then binding, then service.
> 
> Now. Which is right?
> 
> thanks.
>