[jira] [Commented] (CXF-7186) Aegis DataBinding ignores JAXB annotations on a field
[ https://issues.apache.org/jira/browse/CXF-7186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15764113#comment-15764113 ] Daniel Kulp commented on CXF-7186: -- Out of curiosity: if you have a schema for the data, why are you using Aegis instead of JAXB? Aegis is really just for "java first" cases. It's not designed to support the full set of JAXB annotations. > Aegis DataBinding ignores JAXB annotations on a field > - > > Key: CXF-7186 > URL: https://issues.apache.org/jira/browse/CXF-7186 > Project: CXF > Issue Type: Bug > Components: Aegis Databinding >Affects Versions: 2.7.18 >Reporter: Sanjin Tulac > Attachments: CXF Aegis Data Binding.png, CXF-7186.patch > > > I've been trying to use CXF with Aegis DataBinding to host a web service that > needs to be called by a 3rd party, using 3rd party's XML schema. > It turns out that 3rd party XML schema has a naming convention that element > names start with upper case. wsdl2java correctly placed JAXB XMLElement > annotations on the fields in the generated POJOs, But at run-time, Aegis > DataBinding ignores these JAXB annotations on the fields, which causes the > XML from 3rd party to be ignored, instead of converted to the generated POJOs. > I've identified the culprit to be > org.apache.cxf.aegist.type.AnnotatedTypeInfo class, whose method createQName > only looks for annotations on the getter methods, but ignores annotations on > fields. > I can see that this defect stems from the attempt to support both Aegis and > JAXB annotations: former expect annotations on the getter methods, but latter > however, even though quite similar, expect annotations on the field. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DOSGI-252) Unable to export RS services with same addresses and different contexts
[
https://issues.apache.org/jira/browse/DOSGI-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider reassigned DOSGI-252:
-
Assignee: Christian Schneider
> Unable to export RS services with same addresses and different contexts
> ---
>
> Key: DOSGI-252
> URL: https://issues.apache.org/jira/browse/DOSGI-252
> Project: CXF Distributed OSGi
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Dmytro Pishchukhin
>Assignee: Christian Schneider
>
> I've tried to export RS services with such urls:
> {noformat}
> http://:/service1/v1
> http://:/service2/v1
> {noformat}
> if I use only
> {noformat}
> org.apache.cxf.rs.httpservice.context=/service1/v1
> org.apache.cxf.rs.httpservice.context=/service2/v1
> {noformat}
> I receive an exception
> {noformat}
> org.apache.cxf.service.factory.ServiceConstructionException
> at
> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:219)
> ...
> Caused by: org.apache.cxf.service.factory.ServiceConstructionException: There
> is an endpoint already running on /.
> at
> org.apache.cxf.jaxrs.JAXRSBindingFactory.addListener(JAXRSBindingFactory.java:85)
> {noformat}
> If I use
> {noformat}
> org.apache.cxf.rs.httpservice.context=/service1
> org.apache.cxf.rs.address=/v1
> org.apache.cxf.rs.httpservice.context=/service2
> org.apache.cxf.rs.address=/v1
> {noformat}
> I receive another exception
> {noformat}
> org.apache.cxf.service.factory.ServiceConstructionException
> at
> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:219)
> ...
> Caused by: org.apache.cxf.service.factory.ServiceConstructionException: There
> is an endpoint already running on /v1.
> at
> org.apache.cxf.jaxrs.JAXRSBindingFactory.addListener(JAXRSBindingFactory.java:85)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FEDIZ-185) Make one of passiveRequestorEndpoint or passiveRequestorEndpointConstraint mandatory in the IDP
Colm O hEigeartaigh created FEDIZ-185: - Summary: Make one of passiveRequestorEndpoint or passiveRequestorEndpointConstraint mandatory in the IDP Key: FEDIZ-185 URL: https://issues.apache.org/jira/browse/FEDIZ-185 Project: CXF-Fediz Issue Type: Bug Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 1.3.2, 1.2.4, 1.4.0 This task is to make one of passiveRequestorEndpoint or passiveRequestorEndpointConstraint mandatory in the IDP. This guarantees that the "wreply" address presented by the client is valid. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FEDIZ-185) Make one of passiveRequestorEndpoint or passiveRequestorEndpointConstraint mandatory in the IDP
[ https://issues.apache.org/jira/browse/FEDIZ-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved FEDIZ-185. --- Resolution: Fixed > Make one of passiveRequestorEndpoint or passiveRequestorEndpointConstraint > mandatory in the IDP > --- > > Key: FEDIZ-185 > URL: https://issues.apache.org/jira/browse/FEDIZ-185 > Project: CXF-Fediz > Issue Type: Bug >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 1.3.2, 1.2.4, 1.4.0 > > > This task is to make one of passiveRequestorEndpoint or > passiveRequestorEndpointConstraint mandatory in the IDP. This guarantees that > the "wreply" address presented by the client is valid. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7188) javax.xml.bind.annotation.XmlEnumValue annotation should be honored in Aegis data binding
[
https://issues.apache.org/jira/browse/CXF-7188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15765081#comment-15765081
]
Sanjin Tulac commented on CXF-7188:
---
I've checked the fix for this defect (on top of the fix for CXF-7186) in
https://github.com/SanjinTulac/cxf/commit/24adedf854516cacc9b6b50f3d0cf7500171fc19.
This is in 2.7.x-fixes branch.
My (still open) pull request https://github.com/apache/cxf/pull/216 now
contains fixes for both CXF-7186 and CXF-7188.
> javax.xml.bind.annotation.XmlEnumValue annotation should be honored in Aegis
> data binding
> -
>
> Key: CXF-7188
> URL: https://issues.apache.org/jira/browse/CXF-7188
> Project: CXF
> Issue Type: Bug
> Components: Aegis Databinding
>Affects Versions: 2.7.18
>Reporter: Sanjin Tulac
>
> I've been trying to use CXF with Aegis DataBinding to host a web service that
> needs to be called by a 3rd party, using 3rd party's XML schema.
> 3rd party XML schema uses enumeration where values have first character
> upper-case, and the rest is lower-case, e.g., "Completed".
> From this XML schema, wsdl2java correctly creates the following Java enum
> value using javax.xml.bind.annotation.XmlEnumValue annotation :
> {code}
> @XmlEnumValue("Completed")
> COMPLETED("Completed")
> {code}.
> However, when a web service is exposed that uses this enum, WSDL shows that
> this service expects values all in uppercase, e.g.,:
> {code}
>
> {code}
> The same problem is also encountered at run-time. E.g., when XML complying to
> 3rd party XML schema is being converted to a Java object, the web service
> returns:
> {code}
> Illegal argument. No enum constant .Completed.
> {code}
> I've encountered this defect on v. 2.7.18, but I've been able to reproduce it
> on the 3.2.0 snapshot from Dec 12th 2016 (master branch as of commit
> b49075882641fcebbbdf1ed8d84247fcf80aa558)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-7188) javax.xml.bind.annotation.XmlEnumValue annotation should be honored in Aegis data binding
[
https://issues.apache.org/jira/browse/CXF-7188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjin Tulac updated CXF-7188:
--
Affects Version/s: 3.1.9
3.0.12
> javax.xml.bind.annotation.XmlEnumValue annotation should be honored in Aegis
> data binding
> -
>
> Key: CXF-7188
> URL: https://issues.apache.org/jira/browse/CXF-7188
> Project: CXF
> Issue Type: Bug
> Components: Aegis Databinding
>Affects Versions: 2.7.18, 3.1.9, 3.0.12
>Reporter: Sanjin Tulac
>
> I've been trying to use CXF with Aegis DataBinding to host a web service that
> needs to be called by a 3rd party, using 3rd party's XML schema.
> 3rd party XML schema uses enumeration where values have first character
> upper-case, and the rest is lower-case, e.g., "Completed".
> From this XML schema, wsdl2java correctly creates the following Java enum
> value using javax.xml.bind.annotation.XmlEnumValue annotation :
> {code}
> @XmlEnumValue("Completed")
> COMPLETED("Completed")
> {code}.
> However, when a web service is exposed that uses this enum, WSDL shows that
> this service expects values all in uppercase, e.g.,:
> {code}
>
> {code}
> The same problem is also encountered at run-time. E.g., when XML complying to
> 3rd party XML schema is being converted to a Java object, the web service
> returns:
> {code}
> Illegal argument. No enum constant .Completed.
> {code}
> I've encountered this defect on v. 2.7.18, but I've been able to reproduce it
> on the 3.2.0 snapshot from Dec 12th 2016 (master branch as of commit
> b49075882641fcebbbdf1ed8d84247fcf80aa558)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-7186) Aegis DataBinding ignores JAXB annotations on a field
[ https://issues.apache.org/jira/browse/CXF-7186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjin Tulac updated CXF-7186: -- Affects Version/s: 3.1.9 3.0.12 > Aegis DataBinding ignores JAXB annotations on a field > - > > Key: CXF-7186 > URL: https://issues.apache.org/jira/browse/CXF-7186 > Project: CXF > Issue Type: Bug > Components: Aegis Databinding >Affects Versions: 2.7.18, 3.1.9, 3.0.12 >Reporter: Sanjin Tulac > Attachments: CXF Aegis Data Binding.png, CXF-7186.patch > > > I've been trying to use CXF with Aegis DataBinding to host a web service that > needs to be called by a 3rd party, using 3rd party's XML schema. > It turns out that 3rd party XML schema has a naming convention that element > names start with upper case. wsdl2java correctly placed JAXB XMLElement > annotations on the fields in the generated POJOs, But at run-time, Aegis > DataBinding ignores these JAXB annotations on the fields, which causes the > XML from 3rd party to be ignored, instead of converted to the generated POJOs. > I've identified the culprit to be > org.apache.cxf.aegist.type.AnnotatedTypeInfo class, whose method createQName > only looks for annotations on the getter methods, but ignores annotations on > fields. > I can see that this defect stems from the attempt to support both Aegis and > JAXB annotations: former expect annotations on the getter methods, but latter > however, even though quite similar, expect annotations on the field. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7186) Aegis DataBinding ignores JAXB annotations on a field
[ https://issues.apache.org/jira/browse/CXF-7186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15765105#comment-15765105 ] Sanjin Tulac commented on CXF-7186: --- We're using Aegis primarily for historical reasons - development of CodeObjects "model-driven" application-development platform started back in 2006 when CXF was XFire and (AFAIK) JAXB was not yet a viable option. We have customized serialization of SDO-based data, so moving to JAXB data binding would require unknown amount of work and has significant risks associated with it. But it does seem at this point as if we'd be better off switching to JAXB databinding, especially for this particular use case, where we need to implement against 3rd party XML schema. > Aegis DataBinding ignores JAXB annotations on a field > - > > Key: CXF-7186 > URL: https://issues.apache.org/jira/browse/CXF-7186 > Project: CXF > Issue Type: Bug > Components: Aegis Databinding >Affects Versions: 2.7.18, 3.1.9, 3.0.12 >Reporter: Sanjin Tulac > Attachments: CXF Aegis Data Binding.png, CXF-7186.patch > > > I've been trying to use CXF with Aegis DataBinding to host a web service that > needs to be called by a 3rd party, using 3rd party's XML schema. > It turns out that 3rd party XML schema has a naming convention that element > names start with upper case. wsdl2java correctly placed JAXB XMLElement > annotations on the fields in the generated POJOs, But at run-time, Aegis > DataBinding ignores these JAXB annotations on the fields, which causes the > XML from 3rd party to be ignored, instead of converted to the generated POJOs. > I've identified the culprit to be > org.apache.cxf.aegist.type.AnnotatedTypeInfo class, whose method createQName > only looks for annotations on the getter methods, but ignores annotations on > fields. > I can see that this defect stems from the attempt to support both Aegis and > JAXB annotations: former expect annotations on the getter methods, but latter > however, even though quite similar, expect annotations on the field. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7160) Can not configure CXF http-jetty transport to handle X-Fowarded-for headers with Jetty 9
[
https://issues.apache.org/jira/browse/CXF-7160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15765290#comment-15765290
]
Joe Luo commented on CXF-7160:
--
I have a workaround for this issue. We can create a custom Jetty Handler to
deal with those reverse proxy headers:
{code}
public class CustomJettyHttpHandler extends AbstractHandler {
private static final String X_FORWARDED_PROTO_HEADER = "X-Forwarded-Proto";
private static final String X_FORWARDED_FOR_HEADER = "X-Forwarded-For";
public CustomJettyHttpHandler() {
}
public void handle(String target, Request baseRequest, HttpServletRequest
request,
HttpServletResponse response) throws IOException,
ServletException {
String originalProto = request.getHeader(X_FORWARDED_PROTO_HEADER);
String originalIp = request.getHeader(X_FORWARDED_FOR_HEADER);
if (originalIp != null)
{
((Request)request).setRemoteAddr(InetSocketAddress.createUnresolved(
(originalIp.split(",")[0]).trim(),
request.getRemotePort()));
}
if (originalProto != null)
{
((Request)request).setScheme(originalProto);
if (originalProto.equals(HttpScheme.HTTPS.toString()))
((Request)request).setSecure(true);
}
}
}
{code}
Then add it to the http-jetty transport element:
{code}
http://localhost:9000/person";
wsdlURL="META-INF/wsdl/person.wsdl"
serviceClass="org.apache.servicemix.samples.wsdl_first.Person"
serviceName="person:PersonService"
endpointName="person:soap"
xmlns:person="http://servicemix.apache.org/samples/wsdl-first"; />
...
{code}
It does pretty much the same as Jetty9's
org.eclipse.jetty.server.ForwardedRequestCustomizer in dealing with
"X-Forwarded-Proto" and "X-Forwarded-For" headers. However, this is not a
proper solution but a workaround only. I agree with Sergey that we should find
a proper solution to have a better Jetty9 support. In my opinion, it'd be great
if we could just take advantage of Jetty9 features through simple configuration
like adding org.eclipse.jetty.server.ForwardedRequestCustomizer into Jetty
server.
> Can not configure CXF http-jetty transport to handle X-Fowarded-for headers
> with Jetty 9
>
>
> Key: CXF-7160
> URL: https://issues.apache.org/jira/browse/CXF-7160
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 3.1.5
>Reporter: Joe Luo
>Assignee: Freeman Fang
>
> With Jetty 8, we can configure CXF http-jetty transport to handle reverse
> proxy headers by simply setting "forwarded" to "true" to Jetty8 NIO
> SelectChannelConnector:
> {code}
>
>
>
>class="org.eclipse.jetty.server.nio.SelectChannelConnector">
>
>
>
>
>
>
>
>
>
> {code}
> However, with Jetty 9, it is not possible to do so. Because in Jetty 9, the
> SelectChannelConnector was replaced by more generic purpose ServerConnector.
> And we can't configure ServerConnector since the old no-args constructor does
> not exist anymore in ServerConnector class and all new constructors require
> the org.eclipse.jetty.server.Server as an input parameter.
> Jetty 9 documentation here talked about "X-Forward-for Configuration":
> http://www.eclipse.org/jetty/documentation/9.4.x/configuring-connectors.html
> We should configure HttpConfiguration with ForwardedRequestCustomizer in
> order to handle reverse proxy headers:
> {code}
>
> 32768
> 8192
> 8192
>
>
>
>
>
>
> {code}
> However, CXF http-jetty transport schema is not in-sync with API changes in
> Jetty 9. There is no way to configure above with CXF http-jetty transport
> schema.
> I can think of two solutions:
> # Just like what we did in another JIRA:
> https://issues.apache.org/jira/browse/CXF-5937 for servlet, we should also
> fix CXF http-jetty transport so we can optionally react to X-Forwarded
> headers;
> # Change CXF http-jetty transport schema
> http://cxf.apache.org/schemas/configuration/http-jetty.xsd
> and related java code to allow configuring HttpConfiguration along with
> ForwardedRequestCustomizer in order to handle X-Fowarded-for headers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
