Re: JAXRSInInterceptor MissingResourceException

[Sergey Beryozkin]

Hi,

I'm just wondering can it be some class loader/path issue known to the Geronimo 
community ?
May be you can ask the guys there and let us know what might've caused it ? 
Other users seem to have no problems when running it under Tomcat and when 
running it in standalone mode with Jetty. 

Cheers, Sergey


- Original Message - 
From: Fleming, Timothy [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Wednesday, April 23, 2008 3:44 PM
Subject: JAXRSInInterceptor MissingResourceException


I'm attempting to deploy a simple JAX-RS servlet service under
Geronimo/Jetty using Spring for initialization.  During startup I get:

java.lang.ExceptionInInitializerError
at
org.apache.cxf.jaxrs.JAXRSBindingFactory.createBinding(JAXRSBindingFacto
ry.java:43)
at
org.apache.cxf.endpoint.EndpointImpl.createBinding(EndpointImpl.java:130
)
at
org.apache.cxf.endpoint.EndpointImpl.init(EndpointImpl.java:81)
at
org.apache.cxf.jaxrs.JAXRSServerFactoryBean.createEndpoint(JAXRSServerFa
ctoryBean.java:134)
at
org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBea
n.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
...
Caused by: java.util.MissingResourceException: Can't find bundle for
base name org.apache.cxf.jaxrs.interceptor.Messages, locale en_US
at
java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.ja
va:836)
at
java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:805)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:549)
at
org.apache.cxf.common.i18n.BundleUtils.getBundle(BundleUtils.java:75)
at
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.clinit(JAXRSInInte
rceptor.java:49)

The exception itself is pretty simple.  The JAXRSInInterceptor class has
a static initializer that loads a resource bundle.  For some reason the
load fails.  

I'm using 2.1 snapshot and have confirmed the
org.apache.cxf.jaxrs.interceptor.Messages.properties file is present in
the deployed jar.  Any ideas what could be causing this?  Thanks

--
Tim Fleming
FINRA
Sr Developer




This email, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed.  If the reader of this email is not the 
intended recipient or his or her authorized agent, the reader is 
hereby notified that any dissemination, distribution or copying of this 
email is prohibited. If you have received this email in error, 
please notify the sender by replying to this message and delete this 
email immediately.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: Creating a REST service from a schema

[Sergey Beryozkin]

Hi

Hi

If you're using Spring then please have a look at trunk/systests/src/test/resources/jaxrs_spring_providers/WEB-INF/beans.xml. 
something like this will do :

jaxrs:server id=bookservice address=/
   jaxrs:serviceBeans
   ref bean=petstore /
   ref bean=bookstore /
 /jaxrs:serviceBeans
  jaxrs:entityProviders
  bean class=org.apache.cxf.systest.jaxrs.BadgerFishProvider /
 /jaxrs:entityProviders
/jaxrs:server

Now, Jersey and other JAX_RS implementation would pick up the provider from the classpath, just annotating a custom provider with 
@Provider annotation would be sufficient. CXF is not capable of doing it yet. I'm not actually sure I like very much the idea of 
scanning the class path, should be fine in the simple scenarious but might cause classpath-like clash issues if say multiple custom 
providers for a certain type like Atom Feed or JAXB are availbale on the classpath. That said, this is something CXF will likely 
support, it's one of those areas where a patch would also be welcome.


If you don't do Spring then you can do

JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
sf.setResourceClasses(CustomerService.class);
// add you custom providerList? providers = ...;provider.add(new 
CustomProvider());sf.setEntityProviders(listOfProviders);
sf.create();
Hope it helps, Sergey 



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: REST-JS

[Sergey Beryozkin]

Hi Jervis

I'm sorry for replying so late...
The idea behind ?_js or ?_lang=js is not to indicate to the runtime that the 
invocation is coming from a JS client stack but to
provide on the fly generation of the client execution code (JS in this case), 
similar to what Benson did for JAX-WS services. Such execution fragment can 
then be embedded into XHTML pages, etc. 
Perhaps a better option would be to support .js extensions, something like
GET /customer.js

Either way, CXF JAX-RS impl supports handlers which can be invoked before the 
invocation is made on the actual resource class. These handlers need some minor 
cleanup, but as far as the generation of such JS client code is concerned, it 
would be a matter implementing a handler capable of looking at a 
ClassResourceInfo (the model class you created originally) and returning a 
JAX-RS Response with its entity being the generated (JS) code...

Cheers, Sergey


- Original Message - 
From: Jervis Liu [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Monday, March 24, 2008 3:14 AM
Subject: Re: REST-JS


 Hi Sergey, could you elaborate a bit more on the ?_js or ?_lang=js stuff
 please. I thought what Benson and Arul were talking about is a pure client
 stack that is implemented in Java script that can connect to JAX-RS
 compatible RESTful services. As far as the JAX-RS  server side is concerned,
 it does not matter the request is coming from a java script client or
 anything else, does it?
 
 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: Problem when trying to test JAX-RS service

[Sergey Beryozkin]

This entry might be a problem :


 http://cxf.apache.org/jaxrs
 C:\workspace\eclipse33\cxf_REST_Web\WebContent\WEB-INF\schema\jaxrs.xsd


There's a spring.schemas file wich matches the http://cxf.apache.org/schemas/jaxrs.xsd location to the local class resource 
schemas/jaxrs.xsd, so please try

 http://cxf.apache.org/jaxrs
 http://cxf.apache.org/schemas/jaxrs.xsd;

Cheers, Sergey


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: CXF, WS-Policy and Spring

[Sergey Beryozkin]

I think you should inline policy expressions like this, have a look please at 
ws-policy system tests :

beans xmlns:p=http://cxf.apache.org/policy;
xsi:schemaLocation=...http://cxf.apache.org/policy 
http://cxf.apache.org/schemas/policy.xsd...;

jaxws:endpoint id=echoService
implementor=com.example.EchoService address=/echo
jaxws:features

p:policies
wsp:PolicyReference URI=#PolicyId/
/p:policies


/jaxws:features
/jaxws:endpoint


wsp:Policy wsu:Id=PolicyId
!-- ... --
/wsp:Policy
/beans

But, as I said earlier, CXF is not capable yet of automatically propagating such policy expressions into a generated wsdl, hence, at 
the moment, you need to do something like this :


jaxws:endpoint id=echoService
wsdlLocation=META-INF/wsdl/hello.wsdl/

With no policy expressions in the spring config but only in the explicitly created wsdl, this is only needed if the task is to have 
a non-CXF policy aware client like a NET client be capable of consuming the endpoint as expected :


wsdl:definitions
wsdl:service
wsdl:port
!-- your policy expression goes here --
/wsdl:port
/wsdl:service
/wsdl:definitions

Hope this helps
Sergey


- Original Message - 
From: Gerhard Schlager [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Wednesday, April 16, 2008 10:04 PM
Subject: Re: CXF, WS-Policy and Spring




BTW, this is the content of my Spring config file which leads to the
exception.

?xml version=1.0 encoding=UTF-8?
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:jaxws=http://cxf.apache.org/jaxws;
xmlns:wsp=http://www.w3.org/2006/07/ws-policy;
xmlns:wsrm=http://schemas.xmlsoap.org/ws/2005/02/rm/policy;
xmlns:wsam=http://www.w3.org/2007/02/addressing/metadata;

xmlns:mtom=http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization;
xsi:schemaLocation=
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd;

import resource=classpath:META-INF/cxf/cxf.xml /
import resource=classpath:META-INF/cxf/cxf-extension-soap.xml /
import resource=classpath:META-INF/cxf/cxf-servlet.xml /

jaxws:endpoint id=echoService
implementor=com.example.EchoService address=/echo
jaxws:features
wsp:Policy
wsrm:RMAssertion
wsrm:InactivityTimeout Milliseconds=60 /
wsrm:AcknowledgementInterval Milliseconds=200 /
/wsrm:RMAssertion
wsam:Addressing
wsp:Policy /
/wsam:Addressing
mtom:OptimizedMimeSerialization /
/wsp:Policy
/jaxws:features
/jaxws:endpoint
/beans

I have the following JARs in my build path:
asm-2.2.3.jar
commons-logging-1.1.jar
cxf-2.0.5-incubator.jar
geronimo-activation_1.1_spec-1.0.2.jar
geronimo-annotation_1.0_spec-1.1.1.jar
geronimo-javamail_1.4_spec-1.2.jar
geronimo-servlet_2.5_spec-1.1.2.jar
geronimo-stax-api_1.0_spec-1.0.1.jar
geronimo-ws-metadata_2.0_spec-1.1.2.jar
jaxb-api-2.0.jar
jaxb-impl-2.0.5.jar
jaxws-api-2.0.jar
jetty-6.1.8.jar
jetty-util-6.1.8.jar
neethi-2.0.2.jar
saaj-api-1.3.jar
saaj-impl-1.3.jar
slf4j-api-1.3.1.jar
slf4j-jdk14-1.3.1.jar
wsdl4j-1.6.1.jar
wstx-asl-3.2.4.jar
xml-resolver-1.2.jar
XmlSchema-1.3.2.jar
spring.jar

Maybe those details help finding the cause of the exception.
--
View this message in context: 
http://www.nabble.com/CXF%2C-WS-Policy-and-Spring-tp16718063p16733491.html
Sent from the cxf-user mailing list archive at Nabble.com. 



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: CXF, WS-Policy and Spring

[Sergey Beryozkin]

Hi,
I'm sorry to say it but I've never got to ensuring that for java-first services 
WS-Policy expressions get automatically added to a (generated) WSDL. I can't 
commit myself to fixing this issue at this stage, but whenever I get a chance 
to look at a WS-Policy stuff, I'll get it fixed first as it's obvious it's a 
major blocket to utilizing the CXF WS-Policy framework at a wider scale.

Current WS-Policy implementation is a bit complicated, but the fix for this 
issue should be reasonably simple, it would probably require an update to a 
WS-PolicyFeature implementation which should register the policy extensors it 
discovers from a spring configuration with either the Endpoint or WSDLManager...

The only workaround at this stage is to explictly create a WSDL and have those 
expressions bound to the right extension points. The other possibility is to 
consider creating a patch if it's a real blocker...

Cheers, Sergey

- Original Message - 
From: Gerhard Schlager [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Wednesday, April 16, 2008 8:39 AM
Subject: CXF, WS-Policy and Spring


 
 Hello!
 
 I'm currently trying to create a web service with CXF that can be used by a
 .NET client (WCF).
 In the documentation of Sun's Metro I read about WSIT which supports the
 interoperability between Java and .NET.
 
 WSIT in NetBeans is automatically adding a few things to the WSDL:
 
 wsp:Policy wsu:Id=HelloWorld_policy
  wsp:ExactlyOne
wsp:All
  wsrm:RMAssertion
wsrm:InactivityTimeout Milliseconds=60/
wsrm:AcknowledgementInterval Milliseconds=200/
  /wsrm:RMAssertion
  wsoma:OptimizedMimeSerialization/ 
/wsp:All
  /wsp:ExactlyOne
 /wsp:Policy
 
 Can I do the same thing with CXF? I tried adding the following to the
 endpoint's Spring bean:
 
 bean id=classifierService class=com.example.HelloWorldImpl
  !-- properties --
 /bean
 
 jaxws:endpoint id=helloWorldEndpoint
 implementorClass=com.example.HelloWorldImpl implementor=#helloWorld
 address=/helloWorld
  jaxws:properties
entry key=mtom-enabled value=true /
  /jaxws:properties
  jaxws:features
wsp:Policy
  wsrm:RMAssertion
wsrm:InactivityTimeout Milliseconds=60/
wsrm:AcknowledgementInterval Milliseconds=200 /
  /wsrm:RMAssertion
  wsam:Addressing/
  mtom:OptimizedMimeSerialization /
/wsp:Policy
  /jaxws:features
 /jaxws:endpoint
 
 However, that didn't work as expected. Spring throws some type conversion
 exceptions when I add the jaxws:features to the endpoint's bean. Am I
 doing something completely wrong?
 I'd be really grateful if somebody could provide a working example that
 shows a complete Spring configuration file with namespaces, schemaLocations
 and the policy configuration.
 
 Thanks in advance for your help.
 
 Best regards,
 Gerhard
 -- 
 View this message in context: 
 http://www.nabble.com/CXF%2C-WS-Policy-and-Spring-tp16718063p16718063.html
 Sent from the cxf-user mailing list archive at Nabble.com.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: CXF, WS-Policy and Spring

[Sergey Beryozkin]

Hi

 I had some problems with Sun's Metro in conjunction with Spring and
 Hibernate so I switched back to CXF.

Interesting :-). I think you can definitely use Spring and Hibernate in CXF.
But as far as WS-Policy is concerned, in CXF you just need to put policy 
expressions, those starting with
wsp:Policy explicitly in WSDL, say, as children of wsdl:service/wsdl:port. So 
you can use your Spring injection, but the only limitation is that the policy 
expressions need to reside in a given WSDL document.

It should work just fine...Now, Metro has a better domain-specific WS-Policy 
support (specifically WS-SecurityPolicy), but the policy expressions which you 
listed will work in CXF AFAIK... 

Cheers, Sergey


 
 Hello Sergey,
 
 
 Sergey Beryozkin wrote:
 
 I'm sorry to say it but I've never got to ensuring that for java-first
 services WS-Policy expressions get automatically added to a (generated)
 WSDL. I can't commit myself to fixing this issue at this stage, but
 whenever I get a chance to look at a WS-Policy stuff, I'll get it fixed
 first as it's obvious it's a major blocket to utilizing the CXF WS-Policy
 framework at a wider scale.
 
 Current WS-Policy implementation is a bit complicated, but the fix for
 this issue should be reasonably simple, it would probably require an
 update to a WS-PolicyFeature implementation which should register the
 policy extensors it discovers from a spring configuration with either the
 Endpoint or WSDLManager...
 
 
 Now I'm a little bit confused. After reading [1] I thought it would be
 possible to configure the WS-Policy with Spring. I just couldn't get it
 working because of some exceptions (I can post them in a few hours if you
 need them) that Spring was throwing at me. ;-)
 So, are you saying it currently can't be done at all? That would be too bad.
 I had some problems with Sun's Metro in conjunction with Spring and
 Hibernate so I switched back to CXF. It looks like I can't use both of them.
 Writing my own patch is not possible since I need a solution within the next
 few days.
 
 Would it work if I used WSDL first? However, I guess I won't be able to use
 Spring's dependency injection then, will I? :-(
 
 [1] http://netzooid.com/blog/2007/04/23/cxf-spring-and-ws-policy-internals/
 -- 
 View this message in context: 
 http://www.nabble.com/CXF%2C-WS-Policy-and-Spring-tp16718063p16721675.html
 Sent from the cxf-user mailing list archive at Nabble.com.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: CXF, WS-Policy and Spring

[Sergey Beryozkin]

Thanks Freeman. Yes, I need to clarify that it will work indeed this way, it's 
just that the automatic publication of such policy expressions into a published 
WSDL (to be consumed by a NET client in this case) is not supported at this 
stage so that's why I was suggesting to put them into an explicit WSDL document 
and then link to that wsdl document from a jaxws:endpoint definition

Cheers, Sergey


From: Freeman Fang [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Wednesday, April 16, 2008 2:50 PM
Subject: Re: CXF, WS-Policy and Spring


 Hi Gerhard,
 
 I'm not expert of ws-policy, but add spring configure to jaxws:endpoint 
 per as below just works for me
 jaxws:features
wsp:Policy
  wsrm:RMAssertion
wsrm:InactivityTimeout Milliseconds=60/
wsrm:AcknowledgementInterval Milliseconds=200 /
  /wsrm:RMAssertion
  wsam:Addressing
 wsp:Policy/
  /wsam:Addressing
  mtom:OptimizedMimeSerialization /
/wsp:Policy
  /jaxws:features
 Also you need add namespace definition
  xmlns:wsp=http://www.w3.org/2006/07/ws-policy;
  xmlns:wsrm=http://schemas.xmlsoap.org/ws/2005/02/rm/policy;
  xmlns:wsam=http://www.w3.org/2007/02/addressing/metadata;
  
 xmlns:mtom=http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization;
 
 Regards
 
 Freeman
 
 Gerhard Schlager wrote:
 Hello Sergey,


 Sergey Beryozkin wrote:
   
 I'm sorry to say it but I've never got to ensuring that for java-first
 services WS-Policy expressions get automatically added to a (generated)
 WSDL. I can't commit myself to fixing this issue at this stage, but
 whenever I get a chance to look at a WS-Policy stuff, I'll get it fixed
 first as it's obvious it's a major blocket to utilizing the CXF WS-Policy
 framework at a wider scale.

 Current WS-Policy implementation is a bit complicated, but the fix for
 this issue should be reasonably simple, it would probably require an
 update to a WS-PolicyFeature implementation which should register the
 policy extensors it discovers from a spring configuration with either the
 Endpoint or WSDLManager...

 

 Now I'm a little bit confused. After reading [1] I thought it would be
 possible to configure the WS-Policy with Spring. I just couldn't get it
 working because of some exceptions (I can post them in a few hours if you
 need them) that Spring was throwing at me. ;-)
 So, are you saying it currently can't be done at all? That would be too bad.
 I had some problems with Sun's Metro in conjunction with Spring and
 Hibernate so I switched back to CXF. It looks like I can't use both of them.
 Writing my own patch is not possible since I need a solution within the next
 few days.

 Would it work if I used WSDL first? However, I guess I won't be able to use
 Spring's dependency injection then, will I? :-(

 [1] http://netzooid.com/blog/2007/04/23/cxf-spring-and-ws-policy-internals/



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: REST, error handling, HTTP status codes

[Sergey Beryozkin]

Hi


This would be fairly easy to do with JAX-RS. There's a number of ways to 
propogate HTTP errors with JAX-RS from your application code :

1. throw WenApplicationException

public void putIt(String s) {
throw new WebApplicationException()
}

By default it will cause 500.

2. You can also use a Response object, either directly or by wrapping it into a 
WebApplicationException

public void putIt(String s) {
throw new WebApplicationException(
 Response.status(406).entity(descitptionOfProblemInXml).build())
}

WebApplicationException is a RuntimeException so you can use (possibly) at any 
level in your app...

or 

just 

@ProduceMime(application/atom+entry)
@Path({id})
public Response getIt(Long id) {
   Entry e = find(id);
   if (e == null) {
   return  
Response.status(errorCode).entity(descitptionOfProblemInXml).build();
   } else {
   return Response.entity(e).build();
   }  
}

Cheers, Sergey




 Hello,
 
 I'm looking into providing some REST based services with CXF. The examples 
 are great but I can't see something demonstrating error handling. While 
 error handling with REST doesn't seem to be particularly well defined, 
 HTTP status codes would surfice. How easy is this to achieve with CXF? 
 
 
 John Baker
 -- 
 Web SSO 
 IT Infrastructure 
 Deutsche Bank London
 
 URL:  http://websso.cto.gt.intranet.db.com
 
 
 ---
 
 This e-mail may contain confidential and/or privileged information. If you 
 are not the intended recipient (or have received this e-mail in error) please 
 notify the sender immediately and delete this e-mail. Any unauthorized 
 copying, disclosure or distribution of the material in this e-mail is 
 strictly forbidden.
 
 Please refer to http://www.db.com/en/content/eu_disclosures.htm for 
 additional EU corporate and regulatory disclosures.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: jax-rs URLs not working (was: Base class members not serializing / deserializing)

[Sergey Beryozkin]

Hi

As far as I know annotations at the interface level will only supported in the 
0.7 version (it's mandated in the corresponding version of the spec), and only 
method-level annotations will be inherited (I'll need to confirm it), Jersey 
does it on the current trunk (which is corresponds to the soon to be released 
stable 0.7 jaxrs-api).
Brad, try to put the annotations on the actual root resource class, just to see 
that's working. Then at a later stage you may want to put the annotations on 
the superclass, but first try from the root resource class...

Cheers, Sergey


 Maybe the annotations have to go in the implementation class 
 instead/as well? I didn't use an interface - just an instantiatable
 class (with method bodies).
 
 Apart from broken POST data, thats the only other thing I can think of.
 
 Doug
 
 
 On Mon, 7 Apr 2008, Brad O'Hearne wrote:
 Doug,

 Thanks for the reply. I'm still getting the same errors, going to show
 you exactly what happens in my implementation. Here is my web.xml:

 !DOCTYPE web-app
  PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN
  http://java.sun.com/dtd/web-app_2_3.dtd;
 web-app
 context-param
 param-namecontextConfigLocation/param-name
 param-valueWEB-INF/beans.xml/param-value
 /context-param
 listener
 listener-class
 org.springframework.web.context.ContextLoaderListener
 /listener-class
 /listener
 servlet
 servlet-nameCXFServlet/servlet-name
 display-nameCXF Servlet/display-name
 servlet-class
 org.apache.cxf.transport.servlet.CXFServlet
 /servlet-class
 load-on-startup1/load-on-startup
 /servlet
 servlet-mapping
 servlet-nameCXFServlet/servlet-name
 url-pattern/services/*/url-pattern
 /servlet-mapping
 /web-app

 Here is my beans.xml:

 ?xml version=1.0 encoding=UTF-8?
 beans xmlns=http://www.springframework.org/schema/beans;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xmlns:jaxrs=http://cxf.apache.org/jaxrs;
 xsi:schemaLocation=
 http://www.springframework.org/schema/beans
 http://www.springframework.org/schema/beans/spring-beans.xsd
 http://cxf.apache.org/jaxrs
 http://cxf.apache.org/schemas/jaxrs.xsd;
 import resource=classpath:META-INF/cxf/cxf.xml /
 import
 resource=classpath:META-INF/cxf/cxf-extension-jaxrs-binding.xml /
 import resource=classpath:META-INF/cxf/cxf-servlet.xml /
 jaxrs:server id=userService address=/
 jaxrs:serviceBeans
 bean
 class=com.brad.UserService /
 /jaxrs:serviceBeans
 /jaxrs:server
 /beans

 Here is my service interface (which is implemented by the UserService
 class referenced in beans.xml):

 @Path(/UserService)
 public interface IUserService {
  @POST
  @Path(authenticate)
  @ConsumeMime(application/xml)
  @ProduceMime(application/xml)
  AuthenticateResponse authenticate(AuthenticateRequest request);
 }

 Tomcat loads cleanly (as far as I can tell -- no exceptions). When I
 try to access this service with an xml payload and the following URL: 
 http://localhost:8080/MyWebApp/services/UserService/authenticate

 I get the following exception on the server:

 Apr 6, 2008 7:38:46 AM
 org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor handleMessage
 SEVERE: No operation found for path: /UserService/authenticate/,
 contentType: application/xml, Accept contentType: */*
 Apr 6, 2008 7:38:46 AM org.apache.cxf.phase.PhaseInterceptorChain
 doIntercept
 INFO: Interceptor has thrown exception, unwinding now
 org.apache.cxf.interceptor.Fault: .No operation matching request path /
 UserService/authenticate/ is found, ContentType : application/xml,
 Accept : */*.
 at
 org
 .apache
 .cxf
 .jaxrs
 .interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:
 120)
 at
 org
 .apache
 .cxf
 .phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220)
 at
 org
 .apache
 .cxf
 .transport
 .ChainInitiationObserver.onMessage(ChainInitiationObserver.java:78)
 at
 org
 .apache
 .cxf
 .transport.servlet.ServletDestination.invoke(ServletDestination.java:92)
 at
 org
 .apache
 .cxf
 .transport
 .servlet.ServletController.invokeDestination(ServletController.java:214)
 at
 org
 .apache
 .cxf.transport.servlet.ServletController.invoke(ServletController.java:
 113)
 at
 org
 .apache
 .cxf
 .transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:
 170)
 at
 org
 .apache
 .cxf
 .transport.servlet.AbstractCXFServlet.doPost(AbstractCXFServlet.java:
 148)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
 at
 org
 .apache
 .catalina
 .core
 .ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
 290)
 at
 org
 .apache
 .catalina
 .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at
 org
 .apache
 .catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:
 233)
 at
 org
 .apache
 .catalina.core.StandardContextValve.invoke(StandardContextValve.java:
 175)
 at
 org
 .apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
 128)
 at
 org

Re: GET request URL parameters

[Sergey Beryozkin]

Hi

CXF HttpBinding can be considered deprecated as it has not been supported for a 
while.
I'd recommend you to try a JAX-RS approach, multiple query parameters are 
supported there...

Cheers, Sergey


 
 I have tried the rest style web service with http binding with CXF2.0.3
 version.  My service looks as follows. 
 
 @Get
 @HttpResource(location = /searchCustomer/{firstName}/{lastName})
 Customer searchCustomer(@WebParam(name =
 searchInputType)SearchCriteriaType searchInput);
 
 When I tried with the URL,
 
 http://localhost:8080/myapp/services/searchCustomer/foo_first/bar_last
 
 I got the correct output.  
 
 But I would like to use request parameters query string as follows.
 
   
 http://localhost:8080/myapp/services/searchCustomer?firstName=foo_firstlastName=bar_last
 
 But the service is failed with the following Exception:
 
 org.apache.cxf.interceptor.Fault: Invalid URL/Verb combination. Verb: GET
 Path: /searchCustomer
 at
 org.apache.cxf.binding.http.interceptor.DispatchInterceptor.handleMessage(DispatchInterceptor.java:74)
 at
 org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:207)
 at
 org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:73)
 at
 org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletDestination.java:79)
 at
 org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:256)
 at
 org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:123)
 at
 org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:170)
 at
 org.apache.cxf.transport.servlet.AbstractCXFServlet.doGet(AbstractCXFServlet.java:152)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
 
 I would like to know is there any way can I configure CXF web service to
 use query strings?  Because I suspect there could be special characters or
 white spaces in the parameters which might break the URL if I follow the
 first approach.  If I use request parameters as query string I can use
 proper encoding for parameters provided by JSTL taglibs.
 
 Thanks,
 Durga
 
 
 
 -- 
 View this message in context: 
 http://www.nabble.com/GET-request-URL-parameters-tp16476108p16476108.html
 Sent from the cxf-user mailing list archive at Nabble.com.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: JAX-RS: HttpServletRequest resource injection

[Sergey Beryozkin]

Hi

We don't support that yet. We do support the injection of @HttpContext fileds, 
such as UriInfo, HttpHeaders and SecurityContext. Is there any chance you can 
get what you need from HttpServletRequest from either of those JAX-RS types ?
When I get a chance I'll update the code which deals with @HttpContext fileds 
to also check for @Resource annotated fields...

Cheers, Sergey



 
 Hi,
 
 I currently use the JAX-WS WebServiceContext resource injection in my
 service bean to be able to access the HttpServletRequest in my SOAP web
 services and this works well:
 
 @Resource
 private WebServiceContext context;
 
 I now need to implement the same web service as a REST service. CXF
 2.1-incubator is great because it includes the JAX-RS frontend, but resource
 injection doesn't seem to work. 
 Form the 0.6 specs, in section 5.1, I should be able to access the
 HttpServletRequest:
 
 The javax.annotation.Resource annotation can be used to indicate a
 dependency on a Servlet-defined resource. An implementation MUST support
 injection of the following types: ServletConfig, ServletContext,
 HttpServletRequest and HttpServletResponse.
 
 I thought this simple code would be sufficiant, but apparently it isn't:
 
 @Resource
 private HttpServletRequest request;
 
 Resource injection is quite new to me, so maybe I'm doing something wrong.
 Can somebody help?
 
 Cheers,
 
 Mickael
 -- 
 View this message in context: 
 http://www.nabble.com/JAX-RS%3A-HttpServletRequest-resource-injection-tp16418423p16418423.html
 Sent from the cxf-user mailing list archive at Nabble.com.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: re[jira] stful uri binding value not set to input parameter bean property

[Sergey Beryozkin]

Hi Tam

If it's a blocker for you and you know a java JSON library which handles this 
case then there's a fairly easy workaround. One can create a custom 
MessageBodyWriter (copy and paste of the existing JSON provider with minor 
updates), in your case it can be a CustomJsonWriter, which would delegate to 
the library which just works, and then it can be registered with the runtime, 
have a look please on how Barry F. did a BadgerFishJSonProvider in system jaxrs 
tests...

Cheers, Sergey


 
 
 Yea, Jettison issue.   There was a discussion about this on the jettison 
 list:
 
 http://archive.jettison.codehaus.org/dev/27326848.1205101828701.JavaMail.haus-jira%40codehaus01.managed.contegix.com
 
 and JIRA:
 
 http://jira.codehaus.org/browse/JETTISON-36
 
 Dan
 
 
 
 On Thursday 27 March 2008, Sergey Beryozkin wrote:
 Hi Tam

 I'm afraid I don't know what the issue is here. Looks like it's either
 the problem of missing some JAXB annotation... or more likely the
 problem of Jettison...

 Does someone know, is it possible to fix this issue at the JAXB level
 ? Cheers, Sergey

  Hi Sergey
 
  I have run into another problem! I am making a GET request to a
  service and it is returning me some JSON content.  The content I am
  getting is: {telephoneNo:{code:161,number:2382907}}
  the content I want is:
  {telephoneNo:{code:0161,number:2382907}}
  I have tried adding an @XmlElement(type = String.class) annotation
  to the Field of the Object returned by the service but that makes no
  difference. If I add a non numeric char to the code field value
  (0161S) the value is returned in quotes, so it looks like it is
  determining the value type from the value rather than the Field or
  annotation?!  Is this a bug or is there something I'm not setting
  somewhere?
 
  Cheers, Tam
 
  Sergey Beryozkin wrote:
  Hi Tam
 
  Thanks for that, I have now got it up and running.  You also have
  to add the
  @XmlRootElement annotation to the object returned by the service
  otherwise
  you get a NullPointerException.
 
  The exception is quite poor all-right at the moment. In this case
  and exception saying no MessageBodyWriter was found has to be
  generated. I actually have a minor patch I did on weekends to
  improve on some of the things in this area, including the support
  for a standard
  WebApplicationException.
 
   Is it possible to specify the @ProduceMime type in the Spring
   context
 
  file.
 
  You can do
  @GET
  @ProduceMime(application/xml, application/json)
 
  and then, depending on the value of the Accept type the approproate
  MessageBodyWriter will be selected. You can also debug the formats
  like this :
  GET /yourResource?_contentType=application/xml
  or
  GET /yourResource?_contentType=xml
 
  etc, with xml in this case defaulting to application/xml. More
  shortcuts like 'xml' can be easily added to a system query handler
  dealing with this query...
 
  Cheers, Sergey
 
  Hi Sergey
 
  Thanks for that, I have now got it up and running.  You also have
  to add the
  @XmlRootElement annotation to the object returned by the service
  otherwise
  you get a NullPointerException.
  Is it possible to specify the @ProduceMime type in the Spring
  context file.
  At the moment if i want a service to return different mime types
  it seems like i need multiple implementations of the method with
  different annotations.
 
  Cheers, Tam
 
  Sergey Beryozkin wrote:
  Hi Tam,
 
  I'm sorry, but I've never got to updating the documentaion but
  I've created a JIRA to have the docs updated asap, I'll try to
  update them in the next few days...
  In meantime have a look please at a basic jaxrs demo, the only
  difference
  with what the documentation says is that
  different annotations are used, for ex @GET instead of
  @HttpMethod(Get),
  @Path instead of @UriTemplate and @PathParam instead of
  @UriParam...
 
  Cheers, Sergey
 
  - Original Message -
  From: tam.sayers [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Tuesday, March 25, 2008 11:05 AM
  Subject: Re: re[jira] stful uri binding value not set to input
  parameter bean property
 
  Hi Sergey
 
  Thanks for the reply.  The version of the jax-rs implementation
  in the apache-cxf-2.1-incubator-20080321.032844-42.zip seems to
  be different than
  the one described in
  http://cwiki.apache.org/CXF20DOC/jax-rs-jsr-311.html.
  Do you know if there is any documentation anywhere for the newer
  version?
 
  Tam
 
  Sergey Beryozkin wrote:
  Hi
 
  Please try the same with the current JAX-RS implementation in
  CXF. I'm not qute sure why this does not work for the CXF HTTP
  binding, but one
  thing is that
  this binding can be considered depecated...unless someone can
  confirm they're going to mantain it...
 
  Cheers, Sergey
 
  I have tried calling the following service using the cxf 2.0.4
  and 2.1
  code
  and when using both the accountNumber is not set to the
  GetForAccount bean.
  When debugging through the code I can see

Re: re[jira] stful uri binding value not set to input parameter bean property

[Sergey Beryozkin]

Hi Tam

I'm afraid I don't know what the issue is here. Looks like it's either the 
problem of missing some JAXB
annotation... or more likely the problem of Jettison...

Does someone know, is it possible to fix this issue at the JAXB level ?
Cheers, Sergey




 
 Hi Sergey
 
 I have run into another problem! I am making a GET request to a service and
 it is returning me some JSON content.  The content I am getting is:
 {telephoneNo:{code:161,number:2382907}}
 the content I want is:
 {telephoneNo:{code:0161,number:2382907}}
 I have tried adding an @XmlElement(type = String.class) annotation to the
 Field of the Object returned by the service but that makes no difference. 
 If I add a non numeric char to the code field value (0161S) the value is
 returned in quotes, so it looks like it is determining the value type from
 the value rather than the Field or annotation?!  Is this a bug or is there
 something I'm not setting somewhere?
 
 Cheers, Tam
 
 
 Sergey Beryozkin wrote:
 
 Hi Tam
 
 Thanks for that, I have now got it up and running.  You also have to add
 the
 @XmlRootElement annotation to the object returned by the service
 otherwise
 you get a NullPointerException.
 
 The exception is quite poor all-right at the moment. In this case and
 exception saying no MessageBodyWriter was found has to be generated. I
 actually have a minor patch I did on weekends to improve on some of the
 things in this area, including the support for a standard
 WebApplicationException.
 
  Is it possible to specify the @ProduceMime type in the Spring context
 file.
 
 You can do 
 @GET
 @ProduceMime(application/xml, application/json)
 
 and then, depending on the value of the Accept type the approproate
 MessageBodyWriter will be selected. You can also debug the formats like
 this :
 GET /yourResource?_contentType=application/xml
 or 
 GET /yourResource?_contentType=xml
 
 etc, with xml in this case defaulting to application/xml. More shortcuts
 like 'xml' can be easily added to a system query handler dealing with this
 query...
 
 Cheers, Sergey
 
 
 
 
 
 Hi Sergey
 
 Thanks for that, I have now got it up and running.  You also have to add
 the
 @XmlRootElement annotation to the object returned by the service
 otherwise
 you get a NullPointerException.
 Is it possible to specify the @ProduceMime type in the Spring context
 file.
 At the moment if i want a service to return different mime types it seems
 like i need multiple implementations of the method with different
 annotations.
 
 Cheers, Tam
 
 
 Sergey Beryozkin wrote:
 
 Hi Tam,
 
 I'm sorry, but I've never got to updating the documentaion but I've
 created a JIRA to have the docs updated asap, I'll try to update 
 them in the next few days...
 In meantime have a look please at a basic jaxrs demo, the only
 difference
 with what the documentation says is that
 different annotations are used, for ex @GET instead of
 @HttpMethod(Get),
 @Path instead of @UriTemplate and @PathParam instead of 
 @UriParam...
 
 Cheers, Sergey
 
 - Original Message - 
 From: tam.sayers [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Tuesday, March 25, 2008 11:05 AM
 Subject: Re: re[jira] stful uri binding value not set to input parameter
 bean property
 
 

 Hi Sergey

 Thanks for the reply.  The version of the jax-rs implementation in the
 apache-cxf-2.1-incubator-20080321.032844-42.zip seems to be different
 than
 the one described in
 http://cwiki.apache.org/CXF20DOC/jax-rs-jsr-311.html.
 Do you know if there is any documentation anywhere for the newer
 version?

 Tam


 Sergey Beryozkin wrote:

 Hi

 Please try the same with the current JAX-RS implementation in CXF.
 I'm not qute sure why this does not work for the CXF HTTP binding, but
 one
 thing is that
 this binding can be considered depecated...unless someone can confirm
 they're going to mantain it...

 Cheers, Sergey


 I have tried calling the following service using the cxf 2.0.4 and
 2.1
 code
 and when using both the accountNumber is not set to the GetForAccount
 bean.
 When debugging through the code I can see that
 the values are being read from the URL and an XML element is being
 generated
 in the form:

 getTelephoneForAccount
accountNumberab123/accountNumber
 /getTelephoneForAccount

 This is then added to the message but never gets set to the
 GetForAccount
 bean.  Does anybody know why the property is not being set?

 Service definition:

 @WebService(targetNamespace = http://uk.co.jdwilliams/account;)
 public interface AccountTelephoneNumberService {
@Get
@HttpResource(location = /telnos/{accountNumber})
@WebResult(name = telephoneNo)
TelephoneNumberTO getTelephoneForAccount(GetForAccount
 getForAccount);
 }

 input bean:

 public class GetForAccount {
private String accountNumber;

/**
 * @return the accountNumber
 */
public String getAccountNumber() {
return accountNumber;
}

/**
 * @param accountNumber the accountNumber to set

Re: REST-JS

[Sergey Beryozkin]

Hi Arul, Benson

yes, that would be a rather simple thing to do, and in fact you'd likely get 
this JS code (or indeed code in your language of choice) generated for live 
services, as we've introduced SystemQueryHandlers (not sure it's a good name 
though) which are supposed to handle different types of query extensions and 
possibly let the invocation to proceed to the actual object afterwards. For 
example, at the moment, one can debug a live service and check on what format 
it can produce, for example, if it's an Atom-enbaled service then you can try 
?_contentType=json. In this case the only thing the handler does is to update 
the Accept headers on the message.

Likewise, one should be able to do ?_js or ?_lang=js.

That said, supporting extensions like _js has not been prioritized. That would 
be a cool thing to do so if someone in the community is interested then the 
input would be welcomed.

Cheers, Sergey


 There is no existing code to do this, if I follow your definition of a
 'resource object'. It would be only a few days of work to add to the
 existing Javascript generator to add this, I bet. If you post an example of
 what you'd like to see generated that might clarify. I for one wouldn't be
 in a position to tackle the job if I've understood it correctly.
 
 

 Here is my scenario. I have a JAX-RS CXF service. I have a web
 application which consumes this service. Is it possible to generate the
 REST resources as JavaScript so that the web app can use it directly
 when doing a POST (ex: construct the resource object)?






IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: REST-JS

[Sergey Beryozkin]

Hi Benson

For current CXF JAX-RS impl, the idea is to treat queries starting from '_' as system ones, intended for the JAX-RS runtime, such 
that such queries can be distinguished from application-specific ones. We've added SystemQueryHandlers which are invoked before the 
actual target object, so one of such handlers can be created to handle '_js' extension to avoid a clash with ?js support in 
runtime/js...


Cheers, Sergey 



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: JSR-311 and JAXB and JSON

[Sergey Beryozkin]

Hi Doug


So unless there is some JAXB annotation stuff for arrays in java beans,
I'm guessing both the in and out JSON to XML JAXRS convertors may be broken?


This is a grey area for me. Default JSON converter does not do anything but delegating to a Jettison library. Likewise, I'm not sure 
if there's some JAXB annotation which can be used to annotate arrays to give some hint to a JAXB (de)serializer...


Does anyone know what might be happening here ?


i.e., the d2x array soaked up all trailing MachineData bean parameters
in the emitted JSON representation.


I'm just wondering, would it work if a d2x array were placed as the last entry in the CrystalParams's class/schema, as a workaround 
?


Cheers, Sergey



Actually there is something funny going wrong with the JSON
emitted by the JAXRS process. This was just a dummy service to
see the output format:

@GET
@Path(get/{clientId})
@ProduceMime(application/json)
public CrystalParameters dummy(@UriParam(clientId) String id, @HttpContext
UriInfo info) {
CrystalParameters  cpn = new CrystalParameters();
MachineData md = new MachineData();
md.setWavelength(0.7);
md.setD2x(new double[] {1.0,0,0,0,1.0,0,0,0,1.});
md.setBottomOffset(50.);md.setUpperOffset(50.);
md.setLeftOffset(50.); md.setRightOffset(50.);
cpn.setMachineData(md);
return cpn;
}

When I did a wget on this service it gave me JSON:
{CrystalParameters:{machineData:{bottomOffset:50,d2x:
[1,0,0,0,1,0,0,0,1,50,50,50,0.7]}}}

the XML precursor was, from my previous email:

machineDatabottomOffset50.0/bottomOffset
  d2x1.0/d2xd2x0.0/d2xd2x0.0/d2xd2x0.0/d2xd2x1.0/d2x
  d2x0.0/d2xd2x0.0/d2xd2x0.0/d2xd2x1.0/d2x
  leftOffset50.0/leftOffsetrightOffset50.0/rightOffset
  upperOffset50.0/upperOffsetwavelength0.7/wavelength
/machineData

i.e., the d2x array soaked up all trailing MachineData bean parameters
in the emitted JSON representation.

So unless there is some JAXB annotation stuff for arrays in java beans,
I'm guessing both the in and out JSON to XML JAXRS convertors may be broken?

Thanks for any info.
Doug 



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: JSR-311 and JAXB and JSON

[Sergey Beryozkin]

Hi Doug


There's a system test verifying that a json text can be converted into a 
JAXB-annotated
Book class, please see 
systests/jaxrs/JAXRSClientServerBookTest.updateBookWithJSON();

Jettison 1.0 (MappedXMLInputStream) is used as a message body reader for JSON data, can it be that it can not handle the incoming 
JSON stream ? I know that after Dan K has upgraded the version of Jettison he had to update the test Json fragments too...

Another possibility is that  CrystalParameters is not having an @XMLRootElement 
annotation ?

Perhaps a BadgerFishProvider can do better ? Please see a 
systest/jaxrs/JAXRS...SpringProviderTest

Cheers, Sergey


I am just assuming that consuming application/json works ...?
@POST
@Path(init/{clientId})
@ProduceMime(text/plain)
@ConsumeMime(application/json)
public String init(@UriParam(clientId) String id, @HttpContext UriInfo
info, CrystalParameters cp) {
System.out.println(---received the sucker!--);
MultivaluedMap params  = info.getQueryParameters();
// nothing happening here yet ...

String url = /ReflnCover/ + id + /basic;
return url;
}

Thanks
Doug

P.S. I'm using apache-cxf-2.1-incubator-20080306.021818-37.zip under
apache-tomcat-5.5.20 on kubuntu. 



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: JAX-RS sample in 2.1 trunk has wierd behavior on GET

[Sergey Beryozkin]

Hi

I haven't updated the demos after CXF JAX-RS has been upgraded to 0.5 version 
of jsr-311 api as the 0.6 version is already available and it will break the 
user code again. Tomorrow a 0.6 version should become publicly available in the 
java.net maven repository and the demo will be updated in sync with the upgrade 
to 0.6. 

That said, an upgrade to 0.6 may take few days, so we'll do an upgrade to 0.5 
now. Sorry about the hassle...

Have you updated the demo yourself to make it compile with 0.5 ?

Cheers, Sergey


 Hi,
 
 I am trying to run the JAX-RS sample bundled in the 2.1 trunk. I am trying to 
 add /customers/ GET which returns all the customers under that resource. But, 
 I see some wierd behavior when I try to access from the browser. I added 3 
 customers in the init() method which populates the map once the server is 
 started.
 Both the GET calls to /customers and /customers/1 returns 3 customer 
 instances. Here is my sample lookslike:
 
@GET
@Path(/customers/)
public Customers getCustomers() {
System.out.println(invoking getCustomers);
Customers e = new Customers();
e.setCustomer(customers.values());
return e;
}
 
@GET
@Path(/customers/{id}/)
public Customer getCustomer(@UriParam(id) String id) {
System.out.println(invoking getCustomer, Customer id is:  + id);
long idNumber = Long.parseLong(id);
Customer c = customers.get(idNumber);
return c;
}
 
 
 Am I missing something?
 
 Please clarify.
 
 Regards
 Arul



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: JAX-RS sample in 2.1 trunk has wierd behavior on GET

[Sergey Beryozkin]

Hi Arul,

No, I think there's a bug in CXF.


   @GET
   @Path(/customers/)
   public Customers getCustomers() {


should be invoked on /customers

and


   @GET
   @Path(/customers/{id})
   public Customer getCustomer(@UriParam(id) String id) {


should be invoked on /customers/1. Thanks for identifying this issue. we'll fix 
it.
Also, the demos will be updated shortly for them to get compiled with 0.5.

Cheers, Sergey


Yes I did upgrade the demo to 0.5 version. The only change I did to the demo is added a new GET operation for retrieving all 
customers.

Ok I think I found the issue. I changed the Path to /listcustomers instead of 
/customers. This behaved as expected.

Can you confirm if this is correct?

Thanks!
Arul

Sergey Beryozkin wrote:

Hi

I haven't updated the demos after CXF JAX-RS has been upgraded to 0.5 version of jsr-311 api as the 0.6 version is already 
available and it will break the user code again. Tomorrow a 0.6 version should become publicly available in the java.net maven 
repository and the demo will be updated in sync with the upgrade to 0.6.

That said, an upgrade to 0.6 may take few days, so we'll do an upgrade to 0.5 
now. Sorry about the hassle...

Have you updated the demo yourself to make it compile with 0.5 ?

Cheers, Sergey




Hi,

I am trying to run the JAX-RS sample bundled in the 2.1 trunk. I am trying to add /customers/ GET which returns all the 
customers under that resource. But, I see some wierd behavior when I try to access from the browser. I added 3 customers in the 
init() method which populates the map once the server is started.

Both the GET calls to /customers and /customers/1 returns 3 customer instances. 
Here is my sample lookslike:

   @GET
   @Path(/customers/)
   public Customers getCustomers() {
   System.out.println(invoking getCustomers);
   Customers e = new Customers();
   e.setCustomer(customers.values());
   return e;
   }

   @GET
   @Path(/customers/{id}/)
   public Customer getCustomer(@UriParam(id) String id) {
   System.out.println(invoking getCustomer, Customer id is:  + id);
   long idNumber = Long.parseLong(id);
   Customer c = customers.get(idNumber);
   return c;
   }


Am I missing something?

Please clarify.

Regards
Arul





IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland





--
Arul Dhesiaseelan, Flux Development

+1 (406) 656-7398
www.fluxcorp.com

Flux - Java Job Scheduler. File Transfer. Workflow. BPM. 



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: CXF REST problems

[Sergey Beryozkin]

Hi

 First problem that I've noticed is that I can't find the @UriTemplate
 annotation. It's not in the jsr311-api-0.5.jar file where all of the other
 JSR annotations can be found. So, I had a look at the JSR spec, and the
 @Path annotation seemed appropriate so I used that instead. Is that correct?

Yes, 0.5 replaced @UriTemplate with @Path

 Second problem is that I implemented a service using the @Path annotation
 and I'm getting a null pointer exception as described below.

It's a NumberFormatException there, and it's caused by the fact there's no 
expected QueryParam in a request.
You need to use @UriParam instead (please note in 0.6 it will be replaced with 
@PathParam), see below...

 When I try to add @HttpMethod annotations above the @Path annotations I get
 the error The annotation @HttpMethod is disallowed for this location 

Yes, starrting from 0.5 one can use @HttpMethod to create designators, sucg as 
@GET/@[EMAIL PROTECTED]/@DELETE,
so you may for example create @GetRequest if you think it's better than @GET or 
create designators for other http methods

Here's the class :

@Path(/emitterResource)
 public class EmitterResource {
 
@GET
@Path(/getEmitters)
public CollectionEmitter getEmitters() {
return emitterDAO.getAllEmitters();
}

@GET
@Path(/emitters/{emitterId})
public Emitter getEmitter(@UriParam(emitterId) int id) {
LOG.debug(looking for emitter id  + id);
   return emitterDAO.get(id);
}
}

You might want to chnage it like this to minimize a bit the numbner of 
annotations :

@Path(/emitters)
public class EmitterResource {
 
@GET
public CollectionEmitter getEmitters() {
return emitterDAO.getAllEmitters();
}

@GET
@Path({emitterId})
public Emitter getEmitter(@UriParam(emitterId) int id) {
LOG.debug(looking for emitter id  + id);
   return emitterDAO.get(id);
}
}


Hope it helps

Cheers, Sergey



 
 Hi there,
 
 I've been looking through the user group and I haven't been able to find an
 answer to my problem so I thought I'd send a post and see if anyone can help
 me. 
 
 I downloaded the 20080228 and the 20080303 snapshots. What I describe below
 are problems that I have found in both. 
 
 First problem that I've noticed is that I can't find the @UriTemplate
 annotation. It's not in the jsr311-api-0.5.jar file where all of the other
 JSR annotations can be found. So, I had a look at the JSR spec, and the
 @Path annotation seemed appropriate so I used that instead. Is that correct?
 
 Second problem is that I implemented a service using the @Path annotation
 and I'm getting a null pointer exception as described below. I am using
 spring configuration, so here's my spring config file:
 
 beans xmlns=http://www.springframework.org/schema/beans;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xmlns:jaxrs=http://cxf.apache.org/jaxrs;
 xmlns:cxf=http://cxf.apache.org/core;
 xsi:schemaLocation=
 http://www.springframework.org/schema/beans
 http://www.springframework.org/schema/beans/spring-beans.xsd
 http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
 http://cxf.apache.org/bindings/soap
 http://cxf.apache.org/schemas/configuration/soap.xsd
 http://cxf.apache.org/jaxrs http://cxf.apache.org/schemas/jaxrs.xsd;
 
 import resource=classpath:META-INF/cxf/cxf.xml /
 import resource=classpath:META-INF/cxf/cxf-extension-jaxrs-binding.xml
 /
 import resource=classpath:META-INF/cxf/cxf-servlet.xml /
 
  jaxrs:server id=registryEndpoint address=/
jaxrs:serviceBeans
ref bean=emitterResource/
/jaxrs:serviceBeans
  /jaxrs:server
 /beans
 
 Here's the resource file:
 
 @Path(/emitterResource)
 public class EmitterResource {
 
@Path(/getEmitters)
public CollectionEmitter getEmitters() {
return emitterDAO.getAllEmitters();
}

@Path(/emitters/{emitterId})
public Emitter getEmitter(@QueryParam(emitterId) int id) {
//public Emitter getEmitter(@WebParam(name = emitterId) int id) {
   LOG.debug(looking for emitter id  + id);
   return emitterDAO.get(id);
}

@Path(/emitters)
public void addEmitter(@QueryParam(emitter)Emitter emitter) {
LOG.warn(Adding an emitter);
LOG.warn(ID is  + emitter.getId());
LOG.warn(Name is  + emitter.getName());
emitterDAO.save(emitter);
}
 
 When I try to add @HttpMethod annotations above the @Path annotations I get
 the error The annotation @HttpMethod is disallowed for this location 
 
 The Emitter class is just a POJO with an Id and a Name.
 
 Here's a snippet of my client code (I'm using apache commons HttpClient) :
 
   Emitter e = new Emitter();
   e.setId(12345);
   e.setName(Test Name);
   PostMethod post = new
 PostMethod(http://localhost:8080/emitterResource/emitters;);
  
StringWriter stringWriter = new StringWriter();
jaxbMarshaller.marshal(registryObject, stringWriter);
  

Re: CXF REST problems

[Sergey Beryozkin]

Hi,

In this case what happens is that no MessageBodyReader (provider capable of 
getting the input stream data and turning them into Emitter object) has been 
found, thus it's a null and it's an application level error. That said, I need 
to check what the spec says about it, perhaps an exception shouild be raised 
earlier...

What is an Emmiter class ? Is it annotated with JAXB annotatations such as 
@XmlRootElement ?
Does GET works for you, that is can you retrieve an individual Emitter from a 
browser ?

If Emitters are not JAXB-aware then you'd need to register a custom Emitter 
provider, which would know how to serialize/deserialize them. Alertantive you 
might want to use JAXP Source and deal with XML locally...

Actually, I've written it all and just realized that your annotations are not 
correct :

@POST
@Path(/emitters/)
public void addEmitter(@UriParam(emitter)Emitter emitter) {

One can annotate with @UriParam only those parameters which are supposed to be 
substituted as template variables found in your @Path, for ex :

 @PUT
 @Path(/emitters/{id})
 public void addEmitter(@UriParam(id) String id, Emitter emitter) {
 }


So in your case doing just

@POST
@Path(/emitters)
 public void addEmitter(Emitter emitter) {
 }

should work fine, provided your Emitter is JAXB-aware :-)

Give it a try please,
Cheers, Sergey


- Original Message - 
From: daveor [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Wednesday, March 05, 2008 12:37 PM
Subject: Re: CXF REST problems


 
 Hi, and thanks for your reply. I have tried your suggestion, I changed the
 @QueryParam to @UriParam and now I get a different error. Here's the updated
 method:
 
@POST
@Path(/emitters)
public void addEmitter(@UriParam(emitter)Emitter emitter) {
LOG.warn(Adding an emitter);
LOG.warn(ID is  + emitter.getId()); - NullPointerException on
 this line
LOG.warn(Name is  + emitter.getName());
emitterDAO.save(emitter);
} 
 
 
 This is the NullPointerException exception:
 
 FINE: Invoking handleMessage on interceptor
 [EMAIL PROTECTED]
 05-Mar-2008 12:25:05 org.apache.cxf.phase.PhaseInterceptorChain doIntercept
 FINE: Application has thrown exception, unwinding now
 org.apache.cxf.interceptor.Fault
 at
 org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:107)
 at
 org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:95)
 at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:62)
 at
 org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:56)
 at
 org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
 at
 org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:92)
 at
 org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220)
 at
 org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:78)
 at
 org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:92)
 at
 org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:213)
 at
 org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:113)
 at
 org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:170)
 at
 org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFServlet.java:148)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
 at
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
 at
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
 at
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 at
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
 at
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
 at
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
 at
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)
 at
 org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
 at
 org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
 at
 org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
 at
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685)
 at java.lang.Thread.run(Thread.java:619)
 Caused by: java.lang.NullPointerException
 at
 com.westglobal.mscape.registry.EmitterResource.addEmitter(EmitterResource.java:50)
 at 

Re: REST CDATA Marshalling

[Sergey Beryozkin]

Hi,

One way would be to use a CXF JAX-RS implementation. I'm presuming no SOAP is 
involved as Todd is
asking about CDATA in a context of the REST application, right ?
If so, then with JAX-RS one can just return a String which uses CData to 
encapsulate XML..., with no JAXB involved.
JAXB might be used to create the actual XML, but the String will be written 
directly to the output stream or read as is from the input stream...

Cheers, Sergey

 
 Yea, there really is NOT a way to do this with JAXB.   Jaxb doesn't call 
 the writeCData method on the XmlStreamWriter at all, ever.  (I just 
 grepped the source).   The ONLY way I can see to do this would be write 
 a XmlStreamWriter wrapper that wraps the real writer and keeps track 
 of the element it's in and if in the appropriate element, foward the 
 writeCharacters calls to writeCData calls instead.  Not sure how worth 
 it that would be.
 
 Dan
 
 On Saturday 01 March 2008, Todd Orr wrote:
 I'm attempting to get String data wrapped in CDATA before being
 returned to the client. I do not want special characters to be
 escaped. First I tried simply wrapping the properties in my getters
 with the CDATA block. Unfortunately, JAXB continued to escape all the
 special characters.

 I found this post:
 http://forum.java.sun.com/thread.jspa?threadID=607524messageID=353193
1. Although promising, I could not find out how to setup JAXB in my
 applicationContext in such a way to set this as the XMLSerializer.

 Has anyone accomplished this? It seems as though it would be a fairly
 common need.

 Thanks,
 T
 
 
 
 -- 
 J. Daniel Kulp
 Principal Engineer, IONA
 [EMAIL PROTECTED]
 http://www.dankulp.com/blog


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: Restful Declarative security?

[Sergey Beryozkin]

Hi

jsr-311 api 0.6 introduces a SecurityContext[1] to be available to a user code.

Using Acegi (provided Acegi is enhanced a bit) as originally suggested by Donal 
seems like a more scalable solution in terms of the code maintenance. 

Cheers, Sergey

[1] https://jsr311.dev.java.net/nonav/releases/0.6/index.html

- Original Message - 
From: Arundel, Donal [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Tuesday, February 19, 2008 4:18 PM
Subject: RE: Restful Declarative security?


Hi again Barry,

While I haven't tried this myself yet I imagine that an alternate
feasible approach would be to use the ACEGI AOP support for annotations
to allow you to associate roles with the JAX-RS implementation classes.

ACEGI can be used to do a certain level of Authentication and
authorization at the Servlet Filter level, limited to specifying Roles
for a given RESt resource as mentioned in my post below.
However ACEGI can also can be used to provide authorization level
support for implementation code via its use of AOP and annotations (see
the ACEGI docs for the Aspect-J and AOP-Alliance AOP implementations).

This approach would possibly allow you to achieve what you want without
needing to extend ACEGI.

Maybe have a look at:

http://www.acegisecurity.org/

Personally I'm not a huge fan of deployment specific annotations being
embedded directly in code though, I would prefer the approach mentioned 
in my first mail. Security Roles are usually deployment specific data
and supplying the actual values via annotations has operational
consequences in terms of deployment, administration, and ease of
modification.
Obviously whether something is appropriate depends on many factors,
and it might be okay for you.

Cheers,
 Donal 

-Original Message-
From: Arundel, Donal [mailto:[EMAIL PROTECTED] 
Sent: 19 February 2008 12:50
To: cxf-user@incubator.apache.org
Subject: RE: Restful Declarative security?

Hi Barry,

I have recently noticed that it would be a nice extension to ACEGI to
support REST in this fashion. I personally think that URL pattern-based 
RBAC ACL would work really nicely with ACEGI and REST.

ACEGI doesn't provide the ability to specify ACL based on the type of
HTTP operation involved.
This means that ACEGI doesn't naturally support REST out of the box,
if you care about modification versus view semantics (which you do).

The syntax ACEGI uses to specify the RBAC ACL patterns would need to be
overhauled a bit to support this in an ergonomic fashion.
It seems like this would be a very nice and very reusable little project
though :-)

Cheers,
 Donal


-Original Message-
From: Barry Fitzgerald [mailto:[EMAIL PROTECTED] 
Sent: 19 February 2008 10:24
To: cxf-user@incubator.apache.org
Subject: Restful Declarative security?

Hi all,

Just a general question - I'm using the JAX-RS implementation in CXF 2.1
for
writing services and I have a requirement to secure certain aspects of
the
service.

For example - I want everyone to be able to read a user but only certain
people to update to a user. In a Restful these two calls would both be
passed to the same url (update a POST, read a GET)

Almost all security solutions I know simply protect URL's and can't
protect
a url for POST's but not for GET's.

Has anyone else come across this problem? Any solutions/ workarounds?

Obviously I could protect the calls programmatically but this seems a
step
backwards.

Thanks,

Barry


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
Ireland


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: JAX-RS API version change

[Sergey Beryozkin]

Hi

This update is in place now, so if you're using CXF JAX-RS then please give it 
a try.

Please note that a newer 0.6 version is already available, and from the user's 
perspective,
upgrading to 0.6 will mean that existing @UriParam annotations will need to be 
replaced with
@PathParam ones. It seems like the only change in 0.6 which can affect the 
existing user's code.
0.6 jar is not available on Maven yet, so this upgrade will be done a bit later

Cheers, Sergey



- Original Message - 
From: Sergey Beryozkin [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Friday, February 15, 2008 4:55 PM
Subject: JAX-RS API version change


Hi

Currently, the CXF JAX-RS implementation depend upon a 0.4 version of the 
jaxrs-api.
I'm looking into upgrading it to support a latest 0.5 version.

There're some changes from 0.4 to 0.5 which would affect users.
The following is the list of what has changed between 0.4 and 0.5 which will or 
may have an effect on the
current JAX-RS applications built on top of CXF :

1. @HttpMethod annotation is no longer supported, instead
@GET, @POST, @PUT and @DELETE annotations will be used
2. @UriTemplate is not longer supported, @Path is used instead

3. EntityProvider interface has gone too, instead it has been split into two 
interfaces,
MessageBodyReader and MessageBodyWriter. If you provide custom providers and 
you'd like to have the same instance to handle both reads and writes, then 
you'd have to have its class implementing both interfaces.

Existing spring configuration for injecting custom providers won't get changed, 
the runtime will sort difrerent types of handlers
into the right lists itself...

Cheers, Sergey





IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: JAX-RS API version change

[Sergey Beryozkin]

Client API It's not part of the spec (at the moment). It's something Jersey 
will provide

Cheers, Sergey

- Original Message - 
From: Daniel Kulp [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Monday, February 25, 2008 4:26 PM
Subject: Re: JAX-RS API version change


 
 Just to be clear:
 
  I do have a question. 0.6 started implementing a REST client API.
  Does CXF plan to use this Client API or do you suggesting using the
  HTTP Client used in samples?
 
 If it's part of the spec, then yes, we do plan on providing it, just 
 probably not immediately.   The server side parts are a bit higher 
 priority to the folks that are paying us to work on it.  :-)
 
 However, if folks would like to jump in and help, feel free to start 
 raising jira issues, submit patches, etc   We'd LOVE to have the 
 extra help.
 
 Dan
 
 
 On Monday 25 February 2008, Sergey Beryozkin wrote:
 Hi,

  This is cool. Did you update the JAX-RS sample too?

 No, will do as part of the next patch, thanks for pointing it out..

  I do have a question. 0.6 started implementing a REST client API.
  Does CXF plan to use this Client API or do you suggesting using the
  HTTP Client used in samples?

 This is not a priority for CXF JAX-RS at the moment. Yes, that Client
 API looks cool, but I believe it's not something CXF JAX-RS users
 can't live without at this moment of time :-). Things like providing a
 UriInfo implementation, support for types like byte[], improving the
 URITemplating, etc are of higher priority at the moment.

  Thank you
  Arul

 Cheers, Sergey

 
 IONA Technologies PLC (registered in Ireland)
 Registered Number: 171387
 Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
 Ireland
 
 
 
 -- 
 J. Daniel Kulp
 Principal Engineer, IONA
 [EMAIL PROTECTED]
 http://www.dankulp.com/blog


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: JAX-RS API version change

[Sergey Beryozkin]

Well, my comment still stands.   Any help adding it to CXF would be 
greatly appreciated.   :-)


+1 :-)

Cheers, Sergey




Client API It's not part of the spec (at the moment). It's something
Jersey will provide


Oh.  Ok.  

Well, my comment still stands.   Any help adding it to CXF would be 
greatly appreciated.   :-)


Dan


On Monday 25 February 2008, Sergey Beryozkin wrote:


Cheers, Sergey

- Original Message -
From: Daniel Kulp [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Monday, February 25, 2008 4:26 PM
Subject: Re: JAX-RS API version change

 Just to be clear:
  I do have a question. 0.6 started implementing a REST client API.
  Does CXF plan to use this Client API or do you suggesting using
  the HTTP Client used in samples?

 If it's part of the spec, then yes, we do plan on providing it, just
 probably not immediately.   The server side parts are a bit higher
 priority to the folks that are paying us to work on it.  :-)

 However, if folks would like to jump in and help, feel free to start
 raising jira issues, submit patches, etc   We'd LOVE to have the
 extra help.

 Dan

 On Monday 25 February 2008, Sergey Beryozkin wrote:
 Hi,

  This is cool. Did you update the JAX-RS sample too?

 No, will do as part of the next patch, thanks for pointing it out..

  I do have a question. 0.6 started implementing a REST client API.
  Does CXF plan to use this Client API or do you suggesting using
  the HTTP Client used in samples?

 This is not a priority for CXF JAX-RS at the moment. Yes, that
 Client API looks cool, but I believe it's not something CXF JAX-RS
 users can't live without at this moment of time :-). Things like
 providing a UriInfo implementation, support for types like byte[],
 improving the URITemplating, etc are of higher priority at the
 moment.

  Thank you
  Arul

 Cheers, Sergey

 
 IONA Technologies PLC (registered in Ireland)
 Registered Number: 171387
 Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
 Ireland

 --
 J. Daniel Kulp
 Principal Engineer, IONA
 [EMAIL PROTECTED]
 http://www.dankulp.com/blog


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
Ireland




--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: Creating a REST service from a schema

[Sergey Beryozkin]

Hi Brad

 I prefer the XML first approach and would like to build a RESTful
 service which either can use my already generated XMLBeans classes
 (prefered option) or generate JAXB java binding classes from my
 schema.

No problems for a JAXB option, it should work just fine. CXF 
JAXBElementProvider checks if @XMLRootAnnotation is present. 
Fox XMLBeans, a simple custom provider would need to be added. Perhaps we 
should have it supported by default. Barry has added a system test showing how 
to write a JSON BadgerFish JAX-RS Provider  (I was actually very surprised to 
find out BadgerFish is a real thing which lives in the Jettison project)

Cheers, Sergey 


 Hi,
 
 I'm interested in using the jax-rs support in CXF. From the examples
 I've seen it appears that I'm required to take that Java first
 approach and let JAXB take care of the Java to XML mapping. Is this
 correct?
 
 I prefer the XML first approach and would like to build a RESTful
 service which either can use my already generated XMLBeans classes
 (prefered option) or generate JAXB java binding classes from my
 schema.
 
 Is this possible? The important things here for me are to have the
 schema dictate what the XML looks like and to have it as a REST
 service. If its not possible using JAX-RS, does CXF have an
 alternative method to achieve the desired results?
 
 Thanks,
 Brad.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: Servlet.service() for servlet CXFServlet exception

[Sergey Beryozkin]

Hi

 thanks again for your insights on the matter.

I wish I could be more helpful than just advising you to debug it all yourslef 
:-)

Have a look in the cxf systests module, you'll find jax-rs system tests there.

Did you try to run your application in a standalone Tomcat ? 

Cheers, Sergey



- Original Message - 
From: rm-ramos [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Tuesday, February 19, 2008 4:31 PM
Subject: Re: Servlet.service() for servlet CXFServlet exception


 
 Hi Sergey, and thanks again for your insights on the matter.
 
 The fact is that is I launch my server from a main() method, using a
 JAXRSServerFactoryBean as described on the cxf's user manual, everything
 runs smoothly and I have no problem accessing the data from a web browser,
 for ex.
 
 Don't think the problem (back to JBoss) is the content-type either, been
 doing some experiments with 'Poster' (the firefox extension) and the results
 haven't been any different.
 
 I couldn't find the sample you talked about,
 BookServerResourceCreatedSpring. Can you please tell me where to find it?
 
 Thanks again,
 Rui Ramos
 
 
 
 Hi
 
 It seems to be a lower-level CXF issue, ChainInitiationObserver.java:93
 shows this code in my snapshot :
 
 exchange.put(Bus.class, bus);
 
 which is harmlessPerhaps the fact that a content type is set to null
 causes the problem.
 
 Still it's likely that Endpoint which ChainInitiationObserver deals with has
 not been set up properly...
 Is there any chance you can try to run your server using a simple main(),
 without JBoss involved ?
 
 For ex, have a look at BookServerResourceCreatedSpring. It runs a server
 using a /jaxrs_spring resource folder which has beans.xml, 
 so just update it to refer to your web-app folder and try to get resources
 from a browser. It will help narrow the problem.
 
 Cheers, Sergey
 
 -- 
 View this message in context: 
 http://www.nabble.com/JAX-RS-%22No-service-found%22-using-Spring-and-JBoss-tp15461660p15561555.html
 Sent from the cxf-user mailing list archive at Nabble.com.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: Servlet.service() for servlet CXFServlet exception

[Sergey Beryozkin]

Hi

It seems to be a lower-level CXF issue, ChainInitiationObserver.java:93 shows 
this code in my snapshot :

exchange.put(Bus.class, bus);

which is harmlessPerhaps the fact that a content type is set to null causes 
the problem.

Still it's likely that Endpoint which ChainInitiationObserver deals with has 
not been set up properly...
Is there any chance you can try to run your server using a simple main(), 
without JBoss involved ?

For ex, have a look at BookServerResourceCreatedSpring. It runs a server using a /jaxrs_spring resource folder which has beans.xml, 
so just update it to refer to your web-app folder and try to get resources from a browser. It will help narrow the problem.


Cheers, Sergey

- Original Message - 
From: rm-ramos [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Monday, February 18, 2008 4:03 PM
Subject: Re: Servlet.service() for servlet CXFServlet exception




Hi,

Thanks for your reply Sergey. I managed to solve the problem, it actually
was a JBoss config issue...

Now, however, I'm facing new problems deploying my JAX-RS based web service.
On accessing /services/, I already find it listed as it should be, but when
I try to call the service I get a 500 Server Error in return. From JBoss
logs, I found out the exception being raised:

INFO: URIParameterInterceptor handle message on path [/workorder/6] with
content-type [null]
15:53:15,008 ERROR [[CXFServlet]] Servlet.service() for servlet CXFServlet
threw exception
java.lang.NullPointerException
at
org.apache.cxf.transport.ChainInitiationObserver.setExchangeProperties(ChainInitiationObserver.java:93)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:59)
at
org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletDestination.java:79)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:256)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:123)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:170)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.doGet(AbstractCXFServlet.java:152)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
com.criticalsoftware.wow.presentation.CookieFilter.doFilter(CookieFilter.java:61)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)

Any thoughts on this one?
Thanks in advance,
Rui Ramos

--
View this message in context: 
http://www.nabble.com/JAX-RS-%22No-service-found%22-using-Spring-and-JBoss-tp15461660p15546908.html
Sent from the cxf-user mailing list archive at Nabble.com. 



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: JAX-RS API version change

[Sergey Beryozkin]

I've got it mostly finished, but I'm going to add few more tests before 
supplying a patch
Cheers, Sergey

- Original Message - 
From: Sergey Beryozkin [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Friday, February 15, 2008 4:55 PM
Subject: JAX-RS API version change


Hi

Currently, the CXF JAX-RS implementation depend upon a 0.4 version of the 
jaxrs-api.
I'm looking into upgrading it to support a latest 0.5 version.

There're some changes from 0.4 to 0.5 which would affect users.
The following is the list of what has changed between 0.4 and 0.5 which will or 
may have an effect on the
current JAX-RS applications built on top of CXF :

1. @HttpMethod annotation is no longer supported, instead
   @GET, @POST, @PUT and @DELETE annotations will be used
2. @UriTemplate is not longer supported, @Path is used instead

3. EntityProvider interface has gone too, instead it has been split into two 
interfaces,
MessageBodyReader and MessageBodyWriter. If you provide custom providers and you'd like to have the same instance to handle both 
reads and writes, then you'd have to have its class implementing both interfaces.


Existing spring configuration for injecting custom providers won't get changed, 
the runtime will sort difrerent types of handlers
into the right lists itself...

Cheers, Sergey





IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

JAX-RS API version change

[Sergey Beryozkin]

Hi

Currently, the CXF JAX-RS implementation depend upon a 0.4 version of the 
jaxrs-api.
I'm looking into upgrading it to support a latest 0.5 version.

There're some changes from 0.4 to 0.5 which would affect users.
The following is the list of what has changed between 0.4 and 0.5 which will or 
may have an effect on the
current JAX-RS applications built on top of CXF :

1. @HttpMethod annotation is no longer supported, instead
@GET, @POST, @PUT and @DELETE annotations will be used
2. @UriTemplate is not longer supported, @Path is used instead

3. EntityProvider interface has gone too, instead it has been split into two 
interfaces,
MessageBodyReader and MessageBodyWriter. If you provide custom providers and 
you'd like to have the same instance to handle both reads and writes, then 
you'd have to have its class implementing both interfaces.

Existing spring configuration for injecting custom providers won't get changed, 
the runtime will sort difrerent types of handlers
into the right lists itself...

Cheers, Sergey





IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: JAX-RS No service found using Spring and JBoss

[Sergey Beryozkin]

Hi

I think someone was able to run a JAX-RS HTTPS demo in a tomcat container.
I myself has always been confused about the way CXFServlet matches requests.
Can you please try /rest in both the spring config and URLTemplate ?

If you could run your Tomcat in a debugger then it would be ideal in 
identifying what is
exactly happening. I use http://www.eclipsetotale.com/tomcatPlugin.html in 
Eclipse,
copy it into eclipse plugins, then launch it from your workspace by pointing it 
to your
Tomcat installation and have a breakpoint set in a CXF ServletController.

As far as JAX-RS vs HTTP Binding is concerned, JAX-RS is the future so to say 
:-) because it's going to
be a standard way to do RESTful services inthe Java world...

Cheers, Sergey


- Original Message - 
From: rm-ramos [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Wednesday, February 13, 2008 6:00 PM
Subject: JAX-RS No service found using Spring and JBoss




Hi guys,

I'm trying to move from HTTP-Binding RESTful services to the new Java
standard JAX-RS using CXF+Spring, deployed on JBoss.
However I can't seem to make it work due to a No service found problem.
I've been trying to get help from multiple sources, including CXF's IRC
channel, but unfortunately there's not so much written about this. I've
tried to base my config in the CXF docs as much as I could, but still no
luck.


So, moving on to the interesting part:

My web.xml contains the CXFServlet declaration, mapped on
servlet-mapping
servlet-nameCXFServlet/servlet-name
url-pattern/services/*/url-pattern
/servlet-mapping

On beans.xml: (not actually how we call it but..)
!-- RESTful web services --
  jaxrs:server id=workOrderOperations address=/rest/
jaxrs:serviceBeans
  bean class=com.messaging.webservices.WorkOrderOperations /
/jaxrs:serviceBeans
  /jaxrs:server

And on to the implementing class:
   @UriTemplate(/rest/)
   public class WorkOrderOperations {
   (..)
   @HttpMethod(GET)
   @UriTemplate(/wo/{id}/)
   public String getWorkOrder(@UriParam(id) String id){return it works!
#+id;}



So, and if I got it right, http://localhost/app-name/services/rest/wo/123
should output a string, but instead a not-so-nice No service found message
shows up. And i've tried almost every possible URI, can never find a
service. Is there anything else I'm missing?
I think the CXFServlet is mapped correctly, but I'm not so sure if the
service is being registered somewhere (or where..), so I would really thank
you if you could help me out on this one. 
It's been 3 days on this now :\


Thanks,
Rui Ramos

PS. I've already though on sticking with HTTP-Bindings ftm, since I'm
starting to lose hope on this one. What are your thoughts about implementing
a REST service using bindings vs. jaxrs, both present and future
implications?
--
View this message in context: 
http://www.nabble.com/JAX-RS-%22No-service-found%22-using-Spring-and-JBoss-tp15461660p15461660.html
Sent from the cxf-user mailing list archive at Nabble.com.



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: JAX-RS custom provider spring config

[Sergey Beryozkin]

Hi Barry

Lets move a discussion on
https://issues.apache.org/jira/browse/CXF-1425

to this list.

In summary, 
we're discussing with Barry whether a list of JAX-RS Entity Providers (which 
know how to marshal/unmarshal given types) as configured in a given spring xml, 
should override a default list or not.

IMHO it should not be the case. It would put a strain on users. Users do not 
need to know about the fact that a given Book class will only be marshalled if 
a JAXB-aware provider is installed. If a given set of returned types is large 
then it will get complicated. User just need to know about the content type, 
XMLRootElement and similar things. Users do not need to know about class names 
for individual default providers, this will form some sort of a contract 
between a runtime and a user thus making it more difficult for us to change the 
things under the hood.

For example, we can configure a Jetty handler, say we can add a Jetty handler. 
When doing it we do not need to specify all other types of handlers jetty 
may've set up under the hood. I belive we should follow the same practice in 
this case.

As far as duplicates is concnerned : this is easy, lets just have a Set of full 
class names for individual providers. That would do for a start.

Thoughts ?

Cheers, Sergey




- Original Message - 
From: Beryozkin, Sergey [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Thursday, February 07, 2008 1:20 PM
Subject: RE: JAX-RS custom provider spring config


Hi Barry

This would be a nice addition, so that a collection of providers can be
registered. 

Cheers, Sergey

-Original Message-
From: Barry Fitzgerald [mailto:[EMAIL PROTECTED] 
Sent: 07 February 2008 12:29
To: cxf-user@incubator.apache.org
Subject: JAX-RS custom provider spring config

Hi,

Just wondering is it possible to register a custom provider to the
server
using the spring config?

Thanks,

Barry


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: Question on URI resolution and WS endpoints.

[Sergey Beryozkin]

Hi

I'm not sure you can achive it with CXF-specific REST bindings but it's most 
likely you can do it
(I hope pretty easily) with the CXF JAX-RS implementation.

Here's the way Servers and Server resources may look like. I belive there's no 
need to specifically annotate ResultySet class in this case. 

@UriTemplate(/servers)
public class Servers {

  @HttpMethod
  public Source getAll() {
return serversConvertedToSource;
  }

  // sub-resource locator

  @UriTemplate({server})
  public Server getServer(@UriParam String server)  {
   // use server id to find a Server instance
   return server;
  }
}

@UriTemplate(/servers/{server})
public class Server {

 @HttpMethod
 public Response getState() {
 } 

  @HttpMethod
  @UriTemplate(resultsets)
  public Source getAllResultSets()  {
  return resultSetsConvertedToSource;
  }

  // sub-resource locator  
  @UriTemplate(resultsets/{id})
  public ResultSet getResultSet(@UriParam String id)  {
  return resultSet;
  }
}

1. /Servers should be handled by Servers.getAll(), 
2. /Servers/1 should be handled by an individual Server.getState(), preliminary 
routed through a subresource locator Servers.getServer()
3. /Servers/1/resultsets and /Servers/1/resultsets/1 will be handled by an 
individual Serve instance

It's likely that some chnages may need to be done to the above classes to make 
them work with CXF JSR 311 impl.
For ex it supports DOMSource only at the moment, not sure about Response, about 
its ability to match GET to @HttpMethod annotated methods starting with 'get' 
(so @HttpMethod(name=GET) may need to be used), etc...
We haven't had time and resources yet to polish CXF JSR311 but it's going to 
happen, sooner rather than later...
And as I said earlier, most of the issues which may need to be fixed are quite 
trivial thus patches are welcome :-)

Cheers, Sergey




- Original Message - 
From: James Mello [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Wednesday, January 30, 2008 9:52 PM
Subject: Question on URI resolution and WS endpoints.


So I've got the following scenario. I'd like to have the following URI's 
available for use using the REST paradigm.

/Servers returns a list of servers

/Servers/{server} returns info about a specific server

/Servers/{server}/ResultSets returns info about the result sets contained on a 
server

/Servers/{server}/ResultSets/{resultSet} returns info about a particular result 
set on a server.

The thing is I want have the requests to the following URIs to go to a server 
object

/Servers/
/Servers/{server}

while requests to

/Servers/{server}/ResultSets/
/Servers/{server}/ResultSets/{resultSets} to go to a ResultSet object.

I've currently got the following configuration and classes (note, most of this 
probably doesn't work as I've been mucking with things quite a bit):

Spring Config:

?xml version=1.0 encoding=UTF-8?
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:jaxws=http://cxf.apache.org/jaxws;
xsi:schemaLocation=
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxws
http://cxf.apache.org/schemas/jaxws.xsd;

import resource=classpath:META-INF/cxf/cxf.xml/
import 
resource=classpath:META-INF/cxf/cxf-extension-http-binding.xml/
import resource=classpath:META-INF/cxf/cxf-servlet.xml/

!-- jaxws:endpoint id=CCM
implementor=com.atsid.test.ResultSetsImpl
address=/Resources/Servers
bindingUri=http://apache.org/cxf/binding/http;
jaxws:serviceFactory
bean 
class=org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean
property name=wrapped value=false /
/bean
/jaxws:serviceFactory
/jaxws:endpoint --

jaxws:endpoint id=Servers
implementor=com.atsid.test.Servers
address=/Resources
bindingUri=http://apache.org/cxf/binding/http;
jaxws:serviceFactory
bean 
class=org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean
property name=wrapped value=false /
/bean
/jaxws:serviceFactory
/jaxws:endpoint
/beans

Servers class:

package com.atsid.test;

import java.util.ArrayList;
import java.util.List;

import javax.jws.WebService;

import org.codehaus.jra.Get;
import org.codehaus.jra.HttpResource;

@WebService
public class Servers
{
  private ListString servers = new ArrayListString();

  public Servers()
  {
servers.add(nun);
servers.add(jackson);
  }

  @Get
  @HttpResource(location=/Servers)
  public ListString 

Re: JSON and JAX-RS

[Sergey Beryozkin]

Hi

String is supported already, not sure if more work is needed to support 
primitive types, it would be trivial to do


Cheers, Sergey

- Original Message - 
From: Vespa, Anthony J [EMAIL PROTECTED]
To: Daniel Kulp [EMAIL PROTECTED]; cxf-user@incubator.apache.org
Sent: Wednesday, January 23, 2008 2:12 AM
Subject: RE: JSON and JAX-RS


Interesting.  Would that mean I would have to use seekAlso and list all of the 
objects that could possibly be returned - I have currently about six types of 
custom objects.  What if I was returning a type like a boolean or just a string?



From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Tue 1/22/2008 5:31 PM
To: cxf-user@incubator.apache.org
Cc: Vespa, Anthony J
Subject: Re: JSON and JAX-RS




Well, looking at the code, it seems to create a new JAXBContext for each
top level type, which really sucks.   IMO, it should use our
JAXBDatabinding in some way which would allow it/you to configure things
via spring or something so one one JAXBContext is created/used that
would have all the required types in it.   Actually, checking if there
is an ObjectFactory in the package and creating the context based on
that would also go a long way to helping. 

That said,  with JAXB 2.1, you can probably add an @XmlSeeAlso annation
on the wsResponse that points to the wsMessage to make the JAXBContext
for the wsResponse be able to marshal the wsMessage as well.

Dan


On Tuesday 22 January 2008, Vespa, Anthony J wrote:
 So I spent some time playing with JAX-RS and I seem to have
 encountered an issue.

 I can return single objects from my service as JSON (standard Java
 types as well as my custom objects) but if I try to return my wrapper
 object which contains an anytype generic list, I get an exception.

 Effectively I have an object called wsResponse that, in this case, is
 returning an array of messages (wsMessage) - I have decorated both
 objects with the XMLType.  I am looking into this exception and see
 references to JAXB; is it possible to get around this?



 Jan 22, 2008 4:45:26 PM
 org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor handleMessage
 INFO: Available content types for response is: application/json,
 Jan 22, 2008 4:45:26 PM
 org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor handleMessage
 INFO: Response EntityProvider is:
 org.apache.cxf.jaxrs.provider.JSONProvider
 Jan 22, 2008 4:45:26 PM
 org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor handleMessage
 INFO: Response content type is: application/json
 javax.xml.bind.MarshalException
  - with linked exception:
 [javax.xml.bind.JAXBException: class com.cbs.bos.data.ws.wsMessage nor
 any of its super class is known to this context.]
 at
 com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:2
95 )
 at
 com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java
:1 48)
 at
 org.apache.cxf.jaxrs.provider.JSONProvider.writeTo(JSONProvider.java:9
0) at
 org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.handleMessage(JAX
RS OutInterceptor.java:99)
 at
 org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
rC hain.java:208)
 at
 org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(Outg
oi ngChainInterceptor.java:74)
 at
 org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
rC hain.java:208)
 at
 org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitia
ti onObserver.java:78)
 at
 org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletD
es tination.java:79)
 at
 org.apache.cxf.transport.servlet.ServletController.invokeDestination(S
er vletController.java:264)
 at
 org.apache.cxf.transport.servlet.ServletController.invoke(ServletContr
ol ler.java:123)
 at
 org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXF
Se rvlet.java:170)
 at
 org.apache.cxf.transport.servlet.AbstractCXFServlet.doGet(AbstractCXFS
er vlet.java:152)
 at
 javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at
 javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
ca tionFilterChain.java:290)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
lt erChain.java:206)
 at
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVa
lv e.java:233)
 at
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextVa
lv e.java:175)
 at
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.ja
va

 :128)

 at
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.ja
va

 :102)

 at
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValv
e. java:109)
 at
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java
:2 63)
 at
 

Re: JAX-RS maturity

[Sergey Beryozkin]

Hi

 At the moment I'm siding towards using JAX-RS via the CXF implementation
 provided it is pretty stable.

If you look at the JAX-RS code you can see it's a pretty simple code and 
there's a space for
a number of enhancements there. Jervis has already done a lot there, and the 
ability to integrate JAX-RS services through Spring configuration with the core 
CXF runtime is probably the most critical enhancement. 
You can expect a better support for multiple formats coming in, perhaps we can 
see some other features added for it to keep up with Jersey and indeed 
outperform it in some areas. 
In the end of the day it's quite a simple specification (JSR 311) so hopefully 
if you find that some features you'd expect from the CXF implementation missing 
then it would be simple to add a patch...

Cheers, Sergey 


 
 Hi,
 
 I'm currently deciding on a REST framework to use for an upcoming project
 and have been looking at a number of possibilities including CXF.
 
 Just a few quick questions. How mature is the JAX-RS implementation? Will
 there be a lot of changes in the near future? Have any of you had experience
 with the Jersey implementation of the JSR311 standard, and if so how does it
 compare to the CXF implementation?
 
 At the moment I'm siding towards using JAX-RS via the CXF implementation
 provided it is pretty stable.
 
 Cheers.
 -- 
 View this message in context: 
 http://www.nabble.com/JAX-RS-maturity-tp15039120p15039120.html
 Sent from the cxf-user mailing list archive at Nabble.com.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: Leaving CXF for Glasshfish Metro

[Sergey Beryozkin]

 After spending about 2 weeks trying to get a very simple service to
 return JSON in CXF, I found the Glassfish Metro project and it's
 jaxws-json plugin.

What's the point of this post ? Say to the world that you're not happpy with 
CXF ?
Or tell everyone that you could've commited a patch after spending 2 days on it 
but just didn't get enough time :-) ?

Cheers, Sergey



- Original Message - 
From: jonathan doklovic [EMAIL PROTECTED]
To: cxfuser cxf-user@incubator.apache.org
Sent: Wednesday, January 23, 2008 2:37 PM
Subject: Leaving CXF for Glasshfish Metro


 Hi,
 
 After spending about 2 weeks trying to get a very simple service to
 return JSON in CXF, I found the Glassfish Metro project and it's
 jaxws-json plugin.
 
 I gave it a shot and after 2 hours had my service up and running.
 Not only that, but the plugin generates pretty api docs at the endpoint
 for me as well as generates a javascript client on the fly.
 
 It was just too easy to make me stick with CXF.
 
 I think CXF is probably a good framework, but the docs and examples are
 in pieces and without real life end-to-end tutorials, it's really hard
 to get things working.
 
 - Jonathan


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: Flex and CXF

[Sergey Beryozkin]

My understanding is that for Flex (or indeed Silverlight and similar 
technologies) to work with a given service all that needs to be done is, in 
case of Flex, to have some MXML[1] created (tools would do it typically) which 
would link to a service, but for the purpose of the demo it can be done 
manually. And Flex server side libs should be added to a runtime classpath of a 
given application.

Have you done some Flex before ? It would be interesting to know what need to 
be dome to FLEX-ify, say, a basic JAX-RS demo.

Cheers, Sergey

[1] http://en.wikipedia.org/wiki/MXML

- Original Message - 
From: Vespa, Anthony J [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Wednesday, January 23, 2008 2:09 PM
Subject: Flex and CXF


Just curious if anyone has experiences (good/bad/other) working with
Flex and web services in CXF?  Any input on pitfalls or approaches is
appreciated.

Thx,

Tony


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: Leaving CXF for Glasshfish Metro

[Sergey Beryozkin]

If all anyone hears about a project is how great it is and never hears
why people choose not to use it, then it never progresses.


fair enough, it's a good point

Cheers, Sergey


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: JAXB Unmarshalling

[Sergey Beryozkin]

That's pretty interesting all right.

I would say that there might not be much point in dealing directly with 
JAXBContext and pretend
that your code is so light and free :-)

Cheers, Sergey

- Original Message - 
From: Liu, Jervis [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Thursday, December 20, 2007 7:18 AM
Subject: RE: JAXB Unmarshalling


 
 -Original Message-
 From: Sergey Beryozkin [mailto:[EMAIL PROTECTED]
 Sent: 2007年12月19日 22:40
 To: cxf-user@incubator.apache.org
 Subject: Re: JAXB Unmarshalling
 
 By the way, can this approach (which uses JAXBContexts) work for you in
 CXF? :
 
 http://weblogs.java.net/blog/mhadley/archive/2006/03/restful_web_ser_1.
 html
 
 [Liu, Jervis] You don’t have to use JAX-WS Dispatch API in this case. Once 
 you grab the InputStream from HTTPClient (or other lightweight http client 
 stack), you can call JAXB to marshal the response to your Customer object. 
 There is no point to use a heavy stack like a JAX-WS runtime to do such a 
 simple task. Following code snippet should do the job: 
 
public Object getObjectFromInputStream (ClassObject type,  InputStream 
 is) {
try {
JAXBContext context = getJAXBContext(type);
Unmarshaller unmarshaller = context.createUnmarshaller();
return unmarshaller.unmarshal(is);
} catch (JAXBException e) {
e.printStackTrace(); 
}
 
return null;
}
 
private JAXBContext getJAXBContext(Class type) throws JAXBException {
synchronized (jaxbContexts) {
JAXBContext context = jaxbContexts.get(type);
if (context == null) {
context = JAXBContext.newInstance(type);
jaxbContexts.put(type, context);
}
return context;
}
}
 
static MapClass, JAXBContext jaxbContexts = new WeakHashMapClass, 
 JAXBContext();
 
 You'd still need a schema describing the data like Customer, etc...
 Cheers. Sergey
 
 
 
 - Original Message -
 From: Eric Le Goff [EMAIL PROTECTED]
 To: cxf-user@incubator.apache.org
 Sent: Tuesday, December 18, 2007 4:34 PM
 Subject: JAXB Unmarshalling
 
 
 I am going on playing with the restful_jaxrs sample demo
 
 
  In the Client.java there are these lines
 
  ...
  URL url = new
 URL(http://localhost:9000/customerservice/customers/123;);
 InputStream in = url.openStream();
 System.out.println(getStringFromInputStream(in));
  
 
 
  What if I did not want to display the XML content (ie the XML
  representation of customer whose Id is 123)
  But rather I would like to get the actual instance of Customer with id is 
  123
 
  Is there some Unmarshalling method to do that , something like
 
  ...
  URL url = new
 URL(http://localhost:9000/customerservice/customers/123;);
 InputStream in = url.openStream();
 
  // Hypothetic code
  Customer customer = (Customer) getObjectFromInputStream(in);
  ...
 
  How would I implement this
 
  Object getObjectFromInputStream(InputStream in)
 
  method ?
 
  I guess I would have to get a JaxbContext before I can get an
 Unmarshaller ?
 
 
  Thanks for your help
 
  Eric
 
 
 
 
  --
  Eric Le Goff
 
 
 IONA Technologies PLC (registered in Ireland)
 Registered Number: 171387
 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
 
 
 IONA Technologies PLC (registered in Ireland)
 Registered Number: 171387
 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: JAXB Unmarshalling

[Sergey Beryozkin]

This is a nice refactoring effort and indeed the code looks simplier.

My point was not really to do with the fact that the code in your original 
proposal was a bit verbose.

IMHO it's kind of trying to catch 2 rabbits at the same time : attempt to write 
just a simple HTTP code and still expect the
runtime to nicely map the incoming data into classes like Customer. 
In the end one does not get the flexibilty the client code can get from 
technologies like XPath (as far as writing a robust cliend code is concerned). 
And one needs to write manually some utility code which will map the in XMl to 
*generated* types like Customer. What's the point ?

I'd either go for a pure XML approach or would use a description language to do 
all the client bootsrapping stuff for me.

Cheers, Sergey



 Well, if you REALLY want, you can hide the calling of JAXB in an util, for 
 example you can extend HTTP Client to make it aware of a JAXBContext and be 
 able to accept and return a JAXB object, for example following code:
 
String inputFile = 
 client.getClass().getResource(update_customer.txt).getFile();
File input = new File(inputFile);
PutMethod put = new 
 PutMethod(http://localhost:9000/customerservice/customers;);
RequestEntity entity = new FileRequestEntity(input, text/xml; 
 charset=ISO-8859-1);
put.setRequestEntity(entity);
HttpClient httpclient = new HttpClient();
int result = httpclient.executeMethod(put);
String response = put.getResponseBodyAsString()
 
 Will become:
 
PutMethod put = new 
 PutMethod(http://localhost:9000/customerservice/customers;);
Customer customer = new Customer();
RequestEntity entity = new JAXBRequestEntity(customer);
put.setRequestEntity(entity);
HttpClient httpclient = new JAXBHttpClient(jaxbcontext);
int result = httpclient.executeMethod(put);
Customer updatedCustomer = put.getResponseBodyAsJAXB()
 
 Of course, you can also add some nice things such as handle checked exception 
 in this HTTP Client extension, so that it becomes:
  try {
int result = httpclient.executeMethod(put);
Customer updatedCustomer = put.getResponseBodyAsJAXB()
   } catch (CustomerNotFoundException e) {
   } catch (WebServiceException e)  {
   }
 
 Does this make sense?
 
 Cheers,
 Jervis
 -Original Message-
 From: Sergey Beryozkin [mailto:[EMAIL PROTECTED]
 Sent: 2007年12月20日 17:54
 To: cxf-user@incubator.apache.org
 Subject: Re: JAXB Unmarshalling
 
 That's pretty interesting all right.
 
 I would say that there might not be much point in dealing directly with
 JAXBContext and pretend
 that your code is so light and free :-)
 
 Cheers, Sergey
 
 - Original Message -
 From: Liu, Jervis [EMAIL PROTECTED]
 To: cxf-user@incubator.apache.org
 Sent: Thursday, December 20, 2007 7:18 AM
 Subject: RE: JAXB Unmarshalling
 
 
 
  -Original Message-
  From: Sergey Beryozkin [mailto:[EMAIL PROTECTED]
  Sent: 2007年12月19日 22:40
  To: cxf-user@incubator.apache.org
  Subject: Re: JAXB Unmarshalling
 
  By the way, can this approach (which uses JAXBContexts) work for you in
  CXF? :
 
 
 http://weblogs.java.net/blog/mhadley/archive/2006/03/restful_web_ser_1.
  html
 
  [Liu, Jervis] You don’t have to use JAX-WS Dispatch API in this case. Once
 you grab the InputStream from HTTPClient (or other lightweight http client
 stack), you can call JAXB to marshal the response to your Customer object.
 There is no point to use a heavy stack like a JAX-WS runtime to do such a
 simple task. Following code snippet should do the job:
 
 public Object getObjectFromInputStream (ClassObject type,
 InputStream is) {
 try {
 JAXBContext context = getJAXBContext(type);
 Unmarshaller unmarshaller = context.createUnmarshaller();
 return unmarshaller.unmarshal(is);
 } catch (JAXBException e) {
 e.printStackTrace();
 }
 
 return null;
 }
 
 private JAXBContext getJAXBContext(Class type) throws
 JAXBException {
 synchronized (jaxbContexts) {
 JAXBContext context = jaxbContexts.get(type);
 if (context == null) {
 context = JAXBContext.newInstance(type);
 jaxbContexts.put(type, context);
 }
 return context;
 }
 }
 
 static MapClass, JAXBContext jaxbContexts = new
 WeakHashMapClass, JAXBContext();
 
  You'd still need a schema describing the data like Customer, etc...
  Cheers. Sergey
 
 
 
  - Original Message -
  From: Eric Le Goff [EMAIL PROTECTED]
  To: cxf-user@incubator.apache.org
  Sent: Tuesday, December 18, 2007 4:34 PM
  Subject: JAXB Unmarshalling
 
 
  I am going on playing with the restful_jaxrs sample demo
  
  
   In the Client.java there are these lines
  
   ...
   URL url = new
  URL(http://localhost:9000/customerservice/customers/123;);
  InputStream

Re: JAXB Unmarshalling

[Sergey Beryozkin]

Here's a slightly different point. Look at a JAX-RS demo, at a CustomerService 
code [1]. 

This server code is a receiver when POST/PUT requests are issued to it. For ex, 
CustomerService.updateCustomer(Customer).

We don't expect the developers to write their own code to unmarshall it all 
there, be aware of JAXBContexts, etc, right ? If they want they just can go 
ahread and write their own code, no probs, or they can have CXF help them to do 
it with its JAX-RS infrastructure.

Same story for those receivers which initiate have GET responses to deal with. 
One either lets them write their own code if they feel that's what they want or 
help them, possibly with the help of description languages to hide all the 
things needed to get to the actual data like JAXBContext.

Cheers, Sergey


[1]svn.apache.org/viewvc/incubator/cxf/trunk/distribution/src/main/release/samples/restful_jaxrs/src/demo/jaxrs/server/CustomerService.java?revision=605587view=markup


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: Restful web services usage [WAS : JAXB Unmarshalling]

[Sergey Beryozkin]

Hi Eric

You asked a very good question.
It's always a choice. 

If you take XML out of the wire and handle it directly, perhaps
by providing some STAX/SAX handler which will populate a Customer class you 
created yourself (thus non necessarily even matching the actual data on the 
wire), then your client code in general is likely to be more robust when 
dealing with some changes on the server side.

I appreciate you're not using SOAP :-) but RESTful services may have their own 
machine-processible documents (WSDL 2.0/WADL). If you prefer to deal with more 
statically-typed artifacts, like Customer which is automatically populated for 
you by an underlying JAXB runtime, then one way or another you need to tell to 
the client runtime how to do it for you. I'm not aware of Hessian, but 
generally, providing some sort of description should do the trick. I personally 
don't see using description languages as a total evil :-). IMHO, it's much more 
important to make the actual schema for the data extensible and try to make the 
runtime ignore unknown elements when possible/realistic. AFAIK JAXB can be 
configured to ignore unrecognized elements.

Cheers, Sergey



- Original Message - 
From: Eric Le Goff [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Wednesday, December 19, 2007 11:32 AM
Subject: Restful web services usage [WAS : JAXB Unmarshalling]


 Sergey,
 
 I must admit my question was badly asked. Actually I am wondering how
 I could use restful web-services if clients only get an XML
 representation of the Object they request ?
 I am not using SOAP, nor any WSDL description.
 
 I expected to be able to get a kind of stub object on client side
 (may be thanks to a sort of unmarshalling of this XML I get from the
 server)
 
 The CXF Jaxrs demo piece of code I have shown in my previous mail only
 shows how to display an XML representation of Customer with Id 123
 which is fine. But in my case, I would like to manipulate an actual
 Customer stub instance, so that I can call methods on it and do
 interesting things with what the server has sent to me.
 
 I might be confused because so far I was using Hessian
 (http://hessian.caucho.com/) where their binary protocol allow a web
 service client to get an actual instance of the object they request.
 
 I might be totally wrong about Restful web services, and I realize
 that it may totally absurd to have the same behaviour with REST as
 what I had  with Hessian.
 
 My question is more general :
 How do Clients of Restful webservices get a concrete use of the XML
 content they receive from the server ?
 (I guess people just don't print out this XML on console :) but I
 suppose they have to parse it/ unmarshall it  in some way ?)
 
 
 
 PS :I don't know about WADL , so please excuse my ignorance.
 
 Thanks for helping anyway ;)
 
 Eric
 
 
 
 
 
 
 On Dec 19, 2007 11:54 AM, Sergey Beryozkin [EMAIL PROTECTED] wrote:
 Hi

 I'm wondering, are you actually asking for a code generation be done on a 
 client side with the help of a description language like WSDL 2.0 or WADL ?

 Cheers, Sergey



 - Original Message -
 From: Eric Le Goff [EMAIL PROTECTED]
 To: cxf-user@incubator.apache.org
 Sent: Tuesday, December 18, 2007 4:34 PM
 Subject: JAXB Unmarshalling


 I am going on playing with the restful_jaxrs sample demo
 
 
  In the Client.java there are these lines
 
  ...
  URL url = new URL(http://localhost:9000/customerservice/customers/123;);
 InputStream in = url.openStream();
 System.out.println(getStringFromInputStream(in));
  
 
 
  What if I did not want to display the XML content (ie the XML
  representation of customer whose Id is 123)
  But rather I would like to get the actual instance of Customer with id is 
  123
 
  Is there some Unmarshalling method to do that , something like
 
  ...
  URL url = new URL(http://localhost:9000/customerservice/customers/123;);
 InputStream in = url.openStream();
 
  // Hypothetic code
  Customer customer = (Customer) getObjectFromInputStream(in);
  ...
 
  How would I implement this
 
  Object getObjectFromInputStream(InputStream in)
 
  method ?
 
  I guess I would have to get a JaxbContext before I can get an Unmarshaller 
  ?
 
 
  Thanks for your help
 
  Eric
 
 
 
 
  --
  Eric Le Goff

 
 IONA Technologies PLC (registered in Ireland)
 Registered Number: 171387
 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

 
 
 
 -- 
 Eric Le Goff


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: .net ws-addressing relationship type

[Sergey Beryozkin]

Hi Adrian

Great...

I'm using a Tortoise SVN client, so it has an option CreatePatch...Not sure how to create it from a command line. Then you need to 
create a JIRA and attach a patch to it and then ask for this patch be applied


Thanks, Sergey

- Original Message - 
From: Adrian C [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Friday, November 16, 2007 3:29 PM
Subject: Re: .net ws-addressing  relationship type




Hi Sergey,

Thanks for the pointer on this. I changed the VersionTransformer to not set
the relationship type if default value and it works with .net.

Now the question is how to I submit this patch!?

Thanks,
Adrian


Sergey Beryozkin wrote:


I'm not sure but may be it should be

http://www.w3.org/2005/08/addressing/reply ,


/wsa:RelatesTo/@RelationshipType
This OPTIONAL attribute (of type xs:anyURI) conveys the relationship type
as an IRI. When absent, the implied value of this
attribute is http://www.w3.org/2005/08/addressing/reply;.


or better yet, it should be dropped altogether ? Perhaps modifying the cxf
ws-addressing code can help to find the truth...


It's somewhat orthogonal but a cxf response not look good with respect to
namespaces... I thought it was discussed earlier, but not
sure if some work was done...

Namespace declarations should really go to soap:envelope, otherwise, if a
message is large, then duplicate namespace declarations
will take up to 30% of the total message size. There's a number of ways to
ensure that soap:envelope keeps all the ns
declarations...

Cheers, Sergey

- Original Message - 
From: Adrian C [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Thursday, November 15, 2007 3:06 PM
Subject: .net ws-addressing  relationship type





if I use a .net client to consume my web service I am getting errors when
ws-addressing is used:
InnerException {WSE205: RelationshipType attribute can only be of reply
type. The following value was found: reply.} System.Exception
{Microsoft.Web.Services3.Addressing.AddressingFormatException}

seems to expect the RelationshipType attribute value to be different - i
don't get it!

The soap header generated by cxf looks fine:
soap:Header
MessageID
xmlns=http://schemas.xmlsoap.org/ws/2004/08/addressing;
urn:uuid:8504dd78-06aa-4c6b-b589-ad703ae19bbe
/MessageID
To xmlns=http://schemas.xmlsoap.org/ws/2004/08/addressing;
http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
/To
RelatesTo
xmlns=http://schemas.xmlsoap.org/ws/2004/08/addressing;
RelationshipType=reply
urn:uuid:b33fc856-dbae-4034-ac6f-e2d53b593722
/RelatesTo
Action
xmlns=http://schemas.xmlsoap.org/ws/2004/08/addressing;
http://www.daon.com/ws/de/IdentityManagement/CreateIdentity
/Action
/soap:Header

Get the feeling its expecting wsa:Reply as the attribute! Do anyone have
any
ideas what is going on?
--
View this message in context:
http://www.nabble.com/.net-ws-addressing---relationship-type-tf4812987.html#a13770286
Sent from the cxf-user mailing list archive at Nabble.com.



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland




--
View this message in context: 
http://www.nabble.com/.net-ws-addressing---relationship-type-tf4812987.html#a13795319
Sent from the cxf-user mailing list archive at Nabble.com. 



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: JAXWS WS Policy

[Sergey Beryozkin]

Hi






Thanks for the reply James, maybe my understanding of this is incorrect, but
I had hoped that by defining policy assertions for my endpoint
(jaxws:endpoint) that these would be inserted into the served out wsld.


+1. This is what shoud happen. As far as I'm aware no real WS-Policy work is 
happening in CXF but
please stay tuned. Submitting a JIRA so that this issue (ensuring policy assertions with public visibility are inlined in the 
published wsdl) can be tracked would be great


Cheers, Sergey





The example seems to deal with a wsdl with the assertions already embedded,
and these are picked up by the endpoint definition as they reference the
service - i.e. from org.apache.hello_world_soap_http.SOAPService there is
   url = new
URL(file:/C:/temp/apache-cxf-2.0.2-incubator/samples/ws_policy/wsdl/hello_world_addr_policy.wsdl);

Is my understanding of this correct?

What I would like is a more configuration way to add/remove policy
assertions, for my endpoint.

Thanks


James Mao wrote:


I've not been an expert on ws-*, but i just look at the samples in the
cxf distribution, we do have a sample of ws-policy
And we have doc on http://cwiki.apache.org/CXF20DOC/ws-support.html

Don't know if it's sufficient

James


Is there a way to configure WSPolicy in the jaxws definition of a service
in
the same way as WS-Reliable Messaging?

i.e. is it possible to have something like this:

jaxws:features
wsa:addressing /
p:policies
wsp:Policy
wsam:Addressing
xmlns:wsam=http://www.w3.org/2007/02/addressing/metadata;
wsp:Policy /
/wsam:Addressing
/wsp:Policy
/p:policies
/jaxws:features

Are there any examples of this?

Thanks






--
View this message in context: 
http://www.nabble.com/JAXWS---WS-Policy-tf4773036.html#a13666396
Sent from the cxf-user mailing list archive at Nabble.com. 



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Destination factory problem

[Sergey Beryozkin]

Hi

I have this Np DestinationFactory found problem when running a system test. 
I've checked archives, the suggested solutions are all about doing some 
programmatic bus setup, etc...
Unfortunately it's not something I can do in my scenario.

Here's my configuration :

beans xmlns:web=http://java.sun.com/xml/ns/j2ee; 
xmlns:sunjaxws=http://java.sun.com/xml/ns/jax-ws/ri/runtime; 
xmlns:xalan=http://xml.apache.org/xslt; 
xmlns:httpj=http://cxf.apache.org/transports/http-jetty/configuration; 
xmlns:soap=http://cxf.apache.org/bindings/soap; 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
xmlns:jaxws=http://cxf.apache.org/jaxws; 
xmlns=http://www.springframework.org/schema/beans; 
xsi:schemaLocation=http://www.springframework.org/schema/beans 
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd 
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd

import resource=classpath:META-INF/cxf/cxf.xml /

import resource=classpath:META-INF/cxf/cxf-extension-soap.xml /

import resource=classpath:META-INF/cxf/cxf-extension-http.xml /

jaxws:endpoint id=1...other attributes omiited for brevity/ 

jaxws:endpoint id=2...other attributes omiited for brevity

/beans

In debug mode I'm seeing *two* buses created, one bus has a 
DestinationFactoryManagerImpl initialized properly,

for the second bus, no DestinationFactoryManagerImpl is initilized (no 
register() method is called on it) and hence at the service init time an 
exception is thrown

Can someone please show how one can configure two endpoints such that a single 
bus is created...

Thanks, Sergey







IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Writing blocking input interceptor

[Sergey Beryozkin]

Hi

How to write a blocking input interceptor which can send a non-fault response 
back to a client, over HTTP ?
Input interceptors can access input Messages in its handleMessage, 
which, somewhat surprisingly, in case of HTTP, have 
javax.servlet.HTTPServletRequest/HTTPServletResponse object in the map, 
provided Jetty is used. 
It's tempting to use HTTPServletResponse, as it's exactly what I need for my 
scenario, but what is the right way to write blocking in interceptors ? 
 

Thanks, Sergey


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: Cxf Soap message namespace missing

[Sergey Beryozkin]

Hi
I don't think you can configure cxf to place the namespace declaration on the 
top.

CXF client is creating a correct message and the service it's talking to is 
broken (more precisely, the runtime supporting it is). 

That said, using this style can cause creating very verbose messages, when a 
message is big, with a lot of siblings, etc. IMHO an enhancement request should 
be submitted so that all namespace declarations go on top.

Cheers, Sergey 

- Original Message - 
From: Frank61 [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Tuesday, October 02, 2007 1:00 PM
Subject: Cxf Soap message namespace missing


 
 Hi 
 
 I have cxf client which generates soap message
 where the ns2 namespace is inside searchRequest tag.
 I am using cfx version 2.0.2.
 The java classes are generated using wsdl2java.
 
 soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;
 soap:Body
 ns2:searchRequest xmlns:ns2=http://xxx.yy.com/simplesoap/;
 search_nameSomeName/search_name
 /ns2:searchRequest
 /soap:Body
 /soap:Envelope
 
 The web service gives me error because it wants the ns2 namespace to be in
 first Line of msg
 like this. Then it's working Ok. 
 
 soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;
 xmlns:ns2=http://xxx.yy.com/simplesoap/;
 soap:Body
 ns2:searchRequest 
 search_nameSomeNome/search_name
 /ns2:searchRequest
 /soap:Body
 /soap:Envelope
 
 How can i tell cfx to generate the soap message where the namespace is 
 in the first line of the msg.
 
 
 
 
 
 
 
 
 
 
 -- 
 View this message in context: 
 http://www.nabble.com/Cxf-Soap-message-namespace-missing-tf4554470.html#a12997352
 Sent from the cxf-user mailing list archive at Nabble.com.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: WS-RM Usage

[Sergey Beryozkin]

Hi

One thing I'd like to note is that we'll do some work to automatically enable 
the policy engine upon encountering
the policy expressions.

Cheers, Sergey

- Original Message - 
From: Glynn, Eoghan [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Tuesday, September 25, 2007 2:30 PM
Subject: RE: WS-RM Usage




The presence of RMAssertion in the WSDL is enough for WS-RM to be
engaged in the client-runtime *if* the policy engine is turned on the
client config, via something like the following:

bean id=org.apache.cxf.ws.policy.PolicyEngine
class=org.apache.cxf.ws.policy.spring.InitializingPolicyEngine
property name=bus ref=cxf/
property name=enabled value=true/
/bean

See the ws_policy demo for an example of this usage and also the
docco[1] for more details.

This automatic injection of capability into the runtime triggered by the
presence of policy assertions is one of the main goals of the CXF
WS-Policy framework[2].

Cheers,
Eoghan

[1] http://cwiki.apache.org/CXF20DOC/wspconfiguration.html
[2] http://cwiki.apache.org/CXF20DOC/ws-policy-framework-overview.html


 -Original Message-
 From: Bharath Ganesh [mailto:[EMAIL PROTECTED] 
 Sent: 25 September 2007 14:12
 To: cxf-user@incubator.apache.org
 Subject: WS-RM Usage
 
 Hi
 
 I have been trying to get WS-RM to work in CXF. These are the 
 steps I followed.
 
 WSDL: Reference to a WS-policy, containing a RMAssertion.
 
 wsp:Policy wsu:Id=RM
 wsam:Addressing
 wsp:Policy/
 /wsam:Addressing
 wsrmp:RMAssertion
wsrmp:BaseRetransmissionInterval Milliseconds=1/
 /wsrmp:RMAssertion
 /wsp:Policy
 
 But this was not enough for the client side RM configuration. 
 The RM Interceptors were not added even thought the service 
 client (Generated JAX-WS Service class) pointed to this wsdl.
 
 So I chose to programatically get hold of the bus, enable 
 WS-Policy, create the RMFeature, set the RM Store and add the 
 RMInterceptors explicitly.
 Is that really needed? Shouldn't the runtime do this if wsdl 
 contains a WS-Policy reference, which has a RM assertion?
 
 In added RMOutInterceptor, RMInInterceptor, RMSoapInterceptor 
 (to in and out), RetransmissionInterceptor (to in and out) to 
 the client side org.apache.cxf.endpoint.Endpoint.
 
 After configuring all this when the message goes outward from 
 the client I get this exception:
 
 Caused by: java.lang.NullPointerException
 at 
 org.apache.cxf.ws.rm.soap.RetransmissionQueueImpl.cacheUnacknowledged
 (RetransmissionQueueImpl.java:202)
 at 
 org.apache.cxf.ws.rm.soap.RetransmissionQueueImpl.addUnacknowledged(
 RetransmissionQueueImpl.java:92)
 at org.apache.cxf.ws.rm.RetransmissionCallback.onClose(
 RetransmissionCallback.java:56)
 at 
 org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java
 :113)
 at 
 org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java
 :66)
 at 
 org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:576)
 at
 org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSen
 derEndingInterceptor.handleMessage
 (MessageSenderInterceptor.java:62)
 at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
 PhaseInterceptorChain.java:207)
 at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:254)
 at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:205)
 at 
 org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
 at 
 org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java
 :135)
 
 This means the RMProperties is not set in the message.
 What could go wrong?
 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: Problems with Policy file

[Sergey Beryozkin]

Hi

Unfortunately, no WS-SecurityPolicy is supported by CXF at this point of time 
though I believe people are planning to gradually add the support for it. 
The only workaround I can suggest at this point of time is to translate 
WS-PolicySecurity settings into corresponding
CXF configuration properties, possibly using an XSLT stylesheet. I appreciate 
it's not what a user would typically expect to do :-) but that is what needs to 
be done now.
WS-Adrressing policy is supported but I believe the reason it's not enforced is 
that the policy engine does not recognize one of the required policy assertions 
listed in All, which is sp:SymmetricBinding. WS-RM is supported too.

Hope this clarifies the issue...
Cheers, Sergey


- Original Message - 
From: Haselmann, Till [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Friday, September 21, 2007 8:39 AM
Subject: Problems with Policy file


Hello everybody,

I have created a Web Service using Sun's Metro stack (i.e., JAX-WS + WSIT).  
For this, I also created a policy file that works well with the WSIT 
implementation of WS-Policy/WS-SecurityPolicy/...  Now, I would like to create 
a CXF-based Web Service + client for the same WSDL/Policy file.  The Policy 
looks more or less like this (I cut some parts to save space):

?xml version=1.0 encoding=UTF-8?
definitions targetNamespace=http://computernoma.de/AlgebraService;
xmlns=http://schemas.xmlsoap.org/wsdl/;
...
xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;
xmlns:wsp=http://schemas.xmlsoap.org/ws/2004/09/policy;
xmlns:sc=http://schemas.sun.com/2006/03/wss/client;
xmlns:wspp=http://java.sun.com/xml/ns/wsit/policy;
xmlns:sp=http://schemas.xmlsoap.org/ws/2005/07/securitypolicy;
xmlns:wsaws=http://www.w3.org/2006/05/addressing/wsdl;
xmlns:wsrm=http://schemas.xmlsoap.org/ws/2005/02/rm/policy;
wsp:UsingPolicy/

types.../types
message ../message
portType name=AlgebraServicePortType
wsdl:operation name=Evaluate
wsdl:input name=Request message=ns:EvaluationRequest /
wsdl:output name=Response message=ns:EvaluationResponse /
/wsdl:operation
/portType
binding name=SOAPportBinding type=ns:AlgebraServicePortType
wsp:PolicyReference URI=#SOAPBindingPolicy/
soap:binding transport=http://schemas.xmlsoap.org/soap/http; style=document 
/
wsdl:operation name=Evaluate
soap:operation soapAction=urn:Evaluate style=document /
wsdl:input name=Requestsoap:body use=literal //wsdl:input
wsdl:output name=Response soap:body use=literal //wsdl:output
/wsdl:operation
/binding
service ../service

wsp:Policy wsu:Id=SOAPBindingPolicy
wsp:ExactlyOne
wsp:All
wsaws:UsingAddressing xmlns:wsaws=http://www.w3.org/2006/05/addressing/wsdl; 
/
!--wsrm:RMAssertion/--
sp:SymmetricBinding
wsp:Policy
...
/wsp:Policy
/sp:SymmetricBinding
sp:Wss10
wsp:Policy
sp:MustSupportRefKeyIdentifier /
sp:MustSupportRefIssuerSerial /
/wsp:Policy
/sp:Wss10
sp:Wss11
wsp:Policy
sp:MustSupportRefKeyIdentifier /
sp:MustSupportRefIssuerSerial /
sp:MustSupportRefThumbprint /
sp:MustSupportRefEncryptedKey /
/wsp:Policy
/sp:Wss11
sp:SignedParts.../sp:SignedParts
sp:EncryptedParts.../sp:EncryptedParts
sc:KeyStore wspp:visibility=private .../
sc:TrustStore wspp:visibility=private ... /
/wsp:All
/wsp:ExactlyOne
/wsp:Policy
/definitions

I assume that it's a valid policy by the standards (looks ok, works with Sun's 
implementation).  I try to load it into CXF by engaging the policy engine in 
the cxf.xml (taken from CXF samples):

bean id=org.apache.cxf.ws.policy.PolicyEngine 
class=org.apache.cxf.ws.policy.spring.InitializingPolicyEngine
property name=bus ref=cxf /
property name=enabled value=true /
/bean

I then initialize the Web Service stub on the client side by calling the 
constructor with a path to the above WSDL-file.  However, it does not seem to 
understand the policy.  The service works well, but no policy assertions are 
processed: WS-Addressing is not turned on, no security header is inserted, ...  
I read through the documentation but did not find any solution.

What's my mistake?  How can I use WS-Policy with CXF?  Could it be that the 
wsp:PolicyReference .../ is not respected by CXF?

As a next step:  How do I specify a keystore for CXF?  The sc:KeyStore .../ 
seems to be a proprietary Sun extension.

Any help is appreciated!

Yours,
Till.

-
Till Haselmann
Diplomand
viadee Unternehmensberatung GmbH
Anton-Bruchausen-Str. 8
48147 Münster
Telefon: +49 251 7 77 77 303
[EMAIL PROTECTED]
www.viadee.de
Sitz und Amtsgericht: Münster, HRB 4318
Geschäftsführer: Martina Wegener, Heinrich Riemann



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: jaxws:endpoint and wsdlLocation

[Sergey Beryozkin]

Do you use import statements in your cxf-servlet.xml ? If yes then get rid of 
them and it should fix the problem...

Cheers, Sergey
- Original Message - 
From: Jean-François Daune [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Monday, September 17, 2007 3:00 PM
Subject: jaxws:endpoint and wsdlLocation


Hi,

I cannot manage to configure properly a JAX-WS endpoint using servlet transport 
in Tomcat 5.5 with a custom WSDL:

jaxws:endpoint
   id=BackOffice
   implementor=#backOfficeService
   address=/erh/backoffice
   wsdlLocation=WEB-INF/backoffice.wsdl
   jaxws:features
  bean class=org.apache.cxf.feature.LoggingFeature/
   /jaxws:features
/jaxws:endpoint


Generates: java.io.FileNotFoundException: 
D:\tools\apache-tomcat-5.5.25\bin\WEB-INF\backoffice.wsdl

What should I put in 'wsdlLocation' ?

Cheers,

J-F


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: SOAPFactory thread safe?

[Sergey Beryozkin]

Seems to be perfectly thread-safe, VM guarantees that the static initializer is 
executed in a thread-safe manne,
unless SOAPFactory.newInstance() has some global sideeffects. 
Do you see transient failures ?

Cheers, Sergey

- Original Message - 
From: Guy Pardon [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Thursday, September 13, 2007 9:40 AM
Subject: SOAPFactory thread safe?


 Hi,
 
 Is the following code thread safe? In other words, can we reuse the  
 same soapFactory for different threads (concurrently) and within  
 different MEPs?
 
 Thanks,
 Guy
 
 
 private static SOAPFactory soapFactory = null;
 
 static {
 try {
 soapFactory = SOAPFactory.newInstance();
 }
 catch ( Exception e ) {
 Configuration.logWarning ( Failed to create SOAPFactory , e );
 }
 }


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: SOAPFactory thread safe?

[Sergey Beryozkin]

I think I misunderstood your question, you're asking if the static instance shown in your code fragment can be reused afterwords 
concurrently, but I though you were asking if the block itsef was thread-safe, sorry


Cheers, Sergey


Hi,

Is the following code thread safe? In other words, can we reuse the
same soapFactory for different threads (concurrently) and within
different MEPs?

Thanks,
Guy


private static SOAPFactory soapFactory = null;

static {
try {
soapFactory = SOAPFactory.newInstance();
}
catch ( Exception e ) {
Configuration.logWarning ( Failed to create SOAPFactory , e );
}
}



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: jaxws:endpoint wsdlLocation attribute -- form for class path reference?

[Sergey Beryozkin]

phew...I thought I was going to loose my mind. I had two webapps, absolutely 
identical in structure,

one loading WEB-INF/wsdl/hello.wsdl just fine yet another one failing to load 
WEB-INF/wsdl/greetMe.wsdl.
cxf-servlet.xmls were absolutely identical in format too...or so I thought.
Fortunately, I was saved, I was pointed out that one cxf-servlet.xml had the 
following import statements, which I copied from the docs :

import resource=classpath:META-INF/cxf/cxf.xml/
import resource=classpath:META-INF/cxf/cxf-extension-soap.xml/
import resource=classpath:META-INF/cxf/cxf-servlet.xml/

These import statements upset CXFServler and WEB-INF/wsdl/greetMe.wsdl can 
not be loaded.
Without these imports WEB-INF/wsdl/greetMe.wsdl is loaded just fine...

Cheers, Sergey


- Original Message - 
From: Sergey Beryozkin [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Thursday, September 13, 2007 12:19 PM
Subject: Re: jaxws:endpoint wsdlLocation attribute -- form for class path 
reference?


I have CXFServlet loading WEB-INF/wsdl/hello.wsdl just fine. not sure why it 
didn't work for me yesterday,
possibly because I was using an absolute /WEB-INF/wsdl/hello.wsdl form... So 
things are cool.

Cheers, Sergey





 
 Hi
 
 I was about to ask a question if a wsdl document should always be located
 inside WEB-INF/classes or WEB-INF/libs, and then I found this thread...
 
 I agree it's a pain having to relocate a resource like
 WEB-INF/wsdl/hello.wsdl into WEB-INF/classes/wsdl/hello.wsdl just to make it
 work, esppecially when one deal with prepackaged wars.
 
 Unfortunately I have little knowledge of Spring at this stage, but the idea
 of using some Spring webapp-aware context classes looked promising so that
 resources like /WEB-INF/wsdl/hello.wsdl could also be resolved. Is it
 where CXFServlet can be enhanced a bit ?
 
 By the way, I'm using Tomcat 5.5.25, Windows XP.
 
 Thanks, Sergey
 
 
 CMoesel wrote:
 
 I ran into this very same issue when trying to run the war using the
 maven jetty plugin.  It also searched from the working directory instead
 of the root of the application context.  It worked however, when I tried
 it in Tomcat 5.5 and Jboss 4.0 standalone.
 
 In order to get it working in the maven jetty plugin though, I had to
 put my wsdl in the classpath (WEB-INF/classes/myservice.wsdl) and then
 refer to it in the jaxws:endpoint as wsdlLocation=myservice.wsdl
 (note the lack of classpath: prefix).
 
 If you don't mind putting it in the classpath, that may be the best
 solution for you right now (assuming it works!).
 
 -Chris
 
 -Original Message-
 From: Steven E. Harris [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, May 02, 2007 11:32 PM
 To: cxf-user@incubator.apache.org
 Subject: Re: jaxws:endpoint wsdlLocation attribute -- form for class
 path reference?
 
 Jiang, Ning \(Willem\) [EMAIL PROTECTED] writes:
 
 I just try the latest kit's (build with latest trunk) helloworld
 sample with the wsdlLocation=WEB-INF/wsdl/hello_world.wsdl.
 
 It is workable. 
 
 That's good to hear.
 
 Can you check your wsdl in the war or try the CXF helloworld sample?
 
 Actually, I'm deploying via an explode WAR directory, but my WSDL is
 in the proper place in the directory. I just tried deploying via an
 actual WAR file as well. The files are in the directory and in the
 WAR. I tried matching your location specification above:
 WEB-INF/wsdl/myfile.wsdl. No matter what, the search fails,
 apparently taking the current working directory as the base for the
 search:
 
 Caused by: javax.wsdl.WSDLException: WSDLException:
 faultCode=PARSER_ERROR: Problem parsing 'WEB-INF/wsdl/myfile.wsdl'.:
 java.io.FileNotFoundException: C:\Program
 Files\Java\add-ons\apache-tomcat-6.0.10\bin\WEB-INF\wsdl\myfile.wsdl
 (The system cannot find the path specified)
 at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source)
 at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
 at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
 at
 org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.jav
 a:177)
 at
 org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java
 :141)
 at
 org.apache.cxf.wsdl11.WSDLServiceFactory.init(WSDLServiceFactory.java:
 81)
 ... 42 more
 Caused by: java.io.FileNotFoundException: C:\Program
 Files\Java\add-ons\apache-tomcat-6.0.10\bin\WEB-INF\wsdl\myfile.wsdl
 (The system cannot find the path specified)
 at java.io.FileInputStream.open(Native Method)
 at java.io.FileInputStream.init(FileInputStream.java:106)
 at java.io.FileInputStream.init(FileInputStream.java:66)
 at
 sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.ja
 va:70)
 at
 sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnec
 tion.java:161)
 at
 com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEnt
 ity(XMLEntityManager.java:653)
 at
 com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocV
 ersion(XMLVersionDetector.java

Re: cxf servlet and jaxws:endpoint questions

[Sergey Beryozkin]

By the way, using jaxws:endpoint/@implementorClass does not work at all for me 
in a servlet env, but when I use 'implementor' to point to a fuly-qualified 
class then things are fine. I'm inclined to open a bug, is it really bug though 
?

Cheers, Sergey

- Original Message - 
From: Sergey Beryozkin [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Wednesday, September 12, 2007 1:35 PM
Subject: Re: cxf servlet and jaxws:endpoint questions


HI

Just a follow-up question...
So is the rule of thumb is to use wildcard url patterns, like /services/* and 
then use jaxws:endpoint/@address
values like /GreetMe ? 

I'm wondering why specifying a pattern like /services/GreetMe doesn 
work...Casually glancing through a servler code didn't give me an answer so 
I'll probably have to look harder :-).

Cheers, Sergey


- Original Message - 
From: Sergey Beryozkin [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Wednesday, September 12, 2007 1:22 PM
Subject: Re: cxf servlet and jaxws:endpoint questions


Hi Chris

It does work, super !
Thanks for a quick reply,
Sergey

- Original Message - 
From: Christopher Moesel [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Wednesday, September 12, 2007 1:14 PM
Subject: RE: cxf servlet and jaxws:endpoint questions


Hi Sergey,

The following combination *should* work...

In web.xml, the url-pattern for the servlet-mapping:
/hello/*

In the jaxws:endpoint/@address:
/world

I believe that the difference between implementor and implementorClass
is this:

implementor: a reference to an *instance* of your SEI implementation (in
Spring, you use this style: #myServiceEndpointImp)

implementorClass: the fully qualified classname of your SEI
implementation, which must have a default constructor (for example,
com.mycompany.MyServiceEndpointImpl)

I hope that helps!

-Chris

-Original Message-
From: Sergey Beryozkin [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 12, 2007 7:55 AM
To: cxf-user@incubator.apache.org
Subject: cxf servlet and jaxws:endpoint questions

Hi

I have few questions with respect to deploying a cxf servlet into tomcat
:

* how to use/combine correctly a servlet's url pattern and an
jaxws:endpoint/@address values ?

For example, suppose I have a webapp test and I want my servlet to
recognize this pattern : /hello/world

As such, I'd like 
GET http://localhost:8080/test/hello/world?wsdl 

to return me a wsdl.

In web.xml I've tried
/hello/*
/hello/world

and in jaxws:endpoint/@address I tried
/hello/world
/world

with no luck, the above request returns no service is available

* what is the difference between jaxws:endpoint/@implementer and
jaxws:endpoint/@implementerClass attributes ?

Thanks, Sergey




IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
Ireland


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: jaxws:endpoint wsdlLocation attribute -- form for class path reference?

[Sergey Beryozkin]

Hi

I was about to ask a question if a wsdl document should always be located
inside WEB-INF/classes or WEB-INF/libs, and then I found this thread...

I agree it's a pain having to relocate a resource like
WEB-INF/wsdl/hello.wsdl into WEB-INF/classes/wsdl/hello.wsdl just to make it
work, esppecially when one deal with prepackaged wars.

Unfortunately I have little knowledge of Spring at this stage, but the idea
of using some Spring webapp-aware context classes looked promising so that
resources like /WEB-INF/wsdl/hello.wsdl could also be resolved. Is it
where CXFServlet can be enhanced a bit ?

By the way, I'm using Tomcat 5.5.25, Windows XP.

Thanks, Sergey


CMoesel wrote:
 
 I ran into this very same issue when trying to run the war using the
 maven jetty plugin.  It also searched from the working directory instead
 of the root of the application context.  It worked however, when I tried
 it in Tomcat 5.5 and Jboss 4.0 standalone.
 
 In order to get it working in the maven jetty plugin though, I had to
 put my wsdl in the classpath (WEB-INF/classes/myservice.wsdl) and then
 refer to it in the jaxws:endpoint as wsdlLocation=myservice.wsdl
 (note the lack of classpath: prefix).
 
 If you don't mind putting it in the classpath, that may be the best
 solution for you right now (assuming it works!).
 
 -Chris
 
 -Original Message-
 From: Steven E. Harris [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, May 02, 2007 11:32 PM
 To: cxf-user@incubator.apache.org
 Subject: Re: jaxws:endpoint wsdlLocation attribute -- form for class
 path reference?
 
 Jiang, Ning \(Willem\) [EMAIL PROTECTED] writes:
 
 I just try the latest kit's (build with latest trunk) helloworld
 sample with the wsdlLocation=WEB-INF/wsdl/hello_world.wsdl.
 
 It is workable. 
 
 That's good to hear.
 
 Can you check your wsdl in the war or try the CXF helloworld sample?
 
 Actually, I'm deploying via an explode WAR directory, but my WSDL is
 in the proper place in the directory. I just tried deploying via an
 actual WAR file as well. The files are in the directory and in the
 WAR. I tried matching your location specification above:
 WEB-INF/wsdl/myfile.wsdl. No matter what, the search fails,
 apparently taking the current working directory as the base for the
 search:
 
 Caused by: javax.wsdl.WSDLException: WSDLException:
 faultCode=PARSER_ERROR: Problem parsing 'WEB-INF/wsdl/myfile.wsdl'.:
 java.io.FileNotFoundException: C:\Program
 Files\Java\add-ons\apache-tomcat-6.0.10\bin\WEB-INF\wsdl\myfile.wsdl
 (The system cannot find the path specified)
   at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source)
   at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
   at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
   at
 org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.jav
 a:177)
   at
 org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java
 :141)
   at
 org.apache.cxf.wsdl11.WSDLServiceFactory.init(WSDLServiceFactory.java:
 81)
   ... 42 more
 Caused by: java.io.FileNotFoundException: C:\Program
 Files\Java\add-ons\apache-tomcat-6.0.10\bin\WEB-INF\wsdl\myfile.wsdl
 (The system cannot find the path specified)
   at java.io.FileInputStream.open(Native Method)
   at java.io.FileInputStream.init(FileInputStream.java:106)
   at java.io.FileInputStream.init(FileInputStream.java:66)
   at
 sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.ja
 va:70)
   at
 sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnec
 tion.java:161)
   at
 com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEnt
 ity(XMLEntityManager.java:653)
   at
 com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocV
 ersion(XMLVersionDetector.java:186)
   at
 com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML1
 1Configuration.java:771)
   at
 com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML1
 1Configuration.java:737)
   at
 com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.jav
 a:107)
   at
 com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.jav
 a:225)
   at
 com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Docume
 ntBuilderImpl.java:283)
   ... 48 more
 
 
 If I start Tomcat from a shell, the same error arises, but the current
 working directory matches that of the shell that called startup.sh.
 
 I'll give up for now and try again with tomorrow's snapshots.
 
 -- 
 Steven E. Harris
 
 

-- 
View this message in context: 
http://www.nabble.com/jaxws%3Aendpoint-wsdlLocation-attributeform-for-class-path-reference--tf3684247.html#a12633374
Sent from the cxf-user mailing list archive at Nabble.com.

cxf servlet and jaxws:endpoint questions

[Sergey Beryozkin]

Hi

I have few questions with respect to deploying a cxf servlet into tomcat :

* how to use/combine correctly a servlet's url pattern and an 
jaxws:endpoint/@address values ?

For example, suppose I have a webapp test and I want my servlet to recognize 
this pattern : /hello/world

As such, I'd like 
GET http://localhost:8080/test/hello/world?wsdl 

to return me a wsdl.

In web.xml I've tried
/hello/*
/hello/world

and in jaxws:endpoint/@address I tried
/hello/world
/world

with no luck, the above request returns no service is available

* what is the difference between jaxws:endpoint/@implementer and  
jaxws:endpoint/@implementerClass attributes ?

Thanks, Sergey




IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: Bus Features [was: Logging ...]

[Sergey Beryozkin]

Hi,


I wonder can this be done through WS-Policy? I.e., I can make some assertions like this:  I want to apply this feature to endpoint 
A and B or I want this feature applied to all my endpoints by default if there is no overridden feature defined for the individual 
endpoint. Thoughts?


CXF supports an external WS-Policy attachment mechanism, which should suffice...
It's briefly described here :

http://cwiki.apache.org/CXF20DOC/how-it-works.html

Using this approach you can apply a policy expression to one or more domain expressions, for ex, to EndpointReferences...There's an 
rm_external.xml file in a ws_policy system test, it shows how WS-Addresing and WS-RM policies are applied to a given endpoint...


Cheers, Sergey

- Original Message - 
From: Liu, Jervis [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Wednesday, August 29, 2007 7:17 AM
Subject: RE: Bus Features [was: Logging ...]


Hi Fred, I recalled we had a similar discussion before. In your code snippet below, the logging interceptors will be installed 
twice. I wont say cxf:bus is a root scope configuration as there is no hierarchy relationships among bus, endpoints and bindings. 
Bus, endpoints and bindings are just individual components that can contribute interceptors, some times a same bus instance can be 
shared by multiple services but this wont necessarily make it a root configuration. Bindings can be shared by multiple services as 
well. What you required, if a  feature is defined at endpoint granularity, that feature is the  effective feature in config, 
whereas if there is no such config at  endpoint granularity, the runtime would fall back to the Bus config, is really a scope-based 
configuration. This is no such thing existing yet in CXF. I wonder can this be done through WS-Policy? I.e., I can make some 
assertions like this:  I want to apply this feature to endpoint A and B or I want this feature applied to all my endpoints by 
default if there is no overridden feature defined for the individual endpoint. Thoughts?


Jervis


-Original Message-
From: Fred Dushin [mailto:[EMAIL PROTECTED]
Sent: 2007?8?29? 2:52
To: cxf-user@incubator.apache.org
Subject: Bus Features [was: Logging ...]



On Aug 24, 2007, at 11:36 AM, Daniel Kulp wrote:

 cxf:bus
 cxf:features
 cxf:logging/
 /cxf:features
 /cxf:bus

How do Bus-level features interact with endpoint- or client-level
features?  For example, if I have

{{{
cxf:bus
 cxf:features
 cxf:foo/
 /cxf:features
/cxf:bus

jaxws:endpoint name={http://foo.bar.com}FUBAR;
 cxf:features
 cxf:foo/
 /cxf:features
/jaxws:endpoint
}}}

and a servant is instantiated under the WSDL Port
{http://foo.bar.com}
FUBAR, is a feature instantiated twice, once for the Bus, qua
InterceptorProvider, and once for the Endpoint, qua
InterceptorProvider?

If it's instantiated twice, is there any way a feature
implementor to
traverse the interceptors on each InterceptorProvider, to see if a
feature has been installed, or are these interceptor lists
independent of one another?

(The reason I ask is, there might be a tendency to think of the
feature config on the Bus as a kind of default, such that if a
feature is defined at endpoint granularity, that feature is the
effective feature in config, whereas if there is no such config at
endpoint granularity, the runtime would fall back to the Bus
config.
But I'm guessing that's really not the behavior here, is it?)

Thanks!
-Fred




IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland 



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: enable MTOM client

[Sergey Beryozkin]

Hi Dan

If that's the case then agreed. I misunderstood the original usecase. My point is that such a great CXF feature as its 
policy-awareness should be utilized more when feasible...but yes, in this case it wouldn't help. Policy expressions don't have to 
live in wsdls but it's only (?) when they do can they help client to avoid duplicating the configuration...



Remember, the world doesn't have to revolve around wsdl and stuff stuck
in wsdl.


Agreed. Reality check :-)

Cheers, Sergey



Sergey,

On Tuesday 21 August 2007, Sergey Beryozkin wrote:

I'm wondering, why there's a need to configure MTOM explicitly on the
client side ? CXF is policy-aware, so if the service' WSDL contains a
non-optional MTOM WS-Policy assertion then the client runtime should
consume it and do MTOM. The thing is, the server has already expressed
a requirement to have messages MTOMed, so this should be sufficient.
One of the purposes of WS-Policy expressions is to mimimize the need
for a client-side configuration.


Well, if you are doing complete code first development (no wsdl involved
at all), there currently isn't an easy way to enforce WS-Policy
expressions or to add the ws-policy stuff to the wsdl generated with
the ?wsdl call.The client may not even be using a WSDL.   It could
be just using the interface and and endpoint URL.   It doesn't have to
query for a wsdl if it doesn't want too.

Remember, the world doesn't have to revolve around wsdl and stuff stuck
in wsdl.

Dan





Cheers, Serge

- Original Message -
From: Willem Jiang [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Tuesday, August 21, 2007 9:33 AM
Subject: Re: enable MTOM client

 Hi,

 You can take [1]'s inlineSoapBinding bean as a example to configure
 the MTOM on the client side.
 [1]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/frontend/
jaxws/src/test/java/org/apache/cxf/jaxws/spring/clients.xml

 Willem.

 nuka wrote:
 I didn't configure MTOM on the client side. The only configuration
 I've made is
 - jaxws endpoint configuration for MTOM (beans.xml)
 - MIMEType annotation application/octet-stream for the binary data


 I don't know how to configure the client via xml (or by code). I
 use jaxws as frontend. I saw that the client can be configured by
 xml (in the beans.xml file ) but I don't know how. I would
 appreciate if you can show me a sample.

 thanks in advance

 Nuka

 Dan Diephouse wrote:
 What does your client code look like? You probably aren't
 configuring MTOM right on the client side.

 Cheers,
 - Dan

 On 8/20/07, nuka [EMAIL PROTECTED] wrote:
 Hello,

 I have some problems when enabling MTOM for CXF generated client.
 I've made the configuration for MTOM as suggested in the user
 guide for both
 client and server side.

 - jaxws endpoint configuration for MTOM (beans.xml)
 - MIMEType annotation application/octet-stream for the binary
 data


 The server is ok, its responses support MTOM. But the client
 requests are not MTOM based. The binary data is embedded in the
 SOAP body.

 I believe I've missed something on the client side configuration
 but I don't
 know what.

 Thanks in advance
 Nuka


 --
 View this message in context:
 http://www.nabble.com/enable-MTOM-client-tf4300910.html#a12242043
 Sent from the cxf-user mailing list archive at Nabble.com.

 --
 Dan Diephouse
 Envoi Solutions
 http://envoisolutions.com | http://netzooid.com/blog


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
Ireland




--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog 



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: enable MTOM client

[Sergey Beryozkin]

Hi

I'm wondering, why there's a need to configure MTOM explicitly on the client side ? CXF is policy-aware, so if the service' WSDL 
contains a non-optional MTOM WS-Policy assertion then the client runtime should consume it and do MTOM. The thing is, the server has 
already expressed a requirement to have messages MTOMed, so this should be sufficient. One of the purposes of WS-Policy expressions 
is to mimimize the need for a client-side configuration.


Cheers, Sergey

- Original Message - 
From: Willem Jiang [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Tuesday, August 21, 2007 9:33 AM
Subject: Re: enable MTOM client



Hi,

You can take [1]'s inlineSoapBinding bean as a example to configure the MTOM on 
the client side.
[1]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/frontend/jaxws/src/test/java/org/apache/cxf/jaxws/spring/clients.xml

Willem.

nuka wrote:

I didn't configure MTOM on the client side. The only configuration I've made
is
- jaxws endpoint configuration for MTOM (beans.xml)
- MIMEType annotation application/octet-stream for the binary data


I don't know how to configure the client via xml (or by code). I use jaxws
as frontend. I saw that the client can be configured by xml (in the
beans.xml file ) but I don't know how. I would appreciate if you can show me
a sample.

thanks in advance

Nuka











Dan Diephouse wrote:


What does your client code look like? You probably aren't configuring MTOM
right on the client side.

Cheers,
- Dan

On 8/20/07, nuka [EMAIL PROTECTED] wrote:


Hello,

I have some problems when enabling MTOM for CXF generated client.
I've made the configuration for MTOM as suggested in the user guide for
both
client and server side.

- jaxws endpoint configuration for MTOM (beans.xml)
- MIMEType annotation application/octet-stream for the binary data


The server is ok, its responses support MTOM. But the client requests are
not MTOM based. The binary data is embedded in the SOAP body.

I believe I've missed something on the client side configuration but I
don't
know what.

Thanks in advance
Nuka


--
View this message in context:
http://www.nabble.com/enable-MTOM-client-tf4300910.html#a12242043
Sent from the cxf-user mailing list archive at Nabble.com.




--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog









IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: Axis2 vs CXF

[Sergey Beryozkin]

I can understand this answer as I can read Russian :-) but please be aware there're many people here which can not read it, even 
though URLs are provided


Thanks,
Sergey Beryozkin
blog: http://sberyozkin.blogspot.com

- Original Message - 
From: Alexey Zavizionov [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Thursday, July 05, 2007 3:41 PM
Subject: Re: Axis2 vs CXF



Есть только сравнения axis и xfire
http://xfire.codehaus.org/Stack+Comparison

PS XFire и Celtix слияние http://xfire.codehaus.org/XFire+and+Celtix+Merge

Regards,
Alexey



On 7/5/07, Arkady Kasianski [EMAIL PROTECTED] wrote:

Hi everybody,



I have to choose between Axis 2 and CXF 



Could someone compare  between both WS frameworks ?



Thanks in advance



-Arkady


This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp






IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: Axis2 vs CXF

[Sergey Beryozkin]

This is a very helpful answer and the audience is much wider :-)

Cheers, Sergey

P.S. I guess we can also set up a russian speaking cxf-user list too where we can write away in russian :-). we can chat offline if 
there's any interest



OK, I can too :)

There is only comparison axis and xfire
http://xfire.codehaus.org/Stack+Comparison

PS XFire and Celtix merge http://xfire.codehaus.org/XFire+and+Celtix+Merge

Regards,
Alexey

On 7/5/07, Sergey Beryozkin [EMAIL PROTECTED] wrote:

I can understand this answer as I can read Russian :-) but please be aware 
there're many people here which can not read it, even
though URLs are provided

Thanks,
Sergey Beryozkin
blog: http://sberyozkin.blogspot.com

- Original Message -
From: Alexey Zavizionov [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Thursday, July 05, 2007 3:41 PM
Subject: Re: Axis2 vs CXF


 Есть только сравнения axis и xfire
 http://xfire.codehaus.org/Stack+Comparison

 PS XFire и Celtix слияние http://xfire.codehaus.org/XFire+and+Celtix+Merge

 Regards,
 Alexey



 On 7/5/07, Arkady Kasianski [EMAIL PROTECTED] wrote:
 Hi everybody,



 I have to choose between Axis 2 and CXF 



 Could someone compare  between both WS frameworks ?



 Thanks in advance



 -Arkady


 This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
 you may review at http://www.amdocs.com/email_disclaimer.asp








IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: Axis2 vs CXF

[Sergey Beryozkin]

I'm not sure ODE has to do anything with CXF ...It's a WS-BPEL impl. What it 
does is kind of orthogonal to what CXF is about, isn't it ? CXF can help one to 
write a service among other things but how to implement the service is 
orthogonal, BPEL-based service implementation is just one possible option 
really and it seems well above CXF or Axis2.

Thanks, Sergey

P.S. Sorry, had to remove your PS as the spam filter was rejecting my reply. 

  - Original Message - 
  From: Dan Connelly 
  To: cxf-user@incubator.apache.org 
  Sent: Thursday, July 05, 2007 5:39 PM
  Subject: Re: Axis2 vs CXF


  My advice:  Pick your ESB wisely (first).

  The important comparison checklist to look at would be the spec-off between 
WSO2, ServiceMix and (maybe) Mule.

  WSO2 uses Axis2, Synapse and Ode.

  SerivceMix uses CXF.   (What the equivalent for Ode for CXF?)

  Mule ??.

  There is some discussion of this currently at 
http://www.theserverside.com/news/thread.tss?thread_id=46044

 -- Dan Connelly


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: sending POST with emtpy body to RESTFUL server causes error

[Sergey Beryozkin]

Hi Dan

IMHO the Source should be just null if either POST or PUT have an empty body.
Suppose I'd like to write an application on top of Amazon S3 with CXF. There 
one creates buckets with empty PUTs...

Cheers, Sergey

- Original Message - 
From: Dan Diephouse [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Tuesday, July 03, 2007 4:34 PM
Subject: Re: sending POST with emtpy body to RESTFUL server causes error



The question isn't whether its OK to POST with an empty body. The question
is whether its correct Provider semantics to POST with an empty body. I feel
that the Provider interface implies that there should at least be a root XML
element. The Spec/Javadocs are kind of moot on this point though. I'm not
fundamentally opposed to changing this assumption, but I think thats why it
is the way it is...
- Dan

On 7/2/07, Conrad O'Dea [EMAIL PROTECTED] wrote:


Hi,

if a client attempts to send a POST with an empty body to a RESTful
service, the server throws the exception below.  This can be easily
reproduced in the restful_dispatch sample by changing
   InputStream in = url.openStream();
to
   HttpURLConnection conn = (HttpURLConnection)url.openConnection();
   conn.setRequestMethod(PUT);
   InputStream in = conn.getInputStream();

I am guessing that this is not intentional.

Note that it is possible to use POST even without supplying data in
an HTTP message body. -- from
http://www.w3.org/2001/tag/doc/whenToUseGet.html

I've  created CXF-758 for it.

thanks
Conrad



 [java] Jul 2, 2007 3:33:12 PM
org.apache.cxf.phase.PhaseInterceptorChain doIntercept
 [java] INFO: Interceptor has thrown exception, unwinding now
 [java] org.apache.cxf.interceptor.Fault: Could not parse the XML
stream.
 [java] at
org.apache.cxf.databinding.source.XMLStreamDataReader.read(
XMLStreamDataReader.java:96)
 [java] at
org.apache.cxf.databinding.source.XMLStreamDataReader.read(
XMLStreamDataReader.java:86)
 [java] at
org.apache.cxf.databinding.source.XMLStreamDataReader.read(
XMLStreamDataReader.java:48)
 [java] at

org.apache.cxf.jaxws.interceptors.ProviderInDatabindingInterceptor.handleMessage
(ProviderInDatabindingInterceptor.java:103)
 [java] at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
PhaseInterceptorChain.java:206)
 [java] at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(
ChainInitiationObserver.java:67)
 [java] at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(
JettyHTTPDestination.java:253)
 [java] at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(
JettyHTTPDestination.java:213)
 [java] at
org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(
JettyHTTPHandler.java:54)
 [java] at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
 [java] at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
 [java] at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(
ContextHandlerCollection.java:211)
 [java] at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
 [java] at org.mortbay.jetty.Server.handle(Server.java:281)
 [java] at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
 [java] at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(
HttpConnection.java:821)
 [java] at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java
:513)
 [java] at
org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
 [java] at
org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
 [java] at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java
:368)
 [java] at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java
:442)
 [java] Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected
EOF in prolog
 [java]  at [row,col {unknown-source}]: [1,0]
 [java] at
com.ctc.wstx.sr.StreamScanner.throwUnexpectedEOF(StreamScanner.java:661)
 [java] at
com.ctc.wstx.sr.BasicStreamReader.handleEOF(BasicStreamReader.java:2134)
 [java] at
com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java
:2040)
 [java] at
com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1069)
 [java] at
org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:663)
 [java] at org.apache.cxf.staxutils.StaxUtils.read(StaxUtils.java
:518)
 [java] at
org.apache.cxf.databinding.source.XMLStreamDataReader.read(
XMLStreamDataReader.java:93)
 [java] ... 20 more





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog




IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: cannot implement service using ProviderDataSource

[Sergey Beryozkin]

Hi

I remember adding a system test as part of the patch where a provider is parameterized with DataSource, I'm wondering is it still 
there ?


Cheers, Sergey
- Original Message - 
From: Conrad O'Dea [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Wednesday, June 20, 2007 11:23 AM
Subject: cannot implement service using ProviderDataSource



Howdy,

I'm trying to create a service with ProviderDataSource which is
published using XML/HTTP.  I can publish the endpoint without problem
but invoking on the service does not work.

My Provider is declared as follows:

@WebServiceProvider(serviceName = FooProvider)
@ServiceMode(value = Service.Mode.MESSAGE)
@BindingType(value = http://cxf.apache.org/bindings/xformat;)
public class FooProvider implements ProviderDataSource {
 ...
 public DataSource invoke(DataSource msg) {
   ...
 }
}
When my client invokes on this endpoint (as simple GET will do), I get
the NPE below.  I've debugged through this and when CXF is building
the InterfaceInfo bean for the service, it is not recognizing the
invoke method of the Provider implementation.  This is because
JaxWsServiceFactoryBean.isValid calls
WebServiceProviderConfiguration.isOperation which (amongst other
things) checks:

  (Source.class.isAssignableFrom(method.getParameterTypes()[0])
  || SOAPMessage.class.isAssignableFrom(method.getParameterTypes()[0])

so it looks like DataSource is not supported.  This is something that
worked previously. Is there anything else I need to do to re-enable
DataSource?

thanks
Conrad


INFO: Interceptor has thrown exception, unwinding now

java.lang.NullPointerException

at 
org.apache.cxf.frontend.SimpleMethodDispatcher.getMethod(SimpleMethodDispatcher.java:92)

at 
org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:51)

at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:56)

at 
org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)

at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:87)

at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:206)

at 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:67)

at 
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:253)

at 
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:213)

at 
org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:54)

at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)

at 
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)

at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)

at org.mortbay.jetty.Server.handle(Server.java:285)

at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)

at 
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)

at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)

at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)

at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)

at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:368)

at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) 



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: cannot implement service using ProviderDataSource

[Sergey Beryozkin]

Hi

It's in

trunk/systests/src/test/java/org/apache/cxf/systest/provider/

AttachmentProviderXMLClientServerTest.java
AttachmentStreamSourceXMLProvider.java

Unfortunately this test does'not use DataSource as I thought

Cheers, Sergey

- Original Message - 
From: Conrad O'Dea [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Wednesday, June 20, 2007 11:53 AM
Subject: Re: cannot implement service using ProviderDataSource



Hi Sergey,

On 6/20/07, Sergey Beryozkin [EMAIL PROTECTED] wrote:

Hi

I remember adding a system test as part of the patch where a provider is 
parameterized with DataSource, I'm wondering is it still
there ?


The only references to DataSource appear to be in relation to SwA
support and a ContextPropertiesMappingTest which does not look like
it's a system test. Do you remember where it lived?
BTW, I've created CXF-741 for this.



Cheers, Sergey
- Original Message -
From: Conrad O'Dea [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Wednesday, June 20, 2007 11:23 AM
Subject: cannot implement service using ProviderDataSource


 Howdy,

 I'm trying to create a service with ProviderDataSource which is
 published using XML/HTTP.  I can publish the endpoint without problem
 but invoking on the service does not work.

 My Provider is declared as follows:

 @WebServiceProvider(serviceName = FooProvider)
 @ServiceMode(value = Service.Mode.MESSAGE)
 @BindingType(value = http://cxf.apache.org/bindings/xformat;)
 public class FooProvider implements ProviderDataSource {
  ...
  public DataSource invoke(DataSource msg) {
...
  }
 }
 When my client invokes on this endpoint (as simple GET will do), I get
 the NPE below.  I've debugged through this and when CXF is building
 the InterfaceInfo bean for the service, it is not recognizing the
 invoke method of the Provider implementation.  This is because
 JaxWsServiceFactoryBean.isValid calls
 WebServiceProviderConfiguration.isOperation which (amongst other
 things) checks:

   (Source.class.isAssignableFrom(method.getParameterTypes()[0])
   || SOAPMessage.class.isAssignableFrom(method.getParameterTypes()[0])

 so it looks like DataSource is not supported.  This is something that
 worked previously. Is there anything else I need to do to re-enable
 DataSource?

 thanks
 Conrad


 INFO: Interceptor has thrown exception, unwinding now

 java.lang.NullPointerException

 at 
org.apache.cxf.frontend.SimpleMethodDispatcher.getMethod(SimpleMethodDispatcher.java:92)

 at 
org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:51)

 at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:56)

 at 
org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)

 at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:87)

 at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:206)

 at 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:67)

 at 
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:253)

 at 
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:213)

 at 
org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:54)

 at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)

 at 
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)

 at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)

 at org.mortbay.jetty.Server.handle(Server.java:285)

 at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)

 at 
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)

 at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)

 at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)

 at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)

 at 
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:368)

 at 
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland




IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: Wsdl returned from secure service

[Sergey Beryozkin]

Hi

Can't resist :-)

 God I love XML! They say it's flexible!

It's flexible. All depends on how it's used and in what contexts it's used. 
It's good for ensuring the interoperability on the wire but may or may not be 
the best fit for doing the configuration. 

Cheers, Sergey
  - Original Message - 
  From: Sergey Beryozkin 
  To: cxf-user@incubator.apache.org 
  Sent: Monday, June 11, 2007 2:40 PM
  Subject: Re: Wsdl returned from secure service


  Hi

  This is a bit scary :-)
  I think I can remember a catalog solution being discussed. so that this 
xsi:location can be dropped, is it feasible to apply that catalog solution 
somehow ?

  http://cxf.apache.org/transports/http-jetty/configuration
http://cxf.apache.org/schemas/configuration/http-jetty.xsd
  http://cxf.apache.org/transports/http/configuration
http://cxf.apache.org/schemas/configuration/http-conf.xsd

  Can http-jetty.xsd import http://cxf.apache.org/transports/http/configuration 
? to avoid this extra location details for the http-conf.xsd ?

  Cheers, Sergey



  - Original Message - 
  From: Polar Humenn [EMAIL PROTECTED]
  To: cxf-user@incubator.apache.org
  Sent: Monday, June 11, 2007 2:34 PM
  Subject: Re: Wsdl returned from secure service


   Now that I read my own email, (uggg, mistake) just let me give you the 
   whole schema location
   attribute.
   
   
   xsi:schemaLocation=
  http://cxf.apache.org/transports/http-jetty/configuration
http://cxf.apache.org/schemas/configuration/http-jetty.xsd
  http://cxf.apache.org/transports/http/configuration
http://cxf.apache.org/schemas/configuration/http-conf.xsd
  http://cxf.apache.org/configuration/security
http://cxf.apache.org/schemas/configuration/security.xsd
  http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd;
   
   I think just a general rule is that all CXF configuration schemas are 
   found in
   
  http://cxf.apache.org/schemas/configuration/;
   
   Andrea can correct me if I'm wrong. Note the plural schemas, and the 
   singular configuration.
   Namespace names, however, seems to be a completely different matter.
   
   Cheers,
   -Polar
   
   Polar Humenn wrote:
   Richard, see below:
  
   I think you have some things mis-typed (and schema validation doesn't 
   complain on things
   like missing schema locations). God I love XML! They say it's 
   flexible! So why
   program in a programming language?
  
   Anyway, see below, hopefully it will help.
  
  
   Shaw, Richard A wrote:
   I get another error now which I can't understand.
  
   My server needs to talk to another service in order to initialise 
   itself. When it tries to talk to the other service it gives me an 
   error based on my service.xml.
  
   I guessing that it has nothing to do with who I'm talking to but with 
   creating the bus using the service.xml file.
   11-Jun-2007 10:11:55 org.apache.cxf.bus.spring.SpringBusFactory 
   createBus
   WARNING: Failed to create application context.
   org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: 
   Line 33 in XML document from class path resource [etc/server.xml] is 
   invalid; nested exception is org.xml.sax.SAXParseException: 
   cvc-complex-type.2.4.c: The matching wildcard is strict, but no 
   declaration can be found for element 'httpj:engine-factory'.
   Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The 
   matching wildcard is strict, but no declaration can be found for 
   element 'httpj:engine-factory'.
   at 
   
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:236)
 
  
   at 
   
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:172)
 
  
   at 
   
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:382)
 
  
   at 
   
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:316)
 
  
   at 
   
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:429)
 
  
   at 
   
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3185)
 
  
   at 
   
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1955)
 
  
   at 
   
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:705)
 
  
   at 
   
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:330)
 
  
   at 
   
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1693

Re: changes in the https configuration

[Sergey Beryozkin]

Hi



Just to let everyone know that the solution to this problem was that
the bean name was wrong due to the refactoring of Jetty out of the
http module. That bean name is;

org.apache.cxf.transports.http_jetty.JettyHTTPServerEngine.port#


So the name of the module has changed, that's fine...


HTTPListenerConfigBean bean =
(HTTPListenerConfigBean)beanInstance;


I guess when we try to use this name we'll find out the actuall class of that beanInstance upon the match, but do you know by any 
chance what is the class name is ? Has it changed too ? Conrad was saying no HTTPListenerConfigBean instances were being passed to 
configureBean() method




Note difference of http and http_jetty in the package name.

However, I have a question about precedence on this method.
Will Spring Configuration wipe out your setting here, since the
super.configureBean() is after your programmatic call?
Is that your intent?


That worked for us before, but it seems unsafe now that you've asked...That code is suffering from knowing too much about 
internals :-), as far as I remember, the CXXF code which also configures the bean will check if the policy is set and will reset 
only if it's not set...We can change the sequence, but we need to have the configureBean()  working as expected first...


Thanks, Sergey



Cheers,
-Polar

Conrad O'Dea wrote:

H,

I'm in the process of updating a service implementation to an up-to-date snapshot of CXF.  In previous versions we were able to 
programmatically configure an endpoint to be https enabled by registering a Configurer with the Bus and when called, the 
configurer did the following:


public void configureBean(Object beanInstance) {

String beanName = getBeanName(beanInstance);
if (listenerBeanName.equals(beanName)
 sslServerPolicy.getKeystore() != null) {
HTTPListenerConfigBean bean =
(HTTPListenerConfigBean)beanInstance;
if (!bean.isSetSslServer()) {
bean.setSslServer(sslServerPolicy);
}
}
super.configureBean(beanInstance);
}

However, with the latest update, this no longer works.  Firstly, we never see a beanInstance with the right name (previously this 
was: org.apache.cxf.transport.http.JettyHTTPServerEngine.4968).  Secondly, none of the beanInstances visited by the configurer 
are of type HTTPListenerConfigBean.


Is there some other way to set the SSL server policy for the endpoint?

BTW, the Configurer is registered like this:

bus.setExtension(myConfigurer, Configurer.class);

and the endpoint itself is published using the JAX-WS APIs:

Endpoint.publish(address, serviceImpl);

Has something changed recently to affect this?

thanks
Conrad

Re: Why does a JAX-WS client use the WSDL at run time?

[Sergey Beryozkin]

Another reason a client can benefit from using a wsdl is that it might bring extra uptodate information for the client policy 
engine, extra alternative endpoints, etc...


Cheers, Sergey

- Original Message - 
From: Daniel Kulp [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Friday, May 04, 2007 2:23 PM
Subject: Re: Why does a JAX-WS client use the WSDL at run time?



On Thursday 03 May 2007 21:55, Steven E. Harris wrote:

Daniel Kulp [EMAIL PROTECTED] writes:
 Technically, with JAX-WS, you don't need the wsdl.  However, the
 spec does say that if it's available/specified, we're supposed to
 use it.

Use it to supply default values? It seems like a large run time tax
that the WSDL2Java tool -- or something like it -- should be fixing
into code.


There's a couple places it's really used.   One is the actual connection
information.   The URL isn't burned in anywhere.The other thing that
is done is to make sure the WSDL actually matches the code.   For
example, does the interface that you are using actually have matching
operations in the wsdl.

On the server side, if the original WSDL is available, we return it
during ?wsdl processing rather than synthesize one.


.


 You would still need to set the endpoint address though.  That
 doesn't get recorded anywhere.

Oh, as that normally gets read from the WSDL at run time, not from an
annotation on the Service-derived class, right?


Right.

--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog 

Re: Service Versioning Strategies

[Sergey Beryozkin]

This article advocates (implicitly), among other things, for the runtimes to support a forward compatibility, which is a great thing 
to do. On the other hand, changing namespaces is a big-bang style of versioning, sometimes it's necessary, but sometimes it's 
avoidable, it basically makes the newer version of the language be both backward and forward incompatible with the older version.


I'd vote with both hands for CXF to support a must-ignore-rule which is a basic prerequisiute for enabling a forward compatibility. 
This means that the CXF should let those people who are conscious of the costs associated with the namespace change to do the 
compatible evolution, specifically :


* JAXB 2.0+ allows to ignore unrecognized elements, this configuration option 
should be made available to users

Cheers, Sergey


- Original Message - 
From: Guy Pardon [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Monday, April 23, 2007 5:07 PM
Subject: Re: Service Versioning Strategies




Agreed.

I found the following article very useful (after reading it three  times):

http://www.xml.com/pub/a/2004/10/27/extend.html

The nice thing is that it describes compatible versioning so your  version 
upgrades don't ripple out all over.

Guy

On 23-apr-07, at 16:59, Dan Diephouse wrote:


No.  Stepping away from CXF - there is no BEST versioning strategy  in my
mind. Only various bad ones :-)

Some various things I've come up with are:
- Namespace versioning: Create a new schema namespace and new set  of DTOs
for each new version
- Unified Domain Objects: In this scenario you try to map all the  different
versions of your XML data to one set of domain objects. Easier said  then
done... JiBX has some limited support for this, but not enough IMO  to really
be able to do it.
- Deployment versioning: Run multiple versions of your application  at the
same time and give each new version a new URL
- XSLT transformations

There are many sub categories, but I tend to stick to Namespace  versioning
as its relatively straightforward to do, although maintenance can  be a pain.

- Dan

On 4/23/07, Christopher Moesel [EMAIL PROTECTED] wrote:


Does CXF have a recommended service versioning strategy?

-Chris





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: MTOM By Request

[Sergey Beryozkin]

Hi

This is exactly what an MTOM policy assertion is for, please see Optional 
assertions in the policy primer at

http://www.w3.org/TR/2007/WD-ws-policy-primer-20070330/
and the MTOM assertion spec :
http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization/

The service which wishes to support both MTOM-aware and MTOM-unaware clients 
will just do :
in wsdl:service or wsdl:service/wsdl:port :

Policy
  mtom:optimizedMimeSerialization optional=true/
/Policy

The server then determines whether to use the MIME processing or not depending 
on the presence of the a related mime header
Cheers, Sergey

- Original Message - 
From: Dan Diephouse [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Wednesday, April 18, 2007 4:21 PM
Subject: Re: MTOM By Request



How would this work from the Client side? Would it just be always or never
then? I don't think there's a way to detect whether or not MTOM should be
used on the client side of things.

BTW - I fixed your bugs in SVN. We haven't published a new snapshot quite
yet though. That should happen later today I would think.

- Dan

On 4/18/07, Christopher Moesel [EMAIL PROTECTED] wrote:


According to the link below, the .NET 2.0 w/ WSE 3.0 server supports a
feature like this:

quote from link
Note: There are three server MTOM modes: optional, always, and
never.

Always means that the service always requires MTOM messages from the
client and will always return response messages using MTOM.

Never means that MTOM will never be used-and the service will reject
MTOM requests.

Optional (the default) means the service will respond in kind to the
type of message sent by the client. So if the client sends an MTOM
request, it will respond with an MTOM response.
/quote from link

http://www.agilefactor.com/agiledamon/2006/01/mtom-and-microsoft-web-ser
vice.html

-Chris

-Original Message-
From: Christopher Moesel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 18, 2007 10:35 AM
To: cxf-user@incubator.apache.org
Subject: MTOM By Request

I don't know if this goes against any specs or is too difficult to
implement, but it seems to me that this would be a neat feature:

MTOM By Request:
- If a request comes in using MTOM, then respond using MTOM.
- If a request comes in using text/xml, then respond with test/xml.

This way, a single deployed service can support both MTOM-enabled and
non-MTOM-enabled clients.

Any thoughts?

-Chris





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: MTOM By Request

[Sergey Beryozkin]

One clarification :


 I don't think there's a way to detect whether or not MTOM should be
used on the client side of things.


Given the assertion below (which is advertised by a service in its WSDL) the WS-Policy aware client can inspect the service's policy 
assertions and find out that it may use MTOM if it wishes to...Furthermore, the policy-aware client (NET is most likely able to do 
it) can decide through the intersection if it wants to talk to this service depending on whether it supports MTOM or not


Cheers, Sergey

- Original Message - 
From: Sergey Beryozkin [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Wednesday, April 18, 2007 4:33 PM
Subject: Re: MTOM By Request



Hi

This is exactly what an MTOM policy assertion is for, please see Optional 
assertions in the policy primer at

http://www.w3.org/TR/2007/WD-ws-policy-primer-20070330/
and the MTOM assertion spec :
http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization/

The service which wishes to support both MTOM-aware and MTOM-unaware clients 
will just do :
in wsdl:service or wsdl:service/wsdl:port :

Policy
  mtom:optimizedMimeSerialization optional=true/
/Policy

The server then determines whether to use the MIME processing or not depending 
on the presence of the a related mime header
Cheers, Sergey

- Original Message - 
From: Dan Diephouse [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Wednesday, April 18, 2007 4:21 PM
Subject: Re: MTOM By Request



How would this work from the Client side? Would it just be always or never
then? I don't think there's a way to detect whether or not MTOM should be
used on the client side of things.

BTW - I fixed your bugs in SVN. We haven't published a new snapshot quite
yet though. That should happen later today I would think.

- Dan

On 4/18/07, Christopher Moesel [EMAIL PROTECTED] wrote:


According to the link below, the .NET 2.0 w/ WSE 3.0 server supports a
feature like this:

quote from link
Note: There are three server MTOM modes: optional, always, and
never.

Always means that the service always requires MTOM messages from the
client and will always return response messages using MTOM.

Never means that MTOM will never be used-and the service will reject
MTOM requests.

Optional (the default) means the service will respond in kind to the
type of message sent by the client. So if the client sends an MTOM
request, it will respond with an MTOM response.
/quote from link

http://www.agilefactor.com/agiledamon/2006/01/mtom-and-microsoft-web-ser
vice.html

-Chris

-Original Message-
From: Christopher Moesel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 18, 2007 10:35 AM
To: cxf-user@incubator.apache.org
Subject: MTOM By Request

I don't know if this goes against any specs or is too difficult to
implement, but it seems to me that this would be a neat feature:

MTOM By Request:
- If a request comes in using MTOM, then respond using MTOM.
- If a request comes in using text/xml, then respond with test/xml.

This way, a single deployed service can support both MTOM-enabled and
non-MTOM-enabled clients.

Any thoughts?

-Chris





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: MTOM By Request

[Sergey Beryozkin]

I'm just one of those users who knows how things should be done :-) without 
doing much myself :-)


You guys are good!

That's a compliment for the CXF team.

Cheers, Sergey

- Original Message - 
From: Christopher Moesel [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Wednesday, April 18, 2007 4:38 PM
Subject: RE: MTOM By Request


Wow.  You guys are good!  Thanks for educating me!  That's a far better
solution than anything I had proposed. =)

-Chris

-Original Message-
From: Sergey Beryozkin [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 18, 2007 11:38 AM

To: Sergey Beryozkin; cxf-user@incubator.apache.org
Subject: Re: MTOM By Request

One clarification :


 I don't think there's a way to detect whether or not MTOM should be
used on the client side of things.


Given the assertion below (which is advertised by a service in its WSDL)
the WS-Policy aware client can inspect the service's policy 
assertions and find out that it may use MTOM if it wishes

to...Furthermore, the policy-aware client (NET is most likely able to do

it) can decide through the intersection if it wants to talk to this
service depending on whether it supports MTOM or not

Cheers, Sergey

- Original Message - 
From: Sergey Beryozkin [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Wednesday, April 18, 2007 4:33 PM
Subject: Re: MTOM By Request



Hi

This is exactly what an MTOM policy assertion is for, please see

Optional assertions in the policy primer at


http://www.w3.org/TR/2007/WD-ws-policy-primer-20070330/
and the MTOM assertion spec :


http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization/


The service which wishes to support both MTOM-aware and MTOM-unaware

clients will just do :

in wsdl:service or wsdl:service/wsdl:port :

Policy
  mtom:optimizedMimeSerialization optional=true/
/Policy

The server then determines whether to use the MIME processing or not

depending on the presence of the a related mime header

Cheers, Sergey

- Original Message - 
From: Dan Diephouse [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Wednesday, April 18, 2007 4:21 PM
Subject: Re: MTOM By Request



How would this work from the Client side? Would it just be always or

never

then? I don't think there's a way to detect whether or not MTOM

should be

used on the client side of things.

BTW - I fixed your bugs in SVN. We haven't published a new snapshot

quite

yet though. That should happen later today I would think.

- Dan

On 4/18/07, Christopher Moesel [EMAIL PROTECTED] wrote:


According to the link below, the .NET 2.0 w/ WSE 3.0 server supports

a

feature like this:

quote from link
Note: There are three server MTOM modes: optional, always, and
never.

Always means that the service always requires MTOM messages from

the

client and will always return response messages using MTOM.

Never means that MTOM will never be used-and the service will reject
MTOM requests.

Optional (the default) means the service will respond in kind to the
type of message sent by the client. So if the client sends an MTOM
request, it will respond with an MTOM response.
/quote from link



http://www.agilefactor.com/agiledamon/2006/01/mtom-and-microsoft-web-ser

vice.html

-Chris

-Original Message-
From: Christopher Moesel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 18, 2007 10:35 AM
To: cxf-user@incubator.apache.org
Subject: MTOM By Request

I don't know if this goes against any specs or is too difficult to
implement, but it seems to me that this would be a neat feature:

MTOM By Request:
- If a request comes in using MTOM, then respond using MTOM.
- If a request comes in using text/xml, then respond with test/xml.

This way, a single deployed service can support both MTOM-enabled

and

non-MTOM-enabled clients.

Any thoughts?

-Chris





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: MTOM By Request

[Sergey Beryozkin]

Hi Chris

By the way, I think what you've described makes a perfect sense and would work nicely in combination with the MTOM assertion the 
service might use. The MTOM assertion on the service would primarily serve as a hint to a client that MTOM capability is there at 
the service side,

but the client would still need to know if it wants MTOM or not.
If the client is a WS-Policy aware then, upon detecting that MTOM is supported by the service, can automatically engage the 
algorithm you described (check for the size of the outgoing message and if it exceeds a certain limit then do MTOM serialization), 
thus avoiding the need for any related client-side config altogether (except for the size of the message to check, but default might 
do well in many cases).


Cheers, Sergey

- Original Message - 
From: Christopher Moesel [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Wednesday, April 18, 2007 4:38 PM
Subject: RE: MTOM By Request


Wow.  You guys are good!  Thanks for educating me!  That's a far better
solution than anything I had proposed. =)

-Chris

-Original Message-
From: Sergey Beryozkin [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 18, 2007 11:38 AM
To: Sergey Beryozkin; cxf-user@incubator.apache.org
Subject: Re: MTOM By Request

One clarification :


 I don't think there's a way to detect whether or not MTOM should be
used on the client side of things.


Given the assertion below (which is advertised by a service in its WSDL)
the WS-Policy aware client can inspect the service's policy
assertions and find out that it may use MTOM if it wishes
to...Furthermore, the policy-aware client (NET is most likely able to do

it) can decide through the intersection if it wants to talk to this
service depending on whether it supports MTOM or not

Cheers, Sergey

- Original Message - 
From: Sergey Beryozkin [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Wednesday, April 18, 2007 4:33 PM
Subject: Re: MTOM By Request



Hi

This is exactly what an MTOM policy assertion is for, please see

Optional assertions in the policy primer at


http://www.w3.org/TR/2007/WD-ws-policy-primer-20070330/
and the MTOM assertion spec :


http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization/


The service which wishes to support both MTOM-aware and MTOM-unaware

clients will just do :

in wsdl:service or wsdl:service/wsdl:port :

Policy
  mtom:optimizedMimeSerialization optional=true/
/Policy

The server then determines whether to use the MIME processing or not

depending on the presence of the a related mime header

Cheers, Sergey

- Original Message - 
From: Dan Diephouse [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Sent: Wednesday, April 18, 2007 4:21 PM
Subject: Re: MTOM By Request



How would this work from the Client side? Would it just be always or

never

then? I don't think there's a way to detect whether or not MTOM

should be

used on the client side of things.

BTW - I fixed your bugs in SVN. We haven't published a new snapshot

quite

yet though. That should happen later today I would think.

- Dan

On 4/18/07, Christopher Moesel [EMAIL PROTECTED] wrote:


According to the link below, the .NET 2.0 w/ WSE 3.0 server supports

a

feature like this:

quote from link
Note: There are three server MTOM modes: optional, always, and
never.

Always means that the service always requires MTOM messages from

the

client and will always return response messages using MTOM.

Never means that MTOM will never be used-and the service will reject
MTOM requests.

Optional (the default) means the service will respond in kind to the
type of message sent by the client. So if the client sends an MTOM
request, it will respond with an MTOM response.
/quote from link



http://www.agilefactor.com/agiledamon/2006/01/mtom-and-microsoft-web-ser

vice.html

-Chris

-Original Message-
From: Christopher Moesel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 18, 2007 10:35 AM
To: cxf-user@incubator.apache.org
Subject: MTOM By Request

I don't know if this goes against any specs or is too difficult to
implement, but it seems to me that this would be a neat feature:

MTOM By Request:
- If a request comes in using MTOM, then respond using MTOM.
- If a request comes in using text/xml, then respond with test/xml.

This way, a single deployed service can support both MTOM-enabled

and

non-MTOM-enabled clients.

Any thoughts?

-Chris





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: Importing XSDs in a WSDL

[Sergey Beryozkin]

Hi

IMHO the easiest strategy would be to support
http://localhost:8080/myapp/services/MyService/wsdl queries,

with ?wsdl the only way to serve relative imports is to overwrite importing entities to use absolute URLs.  '/wsdl' allows for the 
composability on the client side while giving the server two options :

* overwrite the url (the only option with ?wsdl)
* map MyService/wsdl to some folder keeping the imports or some query handler and let the client runtime compose the relative URL 
with the original one, most ones can do it easily. Assuming the wsdl retrieved from the 
http://localhost:8080/myapp/services/MyService/wsdl imports two more schemas using relative paths then the client can compose the 
paths like this

http://localhost:8080/myapp/services/MyService/wsdl/imported.xsd
http://localhost:8080/myapp/services/MyService/wsdl/bar/imported.xsd

Inlining won't really work for wsdl imports due to different namespaces...

What would be your opinion on /wsdl like queries as opposed to ?wsdl ones ?

Cheers, Sergey

- Original Message - 
From: Daniel Kulp [EMAIL PROTECTED]

To: cxf-user@incubator.apache.org
Cc: Christopher Moesel [EMAIL PROTECTED]
Sent: Monday, April 16, 2007 2:50 PM
Subject: Re: Importing XSDs in a WSDL




Just FYI:  this is a known restriction at this point.   However, I'm
going to be working on fixing it this week.   It is a big hold up for
some of the work I need done.

Dan


On Monday 16 April 2007 08:50, Christopher Moesel wrote:

Hello,

I would prefer to keep my schema types in a separate XSD file rather
than define them inside the WSDL file.  So, I use an xsd:import to
accomplish this.

This appears to work well in CXF with one exception:
When I view the wsdl at
http://localhost:8080/myapp/services/MyService?wsdl the import doesn't
resolve correctly, since it is a relative import.

I want to avoid using an absolute address for the import, since this
will be deployed on several different servers.  I suppose I could use
../MyService.xsd as a relative address, but then that affects my
project's file structure so that I can't have the XSD and WSDL in the
same directory.

Any ideas or work-arounds?

Thanks,
Chris


--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog