[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=12978026#action_12978026 ] Christian Schneider commented on CXF-3230: -- I guess I found the problem ... should have read the description of the issue better ... I was so concerned to find the thread leak that I overread that we do not remove the temporary destinations. We really do not remove the temporary queues. So I think there are two solutions. We could either not create so many temp queues at all or delete each one after the request. The second option is probably easier to do. > 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 > Attachments: 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] 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=12978022#action_12978022 ] Christian Schneider commented on CXF-3230: -- I found something on http://activemq.apache.org/javalangoutofmemory.html Number of Threads By default, ActiveMQ uses a dedicated thread per destination. If there are large numbers of Destinations there will be a large number of threads and their associated memory resource usage. ActiveMQ can be configured to use a thread pool through the use of the system property: -Dorg.apache.activemq.UseDedicatedTaskRunner=false. This is currently specified in the activemq start script via ACTIVEMQ_OPTS. Using a thread pool can restrict the number of threads required by ActiveMQ and hence reduce memory usage. > 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 > Attachments: 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] 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=12978015#action_12978015 ] Christian Schneider commented on CXF-3230: -- I was able to reproduce the issue with cxf 2.3.1 and ActiveMQ 5.4.2 as well as ActiveMQ 4.0.2. At the moment I have no idea though what is the cause of the problem. The Heap Memory and JVM THreads do not seem to grow. Only the native threads seem to grow. When googling the problem that exception "unable to create new native thread" seems not uncommon in ActiveMQ. As the problem is also reported for other jms providers it can´t be a pure ActiveMQ problem though. > 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 > Attachments: 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] Assigned: (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 reassigned CXF-3230: Assignee: Christian Schneider > 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 > Attachments: 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-3085) non-varargs related warning in CXF 2.3 build
[ https://issues.apache.org/jira/browse/CXF-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-3085. -- Resolution: Fixed Fix Version/s: 2.3.2 Assignee: Daniel Kulp > non-varargs related warning in CXF 2.3 build > > > Key: CXF-3085 > URL: https://issues.apache.org/jira/browse/CXF-3085 > Project: CXF > Issue Type: Improvement > Environment: Apache CXF 2.3.0 > OS: Microsoft Windows XP, Professional, Version 2002, Service Pack 3 > Build Command: (mvn -e clean install) >Reporter: Robert Liguori >Assignee: Daniel Kulp >Priority: Minor > Fix For: 2.3.2 > > > If possible, please resolve the warning, thanks! > [INFO] > > [INFO] Building Apache CXF Runtime JAX-RS Frontend > [INFO]task-segment: [clean, install] > [INFO] > > ... > [WARNING] > \_CXF\apache-cxf-2.3.0-src\apache-cxf-2.3.0-src\rt\frontend\jaxrs\src\test\java\org\apache\cxf\jaxrs\impl\UriBuilderImplTest.java:[617,77] > non-varargs call of varargs method with inexact argument type for last > parameter; > cast to java.lang.Object for a varargs call > cast to java.lang.Object[] for a non-varargs call and to suppress this warning > ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3081) Deprecated Soap getPrefix() calls should be replaced.
[
https://issues.apache.org/jira/browse/CXF-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-3081.
--
Resolution: Fixed
Fix Version/s: 2.4
Assignee: Daniel Kulp
Methods removed
> Deprecated Soap getPrefix() calls should be replaced.
> -
>
> Key: CXF-3081
> URL: https://issues.apache.org/jira/browse/CXF-3081
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.3.0
>Reporter: Robert Liguori
>Assignee: Daniel Kulp
>Priority: Minor
> Fix For: 2.4
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> I think the getPrefix() calls from the
> org.apache.cxf.binding.soap.SoapVersion class should be replaced with
> getPrefix() calls from org.apache.cxf.binding.soap.Soap11 and
> org.apache.cxf.binding.soap.Soap12 in order to resolve the respective
> warnings in the following reference (from a CXF 2.3.0 maven build):
> Reference:
> [INFO]
>
> [INFO] Building Apache CXF Runtime SOAP Binding
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean {execution: default-clean}]
> [INFO] Deleting
> C:\_CXF\apache-cxf-2.3.0-src\apache-cxf-2.3.0-src\rt\bindings\soap\target
> [INFO] [checkstyle:checkstyle {execution: validate}]
> [INFO] Starting audit...
> Audit done.
> [INFO] Preparing pmd:check
> [INFO] [pmd:pmd {execution: pmd}]
> [INFO] [pmd:check {execution: validate}]
> [INFO]
> [INFO] [cxf-xml2fastinfoset:xml2fastinfoset {execution: xml2fastinfoset}]
> [INFO] [remote-resources:process {execution: default}]
> [INFO] [resources:resources {execution: default-resources}]
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 3 resources
> [INFO] Copying 7 resources
> [INFO] skip non existing resourceDirectory
> C:\_CXF\apache-cxf-2.3.0-src\apache-cxf-2.3.0-src\rt\bindings\soap\src\main\resources-filtered
> [INFO] Copying 1 resource
> [INFO] Copying 3 resources
> [INFO] [compiler:compile {execution: default-compile}]
> [INFO] Compiling 68 source files to
> C:\_CXF\apache-cxf-2.3.0-src\apache-cxf-2.3.0-src\rt\bindings\soap\target\classes
> [WARNING]
> \_CXF\apache-cxf-2.3.0-src\apache-cxf-2.3.0-src\rt\bindings\soap\src\main\java\org\apache\cxf\binding\soap\Soap12.java:[141,18]
> [deprecation] getPrefix() in org.apache.cxf.binding.soap.SoapVersion has
> been deprecated
> [WARNING]
> \_CXF\apache-cxf-2.3.0-src\apache-cxf-2.3.0-src\rt\bindings\soap\src\main\java\org\apache\cxf\binding\soap\Soap11.java:[161,18]
> [deprecation] getPrefix() in org.apache.cxf.binding.soap.SoapVersion has
> been deprecated
> [INFO] [resources:testResources {execution: default-testResources}]
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 4 resources
> [INFO] Copying 12 resources
> [INFO] skip non existing resourceDirectory
> C:\_CXF\apache-cxf-2.3.0-src\apache-cxf-2.3.0-src\rt\bindings\soap\target\generated\src\test\resources
> [INFO] Copying 3 resources
> [INFO] [compiler:testCompile {execution: default-testCompile}]
> [INFO] Compiling 16 source files to
> C:\_CXF\apache-cxf-2.3.0-src\apache-cxf-2.3.0-src\rt\bindings\soap\target\test-classes
> [INFO] [surefire:test {execution: default-test}]
> [INFO] Surefire report directory:
> C:\_CXF\apache-cxf-2.3.0-src\apache-cxf-2.3.0-src\rt\bindings\soap\target\surefire-reports
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3134) Build fails when a space is included in the directory URL.
[
https://issues.apache.org/jira/browse/CXF-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-3134.
--
Resolution: Fixed
Fix Version/s: 2.3.2
We now have a windows build setup in hudson with spaces in both the path to
the svn checkout as well as the maven repo. Hopefully that will catch these
errors sooner from now on.
> Build fails when a space is included in the directory URL.
> --
>
> Key: CXF-3134
> URL: https://issues.apache.org/jira/browse/CXF-3134
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.3.0
> Environment: Microsoft Windows XP, JDK 1.6, CXF 2.3.0
>Reporter: Robert Liguori
> Fix For: 2.3.2
>
>
> The maven build process is unsuccessful when the cxf folders are subfolders
> of a folder that contains a space.
> That is, running "mvn install" here works fine:
> C:\_Stacks\_CXF\apache-cxf-2.3.0-src\apache-cxf-2.3.0-src\
> However, running "mvn install" with a space included fails the build (notice
> the space between _Space and Stacks):
> C:\_Space Stacks\_CXF\apache-cxf-2.3.0-src\apache-cxf-2.3.0-src\
> Build output:
> ...
>
> [INFO] Building Apache CXF Runtime Core
> [INFO]task-segment: [install]
> [INFO]
>
> [INFO] [checkstyle:checkstyle {execution: validate}]
> [INFO] Starting audit...
> Audit done.
> [INFO] Preparing pmd:check
> [INFO] [pmd:pmd {execution: pmd}]
> [INFO] [pmd:check {execution: validate}]
> [INFO]
> [INFO] [cxf-xml2fastinfoset:xml2fastinfoset {execution: xml2fastinfoset}]
> [INFO] [remote-resources:process {execution: default}]
> [INFO] [resources:resources {execution: default-resources}]
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 14 resources
> [INFO] Copying 8 resources
> [INFO] skip non existing resourceDirectory C:\_Space
> Stacks\_CXF\apache-cxf-2.3.0-src\apache-cxf-2.3.0-src\rt\core\src\main\resources-filtered
> [INFO] Copying 1 resource
> [INFO] Copying 3 resources
> [INFO] [compiler:compile {execution: default-compile}]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [resources:testResources {execution: default-testResources}]
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 19 resources
> [INFO] Copying 30 resources
> [INFO] skip non existing resourceDirectory C:\_Space
> Stacks\_CXF\apache-cxf-2.3.0-src\apache-cxf-2.3.0-src\rt\core\target\generated\src\test\resources
> [INFO] Copying 3 resources
> [INFO] [compiler:testCompile {execution: default-testCompile}]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [surefire:test {execution: default-test}]
> [INFO] Surefire report directory: C:\_Space
> Stacks\_CXF\apache-cxf-2.3.0-src\apache-cxf-2.3.0-src\rt\core\target\surefire-reports
> ---
> T E S T S
> ---
> Running org.apache.cxf.bus.extension.ExtensionTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.156 sec
> Running org.apache.cxf.interceptor.ServiceInvokerInterceptorTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.141 sec
> Running org.apache.cxf.endpoint.ServerRegistryImpTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
> Running org.apache.cxf.endpoint.EndpointResolverRegistryImplTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.125 sec
> Running org.apache.cxf.bus.spring.BusApplicationContextTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.812 sec
> Running org.apache.cxf.workqueue.AutomaticWorkQueueTest
> Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 20.657 sec
> Running org.apache.cxf.transport.ChainInitiationObserverTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.062 sec
> Running org.apache.cxf.bus.CXFBusImplTest
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.078 sec
> Running org.apache.cxf.interceptor.OutgoingChainInterceptorTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.125 sec
> Running org.apache.cxf.wsdl11.WSDLServiceBuilderTest
> Tests run: 16, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.641 sec
> <<< FAILURE!
> testImport(org.apache.cxf.wsdl11.WSDLServiceBuilderTest) Time elapsed: 0.172
> sec <<< FAILURE!
> java.lang.AssertionError:
> at org.junit.Assert.fail(Assert.java:91)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.junit.Assert.assertNotNull(Assert.java:524)
> at org.junit.Assert.assertNotNull(Assert.java:535)
> at
> org.apache.cxf.wsdl11.WSDLServiceBuilderTest.testImport(WS
[jira] Resolved: (CXF-3037) Policy references embedded in policy are not processed
[
https://issues.apache.org/jira/browse/CXF-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-3037.
--
Resolution: Fixed
Fix Version/s: 2.3.2
> Policy references embedded in policy are not processed
> --
>
> Key: CXF-3037
> URL: https://issues.apache.org/jira/browse/CXF-3037
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.2.10
>Reporter: Dennis Sosnoski
>Assignee: Daniel Kulp
> Fix For: 2.3.2
>
>
> WS-Policy allows to be embedded within policy
> documents, but CXF does not handle these references. Here's an example:
>
>
>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";
> xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl";
> xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702";>
>
>
>
>
> sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never";>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";
> xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl";
> xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702";>
> http://www.w3.org/ns/ws-policy";
> URI="#SymmBinding"/>
>
>
>
>
>
>
>
>
> When trying to use this policy on the client it causes an NPE inside Neethi:
> [java] WARNING: Interceptor for
> {http://ws.sosnoski.com/library/wsdl}CXFLibrary#{http://ws.sosnoski.com/library/wsdl}getBook
> has thrown exception, unwinding now
> [java] java.lang.NullPointerException
> [java] at
> org.apache.neethi.AbstractPolicyOperator.normalizeOperator(AbstractPolicyOperator.java:116)
> [java] at
> org.apache.neethi.AbstractPolicyOperator.normalize(AbstractPolicyOperator.java:73)
> [java] at org.apache.neethi.Policy.normalize(Policy.java:64)
> [java] at org.apache.neethi.Policy.normalize(Policy.java:49)
> [java] at
> org.apache.cxf.ws.policy.EffectivePolicyImpl.initialisePolicy(EffectivePolicyImpl.java:134)
> [java] at
> org.apache.cxf.ws.policy.EffectivePolicyImpl.initialise(EffectivePolicyImpl.java:86)
> [java] at
> org.apache.cxf.ws.policy.PolicyEngineImpl.getEffectiveClientRequestPolicy(PolicyEngineImpl.java:155)
> [java] at
> org.apache.cxf.ws.policy.PolicyOutInterceptor.handle(PolicyOutInterceptor.java:110)
> The problem here is that CXF passes a null for the policy context when
> calling the Policy.normalize() method. Just passing the context should be
> enough to make this work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-3232) OneWayProcessorInterceptor throws fault on WebSphere
[ https://issues.apache.org/jira/browse/CXF-3232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Shults updated CXF-3232: - Description: WebSphere rejects all incoming SOAP messages to one-way WSDLs. This error does not occur on WebLogic. OneWayProcessorInterceptor handleMessage throws a fault from line 93. More specifically, org.apache.cxf.transport.AbstractConduit throws the exception from line 56. This call to close gets us into org.apache.cxf.transport.http.AbstractHTTPDestination.flushHeaders(...) which calls IBM's implementation of SRTServletResponse.setContentType(...). That implementation of setContentType(...) throws a NullPointerException when null is passed in. was: WebSphere rejects all incoming SOAP messages to one-way WSDLs. OneWayProcessorInterceptor handleMessage throws a fault from line 93. More specifically, org.apache.cxf.transport.AbstractConduit throws the exception from line 56. This call to close gets us into org.apache.cxf.transport.http.AbstractHTTPDestination.flushHeaders(...) which calls IBM's implementation of SRTServletResponse.setContentType(...). That implementation of setContentType(...) throws a NullPointerException when null is passed in. > OneWayProcessorInterceptor throws fault on WebSphere > > > Key: CXF-3232 > URL: https://issues.apache.org/jira/browse/CXF-3232 > Project: CXF > Issue Type: Bug > Components: Bus >Affects Versions: 2.3.1 > Environment: webSphere WAS >Reporter: Benjamin Shults > > WebSphere rejects all incoming SOAP messages to one-way WSDLs. This error > does not occur on WebLogic. > OneWayProcessorInterceptor handleMessage throws a fault from line 93. > More specifically, org.apache.cxf.transport.AbstractConduit throws the > exception from line 56. > This call to close gets us into > org.apache.cxf.transport.http.AbstractHTTPDestination.flushHeaders(...) which > calls IBM's implementation of SRTServletResponse.setContentType(...). > That implementation of setContentType(...) throws a NullPointerException when > null is passed in. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-3232) OneWayProcessorInterceptor throws fault on WebSphere
OneWayProcessorInterceptor throws fault on WebSphere Key: CXF-3232 URL: https://issues.apache.org/jira/browse/CXF-3232 Project: CXF Issue Type: Bug Components: Bus Affects Versions: 2.3.1 Environment: webSphere WAS Reporter: Benjamin Shults WebSphere rejects all incoming SOAP messages to one-way WSDLs. OneWayProcessorInterceptor handleMessage throws a fault from line 93. More specifically, org.apache.cxf.transport.AbstractConduit throws the exception from line 56. This call to close gets us into org.apache.cxf.transport.http.AbstractHTTPDestination.flushHeaders(...) which calls IBM's implementation of SRTServletResponse.setContentType(...). That implementation of setContentType(...) throws a NullPointerException when null is passed in. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
