[jira] Commented: (CXF-3001) NullPointerException when embledded into spring+jetty
[
https://issues.apache.org/jira/browse/CXF-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912468#action_12912468
]
Willem Jiang commented on CXF-3001:
---
you need to let the CXFServlet to create the application context for you
otherwise you will get the NPE.
> NullPointerException when embledded into spring+jetty
> -
>
> Key: CXF-3001
> URL: https://issues.apache.org/jira/browse/CXF-3001
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.2.10
>Reporter: Krystian Siuda
>
> I'm running embedded jetty inside of a spring ioc container. The spring ioc
> contains also an embedded hsqldb which makes the whole configuration a nice
> and complete web application development environment (on a single JVM). Now
> I'm trying to add apache CXF to this environment to make the jetty host not
> only servlets but also web services. Unfortunately I'm getting
> NullPointerException when attempting to access http://127.0.0.1:8080/cxf/*
> (servlets and static content are served ok). Even if the configuration is
> wrong NPE should not be thrown.
> stacktrace:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:142)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:108)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:281)
> 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)
> {noformat}
> I'm initializing spring with:
> {code:java}
> public static void main(String[] args) throws Exception {
> ApplicationContext applicationContext = new
> ClassPathXmlApplicationContext(new String[] { "jetty-beans.xml" ,
> "cxf-beans.xml" });
> applicationContext.getBean("web-server", Server.class).join();
> }
> {code}
> jetty-beans.xml
> {code:xml}
>
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation=" http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd";>
> init-method="start">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> class="org.mortbay.jetty.servlet.Context">
>
>
>
>
>
>
>
> class="org.mortbay.jetty.servlet.Context">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> class="org.mortbay.jetty.servlet.ServletMapping">
> value="servlet-holder" />
>
>
>
>
>
>
>
> class="org.mortbay.jetty.servlet.Context">
>
>
>
>
>
>
> />
>
> class="org.apache.cxf.transport.servlet.CXFServlet">
>
>
>
>
[jira] Commented: (CXF-2986) sets null instead of empty List/Set/SortedSet when value isn't in query string
[
https://issues.apache.org/jira/browse/CXF-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912484#action_12912484
]
Brad Cupit commented on CXF-2986:
-
excellent! Thanks Sergey!
> sets null instead of empty List/Set/SortedSet when value isn't in query string
> --
>
> Key: CXF-2986
> URL: https://issues.apache.org/jira/browse/CXF-2986
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.2.10
>Reporter: Brad Cupit
>Priority: Minor
>
> CXF sets a null collection, rather than an empty one, when the query param
> isn't in the request
> Example:
> @GET
> @Path("/stuff")
> public Response get(@QueryParam("option") Set options) { ... }
> and http://localhost:8080/stuff is called (but ?option=abc is not on the
> query string), then options will be null, but it should be an empty Set
> The javadocs in @DefaultValue says:
> If this annotation is not used and the corresponding metadata is not present
> in the request, the value will be an empty collection for List, Set or
> SortedSet
> this seems similar to CXF-1675
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-3004) Inconsistent HTTP response code 202 returned for WS-RM piggybacked Ack response message
Inconsistent HTTP response code 202 returned for WS-RM piggybacked Ack response
message
---
Key: CXF-3004
URL: https://issues.apache.org/jira/browse/CXF-3004
Project: CXF
Issue Type: Bug
Components: WS-* Components
Affects Versions: 2.2.10, 2.2.9
Reporter: Aki Yoshida
Fix For: 2.3, 2.2.11
I originally posted this issue on cxf-dev mailing list in last june.
http://mail-archives.apache.org/mod_mbox/cxf-dev/201006.mbox/%3caanlktikvg6uldcj9gkrnfgcks90s5zvcydrz79skx...@mail.gmail.com%3e
I didn't see any response and unfortunately, I also forgot to follow up on this
problem. The problem is present in the recently released 2.2.10. I observed
this problem in 2.2.9, 2.2.10, 2.2.11-SNAPSHOT, and 2.3.0-SNAPSHOT.
The problem description and possible solutions to fix this issue are given
below.
Problem
When oneway call is received at the server and gets rebased, its response
message is marked as a partial response. The response code of this partial
response message is automatically set to 202.
This behavior of the CXF implementation causes interoperability problems for a
WS-RM scenario with a non-addressable client (i.e., the
client that needs to receive WS-RM acknowledgement messages in the piggybacked
HTTP 200 response). As the response code 202 indicates no
presence of a valid SOAP envelope, WS-RM acknowledgement messages are not
correctly processed at those client implementations that follow this rule.
I think there are several approaches in fixing this issue. One option is to
revert the status code to 200 in RMSoapInterceptor when the response message
must be filled with the relevant WS-RM properties. I tested this option with
2.2.9, 2.2.10, and 2.2.11-SNAPSHOT, and it works fine.
Concretely, I modified RMSoapInterceptor to revert the http response code to
200 when the rm header is filled with the relevant rm properties.
In particular, I added the following lines in the encode method of
org.apache.cxf.ws.rm.soap.RMSoapInterceptor
}
Node node = hdr.getFirstChild();
+ if (node != null && MessageUtils.isPartialResponse(message)) {
+ // make sure the ack response is returned as HTTP 200 and not
202
+ // message.put(Message.PARTIAL_RESPONSE_MESSAGE, null);
+ message.put(Message.RESPONSE_CODE, HttpURLConnection.HTTP_OK);
+ }
while (node != null) {
Header holder = new Header(new QName(node.getNamespaceURI(),
node.getLocalName()), node);
header.add(holder);
For 2.3.0-SNAPSHOT, however, this change alone does not solve the problem
because org.apache.cxf.transport.http.AbstractHTTPDestination always
overwrites the http response code for the partial response message in its
updateResponeHeaders method.
So, in order to avoid this overwriting, I needed to comment out this part
shown below in the updateResponseHeader shown below.
protected void updateResponseHeaders(Message message) {
! // setting the response to 202 here breaks the ws-rm piggybacked ack
response
! //if (MessageUtils.isPartialResponse(message)) {
! //message.put(Message.RESPONSE_CODE,
HttpURLConnection.HTTP_ACCEPTED);
! //}
Map> responseHeaders =
CastUtils.cast((Map)message.get(Message.PROTOCOL_HEADERS));
if (responseHeaders == null) {
Alternatively, we could remove the partial response flag of this response
message at RMSoapInterceptor so that the updateResponseHeaders method would not
overwrite the response status. However, this interferes with another part of
the AbstractHTTPDestination class and this approach will require additional
changes in this class. However, it was not clear to me what exactly the
semantic definition of the partial response message should be in the context of
the WS-RM protocol. So I did not pursue this approach.
Best Regards,
Aki
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-3004) Inconsistent HTTP response code 202 returned for WS-RM piggybacked Ack response message
[
https://issues.apache.org/jira/browse/CXF-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida updated CXF-3004:
-
Attachment: cxf-3004-fixes.zip
as my code fragment text in the above description was garbled,
attaching the diffs and the modified java files for 2.2.x and 2.3.x for better
references.
> Inconsistent HTTP response code 202 returned for WS-RM piggybacked Ack
> response message
> ---
>
> Key: CXF-3004
> URL: https://issues.apache.org/jira/browse/CXF-3004
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.2.9, 2.2.10
>Reporter: Aki Yoshida
> Fix For: 2.3, 2.2.11
>
> Attachments: cxf-3004-fixes.zip
>
>
> I originally posted this issue on cxf-dev mailing list in last june.
> http://mail-archives.apache.org/mod_mbox/cxf-dev/201006.mbox/%3caanlktikvg6uldcj9gkrnfgcks90s5zvcydrz79skx...@mail.gmail.com%3e
> I didn't see any response and unfortunately, I also forgot to follow up on
> this problem. The problem is present in the recently released 2.2.10. I
> observed this problem in 2.2.9, 2.2.10, 2.2.11-SNAPSHOT, and 2.3.0-SNAPSHOT.
> The problem description and possible solutions to fix this issue are given
> below.
> Problem
> When oneway call is received at the server and gets rebased, its response
> message is marked as a partial response. The response code of this partial
> response message is automatically set to 202.
> This behavior of the CXF implementation causes interoperability problems for
> a WS-RM scenario with a non-addressable client (i.e., the
> client that needs to receive WS-RM acknowledgement messages in the
> piggybacked HTTP 200 response). As the response code 202 indicates no
> presence of a valid SOAP envelope, WS-RM acknowledgement messages are not
> correctly processed at those client implementations that follow this rule.
> I think there are several approaches in fixing this issue. One option is to
> revert the status code to 200 in RMSoapInterceptor when the response message
> must be filled with the relevant WS-RM properties. I tested this option with
> 2.2.9, 2.2.10, and 2.2.11-SNAPSHOT, and it works fine.
> Concretely, I modified RMSoapInterceptor to revert the http response code to
> 200 when the rm header is filled with the relevant rm properties.
> In particular, I added the following lines in the encode method of
> org.apache.cxf.ws.rm.soap.RMSoapInterceptor
> }
> Node node = hdr.getFirstChild();
> + if (node != null && MessageUtils.isPartialResponse(message)) {
> + // make sure the ack response is returned as HTTP 200 and
> not 202
> + // message.put(Message.PARTIAL_RESPONSE_MESSAGE, null);
> + message.put(Message.RESPONSE_CODE,
> HttpURLConnection.HTTP_OK);
> + }
> while (node != null) {
> Header holder = new Header(new
> QName(node.getNamespaceURI(), node.getLocalName()), node);
> header.add(holder);
> For 2.3.0-SNAPSHOT, however, this change alone does not solve the problem
> because org.apache.cxf.transport.http.AbstractHTTPDestination always
> overwrites the http response code for the partial response message in its
> updateResponeHeaders method.
> So, in order to avoid this overwriting, I needed to comment out this part
> shown below in the updateResponseHeader shown below.
> protected void updateResponseHeaders(Message message) {
> ! // setting the response to 202 here breaks the ws-rm piggybacked
> ack response
> ! //if (MessageUtils.isPartialResponse(message)) {
> ! //message.put(Message.RESPONSE_CODE,
> HttpURLConnection.HTTP_ACCEPTED);
> ! //}
> Map> responseHeaders =
> CastUtils.cast((Map)message.get(Message.PROTOCOL_HEADERS));
> if (responseHeaders == null) {
> Alternatively, we could remove the partial response flag of this response
> message at RMSoapInterceptor so that the updateResponseHeaders method would
> not overwrite the response status. However, this interferes with another part
> of the AbstractHTTPDestination class and this approach will require
> additional changes in this class. However, it was not clear to me what
> exactly the semantic definition of the partial response message should be in
> the context of the WS-RM protocol. So I did not pursue this approach.
> Best Regards,
> Aki
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
issues in cxf client after converting wsdl to java
Hello,
i am in an urgent need of help. its been a week but i am not able to figure
out the problem;
I used the wsdl poseted below to convert to java anc crate a jar file using
CXF; I have been able to successfully generate the .jar file with
dependencies; I am using jonas server. When i run the client i get the
following result.
2010-09-20 15:04:37,167 : LoggingOutInterceptor$LoggingCallback.onClose :
Outbound Message
---
Encoding: UTF-8
Headers: {SOAPAction=[""], Accept=[*]}
Messages:
Payload: http://schemas.xmlsoap.org/soap/envelope/";>
http://ws.cxf.francetelecom.com";>10072601/10072
6010001fr_FR1WSS-ATOL2032309
--
2010-09-20 15:04:37,558 : LoggingInInterceptor.logging : Inbound Message
Encoding: UTF-8
Headers: {connection=[close], Date=[Mon, 20 Sep 2010 13:04:30 GMT],
transfer-encoding=[chu
nked], Server=[Apache], content-type=[text/xml;charset=utf-8]}
Messages:
Message:
Payload: http://sch
emas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="h
ttp://www.w3.org/2001/XMLSchema-instance">http://xml.apache.org/axis/";>ns1:ClientNo such
operation 'getB
illingPeriodRangeRequest'http://xml.apache.
org/axis/">dvedv332
The error is in this line --> No such operation
'getBillingPeriodRangeRequest'
Its really strange coz it is looking for an operation which doesnt exist and
which it shldnt be looking for this. Is ther anything wrong with my wsdl.
The client code is:
JaxWsProxyFactoryBean factory = new
org.apache.cxf.jaxws.JaxWsProxyFactoryBean();
factory.setServiceClass(GetBillingPeriodRange.class);
factory.setAddress(attributes.getWsURL().toString());
factory.getInInterceptors().add(new
org.apache.cxf.interceptor.LoggingInInterceptor());
factory.getOutInterceptors().add(new
org.apache.cxf.interceptor.LoggingOutInterceptor());
GetBillingPeriodRange billingService =
(GetBillingPeriodRange)
factory.create();
result=billingService.manageGetBillingPeriodRange(request);
My wsdl is:
http://ws.cxf.francetelecom.com";
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
xmlns:xmime="http://www.w3.org/2005/05/xmlmime";
xmlns:impl="http://ws.cxf.francetelecom.com";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";>
http://ws.cxf.francetelecom.com";
xmlns="http://www.w3.org/2001/XMLSchema";>
[jira] Created: (DOSGI-79) RemoteServiceAdmin.getImportedEndpoints() returns collection of incorrect type
RemoteServiceAdmin.getImportedEndpoints() returns collection of incorrect type -- Key: DOSGI-79 URL: https://issues.apache.org/jira/browse/DOSGI-79 Project: CXF Distributed OSGi Issue Type: Bug Components: DSW Affects Versions: 1.2 Environment: All Reporter: Neil Bartlett The RemoteServiceAdmin implementation returns objects of the incorrect type for method getImportedEndpoints(). According to the RSA interface and the specification document, the return type should be Collection. But the collection actually contains objects of type ImportRegistrationImpl. This results in ClassCastExceptions when attempting to use the method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2284) org.apache.cxf.BusException: No binding factory for namespace http://schemas.xmlsoap.org/wsdl/soap/ registered."
[ https://issues.apache.org/jira/browse/CXF-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912813#action_12912813 ] Vijay Katam commented on CXF-2284: -- I faced a similar issue, as Richard Flitcroft pointed out it is an issue when using maven assembly plugin to build an uber executable war. There is a workaround using maven shady plugin which constructs an uber war which does not override the META-INF/cxf/*.* files . Using resource transformers in maven shady plugin these files can be combined. > org.apache.cxf.BusException: No binding factory for namespace > http://schemas.xmlsoap.org/wsdl/soap/ registered." > - > > Key: CXF-2284 > URL: https://issues.apache.org/jira/browse/CXF-2284 > Project: CXF > Issue Type: Bug > Components: Soap Binding >Affects Versions: 2.1.5 > Environment: Win XP >Reporter: ANAND RAI >Priority: Blocker > Attachments: screenshot-1.jpg > > > I am writing a Component using CXF to consume an AXIS webservice hosted on > Tomcat.The component works absolutely fine as a standalone application on > eclipse , but things get worst when i integrate it with rest of project which > has another component exposing CXF Webservice . I am using CXF 2.1.5 accross > my application (for consuming and producing) . > Following spring configuration was used to create stub . > class="org.springframework.remoting.jaxws.JaxWsPortProxyFactoryBean"> > > value="http://xyz:8084/someName/services/AccountManager?wsdl"; /> >http://x.y"; /> > > > > Spring logs show that spring is not able to create > AccountManagerSOAP11port_http.jaxws-client.proxy . > CXF logging was enable by following configuration > > > > > > to notice that CXF is able to send and recieve message ,but its returning > back a null object.Initially it appeared to me as if it is some issue with > SOAPHandler or jaxb .After some debugging i noticed that spring is getting an > exception while creating above service the exception was > "org.apache.cxf.BusException: No binding factory for namespace > http://schemas.xmlsoap.org/wsdl/soap/ registered ". > I wasn't able to get a stack trace, because spring was eating up the > exception and rather giving a friendly message which didn't make much sense > to me except that it failed to create > "AccountManagerSOAP11port_http.jaxws-client.proxy " . > Below is a snapshot of eclipse in debug persepective > this DefaultListableBeanFactory (id=257) > ex WebServiceException (id=485) >cause ServiceConstructionException (id=629) >cause BusException (id=633) >cause BusException (id=633) >detailMessage null >message Message (id=638) > bundle PropertyResourceBundle (id=641) >code "NO_BINDING_FACTORY_EXC" (id=644) >parameters Object[1] (id=645) >stackTrace null >detailMessage "org.apache.cxf.BusException: No binding > factory for namespace > http://schemas.xmlsoap.org/wsdl/soap/ registered." (id=636) > message null > stackTrace null >detailMessage > "org.apache.cxf.service.factory.ServiceConstructionException" (id=632) > stackTrace null > beanName"subscriberService" (id=488) > bean JaxWsPortProxyFactoryBean (id=440) > mbd RootBeanDefinition (id=490) > wrappedBean JaxWsPortProxyFactoryBean (id=440) > I googled this exception and found that many people have reported same > problem and for most of queries the cause is suggested to be missing > CXF-extension-soap.xml or cxf-rt-bindings-soap-2.1.3.jar missing in classpath > .But in my case i have both of them > I have following spring imports in spring configuration > > > > and cxf-rt-bindings-soap-2.1.3.jar is present in web-inf/lib of the war file . > I added some more imports ,but didn't prooved to be any help . > > > > > > > > I tried another approach to consume webservice . > xmlns="http://www.springframework.org/schema/beans"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xmlns:jaxws="http://cxf.apache.org/jaxws"; > xmlns:hlapi="http://x.y"; > xmlns:context="http://www.springframework.org/schema/context"; > xsi:schemaLocation="http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans-2.5.xsd > http://www.springframework.org/schema/context > http://www.springframework.org/schema/context/spring-cont
[jira] Resolved: (CXF-3003) Get the java first JMS example work
[ https://issues.apache.org/jira/browse/CXF-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CXF-3003. --- Resolution: Fixed > Get the java first JMS example work > --- > > Key: CXF-3003 > URL: https://issues.apache.org/jira/browse/CXF-3003 > Project: CXF > Issue Type: Task > Components: Samples >Reporter: Willem Jiang >Assignee: Willem Jiang > Fix For: 2.3 > > > Need to go through the example which Benson stared, to make it work. > Here is the discussing[1] about it. > [1]http://cxf.547215.n5.nabble.com/Java-first-and-the-new-JMS-config-universe-td2845889.html#a2845889 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
