[jira] Resolved: (CXF-3172) Add CXF interceptor capable of introspecting arbitrary secure annotations and making authorization decisions
[ https://issues.apache.org/jira/browse/CXF-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-3172. --- Resolution: Fixed > Add CXF interceptor capable of introspecting arbitrary secure annotations and > making authorization decisions > > > Key: CXF-3172 > URL: https://issues.apache.org/jira/browse/CXF-3172 > Project: CXF > Issue Type: New Feature > Components: Core >Affects Versions: 2.3.2, 2.4 >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 2.3.2, 2.4 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3173) Add JAX-RS system test using container-managed authentication and CXF security interceptors for authorization
[ https://issues.apache.org/jira/browse/CXF-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-3173. --- Resolution: Fixed Assignee: Sergey Beryozkin > Add JAX-RS system test using container-managed authentication and CXF > security interceptors for authorization > - > > Key: CXF-3173 > URL: https://issues.apache.org/jira/browse/CXF-3173 > Project: CXF > Issue Type: Task > Components: JAX-RS >Affects Versions: 2.3.2, 2.4 >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 2.3.2, 2.4 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-3160) Reduce Code duplication between http transport variants
[ https://issues.apache.org/jira/browse/CXF-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969295#action_12969295 ] Christian Schneider commented on CXF-3160: -- Seems I had an error in my commit. The build fails to compile. I will fix this as soon as I come home from work. Strange ... I am sure a full build worked ;-( > Reduce Code duplication between http transport variants > --- > > Key: CXF-3160 > URL: https://issues.apache.org/jira/browse/CXF-3160 > Project: CXF > Issue Type: Improvement > Components: Transports >Affects Versions: 2.3.0 >Reporter: Christian Schneider >Assignee: Christian Schneider > Attachments: CXF-3160-1.patch, CXF-3160-2.patch, CXF-3160-3.patch > > > We still have to much duplicated or very similar code in the http transports. > Moving header code from AbstractHttpDestination to Headers > Moving invokeDestination from ServletController to AbstractServletController > to share this code with http-osgi > Moving invoke from ServletDestination to AbstractHttpDestination to share > this code with http-osgi > Removing doMessage from OsgiDestination > Removing invokeDestination from OsgiServletcontroller > Ignoring some mock based tests that do not work anymore. Will have to do some > work on them > There are some small changes in the behaviour for http-osgi as we are now > using the servlet code here. It would be great if Sergey or Dan could review > this. Idon´t think the differences are important but I am not sure. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2770) There is no way to specify autoRewriteSoapAddress from a spring context file.
[
https://issues.apache.org/jira/browse/CXF-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969340#action_12969340
]
Matt Ramey commented on CXF-2770:
-
I noticed from the mailing list
(http://cxf.547215.n5.nabble.com/More-on-autoRewriteSoapAddress-td2853496.html)
that it appears more work was done on this bug.
Has more work been done on it/has it been fixed?
Thanks.
> There is no way to specify autoRewriteSoapAddress from a spring context file.
> -
>
> Key: CXF-2770
> URL: https://issues.apache.org/jira/browse/CXF-2770
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.2.7
>Reporter: Yaytay
>Priority: Minor
>
> I need to be able to use the autoRewriteSoapAddress facility in conjunction
> with CXF.
> This:
> address="http://0.0.0.0:8080/Maths"; depends-on="jetty-factory" >
>
>
>
>
> Queried as this: http://localhost:8080/Maths?wsdl
> Produces this: http://0.0.0.0:8080/Maths*"; />
> It seems that the properties are only set on the endpoint
> (AbstractWSDLBasedEndpointFactory:176), but autoRewriteSoapAddress is looked
> for on the EndpointInfo (WSDLQueryHandler:278).
> It's not at all clear to me what the correct fix is - somehow we need to be
> able to specify properties on the EndpointInfo.
> This is a relatively minor problem for code that makes use of just CXF
> (because one can write code to iterate the endpoints, get the infos and set
> the property), but for projects that use CXF within something else it's a
> bigger problem - for example I want to use CXF with Camel, configured
> entirely with a spring context file.
> The code I use to walk the endpoints and set the property is, roughly:
> String[] serverRegistryNames = beanFactory.getBeanNamesForType(
> ServerRegistry.class );
> for ( String serverRegistryName : serverRegistryNames )
> {
> ServerRegistry serverRegistry = ( ServerRegistry )
> beanFactory.getBean( serverRegistryName );
> List servers = serverRegistry.getServers();
> for ( Server server : servers )
> {
> server.getEndpoint().getEndpointInfo().setProperty(
> "autoRewriteSoapAddress", true );
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-629) WSDL2Java/cxf-codegen-plugin should not generate client artifacts when "-impl" flag is provided
[ https://issues.apache.org/jira/browse/CXF-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969375#action_12969375 ] David J. M. Karlsen commented on CXF-629: - Same here - +1. In fact I would only like to generate the server-side interfaces so that I implement them myself. > WSDL2Java/cxf-codegen-plugin should not generate client artifacts when > "-impl" flag is provided > --- > > Key: CXF-629 > URL: https://issues.apache.org/jira/browse/CXF-629 > Project: CXF > Issue Type: Improvement > Components: Tooling >Affects Versions: 2.0-RC > Environment: NA >Reporter: Steven E. Harris >Assignee: jimma >Priority: Minor > > When trying to generate server-side artifacts using the cxf-codegen-plugin > Maven plugin (WSDL2Java), one can optionally provide the argument "-impl" to > get server-side code generated. If one passes no arguments, the client-side > code gets generated (SEI and Service implementation). If one passes > "-client", the SEI, Service implementation, and a sample client program get > generated. > If one passes only "-impl", the SEI and skeleton implementation get > generated, as well as the Service implementation. There should be some way to > not have the Service implementation generated. Unfortunately, the > command-line arguments as they stand are not adequate to capture the possible > combinations of choices: client-side, server-side, implementation helpers, > and sample program. > In my case, on the client, I just want the SEI and the Service > implementation. I should be able to ask for this with something like > "--client-impl". On the server side, I just want the SEI and skeleton, which > could be expressed as "--server-impl". If I also wanted a sample program for > hte server, I could ask for "--server-harness". Passing no arguments would > trigger just the SEI and the schema types to be generated, but no Service > implementation or skeleton. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2770) There is no way to specify autoRewriteSoapAddress from a spring context file.
[
https://issues.apache.org/jira/browse/CXF-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969378#action_12969378
]
Yaytay commented on CXF-2770:
-
I'm sorry, I'm afraid it's still waiting on me to write a couple of tests for
it.
This is (obviously :) ) not my main priority right now and I'm finding it
difficult to get the time to get my head around the spring tests for CXF.
> There is no way to specify autoRewriteSoapAddress from a spring context file.
> -
>
> Key: CXF-2770
> URL: https://issues.apache.org/jira/browse/CXF-2770
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.2.7
>Reporter: Yaytay
>Priority: Minor
>
> I need to be able to use the autoRewriteSoapAddress facility in conjunction
> with CXF.
> This:
> address="http://0.0.0.0:8080/Maths"; depends-on="jetty-factory" >
>
>
>
>
> Queried as this: http://localhost:8080/Maths?wsdl
> Produces this: http://0.0.0.0:8080/Maths*"; />
> It seems that the properties are only set on the endpoint
> (AbstractWSDLBasedEndpointFactory:176), but autoRewriteSoapAddress is looked
> for on the EndpointInfo (WSDLQueryHandler:278).
> It's not at all clear to me what the correct fix is - somehow we need to be
> able to specify properties on the EndpointInfo.
> This is a relatively minor problem for code that makes use of just CXF
> (because one can write code to iterate the endpoints, get the infos and set
> the property), but for projects that use CXF within something else it's a
> bigger problem - for example I want to use CXF with Camel, configured
> entirely with a spring context file.
> The code I use to walk the endpoints and set the property is, roughly:
> String[] serverRegistryNames = beanFactory.getBeanNamesForType(
> ServerRegistry.class );
> for ( String serverRegistryName : serverRegistryNames )
> {
> ServerRegistry serverRegistry = ( ServerRegistry )
> beanFactory.getBean( serverRegistryName );
> List servers = serverRegistry.getServers();
> for ( Server server : servers )
> {
> server.getEndpoint().getEndpointInfo().setProperty(
> "autoRewriteSoapAddress", true );
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-3175) Unmarshalling does not follow JAXB rules.
Unmarshalling does not follow JAXB rules.
-
Key: CXF-3175
URL: https://issues.apache.org/jira/browse/CXF-3175
Project: CXF
Issue Type: Bug
Components: JAXB Databinding
Affects Versions: 2.3.1
Reporter: David J. M. Karlsen
Priority: Blocker
I have a soapheader element which is declared as:
{noformat}
{noformat}
The JAXB2 generated code (through the cxf-codegen maven plugin will be:
{noformat}
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "EDBHeaderType", propOrder = {
"sourceApplication"
})
public class EDBHeaderType {
@XmlElement(name = "SourceApplication", required = true)
protected String sourceApplication;
{noformat}
which is OK, BUT - then I get this on service invocation from a client:
{noformat}
Caused by: javax.xml.bind.UnmarshalException: unexpected element
(uri:"http://edb.com/ws/WSCommon_v21";, local:"SourceApplication"). Expected
elements are <{http://edb.com<{http://edb.com/ws/WSCommon_v21}sourceApplication>
{noformat}
Check the casing! It expects lowercase elements, although they are declared
uppercase. This is not correct.
If I change it to lowercase it will in fact pass validation (but not adhere to
the schema which declared it).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-3177) Update to latest JAXB version 2.2.2 from 2.2.1
Update to latest JAXB version 2.2.2 from 2.2.1 -- Key: CXF-3177 URL: https://issues.apache.org/jira/browse/CXF-3177 Project: CXF Issue Type: Improvement Affects Versions: 2.3.1 Reporter: Gary Gregory Fix For: 2.3.2 Update to latest JAXB version 2.2.2 from 2.2.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-3176) Update to latest Jetty version 7.2.1 from 7.2.0
Update to latest Jetty version 7.2.1 from 7.2.0 --- Key: CXF-3176 URL: https://issues.apache.org/jira/browse/CXF-3176 Project: CXF Issue Type: Improvement Affects Versions: 2.3.1 Reporter: Gary Gregory Fix For: 2.3.2 Update to latest Jetty version 7.2.1 from 7.2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-3178) build failed on Mac OSX caused by Failed to resolve artifact. om.sun:tools:jar:1.5.0
build failed on Mac OSX caused by Failed to resolve artifact.
om.sun:tools:jar:1.5.0
Key: CXF-3178
URL: https://issues.apache.org/jira/browse/CXF-3178
Project: CXF
Issue Type: Bug
Reporter: Freeman Fang
Assignee: Freeman Fang
Fix For: 2.3.2, 2.4
the latest com.puppycrawl.tools.checkstyle have dependency like
com.sun
tools
1.5.0
system
${java.home}/../lib/tools.jar
but on Mac OSX, there's no tools.jar, it should be
${java.home}/../Classes/classes.jar instead, we need add a profile for mac to
replace the path tomake the build pass.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-3178) build failed on Mac OSX caused by Failed to resolve artifact. om.sun:tools:jar:1.5.0
[
https://issues.apache.org/jira/browse/CXF-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969617#action_12969617
]
Freeman Fang commented on CXF-3178:
---
seems we can safely exclude com.sun.tools as it try to fix some lower version
maven issue.
I test it with maven 2.2.1 on my mac box and it's ok
> build failed on Mac OSX caused by Failed to resolve artifact.
> om.sun:tools:jar:1.5.0
>
>
> Key: CXF-3178
> URL: https://issues.apache.org/jira/browse/CXF-3178
> Project: CXF
> Issue Type: Bug
>Reporter: Freeman Fang
>Assignee: Freeman Fang
> Fix For: 2.3.2, 2.4
>
>
> the latest com.puppycrawl.tools.checkstyle have dependency like
>
> com.sun
> tools
> 1.5.0
> system
> ${java.home}/../lib/tools.jar
>
> but on Mac OSX, there's no tools.jar, it should be
> ${java.home}/../Classes/classes.jar instead, we need add a profile for mac to
> replace the path tomake the build pass.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-3129) wsdl2java: place @Generated annotation on generated code
[ https://issues.apache.org/jira/browse/CXF-3129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969625#action_12969625 ] Nithya commented on CXF-3129: - Made changes in 2 places 1. Passing -mark-generated attribute to XJC 2. Changes in velocity templates > wsdl2java: place @Generated annotation on generated code > > > Key: CXF-3129 > URL: https://issues.apache.org/jira/browse/CXF-3129 > Project: CXF > Issue Type: New Feature > Components: Tooling >Affects Versions: 2.3.0 >Reporter: Andrew Spencer >Priority: Minor > Attachments: Patch for CXF 3129.txt > > > It would be considerate on the part of CXF to place @Generated on the Java > source generated by wsdl2java. > @Generated is in the javax.annotation package and is a marker for generated > code. It allows code quality tools to ignore the generated code, as > described in this feature request for Sonar: > http://jira.codehaus.org/browse/SONAR-1042 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-3129) wsdl2java: place @Generated annotation on generated code
[ https://issues.apache.org/jira/browse/CXF-3129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nithya updated CXF-3129: Attachment: Patch for CXF 3129.txt > wsdl2java: place @Generated annotation on generated code > > > Key: CXF-3129 > URL: https://issues.apache.org/jira/browse/CXF-3129 > Project: CXF > Issue Type: New Feature > Components: Tooling >Affects Versions: 2.3.0 >Reporter: Andrew Spencer >Priority: Minor > Attachments: Patch for CXF 3129.txt > > > It would be considerate on the part of CXF to place @Generated on the Java > source generated by wsdl2java. > @Generated is in the javax.annotation package and is a marker for generated > code. It allows code quality tools to ignore the generated code, as > described in this feature request for Sonar: > http://jira.codehaus.org/browse/SONAR-1042 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3178) build failed on Mac OSX caused by Failed to resolve artifact. om.sun:tools:jar:1.5.0
[
https://issues.apache.org/jira/browse/CXF-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved CXF-3178.
---
Resolution: Fixed
commit fix
http://svn.apache.org/viewvc?rev=1043830&view=rev for trunk
http://svn.apache.org/viewvc?rev=1043832&view=rev for 2.3 branch
http://svn.apache.org/viewvc?rev=1043836&view=rev for 2.2 branch
> build failed on Mac OSX caused by Failed to resolve artifact.
> om.sun:tools:jar:1.5.0
>
>
> Key: CXF-3178
> URL: https://issues.apache.org/jira/browse/CXF-3178
> Project: CXF
> Issue Type: Bug
>Reporter: Freeman Fang
>Assignee: Freeman Fang
> Fix For: 2.3.2, 2.4
>
>
> the latest com.puppycrawl.tools.checkstyle have dependency like
>
> com.sun
> tools
> 1.5.0
> system
> ${java.home}/../lib/tools.jar
>
> but on Mac OSX, there's no tools.jar, it should be
> ${java.home}/../Classes/classes.jar instead, we need add a profile for mac to
> replace the path tomake the build pass.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
