Github user asfgit closed the pull request at:
https://github.com/apache/cxf/pull/54
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Github user asfgit closed the pull request at:
https://github.com/apache/cxf/pull/61
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

GitHub user kops opened a pull request:
https://github.com/apache/cxf/pull/61
[CXF-6268] Make cxf-codegen-plugin toolchains aware during maven build
I reviewed PR #55 against `master`.
`javaExecutable` path resolution follows this order:
1. pom configuration: `javaExecutable` parameter
2. pom configuration: jdk toolchain
3. default value `${java.home}/bin/java`
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/kops/cxf feature/enable_toolchains
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/61.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 #61
----
commit f5e61ba372d93a962c382791142b785ab105a4f6
Author: kops <jeremie@dudie.fr>
Date: 2015-02-25T01:16:54Z
[CXF-6268] Add toolchains support to codegen-plugin
Default behavior is modified and the javaExecutable path is resolved in the
following order:
1. a 'javaExecutable' property explicitely set is used as is ;
2. if the the toolchain manager provides a 'jdk' then it is used ;
3. fallback to default behavior: ${java.home}/bin/java.
commit fa53f4408c63e02dd2e87047bf13e8636645b8e9
Author: kops <jeremie@dudie.fr>
Date: 2015-03-05T22:52:04Z
[CXF-6268] Add integration test
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

GitHub user kops opened a pull request:
https://github.com/apache/cxf/pull/60
Enable travis-ci to help contributors submit valid pull-requests
I work on a PR (#55) to enable toolchains for codegen plugin. It's not really difficult
to implement this feature. I spent most of my effort checking the full build is OK.
Enabling Travis CI may help contributors validating their work and it may help maintainers
qualifying contributions.
- test execution is split in 2 test suites, I'm aware that my choice may not a good one.
Travis builds is limited to 50 minutes. When the build exceed this time they recommand splitting
test execution : http://docs.travis-ci.com/user/speeding-up-the-build/
- Travis CI log output is limited to 10 000 lines, that's why I enabled maven _quiet_
mode
- Some network based tests failed, I had to enable `java.net.preferIPv4Stack` parameter
Please note that I had to exclude 4 tests to get a successful build on Travis CI environment.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/kops/cxf feature/enable_travis
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/60.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 #60
----
commit 6f860331263b138cfe49bb925890791c5465beff
Author: kops <jeremie@dudie.fr>
Date: 2015-03-28T00:47:14Z
Enable travis-ci
Test execution is separated in two test suites because CXF build takes more
than 50 minutes on travis-ci environment.
commit 860212c93e48f36bfc07f058b5eb91bf92bfd099
Author: kops <jeremie@dudie.fr>
Date: 2015-03-28T12:41:36Z
Exclude 4 tests not passing on travis-ci environment
WSDiscoveryClientTest.java
ThreadPoolTest.java
NoAriesBlueprintTest.java
JAXRSClientServerTikaTest.java
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Hi Tyler,
You need to add CrossOriginResourceSharingFilter to the list of providers for your server.
Please let me know if you need help with that, the way to add it depends on a way you configure
the server.
Best Regards,
Andriy Redko
TP> Hi Folks,
TP> I'm trying to enable CORS on a few of Tika's Server resources. But, after
TP> adding the pom.xml dependency and a
TP> @CrossOriginResourceSharing(
TP> allowOrigins = {"url"}
TP> )
TP> annotation to the resources, the Access-Control-Allow-Origin header is
TP> still not given.
TP> Is there another configuration I need to add? Tika's server doesn't
TP> currently have a bean configuration like at the bottom of the examples page
TP> <http://cxf.apache.org/docs/jax-rs-cors.html#JAX-RSCORS-Examples>.
TP> Thanks for any help,
TP> Tyler

Hi Folks,
I'm trying to enable CORS on a few of Tika's Server resources. But, after
adding the pom.xml dependency and a
@CrossOriginResourceSharing(
allowOrigins = {"url"}
)
annotation to the resources, the Access-Control-Allow-Origin header is
still not given.
Is there another configuration I need to add? Tika's server doesn't
currently have a bean configuration like at the bottom of the examples page
<http://cxf.apache.org/docs/jax-rs-cors.html#JAX-RSCORS-Examples>.
Thanks for any help,
Tyler

Hi Vishal,
Could you please share details how are trying to achieve the wsse header
share the configuration and wsdl.
Thanks,
Mohan.
-----Original Message-----
From: Balana, Vishal [mailto:Vishal.Balana@fmr.com.INVALID]
Sent: Wednesday, March 25, 2015 12:07 AM
To: dev@cxf.apache.org
Subject: Schema Validation on input doesn't work
Hi All,
Any help would do wonders!
We have CXF SOAP service using wsdl-first approach.
Schema validation works fine if do not add wsse optional explicit header.
As soon as wsse header added to our wsdl CXF stops validating input
requests.
We are using CXF 2.7.3.
Service is deployed on tomcat 7.0.55.
What needs to be done to make it working?
Thanks,
Vishal

Hi All,
Any help would do wonders!
We have CXF SOAP service using wsdl-first approach.
Schema validation works fine if do not add wsse optional explicit header.
As soon as wsse header added to our wsdl CXF stops validating input requests.
We are using CXF 2.7.3.
Service is deployed on tomcat 7.0.55.
What needs to be done to make it working?
Thanks,
Vishal

Re: what is the current status of checkstyle issue in cxf master?Aki Yoshida <elakito@gmail.com>urn:uuid:%3cCAF8t5XvAfOPHLGif7gtm4awtGC20vDTDzgBCUVtViSnMp+=qFQ@mail-gmail-com%3e2015-03-23T14:12:59Z

Hi Dan,
Thanks for the info. Something was corrupted in my setup.
So, I reinstalled my workspace fresh and now it seems to be working fine.
regards, aki
2015-03-21 0:37 GMT+01:00 Daniel Kulp <dkulp@apache.org>:
>
> Check style should be OK. I updated mine this morning and other than flagging a few
errors that the previous version did not, it seems OK.
>
>
> PMD is usually the bigger issue. I’m using a version of the PMD plugin I built from
the source because it contains a TON of performance fixes that make it much less crappy.
I’m hoping they get a new version out soon. Might need to ping them.
>
> Dan
>
>
>
>> On Mar 20, 2015, at 8:15 AM, Aki Yoshida <elakito@gmail.com> wrote:
>>
>> Hi,
>> Yesterday, I upgraded the checkstyle plugin to 6.2 by accident in my
>> eclipse setup while intending to upgrade other plugins. After that I
>> started to get a warning pop up every time I tried to save the working
>> file and it was awful. Then, I remembered this Dan's mail from a while
>> ago.
>> http://cxf.547215.n5.nabble.com/Warning-Don-t-update-your-eclipse-Checkstyle-plugin-td5754012.html
>>
>> So finally, I uninstalled the plugin.
>> I don't know if I had to do some clean up something or other
>> refreshing to avoid this problem to use the current checkstyle?
>>
>> regards, aki
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

Hi Sergey,
no hurry, with some config it is not a blocker but since I never noticed it
in 2.6 as much as in 3.0 I wondered if I missed something.
Great it will get fixed.
Thanks!
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>
2015-03-23 11:30 GMT+01:00 Sergey Beryozkin <sberyozkin@gmail.com>:
> Hi Romain
>
> Good observation, I have this JIRA opened for a while:
>
> https://issues.apache.org/jira/browse/CXF-4826
>
> but I got side-tracked into other work over the time...If
> isReadable/isWriteable did not need to have a context info in scope then
> services like below would not be affected. You can avoid providers like
> JAXBElementProvider called if you add text/plain, etc...
>
> I've just refreshed it but I'm not sure yet I can fix in time for 3.0.5
> but it is on the map now and we'll take care of it
>
> Thanks, Sergey
>
>
> On 22/03/15 21:13, Romain Manni-Bucau wrote:
>
>> Hi guys,
>>
>> wonder if it would make sense to have a lazy mode
>> on org.apache.cxf.jaxrs.utils.InjectionUtils#injectContextMethods.
>>
>> In my case I use a stupid service:
>>
>> @Path("simple")
>> public class SimpleJaxRs {
>> @GET
>> public String get() {
>> return "it works";
>> }
>> }
>>
>> And I loose a lot of time calling JAXBElementProvider.setMessageContext
>>
>> Of course I can exclude it but wonder about the default.
>>
>> wdyt?
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
>> rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> <http://www.tomitribe.com>
>>
>>
>

Hi Romain
Good observation, I have this JIRA opened for a while:
https://issues.apache.org/jira/browse/CXF-4826
but I got side-tracked into other work over the time...If
isReadable/isWriteable did not need to have a context info in scope then
services like below would not be affected. You can avoid providers like
JAXBElementProvider called if you add text/plain, etc...
I've just refreshed it but I'm not sure yet I can fix in time for 3.0.5
but it is on the map now and we'll take care of it
Thanks, Sergey
On 22/03/15 21:13, Romain Manni-Bucau wrote:
> Hi guys,
>
> wonder if it would make sense to have a lazy mode
> on org.apache.cxf.jaxrs.utils.InjectionUtils#injectContextMethods.
>
> In my case I use a stupid service:
>
> @Path("simple")
> public class SimpleJaxRs {
> @GET
> public String get() {
> return "it works";
> }
> }
>
> And I loose a lot of time calling JAXBElementProvider.setMessageContext
>
> Of course I can exclude it but wonder about the default.
>
> wdyt?
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau>
|
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>

Hi guys,
wonder if it would make sense to have a lazy mode
on org.apache.cxf.jaxrs.utils.InjectionUtils#injectContextMethods.
In my case I use a stupid service:
@Path("simple")
public class SimpleJaxRs {
@GET
public String get() {
return "it works";
}
}
And I loose a lot of time calling JAXBElementProvider.setMessageContext
Of course I can exclude it but wonder about the default.
wdyt?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

Re: what is the current status of checkstyle issue in cxf master?Daniel Kulp <dkulp@apache.org>urn:uuid:%3cB73D3B7F-15E5-407B-89E9-4F4DBE651FFC@apache-org%3e2015-03-20T23:37:56Z

Check style should be OK. I updated mine this morning and other than flagging a few errors
that the previous version did not, it seems OK.
PMD is usually the bigger issue. I’m using a version of the PMD plugin I built from the
source because it contains a TON of performance fixes that make it much less crappy. I’m
hoping they get a new version out soon. Might need to ping them.
Dan
> On Mar 20, 2015, at 8:15 AM, Aki Yoshida <elakito@gmail.com> wrote:
>
> Hi,
> Yesterday, I upgraded the checkstyle plugin to 6.2 by accident in my
> eclipse setup while intending to upgrade other plugins. After that I
> started to get a warning pop up every time I tried to save the working
> file and it was awful. Then, I remembered this Dan's mail from a while
> ago.
> http://cxf.547215.n5.nabble.com/Warning-Don-t-update-your-eclipse-Checkstyle-plugin-td5754012.html
>
> So finally, I uninstalled the plugin.
> I don't know if I had to do some clean up something or other
> refreshing to avoid this problem to use the current checkstyle?
>
> regards, aki
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Github user sberyozkin commented on the pull request:
https://github.com/apache/cxf/pull/59#issuecomment-84168963
Patch has been applied, thanks
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Github user asfgit closed the pull request at:
https://github.com/apache/cxf/pull/59
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

what is the current status of checkstyle issue in cxf master?Aki Yoshida <elakito@gmail.com>urn:uuid:%3cCAF8t5XuYB7sW0PuRctz9GXc56fddWm+H66a4ssk5kz2MCL9e8g@mail-gmail-com%3e2015-03-20T12:15:20Z

Hi,
Yesterday, I upgraded the checkstyle plugin to 6.2 by accident in my
eclipse setup while intending to upgrade other plugins. After that I
started to get a warning pop up every time I tried to save the working
file and it was awful. Then, I remembered this Dan's mail from a while
ago.
http://cxf.547215.n5.nabble.com/Warning-Don-t-update-your-eclipse-Checkstyle-plugin-td5754012.html
So finally, I uninstalled the plugin.
I don't know if I had to do some clean up something or other
refreshing to avoid this problem to use the current checkstyle?
regards, aki

Hi All,
Could someone please help us on the below mentioned issue and provide a solution?
Our migration from Xfire to CXF is stuck due to this reason which means we can’t get any
of security updates.
Thanks,
Deepak
From: deagrawa
Date: Saturday, February 28, 2015 at 12:20 PM
To: "users@cxf.apache.org<mailto:users@cxf.apache.org>"
Subject: Interface polymorphism breaks Aegis Binding mapping of response interfaces in Versioned
SOAP API
Hi,
We are migrating our SOAP services from Xfire(1.2.6 , using ObjectServiceFactory) with Aegis
Binding to latest CXF(3.0.3, using simple frontend) with Aegis Binding.
We were able to get the service up and running with latest CXF with Aegis Binding but it broke
our versioning system and changed the response of versioned APIs as a result.
With Aegis Binding, we define the interfaces of response and an aegis mapping file corresponding
to that interface. Hence, we have different interfaces of same response for different versions
but only one implementation class for response.
For example,
First version interface response is as follows :
publicinterface FirstVersionResult {
publicboolean isSuccess();
public String getErrorMessage();
public ResultCode getErrorCode();
public AccessToken getAccessToken();
}
Then, our second version response with different parameters would be :
publicinterface SecondVersionResult extends FirstVersionResult {
public ResultCode getErrorCodev2();
public AccessToken getAccessTokenv2();
}
As second version response should not contain errorCode and accessToken, as mentioned in
FirstVersionResult Interface, aegis mapping file corresponding to SecondVersionResult would
ignore errorCode and accessToken such as :
<mappings>
<mapping>
<propertyname="errorCode"ignore="true"/>
<propertyname="errorCodev2"mappedName="errorCode"/>
<propertyname=“accessToken"ignore="true"/>
<propertyname="accessTokenv2"mappedName="accessToken"/>
</mapping>
</mappings>
The above mentioned way of versioning used to work fine in Xfire but not in CXF : Xfire used
to ignore errorCode and accessToken for SecondVersion API call but CXF includes errorCode
and accessToken as well in the Second Version API response XML.
By comparing the code of Xfire and CXF, we figured out that while creating the response XML,
CXF gets the superInterfaces as well while Xfire used to check only for superClasses. Hence,
CXF then maps all the elements of super Interfaces in response XML as well.
The change to check for super Interfaces in CXF is made against CXF-3870<https://issues.apache.org/jira/browse/CXF-3870>
to support interface polymorphism.
Specific change in BeanType.getSuperType() which broke Xfire’s versioning system is as follows(
as given here mentioning all CXF-3870 changes<http://mail-archives.apache.org/mod_mbox/cxf-commits/201110.mbox/%3C20111025203012.95B372388A64@eris.apache.org%3E>)
:
+Class c = inf.getTypeClass();
+ if (c.isInterface() && c.getInterfaces().length == 1) {
+ c = c.getInterfaces()[0];
+ } else {
+ c = c.getSuperclass();
+ }
Could you please let us know if we could be missing some other configuration which will stop
this from happening ?
As interface polymorphism seems to be deliberately not supported in Xfire, will this be taken
up as a bug ?
Any help would be very much appreciated.
Thanks,
Deepak

GitHub user skitt opened a pull request:
https://github.com/apache/cxf/pull/59
Store the protocol headers if they need initialized
Currently, if SamlHeaderOutInterceptor finds no protocol headers in the message, it still
proceeds to create the assertion, but it stores it in a new map which is not stored anywhere.
The assertion doesn't appear in the HTTP headers output by CXF...
Simply storing the created map as the message's protocol headers fixes this.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/skitt/cxf patch-1
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/59.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 #59
----
commit 185661f61a2711f50910e17870235c26648ee427
Author: Stephen Kitt <steve@sk2.org>
Date: 2015-03-19T12:53:48Z
Store the protocol headers if they need initialized
Currently, if SamlHeaderOutInterceptor finds no protocol headers in the message, it still
proceeds to create the assertion, but it stores it in a new map which is not stored anywhere.
The assertion doesn't appear in the HTTP headers output by CXF...
Simply storing the created map as the message's protocol headers fixes this.
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Hi,
do you have any more comments in this thing?
I would like to ask you if you know someone who participates in
WS-Fragment working group. I asked them for review the document
https://developer.jboss.org/docs/DOC-52941?uniqueTitle=false , in which
I discuss uncertainties in the specification of WS-Fragment. However
nobody responded to my email
(http://lists.w3.org/Archives/Public/public-ws-resource-access-comments/2015Feb/0000.html).
Could you push the email someone, who will know answer the questions,
which I ask in the document?
Thank you.
Erich
Dňa 19.02.2015 o 20:37 Erich Duda napísal(a):
> In SOAP headers it should be an element with name uuid, which has an
> attribute wsa:isReferenceParameter. This attribute declares that it is
> the ReferenceParameter. Do you see it there?
>
> Dňa 19.02.2015 o 20:10 Daniel Kulp [via CXF] napísal(a):
>>
>> > On Feb 18, 2015, at 1:12 PM, Erich Duda <[hidden email]
>> </user/SendEmail.jtp?type=node&node=5754490&i=0>> wrote:
>> >
>> > Hi,
>> > thank you for your comments. I fixed mentioned issues, see comments
>> bellow.
>> >
>> > Dňa 13.02.2015 o 21:23 Daniel Kulp napísal(a):
>> >>> On Feb 12, 2015, at 3:03 PM, dudae<[hidden email]
>> </user/SendEmail.jtp?type=node&node=5754490&i=1>> wrote:
>> >>> Do you check the implementation? Could you give me some feedback
>> please?
>> >>> Thank you.
>> >> Just took a quick look at this… I completely forgot about this.
>> >>
>> >> There are a couple of obvious things that “jump out” that are very
>> quick/easy to fix. Mostly removing the @author tags (highly
>> discouraged at Apache) and there are a few files that need the Apache
>> header added (the XML files). There are also several warnings when
>> pulled into Eclipse, but those aren’t big deals at all. The other
>> issue would be the use of the System.out for all the messages during
>> the tests causing a lot of output on the console. Again, easy fix
>> and I understand why it’s there during development.
>> >
>> > Should I fixed all PMD warnings? For example, "A method should have
>> only one exit point, and that should be the last statement in the
>> method". I think that more exit points (return statements) do some
>> methods more readable.
>>
>> No. The PMD that is run when you type “mvn” on the command line is
>> the important one. Ideally, they’d both be the same but the current
>> eclipse plugin has a bunch of issues. I have a few pull requests
>> open with the PMD folks that should get the eclipse pmd plugin to be
>> more usable for CXF.
>>
>>
>> >
>> >> The main thing that jumps out at me as being problematic is the
>> use of the JAX-WS handlers
>> (org.apache.cxf.ws.transfer.shared.handlers). Those cause problems
>> as we have to completely break streaming to build the SOAPMessage
>> that is passed into those. I’d very strongly encourage flipping
>> those to normal CXF SOAP interceptors. They seem to only operate on
>> SOAP headers so they can call the getHeaders method on the
>> SOAPMessage passed into the interceptor and pretty much allow the
>> body to remain as is. (likely streaming) That said, I’m not sure
>> those are even needed. CXF’s MAPCodec.java already gathers the
>> headers that have the ReferenceParameter attribute and adds them to
>> the “To” EndpointReference. You may need to experiment a bit more
>> to see if they are really getting through (and if not, figure out
>> why). Likewise, on the client, you could directly add them to the
>> client RequestContext via the normal way of adding headers:
>> >>
>> >>
>> http://cxf.apache.org/faq.html#FAQ-HowcanIaddsoapheaderstotherequest/response?
>>
>> >>
>> >> and avoid the JAX-WS handler/interceptor entirely.
>> >
>> > The ReferenceParameter is possible to send through the request
>> context. When I tried to send it through the standard headers, it
>> isn't getting through because MAPCodec removes all WS-Addressing
>> headers (see discardMAPs method).
>>
>> The discardMAPs method only discards headers that are in the
>> WS-Addressing namespace. It shouldn’t discard the elements that are
>> not in the ws-addressing namespace. If I add a
>> factory.getFeatures().add(new LoggingFeature()) to your code (or use
>> wireshark), I’m not seeing the reference params being written out at
>> all with the new code. That kind of bothers me as I believe they
>> should. Hmm…. Can you double check that the soap headers you are
>> expecting to be there are really there?
>>
>>
>> > Few more CXF things:
>> >> In XLSTResourceTransformer and TransferTools and a few other
>> places, you are creating DocumentBuilderFactory/DocumentBuilder and a
>> Transformer and such. You really should use the utility methods we
>> have in StaxUtils, XMLUtils, and XSLTUtils for much of that. We
>> try to make sure all the XML parsing and processing goes through
>> those utilities so that we can control various aspects to prevent
>> various attacks (like entity expansion attacks).
>> >
>> > I removed TransferTools. I use for
>> > - parsing, serializing XML - StaxUtils
>> > - creating elements - DOMUtils.createDocument().createElement
>> > - transforming - XSLTUtils
>> > - xpath - XPathUtils
>> >
>> > However in FragmentDialectLanguageXPath10 I don't use the
>> XPathUtils, because I need to recognize, when the XPath throw the
>> exception and when not. See https://www.java.net/node/681793
>>
>> OK. That works. Looks much better.
>>
>> I think if we just double check the reference params things, we’re
>> likely good to go with it.
>>
>> --
>> Daniel Kulp
>> [hidden email] </user/SendEmail.jtp?type=node&node=5754490&i=2> -
>> http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
>>
>> ------------------------------------------------------------------------
>> If you reply to this email, your message will be added to the
>> discussion below:
>> http://cxf.547215.n5.nabble.com/Proposal-WS-Transfer-WS-Fragment-implementation-tp5750975p5754490.html
>>
>> To unsubscribe from [Proposal] WS-Transfer/WS-Fragment
>> implementation, click here
>> <http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5750975&code=ZHVkYWVyaWNoQGdtYWlsLmNvbXw1NzUwOTc1fC0xOTc5NzM2MTA0>.
>> NAML
>> <http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
> Erich

GitHub user soul2zimate opened a pull request:
https://github.com/apache/cxf/pull/58
Apply CXF-6198 patch to fix No SOAPFault for HTTP error code 400
https://issues.apache.org/jira/browse/CXF-6198
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/soul2zimate/cxf 2.7.x-fixes
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/58.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 #58
----
commit b48e4bceabdf34b4b830157824dcef7a2baa6864
Author: ChaoWang <chaowan@redhat.com>
Date: 2015-03-17T07:35:18Z
Apply CXF-6198 patch to fix No SOAPFault for HTTP error code 400
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

GitHub user soul2zimate opened a pull request:
https://github.com/apache/cxf/pull/57
Apply CXF-6198 patch to fix No SOAPFault for HTTP error code 400
https://issues.apache.org/jira/browse/CXF-6198
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/soul2zimate/cxf master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/57.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 #57
----
commit b6725d919ebbcb171d862bfbdfc990b15f2336a7
Author: ChaoWang <chaowan@redhat.com>
Date: 2015-03-17T07:22:09Z
Apply CXF-6198 patch to fix No SOAPFault for HTTP error code 400
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Hi Jan
What do you think about making this configurable for both cases?
In this release we can also change the DB schema quite easily.
Thanks
Oli
Von meinem Samsung Gerät gesendet.
-------- Ursprüngliche Nachricht --------
Von: Jan Bernhardt <jbernhardt@talend.com>
Datum: 13.03.2015 09:14 (GMT+01:00)
An: dev@cxf.apache.org, coheigea@apache.org
Betreff: AW: [Fediz] Single Logout Flow at IDP
It is not urgent from my point of view.
Since the logout behavior will change I think it would be great to have this change in 1.2.0
and not in a bug-fix release. But it would also be ok IMHO.
Best regards
Jan
> -----Ursprüngliche Nachricht-----
> Von: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Gesendet: Donnerstag, 12. März 2015 17:56
> An: dev@cxf.apache.org
> Betreff: Re: [Fediz] Single Logout Flow at IDP
>
> Hi Jan,
>
> Yeah that makes sense IMO. Perhaps a task for 1.2.1 though or do you need it for
> 1.2.0?
>
> Colm.
>
> On Thu, Mar 12, 2015 at 4:51 PM, Jan Bernhardt <jbernhardt@talend.com>
> wrote:
>
> > Hi Fediz Developer,
> >
> > I was wondering about the logout flow at the IDP. Currently we get a
> > logout page first with a list of active RPs, then we need to confirm
> > to do the actual logout.
> >
> > The WS-Federation standard describes two actions: wsignout1.0 and
> > wsingoutcleanup1.0
> >
> > Currently we treat both actions alike in Fediz IDP. I would suggest to
> > change the logout behavior to only show the confirm dialog if
> > wsignout1.0 is called and after confirmation navigating to the
> wsingoutcleanup1.0 URL.
> > If wsingoutcleanup1.0 is called directly we should not show a
> > confirmation dialog but logout directly.
> >
> > This way we could also better support a federated logout scenario with
> > multiple IDPs, without the need to confirm on each IDP individually.
> >
> > WDYT?
> >
> > Best regards
> > Jan
> >
> >
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com

> On Mar 13, 2015, at 12:13 PM, David Karlsen <davidkarlsen@gmail.com> wrote:
>
> When do you think 3.0.5 will go out? 3.0.4 was just recently released - so
> it might take some time? Do releases happen at some regular schedule?
Usually about every 2 months or so. 3.0.4 was mid Feb so I would expect mid April.
Dan
> Would
> you consider setting a tentative release date in JIRA for the different
> upcoming versions? (I'm looking out for CXF-6285
> <http://t.signauxdeux.com/e1t/c/5/f18dQhb0SmZ58dDMPbW2n0x6l2B9nMJW7sM9dn7dK_MMdBzM2-04?t=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCXF-6285&si=6166752029835264&pi=9ff12863-22b4-4d7b-bd3c-8765ae91ae1e>
> )
>
>
>
> --
> --
> David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

When do you think 3.0.5 will go out? 3.0.4 was just recently released - so
it might take some time? Do releases happen at some regular schedule? Would
you consider setting a tentative release date in JIRA for the different
upcoming versions? (I'm looking out for CXF-6285
<http://t.signauxdeux.com/e1t/c/5/f18dQhb0SmZ58dDMPbW2n0x6l2B9nMJW7sM9dn7dK_MMdBzM2-04?t=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCXF-6285&si=6166752029835264&pi=9ff12863-22b4-4d7b-bd3c-8765ae91ae1e>
)
--
--
David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen

It is not urgent from my point of view.
Since the logout behavior will change I think it would be great to have this change in 1.2.0
and not in a bug-fix release. But it would also be ok IMHO.
Best regards
Jan
> -----Ursprüngliche Nachricht-----
> Von: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Gesendet: Donnerstag, 12. März 2015 17:56
> An: dev@cxf.apache.org
> Betreff: Re: [Fediz] Single Logout Flow at IDP
>
> Hi Jan,
>
> Yeah that makes sense IMO. Perhaps a task for 1.2.1 though or do you need it for
> 1.2.0?
>
> Colm.
>
> On Thu, Mar 12, 2015 at 4:51 PM, Jan Bernhardt <jbernhardt@talend.com>
> wrote:
>
> > Hi Fediz Developer,
> >
> > I was wondering about the logout flow at the IDP. Currently we get a
> > logout page first with a list of active RPs, then we need to confirm
> > to do the actual logout.
> >
> > The WS-Federation standard describes two actions: wsignout1.0 and
> > wsingoutcleanup1.0
> >
> > Currently we treat both actions alike in Fediz IDP. I would suggest to
> > change the logout behavior to only show the confirm dialog if
> > wsignout1.0 is called and after confirmation navigating to the
> wsingoutcleanup1.0 URL.
> > If wsingoutcleanup1.0 is called directly we should not show a
> > confirmation dialog but logout directly.
> >
> > This way we could also better support a federated logout scenario with
> > multiple IDPs, without the need to confirm on each IDP individually.
> >
> > WDYT?
> >
> > Best regards
> > Jan
> >
> >
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com

Hi Jan,
Yeah that makes sense IMO. Perhaps a task for 1.2.1 though or do you need
it for 1.2.0?
Colm.
On Thu, Mar 12, 2015 at 4:51 PM, Jan Bernhardt <jbernhardt@talend.com>
wrote:
> Hi Fediz Developer,
>
> I was wondering about the logout flow at the IDP. Currently we get a
> logout page first with a list of active RPs, then we need to confirm to do
> the actual logout.
>
> The WS-Federation standard describes two actions: wsignout1.0 and
> wsingoutcleanup1.0
>
> Currently we treat both actions alike in Fediz IDP. I would suggest to
> change the logout behavior to only show the confirm dialog if wsignout1.0
> is called and after confirmation navigating to the wsingoutcleanup1.0 URL.
> If wsingoutcleanup1.0 is called directly we should not show a confirmation
> dialog but logout directly.
>
> This way we could also better support a federated logout scenario with
> multiple IDPs, without the need to confirm on each IDP individually.
>
> WDYT?
>
> Best regards
> Jan
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com

Hi Fediz Developer,
I was wondering about the logout flow at the IDP. Currently we get a logout page first with
a list of active RPs, then we need to confirm to do the actual logout.
The WS-Federation standard describes two actions: wsignout1.0 and wsingoutcleanup1.0
Currently we treat both actions alike in Fediz IDP. I would suggest to change the logout behavior
to only show the confirm dialog if wsignout1.0 is called and after confirmation navigating
to the wsingoutcleanup1.0 URL. If wsingoutcleanup1.0 is called directly we should not show
a confirmation dialog but logout directly.
This way we could also better support a federated logout scenario with multiple IDPs, without
the need to confirm on each IDP individually.
WDYT?
Best regards
Jan

Since we’re Java7 on CXF 3.1, I was thinking of ways to make the generated code more useful.
There isn’t much we can do about the JAX-WS frontend since the spec puts restrictions
on that, but the “cxf” frontend allows us some extra flexibility. The main thing I’d
like to do is get the Closeable interface onto the proxies somehow. Getting the BindingProvider
and Client interfaces also fully declared would save a lot of casting as well.
I’d like to be able to do something like:
try (MyServicePort port = service.getSOAPPort()) {
port.makeCall();
}
and have the close method automatically called. My first thought was to add the Closeable
interface as the superclass of the SEI. This works PERFECTLY for the clients. The problem
is that we tend to also use the SEI on the service implementations and once you do that, you
could need to implement all the other methods which makes no sense on the clients. My next
hope was do change the getSOAPPort() call to something like:
<T extends MyServicePort & Closeable> <T> getSOAPPort();
but the compiler doesn’t seem to like that for return values. :(
The only other thought I had would be to generate a separate interface someplace like:
interface MySoapPortProxy extends MySoapPort, Closeable, BindingProvider, Client {
}
and make the methods return that instead. If they just care about the MySoapPort methods,
they can just do the normal:
MySoapPort proxy = service.getSOAPPort();
if they want the extra functionality:
MySoapPortProxy proxy = service.getSOAPPort();
I’d need to update the runtime a bit to detect these sub=interfaces, but that’s not a
big deal.
Thoughts? Other ideas? Another question: do we generate these pretty much empty interfaces
as separate classes and thus easy to import/use or as a inner interface of the Service? Not
worth pursuing?
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com