[jira] [Closed] (CXF-7884) CXF 3.2.6 creating classes using xjc (WSDL to Java)
[
https://issues.apache.org/jira/browse/CXF-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang closed CXF-7884.
-
Resolution: Not A Problem
> CXF 3.2.6 creating classes using xjc (WSDL to Java)
> ---
>
> Key: CXF-7884
> URL: https://issues.apache.org/jira/browse/CXF-7884
> Project: CXF
> Issue Type: Task
>Reporter: Paul Christopher
>Priority: Major
>
> I am trying to figure out how to generate my classes without the JAXBElement
> and use concreate classes?
>
> Loading FrontEnd jaxws ...
> Loading DataBinding jaxb ...
> wsdl2java -client -d
> C:\liberty_development\workspaces\services\CONWAY_SERVICE_ACCOUNTSPAYABLE_REST\.cxftmp/src
> -classdir
> C:\liberty_development\workspaces\services\CONWAY_SERVICE_ACCOUNTSPAYABLE_REST\WebContent\WEB-INF\classes
> -p
> http://www.con-way.com/BusinessServices/AP/Invoice/V1=com.xpo.ltl.accountspayable.service.ofsinvoice.ws.client
> -b
> C:\liberty_development\workspaces\services\CONWAY_SERVICE_ACCOUNTSPAYABLE_REST\api_specification\Schemas\LTLAPI\LTLAccountsPayableAPI\1.0\jaxb-bindings.xml
> -impl -validate -exsh false -dns false -dex false -wsdlLocation
> file:/C:/liberty_development/workspaces/services/CONWAY_SERVICE_ACCOUNTSPAYABLE_REST/api_specification/Schemas/LTLAPI/LTLAccountsPayableAPI/1.0/OfsInvoicingServices.wsdl
> -verbose -fe jaxws -db jaxb -wv 1.1
> file:/C:/liberty_development/workspaces/services/CONWAY_SERVICE_ACCOUNTSPAYABLE_REST/api_specification/Schemas/LTLAPI/LTLAccountsPayableAPI/1.0/OfsInvoicingServices.wsdl
> wsdl2java - Apache CXF 3.2.6
> Oct 26, 2018 6:59:00 AM org.apache.cxf.wsdl11.WSDLServiceBuilder
> checkForWrapped
> INFO: Operation
> \{http://www.con-way.com/BusinessServices/AP/Invoice/V1}QueryInvoice cannot
> be unwrapped, input message must reference global element declaration with
> same localname as operation
> Oct 26, 2018 6:59:00 AM org.apache.cxf.wsdl11.WSDLServiceBuilder
> checkForWrapped
> INFO: Operation
> \{http://www.con-way.com/BusinessServices/AP/Invoice/V1}CreateInvoice cannot
> be unwrapped, input message must reference global element declaration with
> same localname as operation
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7884) CXF 3.2.6 creating classes using xjc (WSDL to Java)
[
https://issues.apache.org/jira/browse/CXF-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665736#comment-16665736
]
Freeman Fang commented on CXF-7884:
---
Hi Paul,
This kind of question should post to us...@cxf.apache.org mailing list but not
to jira.
Jira ticket is used to track bugs or features.
Thanks!
Freeman
> CXF 3.2.6 creating classes using xjc (WSDL to Java)
> ---
>
> Key: CXF-7884
> URL: https://issues.apache.org/jira/browse/CXF-7884
> Project: CXF
> Issue Type: Task
>Reporter: Paul Christopher
>Priority: Major
>
> I am trying to figure out how to generate my classes without the JAXBElement
> and use concreate classes?
>
> Loading FrontEnd jaxws ...
> Loading DataBinding jaxb ...
> wsdl2java -client -d
> C:\liberty_development\workspaces\services\CONWAY_SERVICE_ACCOUNTSPAYABLE_REST\.cxftmp/src
> -classdir
> C:\liberty_development\workspaces\services\CONWAY_SERVICE_ACCOUNTSPAYABLE_REST\WebContent\WEB-INF\classes
> -p
> http://www.con-way.com/BusinessServices/AP/Invoice/V1=com.xpo.ltl.accountspayable.service.ofsinvoice.ws.client
> -b
> C:\liberty_development\workspaces\services\CONWAY_SERVICE_ACCOUNTSPAYABLE_REST\api_specification\Schemas\LTLAPI\LTLAccountsPayableAPI\1.0\jaxb-bindings.xml
> -impl -validate -exsh false -dns false -dex false -wsdlLocation
> file:/C:/liberty_development/workspaces/services/CONWAY_SERVICE_ACCOUNTSPAYABLE_REST/api_specification/Schemas/LTLAPI/LTLAccountsPayableAPI/1.0/OfsInvoicingServices.wsdl
> -verbose -fe jaxws -db jaxb -wv 1.1
> file:/C:/liberty_development/workspaces/services/CONWAY_SERVICE_ACCOUNTSPAYABLE_REST/api_specification/Schemas/LTLAPI/LTLAccountsPayableAPI/1.0/OfsInvoicingServices.wsdl
> wsdl2java - Apache CXF 3.2.6
> Oct 26, 2018 6:59:00 AM org.apache.cxf.wsdl11.WSDLServiceBuilder
> checkForWrapped
> INFO: Operation
> \{http://www.con-way.com/BusinessServices/AP/Invoice/V1}QueryInvoice cannot
> be unwrapped, input message must reference global element declaration with
> same localname as operation
> Oct 26, 2018 6:59:00 AM org.apache.cxf.wsdl11.WSDLServiceBuilder
> checkForWrapped
> INFO: Operation
> \{http://www.con-way.com/BusinessServices/AP/Invoice/V1}CreateInvoice cannot
> be unwrapped, input message must reference global element declaration with
> same localname as operation
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CXF-7884) CXF 3.2.6 creating classes using xjc (WSDL to Java)
Paul Christopher created CXF-7884:
-
Summary: CXF 3.2.6 creating classes using xjc (WSDL to Java)
Key: CXF-7884
URL: https://issues.apache.org/jira/browse/CXF-7884
Project: CXF
Issue Type: Task
Reporter: Paul Christopher
I am trying to figure out how to generate my classes without the JAXBElement
and use concreate classes?
Loading FrontEnd jaxws ...
Loading DataBinding jaxb ...
wsdl2java -client -d
C:\liberty_development\workspaces\services\CONWAY_SERVICE_ACCOUNTSPAYABLE_REST\.cxftmp/src
-classdir
C:\liberty_development\workspaces\services\CONWAY_SERVICE_ACCOUNTSPAYABLE_REST\WebContent\WEB-INF\classes
-p
http://www.con-way.com/BusinessServices/AP/Invoice/V1=com.xpo.ltl.accountspayable.service.ofsinvoice.ws.client
-b
C:\liberty_development\workspaces\services\CONWAY_SERVICE_ACCOUNTSPAYABLE_REST\api_specification\Schemas\LTLAPI\LTLAccountsPayableAPI\1.0\jaxb-bindings.xml
-impl -validate -exsh false -dns false -dex false -wsdlLocation
file:/C:/liberty_development/workspaces/services/CONWAY_SERVICE_ACCOUNTSPAYABLE_REST/api_specification/Schemas/LTLAPI/LTLAccountsPayableAPI/1.0/OfsInvoicingServices.wsdl
-verbose -fe jaxws -db jaxb -wv 1.1
file:/C:/liberty_development/workspaces/services/CONWAY_SERVICE_ACCOUNTSPAYABLE_REST/api_specification/Schemas/LTLAPI/LTLAccountsPayableAPI/1.0/OfsInvoicingServices.wsdl
wsdl2java - Apache CXF 3.2.6
Oct 26, 2018 6:59:00 AM org.apache.cxf.wsdl11.WSDLServiceBuilder checkForWrapped
INFO: Operation
\{http://www.con-way.com/BusinessServices/AP/Invoice/V1}QueryInvoice cannot be
unwrapped, input message must reference global element declaration with same
localname as operation
Oct 26, 2018 6:59:00 AM org.apache.cxf.wsdl11.WSDLServiceBuilder checkForWrapped
INFO: Operation
\{http://www.con-way.com/BusinessServices/AP/Invoice/V1}CreateInvoice cannot be
unwrapped, input message must reference global element declaration with same
localname as operation
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7883) Handle connectionRequestTimeout in AsyncHTTPConduitFactory
[ https://issues.apache.org/jira/browse/CXF-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665121#comment-16665121 ] ASF GitHub Bot commented on CXF-7883: - gyoetam commented on issue #466: [CXF-7883] fix: handle connectionRequestTimeout in AsyncHTTPConduitFactory URL: https://github.com/apache/cxf/pull/466#issuecomment-433394047 @ffang Thanks for the merge! Do you have a planned release date for 3.2.8 that will include the fix? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Handle connectionRequestTimeout in AsyncHTTPConduitFactory > -- > > Key: CXF-7883 > URL: https://issues.apache.org/jira/browse/CXF-7883 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.2.6 >Reporter: Györgyey Tamás >Assignee: Freeman Fang >Priority: Major > Labels: pull-request-available > Fix For: 3.3.0, 3.2.7 > > > This issue is a follow-up to CXF-7878. > If connections are contended towards a slow target, it may make sense > to set connectionTimeout and connectionRequestTimeout to values much lower > than > the receiveTimeout. Expected client behavior is to receive an error if a > connection > does not become available within connectionRequestTimeout. Current behavior > however > is that the error is only received after up to receiveTimeout has passed, > when a > current request to the target has finished and the connection is released or > returned > to the pool. > This causes a possible build-up of pending requests in memory for the > duration of receiveTimeout instead of connectionRequestTimeout. > See github PR: [https://github.com/apache/cxf/pull/466] > The reference solution in the PR works well, but it may not be the most > elegant one due to my currently limited understanding of the overall design > of the connection handling code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7361) Java 9,10,11 support for CXFAuthenticator
[ https://issues.apache.org/jira/browse/CXF-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang updated CXF-7361: -- Summary: Java 9,10,11 support for CXFAuthenticator (was: Java 9 support for CXFAuthenticator) > Java 9,10,11 support for CXFAuthenticator > - > > Key: CXF-7361 > URL: https://issues.apache.org/jira/browse/CXF-7361 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.11 >Reporter: Romain Manni-Bucau >Assignee: Freeman Fang >Priority: Major > > with java 9, Authenticator getDefault() should be used instead of field.get() > (setAccessible fails) + unsafe should be used to define the class instead > of the failing ClassLoader.defineClass. > All that with reflection of course and in fallback mode probably since for > java 8 it is better to not do it (or it is not available - getDefault() > typically). > Workaround ATM is to call CXFAuthenticator.addAuthenticator(); manually and > ignore the exception, it initializes the instance then it doesn't fail but > the feature is lost until it gets fixed as mentionned before. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7361) Java 9 support for CXFAuthenticator
[ https://issues.apache.org/jira/browse/CXF-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-7361. --- Resolution: Duplicate > Java 9 support for CXFAuthenticator > --- > > Key: CXF-7361 > URL: https://issues.apache.org/jira/browse/CXF-7361 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.11 >Reporter: Romain Manni-Bucau >Assignee: Freeman Fang >Priority: Major > > with java 9, Authenticator getDefault() should be used instead of field.get() > (setAccessible fails) + unsafe should be used to define the class instead > of the failing ClassLoader.defineClass. > All that with reflection of course and in fallback mode probably since for > java 8 it is better to not do it (or it is not available - getDefault() > typically). > Workaround ATM is to call CXFAuthenticator.addAuthenticator(); manually and > ignore the exception, it initializes the instance then it doesn't fail but > the feature is lost until it gets fixed as mentionned before. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7361) Java 9 support for CXFAuthenticator
[
https://issues.apache.org/jira/browse/CXF-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664861#comment-16664861
]
Freeman Fang commented on CXF-7361:
---
Yep, it can pass with
{code}
WARNING: Illegal reflective access
{code}
I'm trying to fix the WARNING.
CXF-7838 tracked this.
I will close this issue for now.
> Java 9 support for CXFAuthenticator
> ---
>
> Key: CXF-7361
> URL: https://issues.apache.org/jira/browse/CXF-7361
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 3.1.11
>Reporter: Romain Manni-Bucau
>Assignee: Freeman Fang
>Priority: Major
>
> with java 9, Authenticator getDefault() should be used instead of field.get()
> (setAccessible fails) + unsafe should be used to define the class instead
> of the failing ClassLoader.defineClass.
> All that with reflection of course and in fallback mode probably since for
> java 8 it is better to not do it (or it is not available - getDefault()
> typically).
> Workaround ATM is to call CXFAuthenticator.addAuthenticator(); manually and
> ignore the exception, it initializes the instance then it doesn't fail but
> the feature is lost until it gets fixed as mentionned before.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7838) Remove illegal reflective access in ReflectionUtil
[
https://issues.apache.org/jira/browse/CXF-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664856#comment-16664856
]
Freeman Fang commented on CXF-7838:
---
OK, I can see the
{code}
WARNING: Illegal reflective access by
org.apache.cxf.common.util.ReflectionUtil$11 (file:./lib/cxf-core-3.2.6.jar) to
method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int)
{code}
after I fixed the
{code}
WARNING: Illegal reflective access by
org.apache.cxf.common.util.ReflectionUtil$11 (file:./lib/cxf-core-3.2.6.jar) to
field java.net.Authenticator.theAuthenticator
{code}
And I have a fix on the way... running more test now.
Freeman
> Remove illegal reflective access in ReflectionUtil
> --
>
> Key: CXF-7838
> URL: https://issues.apache.org/jira/browse/CXF-7838
> Project: CXF
> Issue Type: Task
>Reporter: Tim Allison
>Assignee: Freeman Fang
>Priority: Major
>
> Apologies if this is a duplicate. We're about to upgrade to 3.2.6 on Apache
> Tika, and we're still getting the following when we run our unit tests with
> Java 11.
> {quote}Illegal reflective access by
> org.apache.cxf.common.util.ReflectionUtil$11
> ([file:.m2/repository/org/apache/cxf/cxf-core/3.2.6/cxf-core-3.2.6.jar|file://.m2/repository/org/apache/cxf/cxf-core/3.2.6/cxf-core-3.2.6.jar])
> to field java.net.Authenticator.theAuthenticator
> WARNING: Please consider reporting this to the maintainers of
> org.apache.cxf.common.util.ReflectionUtil$11
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> {quote}
> Let us know if you need more info to solve this. Thank you!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7361) Java 9 support for CXFAuthenticator
[
https://issues.apache.org/jira/browse/CXF-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664731#comment-16664731
]
Freeman Fang commented on CXF-7361:
---
Hi Romain,
I'm a little bit confused.
Currently CXFAuthenticator just use Classloader defineClass, but you mentioned
{code}
unsafe should be used to define the class instead of the failing
ClassLoader.defineClass.
{code}
when you reported this problem.
Could you please elaborate it?
Thanks!
Freeman
> Java 9 support for CXFAuthenticator
> ---
>
> Key: CXF-7361
> URL: https://issues.apache.org/jira/browse/CXF-7361
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 3.1.11
>Reporter: Romain Manni-Bucau
>Assignee: Freeman Fang
>Priority: Major
>
> with java 9, Authenticator getDefault() should be used instead of field.get()
> (setAccessible fails) + unsafe should be used to define the class instead
> of the failing ClassLoader.defineClass.
> All that with reflection of course and in fallback mode probably since for
> java 8 it is better to not do it (or it is not available - getDefault()
> typically).
> Workaround ATM is to call CXFAuthenticator.addAuthenticator(); manually and
> ignore the exception, it initializes the instance then it doesn't fail but
> the feature is lost until it gets fixed as mentionned before.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7361) Java 9 support for CXFAuthenticator
[ https://issues.apache.org/jira/browse/CXF-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664722#comment-16664722 ] Romain Manni-Bucau commented on CXF-7361: - Or classloader defineClass which is used in EE libs. Works well for not named modules. > Java 9 support for CXFAuthenticator > --- > > Key: CXF-7361 > URL: https://issues.apache.org/jira/browse/CXF-7361 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.11 >Reporter: Romain Manni-Bucau >Assignee: Freeman Fang >Priority: Major > > with java 9, Authenticator getDefault() should be used instead of field.get() > (setAccessible fails) + unsafe should be used to define the class instead > of the failing ClassLoader.defineClass. > All that with reflection of course and in fallback mode probably since for > java 8 it is better to not do it (or it is not available - getDefault() > typically). > Workaround ATM is to call CXFAuthenticator.addAuthenticator(); manually and > ignore the exception, it initializes the instance then it doesn't fail but > the feature is lost until it gets fixed as mentionned before. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
