Nabble - cxf-issues

[jira] Resolved: (CXF-2386) abdera-extensions-main and abdera-i18n are required by cxf-bundle-minimal but not present in any repository

2009-12-16T14:22:18Z

[ https://issues.apache.org/jira/browse/CXF-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-2386.
------------------------------

Resolution: Fixed
Fix Version/s: 2.2.6
2.1.9
Assignee: Daniel Kulp

Abdera is now in central. Thus, it should resolve without excludes or any repository entry now.

> abdera-extensions-main and abdera-i18n are required by cxf-bundle-minimal but not present in any repository
> -----------------------------------------------------------------------------------------------------------
>
> Key: CXF-2386
> URL: https://issues.apache.org/jira/browse/CXF-2386
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.3
> Environment: Maven 2.2.0
> Reporter: Dennis Kieselhorst
> Assignee: Daniel Kulp
> Fix For: 2.1.9, 2.2.6
>
>
> I have updated an application with cxf-bundle-minimal from 2.2 to 2.2.3. Build fails with:
> Missing:
> ----------
> 1) org.apache.abdera:abdera-i18n:jar:0.4.0-incubating
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=org.apache.abdera -DartifactId=abdera-i18n -Dversion=0.4.0-incubating -Dpackaging=jar -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file there:
> mvn deploy:deploy-file -DgroupId=org.apache.abdera -DartifactId=abdera-i18n -Dversion=0.4.0-incubating -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
> Path to dependency:
> 1) ...
> 2) org.apache.cxf:cxf-bundle-minimal:jar:2.2.3
> 3) org.apache.abdera:abdera-i18n:jar:0.4.0-incubating
> 2) org.apache.abdera:abdera-extensions-main:jar:0.4.0-incubating
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=org.apache.abdera -DartifactId=abdera-extensions-main -Dversion=0.4.0-incubating -Dpackaging=jar -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file there:
> mvn deploy:deploy-file -DgroupId=org.apache.abdera -DartifactId=abdera-extensions-main -Dversion=0.4.0-incubating -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
> Path to dependency:
> 1) ...
> 2) org.apache.cxf:cxf-bundle-minimal:jar:2.2.3
> 3) org.apache.abdera:abdera-extensions-main:jar:0.4.0-incubating
> Regarding to this malinglist thread http://www.nabble.com/Abdera-dependencies-td24264687.html scope should be provided.
> I have to exclude the abdera dependencies to get it build.
> <exclusions>
> <exclusion>
> <groupId>org.apache.abdera</groupId>
> <artifactId>abdera-extensions-main</artifactId>
> </exclusion>
> <exclusion>
> <groupId>org.apache.abdera</groupId>
> <artifactId>abdera-i18n</artifactId>
> </exclusion>
> </exclusions>

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (CXF-2579) Aegis reports duplicate tags for some complex types

2009-12-16T13:56:18Z

[ https://issues.apache.org/jira/browse/CXF-2579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-2579.
------------------------------

Resolution: Fixed
Fix Version/s: (was: 2.2.6)

Marking this resolved for 2.3. The flattened array stuff is only on trunk and not on 2.2.x. Thus, on 2.2.x, you would get the wrapper tag.

> Aegis reports duplicate tags for some complex types
> ---------------------------------------------------
>
> Key: CXF-2579
> URL: https://issues.apache.org/jira/browse/CXF-2579
> Project: CXF
> Issue Type: Bug
> Components: Aegis Databinding
> Reporter: Sergey Beryozkin
> Assignee: Daniel Kulp
> Fix For: 2.3
>
>
> See JAXRS AegisJSONProvider.testManyTags tests

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CXF-2579) Aegis reports duplicate tags for some complex types

2009-12-16T13:26:18Z

[ https://issues.apache.org/jira/browse/CXF-2579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791590#action_12791590 ]

Daniel Kulp commented on CXF-2579:
----------------------------------

This is actually working "as designed" due to the way Aegis doesn't flatten collections down like JAXB does. It creates a wrapper type which then results in a wrapper element.

However, Benson recently added support for flattened arrays through the aegis xml config. I'm updating that to also allow for flattened Collections as well as added a @XmlFlattenedArray annotation to aegis. Thus, with the new annotation added to the Tags class, I can get the json to look a bit better.

Testing the fixes now.

> Aegis reports duplicate tags for some complex types
> ---------------------------------------------------
>
> Key: CXF-2579
> URL: https://issues.apache.org/jira/browse/CXF-2579
> Project: CXF
> Issue Type: Bug
> Components: Aegis Databinding
> Reporter: Sergey Beryozkin
> Assignee: Daniel Kulp
> Fix For: 2.2.6, 2.3
>
>
> See JAXRS AegisJSONProvider.testManyTags tests

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CXF-2585) Already connected exception when using a proxy created with JAXRSClientFactory

2009-12-16T12:50:18Z

[ https://issues.apache.org/jira/browse/CXF-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791576#action_12791576 ]

Sergey Beryozkin commented on CXF-2585:
---------------------------------------

it is a bug affecting a proxy based flavor only.
The problem is that a proxy does not indicate to the transport-level HttpConduit that an empty POST (with no request body) is coming which is something that never occurs with SOAP proxies.

It will be fixed for soon to be released 2.2.6

Couple of workarounds.
1. Use WebClient :

Response r = WebClient.create(endpointAddress).query("param", "bob").post(null);
String s = (String)r.getEntity();

2. If you do prefer to use a proxy then for the empty POST be processed correctly, you can temporarily register a CXF out interceptor
with a proxy and set a "org.apache.cxf.post.empty" property on a message - let me know please if you'd like to try this option and I will post a code for the interceptor

thanks

> Already connected exception when using a proxy created with JAXRSClientFactory
> ------------------------------------------------------------------------------
>
> Key: CXF-2585
> URL: https://issues.apache.org/jira/browse/CXF-2585
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.5
> Environment: JDK 1.5.0.18
> Reporter: Stephane Allegro
> Fix For: 2.2.6, 2.3
>
>
> I'm trying to get a very simple Rest client working, but I always got this exception:
> java.lang.IllegalStateException: Already connected
> at java.net.HttpURLConnection.setFixedLengthStreamingMode(HttpURLConnection.java:100)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.thresholdNotReached(HTTPConduit.java:1885)
> at org.apache.cxf.io.AbstractThresholdOutputStream.close(AbstractThresholdOutputStream.java:99)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1976)
> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:637)
> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
> at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:429)
> at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:166)
> at $Proxy16.doSomething(Unknown Source)
> at com.francetelecom.resttest.RestTest.main(RestTest.java:27)
> Here is my jax-rs interface:
> @Path("/")
> public interface RestWS {
> @POST
> @Path("/test")
> public String doSomething( @QueryParam("param") String paramName);
> }
> And here the way my client uses it:
> RestWS proxy = JAXRSClientFactory.create("http://localhost:8080/RestWSMock",RestWS.class);
> proxy.doSomething("bob");
> I can not get it simpler. Any idea what's wrong ?
> regards

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CXF-2585) Already connected exception when using a proxy created with JAXRSClientFactory

2009-12-16T12:50:18Z

[ https://issues.apache.org/jira/browse/CXF-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sergey Beryozkin updated CXF-2585:
----------------------------------

Fix Version/s: 2.3
2.2.6
Assignee: Sergey Beryozkin

> Already connected exception when using a proxy created with JAXRSClientFactory
> ------------------------------------------------------------------------------
>
> Key: CXF-2585
> URL: https://issues.apache.org/jira/browse/CXF-2585
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.5
> Environment: JDK 1.5.0.18
> Reporter: Stephane Allegro
> Assignee: Sergey Beryozkin
> Fix For: 2.2.6, 2.3
>
>
> I'm trying to get a very simple Rest client working, but I always got this exception:
> java.lang.IllegalStateException: Already connected
> at java.net.HttpURLConnection.setFixedLengthStreamingMode(HttpURLConnection.java:100)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.thresholdNotReached(HTTPConduit.java:1885)
> at org.apache.cxf.io.AbstractThresholdOutputStream.close(AbstractThresholdOutputStream.java:99)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1976)
> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:637)
> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
> at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:429)
> at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:166)
> at $Proxy16.doSomething(Unknown Source)
> at com.francetelecom.resttest.RestTest.main(RestTest.java:27)
> Here is my jax-rs interface:
> @Path("/")
> public interface RestWS {
> @POST
> @Path("/test")
> public String doSomething( @QueryParam("param") String paramName);
> }
> And here the way my client uses it:
> RestWS proxy = JAXRSClientFactory.create("http://localhost:8080/RestWSMock",RestWS.class);
> proxy.doSomething("bob");
> I can not get it simpler. Any idea what's wrong ?
> regards

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (CXF-2579) Aegis reports duplicate tags for some complex types

2009-12-16T12:46:18Z

[ https://issues.apache.org/jira/browse/CXF-2579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp reassigned CXF-2579:
--------------------------------

Assignee: Daniel Kulp

> Aegis reports duplicate tags for some complex types
> ---------------------------------------------------
>
> Key: CXF-2579
> URL: https://issues.apache.org/jira/browse/CXF-2579
> Project: CXF
> Issue Type: Bug
> Components: Aegis Databinding
> Reporter: Sergey Beryozkin
> Assignee: Daniel Kulp
> Fix For: 2.2.6, 2.3
>
>
> See JAXRS AegisJSONProvider.testManyTags tests

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (CXF-2583) Please remove Maven dependency on slf4j-jdk14

2009-12-16T11:26:18Z

[ https://issues.apache.org/jira/browse/CXF-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-2583.
------------------------------

Resolution: Fixed
Fix Version/s: 2.2.6

> Please remove Maven dependency on slf4j-jdk14
> ---------------------------------------------
>
> Key: CXF-2583
> URL: https://issues.apache.org/jira/browse/CXF-2583
> Project: CXF
> Issue Type: Bug
> Components: Build system
> Affects Versions: 2.2.4
> Reporter: Chris Wilson
> Assignee: Daniel Kulp
> Fix For: 2.2.6
>
> Original Estimate: 0.25h
> Remaining Estimate: 0.25h
>
> The Maven POM for CXF 2.2.4 contains the following lines:
> <dependency>
> <groupId>org.slf4j</groupId>
> <artifactId>slf4j-jdk14</artifactId>
> <version>1.5.8</version>
> </dependency>
> This forces the SLF4J JDK14 binding to be downloaded and included in any project using this POM. Even if we want to use Log4J instead, we have no choice about the JDK14 binding being included in our project.
> We're using the Maven-Eclipse plugin to generate our Eclipse configuration. This results in slf4j-jdk14 being added to the classpath. Again this appears to be unavoidable.
> SLF4J picks the first binding in the classpath. This appears to be unavoidable. There is no documented way to avoid it. Because J comes before L, it always picks the JDK binding over the Log4J binding. This makes it impossible to use Log4J instead.
> I don't think any project should force users to choose a particular logging binding, as this defeats the whole point of SLF4J. Please just depend on the API, and let the developer or user install whatever actual binding they wish.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CXF-2427) The CXF DOSGi implementation needs to be updated to support the latest OSGi Remote Services Admin spec.

2009-12-16T10:58:18Z

[ https://issues.apache.org/jira/browse/CXF-2427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marc Schaaf updated CXF-2427:
-----------------------------

Attachment: cxf-dosgi-rsa-merge.patch

First implementation of the new Remote Service Admin Spec.
This patch splits the Distribution Software into a Remote Service Admin and a Topology Manager. Furthermore it changes the interaction between the Topology Manager and the distributed discovery to the mechanisms defined in the new Spec.

> The CXF DOSGi implementation needs to be updated to support the latest OSGi Remote Services Admin spec.
> -------------------------------------------------------------------------------------------------------
>
> Key: CXF-2427
> URL: https://issues.apache.org/jira/browse/CXF-2427
> Project: CXF
> Issue Type: Bug
> Components: Distributed-OSGi
> Affects Versions: dOSGi-1.1
> Reporter: David Bosschaert
> Assignee: David Bosschaert
> Attachments: cxf-dosgi-rsa-merge.patch
>
>
> The API for Distributed OSGi has changed quite significantly between the text in the RFC and the ultimate spec text. The DOSGi implementation in CXF needs to be updated to support the new APIs as described in the (proposed) spec.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (CXF-2583) Please remove Maven dependency on slf4j-jdk14

2009-12-16T09:26:18Z

[ https://issues.apache.org/jira/browse/CXF-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp reassigned CXF-2583:
--------------------------------

Assignee: Daniel Kulp

> Please remove Maven dependency on slf4j-jdk14
> ---------------------------------------------
>
> Key: CXF-2583
> URL: https://issues.apache.org/jira/browse/CXF-2583
> Project: CXF
> Issue Type: Bug
> Components: Build system
> Affects Versions: 2.2.4
> Reporter: Chris Wilson
> Assignee: Daniel Kulp
> Original Estimate: 0.25h
> Remaining Estimate: 0.25h
>
> The Maven POM for CXF 2.2.4 contains the following lines:
> <dependency>
> <groupId>org.slf4j</groupId>
> <artifactId>slf4j-jdk14</artifactId>
> <version>1.5.8</version>
> </dependency>
> This forces the SLF4J JDK14 binding to be downloaded and included in any project using this POM. Even if we want to use Log4J instead, we have no choice about the JDK14 binding being included in our project.
> We're using the Maven-Eclipse plugin to generate our Eclipse configuration. This results in slf4j-jdk14 being added to the classpath. Again this appears to be unavoidable.
> SLF4J picks the first binding in the classpath. This appears to be unavoidable. There is no documented way to avoid it. Because J comes before L, it always picks the JDK binding over the Log4J binding. This makes it impossible to use Log4J instead.
> I don't think any project should force users to choose a particular logging binding, as this defeats the whole point of SLF4J. Please just depend on the API, and let the developer or user install whatever actual binding they wish.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (CXF-2585) Already connected exception when using a proxy created with JAXRSClientFactory

2009-12-16T09:08:18Z

Already connected exception when using a proxy created with JAXRSClientFactory
------------------------------------------------------------------------------

Key: CXF-2585
URL: https://issues.apache.org/jira/browse/CXF-2585
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.2.5
Environment: JDK 1.5.0.18

Reporter: Stephane Allegro

I'm trying to get a very simple Rest client working, but I always got this exception:

java.lang.IllegalStateException: Already connected
at java.net.HttpURLConnection.setFixedLengthStreamingMode(HttpURLConnection.java:100)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.thresholdNotReached(HTTPConduit.java:1885)
at org.apache.cxf.io.AbstractThresholdOutputStream.close(AbstractThresholdOutputStream.java:99)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1976)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:637)
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:429)
at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:166)
at $Proxy16.doSomething(Unknown Source)
at com.francetelecom.resttest.RestTest.main(RestTest.java:27)

Here is my jax-rs interface:

@Path("/")
public interface RestWS {
@POST
@Path("/test")
public String doSomething( @QueryParam("param") String paramName);
}

And here the way my client uses it:

RestWS proxy = JAXRSClientFactory.create("http://localhost:8080/RestWSMock",RestWS.class);
proxy.doSomething("bob");

I can not get it simpler. Any idea what's wrong ?
regards

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CXF-2541) JMX Per Operation ResponseTime not collected for JAX-RS services

2009-12-16T08:55:18Z

[ https://issues.apache.org/jira/browse/CXF-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791449#action_12791449 ]

Sergey Beryozkin commented on CXF-2541:
---------------------------------------

Sure, no probs :-) I'll apply tomorrow, need to complete some Atom logging work

cheers, Sergey

> JMX Per Operation ResponseTime not collected for JAX-RS services
> ----------------------------------------------------------------
>
> Key: CXF-2541
> URL: https://issues.apache.org/jira/browse/CXF-2541
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.3
> Reporter: Cyrille Le Clerc
> Attachments: CXF-2541-jaxrs-client.patch, cxf-2541.patch, usage-of-OperationInfo-and-OperationResourceInfo.log
>
>
> The JMX ResponseTimeFeature does not work on a per operation basis for JAXRS calls but works on a per Service basis.
> My understanding is that it works on a per service basis because both o.a.c.jaxrs.JAXRSServiceImpl and o.a.c.service.ServiceImpl implement the same o.a.c.service.Service interface and are indexed in the Exchange map at the o.a.c.service.Service entry.
> On the other hand, it does not work on the per operation basis because o.a.c.jaxrs.model.OperationResourceInfo and o.a.c.service.model.OperationInfo do not implement a shared interface. Thus, the ResponseTimeFeature is specific to SOAP operations and can not handle JAXRS 'operations'.
> A fix could be to introduce a shared Operation interface, to make both OperationResourceInfo and OperationInfo implement this interface and to us the interface as the key for the Exchange map instead of the current OperationResourceInfo.class and OperationInfo.class.
> There are 30 "put()" & "get()" calls on OperationInfo.class. and 8 "put()" & "get()" calls on OperationResourceInfo.class.
> I would be very pleased to propose a patch if the project is interested.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CXF-2584) NullPointerException in CXFAuthenticator.getPasswordAuthentication() if password is null

2009-12-16T08:43:18Z

[ https://issues.apache.org/jira/browse/CXF-2584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp updated CXF-2584:
-----------------------------

Affects Version/s: (was: 2.2.5)
2.2.6

> NullPointerException in CXFAuthenticator.getPasswordAuthentication() if password is null
> ----------------------------------------------------------------------------------------
>
> Key: CXF-2584
> URL: https://issues.apache.org/jira/browse/CXF-2584
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 2.2.6
> Reporter: Cyrille Le Clerc
> Assignee: Daniel Kulp
> Fix For: 2.2.6
>
> Attachments: CXF-2584.patch
>
>
> {{NullPointerException}} in {{CXFAuthenticator.getPasswordAuthentication()}} if password is {{null}}.
> Cause of the NPE :
> {code:title=extract from org.apache.cxf.transport.http.CXFAuthenticator}
> protected PasswordAuthentication getPasswordAuthentication() {
> ...
> auth = new PasswordAuthentication(httpConduit.getAuthorization().getUserName(),
> httpConduit.getAuthorization()
> .getPassword().toCharArray());
> ...
> {code}
> Stack trace :
> {noformat}
> java.lang.RuntimeException: RuntimeException invoking http://localhost:8080/... : java.lang.NullPointerException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:2010)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1996)
> at org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:47)
> at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:188)
> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:639)
> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:239)
> at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:429)
> at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:166)
> at $Proxy69.sayHello(Unknown Source)
> ...
> Caused by: java.lang.RuntimeException: java.lang.NullPointerException
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1014)
> at sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:2211)
> at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:382)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2110)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2086)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1984)
> ... 70 more
> Caused by: java.lang.NullPointerException
> at org.apache.cxf.transport.http.CXFAuthenticator.getPasswordAuthentication(CXFAuthenticator.java:96)
> at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:300)
> at sun.net.www.protocol.http.HttpURLConnection$1.run(HttpURLConnection.java:297)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.net.www.protocol.http.HttpURLConnection.privilegedRequestPasswordAuthentication(HttpURLConnection.java:293)
> at sun.net.www.protocol.http.HttpURLConnection.getServerAuthentication(HttpURLConnection.java:1795)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1159)
> at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:373)
> ... 73 more
> {noformat}

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (CXF-2584) NullPointerException in CXFAuthenticator.getPasswordAuthentication() if password is null

2009-12-16T08:43:18Z

[ https://issues.apache.org/jira/browse/CXF-2584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-2584.
------------------------------

Resolution: Fixed
Fix Version/s: 2.2.6
Assignee: Daniel Kulp

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CXF-2541) JMX Per Operation ResponseTime not collected for JAX-RS services

2009-12-16T07:23:18Z

[ https://issues.apache.org/jira/browse/CXF-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791399#action_12791399 ]

Cyrille Le Clerc commented on CXF-2541:
---------------------------------------

Thanks Sergey but I didn't receive my credentials yet.
I may do my first commit on JAX-RS endpoints & clients' exception monitoring ; my project will need it very very soon :-) .

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CXF-2541) JMX Per Operation ResponseTime not collected for JAX-RS services

2009-12-16T07:17:18Z

[ https://issues.apache.org/jira/browse/CXF-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791397#action_12791397 ]

Sergey Beryozkin commented on CXF-2541:
---------------------------------------

Hi Cyrille, thanks a lot, it looks fine. Would you like to do your first CXF commit :-) ?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CXF-2541) JMX Per Operation ResponseTime not collected for JAX-RS services

2009-12-16T07:05:18Z

[ https://issues.apache.org/jira/browse/CXF-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Cyrille Le Clerc updated CXF-2541:
----------------------------------

Attachment: CXF-2541-jaxrs-client.patch

Here is the patch for JAX-RS client monitoring :
* define exchange.service in o.a.c.jaxrs.client.AbstractClient.createMessage()
* define exchange.operationname in o.a.c.jaxrs.client.ClientProxyImpl.doChainedInvocation()

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CXF-2541) JMX Per Operation ResponseTime not collected for JAX-RS services

2009-12-16T03:48:18Z

[ https://issues.apache.org/jira/browse/CXF-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791337#action_12791337 ]

Sergey Beryozkin commented on CXF-2541:
---------------------------------------

Hi Cyrille

AbstractJAXRSFactoryBean.createEndpoint() initializes an endpoint with a service.

Adding exchange.setContent(Service.class, cfg.getConduitSelector().getEndpoint().getService()) ?
in AbstractClient.prepareMessage, after prepareConduitSelector() call, should work...

> The next step would be to pass the OperationResourceInfo to this AbstractClient.prepareMessage() to set the Operation name

AbstractClient.prepareMessage() is also used by WebClient which has no notion of OperationResourceInfo, so doing it in

ClientProxyImpl.doChainedInvocation, immediately after prepareMessage(), on message.getExchange(), should do the trick

cheers, Sergey

> JMX Per Operation ResponseTime not collected for JAX-RS services
> ----------------------------------------------------------------
>
> Key: CXF-2541
> URL: https://issues.apache.org/jira/browse/CXF-2541
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.3
> Reporter: Cyrille Le Clerc
> Attachments: cxf-2541.patch, usage-of-OperationInfo-and-OperationResourceInfo.log
>
>
> The JMX ResponseTimeFeature does not work on a per operation basis for JAXRS calls but works on a per Service basis.
> My understanding is that it works on a per service basis because both o.a.c.jaxrs.JAXRSServiceImpl and o.a.c.service.ServiceImpl implement the same o.a.c.service.Service interface and are indexed in the Exchange map at the o.a.c.service.Service entry.
> On the other hand, it does not work on the per operation basis because o.a.c.jaxrs.model.OperationResourceInfo and o.a.c.service.model.OperationInfo do not implement a shared interface. Thus, the ResponseTimeFeature is specific to SOAP operations and can not handle JAXRS 'operations'.
> A fix could be to introduce a shared Operation interface, to make both OperationResourceInfo and OperationInfo implement this interface and to us the interface as the key for the Exchange map instead of the current OperationResourceInfo.class and OperationInfo.class.
> There are 30 "put()" & "get()" calls on OperationInfo.class. and 8 "put()" & "get()" calls on OperationResourceInfo.class.
> I would be very pleased to propose a patch if the project is interested.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CXF-2541) JMX Per Operation ResponseTime not collected for JAX-RS services

2009-12-16T03:25:18Z

[ https://issues.apache.org/jira/browse/CXF-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791328#action_12791328 ]

Cyrille Le Clerc commented on CXF-2541:
---------------------------------------

Hi Sergey,

For homogeneity with jaxws, I feel more like following the AbstractClient.prepareMessage() way.

Unfortunately, when I step-by-step debug the jax-rs client call, cfg.getConduitSelector().getEndpoint().getService() is null and I am digging to find where it could be elegantly initialized:-(

The next step would be to pass the OperationResourceInfo to this AbstractClient.prepareMessage() to set the Operation name.

Does it make sense ?

Cyrille

> JMX Per Operation ResponseTime not collected for JAX-RS services
> ----------------------------------------------------------------
>
> Key: CXF-2541
> URL: https://issues.apache.org/jira/browse/CXF-2541
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.3
> Reporter: Cyrille Le Clerc
> Attachments: cxf-2541.patch, usage-of-OperationInfo-and-OperationResourceInfo.log
>
>
> The JMX ResponseTimeFeature does not work on a per operation basis for JAXRS calls but works on a per Service basis.
> My understanding is that it works on a per service basis because both o.a.c.jaxrs.JAXRSServiceImpl and o.a.c.service.ServiceImpl implement the same o.a.c.service.Service interface and are indexed in the Exchange map at the o.a.c.service.Service entry.
> On the other hand, it does not work on the per operation basis because o.a.c.jaxrs.model.OperationResourceInfo and o.a.c.service.model.OperationInfo do not implement a shared interface. Thus, the ResponseTimeFeature is specific to SOAP operations and can not handle JAXRS 'operations'.
> A fix could be to introduce a shared Operation interface, to make both OperationResourceInfo and OperationInfo implement this interface and to us the interface as the key for the Exchange map instead of the current OperationResourceInfo.class and OperationInfo.class.
> There are 30 "put()" & "get()" calls on OperationInfo.class. and 8 "put()" & "get()" calls on OperationResourceInfo.class.
> I would be very pleased to propose a patch if the project is interested.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CXF-2584) NullPointerException in CXFAuthenticator.getPasswordAuthentication() if password is null

2009-12-16T02:25:18Z

[ https://issues.apache.org/jira/browse/CXF-2584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Cyrille Le Clerc updated CXF-2584:
----------------------------------

Attachment: CXF-2584.patch

Proposed patch : check for non null authorization.username and username.password .

> NullPointerException in CXFAuthenticator.getPasswordAuthentication() if password is null
> ----------------------------------------------------------------------------------------
>
> Key: CXF-2584
> URL: https://issues.apache.org/jira/browse/CXF-2584
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 2.2.5
> Reporter: Cyrille Le Clerc
> Attachments: CXF-2584.patch
>
>
> {{NullPointerException}} in {{CXFAuthenticator.getPasswordAuthentication()}} if password is {{null}}.
> Cause of the NPE :
> {code:title=extract from org.apache.cxf.transport.http.CXFAuthenticator}
> protected PasswordAuthentication getPasswordAuthentication() {
> ...
> auth = new PasswordAuthentication(httpConduit.getAuthorization().getUserName(),
> httpConduit.getAuthorization()
> .getPassword().toCharArray());
> ...
> {code}
> Stack trace :
> {noformat}
> java.lang.RuntimeException: RuntimeException invoking http://localhost:8080/... : java.lang.NullPointerException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:2010)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1996)
> at org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:47)
> at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:188)
> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:639)
> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:239)
> at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:429)
> at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:166)
> at $Proxy69.sayHello(Unknown Source)
> ...
> Caused by: java.lang.RuntimeException: java.lang.NullPointerException
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1014)
> at sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:2211)
> at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:382)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2110)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2086)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1984)
> ... 70 more
> Caused by: java.lang.NullPointerException
> at org.apache.cxf.transport.http.CXFAuthenticator.getPasswordAuthentication(CXFAuthenticator.java:96)
> at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:300)
> at sun.net.www.protocol.http.HttpURLConnection$1.run(HttpURLConnection.java:297)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.net.www.protocol.http.HttpURLConnection.privilegedRequestPasswordAuthentication(HttpURLConnection.java:293)
> at sun.net.www.protocol.http.HttpURLConnection.getServerAuthentication(HttpURLConnection.java:1795)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1159)
> at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:373)
> ... 73 more
> {noformat}

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CXF-2541) JMX Per Operation ResponseTime not collected for JAX-RS services

2009-12-16T02:19:18Z

[ https://issues.apache.org/jira/browse/CXF-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791298#action_12791298 ]

Sergey Beryozkin commented on CXF-2541:
---------------------------------------

Hi Cyrille

thanks for the confirmation.
Perhaps AbstractMessageResponseTimeInterceptor can be updated to get Service out of Endpoint, endpoint.getService() ?

Or may be it would make sense to update AbstractClient.prepareMessage with something like

exchange.setContent(Service.class, cfg.getConduitSelector().getEndpoint().getService()) ?

Actually, ClientProxyImpl.doChainedInvocation should probably be updated to have

"org.apache.cxf.management.operation.name" set on the exchange as well, so that proxy-based clients can also have
the operations checked...

thanks, Sergey

> JMX Per Operation ResponseTime not collected for JAX-RS services
> ----------------------------------------------------------------
>
> Key: CXF-2541
> URL: https://issues.apache.org/jira/browse/CXF-2541
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.3
> Reporter: Cyrille Le Clerc
> Attachments: cxf-2541.patch, usage-of-OperationInfo-and-OperationResourceInfo.log
>
>
> The JMX ResponseTimeFeature does not work on a per operation basis for JAXRS calls but works on a per Service basis.
> My understanding is that it works on a per service basis because both o.a.c.jaxrs.JAXRSServiceImpl and o.a.c.service.ServiceImpl implement the same o.a.c.service.Service interface and are indexed in the Exchange map at the o.a.c.service.Service entry.
> On the other hand, it does not work on the per operation basis because o.a.c.jaxrs.model.OperationResourceInfo and o.a.c.service.model.OperationInfo do not implement a shared interface. Thus, the ResponseTimeFeature is specific to SOAP operations and can not handle JAXRS 'operations'.
> A fix could be to introduce a shared Operation interface, to make both OperationResourceInfo and OperationInfo implement this interface and to us the interface as the key for the Exchange map instead of the current OperationResourceInfo.class and OperationInfo.class.
> There are 30 "put()" & "get()" calls on OperationInfo.class. and 8 "put()" & "get()" calls on OperationResourceInfo.class.
> I would be very pleased to propose a patch if the project is interested.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (CXF-2584) NullPointerException in CXFAuthenticator.getPasswordAuthentication() if password is null

2009-12-16T02:16:18Z

NullPointerException in CXFAuthenticator.getPasswordAuthentication() if password is null
----------------------------------------------------------------------------------------

Key: CXF-2584
URL: https://issues.apache.org/jira/browse/CXF-2584
Project: CXF
Issue Type: Bug
Components: Transports
Affects Versions: 2.2.5
Reporter: Cyrille Le Clerc

{{NullPointerException}} in {{CXFAuthenticator.getPasswordAuthentication()}} if password is {{null}}.

Cause of the NPE :

{code:title=extract from org.apache.cxf.transport.http.CXFAuthenticator}

protected PasswordAuthentication getPasswordAuthentication() {
...
auth = new PasswordAuthentication(httpConduit.getAuthorization().getUserName(),
httpConduit.getAuthorization()
.getPassword().toCharArray());
...
{code}

Stack trace :

{noformat}
java.lang.RuntimeException: RuntimeException invoking http://localhost:8080/... : java.lang.NullPointerException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:2010)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1996)
at org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:47)
at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:188)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:639)
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:239)
at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:429)
at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:166)
at $Proxy69.sayHello(Unknown Source)
...
Caused by: java.lang.RuntimeException: java.lang.NullPointerException
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1014)
at sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:2211)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:382)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2110)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2086)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1984)
... 70 more
Caused by: java.lang.NullPointerException
at org.apache.cxf.transport.http.CXFAuthenticator.getPasswordAuthentication(CXFAuthenticator.java:96)
at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:300)
at sun.net.www.protocol.http.HttpURLConnection$1.run(HttpURLConnection.java:297)
at java.security.AccessController.doPrivileged(Native Method)
at sun.net.www.protocol.http.HttpURLConnection.privilegedRequestPasswordAuthentication(HttpURLConnection.java:293)
at sun.net.www.protocol.http.HttpURLConnection.getServerAuthentication(HttpURLConnection.java:1795)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1159)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:373)
... 73 more
{noformat}

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CXF-1510) Cannot handle anonymous bare requests

2009-12-16T01:52:18Z

[ https://issues.apache.org/jira/browse/CXF-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791295#action_12791295 ]

Alessio Soldano commented on CXF-1510:
--------------------------------------

Thanks Dan

> Cannot handle anonymous bare requests
> -------------------------------------
>
> Key: CXF-1510
> URL: https://issues.apache.org/jira/browse/CXF-1510
> Project: CXF
> Issue Type: Sub-task
> Components: JAX-WS Runtime
> Affects Versions: 2.0.5
> Reporter: Thomas Diesler
> Assignee: Daniel Kulp
> Fix For: 2.2.6
>
>
> [tdiesler@tddell trunk]$ ant -Dtest=jaxws/anonymous test
> tests-run-internal:
> [junit] Running org.jboss.test.ws.jaxws.anonymous.AnonymousTestCase
> [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 7.294 sec
> [junit] Test org.jboss.test.ws.jaxws.anonymous.AnonymousTestCase FAILED
> 14:43:30,862 ERROR [[AnonymousService]] Allocate exception for servlet AnonymousService
> java.lang.NullPointerException
> at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.createBareMessage(ReflectionServiceFactoryBean.java:951)
> at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:330)
> at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:368)
> at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:162)
> at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:97)
> at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:74)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (CXF-2541) JMX Per Operation ResponseTime not collected for JAX-RS services

2009-12-16T01:44:18Z

[ https://issues.apache.org/jira/browse/CXF-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791290#action_12791290 ]

Cyrille Le Clerc edited comment on CXF-2541 at 12/16/09 9:42 AM:
-----------------------------------------------------------------

Hi Sergey,

JAX-RS end point per operation monitoring works as expected with your patch. However, there is a problem for JAX-RS cleints (NPE because Service attribute is missing) ; I am working on it.

{noformat}
2009/12/16 10:35:19,028 WARN [http-8080-1] org.apache.cxf.phase.PhaseInterceptorChain - Exception in handleFault on interceptor org.apache.cxf.management.interceptor.ResponseTimeMessageOutInterceptor@1e19bba3
java.lang.NullPointerException
at org.apache.cxf.management.interceptor.AbstractMessageResponseTimeInterceptor.increaseCounter(AbstractMessageResponseTimeInterceptor.java:108)
at org.apache.cxf.management.interceptor.AbstractMessageResponseTimeInterceptor.endHandlingMessage(AbstractMessageResponseTimeInterceptor.java:74)
at org.apache.cxf.management.interceptor.ResponseTimeMessageOutInterceptor.handleFault(ResponseTimeMessageOutInterceptor.java:62)
at org.apache.cxf.phase.PhaseInterceptorChain.unwind(PhaseInterceptorChain.java:384)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:305)
at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:429)
at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:166)
at $Proxy69.sayHello(Unknown Source)
...
{noformat}

was (Author: cleclerc):
Hi Sergey,

JAX-RS end point per operation monitoring works as expected with your patch. However, there is a problem for JAX-RS cleints (NPE because Service attribute is missing) ; I am working on it.

{quote}
2009/12/16 10:35:19,028 WARN [http-8080-1] org.apache.cxf.phase.PhaseInterceptorChain - Exception in handleFault on interceptor org.apache.cxf.management.interceptor.ResponseTimeMessageOutInterceptor@1e19bba3
java.lang.NullPointerException
at org.apache.cxf.management.interceptor.AbstractMessageResponseTimeInterceptor.increaseCounter(AbstractMessageResponseTimeInterceptor.java:108)
at org.apache.cxf.management.interceptor.AbstractMessageResponseTimeInterceptor.endHandlingMessage(AbstractMessageResponseTimeInterceptor.java:74)
at org.apache.cxf.management.interceptor.ResponseTimeMessageOutInterceptor.handleFault(ResponseTimeMessageOutInterceptor.java:62)
at org.apache.cxf.phase.PhaseInterceptorChain.unwind(PhaseInterceptorChain.java:384)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:305)
at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:429)
at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:166)
at $Proxy69.sayHello(Unknown Source)
...
{quote}

> JMX Per Operation ResponseTime not collected for JAX-RS services
> ----------------------------------------------------------------
>
> Key: CXF-2541
> URL: https://issues.apache.org/jira/browse/CXF-2541
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.3
> Reporter: Cyrille Le Clerc
> Attachments: cxf-2541.patch, usage-of-OperationInfo-and-OperationResourceInfo.log
>
>
> The JMX ResponseTimeFeature does not work on a per operation basis for JAXRS calls but works on a per Service basis.
> My understanding is that it works on a per service basis because both o.a.c.jaxrs.JAXRSServiceImpl and o.a.c.service.ServiceImpl implement the same o.a.c.service.Service interface and are indexed in the Exchange map at the o.a.c.service.Service entry.
> On the other hand, it does not work on the per operation basis because o.a.c.jaxrs.model.OperationResourceInfo and o.a.c.service.model.OperationInfo do not implement a shared interface. Thus, the ResponseTimeFeature is specific to SOAP operations and can not handle JAXRS 'operations'.
> A fix could be to introduce a shared Operation interface, to make both OperationResourceInfo and OperationInfo implement this interface and to us the interface as the key for the Exchange map instead of the current OperationResourceInfo.class and OperationInfo.class.
> There are 30 "put()" & "get()" calls on OperationInfo.class. and 8 "put()" & "get()" calls on OperationResourceInfo.class.
> I would be very pleased to propose a patch if the project is interested.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CXF-2541) JMX Per Operation ResponseTime not collected for JAX-RS services

2009-12-16T01:42:18Z

[ https://issues.apache.org/jira/browse/CXF-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791290#action_12791290 ]

Cyrille Le Clerc commented on CXF-2541:
---------------------------------------

Hi Sergey,

JAX-RS end point per operation monitoring works as expected with your patch. However, there is a problem for JAX-RS cleints (NPE because Service attribute is missing) ; I am working on it.

{quote}
2009/12/16 10:35:19,028 WARN [http-8080-1] org.apache.cxf.phase.PhaseInterceptorChain - Exception in handleFault on interceptor org.apache.cxf.management.interceptor.ResponseTimeMessageOutInterceptor@1e19bba3
java.lang.NullPointerException
at org.apache.cxf.management.interceptor.AbstractMessageResponseTimeInterceptor.increaseCounter(AbstractMessageResponseTimeInterceptor.java:108)
at org.apache.cxf.management.interceptor.AbstractMessageResponseTimeInterceptor.endHandlingMessage(AbstractMessageResponseTimeInterceptor.java:74)
at org.apache.cxf.management.interceptor.ResponseTimeMessageOutInterceptor.handleFault(ResponseTimeMessageOutInterceptor.java:62)
at org.apache.cxf.phase.PhaseInterceptorChain.unwind(PhaseInterceptorChain.java:384)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:305)
at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:429)
at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:166)
at $Proxy69.sayHello(Unknown Source)
...
{quote}

> JMX Per Operation ResponseTime not collected for JAX-RS services
> ----------------------------------------------------------------
>
> Key: CXF-2541
> URL: https://issues.apache.org/jira/browse/CXF-2541
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.3
> Reporter: Cyrille Le Clerc
> Attachments: cxf-2541.patch, usage-of-OperationInfo-and-OperationResourceInfo.log
>
>
> The JMX ResponseTimeFeature does not work on a per operation basis for JAXRS calls but works on a per Service basis.
> My understanding is that it works on a per service basis because both o.a.c.jaxrs.JAXRSServiceImpl and o.a.c.service.ServiceImpl implement the same o.a.c.service.Service interface and are indexed in the Exchange map at the o.a.c.service.Service entry.
> On the other hand, it does not work on the per operation basis because o.a.c.jaxrs.model.OperationResourceInfo and o.a.c.service.model.OperationInfo do not implement a shared interface. Thus, the ResponseTimeFeature is specific to SOAP operations and can not handle JAXRS 'operations'.
> A fix could be to introduce a shared Operation interface, to make both OperationResourceInfo and OperationInfo implement this interface and to us the interface as the key for the Exchange map instead of the current OperationResourceInfo.class and OperationInfo.class.
> There are 30 "put()" & "get()" calls on OperationInfo.class. and 8 "put()" & "get()" calls on OperationResourceInfo.class.
> I would be very pleased to propose a patch if the project is interested.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (CXF-2578) Discovery problem when two dependent bundles export interfaces

2009-12-16T01:34:18Z

[ https://issues.apache.org/jira/browse/CXF-2578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Bosschaert resolved CXF-2578.
-----------------------------------

Resolution: Fixed

> Discovery problem when two dependent bundles export interfaces
> --------------------------------------------------------------
>
> Key: CXF-2578
> URL: https://issues.apache.org/jira/browse/CXF-2578
> Project: CXF
> Issue Type: Bug
> Components: Distributed-OSGi
> Affects Versions: dOSGi-1.1
> Environment: felix-2.0.1
> Reporter: Alexander Broekhuis
> Assignee: David Bosschaert
> Attachments: cxf-dosgi-ri-multibundle-distribution-1.2-SNAPSHOT.tar.gz, cxf-dosgi-ri-singlebundle-distribution-1.2-SNAPSHOT.jar, testcase.tar.gz
>
>
> I have the following setup:
> - first bundle with a common interface (common)
> - second bundle with a common interface (commonb)
> - client bundle with a service implementing the first common interface (client)
> - server bundle with a service implementing the second common interface (server)
> Both the client and the server export the implemented interface.
> The client service has a tracker to the interface published by the server.
> So the interface of the client isn't used.
> Further, I use the 1.1 singlebundle distribution.
> If I run this situation, the client most of the time does not track any server interface. Stopping the client and the distributed osgi bundle, and then first starting the dosgi bundle, and after that the client, makes the tracker work.
> If I remove the remote properties from the client the tracker works. I can start stop any way I want, it keeps finding the server interface.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (CXF-2583) Please remove Maven dependency on slf4j-jdk14

2009-12-16T01:28:18Z

Please remove Maven dependency on slf4j-jdk14
---------------------------------------------

Key: CXF-2583
URL: https://issues.apache.org/jira/browse/CXF-2583
Project: CXF
Issue Type: Bug
Components: Build system
Affects Versions: 2.2.4
Reporter: Chris Wilson

The Maven POM for CXF 2.2.4 contains the following lines:

<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-jdk14</artifactId>
<version>1.5.8</version>
</dependency>

This forces the SLF4J JDK14 binding to be downloaded and included in any project using this POM. Even if we want to use Log4J instead, we have no choice about the JDK14 binding being included in our project.

We're using the Maven-Eclipse plugin to generate our Eclipse configuration. This results in slf4j-jdk14 being added to the classpath. Again this appears to be unavoidable.

SLF4J picks the first binding in the classpath. This appears to be unavoidable. There is no documented way to avoid it. Because J comes before L, it always picks the JDK binding over the Log4J binding. This makes it impossible to use Log4J instead.

I don't think any project should force users to choose a particular logging binding, as this defeats the whole point of SLF4J. Please just depend on the API, and let the developer or user install whatever actual binding they wish.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (CXF-1520) MTOM chunked encoding transfer

2009-12-16T00:40:18Z

[ https://issues.apache.org/jira/browse/CXF-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano reassigned CXF-1520:
------------------------------------

Assignee: jimma

> MTOM chunked encoding transfer
> ------------------------------
>
> Key: CXF-1520
> URL: https://issues.apache.org/jira/browse/CXF-1520
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0.5
> Reporter: Thomas Diesler
> Assignee: jimma
>
> [tdiesler@tddell trunk]$ ant -Dtest=jaxws/jbws2000 test
> tests-run-internal:
> [junit] Running org.jboss.test.ws.jaxws.jbws2000.JBWS2000TestCase
> [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 77.876 sec
> [junit] Test org.jboss.test.ws.jaxws.jbws2000.JBWS2000TestCase FAILED
> BUILD SUCCESSFUL
> Total time: 1 minute 26 seconds
> [tdiesler@tddell trunk]$ cat output/tests/reports/TEST-org.jboss.test.ws.jaxws.jbws2000.JBWS2000TestCase.txt
> Testsuite: org.jboss.test.ws.jaxws.jbws2000.JBWS2000TestCase
> Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 77.876 sec
> Testcase: testFileTransfer took 73.095 sec
> Caused an ERROR
> Could not send Message.
> javax.xml.ws.soap.SOAPFaultException: Could not send Message.
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:211)
> at $Proxy21.transferFile(Unknown Source)
> at org.jboss.test.ws.jaxws.jbws2000.JBWS2000TestCase.testFileTransfer(JBWS2000TestCase.java:70)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> Caused by: org.apache.cxf.interceptor.Fault: Could not send Message.
> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:170)
> ... 21 more
> Caused by: java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:129)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:659)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:604)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:957)
> at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:367)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1884)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1812)
> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:582)
> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> ... 26 more

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CXF-2578) Discovery problem when two dependent bundles export interfaces

2009-12-15T23:46:18Z

[ https://issues.apache.org/jira/browse/CXF-2578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791254#action_12791254 ]

Alexander Broekhuis commented on CXF-2578:
------------------------------------------

Yes for now I have either a workaround, or the bugs are fixed.

Thanks for the multibundle file.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (CXF-2546) NullPointerException when trying to find WS-Addressing Action

2009-12-15T14:33:18Z

[ https://issues.apache.org/jira/browse/CXF-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-2546.
------------------------------

Resolution: Fixed
Fix Version/s: 2.2.6
2.1.9

> NullPointerException when trying to find WS-Addressing Action
> -------------------------------------------------------------
>
> Key: CXF-2546
> URL: https://issues.apache.org/jira/browse/CXF-2546
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Affects Versions: 2.2.4
> Reporter: John Hite
> Assignee: Daniel Kulp
> Priority: Minor
> Fix For: 2.1.9, 2.2.6
>
> Attachments: WSAddressingSample.zip
>
>
> I have wsdl operations that look like this
> <wsdl:operation name="Ping">
> <wsdl:input wsam:Action="Test.Services/IProxyService/Ping" message="tns:IProxyService_Ping_InputMessage" />
> <wsdl:output wsam:Action="Test.Services/IProxyService/PingResponse" message="tns:IProxyService_Ping_OutputMessage" />
> </wsdl:operation>
> wsam=http://www.w3.org/2007/05/addressing/metadata
> If I try to run the client with this wsdl, I get a NullPointerException
> IProxyServiceClient:
> [java] Invoking ping...
> [java] Nov 17, 2009 4:15:58 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> [java] WARNING: Interceptor has thrown exception, unwinding now
> [java] java.lang.NullPointerException
> [java] at org.apache.cxf.ws.addressing.ContextUtils.getAction(ContextUtils.java:803)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.getActionFromInputMessage(MAPAggregator.java:438)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.getActionUri(MAPAggregator.java:521)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.assembleGeneric(MAPAggregator.java:427)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.aggregate(MAPAggregator.java:396)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.mediate(MAPAggregator.java:342)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.handleMessage(MAPAggregator.java:158)
> [java] at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
> [java] at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:478)
> [java] at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:308)
> [java] at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:260)
> [java] at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> [java] at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
> [java] at $Proxy39.ping(Unknown Source)
> [java] at services.test.IProxyService_CustomBindingIProxyService_Client.main(IProxyService_CustomBindingIProxyService_Client.java:56)
> [java] Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: Fault string, and possibly fault code, not set
> [java] at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146)
> [java] at $Proxy39.ping(Unknown Source)
> [java] at services.test.IProxyService_CustomBindingIProxyService_Client.main(IProxyService_CustomBindingIProxyService_Client.java:56)
> [java] Caused by: java.lang.NullPointerException
> [java] at org.apache.cxf.ws.addressing.ContextUtils.getAction(ContextUtils.java:803)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.getActionFromInputMessage(MAPAggregator.java:438)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.getActionUri(MAPAggregator.java:521)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.assembleGeneric(MAPAggregator.java:427)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.aggregate(MAPAggregator.java:396)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.mediate(MAPAggregator.java:342)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.handleMessage(MAPAggregator.java:158)
> [java] at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
> [java] at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:478)
> [java] at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:308)
> [java] at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:260)
> [java] at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> [java] at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
> [java] ... 2 more
> [java] Java Result: 1
> if I switch the namespace prefix of the actions to wsaw, where wsaw=http://www.w3.org/2006/05/addressing/wsdl, everything works.
> I'll upload a sample wsdl and ant build file. It will generate a client, server and ant file.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CXF-1510) Cannot handle anonymous bare requests

2009-12-15T13:49:18Z

[ https://issues.apache.org/jira/browse/CXF-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp updated CXF-1510:
-----------------------------

Fix Version/s: (was: 2.1.9)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (CXF-2135) JAXB binding files with no schemaLocation don't work

2009-12-15T13:19:35Z

[ https://issues.apache.org/jira/browse/CXF-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-2135.
------------------------------

Resolution: Won't Fix
Fix Version/s: Invalid

Marking this invalid. Per JAXB spec, the schemaLocation is required so not accepting it is OK.

> JAXB binding files with no schemaLocation don't work
> ----------------------------------------------------
>
> Key: CXF-2135
> URL: https://issues.apache.org/jira/browse/CXF-2135
> Project: CXF
> Issue Type: Bug
> Components: Tooling
> Reporter: Benson Margulies
> Fix For: Invalid
>
>
> In order to clean up other code and prevent other bugs, I am breaking the code that allows JAXB binding files with no schemaLocation attribute to work.
> In 2.2 and earlier, this worked because we fed all the schemas to JAXB under the same key. This is contrary to the doc and likely to cause other more confusing problems, such as mis-applied customizations.
> The correct solution seems to be to just leave off the schemaLocation, but as of JAXB 2.1.10, that doesn't work, since JAXB doesn't handle this case for outboard customization files. Heck, perhaps recycling outboard customization files with JAXB is just not a good idea, period.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (CXF-1886) Disappearing types from @XmlRootElement and no particular namespace

2009-12-15T13:15:18Z

[ https://issues.apache.org/jira/browse/CXF-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-1886.
------------------------------

Resolution: Fixed
Fix Version/s: 2.2.6
2.1.9
Assignee: Daniel Kulp

This is actually the same issue as CXF-1510 and was fixed as part of that. Param types with just XmlRootElement and no XmlType are pretty much considered anonymous types.

> Disappearing types from @XmlRootElement and no particular namespace
> -------------------------------------------------------------------
>
> Key: CXF-1886
> URL: https://issues.apache.org/jira/browse/CXF-1886
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
> Affects Versions: 2.2
> Reporter: Benson Margulies
> Assignee: Daniel Kulp
> Fix For: 2.1.9, 2.2.6
>
> Attachments: trouble.patch, wsdl
>
>
> The attached patch adds two 'innocent' types to the the tests in cxf-rt-javascript. If you look at the attached WSDL, you will see that the type 'inheritanceTestDerived' is referenced in the WSDL but does not end up defined in the schema at all, anywhere!

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (CXF-2093) CXF Compatiblity

2009-12-15T12:40:18Z

[ https://issues.apache.org/jira/browse/CXF-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-2093.
------------------------------

Resolution: Fixed
Fix Version/s: 2.2.6
2.1.9

I'm resolving this. Using the test case above, I checked:

|| Client || Server
|2.1.9-SNAPSHOT|2.1.9-SNAPSHOT|
|2.1.9-SNAPSHOT|2.2.6-SNAPSHOT|
|2.2.6-SNAPSHOT|2.1.9-SNAPSHOT|
|2.2.6-SNAPSHOT|2.2.6-SNAPSHOT|

Thus, all the 2.1 <--> 2.2 scenarios are now working. The 2.0.x scenarios might not be, but we don't support 2.0.x anymore.

> CXF Compatiblity
> ----------------
>
> Key: CXF-2093
> URL: https://issues.apache.org/jira/browse/CXF-2093
> Project: CXF
> Issue Type: Bug
> Components: Integration
> Affects Versions: 2.0.9, 2.1.3, 2.0.10, 2.1.4, 2.2, 2.1.5
> Reporter: Brian Relph
> Assignee: Benson Margulies
> Fix For: 2.1.9, 2.2.6
>
> Attachments: cxf-test-case.zip
>
>
> The attached projects attempt to illustrate the compatibility problems between CXF versions. The projects also illustrate some bugs within each CXF code branch. Hopefully these test projects can help to identify the bugs.
> The -service projects are wars. They each contain a test that starts the war, generates a client, and runs each service method. The wars can also run standalone with 'mvn jetty:run', and you can run the -client projects tests against it.
> The -client projects contains a test that creates a client, and attempts to run each service method against a localhost:8080 server.
> Here is an overview of the current compatibility with the supplied projects:
> 2.0 Service
> ----------------
> 1. 2.0 Client: The client throws a null-pointer exception when creating the Aegis databinding at org.apache.cxf.aegis.type.basic.BeanTypeInfo.getType(BeanTypeInfo.java:199).
> 2. 2.1 Client: The client throws a null-pointer exception when creating the Aegis databinding at org.apache.cxf.aegis.type.basic.BeanType.getMinOccurs(BeanType.java:775).
> 3. 2.2 Client: The client cannot send any method arguments (all methods receive null-valued arguments.
> 2.1 Service
> ----------------
> 1. 2.0 Client: The client throws a null-pointer exception when creating the Aegis databinding at org.apache.cxf.aegis.type.basic.BeanTypeInfo.getType(BeanTypeInfo.java:199).
> 2. 2.1 Client: The client throws a null-pointer exception when creating the Aegis databinding at org.apache.cxf.aegis.type.basic.BeanType.getMinOccurs(BeanType.java:775).
> 3. 2.2 Client: The client cannot send any method arguments (all methods receive null-valued arguments.
> 2.2 Service
> ----------------
> 1. 2.0 Client: The client throws a null-pointer exception when creating the Aegis databinding at org.apache.cxf.aegis.type.basic.BeanTypeInfo.getType(BeanTypeInfo.java:199).
> 2. 2.1 Client: The client throws a null-pointer exception when creating the Aegis databinding at org.apache.cxf.aegis.type.basic.BeanType.getMinOccurs(BeanType.java:775).
> 3. 2.2 Client: All tests pass.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (CXF-2546) NullPointerException when trying to find WS-Addressing Action

2009-12-15T12:28:18Z

[ https://issues.apache.org/jira/browse/CXF-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp reassigned CXF-2546:
--------------------------------

Assignee: Daniel Kulp

> NullPointerException when trying to find WS-Addressing Action
> -------------------------------------------------------------
>
> Key: CXF-2546
> URL: https://issues.apache.org/jira/browse/CXF-2546
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Affects Versions: 2.2.4
> Reporter: John Hite
> Assignee: Daniel Kulp
> Priority: Minor
> Attachments: WSAddressingSample.zip
>
>
> I have wsdl operations that look like this
> <wsdl:operation name="Ping">
> <wsdl:input wsam:Action="Test.Services/IProxyService/Ping" message="tns:IProxyService_Ping_InputMessage" />
> <wsdl:output wsam:Action="Test.Services/IProxyService/PingResponse" message="tns:IProxyService_Ping_OutputMessage" />
> </wsdl:operation>
> wsam=http://www.w3.org/2007/05/addressing/metadata
> If I try to run the client with this wsdl, I get a NullPointerException
> IProxyServiceClient:
> [java] Invoking ping...
> [java] Nov 17, 2009 4:15:58 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> [java] WARNING: Interceptor has thrown exception, unwinding now
> [java] java.lang.NullPointerException
> [java] at org.apache.cxf.ws.addressing.ContextUtils.getAction(ContextUtils.java:803)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.getActionFromInputMessage(MAPAggregator.java:438)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.getActionUri(MAPAggregator.java:521)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.assembleGeneric(MAPAggregator.java:427)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.aggregate(MAPAggregator.java:396)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.mediate(MAPAggregator.java:342)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.handleMessage(MAPAggregator.java:158)
> [java] at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
> [java] at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:478)
> [java] at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:308)
> [java] at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:260)
> [java] at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> [java] at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
> [java] at $Proxy39.ping(Unknown Source)
> [java] at services.test.IProxyService_CustomBindingIProxyService_Client.main(IProxyService_CustomBindingIProxyService_Client.java:56)
> [java] Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: Fault string, and possibly fault code, not set
> [java] at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146)
> [java] at $Proxy39.ping(Unknown Source)
> [java] at services.test.IProxyService_CustomBindingIProxyService_Client.main(IProxyService_CustomBindingIProxyService_Client.java:56)
> [java] Caused by: java.lang.NullPointerException
> [java] at org.apache.cxf.ws.addressing.ContextUtils.getAction(ContextUtils.java:803)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.getActionFromInputMessage(MAPAggregator.java:438)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.getActionUri(MAPAggregator.java:521)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.assembleGeneric(MAPAggregator.java:427)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.aggregate(MAPAggregator.java:396)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.mediate(MAPAggregator.java:342)
> [java] at org.apache.cxf.ws.addressing.MAPAggregator.handleMessage(MAPAggregator.java:158)
> [java] at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
> [java] at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:478)
> [java] at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:308)
> [java] at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:260)
> [java] at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> [java] at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
> [java] ... 2 more
> [java] Java Result: 1
> if I switch the namespace prefix of the actions to wsaw, where wsaw=http://www.w3.org/2006/05/addressing/wsdl, everything works.
> I'll upload a sample wsdl and ant build file. It will generate a client, server and ant file.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (CXF-2550) transactions don't work in jaxws Endpoint with jms transport

2009-12-15T11:33:18Z

[ https://issues.apache.org/jira/browse/CXF-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-2550.
------------------------------

Resolution: Fixed
Fix Version/s: 2.2.6
2.1.9

> transactions don't work in jaxws Endpoint with jms transport
> -------------------------------------------------------------
>
> Key: CXF-2550
> URL: https://issues.apache.org/jira/browse/CXF-2550
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 2.2.4, 2.2.5
> Reporter: javier
> Assignee: Daniel Kulp
> Fix For: 2.1.9, 2.2.6
>
> Attachments: jms_queue.zip
>
>
> i'm trying cxf with jms transport with transaction to process a message and it is dequeued when the implementor object throw an error .
> the message is inonly and the code is:
> EndpointImpl endpoint = new EndpointImpl(new ObjectImpl());
> endpoint.setAddress("jms://");
> ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory("tcp://localhost:61616");
> JMSConfiguration jmsConfig = new JMSConfiguration();
> jmsConfig.setConnectionFactory(connectionFactory);
> jmsConfig.setTargetDestination("sso2");
> jmsConfig.setSessionTransacted(true);
> jmsConfig.setPubSubDomain(false);
> jmsConfig.setUseJms11(true);
> jmsConfig.setTransactionManager(new JmsTransactionManager(connectionFactory));
> JMSConfigFeature jmsConfigFeature = new JMSConfigFeature();
> jmsConfigFeature.setJmsConfig(jmsConfig);
> endpoint.getFeatures().add(jmsConfigFeature);
> endpoint.publish();
> seems that the exception never arrive to AbstractMessageListenerContainer.doExecuteListener but it is catched inside

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.