Issues with Attachments: week of 2011-01-17
CXF - Monday, January 17, 2011 5 Issues with Attachments (sorted oldest to newest) [CXF-2775] CLONE -CXF http-jetty transport do not call the jetty server engine shutdown when the server stop - Created: 2010-04-21 - Updated: 2010-12-20 - Type: Bug - Fix Versions: [] - Reporter: Chris Wilson - Assigned: Willem Jiang - Attachments: [CxfServerRestartTimeoutTest.java] - https://issues.apache.org:443/jira/browse/CXF-2775 [CXF-3055] Adding appropriate switches to all command line tools - Created: 2010-10-08 - Updated: 2011-01-13 - Type: Improvement - Fix Versions: [] - Reporter: Robert Liguori - Assigned: Unassigned - Attachments: [usages_of_cxf_commands.doc] - https://issues.apache.org:443/jira/browse/CXF-3055 [CXF-3219] WS-RMs' DestinationSequence does not update the ack range in the RMStore - Created: 2010-12-25 - Updated: 2010-12-25 - Type: Bug - Fix Versions: [2.3.2] - Reporter: Aki Yoshida - Assigned: Unassigned - Attachments: [rt-ws-rm-2.3.x-fixes-diff.txt] - https://issues.apache.org:443/jira/browse/CXF-3219 [CXF-3236] Add support for an Issued Token extracted from a SAML assertion - Created: 2011-01-07 - Updated: 2011-01-07 - Type: Bug - Fix Versions: [2.3.2, 2.4] - Reporter: Colm O hEigeartaigh - Assigned: Colm O hEigeartaigh - Attachments: [cxf-3234-tentative.patch] - https://issues.apache.org:443/jira/browse/CXF-3236 [CXF-3245] Adding command line options where appropriate - Created: 2011-01-13 - Updated: 2011-01-13 - Type: Improvement - Fix Versions: [] - Reporter: Robert Liguori - Assigned: Unassigned - Attachments: [command+line+options+for+tooling.doc] - https://issues.apache.org:443/jira/browse/CXF-3245
[jira] Created: (CXF-3251) org.apache.cxf.ws.addressing.ContextUtils should support the
org.apache.cxf.ws.addressing.ContextUtils should support the - Key: CXF-3251 URL: https://issues.apache.org/jira/browse/CXF-3251 Project: CXF Issue Type: Bug Reporter: Willem Jiang -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-3252) org.apache.cxf.ws.addressing.ContextUtils.getAction should support to namespace "http://www.w3.org/2005/08/addressing"
[
https://issues.apache.org/jira/browse/CXF-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang updated CXF-3252:
--
Description:
Current CXF dosen't support the get the Address Action with the namespace "
http://www.w3.org/2005/08/addressing";,
You will get the NPE if the wsdl definition like this.
The test case can be ran successfully with JDK 1.6 's JAXWS implementation.
{code}
http://www.w3.org/2005/08/addressing";>
http://example.com/webservices/AccountStatusRequest";>
http://example.com/webservices/AccountStatusResponse"; />
{code}
The stack trace is with CXF 2.2.9, I can also reproduce the error with CXF
trunk code.
{code}
Caused by: java.lang.NullPointerException
at org.apache.cxf.ws.addressing.ContextUtils.getAction(ContextUtils.java:830)
at
org.apache.cxf.ws.addressing.ContextUtils.getActionFromMessageAttributes(ContextUtils.java:808)
at
org.apache.cxf.ws.addressing.ContextUtils.getActionFromServiceModel(ContextUtils.java:744)
at org.apache.cxf.ws.addressing.ContextUtils.getAction(ContextUtils.java:712)
at
org.apache.cxf.ws.addressing.MAPAggregator.assembleGeneric(MAPAggregator.java:511)
at org.apache.cxf.ws.addressing.MAPAggregator.aggregate(MAPAggregator.java:484)
at org.apache.cxf.ws.addressing.MAPAggregator.mediate(MAPAggregator.java:411)
at
org.apache.cxf.ws.addressing.MAPAggregator.handleMessage(MAPAggregator.java:166)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:487)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
... 25 more
{code}
was:
Current CXF dosen't support the get the Address Action with the namespace "
http://www.w3.org/2005/08/addressing";,
You will get the NPE if the wsdl definition like this.
The test case can be ran successfully with JDK 1.6 's JAXWS implementation.
{code}
http://www.w3.org/2005/08/addressing";>
http://example.com/webservices/AccountStatusRequest";>
http://example.com/webservices/AccountStatusResponse"; />
{code}
The stack trace is with CXF 2.2.9
{code}
Caused by: java.lang.NullPointerException
at org.apache.cxf.ws.addressing.ContextUtils.getAction(ContextUtils.java:830)
at
org.apache.cxf.ws.addressing.ContextUtils.getActionFromMessageAttributes(ContextUtils.java:808)
at
org.apache.cxf.ws.addressing.ContextUtils.getActionFromServiceModel(ContextUtils.java:744)
at org.apache.cxf.ws.addressing.ContextUtils.getAction(ContextUtils.java:712)
at
org.apache.cxf.ws.addressing.MAPAggregator.assembleGeneric(MAPAggregator.java:511)
at org.apache.cxf.ws.addressing.MAPAggregator.aggregate(MAPAggregator.java:484)
at org.apache.cxf.ws.addressing.MAPAggregator.mediate(MAPAggregator.java:411)
at
org.apache.cxf.ws.addressing.MAPAggregator.handleMessage(MAPAggregator.java:166)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:487)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
... 25 more
{code}
Fix Version/s: 2.4
> org.apache.cxf.ws.addressing.ContextUtils.getAction should support to
> namespace "http://www.w3.org/2005/08/addressing";
> ---
>
> Key: CXF-3252
> URL: https://issues.apache.org/jira/browse/CXF-3252
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.2.9, 2.1.10, 2.0.13, 2.2.10, 2.3.0, 2.2.11, 2.2.12,
> 2.3.1
>Reporter: Willem Jiang
>Assignee: Willem Jiang
> Fix For: 2.3.2, 2.2.13, 2.4
>
>
> Current CXF dosen't support the get the Address Action with the namespace "
> http://www.w3.org/2005/08/addressing";,
> You will get the NPE if the wsdl definition like this.
> The test case can be ran successfully with JDK 1.6 's JAXWS implementation.
> {code}
> xmlns:wsa="http://www.w3.org/2005/08/addressing";>
>
>
> wsa:Action="http://example.com/webservices/AccountStatusRequest";>
>
>
> wsa:Action="http://example.com/webservices/AccountStatusResponse"; />
>
>
> {code}
> The stack trace is with CXF 2.2.9, I can also reproduce the error with CXF
> t
[jira] Created: (CXF-3252) org.apache.cxf.ws.addressing.ContextUtils.getAction should support to namespace "http://www.w3.org/2005/08/addressing"
org.apache.cxf.ws.addressing.ContextUtils.getAction should support to namespace
"http://www.w3.org/2005/08/addressing";
---
Key: CXF-3252
URL: https://issues.apache.org/jira/browse/CXF-3252
Project: CXF
Issue Type: Bug
Affects Versions: 2.3.1, 2.2.12, 2.2.11, 2.3.0, 2.2.10, 2.0.13, 2.1.10,
2.2.9
Reporter: Willem Jiang
Assignee: Willem Jiang
Fix For: 2.3.2, 2.2.13
Current CXF dosen't support the get the Address Action with the namespace "
http://www.w3.org/2005/08/addressing";,
You will get the NPE if the wsdl definition like this.
The test case can be ran successfully with JDK 1.6 's JAXWS implementation.
{code}
http://www.w3.org/2005/08/addressing";>
http://example.com/webservices/AccountStatusRequest";>
http://example.com/webservices/AccountStatusResponse"; />
{code}
The stack trace is with CXF 2.2.9
{code}
Caused by: java.lang.NullPointerException
at org.apache.cxf.ws.addressing.ContextUtils.getAction(ContextUtils.java:830)
at
org.apache.cxf.ws.addressing.ContextUtils.getActionFromMessageAttributes(ContextUtils.java:808)
at
org.apache.cxf.ws.addressing.ContextUtils.getActionFromServiceModel(ContextUtils.java:744)
at org.apache.cxf.ws.addressing.ContextUtils.getAction(ContextUtils.java:712)
at
org.apache.cxf.ws.addressing.MAPAggregator.assembleGeneric(MAPAggregator.java:511)
at org.apache.cxf.ws.addressing.MAPAggregator.aggregate(MAPAggregator.java:484)
at org.apache.cxf.ws.addressing.MAPAggregator.mediate(MAPAggregator.java:411)
at
org.apache.cxf.ws.addressing.MAPAggregator.handleMessage(MAPAggregator.java:166)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:487)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
... 25 more
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-3230) CXF over JMS leaks JMS resources when no replay queue is specified
[ https://issues.apache.org/jira/browse/CXF-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982528#action_12982528 ] Kjell Winblad commented on CXF-3230: I use the default settings for HornetQ 2.1.2. The example I used is the same as the one I have attached to this bug with the difference that the address tag in the WSDL is replaced with the following: http://cxf.apache.org/transports/jms";> I will try to learn maven before I send another bug report. > CXF over JMS leaks JMS resources when no replay queue is specified > --- > > Key: CXF-3230 > URL: https://issues.apache.org/jira/browse/CXF-3230 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 2.3.1 > Environment: Linux, ActiveMQ 5.4.2 and HornetQ 2.1.2 >Reporter: Kjell Winblad >Assignee: Christian Schneider >Priority: Blocker > Fix For: 2.3.2 > > Attachments: CXF-3230.patch, CXFJMSResourceLeaking.tar.gz > > > This issue was found both when testing with ActiveMQ 5.4.2 and HornetQ 2.1.2 > as JMS provider. The JMS settings is set in the WSDL file: > > > > jndiConnectionFactoryName="ConnectionFactory" > > jndiDestinationName="dynamicQueues/messageDestination" > > xmlns="http://cxf.apache.org/transports/jms";> >name="java.naming.provider.url" > value="tcp://localhost:61616?jms.watchTopicAdvisories=false"/> >name="java.naming.factory.initial" > value="org.apache.activemq.jndi.ActiveMQInitialContextFactory"/> > > > > The issue was found when performing a test with a server and a client both > created with CXF. The client has an infinite loop that performs a request on > the server and waits for a response before the next iteration is executed. > After a couple of thousands of request response iterations have been > performed the JMS provider starts to get very slow and ActiveMQ gets out of > memory if the test is run long enough. First I thought it was a configuration > problem with the JMS provider or a bug in ActiveMQ, but because the same > problem exists both with HornetQ and several configurations of ActiveMQ it > seems like it is a problem with CXF. > When monitoring ActiveMQ with jconsole it can be seen that when ActiveMQ is > set to not use a thread pool > (-Dorg.apache.activemq.UseDedicatedTaskRunner=true), the number of threads > grows while the test is running and no threads seem to be deallocated. When a > thread pool is used the number of threads is quite constant but the amount of > memory on the heap still grows. No leak is observed when a response queue is > specified with jndiReplyDestinationName. So when a temporary queue should be > used to send back the replay it seems like one replay queue is created for > every replay and they never get removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-3252) org.apache.cxf.ws.addressing.ContextUtils.getAction should support namespace "http://www.w3.org/2005/08/addressing"
[
https://issues.apache.org/jira/browse/CXF-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang updated CXF-3252:
--
Summary: org.apache.cxf.ws.addressing.ContextUtils.getAction should support
namespace "http://www.w3.org/2005/08/addressing"; (was:
org.apache.cxf.ws.addressing.ContextUtils.getAction should support to namespace
"http://www.w3.org/2005/08/addressing"; )
> org.apache.cxf.ws.addressing.ContextUtils.getAction should support namespace
> "http://www.w3.org/2005/08/addressing";
>
>
> Key: CXF-3252
> URL: https://issues.apache.org/jira/browse/CXF-3252
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.2.9, 2.1.10, 2.0.13, 2.2.10, 2.3.0, 2.2.11, 2.2.12,
> 2.3.1
>Reporter: Willem Jiang
>Assignee: Willem Jiang
> Fix For: 2.3.2, 2.2.13, 2.4
>
>
> Current CXF dosen't support the get the Address Action with the namespace "
> http://www.w3.org/2005/08/addressing";,
> You will get the NPE if the wsdl definition like this.
> The test case can be ran successfully with JDK 1.6 's JAXWS implementation.
> {code}
> xmlns:wsa="http://www.w3.org/2005/08/addressing";>
>
>
> wsa:Action="http://example.com/webservices/AccountStatusRequest";>
>
>
> wsa:Action="http://example.com/webservices/AccountStatusResponse"; />
>
>
> {code}
> The stack trace is with CXF 2.2.9, I can also reproduce the error with CXF
> trunk code.
> {code}
> Caused by: java.lang.NullPointerException
> at org.apache.cxf.ws.addressing.ContextUtils.getAction(ContextUtils.java:830)
> at
> org.apache.cxf.ws.addressing.ContextUtils.getActionFromMessageAttributes(ContextUtils.java:808)
> at
> org.apache.cxf.ws.addressing.ContextUtils.getActionFromServiceModel(ContextUtils.java:744)
> at org.apache.cxf.ws.addressing.ContextUtils.getAction(ContextUtils.java:712)
> at
> org.apache.cxf.ws.addressing.MAPAggregator.assembleGeneric(MAPAggregator.java:511)
> at
> org.apache.cxf.ws.addressing.MAPAggregator.aggregate(MAPAggregator.java:484)
> at org.apache.cxf.ws.addressing.MAPAggregator.mediate(MAPAggregator.java:411)
> at
> org.apache.cxf.ws.addressing.MAPAggregator.handleMessage(MAPAggregator.java:166)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:487)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
> ... 25 more
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3252) org.apache.cxf.ws.addressing.ContextUtils.getAction should support namespace "http://www.w3.org/2005/08/addressing"
[
https://issues.apache.org/jira/browse/CXF-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang resolved CXF-3252.
---
Resolution: Fixed
> org.apache.cxf.ws.addressing.ContextUtils.getAction should support namespace
> "http://www.w3.org/2005/08/addressing";
>
>
> Key: CXF-3252
> URL: https://issues.apache.org/jira/browse/CXF-3252
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.2.9, 2.1.10, 2.0.13, 2.2.10, 2.3.0, 2.2.11, 2.2.12,
> 2.3.1
>Reporter: Willem Jiang
>Assignee: Willem Jiang
> Fix For: 2.3.2, 2.2.13, 2.4
>
>
> Current CXF dosen't support the get the Address Action with the namespace "
> http://www.w3.org/2005/08/addressing";,
> You will get the NPE if the wsdl definition like this.
> The test case can be ran successfully with JDK 1.6 's JAXWS implementation.
> {code}
> xmlns:wsa="http://www.w3.org/2005/08/addressing";>
>
>
> wsa:Action="http://example.com/webservices/AccountStatusRequest";>
>
>
> wsa:Action="http://example.com/webservices/AccountStatusResponse"; />
>
>
> {code}
> The stack trace is with CXF 2.2.9, I can also reproduce the error with CXF
> trunk code.
> {code}
> Caused by: java.lang.NullPointerException
> at org.apache.cxf.ws.addressing.ContextUtils.getAction(ContextUtils.java:830)
> at
> org.apache.cxf.ws.addressing.ContextUtils.getActionFromMessageAttributes(ContextUtils.java:808)
> at
> org.apache.cxf.ws.addressing.ContextUtils.getActionFromServiceModel(ContextUtils.java:744)
> at org.apache.cxf.ws.addressing.ContextUtils.getAction(ContextUtils.java:712)
> at
> org.apache.cxf.ws.addressing.MAPAggregator.assembleGeneric(MAPAggregator.java:511)
> at
> org.apache.cxf.ws.addressing.MAPAggregator.aggregate(MAPAggregator.java:484)
> at org.apache.cxf.ws.addressing.MAPAggregator.mediate(MAPAggregator.java:411)
> at
> org.apache.cxf.ws.addressing.MAPAggregator.handleMessage(MAPAggregator.java:166)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:487)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
> ... 25 more
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-3249) When accessing a service that requires auth CXF returns: RuntimeException: Can't find input stream in message
[
https://issues.apache.org/jira/browse/CXF-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982603#action_12982603
]
Sergey Beryozkin commented on CXF-3249:
---
Hi Christian
One minor comment is that having a 500 status does not guarantee that it is a
valid SOAP fault response, but this probably indicates the server is in a
pretty bad state.
The other comment is that you may still want to wrap a CXF specific HTTP
exception into a javax one you spotted on Friday somewhere at the JAX-WS level
(in-fault interceptor comes to mind), this would make the JAX-WS client code
portable and it will also let us experiment going forward with different
approaches.
For example, the reason the JAX-RS client runtime 'disables' the exceptions at
the HTTPConduit level is that noisy log messages are being generated and if we
have a client code catching (JAX-RS) WebApplicationExceptions or checking
explicit (JAX-RS) Responses and doing some logging of it own then the logging
becomes too visible... Disabling logging at the transport level is not possible
because we may have some genuine IO exceptions like timeout, etc, but choosing
to deal with 400+ statuses at the higher level is a possibility
thanks, Sergey
> When accessing a service that requires auth CXF returns: RuntimeException:
> Can't find input stream in message
> -
>
> Key: CXF-3249
> URL: https://issues.apache.org/jira/browse/CXF-3249
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 2.3.1
>Reporter: Christian Schneider
>Assignee: Christian Schneider
> Fix For: 2.3.2
>
>
> I try to access a service that requires basic auth. My request does not
> include credentials. I would expect CXF to return something like
> 401 Authentication required. But it returns the following exception:
> WARNUNG: Interceptor for
> {http://customerservice.example.com/}CustomerServiceService#{http://customerservice.example.com/}getCustomersByName
> has thrown exception, unwinding now
> java.lang.RuntimeException: Can't find input stream in message
> at
> org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:116)
> at
> org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:60)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:755)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2330)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2192)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:2036)
> at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:696)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:516)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
> at $Proxy30.getCustomersByName(Unknown Source)
> at client.JaxWsClient.main(JaxWsClient.java:24)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3145) Refactor toSQL method as visitor pattern
[ https://issues.apache.org/jira/browse/CXF-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-3145. --- Resolution: Fixed Fix Version/s: 2.4 Assignee: Sergey Beryozkin Hi Brian - I've finally managed to look at this issue. I've committed the patch with few minor changes. http://svn.apache.org/viewvc?rev=1059923&view=rev This is a breaking change so it will be limited to 2.4.0. Thanks > Refactor toSQL method as visitor pattern > > > Key: CXF-3145 > URL: https://issues.apache.org/jira/browse/CXF-3145 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 2.3.0 >Reporter: Brian Topping >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 2.4 > > Attachments: cxf3145.patch > > > In doing some work with the FIQL parser, I needed to generate a different > output than SQL. By using a visitor pattern for rendering the SQL, any > visitor can be applied to the SearchCondition object graph. > The attached patch provides that refactoring. > As a part of that, SearchCondition.toSql() is deprecated, but I maintained > the interface for maximum compatibility. > There was also a change to SearchCondition.getSearchConditions(). There were > no callers to that code except test code, and it was set up to return null if > there was only one condition. That wasn't clear to me, hopefully that change > is not unreasonable. > This may not be formatted properly, please adjust to suit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CXF-3248) CXF JAX-RS assumes custom Application returns providers only via Application.getSingletons
[
https://issues.apache.org/jira/browse/CXF-3248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin reassigned CXF-3248:
-
Assignee: Sergey Beryozkin
> CXF JAX-RS assumes custom Application returns providers only via
> Application.getSingletons
> ---
>
> Key: CXF-3248
> URL: https://issues.apache.org/jira/browse/CXF-3248
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.3.2
>Reporter: Glen Mazza
>Assignee: Sergey Beryozkin
>Priority: Minor
>
> Example 7-1 of the JAX-RS book samples (see
> https://issues.apache.org/jira/browse/CXF-3247) is returning a unclear error
> message when it processes the following ExceptionMapper:
> @Provider
> public class NotFoundExceptionMapper implements
> ExceptionMapper
> {
>public Response toResponse(NotFoundException exception)
>{
> return Response.status(Response.Status.NOT_FOUND)
> .entity(exception.getMessage())
> .type("text/plain").build();
>}
> }
> This is the error message it's returning:
> WARNING: No resource methods have been found for resource class
> com.restfully.shop.services.NotFoundExceptionMapper
> I'm not sure why an exception mapper needs to have resource methods, or what
> a "resource method" is for that matter. I think this error is appropriate
> for root resources only and not exception mappers, if so, this message should
> be suppressed for exception mappers. OTOH, if this warning does have meaning
> for exception mappers, could it be made clearer for newbies/novices?
> Note this example has other bugs with it, not related to this problem
> (https://issues.jboss.org/browse/RESTEASY-495).
> To duplicate, download and extract RESTEasy and make the pom.xml and web.xml
> changes all described in https://issues.apache.org/jira/browse/CXF-3247.
> Then just run mvn clean install and you'll see the above error message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (CXF-3230) CXF over JMS leaks JMS resources when no replay queue is specified
[ https://issues.apache.org/jira/browse/CXF-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reopened CXF-3230: -- I reopen the issue to check with hornetq. The fix for activemq is in trunk and will go into 2.3.2 > CXF over JMS leaks JMS resources when no replay queue is specified > --- > > Key: CXF-3230 > URL: https://issues.apache.org/jira/browse/CXF-3230 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 2.3.1 > Environment: Linux, ActiveMQ 5.4.2 and HornetQ 2.1.2 >Reporter: Kjell Winblad >Assignee: Christian Schneider >Priority: Blocker > Fix For: 2.3.2 > > Attachments: CXF-3230.patch, CXFJMSResourceLeaking.tar.gz > > > This issue was found both when testing with ActiveMQ 5.4.2 and HornetQ 2.1.2 > as JMS provider. The JMS settings is set in the WSDL file: > > > > jndiConnectionFactoryName="ConnectionFactory" > > jndiDestinationName="dynamicQueues/messageDestination" > > xmlns="http://cxf.apache.org/transports/jms";> >name="java.naming.provider.url" > value="tcp://localhost:61616?jms.watchTopicAdvisories=false"/> >name="java.naming.factory.initial" > value="org.apache.activemq.jndi.ActiveMQInitialContextFactory"/> > > > > The issue was found when performing a test with a server and a client both > created with CXF. The client has an infinite loop that performs a request on > the server and waits for a response before the next iteration is executed. > After a couple of thousands of request response iterations have been > performed the JMS provider starts to get very slow and ActiveMQ gets out of > memory if the test is run long enough. First I thought it was a configuration > problem with the JMS provider or a bug in ActiveMQ, but because the same > problem exists both with HornetQ and several configurations of ActiveMQ it > seems like it is a problem with CXF. > When monitoring ActiveMQ with jconsole it can be seen that when ActiveMQ is > set to not use a thread pool > (-Dorg.apache.activemq.UseDedicatedTaskRunner=true), the number of threads > grows while the test is running and no threads seem to be deallocated. When a > thread pool is used the number of threads is quite constant but the amount of > memory on the heap still grows. No leak is observed when a response queue is > specified with jndiReplyDestinationName. So when a temporary queue should be > used to send back the replay it seems like one replay queue is created for > every replay and they never get removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-3230) CXF over JMS leaks JMS resources when no replay queue is specified
[ https://issues.apache.org/jira/browse/CXF-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated CXF-3230: - Fix Version/s: (was: 2.3.2) 2.3.3 > CXF over JMS leaks JMS resources when no replay queue is specified > --- > > Key: CXF-3230 > URL: https://issues.apache.org/jira/browse/CXF-3230 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 2.3.1 > Environment: Linux, ActiveMQ 5.4.2 and HornetQ 2.1.2 >Reporter: Kjell Winblad >Assignee: Christian Schneider >Priority: Blocker > Fix For: 2.3.3 > > Attachments: CXF-3230.patch, CXFJMSResourceLeaking.tar.gz > > > This issue was found both when testing with ActiveMQ 5.4.2 and HornetQ 2.1.2 > as JMS provider. The JMS settings is set in the WSDL file: > > > > jndiConnectionFactoryName="ConnectionFactory" > > jndiDestinationName="dynamicQueues/messageDestination" > > xmlns="http://cxf.apache.org/transports/jms";> >name="java.naming.provider.url" > value="tcp://localhost:61616?jms.watchTopicAdvisories=false"/> >name="java.naming.factory.initial" > value="org.apache.activemq.jndi.ActiveMQInitialContextFactory"/> > > > > The issue was found when performing a test with a server and a client both > created with CXF. The client has an infinite loop that performs a request on > the server and waits for a response before the next iteration is executed. > After a couple of thousands of request response iterations have been > performed the JMS provider starts to get very slow and ActiveMQ gets out of > memory if the test is run long enough. First I thought it was a configuration > problem with the JMS provider or a bug in ActiveMQ, but because the same > problem exists both with HornetQ and several configurations of ActiveMQ it > seems like it is a problem with CXF. > When monitoring ActiveMQ with jconsole it can be seen that when ActiveMQ is > set to not use a thread pool > (-Dorg.apache.activemq.UseDedicatedTaskRunner=true), the number of threads > grows while the test is running and no threads seem to be deallocated. When a > thread pool is used the number of threads is quite constant but the amount of > memory on the heap still grows. No leak is observed when a response queue is > specified with jndiReplyDestinationName. So when a temporary queue should be > used to send back the replay it seems like one replay queue is created for > every replay and they never get removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3248) CXF JAX-RS assumes custom Application returns providers only via Application.getSingletons
[
https://issues.apache.org/jira/browse/CXF-3248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-3248.
---
Resolution: Fixed
Fix Version/s: 2.4
2.3.2
> CXF JAX-RS assumes custom Application returns providers only via
> Application.getSingletons
> ---
>
> Key: CXF-3248
> URL: https://issues.apache.org/jira/browse/CXF-3248
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.3.2
>Reporter: Glen Mazza
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 2.3.2, 2.4
>
>
> Example 7-1 of the JAX-RS book samples (see
> https://issues.apache.org/jira/browse/CXF-3247) is returning a unclear error
> message when it processes the following ExceptionMapper:
> @Provider
> public class NotFoundExceptionMapper implements
> ExceptionMapper
> {
>public Response toResponse(NotFoundException exception)
>{
> return Response.status(Response.Status.NOT_FOUND)
> .entity(exception.getMessage())
> .type("text/plain").build();
>}
> }
> This is the error message it's returning:
> WARNING: No resource methods have been found for resource class
> com.restfully.shop.services.NotFoundExceptionMapper
> I'm not sure why an exception mapper needs to have resource methods, or what
> a "resource method" is for that matter. I think this error is appropriate
> for root resources only and not exception mappers, if so, this message should
> be suppressed for exception mappers. OTOH, if this warning does have meaning
> for exception mappers, could it be made clearer for newbies/novices?
> Note this example has other bugs with it, not related to this problem
> (https://issues.jboss.org/browse/RESTEASY-495).
> To duplicate, download and extract RESTEasy and make the pom.xml and web.xml
> changes all described in https://issues.apache.org/jira/browse/CXF-3247.
> Then just run mvn clean install and you'll see the above error message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-3230) CXF over JMS leaks JMS resources when no replay queue is specified
[ https://issues.apache.org/jira/browse/CXF-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982698#action_12982698 ] Christian Schneider commented on CXF-3230: -- Don´t let maven keep you from reporting bugs. It just makes life a little easier for us. I will also help you without an easy test. It is only that the easier you make it for the people that have to solve the problem the faster things get solved usually ;-) At least this is what I experienced when reporting bugs myself. The nice thing when I have a maven project is that I can simply import it in eclipse and get all dependencies (with the sonatype eclipse maven plugin). So I can simply start debugging. The plugin even downloads and attaches the source for all dependencies. If you want to look into maven projects you best start with the examples from the cxf distribution. > CXF over JMS leaks JMS resources when no replay queue is specified > --- > > Key: CXF-3230 > URL: https://issues.apache.org/jira/browse/CXF-3230 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 2.3.1 > Environment: Linux, ActiveMQ 5.4.2 and HornetQ 2.1.2 >Reporter: Kjell Winblad >Assignee: Christian Schneider >Priority: Blocker > Fix For: 2.3.3 > > Attachments: CXF-3230.patch, CXFJMSResourceLeaking.tar.gz > > > This issue was found both when testing with ActiveMQ 5.4.2 and HornetQ 2.1.2 > as JMS provider. The JMS settings is set in the WSDL file: > > > > jndiConnectionFactoryName="ConnectionFactory" > > jndiDestinationName="dynamicQueues/messageDestination" > > xmlns="http://cxf.apache.org/transports/jms";> >name="java.naming.provider.url" > value="tcp://localhost:61616?jms.watchTopicAdvisories=false"/> >name="java.naming.factory.initial" > value="org.apache.activemq.jndi.ActiveMQInitialContextFactory"/> > > > > The issue was found when performing a test with a server and a client both > created with CXF. The client has an infinite loop that performs a request on > the server and waits for a response before the next iteration is executed. > After a couple of thousands of request response iterations have been > performed the JMS provider starts to get very slow and ActiveMQ gets out of > memory if the test is run long enough. First I thought it was a configuration > problem with the JMS provider or a bug in ActiveMQ, but because the same > problem exists both with HornetQ and several configurations of ActiveMQ it > seems like it is a problem with CXF. > When monitoring ActiveMQ with jconsole it can be seen that when ActiveMQ is > set to not use a thread pool > (-Dorg.apache.activemq.UseDedicatedTaskRunner=true), the number of threads > grows while the test is running and no threads seem to be deallocated. When a > thread pool is used the number of threads is quite constant but the amount of > memory on the heap still grows. No leak is observed when a response queue is > specified with jndiReplyDestinationName. So when a temporary queue should be > used to send back the replay it seems like one replay queue is created for > every replay and they never get removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (CXF-3248) CXF JAX-RS assumes custom Application returns providers only via Application.getSingletons
[
https://issues.apache.org/jira/browse/CXF-3248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin reopened CXF-3248:
---
> CXF JAX-RS assumes custom Application returns providers only via
> Application.getSingletons
> ---
>
> Key: CXF-3248
> URL: https://issues.apache.org/jira/browse/CXF-3248
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.3.2
>Reporter: Glen Mazza
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 2.3.2, 2.4
>
>
> Example 7-1 of the JAX-RS book samples (see
> https://issues.apache.org/jira/browse/CXF-3247) is returning a unclear error
> message when it processes the following ExceptionMapper:
> @Provider
> public class NotFoundExceptionMapper implements
> ExceptionMapper
> {
>public Response toResponse(NotFoundException exception)
>{
> return Response.status(Response.Status.NOT_FOUND)
> .entity(exception.getMessage())
> .type("text/plain").build();
>}
> }
> This is the error message it's returning:
> WARNING: No resource methods have been found for resource class
> com.restfully.shop.services.NotFoundExceptionMapper
> I'm not sure why an exception mapper needs to have resource methods, or what
> a "resource method" is for that matter. I think this error is appropriate
> for root resources only and not exception mappers, if so, this message should
> be suppressed for exception mappers. OTOH, if this warning does have meaning
> for exception mappers, could it be made clearer for newbies/novices?
> Note this example has other bugs with it, not related to this problem
> (https://issues.jboss.org/browse/RESTEASY-495).
> To duplicate, download and extract RESTEasy and make the pom.xml and web.xml
> changes all described in https://issues.apache.org/jira/browse/CXF-3247.
> Then just run mvn clean install and you'll see the above error message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-3248) CXF JAX-RS assumes custom Application returns providers only via Application.getSingletons
[
https://issues.apache.org/jira/browse/CXF-3248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin closed CXF-3248.
-
Resolution: Fixed
Reopened the wrong issue
> CXF JAX-RS assumes custom Application returns providers only via
> Application.getSingletons
> ---
>
> Key: CXF-3248
> URL: https://issues.apache.org/jira/browse/CXF-3248
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.3.2
>Reporter: Glen Mazza
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 2.3.2, 2.4
>
>
> Example 7-1 of the JAX-RS book samples (see
> https://issues.apache.org/jira/browse/CXF-3247) is returning a unclear error
> message when it processes the following ExceptionMapper:
> @Provider
> public class NotFoundExceptionMapper implements
> ExceptionMapper
> {
>public Response toResponse(NotFoundException exception)
>{
> return Response.status(Response.Status.NOT_FOUND)
> .entity(exception.getMessage())
> .type("text/plain").build();
>}
> }
> This is the error message it's returning:
> WARNING: No resource methods have been found for resource class
> com.restfully.shop.services.NotFoundExceptionMapper
> I'm not sure why an exception mapper needs to have resource methods, or what
> a "resource method" is for that matter. I think this error is appropriate
> for root resources only and not exception mappers, if so, this message should
> be suppressed for exception mappers. OTOH, if this warning does have meaning
> for exception mappers, could it be made clearer for newbies/novices?
> Note this example has other bugs with it, not related to this problem
> (https://issues.jboss.org/browse/RESTEASY-495).
> To duplicate, download and extract RESTEasy and make the pom.xml and web.xml
> changes all described in https://issues.apache.org/jira/browse/CXF-3247.
> Then just run mvn clean install and you'll see the above error message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (CXF-3247) RESTEasy example involving MessageBodyReader/MessageBodyWriter creation not working with CXF's JAX-RS implementation
[
https://issues.apache.org/jira/browse/CXF-3247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin reopened CXF-3247:
---
Assignee: Sergey Beryozkin
> RESTEasy example involving MessageBodyReader/MessageBodyWriter creation not
> working with CXF's JAX-RS implementation
>
>
> Key: CXF-3247
> URL: https://issues.apache.org/jira/browse/CXF-3247
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.3.2
>Reporter: Glen Mazza
>Assignee: Sergey Beryozkin
>
> Chapter 19, Example 6_02 (page 230) from Bill Burke's RESTful Java with
> JAX-RS book is working with RESTEasy but not CXF (I'm using 2.3.2-SNAPSHOT).
> This example is freely available in the RESTEasy download[1].
> This example creates a new MessageBodyReader and MessageBodyWriter for
> exchanging Java objects directly using REST.
> Steps to duplicate:
> 1.) After downloading and extracting RESTEasy and navigating to this folder:
> resteasy-jaxrs-2.1.0.GA/examples/oreilly-workbook/ex06_2 , type mvn clean
> install. You'll see a before/after response using the RESTEasy library:
> ---
> T E S T S
> ---
> Running com.restfully.shop.test.CustomerResourceTest
> *** Create a new Customer ***
> 15.01.2011 17:21:14 org.jboss.resteasy.spi.ResteasyDeployment
> INFO: Deploying javax.ws.rs.core.Application: class
> com.restfully.shop.services.ShoppingApplication
> 15.01.2011 17:21:14 org.jboss.resteasy.spi.ResteasyDeployment
> INFO: Adding singleton resource com.restfully.shop.services.CustomerResource
> from Application javax.ws.rs.core.Application
> Created customer 1
> Location: http://localhost:9095/customers/1
> *** GET Created Customer **
> Content-Type: application/x-java-serialized-object
> Customer{id=1, firstName='Bill', lastName='Burke', street='256 Clarendon
> Street', city='Boston', state='MA', zip='02115', country='USA'}
> After Update ***
> Content-Type: application/x-java-serialized-object
> Customer{id=1, firstName='William', lastName='Burke', street='256 Clarendon
> Street', city='Boston', state='MA', zip='02115', country='USA'}
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.344 sec
> 2.) Convert the sample to using CXF's version of JAX-RS by making the
> following two changes (I've used these two steps with success in nearly all
> the other examples up to this one):
> -- Switching the servlet in the web.xml:
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> -- Switching the dependency in the pom.xml:
>
> org.apache.cxf
> cxf-rt-frontend-jaxrs
> 2.3.2-SNAPSHOT
>
>
> 3.) Running mvn clean install again will return this error:
> ---
> T E S T S
> ---
> Running com.restfully.shop.test.CustomerResourceTest
> *** Create a new Customer ***
> 15.01.2011 17:22:52 org.apache.cxf.transport.servlet.CXFNonSpringServlet
> loadBusNoConfig
> INFO: Load the bus without application context
> 15.01.2011 17:22:52
> org.springframework.context.support.AbstractApplicationContext prepareRefresh
> INFO: Refreshing org.apache.cxf.bus.spring.BusApplicationContext@23b561a2:
> startup date [Sat Jan 15 17:22:52 EST 2011]; root of context hierarchy
> 15.01.2011 17:22:52
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource
> [META-INF/cxf/cxf.xml]
> 15.01.2011 17:22:52
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource
> [META-INF/cxf/cxf-extension-jaxrs-binding.xml]
> 15.01.2011 17:22:52
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource
> [META-INF/cxf/cxf-extension-xml.xml]
> 15.01.2011 17:22:52
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource
> [META-INF/cxf/cxf-extension-http.xml]
> 15.01.2011 17:22:52
> org.springframework.beans.factory.support.DefaultListableBeanFactory
> preInstantiateSingletons
> INFO: Pre-instantiating singletons in
> org.springframework.beans.factory.support.DefaultListableBeanFactory@2f78743b:
> defining beans
> [cxf,org.apache.cxf.bus.spring.BusApplicationListener,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExten
[jira] Updated: (CXF-3247) CXF JAX-RS does not recognize MessageBodyReader/MessageBodyWriter with no generic parameters
[
https://issues.apache.org/jira/browse/CXF-3247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin updated CXF-3247:
--
Priority: Critical (was: Major)
Affects Version/s: (was: 2.3.2)
2.3.1
Fix Version/s: 2.4
2.3.2
Summary: CXF JAX-RS does not recognize
MessageBodyReader/MessageBodyWriter with no generic parameters (was: RESTEasy
example involving MessageBodyReader/MessageBodyWriter creation not working with
CXF's JAX-RS implementation)
> CXF JAX-RS does not recognize MessageBodyReader/MessageBodyWriter with no
> generic parameters
>
>
> Key: CXF-3247
> URL: https://issues.apache.org/jira/browse/CXF-3247
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.3.1
>Reporter: Glen Mazza
>Assignee: Sergey Beryozkin
>Priority: Critical
> Fix For: 2.3.2, 2.4
>
>
> Chapter 19, Example 6_02 (page 230) from Bill Burke's RESTful Java with
> JAX-RS book is working with RESTEasy but not CXF (I'm using 2.3.2-SNAPSHOT).
> This example is freely available in the RESTEasy download[1].
> This example creates a new MessageBodyReader and MessageBodyWriter for
> exchanging Java objects directly using REST.
> Steps to duplicate:
> 1.) After downloading and extracting RESTEasy and navigating to this folder:
> resteasy-jaxrs-2.1.0.GA/examples/oreilly-workbook/ex06_2 , type mvn clean
> install. You'll see a before/after response using the RESTEasy library:
> ---
> T E S T S
> ---
> Running com.restfully.shop.test.CustomerResourceTest
> *** Create a new Customer ***
> 15.01.2011 17:21:14 org.jboss.resteasy.spi.ResteasyDeployment
> INFO: Deploying javax.ws.rs.core.Application: class
> com.restfully.shop.services.ShoppingApplication
> 15.01.2011 17:21:14 org.jboss.resteasy.spi.ResteasyDeployment
> INFO: Adding singleton resource com.restfully.shop.services.CustomerResource
> from Application javax.ws.rs.core.Application
> Created customer 1
> Location: http://localhost:9095/customers/1
> *** GET Created Customer **
> Content-Type: application/x-java-serialized-object
> Customer{id=1, firstName='Bill', lastName='Burke', street='256 Clarendon
> Street', city='Boston', state='MA', zip='02115', country='USA'}
> After Update ***
> Content-Type: application/x-java-serialized-object
> Customer{id=1, firstName='William', lastName='Burke', street='256 Clarendon
> Street', city='Boston', state='MA', zip='02115', country='USA'}
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.344 sec
> 2.) Convert the sample to using CXF's version of JAX-RS by making the
> following two changes (I've used these two steps with success in nearly all
> the other examples up to this one):
> -- Switching the servlet in the web.xml:
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> -- Switching the dependency in the pom.xml:
>
> org.apache.cxf
> cxf-rt-frontend-jaxrs
> 2.3.2-SNAPSHOT
>
>
> 3.) Running mvn clean install again will return this error:
> ---
> T E S T S
> ---
> Running com.restfully.shop.test.CustomerResourceTest
> *** Create a new Customer ***
> 15.01.2011 17:22:52 org.apache.cxf.transport.servlet.CXFNonSpringServlet
> loadBusNoConfig
> INFO: Load the bus without application context
> 15.01.2011 17:22:52
> org.springframework.context.support.AbstractApplicationContext prepareRefresh
> INFO: Refreshing org.apache.cxf.bus.spring.BusApplicationContext@23b561a2:
> startup date [Sat Jan 15 17:22:52 EST 2011]; root of context hierarchy
> 15.01.2011 17:22:52
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource
> [META-INF/cxf/cxf.xml]
> 15.01.2011 17:22:52
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource
> [META-INF/cxf/cxf-extension-jaxrs-binding.xml]
> 15.01.2011 17:22:52
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource
> [META-INF/cxf/cxf-extension-xml.xml]
> 15.01.2011 17:22:52
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource
> [META-INF/cxf/cxf-extension-http.xml]
> 15.01.2011 17:22:52
> org.springframework.beans.factory.supp
[jira] Resolved: (CXF-3248) CXF JAX-RS assumes custom Application returns providers only via Application.getSingletons
[
https://issues.apache.org/jira/browse/CXF-3248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-3248.
---
Resolution: Fixed
> CXF JAX-RS assumes custom Application returns providers only via
> Application.getSingletons
> ---
>
> Key: CXF-3248
> URL: https://issues.apache.org/jira/browse/CXF-3248
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.3.2
>Reporter: Glen Mazza
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 2.3.2, 2.4
>
>
> Example 7-1 of the JAX-RS book samples (see
> https://issues.apache.org/jira/browse/CXF-3247) is returning a unclear error
> message when it processes the following ExceptionMapper:
> @Provider
> public class NotFoundExceptionMapper implements
> ExceptionMapper
> {
>public Response toResponse(NotFoundException exception)
>{
> return Response.status(Response.Status.NOT_FOUND)
> .entity(exception.getMessage())
> .type("text/plain").build();
>}
> }
> This is the error message it's returning:
> WARNING: No resource methods have been found for resource class
> com.restfully.shop.services.NotFoundExceptionMapper
> I'm not sure why an exception mapper needs to have resource methods, or what
> a "resource method" is for that matter. I think this error is appropriate
> for root resources only and not exception mappers, if so, this message should
> be suppressed for exception mappers. OTOH, if this warning does have meaning
> for exception mappers, could it be made clearer for newbies/novices?
> Note this example has other bugs with it, not related to this problem
> (https://issues.jboss.org/browse/RESTEASY-495).
> To duplicate, download and extract RESTEasy and make the pom.xml and web.xml
> changes all described in https://issues.apache.org/jira/browse/CXF-3247.
> Then just run mvn clean install and you'll see the above error message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (CXF-3248) CXF JAX-RS assumes custom Application returns providers only via Application.getSingletons
[
https://issues.apache.org/jira/browse/CXF-3248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin reopened CXF-3248:
---
> CXF JAX-RS assumes custom Application returns providers only via
> Application.getSingletons
> ---
>
> Key: CXF-3248
> URL: https://issues.apache.org/jira/browse/CXF-3248
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.3.2
>Reporter: Glen Mazza
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 2.3.2, 2.4
>
>
> Example 7-1 of the JAX-RS book samples (see
> https://issues.apache.org/jira/browse/CXF-3247) is returning a unclear error
> message when it processes the following ExceptionMapper:
> @Provider
> public class NotFoundExceptionMapper implements
> ExceptionMapper
> {
>public Response toResponse(NotFoundException exception)
>{
> return Response.status(Response.Status.NOT_FOUND)
> .entity(exception.getMessage())
> .type("text/plain").build();
>}
> }
> This is the error message it's returning:
> WARNING: No resource methods have been found for resource class
> com.restfully.shop.services.NotFoundExceptionMapper
> I'm not sure why an exception mapper needs to have resource methods, or what
> a "resource method" is for that matter. I think this error is appropriate
> for root resources only and not exception mappers, if so, this message should
> be suppressed for exception mappers. OTOH, if this warning does have meaning
> for exception mappers, could it be made clearer for newbies/novices?
> Note this example has other bugs with it, not related to this problem
> (https://issues.jboss.org/browse/RESTEASY-495).
> To duplicate, download and extract RESTEasy and make the pom.xml and web.xml
> changes all described in https://issues.apache.org/jira/browse/CXF-3247.
> Then just run mvn clean install and you'll see the above error message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3247) CXF JAX-RS does not recognize MessageBodyReader/MessageBodyWriter with no generic parameters
[
https://issues.apache.org/jira/browse/CXF-3247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-3247.
---
Resolution: Fixed
> CXF JAX-RS does not recognize MessageBodyReader/MessageBodyWriter with no
> generic parameters
>
>
> Key: CXF-3247
> URL: https://issues.apache.org/jira/browse/CXF-3247
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.3.1
>Reporter: Glen Mazza
>Assignee: Sergey Beryozkin
>Priority: Critical
> Fix For: 2.3.2, 2.4
>
>
> Chapter 19, Example 6_02 (page 230) from Bill Burke's RESTful Java with
> JAX-RS book is working with RESTEasy but not CXF (I'm using 2.3.2-SNAPSHOT).
> This example is freely available in the RESTEasy download[1].
> This example creates a new MessageBodyReader and MessageBodyWriter for
> exchanging Java objects directly using REST.
> Steps to duplicate:
> 1.) After downloading and extracting RESTEasy and navigating to this folder:
> resteasy-jaxrs-2.1.0.GA/examples/oreilly-workbook/ex06_2 , type mvn clean
> install. You'll see a before/after response using the RESTEasy library:
> ---
> T E S T S
> ---
> Running com.restfully.shop.test.CustomerResourceTest
> *** Create a new Customer ***
> 15.01.2011 17:21:14 org.jboss.resteasy.spi.ResteasyDeployment
> INFO: Deploying javax.ws.rs.core.Application: class
> com.restfully.shop.services.ShoppingApplication
> 15.01.2011 17:21:14 org.jboss.resteasy.spi.ResteasyDeployment
> INFO: Adding singleton resource com.restfully.shop.services.CustomerResource
> from Application javax.ws.rs.core.Application
> Created customer 1
> Location: http://localhost:9095/customers/1
> *** GET Created Customer **
> Content-Type: application/x-java-serialized-object
> Customer{id=1, firstName='Bill', lastName='Burke', street='256 Clarendon
> Street', city='Boston', state='MA', zip='02115', country='USA'}
> After Update ***
> Content-Type: application/x-java-serialized-object
> Customer{id=1, firstName='William', lastName='Burke', street='256 Clarendon
> Street', city='Boston', state='MA', zip='02115', country='USA'}
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.344 sec
> 2.) Convert the sample to using CXF's version of JAX-RS by making the
> following two changes (I've used these two steps with success in nearly all
> the other examples up to this one):
> -- Switching the servlet in the web.xml:
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> -- Switching the dependency in the pom.xml:
>
> org.apache.cxf
> cxf-rt-frontend-jaxrs
> 2.3.2-SNAPSHOT
>
>
> 3.) Running mvn clean install again will return this error:
> ---
> T E S T S
> ---
> Running com.restfully.shop.test.CustomerResourceTest
> *** Create a new Customer ***
> 15.01.2011 17:22:52 org.apache.cxf.transport.servlet.CXFNonSpringServlet
> loadBusNoConfig
> INFO: Load the bus without application context
> 15.01.2011 17:22:52
> org.springframework.context.support.AbstractApplicationContext prepareRefresh
> INFO: Refreshing org.apache.cxf.bus.spring.BusApplicationContext@23b561a2:
> startup date [Sat Jan 15 17:22:52 EST 2011]; root of context hierarchy
> 15.01.2011 17:22:52
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource
> [META-INF/cxf/cxf.xml]
> 15.01.2011 17:22:52
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource
> [META-INF/cxf/cxf-extension-jaxrs-binding.xml]
> 15.01.2011 17:22:52
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource
> [META-INF/cxf/cxf-extension-xml.xml]
> 15.01.2011 17:22:52
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource
> [META-INF/cxf/cxf-extension-http.xml]
> 15.01.2011 17:22:52
> org.springframework.beans.factory.support.DefaultListableBeanFactory
> preInstantiateSingletons
> INFO: Pre-instantiating singletons in
> org.springframework.beans.factory.support.DefaultListableBeanFactory@2f78743b:
> defining beans
> [cxf,org.apache.cxf.bus.spring.BusApplicationListener,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring
[jira] Resolved: (CXF-3250) EPR's address is NOT used for invocations on the endpoint when the dispatchImpl is created with EPR
[ https://issues.apache.org/jira/browse/CXF-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-3250. -- Resolution: Fixed > EPR's address is NOT used for invocations on the endpoint when the > dispatchImpl is created with EPR > > > Key: CXF-3250 > URL: https://issues.apache.org/jira/browse/CXF-3250 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 2.3.1 >Reporter: jimma >Assignee: jimma > Fix For: 2.3.2, 2.4 > > > From the jaxws api : > Creates a Dispatch instance for use with objects of the user's choosing. If > there are any reference parameters in the endpointReference, then those > reference parameters MUST appear as SOAP headers, indicating them to be > reference parameters, on all messages sent to the endpoint. The > endpointReference's address MUST be used for invocations on the endpoint. In > the implementation of this method, the JAX-WS runtime system takes the > responsibility of selecting a protocol binding (and a port) and configuring > the dispatch accordingly from the WSDL associated with this Service instance > or from the metadata from the endpointReference. If this Service instance has > a WSDL and the endpointReference also has a WSDL in its metadata, then the > WSDL from this instance MUST be used. If this Service instance does not have > a WSDL and the endpointReference does have a WSDL, then the WSDL from the > endpointReference MAY be used. An implementation MUST be able to retrieve the > portName from the endpointReference metadata. > This method behaves the same as calling > dispatch = service.createDispatch(portName, type, mode, features); > > where the portName is retrieved from the WSDL or EndpointReference metadata. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3236) Add support for an Issued Token extracted from a SAML assertion
[ https://issues.apache.org/jira/browse/CXF-3236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-3236. -- Resolution: Fixed > Add support for an Issued Token extracted from a SAML assertion > --- > > Key: CXF-3236 > URL: https://issues.apache.org/jira/browse/CXF-3236 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.3.1 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.3.2, 2.4 > > Attachments: cxf-3234-tentative.patch > > > CXF cannot currently support the following use-case: > A service endpoint has a security policy consisting of a sp:SymmetricBinding > which uses a (SAML) sp:IssuedToken as the sp:ProtectionToken. A client parses > this, and obtains the appropriate SAML token from an STS, which it sends to > the service endpoint, securing the message appropriately. The service > endpoint can process the request, but it falls down on the reply as it does > not know how to get access to the Issued Token to secure the message reply. > A patch to WSS4J to save the secret key extracted from the SAML assertion is > here (https://issues.apache.org/jira/browse/WSS-263). A patch is required to > CXF to parse the result set and save the appropriate token. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-3253) LocalConduit with DirectDispatch does not work with interceptors that decorate the OutputStream
LocalConduit with DirectDispatch does not work with interceptors that decorate
the OutputStream
---
Key: CXF-3253
URL: https://issues.apache.org/jira/browse/CXF-3253
Project: CXF
Issue Type: Bug
Components: Transports
Affects Versions: 2.3.1, 2.2.10
Environment: Found in CXF 2.2.10, confirmed the code is the same in
2.3.1
Windows 2003 Server x64
Reporter: Sven Zethelius
Create a Client that uses the local transport.
Set property org.apache.cxf.transport.local.LocalConduit.directDispatch
Add an Out interceptor to the Client that decorates the OutputStream. For
example GZIPOutInterceptor.
Expected:
decorated OutputStream to work.
Actual:
ClassCastException
Cause:
{code:title=org.apache.cxf.transport.local.LocalConduit.dispatchDirect(Message)}
CachedOutputStream stream =
(CachedOutputStream)message.getContent(OutputStream.class);
{code}
This code is assuming the message OutputStream hasn't been wrapped. My
suggested fix would be to store the CachedContentStream you need to manipulate
as a property of the Message, in addition to the setContent, so that even if
the setContent is manipulated the other property would still be available.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
