[jira] [Created] (CXF-3770) WADL Generator does not handle Enums correctly
WADL Generator does not handle Enums correctly -- Key: CXF-3770 URL: https://issues.apache.org/jira/browse/CXF-3770 Project: CXF Issue Type: Bug Components: JAX-RS Reporter: Sergey Beryozkin WADL generator should print multiple options when dealing with Enum -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-3769) Update WADL2Java generator to accept additional args
[ https://issues.apache.org/jira/browse/CXF-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-3769. --- Resolution: Fixed Support for additional xjc params will be added on demand > Update WADL2Java generator to accept additional args > - > > Key: CXF-3769 > URL: https://issues.apache.org/jira/browse/CXF-3769 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 2.4.2 >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 2.4.3, 2.5 > > > One example is when custom bindings such as W3CEPR bindings need to be > enabled, when the generated code is shared by soap and rs impls -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3756) wadl2java ignores multiple inline XML schemas
[
https://issues.apache.org/jira/browse/CXF-3756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092085#comment-13092085
]
Glen Mazza commented on CXF-3756:
-
Oh. I like #grammar then.
> wadl2java ignores multiple inline XML schemas
> -
>
> Key: CXF-3756
> URL: https://issues.apache.org/jira/browse/CXF-3756
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.4.2
>Reporter: metatech
>Assignee: Sergey Beryozkin
> Fix For: 2.4.3, 2.5
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> When generating classes from a WADL, if multiple inline XML schemas are
> present in the file, they are ignored, only the last one is taken into
> account.
> This seems to happen because multiple schemas have the same SystemID, which
> are later parsed by the
> com.sun.tools.xjc.api.SchemaCompiler.parseSchema(String systemId, Element
> element) method, which documents that the SystemID should be made unique.
> I followed this advice and added the targetNamespace to the SystemID, and now
> classes for all schemas are generated.
> In method SourceGenerator.getSchemaElements(...)
> ==
> for (Element schemaEl : schemasEls) {
> String targetNS = schemaEl.getAttribute("targetNamespace");
> schemas.add(createSchemaInfo(schemaEl, app.getWadlPath() + "#" +
> targetNS));
> }
> Could you please apply this contribution if you think it makes sense.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3756) wadl2java ignores multiple inline XML schemas
[
https://issues.apache.org/jira/browse/CXF-3756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092077#comment-13092077
]
Sergey Beryozkin commented on CXF-3756:
---
Hi Glen, yes I was thinking about "#types", but assumed that convention came
from the fact that in WSDL a 'types' container tag is used to group
schemas, in WADL - it's a grammar tag, so for the moment I'd like to name it as
"#grammars" - just to align it with WADL's application:grammar.
We can easily switch it to #types
thanks
> wadl2java ignores multiple inline XML schemas
> -
>
> Key: CXF-3756
> URL: https://issues.apache.org/jira/browse/CXF-3756
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.4.2
>Reporter: metatech
>Assignee: Sergey Beryozkin
> Fix For: 2.4.3, 2.5
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> When generating classes from a WADL, if multiple inline XML schemas are
> present in the file, they are ignored, only the last one is taken into
> account.
> This seems to happen because multiple schemas have the same SystemID, which
> are later parsed by the
> com.sun.tools.xjc.api.SchemaCompiler.parseSchema(String systemId, Element
> element) method, which documents that the SystemID should be made unique.
> I followed this advice and added the targetNamespace to the SystemID, and now
> classes for all schemas are generated.
> In method SourceGenerator.getSchemaElements(...)
> ==
> for (Element schemaEl : schemasEls) {
> String targetNS = schemaEl.getAttribute("targetNamespace");
> schemas.add(createSchemaInfo(schemaEl, app.getWadlPath() + "#" +
> targetNS));
> }
> Could you please apply this contribution if you think it makes sense.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3756) wadl2java ignores multiple inline XML schemas
[
https://issues.apache.org/jira/browse/CXF-3756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092021#comment-13092021
]
Glen Mazza commented on CXF-3756:
-
Unsure if I'm mixing apples and oranges here, but I wonder if it would be
better to use the same naming standard already done by CXF's JAX-WS
implementation (types1, types2, etc.) See:
http://www.jroller.com/gmazza/entry/customizing_jaxb_artifacts#BindingFile.
Not that big a deal, just mentioning it.
> wadl2java ignores multiple inline XML schemas
> -
>
> Key: CXF-3756
> URL: https://issues.apache.org/jira/browse/CXF-3756
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.4.2
>Reporter: metatech
>Assignee: Sergey Beryozkin
> Fix For: 2.4.3, 2.5
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> When generating classes from a WADL, if multiple inline XML schemas are
> present in the file, they are ignored, only the last one is taken into
> account.
> This seems to happen because multiple schemas have the same SystemID, which
> are later parsed by the
> com.sun.tools.xjc.api.SchemaCompiler.parseSchema(String systemId, Element
> element) method, which documents that the SystemID should be made unique.
> I followed this advice and added the targetNamespace to the SystemID, and now
> classes for all schemas are generated.
> In method SourceGenerator.getSchemaElements(...)
> ==
> for (Element schemaEl : schemasEls) {
> String targetNS = schemaEl.getAttribute("targetNamespace");
> schemas.add(createSchemaInfo(schemaEl, app.getWadlPath() + "#" +
> targetNS));
> }
> Could you please apply this contribution if you think it makes sense.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-3762) Add an -exceptionSuper flag, allowing wsdl2java to generate exceptions which extend from java.lang.RuntimeException
[ https://issues.apache.org/jira/browse/CXF-3762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-3762. -- Resolution: Fixed Fix Version/s: 2.4.3 >From a spec compliance thing, I'm not concerned. This is a non-default flag. > It may prevent complete round tripping of wsdl -> java -> wsdl, but if you >use the original wsdl at runtime, it should work fine. That said, I did modify it a bit. I made no attempt to load the exception class at code generation time. The main reason is that if you are generating code into the maven module that also defines the exception, it won't work. By not checking, it delays the checking to the compile step, but that should be OK. > Add an -exceptionSuper flag, allowing wsdl2java to generate exceptions which > extend from java.lang.RuntimeException > --- > > Key: CXF-3762 > URL: https://issues.apache.org/jira/browse/CXF-3762 > Project: CXF > Issue Type: New Feature > Components: Tooling >Affects Versions: 2.4.2 >Reporter: aaron pieper >Assignee: Daniel Kulp > Labels: jaxb, wsdl2java > Fix For: 2.4.3 > > Attachments: patch.txt > > > When using CXF's wsdl2java tool, generated exceptions always extend > java.lang.Exception. It would be nice if exceptions could optionally extend > java.lang.RuntimeException instead. This could be accomplished by adding a > flag like -exceptionSuper= on the wsdl2java tool, which would allow us to > specify our own superclass. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-3763) CLONE - JaxWsDynamicClientFactory unable to handle custom exceptions
[
https://issues.apache.org/jira/browse/CXF-3763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-3763.
--
Resolution: Fixed
Fix Version/s: 2.4.3
Patch applied. Thanks!
> CLONE - JaxWsDynamicClientFactory unable to handle custom exceptions
>
>
> Key: CXF-3763
> URL: https://issues.apache.org/jira/browse/CXF-3763
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.4.2
> Environment: Windows OS with tomcat server
>Reporter: Esteban Salazar
>Assignee: Daniel Kulp
> Fix For: 2.4.3
>
> Attachments: TypeClassInitializer.java.patch
>
>
> When server throws a custom exception client is showing a
> NULLPointerException and returning a SoapFault with the error message thrown
> by the server. But the expected output should be the custom exception.
> Below is the full stack trace.
> Nov 21, 2009 11:25:01 AM org.apache.cxf.bus.spring.BusApplicationContext
> getConfigResources
> INFO: No cxf.xml configuration file detected, relying on defaults.
> Nov 21, 2009 11:25:03 AM org.apache.cxf.endpoint.dynamic.DynamicClientFactory
> outputDebug
> INFO: Created classes: contactus.CxCSWebserviceExcpetion123,
> contactus.ObjectFactory, contactus.PostMessage, contactus.PostMessageResponse
> Nov 21, 2009 11:25:05 AM org.apache.cxf.interceptor.ClientFaultConverter
> processFaultDetail
> INFO: Exception occurred while creating exception: null
> java.lang.NullPointerException
> at
> org.apache.cxf.interceptor.ClientFaultConverter.getConstructor(ClientFaultConverter.java:182)
> at
> org.apache.cxf.interceptor.ClientFaultConverter.processFaultDetail(ClientFaultConverter.java:154)
> at
> org.apache.cxf.interceptor.ClientFaultConverter.handleMessage(ClientFaultConverter.java:74)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
> at
> org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:96)
> at
> org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69)
> at
> org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:658)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2139)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2022)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1947)
> at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:632)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:472)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:302)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:254)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:274)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:260)
> at
> com.chordiant.cs.scheduler.client.CXFDynamicContactClient.main(CXFDynamicContactClient.java:23)
> org.apache.cxf.binding.soap.SoapFault: Exception from postMessages
> Here is the client Code.
> try
> {
> JaxWsDynamicClientFactory dcf =
> JaxWsDynamicClientFactory.newInstance();
> Client client =
> dcf.createClient("http://localhost:8080/contactUs/contactus?wsdl";,
> Thread.currentThread().getContextClassLoader());
> client.invoke("postMessage", "test");
> }
> catch(Exception e){
> System.out.println(e);
> }
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CXF-3762) Add an -exceptionSuper flag, allowing wsdl2java to generate exceptions which extend from java.lang.RuntimeException
[ https://issues.apache.org/jira/browse/CXF-3762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp reassigned CXF-3762: Assignee: Daniel Kulp > Add an -exceptionSuper flag, allowing wsdl2java to generate exceptions which > extend from java.lang.RuntimeException > --- > > Key: CXF-3762 > URL: https://issues.apache.org/jira/browse/CXF-3762 > Project: CXF > Issue Type: New Feature > Components: Tooling >Affects Versions: 2.4.2 >Reporter: aaron pieper >Assignee: Daniel Kulp > Labels: jaxb, wsdl2java > Attachments: patch.txt > > > When using CXF's wsdl2java tool, generated exceptions always extend > java.lang.Exception. It would be nice if exceptions could optionally extend > java.lang.RuntimeException instead. This could be accomplished by adding a > flag like -exceptionSuper= on the wsdl2java tool, which would allow us to > specify our own superclass. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3765) CXF features should use version range for features provided by Karaf
[ https://issues.apache.org/jira/browse/CXF-3765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13091968#comment-13091968 ] Jean-Baptiste Onofré commented on CXF-3765: --- CXF spring-jms feature doesn't install because spring-jms bundle requires 3.0.6.RELEASE version (it doesn't use version range). It means that CXF-3766 should be fix first. > CXF features should use version range for features provided by Karaf > > > Key: CXF-3765 > URL: https://issues.apache.org/jira/browse/CXF-3765 > Project: CXF > Issue Type: Improvement > Components: OSGi >Affects Versions: 2.4.2 >Reporter: Jean-Baptiste Onofré > Fix For: 2.4.3, 2.5 > > > Currently, CXF features use specific version for spring and spring-dm > features. > It means that if CXF upgrade to a new Spring version, if Karaf doesn't update > to the same version, CXF won't be installable in Karaf. > To avoid this situation, CXF should use version range for features provided > by Karaf. > I'm gonna provide a patch for that. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3769) Update WADL2Java generator to accept additional args
Update WADL2Java generator to accept additional args - Key: CXF-3769 URL: https://issues.apache.org/jira/browse/CXF-3769 Project: CXF Issue Type: Improvement Components: JAX-RS Affects Versions: 2.4.2 Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Fix For: 2.4.3, 2.5 One example is when custom bindings such as W3CEPR bindings need to be enabled, when the generated code is shared by soap and rs impls -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3768) HTTP response code 202 is not set for WS-Addressing partial responses
HTTP response code 202 is not set for WS-Addressing partial responses
-
Key: CXF-3768
URL: https://issues.apache.org/jira/browse/CXF-3768
Project: CXF
Issue Type: Bug
Components: WS-* Components
Affects Versions: 2.4.2
Reporter: Dmytro Rud
When asyncronous processing is requested by specifying an endpoint reference in
the request's ReplyTo WSA header, an immediate acknowledgement should be sent
with HTTP code 202. Older CXF versions (e.g. 2.2.11) implemented this
requirement in the method
{{org.apache.cxf.transport.http.AbstractHTTPDestination#markPartialResponse}},
but the newer ones (2.4.1, 2.4.2) do not set the HTTP response code
explicitely, therefore acknowledgements are delivered with code 200.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3767) Support the ability to sign and encrypt message parts using a Kerberos Ticket
Support the ability to sign and encrypt message parts using a Kerberos Ticket - Key: CXF-3767 URL: https://issues.apache.org/jira/browse/CXF-3767 Project: CXF Issue Type: Improvement Affects Versions: 2.4.2 Reporter: Colm O hEigeartaigh -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3767) Support the ability to sign and encrypt message parts using a Kerberos Ticket
[ https://issues.apache.org/jira/browse/CXF-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-3767: - Description: This task is to support using a Kerberos Ticket to sign and encrypt a request. Support for the Kerberos Token Profile was added in CXF 2.4.2 but only to obtain a Kerberos Ticket, wrap it in a BinarySecurityToken, and process it at the other side. Fix Version/s: 2.5 2.4.3 Assignee: Colm O hEigeartaigh > Support the ability to sign and encrypt message parts using a Kerberos Ticket > - > > Key: CXF-3767 > URL: https://issues.apache.org/jira/browse/CXF-3767 > Project: CXF > Issue Type: Improvement >Affects Versions: 2.4.2 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.4.3, 2.5 > > > This task is to support using a Kerberos Ticket to sign and encrypt a > request. Support for the Kerberos Token Profile was added in CXF 2.4.2 but > only to obtain a Kerberos Ticket, wrap it in a BinarySecurityToken, and > process it at the other side. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3766) Move the spring-jms feature into Karaf
[ https://issues.apache.org/jira/browse/CXF-3766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13091766#comment-13091766 ] Jean-Baptiste Onofré commented on CXF-3766: --- As soon as I made the change in Karaf, I will submit the CXF patch. > Move the spring-jms feature into Karaf > -- > > Key: CXF-3766 > URL: https://issues.apache.org/jira/browse/CXF-3766 > Project: CXF > Issue Type: Improvement > Components: OSGi >Reporter: Jean-Baptiste Onofré > Fix For: 2.4.3, 2.5 > > > As Karaf already provides spring and spring-jms features, it makes sense to > also provide the spring-jms one. > CXF will use this Karaf spring-jms feature. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3766) Move the spring-jms feature into Karaf
Move the spring-jms feature into Karaf -- Key: CXF-3766 URL: https://issues.apache.org/jira/browse/CXF-3766 Project: CXF Issue Type: Improvement Components: OSGi Reporter: Jean-Baptiste Onofré Fix For: 2.4.3, 2.5 As Karaf already provides spring and spring-jms features, it makes sense to also provide the spring-jms one. CXF will use this Karaf spring-jms feature. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3765) CXF features should use version range for features provided by Karaf
CXF features should use version range for features provided by Karaf Key: CXF-3765 URL: https://issues.apache.org/jira/browse/CXF-3765 Project: CXF Issue Type: Improvement Components: OSGi Affects Versions: 2.4.2 Reporter: Jean-Baptiste Onofré Fix For: 2.4.3, 2.5 Currently, CXF features use specific version for spring and spring-dm features. It means that if CXF upgrade to a new Spring version, if Karaf doesn't update to the same version, CXF won't be installable in Karaf. To avoid this situation, CXF should use version range for features provided by Karaf. I'm gonna provide a patch for that. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-3759) wadl2java fails with NullPointerException if status codes of multiple response elements are not in ascending numerical order
[ https://issues.apache.org/jira/browse/CXF-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-3759. --- Resolution: Fixed Fix Version/s: 2.5 2.4.3 Assignee: Sergey Beryozkin > wadl2java fails with NullPointerException if status codes of multiple > response elements are not in ascending numerical order > > > Key: CXF-3759 > URL: https://issues.apache.org/jira/browse/CXF-3759 > Project: CXF > Issue Type: Bug >Affects Versions: 2.4.2 >Reporter: Oliver Jelinski >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 2.4.3, 2.5 > > > Strangely, if I have the status codes in the response not in ascending order > in the wadl-document, wadl2java fails with NPE. > For example the following works correctly: > >xmlns="http://wadl.dev.java.net/2009/02"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://wadl.dev.java.net/2009/02 wadl.xsd" > > http://localhost:9900/MyService";> > > > > > > > > > > ... while the following doesn't: > >xmlns="http://wadl.dev.java.net/2009/02"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://wadl.dev.java.net/2009/02 wadl.xsd" > > http://localhost:9900/MyService";> > > > > > > > > > > ... but throws the following exception: > [ERROR] Failed to execute goal > org.apache.cxf:cxf-wadl2java-plugin:2.4.2:wadl2java (generate-sources) on > project XXX: java.lang.NullPointerException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.cxf:cxf-wadl2java-plugin:2.4.2:wadl2java (generate-sources) > on project XXX: java.lang.NullPointerException > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > 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) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: > java.lang.NullPointerException > at > org.apache.cxf.maven_plugin.wadlto.AbstractCodeGeneratorMojo.callCodeGenerator(AbstractCodeGeneratorMojo.java:458) > at > org.apache.cxf.maven_plugin.wadlto.WADL2JavaMojo.execute(WADL2JavaMojo.java:101) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > ... 19 more > Caused by: org.apache.cxf.tools.common.ToolException: > java.lang.NullPointerException > at > org.apache.cxf.tools.wadlto.jaxrs.JAXRSContainer.execute(JAXRSContainer.java:75) > at > org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:103) > at org.apache.cxf.tools.wadlto.WADLToJava.run(WADLToJava.java:65) > at org.apache.cxf.tools.wadlto.WADLToJava.run(WADLToJava.java:57) > at > org.apache.cxf.maven_plugin.wadlto.AbstractCodeGeneratorMojo.callCodeGenerator(AbstractCodeGeneratorMojo.java:45
[jira] [Resolved] (CXF-3756) wadl2java ignores multiple inline XML schemas
[
https://issues.apache.org/jira/browse/CXF-3756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-3756.
---
Resolution: Fixed
Fix Version/s: 2.5
2.4.3
Assignee: Sergey Beryozkin
I updated a code to append "#grammar1", "#grammar2", etc -
that will make it easier to refer to inlined schemas from jaxb binding files
thanks
> wadl2java ignores multiple inline XML schemas
> -
>
> Key: CXF-3756
> URL: https://issues.apache.org/jira/browse/CXF-3756
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.4.2
>Reporter: metatech
>Assignee: Sergey Beryozkin
> Fix For: 2.4.3, 2.5
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> When generating classes from a WADL, if multiple inline XML schemas are
> present in the file, they are ignored, only the last one is taken into
> account.
> This seems to happen because multiple schemas have the same SystemID, which
> are later parsed by the
> com.sun.tools.xjc.api.SchemaCompiler.parseSchema(String systemId, Element
> element) method, which documents that the SystemID should be made unique.
> I followed this advice and added the targetNamespace to the SystemID, and now
> classes for all schemas are generated.
> In method SourceGenerator.getSchemaElements(...)
> ==
> for (Element schemaEl : schemasEls) {
> String targetNS = schemaEl.getAttribute("targetNamespace");
> schemas.add(createSchemaInfo(schemaEl, app.getWadlPath() + "#" +
> targetNS));
> }
> Could you please apply this contribution if you think it makes sense.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3764) JARS does not respect encoding when reading application/x-www-form-urlencoded;charset=Iso-8859-1 parameters
JARS does not respect encoding when reading
application/x-www-form-urlencoded;charset=Iso-8859-1 parameters
---
Key: CXF-3764
URL: https://issues.apache.org/jira/browse/CXF-3764
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.4.2
Reporter: Marc Giger
JAXRS calls UrlUtils.urlDecode(value);
which has hardcoded UTF-8 as encoding:
public static String urlDecode(String value) {
try {
value = URLDecoder.decode(value, "UTF-8");
} catch (UnsupportedEncodingException e) {
LOG.warning("UTF-8 encoding can not be used to decode " + value);
}
return value;
}
I've provided the stack trace so that you can see which path it went through:
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1206)
at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:53)
at org.apache.cxf.jaxrs.utils.HttpUtils.urlDecode(HttpUtils.java:72)
at
org.apache.cxf.jaxrs.utils.FormUtils.populateMapFromString(FormUtils.java:85)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.processFormParam(JAXRSUtils.java:732)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.createHttpParameterValue(JAXRSUtils.java:659)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameter(JAXRSUtils.java:617)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameters(JAXRSUtils.java:571)
at
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:230)
at
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:88)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:118)
at
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:208)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:223)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:166)
at
org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:113)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:184)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:163)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
