[jira] [Created] (CXF-5904) wadl2java -inheritResourceParams don't generate parent parameter
Alexey Markevich created CXF-5904:
-
Summary: wadl2java -inheritResourceParams don't generate parent
parameter
Key: CXF-5904
URL: https://issues.apache.org/jira/browse/CXF-5904
Project: CXF
Issue Type: Bug
Components: Tooling
Affects Versions: 2.7.12
Reporter: Alexey Markevich
using attached sample only {id} generated but {name} also expected
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CXF-5904) wadl2java -inheritResourceParams don't generate parent parameter
[
https://issues.apache.org/jira/browse/CXF-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Markevich updated CXF-5904:
--
Attachment: wadl2java-inheritResourceParams.zip
wadl2java -inheritResourceParams don't generate parent parameter
Key: CXF-5904
URL: https://issues.apache.org/jira/browse/CXF-5904
Project: CXF
Issue Type: Bug
Components: Tooling
Affects Versions: 2.7.12
Reporter: Alexey Markevich
Attachments: wadl2java-inheritResourceParams.zip
using attached sample only {id} generated but {name} also expected
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CXF-5904) wadl2java -inheritResourceParams don't generate parent parameter
[
https://issues.apache.org/jira/browse/CXF-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14074215#comment-14074215
]
Sergey Beryozkin commented on CXF-5904:
---
Regression, caused by a fix to CXF-5870
wadl2java -inheritResourceParams don't generate parent parameter
Key: CXF-5904
URL: https://issues.apache.org/jira/browse/CXF-5904
Project: CXF
Issue Type: Bug
Components: Tooling
Affects Versions: 2.7.12
Reporter: Alexey Markevich
Attachments: wadl2java-inheritResourceParams.zip
using attached sample only {id} generated but {name} also expected
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CXF-5904) wadl2java -inheritResourceParams don't generate parent parameter
[
https://issues.apache.org/jira/browse/CXF-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-5904.
---
Resolution: Fixed
Fix Version/s: 3.1.0
3.0.2
2.7.13
Assignee: Sergey Beryozkin
wadl2java -inheritResourceParams don't generate parent parameter
Key: CXF-5904
URL: https://issues.apache.org/jira/browse/CXF-5904
Project: CXF
Issue Type: Bug
Components: Tooling
Affects Versions: 2.7.12
Reporter: Alexey Markevich
Assignee: Sergey Beryozkin
Fix For: 2.7.13, 3.0.2, 3.1.0
Attachments: wadl2java-inheritResourceParams.zip
using attached sample only {id} generated but {name} also expected
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CXF-5897) Relax setter method name restriction for @context injection
[
https://issues.apache.org/jira/browse/CXF-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14074238#comment-14074238
]
iris ding commented on CXF-5897:
According the discussion from
http://cxf.547215.n5.nabble.com/context-injection-through-setter-method-method-name-restriction-td5746712.html,
Let's relax the method name restriction and add a check for the parameterType
as Interface
(Yes, 1. can be implemented as part the JIRA you created (the proxy won't
be created for non interfaces either way but no point in even trying to
do it). )
like below:
private void checkContextMethod(Method m, Object provider) {
Class? type = m.getParameterTypes()[0];
//if (m.getName().equals(set + type.getSimpleName())) {
if (m.getName().startsWith(set) ((type.isInterface()
|| type == Application.class))) {
addContextMethod(type, m, provider);
}
}
Iris Ding
Relax setter method name restriction for @context injection
---
Key: CXF-5897
URL: https://issues.apache.org/jira/browse/CXF-5897
Project: CXF
Issue Type: Bug
Reporter: iris ding
Assignee: Andrei Shakirin
Fix For: 3.0.2
Relax setter method name restriction for @context injection
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CXF-5905) Allow setting additional Security Provider at Exchange level
[ https://issues.apache.org/jira/browse/CXF-5905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessio Soldano updated CXF-5905: - Attachment: initial-patch.diff Allow setting additional Security Provider at Exchange level Key: CXF-5905 URL: https://issues.apache.org/jira/browse/CXF-5905 Project: CXF Issue Type: New Feature Reporter: Alessio Soldano Attachments: initial-patch.diff This is a follow-up from the CXF dev list thread at http://cxf.547215.n5.nabble.com/On-BouncyCastle-installed-as-a-global-security-provider-td5746785.html and is meant to work with the WSS4J changes at https://issues.apache.org/jira/browse/WSS-507 . CXF could allow setting a custom (BouncyCastle) security provider in the message exchange; if provided, that would be set into WSS4J ThreadLocalSecurityProvider (when installed) just before running sensible interceptors, and cleaned up just afterwards. Attached is an initial patch; I'm going to figure out the other WS-Security interceptors that need to be modified if this approach is fine. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CXF-5905) Allow setting additional Security Provider at Exchange level
Alessio Soldano created CXF-5905: Summary: Allow setting additional Security Provider at Exchange level Key: CXF-5905 URL: https://issues.apache.org/jira/browse/CXF-5905 Project: CXF Issue Type: New Feature Reporter: Alessio Soldano Attachments: initial-patch.diff This is a follow-up from the CXF dev list thread at http://cxf.547215.n5.nabble.com/On-BouncyCastle-installed-as-a-global-security-provider-td5746785.html and is meant to work with the WSS4J changes at https://issues.apache.org/jira/browse/WSS-507 . CXF could allow setting a custom (BouncyCastle) security provider in the message exchange; if provided, that would be set into WSS4J ThreadLocalSecurityProvider (when installed) just before running sensible interceptors, and cleaned up just afterwards. Attached is an initial patch; I'm going to figure out the other WS-Security interceptors that need to be modified if this approach is fine. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CXF-5858) WebClient using GET with complex query param object : IllegalArgumentException: Unresolved variables; only 0 value(s) given for 1 unique variable(s)
[
https://issues.apache.org/jira/browse/CXF-5858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14074303#comment-14074303
]
Sergey Beryozkin edited comment on CXF-5858 at 7/25/14 11:31 AM:
-
Hi, thanks for creating a test project.
I run it with CXF 3.1.0-SNAPSHOT, disabled the tests, deployed the war into
Tomcat, and then run the test where Criteria is built (I changed the context
name to cxf-rest and port to 8080, enabled the registration of the param
converter) and it passed.
I've found why registering the param converter makes a difference. The param
converter returns the correct JSON representation, starting with '{', followed
by a double quote, followed by the property name, etc. Criteria.toString()
returns a string starting from '{' and then followed immediately by the
property name. In the latter case CXF UriTemplate thinks it is a proper
template variable and does not encode '{'. In the former it does not recognize
the sequence as a template var and encodes '{} too and thus the invocation
proceeds.
I think the fact that UriTemplate treats
{noformat}
{a:b}
{noformat}
and
{noformat}
{a:b}
{noformat}
differently is a UriTemplate bug and as such,
with or without ParamConverterProvider the invocation should've failed.
Unless the client code does take care of encoding '{' itself.
So to summarize: get your ParamConverterProvider encode '{' and '}' because
when these characters get submitted as is CXF should always treat it as a
template variable. I'll deal with the UriTemplate issue to make sure it is
enforced asap
was (Author: sergey_beryozkin):
Hi, thanks for creating a test project.
I run it with CXF 3.1.0-SNAPSHOT, disabled the tests, deployed the war into
Tomcat, and then run the test where Criteria is built (I changed the context
name to cxf-rest and port to 8080, enabled the registration of the param
converter) and it passed.
I've found why registering the param converter makes a difference. The param
converter returns the correct JSON representation, starting with '{', followed
by a double quote, followed by the property name, etc. Criteria.toString()
returns a string starting from '{' and then followed immediately by the
property name. In the latter case CXF UriTemplate things it is a proper
template variable and does not encode '{'. In the former it does not recognize
the sequence as a template var and encodes '{} too and thus the invocation
proceeds.
I think the fact that UriTemplate treats
{noformat}
{a:b}
{noformat}
and
{noformat}
{a:b}
{noformat}
differently is a UriTemplate bug and as such,
with or without ParamConverterProvider the invocation should've failed.
Unless the client code does take care of encoding '{' itself.
So to summarize: get your ParamConverterProvider to encode '{' and '}' because
when these characters get submitted as is CXF should always treat it as a
template variable. I'll deal with the UriTemplate issue to make sure it is
enforced asap
WebClient using GET with complex query param object :
IllegalArgumentException: Unresolved variables; only 0 value(s) given for 1
unique variable(s)
Key: CXF-5858
URL: https://issues.apache.org/jira/browse/CXF-5858
Project: CXF
Issue Type: Bug
Affects Versions: 2.7.11, 3.0.0
Reporter: julien Bordeneuve
Hi,
I use the CXF WebClient to GET a message to a server with a complex query ,
this code work on CXF 2.5.x but after a complete version upgrade to CXF 3.0.0
(also try on 2.7.11). I obtain this exception IllegalArgumentException:
Unresolved variables; only 0 value(s) given for 1 unique variable(s).
The problem seems to be on the URITemplate when CurlyBraceTokenizer parse
the query.
for example for my query :
criteria={destination:Paris, arrivalDate:20/11/2014, nbNight:2,
nbAdult:1, nbChild:0, nbRoom:null},
The CurlyBraceTokenizer parser split it like this :
variable = destination
value = Paris, arrivalDate:20/11/2014, nbNight:2, nbAdult:1,
nbChild:0, nbRoom:null
client side :
final ListObject providers = new ArrayListObject();
providers.add(new JacksonJaxbJsonProvider());
// providers.add(new ParamConverterProviderImpl());
WebClient client = WebClient.create(
http://localhost:8090/rest-cxf_v2.7.11/API/REST/POC/;, providers);
client =
client.accept(application/json).type(application/json)
.path(/bookingServices/getHotelByCriteria);
client.resetQuery();
final Criteria criteria = new Criteria();
criteria.setDestination(Paris);
[jira] [Commented] (CXF-5858) WebClient using GET with complex query param object : IllegalArgumentException: Unresolved variables; only 0 value(s) given for 1 unique variable(s)
[
https://issues.apache.org/jira/browse/CXF-5858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14074303#comment-14074303
]
Sergey Beryozkin commented on CXF-5858:
---
Hi, thanks for creating a test project.
I run it with CXF 3.1.0-SNAPSHOT, disabled the tests, deployed the war into
Tomcat, and then run the test where Criteria is built (I changed the context
name to cxf-rest and port to 8080, enabled the registration of the param
converter) and it passed.
I've found why registering the param converter makes a difference. The param
converter returns the correct JSON representation, starting with '{', followed
by a double quote, followed by the property name, etc. Criteria.toString()
returns a string starting from '{' and then followed immediately by the
property name. In the latter case CXF UriTemplate things it is a proper
template variable and does not encode '{'. In the former it does not recognize
the sequence as a template var and encodes '{} too and thus the invocation
proceeds.
I think the fact that UriTemplate treats
{noformat}
{a:b}
{noformat}
and
{noformat}
{a:b}
{noformat}
differently is a UriTemplate bug and as such,
with or without ParamConverterProvider the invocation should've failed.
Unless the client code does take care of encoding '{' itself.
So to summarize: get your ParamConverterProvider to encode '{' and '}' because
when these characters get submitted as is CXF should always treat it as a
template variable. I'll deal with the UriTemplate issue to make sure it is
enforced asap
WebClient using GET with complex query param object :
IllegalArgumentException: Unresolved variables; only 0 value(s) given for 1
unique variable(s)
Key: CXF-5858
URL: https://issues.apache.org/jira/browse/CXF-5858
Project: CXF
Issue Type: Bug
Affects Versions: 2.7.11, 3.0.0
Reporter: julien Bordeneuve
Hi,
I use the CXF WebClient to GET a message to a server with a complex query ,
this code work on CXF 2.5.x but after a complete version upgrade to CXF 3.0.0
(also try on 2.7.11). I obtain this exception IllegalArgumentException:
Unresolved variables; only 0 value(s) given for 1 unique variable(s).
The problem seems to be on the URITemplate when CurlyBraceTokenizer parse
the query.
for example for my query :
criteria={destination:Paris, arrivalDate:20/11/2014, nbNight:2,
nbAdult:1, nbChild:0, nbRoom:null},
The CurlyBraceTokenizer parser split it like this :
variable = destination
value = Paris, arrivalDate:20/11/2014, nbNight:2, nbAdult:1,
nbChild:0, nbRoom:null
client side :
final ListObject providers = new ArrayListObject();
providers.add(new JacksonJaxbJsonProvider());
// providers.add(new ParamConverterProviderImpl());
WebClient client = WebClient.create(
http://localhost:8090/rest-cxf_v2.7.11/API/REST/POC/;, providers);
client =
client.accept(application/json).type(application/json)
.path(/bookingServices/getHotelByCriteria);
client.resetQuery();
final Criteria criteria = new Criteria();
criteria.setDestination(Paris);
criteria.setArrivalDate(20/11/2014);
criteria.setNbNight(2);
criteria.setNbAdult(1);
criteria.setNbChild(2);
criteria.setNbRoom(1);
client.query(criteria, criteria);
client.getCurrentURI();
@SuppressWarnings(unchecked)
final ListHotel hotels = (ListHotel) client
.getCollection(Hotel.class);
assertThat(hotels).isNotNull();
}
server side :
@GET
@Consumes({ MediaType.APPLICATION_JSON })
@Produces({ MediaType.APPLICATION_JSON })
@Path(/getHotelByCriteria)
public ListHotel getHotelByCriteria (@QueryParam(criteria) final
Criteria criteria)
{
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CXF-5897) Relax setter method name restriction for @context injection
[ https://issues.apache.org/jira/browse/CXF-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14074390#comment-14074390 ] Andrei Shakirin commented on CXF-5897: -- Hi Iris, Would you like to provide a patch, as far as you already deep in the code? If not, I will fix this myself. Regards, Andrei. Relax setter method name restriction for @context injection --- Key: CXF-5897 URL: https://issues.apache.org/jira/browse/CXF-5897 Project: CXF Issue Type: Bug Reporter: iris ding Assignee: Andrei Shakirin Fix For: 3.0.2 Relax setter method name restriction for @context injection -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CXF-5898) Feature wss4j should be updated after saaj-impl version change
[ https://issues.apache.org/jira/browse/CXF-5898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14074449#comment-14074449 ] Daniel Kulp commented on CXF-5898: -- Updating the feature.xml file won't help. :( There is a bug in the saaj-impl bundle where it's not even specifying an import for that package. Thus, adding the stax-ex bundle to the features.xml won't even help. I've fixed the saaj-bundle in SMX and the next release of the bundles should provide a new saaj-impl bundle that we can use. Feature wss4j should be updated after saaj-impl version change -- Key: CXF-5898 URL: https://issues.apache.org/jira/browse/CXF-5898 Project: CXF Issue Type: Bug Components: OSGi Affects Versions: 2.7.12 Reporter: Alexey Markevich Attachments: wsdl_first.zip CXF 2.7.11 bundle start-level='25'mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.saaj-impl/1.3.21_1/bundle [INFO] \- org.apache.servicemix.bundles:org.apache.servicemix.bundles.saaj-impl:jar:1.3.21_1:compile [INFO]+- javax.xml.soap:javax.xml.soap-api:jar:1.3.5:compile [INFO]+- org.jvnet.mimepull:mimepull:jar:1.9:compile [INFO]\- org.apache.servicemix.specs:org.apache.servicemix.specs.saaj-api-1.3:jar:2.2.0:compile CXF 2.7.12 bundle start-level='25'mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.saaj-impl/1.3.23_1/bundle [INFO] \- org.apache.servicemix.bundles:org.apache.servicemix.bundles.saaj-impl:jar:1.3.23_1:compile [INFO]+- javax.xml.soap:javax.xml.soap-api:jar:1.3.5:compile [INFO]+- org.jvnet.mimepull:mimepull:jar:1.9:compile [INFO]+- org.jvnet.staxex:stax-ex:jar:1.7.4:compile [INFO]+- javax.xml.stream:stax-api:jar:1.0-2:compile [INFO]+- javax.activation:activation:jar:1.1:compile [INFO]\- org.apache.servicemix.specs:org.apache.servicemix.specs.saaj-api-1.3:jar:2.2.0:compile Actual error: Caused by: java.lang.ClassNotFoundException: org.jvnet.staxex.util.XMLStreamReaderToXMLStreamWriter$Breakpoint not found by org.apache.servicemix.bundles.saaj-impl [156] at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1460)[org.apache.felix.framework-4.0.3.jar:] at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)[org.apache.felix.framework-4.0.3.jar:] at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)[org.apache.felix.framework-4.0.3.jar:] at java.lang.ClassLoader.loadClass(ClassLoader.java:358)[:1.7.0_65] ... 46 more -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CXF-5844) Annotations inherited from interface not merged with annotations from implementing method
[
https://issues.apache.org/jira/browse/CXF-5844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-5844.
---
Resolution: Fixed
Fix Version/s: 3.1.0
3.0.2
Assignee: Sergey Beryozkin
Please be prepared to introduce a contextual property to enable the merge if
JAX-RS JIRA will not directly support it in its resolution.
Annotations inherited from interface not merged with annotations from
implementing method
---
Key: CXF-5844
URL: https://issues.apache.org/jira/browse/CXF-5844
Project: CXF
Issue Type: Bug
Affects Versions: 3.0.0
Reporter: Vjacheslav Borisov
Assignee: Sergey Beryozkin
Priority: Minor
Fix For: 3.0.2, 3.1.0
Annotations inherited from interface not merged with annotations from
implementing method
example interface
{code:title=DocumentResource.java|borderStyle=solid}
public interface DocumentResource {
@GET
@Produces(application/xml)
@Path(/document)
Document getDocument(@QueryParam(objectId) String objectId);
}
{code}
example implementation method
{code:title=DocumentResourceImpl.java|borderStyle=solid}
public class DocumentResourceImpl implements DocumentResource {
@XSLTTransform(value=stylesheets/document.xsl, type =
XSLTTransform.TransformType.CLIENT)
@Override
public Document getDocument(String objectId) {
}
}
{code}
when i place breakpoint in XSLTJaxbProvider.java in method isWriteable
i see only three annotations in anns variable: @GET, @Produces, @PATH,
and don't see @XSLTTransform.
Is this expected behavior?
Doc only states Similarly, annotations can be inherited from super-classes.
In CXF, the resource class will inherit the class-level annotations from both
its implemented interfaces and any class it extends.
and don't mention annotations from implementing method
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CXF-5722) JAXB generated Enum throws IllegalArgumentException by unmarshalling as @QueryParam
[
https://issues.apache.org/jira/browse/CXF-5722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-5722.
---
Resolution: Fixed
Hi Andrei
Let me resolve this issue, we will reopen it we will have to introduce a
contextual property
thanks
JAXB generated Enum throws IllegalArgumentException by unmarshalling as
@QueryParam
---
Key: CXF-5722
URL: https://issues.apache.org/jira/browse/CXF-5722
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 3.0.0-milestone2
Reporter: Andrei Shakirin
Assignee: Andrei Shakirin
By processing request with Query parameter, InjectionUtils tries to recognize
and instantiate parameter class.
In case of Enum parameter class, InjectionUtils.handleParameter() method
calls in loop following methods: fromString, fromValue, valueOf using
reflection. If method returns null, it tries the next one:
if (result == null) {
// check for valueOf(String) static methods
String[] methodNames = cls.isEnum()
? new String[] {fromString, fromValue, valueOf}
: new String[] {valueOf, fromString};
for (String mName : methodNames) {
result = evaluateFactoryMethod(value, cls, pType, mName);
if (result != null) {
break;
}
}
The problem is that factory methods in JAXB generated Enum behaves
differently:
- valueOf() accepts enum identifier (not value)
- fromValue() accepts enum value
Both methods throws IllegalArgumentException by worng argument and do not
return null, how current code expecting. Because formValue() is tried before
valueOf(), it throws exception and valueOf() is never tried, despite of fact
that it will convert the value correctly.
As a result following method throws IllegalArgumentException:
1) method:
@GET
@Path(/enum/)
Response checkEnum(@QueryParam(car) CarType car);
2) generated enum:
@XmlRootElement(name = Car)
@XmlType(name = carType)
@XmlEnum
public enum CarType {
@XmlEnumValue(Audi)
AUDI(Audi),
@XmlEnumValue(Golf)
GOLF(Golf),
BMW(BMW);
private final String value;
CarType(String v) {
value = v;
}
public String value() {
return value;
}
public static CarType fromValue(String v) {
for (CarType c: CarType.values()) {
if (c.value.equals(v)) {
return c;
}
}
throw new IllegalArgumentException(v);
}
}
3) call:
customerService.checkEnum(CarType.AUDI);
The issue was found by [Jeroen Vlek |
https://issues.apache.org/jira/secure/ViewProfile.jspa?name=jeroenvlek].
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CXF-5844) Annotations inherited from interface not merged with annotations from implementing method
[
https://issues.apache.org/jira/browse/CXF-5844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin updated CXF-5844:
--
Component/s: JAX-RS
Annotations inherited from interface not merged with annotations from
implementing method
---
Key: CXF-5844
URL: https://issues.apache.org/jira/browse/CXF-5844
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 3.0.0
Reporter: Vjacheslav Borisov
Assignee: Sergey Beryozkin
Priority: Minor
Fix For: 3.0.2, 3.1.0
Annotations inherited from interface not merged with annotations from
implementing method
example interface
{code:title=DocumentResource.java|borderStyle=solid}
public interface DocumentResource {
@GET
@Produces(application/xml)
@Path(/document)
Document getDocument(@QueryParam(objectId) String objectId);
}
{code}
example implementation method
{code:title=DocumentResourceImpl.java|borderStyle=solid}
public class DocumentResourceImpl implements DocumentResource {
@XSLTTransform(value=stylesheets/document.xsl, type =
XSLTTransform.TransformType.CLIENT)
@Override
public Document getDocument(String objectId) {
}
}
{code}
when i place breakpoint in XSLTJaxbProvider.java in method isWriteable
i see only three annotations in anns variable: @GET, @Produces, @PATH,
and don't see @XSLTTransform.
Is this expected behavior?
Doc only states Similarly, annotations can be inherited from super-classes.
In CXF, the resource class will inherit the class-level annotations from both
its implemented interfaces and any class it extends.
and don't mention annotations from implementing method
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CXF-5722) JAXB generated Enum throws IllegalArgumentException by unmarshalling as @QueryParam
[
https://issues.apache.org/jira/browse/CXF-5722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin updated CXF-5722:
--
Fix Version/s: 3.0.0
JAXB generated Enum throws IllegalArgumentException by unmarshalling as
@QueryParam
---
Key: CXF-5722
URL: https://issues.apache.org/jira/browse/CXF-5722
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 3.0.0-milestone2
Reporter: Andrei Shakirin
Assignee: Andrei Shakirin
Fix For: 3.0.0
By processing request with Query parameter, InjectionUtils tries to recognize
and instantiate parameter class.
In case of Enum parameter class, InjectionUtils.handleParameter() method
calls in loop following methods: fromString, fromValue, valueOf using
reflection. If method returns null, it tries the next one:
if (result == null) {
// check for valueOf(String) static methods
String[] methodNames = cls.isEnum()
? new String[] {fromString, fromValue, valueOf}
: new String[] {valueOf, fromString};
for (String mName : methodNames) {
result = evaluateFactoryMethod(value, cls, pType, mName);
if (result != null) {
break;
}
}
The problem is that factory methods in JAXB generated Enum behaves
differently:
- valueOf() accepts enum identifier (not value)
- fromValue() accepts enum value
Both methods throws IllegalArgumentException by worng argument and do not
return null, how current code expecting. Because formValue() is tried before
valueOf(), it throws exception and valueOf() is never tried, despite of fact
that it will convert the value correctly.
As a result following method throws IllegalArgumentException:
1) method:
@GET
@Path(/enum/)
Response checkEnum(@QueryParam(car) CarType car);
2) generated enum:
@XmlRootElement(name = Car)
@XmlType(name = carType)
@XmlEnum
public enum CarType {
@XmlEnumValue(Audi)
AUDI(Audi),
@XmlEnumValue(Golf)
GOLF(Golf),
BMW(BMW);
private final String value;
CarType(String v) {
value = v;
}
public String value() {
return value;
}
public static CarType fromValue(String v) {
for (CarType c: CarType.values()) {
if (c.value.equals(v)) {
return c;
}
}
throw new IllegalArgumentException(v);
}
}
3) call:
customerService.checkEnum(CarType.AUDI);
The issue was found by [Jeroen Vlek |
https://issues.apache.org/jira/secure/ViewProfile.jspa?name=jeroenvlek].
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CXF-5906) CLaim Manager only parses first claim value
Jan Bernhardt created CXF-5906:
--
Summary: CLaim Manager only parses first claim value
Key: CXF-5906
URL: https://issues.apache.org/jira/browse/CXF-5906
Project: CXF
Issue Type: Bug
Components: STS
Affects Versions: 3.0.1, 2.7.11
Reporter: Jan Bernhardt
In case of claim mapping in a federation scenario the
{{org.apache.cxf.sts.claims.ClaimManager}} parses the onBehalfOf token to
detected source claims. The method parseClaimsInAssertion for SAML 1 2 token
contains a bug by only copying the first claim value.
This error becomes visible for example for role claims with multliple values.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CXF-5906) Claim Manager only parses first claim value
[
https://issues.apache.org/jira/browse/CXF-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14074740#comment-14074740
]
Jan Bernhardt commented on CXF-5906:
I would be willing to provide a patch for this, but I'm not able to assign this
issue to myself...
Claim Manager only parses first claim value
---
Key: CXF-5906
URL: https://issues.apache.org/jira/browse/CXF-5906
Project: CXF
Issue Type: Bug
Components: STS
Affects Versions: 2.7.11, 3.0.1
Reporter: Jan Bernhardt
Labels: Claims, STS
In case of claim mapping in a federation scenario the
{{org.apache.cxf.sts.claims.ClaimManager}} parses the onBehalfOf token to
detected source claims. The method parseClaimsInAssertion for SAML 1 2
token contains a bug by only copying the first claim value.
This error becomes visible for example for role claims with multliple values.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CXF-5906) Claim Manager only parses first claim value
[
https://issues.apache.org/jira/browse/CXF-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Bernhardt updated CXF-5906:
---
Summary: Claim Manager only parses first claim value (was: CLaim Manager
only parses first claim value)
Claim Manager only parses first claim value
---
Key: CXF-5906
URL: https://issues.apache.org/jira/browse/CXF-5906
Project: CXF
Issue Type: Bug
Components: STS
Affects Versions: 2.7.11, 3.0.1
Reporter: Jan Bernhardt
Labels: Claims, STS
In case of claim mapping in a federation scenario the
{{org.apache.cxf.sts.claims.ClaimManager}} parses the onBehalfOf token to
detected source claims. The method parseClaimsInAssertion for SAML 1 2
token contains a bug by only copying the first claim value.
This error becomes visible for example for role claims with multliple values.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CXF-5906) Claim Manager only parses first claim value
[
https://issues.apache.org/jira/browse/CXF-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14074793#comment-14074793
]
ASF GitHub Bot commented on CXF-5906:
-
GitHub user janbernhardt opened a pull request:
https://github.com/apache/cxf/pull/12
[CXF-5906] Fixing multi claim value support
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/janbernhardt/cxf 2.7.x-fixes
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/12.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #12
commit b43703a3116dd43a70d3d9b72ad532de5b1a0426
Author: jbernhardt jbernha...@talend.com
Date: 2014-07-25T18:46:08Z
[CXF-5906] Fixing multi claim value support
Claim Manager only parses first claim value
---
Key: CXF-5906
URL: https://issues.apache.org/jira/browse/CXF-5906
Project: CXF
Issue Type: Bug
Components: STS
Affects Versions: 2.7.11, 3.0.1
Reporter: Jan Bernhardt
Labels: Claims, STS
In case of claim mapping in a federation scenario the
{{org.apache.cxf.sts.claims.ClaimManager}} parses the onBehalfOf token to
detected source claims. The method parseClaimsInAssertion for SAML 1 2
token contains a bug by only copying the first claim value.
This error becomes visible for example for role claims with multliple values.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CXF-5906) Claim Manager only parses first claim value
[
https://issues.apache.org/jira/browse/CXF-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14074791#comment-14074791
]
ASF GitHub Bot commented on CXF-5906:
-
GitHub user janbernhardt opened a pull request:
https://github.com/apache/cxf/pull/11
[CXF-5906] Fixing multi claim value support
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/janbernhardt/cxf master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/11.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #11
commit 48ae10b5fa277c0eec38236ee0328d4df771c15b
Author: jbernhardt jbernha...@talend.com
Date: 2014-07-25T18:46:08Z
[CXF-5906] Fixing multi claim value support
Claim Manager only parses first claim value
---
Key: CXF-5906
URL: https://issues.apache.org/jira/browse/CXF-5906
Project: CXF
Issue Type: Bug
Components: STS
Affects Versions: 2.7.11, 3.0.1
Reporter: Jan Bernhardt
Labels: Claims, STS
In case of claim mapping in a federation scenario the
{{org.apache.cxf.sts.claims.ClaimManager}} parses the onBehalfOf token to
detected source claims. The method parseClaimsInAssertion for SAML 1 2
token contains a bug by only copying the first claim value.
This error becomes visible for example for role claims with multliple values.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CXF-5906) Claim Manager only parses first claim value
[
https://issues.apache.org/jira/browse/CXF-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14074795#comment-14074795
]
ASF GitHub Bot commented on CXF-5906:
-
GitHub user janbernhardt opened a pull request:
https://github.com/apache/cxf/pull/13
[CXF-5906] Fixing multi claim value support
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/janbernhardt/cxf 3.0.x-fixes
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/13.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #13
commit a805fab1971120ff70d13099418cf79bedbee247
Author: jbernhardt jbernha...@talend.com
Date: 2014-07-25T18:46:08Z
[CXF-5906] Fixing multi claim value support
Claim Manager only parses first claim value
---
Key: CXF-5906
URL: https://issues.apache.org/jira/browse/CXF-5906
Project: CXF
Issue Type: Bug
Components: STS
Affects Versions: 2.7.11, 3.0.1
Reporter: Jan Bernhardt
Labels: Claims, STS
In case of claim mapping in a federation scenario the
{{org.apache.cxf.sts.claims.ClaimManager}} parses the onBehalfOf token to
detected source claims. The method parseClaimsInAssertion for SAML 1 2
token contains a bug by only copying the first claim value.
This error becomes visible for example for role claims with multliple values.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CXF-5907) Full claim mapping enforcement in federated scenario
Jan Bernhardt created CXF-5907:
--
Summary: Full claim mapping enforcement in federated scenario
Key: CXF-5907
URL: https://issues.apache.org/jira/browse/CXF-5907
Project: CXF
Issue Type: Bug
Components: STS
Affects Versions: 3.0.1, 2.7.12
Reporter: Jan Bernhardt
In case of federation claims can be mapped from one realm to another. Mapping
can also include that some claim values are not relevant/desired for the target
realm and thus should be omitted in the new token. However the
{{org.apache.cxf.sts.claims.ClaimsManager}} enforces currently that all claim
types contained in the request also must be included in the response by calling
{{validateClaimValues(claims, targetClaims);}} at the end of the claim mapping.
If some claim types have not been mapped to the new token, an exception is
thrown. Therefore this check should be removed to allow mappings with different
claim types in request and response.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CXF-5906) Claim Manager only parses first claim value
[
https://issues.apache.org/jira/browse/CXF-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14074841#comment-14074841
]
ASF GitHub Bot commented on CXF-5906:
-
Github user asfgit closed the pull request at:
https://github.com/apache/cxf/pull/11
Claim Manager only parses first claim value
---
Key: CXF-5906
URL: https://issues.apache.org/jira/browse/CXF-5906
Project: CXF
Issue Type: Bug
Components: STS
Affects Versions: 2.7.11, 3.0.1
Reporter: Jan Bernhardt
Labels: Claims, STS
In case of claim mapping in a federation scenario the
{{org.apache.cxf.sts.claims.ClaimManager}} parses the onBehalfOf token to
detected source claims. The method parseClaimsInAssertion for SAML 1 2
token contains a bug by only copying the first claim value.
This error becomes visible for example for role claims with multliple values.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
