Skipping xjc in wsdl2java
Hi, I would like to reuse my xsd generated classes in different projects. Therefore I would like to have a stand alone project which just contains the xsd and generates the classes. These classes should be put in my maven repository. After that I would like to tell wsdl2java not to generate the jaxb stuff, but just the wsdl interface classes and reuse the jaxb classes from the repository. Is this possible? Thanks and regards Cybexion -- View this message in context: http://www.nabble.com/Skipping-xjc-in-wsdl2java-tp15200075p15200075.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: List parameters appearing with no entries on server side
ronanf wrote: Thanks for that Dan, Yes I am running CXF 2.0.3. In the end my problem was I have an asm1*.jar in my build path (this is needed for the version of Hibernate I'm running). But CXF requires asm2* or asm3* as you pointed out. I got around this by using the cglib-nodep JAR with Hibernate, which includes its own internal copy of the ASM classes under a different package name and can happily co-exist with another version of ASM on the classpath. Ian -- Ian Roberts | Department of Computer Science [EMAIL PROTECTED] | University of Sheffield, UK
Re: Question on URI resolution and WS endpoints.
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: customizing FaultCode in a SOAP:Fault response
dkulp wrote: Hmm... That's not good. I more or less expected that to work. Not sure why it wouldn't be.. Ok. Couple questions: 1) Are you throwing this from your impl, and interceptor, or a jaxws handler? I'm throwing Exception inside my webService application code. dkulp wrote: 2) Are you using the JAXWS frontend or the simple frontend? I am using spring configuration with jaxws:endpoint definitions so I guess I am using jaxws frontend. dkulp wrote: 3) Any chance you could try 2.0.4 (released today)? I have tried it this morning, upgraded cxf-2.0.3-incubator to 2.0.4 version and all other libraries which seemed to me were in older version in 2.0.3 libs bundle (asm, saaj-api, saaj-impl). Unfortunately it doesn't resolve this problem. dkulp wrote: If it's jaxws, you COULD try building up and throwing a javax.xml.ws.soap.SOAPFaultException, but that kind of sucks. Dan Well, SOAPFaultException requires class extending javax.xml.soap.SOAPFault interface as a constructor parameter. Do you suggest using some specific implementing class? Thanks for your help, az -- View this message in context: http://www.nabble.com/customizing-FaultCode-in-a-SOAP%3AFault-response-tp15091146p15203527.html Sent from the cxf-user mailing list archive at Nabble.com.
CXF - username token authentication with SSL
Hi, What is the right way to call a secure web service that authenticates the requests based on username token authentication in CXF ? How can I accomplish this with Client Outbound Endpoint ? Or should I implement my client ssing a web service client directly ? Also can I use https connector with CXF-transport in mule ? Any help will be appreciated. Thanks. -- View this message in context: http://www.nabble.com/CXF---username-token-authentication-with-SSL-tp15203683p15203683.html Sent from the cxf-user mailing list archive at Nabble.com.
changing WSDL port location on HTTP proxied URL
We are currently creating a Web Service using CXF configured with Spring and Jax-ws annotations. The web service runs on a server that is proxied (using Apache 2 httpd) from an external URL to the internal URL. So, the public URL of the WSDL is (for example) - https://public.url/services/aservice?wsdl The internal location (un-proxied) of this URL is - http://internal.server:8088/services/aservice?wsdl When an external request for the WSDL comes in, the wsdl:port section specifies the location of the service as follows - wsdl:service name=AService wsdl:port binding=tns:AServiceSoapBinding name=APort soap:address location=http://internal.server:8088/services/aservice/ /wsdl:port /wsdl:service The question : Is there any way of changing the automatically generated WSDL port location through the Spring configuration files ? I want the soap:address to be the EXTERNAL URL, not the internal one. The solution needs to work for deployment to several servers with different external URLS (we have various development and testing servers). Thanks in advance for any helpful replies !! Richard Newton Richard Newton Analyst Developer IT Department Tel 0870 118 1918 Fax 0870 118 2068 [EMAIL PROTECTED] able2buy able2buy is a trading style of Matt E-commerce Solutions Limited. This e-mail is confidential. Matt E-commerce Solutions Limited, 400 Metroplex, Broadway, Salford, Manchester, M50 2UE, Registered in England, Company number 6370751.
Re: CXF - username token authentication with SSL
I am sorry I shoud have post this message to mule forum. blacksheep wrote: Hi, What is the right way to call a secure web service that authenticates the requests based on username token authentication in CXF ? How can I accomplish this with Client Outbound Endpoint ? Or should I implement my client ssing a web service client directly ? Also can I use https connector with CXF-transport in mule ? Any help will be appreciated. Thanks. -- View this message in context: http://www.nabble.com/CXF---username-token-authentication-with-SSL-tp15203683p15203686.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem generating WSDL from Java API with CXF 2.0.3
Regarding target namespace and the elementFormDefault issues...
Interestingly the package-info.java approach doesn't seem to work.
Whilst this sets the default element form to qualified, each element is
then generated with the form=unqualified attribute set. D'oh! I guess
I'll have to use the XmlElement approach. Will let you know what
happens.
I've also set the XmlSchema namespace as you have suggested, and have
explicitly set the @WebService(targetNamespace) to the same value but I
still get a WSDL targetNamespace derived from the package name. How do I
override this behaviour?
The package-info.java has:
@javax.xml.bind.annotation.XmlSchema(
namespace = http://com.volantis.xmlns/2008/01/mss/user-module;,
elementFormDefault = javax.xml.bind.annotation.XmlNsForm.QUALIFIED)
package com.volantis.openapi.mss.usermodule;
and the SEI interface has:
@WebService(name = UserModule,
targetNamespace =
http://com.volantis.xmlns/2008/01/mss/user-module;)
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT,
use = SOAPBinding.Use.LITERAL,
parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
public interface UserModule {
...
ListUser getSubscribers(
@WebParam(name = application)
final String applicationID,
@WebParam(name = subscription)
final String subscriptionID,
@WebParam(name = includeExtensionParameters)
final boolean includeExtensionParameters,
@WebParam(name = includeSubscriptions)
final boolean includeSubscriptions) throws PersistenceException;
...
but the WSDL is generated with:
wsdl:definitions name=UserModuleService
targetNamespace=http://com.volantis.openapi.mss.usermodule;
xmlns:ns1=http://com.volantis.xmlns/2008/01/mss/user-module;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:tns=http://com.volantis.openapi.mss.usermodule;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
wsdl:types
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns:tns=http://com.volantis.xmlns/2008/01/mss/user-module;
attributeFormDefault=unqualified
elementFormDefault=qualified
targetNamespace=http://com.volantis.xmlns/2008/01/mss/user-module;
...
xs:complexType name=getSubscribersResponse
xs:sequence
xs:element form=unqualified maxOccurs=unbounded
minOccurs=0 name=return type=xs:anyType/
/xs:sequence
/xs:complexType
...
/xs:schema
/wsdl:types
wsdl:message name=getSubscribersResponse
wsdl:part name=parameters element=ns1:getSubscribersResponse
/wsdl:part
/wsdl:message
...
What I want to see is:
* the WSDL targetNamespace matching the ns1 URI
* the elements generated with form qualified
* the sequence returned by getSubscribersResponse using the
generated schema type for User.
Any suggestions?
Phil :n(
On Mon, 2008-01-28 at 10:31 -0500, Daniel Kulp wrote:
2) Create a package-info.java class in the package containing the
beans.
It would look like:
@javax.xml.bind.annotation.XmlSchema(
namespace = http://the.namespace.to.use;,
elementFormDefault =
javax.xml.bind.annotation.XmlNsForm.QUALIFIED)
package the package;
Wsdl2java ignores soapAction?
I tried to apply wsdl2java to the WSDL below. The WSDL operations
defined are both referring to the same type element as input message,
so the soap body are the same for both the messages. To solve this
collision, i added the soapAction to the binding, but the wsdl2java
seems to ignore it.
The message returned by the tool is:
WSDLToJava Error : Non unique body parts! In a port, operations must
have unique operation signaure on the wire for successful dispatch. In
port {urn:test}EchoTestPort, Operations {urn:test}echoRequestB and
{urn:test}echoRequestA have the same request body block
{urn:test}TRequestA
That's correct (if no soapAction is defined), but in my opinion
shouldn't be returned with the soapAction defined.
Marco.
?xml version=1.0 encoding=UTF-8 standalone=no?definitions
xmlns=http://schemas.xmlsoap.org/wsdl/; xmlns:ns1=http://test.it;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:soap11=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:soap12=http://www.w3.org/2003/05/soap-envelope;
xmlns:soapenc11=http://schemas.xmlsoap.org/soap/encoding/;
xmlns:soapenc12=http://www.w3.org/2003/05/soap-encoding;
xmlns:tns=urn:test xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:wsdlsoap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema; targetNamespace=urn:test
types
xsd:schema attributeFormDefault=qualified
elementFormDefault=qualified targetNamespace=urn:test
xsd:complexType name=TypeA
xsd:sequence
xsd:element maxOccurs=1 minOccurs=1
name=dataBoolean nillable=false type=xsd:boolean/
/xsd:sequence
/xsd:complexType
xsd:complexType name=TypeB
xsd:sequence
xsd:element maxOccurs=1 minOccurs=1
name=dataString nillable=false type=xsd:string/
/xsd:sequence
/xsd:complexType
xsd:element name=TRequestA
xsd:complexType
xsd:sequence
xsd:element maxOccurs=1 minOccurs=1
name=typeA nillable=false type=tns:TypeA/
/xsd:sequence
/xsd:complexType
/xsd:element
xsd:element name=TRequestB
xsd:complexType
xsd:sequence
xsd:element maxOccurs=1 minOccurs=1
name=typeB nillable=false type=tns:TypeB/
/xsd:sequence
/xsd:complexType
/xsd:element
xsd:element name=TResponseAB
xsd:complexType
xsd:sequence
xsd:element minOccurs=0 name=typeA
type=tns:TypeA/
xsd:element minOccurs=0 name=typeB
type=tns:TypeB/
/xsd:sequence
/xsd:complexType
/xsd:element
/xsd:schema
/types
message name=MRequestA
part element=tns:TRequestA name=MRequestA
/part
/message
message name=MRequestB
part element=tns:TRequestB name=MRequestB
/part
/message
message name=MRequestAB
part element=tns:TResponseAB name=MRequestAB
/part
/message
portType name=EchoTestPortType
operation name=echoRequestA
input message=tns:MRequestA name=echoRequestAIn
/input
output message=tns:MRequestAB name=echoRequestAOut
/output
/operation
operation name=echoRequestB
input message=tns:MRequestA name=echoRequestBIn
/input
output message=tns:MRequestAB name=echoRequestBOut
/output
/operation
/portType
binding name=EchoTestBinding type=tns:EchoTestPortType
operation name=echoRequestA
wsdlsoap:operation soapAction=echoRequestA style=document/
input name=echoRequestAIn
wsdlsoap:body use=literal/
/input
output name=echoRequestAOut
wsdlsoap:body use=literal/
/output
/operation
operation name=echoRequestB
wsdlsoap:operation soapAction=echoRequestB style=document/
input name=echoRequestBIn
wsdlsoap:body use=literal/
/input
output name=echoRequestBOut
wsdlsoap:body use=literal/
/output
/operation
/binding
service name=EchoTest
port binding=tns:EchoTestBinding name=EchoTestPort
wsdlsoap:address location=http://localhost/fake_location/
/port
/service
/definitions
Re: jms header properties
Hi Dan, This worked very well! How can I do this on the client side? Thanks! Mayank On 1/28/08, Daniel Kulp [EMAIL PROTECTED] wrote: On Monday 28 January 2008, Mayank Thakore wrote: Hi Daniel, Will BindingProvider.HTTP_PROTOCOL_HEADERS work for JMS also? With 2.0.4, yes. Internally, we just have a PROTOCOL_HEADERS thing in the message that is completely protocol nuetral. The JAX-WS frontend just maps that onto the HTTP_PROTOCOL_HEADERS thing. With 1st option: At the server side, I had to add interceptor. So what I do (in the service implementation) is to put the jms property in a threadlocal variable. Then in an interceptor (invoked prior to send), I use the code mentioned by Willem to put these properties into the message. Do you think this is ok? Any better way? Yes. Inject the WebServiceContext into your service and just set them there. The key would be the class.getName() of the JMS context class. Dan Thanks! Regards Mayank -Original Message- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: Monday, January 28, 2008 22:03 To: cxf-user@incubator.apache.org Cc: Mayank Thakore Subject: Re: jms header properties There are two options: 1) the jms context stuff Willem mentioned. 2) The standard protocol header things from JAX-WS. In the second case, the JMS transport maps the headers onto the BindingProvider.HTTP_PROTOCOL_HEADERS map thing. Thus, the normal stuff applies. HOWEVER: that only works with 2.0.4 (to be released tomorrow) and the 2.1 snapshots.There was a bug that prevented that from working in earlier versions. Dan On Sunday 27 January 2008, Mayank Thakore wrote: Hi, How to set header/property fields in outgoing jms messages? There is lot of configuration examples to set jms destination properties. But I didn't find any for message properties. Thanks and Regards Mayank -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: jms header properties
on server side i used the server response context... i noticed that it only copies the jms message properties, not the header... for the header server request context seems to work... but anyway, i needed only the message properties. how to get the context on the client side? i want to set jms properties on a per message basis. On 1/31/08, Ulhas Bhole [EMAIL PROTECTED] wrote: Which option did you use? you can use JAX-WS requstcontext and responsecontext to get the access to JMS headers at client side. Regards, Ulhas Bhole Mayank Thakore wrote: Hi Dan, This worked very well! How can I do this on the client side? Thanks! Mayank On 1/28/08, Daniel Kulp [EMAIL PROTECTED] wrote: On Monday 28 January 2008, Mayank Thakore wrote: Hi Daniel, Will BindingProvider.HTTP_PROTOCOL_HEADERS work for JMS also? With 2.0.4, yes. Internally, we just have a PROTOCOL_HEADERS thing in the message that is completely protocol nuetral. The JAX-WS frontend just maps that onto the HTTP_PROTOCOL_HEADERS thing. With 1st option: At the server side, I had to add interceptor. So what I do (in the service implementation) is to put the jms property in a threadlocal variable. Then in an interceptor (invoked prior to send), I use the code mentioned by Willem to put these properties into the message. Do you think this is ok? Any better way? Yes. Inject the WebServiceContext into your service and just set them there. The key would be the class.getName() of the JMS context class. Dan Thanks! Regards Mayank -Original Message- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: Monday, January 28, 2008 22:03 To: cxf-user@incubator.apache.org Cc: Mayank Thakore Subject: Re: jms header properties There are two options: 1) the jms context stuff Willem mentioned. 2) The standard protocol header things from JAX-WS. In the second case, the JMS transport maps the headers onto the BindingProvider.HTTP_PROTOCOL_HEADERS map thing. Thus, the normal stuff applies. HOWEVER: that only works with 2.0.4 (to be released tomorrow) and the 2.1 snapshots.There was a bug that prevented that from working in earlier versions. Dan On Sunday 27 January 2008, Mayank Thakore wrote: Hi, How to set header/property fields in outgoing jms messages? There is lot of configuration examples to set jms destination properties. But I didn't find any for message properties. Thanks and Regards Mayank -- 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: jms header properties
Which option did you use? you can use JAX-WS requstcontext and responsecontext to get the access to JMS headers at client side. Regards, Ulhas Bhole Mayank Thakore wrote: Hi Dan, This worked very well! How can I do this on the client side? Thanks! Mayank On 1/28/08, Daniel Kulp [EMAIL PROTECTED] wrote: On Monday 28 January 2008, Mayank Thakore wrote: Hi Daniel, Will BindingProvider.HTTP_PROTOCOL_HEADERS work for JMS also? With 2.0.4, yes. Internally, we just have a PROTOCOL_HEADERS thing in the message that is completely protocol nuetral. The JAX-WS frontend just maps that onto the HTTP_PROTOCOL_HEADERS thing. With 1st option: At the server side, I had to add interceptor. So what I do (in the service implementation) is to put the jms property in a threadlocal variable. Then in an interceptor (invoked prior to send), I use the code mentioned by Willem to put these properties into the message. Do you think this is ok? Any better way? Yes. Inject the WebServiceContext into your service and just set them there. The key would be the class.getName() of the JMS context class. Dan Thanks! Regards Mayank -Original Message- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: Monday, January 28, 2008 22:03 To: cxf-user@incubator.apache.org Cc: Mayank Thakore Subject: Re: jms header properties There are two options: 1) the jms context stuff Willem mentioned. 2) The standard protocol header things from JAX-WS. In the second case, the JMS transport maps the headers onto the BindingProvider.HTTP_PROTOCOL_HEADERS map thing. Thus, the normal stuff applies. HOWEVER: that only works with 2.0.4 (to be released tomorrow) and the 2.1 snapshots.There was a bug that prevented that from working in earlier versions. Dan On Sunday 27 January 2008, Mayank Thakore wrote: Hi, How to set header/property fields in outgoing jms messages? There is lot of configuration examples to set jms destination properties. But I didn't find any for message properties. Thanks and Regards Mayank -- 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: jms header properties
If you check the following system test it will show you how to use context. http://svn.apache.org/repos/asf/incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jms/JMSClientServerTest.java Regards, Ulhas Bhole Mayank Thakore wrote: on server side i used the server response context... i noticed that it only copies the jms message properties, not the header... for the header server request context seems to work... but anyway, i needed only the message properties. how to get the context on the client side? i want to set jms properties on a per message basis. On 1/31/08, Ulhas Bhole [EMAIL PROTECTED] wrote: Which option did you use? you can use JAX-WS requstcontext and responsecontext to get the access to JMS headers at client side. Regards, Ulhas Bhole Mayank Thakore wrote: Hi Dan, This worked very well! How can I do this on the client side? Thanks! Mayank On 1/28/08, Daniel Kulp [EMAIL PROTECTED] wrote: On Monday 28 January 2008, Mayank Thakore wrote: Hi Daniel, Will BindingProvider.HTTP_PROTOCOL_HEADERS work for JMS also? With 2.0.4, yes. Internally, we just have a PROTOCOL_HEADERS thing in the message that is completely protocol nuetral. The JAX-WS frontend just maps that onto the HTTP_PROTOCOL_HEADERS thing. With 1st option: At the server side, I had to add interceptor. So what I do (in the service implementation) is to put the jms property in a threadlocal variable. Then in an interceptor (invoked prior to send), I use the code mentioned by Willem to put these properties into the message. Do you think this is ok? Any better way? Yes. Inject the WebServiceContext into your service and just set them there. The key would be the class.getName() of the JMS context class. Dan Thanks! Regards Mayank -Original Message- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: Monday, January 28, 2008 22:03 To: cxf-user@incubator.apache.org Cc: Mayank Thakore Subject: Re: jms header properties There are two options: 1) the jms context stuff Willem mentioned. 2) The standard protocol header things from JAX-WS. In the second case, the JMS transport maps the headers onto the BindingProvider.HTTP_PROTOCOL_HEADERS map thing. Thus, the normal stuff applies. HOWEVER: that only works with 2.0.4 (to be released tomorrow) and the 2.1 snapshots.There was a bug that prevented that from working in earlier versions. Dan On Sunday 27 January 2008, Mayank Thakore wrote: Hi, How to set header/property fields in outgoing jms messages? There is lot of configuration examples to set jms destination properties. But I didn't find any for message properties. Thanks and Regards Mayank -- 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 IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: CXF on WebLogic 9.2
After a bit more research it seems that this error was because Weblogic is
trying to use it's own older version of JSR 181. So, I prepended
geronimo-ws-metadeta_2.0_spec-1.1.1.jar to the Weblogic classpath and am now
getting:
Jan 31, 2008 11:46:07 AM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass
INFO: Creating Service {http://service.auth.sd.sherwin.com/}swAuthService
from class com.sherwin.sd.auth.service.AuthServiceImpl
2008-01-31 11:46:07 ContextLoader [ERROR] Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean
with name 'auth': Invocation of init method failed; nested exception is
java.lang.LinkageError: loader constraints violated when linking
javax/xml/namespace/QName class
Caused by:
java.lang.LinkageError: loader constraints violated when linking
javax/xml/namespace/QName class
at
com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl.clinit(RuntimeBuiltinLeafInfoImpl.java:186)
at
com.sun.xml.bind.v2.model.impl.RuntimeTypeInfoSetImpl.init(RuntimeTypeInfoSetImpl.java:25)
at
com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet(RuntimeModelBuilder.java:84)
at
com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet(RuntimeModelBuilder.java:41)
at
com.sun.xml.bind.v2.model.impl.ModelBuilder.init(ModelBuilder.java:104)
at
com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.init(RuntimeModelBuilder.java:49)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:372)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.init(JAXBContextImpl.java:236)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:76)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:210)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:366)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at
org.apache.cxf.jaxb.JAXBDataBinding.createJAXBContext(JAXBDataBinding.java:427)
at
org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:221)
at
org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:313)
at
org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:362)
at
org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:156)
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:89)
at
org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:74)
at
org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:108)
at
org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:147)
at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:299)
at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:230)
at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:181)
at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:352)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1240)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1205)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1171)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:425)
at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:251)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:156)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:248)
at
RE: Question on URI resolution and WS endpoints.
Yeah, after reading the source code, I realized that the path resolution
happens in 2 phases. The first is the servelet selection based on the first
address.startsWith(path) match, and the second the score based match for the
URL once it gets into the servlet. Because of that overlapping URI path
elements won't ever get to the appropriate class (at least in my example).
The JSR-311 bindings look neat though (at least based on your description) so
I'll try to take a look at it. Thanks for the info!
-- Cheers
-- James
-Original Message-
From: Sergey Beryozkin [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 31, 2008 2:52 AM
To: cxf-user@incubator.apache.org
Subject: Re: Question on URI resolution and WS endpoints.
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
Re: CXF on WebLogic 9.2
I found this guide on the CFX wiki, which confirms the issue is with WebLogic
overriding geronimo-ws-metadeta_2.0_spec-1.1.1.jar
http://cwiki.apache.org/CXF20DOC/appserverguide.html#AppServerGuide-WebLogic
However, following their instructions I still get the QName error.
-Ben
chengas123 wrote:
After a bit more research it seems that this error was because Weblogic is
trying to use it's own older version of JSR 181. So, I prepended
geronimo-ws-metadeta_2.0_spec-1.1.1.jar to the Weblogic classpath and am
now getting:
Jan 31, 2008 11:46:07 AM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass
INFO: Creating Service {http://service.auth.sd.sherwin.com/}swAuthService
from class com.sherwin.sd.auth.service.AuthServiceImpl
2008-01-31 11:46:07 ContextLoader [ERROR] Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'auth': Invocation of init method failed; nested exception
is java.lang.LinkageError: loader constraints violated when linking
javax/xml/namespace/QName class
Caused by:
java.lang.LinkageError: loader constraints violated when linking
javax/xml/namespace/QName class
at
com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl.clinit(RuntimeBuiltinLeafInfoImpl.java:186)
at
com.sun.xml.bind.v2.model.impl.RuntimeTypeInfoSetImpl.init(RuntimeTypeInfoSetImpl.java:25)
at
com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet(RuntimeModelBuilder.java:84)
at
com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet(RuntimeModelBuilder.java:41)
at
com.sun.xml.bind.v2.model.impl.ModelBuilder.init(ModelBuilder.java:104)
at
com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.init(RuntimeModelBuilder.java:49)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:372)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.init(JAXBContextImpl.java:236)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:76)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:210)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:366)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at
org.apache.cxf.jaxb.JAXBDataBinding.createJAXBContext(JAXBDataBinding.java:427)
at
org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:221)
at
org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:313)
at
org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:362)
at
org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:156)
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:89)
at
org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:74)
at
org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:108)
at
org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:147)
at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:299)
at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:230)
at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:181)
at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:352)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1240)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1205)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1171)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:425)
at
Re: CXF on WebLogic 9.2
Unfortunately that does not work either. I get the stacktrace below. I feel like I was closest overriding geronimo-ws-metadeta_2.0_spec-1.1.1.jar: http://cwiki.apache.org/CXF20DOC/appserverguide.html#AppServerGuide-WebLogic However, I then get the QName error. The wiki says in multiple places to Remove javax.xml.namespace.QName from stax-api shiped with CXF if you get this error, but there's no such file as stax-api.jar, so I have no clue what they're talking about (nor could I find that file in any jars I have included in my project). Thanks, Ben Jan 31, 2008 2:22:40 PM EST Error J2EE BEA-160197 Unable to load descriptor C:\appServers\bea9\weblogic92\server\lib\consoleapp/META-INF/application.xml of module consoleapp. The error is weblogic.descriptor.DescriptorException: Unmarshaller failed at weblogic.descriptor.internal.MarshallerFactory$1.createDescriptor(MarshallerFactory.java:147) at weblogic.descriptor.DescriptorManager.createDescriptor(DescriptorManager.java:280) at weblogic.descriptor.DescriptorManager.createDescriptor(DescriptorManager.java:248) at weblogic.application.descriptor.AbstractDescriptorLoader2.getDescriptorBeanFromReader(AbstractDescriptorLoader2.java:749) at weblogic.application.descriptor.AbstractDescriptorLoader2.createDescriptorBean(AbstractDescriptorLoader2.java:376) at weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescriptorBeanWithoutPlan(AbstractDescriptorLoader2.java:720) at weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescriptorBean(AbstractDescriptorLoader2.java:729) at weblogic.application.ApplicationDescriptor.getApplicationDescriptor(ApplicationDescriptor.java:277) at weblogic.application.internal.EarDeploymentFactory.findOrCreateComponentMBeans(EarDeploymentFactory.java:174) at weblogic.application.internal.MBeanFactoryImpl.findOrCreateComponentMBeans(MBeanFactoryImpl.java:48) at weblogic.application.internal.MBeanFactoryImpl.createComponentMBeans(MBeanFactoryImpl.java:110) at weblogic.application.internal.MBeanFactoryImpl.initializeMBeans(MBeanFactoryImpl.java:76) at weblogic.deploy.internal.InternalAppProcessor.createBeansForInternalApp(InternalAppProcessor.java:396) at weblogic.deploy.internal.InternalAppProcessor.stageFilesAndCreateBeansForInternalApp(InternalAppProcessor.java:250) at weblogic.deploy.internal.InternalAppProcessor.updateConfiguration(InternalAppProcessor.java:196) at weblogic.management.deploy.internal.DeploymentServerService.init(DeploymentServerService.java:144) at weblogic.management.deploy.internal.DeploymentPreStandbyServerService.start(DeploymentPreStandbyServerService.java:32) at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209) at weblogic.work.ExecuteThread.run(ExecuteThread.java:181) Caused by: com.bea.xml.XmlException: weblogic.descriptor.BeanAlreadyExistsException: Bean already exists: [EMAIL PROTECTED](/[EMAIL PROTECTED]) at com.bea.staxb.runtime.internal.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:54) at com.bea.staxb.runtime.internal.RuntimeBindingType$BeanRuntimeProperty.setValue(RuntimeBindingType.java:483) at com.bea.staxb.runtime.internal.AttributeRuntimeBindingType$QNameRuntimeProperty.fillCollection(AttributeRuntimeBindingType.java:385) at com.bea.staxb.runtime.internal.MultiIntermediary.getFinalValue(MultiIntermediary.java:52) at com.bea.staxb.runtime.internal.AttributeRuntimeBindingType.getFinalObjectFromIntermediary(AttributeRuntimeBindingType.java:145) at com.bea.staxb.runtime.internal.UnmarshalResult.unmarshalBindingType(UnmarshalResult.java:185) at com.bea.staxb.runtime.internal.UnmarshalResult.unmarshalDocument(UnmarshalResult.java:154) at com.bea.staxb.runtime.internal.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:65) at weblogic.descriptor.internal.MarshallerFactory$1.createDescriptor(MarshallerFactory.java:136) ... 19 more Caused by: weblogic.descriptor.BeanAlreadyExistsException: Bean already exists: [EMAIL PROTECTED](/[EMAIL PROTECTED]) at weblogic.descriptor.internal.ReferenceManager.registerBean(ReferenceManager.java:207) at weblogic.j2ee.descriptor.ApplicationBeanImpl.setModules(ApplicationBeanImpl.java:419) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.bea.staxb.runtime.internal.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:48) ... 27 more . Jan 31, 2008 2:22:40 PM EST Error J2EE BEA-160197 Unable to load descriptor
Different bevaviour in 2.0.4
Hi I've been using 2.0.3 with good success and I decided to upgrade to 2.0.4 this morning. I'm having problem running my tests which are failing now with: Testcase: test5SoapRemoting (com.surgex.addresslookup.service.AddressLookupServiceIntegrationTest): Caused an ERROR [junit] null while invoking public com.surgex.addresslookup.model.UKAddress[] com.surgex.addresslookup.service.impl.AddressLookupServiceImpl.lookupUK( com.surgex.commons.remoting.model.Credential,java.lang.String,java.util. Map,boolean) throws com.surgex.commons.remoting.exceptions.RemotingException,com.surgex.comm ons.remoting.exceptions.InvalidArgumentException,com.surgex.commons.remo ting.exceptions.UnauthorisedAccessException with params [null, null, null, null]. [junit] javax.xml.ws.soap.SOAPFaultException: null while invoking public com.surgex.addresslookup.model.UKAddress[] com.surgex.addresslookup.service.impl.AddressLookupServiceImpl.lookupUK( com.surgex.commons.remoting.model.Credential,java.lang.String,java.util. Map,boolean) throws com.surgex.commons.remoting.exceptions.RemotingException,com.surgex.comm ons.remoting.exceptions.InvalidArgumentException,com.surgex.commons.remo ting.exceptions.UnauthorisedAccessException with params [null, null, null, null]. [junit] at org.apache.cxf.jaxws.JaxWsClientProxy.invoke (JaxWsClientProxy.java:175) [junit] at $Proxy21.lookupUK(Unknown Source) [junit] at com.surgex.addresslookup.service.AddressLookupServiceIntegrationTest.exe cuteTests(AddressLookupServiceIntegrationTest.java:217) [junit] at com.surgex.addresslookup.service.AddressLookupServiceIntegrationTest.tes t5SoapRemoting(AddressLookupServiceIntegrationTest.java:158) [junit] at org.springframework.test.ConditionalTestCase.runBare (ConditionalTestCase.java:76) [junit] Caused by: org.apache.cxf.binding.soap.SoapFault: null while invoking public com.surgex.addresslookup.model.UKAddress[] com.surgex.addresslookup.service.impl.AddressLookupServiceImpl.lookupUK( com.surgex.commons.remoting.model.Credential,java.lang.String,java.util. Map,boolean) throws com.surgex.commons.remoting.exceptions.RemotingException,com.surgex.comm ons.remoting.exceptions.InvalidArgumentException,com.surgex.commons.remo ting.exceptions.UnauthorisedAccessException with params [null, null, null, null]. [junit] at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleM essage(Soap11FaultInInterceptor.java:70) [junit] at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleM essage(Soap11FaultInInterceptor.java:35) [junit] at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept (PhaseInterceptorChain.java:208) [junit] at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage (AbstractFaultChainInitiatorObserver.java:96) [junit] at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMes sage(ReadHeadersInterceptor.java:183) [junit] at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMes sage(ReadHeadersInterceptor.java:56) [junit] at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept (PhaseInterceptorChain.java:208) [junit] at org.apache.cxf.endpoint.ClientImpl.onMessage (ClientImpl.java:429) [junit] at org.apache.cxf.transport.http.HTTPConduit $WrappedOutputStream.handleResponse(HTTPConduit.java:1955) [junit] at org.apache.cxf.transport.http.HTTPConduit $WrappedOutputStream.close(HTTPConduit.java:1791) [junit] at org.apache.cxf.transport.AbstractConduit.close (AbstractConduit.java:66) [junit] at org.apache.cxf.transport.http.HTTPConduit.close (HTTPConduit.java:575) [junit] at org.apache.cxf.interceptor.MessageSenderInterceptor $MessageSenderEndingInterceptor.handleMessage (MessageSenderInterceptor.java:62) [junit] at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept (PhaseInterceptorChain.java:208) [junit] at org.apache.cxf.endpoint.ClientImpl.invoke (ClientImpl.java:276) [junit] at org.apache.cxf.endpoint.ClientImpl.invoke (ClientImpl.java:222) [junit] at org.apache.cxf.frontend.ClientProxy.invokeSync (ClientProxy.java:73) [junit] at org.apache.cxf.jaxws.JaxWsClientProxy.invoke (JaxWsClientProxy.java:135) [junit] Test com.surgex.addresslookup.service.AddressLookupServiceIntegrationTest FAILED If I downgrade the CXF jar file back to 2.0.3 the tests run again. Any idea what I'm missing or what's triggering this behaviour? Thx a lot for any help. -- This email is intended for the recipients only and should not be copied, forwarded or otherwise distributed to third parties without the consent of the original author. Frederic Soulier [EMAIL PROTECTED] Senior Vice-President Casino Cecure Gaming Ltd. 23 Clayton Rd. Hayes. Middlesex. UB3 1AN. United Kingdom (Mob) +44(0)7967966490 (Tel) +44(0)2088171444 (Fax) +44(0)2088171240 OpenPGP key
Re: CXF on WebLogic 9.2
I downloaded apache-cxf-2.0.4-incubator.tar.gz and could not find any file
name stax-api.jar in the lib directory.
YI (William) ZHU wrote:
stax-api jar file is in \{CXF-home}\lib
unpackage it, you will find the javax.xml.namespace.QName class.
delete it, and re-package the file.
try it.
--
View this message in context:
http://www.nabble.com/CXF-on-WebLogic-9.2-tp15193763p15213356.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF on WebLogic 9.2
stax-api jar file is in \{CXF-home}\lib
unpackage it, you will find the javax.xml.namespace.QName class.
delete it, and re-package the file.
try it.
chengas123 wrote:
Hi,
I was getting a java.lang.NoSuchMethodError:
javax.jws.WebService.portName()Ljava/lang/String; error on WebLogic 9.2,
but seemed to have solved it by following a post
(http://forums.bea.com/thread.jspa?threadID=69031) I found and adding
-Djavax.xml.stream.XMLInputFactory=com.ctc.wstx.stax.WstxInputFactory to
my WebLogic startup.
However, I'm now getting:
java.lang.RuntimeException: [was class java.net.ConnectException] Tried
all: '1' addresses, but could not connect over HTTP to server:
'java.sun.com', port: '80'
My only guess is it's trying to validate a DTD or something and is being
blocked by our corporate firewall. I have no idea how to tell weblogic
about our proxy. Configuring the proxy would be a good short-term
solution since it would allow development to move forward. However,
ultimately I'm probably going to need another solution since I'm not sure
this would fly in our production environment.
Thanks,
Ben
--
View this message in context:
http://www.nabble.com/CXF-on-WebLogic-9.2-tp15193763p15213281.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF on WebLogic 9.2
Haha. I would have realized that was the same .jar
The only one included in 2.0.4 is stax-utils-20060502.jar
YI (William) ZHU wrote:
actually, it's stax-api-1.0.1.jar.
(on CXF 2.0.2 and CXF 2.0.3)
chengas123 [EMAIL PROTECTED] wrote:
I downloaded apache-cxf-2.0.4-incubator.tar.gz and could not find any file
name stax-api.jar in the lib directory.
YI (William) ZHU wrote:
stax-api jar file is in \{CXF-home}\lib
unpackage it, you will find the javax.xml.namespace.QName class.
delete it, and re-package the file.
try it.
--
View this message in context:
http://www.nabble.com/CXF-on-WebLogic-9.2-tp15193763p15213728.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF on WebLogic 9.2
chengas123 wrote: I downloaded apache-cxf-2.0.4-incubator.tar.gz and could not find any file name stax-api.jar in the lib directory. 2.0.4 ships geronimo-stax-api_1.0_spec-1.0.jar instead, but this doesn't include the QName class so probably doesn't help you. Ian -- Ian Roberts | Department of Computer Science [EMAIL PROTECTED] | University of Sheffield, UK
Re: CXF on WebLogic 9.2
on CXF2.0.4, it's geronimo-stax-api_1.0_spec-1.0.jar.
chengas123 [EMAIL PROTECTED] wrote:
Haha. I would have realized that was the same .jar
The only one included in 2.0.4 is stax-utils-20060502.jar
YI (William) ZHU wrote:
actually, it's stax-api-1.0.1.jar.
(on CXF 2.0.2 and CXF 2.0.3)
chengas123 wrote:
I downloaded apache-cxf-2.0.4-incubator.tar.gz and could not find any file
name stax-api.jar in the lib directory.
YI (William) ZHU wrote:
stax-api jar file is in \{CXF-home}\lib
unpackage it, you will find the javax.xml.namespace.QName class.
delete it, and re-package the file.
try it.
--
View this message in context:
http://www.nabble.com/CXF-on-WebLogic-9.2-tp15193763p15213728.html
Sent from the cxf-user mailing list archive at Nabble.com.
-
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
Re: CXF on WebLogic 9.2
Thank you for your help. I finally got WebLogic to start. I'm not sure what exactly I did to fix it, but part of it was definitely clearing the weblogic cache. Thanks again, Ben ianroberts wrote: chengas123 wrote: I downloaded apache-cxf-2.0.4-incubator.tar.gz and could not find any file name stax-api.jar in the lib directory. 2.0.4 ships geronimo-stax-api_1.0_spec-1.0.jar instead, but this doesn't include the QName class so probably doesn't help you. Ian -- Ian Roberts | Department of Computer Science [EMAIL PROTECTED] | University of Sheffield, UK -- View this message in context: http://www.nabble.com/CXF-on-WebLogic-9.2-tp15193763p15214832.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF on WebLogic 9.2
FYI: for 2.0.4, we specifically switched to the geronimo version as it
does NOT have the QName class in it like the stax-api version that we
used in 2.0.3 does. Thus, the problem should be reduced.
Dan
On Thursday 31 January 2008, William Zhu wrote:
on CXF2.0.4, it's geronimo-stax-api_1.0_spec-1.0.jar.
chengas123 [EMAIL PROTECTED] wrote:
Haha. I would have realized that was the same .jar
The only one included in 2.0.4 is stax-utils-20060502.jar
YI (William) ZHU wrote:
actually, it's stax-api-1.0.1.jar.
(on CXF 2.0.2 and CXF 2.0.3)
chengas123 wrote:
I downloaded apache-cxf-2.0.4-incubator.tar.gz and could not find
any file name stax-api.jar in the lib directory.
YI (William) ZHU wrote:
stax-api jar file is in \{CXF-home}\lib
unpackage it, you will find the javax.xml.namespace.QName class.
delete it, and re-package the file.
try it.
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: Skipping xjc in wsdl2java
I think the only option is the -nexclude namespace option to have it not generate code for stuff in a specific namespace. Dan On Thursday 31 January 2008, Cybexion wrote: Hi, I would like to reuse my xsd generated classes in different projects. Therefore I would like to have a stand alone project which just contains the xsd and generates the classes. These classes should be put in my maven repository. After that I would like to tell wsdl2java not to generate the jaxb stuff, but just the wsdl interface classes and reuse the jaxb classes from the repository. Is this possible? Thanks and regards Cybexion -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Supressing generation of xs:extension against inheritance
Honestly, looking at the jaxb spec, I don't see anything that would allow that.Thats something you may want to ask on the jaxb lists: https://jaxb.dev.java.net/servlets/ProjectMailingListList There might be some hidden flag or something that could be used to set it. I don't really know. Dan On Wednesday 30 January 2008, Phil Weighill-Smith wrote: I have an SEI API that includes some data objects. Some of the data objects share some common attributes which I have implemented via extraction of a base class and inheritance from that where needed. When I use java2wsdl this inheritance gets turned into an xs:extension. What I'd like to do is actually have the common attributes duplicated into each XML schema representation of the data objects (flattening out the inheritance) since this base class is really only for Java convenience and doesn't have a meaningful representation in the schema. Does anyone know how to do this with JAX-WS or JAXB annotations (or even if it is possible at all)? Phil :n. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
How to make java package names the target name spaces ?
Hi, I am developing using the Java first approach (using jaxb data binding), and the wsdl is auto generated by the cxf servlet at http://localhost/SomeService?wsdl Short of annotating each class with @XmlType(namespace=http://x.y.z;), is there a setting which inform the servlet to use the source java classes' package names as the targetNamespaces when generating the wsdl? Thank you. -c p.s. Using java package names as targetNamespaces seems to be the default behavior when using aegis data binding. p.p.s. I have tried the @XmlSchema in package-info.java approach, but it was not picked-up by the servlet (probably only works using java2wsdl).
Re: Supressing generation of xs:extension against inheritance
On Thu, 2008-01-31 at 17:01 -0500, Daniel Kulp wrote: Honestly, looking at the jaxb spec, I don't see anything that would allow that.Thats something you may want to ask on the jaxb lists: https://jaxb.dev.java.net/servlets/ProjectMailingListList There might be some hidden flag or something that could be used to set it. I don't really know. (sort of) As per the blog posting I wrote at dssheep.blogspot.com, you could consider the following methodology: 1) Use your current classes as sacrificial. 2) Edit the XSD until you like it. 3) Regenerate new classes. The new classes will be redundant, but will that really hurt? You could also whip up a set of facade wrappers that delegate your interfaces to them.
Re: Leaving CXF for Glasshfish Metro
Well, I have to agree. The docs seem to be the last thing that a developer thinks about - because it's so obvious right? CXF, like a lot of software, badly needs some end to end examples at the very least. Currently, it's very lacking, as was XFire! Mayank Thakore-2 wrote: well, i have spent a lot of time getting cxf to work. but migrating from xfire, our code reduced from about 1200 lines to 200 lines. and i find cxf to be very extensible but it's not just coincidence that someone was talking about a book on cxf just today... Regards Mayank On Jan 23, 2008 8:36 PM, jonathan doklovic [EMAIL PROTECTED] wrote: The point being that since this is a users list (not a dev list) I thought I'd share my user experience in hopes that it could help the future of the project. 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. I was never able to get CXF working properly simply because of the lack of simple docs and end-to-end examples. Maybe it's just that I don't get it or something, but I feel there are probably a lot of me's out there that struggle with getting things up and running. - Jonathan On Wed, 2008-01-23 at 14:47 +, Sergey Beryozkin wrote: 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 -- View this message in context: http://www.nabble.com/Leaving-CXF-for-Glasshfish-Metro-tp15043303p15219122.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: Leaving CXF for Glasshfish Metro
OK. Let's flip this around a bit... Describe the type of example that would (or would have) helped you do what you wanted to do. We can work to get one in place. CXF has a bunch of samples already that cover a large variety of different configuations and samples. Knowing where they are deficient can help us get them improved. Dan On Thursday 31 January 2008, Phil Gibbs wrote: Well, I have to agree. The docs seem to be the last thing that a developer thinks about - because it's so obvious right? CXF, like a lot of software, badly needs some end to end examples at the very least. Currently, it's very lacking, as was XFire! Mayank Thakore-2 wrote: well, i have spent a lot of time getting cxf to work. but migrating from xfire, our code reduced from about 1200 lines to 200 lines. and i find cxf to be very extensible but it's not just coincidence that someone was talking about a book on cxf just today... Regards Mayank On Jan 23, 2008 8:36 PM, jonathan doklovic [EMAIL PROTECTED] wrote: The point being that since this is a users list (not a dev list) I thought I'd share my user experience in hopes that it could help the future of the project. 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. I was never able to get CXF working properly simply because of the lack of simple docs and end-to-end examples. Maybe it's just that I don't get it or something, but I feel there are probably a lot of me's out there that struggle with getting things up and running. - Jonathan On Wed, 2008-01-23 at 14:47 +, Sergey Beryozkin wrote: 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 -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Different bevaviour in 2.0.4
Hmm... That's really not good. Is there any chance you can get a wire trace of the test with both 2.0.3 and 2.0.4? Is it CXF on both sides of the wire? There were some updates to the fault handling/mapping to make it honor the elementFormDefault flags of the schemas. Thus, the fault messages don't match the schema, there could be problems. Dan On Thursday 31 January 2008, Frederic Soulier wrote: Hi I've been using 2.0.3 with good success and I decided to upgrade to 2.0.4 this morning. I'm having problem running my tests which are failing now with: Testcase: test5SoapRemoting (com.surgex.addresslookup.service.AddressLookupServiceIntegrationTest) : Caused an ERROR [junit] null while invoking public com.surgex.addresslookup.model.UKAddress[] com.surgex.addresslookup.service.impl.AddressLookupServiceImpl.lookupU K( com.surgex.commons.remoting.model.Credential,java.lang.String,java.uti l. Map,boolean) throws com.surgex.commons.remoting.exceptions.RemotingException,com.surgex.co mm ons.remoting.exceptions.InvalidArgumentException,com.surgex.commons.re mo ting.exceptions.UnauthorisedAccessException with params [null, null, null, null]. [junit] javax.xml.ws.soap.SOAPFaultException: null while invoking public com.surgex.addresslookup.model.UKAddress[] com.surgex.addresslookup.service.impl.AddressLookupServiceImpl.lookupU K( com.surgex.commons.remoting.model.Credential,java.lang.String,java.uti l. Map,boolean) throws com.surgex.commons.remoting.exceptions.RemotingException,com.surgex.co mm ons.remoting.exceptions.InvalidArgumentException,com.surgex.commons.re mo ting.exceptions.UnauthorisedAccessException with params [null, null, null, null]. [junit] at org.apache.cxf.jaxws.JaxWsClientProxy.invoke (JaxWsClientProxy.java:175) [junit] at $Proxy21.lookupUK(Unknown Source) [junit] at com.surgex.addresslookup.service.AddressLookupServiceIntegrationTest.e xe cuteTests(AddressLookupServiceIntegrationTest.java:217) [junit] at com.surgex.addresslookup.service.AddressLookupServiceIntegrationTest.t es t5SoapRemoting(AddressLookupServiceIntegrationTest.java:158) [junit] at org.springframework.test.ConditionalTestCase.runBare (ConditionalTestCase.java:76) [junit] Caused by: org.apache.cxf.binding.soap.SoapFault: null while invoking public com.surgex.addresslookup.model.UKAddress[] com.surgex.addresslookup.service.impl.AddressLookupServiceImpl.lookupU K( com.surgex.commons.remoting.model.Credential,java.lang.String,java.uti l. Map,boolean) throws com.surgex.commons.remoting.exceptions.RemotingException,com.surgex.co mm ons.remoting.exceptions.InvalidArgumentException,com.surgex.commons.re mo ting.exceptions.UnauthorisedAccessException with params [null, null, null, null]. [junit] at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handl eM essage(Soap11FaultInInterceptor.java:70) [junit] at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handl eM essage(Soap11FaultInInterceptor.java:35) [junit] at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept (PhaseInterceptorChain.java:208) [junit] at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessa ge (AbstractFaultChainInitiatorObserver.java:96) [junit] at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleM es sage(ReadHeadersInterceptor.java:183) [junit] at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleM es sage(ReadHeadersInterceptor.java:56) [junit] at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept (PhaseInterceptorChain.java:208) [junit] at org.apache.cxf.endpoint.ClientImpl.onMessage (ClientImpl.java:429) [junit] at org.apache.cxf.transport.http.HTTPConduit $WrappedOutputStream.handleResponse(HTTPConduit.java:1955) [junit] at org.apache.cxf.transport.http.HTTPConduit $WrappedOutputStream.close(HTTPConduit.java:1791) [junit] at org.apache.cxf.transport.AbstractConduit.close (AbstractConduit.java:66) [junit] at org.apache.cxf.transport.http.HTTPConduit.close (HTTPConduit.java:575) [junit] at org.apache.cxf.interceptor.MessageSenderInterceptor $MessageSenderEndingInterceptor.handleMessage (MessageSenderInterceptor.java:62) [junit] at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept (PhaseInterceptorChain.java:208) [junit] at org.apache.cxf.endpoint.ClientImpl.invoke (ClientImpl.java:276) [junit] at org.apache.cxf.endpoint.ClientImpl.invoke (ClientImpl.java:222) [junit] at org.apache.cxf.frontend.ClientProxy.invokeSync (ClientProxy.java:73) [junit] at org.apache.cxf.jaxws.JaxWsClientProxy.invoke (JaxWsClientProxy.java:135) [junit] Test com.surgex.addresslookup.service.AddressLookupServiceIntegrationTest FAILED If I downgrade the CXF jar file back to 2.0.3 the tests run again. Any idea what I'm missing or what's
Re: data binding question
Thanks for that Daniel. Do you know if there's a consistent sequence that cxf forces the binders and invokers to follow i.e. Reader - Invoker - Writer or if there are scenarios that should cause the sequnce to change? Cheers, Rob On Feb 1, 2008 1:27 PM, Daniel Kulp [EMAIL PROTECTED] wrote: Rob, Writing a new databinding is slightly tricky to get completely working correctly. I don't think we have any good docs for it yet. The new xmlbeans databinding (on trunk only) is probably the easiest to follow as an example as it doesn't do anything that complex yet. The steps to creating a databinding would be: 1) Write Reader/Writer implementations that read/write to XmlStreamReader/Writers. In some cases, the runtime also wants readers/writers for nodes, but you can always create a XmlStreamReader/Writer from the node and feed it into the same impl. JAXB does does some optimizations if it's a node, but for simplicity, the xmlbeans databinding currently doesn't. 2) Write the DataBinding object that creates the readers/writers. The tricky part of this is the initizialize(...) method. It needs to create the schemas and get them plugged into the service model for all the parts so that the generated wsdl will look correct.For XMLBeans, it was pretty simple as the schemas are in the generated jar. For each MessagePartInfo just need to find the appropriate XmlSchema element or type and set the appropriate fields. 3) Fault handling - this is somewhat optional (xmlbeans doesn't do it yet), but if your databinding has special rules for handling/mapping exceptions, both of the above would need updating for that as well. A chunk of jaxb's complexity is around that. Anyway, I'd definitely recommend looking at the XmlBeans databinding. The JAXB databinding does a BUNCH of things that makes it very complex. Dan On Wednesday 30 January 2008, Rob Barrett wrote: I'm about to start some data binding code to map soap messages to java components and I'm looking at the DataBinding interfaces in cxf. Could anyone point me at a good point of introduction to this interface/class set. I'd like to find out about the lifecycle of these things, how/when they are called, etc. Thanks, Rob -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
