Re: [VOTE] Apache CXF 3.0.10 and 3.1.7

[Aki Yoshida]

+1

regards, aki

2016-07-26 20:25 GMT+02:00 Daniel Kulp :
>
> It’s been a long time coming, but we’re finally ready to release 
> 3.0.10/3.1.7.   We’ve resolved over 75 issues for 3.1.7 which is a LOT for a 
> “.7” release.
>
> Staging areas:
> 3.1.7:
> https://repository.apache.org/content/repositories/orgapachecxf-1074/ 
> 
> 3.0.10:
> https://repository.apache.org/content/repositories/orgapachecxf-1073 
> /
>
>
> Tags:
> 3.1.7:
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=687d104d55d88449778dce8582bc549857460ded
>  
> 
> 3.0.10:
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=a8745ba730bd7081b0f51dc1ff3edb3329fbc854
>  
> 
>
>
> Here is my +1
>
>
> --
> Daniel Kulp
> dk...@apache.org  - http://dankulp.com/blog 
> 
> Talend Community Coder - http://coders.talend.com 

Re: [VOTE] CXF 3.1.6/3.0.9

[Aki Yoshida]

+1

regards, aki


2016-03-23 21:48 GMT+01:00 Daniel Kulp :

>
> It’s been awhile since the last set of releases and we’ve fixed over 45
> JIRA’s (some of which may be needed for the Fediz release) so I’d like to
> get this out.
>
> Staging areas:
> 3.0.9:
> https://repository.apache.org/content/repositories/orgapachecxf-1066/
> 3.1.6:
> https://repository.apache.org/content/repositories/orgapachecxf-1065/
>
> Tags:
> 3.0.9:
>
> https://git1-us-west.apache.org/repos/asf?p=cxf.git;a=tag;h=26f17fad2f123d655ccf2d3a7bd2f4d7f8c81862
> 3.1.6:
>
> https://git1-us-west.apache.org/repos/asf?p=cxf.git;a=tag;h=ff9419a6292393159d44f134c15570f0c7c80bdb
>
>
> Vote will be open for 72h.
>
> Here is my +1.
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: [VOTE] CXF 3.1.5/3.0.8

[Aki Yoshida]

+1

regards, aki

2016-02-02 22:28 GMT+01:00 Daniel Kulp :
> It’s been 3 months since the last patch releases so we really need to get 
> these out.
>
> Staging areas:
> 3.1.5
> https://repository.apache.org/content/repositories/orgapachecxf-1059/
> 3.0.8
> https://repository.apache.org/content/repositories/orgapachecxf-1060/
>
> Tags:
> 3.1.5:
> https://git1-us-west.apache.org/repos/asf?p=cxf.git;a=tag;h=9a864cf721b510621f73f36e0ffabc17fd13c53c
> 3.0.8:
> https://git1-us-west.apache.org/repos/asf?p=cxf.git;a=tag;h=257a6d23948cb120b1e24e3668e128d8b6672829
>
> Vote will be open for at least 72 hours.
>
>
> Here is my +1
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

Re: CXF Client ReceiveTimeout not working on weblogic server

[Aki Yoshida]

is your 'local' system the same system where your weblogic server runs
and has the same jdk and the network setup?
could it be that something else is interrupting the connection from
your web logic server?


2015-11-19 17:30 GMT+01:00 Tomi Prifti :
> Hi,
>
> I'm setting the receive timeout in cxf WebClient for a POST call in the
> following way:
>
>  HTTPConduit conduit = (HTTPConduit)
> WebClient.getConfig(client).getConduit();
>  HTTPClientPolicy policy = conduit.getClient();
>  policy.setReceiveTimeout(timeout);
>  conduit.setClient(policy);
>
> This works fine when I test locally but when deployed in Weblogic the
> receive timeout does not work.
> I'm using cxf 2.7.11, java 6
>
> Thank you,
>
> Tom
>
>
>
> --
> View this message in context: 
> http://cxf.547215.n5.nabble.com/CXF-Client-ReceiveTimeout-not-working-on-weblogic-server-tp5763108.html
> Sent from the cxf-dev mailing list archive at Nabble.com.

Re: Drop support for Jetty 8?

[Aki Yoshida]

+1
sounds good.
thanks,
regards, aki

2015-11-12 16:40 GMT+01:00 Daniel Kulp :
> You may have seen a bunch of updates for 3.2 around getting the Jetty support 
> updated to allow for Jetty 9.3  (which requires Java 8, BTW).   I have all 
> the tests passing with both Jetty 9.2 and Jetty 9.3 now which is a good 
> start.   However, looking through the code, we still have a lot of reflection 
> and other hacks to support Jetty 8.  This was kind of required to be able to 
> support CXF on Karaf 3 and 2.x.   With Karaf 4.0 out for a while now (with 
> several patches) and with us updating to CXF 3.2, could we drop support for 
> Jetty 8 entirely and remove a bunch of those hacks?  Could we maybe make 9.2 
> the minimum (since that’s what’s in Karaf 4)?
>
> My next step is to update the jetty transport to support http/2, but that 
> definitely would require Jetty >=9.2 unless we do a bunch more detection 
> logic and such.
>
> Thoughts?
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

Re: [VOTE] CXF 2.7.18/3.0.7/3.1.4

[Aki Yoshida]

+1

aki

2015-10-31 20:52 GMT+01:00 Daniel Kulp :
>
> This is a vote to release a bunch of patches for CXF.
>
> Staging areas:
> https://repository.apache.org/content/repositories/orgapachecxf-1056/
> https://repository.apache.org/content/repositories/orgapachecxf-1057/
> https://repository.apache.org/content/repositories/orgapachecxf-1058/
>
> Tags:
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=e653f59e052212f3bf425ba177651fa337fb6c6b
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=b1cf6f7f3a9cd18af6584a2c076eb36504e2e9cf
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=55292609edc928dbfc47c8511157159b41fffcd2
>
> Vote will be open for 72h.
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

Re: Releases tomorrow?

[Aki Yoshida]

Hi Dan,
I just want to let you know before you ask about the ticket on my name.

That is CXF-6646 about WS-RM regression in 3.0.x.  But the fix for
this issue will require an invasive change and will require more time,
so I am not committing anything before this release cut. So, it's fine
with cutting a release.

I started discussion with Dennis about this regression in June this
year, unfortunately the discussion went privately as I forgot to cc on
dev in my initial message[1]. And unfortunately, we didn't follow up
until its resolution.

I will spend some time now in the next few weeks to try to fix this issue.

-- Forwarded message --
From: Aki Yoshida <elak...@gmail.com>
Date: 2015-06-19 18:56 GMT+02:00
Subject: RMStore no longer working in 3.x in some cases
To: Dennis Sosnoski <d...@sosnoski.com>


Hi Dennis,

I think the change that took place along the restructuring of the
WS-RM in CXF 3.x has several side effects that break some scenarios.
https://github.com/apache/cxf/commit/b54206babc92ff982df9ad3215a0c001961bd3e3

1. corrupted data
RMMessage no longer caches the data from the DB, so the data will get
lost or corrupted in most DB when multiple messages are read (as each
iteration in the loop within getMesssages() may corrupt the stream
resource from the previous step).

2. memory consumption
RMMessage replaced CachedOutputStream with a memory based byte buffer
and this could lead to OOM.

Could you look at them or should I open a ticket?

Thanks.
regards, aki

2015-10-29 19:05 GMT+01:00 Daniel Kulp <dk...@apache.org>:
> I’m thinking about doing a bunch of releases either tomorrow or Monday.   I’d 
> like to get the “last” 2.7.x release out relatively soon.   At that point, 
> we’d create a 3.1.x branch and open up trunk for new stuff for 3.2 (and 
> likely Java8).It’s been 3 months since 2.7.17 and 3.0.6 so it’s a bit 
> overdue.I’ll likely go ahead and do a 3.1.4 as well as there are some 
> useful fixes there.
>
> If you have anything you want in that isn’t already, let me know.
>
> Thanks!
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

Re: Question about start-level used in cxf's karaf feature entries

[Aki Yoshida]

OK.

In that case, I propose to make the following change. Basically, to
pick the lower of the currently used levels. I think picking a higher
level will likely require changing other depending bundles'
start-level to a higher level.

mvn:commons-codec/commons-codec
25 35
=> choose 25

mvn:commons-lang/commons-lang
none 35 40
=> choose 35

mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.xmlresolver
25 30
=> choose 25

If no one objects, I'll make this change.

regards, aki

2015-10-21 19:38 GMT+02:00 Daniel Kulp <dk...@apache.org>:
>
> No real guidance, just “what works”.   For the most part, “specs” and impls 
> of specs are very early, (<=20)  most other 3rd party things are 25-35,  CXF 
> itself at 40.
>
>
> Dan
>
>
>
>> On Oct 21, 2015, at 8:07 AM, Aki Yoshida <elak...@gmail.com> wrote:
>>
>> Hi,
>> while adding a new feature and making sure to use somewhat consistent
>> start-level for the bundles with the existing features, I noticed
>> there are several inconsistent start-level entries:
>>
>> mvn:commons-codec/commons-codec
>> 25 35
>>
>> mvn:commons-lang/commons-lang
>> none 35 40
>>
>> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.xmlresolver
>> 25 30
>>
>> I think we should these should be aligned. But besides that, I wanted
>> to know if there is a more explicitly stated guidance in choosing the
>> level.
>>
>> regards, aki
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

Question about start-level used in cxf's karaf feature entries

[Aki Yoshida]

Hi,
while adding a new feature and making sure to use somewhat consistent
start-level for the bundles with the existing features, I noticed
there are several inconsistent start-level entries:

mvn:commons-codec/commons-codec
25 35

mvn:commons-lang/commons-lang
none 35 40

mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.xmlresolver
25 30

I think we should these should be aligned. But besides that, I wanted
to know if there is a more explicitly stated guidance in choosing the
level.

regards, aki

Re: [VOTE]Apache CXF 3.1.3

[Aki Yoshida]

+1

Aki

2015-09-17 15:53 GMT+02:00 Daniel Kulp :
> It’s been about 6 weeks since the 3.1.2 release and we’ve fixed a bunch of 
> things that some users have been asking for:
>
> Tag:
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=commit;h=f3185100ec7caea0ac4b52108210ed7e68e85271
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachecxf-1055/
>
> Vote will be open for at least 72 hours.   Here is my +1.
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

Re: Describe those bean based features in the features list document page more consistently

[Aki Yoshida]

I have rearranged the list in the following way

- for those with their own specific schema, the name and namespace
entries correspond to the feature's name and namespace, respectively.
- for those with no specific schema, the name and namespace entries
show simply bean and spring/blueprint in italic. And it is explained
at the bottom of the table what this means
- the entries are sorted by the name for the named entries first,
followed by those no-name entries ordered by the simple name of their
implementing classes.



2015-08-25 20:16 GMT+02:00 Aki Yoshida <elak...@gmail.com>:
> Or maybe add an extra column to describe the common feature name for each 
> entry.
>
>
> 2015-08-25 20:12 GMT+02:00 Aki Yoshida <elak...@gmail.com>:
>> I noticed that the features described in the below features list page
>> are not very consistently described for those bean based features.
>>
>> http://cxf.apache.org/docs/featureslist.html
>>
>> variant 1 (GZIPFeature, etc)
>> Name Namespace ...
>> bean   ...
>>
>> variant 2 (StaxDataBindingFeature, etc)
>> Name  Namespace  ...
>> beanhttp://springframework.org
>>
>> variant 3 (StaxTransform, etc)
>> Name  Namespace 
>> Stax transform...
>>
>>
>> I think we should make those entries look consistent.
>>
>> My suggestion would be something like
>>
>> Name  Namespace
>> /bean/  ...
>>
>> where I /bean/ to represent "bean" written in italic and at the bottom
>> of the table, we can give a short description of what those entries
>> with /bean/ mean.
>>
>> I appreciate for your suggestions. Maybe someone has a nicer idea ;-)
>>
>> regards, aki

Re: cxf git commit: [CXF-6557] add a CORS filter for swagger2 samples

[Aki Yoshida]

Hi Sergey,
yes. Thanks. I saw that. But that is in another dependency and I only
wanted to have allow * for these demos to be easily accessible, so I
opted for just adding a simple filter.
regards, aki

2015-08-26 11:20 GMT+02:00 Sergey Beryozkin sberyoz...@gmail.com:
 Hi Aki

 Benson added CrossOriginResourceSharingFilter to CXF awhile back, it is
 quite advanced, handles simple and pre-flight requests, can be configured
 directly or it can check the annotations on the resource methods.
 Only FYI (in case you'll need to do more fine-grained CORS control), having
 a simple custom CORS filter in a demo is perfect.

 Thanks, Sergey

Describe those bean based features in the features list document page more consistently

[Aki Yoshida]

I noticed that the features described in the below features list page
are not very consistently described for those bean based features.

http://cxf.apache.org/docs/featureslist.html

variant 1 (GZIPFeature, etc)
Name Namespace ...
bean   ...

variant 2 (StaxDataBindingFeature, etc)
Name  Namespace  ...
beanhttp://springframework.org

variant 3 (StaxTransform, etc)
Name  Namespace 
Stax transform...


I think we should make those entries look consistent.

My suggestion would be something like

Name  Namespace
/bean/  ...

where I /bean/ to represent bean written in italic and at the bottom
of the table, we can give a short description of what those entries
with /bean/ mean.

I appreciate for your suggestions. Maybe someone has a nicer idea ;-)

regards, aki

Re: [VOTE] CXF 3.0.6 and 3.1.2

[Aki Yoshida]

+1

aki

2015-07-28 20:13 GMT+02:00 Daniel Kulp dk...@apache.org:
 This is a vote to release 3.0.6 and 3.1.2.   We’ve fixed over 40 issues for 
 3.1.2.

 Staging areas:
 https://repository.apache.org/content/repositories/orgapachecxf-1049/
 https://repository.apache.org/content/repositories/orgapachecxf-1051/

 Tags:
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=28edab19c30da3171a78319156b5364682da5232
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=bea9ca61265711ed843750c6ee1ef4686e3b78b1

 The vote will be open for at least 72 hours.


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: [VOTE] CXF 2.7.17

[Aki Yoshida]

+1

aki

2015-07-27 21:26 GMT+02:00 Alessio Soldano asold...@redhat.com:
 This is a vote to release 2.7.17.  It’s been over 2 months since the last
 release and we’ve fixed more than 18 issues.

 Staging area:
 2.7.17:
 https://repository.apache.org/content/repositories/orgapachecxf-1048/

 Tag:
 2.7.17:
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=d8e7b4fd8eb69da6b3a95f8de1a6a671ac4aaa19

 The vote will be open for at least 72 hours.

 --
 Alessio Soldano
 Web Service Lead, JBoss

Re: What dataType in Dispatch API should I use to gain best performance?

[Aki Yoshida]

Hi,
Maybe SOAPMessage is slow because you are internally building the
object using DOM?
I suppose one of the stream based Source variants should perform better.
regards, aki

2015-07-16 4:09 GMT+02:00 iris ding irisdin...@gmail.com:
 HI guys,
 Looking at the introduction for:
 http://cxf.apache.org/docs/jax-ws-dispatch-api.html

 We supported below dataTypes:
 javax.xml.transform.Source
 javax.xml.soap.SOAPMessage
 javax.activation.DataSource
 JAXB

 Currently we are using javax.xml.soap.SOAPMessage and it's performance is
 very bad. Do you know what dataType is suggested to gain best performance
 when using the Dispatch API? Or is there any CXF internal dataType that can
 be used to gain best performance?


 Thanks  Best Regards,

 Iris Ding





 --
 View this message in context: 
 http://cxf.547215.n5.nabble.com/What-dataType-in-Dispatch-API-should-I-use-to-gain-best-performance-tp5759221.html
 Sent from the cxf-dev mailing list archive at Nabble.com.

Shutting down CXF IBM-JDK jenkins job?

[Aki Yoshida]

This build hasn't passed for quite a long long time.

When I just looked at the error page, it is complaining about some gwt
incompatibility that seems to relate to this message.
https://groups.google.com/forum/#!topic/google-web-toolkit/MAti0jQqgws

But a while ago, when I looked at the error, it was complaining about
some missing javax annotaiton class. So, I think, it will need changes
in not just in one place but in several places.

Unless someone volunteers to figure this out and fix the build, we
should shut down this jenkins job. Although this build job runs only
once a day and also fails early enough to not use up much resource, it
is a waste to have this job scheduled.

regards, aki

Re: [VOTE]xjc-utils 3.0.4

[Aki Yoshida]

+1

aki

2015-07-09 23:40 GMT+02:00 Daniel Kulp dk...@apache.org:
 This is a vote for the XJC-Utils 3.0.4.   This is mostly to release the extra 
 fixes we need for the bug986 plugin required to get the jetty/netty settings 
 properly parsed in blueprint.   However, it also includes two fixes from 
 users.

 Staging repo:
 https://repository.apache.org/content/repositories/orgapachecxf-1047/

 Tag:
 https://git1-us-west.apache.org/repos/asf?p=cxf-xjc-utils.git;a=tag;h=7da906cb4daf3e3da359d33169c17a1466b6b486

 Here is my +1


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: [VOTE] CXF 3.1.1

[Aki Yoshida]

Hi Andriy,
Thank you for the information regarding cxf-jaxrs-cdi. Then, we keep
it that way.

regards, aki


2015-06-09 1:17 GMT+02:00 Andriy Redko drr...@gmail.com:
 Hi Aki,

 Thanks a lot for trying out cxf-jaxrs-cdi. It is true, it needs CDI dependency
 to be present in the OSGi container. There are few reasons behind that:
  - cxf-jaxrs-cdi does not manage version of CDI (1.0 / 1.1 / 1.2 / ...)
  - cxf-jaxrs-cdi does not manage CDI provider (Weld / OpenWebBeans / ...)
  - we totally rely on the CDI capabilities of the OSGi container

 The typical prerequisites for cxf-jaxrs-cdi are pax-cdi-1.2-web-weld or
 pax-cdi-1.1-web-weld, depending on the applications demands. Please let
 me know if it makes sense or we should do something differently.

 Thank you!

 Best Regards,
 Andriy Redko

 AY +1

 AY but I noticed two minor issues that need to be fixed in the next 3.1.x 
 version.

 AY Feature cxf-transports-websocket-server can't get installed out of the
 AY box because it was my fault in not noticing earlier that atmosphere
 AY 2.3.0 was requiring javax.enterprise.context. (CXF-3.1.0 was using
 AY atmosphere-2.2.6). I'll see if we can make atmosphere to have this
 AY dependency optional. As a temporary workaround, one has to install
 AY geronimo's cdi bundle. Alternatively, do not use this feature but
 AY install atmosphere-2.2.7 because CXF 3.1.1 itself works with
 AY atmosphere 2.2.x or 2.3.x. In any case,

 AY As another workaround, I thought one could just install feature 
 cxf-jaxrs-cdi.
 AY But this feature seems to be missing the dependency to the required
 AY cdi bundle. So it doesn't get installed out of the box. But this
 AY seemed to be the case with CXF 3.1.0 as well.

 AY aki

 AY 2015-06-05 22:49 GMT+02:00 Daniel Kulp dk...@apache.org:
 3.1.1 fixes a bunch of issues in 3.1.0 that would prevent it from working 
 properly in several normal use cases, particularly in OSGi.

 Staging area:
 https://repository.apache.org/content/repositories/orgapachecxf-1044/

 Tag:
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=f0d82d6f37105d1e2c97a459fb7fe41d98e1e401

 Here is my +1.

 Vote will be open for 72 hours



 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: [VOTE] CXF 3.1.1

[Aki Yoshida]

+1

but I noticed two minor issues that need to be fixed in the next 3.1.x version.

Feature cxf-transports-websocket-server can't get installed out of the
box because it was my fault in not noticing earlier that atmosphere
2.3.0 was requiring javax.enterprise.context. (CXF-3.1.0 was using
atmosphere-2.2.6). I'll see if we can make atmosphere to have this
dependency optional. As a temporary workaround, one has to install
geronimo's cdi bundle. Alternatively, do not use this feature but
install atmosphere-2.2.7 because CXF 3.1.1 itself works with
atmosphere 2.2.x or 2.3.x. In any case,

As another workaround, I thought one could just install feature cxf-jaxrs-cdi.
But this feature seems to be missing the dependency to the required
cdi bundle. So it doesn't get installed out of the box. But this
seemed to be the case with CXF 3.1.0 as well.

aki

2015-06-05 22:49 GMT+02:00 Daniel Kulp dk...@apache.org:
 3.1.1 fixes a bunch of issues in 3.1.0 that would prevent it from working 
 properly in several normal use cases, particularly in OSGi.

 Staging area:
 https://repository.apache.org/content/repositories/orgapachecxf-1044/

 Tag:
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=f0d82d6f37105d1e2c97a459fb7fe41d98e1e401

 Here is my +1.

 Vote will be open for 72 hours



 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: [VOTE] CXF 2.7.16 and 3.0.5

[Aki Yoshida]

Hi Jan,
Some of the integration tests have too much dependency to the external
causes because of the asynchronous nature of those tests.
So, we have some tests sporadically failing and there seem to be a
couple of tests that fall into this category more frequently.
As a result, the error status of the central jenkins does not
necessarily mean that there are real blocker issues.
A couple of people are running the whole clean tests to verify if this
is the case.

But we admit that there is some room for improvement in making those
tests more stable/reliable.

And if you find some reproducible errors in a staged version before
its release, you can report it here and this will be appreciated.

Regards, aki

2015-06-08 10:15 GMT+02:00 Jan Bernhardt jbernha...@talend.com:
 -1 (non-binding)

 how can we release CXF if it is still unstable on the build server?

 https://builds.apache.org/view/All/job/CXF-Trunk-JDK17/

 https://builds.apache.org/view/All/job/CXF-3.0.x/

 https://builds.apache.org/job/CXF-2.7.x/

 Regards
 Jan

 -Ursprüngliche Nachricht-
 Von: Daniel Kulp [mailto:dk...@apache.org]
 Gesendet: Freitag, 1. Mai 2015 19:27
 An: dev@cxf.apache.org
 Betreff: [VOTE] CXF 2.7.16 and 3.0.5

 This is a vote to release 3.0.5 and 2.7.16.  It’s been over 2 months since 
 the
 last release and we’ve fixed more than 70 issues.

 Staging areas:
 2.7.16:
 https://repository.apache.org/content/repositories/orgapachecxf-1039/
 3.0.5:
 https://repository.apache.org/content/repositories/orgapachecxf-1040/


 Tags:
 2.7.16:
 https://git-wip-
 us.apache.org/repos/asf?p=cxf.git;a=tag;h=a169b5caf85af4337fbd19ffccef70
 389d308bd0
 3.0.5:
 https://git-wip-
 us.apache.org/repos/asf?p=cxf.git;a=tag;h=0f623dd8dcacb38868501012796
 c29b387042adf

 The vote will be open for at least 72 hours.
 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog Talend Community Coder -
 http://coders.talend.com

Re: [VOTE] CXF 2.7.16 and 3.0.5

[Aki Yoshida]

+1

regards, aki

2015-05-01 19:26 GMT+02:00 Daniel Kulp dk...@apache.org:
 This is a vote to release 3.0.5 and 2.7.16.  It’s been over 2 months since 
 the last release and we’ve fixed more than 70 issues.

 Staging areas:
 2.7.16:
 https://repository.apache.org/content/repositories/orgapachecxf-1039/
 3.0.5:
 https://repository.apache.org/content/repositories/orgapachecxf-1040/


 Tags:
 2.7.16:
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=a169b5caf85af4337fbd19ffccef70389d308bd0
 3.0.5:
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=0f623dd8dcacb38868501012796c29b387042adf

 The vote will be open for at least 72 hours.
 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: [VOTE] CXF 3.1.0

[Aki Yoshida]

+1

regards, aki

2015-05-01 19:30 GMT+02:00 Daniel Kulp dk...@apache.org:
 It’s been a year since the 3.0.0 release and we’ve made a bunch of 
 significant improvements. We really need to get this out.  :-)

 This also include the latest cxf-build-utils which allows CXF to import into 
 the latest Eclipse plugins

 Staging areas:
 build-utils:
 https://repository.apache.org/content/repositories/orgapachecxf-1041/org/apache/cxf/apache-cxf/
 3.1.0
 https://repository.apache.org/content/repositories/orgapachecxf-1042/org/apache/cxf/apache-cxf/

 Tags:
 build-utils:
 https://git-wip-us.apache.org/repos/asf?p=cxf-build-utils.git;a=tag;h=744814506a23406a77fa53e75b3f0036efda3f9d
 3.1.0:
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=ecacd89321435a5e64deb0f8e850dc8b094c934e


 This vote will be open for at least 72 hours.
 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: HTTP/2 transport for CXF

[Aki Yoshida]

Hi,
I'll add my comments to the jira ticket.
regards, aki

2015-04-16 22:22 GMT+02:00 Sergey Beryozkin sberyoz...@gmail.com:
 Hi

 Interesting, we chatted with Aki where he did mention HTTP/2, and I opened

 https://issues.apache.org/jira/browse/CXF-6349

 I guess we are about to witness a higher demand for a need to push back to a
 client a high amount of data real fast. HTTP/2 can be one option there. We
 will need to discuss which framework to use, Aki has done a very advanced
 WebSockets support with Atmosphere and also Jetty.

 Lets wait for some initial comments from Aki

 Thanks,
 Sergey


 difficult to add also a Netty-based HTTP/2 one.

 gRPC is actually using Netty for it's transport layer, so I believe that
 the Netty HTTP/2 codec is reasonably proven:
 https://github.com/grpc/grpc-java

 WDYT? Would a contribution be welcome?

 Cheers,
 Leo

Re: what is the current status of checkstyle issue in cxf master?

[Aki Yoshida]

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 dk...@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 elak...@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
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

what is the current status of checkstyle issue in cxf master?

[Aki Yoshida]

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

Re: Planning for Java8 trunk

[Aki Yoshida]

I just checked the release dates of the last 2.4.x, 2.5.x and 2.6.x versions.
Closed 2.4.10 05-Oct-2012
Closed 2.5.11 16-Jul-2013
Closed 2.6.16 07-Oct-2014

So I think it is reasonable to expect 2.7.x to be closed sometime
later this year, that means to have only a few more releases on 2.7.x.

Maybe we can already mention in the 2.7.15 release note that there
will be only a few more releases planned (2~3).


2015-02-15 23:15 GMT+01:00 Jason Pell ja...@pellcorp.com:
 Java 8 support I think is paramount for moving project forward. I just
 don't want the death of 2.7 to be a prerequisite :-)

 Its probably going to be at least 6 months before I can migrate my own
 project to 3.x
 On 16/02/2015 6:03 AM, Sergey Beryozkin sberyoz...@gmail.com wrote:

 Sure. I guess it would be wise to discuss the introduction of
 a Java 8 trunk without making 2.7.x and 3.0.x and 3.1.x releases as the
 prerequisites.
 At some point we did have 4 branches (including a trunk). Ultimately,
 IMHO, a Java 8 trunk can indeed help with getting more new features into
 CXF. Java 7 reaches the end of life in two months. I agree things are
 changing at a much slower rate in the productions. But starting planning
 for a Java 8 trunk is better be done earlier than later :-)

 Sergey


 On 13/02/15 22:32, Jason Pell wrote:

 By customers I don't mean my companies customers, I mean users of cxf 2.7

 On Sat, Feb 14, 2015 at 9:30 AM, Jason Pell ja...@pellcorp.com wrote:

   From a purely selfish point of view, I hope that 2.7 end of life is
 announced well in advance, as a lot of customers will have to migrate to
 3.x.

 On Sat, Feb 14, 2015 at 4:20 AM, Sergey Beryozkin sberyoz...@gmail.com
 wrote:

  Hi All,

 We've had a brief chat with Dan earlier about the possibility of
 introducing a Java 8 trunk after it was announced JAX-RS 2.1 API would
 be
 Java 8 based.

 I'd like to justify here why IMHO this would be a very good thing for
 CXF:

 - Java 8 is recognized to have a lot of new language features that can
 help with significantly enhancing the capabilities of a given project.
 Functional programming, security related enhancements, etc, etc. IMHO
 opening a Java 8 trunk would help us 're-invigorate' the CXF source (all
 frontends) with respect to the asynchronous, security-related and other
 processing and will likely lead to the introduction of the new features
 we
 can not even think of now. It will also excite the CXF community at
 large.

 - JAX-RS 2.1 requires Java8. JAX-RS 2.1 started its work in December
 2014
 and I do expect Jersey and RestEasy teams publishing the snapshots more
 or
 less in sync with the ongoing API updates. Many users do want to play
 with
 the latest and greatest API asap. Besides, implementing iteratively
 would
 make it easier for us to deal with the other commitments we may have.

 We have 3.1.0 and 3.0.x but there are no major differences between them
 from a feature point of view except that 3.1.0 is Java 7 based (with
 some
 related improvements).

 So I believe it would be good to have a Java 8 trunk. The major question
 is when. But I hope it can be opened by the end of this year or possibly
 even a bit earlier.

 IMHO the following may make sense:

 Open it in the end of life for 2.7.x and either 3.1.0 or 3.1.1 releases.

 2.7.x is nearly 2.7.15 now and I guess there will be 3 or so 2.7.x
 releases afterwards max.

 If 2.7.x can be 'closed' and '3.1.0' released at the same time then IMHO
 it can just make sense to branch 3.1.x at that point and open a Java 8
 CXF
 4.0 trunk. Otherwise do it after 2.7.x is closed and 3.1.1 is released.

 Thoughts are welcome
 Thanks, Sergey

Re: cxf jetty blueprint issue (was: [VOTE] CXF 3.0.4/2.7.15)

[Aki Yoshida]

Hi Dan, Krzysztof,
I didn't look at the cxf code itself and as I didn't see any wiring
problem when I tested cxf with karaf-3.0.3, I just looked at its
manifest which is optionally importing
org.apache.aries.blueprint.reflect and the availability of this
package on karaf. I didn't know that this package was intentionally
not-exposed.
So, I agree with Dan. Thanks for the clarification.
regards, aki

2015-02-12 18:37 GMT+01:00 Daniel Kulp dk...@apache.org:

 Three thoughts:

 1) This has been there for at least a few months and this was the first I’ve 
 seen it (and there still isn’t a JIRA filed…).  It’s definitely not a 
 regression from the last release.

 2) We have a viable workaround via the compat bundle

 3) Even with the workaround, I strongly discourage people from configuring 
 the jetty servers in their blueprint files.   Since the servers are “shared”, 
 you get into a “first bundle to create the port has the configuration that 
 wins” situation which can be unpredictable and error prone.  If bundles with 
 different services start up in different order, you can get strange behavior. 
  Configuring the port via the files in /etc would be better (and also then 
 puts the job of configuring the ports into the hands of the administrator, 
 not the app developer, and puts it with the configs for the pax-web and 
 others).

 Anyway, it IS a bug we should fix, but not something I’d hold the release up 
 for at this point.

 Dan



 On Feb 12, 2015, at 11:58 AM, Krzysztof Sobkowiak 
 krzys.sobkow...@gmail.com wrote:

 Hi Aki

 Indeed, it works. But I had to install the compatibility bundle
 separately. Which Karaf/ServiceMix version did you use to test this?
 Which Karaf feature have you installed? Have you installed the bundle
 separately too? The bundle is not installed per default in Karaf now.

 Thanks for the hint :-)

 Regards
 Krzysztof


 On 12.02.2015 15:31, Aki Yoshida wrote:
 But this org.apache.aries.blueprint.reflect is available from
 org.apache.aries.blueprint.core.compatibility, so it isn't a problem
 of CXF, no?

 karaf@root() exports | grep org.apache.aries.blueprint.reflect

 org.apache.aries.blueprint.reflect
| 1.0.0| 14  |
 org.apache.aries.blueprint.core.compatibility

 karaf@root() headers 14

 Apache Aries Blueprint Core Compatiblity Fragment Bundle (14)
 -
 ...

 Export-Package =
 org.apache.aries.blueprint.container;
 uses:=org.apache.aries.blueprint.di,
 org.apache.aries.blueprint.reflect;
 deprecated=true;
 version=1.0.0,
 org.apache.aries.blueprint.di;uses:=org.apache.aries.blueprint.container;deprecated=true;version=1.0.0,
 org.apache.aries.blueprint.reflect;deprecated=true;version=1.0.0


 karaf@root()


 2015-02-12 7:01 GMT+01:00 Krzysztof Sobkowiak krzys.sobkow...@gmail.com:
 Hi

 One user has reported a problem with usage of httpj:engine-factoryin
 ServiceMix
 (http://servicemix.396122.n5.nabble.com/servicemix-5-4-0-cxf-jetty-blueprint-issue-tp5722268.html).
 Using this configuration element in blueprint causes following error


 java.lang.NoClassDefFoundError:
 org/apache/aries/blueprint/reflect/MapMetadataImpl
at
 org.apache.cxf.transport.http_jetty.blueprint.JettyServerEngineFactoryParser.parseEngineConnector(JettyServerEngineFactoryParser.java:110)
at
 org.apache.cxf.transport.http_jetty.blueprint.JettyServerEngineFactoryParser.parse(JettyServerEngineFactoryParser.java:83)
at
 org.apache.cxf.transport.http_jetty.blueprint.HTTPJettyTransportNamespaceHandler.parse(HTTPJettyTransportNamespaceHandler.java:68)
at
 org.apache.aries.blueprint.parser.Parser.parseCustomElement(Parser.java:1308)[18:org.apache.aries.blueprint.core:1.4.2]
at
 org.apache.aries.blueprint.parser.Parser.loadComponents(Parser.java:366)[18:org.apache.aries.blueprint.core:1.4.2]
at
 org.apache.aries.blueprint.parser.Parser.populate(Parser.java:306)[18:org.apache.aries.blueprint.core:1.4.2]
at
 org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:323)[18:org.apache.aries.blueprint.core:1.4.2]
at
 org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269)[18:org.apache.aries.blueprint.core:1.4.2]
at
 org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:294)[18:org.apache.aries.blueprint.core:1.4.2]
at
 org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:263)[18:org.apache.aries.blueprint.core:1.4.2]
at
 org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:253)[18:org.apache.aries.blueprint.core:1.4.2]
at
 org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[13:org.apache.aries.util:1.1.0]
at
 org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified

Re: [VOTE] CXF 3.0.4/2.7.15

[Aki Yoshida]

But this org.apache.aries.blueprint.reflect is available from
org.apache.aries.blueprint.core.compatibility, so it isn't a problem
of CXF, no?

karaf@root() exports | grep org.apache.aries.blueprint.reflect

org.apache.aries.blueprint.reflect
| 1.0.0| 14  |
org.apache.aries.blueprint.core.compatibility

karaf@root() headers 14

Apache Aries Blueprint Core Compatiblity Fragment Bundle (14)
-
...

Export-Package =
org.apache.aries.blueprint.container;
uses:=org.apache.aries.blueprint.di,
org.apache.aries.blueprint.reflect;
deprecated=true;
version=1.0.0,
org.apache.aries.blueprint.di;uses:=org.apache.aries.blueprint.container;deprecated=true;version=1.0.0,
org.apache.aries.blueprint.reflect;deprecated=true;version=1.0.0


karaf@root()


2015-02-12 7:01 GMT+01:00 Krzysztof Sobkowiak krzys.sobkow...@gmail.com:
 Hi

 One user has reported a problem with usage of httpj:engine-factoryin
 ServiceMix
 (http://servicemix.396122.n5.nabble.com/servicemix-5-4-0-cxf-jetty-blueprint-issue-tp5722268.html).
 Using this configuration element in blueprint causes following error


 java.lang.NoClassDefFoundError:
 org/apache/aries/blueprint/reflect/MapMetadataImpl
 at
 org.apache.cxf.transport.http_jetty.blueprint.JettyServerEngineFactoryParser.parseEngineConnector(JettyServerEngineFactoryParser.java:110)
 at
 org.apache.cxf.transport.http_jetty.blueprint.JettyServerEngineFactoryParser.parse(JettyServerEngineFactoryParser.java:83)
 at
 org.apache.cxf.transport.http_jetty.blueprint.HTTPJettyTransportNamespaceHandler.parse(HTTPJettyTransportNamespaceHandler.java:68)
 at
 org.apache.aries.blueprint.parser.Parser.parseCustomElement(Parser.java:1308)[18:org.apache.aries.blueprint.core:1.4.2]
 at
 org.apache.aries.blueprint.parser.Parser.loadComponents(Parser.java:366)[18:org.apache.aries.blueprint.core:1.4.2]
 at
 org.apache.aries.blueprint.parser.Parser.populate(Parser.java:306)[18:org.apache.aries.blueprint.core:1.4.2]
 at
 org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:323)[18:org.apache.aries.blueprint.core:1.4.2]
 at
 org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269)[18:org.apache.aries.blueprint.core:1.4.2]
 at
 org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:294)[18:org.apache.aries.blueprint.core:1.4.2]
 at
 org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:263)[18:org.apache.aries.blueprint.core:1.4.2]
 at
 org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:253)[18:org.apache.aries.blueprint.core:1.4.2]
 at
 org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[13:org.apache.aries.util:1.1.0]
 at
 org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)[13:org.apache.aries.util:1.1.0]
 at
 org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)[13:org.apache.aries.util:1.1.0]
 at
 org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)[13:org.apache.aries.util:1.1.0]
 at
 org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)[13:org.apache.aries.util:1.1.0]
 at
 org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1127)[org.apache.felix.framework-4.4.1.jar:]
 at
 org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:696)[org.apache.felix.framework-4.4.1.jar:]
 at
 org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:484)[org.apache.felix.framework-4.4.1.jar:]
 at
 org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4429)[org.apache.felix.framework-4.4.1.jar:]
 at
 org.apache.felix.framework.Felix.startBundle(Felix.java:2100)[org.apache.felix.framework-4.4.1.jar:]
 at
 org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1299)[org.apache.felix.framework-4.4.1.jar:]
 at
 org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)[org.apache.felix.framework-4.4.1.jar:]
 at java.lang.Thread.run(Thread.java:745)[:1.7.0_76]
 Caused by: java.lang.ClassNotFoundException:
 org.apache.aries.blueprint.reflect.MapMetadataImpl not found by
 org.apache.cxf.cxf-rt-transports-http-jetty [165]
 at
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1556)[org.apache.felix.framework-4.4.1.jar:]
 at
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:77)[org.apache.felix.framework-4.4.1.jar:]
 

Re: [VOTE] CXF 3.0.4/2.7.15

[Aki Yoshida]

+1

Aki

2015-02-12 2:53 GMT+01:00 Daniel Kulp dk...@apache.org:
 This is a vote to release 3.0.4 and 2.7.15.  It’s been about 2 months since 
 the last release and we’ve fixed more than 70 issues.

 Staging areas:
 2.7.15:
 https://repository.apache.org/content/repositories/orgapachecxf-1036/
 3.0.4:
 https://repository.apache.org/content/repositories/orgapachecxf-1037/


 Tags:
 2.7.15:
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=ad0e985de4d14603398765e96723a4d2efe9da64
 3.0.4:
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=3bbc187f31e42cd4cb2e82b6604a87029823331c


 The vote will be open for at least 72 hours.

 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: build failure in systests/jaxrs

[Aki Yoshida]

Hi Jason,
yes. We had this issue that was caused by some inconsistency with
jetty8 and jetty9 wiring and it was fixed yesterday.
regards, aki

2015-02-06 23:05 GMT+01:00 Jason Pell ja...@pellcorp.com:
 Sorry should have mentioned, I received this building master

 Results :

 Failed tests:

 JAXRSClientConduitWebSocketTest.startServers:43-AbstractClientServerTestBase.launchServer:66-Assert.assertTrue:41-Assert.fail:88
 server failed to launch

 JAXRSClientServerWebSocketTest.startServers:40-AbstractClientServerTestBase.launchServer:66-Assert.assertTrue:41-Assert.fail:88
 server failed to launch

 Tests in error:
   JAXRSClientServerWebSocketSpringTest.startServers:37 » BeanCreation Error
 crea...
   JAXRSClientServerWebSocketSpringWebAppTest.testGetBookHTTP:75 »
 ServiceUnavailable

 JAXRSClientServerWebSocketSpringWebAppTestJAXRSClientServerWebSocketTest.testBookWithWebSocketServletStream:238
 » NullPointer

 JAXRSClientServerWebSocketSpringWebAppTestJAXRSClientServerWebSocketTest.testWrongMethod:260
 » NullPointer

 JAXRSClientServerWebSocketSpringWebAppTestJAXRSClientServerWebSocketTest.testBookWithWebSocket:49
 » NullPointer

 JAXRSClientServerWebSocketSpringWebAppTestJAXRSClientServerWebSocketTest.testGetBookStreamWithIDReferences:167
 » NullPointer

 JAXRSClientServerWebSocketSpringWebAppTestJAXRSClientServerWebSocketTest.testCallsInParallel:349
 » NullPointer

 JAXRSClientServerWebSocketSpringWebAppTestJAXRSClientServerWebSocketTest.testBookWithWebSocketAndHTTP:204
 » NullPointer

 JAXRSClientServerWebSocketSpringWebAppTestJAXRSClientServerWebSocketTest.testCallsWithIDReferences:299
 » NullPointer

 JAXRSClientServerWebSocketSpringWebAppTestJAXRSClientServerWebSocketTest.testGetBookStream:137
 » NullPointer

 JAXRSClientServerWebSocketSpringWebAppTestJAXRSClientServerWebSocketTest.testPathRestriction:280
 » NullPointer

 JAXRSClientServerWebSocketSpringWebAppTestJAXRSClientServerWebSocketTest.testGetBookHTTPFromWebSocketEndpoint:229
 » ServiceUnavailable

 JAXRSClientServerWebSocketSpringWebAppTestJAXRSClientServerWebSocketTest.testStreamRegisterAndUnregister:372
 » NullPointer


 On Sat, Feb 7, 2015 at 9:04 AM, Jason Pell ja...@pellcorp.com wrote:

 Is this expected at the moment:

 Caused by: java.lang.ClassNotFoundException:
 org.eclipse.jetty.websocket.WebSocketFactory$Acceptor
 at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
 at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 ... 26 more

Re: maven setting for cxf build in using com.googlecode.maven-download-plugin behind firewall?

[Aki Yoshida]

I didn't take any action on this, as I found a workaround that works
out of the box without any change in the profiles.

So if you need to build rt-transports-http with no Internet
connection, you need to have in your maven repo cache folder
($localRepository/.cache)
the folder maven-download-plugin that contains the necessary file
public-suffix-list.txt and its index file index.ser. You should
already have these files if you once had the Internet connection
during your previous build. If not, you can copy these files from
another machine.

regards, aki


2015-01-23 0:22 GMT+01:00 Aki Yoshida elak...@gmail.com:
 2015-01-22 12:05 GMT+01:00 Sergey Beryozkin sberyoz...@gmail.com:
 Hi Aki
 On 22/01/15 11:02, Aki Yoshida wrote:

 Hi Sergey,

 2015-01-22 11:27 GMT+01:00 Sergey Beryozkin sberyoz...@gmail.com:

 Hi Aki

 Not sure about configuring this plugin, may be an alternative plugin
 exists
 which can do the same but also accept the proxy properties ?


 In fact, I also tried codehaus' wagon-maven-plugin (with goal
 download-single), but I had the same problem ;-(


 The other possible option for doing the local builds without the internet
 access, predownload this file and update the build to check the file from
 the local directory too ?


 Yes. If we can configure the build to check for a local copy and then
 upon not finding it, use this download plugin to go to the internet,
 that would be a good option.

 May be having a profile would simplify it if having if/else is tricky to do
 in the pom.xml for it to work :-)

 Hi Sergey,
 it looks like we can create a profile for downloading this file and
 make its activation depend on the absence of this local cached file.
 i'll try it out tomorrow.

 regards, aki


 Cheers, Sergey


 regards, aki


 Cheers, Sergey

 On 22/01/15 10:14, Aki Yoshida wrote:


 the current CXF snapshots uses com.googlecode.maven-download-plugin to
 download a remote file during build. The background for this is
 described in https://issues.apache.org/jira/browse/CXF-6143.

 I am trying to make this plugin use a local http proxy. I have tried
 setting those java proxy properties -Dhttps.proxyHost etc in my
 MAVEN_OPTS and also setting https_proxy system properties. but it is
 not working. Does anyone know how to make this plugin use an http
 proxy?

 Thanks.

 regards, aki




 --
 Sergey Beryozkin

 Talend Community Coders
 http://coders.talend.com/

 Blog: http://sberyozkin.blogspot.com

Re: [1/5] cxf git commit: Update plugins to use annotations instead of the javadoc things

[Aki Yoshida]

Hi Alessio,
thanks. I'll try with that maven version.
But that means someone has to update the central jenkins build job to
use that maven version as well.
it is currently failing at the same spot.
https://builds.apache.org/view/A-D/view/CXF/job/CXF-Trunk-JDK17/688/console
regards, aki

2015-02-03 11:03 GMT+01:00 Alessio Soldano asold...@redhat.com:
 AFAICS, it's a matter of the Maven version being used. Just tried with 3.2.3
 and it works fine.
 Could be caused by http://jira.codehaus.org/browse/MNG-5346 .

 Cheers
 Alessio

 On 03/02/15 10:34, Aki Yoshida wrote:

 It looks like this commit has broken cxf-codegen-plugin in trunk.

 [INFO] Apache CXF Command Line Tools WSDL to JavaScript Front End
 SUCCESS [2.062s]
 [INFO] Apache CXF Command Line Tools WSDLTo JAXB Databinding  SUCCESS
 [1.981s]
 [INFO] Apache CXF Maven Plugins .. SUCCESS
 [0.057s]
 [INFO] Apache CXF WSDL Validator Maven2 Plugin ... SUCCESS
 [1.751s]
 [INFO] Apache CXF Code Generation Maven2 Plugins . FAILURE
 [0.784s]
 [INFO] Apache CXF Test Utilities . SKIPPED
 ...

 Does anyone know how to fix it or do we have to wait for Dan?

 I just temporarily synch'ed my local branch to one commit earlier to
 get the build run.
 regards, aki


 2015-02-02 19:59 GMT+01:00  dk...@apache.org:

 Repository: cxf
 Updated Branches:
refs/heads/master 27e877346 - 96ed80508


 Update plugins to use annotations instead of the javadoc things


 Project: http://git-wip-us.apache.org/repos/asf/cxf/repo
 Commit: http://git-wip-us.apache.org/repos/asf/cxf/commit/96ed8050
 Tree: http://git-wip-us.apache.org/repos/asf/cxf/tree/96ed8050
 Diff: http://git-wip-us.apache.org/repos/asf/cxf/diff/96ed8050

 Branch: refs/heads/master
 Commit: 96ed80508cf15f7dc8c2d5a73225a36dbc096ee2
 Parents: bfbc0a2
 Author: Daniel Kulp dk...@apache.org
 Authored: Mon Feb 2 13:58:09 2015 -0500
 Committer: Daniel Kulp dk...@apache.org
 Committed: Mon Feb 2 13:58:43 2015 -0500

 --
   maven-plugins/codegen-plugin/pom.xml| 42 ++---
   .../cxf/maven_plugin/AbstractCodegenMoho.java   | 85 +++---
   .../maven_plugin/wsdl2java/WSDL2JavaMojo.java   | 30 +++
   .../wsdl2js/WSDL2JavaScriptMojo.java| 28 +++---
   maven-plugins/corba/pom.xml | 37 
   maven-plugins/java2wadl-plugin/pom.xml  | 52 +++
   .../javatowadl/ParseJavaDocMojo.java| 91
 
   maven-plugins/java2ws-plugin/pom.xml| 37 
   maven-plugins/pom.xml   | 20 -
   maven-plugins/wadl2java-plugin/pom.xml  | 42 ++---
   .../wadlto/AbstractCodeGeneratorMojo.java   | 81 +
   .../cxf/maven_plugin/wadlto/WADL2JavaMojo.java  | 29 +++
   maven-plugins/wsdl-validator-plugin/pom.xml | 37 
   parent/pom.xml  | 12 +++
   pom.xml | 31 +++
   15 files changed, 194 insertions(+), 460 deletions(-)
 --



 http://git-wip-us.apache.org/repos/asf/cxf/blob/96ed8050/maven-plugins/codegen-plugin/pom.xml
 --
 diff --git a/maven-plugins/codegen-plugin/pom.xml
 b/maven-plugins/codegen-plugin/pom.xml
 index 521d097..0259a06 100644
 --- a/maven-plugins/codegen-plugin/pom.xml
 +++ b/maven-plugins/codegen-plugin/pom.xml
 @@ -56,6 +56,11 @@
   scopeprovided/scope
   /dependency
   dependency
 +groupIdorg.apache.maven.plugin-tools/groupId
 +artifactIdmaven-plugin-annotations/artifactId
 +scopeprovided/scope
 +/dependency
 +dependency
   groupIdorg.codehaus.plexus/groupId
   artifactIdplexus-utils/artifactId
   version2.0.5/version
 @@ -148,41 +153,4 @@
   /dependencies
   /profile
   /profiles
 -build
 -   pluginManagement
 -   plugins
 -   !--This plugin's configuration is used to store
 Eclipse m2e settings only. It has no influence on the Maven build itself.--
 -   plugin
 -   groupIdorg.eclipse.m2e/groupId
 -
 artifactIdlifecycle-mapping/artifactId
 -   version1.0.0/version
 -   configuration
 -   lifecycleMappingMetadata
 -   pluginExecutions
 -   pluginExecution
 -
 pluginExecutionFilter
 -
 groupId
 -
 org.apache.maven.plugins
 -
 /groupId
 -
 artifactId
 -
 maven-plugin-plugin
 -
 /artifactId
 -
 versionRange
 -
 [2.9,)
 -
 /versionRange
 -
 goals
 -
 goaldescriptor/goal
 -
 /goals

Re: [1/5] cxf git commit: Update plugins to use annotations instead of the javadoc things

[Aki Yoshida]

confirmed. I used 3.2.5 and it's building fine.
regards, aki

2015-02-03 11:11 GMT+01:00 Aki Yoshida elak...@gmail.com:
 Hi Alessio,
 thanks. I'll try with that maven version.
 But that means someone has to update the central jenkins build job to
 use that maven version as well.
 it is currently failing at the same spot.
 https://builds.apache.org/view/A-D/view/CXF/job/CXF-Trunk-JDK17/688/console
 regards, aki

 2015-02-03 11:03 GMT+01:00 Alessio Soldano asold...@redhat.com:
 AFAICS, it's a matter of the Maven version being used. Just tried with 3.2.3
 and it works fine.
 Could be caused by http://jira.codehaus.org/browse/MNG-5346 .

 Cheers
 Alessio

 On 03/02/15 10:34, Aki Yoshida wrote:

 It looks like this commit has broken cxf-codegen-plugin in trunk.

 [INFO] Apache CXF Command Line Tools WSDL to JavaScript Front End
 SUCCESS [2.062s]
 [INFO] Apache CXF Command Line Tools WSDLTo JAXB Databinding  SUCCESS
 [1.981s]
 [INFO] Apache CXF Maven Plugins .. SUCCESS
 [0.057s]
 [INFO] Apache CXF WSDL Validator Maven2 Plugin ... SUCCESS
 [1.751s]
 [INFO] Apache CXF Code Generation Maven2 Plugins . FAILURE
 [0.784s]
 [INFO] Apache CXF Test Utilities . SKIPPED
 ...

 Does anyone know how to fix it or do we have to wait for Dan?

 I just temporarily synch'ed my local branch to one commit earlier to
 get the build run.
 regards, aki


 2015-02-02 19:59 GMT+01:00  dk...@apache.org:

 Repository: cxf
 Updated Branches:
refs/heads/master 27e877346 - 96ed80508


 Update plugins to use annotations instead of the javadoc things


 Project: http://git-wip-us.apache.org/repos/asf/cxf/repo
 Commit: http://git-wip-us.apache.org/repos/asf/cxf/commit/96ed8050
 Tree: http://git-wip-us.apache.org/repos/asf/cxf/tree/96ed8050
 Diff: http://git-wip-us.apache.org/repos/asf/cxf/diff/96ed8050

 Branch: refs/heads/master
 Commit: 96ed80508cf15f7dc8c2d5a73225a36dbc096ee2
 Parents: bfbc0a2
 Author: Daniel Kulp dk...@apache.org
 Authored: Mon Feb 2 13:58:09 2015 -0500
 Committer: Daniel Kulp dk...@apache.org
 Committed: Mon Feb 2 13:58:43 2015 -0500

 --
   maven-plugins/codegen-plugin/pom.xml| 42 ++---
   .../cxf/maven_plugin/AbstractCodegenMoho.java   | 85 +++---
   .../maven_plugin/wsdl2java/WSDL2JavaMojo.java   | 30 +++
   .../wsdl2js/WSDL2JavaScriptMojo.java| 28 +++---
   maven-plugins/corba/pom.xml | 37 
   maven-plugins/java2wadl-plugin/pom.xml  | 52 +++
   .../javatowadl/ParseJavaDocMojo.java| 91
 
   maven-plugins/java2ws-plugin/pom.xml| 37 
   maven-plugins/pom.xml   | 20 -
   maven-plugins/wadl2java-plugin/pom.xml  | 42 ++---
   .../wadlto/AbstractCodeGeneratorMojo.java   | 81 +
   .../cxf/maven_plugin/wadlto/WADL2JavaMojo.java  | 29 +++
   maven-plugins/wsdl-validator-plugin/pom.xml | 37 
   parent/pom.xml  | 12 +++
   pom.xml | 31 +++
   15 files changed, 194 insertions(+), 460 deletions(-)
 --



 http://git-wip-us.apache.org/repos/asf/cxf/blob/96ed8050/maven-plugins/codegen-plugin/pom.xml
 --
 diff --git a/maven-plugins/codegen-plugin/pom.xml
 b/maven-plugins/codegen-plugin/pom.xml
 index 521d097..0259a06 100644
 --- a/maven-plugins/codegen-plugin/pom.xml
 +++ b/maven-plugins/codegen-plugin/pom.xml
 @@ -56,6 +56,11 @@
   scopeprovided/scope
   /dependency
   dependency
 +groupIdorg.apache.maven.plugin-tools/groupId
 +artifactIdmaven-plugin-annotations/artifactId
 +scopeprovided/scope
 +/dependency
 +dependency
   groupIdorg.codehaus.plexus/groupId
   artifactIdplexus-utils/artifactId
   version2.0.5/version
 @@ -148,41 +153,4 @@
   /dependencies
   /profile
   /profiles
 -build
 -   pluginManagement
 -   plugins
 -   !--This plugin's configuration is used to store
 Eclipse m2e settings only. It has no influence on the Maven build 
 itself.--
 -   plugin
 -   groupIdorg.eclipse.m2e/groupId
 -
 artifactIdlifecycle-mapping/artifactId
 -   version1.0.0/version
 -   configuration
 -   lifecycleMappingMetadata
 -   pluginExecutions
 -   pluginExecution
 -
 pluginExecutionFilter
 -
 groupId
 -
 org.apache.maven.plugins
 -
 /groupId
 -
 artifactId
 -
 maven-plugin

Re: [1/5] cxf git commit: Update plugins to use annotations instead of the javadoc things

[Aki Yoshida]

It looks like this commit has broken cxf-codegen-plugin in trunk.

[INFO] Apache CXF Command Line Tools WSDL to JavaScript Front End
SUCCESS [2.062s]
[INFO] Apache CXF Command Line Tools WSDLTo JAXB Databinding  SUCCESS [1.981s]
[INFO] Apache CXF Maven Plugins .. SUCCESS [0.057s]
[INFO] Apache CXF WSDL Validator Maven2 Plugin ... SUCCESS [1.751s]
[INFO] Apache CXF Code Generation Maven2 Plugins . FAILURE [0.784s]
[INFO] Apache CXF Test Utilities . SKIPPED
...

Does anyone know how to fix it or do we have to wait for Dan?

I just temporarily synch'ed my local branch to one commit earlier to
get the build run.
regards, aki


2015-02-02 19:59 GMT+01:00  dk...@apache.org:
 Repository: cxf
 Updated Branches:
   refs/heads/master 27e877346 - 96ed80508


 Update plugins to use annotations instead of the javadoc things


 Project: http://git-wip-us.apache.org/repos/asf/cxf/repo
 Commit: http://git-wip-us.apache.org/repos/asf/cxf/commit/96ed8050
 Tree: http://git-wip-us.apache.org/repos/asf/cxf/tree/96ed8050
 Diff: http://git-wip-us.apache.org/repos/asf/cxf/diff/96ed8050

 Branch: refs/heads/master
 Commit: 96ed80508cf15f7dc8c2d5a73225a36dbc096ee2
 Parents: bfbc0a2
 Author: Daniel Kulp dk...@apache.org
 Authored: Mon Feb 2 13:58:09 2015 -0500
 Committer: Daniel Kulp dk...@apache.org
 Committed: Mon Feb 2 13:58:43 2015 -0500

 --
  maven-plugins/codegen-plugin/pom.xml| 42 ++---
  .../cxf/maven_plugin/AbstractCodegenMoho.java   | 85 +++---
  .../maven_plugin/wsdl2java/WSDL2JavaMojo.java   | 30 +++
  .../wsdl2js/WSDL2JavaScriptMojo.java| 28 +++---
  maven-plugins/corba/pom.xml | 37 
  maven-plugins/java2wadl-plugin/pom.xml  | 52 +++
  .../javatowadl/ParseJavaDocMojo.java| 91 
  maven-plugins/java2ws-plugin/pom.xml| 37 
  maven-plugins/pom.xml   | 20 -
  maven-plugins/wadl2java-plugin/pom.xml  | 42 ++---
  .../wadlto/AbstractCodeGeneratorMojo.java   | 81 +
  .../cxf/maven_plugin/wadlto/WADL2JavaMojo.java  | 29 +++
  maven-plugins/wsdl-validator-plugin/pom.xml | 37 
  parent/pom.xml  | 12 +++
  pom.xml | 31 +++
  15 files changed, 194 insertions(+), 460 deletions(-)
 --


 http://git-wip-us.apache.org/repos/asf/cxf/blob/96ed8050/maven-plugins/codegen-plugin/pom.xml
 --
 diff --git a/maven-plugins/codegen-plugin/pom.xml 
 b/maven-plugins/codegen-plugin/pom.xml
 index 521d097..0259a06 100644
 --- a/maven-plugins/codegen-plugin/pom.xml
 +++ b/maven-plugins/codegen-plugin/pom.xml
 @@ -56,6 +56,11 @@
  scopeprovided/scope
  /dependency
  dependency
 +groupIdorg.apache.maven.plugin-tools/groupId
 +artifactIdmaven-plugin-annotations/artifactId
 +scopeprovided/scope
 +/dependency
 +dependency
  groupIdorg.codehaus.plexus/groupId
  artifactIdplexus-utils/artifactId
  version2.0.5/version
 @@ -148,41 +153,4 @@
  /dependencies
  /profile
  /profiles
 -build
 -   pluginManagement
 -   plugins
 -   !--This plugin's configuration is used to store 
 Eclipse m2e settings only. It has no influence on the Maven build itself.--
 -   plugin
 -   groupIdorg.eclipse.m2e/groupId
 -   artifactIdlifecycle-mapping/artifactId
 -   version1.0.0/version
 -   configuration
 -   lifecycleMappingMetadata
 -   pluginExecutions
 -   pluginExecution
 -   
 pluginExecutionFilter
 -   
 groupId
 - 
   org.apache.maven.plugins
 -   
 /groupId
 -   
 artifactId
 - 
   maven-plugin-plugin
 -   
 /artifactId
 -   
 versionRange
 - 
   [2.9,)
 -

Re: maven setting for cxf build in using com.googlecode.maven-download-plugin behind firewall?

[Aki Yoshida]

Hi Sergey,

2015-01-22 11:27 GMT+01:00 Sergey Beryozkin sberyoz...@gmail.com:
 Hi Aki

 Not sure about configuring this plugin, may be an alternative plugin exists
 which can do the same but also accept the proxy properties ?

In fact, I also tried codehaus' wagon-maven-plugin (with goal
download-single), but I had the same problem ;-(


 The other possible option for doing the local builds without the internet
 access, predownload this file and update the build to check the file from
 the local directory too ?

Yes. If we can configure the build to check for a local copy and then
upon not finding it, use this download plugin to go to the internet,
that would be a good option.

regards, aki


 Cheers, Sergey

 On 22/01/15 10:14, Aki Yoshida wrote:

 the current CXF snapshots uses com.googlecode.maven-download-plugin to
 download a remote file during build. The background for this is
 described in https://issues.apache.org/jira/browse/CXF-6143.

 I am trying to make this plugin use a local http proxy. I have tried
 setting those java proxy properties -Dhttps.proxyHost etc in my
 MAVEN_OPTS and also setting https_proxy system properties. but it is
 not working. Does anyone know how to make this plugin use an http
 proxy?

 Thanks.

 regards, aki

maven setting for cxf build in using com.googlecode.maven-download-plugin behind firewall?

[Aki Yoshida]

the current CXF snapshots uses com.googlecode.maven-download-plugin to
download a remote file during build. The background for this is
described in https://issues.apache.org/jira/browse/CXF-6143.

I am trying to make this plugin use a local http proxy. I have tried
setting those java proxy properties -Dhttps.proxyHost etc in my
MAVEN_OPTS and also setting https_proxy system properties. but it is
not working. Does anyone know how to make this plugin use an http
proxy?

Thanks.

regards, aki

Re: [VOTE] CXF 2.7.14/3.0.3

[Aki Yoshida]

+1

Regards,
aki

2014-12-03 17:20 GMT+01:00 Daniel Kulp dk...@apache.org:
 This is a vote to release CXF 2.7.14 and 3.0.3.   These versions fix a bunch 
 of bugs users have encountered.  They also provide some additional 
 functionality to make it easier to configure various SSL/TLS things to 
 mitigate various attacks.

 Staging areas:
 2.7.14:
 https://repository.apache.org/content/repositories/orgapachecxf-1033/
 3.0.3:
 https://repository.apache.org/content/repositories/orgapachecxf-1034/

 Tags:
 3.0.3:
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=e157ea4fd4848983a7044614246d04093b8a6936
 2.7.14:
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=b1867aec7a6be2e20f75570f4e99aac628ec73ea

 The vote will be open for at least 72h.

 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: cxf git commit: Including Ekstazi (www.ekstazi.org) profile to optimize execution of the tests

[Aki Yoshida]

@Milos,
this file usually gets deleted after the test completes, right?
And even when the test gets aborted and leaves this file, this will be
be deleted in the next test.

In that case, this file is currently doing not much harm to the build.
We can keep the current pom setting for now and wait for Milo's update
(either not using such temp file or having the reasonable location so
it doesn't need to be explicitly set in the pom).



2014-11-30 4:19 GMT+01:00 Milos Gligoric milos.gligo...@gmail.com:
 Hi Dan,

 Good point.  Currently excludesFile is needed, but the value can be
 any (including target, as you suggested).

 I am working on a new version of Ekstazi, which will not use
 excludesFile. Actually, the new version will not require any changes
 in pom.xml except including Ekstazi plugin.  Due to some other work, I
 cannot say the exact date, but new version should be soon (say in a
 week).  I will announce the new version on
 https://groups.google.com/forum/#!forum/ekstazi.  Also, I will notify
 a CXF developer to remove the line that you mentioned.

 Thanks for the comment,
 Milos

 On Sat, Nov 29, 2014 at 3:50 AM, Daniel Kulp dk...@apache.org wrote:
 +/excludes
 +
 excludesFile${java.io.tmpdir}/${user.name}EkstaziExcludes/excludesFile
 +/configuration

 Does that need to go there?   Can that just be set to the target directory?

 It's really a  bad idea to have it generate and leave things in the tmp dir 
 and I want to make sure a clean really does clean everything related to it.

 Dan



 On Nov 28, 2014, at 4:27 AM, a...@apache.org wrote:

 Repository: cxf
 Updated Branches:
  refs/heads/master c29f64a42 - 9dfb278c7


 Including Ekstazi (www.ekstazi.org) profile to optimize execution of the 
 tests


 Project: http://git-wip-us.apache.org/repos/asf/cxf/repo
 Commit: http://git-wip-us.apache.org/repos/asf/cxf/commit/9dfb278c
 Tree: http://git-wip-us.apache.org/repos/asf/cxf/tree/9dfb278c
 Diff: http://git-wip-us.apache.org/repos/asf/cxf/diff/9dfb278c

 Branch: refs/heads/master
 Commit: 9dfb278c7739b9f4621f43b8146d057e21fafb64
 Parents: c29f64a
 Author: Milos Gligoric milos.gligo...@gmail.com
 Authored: Thu Nov 13 09:25:26 2014 -0600
 Committer: Akitoshi Yoshida a...@apache.org
 Committed: Fri Nov 28 10:25:35 2014 +0100

 --
 .gitignore |  1 +
 parent/pom.xml | 45 +
 2 files changed, 46 insertions(+)
 --


 http://git-wip-us.apache.org/repos/asf/cxf/blob/9dfb278c/.gitignore
 --
 diff --git a/.gitignore b/.gitignore
 index dbf1353..9810ca4 100644
 --- a/.gitignore
 +++ b/.gitignore
 @@ -5,6 +5,7 @@
 .DS_Store
 .checkstyle
 .classpath
 +.ekstazi
 .pmd
 .pmdruleset
 .pmdruleset.xml

 http://git-wip-us.apache.org/repos/asf/cxf/blob/9dfb278c/parent/pom.xml
 --
 diff --git a/parent/pom.xml b/parent/pom.xml
 index 87e2002..a9de550 100644
 --- a/parent/pom.xml
 +++ b/parent/pom.xml
 @@ -1986,5 +1986,50 @@
 defaultGoalclean/defaultGoal
 /build
 /profile
 +
 +!-- experimental profile to activate ekstazi 
 http://www.ekstazi.org --
 +profile
 +idekstazi/id
 +activation
 +property
 +nameekstazi/name
 +/property
 +/activation
 +
 +build
 +plugins
 +plugin
 +groupIdorg.ekstazi/groupId
 +artifactIdekstazi-maven-plugin/artifactId
 +version4.3.0/version
 +configuration
 +!-- always run tests that failed in prevoius 
 run --
 +forcefailingtrue/forcefailing
 +/configuration
 +executions
 +execution
 +iddoit/id
 +goals
 +goalselect/goal
 +goalrestore/goal
 +/goals
 +/execution
 +/executions
 +/plugin
 +
 +plugin
 +artifactIdmaven-surefire-plugin/artifactId
 +configuration
 +argLine${argLine} 
 ${cxf.surefire.fork.vmargs}/argLine
 +excludes
 +
 exclude**/*NoAriesBlueprintTest.java/exclude
 +
 exclude**/*JAXRSDataBindingTest.java/exclude
 +/excludes
 +   

Re: build error in 3.0 systests/jaxrs

[Aki Yoshida]

I haven't updated my ubuntu box for some time (and I still have 13.10
with JDK 1.7.0_45).
On that system, I just ran the test and am seeing the same problem
Jason is getting.

I am not seeing this problem on my OSX with JDK 1.7.0_67.

Does that mean something is incompatible with some Ubuntu or JDK version?

2014-12-01 11:35 GMT+01:00 Sergey Beryozkin sberyoz...@gmail.com:
 Hi

 I've just tried, the test is OK, Ubuntu 14.04, Java 7 patch 67.
 Can you please retry with the latest Java 7 patch ?

 Thanks, Sergey

 On 01/12/14 03:11, Jason Pell wrote:

 With both Java 6 (patch 37) and Java 7 (patch 60)

 On Mon, Dec 1, 2014 at 2:09 PM, Jason Pell ja...@pellcorp.com wrote:

 I get the following exception in 3.0.x fixes when running from command
 line on ubuntu 14.04.  The same error does not appear when executing from
 Eclipse Luna

 Tests run: 203, Failures: 0, Errors: 1, Skipped: 1, Time elapsed: 3.637
 sec  FAILURE! - in
 org.apache.cxf.systest.jaxrs.JAXRSClientServerBookTest

 testWebClientUnwrapBookWithXslt(org.apache.cxf.systest.jaxrs.JAXRSClientServerBookTest)
 Time elapsed: 0.121 sec   ERROR!
 javax.ws.rs.client.ResponseProcessingException: Problem with reading the
 data, class org.apache.cxf.systest.jaxrs.Book, ContentType:
 application/xml.
  at
 com.ctc.wstx.sr.StreamScanner.throwUnexpectedEOF(StreamScanner.java:685)
  at
 com.ctc.wstx.sr.BasicStreamReader.handleEOF(BasicStreamReader.java:2141)
  at

 com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2047)
  at
 com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1131)
  at org.apache.cxf.staxutils.StaxSource.parse(StaxSource.java:164)
  at org.apache.cxf.staxutils.StaxSource.parse(StaxSource.java:268)
  at
 org.apache.xalan.transformer.TrAXFilter.parse(TrAXFilter.java:164)
  at

 com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:217)
  at

 com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:189)
  at

 javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:120)
  at

 javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:103)
  at

 org.apache.cxf.jaxrs.provider.XSLTJaxbProvider.unmarshalFromInputStream(XSLTJaxbProvider.java:272)
  at

 org.apache.cxf.jaxrs.provider.JAXBElementProvider.doUnmarshal(JAXBElementProvider.java:242)
  at

 org.apache.cxf.jaxrs.provider.JAXBElementProvider.readFrom(JAXBElementProvider.java:191)
  at

 org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(JAXRSUtils.java:1322)
  at

 org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:369)
  at

 org.apache.cxf.jaxrs.client.AbstractClient.readBody(AbstractClient.java:499)
  at
 org.apache.cxf.jaxrs.client.WebClient.handleResponse(WebClient.java:1166)
  at
 org.apache.cxf.jaxrs.client.WebClient.doResponse(WebClient.java:1149)
  at

 org.apache.cxf.jaxrs.client.WebClient.doChainedInvocation(WebClient.java:1085)
  at
 org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:883)
  at
 org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:854)
  at org.apache.cxf.jaxrs.client.WebClient.invoke(WebClient.java:417)
  at org.apache.cxf.jaxrs.client.WebClient.get(WebClient.java:600)
  at

 org.apache.cxf.systest.jaxrs.JAXRSClientServerBookTest.testWebClientUnwrapBookWithXslt(JAXRSClientServerBookTest.java:1112)


 Anyone encountered this error before?

Re: xkms test failures

[Aki Yoshida]

I think you have another karaf instance running on your box.

Exception in thread JMX Connector Thread
[service:jmx:rmi://0.0.0.0:4/jndi/rmi://0.0.0.0:1099/karaf-root]
java.lang.RuntimeException:
Port already in use: 4;

2014-11-27 3:28 GMT+01:00 Jim Ma mail2ji...@gmail.com:
 Hi,
 Does anyone hit these failures when run xkms integration tests ? I tried
 these tests from cxf 2.7.13 tag  in different machines(Fedora 20/oracle
 jdk7) and got the same failures.It looks the karaf container didn't start
 well and there are connections timeout. Full error stacktrace, please see
 the attached file.
 Do we have to involve karaf and bundle things for the xkms test ? Is there
 something we can improve to make these test more robust ?

 ValidatorCRLTest.org.apache.cxf.xkms.itests.handlers.validator.ValidatorCRLTest
 » Runtime
   JUnit4Provider.invoke:124-executeTestSet:153-execute:264 » Runtime
 Container...
   ValidatorTest.org.apache.cxf.xkms.itests.handlers.validator.ValidatorTest
 » Runtime
   JUnit4Provider.invoke:124-executeTestSet:153-execute:264 » Runtime
 Container...
   XKMSServiceTest.org.apache.cxf.xkms.itests.service.XKMSServiceTest »
 Runtime C...
   JUnit4Provider.invoke:124-executeTestSet:153-execute:264 » Runtime
 Container...
   XKRSSDisableTest.org.apache.cxf.xkms.itests.service.XKRSSDisableTest »
 Runtime
   JUnit4Provider.invoke:124-executeTestSet:153-execute:264 » Runtime
 Container...

 Cheers,
 Jim

Re: Two different tests for isRequestor??

[Aki Yoshida]

I didn't know there are so many isRequest methods hiding in the code ;-)

I knew only MessageUtils's one, which was probably added later after some time.

The inconsistency that you observed between
AbstractInDatabindingIntereceptor and
AbstractOutDatabindingIntereceptor was the result of this patch
https://svn.apache.org/viewvc?view=revisionrevision=477226
which only fixed this method in AbstractInDatabindingIntereceptor.

In any case, I think we should remove these other methods from the
master version. For the released tracks, we probably need to keep them
as @deprecated with delegating to MessageUtils impl.


2014-11-27 12:49 GMT+01:00 Jason Pell ja...@pellcorp.com:
 Oh and then we have another method  in the AbstractPhaseInterceptor which
 calls

 protected boolean isRequestor(T message) {
 return MessageUtils.isRequestor(message);
 }

 Would it be possible to remove the isRequestor methods from
 AbstractOutDatabindingInterceptor and AbstractInDatabindingInterceptor

 Anyone know of any reason why that would be problematic?

 On Thu, Nov 27, 2014 at 10:45 PM, Jason Pell ja...@pellcorp.com wrote:

 Hi All

 Was wondering if anyone knows why in AbstractOutDatabindingInterceptor,
 isRequestorRole has a definition of:

 protected boolean isRequestor(Message message) {
 return
 Boolean.TRUE.equals(message.containsKey(Message.REQUESTOR_ROLE));
 }

 Whereas in AbstractInDatabindingInterceptor its:

 protected boolean isRequestor(Message message) {
 return Boolean.TRUE.equals(message.get(Message.REQUESTOR_ROLE));
 }


 The first is just returning true if the Message.REQUESTOR_ROLE exists,
 whereas for the second the Message.REQUESTOR_ROLE must be equal to TRUE.

 Seems very strange to have this difference.  Dones anyone know the history
 of this?

Re: [DISCUSS] Remove spring and spring-dm from featues.xml.....

[Aki Yoshida]

+ 1 sounds good.
thanks., aki

2014-11-05 15:40 GMT+01:00 Daniel Kulp dk...@apache.org:

 For 3.1, I’m thinking about removing the dependencies on spring and spring-dm 
 from the features.xml file.   Right now, if you do a feature:install cxf”, 
 you would get spring 3.2 and spring-dm forcibly installed even if you don’t 
 need either of them.  What’s worse is if you need Spring4, you have other 
 problems of multiple versions and such.By removing that dependency, that 
 problem wouldn’t pop up.

 If people need spring-dm, they can “feature:install spring-dm” first (or add 
 to their boot features or something) and it would still work like today.   
 That’s a user impact, but not much of one.

 Thoughts?  Any major objections?

 Also, with dropping support for Karaf 2.3, I THINK we can remove the specs 
 dependencies, at least the API jars that Karaf has already endorsed.   I need 
 to double check that though.

 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: [VOTE] CXF XJC Utils 3.0.2

[Aki Yoshida]

+1

Aki

2014-09-19 15:42 GMT+02:00 Daniel Kulp dk...@apache.org:

 This is a vote to release the 3.0.2 version of the XJC Utils.There are 
 two major changes:

 1) Update the plugin to use all the repositories in the pom to find the 
 extensions so it can locate extensions that aren’t found in central

 2) Add the new bug986 plugin to work around the XJC bug found in the latest 
 versions of JAXB XJC (and Java8).

 #2 is needed to be able to use Java7 and Java8 to build CXF in a way that the 
 WS-Discovery stuff works.


 Staging repo:
 https://repository.apache.org/content/repositories/orgapachecxf-1027/

 Tag:
 https://git-wip-us.apache.org/repos/asf?p=cxf-xjc-utils.git;a=tag;h=758e8639d0bac8c8173fbb353d0110c240b9a804


 Here is my +1.


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: [VOTE] CXF 2.6.15/2.7.12/3.0.1

[Aki Yoshida]

+1

Aki


2014-07-15 21:57 GMT+02:00 Daniel Kulp dk...@apache.org:

 This is a vote to release the latest patch releases on all three branches.

 There are over 80 fixes for 3.0.1 with most back ported to 2.7.12 and some to 
 2.6.15.

 Note: this is expected to be the last release of the 2.6.x branch.

 Tags:
 2.6.15:
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=67f6d1aaba4108b4e42bb2cfee098b8e6bec8ccd
 2.7.12:
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=18e0bb93814c9c8d244816ed9b2ea48a30a7fb38
 3.0.1:
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=dffa15d68cbcea75faa138bfee7c2443ff930505


 Staging repos:
 2.6.15:
 https://repository.apache.org/content/repositories/orgapachecxf-1024/
 2.7.12
 https://repository.apache.org/content/repositories/orgapachecxf-1025/
 3.0.1
 https://repository.apache.org/content/repositories/orgapachecxf-1026/

 Vote will be open for 72 hours.


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: Performance issue with Content-ID computation of multipart MTOM/XOP messages

[Aki Yoshida]

I'm not sure whether it is really necessary to make the cid part
depend on the namespace string.

If we only need to guarantee uniquness within a document, a single
thread calling the createContentID method will get a series of unique
IDs. However, as the static variable counter is not synchronously
updated, currently two threads may get the same ID value but this
situation is not relevant as long as these two threads are working on
two different documents. And even if two threads may be working on the
same document, using the namespace depending value for the cid part
won't decrease the collision chance very much as they are likely to be
using the same namespace value. If we need to guarantee uniqueness
among multiple documents, we will need a different mechanism anyway.
So, I see not much benefit in using the namespace depending variable
here.

regards, aki

2014-07-14 11:11 GMT+02:00 Sergey Beryozkin sberyoz...@gmail.com:
 Hi Alessio

 On 14/07/14 08:54, Alessio Soldano wrote:

 Hi,
 while running some performance benchmarks here, we noticed lot of time
 spent computing the content-id of multipart MTOM/XOP messages, which is
 quite unexpected (at least to me). We have a client consuming a wsdl
 which references an external xsd. That xsd contains a type with base64
 encoded data. The schema declares elementFormDefault=qualified,
 attributeFormDefault=unqualified and
 targetNamespace=org:foo:PurchaseOrder.
 The problem is in AttachmentUtil's createContentID:

  public static String createContentID(String ns) throws
 UnsupportedEncodingException {
  String cid = cxf.apache.org;
  String name = ATT_UUID + - + String.valueOf(++counter);
  if (ns != null  (ns.length()  0)) {
  try {
  URI uri = new URI(ns);
  String host = uri.toURL().getHost();
  cid = host;
  } catch (Exception e) {
  cid = ns;
  }
  }
  return URLEncoder.encode(name, UTF-8) + @ +
 URLEncoder.encode(cid, UTF-8);
  }

 If the code inside the 'if' block is executed, a URL is to be created
 from the namespace string, which in my case is something like
 org:foo:PurchaseOrder (note, I can't change that, it's part of the
 benchmark sources). Building a URL from a String is potentially very
 expensive, because of the involved URLStreamHandler processing. In my
 case, the method will try to locate a URLStreamHandler named something
 like xyz.org.Handler, which obviously does not exist; that causes a
 CNFE to be initialized, thrown and caught in the catch block above. That
 badly affects performances.

 Now, I have few questions:
 1) do we really need that mechanism for computing the content-id from
 the host of the url generated using the namespace? is there a spec
 requiring that?
 2) if that's required, would you mind me trying to add some preliminary
 checks to avoid the URL generation when that's clearly going to raise an
 exception (for instance by parsing the string using a pre-computed
 regular expression) ?


 Doing some basic manual checks would be faster indeed. You can simply try
 URI.getScheme and/or URI.getAuthority, and do some basic checks around it,
 no need to convert to URL for sure...

 Thanks, Sergey


 3) any different idea / solution?

 Thanks
 Alessio

Re: [VOTE] CXF XJC Utils 3.0.1 and buildutils 3.0.0

[Aki Yoshida]

+1

regards, aki


2014-07-02 17:34 GMT+02:00 Daniel Kulp dk...@apache.org:

 This is a vote to release our xjc-utils 3.0.1 subproject and our build utils 
 as 3.0.0.

 Changes for xjc:
 [CXFXJC-7] Make sure list types aren't instantiated.
 Attempt to workaround JAXB-1026 via some byte bode manipulation.

 Changes for buildutils:  (allows better configuration for Eclipse Luna)
 Add some exclude patters for file types we know PMD doesn't need to check
 Update the eclipse settngs to make sure we use the same pmd rules in eclipse

 Tags:
 https://git-wip-us.apache.org/repos/asf?p=cxf-xjc-utils.git;a=commit;h=98ddd72b2c8010069265e5a5d98e93b7d5f4df1f
 https://git-wip-us.apache.org/repos/asf?p=cxf-build-utils.git;a=commit;h=d20d2fb4f8bfec25bdfb30da757c840c0a411c3b

 Staging repo:
 https://repository.apache.org/content/repositories/orgapachecxf-1023/

 Here is my +1.

 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: git commit: [CXF-5827] Use only local name matching for inbound rpc/literal processing

[Aki Yoshida]

Hi Dan,
yes. I changed it to use the local name comparison so that both
unqualified and qualified elements are accepted, where this latter
qualified case seems to happen frequently in some old
implementations in production. The comment lines above that part,
which you added in 2007, talks exactly about this situation and I
thought the intention of the code was to accept both names: qualified
and unqualified for maximum interoperability.

Maybe, I misread your comment. If you are against accepting both types
by default, we could introduce an option to make this behavior
optional or we could revert the change and ask people to configure the
transform feature. But I think, there is benefit in accepting both
elements than strictly rejecting those non-BP compliant elements.

Thanks.

regards, Aki



2014-06-26 22:40 GMT+02:00 Daniel Kulp dk...@apache.org:

 Aki,

 Isn’t the part.getConcreteName()” qname  only the local name (no namespace) 
 in this case?   On the wire, that part name should NOT be qualified so we 
 should be checking to make sure that’s the case to make sure it’s a valid 
 message.


 Dan



 On Jun 26, 2014, at 3:54 PM, a...@apache.org wrote:

 Repository: cxf
 Updated Branches:
  refs/heads/master cd058a977 - bf8247f86


 [CXF-5827] Use only local name matching for inbound rpc/literal processing


 Project: http://git-wip-us.apache.org/repos/asf/cxf/repo
 Commit: http://git-wip-us.apache.org/repos/asf/cxf/commit/bf8247f8
 Tree: http://git-wip-us.apache.org/repos/asf/cxf/tree/bf8247f8
 Diff: http://git-wip-us.apache.org/repos/asf/cxf/diff/bf8247f8

 Branch: refs/heads/master
 Commit: bf8247f8640c59b6647e2dde0c5a142624afdd24
 Parents: cd058a9
 Author: Akitoshi Yoshida a...@apache.org
 Authored: Thu Jun 26 21:54:15 2014 +0200
 Committer: Akitoshi Yoshida a...@apache.org
 Committed: Thu Jun 26 21:54:15 2014 +0200

 --
 .../apache/cxf/binding/soap/interceptor/RPCInInterceptor.java   | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
 --


 http://git-wip-us.apache.org/repos/asf/cxf/blob/bf8247f8/rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/interceptor/RPCInInterceptor.java
 --
 diff --git 
 a/rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/interceptor/RPCInInterceptor.java
  
 b/rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/interceptor/RPCInInterceptor.java
 index cd16a9c..37120a8 100644
 --- 
 a/rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/interceptor/RPCInInterceptor.java
 +++ 
 b/rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/interceptor/RPCInInterceptor.java
 @@ -164,8 +164,9 @@ public class RPCInInterceptor extends 
 AbstractInDatabindingInterceptor {
  partItr.hasNext()) {
 part = partItr.next();
 }
 -
 -if (!qn.equals(part.getConcreteName())) {
 +
 +// only check the localpart as explained above
 +if 
 (!qn.getLocalPart().equals(part.getConcreteName().getLocalPart())) {
 throw new Fault(
 new org.apache.cxf.common.i18n.Message(

 UNKNOWN_RPC_LIT_PART,


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: [VOTE] - Release Apache CXF Fediz 1.1.1

[Aki Yoshida]

+1

Aki

2014-06-11 12:45 GMT+02:00 Colm O hEigeartaigh cohei...@apache.org:
 This is a vote to release Apache CXF Fediz 1.1.1. It upgrades to the latest
 CXF 2.7.x and fixes a licensing issue with a dependency.

 Artifacts:

 https://repository.apache.org/content/repositories/orgapachecxf-1021/

 Git tag:

 https://git-wip-us.apache.org/repos/asf?p=cxf-fediz.git;a=commit;h=5500f3cbf061b8f5b2d763e020df35516823d4e6

 Issues fixed:

 https://issues.apache.org/jira/browse/FEDIZ/fixforversion/12325565/

 Here is my +1.

 Colm.

 --
 Colm O hEigeartaigh

 Talend Community Coder
 http://coders.talend.com

Re: [VOTE] - Release Apache CXF Fediz 1.0.4

[Aki Yoshida]

+1

Aki

2014-06-11 12:43 GMT+02:00 Colm O hEigeartaigh cohei...@apache.org:
 This is a vote to release Apache CXF Fediz 1.0.4. It fixes a couple of
 minor issues and contains an upgrade to the latest version of CXF 2.6.x.

 Artifacts:

 https://repository.apache.org/content/repositories/orgapachecxf-1022/

 Git tag:

 https://git-wip-us.apache.org/repos/asf?p=cxf-fediz.git;a=commit;h=22686242998f89d6bbc0e96167eed1453c5350e6

 Issues fixed:

 https://issues.apache.org/jira/browse/FEDIZ/fixforversion/12324084/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel

 Here is my +1.

 Colm.


 --
 Colm O hEigeartaigh

 Talend Community Coder
 http://coders.talend.com

Re: Build Failure in git

[Aki Yoshida]

http://docs.fedoraproject.org/en-US/Fedora/19/html/Security_Guide/sec-Disabling_firewalld.html

if you have further problems in setting up your fedora system, you
should probably ask at the Fedora forum.

regards, aki

2014-06-11 6:55 GMT+02:00 Malintha Adikari malintha.adik...@gmail.com:
 Hi,

 Yes the problem is not enabled UDP broadcast on firewall. I have tried
 several ways to enable it. But couldn't solve the issue. How can we enable
 UDP broadcast on firewall.

 Note: My OS is Fedora 18

 Regards,
 Malintha


 On Wed, Jun 11, 2014 at 1:16 AM, Malintha Adikari 
 malintha.adik...@gmail.com wrote:

 Hi

 Thank you very much for help.

 On Wed, Jun 11, 2014 at 12:58 AM, Grzegorz Grzybek gr.grzy...@gmail.com
 wrote:

 Hi Malintha - I had this problem too - I had to enable UDP broadcast on my
 firewall (just allow the ports of UDP) - then the tests went fine.

 I am trying to open UDP ports. But still no luck with me . Will keep try
 and update you.

 regards
 Grzegorz Grzybek


 2014-06-10 21:26 GMT+02:00 Daniel Kulp dk...@apache.org:

 
 
  All the UDP tests are passing on the Jenkins builds with Java6  as well
 as
  using Java 6 and Java 7 on my machine locally.
 
 
 
 https://builds.apache.org/view/A-D/view/CXF/job/CXF-Trunk-JDK16/lastBuild/testReport/
 
 
  What OS are you using?   The RedHat folks said there might be some
 issues


 I am using fedora 18 as my OS.


   with the latest versions of RedHat due to broadcast UDP being turned
 off.
  However, the tests should have been updated to detect that OS and skip.
 
 
  Dan
 
 
 
 
  On Jun 10, 2014, at 7:03 AM, Malintha Adikari 
 malintha.adik...@gmail.com
  wrote:
 
   Hi,
  
   I am building Apache CXF from git clone
   https://git-wip-us.apache.org/repos/asf/cxf.git. Following build
 failure
   appeared in the middle of the building process.
  
   Note: I am using java 1.6 and maven 3.0.5. Also I am using a fresh
 maven
   repository.
  
   [INFO] Apache CXF Runtime Object Binding . SUCCESS
  [4.044s]
   [INFO] Apache CXF Runtime Colocated Binding .. SUCCESS
  [1.690s]
   [INFO] Apache CXF Runtime  SUCCESS
  [0.064s]
   [INFO] Apache CXF Runtime Bindings ... SUCCESS
  [0.022s]
   [INFO] Apache CXF Runtime Clustering . SUCCESS
  [1.130s]
   [INFO] Apache CXF Runtime JavaScript Frontend  SUCCESS
  [1.745s]
   [INFO] Apache CXF Runtime HTTP Async Transport ... SUCCESS
  [9.276s]
   [INFO] Apache CXF Runtime HTTP Netty Server Transport  SUCCESS
  [8.421s]
   [INFO] Apache CXF Runtime HTTP Netty Client Transport  SUCCESS
  [16.604s]
   [INFO] Apache CXF Runtime UDP Transport .. FAILURE
  [32.762s]
   [INFO] Apache CXF Runtime WebSocket Transport  SKIPPED
   [INFO] Apache CXF Runtime Security functionality . SKIPPED
   [INFO] Apache CXF Runtime WS MetadataExchange  SKIPPED
   [INFO] Apache CXF Runtime WS Security  SKIPPED
   [INFO] Apache CXF Runtime WS Reliable Messaging .. SKIPPED
   [INFO] Apache CXF Runtime WS Eventing  SKIPPED
   [INFO] Apache CXF JAX-RS Client .. SKIPPED
   [INFO] Apache CXF JAX-RS Extensions: Providers ... SKIPPED
   [INFO] Apache CXF JAX-RS Extensions: Search .. SKIPPED
   [INFO] Apache CXF RS XML Security  SKIPPED
   [INFO] Apache CXF RS SSO SAML  SKIPPED
   [INFO] Apache CXF Runtime RS Security OAuth Parent ... SKIPPED
   [INFO] Apache CXF Runtime OAuth 1.0a . SKIPPED
   [INFO] Apache CXF Runtime OAuth 2.0 .. SKIPPED
   [INFO] Apache CXF Runtime OAuth 2.0 SAML . SKIPPED
   [INFO] Apache CXF Runtime OAuth 2.0 JWT .. SKIPPED
   [INFO] Apache CXF RS Cross-Origin Resource Sharing ... SKIPPED
   [INFO] Apache CXF Runtime Web Management . SKIPPED
   [INFO] Apache CXF Runtime JavaScript Client Generator Tests  SKIPPED
   [INFO] Apache CXF JCA Connection . SKIPPED
   [INFO] Apache CXF CDI Integration  SKIPPED
   [INFO] Apache CXF Integration  SKIPPED
   [INFO] Apache CXF Java2WS Maven2 Plugin .. SKIPPED
   [INFO] Apache CXF Java2WADL Maven2 Plugin  SKIPPED
   [INFO] Apache CXF WADL2Java Code Generation Maven2 Plugin  SKIPPED
   [INFO] Apache CXF CORBA Tools Maven2 Plugins . SKIPPED
   [INFO] Apache CXF Archetype - Simple JAX-WS Java First ... SKIPPED
   [INFO] Apache CXF Archetype - Simple JAX-RS webapp ... SKIPPED
   [INFO] Apache CXF Maven Archetypes ... SKIPPED
   [INFO] Apache CXF STS Core ... SKIPPED
   [INFO] Apache CXF STS war deployment . SKIPPED
   [INFO] Apache CXF STS basic systests . SKIPPED
   [INFO] 

Re: How to get a public jaxrs.xsd at org.apache.cxf support multiple CXF versions

[Aki Yoshida]

Hi Sergey,
Maybe, I am not getting the down side of option 1 right. Option 1
means, the schema contains some definitions that are no longer used. I
don't know if this is really bad. A component can decide which part to
implement and which part to ignore, no?

The down side of option 3 is that you will have some duplicated type
definitions in two namespaces, no?

regards, aki


2014-06-06 11:57 GMT+02:00 Sergey Beryozkin sberyoz...@gmail.com:
 Hi

 In CXF 3.0.0 we've had a client element used to be defined in jaxrs.xsd
 shipped with the rt/frontend/jaxrs module moved out (alongside with the code
 supporting Client API) to a new jaxrs-client.xsd (with a new target
 namespace http://cxf.apache.org/jaxrs-client) now shipped with the
 rt/rs/client module.

 This is documented in the migration guide.

 Note that I've updated a target namespace for a 'client' element not for
 some design reasons but only due to the fact that I came to the conclusion
 it was not possible to have a shared/single target namespace for schemas
 shipped in multiple modules.

 So, after 3.0.0 has been released I've pushed a new jaxrs.xsd schema without
 the 'client' element to org.apache.cxf. And we've started getting reports of
 CXF 2.x clients using jaxrs:client getting the validation issues.

 So I wonder what would should the best strategy be for supporting multiple
 CXF versions validating against a public jaxrs schema be, without having to
 introduce the numbers or dates into target schema namespace (just for the
 sake of simplicity, given that the schemas are in themselves are very stable
 now, with only very attributes or optional elements possibly added in the
 future).

 I can think of 4 options:

 1. The current workaround has been to restore the old 'client' element only
 in the public jaxrs.xsd at org.apache.cxf/schemas just to keep CXF 2.x
 clients using jaxrs:client getting the validation working.
 If it works and will have no side-effects over a some period of time then
 may be we can settle with this solution, even though it's effectively a
 hack.

 2. Revert the migration of 'client' into a new target namespace
 jaxrs-client, have client  restored in jaxrs.xsd, and either 'include'
 jaxrs.xsd or use it directly in rt/rs/client. The downside: we will never be
 able to break a link between RS client and RS frontend modules, which is on
 the map, at the moment only the RS frontend has benefited from getting the
 client code moved out of it, while the client code is still depending on all
 of the frontend RS; may it is not a big deal really

 3. In CXF 3.0.1: update a shipped jaxrs.xsd to have a new target namespace,
 http://cxf.apache.org/jaxrs3x;, restore the old jaxrs.xsd at org.apache.cxf
 and redirect /jaxrs3x requests to a new jaxrs3x.xsd file.
 This is probably the best solution as far as the best practice is concerned.

 4. Add jaxrs2x.xsd file to org.apache.cxf and advise CXF 2.x clients working
 with jaxrs:client update schemaLocation elements accordingly.
 This will work but kind of not cool, breaking the validation for the
 existing working clients is not good, even though it is a tiny change.

 Any comments please ?
 Right now I'd like to see if 1. works and open to doing 3. in CXF 3.0.1

 Thanks, Sergey

Re: How to get a public jaxrs.xsd at org.apache.cxf support multiple CXF versions

[Aki Yoshida]

2014-06-06 17:44 GMT+02:00 Sergey Beryozkin sberyoz...@gmail.com:
 Hi Aki,
 thanks for the comments,

 On 06/06/14 16:32, Aki Yoshida wrote:

 Hi Sergey,
 Maybe, I am not getting the down side of option 1 right. Option 1
 means, the schema contains some definitions that are no longer used. I
 don't know if this is really bad. A component can decide which part to
 implement and which part to ignore, no?

 Right, yes, that is the case, the public jaxrs.xsd schema, available only at
 org.apache.cxf/schemas, will have the 'client' element only to support the
 CXF 2.x clients which use jaxrs:client and expecting it to be in jaxrs.xsd,
 but no longer used by the CXF 3.x code which will use a client in
 jaxrs-client.xsd instead. CXF 3.x itself ships jaxrs.xsd without client.

CXF 3.x itself can ship also the jaxrs.xsd with the unused client
definition with the comment that you described below, no?


 So it would be the simplest option. The only downside is that a CXF 3/x user
 who is browsing the public schemas may get confused, knowing that
 jaxrs-client.xsd also has a 'client' element. I guess I can simply add the
 comments to the public jaxrs.xsd clarifying which consumers can work with
 the client in the public jaxrs.xsd



 The down side of option 3 is that you will have some duplicated type
 definitions in two namespaces, no?

 The option 3 is about having jaxrs.xsd and jaxrs3x.xsd at org.apache.cxf.
 The former will have a target namespace ending with /jaxrs, as it is at
 the moment for all the CXF consumers. The latter will have a targetNamespace
 ending with /jaxrs3x and all CXF clients starting from 3.0.1 will be
 expected to use it when defining jaxrs:server endpoints. So the public
 jaxrs.xsd will keep supporting CXF 2.x and CXF 3.0.0, jaxrs3x.xsd - CXF
 3.0.1 and higher. CXF 3.0.1 will ship jaxrs.xsd only except that its target
 namespace will be ending with /jaxrs3x

Does this mean, your beans.xml for 2.7.x/3.0.0 needs to be updated for
3.0.1 to use the .../jaxrs3x namespace?
And if you want to make the old beans.xml also work for 3.0.1, you
will need duplicated code to handle both namespaces.

And this was not clear to me. Maybe, I don't know the difference
between those non-client schema part of …/jaxrs and .../jaxrs3x
schemas whether there is some incompatible structural changes or
somehow the difference is compatibly shared. I'll look at them to get
a better understanding.

Thanks.
regards, aki

 Cheers, Sergey


 regards, aki


 2014-06-06 11:57 GMT+02:00 Sergey Beryozkin sberyoz...@gmail.com:

 Hi

 In CXF 3.0.0 we've had a client element used to be defined in jaxrs.xsd
 shipped with the rt/frontend/jaxrs module moved out (alongside with the
 code
 supporting Client API) to a new jaxrs-client.xsd (with a new target
 namespace http://cxf.apache.org/jaxrs-client) now shipped with the
 rt/rs/client module.

 This is documented in the migration guide.

 Note that I've updated a target namespace for a 'client' element not for
 some design reasons but only due to the fact that I came to the
 conclusion
 it was not possible to have a shared/single target namespace for schemas
 shipped in multiple modules.

 So, after 3.0.0 has been released I've pushed a new jaxrs.xsd schema
 without
 the 'client' element to org.apache.cxf. And we've started getting reports
 of
 CXF 2.x clients using jaxrs:client getting the validation issues.

 So I wonder what would should the best strategy be for supporting
 multiple
 CXF versions validating against a public jaxrs schema be, without having
 to
 introduce the numbers or dates into target schema namespace (just for the
 sake of simplicity, given that the schemas are in themselves are very
 stable
 now, with only very attributes or optional elements possibly added in the
 future).

 I can think of 4 options:

 1. The current workaround has been to restore the old 'client' element
 only
 in the public jaxrs.xsd at org.apache.cxf/schemas just to keep CXF 2.x
 clients using jaxrs:client getting the validation working.
 If it works and will have no side-effects over a some period of time then
 may be we can settle with this solution, even though it's effectively a
 hack.

 2. Revert the migration of 'client' into a new target namespace
 jaxrs-client, have client  restored in jaxrs.xsd, and either
 'include'
 jaxrs.xsd or use it directly in rt/rs/client. The downside: we will never
 be
 able to break a link between RS client and RS frontend modules, which is
 on
 the map, at the moment only the RS frontend has benefited from getting
 the
 client code moved out of it, while the client code is still depending on
 all
 of the frontend RS; may it is not a big deal really

 3. In CXF 3.0.1: update a shipped jaxrs.xsd to have a new target
 namespace,
 http://cxf.apache.org/jaxrs3x;, restore the old jaxrs.xsd at
 org.apache.cxf
 and redirect /jaxrs3x requests to a new jaxrs3x.xsd file.
 This is probably the best solution as far as the best practice is
 concerned.

 4. Add

Re: [VOTE] CXF XJC Utils 3.0.0

[Aki Yoshida]

+1

2014-05-30 21:10 GMT+02:00 Daniel Kulp dk...@apache.org:

 This is a vote to release a 3.0.0 version of our XJC utils.

 This fixes a bunch of issues that I’ve found and users have found.  It also 
 updates to the latest JAXB which will help on Java8.All tests pass with 
 Java8.

 This drops support for Java5.  Also drops support for Maven 2.x.


 Staging area:
 https://repository.apache.org/content/repositories/orgapachecxf-1020/

 Tag:
 https://git-wip-us.apache.org/repos/asf?p=cxf-xjc-utils.git;a=tag;h=bed1ba575e950af1eab8849ad58ba7bb1018fb51

 Source release is in:
 https://repository.apache.org/content/repositories/orgapachecxf-1020/org/apache/cxf/xjc-utils/xjc-utils/3.0.0/

 Jira issues:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315520version=12327041


 Here is my +1.

 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: [VOTE] CXF 3.0.0

[Aki Yoshida]

+1

I forgot to add the karaf feature part for the websocket transport.
But this is a minor thing and we can add it in 3.0.1.

regards, aki

2014-05-14 22:13 GMT+02:00 Daniel Kulp dk...@apache.org:

 This is a vote to release CXF 3.0.0.It’s been a long time coming, but I 
 think it’s ready to be released.  :-)


 Staging area:
 https://repository.apache.org/content/repositories/orgapachecxf-1019/

 Tag:
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=3ece1e24ea95474a36eaac8de85170f691553a8b


 Vote will be open until Monday the 19th.


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: git commit: Reorder some of hte calls to get the createSequence stuff occuring immediately to fix the tests

[Aki Yoshida]

Hi Dennis,
I was wondering about the code change that caused the test error that
lead to this test code change.

I am seeing the following exception in one of my local old scenarios
that invokes oneway and request-responser operations in that order.
This has been working for 2.7.x and also working with
3.0.0-milerstonres2.

However, I noticed that it is failing with 3.0.0-SNAPSHOT with the
following exception. And this seems to be the same error.

org.apache.cxf.interceptor.Fault: It is not possible to send a create
sequence request to the anonymous address
http://www.w3.org/2005/08/addressing/anonymous
at 
org.apache.cxf.ws.rm.AbstractRMInterceptor.handleMessage(AbstractRMInterceptor.java:104)
at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
at 
org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:81)
at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
at 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
at 
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:243)
at 
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:259)
at 
org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:65)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1088)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1024)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:370)
at 
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
at 
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)
at 
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
at 
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at 
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
at 
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:695)
Caused by: org.apache.cxf.ws.rm.RMException: It is not possible to
send a create sequence request to the anonymous address
http://www.w3.org/2005/08/addressing/anonymous
at org.apache.cxf.ws.rm.RMManager.getSequence(RMManager.java:458)
at 
org.apache.cxf.ws.rm.RMCaptureOutInterceptor.handle(RMCaptureOutInterceptor.java:156)
at 
org.apache.cxf.ws.rm.AbstractRMInterceptor.handleMessage(AbstractRMInterceptor.java:83)
... 24 more

I think there is some regression issue in the code.


regards, aki

2014-05-02 20:29 GMT+02:00  dk...@apache.org:
 Repository: cxf
 Updated Branches:
   refs/heads/master 126775733 - a4c85510a


 Reorder some of hte calls to get the createSequence stuff occuring 
 immediately to fix the tests


 Project: http://git-wip-us.apache.org/repos/asf/cxf/repo
 Commit: http://git-wip-us.apache.org/repos/asf/cxf/commit/a4c85510
 Tree: http://git-wip-us.apache.org/repos/asf/cxf/tree/a4c85510
 Diff: http://git-wip-us.apache.org/repos/asf/cxf/diff/a4c85510

 Branch: refs/heads/master
 Commit: a4c85510a14854349d877510d3688c47457e6b3b
 Parents: 1267757
 Author: Daniel Kulp dk...@apache.org
 Authored: Fri May 2 14:14:55 2014 -0400
 Committer: Daniel Kulp dk...@apache.org
 Committed: Fri May 2 14:14:55 2014 -0400

 --
  .../cxf/systest/ws/policy/RM10PolicyWsdlTest.java  | 11 ++-
  .../cxf/systest/ws/policy/RM12PolicyWsdlTest.java  | 13 +++--
  .../org/apache/cxf/systest/ws/policy/RMPolicyTest.java | 13 +++--
  3 files changed, 20 insertions(+), 17 deletions(-)
 --


 http://git-wip-us.apache.org/repos/asf/cxf/blob/a4c85510/systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/policy/RM10PolicyWsdlTest.java
 --
 diff --git 
 a/systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/policy/RM10PolicyWsdlTest.java
  
 b/systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/policy/RM10PolicyWsdlTest.java
 index 3bb79e8..b19536f 100644
 --- 
 

Re: Copy all these properties to RMClient's message ?

[Aki Yoshida]

Hi Jim,
I think the new client should be using the same context as the
original one, as the newly created one is logically still part of the
original one. But I'm not sure if all the context needs to be copied
into the new one.

I noticed this behavior some months ago (something was not set in
those RM control messages and that was causing some interop issue but
I don't remember exactly what it was)  and wanted to copy the context
property responsible for this behavior to the  RMclient to solve this
issue (but I don't remember why I didn't do this ;-( )

regards, aki


2014-04-24 8:40 GMT+02:00 Jim Ma mail2ji...@gmail.com:
 Hi All,
 When I tried to put all the security configuration properties in the
 requestContext and call a service with both RM and security policy
 enabled(like the service in WSRMWithWSSecurityPolicyTest) :
 bp.getRequestContext().put(SecurityConstants.CALLBACK_HANDLER, new
 KeystorePasswordCallback());
 bp.getRequestContext().put(SecurityConstants.SIGNATURE_PROPERTIES,,
 getResource(/META-INF/security-client.properties));
 
 This doesn't work as expected and there is exception thrown:
 Failed to send RM protocol message {
 http://schemas.xmlsoap.org/ws/2005/02/rm}CreateSequence.:
 org.apache.cxf.interceptor.Fault: Security configuration could not be
 detected. Potential cause: Make sure jaxws:client element with name
 attribute value matching endpoint port is defined as well as a
 ws-security.signature.properties element within it.

 After I investigated the code, I saw all these ws-scurity configuration
 properties are not copied into the new created message by RMClient which
 initialized by RM interceptor.
 That's the root cause for this failure.
 I went back to look at jaxws spec about BindingProvider's requestContext
 and it's scope. There isn't clue and detail to say if these properties
 should be copied into the new created message like RM message from the
 message which send out the real payload with user's setting though
 requestContext.
 Do you think we should copy them ? or What can do to support this easily?
 Thanks in advance.

 Jim

Re: Copy all these properties to RMClient's message ?

[Aki Yoshida]

Hi Dennis,
a combined scenario of ws-rm + ws-sec works fine in general. (and
there is a test case in systests/ws-rm that Jim mentioned).

But I think Jim is trying to control some of its behavior by passing
some properties in the client context and that won't work if those
properties are not copied into the new client's context.

regards, aki


2014-04-24 13:28 GMT+02:00 Dennis Sosnoski d...@sosnoski.com:
 Hi Jim,

 Which version of the code are you using? I've been working on combining
 WS-RM and WS-Security in the 3.0 code. There are still some pieces that need
 to be put in place (especially persisting the security properties so
 messages can be retransmitted), but the basic security+rm operation has been
 working for me in my tests.

 Regards,

   - Dennis

 Dennis M. Sosnoski
 Java Web Services Consulting http://www.sosnoski.com/consult.html
 CXF and Web Services Security Training
 http://www.sosnoski.com/training.html
 Web Services Jump-Start http://www.sosnoski.com/jumpstart.html


 On 04/24/2014 06:40 PM, Jim Ma wrote:

 Hi All,
 When I tried to put all the security configuration properties in the
 requestContext and call a service with both RM and security policy
 enabled(like the service in WSRMWithWSSecurityPolicyTest) :
 bp.getRequestContext().put(SecurityConstants.CALLBACK_HANDLER, new
 KeystorePasswordCallback());
 bp.getRequestContext().put(SecurityConstants.SIGNATURE_PROPERTIES,,
 getResource(/META-INF/security-client.properties));
 
 This doesn't work as expected and there is exception thrown:
 Failed to send RM protocol message {
 http://schemas.xmlsoap.org/ws/2005/02/rm}CreateSequence.:
 org.apache.cxf.interceptor.Fault: Security configuration could not be
 detected. Potential cause: Make sure jaxws:client element with name
 attribute value matching endpoint port is defined as well as a
 ws-security.signature.properties element within it.

 After I investigated the code, I saw all these ws-scurity configuration
 properties are not copied into the new created message by RMClient which
 initialized by RM interceptor.
 That's the root cause for this failure.
 I went back to look at jaxws spec about BindingProvider's requestContext
 and it's scope. There isn't clue and detail to say if these properties
 should be copied into the new created message like RM message from the
 message which send out the real payload with user's setting though
 requestContext.
 Do you think we should copy them ? or What can do to support this easily?
 Thanks in advance.

 Jim

Re: [VOTE] CXF 2.6.14/2.7.11 - take 2

[Aki Yoshida]

Hi Willem,
thanks for your explanation.
regards, aki

2014-04-09 15:30 GMT+02:00 Willem Jiang willem.ji...@gmail.com:
 Hi Aki,

 Thanks for running the test, current CXF-5610 just make sure we don’t publish 
 the same service with the same address twice before the cxf bus shutdown.

 The test error of CxfRsProducerTest is cause by the 
 CxfRsProducerClientFactoryCacheTest  publish the service with the same 
 address before CxfRsProducerTest. It can be fixed by changing the test case, 
 I will update the apache camel master branch to fix the test error.


 --
 Willem Jiang

 Red Hat, Inc.
 Web: http://www.redhat.com
 Blog: http://willemjiang.blogspot.com (English)
 http://jnn.iteye.com (Chinese)
 Twitter: willemjiang
 Weibo: 姜宁willem



 On April 9, 2014 at 8:15:28 PM, Aki Yoshida (elak...@gmail.com) wrote:
 I see camel-cxf's CxfRsProducerTest tests (using camel 2.13.0 and
 trunk) are failing with cxf-2.7.11 and this behavior seems to be
 caused by
 https://issues.apache.org/jira/browse/CXF-5610

 @Willem,
 I was wondering if the issue regarding the REST services (mentioned in
 this ticket) has been resolved or is it still there to affect these
 tests?

 thanks.

 regards, aki

 2014-04-09 5:44 GMT+02:00 Daniel Kulp :
 
 
  It's been 2 months since the last releases... This is a vote to release 
  2.7.11 and 2.6.14.
 
  There are over 60 issues fixed for 2.7.11 and more than 20 ported back to 
  2.6.14.
 
 
  This second attempt fixes the blueprint parsing issues that Aki found as 
  well as a potential
 NPE in the Logging interceptors.
 
 
  Staging area:
  https://repository.apache.org/content/repositories/orgapachecxf-1017/
  https://repository.apache.org/content/repositories/orgapachecxf-1018/
 
  Tag:
  https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=22e7ed37f8967f6fc2e0035f3b56eb5b882e0582
  https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=0245050c1c326a6bfa26186806615dc311686946
 
  This vote will be open for 72 hours.
 
 
  --
  Daniel Kulp
  dk...@apache.org - http://dankulp.com/blog
  Talend Community Coder - http://coders.talend.com
 

Re: [VOTE] CXF 2.6.14/2.7.11 - take 2

[Aki Yoshida]

+1

Aki

2014-04-09 5:44 GMT+02:00 Daniel Kulp dk...@apache.org:


 It's been 2 months since the last releases... This is a vote to release 
 2.7.11 and 2.6.14.

 There are over 60 issues fixed for 2.7.11 and more than 20 ported back to 
 2.6.14.


 This second attempt fixes the blueprint parsing issues that Aki found as well 
 as a potential NPE in the Logging interceptors.


 Staging area:
 https://repository.apache.org/content/repositories/orgapachecxf-1017/
 https://repository.apache.org/content/repositories/orgapachecxf-1018/

 Tag:
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=22e7ed37f8967f6fc2e0035f3b56eb5b882e0582
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=0245050c1c326a6bfa26186806615dc311686946

 This vote will be open for 72 hours.


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: [VOTE] CXF 2.6.14/2.7.11

[Aki Yoshida]

I am observing the following error with 2.7.11 for a blueprint jaxws
client using basic authentication.

Caused by: org.osgi.service.blueprint.container.ComponentDefinitionException:
Error setting property: PropertyDescriptor name: authorization,
getter: class org.apache.cxf.transport.http.HTTPConduit.getAuthorization(),
setter: [class org.apache.cxf.transport.http.HTTPConduit.setAuthorization(class
org.apache.cxf.configuration.security.AuthorizationPolicy)]
at 
org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:941)
at 
org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:907)
at 
org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:888)
at 
org.apache.aries.blueprint.container.BlueprintContainerImpl.injectBeanInstance(BlueprintContainerImpl.java:934)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.cxf.bus.blueprint.ConfigurerImpl.configureBean(ConfigurerImpl.java:128)
at 
org.apache.cxf.bus.blueprint.ConfigurerImpl.configureWithWildCard(ConfigurerImpl.java:188)
at 
org.apache.cxf.bus.blueprint.ConfigurerImpl.configureBean(ConfigurerImpl.java:111)
at 
org.apache.cxf.bus.blueprint.ConfigurerImpl.configureBean(ConfigurerImpl.java:100)
at 
org.apache.cxf.transport.http.HTTPTransportFactory.configure(HTTPTransportFactory.java:189)
at 
org.apache.cxf.transport.http.HTTPTransportFactory.getConduit(HTTPTransportFactory.java:270)
at 
org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransportFactory.java:238)
at 
org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(AbstractConduitSelector.java:110)
at 
org.apache.cxf.endpoint.UpfrontConduitSelector.prepare(UpfrontConduitSelector.java:63)
at 
org.apache.cxf.endpoint.ClientImpl.prepareConduitSelector(ClientImpl.java:896)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:565)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:479)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:382)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:335)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
... 26 more
Caused by: java.lang.Exception: Unable to convert value
javax.xml.bind.JAXBElement@6c6cef3a to type
org.apache.cxf.configuration.security.AuthorizationPolicy
at 
org.apache.aries.blueprint.container.AggregateConverter.convert(AggregateConverter.java:184)
at 
org.apache.aries.blueprint.container.BlueprintRepository.convert(BlueprintRepository.java:402)
at 
org.apache.aries.blueprint.utils.ReflectionUtils$PropertyDescriptor.convert(ReflectionUtils.java:394)
at 
org.apache.aries.blueprint.utils.ReflectionUtils$MethodPropertyDescriptor.internalSet(ReflectionUtils.java:628)
at 
org.apache.aries.blueprint.utils.ReflectionUtils$PropertyDescriptor.set(ReflectionUtils.java:378)
at 
org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:939)
... 49 more

The same scenario runs fine with cxf 2.7.10.
The spring version of the same scenario runs fine with 2.7.11.

Does anyone have an idea?
I need to look at it deeper to find out what has changed to see what
is causing this issue/difference.

regards, aki


2014-04-06 18:34 GMT+02:00 Daniel Kulp dk...@apache.org:

 It's been 2 months since the last releases... This is a vote to release 
 2.7.11 and 2.6.14.

 There are over 60 issues fixed for 2.7.11 and more than 20 ported back to 
 2.6.14.


 Staging area:
 https://repository.apache.org/content/repositories/orgapachecxf-1014/
 https://repository.apache.org/content/repositories/orgapachecxf-1015/

 Tag:
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=6c4a45138976c7c7b770fdaa979cd0eddb2449c6
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=0d3b94e213446763d348fb07c51e71fe00fa3151


 This vote will be open for 72 hours.


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: SOAP over WebSocket

[Aki Yoshida]

Hi Przemyslaw,
I am not sure if your multiplex case needs websockets or the normal
asynchronous soap invocation over http is suitable.

Regarding the current websocket support in cxf, it is supported out of
the box in the current 3.0.0-SNAPSHOT for some scenarios and this part
is documented in the wiki page you found.  There are still many things
to do, so some behavior may change incompatibly in the future.

Our focus was so far on the server side, in particular for jaxrs
scenarios, to push data continuously to the client over the socket.
That means, the service can push data asynchronously to the client
after the initial call is made and the socket is opened .

We don't have a similar capability in the other direction as there is
no output stream of some sort that allows the client to keep writing
to the socket directly..

You can find some samples in the systests/jasrs as the unit test cases
and also a browser based demo in the sample collection. (the projects
paths are mentioned in the wiki page).

The current implementation only supports one particular biding (i.e.,
the way in which the cxf message is bound to the websocke's wire), we
are making this part customizable and provide some other bindings
(e.g., microsoft soap over websocket).

Any feedback and possible contribution is welcome.

regards, aki

2014-04-08 9:47 GMT+02:00 Przemyslaw Bielicki pbieli...@gmail.com:
 Hi,

 does CXF support WebSockets as a transport? I need to support multiplexed
 SOAP and WebSocket protocol looks perfect as a starting point. It is
 bidirectional and full duplex.
 By multiplexing I mean that the client can send messages without waiting
 for the response, and the responses may be sent back in the different order
 that they were sent (I will use message / conversation ID, to identify the
 request and response)

 I looked for the information in the mailing list history, but it's still
 not clear for me if you support WebSocket out-of-the box[1] or I need to
 implement my own transport[2] (that could be a nice contribution to CXF?

 Many thanks,
 Przemyslaw

 [1] http://cxf.apache.org/docs/websocket.html
 [2] http://cxf.apache.org/docs/custom-transport.html

Re: [VOTE] CXF 2.6.14/2.7.11

[Aki Yoshida]

Hi Dan,
I am suspecting there might be some sort of incompatibility introduced
in 2.7.11 with
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=commit;h=545a6fcaf9d503d4e0b08bb4ce4cba12893b7b2c

Below in the exception stack where
org.apache.cxf.configuration.security.AuthorizationPolicy was picked
and complained for 2.7.11, I see AuthorizationPolicyHolder in 2.7.10
which is processed fine and this AuthorizationPolicyHolder was removed
in the above commit. I am still confused with this symptom, But maybe
you have an idea?

thanks.
regards, aki

2014-04-08 12:14 GMT+02:00 Aki Yoshida elak...@gmail.com:
 I am observing the following error with 2.7.11 for a blueprint jaxws
 client using basic authentication.

 Caused by: org.osgi.service.blueprint.container.ComponentDefinitionException:
 Error setting property: PropertyDescriptor name: authorization,
 getter: class org.apache.cxf.transport.http.HTTPConduit.getAuthorization(),
 setter: [class 
 org.apache.cxf.transport.http.HTTPConduit.setAuthorization(class
 org.apache.cxf.configuration.security.AuthorizationPolicy)]
 at 
 org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:941)
 at 
 org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:907)
 at 
 org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:888)
 at 
 org.apache.aries.blueprint.container.BlueprintContainerImpl.injectBeanInstance(BlueprintContainerImpl.java:934)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at 
 org.apache.cxf.bus.blueprint.ConfigurerImpl.configureBean(ConfigurerImpl.java:128)
 at 
 org.apache.cxf.bus.blueprint.ConfigurerImpl.configureWithWildCard(ConfigurerImpl.java:188)
 at 
 org.apache.cxf.bus.blueprint.ConfigurerImpl.configureBean(ConfigurerImpl.java:111)
 at 
 org.apache.cxf.bus.blueprint.ConfigurerImpl.configureBean(ConfigurerImpl.java:100)
 at 
 org.apache.cxf.transport.http.HTTPTransportFactory.configure(HTTPTransportFactory.java:189)
 at 
 org.apache.cxf.transport.http.HTTPTransportFactory.getConduit(HTTPTransportFactory.java:270)
 at 
 org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransportFactory.java:238)
 at 
 org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(AbstractConduitSelector.java:110)
 at 
 org.apache.cxf.endpoint.UpfrontConduitSelector.prepare(UpfrontConduitSelector.java:63)
 at 
 org.apache.cxf.endpoint.ClientImpl.prepareConduitSelector(ClientImpl.java:896)
 at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:565)
 at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:479)
 at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:382)
 at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:335)
 at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
 at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
 ... 26 more
 Caused by: java.lang.Exception: Unable to convert value
 javax.xml.bind.JAXBElement@6c6cef3a to type
 org.apache.cxf.configuration.security.AuthorizationPolicy
 at 
 org.apache.aries.blueprint.container.AggregateConverter.convert(AggregateConverter.java:184)
 at 
 org.apache.aries.blueprint.container.BlueprintRepository.convert(BlueprintRepository.java:402)
 at 
 org.apache.aries.blueprint.utils.ReflectionUtils$PropertyDescriptor.convert(ReflectionUtils.java:394)
 at 
 org.apache.aries.blueprint.utils.ReflectionUtils$MethodPropertyDescriptor.internalSet(ReflectionUtils.java:628)
 at 
 org.apache.aries.blueprint.utils.ReflectionUtils$PropertyDescriptor.set(ReflectionUtils.java:378)
 at 
 org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:939)
 ... 49 more

 The same scenario runs fine with cxf 2.7.10.
 The spring version of the same scenario runs fine with 2.7.11.

 Does anyone have an idea?
 I need to look at it deeper to find out what has changed to see what
 is causing this issue/difference.

 regards, aki


 2014-04-06 18:34 GMT+02:00 Daniel Kulp dk...@apache.org:

 It's been 2 months since the last releases... This is a vote to release 
 2.7.11 and 2.6.14.

 There are over 60 issues fixed for 2.7.11 and more than 20 ported back to 
 2.6.14.


 Staging area:
 https://repository.apache.org/content/repositories/orgapachecxf-1014/
 https://repository.apache.org/content/repositories/orgapachecxf-1015/

 Tag:
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=6c4a45138976c7c7b770fdaa979cd0eddb2449c6
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=0d3b94e213446763d348fb07c51e71fe00fa3151


 This vote will be open for 72 hours.


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: WS-RM and WSDLGetInInterceptor

[Aki Yoshida]

Hi Alessio,
Just look at the code and I think the problem s the
RMDeliveryInteceptor sometimes gets inserted behind
OutputGoingInterceptor, as it only specifies the phase condition and
not the before condition. I think using the correct rule should fix
this issue.
I can look at it to see if that's indeed the case and fix it in that case there.
regards, aki

2014-03-07 16:35 GMT+01:00 Alessio Soldano asold...@redhat.com:
 Hi,
 I'm seeing the exception at [1] when getting the published WSDL for an
 endpoint using WS-RM (policy).
 The reason seems to be the lack of WSAddressing MAP in that case, possibly
 related to the modified interceptor chain being executed when a wsdl GET is
 processed. I believe the RM interceptor should not be run at all when wsdl
 GET requests are processed, but wanted to check here too. And if that's the
 proper approach for solving the problem, should I add it in
 WSDLGetInInterceptor::cleanUpOutInterceptors ?
 Thanks
 Alessio

 [1] http://www.fpaste.org/83382/13942061/raw/

 --
 Alessio Soldano
 Web Service Lead, JBoss

Re: [VOTE] CXF 2.6.13/2.7.10 (attempt 2)

[Aki Yoshida]

+1
Aki

2014-02-06 19:29 GMT+01:00 Daniel Kulp dk...@apache.org:


 This is a vote to release 2.6.13 and 2.7.10.

 For 2.7.10, this is mostly to fix the JAX-WS 2.2 problems in the 2.7.9 
 release that would not allow it to work as a 2.2 runtime.   Also has a couple 
 other minor fixes.

 Both builds also have a fix for a pending security advisory.

 Staging area:
 https://repository.apache.org/content/repositories/orgapachecxf-1008/
 https://repository.apache.org/content/repositories/orgapachecxf-1009/

 Tag:
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.13
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.10

 This vote will be open for 24 hours.

 Note: recent discussion on board@ seems to allow a shorter than 72h vote 
 period as long as the PMC has been doing reviews and such prior to the vote 
 starting and has ample notice of at least 72h and opportunities to weigh in.  
 Since we've had a couple builds with failed votes and plenty of discussions 
 and reviews prior to that, I think we're OK.  (providing I get the 3 votes by 
 tomorrow.  :)  )



 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: [VOTE] Apache CXF 2.7.10

[Aki Yoshida]

+1

Aki

2014-02-05 Daniel Kulp dk...@apache.org:

 This is a vote to release 2.7.10.  This is mostly to fix the JAX-WS 2.2 
 problems in the 2.7.9 release that would not allow it to work as a 2.2 
 runtime.   Also has a couple other minor fixes.


 Staging area:
 https://repository.apache.org/content/repositories/orgapachecxf-1007/

 Tag:
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.10

 This vote will be open for at least 72 hours.

 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: [VOTE] Apache CXF 2.7.9/2.6.12

[Aki Yoshida]

+1

Regards, Aki


2014-01-29 Daniel Kulp dk...@apache.org:


 We've resolved over 60 issues since 2.7.8 and almost 40 ported back to 2.6.12.


 List of issues:
 2.6.12
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12325599
 2.7.9
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12325600

 The Maven staging areas are at:
 2.6.12
 https://repository.apache.org/content/repositories/orgapachecxf-1001/
 2.7.9
 https://repository.apache.org/content/repositories/orgapachecxf-1003/

 The distributions are in the org/apache/cxf/apache-cxf/ directory of the 
 Maven staging areas.


 This releases are tagged at:
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.12
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.9

 This vote will be open for at least 72 hours.



 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: issue with schema loading in spring

[Aki Yoshida]

Hi Dan,
thanks for your input.

In that case, I will go ahead and update the local schemas to use the
absolute URLs for the imports.
As most imports are already using the absolute URLs and they are
working also for offline, if some issue occurs after this change, that
likely just means we forgot to include that particular URL in the BP's
ns-handler's schema map. Then, we can fix it there.

regards, aki

2013/12/13 Daniel Kulp dk...@apache.org:

 Aki,

 Most of the flipping to relative locations was to work around namespace 
 handler issues in Blueprint.   I think those issues are now fixed in the 
 latest blueprint, but I’m not sure if the latest Karaf releases have been 
 updated yet.  If not, we could always start pushing them a bit harder.  :-)

 If we can verify the various situations in blueprint won’t go off to the 
 internet to grab schemas, we could revert them back.

 Dan


 On Dec 11, 2013, at 6:06 AM, Aki Yoshida elak...@gmail.com wrote:

 I noticed a problem of loading a certain xsd schema in spring and I
 identified the cause. But as I remember that we have had a few rounds
 of changes in the past and I would like to ask you if the suggested
 fix makes sense.

 The problem occurs when I try to look up the schema for namespace
 http://www.w3.org/ns/ws-policy; and I have its schemaloc in my
 beans.xml correctly set to http://www.w3.org/2007/02/ws-policy.xsd;

 And as this location is given in the rt-ws-policy's catalog file which
 maps this location to its local resource file
 schemas/ws-policy-200702.xsd. So far, it's fine.

 and this local schema resource has the following import:
  xs:import
  
 namespace=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
  schemaLocation=oasis-200401-wss-wssecurity-secext-1.0.xsd /

 and here it hits the problem because the schema processor thinks this
 schema to be imported is located at
 http://www.w3.org/2007/02/oasis-200401-wss-wssecurity-secext-1.0.xsd,
 as the parent schema ws-policy.xsd was supposed to be located at
 http://www.w3.org/2007/02/;
 and tries to load  it from there and results in

 Caused by: java.io.FileNotFoundException:
 http://www.w3.org/2007/02/oasis-200401-wss-wssecurity-utility-1.0.xsd
 at 
 sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1457)
 at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
 at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown 
 Source)
 at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.parse(Unknown Source)
 at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.parse(Unknown Source)
 at org.apache.xerces.impl.xs.opti.SchemaDOMParser.parse(Unknown Source)
 ... 58 more

 The real schema is located at
 http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
 and this location is also given in rt-ws-policy's catalog file and
 mapped to its local
 schemas/oasis-200401-wss-wssecurity-secext-1.0.xsd.

 One way to fix this issue is to change the way the schemaLocation is
 resolved after a catalog look up occurs that switches the location so
 that in the above case,
 schemaLocation=oasis-200401-wss-wssecurity-secext-1.0.xsd will
 resolve directly to
 schemas/oasis-200401-wss-wssecurity-secext-1.0.xsd instead to its
 logical location
 http://www.w3.org/2007/02/oasis-200401-wss-wssecurity-utility-1.0.xsd;.
 But I find this approach is somehow invasive.

 The better approach would be to always use the absolute location URLs
 in the schemaLocation attribute of imports. In contrast, for
 includes, we can keep the local URLs because the namespace nor the
 location path is not switched.

 I think the original schemas always had the absolute URLs for their
 imports. So, making this change means that we can put the unmodified
 schemas in the local resources folder and let the catalog and
 blueprint handler to do the resolution.

 Should we make this change or will there be some concern or
 alternative approach?

 thanks.
 regards, aki

 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: [VOTE] Apache CXF 3.0.0-milestone1

[Aki Yoshida]

+1

regards, aki

2013/11/20 Daniel Kulp dk...@apache.org:

 We’ve done quite a lot of work toward 3.0.0.  While we still have work to do, 
 I think it’s a good idea to get a stable milestone release out that users can 
 depend on to start testing some of the new stuff and provide feedback about 
 some of the changes. I didn’t really want to call it an alpha (implies to 
 much of a level of instability) or beta/rc (implies too close to actual 
 release, I do expect some more API changes), so I just went with a 
 “milestone1” name.

 Anyway, I’ve started trying to accumulate information about 3.0.0 migrations 
 at:
 http://cxf.apache.org/docs/30-migration-guide.html
 to give you a better idea about what’s there.

 This also includes a new release of the xic-utils to have the new javadoc 
 plugin.


 Tags:
 http://svn.apache.org/repos/asf/cxf/xjc-utils/tags/xjc-utils-2.7.0/
 http://svn.apache.org/repos/asf/cxf/tags/cxf-3.0.0-milestone1/

 Staging repos:
 https://repository.apache.org/content/repositories/orgapachecxf-160/
 https://repository.apache.org/content/repositories/orgapachecxf-161/


 Here is my +1.  Vote open till Monday.

 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: [VOTE] Apache CXF 2.7.8/2.6.11

[Aki Yoshida]

+1
tested OK with cxf-2.7.8 with current camel and olingo.
and with some manual tests on equinox.

the only minor thing I noticed was the build/test order that causes
the fresh clean install to fail at xkms.itests, as xkms.itests gets
executed before osgi/karaf is built and consequently the cxf feature
artifact is not available during the test.

Running org.apache.cxf.xkms.itests.handlers.validator.ValidatorCRLTest
12:12:28,656 | ERROR |
apache.karaf.features.internal.FeaturesServiceImpl | Error installing
boot feature config
java.lang.RuntimeException: URL
[mvn:org.apache.cxf.karaf/apache-cxf/2.7.8/xml/features] could not be
resolved.
at 
org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:195)[1:org.ops4j.pax.url.mvn:1.3.5]
at 
org.apache.karaf.features.internal.FeatureValidationUtil.validate(FeatureValidationUtil.j

... the build order looks like this
[INFO] Apache CXF XKMS Integration Tests
[INFO] Apache CXF XKMS
[INFO] Apache CXF Karaf Parent
[INFO] Apache CXF Karaf Features
[INFO] Apache CXF Karaf Commands

Adding a test dependency in xkms.itests to the cxf feature, as
dependency
groupIdorg.apache.cxf.karaf/groupId
artifactIdapache-cxf/artifactId
version${project.version}/version
typepom/type
scopetest/scope
/dependency

changed the execution order so that the fresh install runs. And I
wanted to ask if I should make this change to trunk, 2,7.x et al or we
should come up with another workaround.

regards, aki


2013/11/20 Daniel Kulp dk...@apache.org:

 We've resolved over 75 issues since 2.7.7 and almost 35 ported back to 2.6.11.


 List of issues:
 2.6.11
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12325006
 2.7.8
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12325005

 The Maven staging areas are at:
 2.6.11
 https://repository.apache.org/content/repositories/orgapachecxf-155/
 2.7.8
 https://repository.apache.org/content/repositories/orgapachecxf-158/

 The distributions are in the org/apache/cxf/apache-cxf/ directory of the 
 Maven staging areas.


 This releases are tagged at:
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.11
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.8

 This vote will be open for at least 72 hours.



 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: Checking of SOAP action in SoapActionInInterceptor: regression in proxy services

[Aki Yoshida]

i think introducing an explicit option like allowWrongAction (or
something that sound better :-) to turn off this action equality-check
is better than using an empty string to automatically turn off the
check. Or we can define a special matchAny kind of action that can be
used in opinfo?

2013/11/13 Andrei Shakirin ashaki...@talend.com:
 Hi,

 I have a bit regression under 2.7.7 because of changes in 
 SoapActionInInterceptor 
 (https://fisheye6.atlassian.com/changelog/cxf?cs=1368559 )

 SoapActionInInterceptor requires that the SOAPAction exactly matches to the 
 service operation.
 The problem is that there are some scenarios where the proxies using 
 Provider API process requests from different clients with any SOAPAction.

 If you don't see security issue in that, I would ignore the check if 
 SoapOperationInfo action has default SOAP action (configured as empty in 
 SoapBindingConfiguration):

 Instead:
 SoapOperationInfo soi = boi.getExtensor(SoapOperationInfo.class);
 if (soi == null || action.equals(soi.getAction())) {
 return;
 }

 Will be:

 SoapOperationInfo soi = boi.getExtensor(SoapOperationInfo.class);
 if ((soi == null) || StringUtils.isEmpty(soi.getAction()) || 
 action.equals(soi.getAction())) {
 return;
 }

 WDYT?

 Regards,
 Andrei.

Re: 2.7.7 possible issue with loading security schema

[Aki Yoshida]

I am aware of the change that we needed to make in the schema lookup
entries for trunk after its api+core packages were refactored.
But I don't know if there was any change in 2.7.x line that can affect
the schema lookup.
regards, aki



2013/9/24 Jason Pell ja...@pellcorp.com:
 I think this issue is causing hanging of startup of my application. I am
 reverting to 2.7.6.

 I will debug and try to figure out what is wrong and raise a jira + fix if
 possible.

 Any info anyone of the devs may have though would be appreciated.

 I am running with spring 3.1 and embedded jetty with WS policy username
 password with with java first

 Sent from my Android phone
 On 24/09/2013 2:49 PM, Jason Pell jp...@apache.org wrote:

 Hi,

 I upgraded our environment to use 2.7.7 and immediately upon deployment I
 started getting the following error:

 org.xml.sax.SAXParseException; systemId:
 http://www.w3.org/2007/02/ws-policy.xsd; lineNumber: 30; columnNumber:
 69; schema_reference.4: Failed to read schema document
 'oasis-200401-wss-wssecurity-secext-1.0.xsd', because 1) could not find the
 document; 2) the document could not be read; 3) the root element of the
 document is not xsd:schema.

 this looks like perhaps there is a spring schemas mapping missing?

 I have lowered the logging for now so that I don't see the WARN, but
 wondered if anyone was aware why I would be seeing this now.

 I am behind a firewall, but I was behind a firewall in 2.7.6 and did not
 see this message in the logs.

 Thanks for any info you might have

Re: 2.7.7 possible issue with loading security schema

[Aki Yoshida]

maybe this is just a guess, but shouldn't adding those referenced
schemas to the relevant BP namespace handlers's schema lookup code
would solve this look up problem? I think those schemas were not
included there because we don't directly use those namespaces in
blueprint.xml.

the relative path problem in spring is strange. I didn't observe this
problem in 2.7.7 when I ran those spring based unit tests without the
network. And we were using a relative path in some schemas (e.g.,
wsrm-manager.xsd) for a long time.

regards, aki





2013/9/24 Daniel Kulp dk...@apache.org:

 Erg….  copy paste apparently cut off the locations.

 http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
  
 http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
 http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
  
 http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
 http://www.w3.org/2000/09/xmldsig# 
 http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd


 Dan

 On Sep 24, 2013, at 12:28 PM, Daniel Kulp dk...@apache.org wrote:


 Ran into this yesterday while trying to diagnose a similar issue with Colm.

 It's a result of:  https://issues.apache.org/jira/browse/CXF-5181

 Apparently there is a complete miss match between Spring and Blueprint in 
 this regards.  If we use full absolute paths, blueprint goes off to the 
 internet.  If we don't, Spring does (by default).  It's really a bug in 
 Spring.  When Spring resolves a resource (such as an xsd), it doesn't set 
 the SystemID on the InputSource.  Thus, the xml parser cannot resolve the 
 relative paths correctly.

 With spring, if you update the schemaLocation in your beans.xml to add:

   
 http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
  http://docs.oasis-open.or
   
 http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
  http://docs.oasis-open.o
   http://www.w3.org/2000/09/xmldsig# 
 http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd

 that will likely fix it.

 I'm going to try and dig into Aries blueprint to see if we can fix the 
 problem with absolute paths there and if so, revert the schemas back.  But 
 for now, we have a workaround for Spring, but not for blueprint so we're 
 using the relative paths that then work with blueprint.

 Dan


 On Sep 24, 2013, at 2:50 AM, Jason Pell ja...@pellcorp.com wrote:

 I think this issue is causing hanging of startup of my application. I am
 reverting to 2.7.6.

 I will debug and try to figure out what is wrong and raise a jira + fix if
 possible.

 Any info anyone of the devs may have though would be appreciated.

 I am running with spring 3.1 and embedded jetty with WS policy username
 password with with java first

 Sent from my Android phone
 On 24/09/2013 2:49 PM, Jason Pell jp...@apache.org wrote:

 Hi,

 I upgraded our environment to use 2.7.7 and immediately upon deployment I
 started getting the following error:

 org.xml.sax.SAXParseException; systemId:
 http://www.w3.org/2007/02/ws-policy.xsd; lineNumber: 30; columnNumber:
 69; schema_reference.4: Failed to read schema document
 'oasis-200401-wss-wssecurity-secext-1.0.xsd', because 1) could not find the
 document; 2) the document could not be read; 3) the root element of the
 document is not xsd:schema.

 this looks like perhaps there is a spring schemas mapping missing?

 I have lowered the logging for now so that I don't see the WARN, but
 wondered if anyone was aware why I would be seeing this now.

 I am behind a firewall, but I was behind a firewall in 2.7.6 and did not
 see this message in the logs.

 Thanks for any info you might have


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: [VOTE] Apache CXF 2.7.7/2.6.10

[Aki Yoshida]

+1

regards, aki


2013/9/14 Daniel Kulp dk...@apache.org:


 We've resolved over 90 issues since 2.7.6 and almost 50 ported back to 2.6.10.

 This also includes an update release of our build-utils to get the PMD stuff 
 needed to work with the latest Eclipse.


 List of issues:
 2.6.10
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12324771
 2.7.7
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12324770

 The Maven staging areas are at:
 build-utils:
 https://repository.apache.org/content/repositories/orgapachecxf-042/
 2.6.10
 https://repository.apache.org/content/repositories/orgapachecxf-041/
 2.7.7
 https://repository.apache.org/content/repositories/orgapachecxf-043/

 The distributions are in the org/apache/cxf/apache-cxf/ directory of the 
 Maven staging areas.


 This releases are tagged at:
 http://svn.apache.org/repos/asf/cxf/build-utils/tags/cxf-build-utils-2.6.0/
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.10
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.7

 This vote will be open for at least 72 hours.


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: Changing WS-RM default to terminate on shutdown

[Aki Yoshida]

it looks like there is some complexity in the desired convenient
default behavior

for non-persistence case, it probably makes more sense to switch the
default behavior to terminate the sequence.

but for johns in-order case, the in-ordeing may break when we don't
keep the old persisted sequence and only let the application decide to
terminate the current sequence and start a new one.

So, I am not really convinced of the benefit of changing the default
of terminateOnShutdown=false, but I also don't find a very strong
argument for keeping the current default.

regards, aki


2013/9/3 John Li j...@mycubes.nl:
 hi all,

 I would also think it logical that the client by default will sent a
 terminate sequence on normal shutdown since it cleans up the resources. In
 the case that the client crashes unexpectedly it should pick up from where
 it ended.

 Regarding relying on maxSequence might cause problems with clients that are
 heavily relying on 'inOrder' delivery. During a pilot we have set this
 sequence to 10 and we have seen that in some cases message 11 was handled
 by the server before message 10. Since inOrder is only working within the
 same sequence and message 11 was sent with a new sequence this seems to be
 'as designed'. Maybe a bit of topic but wanted to mention this while you
 guys are looking into the terminate sequence.

 regards,
 John



 On Mon, Sep 2, 2013 at 11:49 PM, Dennis Sosnoski d...@sosnoski.com wrote:

 On 09/03/2013 02:48 AM, Aki Yoshida wrote:

 ...


 I think, as long as the client either terminates each unused old
 sequence or keeps reusing the old sequence, it is well behaved. In
 contrast, when the client keeps creating a new sequence and never
 terminates those sequences, it's a bad client for himself and for the
 communicating server.


 That's exactly the situation we have now, in the case where a client is
 executed without persistent storage. Even with persistent storage, if the
 client only runs periodically it's a bad practice to keep the same sequence
 around.

 Relying on expires is also not a great idea in general, since this is an
 optional setting that's only controlled by the CXF custom configuration.

   - Dennis

Re: Changing WS-RM default to terminate on shutdown

[Aki Yoshida]

Hi Dennis,
You mean you want to terminate the active sequence when the endpoint
is shutdown? Maybe I am getting what you meant. A sequence should
survive a crash or a normal endpoint shutdown because the persisted
messages for that ws-rm endpoint must survive. So I don't think we
should change the default setting.

We can already try to avoid having non-terminated sequences by setting
the sequence length or validity and let the ws-rm runtime terminate
the sequences periodically.

regards, aki


2013/9/1 Dennis Sosnoski d...@sosnoski.com:
 Right now WS-RM handling allows the user to configure sequence termination
 on shutdown, but defaults to no termination of sequences. This looks like an
 incorrect default, since WS-RM relies on having a TerminateSequence message
 in order to free up resources at the destination. I'd like to change this in
 trunk to default to sending the termination, while allowing the user to
 override with an explicit setting.

 The cost of this is an added message exchange (or potentially two, if the
 server also terminates a reverse sequence) as part of the client shutdown
 process.

 Anyone object?

   - Dennis

 --

 Dennis M. Sosnoski
 Java SOA and Web Services Consulting http://www.sosnoski.com/consult.html
 CXF and Web Services Security Training
 http://www.sosnoski.com/training.html
 Web Services Jump-Start http://www.sosnoski.com/jumpstart.html

Re: Changing WS-RM default to terminate on shutdown

[Aki Yoshida]

Hi Dan,
yes. we could terminate the unused empty sequences at the shutdown or
at the next restart. but those sequences that are not terminated
should not normally cause any problem for the cxf ws-rm client as
these sequences are reused at the restart as long as they are still
valid and they will be terminated when their expiration time or size
is reached.  And if someone wants to terminate an empty sequence at
shutdown, they can always set terminateOnShutdown to true. But we
could add an option to not reuse the old empty sequence at restart and
terminate it if that helps.

I think, as long as the client either terminates each unused old
sequence or keeps reusing the old sequence, it is well behaved. In
contrast, when the client keeps creating a new sequence and never
terminates those sequences, it's a bad client for himself and for the
communicating server. And the server needs to protect against such bad
clients. For this, for instance, the property maxSequence can be set
at the server to limit the number of active sequences.

regards, aki


2013/9/2 Daniel Kulp dk...@apache.org:

 On Sep 2, 2013, at 3:57 AM, Aki Yoshida elak...@gmail.com wrote:

 Hi Dennis,
 You mean you want to terminate the active sequence when the endpoint
 is shutdown? Maybe I am getting what you meant. A sequence should
 survive a crash or a normal endpoint shutdown because the persisted
 messages for that ws-rm endpoint must survive. So I don't think we
 should change the default setting.

 What if we don't have any outstanding messages?   In that case, could we go 
 ahead and terminate the sequence?

 If there are messages, should we add a terminate message to the DB so upon 
 restart or similar, the messages would be sent out and then the terminate 
 sent?

 Just some thoughts.

 Dan



 We can already try to avoid having non-terminated sequences by setting
 the sequence length or validity and let the ws-rm runtime terminate
 the sequences periodically.

 regards, aki


 2013/9/1 Dennis Sosnoski d...@sosnoski.com:
 Right now WS-RM handling allows the user to configure sequence termination
 on shutdown, but defaults to no termination of sequences. This looks like an
 incorrect default, since WS-RM relies on having a TerminateSequence message
 in order to free up resources at the destination. I'd like to change this in
 trunk to default to sending the termination, while allowing the user to
 override with an explicit setting.

 The cost of this is an added message exchange (or potentially two, if the
 server also terminates a reverse sequence) as part of the client shutdown
 process.

 Anyone object?

  - Dennis

 --

 Dennis M. Sosnoski
 Java SOA and Web Services Consulting http://www.sosnoski.com/consult.html
 CXF and Web Services Security Training
 http://www.sosnoski.com/training.html
 Web Services Jump-Start http://www.sosnoski.com/jumpstart.html


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: Cant canonicalize system path

[Aki Yoshida]

I started seeing this problem no so long ago in systests-databinding
and systests-codegen. Before that, we didn't have this problem. I saw
the windows paths are not correctly compared and recognized as one
being the parent of the other. And this is resulting in a
syntactically invalid path.

I have been wondering if we always had this problem but we didn't see
it or some recent change caused this problem.

Using a relative path or converting the path in a way so that the path
comparison works will solve this problem. But I haven't looked into it
in details.

regards, aki




2013/8/1 vladimiro vladimiro.co...@gmail.com:
 Hi,
 when building the CXF trunk (CXF 3.0.0-SNAPHSOT) with the following
 environment:

 Apache Maven 3.1.0 (893ca28a1da9d5f51ac03827af98bb730128f9f2; 2013-06-28
 04:15:32+0200)
 Maven home: C:\apache-maven-3.1.0\bin\..
 Java version: 1.7.0_25, vendor: Oracle Corporation
 Java home: C:\Program Files\Java\jdk1.7.0_25\jre
 Default locale: en_US, platform encoding: Cp1252
 OS name: windows 7, version: 6.1, arch: x86, family: windows



 I have the following error:

 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-eclipse-plugin:2.9:eclipse
 (setup.eclipse.project) on project cxf-systests-databinding: Cant
 canonicalize system path: {0}: The filename, directory name, or volume
 label syntax is incorrect - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
 goal org.apache.maven.plugins:maven-eclipse-plugin:2.9:eclipse
 (setup.eclipse.project) on project cxf-systests-databinding: Cant
 canonicalize system path: {0}
 at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
 at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 at
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
 at
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
 at
 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
 at
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:318)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
 at
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
 at
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:414)
 at
 org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:357)
 Caused by: org.apache.maven.plugin.MojoExecutionException: Cant
 canonicalize system path: {0}
 at
 org.apache.maven.plugin.ide.IdeUtils.getCanonicalPath(IdeUtils.java:147)
 at
 org.apache.maven.plugin.ide.IdeUtils.toRelativeAndFixSeparator(IdeUtils.java:591)
 at
 org.apache.maven.plugin.eclipse.EclipsePlugin.extractResourceDirs(EclipsePlugin.java:1787)
 at
 org.apache.maven.plugin.eclipse.EclipsePlugin.buildDirectoryList(EclipsePlugin.java:1684)
 at
 org.apache.maven.plugin.eclipse.EclipsePlugin.createEclipseWriterConfig(EclipsePlugin.java:1359)
 at
 org.apache.maven.plugin.eclipse.EclipsePlugin.writeConfiguration(EclipsePlugin.java:1178)
 at
 org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:511)
 at
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
 at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
 ... 19 more
 Caused by: java.io.IOException: The filename, directory name, or volume
 label syntax is incorrect
 at java.io.WinNTFileSystem.canonicalize0(Native Method)
 at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:414)
 at java.io.File.getCanonicalPath(File.java:589)
 at
 org.apache.maven.plugin.ide.IdeUtils.getCanonicalPath(IdeUtils.java:143)
 ... 27 more



 After investigation it looks like cxf-codegen-plugin is setting absolute
 paths for maven resource's targetPaths and that makes the eclipse plugin
 crash. See also http://jira.codehaus.org/browse/MECLIPSE-269 for reference.

 I see at lines 359 and 375 of
 org.apache.cxf.maven_plugin.AbstractCodegenMoho:

 ...
 

Re: [VOTE] Apache CXF patch releases (2.5.11/2.6.9/2.7.6 and xjc-utils 2.6.2)

[Aki Yoshida]

Hi Sergey,
thanks for explaining the background.

As discussed on #irc, I agree with you that mentioning it in the
release note for 2.7.6 is fine.

regards, aki

2013/7/18 Sergey Beryozkin sberyoz...@gmail.com:
 Hi Aki, thanks for reporting it,
 the fact an older Jettison version can be picked up in OSGI was not
 something I thought about...
 I reckon this is not a critical issue, unless yourself or others disagree,
 perhaps Dan can mention this issue in CXF 2.7.6 release section as you
 suggested.
 I will also update CXF JSONProvider calling this method conditionally, only
 if a related property is set (FYI, this is to do with affecting the way
 Jettison reporting null properties, null in quotes as null as opposed to
 null)

 Thanks, Sergey

 On 17/07/13 23:39, Aki Yoshida wrote:

 So far all the tests I ran with 2.7.6 are fine except I noticed one thing.

 cxf-2.7.6 uses jettison 1.3.4 and uses a new method that was not in
 1.3.3. So with 1.3.3, it runs into
 javax.ws.rs.InternalServerErrorException: java.lang.NoSuchMethodError:
 org.codehaus.jettison.mapped.Configuration.setWriteNullAsString(Z)V

 The version range given in rt-rs-extension-provider is [1.3,2), so it
 can still pick up the old jettison version that is incompatible with
 it. (not relevant when using karaf cxf feature because that is
 bringing the new one).

 I am not familiar with the jettison's versions, and not sure whether a
 short remark in the 2.7.6 release note is sufficient or some change in
 the code is necessary.

 regards, aki






 2013/7/17 Daniel Kulp dk...@apache.org:



 We've resolved over 75 issues since 2.7.5 and almost 50 ported back to
 2.5.11 and 2.6.9.

 This also includes an minor 2.6.2 release of xjc-utils to get the update
 to the boolean getter plugin that was requested.


 List of issues:
 2.5.11

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12324275
 2.6.9

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12324384
 2.7.6

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12324383

 The Maven staging areas are at:
 xjc-utils:
 https://repository.apache.org/content/repositories/orgapachecxf-153
 2.5.11
 https://repository.apache.org/content/repositories/orgapachecxf-152
 2.6.9
 https://repository.apache.org/content/repositories/orgapachecxf-155
 2.7.6
 https://repository.apache.org/content/repositories/orgapachecxf-159

 The distributions are in the org/apache/cxf/apache-cxf/ directory of the
 Maven staging areas.


 This releases are tagged at:
 http://svn.apache.org/repos/asf/cxf/xjc-utils/tags/xjc-utils-2.6.2/
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.11
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.9
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.6

 This vote will be open for at least 72 hours.


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com



 --
 Sergey Beryozkin

 Talend Community Coders
 http://coders.talend.com/

 Blog: http://sberyozkin.blogspot.com

Re: [VOTE] Apache CXF patch releases (2.5.11/2.6.9/2.7.6 and xjc-utils 2.6.2)

[Aki Yoshida]

+1

thanks.
aki

2013/7/17 Daniel Kulp dk...@apache.org:


 We've resolved over 75 issues since 2.7.5 and almost 50 ported back to 2.5.11 
 and 2.6.9.

 This also includes an minor 2.6.2 release of xjc-utils to get the update to 
 the boolean getter plugin that was requested.


 List of issues:
 2.5.11
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12324275
 2.6.9
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12324384
 2.7.6
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12324383

 The Maven staging areas are at:
 xjc-utils:
 https://repository.apache.org/content/repositories/orgapachecxf-153
 2.5.11
 https://repository.apache.org/content/repositories/orgapachecxf-152
 2.6.9
 https://repository.apache.org/content/repositories/orgapachecxf-155
 2.7.6
 https://repository.apache.org/content/repositories/orgapachecxf-159

 The distributions are in the org/apache/cxf/apache-cxf/ directory of the 
 Maven staging areas.


 This releases are tagged at:
 http://svn.apache.org/repos/asf/cxf/xjc-utils/tags/xjc-utils-2.6.2/
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.11
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.9
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.6

 This vote will be open for at least 72 hours.


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: [VOTE] Apache CXF patch releases (2.5.11/2.6.9/2.7.6 and xjc-utils 2.6.2)

[Aki Yoshida]

So far all the tests I ran with 2.7.6 are fine except I noticed one thing.

cxf-2.7.6 uses jettison 1.3.4 and uses a new method that was not in
1.3.3. So with 1.3.3, it runs into
javax.ws.rs.InternalServerErrorException: java.lang.NoSuchMethodError:
org.codehaus.jettison.mapped.Configuration.setWriteNullAsString(Z)V

The version range given in rt-rs-extension-provider is [1.3,2), so it
can still pick up the old jettison version that is incompatible with
it. (not relevant when using karaf cxf feature because that is
bringing the new one).

I am not familiar with the jettison's versions, and not sure whether a
short remark in the 2.7.6 release note is sufficient or some change in
the code is necessary.

regards, aki






2013/7/17 Daniel Kulp dk...@apache.org:


 We've resolved over 75 issues since 2.7.5 and almost 50 ported back to 2.5.11 
 and 2.6.9.

 This also includes an minor 2.6.2 release of xjc-utils to get the update to 
 the boolean getter plugin that was requested.


 List of issues:
 2.5.11
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12324275
 2.6.9
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12324384
 2.7.6
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12324383

 The Maven staging areas are at:
 xjc-utils:
 https://repository.apache.org/content/repositories/orgapachecxf-153
 2.5.11
 https://repository.apache.org/content/repositories/orgapachecxf-152
 2.6.9
 https://repository.apache.org/content/repositories/orgapachecxf-155
 2.7.6
 https://repository.apache.org/content/repositories/orgapachecxf-159

 The distributions are in the org/apache/cxf/apache-cxf/ directory of the 
 Maven staging areas.


 This releases are tagged at:
 http://svn.apache.org/repos/asf/cxf/xjc-utils/tags/xjc-utils-2.6.2/
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.11
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.9
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.6

 This vote will be open for at least 72 hours.


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: ehcache version used in cxf build

[Aki Yoshida]

Hi Jason,
I suppose you haven't had time for this.

Since I see Dan preparing for the 2.7.x release today, I would like to
include this ehcache fix in the release if we still got time so that
we can use cxf 2.7.6 with a newer ehcache. I made a local change for
trunk (not updating the ehcache version in pom yet there but changed
the code to use reflection to pick up the right method). I can
integrate the corresponding changes into 2.7.x and add them to the
ticket. Please take a look.
Thanks.

regards, aki

2013/7/12 Jason Pell ja...@pellcorp.com:
 Hi,

 I did not get to this this week.  I have been in xtext hell all week, and
 performance problems with xtext have continued with no resolution.  I hope
 to resolve them in the next day or so.


 On Thu, Jul 11, 2013 at 1:46 AM, Aki Yoshida elak...@gmail.com wrote:

 okay. then i'll wait for you.

 2013/7/7 Jason Pell ja...@pellcorp.com:
  I might have time end of next week so leave with me for the moment.
 
  On Jul 7, 2013 6:54 AM, Aki Yoshida elak...@gmail.com wrote:
 
  Hi Jason,
 
  I wanted to have a patched snapshot sometime next week. But I am not
  around in the beginning of the next week, so I was wondering if you
  wanted
  to work on it in the next few days :-). But if you can't find time next
  week, I can look at it next week then.
 
  regards, aki
 
 
  2013/7/5 Jason Pell ja...@pellcorp.com
 
  It depends when you need it done :-)
 
  Its been on my list of todos for a long time and i am flat out on my
  day
  job with other stuff. Might be able to look at it in a few weeks.
 
  On Jul 5, 2013 10:46 PM, Aki Yoshida elak...@gmail.com wrote:
 
  Hi Colm, all,
 
  My mind has been going back and forth :-(
 
  I think we should make cxf 2.7.x, et al use a reflection based method
  so
  that we can use either ehcache 2.5.1 or a higher version at runtime.
  If we
  don't do this and either stick to the current 2.5.1 usage or switch
  to the
  new 2.5.2 usage, we will have to set its ehcache range to either
  [2.5.0,2.5.1] or [2.5.2,3.0.0), and that will look sad.
 
  For cxf trunk, we can update its compile time dependency to ehcache
  2.7.2 and since the code change has to go into 2.7,x, we can also
  include
  this change for rt/rs/security/sso/saml that uses the create method.
  And we
  need an equivalent change in wss4j trunk to be consistent.
 
  @Jason,
  Will you be doing the change for cxf or shall I do it or help you
  some
  part? Let me know.
 
  thanks.
  aki
 
 
 
 
  2013/7/5 Colm O hEigeartaigh cohei...@apache.org
 
  Hi Aki,
 
  EHCacheManagerHolder has only been moved to WSS4J trunk and so only
  affects
  CXF trunk. It still exists in CXF 2.7.x. I think you are probably
  right,
  and that we should only upgrade EhCache for CXF trunk and not 2.7.x.
 
  Colm.
 
 
  On Thu, Jul 4, 2013 at 5:48 PM, Aki Yoshida elak...@gmail.com
  wrote:
 
   I just noticed that EHCacheManagerHolder used in cxf trunk has
   been
   moved
   to wss4j-ws-security-common''s org.apache.wss4j.common.cache. So
   this
   handling needs to be done there. This component currently has the
   same
   setting like in cxf's 2.7.x (i.e, compiles with 2.5.1, uses
   create()
   and
   sets the range [2.5.0, 3.0.0).
  
   Maybe, there are other components that are also using 2.5.1 with
   this
   default 2.5 range and if these rely on the old behavior, they
   cannot
   upgrade to ehcache to 2.5.2 or higher. So maybe it may not be a
   good
   idea
   to change cxf 2.7.x's ehcache's lower range to 2.5.2.
  
   @Colm
   are you reading this thread?
  
   thanks.
   aki
  
  
   2013/7/4 Aki Yoshida elak...@gmail.com
  
maybe I should revert my opinion.
   
if we can change the cxf 2.7.x et al branches to require ehcache
2.5.2,
that will be probably better than putting more effort to support
2.5.1.
   
   
   
2013/7/4 Aki Yoshida elak...@gmail.com
   
hi,
thanks all for the information.
   
Is this issue about the manager instance that is created using
the
   create
method in the newer version (eg., 2.5.2 and also 2.6.6, etc)
being
a
singleton? In other words, in the newer version to have the
same
   behavior,
the newly introduced method newInstance needs to be instead
called?
   
If that's the case, we should put the code to handle both cases
in
all
code lines.
   
thanks.
aki
   
   
2013/7/4 Jason Pell ja...@pellcorp.com
   
Sorry guys i never got back to this one. Would be easier i
should
think
to fix this for 3.0 and no longer support the old version at
all
thus
   no
reflection magic.
On Jul 4, 2013 7:04 AM, Daniel Kulp dk...@apache.org
wrote:
   
Aki,
   
This was on my todo list to look at, just never have managed
to
find
the time.   There is an issue logged about it:
   
https://issues.apache.org/jira/browse/CXF-4577
   
If you have time, feel free to grab it and see what you can
find
out

Re: ehcache version used in cxf build

[Aki Yoshida]

okay. then i'll wait for you.

2013/7/7 Jason Pell ja...@pellcorp.com:
 I might have time end of next week so leave with me for the moment.

 On Jul 7, 2013 6:54 AM, Aki Yoshida elak...@gmail.com wrote:

 Hi Jason,

 I wanted to have a patched snapshot sometime next week. But I am not
 around in the beginning of the next week, so I was wondering if you wanted
 to work on it in the next few days :-). But if you can't find time next
 week, I can look at it next week then.

 regards, aki


 2013/7/5 Jason Pell ja...@pellcorp.com

 It depends when you need it done :-)

 Its been on my list of todos for a long time and i am flat out on my day
 job with other stuff. Might be able to look at it in a few weeks.

 On Jul 5, 2013 10:46 PM, Aki Yoshida elak...@gmail.com wrote:

 Hi Colm, all,

 My mind has been going back and forth :-(

 I think we should make cxf 2.7.x, et al use a reflection based method so
 that we can use either ehcache 2.5.1 or a higher version at runtime. If we
 don't do this and either stick to the current 2.5.1 usage or switch to the
 new 2.5.2 usage, we will have to set its ehcache range to either
 [2.5.0,2.5.1] or [2.5.2,3.0.0), and that will look sad.

 For cxf trunk, we can update its compile time dependency to ehcache
 2.7.2 and since the code change has to go into 2.7,x, we can also include
 this change for rt/rs/security/sso/saml that uses the create method. And we
 need an equivalent change in wss4j trunk to be consistent.

 @Jason,
 Will you be doing the change for cxf or shall I do it or help you some
 part? Let me know.

 thanks.
 aki




 2013/7/5 Colm O hEigeartaigh cohei...@apache.org

 Hi Aki,

 EHCacheManagerHolder has only been moved to WSS4J trunk and so only
 affects
 CXF trunk. It still exists in CXF 2.7.x. I think you are probably
 right,
 and that we should only upgrade EhCache for CXF trunk and not 2.7.x.

 Colm.


 On Thu, Jul 4, 2013 at 5:48 PM, Aki Yoshida elak...@gmail.com wrote:

  I just noticed that EHCacheManagerHolder used in cxf trunk has been
  moved
  to wss4j-ws-security-common''s org.apache.wss4j.common.cache. So this
  handling needs to be done there. This component currently has the
  same
  setting like in cxf's 2.7.x (i.e, compiles with 2.5.1, uses create()
  and
  sets the range [2.5.0, 3.0.0).
 
  Maybe, there are other components that are also using 2.5.1 with this
  default 2.5 range and if these rely on the old behavior, they cannot
  upgrade to ehcache to 2.5.2 or higher. So maybe it may not be a good
  idea
  to change cxf 2.7.x's ehcache's lower range to 2.5.2.
 
  @Colm
  are you reading this thread?
 
  thanks.
  aki
 
 
  2013/7/4 Aki Yoshida elak...@gmail.com
 
   maybe I should revert my opinion.
  
   if we can change the cxf 2.7.x et al branches to require ehcache
   2.5.2,
   that will be probably better than putting more effort to support
   2.5.1.
  
  
  
   2013/7/4 Aki Yoshida elak...@gmail.com
  
   hi,
   thanks all for the information.
  
   Is this issue about the manager instance that is created using the
  create
   method in the newer version (eg., 2.5.2 and also 2.6.6, etc) being
   a
   singleton? In other words, in the newer version to have the same
  behavior,
   the newly introduced method newInstance needs to be instead
   called?
  
   If that's the case, we should put the code to handle both cases in
   all
   code lines.
  
   thanks.
   aki
  
  
   2013/7/4 Jason Pell ja...@pellcorp.com
  
   Sorry guys i never got back to this one. Would be easier i should
   think
   to fix this for 3.0 and no longer support the old version at all
   thus
  no
   reflection magic.
   On Jul 4, 2013 7:04 AM, Daniel Kulp dk...@apache.org wrote:
  
   Aki,
  
   This was on my todo list to look at, just never have managed to
   find
   the time.   There is an issue logged about it:
  
   https://issues.apache.org/jira/browse/CXF-4577
  
   If you have time, feel free to grab it and see what you can find
   out.
  
   Dan
  
  
  
  
   On Jul 3, 2013, at 4:58 PM, Aki Yoshida elak...@gmail.com
   wrote:
  
cxf's trunk and branches (2.7.x, 2.6.x, etc) all use ehcache
2.5.1
  and
create the karaf feature with the corresponding smx's bundle
  version.
   But
the version range specified in the package imports is set as
   [2.5.0,3.0.0),
so we could use a newer version in runtime.
   
As ehcache 2.5.1 is rather old (from 2012-01) and there are
newer
   versions
such as 2.6.6 (2013-05) and 2.7.2 (2013-07) which is already
an
osgi-bundle,  I was wondering if we can use a newer version
for
   trunk's
build. There are some disappeared classes and other changes,
but the
   usage
in cxf seem to be compatible with these versions. I tried both
2.6.6
   and
2.7.2, and the build itself seems to run without problems.
   
How do you think about upgrading ehcache to ehcache 2.7.2 for
trunk
   so that
we can test cxf not just against old ehcache 2.5.1?
   
As comparison

Re: ehcache version used in cxf build

[Aki Yoshida]

Hi Colm, all,

My mind has been going back and forth :-(

I think we should make cxf 2.7.x, et al use a reflection based method so
that we can use either ehcache 2.5.1 or a higher version at runtime. If we
don't do this and either stick to the current 2.5.1 usage or switch to the
new 2.5.2 usage, we will have to set its ehcache range to either
[2.5.0,2.5.1] or [2.5.2,3.0.0), and that will look sad.

For cxf trunk, we can update its compile time dependency to ehcache 2.7.2
and since the code change has to go into 2.7,x, we can also include this
change for rt/rs/security/sso/saml that uses the create method. And we need
an equivalent change in wss4j trunk to be consistent.

@Jason,
Will you be doing the change for cxf or shall I do it or help you some
part? Let me know.

thanks.
aki




2013/7/5 Colm O hEigeartaigh cohei...@apache.org

 Hi Aki,

 EHCacheManagerHolder has only been moved to WSS4J trunk and so only affects
 CXF trunk. It still exists in CXF 2.7.x. I think you are probably right,
 and that we should only upgrade EhCache for CXF trunk and not 2.7.x.

 Colm.


 On Thu, Jul 4, 2013 at 5:48 PM, Aki Yoshida elak...@gmail.com wrote:

  I just noticed that EHCacheManagerHolder used in cxf trunk has been moved
  to wss4j-ws-security-common''s org.apache.wss4j.common.cache. So this
  handling needs to be done there. This component currently has the same
  setting like in cxf's 2.7.x (i.e, compiles with 2.5.1, uses create() and
  sets the range [2.5.0, 3.0.0).
 
  Maybe, there are other components that are also using 2.5.1 with this
  default 2.5 range and if these rely on the old behavior, they cannot
  upgrade to ehcache to 2.5.2 or higher. So maybe it may not be a good idea
  to change cxf 2.7.x's ehcache's lower range to 2.5.2.
 
  @Colm
  are you reading this thread?
 
  thanks.
  aki
 
 
  2013/7/4 Aki Yoshida elak...@gmail.com
 
   maybe I should revert my opinion.
  
   if we can change the cxf 2.7.x et al branches to require ehcache 2.5.2,
   that will be probably better than putting more effort to support 2.5.1.
  
  
  
   2013/7/4 Aki Yoshida elak...@gmail.com
  
   hi,
   thanks all for the information.
  
   Is this issue about the manager instance that is created using the
  create
   method in the newer version (eg., 2.5.2 and also 2.6.6, etc) being a
   singleton? In other words, in the newer version to have the same
  behavior,
   the newly introduced method newInstance needs to be instead called?
  
   If that's the case, we should put the code to handle both cases in all
   code lines.
  
   thanks.
   aki
  
  
   2013/7/4 Jason Pell ja...@pellcorp.com
  
   Sorry guys i never got back to this one. Would be easier i should
 think
   to fix this for 3.0 and no longer support the old version at all thus
  no
   reflection magic.
   On Jul 4, 2013 7:04 AM, Daniel Kulp dk...@apache.org wrote:
  
   Aki,
  
   This was on my todo list to look at, just never have managed to find
   the time.   There is an issue logged about it:
  
   https://issues.apache.org/jira/browse/CXF-4577
  
   If you have time, feel free to grab it and see what you can find
 out.
  
   Dan
  
  
  
  
   On Jul 3, 2013, at 4:58 PM, Aki Yoshida elak...@gmail.com wrote:
  
cxf's trunk and branches (2.7.x, 2.6.x, etc) all use ehcache 2.5.1
  and
create the karaf feature with the corresponding smx's bundle
  version.
   But
the version range specified in the package imports is set as
   [2.5.0,3.0.0),
so we could use a newer version in runtime.
   
As ehcache 2.5.1 is rather old (from 2012-01) and there are newer
   versions
such as 2.6.6 (2013-05) and 2.7.2 (2013-07) which is already an
osgi-bundle,  I was wondering if we can use a newer version for
   trunk's
build. There are some disappeared classes and other changes, but
 the
   usage
in cxf seem to be compatible with these versions. I tried both
 2.6.6
   and
2.7.2, and the build itself seems to run without problems.
   
How do you think about upgrading ehcache to ehcache 2.7.2 for
 trunk
   so that
we can test cxf not just against old ehcache 2.5.1?
   
As comparison, camel trunk uses ehcache 2.7.0, while 2.11.x uses
   2.5.2.
   
regards, aki
  
   --
   Daniel Kulp
   dk...@apache.org - http://dankulp.com/blog
   Talend Community Coder - http://coders.talend.com
  
  
  
  
 



 --
 Colm O hEigeartaigh

 Talend Community Coder
 http://coders.talend.com

Re: CXF-2.6.x - Build # 4152 - Still Failing

[Aki Yoshida]

Does anyone know why 2.6.x build is failing all the time?
I see only the following error in the last couple of builds

SEVERE: I/O error in channel channel
java.io.StreamCorruptedException
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1332)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at hudson.remoting.Command.readFrom(Command.java:92)
at 
hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59)
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)
channel stopped
ERROR: Maven JVM terminated unexpectedly with exit code 0


thanks.


regards, aki



2013/7/5 Apache Jenkins Server jenk...@builds.apache.org

 The Apache Jenkins build system has built CXF-2.6.x (build #4152)

 Status: Still Failing

 Check console output at https://builds.apache.org/job/CXF-2.6.x/4152/ to
 view the results.

Re: ehcache version used in cxf build

[Aki Yoshida]

hi,
thanks all for the information.

Is this issue about the manager instance that is created using the create
method in the newer version (eg., 2.5.2 and also 2.6.6, etc) being a
singleton? In other words, in the newer version to have the same behavior,
the newly introduced method newInstance needs to be instead called?

If that's the case, we should put the code to handle both cases in all code
lines.

thanks.
aki


2013/7/4 Jason Pell ja...@pellcorp.com

 Sorry guys i never got back to this one. Would be easier i should think to
 fix this for 3.0 and no longer support the old version at all thus no
 reflection magic.
 On Jul 4, 2013 7:04 AM, Daniel Kulp dk...@apache.org wrote:

 Aki,

 This was on my todo list to look at, just never have managed to find the
 time.   There is an issue logged about it:

 https://issues.apache.org/jira/browse/CXF-4577

 If you have time, feel free to grab it and see what you can find out.

 Dan




 On Jul 3, 2013, at 4:58 PM, Aki Yoshida elak...@gmail.com wrote:

  cxf's trunk and branches (2.7.x, 2.6.x, etc) all use ehcache 2.5.1 and
  create the karaf feature with the corresponding smx's bundle version.
 But
  the version range specified in the package imports is set as
 [2.5.0,3.0.0),
  so we could use a newer version in runtime.
 
  As ehcache 2.5.1 is rather old (from 2012-01) and there are newer
 versions
  such as 2.6.6 (2013-05) and 2.7.2 (2013-07) which is already an
  osgi-bundle,  I was wondering if we can use a newer version for trunk's
  build. There are some disappeared classes and other changes, but the
 usage
  in cxf seem to be compatible with these versions. I tried both 2.6.6 and
  2.7.2, and the build itself seems to run without problems.
 
  How do you think about upgrading ehcache to ehcache 2.7.2 for trunk so
 that
  we can test cxf not just against old ehcache 2.5.1?
 
  As comparison, camel trunk uses ehcache 2.7.0, while 2.11.x uses 2.5.2.
 
  regards, aki

 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: ehcache version used in cxf build

[Aki Yoshida]

maybe I should revert my opinion.

if we can change the cxf 2.7.x et al branches to require ehcache 2.5.2,
that will be probably better than putting more effort to support 2.5.1.



2013/7/4 Aki Yoshida elak...@gmail.com

 hi,
 thanks all for the information.

 Is this issue about the manager instance that is created using the create
 method in the newer version (eg., 2.5.2 and also 2.6.6, etc) being a
 singleton? In other words, in the newer version to have the same behavior,
 the newly introduced method newInstance needs to be instead called?

 If that's the case, we should put the code to handle both cases in all
 code lines.

 thanks.
 aki


 2013/7/4 Jason Pell ja...@pellcorp.com

 Sorry guys i never got back to this one. Would be easier i should think
 to fix this for 3.0 and no longer support the old version at all thus no
 reflection magic.
 On Jul 4, 2013 7:04 AM, Daniel Kulp dk...@apache.org wrote:

 Aki,

 This was on my todo list to look at, just never have managed to find the
 time.   There is an issue logged about it:

 https://issues.apache.org/jira/browse/CXF-4577

 If you have time, feel free to grab it and see what you can find out.

 Dan




 On Jul 3, 2013, at 4:58 PM, Aki Yoshida elak...@gmail.com wrote:

  cxf's trunk and branches (2.7.x, 2.6.x, etc) all use ehcache 2.5.1 and
  create the karaf feature with the corresponding smx's bundle version.
 But
  the version range specified in the package imports is set as
 [2.5.0,3.0.0),
  so we could use a newer version in runtime.
 
  As ehcache 2.5.1 is rather old (from 2012-01) and there are newer
 versions
  such as 2.6.6 (2013-05) and 2.7.2 (2013-07) which is already an
  osgi-bundle,  I was wondering if we can use a newer version for trunk's
  build. There are some disappeared classes and other changes, but the
 usage
  in cxf seem to be compatible with these versions. I tried both 2.6.6
 and
  2.7.2, and the build itself seems to run without problems.
 
  How do you think about upgrading ehcache to ehcache 2.7.2 for trunk so
 that
  we can test cxf not just against old ehcache 2.5.1?
 
  As comparison, camel trunk uses ehcache 2.7.0, while 2.11.x uses 2.5.2.
 
  regards, aki

 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: ehcache version used in cxf build

[Aki Yoshida]

I just noticed that EHCacheManagerHolder used in cxf trunk has been moved
to wss4j-ws-security-common''s org.apache.wss4j.common.cache. So this
handling needs to be done there. This component currently has the same
setting like in cxf's 2.7.x (i.e, compiles with 2.5.1, uses create() and
sets the range [2.5.0, 3.0.0).

Maybe, there are other components that are also using 2.5.1 with this
default 2.5 range and if these rely on the old behavior, they cannot
upgrade to ehcache to 2.5.2 or higher. So maybe it may not be a good idea
to change cxf 2.7.x's ehcache's lower range to 2.5.2.

@Colm
are you reading this thread?

thanks.
aki


2013/7/4 Aki Yoshida elak...@gmail.com

 maybe I should revert my opinion.

 if we can change the cxf 2.7.x et al branches to require ehcache 2.5.2,
 that will be probably better than putting more effort to support 2.5.1.



 2013/7/4 Aki Yoshida elak...@gmail.com

 hi,
 thanks all for the information.

 Is this issue about the manager instance that is created using the create
 method in the newer version (eg., 2.5.2 and also 2.6.6, etc) being a
 singleton? In other words, in the newer version to have the same behavior,
 the newly introduced method newInstance needs to be instead called?

 If that's the case, we should put the code to handle both cases in all
 code lines.

 thanks.
 aki


 2013/7/4 Jason Pell ja...@pellcorp.com

 Sorry guys i never got back to this one. Would be easier i should think
 to fix this for 3.0 and no longer support the old version at all thus no
 reflection magic.
 On Jul 4, 2013 7:04 AM, Daniel Kulp dk...@apache.org wrote:

 Aki,

 This was on my todo list to look at, just never have managed to find
 the time.   There is an issue logged about it:

 https://issues.apache.org/jira/browse/CXF-4577

 If you have time, feel free to grab it and see what you can find out.

 Dan




 On Jul 3, 2013, at 4:58 PM, Aki Yoshida elak...@gmail.com wrote:

  cxf's trunk and branches (2.7.x, 2.6.x, etc) all use ehcache 2.5.1 and
  create the karaf feature with the corresponding smx's bundle version.
 But
  the version range specified in the package imports is set as
 [2.5.0,3.0.0),
  so we could use a newer version in runtime.
 
  As ehcache 2.5.1 is rather old (from 2012-01) and there are newer
 versions
  such as 2.6.6 (2013-05) and 2.7.2 (2013-07) which is already an
  osgi-bundle,  I was wondering if we can use a newer version for
 trunk's
  build. There are some disappeared classes and other changes, but the
 usage
  in cxf seem to be compatible with these versions. I tried both 2.6.6
 and
  2.7.2, and the build itself seems to run without problems.
 
  How do you think about upgrading ehcache to ehcache 2.7.2 for trunk
 so that
  we can test cxf not just against old ehcache 2.5.1?
 
  As comparison, camel trunk uses ehcache 2.7.0, while 2.11.x uses
 2.5.2.
 
  regards, aki

 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

ehcache version used in cxf build

[Aki Yoshida]

cxf's trunk and branches (2.7.x, 2.6.x, etc) all use ehcache 2.5.1 and
create the karaf feature with the corresponding smx's bundle version. But
the version range specified in the package imports is set as [2.5.0,3.0.0),
so we could use a newer version in runtime.

As ehcache 2.5.1 is rather old (from 2012-01) and there are newer versions
such as 2.6.6 (2013-05) and 2.7.2 (2013-07) which is already an
osgi-bundle,  I was wondering if we can use a newer version for trunk's
build. There are some disappeared classes and other changes, but the usage
in cxf seem to be compatible with these versions. I tried both 2.6.6 and
2.7.2, and the build itself seems to run without problems.

How do you think about upgrading ehcache to ehcache 2.7.2 for trunk so that
we can test cxf not just against old ehcache 2.5.1?

As comparison, camel trunk uses ehcache 2.7.0, while 2.11.x uses 2.5.2.

regards, aki

Re: svn commit: r1498991 - in /cxf/branches/2.7.x-fixes: ./ api/src/main/java/org/apache/cxf/internal/ rt/bindings/coloc/src/main/java/org/apache/cxf/binding/coloc/blueprint/ rt/bindings/object/src/ma

[Aki Yoshida]

it happened to me again. forgot to make sure my local 2.7.x svn is clean
before using domerge.
some other stuff went in with an unrelated merge.
i'll clean them up.


2013/7/2 a...@apache.org

 Author: ay
 Date: Tue Jul  2 15:52:45 2013
 New Revision: 1498991

 URL: http://svn.apache.org/r1498991
 Log:
 Merged revisions 1498988 via  svn merge from
 https://svn.apache.org/repos/asf/cxf/trunk

 
   r1498988 | ay | 2013-07-02 17:44:55 +0200 (Tue, 02 Jul 2013) | 1 line

   clean up and add another test for CXF-5095
 

 Added:

 cxf/branches/2.7.x-fixes/rt/frontend/jaxws/src/test/java/org/apache/cxf/jaxws/context/WrappedAttachmentsTest.java
   - copied unchanged from r1498988,
 cxf/trunk/rt/frontend/jaxws/src/test/java/org/apache/cxf/jaxws/context/WrappedAttachmentsTest.java
 Modified:
 cxf/branches/2.7.x-fixes/   (props changed)

 cxf/branches/2.7.x-fixes/api/src/main/java/org/apache/cxf/internal/CXFAPINamespaceHandler.java

 cxf/branches/2.7.x-fixes/rt/bindings/coloc/src/main/java/org/apache/cxf/binding/coloc/blueprint/ColocBPNamespaceHandler.java

 cxf/branches/2.7.x-fixes/rt/bindings/object/src/main/java/org/apache/cxf/binding/object/blueprint/

 cxf/branches/2.7.x-fixes/rt/ws/rm/src/main/java/org/apache/cxf/ws/rm/blueprint/RMBPHandler.java
 ...

Re: CXF-2.6.x - Build # 4147 - Still Failing

[Aki Yoshida]

I seem to have broken the build by integrating a jdk16 stuff into 2.6.x.
will fix it shortly.
aki


2013/7/1 Apache Jenkins Server jenk...@builds.apache.org

 The Apache Jenkins build system has built CXF-2.6.x (build #4147)

 Status: Still Failing

 Check console output at https://builds.apache.org/job/CXF-2.6.x/4147/ to
 view the results.

Re: OData support

[Aki Yoshida]

Hi Sergey, Andrei,
here is the info from Stephan on the new odata project which has recently
been submitted to the apache incubator program.
https://wiki.apache.org/incubator/ODataProposal

regards, aki



2013/6/17 Sergey Beryozkin sberyoz...@gmail.com

 Hi Andrei

 On 17/06/13 16:33, Andrei Shakirin wrote:

 Hi,

 The guys on the conference some weeks ago asked about Open Data (OData)
 support in CXF.

 The reason of question was better compatibility with .Net stack.

 Do we have already kind of OData support and are there any plans to do it?

  have a look at OData4J project - they provide Jersey and CXF
 integrations. I can see a configuration example here:

 http://code.google.com/p/**odata4j/wiki/Tomcathttp://code.google.com/p/odata4j/wiki/Tomcat

 The other thing I've been thinking about, perhaps it would make sense to
 have a light-weight OData support done in the CXF search module, in terms
 of FIQL, ie, take an OData query, convert it to FIQL internally, and use
 SearchContext and SearchCondition API, etc...
 Stephan, if you read it, do you reckon it may work ? I'm not sure FIQL is
 rich enough to cover all of OData but I think it may cover some of it, so
 there could be a subset of OData supported this way. I'm only interested in
 this to get CXF Search extensions utilized with OData queries. I've opened
 an OData4J JIRA to get OData with CXF Search extensions integrated but
 having an OData query converted to FIQL query first and then use the
 existing FIQL parser might be a cheaper option...

 Thanks, Sergey



  Regards,

 Andrei.

Re: CXF-2.6.x - Build # 4099 - Still Failing

[Aki Yoshida]

hi sergey,

another jdk16/15 compliance issue in cxf 2.6.x build


bad class file:
/home/jenkins/jenkins-slave/workspace/CXF-2.6.x/.repository/com/fasterxml/jackson/jaxrs/jackson-jaxrs-json-provider/2.2.1/jackson-jaxrs-json-provider-2.2.1.jar(com/fasterxml/jackson/jaxrs/json/JacksonJsonProvider.class)

class file has wrong version 50.0, should be 49.0


jackson-jaxrs-json-provider-2.1.5 seems to be still jdk15 compliant
but 2.2.0 is for jdk16.


don't know if you want to go to 2.1.5 or go back to codehaus for cxf-2.6.x?


aki



2013/5/28 Aki Yoshida elak...@gmail.com

 hi sergey,
 it seems like a jdk16 method got into 2.6.x.
 I just replaced it with one of the old variants.
 regards, aki



 2013/5/28 Apache Jenkins Server jenk...@builds.apache.org

 The Apache Jenkins build system has built CXF-2.6.x (build #4099)

 Status: Still Failing

 Check console output at https://builds.apache.org/job/CXF-2.6.x/4099/ to
 view the results.

Re: Question about WS-RM and redelivery queue with custom Conduit

[Aki Yoshida]

Hi Juan,

not sure from the one log line.

Could you describe your configuration in more details and repost your query
to the users@cxf list?

thanks.

regards, aki


2013/5/28 Juan Alberto Lopez Cavallotti juan.cavallo...@mulesoft.com

 Hello,


 I have a custom conduit implementation which takes care of the integration
 of CXF and MuleESB. I am able to use the WS-RM functionality on the happy
 path over this conduit but when something goes wrong on the backchannel I
 get the message stuck on the redelivery queue and constantly printing the
 following log statement:

 WARN 2013-05-27 16:57:33,917 [RMManager-Timer-2051976295]
 org.apache.cxf.endpoint.DeferredConduitSelector:
 MessageObserver not found

 I would like to diagnose the cause of this situation.

 Thanks for your help in advance.

 Regards,
 Juan Alberto López Cavallotti

Re: CXF-2.6.x - Build # 4099 - Still Failing

[Aki Yoshida]

hi sergey,
it seems like a jdk16 method got into 2.6.x.
I just replaced it with one of the old variants.
regards, aki


2013/5/28 Apache Jenkins Server jenk...@builds.apache.org

 The Apache Jenkins build system has built CXF-2.6.x (build #4099)

 Status: Still Failing

 Check console output at https://builds.apache.org/job/CXF-2.6.x/4099/ to
 view the results.

Re: [VOTE] CXF 2.7.5/2.6.8 - take 3

[Aki Yoshida]

+1

aki



2013/5/11 Daniel Kulp dk...@apache.org


 We've resolved over 40 issues since 2.7.4.   Not a lot, but it includes an
 OSGi fix that is blocking a Camel issues which may also be causing issues
 with the ServiceMix release.  This also affects CXF 2.6.x which affects
 Camel 2.10.x/ServiceMix 4.5.1 so I decided to do a 2.6.x release as well.

 This third build fixes the security login issues Colm discovered along
 with a potential class loader deadlock.


 List of issues:
 2.6.8

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12324276
 2.7.5

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12324277

 The Maven staging areas are at:
 2.6.8
 https://repository.apache.org/content/repositories/orgapachecxf-172/
 2.7.5
 https://repository.apache.org/content/repositories/orgapachecxf-001/

 The distributions are in the org/apache/cxf/apache-cxf/ directory of the
 Maven staging areas.

 This releases are tagged at:
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.8
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.5

 This vote will be open for at least 72 hours.


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: [VOTE] CXF 2.7.5/2.6.8 - take 2

[Aki Yoshida]

+1

aki


2013/5/8 Daniel Kulp dk...@apache.org


 We've resolved over 40 issues since 2.7.4.   Not a lot, but it includes an
 OSGi fix that is blocking a Camel issues which may also be causing issues
 with the ServiceMix release.  This also affects CXF 2.6.x which affects
 Camel 2.10.x/ServiceMix 4.5.1 so I decided to do a 2.6.x release as well.

 This second build fixes the 3 issues in JAX-RS that were identified as
 well as an issue in StaxUtils when using the in-jdk parser and an issue in
 the WS-Discovery service.



 List of issues:
 2.6.8

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12324276
 2.7.5

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12324277

 The Maven staging areas are at:
 2.6.8
 https://repository.apache.org/content/repositories/orgapachecxf-172/
 2.7.5
 https://repository.apache.org/content/repositories/orgapachecxf-018/

 The distributions are in the org/apache/cxf/apache-cxf/ directory of the
 Maven staging areas.

 This releases are tagged at:
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.8
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.5

 This vote will be open for at least 72 hours.


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: [VOTE] CXF 2.7.5/2.6.8

[Aki Yoshida]

+1

thanks
aki



2013/5/4 Daniel Kulp dk...@apache.org



 We've resolved over 40 issues since 2.7.4.   Not a lot, but it includes an
 OSGi fix that is blocking a Camel issues which may also be causing issues
 with the ServiceMix release.  This also affects CXF 2.6.x which affects
 Camel 2.10.x/ServiceMix 4.5.1 so I decided to do a 2.6.x release as well.


 List of issues:
 2.6.8

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12324276
 2.7.5

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12324277

 The Maven staging areas are at:
 2.6.8
 https://repository.apache.org/content/repositories/orgapachecxf-172/
 2.7.5
 https://repository.apache.org/content/repositories/orgapachecxf-174/

 The distributions are in the org/apache/cxf/apache-cxf/ directory of the
 Maven staging areas.

 This releases are tagged at:
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.8
 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.5

 This vote will be open for at least 72 hours.


 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: Build 2.7.5 tomorrow...

[Aki Yoshida]

+1 for 2.7.5 release

thanks.
aki



2013/5/2 Daniel Kulp dk...@apache.org


 It looks like we have the WS-Discovery stuff nailed down (and I'd like to
 blog about it a bit but would like a release first) and we've also fixed a
 few bugs related to OSGi/Camel that I'd like to get out to resolve some
 Camel issues.We also properly fixed the Woodstox dependency problem
 introduced in 2.7.4.   Thus, I'm thinking about doing a 2.7.5 build
 tomorrow.   I'm kind of undecided about 2.5.11/2.6.8 as the above issues
 (other than the woodstox one) are 2.7.x specific.  Thus, I'll likely just
 do 2.7.5 this time.   That might help drive users to 2.7.x as well.   :-)

 Thoughts?   Issues?

 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

Re: woodstox mandatory?

[Aki Yoshida]

that generated a required woodstox import in cxf-api's manifest. That
needs to be changed to optional as well.

2013/4/2 Sergey Beryozkin sberyoz...@gmail.com:
 On 02/04/13 11:01, Romain Manni-Bucau wrote:

 Hi Sergey,

 tomee doesn't bring it by default because it is too fatty and not always
 mandatory (same reason we don't bring jackson by default).

 i think the issue is not with close() but with the loadclass of staxutils
 which imports woodstox (i run with java 7)

 Yep, see it now... I guess we'll need to externalize a bit the explicit
 loading of the Woodstox factory or load it reflectively.
 Dan, what would be your preference ?

 Sergey



 *Romain Manni-Bucau*
 *Twitter: @rmannibucauhttps://twitter.com/rmannibucau*
 *Blog:
 **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
 *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
 *Github: https://github.com/rmannibucau*



 2013/4/2 Sergey Beryozkinsberyoz...@gmail.com

 Hi Romain

 The latest Woodstox has the superior security characteristics with regard
 to managing large payloads, and this is why it is preferred now,
 perhaps even TomEE might 'consider' swithcing to it in the future,
 however, StaxUtils checks a system
 org.apache.cxf.stax.**allowInsecureParser
 property, in fact at the moment it is set to 'true' by default to let
 containers like TomEE continue using their parsers of choice.

 So it appears it is a problem with StaxUtils.close...Or may be you can
 simply exclude Woodstox from the maven dependencies when upgrading ?

 Thanks, Sergey



 On 02/04/13 10:42, Romain Manni-Bucau wrote:

 when unmarshalling
 (org.apache.cxf.jaxrs.**provider.JAXBElementProvider.**readFrom) the
 reader is
 closed thanks to StaxUtils.close(reader); call

 and it triggers:

 org.apache.cxf.jaxrs.client.**ClientWebApplicationException:
 java.lang.**NoClassDefFoundError: com/ctc/wstx/stax/**WstxInputFactory
at org.apache.cxf.jaxrs.client.**WebClient.handleResponse(**
 WebClient.java:871)
 at
 org.apache.cxf.jaxrs.client.**WebClient.doChainedInvocation(**
 WebClient.java:841)
at org.apache.cxf.jaxrs.client.**WebClient.doInvoke(WebClient.**
 java:768)
 at
 org.apache.cxf.jaxrs.client.**WebClient.doInvoke(WebClient.**java:729)
at
 org.apache.cxf.jaxrs.client.**WebClient.invoke(WebClient.**java:345)
 at org.apache.cxf.jaxrs.client.**WebClient.get(WebClient.java:**481)
at
 org.superbiz.rest.**UserServiceTest.show(**UserServiceTest.java:95)
 at sun.reflect.**NativeMethodAccessorImpl.**invoke0(Native Method)
at
 sun.reflect.**NativeMethodAccessorImpl.**invoke(**
 NativeMethodAccessorImpl.java:**57)
 at
 sun.reflect.**DelegatingMethodAccessorImpl.**invoke(**
 DelegatingMethodAccessorImpl.**java:43)
at
 org.junit.runners.model.**FrameworkMethod$1.**runReflectiveCall(**
 FrameworkMethod.java:45)
 at
 org.junit.internal.runners.**model.ReflectiveCallable.run(**
 ReflectiveCallable.java:15)
at
 org.junit.runners.model.**FrameworkMethod.**invokeExplosively(**
 FrameworkMethod.java:42)
 at
 org.junit.internal.runners.**statements.InvokeMethod.**
 evaluate(InvokeMethod.java:20)
at org.junit.runners.**ParentRunner.runLeaf(**ParentRunner.java:263)
 at
 org.junit.runners.**BlockJUnit4ClassRunner.**runChild(**
 BlockJUnit4ClassRunner.java:**68)
at
 org.junit.runners.**BlockJUnit4ClassRunner.**runChild(**
 BlockJUnit4ClassRunner.java:**47)
 at org.junit.runners.**ParentRunner$3.run(**ParentRunner.java:231)
at
 org.junit.runners.**ParentRunner$1.schedule(**ParentRunner.java:60)
 at org.junit.runners.**ParentRunner.runChildren(**ParentRunner.java:229)
at
 org.junit.runners.**ParentRunner.access$000(**ParentRunner.java:50)
 at org.junit.runners.**ParentRunner$2.evaluate(**ParentRunner.java:222)
at
 org.junit.internal.runners.**statements.RunBefores.**
 evaluate(RunBefores.java:28)
 at
 org.junit.internal.runners.**statements.RunAfters.evaluate(**
 RunAfters.java:30)
at org.junit.runners.**ParentRunner.run(ParentRunner.**java:300)
 at org.junit.runner.JUnitCore.**run(JUnitCore.java:157)
at
 com.intellij.junit4.**JUnit4IdeaTestRunner.**startRunnerWithArgs(**
 JUnit4IdeaTestRunner.java:77)
 at

 com.intellij.rt.execution.**junit.JUnitStarter.**prepareStreamsAndStart(*
 *JUnitStarter.java:195)
at com.intellij.rt.execution.**junit.JUnitStarter.main(**
 JUnitStarter.java:63)
 at sun.reflect.**NativeMethodAccessorImpl.**invoke0(Native Method)
at
 sun.reflect.**NativeMethodAccessorImpl.**invoke(**
 NativeMethodAccessorImpl.java:**57)
 at com.intellij.rt.execution.**application.AppMain.main(**
 AppMain.java:120)
 Caused by: java.lang.**NoClassDefFoundError:
 com/ctc/wstx/stax/**WstxInputFactory
 at
 org.apache.cxf.jaxrs.provider.**JAXBElementProvider.readFrom(**
 JAXBElementProvider.java:196)
at
 org.apache.cxf.jaxrs.client.**AbstractClient.readBody(**
 AbstractClient.java:446)
 at org.apache.cxf.jaxrs.client.**WebClient.handleResponse(**
 WebClient.java:857)
... 34 more
 Caused by: