Mime type parameter matching - or lack

[Longton, Nigel]

Hi,
We've noticed that CXF doesn't use mime type parameters for matching except for 
q and d. Is there a reason for this?
Our goal is to use a parameter to influence the shape of json or xml that is 
returned. We had to create a @Feature to override the default sort model for 
method selection, but now we are running into a problem with the Content-Type 
that CXF is using to select the message writer - it effectively uses the first 
mime type in the @Produces section whose type/subtype match the incoming Accept 
rather than the parameters that are on the incoming accept. An example
Consider a method of
@GET @Produces({"a/b", "a/b;x=y"}) Object getData() {}
When sent
Accept = a/b;x=y, a/b
Will call a message body with content type of
a/b
but the caller prefers a/b;x=y as it is listed first.

Have I misunderstood Mime types or is there a way to influence CXF?
The problem is in JAXRSUtils.intersectMimeType. When it sorts, the comparator 
ignores the mime type parameters and doesn't do a best match against the users 
types.

Nigel

This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute, alter or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. E-mail transmissions cannot be guaranteed to be 
secure or without error as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or contain viruses. The sender, 
therefore, does not accept liability for any errors or omissions in the 
contents of this message which arise during or as a result of e-mail 
transmission. If verification is required, please request a hard-copy version. 
This message is provided for information purposes and should not be construed 
as a solicitation or offer to buy or sell any securities or related financial 
instruments in any jurisdiction.  Securities are offered in the U.S. through 
PIMCO Investments LLC, distributor and a company of PIMCO LLC.

wsdl2java generates incorrect @XmlElement(namespace=“…”)

[Randy Leonard]

I am using Apache CXF 3.1.7, and the wsdl2java command is generating code with 
missing/incorrect namespace attributes on the @XMLEment annotation.

Note I generally use four distinct namespaces within each WSDL document, which 
are as follows:

• Shared data types across many WSDL documents 
(http://v1_0_0.datatypes.provider.soap.foundation.rps.com)
• Domain-specific data types 
(http://v1_0_0.datatypes.provider.soap.common.masterdata.rps.com)
• Parameter types 
(http://v1_0_0.parameters.provider.soap.common.masterdata.rps.com)
• Service types (http://v1_0_0.provider.soap.common.masterdata.rps.com)

This gives a nice separation of data types, and has worked quite well for me 
with Axis2. I am having issues, however, when applying this approach to CXF. 
Below is an example WSDL document with the namespaces defined above:

———


http://v1_0_0.provider.soap.common.masterdata.rps.com; 
xmlns:foundationTypes="http://v1_0_0.datatypes.provider.soap.foundation.rps.com;

xmlns:masterdataCommonTypes="http://v1_0_0.datatypes.provider.soap.common.masterdata.rps.com;
 
xmlns:parameter="http://v1_0_0.parameters.provider.soap.common.masterdata.rps.com;
 xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/;
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/; 
xmlns:tns="http://v1_0_0.provider.soap.common.masterdata.rps.com; 
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/; 
xmlns:xs="http://www.w3.org/2001/XMLSchema;
xmlns:wsoap12="http://schemas.xmlsoap.org/wsdl/soap12/; 
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/; 
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/;>


http://v1_0_0.parameters.provider.soap.common.masterdata.rps.com;
 >
http://v1_0_0.datatypes.provider.soap.foundation.rps.com; 
schemaLocation="schemas/FoundationTypes.xsd" />
http://v1_0_0.datatypes.provider.soap.common.masterdata.rps.com; 
schemaLocation="schemas/MasterDataCommonTypes.xsd" />










































































http://schemas.xmlsoap.org/soap/http; />























http://localhost:8080/axis2/services/ConsumerChannelService; />




———


The following generated ConsumerChannelFetchResponse class contains no 
namespace attribute for @XmlElement annotations, unless I include '-xjc-npa' in 
the wsdl2java command. When including '-xjc-npa', I then get the incorrect 
namespaces in the @XmlElement annotation. Both scenarios result in unmarshaling 
errors on the client side:


———

/**
 * Java class for anonymous complex type.
 * 
 

RE: Configuring 2way SSL on a REST endpoint in an OSGi container

[Andrei Shakirin]

Hi,

If you would like to force client authentication, the property 
org.ops4j.pax.web.ssl.clientauthneeded is more appropriate, I guess.

That means, the OSGi container will accept only client calls containing 
certificate trusted on container side.
The property will activate client authentication for all SSL endpoints are 
registered with relative URLs.

Regards,
Andrei. 

> -Original Message-
> From: Martin Nielsen [mailto:mny...@gmail.com]
> Sent: Freitag, 16. September 2016 21:18
> To: users@cxf.apache.org
> Subject: Re: Configuring 2way SSL on a REST endpoint in an OSGi container
> 
> I think I figured that out myself actually. Setting
> org.ops4j.pax.web.ssl.clientauthwanted = true Should enable two way ssl if the
> client has anything to send.
> At least that is what I am hoping. Does anyone have any experience about
> whether this is a correct assumption?
> 
> If that is correctly understood,  I can just reject all calls without a valid 
> client
> cert in that specific endpoint.
> 
> On 16 Sep 2016 8:45 p.m., "Martin Nielsen"  wrote:
> 
> > That looks very much like what I would need.  The only issue is that I
> > will need 2way ssl for only a select few endpoints. It looks to me
> > like the pax web configuration is global. Is that right?
> >
> > On 16 Sep 2016 10:21, "Christian Schneider" 
> > wrote:
> >
> >> I am not sure about reading the client certificate in an interceptor
> >> but that part should be for the most part unrelated to OSGi. Maybe
> >> you can ask that as a separate question so people without OSGi
> >> knowledge tune in.
> >>
> >> Christian
> >>
> >> On 16.09.2016 08:42, Martin Nielsen wrote:
> >>
> >>> Hello everyone.
> >>>
> >>> I have a question about using CXF in an OSGi container. More
> >>> specifically using it via Declarative Services.
> >>>
> >>> I need to create a REST endpoint, that is secured by 2way SSL, as
> >>> well as an interceptor which can read the incomming client
> >>> certificate after the handshake in order to perform authentication
> >>> inside the application itself.
> >>>
> >>> But how do i do this? I found a demo to make CXF register a
> >>> component as a rest service here.
> >>> http://cxf.apache.org/dosgi-ds-demo-page.html
> >>>
> >>> But i still can't resources on how to do the 2way ssl part.
> >>> I know i need to setup trust and keystores on the HTTPConduit, but i
> >>> have no idea how or where to do that in an OSGi environment.
> >>>
> >>> I am using Karaf for the OSGi container, if that has any relevance.
> >>>
> >>> Thank you in advance
> >>>
> >>> -Martin
> >>>
> >>>
> >>
> >> --
> >> Christian Schneider
> >> http://www.liquid-reality.de
> >>
> >> Open Source Architect
> >> http://www.talend.com
> >>
> >>

RE: SAP Webservice: None of the policy alternatives can be satisfied

[Andrei Shakirin]

Hi,

In case if SAP web service doesn't force special headers / security, you can 
just use generated service interface and set address in the factory explicitly, 
without using WSDL:

JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();

factory.setAddress("https://mydomain.com/myservice;); 
HelloWorld client = factory.create(HelloWorld.class);
System.out.println(client.sayHi("World"));

Regards,
Andrei.

> -Original Message-
> From: MRneedHelp [mailto:matthias.rudingsdor...@freenet.de]
> Sent: Donnerstag, 15. September 2016 11:15
> To: users@cxf.apache.org
> Subject: SAP Webservice: None of the policy alternatives can be satisfied
> 
> Hi,
> 
> i´m new to CXF and trying to connect to a SAP Webservice. I use the newest cxf
> version 3.1.7.
> I have the WSDL from the webservice and generated code with wsdl2java.
> 
> I should update a program from Axis2 to CXF. But when i start the standard
> client (genarted with wsdl2java) i get a "SOAPFaultException: None of the
> policy alternatives can be satisfied."
> 
> Now i searched for 3 days on the internet and i know that the error occurs,
> because some SAP policies are not supported by cxf. I know several solutions
> for this problem, but none of them is working...
> 
> I tried it with the JaxWSFactoryBean:
> http://stackoverflow.com/questions/12072500/apache-cxf-none-of-the-policy-
> alternatives-can-be-satisfied
>  alternatives-can-be-satisfied>
> But when i use the code, i get a "ServiceConstructionException: Could not find
> definition for service" in the "factory.create()" line. I searched for the 
> exception
> and think, it is because of differences in "namespaces". But i could not find 
> any
> difference in the code to the wsdl.
> 
> Well so, back to the basic code from wsdl2java.
> I read many posts, that say to use Interceptors and AssertionBuilders, but I
> could not get it, how to imlement them or use them.
> I also dont know, if i really need them. I just want to connect with the SAP
> Webservice. I can just ignore all policies in the wsdl, but i cant remove them
> from the wsdl. In the Axis2 code the policies were overwritten with a default
> policy, which was accepted.
> I´ve tryed the IgnorablePolicyInterceptorProvider, self implemented in java or
> with a bean in the cxf.xml file, but nothing worked. Im not sure, if i did it 
> right.
> 
> So my question is: IS there a simple way to just ignore all policies and get
> access to the SAP webservice? (With soap UI it works perfectly).
> 
> Thank you in advance.
> 
> Matthew
> 
> 
> 
> --
> View this message in context: http://cxf.547215.n5.nabble.com/SAP-
> Webservice-None-of-the-policy-alternatives-can-be-satisfied-tp5772704.html
> Sent from the cxf-user mailing list archive at Nabble.com.

Re: WadlGenerator - Bean validation support for complex types?

[J. Fiala]

Sergey,

Thanks for the hint - now I added the schema type reference detection 
for minLength/maxLength/pattern as example in SourceGenerator.java.


I had to add a separate method to get all prefixes used in the WADL 
(createWadlPrefixMap(app)), as schemaCollections doesn't hold them 
(schemaCollection.getNamespaceContext().getDeclaredPrefixes().getLength() 
is 0).


Can you take a look if you like it - if yes I'll add the other ones?

For WadlGenerator I'd then suggest to automatically setup a separate 
parameter-beanvalidation schema which could contain the complete 
collection of all beanvalidations used with generated schemaType-names. 
Then it we could remove the inline simple types from 
SourceGenerator.java as well if you don't want to support it.


Best regards,
Johannes


Am 12.09.2016 um 12:10 schrieb Sergey Beryozkin:

Johannes,

FYI, SourceGenerator keeps a SchemaCollection field - so knowing a 
parameter type reference (SourceGenerator has a utility method for 
giving you a full QName of this reference) you can load an appropriate 
XML Schema type.


I'm still thinking going a ParamConverter path is significantly simpler.
But please experiment, SourceGenerator does not enforce that 
parameters should not refer to the grammar...


Cheers, Sergey

On 11/09/16 21:44, Sergey Beryozkin wrote:

Swagger JAX-RS is capable of generating Swagger JSON based on JAX-RS
annotations alone. Having partial schema fragment inside WADL param is
not good IMHO.

If you'd like to explore it further - do assume that parameters will
refer to XML Schema in WADL:grammar. WADL has XMLSchema loaded - so you
can use that data to analyze the types and add BeanVal annotations if
-beanValidation is enabled, using full class names of these annotations
without introducing a strong beanVal API dep

Many thanks, Sergey


On 11/09/16 10:00, J. Fiala wrote:

Sergey,

I think we can use the simpletype restrictions as already 
implemented in

WadlGenerator and even use them in the SourceGenerator (wadl2java).

I implemented a draft for Size(min,max) and Pattern, can you take a 
look

in the PR (see SourceGenerator.java)?

https://github.com/apache/cxf/pull/146

If you like it, I'll add the other annotations.
This allows usage of standard schema simpletypes and still get the
beanvalidation annotations (without the need to use cxf:beanVal).

The only thing missing is usage of the types in a separate schema, but
that can be added later when access to the simpletypes is possible
during the parameter processing.

Best regards,
Johannes



Am 10.09.2016 um 21:41 schrieb J. Fiala:

Sergey,

1.) So we would have to map the complex types to the parameter list
here.
I don't think this is a really good idea, I think the parameters
should always map to simpletypes.

2.) I think the cxf:beanVal extension is a good starting point for now
(as long as we don't get access to the types/restrictions backing the
parameters in the schema).
I think it would be readable and later can be easily ported to a type.
The only sad thing is that one has to define it for each parameter,
but we could also allow to define types maybe?.

a) The easiest solution (add all restrictions to the parameter
directly):


   



   
…

b) Also allow usage of types (I believe much better):

type="xs:integer">/>…
maxLength="..." />


This way it would be possible to use search/replace once in the future
we are able to access the restrictions of the parameters!

Regarding WadlGenerator: Here we could reuse this perfectly, simply
generate the appropriate cxf:beanValidationRestrictions (see 1.) the
easy way).

So we have both code first/contract first covered with a solution
which is easy to use and also supports existing codebases with
BeanValidation-annotations.

What do you think?

Best regards,
Johannes


Am 08.09.2016 um 11:42 schrieb Sergey Beryozkin:

Hi Johannes

I suppose an idea which you have tried to do with enriching wadl:doc
is useful - lets keep it in mind.

So these ideas are proposed:

1. in WADL-first one simply has the query/header/path parameters
referring to WADL grammar complex types - this will produce Java 
types

with BeanVal annotations - and will require JAX-RS ParamConverters
to to create these beans from Strings.
Can you experiment with this option ? Bean val can then be done
inside this param converter or with JAXRS BeanVal filer (or may be
invoker).

Nothing extra will need to be done on a source generator side for
this to work.

If this option works for WADL-first - then you can start thinking of
how to make it work in the WADL-gen case - WADLGen may simply need to
be enhanced to optionally add non-body JAX-RS parameter types to a
JAXB context passed to JAXB schema compiler.

2. Introduce a cxf:beanVal extension which may be added to wadl:doc ?

Sergey



On 08/09/16 10:22, J. Fiala wrote:

Hi Sergey,

No problem, the solution you suggested is of course the better way
regarding interoperability!

(and great if it will work both ways