Re: Integrating JAX-RS runtime into DOSGi
I'm not sure how the cxf-rt-frontend-jaxrs dependency should be handled. The work I've done so far [1] will tie the DSW software to the JAX-RS implementation. Since cxf-rt-frontend-jaxrs isn't an osgi bundle, I'd have to embed the jar within DSW to satisfy the dependency. This doesn't seem like a good idea to me. Any suggestions? Thanks, Josh [1] http://codereview.appspot.com/71041 On Wed, Jun 10, 2009 at 5:18 AM, David Bosschaert < david.bosscha...@gmail.com> wrote: > > I've just updated a cxf-minimal bundle to include a jaxrs frontend and I > > updated the cxf.version in dosgi/parent to 2.3.0-SNAPHOT > > > > (David, Eoghan - we can downgrade it easily to 2.2.2 fixes tag if DOSGi > will > > need to be released sooner than 2.3 does which is in about 3 months or so > I > > believe, with fixes branch likely be easiler tp release earlier). > > Yeah - going to 2.2.2.fixes might be good. I expect that a DOSGi > release will be done earlier than in 3 months, especially since the > property names that are used will change in the real OSGi spec, which > is currently being finalized. > I am planning to update the properties in the DOSGi implementation to > reflect the latest in the spec draft either later this week or early > next week. > > BTW we now also have Discovery in CXF/DOSGi, so it would be nice to > include that in a release fairly soon too. > > Thanks, > > David >
hudson failures
test failures are because the test 'fails to fail' in the default profile which lacks the necessary wstx version. I will deal when I get home from 5th grade concert.
Re: Invalid soap messagein web service request
On Wed June 10 2009 12:57:52 pm Naresh Tallapelli wrote: > Thanks Daniel.I am not using any of the external parsers for web services. > Could you please let me know any configuration in cxf change the parser > from woodstox to sun. And iam using cxf for last one year. I did not face > this problem earlier. I am seeing this error from last one week. Could you > please let me know what is the problem. The simple explanation is that the Sun version of the stax XMLOutputFactory is not thread safe. If two threads try to create an XMLOutputStream at the same time, it's possible that they end up with the exact same stream object and you end up with the interleaved soap message that you see.The woodstox version IS thread safe and thus doesn't exhibit the problem. In 2.2.2, we sync on the factory to make sure only one thread calls it at a time. Kind of sucky, but it works. For the most part, to change to woodstox, just put the woodstox jar on the classpath.That should make it automatic. You may just be hitting it now if your load got high enough that two threads are contending more often. Dan > > Thank you, > Naresh > > On Tue, Jun 9, 2009 at 9:52 PM, Daniel Kulp wrote: > > I BELIEVE this is due to using the Sun's StAX parser. Two options to > > fix this: > > > > 1) Make sure you pickup woodstox instead of the sun parser. > > > > 2) Upgrade to CXF 2.2.2 which works around this issue. > > > > Dan > > > > On Tue June 9 2009 8:19:06 am Naresh Tallapelli wrote: > > > Hi All, > > > > > > I am Naresh. Iam usig cxf-2.1.2 version. I was able to execute my web > > > service successfully. But sometimes, when web service client tries to > > > > send > > > > > message to web service server, the soap message was in the following > > > form > > > > > > > > > s > > > > > :xEmnlvnesl:oSp=e" http://sc > > > > > > hxemmlanss.:xSm=l"soap.orhgt/tspo:a/p//secnhveemlaosp.ex/m"l>s< > > > oap.org/soS:Body> > > > > > > The soap message was repeated itself. And this was not reproducible > > > everytime. So could any one please help me to resolve this issue. Why > > > the SOAP message is rendered like that and what is fix for it. > > > > > > Any help is much appreciated. > > > > > > Thank you, > > > Naresh. > > > > -- > > Daniel Kulp > > dk...@apache.org > > http://www.dankulp.com/blog -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: SOAP/JMS specification for CXF [Project Status]
Excellent work.It would probably be a good idea to start getting some of this integrated into CXF itself. Now that a fixes branch for 2.2 has been created and trunk is targeting 2.3, we definitely should start committing some patches for this. Dan On Wed June 10 2009 4:04:22 am liucong wrote: > Hi all, > > Project Description: > SOAP over JMS specification (http://www.w3.org/TR/soapjms/) is aimed at > a set of standards for the transport of SOAP messages over JMS (Java > Message Service). The main purpose is to ensure interoperability between > the implementations of different Web services vendors. > CXF does support SOAP over JMS, but it does not meet the current draft > specification defined at http://www.w3.org/TR/soapjms/ and instead uses > some proprietary formats, headers, URL formats, etc. This project would > update the SOAP/JMS support in CXF to be completely specification > compliant. > Any advice or help are welcome! > > Project Information: > 1.Project Status: http://wiki.apache.org/general/soapjms4cxf > 2.Project Code: http://github.com/liucong/jms4cxf2/tree/master > 3.Project JIRA task: https://issues.apache.org/jira/browse/CXF-2253 > > What I have done: > 1.Implement a simple JMS URI > (http://tools.ietf.org/html/draft-merrick-jms-uri-05 ) > 2.Integrate the JMS URI into current jms-transport. It is compatible > with the specification. > 3.Modify the JMS Header Properties and JMS Properties and make it > compatible with the specification. > 4.Modify some code about SOAP fault and MEPs. > > Liu -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Invalid soap messagein web service request
Thanks Daniel.I am not using any of the external parsers for web services. Could you please let me know any configuration in cxf change the parser from woodstox to sun. And iam using cxf for last one year. I did not face this problem earlier. I am seeing this error from last one week. Could you please let me know what is the problem. Thank you, Naresh On Tue, Jun 9, 2009 at 9:52 PM, Daniel Kulp wrote: > > I BELIEVE this is due to using the Sun's StAX parser. Two options to fix > this: > > 1) Make sure you pickup woodstox instead of the sun parser. > > 2) Upgrade to CXF 2.2.2 which works around this issue. > > Dan > > > On Tue June 9 2009 8:19:06 am Naresh Tallapelli wrote: > > Hi All, > > > > I am Naresh. Iam usig cxf-2.1.2 version. I was able to execute my web > > service successfully. But sometimes, when web service client tries to > send > > message to web service server, the soap message was in the following form > > > > > > s > :xEmnlvnesl:oSp=e" http://sc > > hxemmlanss.:xSm=l"soap.orhgt/tspo:a/p//secnhveemlaosp.ex/m"l>s< > > oap.org/soS:Body> > > > > The soap message was repeated itself. And this was not reproducible > > everytime. So could any one please help me to resolve this issue. Why the > > SOAP message is rendered like that and what is fix for it. > > > > Any help is much appreciated. > > > > Thank you, > > Naresh. > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog >
Re: Are we branched?
Ah, a task at which I am uniquely qualified. On Wed, Jun 10, 2009 at 11:21 AM, Daniel Kulp wrote: > On Wed June 10 2009 11:12:58 am Benson Margulies wrote: >> Is it OK if I check into trunk with changes that depend on new wstx+ msv? > > Yep. All's a go. Go ahead and destabilize trunk. :-) > > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog >
Re: How to generate schemas from Java classes
On Wed June 10 2009 10:25:32 am Sergey Beryozkin wrote: > Hi > > I need to generate schema instances from java types, these types may or may > not be JAXB annotated. What options are available in CXF ? > > thanks, Sergey JAXB can handle beans without annotations. You just need the annotations if you need to customize anything. Thus, I'd stick with it. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Are we branched?
On Wed June 10 2009 11:12:58 am Benson Margulies wrote: > Is it OK if I check into trunk with changes that depend on new wstx+ msv? Yep. All's a go. Go ahead and destabilize trunk.:-) -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Are we branched?
Is it OK if I check into trunk with changes that depend on new wstx+ msv?
Re: How to generate schemas from Java classes
Jaxb or Aegis. I don't think xmlbeans, but I may be out of date. On Wed, Jun 10, 2009 at 10:25 AM, Sergey Beryozkin wrote: > Hi > > I need to generate schema instances from java types, these types may or may > not be JAXB annotated. > What options are available in CXF ? > > thanks, Sergey
How to generate schemas from Java classes
Hi I need to generate schema instances from java types, these types may or may not be JAXB annotated. What options are available in CXF ? thanks, Sergey
Re: How to implement the SOAP Fault for JMS Transport?
On Wed June 10 2009 4:38:37 am liucong wrote: > So, the JMS transport just copy JMS message properties to somewhere(For > example, Message.PROTOCOL_HEADERS map). Then the SOAP binding add some > extra interceptors (How to add these interceptors?) to deal with these > properties (check the properties, throw some SOAP Faults, and so on). > > Does it work? Is it Ok? Yep. That seems right. To add your interceptors, it would be in the SoapBindingFactory class. The createBinding(BindingInfo) method is where the interceptors for the SOAP stuff is setup.That would be the starting place to look. Dan > > Daniel Kulp Writes: > > Ideally, to me, this type of fault mapping needs to be in the SOAP > > binding, not the JMS transport.The JMS transport needs to be somewhat > > independent of soap so that it's usable for things like XML over JMS and > > possibly even some resty things. > > > > Basically, the SOAP binding should examine it's transportId and if it's > > the SOAP/JMS spec defined ID, it should add some extra interceptors to > > handle the mapping of the "soap specific" things into the non-soap > > specific things in the transport. > > > > For example: all the funky JMS headers that the SOAP/JMS spec requires > > should be done from an interceptor provided by the SOAP binding (put them > > in the Message.PROTOCOL_HEADERS map) that the JMS transport would just > > copy across. > > > > That said, I really haven't read the SOAP/JMS spec in very much detail so > > I'm not sure if it's completely possible. :-) > > > > Dan > > > > On Mon June 8 2009 10:54:18 pm liucong wrote: > >> Hi, > >> > >> Willem Jiang Writes: > >>> Hi, > >>> > >>> I think you mean how to throw the fault from the JMS transport. > >>> Basically , if you throw the fault from a CXF interceptor, CXF's > >>> interceptors chain will take care of it and build the fault message and > >>> throw it out. > >>> > >>> If you want to check the Content type , you could write an interceptor > >>> and load it with your soap jms transport. > >> > >> How to load an interceptor with my soap jms transport? Is there any > >> material for help? > >> > >> Thank you. > >> > >>> But I think you could take > >>> the soap binding (SoapBindingFactory) as an example, and put this kind > >>> of checking as a work of soap jms binding. > >>> > >>> Just my 2 cents, > >>> > >>> Willem > >>> > >>> liucong wrote: > Hi all, > > When I implement the SOAP Over JMS Specification, I don’t know how to > implement SOAP fault for it. > > I use the org.apache.cxf.interceptor.Fault to record the Fault > information. For example, I create a Fault instance for SOAP fault > subcode contentTypeMismatch > (http://www.w3.org/TR/2008/WD-soapjms-20080723/#binding-faults). If I > check the fault the cxf-rt-transports-jms module, I don’t know how to > deal with the fault which is checked out. > > If I added an Interceptor for JMS transport, I can use the interceptor > to deal with the fault. Is It right? > > If it is Ok, how is the interceptor added to the interceptors > according to whether the jms transport is used or not? > > Are there any materials for interceptors, phases, and phase order? > > Thank you very much! > > Best regards, > > Liu -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Integrating JAX-RS runtime into DOSGi
> I've just updated a cxf-minimal bundle to include a jaxrs frontend and I > updated the cxf.version in dosgi/parent to 2.3.0-SNAPHOT > > (David, Eoghan - we can downgrade it easily to 2.2.2 fixes tag if DOSGi will > need to be released sooner than 2.3 does which is in about 3 months or so I > believe, with fixes branch likely be easiler tp release earlier). Yeah - going to 2.2.2.fixes might be good. I expect that a DOSGi release will be done earlier than in 3 months, especially since the property names that are used will change in the real OSGi spec, which is currently being finalized. I am planning to update the properties in the DOSGi implementation to reflect the latest in the spec draft either later this week or early next week. BTW we now also have Discovery in CXF/DOSGi, so it would be nice to include that in a release fairly soon too. Thanks, David
Re: Integrating JAX-RS runtime into DOSGi
Hi Josh
What do you think about this idea. The factory which returns handlers
can check first if a given service intents include "HTTP" but no "SOAP"
and a frontend.jaxrs property is set, and if yes then it returns
JaxRSPojoConfigurationTypeHandler which will do what
PojoConfigurationTypeHandler but use JAXRS factories instead. The common
code, if any, can be refactored away into OSGIUtils.
I agree it would be great if a common interface was there but may be we
will be able to get to it at some later stage and collapse handlers into
a single one...
Thanks, Sergey
I can't seem to find JaxRSPojoConfigurationTypeHandler anywhere in the
source. I thought this was something that had been written and
committed already. Should I be looking in a branch for this?
Sorry, it was just an idea, there's no such handler in the source code yet.
I've just updated a cxf-minimal bundle to include a jaxrs frontend and I
updated the cxf.version in dosgi/parent to 2.3.0-SNAPHOT
(David, Eoghan - we can downgrade it easily to 2.2.2 fixes tag if DOSGi will need to be released sooner than 2.3 does which is in
about 3 months or so I believe, with fixes branch likely be easiler tp release earlier).
I haven't gone yet into the DOSGi code, it's been awhile since I last time worked with it. So the idea is to basically copy&paste
the existing PojoConfigurationHandler into JaxRSPojoConfigurationHandler and return it from a factory if certain conditions are met
(namely HTTP content is set, no SOAP and the the jaxrs property is also set). And then, as the next step, see what may be refactored
from both JaxRSPojoConfigurationHandler & PojoConfigurationHandler into OSGIUtils.
so the code for the server should be along these lines :
JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
sf.setResourceClasses(serviceClass);
sf.setResourceProvider(serviceClass, new
SingletonResourceProvider(serviceObject));
// only if aegis is needed, otherwise jaxb will be supported otb
sf.setProviders(Collections.singletonList(new AegisProvider()));
return sf.create()
for the client it should be something like
JAXRSClientFactory.create(serviceClass, Collections.singletonList(new
AegisProvider()));
I'd also like to suggest that we check first if a model info is available, say
in META-INF/{classname}.model, and if yes then use
JAXRSClientFactory.createFromModel(serviceClass, Collections.singletonList(new
AegisProvider()), modelRef);
and
JAXRSServerFactoryBean.setModelRef(modelRef)
so that users who'd like to avoid pulling in JAX-RS annotations can avail of
this featuer - but this can be done later on
Let me know please if you'd like me to prototype some code there.
thanks, Sergey
Thanks,
Josh
--
Josh Holtzman
Educational Technology Services, UC Berkeley
jholtz...@berkeley.edu
510.529.9225
Re: How to implement the SOAP Fault for JMS Transport?
So, the JMS transport just copy JMS message properties to somewhere(For example, Message.PROTOCOL_HEADERS map). Then the SOAP binding add some extra interceptors (How to add these interceptors?) to deal with these properties (check the properties, throw some SOAP Faults, and so on). Does it work? Is it Ok? Daniel Kulp Writes: Ideally, to me, this type of fault mapping needs to be in the SOAP binding, not the JMS transport.The JMS transport needs to be somewhat independent of soap so that it's usable for things like XML over JMS and possibly even some resty things. Basically, the SOAP binding should examine it's transportId and if it's the SOAP/JMS spec defined ID, it should add some extra interceptors to handle the mapping of the "soap specific" things into the non-soap specific things in the transport. For example: all the funky JMS headers that the SOAP/JMS spec requires should be done from an interceptor provided by the SOAP binding (put them in the Message.PROTOCOL_HEADERS map) that the JMS transport would just copy across. That said, I really haven't read the SOAP/JMS spec in very much detail so I'm not sure if it's completely possible. :-) Dan On Mon June 8 2009 10:54:18 pm liucong wrote: Hi, Willem Jiang Writes: Hi, I think you mean how to throw the fault from the JMS transport. Basically , if you throw the fault from a CXF interceptor, CXF's interceptors chain will take care of it and build the fault message and throw it out. If you want to check the Content type , you could write an interceptor and load it with your soap jms transport. How to load an interceptor with my soap jms transport? Is there any material for help? Thank you. But I think you could take the soap binding (SoapBindingFactory) as an example, and put this kind of checking as a work of soap jms binding. Just my 2 cents, Willem liucong wrote: Hi all, When I implement the SOAP Over JMS Specification, I don’t know how to implement SOAP fault for it. I use the org.apache.cxf.interceptor.Fault to record the Fault information. For example, I create a Fault instance for SOAP fault subcode contentTypeMismatch (http://www.w3.org/TR/2008/WD-soapjms-20080723/#binding-faults). If I check the fault the cxf-rt-transports-jms module, I don’t know how to deal with the fault which is checked out. If I added an Interceptor for JMS transport, I can use the interceptor to deal with the fault. Is It right? If it is Ok, how is the interceptor added to the interceptors according to whether the jms transport is used or not? Are there any materials for interceptors, phases, and phase order? Thank you very much! Best regards, Liu
SOAP/JMS specification for CXF [Project Status]
Hi all, Project Description: SOAP over JMS specification (http://www.w3.org/TR/soapjms/) is aimed at a set of standards for the transport of SOAP messages over JMS (Java Message Service). The main purpose is to ensure interoperability between the implementations of different Web services vendors. CXF does support SOAP over JMS, but it does not meet the current draft specification defined at http://www.w3.org/TR/soapjms/ and instead uses some proprietary formats, headers, URL formats, etc. This project would update the SOAP/JMS support in CXF to be completely specification compliant. Any advice or help are welcome! Project Information: 1.Project Status: http://wiki.apache.org/general/soapjms4cxf 2.Project Code: http://github.com/liucong/jms4cxf2/tree/master 3.Project JIRA task: https://issues.apache.org/jira/browse/CXF-2253 What I have done: 1.Implement a simple JMS URI (http://tools.ietf.org/html/draft-merrick-jms-uri-05 ) 2.Integrate the JMS URI into current jms-transport. It is compatible with the specification. 3.Modify the JMS Header Properties and JMS Properties and make it compatible with the specification. 4.Modify some code about SOAP fault and MEPs. Liu
