Re: CXF Premature End Of File ?
Hi all, this issue can be closed as I am beginner in this webservices I also made such an error ... but at least I figured it out... one basic rule as it seems is that in the webservice one may only pass objects. At some places I tried to pass interfaces. so the correct wsdl for such a project - team relation would look like shown below. Also:the groovy script now returns a much more promising message: INFO: Created classes: org.expertfinder.webservice.export.GetAllTeamsByProjectID, org.expertfinder.webservice.export.GetAllTeamsByProjectIDResponse, org.expertfinder.webservice.export.ObjectFactory, org.expertfinder.db.export.ArrayOfTeam, org.expertfinder.db.export.ObjectFactory, org.expertfinder.db.export.Project, org.expertfinder.db.export.Team org.expertfinder.db.export.arrayoft...@146f97cf WSDL script: http://export.webservice.expertfinder.org/";> − − http://export.db.expertfinder.org";> − − − − − − − http://export.webservice.expertfinder.org/";> http://export.db.expertfinder.org"/> − − − − − − − − − http://schemas.xmlsoap.org/soap/http"/> − − − − − http://localhost:9090/expertFinder"/> -- View this message in context: http://cxf.547215.n5.nabble.com/CXF-Premature-End-Of-File-tp3249208p3326776.html Sent from the cxf-issues mailing list archive at Nabble.com.
[jira] Commented: (CXF-3129) wsdl2java: place @Generated annotation on generated code
[ https://issues.apache.org/jira/browse/CXF-3129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977195#action_12977195 ] Andrew Spencer commented on CXF-3129: - Thanks to both of you for your work on this issue. > wsdl2java: place @Generated annotation on generated code > > > Key: CXF-3129 > URL: https://issues.apache.org/jira/browse/CXF-3129 > Project: CXF > Issue Type: New Feature > Components: Tooling >Affects Versions: 2.3.0 >Reporter: Andrew Spencer >Assignee: Daniel Kulp >Priority: Minor > Fix For: 2.3.2 > > Attachments: Patch for CXF 3129 - version 2.patch, Patch for CXF > 3129.txt > > > It would be considerate on the part of CXF to place @Generated on the Java > source generated by wsdl2java. > @Generated is in the javax.annotation package and is a marker for generated > code. It allows code quality tools to ignore the generated code, as > described in this feature request for Sonar: > http://jira.codehaus.org/browse/SONAR-1042 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3216) Refactor http authentication to make it more flexible and simpler
[ https://issues.apache.org/jira/browse/CXF-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved CXF-3216. -- Resolution: Fixed The issue is fixed from my perspective > Refactor http authentication to make it more flexible and simpler > - > > Key: CXF-3216 > URL: https://issues.apache.org/jira/browse/CXF-3216 > Project: CXF > Issue Type: Improvement > Components: Transports >Affects Versions: 2.3.1 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 2.4 > > Attachments: CXF-3216-1.patch, CXF-3216-2.patch > > > The http authentication should be completely based on authSupplier. The > HttpConduit should simply delegate to it. > We should also remove some of the other auth config options besides > authorizationPolicy on conduit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3123) Support Spnego/Kerberos authentication for http transport
[ https://issues.apache.org/jira/browse/CXF-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved CXF-3123. -- Resolution: Fixed Fix Version/s: 2.4 Spnego auth should now be possible. Need to do a manual system test though. > Support Spnego/Kerberos authentication for http transport > - > > Key: CXF-3123 > URL: https://issues.apache.org/jira/browse/CXF-3123 > Project: CXF > Issue Type: New Feature > Components: Transports >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 2.4 > > > Spnego/kerberos is a quite common authentication mechanism in the microsoft > world. CXF should support this mechanism for the client as well as the server > side. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-3229) Generated Exception files should extend java.lang.Exception, not Exception
Generated Exception files should extend java.lang.Exception, not Exception -- Key: CXF-3229 URL: https://issues.apache.org/jira/browse/CXF-3229 Project: CXF Issue Type: Bug Components: JAX-RS, Tooling Affects Versions: 2.3.1, 2.3.0, 2.4 Environment: All Reporter: Jesse Long WSDL2Java generates Java source code, for faults, it generates exceptions. When the fault name is Exception, the code looks like public class Exception extends Exception Which is a cyclic inheritance problem. It should be: public class Exception extends java.lang.Exception -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-3229) Generated Exception files should extend java.lang.Exception, not Exception
[ https://issues.apache.org/jira/browse/CXF-3229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Long updated CXF-3229: Attachment: cxf-Exception.patch This is the patch against trunk to resolve the issue, probably will patch cleanly against 2.3x branch too > Generated Exception files should extend java.lang.Exception, not Exception > -- > > Key: CXF-3229 > URL: https://issues.apache.org/jira/browse/CXF-3229 > Project: CXF > Issue Type: Bug > Components: JAX-RS, Tooling >Affects Versions: 2.3.0, 2.3.1, 2.4 > Environment: All >Reporter: Jesse Long > Attachments: cxf-Exception.patch > > > WSDL2Java generates Java source code, for faults, it generates exceptions. > When the fault name is Exception, the code looks like > public class Exception extends Exception > Which is a cyclic inheritance problem. It should be: > public class Exception extends java.lang.Exception -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-3229) Generated Exception files should extend java.lang.Exception, not Exception
[ https://issues.apache.org/jira/browse/CXF-3229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977270#action_12977270 ] Glen Mazza commented on CXF-3229: - Dan Kulp had suggested a while back a little bit more work would be needed (throw clauses in methods also would need updating): http://cxf.547215.n5.nabble.com/name-collision-Exception-td560353.html It may be interesting to see what Metro's wsimport equivalent does, they may be a step ahead of CXF in this regard: http://www.jroller.com/gmazza/entry/soap_client_tutorial > Generated Exception files should extend java.lang.Exception, not Exception > -- > > Key: CXF-3229 > URL: https://issues.apache.org/jira/browse/CXF-3229 > Project: CXF > Issue Type: Bug > Components: JAX-RS, Tooling >Affects Versions: 2.3.0, 2.3.1, 2.4 > Environment: All >Reporter: Jesse Long > Attachments: cxf-Exception.patch > > > WSDL2Java generates Java source code, for faults, it generates exceptions. > When the fault name is Exception, the code looks like > public class Exception extends Exception > Which is a cyclic inheritance problem. It should be: > public class Exception extends java.lang.Exception -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-3229) Generated Exception files should extend java.lang.Exception, not Exception
[ https://issues.apache.org/jira/browse/CXF-3229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977275#action_12977275 ] Jesse Long commented on CXF-3229: - Good news. References to unqualified class names in java source code are resolved by first looking for inner classes, then classes from the same package and finally classes from java.lang. So, because the fault is xxx.Exception, and the interface is xxx.MyInterface, the "throws Exception" will refer to xxx.Exception. :) > Generated Exception files should extend java.lang.Exception, not Exception > -- > > Key: CXF-3229 > URL: https://issues.apache.org/jira/browse/CXF-3229 > Project: CXF > Issue Type: Bug > Components: JAX-RS, Tooling >Affects Versions: 2.3.0, 2.3.1, 2.4 > Environment: All >Reporter: Jesse Long > Attachments: cxf-Exception.patch > > > WSDL2Java generates Java source code, for faults, it generates exceptions. > When the fault name is Exception, the code looks like > public class Exception extends Exception > Which is a cyclic inheritance problem. It should be: > public class Exception extends java.lang.Exception -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CXF-3215) Error when a process method of a webservice is called by multiple client (thread) in the same time
[
https://issues.apache.org/jira/browse/CXF-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp reassigned CXF-3215:
Assignee: Daniel Kulp
> Error when a process method of a webservice is called by multiple client
> (thread) in the same time
> --
>
> Key: CXF-3215
> URL: https://issues.apache.org/jira/browse/CXF-3215
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Windows7/Jetty
>Reporter: Jerome Dupont
>Assignee: Daniel Kulp
>
> This error occurs :
> INFO: Creating Service {http://siham.amue.fr}IUtilisateursServiceService from
> class fr.amue.siham.service.IUtilisateursService
> Exception in thread "Thread-2" Exception in thread "Thread-1"
> java.lang.LinkageError: loader (instance of
> org/apache/cxf/common/util/ASMHelper$TypeHelperClassLoader): attempted
> duplicate class definition for name:
> "fr/amue/siham/service/jaxws_asm/package-info"
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClassCond(Unknown Source)
> at java.lang.ClassLoader.defineClass(Unknown Source)
> at java.lang.ClassLoader.defineClass(Unknown Source)
> at
> org.apache.cxf.common.util.ASMHelper$TypeHelperClassLoader.defineClass(ASMHelper.java:208)
> at org.apache.cxf.common.util.ASMHelper.loadClass(ASMHelper.java:167)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.generatePackageInfo(WrapperClassGenerator.java:255)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:179)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:137)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:518)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:496)
> at
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:365)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:525)
> at
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:431)
> at
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:191)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:164)
> at
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:100)
> at
> org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:52)
> at
> org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:102)
> at
> org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:115)
> at
> fr.amue.siham.client.CreateOrModifyClient.process(CreateOrModifyClient.java:76)
> at fr.amue.siham.client.ThreadInjection.run(ThreadInjection.java:34)
> java.lang.IllegalArgumentException: fr.amue.siham.service.jaxws_asm
> at java.lang.ClassLoader.definePackage(Unknown Source)
> at
> org.apache.cxf.common.util.ASMHelper$TypeHelperClassLoader.defineClass(ASMHelper.java:197)
> at org.apache.cxf.common.util.ASMHelper.loadClass(ASMHelper.java:167)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.generatePackageInfo(WrapperClassGenerator.java:255)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:179)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:137)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:518)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:496)
> at
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:365)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:525)
> at
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:431)
> at
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:191)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:164)
> at
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:100)
> at
> org.apach
[jira] Assigned: (CXF-3229) Generated Exception files should extend java.lang.Exception, not Exception
[ https://issues.apache.org/jira/browse/CXF-3229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp reassigned CXF-3229: Assignee: Daniel Kulp > Generated Exception files should extend java.lang.Exception, not Exception > -- > > Key: CXF-3229 > URL: https://issues.apache.org/jira/browse/CXF-3229 > Project: CXF > Issue Type: Bug > Components: JAX-RS, Tooling >Affects Versions: 2.3.0, 2.3.1, 2.4 > Environment: All >Reporter: Jesse Long >Assignee: Daniel Kulp > Attachments: cxf-Exception.patch > > > WSDL2Java generates Java source code, for faults, it generates exceptions. > When the fault name is Exception, the code looks like > public class Exception extends Exception > Which is a cyclic inheritance problem. It should be: > public class Exception extends java.lang.Exception -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CXF-3228) SOAPMessage does not recognize SOAPMessage.WRITE_XML_DECLARATION
[
https://issues.apache.org/jira/browse/CXF-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp reassigned CXF-3228:
Assignee: Daniel Kulp
> SOAPMessage does not recognize SOAPMessage.WRITE_XML_DECLARATION
>
>
> Key: CXF-3228
> URL: https://issues.apache.org/jira/browse/CXF-3228
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Reporter: David Liu
>Assignee: Daniel Kulp
>
> Hi,
> It could be a bug in cxf's @WebServiceProvider implementation that we
> cannot control the output xml encoding by setting
> SOAPMessage.CHARACTER_SET_ENCODING. The encoding ( {quote} encoding="UTF-8"?>{quote} ) response message was not changed when I change
> CHARACTER_SET_ENCODING to UTF-16.
> Please see my test class:
> {quote}
> @WebServiceProvider
> @ServiceMode(value = Service.Mode.MESSAGE)
> public class CalculatorProvider implements Provider {
> @Override
> public SOAPMessage invoke(SOAPMessage request) {
> long start = System.currentTimeMillis();
> System.out.println("* start at " + start);
> try {
> MessageFactory mf = MessageFactory.newInstance();
> SOAPMessage soapMsg = mf.createMessage();
> soapMsg.setProperty(SOAPMessage.CHARACTER_SET_ENCODING, "UTF-16");
> soapMsg.setProperty(SOAPMessage.WRITE_XML_DECLARATION, "false");
> soapMsg.getSOAPBody().addBodyElement(new QName("mytest"));
> soapMsg.saveChanges();
> return soapMsg;
> } catch (SOAPException e) {
> throw new RuntimeException(e);
> }
> }
> public static void main(String[] args) {
> System.out.println("Starting Server");
> CalculatorProvider implementor = new CalculatorProvider();
> String address = "http://localhost:7650/Calculator";;
> Endpoint.publish(address, implementor);
> }
> }
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-3230) CXF over JMS leaks JMS resources when no replay queue is specified
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 Priority: Blocker 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: http://cxf.apache.org/transports/jms";> 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 ] Kjell Winblad updated CXF-3230: --- Attachment: CXFJMSResourceLeaking.tar.gz Simple test programs that can be used to reproduce the issue. It is an eclipse project. Just run the Server and then the Client to start the test. > 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 >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] Created: (CXF-3231) wsdl2java should check wsa action if soap:body is overloaded
wsdl2java should check wsa action if soap:body is overloaded Key: CXF-3231 URL: https://issues.apache.org/jira/browse/CXF-3231 Project: CXF Issue Type: Improvement Reporter: Daniel Kulp Assignee: Daniel Kulp Fix For: 2.3.2 For a wsdl like those describing an STS, there are several operations that would have the same soap:body element, but COULD be distinguished based on the WSA Action. Currently, it results in a validation error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2564) CXF uses an old RS API 1.0 - Consider upgrading to 1.1 on branches as well
[ https://issues.apache.org/jira/browse/CXF-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-2564. -- Resolution: Fixed Fix Version/s: 2.3.0 2.3.x implements the 1.1 spec > CXF uses an old RS API 1.0 - Consider upgrading to 1.1 on branches as well > -- > > Key: CXF-2564 > URL: https://issues.apache.org/jira/browse/CXF-2564 > Project: CXF > Issue Type: Improvement >Affects Versions: 2.2.5 >Reporter: Claus Ibsen > Fix For: 2.3.0 > > > Looks like trunk is on API 1.1 which is good > But 2.2.5 is using old 1.0 API > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.5/rt/frontend/jaxrs/pom.xml > Which does not work well with the rest of the world where 1.1 API is commonly > used. > Consider if possible to upgrade to 1.1 on these branches, or at least on > 2.2.x branch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CXF-3201) Test failure on testCXF3105(org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest)
[
https://issues.apache.org/jira/browse/CXF-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp reassigned CXF-3201:
Assignee: Daniel Kulp
> Test failure on testCXF3105(org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest)
> --
>
> Key: CXF-3201
> URL: https://issues.apache.org/jira/browse/CXF-3201
> Project: CXF
> Issue Type: Test
> Components: Tooling
>Affects Versions: 2.3.1
> Environment: Trunk, Windows Vista 64bit, java version 1.6.0_21, Maven
> 2.2.1
>Reporter: Christian Schneider
>Assignee: Daniel Kulp
> Fix For: 2.3.2
>
>
> Hi,
> On revision 1050333 building on Windows Vista 64bit, java version 1.6.0_21,
> Maven 2.2.1, I hit the following error:
> 17-Dec-2010 09:09:05 org.apache.cxf.tools.validator.internal.WSDLRefValidator
> collectValidationPointsForBindings
> SEVERE: {http://child/}Binding is not correct, please check that the correct
> namespace is being used
> WSDLToJava Error: Thrown by JAXB: A class/interface with the same name
> "org.apache.cxf.testcase.cxf3105.LoginResponse" is already in use. Use a
> class customization or the -autoNameResolution option to resolve this
> conflict.
> Tests run: 63, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 21.963 sec
> <<< FAILURE!
> testCXF3105(org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest) Time elapsed:
> 0.078 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.assertTrue(Assert.java:54)
> at
> org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest.testCXF3105(CodeGenBugTest.java:1148)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> Looking at the wsdl I wonder if this is caused by a case insensitivity issue
> on Windows?
> Jim
> ---
> Also see
> http://cxf.547215.n5.nabble.com/Failure-building-latest-trunk-td3309214.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3215) Error when a process method of a webservice is called by multiple client (thread) in the same time
[
https://issues.apache.org/jira/browse/CXF-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-3215.
--
Resolution: Fixed
Fix Version/s: 2.3.2
> Error when a process method of a webservice is called by multiple client
> (thread) in the same time
> --
>
> Key: CXF-3215
> URL: https://issues.apache.org/jira/browse/CXF-3215
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Windows7/Jetty
>Reporter: Jerome Dupont
>Assignee: Daniel Kulp
> Fix For: 2.3.2
>
>
> This error occurs :
> INFO: Creating Service {http://siham.amue.fr}IUtilisateursServiceService from
> class fr.amue.siham.service.IUtilisateursService
> Exception in thread "Thread-2" Exception in thread "Thread-1"
> java.lang.LinkageError: loader (instance of
> org/apache/cxf/common/util/ASMHelper$TypeHelperClassLoader): attempted
> duplicate class definition for name:
> "fr/amue/siham/service/jaxws_asm/package-info"
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClassCond(Unknown Source)
> at java.lang.ClassLoader.defineClass(Unknown Source)
> at java.lang.ClassLoader.defineClass(Unknown Source)
> at
> org.apache.cxf.common.util.ASMHelper$TypeHelperClassLoader.defineClass(ASMHelper.java:208)
> at org.apache.cxf.common.util.ASMHelper.loadClass(ASMHelper.java:167)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.generatePackageInfo(WrapperClassGenerator.java:255)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:179)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:137)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:518)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:496)
> at
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:365)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:525)
> at
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:431)
> at
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:191)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:164)
> at
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:100)
> at
> org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:52)
> at
> org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:102)
> at
> org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:115)
> at
> fr.amue.siham.client.CreateOrModifyClient.process(CreateOrModifyClient.java:76)
> at fr.amue.siham.client.ThreadInjection.run(ThreadInjection.java:34)
> java.lang.IllegalArgumentException: fr.amue.siham.service.jaxws_asm
> at java.lang.ClassLoader.definePackage(Unknown Source)
> at
> org.apache.cxf.common.util.ASMHelper$TypeHelperClassLoader.defineClass(ASMHelper.java:197)
> at org.apache.cxf.common.util.ASMHelper.loadClass(ASMHelper.java:167)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.generatePackageInfo(WrapperClassGenerator.java:255)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:179)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:137)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:518)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:496)
> at
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:365)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:525)
> at
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:431)
> at
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:191)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:164)
> at
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBas
[jira] Resolved: (CXF-3229) Generated Exception files should extend java.lang.Exception, not Exception
[ https://issues.apache.org/jira/browse/CXF-3229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-3229. -- Resolution: Fixed Fix Version/s: 2.3.2 > Generated Exception files should extend java.lang.Exception, not Exception > -- > > Key: CXF-3229 > URL: https://issues.apache.org/jira/browse/CXF-3229 > Project: CXF > Issue Type: Bug > Components: JAX-RS, Tooling >Affects Versions: 2.3.0, 2.3.1, 2.4 > Environment: All >Reporter: Jesse Long >Assignee: Daniel Kulp > Fix For: 2.3.2 > > Attachments: cxf-Exception.patch > > > WSDL2Java generates Java source code, for faults, it generates exceptions. > When the fault name is Exception, the code looks like > public class Exception extends Exception > Which is a cyclic inheritance problem. It should be: > public class Exception extends java.lang.Exception -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3228) SOAPMessage does not recognize SOAPMessage.WRITE_XML_DECLARATION
[
https://issues.apache.org/jira/browse/CXF-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-3228.
--
Resolution: Fixed
Fix Version/s: 2.3.2
> SOAPMessage does not recognize SOAPMessage.WRITE_XML_DECLARATION
>
>
> Key: CXF-3228
> URL: https://issues.apache.org/jira/browse/CXF-3228
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Reporter: David Liu
>Assignee: Daniel Kulp
> Fix For: 2.3.2
>
>
> Hi,
> It could be a bug in cxf's @WebServiceProvider implementation that we
> cannot control the output xml encoding by setting
> SOAPMessage.CHARACTER_SET_ENCODING. The encoding ( {quote} encoding="UTF-8"?>{quote} ) response message was not changed when I change
> CHARACTER_SET_ENCODING to UTF-16.
> Please see my test class:
> {quote}
> @WebServiceProvider
> @ServiceMode(value = Service.Mode.MESSAGE)
> public class CalculatorProvider implements Provider {
> @Override
> public SOAPMessage invoke(SOAPMessage request) {
> long start = System.currentTimeMillis();
> System.out.println("* start at " + start);
> try {
> MessageFactory mf = MessageFactory.newInstance();
> SOAPMessage soapMsg = mf.createMessage();
> soapMsg.setProperty(SOAPMessage.CHARACTER_SET_ENCODING, "UTF-16");
> soapMsg.setProperty(SOAPMessage.WRITE_XML_DECLARATION, "false");
> soapMsg.getSOAPBody().addBodyElement(new QName("mytest"));
> soapMsg.saveChanges();
> return soapMsg;
> } catch (SOAPException e) {
> throw new RuntimeException(e);
> }
> }
> public static void main(String[] args) {
> System.out.println("Starting Server");
> CalculatorProvider implementor = new CalculatorProvider();
> String address = "http://localhost:7650/Calculator";;
> Endpoint.publish(address, implementor);
> }
> }
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3231) wsdl2java should check wsa action if soap:body is overloaded
[ https://issues.apache.org/jira/browse/CXF-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-3231. -- Resolution: Fixed > wsdl2java should check wsa action if soap:body is overloaded > > > Key: CXF-3231 > URL: https://issues.apache.org/jira/browse/CXF-3231 > Project: CXF > Issue Type: Improvement > Components: Tooling >Reporter: Daniel Kulp >Assignee: Daniel Kulp > Fix For: 2.3.2 > > > For a wsdl like those describing an STS, there are several operations that > would have the same soap:body element, but COULD be distinguished based on > the WSA Action. Currently, it results in a validation error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3201) Test failure on testCXF3105(org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest)
[
https://issues.apache.org/jira/browse/CXF-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-3201.
--
Resolution: Fixed
> Test failure on testCXF3105(org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest)
> --
>
> Key: CXF-3201
> URL: https://issues.apache.org/jira/browse/CXF-3201
> Project: CXF
> Issue Type: Test
> Components: Tooling
>Affects Versions: 2.3.1
> Environment: Trunk, Windows Vista 64bit, java version 1.6.0_21, Maven
> 2.2.1
>Reporter: Christian Schneider
>Assignee: Daniel Kulp
> Fix For: 2.3.2
>
>
> Hi,
> On revision 1050333 building on Windows Vista 64bit, java version 1.6.0_21,
> Maven 2.2.1, I hit the following error:
> 17-Dec-2010 09:09:05 org.apache.cxf.tools.validator.internal.WSDLRefValidator
> collectValidationPointsForBindings
> SEVERE: {http://child/}Binding is not correct, please check that the correct
> namespace is being used
> WSDLToJava Error: Thrown by JAXB: A class/interface with the same name
> "org.apache.cxf.testcase.cxf3105.LoginResponse" is already in use. Use a
> class customization or the -autoNameResolution option to resolve this
> conflict.
> Tests run: 63, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 21.963 sec
> <<< FAILURE!
> testCXF3105(org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest) Time elapsed:
> 0.078 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.assertTrue(Assert.java:54)
> at
> org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest.testCXF3105(CodeGenBugTest.java:1148)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> Looking at the wsdl I wonder if this is caused by a case insensitivity issue
> on Windows?
> Jim
> ---
> Also see
> http://cxf.547215.n5.nabble.com/Failure-building-latest-trunk-td3309214.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CXF-3218) apparent regression introduced between 2.2.8 and 2.2.9: http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT not supported
[
https://issues.apache.org/jira/browse/CXF-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp reassigned CXF-3218:
Assignee: Daniel Kulp
> apparent regression introduced between 2.2.8 and 2.2.9:
> http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT not supported
> ---
>
> Key: CXF-3218
> URL: https://issues.apache.org/jira/browse/CXF-3218
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.3.1
> Environment: jdk1.6, linux ubuntu 10.10, tomcat 5.5.31.
>Reporter: John J. Franey
>Assignee: Daniel Kulp
> Attachments: scencr.zip
>
>
> This problem shows on 2.3.1 but not in 2.2.8. The problem shows in 2.2.9.
> The code is taken from:
> http://www.ibm.com/developerworks/java/library/j-jws17/index.html
> The only difference between the (soon to be attached) code and the original
> is the cxf home path in build.properties.
> There are two services defined in the code, the failure occurs on only one of
> them: cxf-seismic-scencr.war
> Load that into tomcat and then run the client with: ant run-scencr
> Exception in tomcat catalina log:
> Dec 24, 2010 12:48:19 PM org.apache.cxf.phase.PhaseInterceptorChain
> doDefaultLogging
> WARNING: Interceptor for
> {http://docs.oasis-open.org/ws-sx/ws-trust/200512/wsdl}SecurityTokenService#{http://docs.oasis-open.org/ws-sx/ws-trust/200512/wsdl}RequestSecurityToken
> has thrown exception, unwinding now
> org.apache.cxf.binding.soap.SoapFault: Action
> http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT not supported
> at
> org.apache.cxf.ws.addressing.MAPAggregator.mediate(MAPAggregator.java:461)
> 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.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:110)
> at
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:98)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:423)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:178)
> at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:142)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:647)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3218) apparent regression introduced between 2.2.8 and 2.2.9: http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT not supported
[
https://issues.apache.org/jira/browse/CXF-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-3218.
--
Resolution: Fixed
Fix Version/s: 2.3.2
> apparent regression introduced between 2.2.8 and 2.2.9:
> http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT not supported
> ---
>
> Key: CXF-3218
> URL: https://issues.apache.org/jira/browse/CXF-3218
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.3.1
> Environment: jdk1.6, linux ubuntu 10.10, tomcat 5.5.31.
>Reporter: John J. Franey
>Assignee: Daniel Kulp
> Fix For: 2.3.2
>
> Attachments: scencr.zip
>
>
> This problem shows on 2.3.1 but not in 2.2.8. The problem shows in 2.2.9.
> The code is taken from:
> http://www.ibm.com/developerworks/java/library/j-jws17/index.html
> The only difference between the (soon to be attached) code and the original
> is the cxf home path in build.properties.
> There are two services defined in the code, the failure occurs on only one of
> them: cxf-seismic-scencr.war
> Load that into tomcat and then run the client with: ant run-scencr
> Exception in tomcat catalina log:
> Dec 24, 2010 12:48:19 PM org.apache.cxf.phase.PhaseInterceptorChain
> doDefaultLogging
> WARNING: Interceptor for
> {http://docs.oasis-open.org/ws-sx/ws-trust/200512/wsdl}SecurityTokenService#{http://docs.oasis-open.org/ws-sx/ws-trust/200512/wsdl}RequestSecurityToken
> has thrown exception, unwinding now
> org.apache.cxf.binding.soap.SoapFault: Action
> http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT not supported
> at
> org.apache.cxf.ws.addressing.MAPAggregator.mediate(MAPAggregator.java:461)
> 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.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:110)
> at
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:98)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:423)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:178)
> at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:142)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:647)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DOSGI-87) Declarative Services not registering ExceptionMapper provider
[
https://issues.apache.org/jira/browse/DOSGI-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Williamson updated DOSGI-87:
Attachment: DS_Provider.zip
The .zip contains a working example of the failure of the ExceptionMapper to
register. There are a client and server bundle.
The other bundles in use when this example was created are:
org.eclipse.osgi_3.5.1.R35x_v20090827
org.eclipse.osgi.services_3.2.0.v20090520-1800
org.eclipse.equinox.util_1.0.100.v20090520-1800
org.eclipse.equinox.ds_1.1.0.v20090601
org.apache.servicemix.specs.jsr311-api-1.0_1.3.0
> Declarative Services not registering ExceptionMapper provider
> -
>
> Key: DOSGI-87
> URL: https://issues.apache.org/jira/browse/DOSGI-87
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: DSW
>Affects Versions: 1.1
> Environment: D-OSGi 1.1, Equinox 3.5, Windows XP
>Reporter: Ian Williamson
> Attachments: DS_Provider.zip
>
>
> Greetings,
> I am attempting to setup a custom exception handler through CXF-DOSGi using
> Declarative Services to register my provider.
> My endpoints registration file (for REST) declares the following:
>value="com.MyExceptionClassPath.TestExceptionMapper" />
> (Sergey suggested the following format - it does not solve my issue:
>
> com.MyExceptionClassPath.TestExceptionMapper
>
> )
> The class TestExceptionMapper is defined with the following signature and
> default method:
> package com.MyExceptionClassPath;
> public class TestExceptionMapper implements
> ExceptionMapper {
> public Response toResponse(MyCustomException arg0) {
> return Response.status(Response.Status.FORBIDDEN).build();
> }
> }
> I am using SoapUI to call into my web service and I am trying a test of the
> custom exception provider by simply calling:
> throw new MyCustomException();
> I have a breakpoint set at TestExceptionMapper.toResponse(), but it is never
> hit. Instead, the execution stack just falls through MyCustomException.
> Tracing to ServiceComponent.createInstance(), I see that during a subsequent
> call to ServiceComponentProp.build(), an element of instance
> ComponentInstanceImpl has a ServiceComponentProp.properties hashtable entry
> for provider TestMapperException. Not sure where to go from here.
> I have attached a sample bundle. It is bare bones but should be able to
> convey what I am attempting.
> I must add a common caveat. This is all extremely new to me, so any
> responsdor needs to understand that I do not have a deep background (working
> on it) in this technological field.
> Thanks for any forthcoming assistance.
> Cheers, Ian
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DOSGI-87) Declarative Services not registering ExceptionMapper provider
[
https://issues.apache.org/jira/browse/DOSGI-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Williamson updated DOSGI-87:
Attachment: (was: DS_Provider.zip)
> Declarative Services not registering ExceptionMapper provider
> -
>
> Key: DOSGI-87
> URL: https://issues.apache.org/jira/browse/DOSGI-87
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: DSW
>Affects Versions: 1.1
> Environment: D-OSGi 1.1, Equinox 3.5, Windows XP
>Reporter: Ian Williamson
> Attachments: DS_Provider.zip
>
>
> Greetings,
> I am attempting to setup a custom exception handler through CXF-DOSGi using
> Declarative Services to register my provider.
> My endpoints registration file (for REST) declares the following:
>value="com.MyExceptionClassPath.TestExceptionMapper" />
> (Sergey suggested the following format - it does not solve my issue:
>
> com.MyExceptionClassPath.TestExceptionMapper
>
> )
> The class TestExceptionMapper is defined with the following signature and
> default method:
> package com.MyExceptionClassPath;
> public class TestExceptionMapper implements
> ExceptionMapper {
> public Response toResponse(MyCustomException arg0) {
> return Response.status(Response.Status.FORBIDDEN).build();
> }
> }
> I am using SoapUI to call into my web service and I am trying a test of the
> custom exception provider by simply calling:
> throw new MyCustomException();
> I have a breakpoint set at TestExceptionMapper.toResponse(), but it is never
> hit. Instead, the execution stack just falls through MyCustomException.
> Tracing to ServiceComponent.createInstance(), I see that during a subsequent
> call to ServiceComponentProp.build(), an element of instance
> ComponentInstanceImpl has a ServiceComponentProp.properties hashtable entry
> for provider TestMapperException. Not sure where to go from here.
> I have attached a sample bundle. It is bare bones but should be able to
> convey what I am attempting.
> I must add a common caveat. This is all extremely new to me, so any
> responsdor needs to understand that I do not have a deep background (working
> on it) in this technological field.
> Thanks for any forthcoming assistance.
> Cheers, Ian
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
