Re: [VOTE] Apache CXF 3.2.6

[Willem Jiang]

+1


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Thu, Aug 9, 2018 at 7:14 AM, Daniel Kulp  wrote:

> This is a vote to release CXF 3.2.6.
>
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachecxf-1120/ <
> https://repository.apache.org/content/repositories/orgapachecxf-1120/>
>
>
> Tag:
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=
> f0b4f939f81894c9943c24ea6891c7fa08df00a6 <https://gitbox.apache.org/
> repos/asf?p=cxf.git;a=tag;h=f0b4f939f81894c9943c24ea6891c7fa08df00a6>
>
>
> Here is my +1
>
>
> --
> Daniel Kulp
> dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <
> http://dankulp.com/blog>
> Talend Community Coder - http://talend.com <http://coders.talend.com/>
>

Re: 10 years of CXF - Happy Birthday!

[Willem Jiang]

Yeah,  It's ten years.  Happy birthday CXF.
It's my pleasure to be part of this project.



Willem Jiang


On Tue, Apr 17, 2018 at 7:06 AM, Freeman Fang 
wrote:

> Wow, ten years, time flies! We should have a beer together, remotely, ;)
>
> I am so grateful and proud that I am part of this great project and
> looking forward another 10 years’ success of Apache CXF!
>
> Thanks to very one in this community, a lot of memorable experience.
> －
> Freeman(Yue) Fang
>
> Red Hat, Inc.
> FuseSource is now part of Red Hat
>
>
>
> > On Apr 17, 2018, at 2:15 AM, Dennis Kieselhorst  wrote:
> >
> > Hi,
> >
> > it's time to celebrate: 10 years ago, on April 16th in the year 2008,
> > CXF graduated from the Apache incubator as a merge of the Objectweb
> > Celtix project and the Codehaus XFire project (see
> > http://incubator.apache.org/projects/cxf.html for more details).
> >
> > Today we have lots of more features, support for additional
> > specifications and a large user base.
> >
> > Thanks to anyone who made this possible and looking forward to another
> > 10 years :-)
> >
> > Cheers
> > Dennis
>
>

Re: [PROPOSAL] Move IRC channel to freenode ?

[Willem Jiang]

+1, it sounds good for me.

--  
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 7, 2015 at 12:43:40 AM, Jean-Baptiste Onofré (j...@nanthrax.net) wrote:
> Hi all,
>  
> as you may know, codehaus will be down soon:
>  
> http://www.codehaus.org/
>  
> Even if it's not clear about the future of the IRC server, I think it
> makes sense to try to anticipate.
> I propose to "move" our IRC channels to freenode (irc.freenode.net) with
> the following name:
>  
> #apache-activemq
> #apache-archiva
> #apache-camel
> #apache-cxf
> #apache-kalumet
> #apache-karaf
> #apache-servicemix
>  
> WDYT ?
>  
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>  

Re: [VOTE] CXF 3.0.4/2.7.15

[Willem Jiang]

My +1.

--  
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 February 12, 2015 at 9:53:41 AM, Daniel Kulp (dk...@apache.org) wrote:
> 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: git commit: Disallow SSLv3 by default in Jetty

[Willem Jiang]

Hi Colm,

If I ran below code with Oracle JDK, I can see SSLv2Hello, SSLv3 there.

SSLContext context = SSLContext.getInstance(“TSL”);
SSLEngine engine = context.createSSLEngine();
print engine.getEnabledProtocols() 

I guess we need to exclude the SSLv2Hello at the same time.

Regards,

--  
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 October 20, 2014 at 11:45:39 PM, cohei...@apache.org (cohei...@apache.org) 
wrote:

> > + if (!"SSLv3".equals(proto)) {
> + scf.addExcludeProtocols("SSLv3");
> + }

Re: [VOTE] CXF 2.6.16

[Willem Jiang]

+1.

--  
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 October 8, 2014 at 3:59:42 AM, Daniel Kulp (dk...@apache.org) wrote:
> This is a vote to release CXF 2.6.16. This release is JUST to fix the 
> problems running 2.6.15  
> with Java5. All the changes between 2.6.15 and 2.6.16 are directly related to 
> getting  
> it to build, run, and test with Java5. This does include downgrading a couple 
> of dependencies  
> back to the 2.6.14 level.
>  
> Tag:
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=03ee4401807edee68cfa590a400e8b35a0caac6b
>   
>  
> Staging area:
> https://repository.apache.org/content/repositories/orgapachecxf-1028/
>  
> Here is my +1.
>  
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>  
>  

Re: [VOTE] CXF XJC Utils 3.0.2

[Willem Jiang]

+1.

--  
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 September 19, 2014 at 9:43:05 PM, Daniel Kulp (dk...@apache.org) wrote:
>  
> 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: Moving JiBX related system tests into a module

[Willem Jiang]

FYI, I just created a JIRA[1], and committed the patch into master and 
3.0.x-fixes branches.

[1]https://issues.apache.org/jira/browse/CXF-5999

Regards,

--  
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 September 11, 2014 at 8:48:08 PM, Dennis Sosnoski (d...@sosnoski.com) wrote:
> +1
>  
> - Dennis
>  
> On 09/11/2014 08:53 PM, Willem Jiang wrote:
> > Hi,
> >
> > As there is no plan for support jibx with JDK8[1], and some system tests 
> > failed with JDK8.  
> > I’m planing to move these JiBX related system tests into the other module 
> > called JiBX,  
> so we can skip the module when using JDK8.
> >
> > Any thoughts?
> >
> > [1]http://cxf.547215.n5.nabble.com/DISCUSS-Short-term-plans-branching-td5744177.html
> >   
> >
> > --
> > 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
> >
> >
> >
> >
>  
>  

Moving JiBX related system tests into a module

[Willem Jiang]

Hi,

As there is no plan for support jibx with JDK8[1], and some system tests failed 
with JDK8.
I’m planing to move these JiBX related system tests into the other module 
called JiBX, so we can skip the module when using JDK8. 

Any thoughts?

[1]http://cxf.547215.n5.nabble.com/DISCUSS-Short-term-plans-branching-td5744177.html

--  
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

Re: CXF tools jars aren't OSGi bundles anymore in 3.x

[Willem Jiang]

+1 to change the tools maven packaging to bundle first.

--  
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 August 28, 2014 at 2:41:45 AM, Daniel Kulp (dk...@apache.org) wrote:
>  
> On Aug 26, 2014, at 10:32 AM, Guillaume Nodet wrote:
>  
> > In 2.x, cxf tooling jars were packaged as valid OSGi bundles.
> > In 3.x, the maven packaging has been changed from jar to bundle for most of
> > the bundles, but the tool ones remained jars. Unfortunately, the OSGi
> > manifest is not generated anymore.
>  
> When I did the conversion from packaging:jar to bundle, I kind of skipped the 
> tooling  
> jars. The main reasons were:
>  
> 1) I couldn’t find a real use case where the tooling needed to work in OSGi 
> so it wasn’t a  
> high priority.
>  
> 2) I’m 90% certain that some of the tooling won’t work in OSGi anyway. Much 
> of the tooling  
> would need to be able to load the various META-INF/tools-plugins.xml files 
> from the  
> various bundles. That would require a new Bundle Activator or something like 
> we do for  
> the bus-extensions.txt to be able to read them from the various bundles. 
> Since that would,  
> at the very least, prevent then entire wsdl2* set of tools from running and 
> likely others,  
> I didn’t pursue it much further. If I WAS to pursue this further, I’d likely 
> ditch the tools-plugins.xml  
> files entirely and go with the bus-extensions.txt and load them all via a 
> Bus. Not a high  
> priority though.
>  
>  
> > I'm raising this issue because the feature definitions comes with a
> > cxf-tools feature which can't be used anymore in 3.x.
> > Given I'm verifying those features, which way should I go ? Remove this
> > feature or change the maven packaging to bundle ?
>  
> I’m OK with changing them to bundle. There are definite use cases where 
> someone COULD  
> use some of the functionality out of the jars without actually invoking the 
> tools themselves.  
> I think the WSDL validator might be usable that way.
>  
>  
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>  
>  

Re: Ready to create 3.0.x branch, start 3.1?

[Willem Jiang]

It sounds good :)

--  
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 July 23, 2014 at 2:37:55 AM, Daniel Kulp (dk...@apache.org) wrote:
>  
> Just a quick query to everyone:
>  
> With 2.6.15 out, we planned to drop support for 2.6.x and start working 
> toward 3.1 on master.  
> Is everyone ready for that? If there are no objections, tomorrow I’ll create 
> the 3.0.x-fixes  
> branch and then move all the poms to 3.1.0-SNAPSHOT.
>  
>  
> --
> 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

[Willem Jiang]

I ran some tests with apache camel, everything looks good.
Here is my +1.

--  
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 July 16, 2014 at 3:59:21 AM, Daniel Kulp (dk...@apache.org) wrote:
>  
> 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: [VOTE] CXF XJC Utils 3.0.0

[Willem Jiang]

+1.

--  
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 May 31, 2014 at 3:10:51 AM, Daniel Kulp (dk...@apache.org) wrote:
>  
> 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=12315520&version=12327041
>   
>  
>  
> Here is my +1.
>  
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>  
>  

Re: [DISCUSS] Java 8 and JAXB and 3.0.1

[Willem Jiang]

+1 to use JAXB 2.2.10 in CXF 3.0.1.
We can leave the “org.glassfish.jaxb” part change to CXF 3.1.x.


--  
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 May 28, 2014 at 10:41:42 PM, Daniel Kulp (dk...@apache.org) wrote:
>  
> There is a new version of JAXB available in central (2.2.10-b140310.1920) 
> that allows  
> it to work better with Java 8. All the CXF tooling tests now pass. There is a 
> new single failure  
> in the jaxws systests and of course all the OSGi and JIBX related things 
> still fail. Thus,  
> it’s a step in the right direction.
>  
> HOWEVER, there is a minor incompatibility with it and JAXB 2.2.7 that we’ve 
> been using  
> so I want to bring this up for discussion before updating master to use this 
> for 3.0.1.  
> With 2.2.7, we had just two jaxb related jars: jaxb-impl and jaxb-xjc. With 
> 2.2.10, it  
> adds a third: jaxb-core. For the most part, people that get JAXB transitively 
> from CXF  
> won’t have any issue as I can update our poms to bring that in as well. 
> However, anyone that  
> excludes JAXB when grabbing CXF would have to update their poms to also 
> exclude that jar.  
>  
> So, the question is: is that kind of thing OK for 3.0.1 or would it need to 
> wait for 3.1? Personally,  
> I’d like to get it in for 3.0.1 as it brings us closer to having support for 
> Java8. In particular,  
> the command line tools in bin (wsdl2java, etc….) would work.
>  
> Another note: the jaxb stuff in “com.sun.xml.bind” in maven central are now 
> shaded versions  
> of stuff in org.glassfish.jaxb. Thus, longer term, we likely should flip to 
> the org.glassfish  
> versions. That’s an even bigger change and not something I’d like to do for 
> 3.0.1 though.  
>  
> Thoughts?
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>  
>  

Re: CXF compile with JDK 8

[Willem Jiang]

I managed to work around the new JAXP security setting issue by applying 
-Djavax.xml.accessExternalSchema=file,http  and forcing jaxb maven plugin not 
to fork when running the mvn clean install.

But I hit the issue of jibx plugin[1], it looks like Dennis need a fund to 
resolve this issue.

[1]http://www.mail-archive.com/jibx-users@lists.sourceforge.net/msg05000.html

--  
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 May 1, 2014 at 1:34:35 AM, Daniel Kulp (dk...@apache.org) wrote:
>  
> At this point, there isn’t a way to build CXF with Java 8. The versions of 
> JAXB available  
> in maven central cannot handle having the XML secure processing flag turned 
> on by default.  
> Until Oracle releases a new version of JAXB, I’m not sure what we can do. The 
> only option  
> available would be to start depending directly on the “internal” versions of 
> JAXB found  
> in the JDK, but that has other issues, particularly with IDE’s like Eclipse 
> that restrict  
> that as well as on Java6 where the internal version is based on 2.1 instead 
> of 2.2.
>  
> Also, a couple other plugins still have issues. For example, the jibx plugin 
> fails on  
> java8 as well.
>  
> Dan
>  
>  
>  
> On Apr 28, 2014, at 11:35 AM, Raja Nagendra Kumar wrote:  
>  
> > Hi,
> >
> >
> > I am using mvn package for compiling source code cxf 
> > (https://git-wip-us.apache.org/repos/asf/cxf.git)  
> >
> > I am using JDK 8 to compile.
> >
> >
> > Source Code compile fails with error
> >
> >
> > [ERROR] Failed to execute goal 
> > org.apache.cxf:cxf-codegen-plugin:3.0.0-SNAPSHOT:  
> > wsdl2java (generate-sources) on project cxf-testutils:
> > [ERROR] Exit code: 1
> > [ERROR] Command line was: d:\Apps\java\jdk\jre\bin\java.exe -jar 
> > C:\Users\nagkum  
> > ar\AppData\Local\Temp\cxf-tmp-36108\cxf-codegen6570965978496805609.jar  
> C:\Users\
> > nagkumar\AppData\Local\Temp\cxf-tmp-36108\cxf-w2j6619711455234741106args  
> > [ERROR] -> [Help 1]
> > [ERROR]
> > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> > swit
> > ch.
> > [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> > [ERROR]
> > [ERROR] For more information about the errors and possible solutions, 
> > please rea
> > d the following articles:
> > [ERROR] [Help 1] 
> > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionE  
> > xception
> > [ERROR]
> > [ERROR] After correcting the problems, you can resume the build with the 
> > command
> >
> > [ERROR] mvn -rf :cxf-testutils
> >
> > Does this not work with JDK 8, compile works fine with JDK 6 & 7.
> > Is there any work around.
> >
> >
> > Raja Nagendra Kumar,
> > C.T.O
> > www.tejasoft.com
> >
>  
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>  
>  

Re: [VOTE] CXF 3.0.0

[Willem Jiang]

I just ran a quick test in camel-cxf with CXF 3.0 staging kit.
Everything looks fine, here is my +1. 

--  
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 May 15, 2014 at 8:45:37 AM, Daniel Kulp (dk...@apache.org) wrote:
>  
> 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: [VOTE] CXF 2.6.14/2.7.11 - take 2

[Willem Jiang]

Ran some tests with camel-cxf, every thing looks good.
Here is my +1.

--  
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 11:45:09 AM, Daniel Kulp (dk...@apache.org) wrote:
>  
>  
> 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

[Willem Jiang]

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: CXF 2.6.x-fixes uncategorized systest failures

[Willem Jiang]

After digging the code I found the tests failures was fixed in master and 
2.7.x-fixes branches.
The tests can fixed by merge the patch[1] into 2.6.x-fixes branch.

1]https://fisheye6.atlassian.com/changelog/cxf?cs=dd1dc8ae2b163e9a000e51dabbec41024a866069

--  
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 March 14, 2014 at 11:03:43 AM, Willem Jiang (willem.ji...@gmail.com) wrote:
> Hi,
>  
> I just found the system tests of uncategorised[1] in CXF 2.6.x-fixes branch 
> were failed  
> for a while.
> It looks there are some patch in the CXF 2.7.x-fixes branch are not merged 
> into CXF 2.6.x-fixes.  
>  
> [1]https://builds.apache.org/job/CXF-2.6.x/4408/#showFailuresLink
>  
>  
> --
> 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
>  
>  
>  
>  

CXF 2.6.x-fixes uncategorized systest failures

[Willem Jiang]

Hi,

I just found the system tests of uncategorised[1] in CXF 2.6.x-fixes branch 
were failed for a while. 
It looks there are some patch in the CXF 2.7.x-fixes branch are not merged into 
CXF 2.6.x-fixes.

[1]https://builds.apache.org/job/CXF-2.6.x/4408/#showFailuresLink


--  
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

Re: [VOTE] Apache CXF 3.0.0-milestone2

[Willem Jiang]

my +1.

--  
Willem Jiang

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



On February 15, 2014 at 10:02:19 AM, Daniel Kulp (dk...@apache.org) wrote:
>  
>  
> This is a vote to release 3.0.0-milestone2
>  
> This has a bunch of more updates targeting 3.0 including a fully  
> revamped JMS transport, fully revamped WS-RM system, updates  
> to WS-Security, JAX-RS updates, some more deprecated API’s  
> removed, blueprint requirement removed, etc….
>  
>  
> Staging area:
> https://repository.apache.org/content/repositories/orgapachecxf-1012/  
>  
> Tag:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-3.0.0-milestone2  
>  
>  
> The vote will be open for 24 hours.
>  
>  
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>  
>  

Re: Discuss: Switching cxf to git

[Willem Jiang]

It’s not pleasure work to merge the patches between the branches in SVN behind 
the GFW.
I’m +1 for swathing cxf to git.

--  
Willem Jiang

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



On January 22, 2014 at 6:02:21 PM, Sergey Beryozkin (sberyoz...@gmail.com) 
wrote:
>  
> On 22/01/14 09:20, Christian Schneider wrote:
> > Recently many apache projects switched from svn to git (like  
> Camel and
> > Karaf).
> > As git has many advantages compared to svn (especially for back  
> ports) I
> > think it makes sense to also do this switch for cxf.
> >
> > Any opinions?
> Comment from someone who has been lazy enough (scared ?) to switch  
> to
> git completely: SVN has never caused me any issues, I mean, git  
> is
> obviously great and much more advanced than SVN, but I haven't  
> found SVN
> slowing down my CXF development process which is straight-forward.  
>  
> I will switch to git if that what I will need to do to work with CXF  
> :-), but I'm happy where I am with SVN. If that is expensive/real  
> hassle
> to maintain, bith SVN & git repos, then sure, lets go for it
>  
> My 2c
> Sergey
>  
>  
> >
> > Christian
> >
>  
>  
>  

Re: Question about SpringBus lifecycle

[Willem Jiang]

Hi Dan,

Thanks for the review. I polished the code to avoid recalling the shutdown 
method for the same bus and ran the whole unit tests, every thing looks good. I 
will commit the code shortly.

Regards,

--  
Willem Jiang

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



On January 20, 2014 at 9:18:42 PM, Daniel Kulp (dk...@apache.org) wrote:
>  
>  
> If a user creates a basic application outside of spring but using  
> Spring config and THEY manage the bus via a BusFactory, this MAY  
> result in a loop at shutdown.
>  
> Bus bus = new SpringBusFactory.createBus(“/cxf.xml”);
>  
> .. do stuff with bus …
>  
> bus.shutdown();
>  
> Looking at the code for this, shutdown() would call destroyBeans()  
> which would call ctx.close() which would trigger your ContextClosedEvent  
> which would re-call shutdown….
>  
> The check:
> if (state == BusState.SHUTTING_DOWN)…
>  
> SHOULD prevent any problems with that, but you’d definitely  
> need to check to make sure. That said, it shouldn’t be hard check,  
> we do this type of thing in our system tests all over the place.  
>  
>  
> Dan
>  
>  
>  
>  
>  
> On Jan 20, 2014, at 7:43 AM, Willem Jiang  
> wrote:
>  
> > Hi,
> >
> > I was tracing a CXFBus leak issue recently.
> >
> > Here are the some details about the application bundle:
> >
> > It's Spring application context holds a camel context which  
> has a camel-cxf endpoint to receive the invocation from outside.  
> When the application bundle is uninstalled from Karaf, the SpringBus  
> doesn’t shutdown itself and CXFBusFactory doesn’t clean itself  
> up.
> >
> > If the application bundle is changed to use Blueprint to load  
> the same Camel context, we don’t find any Bus leak by dump the memory  
> of the JVM.
> >
> > I dig the SpringBus code and found it registers an ApplicationListener  
> which handles application context refresh and close event.  
> >
> > My patch is just replacing the 
> > getExtension(BusLifeCycleManager.class).postShutdown();  
> with bus shutdown().
> >
> > --- a/rt/core/src/main/java/org/apache/cxf/bus/spring/SpringBus.java  
> > +++ b/rt/core/src/main/java/org/apache/cxf/bus/spring/SpringBus.java  
> > @@ -21,7 +21,7 @@ package org.apache.cxf.bus.spring;
> >
> > import org.apache.cxf.bus.BusState;
> > import org.apache.cxf.bus.extension.ExtensionManagerBus;  
> > -import org.apache.cxf.buslifecycle.BusLifeCycleManager;  
> > import org.apache.cxf.configuration.ConfiguredBeanLocator;  
> > import org.apache.cxf.configuration.Configurer;
> > import org.apache.cxf.configuration.spring.ConfigurerImpl;  
> > @@ -110,7 +110,8 @@ public class SpringBus extends ExtensionManagerBus  
> > initialize();
> > }
> > } else if (event instanceof ContextClosedEvent) {
> > - getExtension(BusLifeCycleManager.class).postShutdown();  
> > + shutdown();
> > }
> > }
> > }
> >
> > Is there any thing that I'm missing?
> >
> > --
> > Willem Jiang
> >
> > Red Hat, Inc.
> > Web: http://www.redhat.com
> > Blog: http://willemjiang.blogspot.com(http://willemjiang.blogspot.com/)  
> (English)
> > http://jnn.iteye.com(http://jnn.javaeye.com/) (Chinese)  
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> >
> >
>  
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>  
>  

Question about SpringBus lifecycle

[Willem Jiang]

Hi,

I was tracing a CXFBus leak issue recently.

Here are the some details about the application bundle: 

It's Spring application context holds a camel context which has a camel-cxf 
endpoint to receive the invocation from outside. When the application bundle is 
uninstalled from Karaf, the SpringBus doesn’t shutdown itself and CXFBusFactory 
doesn’t clean itself up.

If the application bundle is changed to use Blueprint to load the same Camel 
context, we don’t find any Bus leak by dump the memory of the JVM.

I dig the SpringBus code and found it registers an ApplicationListener which 
handles application context refresh and close event.

My patch is just replacing the 
getExtension(BusLifeCycleManager.class).postShutdown(); with bus  shutdown(). 

--- a/rt/core/src/main/java/org/apache/cxf/bus/spring/SpringBus.java
+++ b/rt/core/src/main/java/org/apache/cxf/bus/spring/SpringBus.java
@@ -21,7 +21,7 @@ package org.apache.cxf.bus.spring;
 
 import org.apache.cxf.bus.BusState;
 import org.apache.cxf.bus.extension.ExtensionManagerBus;
-import org.apache.cxf.buslifecycle.BusLifeCycleManager;
 import org.apache.cxf.configuration.ConfiguredBeanLocator;
 import org.apache.cxf.configuration.Configurer;
 import org.apache.cxf.configuration.spring.ConfigurerImpl;
@@ -110,7 +110,8 @@ public class SpringBus extends ExtensionManagerBus
                     initialize();
                 }
             } else if (event instanceof ContextClosedEvent) {
-                getExtension(BusLifeCycleManager.class).postShutdown();
+                shutdown();
             }
         }
     }

Is there any thing that I'm missing?

--  
Willem Jiang

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

Re: Fail-over support for HTTP errors

[Willem jiang]

+1, it makes sense.


--  
Willem Jiang

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





On Wednesday, November 13, 2013 at 3:19 AM, Sergey Beryozkin wrote:

> Hi
>  
> While working on fixing [1] which is really about the JAX-RS client code  
> not working with the failover feature in case of exceptions caused by  
> statuses like 404 (Not Found), which works fine for JAX-WS, I spotted  
> that by default the fail-over will also be activated by statuses like  
> 401, 403 or 405-415, etc.
>  
> I think activating the feature in case of 404 or 503 is very reasonable,  
> but IMHO it can be wrong to do it when say the client has failed to  
> authorize with 403 or authenticate with the supplied credentials (401):  
> in this case the client should get an immediate exception.
>  
> So I added a flag to FailoverTargetSelector,  
> supportNotAvaialbleErrorsOnly, this can be enabled so that 401/403 and  
> other statuses except 404 or 503, do not activate the feature.
>  
> I reckon that this flag should be set to true by default on the trunk,  
> otherwise we can have a 'failover' concept 'overloaded' by using the  
> alternative addresses
>  
> Thanks, Sergey
>  
> [1] https://issues.apache.org/jira/browse/CXF-5378  

Re: [VOTE] Apache CXF 2.7.7/2.6.10

[Willem jiang]

+1

I just did a quick test  by running the Apache CXF 2.7.7 with Camel 
2.13-SNAPSHOT.  
All the test passed.

--  
Willem Jiang

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





On Monday, September 16, 2013 at 4:35 PM, Christian Schneider wrote:

> +1
>  
> I have some classloading issues on Eclipse RCP with CXF 2.7.7. The  
> exception says the BindingProvider interface is not visible when  
> creating a JAXWS client.
> Does anyone else here use CXF with Eclipse RCP and can give it a try?  
> The problem is not big enough in my opinion to stop the release though.
>  
> Christian
>  
>  
> On 14.09.2013 14:36, Daniel Kulp wrote:
> >  
> > 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=12310511&version=12324771
> > 2.7.7
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=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.
>  
>  
> --  
> Christian Schneider
> http://www.liquid-reality.de
>  
> Open Source Architect
> http://www.talend.com

Re: FailOver Feature doesn't support the async calling of client

[Willem jiang]

Hi Dan,  

It's really helpful.

Thanks,  

--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem





On Tuesday, August 6, 2013 at 11:12 AM, Daniel Kulp wrote:

>  
> On Aug 5, 2013, at 10:45 PM, Willem jiang  (mailto:willem.ji...@gmail.com)> wrote:
>  
> > Hi Team,
> >  
> > I just fixed CAMEL-6609[1] by calling the 
> > getConduitSelector().complete(cxfExchange) inside of my custom CallBack 
> > method. But I think I should fix it from CXF.
> >  
> > I tried to add this call into the 
> > org.apache.cxf.message.Message.ClientCallback class, but I found I have to 
> > get the reference of ClientImpl to do that call.
> > I also tried to add some code in the ClientImpl, but I found the 
> > ClientOutFaultObserver will call the ClientCallback handleException when 
> > exception is through, and I don't like the idea to let the 
> > ClientOutFaultObserver hold the reference of ClientImpl.  
> >  
> > Is there any good way to let the getConduitSelector().complete(cxfExchange) 
> > be called rightly, when the exception is thrown from the interceptor chain.
>  
> Shouldn't this just be adding a couple more calls to ….complete(exchange) in 
> the ClientImpl.processResult, particularly in the if (callback != null) paths?
>  
> For the outFault case… in ClientImpl where it adds it to the chain, do:
>  
> chain.setFaultObserver(new MessageObserver() {
> public void onMessage(Message message) {
> outFaultObserver.onMessage(message);
> getConduitSelector().complete(message.getExchange());
> }
> });
>  
> to wrapper it and handle the completions. That avoids adding the ClientImpl 
> directly to the ClientOutFaultObserver.
>  
> Actually, in ClientImpl.prepareConduitSelector(…), the conduit selector is 
> set into the exchange. Thus, at any point, you should be able to do 
> message.getExchange().get(ConduitSelector.class)…. and use it.
>  
> Dan
>  
>  
> >  
> > [1]https://issues.apache.org/jira/browse/CAMEL-6609
> >  
> > Regards,
> >  
> > Willem
>  
> --  
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com

FailOver Feature doesn't support the async calling of client

[Willem jiang]

Hi Team,

I just fixed CAMEL-6609[1] by calling the 
getConduitSelector().complete(cxfExchange) inside of my custom CallBack method. 
But I think I should fix it from CXF.

I tried to add this call into the org.apache.cxf.message.Message.ClientCallback 
class, but I found  I have to get the reference of ClientImpl to do that call.
I also tried to add some code in the ClientImpl, but I found the 
ClientOutFaultObserver will call the ClientCallback handleException when 
exception is through, and I don't like the idea to let the 
ClientOutFaultObserver hold the reference of ClientImpl. 

Is there any good way to let the getConduitSelector().complete(cxfExchange) be 
called rightly, when the exception is thrown from the interceptor chain.

[1]https://issues.apache.org/jira/browse/CAMEL-6609

Regards,

Willem
 

Re: Can LocalConduit use Direct Dispatch by default ?

[Willem jiang]

+1 for using Direct Dispatch by default.


--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem




On Wednesday, July 31, 2013 at 12:07 AM, Sergey Beryozkin wrote:

> Hi Dan, others
>  
> Do you remember why LocalConduit uses a piped-style communication by  
> default ? The problem with that it causes calls with empty payloads hang  
> (plenty of cases with RS but also possible with SOAP GET for ex), unless  
> users go and enable a direct dispatch style.
>  
> I'd rather go and enable the direct dispatch style by default, will make  
> things a bit simpler for users (no need to know about  
> LocalConduit.DIRECT_DISPATCH unless really needed, and if they will need  
> a piped style then they'd disable it by setting  
> LocalConduit.DIRECT_DISPATCH to false)
>  
> Sergey  

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

[Willem jiang]

+1


--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem





On Thursday, July 18, 2013 at 12:57 AM, Daniel Kulp wrote:

>  
>  
> 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=12310511&version=12324275
> 2.6.9
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12324384
> 2.7.6
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=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: CXF Client issue when try to handle session for One-Way Operation call

[Willem jiang]

Please fill a JIRA[1] and share the patch with us.
[1]https://issues.apache.org/jira/browse/CXF


--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem




On Tuesday, July 9, 2013 at 2:55 AM, Harsha Thirimanna wrote:

> Hi ,
>  
> I am working for a project that base on web service and client. My issue is
> in client side. I created the client using CXF. I wanted to call few
> operation in one service at once. In server side it handle the session so
> when do the first call it return session id and client should pass it to
> the next operation call in same service There may be sequence of operation
> calls in one service at once.
> I got this issue when first operation is one-way. Because after do the
> first call it returns session id, but second call goes to the server as a
> fresh request(no set session id to second request).
> I went through your code and got some fix , I'll attached that fix with
> this. But your the expertise of this. Please we want to clear this out.
> This was blocker issue for us really.
>  
> Note : I have handled the configuration in client side to do this as
> session enabled. I confirmed that, because If I do two way operation call ,
> then this session handle correctly.
>  
> thanks  

Re: svn commit: r1496976 - in /cxf/trunk: rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/policyhandlers/ systests/ws-security/src/test/java/org/apache/cxf/systest/ws/saml/ systests/ws-s

[Willem jiang]

Apache CI hit the same issue as I had.
https://builds.apache.org/job/CXF-Trunk-JDK16/1849/console


--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem





On Thursday, June 27, 2013 at 4:52 PM, Willem jiang wrote:

> I tried to build the latest version of wss4j with -U option, I still get the 
> errors.
>  
>  
> --  
> Willem Jiang
>  
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Web: http://www.fusesource.com | http://www.redhat.com
> Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
> (English)
> http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
> Twitter: willemjiang  
> Weibo: 姜宁willem
>  
>  
>  
>  
> On Thursday, June 27, 2013 at 4:48 PM, Colm O hEigeartaigh wrote:
>  
> > Could you try with "-U"? It's working fine for me, but you probably don't
> > have the most up to date Santuario/WSS4J SNAPSHOT jars in your maven repo.
> >  
> > Colm.
> >  
> >  
> > On Thu, Jun 27, 2013 at 5:41 AM, Willem jiang  > (mailto:willem.ji...@gmail.com)>wrote:
> >  
> > > Hi Colm,
> > >  
> > > I tried to build the CXF trunk and ran into this error.
> > >  
> > > [ERROR]
> > > /Users/jiangning/work/cxf/git/cxf/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/policyhandlers/StaxSymmetricBindingHandler.java:[454,42]
> > > cannot find symbol
> > > [ERROR] symbol : method getSha1Identifier()
> > > [ERROR] location: interface
> > > org.apache.xml.security.stax.securityToken.SecurityToken
> > > [ERROR]
> > > /Users/jiangning/work/cxf/git/cxf/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/policyhandlers/StaxSymmetricBindingHandler.java:[484,33]
> > > cannot find symbol
> > > [ERROR] symbol : method getSha1Identifier()
> > > [ERROR] location: interface
> > > org.apache.xml.security.stax.securityToken.SecurityToken
> > > [ERROR]
> > > /Users/jiangning/work/cxf/git/cxf/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/policyhandlers/StaxSymmetricBindingHandler.java:[549,34]
> > > cannot find symbol
> > > [ERROR] symbol : method setSha1Identifier(java.lang.String)
> > > [ERROR] location: class
> > > org.apache.xml.security.stax.impl.securityToken.GenericOutboundSecurityToken
> > > [ERROR] -> [Help 1]
> > >  
> > >  
> > >  
> > >  
> > > I even try to build the wss4j trunk, but I got more error in the
> > >  
> > > ERROR] Failed to execute goal
> > > org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
> > > (default-compile) on project wss4j-ws-security-stax: Compilation failure:
> > > Compilation failure:
> > > [ERROR]
> > > /Users/jiangning/work/wss4j/wss4j/ws-security-stax/src/main/java/org/apache/wss4j/stax/impl/processor/output/EncryptOutputProcessor.java:[98,50]
> > > cannot find symbol
> > > [ERROR] symbol : method getSha1Identifier()
> > > [ERROR] location: interface
> > > org.apache.xml.security.stax.securityToken.OutboundSecurityToken
> > > [ERROR]
> > > /Users/jiangning/work/wss4j/wss4j/ws-security-stax/src/main/java/org/apache/wss4j/stax/impl/securityToken/SecurityTokenFactoryImpl.java:[140,65]
> > > cannot find symbol
> > > [ERROR] symbol : variable KeyIdentifier_IssuerSerial
> > > [ERROR] location: class
> > > org.apache.wss4j.stax.securityToken.WSSecurityTokenConstants
> > > [ERROR]
> > > /Users/jiangning/work/wss4j/wss4j/ws-security-stax/src/main/java/org/apache/wss4j/stax/validate/SecurityContextTokenValidatorImpl.java:[42,61]
> > > cannot find symbol
> > > [ERROR] symbol : constructor
> > > AbstractInboundSecurityToken(org.apache.wss4j.stax.ext.WSInboundSecurityContext,java.lang.String,org.apache.xml.security.stax.securityToken.SecurityTokenConstants.KeyIdentifier,boolean)
> > > [ERROR] location: class
> > > org.apache.xml.security.stax.impl.securityToken.AbstractInboundSecurityToken
> > > [ERROR]
> > > /Users/jiangning/work/wss4j/wss4j/ws-security-stax/src/main/java/org/apache/wss4j/stax/validate/SecurityContextTokenValidatorImpl.java:[44,82]
> > > cannot find symbol
> > > [ERROR] symbol : constructor AbstractInboundSecurityToken()
> > > [ERROR] location: class
> > > org.apache.xml.security.stax.impl.se

Re: svn commit: r1496976 - in /cxf/trunk: rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/policyhandlers/ systests/ws-security/src/test/java/org/apache/cxf/systest/ws/saml/ systests/ws-s

[Willem jiang]

I tried to build the latest version of wss4j with -U option, I still get the 
errors.


--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem




On Thursday, June 27, 2013 at 4:48 PM, Colm O hEigeartaigh wrote:

> Could you try with "-U"? It's working fine for me, but you probably don't
> have the most up to date Santuario/WSS4J SNAPSHOT jars in your maven repo.
>  
> Colm.
>  
>  
> On Thu, Jun 27, 2013 at 5:41 AM, Willem jiang  (mailto:willem.ji...@gmail.com)>wrote:
>  
> > Hi Colm,
> >  
> > I tried to build the CXF trunk and ran into this error.
> >  
> > [ERROR]
> > /Users/jiangning/work/cxf/git/cxf/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/policyhandlers/StaxSymmetricBindingHandler.java:[454,42]
> > cannot find symbol
> > [ERROR] symbol : method getSha1Identifier()
> > [ERROR] location: interface
> > org.apache.xml.security.stax.securityToken.SecurityToken
> > [ERROR]
> > /Users/jiangning/work/cxf/git/cxf/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/policyhandlers/StaxSymmetricBindingHandler.java:[484,33]
> > cannot find symbol
> > [ERROR] symbol : method getSha1Identifier()
> > [ERROR] location: interface
> > org.apache.xml.security.stax.securityToken.SecurityToken
> > [ERROR]
> > /Users/jiangning/work/cxf/git/cxf/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/policyhandlers/StaxSymmetricBindingHandler.java:[549,34]
> > cannot find symbol
> > [ERROR] symbol : method setSha1Identifier(java.lang.String)
> > [ERROR] location: class
> > org.apache.xml.security.stax.impl.securityToken.GenericOutboundSecurityToken
> > [ERROR] -> [Help 1]
> >  
> >  
> >  
> >  
> > I even try to build the wss4j trunk, but I got more error in the
> >  
> > ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
> > (default-compile) on project wss4j-ws-security-stax: Compilation failure:
> > Compilation failure:
> > [ERROR]
> > /Users/jiangning/work/wss4j/wss4j/ws-security-stax/src/main/java/org/apache/wss4j/stax/impl/processor/output/EncryptOutputProcessor.java:[98,50]
> > cannot find symbol
> > [ERROR] symbol : method getSha1Identifier()
> > [ERROR] location: interface
> > org.apache.xml.security.stax.securityToken.OutboundSecurityToken
> > [ERROR]
> > /Users/jiangning/work/wss4j/wss4j/ws-security-stax/src/main/java/org/apache/wss4j/stax/impl/securityToken/SecurityTokenFactoryImpl.java:[140,65]
> > cannot find symbol
> > [ERROR] symbol : variable KeyIdentifier_IssuerSerial
> > [ERROR] location: class
> > org.apache.wss4j.stax.securityToken.WSSecurityTokenConstants
> > [ERROR]
> > /Users/jiangning/work/wss4j/wss4j/ws-security-stax/src/main/java/org/apache/wss4j/stax/validate/SecurityContextTokenValidatorImpl.java:[42,61]
> > cannot find symbol
> > [ERROR] symbol : constructor
> > AbstractInboundSecurityToken(org.apache.wss4j.stax.ext.WSInboundSecurityContext,java.lang.String,org.apache.xml.security.stax.securityToken.SecurityTokenConstants.KeyIdentifier,boolean)
> > [ERROR] location: class
> > org.apache.xml.security.stax.impl.securityToken.AbstractInboundSecurityToken
> > [ERROR]
> > /Users/jiangning/work/wss4j/wss4j/ws-security-stax/src/main/java/org/apache/wss4j/stax/validate/SecurityContextTokenValidatorImpl.java:[44,82]
> > cannot find symbol
> > [ERROR] symbol : constructor AbstractInboundSecurityToken()
> > [ERROR] location: class
> > org.apache.xml.security.stax.impl.securityToken.AbstractInboundSecurityToken
> > [ERROR]
> > /Users/jiangning/work/wss4j/wss4j/ws-security-stax/src/main/java/org/apache/wss4j/stax/ConfigurationConverter.java:[530,43]
> > cannot find symbol
> > [ERROR] symbol : variable KeyIdentifier_IssuerSerial
> > [ERROR] location: class
> > org.apache.wss4j.stax.securityToken.WSSecurityTokenConstants
> > ……
> >  
> >  
> >  
> >  
> >  
> > So I guess you didn't commit you local change of wss4j before you updated
> > the CXF code.
> >  
> > --
> > Willem Jiang
> >  
> > Red Hat, Inc.
> > FuseSource is now part of Red Hat
> > Web: http://www.fusesource.com | http://www.redhat.com
> > Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
> > (English)
> > http://jnn.iteye.com (http://jnn.javaey

Re: svn commit: r1496976 - in /cxf/trunk: rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/policyhandlers/ systests/ws-security/src/test/java/org/apache/cxf/systest/ws/saml/ systests/ws-s

[Willem jiang]

Hi Colm,  

I tried to build the CXF trunk and ran into this error.

[ERROR] 
/Users/jiangning/work/cxf/git/cxf/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/policyhandlers/StaxSymmetricBindingHandler.java:[454,42]
 cannot find symbol
[ERROR] symbol : method getSha1Identifier()
[ERROR] location: interface 
org.apache.xml.security.stax.securityToken.SecurityToken
[ERROR] 
/Users/jiangning/work/cxf/git/cxf/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/policyhandlers/StaxSymmetricBindingHandler.java:[484,33]
 cannot find symbol
[ERROR] symbol : method getSha1Identifier()
[ERROR] location: interface 
org.apache.xml.security.stax.securityToken.SecurityToken
[ERROR] 
/Users/jiangning/work/cxf/git/cxf/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/policyhandlers/StaxSymmetricBindingHandler.java:[549,34]
 cannot find symbol
[ERROR] symbol : method setSha1Identifier(java.lang.String)
[ERROR] location: class 
org.apache.xml.security.stax.impl.securityToken.GenericOutboundSecurityToken
[ERROR] -> [Help 1]




I even try to build the wss4j trunk, but I got more error in the  

ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on 
project wss4j-ws-security-stax: Compilation failure: Compilation failure:
[ERROR] 
/Users/jiangning/work/wss4j/wss4j/ws-security-stax/src/main/java/org/apache/wss4j/stax/impl/processor/output/EncryptOutputProcessor.java:[98,50]
 cannot find symbol
[ERROR] symbol : method getSha1Identifier()
[ERROR] location: interface 
org.apache.xml.security.stax.securityToken.OutboundSecurityToken
[ERROR] 
/Users/jiangning/work/wss4j/wss4j/ws-security-stax/src/main/java/org/apache/wss4j/stax/impl/securityToken/SecurityTokenFactoryImpl.java:[140,65]
 cannot find symbol
[ERROR] symbol : variable KeyIdentifier_IssuerSerial
[ERROR] location: class 
org.apache.wss4j.stax.securityToken.WSSecurityTokenConstants
[ERROR] 
/Users/jiangning/work/wss4j/wss4j/ws-security-stax/src/main/java/org/apache/wss4j/stax/validate/SecurityContextTokenValidatorImpl.java:[42,61]
 cannot find symbol
[ERROR] symbol : constructor 
AbstractInboundSecurityToken(org.apache.wss4j.stax.ext.WSInboundSecurityContext,java.lang.String,org.apache.xml.security.stax.securityToken.SecurityTokenConstants.KeyIdentifier,boolean)
[ERROR] location: class 
org.apache.xml.security.stax.impl.securityToken.AbstractInboundSecurityToken
[ERROR] 
/Users/jiangning/work/wss4j/wss4j/ws-security-stax/src/main/java/org/apache/wss4j/stax/validate/SecurityContextTokenValidatorImpl.java:[44,82]
 cannot find symbol
[ERROR] symbol : constructor AbstractInboundSecurityToken()
[ERROR] location: class 
org.apache.xml.security.stax.impl.securityToken.AbstractInboundSecurityToken
[ERROR] 
/Users/jiangning/work/wss4j/wss4j/ws-security-stax/src/main/java/org/apache/wss4j/stax/ConfigurationConverter.java:[530,43]
 cannot find symbol
[ERROR] symbol : variable KeyIdentifier_IssuerSerial
[ERROR] location: class 
org.apache.wss4j.stax.securityToken.WSSecurityTokenConstants
……





So I guess you didn't commit you local change of wss4j before you updated the 
CXF code.  

--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem





On Wednesday, June 26, 2013 at 11:53 PM, cohei...@apache.org wrote:

> Author: coheigea
> Date: Wed Jun 26 15:53:24 2013
> New Revision: 1496976
>  
> URL: http://svn.apache.org/r1496976
> Log:
> Added support for the streaming SymmetricBinding for X.509 + SAML tokens
>  
> Modified:
> cxf/trunk/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/policyhandlers/StaxSymmetricBindingHandler.java
> cxf/trunk/systests/ws-security/src/test/java/org/apache/cxf/systest/ws/saml/StaxSamlTokenTest.java
> cxf/trunk/systests/ws-security/src/test/java/org/apache/cxf/systest/ws/x509/StaxX509TokenTest.java
> cxf/trunk/systests/ws-security/src/test/resources/org/apache/cxf/systest/ws/saml/server/stax-server.xml
>  
> Modified: 
> cxf/trunk/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/policyhandlers/StaxSymmetricBindingHandler.java
> URL: 
> http://svn.apache.org/viewvc/cxf/trunk/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/policyhandlers/StaxSymmetricBindingHandler.java?rev=1496976&r1=1496975&r2=1496976&view=diff
> ==
> --- 
> cxf/trunk/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/policyhandlers/StaxSymmetricBindingHandler.java
>  (original)
> +++ 
> cxf/trunk/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/policyhandlers/StaxSymmetricBindingHandler.java
>  Wed J

Re: Netty transport for CXF

[Willem jiang]

On Thursday, May 30, 2013 at 4:15 AM, Daniel Kulp wrote:

>  
> On May 27, 2013, at 10:14 PM, Willem jiang  (mailto:willem.ji...@gmail.com)> wrote:
> > > > I just did a prototype of support Netty transport for CXF, it include 
> > > > the server side implementation and client side implementation. And I 
> > > > did some performance compare tests by running the wsdl_first from 
> > > > examples with Jetty transport and Netty transport and using Jmeter to 
> > > > send the requests. The test results are much similar, Netty transport 
> > > > and Jetty transport can hit the highest processing recorder with the 
> > > > throughput of 9M per second in my MacBookPro. I only performance 
> > > > turning I did was just changing the thread pool size of 
> > > > ExecutionHandler which will be used to call the whole soap stake of CXF.
> > >  
> > >  
> > >  
> > > When I looked at Netty's HTTP client stuff (over a year ago now), I had 
> > > MAJOR problems getting it to stream large messages. The small messages 
> > > worked great and did have good performance, but once we could no longer 
> > > buffer the whole message and wanted to get it streaming in chunks, I 
> > > could never get it working. That said, that was a long time ago and they 
> > > may have fixed all the bugs related to that.
> > The test that I did just one the server side and no chunk encoding involved.
> > We can polish it if we need :)  
>  
>  
>  
> Just checked. If the size of the message sent from the client exceeds the 
> chunk threshold, nothing gets sent over the wire at all. :-( The client then 
> just hangs and eventually times out. Didn't really look into what is needed 
> yet.

I will dig this issue next week when I finish the SSL support of the netty.  
>  
>  
> > > > I'd like to commit the prototype into Apache CXF trunk, and we could 
> > > > polish the transport together :)
> > > > Any thought?
> > >  
> > >  
> > >  
> > >  
> > >  
> > > Sure. On the client side, if it's sticking to HTTP, I'd like to see it 
> > > plug into the HTTPConduit like the async client version does. That's 
> > > something we could work on though. Speaking of asyncclient version, they 
> > > supposedly have a new version that is supposedly significantly faster. On 
> > > my todo list to look at. :-(
> > Yes, it do the same thing as the async client does.
> > I will commit the code shortly today.  
>  
>  
>  
> We'll likely need to figure something out. With your changes to distribution, 
> both async and netty clients are in the lib dir and it would then be 
> whichever one is found on the classpath first.  
>  
I've been thinking about it for a while, maybe we should introduce some schemes 
as camel does, such as "abc", "netty", etc. if the client want to use async 
http client, he could specify the address with "ahc:http://example.com/server"; 
and if he want to use netty he could use "netty:http://example.com/server";, if 
he uses "http://example.com/server"; we just let the class path decide which 
client will be used.

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




--  
Willem Jiang



Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  

Weibo: 姜宁willem  

Re: Netty transport for CXF

[Willem jiang]

Hi Dan,

Please check out my comments in line.  

--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem




On Tuesday, May 28, 2013 at 10:05 AM, Daniel Kulp wrote:

>  
> On May 26, 2013, at 11:54 PM, Willem jiang  (mailto:willem.ji...@gmail.com)> wrote:
>  
> > Hi,  
> >  
> > As you know Netty[1] provides excellent supports of NIO and you can still 
> > get the full control of protocol handler. It could be useful if we provides 
> > a Netty transport of CXF.
>  
> Are you proposing some sort of proprietary Netty transport or are you 
> thinking of using Netty's HTTP stuff to create another HTTP implementation 
> for CXF?

It just leverage the Netty HTTP implementations.   
>  
>  
> >  
> > I just did a prototype of support Netty transport for CXF, it include the 
> > server side implementation and client side implementation. And I did some 
> > performance compare tests by running the wsdl_first from examples with 
> > Jetty transport and Netty transport and using Jmeter to send the requests. 
> > The test results are much similar, Netty transport and Jetty transport can 
> > hit the highest processing recorder with the throughput of 9M per second in 
> > my MacBookPro. I only performance turning I did was just changing the 
> > thread pool size of ExecutionHandler which will be used to call the whole 
> > soap stake of CXF.
>  
> When I looked at Netty's HTTP client stuff (over a year ago now), I had MAJOR 
> problems getting it to stream large messages. The small messages worked great 
> and did have good performance, but once we could no longer buffer the whole 
> message and wanted to get it streaming in chunks, I could never get it 
> working. That said, that was a long time ago and they may have fixed all the 
> bugs related to that.
The test that I did just one the server side and no chunk encoding involved.
We can polish it if we need :)   
>  
>  
>  
> > I'd like to commit the prototype into Apache CXF trunk, and we could polish 
> > the transport together :)
> > Any thought?
>  
>  
>  
> Sure. On the client side, if it's sticking to HTTP, I'd like to see it plug 
> into the HTTPConduit like the async client version does. That's something we 
> could work on though. Speaking of asyncclient version, they supposedly have a 
> new version that is supposedly significantly faster. On my todo list to look 
> at. :-(
Yes, it do the same thing as the async client does.
I will commit the code shortly today.  
>  
>  
> --  
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com

Netty transport for CXF

[Willem jiang]

Hi,  

As you know Netty[1] provides excellent supports of NIO and you  can still get 
the full control of protocol handler. It could be useful if we provides a Netty 
transport of CXF.

I just did a prototype of support Netty transport for CXF, it include the 
server side implementation and client side implementation. And I did some 
performance compare tests by running the wsdl_first from examples with Jetty 
transport and Netty transport and using Jmeter to send the requests. The test 
results are much similar,  Netty transport and Jetty transport can hit the 
highest processing recorder with the throughput of 9M per second in my 
MacBookPro.  I only performance turning I did was just changing the thread pool 
size of ExecutionHandler which will be used to call the whole soap stake of CXF.

I'd like to commit the prototype into Apache CXF trunk, and we could polish the 
transport together :)
Any thought?

[1]http://netty.io/

--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem

Re: Spring/Aries/Jetty versions for 3.0....

[Willem jiang]

It sounds good, here is my +1.


--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem





On Wednesday, May 22, 2013 at 12:39 AM, Daniel Kulp wrote:

>  
> Curious what people think about the various versions for CXF 3.
>  
> Aries:
> We current support 1.x and 0.3.x via a bunch of reflection stuff. If we drop 
> support for 0.3.x, we can clean up some of that reflection code. However, we 
> then lose support for Karaf 2.2.x.
>  
> Spring:
> We current test with 3.1, but have some level of support for 2.5.x by calling 
> a bunch of deprecated methods instead of the newer methods. Thoughts about at 
> least dropping support for 2.5.x? Likely should move to 3.2 as our default, 
> but keep support for 3.1?
>  
> Jetty:
> We current test and ship 8.1, but have support for 7.x via a bunch of 
> reflection code. Since even Karaf 2.3 uses 7.x, we likely need to keep this. 
> :-(
>  
>  
>  
> --  
> 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 3

[Willem jiang]

+1,


--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem





On Saturday, May 11, 2013 at 9:22 AM, Daniel Kulp wrote:

>  
> 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=12310511&version=12324276
> 2.7.5
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=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

[Willem jiang]

+1


--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem




On Wednesday, May 8, 2013 at 8:57 AM, Daniel Kulp wrote:

>  
> 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=12310511&version=12324276
> 2.7.5
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=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: Spring integration

[Willem jiang]

Yeah, you are not the first one who has this idea.
I think the easiest way is implement a transport of sprint integration, you can 
setup the {Input|Output} channel for the conduit or destination.
The difficult part could how to implement the CXF Continuation API with spring 
integration async support.

BTW, CXF supports the Servlet3 async invocation API out of box.  

--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem





On Friday, April 12, 2013 at 8:27 AM, Jason Pell wrote:

> Topics of interest.
>  
> http://cxf.547215.n5.nabble.com/re-CXF-with-Sprint-Integration-td5501007.html
> http://cxf.547215.n5.nabble.com/CXF-embedded-within-a-SpringIntegration-Context-td5158465.html
>  
>  
> On Wed, Apr 10, 2013 at 8:25 PM, Jason Pell  (mailto:ja...@pellcorp.com)> wrote:
>  
> > Is there any plans to add namespace support for jaxws endpoint and client
> > to spring integration?
> >  
> > I am envisioning ability to define jaxws:client as a gateway with a queue
> > channel in between to provide decoupling of client from transport
> >  
> > And endpoint as a end of a channel - service activator maybe.
> >  
> > There is camel support for cxf not sure how that works
> >  
> > I am looking at using spring integration for async support rather than jms  

Re: filtering of features at automatic features loading over osgi service

[Willem jiang]

Yes, we could use the Client/ServerLifecycleListener to do that kind of job.
But now I have some trouble to do the same configuration on the WebClient which 
is created by JAXRSClientFactoryBean.
It looks like the ClientLifecycleListener doesn't work for the WebClient, I had 
to using the patch in CXF-4953 (https://issues.apache.org/jira/browse/CXF-4953) 
to work around it.

We need implement the same interface in jaxrs front end.

[1]https://issues.apache.org/jira/browse/CXF-4953  

--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem





On Tuesday, April 9, 2013 at 7:33 PM, Daniel Kulp wrote:

>  
> On Apr 9, 2013, at 4:53 AM, Willem.Jiang  (mailto:willem.ji...@gmail.com)> wrote:
>  
> > Hi,
> > I'm sorry my reply may not relate to this discussion directly, but I think
> > it could be interesting to for us to discuss that if the bus aware the
> > exported feature, how the ClientFactoryBeans can use it. As you know the
> > feature could not just be used to setup the interceptors.
>  
>  
>  
> No, features applied to a Bus should only be applied to the Bus as they may 
> only be designed for that scenario. If you have something that needs to be 
> applied to a client or server, they should be registering the 
> Client/ServerLifcycleListeners and apply things at that point.
>  
> Dan
>  
>  
> >  
> > I create a JIRA CXF-4953[1] for it.  
> > Any thought?
> >  
> > [1]https://issues.apache.org/jira/browse/CXF-4953
> >  
> > Willem
> >  
> >  
> >  
> > --
> > View this message in context: 
> > http://cxf.547215.n5.nabble.com/filtering-of-features-at-automatic-features-loading-over-osgi-service-tp5724596p5726029.html
> > Sent from the cxf-dev mailing list archive at Nabble.com 
> > (http://Nabble.com).
>  
>  
>  
> --  
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com

Re: [VOTE] Release Apache CXF 2.5.10/2.6.7/2.7.4

[Willem jiang]

+1


--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem





On Friday, March 29, 2013 at 5:09 AM, Daniel Kulp wrote:

>  
> We've resolved over 80 issues since 2.7.3, which is a bunch
>  
>  
> List of issues:
> 2.5.10
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12324007
> 2.6.7
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12324006
> 2.7.4
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12324005
>  
> The Maven staging areas are at: (forgot to close between 2.5.10 and 2.6.7)
> 2.5.10
> 2.6.7
> https://repository.apache.org/content/repositories/orgapachecxf-030/
> 2.7.4
> https://repository.apache.org/content/repositories/orgapachecxf-031/
>  
>  
> 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.5.10
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.7
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.4
>  
> This vote will be open for at least 72 hours.
>  
>  
> Here's my +1.
>  
>  
> --  
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com

Re: Can anybody take a look at CXF-4836?

[Willem jiang]

Hi,

If you just call the Service svc = Service.create(serviceName);
CXF know nothing about how to build the ServiceModel as it's only a ServiceName.
When you call  
port = svc.getPort(portName, MTOMInterface.class);
It can build the ServiceModel according to the MTOMInterface.class, but it 
doesn't know anything about the endpoint address.
If we don't through the exception here, user will think the port object is OK 
for sending invocation, and it is hard for him to track the issue in the run 
time.  
You still need to call the svc.addPort for it.

BTW, it's typical usage of JAXWS API, I don't think there is anything wrong 
with it.   

--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem





On Monday, March 11, 2013 at 1:56 PM, Yanmin Sheng wrote:

> We create such client which will set target address info and binding
> info in RequestContext of BindingProvider.
>  
> String mtom11URL = "http://localhost:9080//MyBusiness/MTOM11Service";;
>  
> MTOMInterface port = null;
> BindingProvider bp = null;
>  
> System.out.println("Looking up SOAP 1.1 MTOM service");
>  
> QName serviceName = new 
> QName("http://shengym.com/MyBusiness/","MTOM11Service";);
> QName portName = new QName("http://shengym.com/MyBusiness";, "MTOM11Port");
> // Setup the necessary JAX-WS artifacts
> Service svc = Service.create(serviceName);
> port = svc.getPort(portName, MTOMInterface.class);
>  
> // Set the target URL
> bp = (BindingProvider) port;
> Map requestCtx = bp.getRequestContext();
> requestCtx.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,mtom11URL);
>  
> // Enable MTOM
> SOAPBinding binding = (SOAPBinding) bp.getBinding();
> binding.setMTOMEnabled(true);
>  
> However, it reports such error:
>  
> javax.xml.ws.WebServiceException:Port
> {http://shengym.com/MyBusiness/}
>  
> MTOM11Port not found.
> org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:332)
> org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:323)
> javax.xml.ws.Service.getPort(Service.java:134)
>  
> I know that the added following code can fix this error:
> svc.addPort(portName, SOAPBinding.SOAP11HTTP_MTOM_BINDING, mtom11URL);
>  
> Well, this error should not report even the addPort method is not called.
> I know the added check in ServiceImpl is to avoid run time error and
> report it as early as possible. But I think it is not needed. The
> reasons are:
> 1. User can get run time error later;
> 2. User can set target addess info and bind info in other ways (as my
> example shows)
>  
> I remove the check from the ServiceImpl then my client code works well.  

Re: [VOTE] New features.xml for 2.6.6

[Willem jiang]

Here is my +1.

--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem





On Thursday, February 14, 2013 at 2:05 AM, Daniel Kulp wrote:

>  
> There is a problem with the features.xml file for 2.6.6 where a property 
> wasn't expanded. This is a vote to release a 2.6.6.1 versioned features file 
> only that pulls in the 2.6.6 bundles, but correct the property expansion.  
>  
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachecxf-232/
>  
> Tag:
> https://svn.apache.org/repos/asf/cxf/tags/apache-cxf-features-xml-2.6.6.1/
>  
>  
> --  
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com

Re: [VOTE] CXF 2.7.3/2.6.6/2.5.9

[Willem jiang]

Here is my +1.


--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem





On Tuesday, January 29, 2013 at 10:30 PM, Daniel Kulp wrote:

>  
>  
>  
> We've resolved over 35 issues since 2.7.2. Not a huge number, but sufficient. 
>  
>  
>  
> List of issues:
> 2.5.9
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12323912
> 2.6.6
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12323911
> 2.7.3
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12323910
>  
> The Maven staging areas are at:
> 2.5.9
> https://repository.apache.org/content/repositories/orgapachecxf-184/
> 2.6.6
> https://repository.apache.org/content/repositories/orgapachecxf-185/
> 2.7.3
> https://repository.apache.org/content/repositories/orgapachecxf-187/
>  
> 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.5.9
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.6
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.3
>  
> This vote will be open for at least 72 hours.
>  
>  
> Here's my +1.
>  
>  
> --  
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com

Re: [VOTE] Apache CXF 2.5.8/2.6.5/2.7.2

[Willem jiang]

+1,

I did some tests on the camel trunk with cxf-2.7.2, every thing looks good.  

--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem





On Saturday, January 5, 2013 at 6:22 AM, Daniel Kulp wrote:

>  
>  
> We've resolved over 35 issues since 2.7.1. Not a huge number, but sufficient. 
>  
>  
>  
> List of issues:
> 2.5.8
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12323606
> 2.6.5
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12323605
> 2.7.2
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12323604
>  
> The Maven staging areas are at:
> 2.5.8
> https://repository.apache.org/content/repositories/orgapachecxf-99/
> 2.6.5
> https://repository.apache.org/content/repositories/orgapachecxf-100/
> 2.7.2
> https://repository.apache.org/content/repositories/orgapachecxf-101/
>  
> 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.5.8
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.5
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.2
>  
> This vote will be open for at least 72 hours.
>  
>  
> Here's my +1.
>  
>  
> --  
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com

Re: aligning exceptionMessgeCauseEnabled for CXF-4689 (Re: interpretation of jaxws 10.2.2 exception handling

[Willem jiang]

+1 for get more meaningful exception message.


--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem





On Tuesday, December 18, 2012 at 10:02 PM, Aki Yoshida wrote:

> Hi Willem, Team,
>  
> I am working on CXF-4689 that requests for a feature to return the
> runtime exception information. Initially, as this question was raised
> on users@cxf [1], I suggested the requester to use the
> exceptionMessageCauseEnabled property. However, this did not work, as
> this option only writes additionally ex.getMessage() and this is null
> in runtime exceptions. Furthermore, during this discussion, it was
> pointed out that the jaxws spec section 10.2.2 specifies that the
> faultstring value must be constructed from ex.toString() when
> ex.getMessage() is null for runtime exceptions.
>  
> As this potentially touches the security aspect, Glen and I discussed
> over it [2] and I am looking for a solution using a configurable
> property.
>  
> In principle, the purpose of this exceptionMessageCauseEnabled, which
> was introduced for CXF-3443 [3], is quite similar to the original
> requester's use case. However, its behavior differs from what is
> specified in the jaxws's faultstring rule and also from what the
> javadoc in Message.java on this property says. So my question is
> whether we can align the behavior of this property.
>  
> Currently, this property constructs the faultstring from
>  
> fault.getMessage() + " Caused by " + cause.getMessage()
>  
> That means (using the behavior prior to my current temporary change in
> Fault, which I intend to revert and replace it with a more appropriate
> solution),
> o Fault("fault happened", new RuntimeException("unexpected")) =>
> "fault happened Caused by unexpected".
> o Fault(new RuntimeException("unexpected")) => "unexpected Caused by
> unexpected"
> o Fault(new RuntimeException()) => "null Caused by null".
>  
> The second and third cases do not seem practical. One possibility is
> to change the behavior based on the getMessage() value.
>  
> For example, if we have
> if fault.getMessge() is null but cause.getMessage() isn't null or both
> are not null and equal, we can use cause.getMessage().
> if both fault.getMessage() and cause.getMessage() are null, we can use
> cause.toString()
>  
> With this rule, we get for the second and third cases the faultstring
> that conforms to the jaxws faultstring rule.
> o Fault(new RuntimeException("unexpected")) => "unexpected"
> o Fault(new RuntimeException()) => "java.lang.RuntimeException".
>  
> Do you think we can unify this behavior? Or do you think we should
> introduce a separate property to turn on this jaxws's faultstring
> generation rule?
>  
> 1. 
> http://cxf.547215.n5.nabble.com/SOAPFault-message-improvement-in-CXF-when-there-is-unchecked-NPE-tc5719398.html#a5719568
> 2. https://issues.apache.org/jira/browse/CXF-4684
> 3. https://issues.apache.org/jira/browse/CXF-3442
>  
> Regards, Aki
>  
> 2012/12/10 Aki Yoshida mailto:elak...@gmail.com)>:
> > Hi Dan,
> >  
> > The spec seems to say that ex.toString() is only used for message-less
> > runtime exceptions from service endpoints or SOAPFaultException from
> > handlers. That would mean unexpected runtime exceptions from the
> > processing runtime are not exposed into the faultstring by default.
> > This could be intentional from security concerned people of not
> > wanting to expose technical details of unexpected runtime errors.
> > Maybe that would be overly concerned but it could be.
> >  
> > In that case, I thought we could follow the same rule and limit the
> > use of ex.toString() to only service endpoints exceptions.
> >  
> > Thanks for your comments. As you suggest, we will probably look at
> > what RI is doing.
> >  
> > regards, aki
> >  
> > 2012/12/10 Daniel Kulp mailto:dk...@apache.org)>:
> > >  
> > > On Dec 10, 2012, at 3:29 AM, Aki Yoshida  > > (mailto:elak...@gmail.com)> wrote:
> > >  
> > > > Hi,
> > > > There is a mail thread on users@cxf regarding the soap faultstring
> > > > generation rule.
> > > > http://mail-archives.apache.org/mod_mbox/cxf-users/201212.mbox/%3CCANXr88J3iiWU_d_xrBDv0x5msKH9FiWVP-DcQA9fOWC_3p%3DFvQ%40mail.gmail.com%3E
> > > >  
> > >

Re: [VOTE] Apache CXF 2.5.7/2.6.4/2.7.1

[Willem jiang]

+1

Willem  

--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem





On Friday, December 7, 2012 at 10:41 PM, Daniel Kulp wrote:

>  
> We've resolved over 110 issues since 2.7.0. That's a very large number for a 
> patch release so we definitely should get this out. Over 90 were ported back 
> to 2.6.4, again, a large number.  
>  
>  
> List of issues:
> 2.5.7
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12323349
> 2.6.4
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12323348
> 2.7.1
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12323347
>  
> The Maven staging areas are at:
> 2.5.7
> https://repository.apache.org/content/repositories/orgapachecxf-120/
> 2.6.4
> https://repository.apache.org/content/repositories/orgapachecxf-121/
> 2.7.1
> https://repository.apache.org/content/repositories/orgapachecxf-122/
>  
>  
> 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.5.7
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.4
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.1
>  
> This vote will be open for at least 72 hours.
>  
>  
> Here's my +1.
>  
>  
> --  
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com

Re: svn commit: r1399990 - /cxf/trunk/services/sts/sts-core/pom.xml

[Willem jiang]

DefaultSecurityTokenServiceProvider need to use the cxf-rt-ws-security module.


If we remove the import package, it will cause some trouble for us to load the 
DefaultSecurityTokenServiceProvider.




On Friday, October 19, 2012 at 8:24 PM, Colm O hEigeartaigh wrote:

> > I'm also wondering why its importing org.apache.cxf.sts.provider which
> 
> 
> it's also exporting. Isn't that something it shouldn't be
> > doing? Colm, know why?
> 
> 
> 
> No idea. At a guess it was put there to add the STS provider framework
> (should be "org.apache.cxf.ws.security.sts.provider") in the
> cxf-rt-ws-security module. But it can just be removed I think.
> 
> Colm.
> 
> On Fri, Oct 19, 2012 at 12:43 PM, Daniel Kulp  (mailto:dk...@apache.org)> wrote:
> 
> > 
> > I'm -1 to this change (and to the similar change done to the wsn stuff).
> > I KNOW the latest sts stuff doesn't work with 2.6.0 due to the security
> > enhancements done in 2.6.1. As we move forward, I'm 95% confident that
> > other security related things will prevent it from working in the future.
> > 
> > I'm also wondering why its importing org.apache.cxf.sts.provider which
> > it's also exporting. Isn't that something it shouldn't be doing? Colm,
> > know why?
> > 
> > 
> > Dan
> > 
> > 
> > 
> > On Oct 19, 2012, at 3:37 AM, ningji...@apache.org 
> > (mailto:ningji...@apache.org) wrote:
> > 
> > > Author: ningjiang
> > > Date: Fri Oct 19 07:37:45 2012
> > > New Revision: 130
> > > 
> > > URL: http://svn.apache.org/viewvc?rev=130&view=rev
> > > Log:
> > > CXF-4585 Updated the cxf imports version range of sts-core bundle
> > > 
> > > Modified:
> > > cxf/trunk/services/sts/sts-core/pom.xml
> > > 
> > > Modified: cxf/trunk/services/sts/sts-core/pom.xml
> > > URL:
> > 
> > 
> > http://svn.apache.org/viewvc/cxf/trunk/services/sts/sts-core/pom.xml?rev=130&r1=1399989&r2=130&view=diff
> > 
> > 
> > ==
> > > --- cxf/trunk/services/sts/sts-core/pom.xml (original)
> > > +++ cxf/trunk/services/sts/sts-core/pom.xml Fri Oct 19 07:37:45 2012
> > > @@ -102,9 +102,9 @@
> > 
> > 
> > org.apache.cxf.sts.*;version=${project.version}
> > > 
> > > 
> > > -
> > 
> > 
> > org.apache.cxf.sts.provider.*;version=${project.version},
> > > +
> > 
> > 
> > org.apache.cxf.sts.provider.*;version="[2.6,3)",
> > > !org.apache.cxf.sts.*,
> > > - org.apache.cxf.*;version=${project.version},
> > > + org.apache.cxf.*;version="[2.6,3)",
> > > javax.xml.ws*;version="[0.0,3)",
> > 
> > 
> > org.springframework.ldap*;resolution:=optional,
> > > *
> > 
> > 
> > 
> > --
> > 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: svn commit: r1399990 - /cxf/trunk/services/sts/sts-core/pom.xml

[Willem jiang]

Hi Dan,

I'm sorry, I just saw the mail. 
For the wsn service stuff, as it is not tied with CXF version which we ship, so 
it should be fine.
I will revert the sts-service part, as it could introduce some security related 
issue.

-- 
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang 
Weibo: willemjiang





On Friday, October 19, 2012 at 7:43 PM, Daniel Kulp wrote:

> 
> I'm -1 to this change (and to the similar change done to the wsn stuff). I 
> KNOW the latest sts stuff doesn't work with 2.6.0 due to the security 
> enhancements done in 2.6.1. As we move forward, I'm 95% confident that other 
> security related things will prevent it from working in the future.
> 
> I'm also wondering why its importing org.apache.cxf.sts.provider which it's 
> also exporting. Isn't that something it shouldn't be doing? Colm, know why?
> 
> 
> Dan
> 
> 
> 
> On Oct 19, 2012, at 3:37 AM, ningji...@apache.org 
> (mailto:ningji...@apache.org) wrote:
> 
> > Author: ningjiang
> > Date: Fri Oct 19 07:37:45 2012
> > New Revision: 130
> > 
> > URL: http://svn.apache.org/viewvc?rev=130&view=rev
> > Log:
> > CXF-4585 Updated the cxf imports version range of sts-core bundle
> > 
> > Modified:
> > cxf/trunk/services/sts/sts-core/pom.xml
> > 
> > Modified: cxf/trunk/services/sts/sts-core/pom.xml
> > URL: 
> > http://svn.apache.org/viewvc/cxf/trunk/services/sts/sts-core/pom.xml?rev=130&r1=1399989&r2=130&view=diff
> > ==
> > --- cxf/trunk/services/sts/sts-core/pom.xml (original)
> > +++ cxf/trunk/services/sts/sts-core/pom.xml Fri Oct 19 07:37:45 2012
> > @@ -102,9 +102,9 @@
> > org.apache.cxf.sts.*;version=${project.version}
> > 
> > 
> > - org.apache.cxf.sts.provider.*;version=${project.version},
> > + org.apache.cxf.sts.provider.*;version="[2.6,3)",
> > !org.apache.cxf.sts.*,
> > - org.apache.cxf.*;version=${project.version},
> > + org.apache.cxf.*;version="[2.6,3)",
> > javax.xml.ws*;version="[0.0,3)",
> > org.springframework.ldap*;resolution:=optional,
> > *
> 
> 
> 
> -- 
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com

Re: jms-spec-demo WSDL over-configured?

[Willem jiang]

Hi Glen,

As you know, WSDL supports to override the configuration from different level,  
such as the wsdl:service can override the definition of the wsdl:binding, and 
wsdl:port can override the definition of the wsdl:service.

And you can override the WSDL definition by specify the JMS address when you 
publish the service.
I think we should tell user about it in the README,  so they will not be 
confused any more.
 
-- 
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang 
Weibo: willemjiang





On Monday, October 22, 2012 at 9:35 AM, Glen Mazza wrote:

> Team, I noticed we're configuring the JMS info in the jms-spec-demo sample
> WSDL in three places[1]: within the wsdl:binding, under the wsdl:service,
> and under the wsdl:port. I believe one location alone will suffice--just
> the wsdl:binding section. Unless any objections, I'll simplify the WSDL to
> that but mention in the README it can be alternatively attached to the
> wsdl:service or wsdl:port section as well if desired.
> 
> Regards,
> Glen
> 
> [1]
> http://svn.apache.org/viewvc/cxf/trunk/distribution/src/main/release/samples/jms-spec-demo/wsdl/jms_greeter.wsdl?revision=806580&view=markup
> 
> 
> 
> 
> --
> View this message in context: 
> http://cxf.547215.n5.nabble.com/jms-spec-demo-WSDL-over-configured-tp5717075.html
> Sent from the cxf-dev mailing list archive at Nabble.com (http://Nabble.com).

Re: encrypting tmp files generated by CachedOutputStream?

[Willem jiang]

Using the system property will effect CXF instance across the JVM.
It could be good if we can do it on the bus level.

--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: willemjiang




On Thursday, October 18, 2012 at 9:05 PM, Aki Yoshida wrote:

> Hi Freeman,
> yes. This should be an option and disabled by default.
> I am thinking about introducing a system property
> org.apache.cxf.io.CachedOutputStream.something to set the cipher
> transformation name to enable this option.
>  
> regards, aki
>  
> 2012/10/18 Freeman Fang  (mailto:freeman.f...@gmail.com)>:
> > Hi Aki,
> >  
> > Basically I'm +1 for this good idea. Just a little bit concern about the 
> > performance impact.
> > Could we add a flag to enable this encryption behavior? By default the 
> > value is false, so keep same behavior as is, and users can explicitly 
> > enable it if they need a higher secure runtime.
> >  
> > My 2 cents.
> > Best Regards
> > Freeman
> > －
> > Freeman(Yue) Fang
> >  
> > Red Hat, Inc.
> > FuseSource is now part of Red Hat
> > Web: http://fusesource.com | http://www.redhat.com/
> > Twitter: freemanfang
> > Blog: http://freemanfang.blogspot.com
> > http://blog.sina.com.cn/u/1473905042
> > weibo: http://weibo.com/u/1473905042
> >  
> > On 2012-10-18, at 下午8:31, Aki Yoshida wrote:
> >  
> > > Hi,
> > > There is a concern that these temporary files are written out to the
> > > file system without any protection. And I was wondering if we can add
> > > an option to enable encryption for the stream output and keep the key
> > > in the COS instance so that only that COS instance can later read the
> > > data from the file system.
> > >  
> > > Is there any security concern to this approach? If none, I will go
> > > ahead and add this option.
> > >  
> > > thanks.
> > > regards, aki
> >  
>  

Re: OSGI service dynamic discovery using zookeeper

[Willem jiang]

Please check out my comments in the mail.

--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: willemjiang



On Monday, October 15, 2012 at 12:04 PM, Roger wrote:

> Hi,
>  
> Thanks for your reply.
> Please correct me if my understanding is wrong.
>  
> By using the fabric-cxf code, my code will need to specify the endpoints
> of the service providers right?

No， you just need to tell the zoo keeper address which could hold the reference 
of the service providers actual address.
The client can access the endpoint at the runtime.   
>  
> Actually, what I wanted to acheive is to retrieve a list of OSGI service
> provider information from the zookeeper and failover among the list. Will
> the fabric-cxf code helps me to retrieve the list of OSGI service provider
> information from the zookeeper at the start?

Yes, fabric-cxf does the exactly the same work as you want.
>  
> Thanks a lot.
>  
>  
>  
> --
> View this message in context: 
> http://cxf.547215.n5.nabble.com/OSGI-service-dynamic-discovery-using-zookeeper-tp5716356p5716593.html
> Sent from the cxf-dev mailing list archive at Nabble.com (http://Nabble.com).

Re: OSGI service dynamic discovery using zookeeper

[Willem jiang]

It is easy to let the zookeeper know when you publish the service.
But you client need more work to know the real service address by looking up 
the address from the zookeeper.

CXF client has the failover feature[1] could help you do this kind of work, you 
just need to configure the endpoint address which you want to use.
With the fabric-cxf[2] component you can do the same thing by leverage the 
zookeeper which just implement the feature you need.

[1]http://cxf.apache.org/docs/featureslist.html
[2]http://fuse.fusesource.org/fabric/docs/user-guide.html#CXF_Fabric
-- 
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang 
Weibo: willemjiang





On Thursday, October 11, 2012 at 11:09 AM, Roger wrote:

> Hi everyone,
> 
> Recently, I have just started exploring on the OSGI service dynamic
> discovery using the zookeeper.
> 
> Background info
> --
> I am using the eclipse osgi jars to start the bundles.
> I followed the instruction from the apache website to configure the
> zookeeper.
> Currently, I am able to publish my OSGI services to the zookeeper/osgi
> folder & also able to connect to the zookeeper using the client & retrieve
> the published service information. When I published a new service, the
> service will be reflected in the zookeeper.
> 
> Testing environment
> --
> I have two machines.
> I am running the same greeter service in two separate machines
> (connected in the same network).
> At the same time, I am running the greeter client program in one of the
> machines.
> I have also published both the services in the zookeeper (after placing
> the zookeeper.cfg in the load folder).
> 
> Verify my concept
> 
> I am thinking if I stop the service which runs in the same machine as
> the greeter client program, the greeter client should be able to track the
> other remote service running in the other machine (Is my concept right?). 
> However, when I stop the service (which runs in the same machine as the
> greeter client program), the servicetracker is not able to track the remote
> service. The number of tracked services is 0. 
> 
> My questions are:
> 
> 1) Are there any other settings which needs to be done for the client to
> discover the published services in the zookeeper? Must I tell the client
> where is the zookeeper or this is done by the single-bundle?
> 2) It seems like the client is not interacting with the zookeeper to get
> the published services information. Must I do anything to the client to
> retrieve the info?
> 3) Why cant the client switch to the remote service automatically?
> 
> Thanks a lot in advance.
> 
> Roger
> 
> 
> 
> --
> View this message in context: 
> http://cxf.547215.n5.nabble.com/OSGI-service-dynamic-discovery-using-zookeeper-tp5716356.html
> Sent from the cxf-dev mailing list archive at Nabble.com (http://Nabble.com).

Re: [VOTE] Release Apache CXF 2.4.10, 2.5.6, 2.6.3

[Willem jiang]

+1.

-- 
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang 
Weibo: willemjiang





On Saturday, October 6, 2012 at 7:40 PM, Daniel Kulp wrote:

> 
> 
> We've resolved over 48 issues since 2.6.2 with a bunch of them fairly 
> important. 
> 
> List of issues:
> 2.4.10
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12322966
> 2.5.6
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12322965
> 2.6.3
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12322964
> 
> 
> The Maven staging areas are at:
> 2.4.10
> https://repository.apache.org/content/repositories/orgapachecxf-093/
> 2.5.6
> https://repository.apache.org/content/repositories/orgapachecxf-094/
> 2.6.3
> https://repository.apache.org/content/repositories/orgapachecxf-095/
> 
> 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.4.10
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.6
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.3
> 
> This vote will be open for at least 72 hours.
> 
> 
> Here's my +1.
> 
> 
> -- 
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com

Re: [VOTE] Apache CXF 2.7.0

[Willem jiang]

I just ran some tests with Camel trunk, it looks good.
Here is my +1.

--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: willemjiang





On Saturday, October 6, 2012 at 7:43 PM, Daniel Kulp wrote:

>  
> It's been 6 months since 2.6.x was first released and thus time for the next 
> big thing. :-)
>  
> We have several new features including two new transports (UDP and an Async 
> based HTTP transport), WS-Discovery support, many JAX-RS enhancements while 
> on the road to 2.0 support, etc….
>  
>  
> The Maven staging area is at:
> https://repository.apache.org/content/repositories/orgapachecxf-098/
>  
> 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.7.0
>  
> Migration guide is at:
> http://cxf.apache.org/docs/27-migration-guide.html
>  
> Vote will be open for 72 hours.
>  
> Here is my +1.
>  
> --  
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com

Re: [PROPOSAL] Rename "Simple Frontend" --> "No-Annotation Frontend"?

[Willem jiang]

Hi Glen,

I'm sorry I forgot to replay the mail on the weekend. 

I totally agree with you that we could add a sentence to help people to search 
the simple front end  on the document if they want.

Now my question is will we rename the module name of the simple frontend in the 
code ?
If not, we still need to add a mapping between the code and docs. 
If so, we need to tell the people to change the poms if they are doing the 
upgrade.

It looks like we are introducing a troubles before we clean up the mass. The 
meaning of "simple" I think that is you don't need to configure any thing and 
it just runs, it is the KISS principle that we alway apply during our open 
source development process. But it could be dumb as CXF cannot know every thing 
he need to build up a right service module in the run time. That is why we need 
the JAXWS frontend. 

So I still opposite the proposal of rename the "Simple Frontend".

It could be more easier for users to realize that if they chose the simple 
frontend they may face lots of issues in the production world,  if we can list 
the issues in the wiki page instead of by guessing them from its name.

Any thought?

-- 
Willem Jiang

FuseSource
Web: http://www.fusesource.com (http://www.fusesource.com/)
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang 
Weibo: willemjiang





On Friday, September 7, 2012 at 12:35 AM, Glen Mazza wrote:

> Hi Willem, was my response sufficient for you to lift your veto or would you
> still like to prevent the proposed change?
> 
> Thanks,
> Glen
> 
> 
> 
> 
> --
> View this message in context: 
> http://cxf.547215.n5.nabble.com/PROPOSAL-Rename-Simple-Frontend-No-Annotation-Frontend-tp5713384p5713669.html
> Sent from the cxf-dev mailing list archive at Nabble.com (http://Nabble.com).

Re: [PROPOSAL] Rename "Simple Frontend" --> "No-Annotation Frontend"?

[Willem jiang]

Hi,

I don't think it is a good idea to just rename it in the wiki page as we still 
to provide a reference link for the people who want to search for the Simple 
Frontend.  I don't think current CXF kit doesn't provide this kind of document. 
People has to us the wiki for looking up the document, we should not prevent 
user to search "Simple Frontend".
So I'm -1 for this proposal.

I think we could explain about the "Simple Frontend" in the 5 min tutorial, and 
add a entry in FAQ to tell people it is not Simple when you use the "Simple 
Frontend".   

I think it could be easy for us to rename the "Simple Frontend" in CXF 3.0 if 
we really want to do it. As we could create CXFDOC3 for people to use.

My 2 cents. 

-- 
Willem Jiang

FuseSource
Web: http://www.fusesource.com (http://www.fusesource.com/)
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang 
Weibo: willemjiang





On Friday, August 31, 2012 at 4:31 AM, Glen Mazza wrote:

> Team, I'd like to rename our Simple Front End
> (https://cwiki.apache.org/confluence/display/CXF20DOC/Simple+Frontend) in
> our Confluence docs.
> 
> The problem with naming it "simple" is that it (1) falsely implies to
> newcomers that JAX-WS is difficult and something nasty to be avoided, and
> (2) its "simple" name encourages newcomers to use it. Further, what might
> be simple for the first twenty minutes of development may not actually be
> simple for the next six months of maintainance, and on that basis a fair
> argument could be made that the JAX-WS frontend is really the "simple" one.
> 
> Accordingly, I'd like to rename it the "No-Annotation Frontend" (I'm open to
> other ideas), because that's precisely what it is while being neutral about
> the other front end options (i.e., it's not good to have a frontend called
> "the intelligent frontend" or "the well-designed frontend" as it just makes
> the others look bad that way), and it also does not unduly encourage people
> to use it over the default JAX-WS front end. 
> 
> This will just be a Confluence search and replace (only a few pages). I'll
> keep the "simple"-named Schema as well as the -simple wsdl2java tooling
> option (just explaining it's for the no-Annotation front end in the
> docs)--while I *could* change those it would raise backward compatibility
> headaches for what is increasingly a seldom-used front end, so I don't think
> its worth the effort.
> 
> WDYT?
> 
> Glen
> 
> 
> 
> --
> View this message in context: 
> http://cxf.547215.n5.nabble.com/PROPOSAL-Rename-Simple-Frontend-No-Annotation-Frontend-tp5713384.html
> Sent from the cxf-dev mailing list archive at Nabble.com (http://Nabble.com).

Re: [VOTE] Release CXF Fediz 1.0.1

[Willem jiang]

+1

Willem 

-- 
Willem Jiang

FuseSource
Web: http://www.fusesource.com (http://www.fusesource.com/)
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang 
Weibo: willemjiang





On Saturday, August 25, 2012 at 1:02 AM, Glen Mazza wrote:

> Hi all, this new release provides significant documentation updates within
> the samples as well as new sample keys to help clarify necessary trust
> requirements. Oli has also gotten some programmatic fixes/enhancements in.
> 
> List of issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313420&version=12321857
> 
> Maven staging areas:
> https://repository.apache.org/content/repositories/orgapachecxf-006/
> 
> Releases are tagged at:
> http://svn.apache.org/repos/asf/cxf/fediz/tags/fediz-1.0.1/
> 
> Here is my +1. The vote will be open for at least 72 hours.
> 
> Thanks,
> Glen
> 
> 
> 
> 
> --
> View this message in context: 
> http://cxf.547215.n5.nabble.com/VOTE-Release-CXF-Fediz-1-0-1-tp5713126.html
> Sent from the cxf-dev mailing list archive at Nabble.com (http://Nabble.com).

Re: [VOTE] New features.xml for 2.5.5(.1)

[Willem jiang]

+1. We need to fix the feature issue ASAP.

-- 
Willem Jiang

FuseSource
Web: http://www.fusesource.com (http://www.fusesource.com/)
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang 
Weibo: willemjiang





On Wednesday, August 22, 2012 at 10:27 PM, Daniel Kulp wrote:

> 
> The Karaf features.xml file that was released with 2.5.5 is corrupt which is 
> preventing it from actually being usable to install CXF 2.5.5 into Karaf. 
> This vote is just to release a new features file (version 2.5.5.1) that fixes 
> that issue. It installs all the CXF 2.5.5 artifacts that have previously been 
> released.
> 
> Again, this is ONLY a features.xml file release.
> 
> Staging are:
> https://repository.apache.org/content/repositories/orgapachecxf-029/
> 
> Tag:
> http://svn.apache.org/repos/asf/cxf/tags/apache-cxf-features-xml-2.5.5.1/
> 
> 
> Here is my +1
> 
> -- 
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com

Re: [VOTE] Release Apache CXF 2.4.9/2.5.5/2.6.2

[Willem jiang]

That's it.
OK, here is my +1.

-- 
Willem Jiang

FuseSource
Web: http://www.fusesource.com (http://www.fusesource.com/)
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang 
Weibo: willemjiang




On Wednesday, August 15, 2012 at 9:04 PM, Daniel Kulp wrote:

> 
> Willem,
> 
> There are changes to Camel needed which I've done on trunk, but haven't yet 
> had the time to back port to the fixes branches.
> 
> Most notably are revs 1371861 and 1371861.
> 
> Will work on porting those back later today.
> 
> 
> Dan
> 
> 
> 
> On Aug 15, 2012, at 5:53 AM, Willem jiang  (mailto:willem.ji...@gmail.com)> wrote:
> 
> > Hi, 
> > 
> > I ran some tests in camel with CXF 2.6.2 and 2.5.5.
> > All the CXF related tests are passed with CXF 2.6.2 in the Camel trunk.
> > 
> > But I got some error when running the test with CXF 2.5.5 and Camel 2.9.x 
> > in camel-cxf module.
> > The test failures are
> > 
> > Failed tests: 
> > testDispatchPayload(org.apache.camel.component.cxf.CxfDispatchPayloadTest): 
> > The request should be handled sucessfully expected: but was:
> > Tests in error: 
> > testRoutes(org.apache.camel.component.cxf.CXFWsdlOnlyPayloadModeNoSpringSoap12Test):
> >  The given SOAPAction GetPersonAction does not match an operation.
> > testApplicationFault(org.apache.camel.component.cxf.CXFWsdlOnlyPayloadModeNoSpringSoap12Test):
> >  The given SOAPAction GetPersonAction does not match an operation.
> > 
> > 
> > 
> > When I changed the CXF version 2.5.4 all the tests passed, and these test 
> > are not change since Camel 2.9.0. So I bring these regression test out.
> > 
> > CxfDispatchPayloadTest is failed with on the client side with this error.
> > 
> > WARN PhaseInterceptor for 
> > {http://apache.org/hello_world_soap_http}GreeterService#{http://camel.apache.org/cxf/jaxws/dispatch}Invoke
> >  has thrown exception, unwinding now
> > org.apache.cxf.interceptor.Fault: Unexpected element 
> > {http://apache.org/hello_world_soap_http/types}greetMeResponse found. 
> > Expected {http://camel.apache.org/cxf/jaxws/dispatch}InvokeResponse.
> > at 
> > org.apache.cxf.interceptor.DocLiteralInInterceptor.validatePart(DocLiteralInInterceptor.java:259)
> > at 
> > org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:201)
> > at 
> > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
> > at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:802)
> > 
> > 
> > 
> > 
> > 
> > CXFWsdlOnlyPayloadModeNoSpringSoap12Test is failed due to server doesn't 
> > 
> > WARN PhaseInterceptorChain - Interceptor for 
> > {http://camel.apache.org/wsdl-first}PersonService12#{http://camel.apache.org/wsdl-first}GetPerson
> >  has thrown exception, unwinding now
> > org.apache.cxf.interceptor.Fault: The given SOAPAction GetPersonAction does 
> > not match an operation.
> > at 
> > org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor$SoapActionInAttemptTwoInterceptor.handleMessage(SoapActionInInterceptor.java:188)
> > at 
> > org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor$SoapActionInAttemptTwoInterceptor.handleMessage(SoapActionInInterceptor.java:162)
> > at 
> > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
> > at 
> > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:122)
> > at 
> > org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:348)
> > at 
> > org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:312)
> > at 
> > org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:72)
> > 
> > 
> > 
> > 
> > -- 
> > Willem Jiang
> > 
> > FuseSource
> > Web: http://www.fusesource.com (http://www.fusesource.com/)
> > Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
> > (English)
> > http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
> > Twitter: willemjiang 
> > Weibo: willemjiang
> > 
> > 
> > 
> > 
> > 
> > On Wednesday, August 15, 2012 at 9:20 AM, Daniel Kulp wrote:
> > 
> > > 
> > > We've resolved over 80 issues since 2.6.1 and we're a little overdue for 
> > > a release. 
> > > 

Re: [VOTE] Release Apache CXF 2.4.9/2.5.5/2.6.2

[Willem jiang]

Hi, 

I ran some tests in camel with CXF 2.6.2 and 2.5.5.
All the CXF related tests are passed with CXF 2.6.2 in the Camel trunk.

But I got some error when running the test with CXF 2.5.5 and Camel 2.9.x in  
camel-cxf module.
The test failures are

Failed tests: 
testDispatchPayload(org.apache.camel.component.cxf.CxfDispatchPayloadTest): The 
request should be handled sucessfully expected: but was:
Tests in error: 
testRoutes(org.apache.camel.component.cxf.CXFWsdlOnlyPayloadModeNoSpringSoap12Test):
 The given SOAPAction GetPersonAction does not match an operation.
testApplicationFault(org.apache.camel.component.cxf.CXFWsdlOnlyPayloadModeNoSpringSoap12Test):
 The given SOAPAction GetPersonAction does not match an operation.



When I changed the CXF version 2.5.4 all the tests passed, and these test are 
not change since Camel 2.9.0. So I bring these regression test out.

CxfDispatchPayloadTest is failed with on the client side with this error.

WARN PhaseInterceptor for 
{http://apache.org/hello_world_soap_http}GreeterService#{http://camel.apache.org/cxf/jaxws/dispatch}Invoke
 has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Unexpected element 
{http://apache.org/hello_world_soap_http/types}greetMeResponse found. Expected 
{http://camel.apache.org/cxf/jaxws/dispatch}InvokeResponse.
at 
org.apache.cxf.interceptor.DocLiteralInInterceptor.validatePart(DocLiteralInInterceptor.java:259)
at 
org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:201)
at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:802)





CXFWsdlOnlyPayloadModeNoSpringSoap12Test is failed due to server doesn't 

 WARN PhaseInterceptorChain - Interceptor for 
{http://camel.apache.org/wsdl-first}PersonService12#{http://camel.apache.org/wsdl-first}GetPerson
 has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: The given SOAPAction GetPersonAction does not 
match an operation.
at 
org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor$SoapActionInAttemptTwoInterceptor.handleMessage(SoapActionInInterceptor.java:188)
at 
org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor$SoapActionInAttemptTwoInterceptor.handleMessage(SoapActionInInterceptor.java:162)
at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
at 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:122)
at 
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:348)
at 
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:312)
at 
org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:72)




-- 
Willem Jiang

FuseSource
Web: http://www.fusesource.com (http://www.fusesource.com/)
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
  http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang 
Weibo: willemjiang





On Wednesday, August 15, 2012 at 9:20 AM, Daniel Kulp wrote:

> 
> We've resolved over 80 issues since 2.6.1 and we're a little overdue for a 
> release. 
> 
> List of issues:
> 2.4.9
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12321666
> 2.5.5
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12321667
> 2.6.2
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12321668
> 
> 
> The Maven staging areas are at:
> 2.4.9
> https://repository.apache.org/content/repositories/orgapachecxf-001/
> 2.5.5
> https://repository.apache.org/content/repositories/orgapachecxf-002/
> 2.6.2
> https://repository.apache.org/content/repositories/orgapachecxf-004/
> 
> 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.4.9
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.5
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.2
> 
> 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: more flexibility in configuring httpconduit's tlsClientParameters in spring or blueprint?

[Willem Jiang]

+1，it makes our life easier to share the security parameter beans 
across the http conduit.

On Thu Jul  5 19:09:57 2012, Sergey Beryozkin wrote:

Hi Aki,
On 05/07/12 11:58, Aki Yoshida wrote:

2012/7/5 Sergey Beryozkin:

Hi Aki

On 04/07/12 11:59, Aki Yoshida wrote:


Hi,
I haven been wondering about this for a while and I would like to hear
your thoughts.

Concretely, I am wondering if people are happy with the current file
or resource based keystore instantiation provided by the
tlsClientParameters's configuration schema. The current schema does
not allow any bean referencing from within that structure. So, using
the http's spring or blueprint namespace handlers that are based on
this schema, you need to configure this entire structure. This makes
it difficult to use this configuration handler If you have your own
mechanism to get keystores and you can provide it as a bean or
factory-bean reference.

In such cases, one could directly configure the httpConduit and its
tlsClientParameter as beans directly. Unfortunately, this doesn't work
in blueprint because the blueprint bean element does not have the name
attribute that can be used to configure the conduit's matching
pattern.  So, this is not practical. Besides, I think it's pain to
configure beans directly when the specific namespace handlers are
available.

So what are the options? Is this an unusual use case?  If this is not
an unusual use case, should we add the reference attribute in some of
those elements so that these can be optionally configured separately
and referenced?

Your comments are appreciated.



I've had a chance to deal with tlsClientParameters few days ago,
I've seen
the examples of the references like


Are you thinking of having something like

ref="mybean" ? I guess it makes sense, we'd probably need to have some
interface like KeyResourceStore introduced, sorry if I misunderstood




Hi Sergey,

yes. I was thinking about introducing an optional ref attribute in
some suitable places to do ref="mybean".
Here are some examples.

The current configuration looks like this:
  http://apache.org/hello_world}HelloWorld.http-conduit";>







   ...

Depending on where we allow this optional ref attribute, we could have
several variations in referencing.

For example, we could allow this attribute in the root level as in
  http://apache.org/hello_world}HelloWorld.http-conduit";>

...
In this case, you could configure this bean directly and setting each
of its bean attributes. This may not be very convenient, but it is
simple and does not require any schema changes to its sub components.

or we could allow the ref attribute in the key/trustManagers level,
as in
  http://apache.org/hello_world}HelloWorld.http-conduit";>



   ...

or in the keystore level:
  http://apache.org/hello_world}HelloWorld.http-conduit";>



   ...

I would like to hear if people want to have something like these.


IMHO both options look good, +1 from me

Thanks, Sergey



Thanks.

Regards, aki



Cheers, Sergey



Thanks.

Regards, Aki




--
Sergey Beryozkin

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

Blog: http://sberyozkin.blogspot.com








--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Re: svn commit: r1354452 - in /cxf/branches/2.4.x-fixes: ./ rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/ rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/utils/

[Willem Jiang]

I just committed a quick fix for it.
Sergey, if you have time, please double check it.


On Wed Jul  4 08:44:12 2012, Freeman Fang wrote:

Hi Sergey,

This commit break some jaxrs tests in 2.5.x branch, they're

org.apache.cxf.jaxrs.utils.InjectionUtilsTest.testHandleParameterWithXmlAdapterOnInterface


org.apache.cxf.jaxrs.ext.codegen.CodeGeneratorProviderTest.testBookStoreAsInterface


org.apache.cxf.jaxrs.ext.codegen.CodeGeneratorProviderTest.testBookStoreAsClass


org.apache.cxf.jaxrs.ext.codegen.CodeGeneratorProviderTest.testBookStoreTypesOnly


Those test failed since Project CXF-2.5.x #337[1] on CI and afterwards.

The reason for CodeGeneratorProviderTest failure is because there's
another extra "Books.class" in addition to the classes listed, as
CodeGeneratorProviderTest get removed from trunk and 2.6.x branches,
so I'm not sure CodeGeneratorProviderTest is still valid based on
current jaxrs code.

The InjectionUtilsTest failed because the code
Object id = InjectionUtils.handleParameter(value,
   true,
   Id.class,
   new Annotation[] {},
   ParameterType.PATH,
   createMessage());

now return id as a String.class, but not the expected Id.class.

Could you please take a look?


[1]https://builds.apache.org/job/CXF-2.5.x/337/#showFailuresLink

Thanks
Freeman

On 2012-6-27, at 下午7:58, serg...@apache.org wrote:


Author: sergeyb
Date: Wed Jun 27 11:58:32 2012
New Revision: 1354452

URL: http://svn.apache.org/viewvc?rev=1354452&view=rev
Log:
Merged revisions 1354451 via svnmerge from
https://svn.apache.org/repos/asf/cxf/branches/2.5.x-fixes


 r1354451 | sergeyb | 2012-06-27 12:55:57 +0100 (Wed, 27 Jun 2012) |
24 lines

 Merged revisions 1354447 via svnmerge from
 https://svn.apache.org/repos/asf/cxf/branches/2.6.x-fixes

 
   r1354447 | sergeyb | 2012-06-27 12:51:30 +0100 (Wed, 27 Jun 2012)
| 17 lines

   Merged revisions 1354441-1354442,1354446 via svnmerge from
   https://svn.apache.org/repos/asf/cxf/trunk

   
 r1354441 | sergeyb | 2012-06-27 12:44:38 +0100 (Wed, 27 Jun
2012) | 1 line

 [CXF-4396] Checking a port when 0.0.0.0 address gets replaced
   
 r1354442 | sergeyb | 2012-06-27 12:45:33 +0100 (Wed, 27 Jun
2012) | 1 line

 [CXF-4379] Passing corect type for adapters bound to interfaces
to be discoverd
   
 r1354446 | sergeyb | 2012-06-27 12:49:57 +0100 (Wed, 27 Jun
2012) | 1 line

 [CXF-4379] Minor optimization
   
 


Modified:
   cxf/branches/2.4.x-fixes/   (props changed)

cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java


cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/InjectionUtils.java


cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXBUtils.java


cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/utils/HttpUtilsTest.java


cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/utils/InjectionUtilsTest.java


Propchange: cxf/branches/2.4.x-fixes/
--

 Merged /cxf/branches/2.5.x-fixes:r1354451
 Merged /cxf/trunk:r1354441-1354446
 Merged /cxf/branches/2.6.x-fixes:r1354447

Propchange: cxf/branches/2.4.x-fixes/
--

Binary property 'svnmerge-integrated' - no diff available.

Modified:
cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java

URL:
http://svn.apache.org/viewvc/cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java?rev=1354452&r1=1354451&r2=1354452&view=diff

==

---
cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java
(original)
+++
cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java
Wed Jun 27 11:58:32 2012
@@ -200,7 +200,10 @@ public final class HttpUtils {
if (!absolute) {
u = URI.create(base + u.toString());
} else {
-u = URI.create(u.toString().replace(ANY_IP_ADDRESS,
serverAndPort));
+int originalPort = u.getPort();
+String replaceValue = originalPort == -1 ?
ANY_IP_ADDRESS
+: ANY_IP_ADDRESS + ":" + originalPort;
+u = URI.create(u.toString().replace(replaceValue,
serverAndPort));
}
}
return u;

Modified:
cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/Injectio

Re: Bus instance sharing among different ports ?

[Willem Jiang]

Hi,

You may consider to configure the feature on endpoints and then share 
the same bus across these endpoints.


On 7/4/12 11:40 PM, Ivan wrote:

Hi, from the design side, is it too heavy to create one bus instance for
each web service port ? If does, let's say, I have many serviceBeans, some
of them are required to enable ws-security, and some of them may require to
enable ws-addressing, it is possible to do that with the same bus instance
and does it mean that all those interceptors and policy builder will be
involved in the message processing ?

Thanks.




--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
 http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Re: [DISCUSSION] Adding the instance.id on the ObjectName

[Willem Jiang]

Let's take the ManagedEndpoint as an example.
If the user create two jaxws endpoint with same SEI like this.
http://localhost:9000/service1"; />

http://localhost:9000/service2"; />

It ends up with javax.management.InstanceAlreadyExistsException.
As CXF build up the ObjectName for the ManagedEndpoint with the same 
bus id, service name and endpoint name.


On Fri Jun 29 18:42:47 2012, Aki Yoshida wrote:

Hi Willem,
I am not sure exactly what you mean by this "instance.id".

Currently, if no id attribute is set, the bus.id is generated by the
bundle id plus cxf and a random number.
When the id attribute is set, it is used as the bus.id shown in JMX.

I am not sure how this "instance.id" is supposed to be used in your use case.

Could you give some examples?
Thanks.
regards, aki

2012/6/29 Willem Jiang :

Hi,

As you know CXF management provides a lots MBeans out of box. It works
perfect if it run as stand alone.
If we deploy the CXF endpoints into container like Apache Karaf, we may hit
the issue that Object is already registered. That is because we don't build
up unique Object name for JMX to use. And there could be more than one Bus
which id is CXF.

To resolve this issue I suggest we add the "instance.id" on the ObjectName.
As JMX supports to look up the object with a query string, I don't think
this change will effect much on the user CXF management codes.

Any thoughts?

--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
 http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang







--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

[DISCUSSION] Adding the instance.id on the ObjectName

[Willem Jiang]

Hi,

As you know CXF management provides a lots MBeans out of box. It works 
perfect if it run as stand alone.
If we deploy the CXF endpoints into container like Apache Karaf, we may 
hit the issue that Object is already registered. That is because we 
don't build up unique Object name for JMX to use. And there could be 
more than one Bus which id is CXF.


To resolve this issue I suggest we add the "instance.id" on the 
ObjectName. As JMX supports to look up the object with a query string, I 
don't think this change will effect much on the user CXF management codes.


Any thoughts?

--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
 http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Re: Discussion about using JMS transport with CXFRS

[Willem Jiang]

Hi Sergey,

I'm trying to create a WebClient instance by setting the address with 
jms uri to configure the endpoint jms address.
But now I have trouble to setup the message context of REQUEST_URI in 
WebClient as this uri is not jms uri which I used to create the 
WebClient.
How can I set REQUEST_URI without affect the ENDPOINT_ADDRESS by using 
WebClient API ?


If not, I'm going to update the WebClient API for it.

On Tue May 29 22:40:34 2012, Willem Jiang wrote:

On Tue May 29 22:33:59 2012, Sergey Beryozkin wrote:

Hi Willem
On 29/05/12 14:53, Willem Jiang wrote:

Hi,

I just have a chance to go through the missing feature of JMS transport
to support cxfrs frontend.

Current JMS transport doesn't send out Message.REQUEST_URI and
Message.HTTP_REQUEST_METHOD properties as the HTTP transport does.
So it hard for use the use the cxfrs frontend with JMS transport.

My question is do we need to transfer other properties which could be
used by cxfrs frondend?


The above properties are defaulted to "/" and "POST" respectively but
can be customized via JMS properties


Thanks, I will try to write some test tomorrow.




And The AbstractClient is tend to use HttpConnection to get the headers
for build the response, it stops the user to leverage other transports.
We may need to update this part of code.


+1. I did few changes to address
https://issues.apache.org/jira/browse/CXF-3562, but I will prioritize
on it after 2.6.1 is out. It is also needed for the future async
support, alternative HTTP stacks support, etc, so it's time to start
addressing it


sounds good.



Cheers, Sergey


Any thoughts?








--
Willem
--
CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang





--
Willem
--
CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Re: [VOTE] Apache CXF 2.3.11/2.4.8/2.5.4/2.6.1

[Willem Jiang]

+1

Willem

On 5/31/12 2:15 AM, Daniel Kulp wrote:



We've resolved over 90 issues since 2.6.0 was released. We've back ported
over 70 of them to 2.5.4 and 40 to 2.4.8 and 25 to 2.3.11.


List of issues:
2.3.11:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12320749
2.4.8:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12320748
2.5.4:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12320747
2.6.1:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12320746


The Maven staging areas are at:
2.3.12:
https://repository.apache.org/content/repositories/orgapachecxf-149/
2.4.8:
https://repository.apache.org/content/repositories/orgapachecxf-159/
2.5.4:
https://repository.apache.org/content/repositories/orgapachecxf-160/
2.6.1:
https://repository.apache.org/content/repositories/orgapachecxf-161/


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.3.11
http://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.8
http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.4
http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.1


This vote will be open for at least 72 hours.




--
Willem
--
CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
 http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Re: Delaying 2.6.1/2.5.4 due to test failures...

[Willem Jiang]

Hi ,

I just found I forgot to commit merge of r1343561 yesterday. And it was 
marked as integrated in CXF-2.4.x branch.
I will commit the patch after running some tests, It could be better if 
we redo the CXF 2.4.8 release again.


Sorry for the mass that I made.

Willem

On Wed May 30 06:02:54 2012, Sergey Beryozkin wrote:

Hi
On 29/05/12 21:52, Daniel Kulp wrote:

On Tuesday, May 29, 2012 09:49:36 PM Sergey Beryozkin wrote:

On 29/05/12 21:10, Daniel Kulp wrote:

We have a bunch of test failures in the rs-security stuff with Java 5:

https://builds.apache.org/view/A-F/view/CXF/job/CXF-Trunk-JDK15/
https://builds.apache.org/view/A-F/view/CXF/job/CXF-2.5.x/


which needs to get resolved before the release. Thus, I'm going to
delay this build until tomorrow. Colm and Sergey: can you look at
those please?

Looking into it now. I fear I've messed it up with my updates to the
client runtime...Though why on Java 5 only, not sure yet


Well, they fail on Java 7 as well. :-)


I believe I've got it fixed. The issue will be there in CXF 2.4.8 but
not in 2.4.9, I think it's very rare that the client code would
replace say Book.class with DOMSource class, so hopefully no CXF 2.4.8
users will ever see this problem and I think we will be able to offer
a workaround by setting the out message properties if really needed.

Sorry for a big mess,

Sergey


Dan




Sergey


I'm checking 2.4.x as well. I may have to redo that build.

Re: Discussion about using JMS transport with CXFRS

[Willem Jiang]

On Tue May 29 22:33:59 2012, Sergey Beryozkin wrote:

Hi Willem
On 29/05/12 14:53, Willem Jiang wrote:

Hi,

I just have a chance to go through the missing feature of JMS transport
to support cxfrs frontend.

Current JMS transport doesn't send out Message.REQUEST_URI and
Message.HTTP_REQUEST_METHOD properties as the HTTP transport does.
So it hard for use the use the cxfrs frontend with JMS transport.

My question is do we need to transfer other properties which could be
used by cxfrs frondend?


The above properties are defaulted to "/" and "POST" respectively but
can be customized via JMS properties


Thanks, I will try to write some test tomorrow.




And The AbstractClient is tend to use HttpConnection to get the headers
for build the response, it stops the user to leverage other transports.
We may need to update this part of code.


+1. I did few changes to address
https://issues.apache.org/jira/browse/CXF-3562, but I will prioritize
on it after 2.6.1 is out. It is also needed for the future async
support, alternative HTTP stacks support, etc, so it's time to start
addressing it


sounds good.



Cheers, Sergey


Any thoughts?








--
Willem
--
CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Discussion about using JMS transport with CXFRS

[Willem Jiang]

Hi,

I just have a chance to go through the missing feature of JMS transport 
to support cxfrs frontend.


Current JMS transport doesn't send out Message.REQUEST_URI and 
Message.HTTP_REQUEST_METHOD properties as the HTTP transport does.

So it hard for use the use the cxfrs frontend with JMS transport.

My question is do we need to transfer other properties which could be 
used by cxfrs frondend?


And The AbstractClient is tend to use HttpConnection to get the headers 
for build the response, it stops the user to leverage other transports. 
We may need to update this part of code.


Any thoughts?

--
Willem

Re: svn commit: r1343446

[Willem Jiang]

Hi Sergey,

JAXRSClientFactory provides the static method to create the proxy or the 
client. I didn't find a better way to apply the features to all these 
method by just changing a single method.


If you have a better idea, please share it with me.

BTW, I just found my commit introduced a stall over follow issue, I will 
commit a patch to fix the build right way.



On 5/29/12 5:00 PM, Sergey Beryozkin wrote:

Hi Willem

I'd really prefer us discussing updates like this one to the public
client API that the CXF JAX-RS runtime offers.

I can see you just added 5 or so new JAXRSClientFactory methods.
I consider most of them redundant. JAXRSClientFactory is a *utility*
factory and is already a bit overloaded without these new extra 5
methods added.

JAXRSClientFactoryBean is always there to offer a more custom approach
toward creating a proxy and I would like to revert most of the methods
you added.

I agree it may make sense to offer say a single utility method for
accepting the features, but I'd not like to have 5+ variations, the API
will become too 'noisy'. Besides the same would then need to be added to
WebClient factory methods...

I'll take care of updating the api

Thanks, Sergey


On 29/05/12 02:39, ningji...@apache.org wrote:

Author: ningjiang
Date: Tue May 29 01:39:02 2012
New Revision: 1343446

URL: http://svn.apache.org/viewvc?rev=1343446&view=rev
Log:
CXF-4345 Allow user-secified feautres for JAXRSClientFactory

Modified:
cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/client/JAXRSClientFactory.java


Modified:
cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/client/JAXRSClientFactory.java

URL:
http://svn.apache.org/viewvc/cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/client/JAXRSClientFactory.java?rev=1343446&r1=1343445&r2=1343446&view=diff

==

---
cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/client/JAXRSClientFactory.java
(original)
+++
cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/client/JAXRSClientFactory.java
Tue May 29 01:39:02 2012
@@ -26,6 +26,7 @@ import java.util.List;
import javax.ws.rs.core.MultivaluedMap;

import org.apache.cxf.common.util.ProxyHelper;
+import org.apache.cxf.feature.AbstractFeature;
import org.apache.cxf.jaxrs.model.UserResource;

/**
@@ -56,7 +57,20 @@ public final class JAXRSClientFactory {
* @return typed proxy
*/
public static T create(String baseAddress, Class cls,
ClassLoader loader) {
+
+ return create(baseAddress, cls, loader, null);
+ }
+
+ /**
+ * Creates a proxy using a custom class loader
+ * @param baseAddress baseAddress
+ * @param loader class loader
+ * @param cls resource class, if not interface then a CGLIB proxy
will be created
+ * @return typed proxy
+ */
+ public static T create(String baseAddress, Class cls,
ClassLoader loader, List features) {
JAXRSClientFactoryBean bean = getBean(baseAddress, cls, null);
+ bean.setFeatures(features);
bean.setClassLoader(loader);
return bean.create(cls);
}
@@ -80,18 +94,30 @@ public final class JAXRSClientFactory {
* @return typed proxy
*/
public static T create(URI baseURI, Class cls, boolean
inheritHeaders) {
-
+ return create(baseURI, cls, inheritHeaders, null);
+ }
+
+ /**
+ * Creates a proxy
+ * @param baseURI baseURI
+ * @param cls resource class, if not interface then a CGLIB proxy
will be created
+ * @param inheritHeaders if true then existing proxy headers will be
inherited by
+ * subresource proxies if any
+ * @param features, the features which will be applied to the client
+ * @return typed proxy
+ */
+ public static T create(URI baseURI, Class cls, boolean
inheritHeaders, List features) {
JAXRSClientFactoryBean bean = getBean(baseURI.toString(), cls, null);
bean.setInheritHeaders(inheritHeaders);
+ bean.setFeatures(features);
return bean.create(cls);
-
}

/**
* Creates a proxy
* @param baseAddress baseAddress
* @param cls resource class, if not interface then a CGLIB proxy will
be created
- * @param config classpath location of Spring configuration resource
+ * @param configLocation classpath location of Spring configuration
resource
* @return typed proxy
*/
public static T create(String baseAddress, Class cls, String
configLocation) {
@@ -103,9 +129,42 @@ public final class JAXRSClientFactory {
* Creates a proxy
* @param baseAddress baseAddress
* @param cls resource class, if not interface then a CGLIB proxy will
be created
+ * @param configLocation classpath location of Spring configuration
resource
+ * @param features, the features which will be applied to the client
+ * @return typed proxy
+ */
+ public static T create(String baseAddress, Class cls, String
configLocation,
+ List features) {
+ JAXRSClientFactoryBean bean = getBean(baseAddress, cls,
configLocation);
+ bean.setFeatures(features);
+ return bean.create(cls);
+ }
+
+ /**
+ * Creates a proxy
+ * @param baseAddress baseAddress
+ * @param cls resource class, if not interfac

Re: svn commit: r1340905 - in /cxf/trunk/rt/features/clustering: ./ src/main/java/org/apache/cxf/clustering/blueprint/ src/main/resources/META-INF/ src/main/resources/OSGI-INF/ src/main/resources/OSGI

[Willem Jiang]

+1 for it.
I think we also need to add the attribute of depends-on, it will help 
people to avoid some bean depends issue.


On 5/24/12 5:07 AM, Aki Yoshida wrote:

Regarding this ID type, I think it's time we move this type into the
cxf-beans schema because we now have three schemas (wsrm, http, and
cluster) locally defining this ID type.

The cxf-beans schema seems to be the right place. If there is no
objection, I can do the move and consolidate all these three schemas
to use that type.

2012/5/22 Willem Jiang:

Hi Dan,

Thanks for the hint, I just commit the new patch to get ride of blueprint
schema.


On Mon May 21 22:41:12 2012, Daniel Kulp wrote:




Willem,

Can we do this without having separate Blueprint and Spring schemas?
  Since
this is effectively a new schema for both, I'd hate to have 2 schemas when
one could do.


The configuration/wsrm-manager.xsd did something similar at one point and
ended up defining a very small "identifiedType" complexType to stick the
attributes that are required instead of pulling them from Spring or
Blueprint.

Also:  the blueprint xsd is invalid.   There is a missing closing element
and the Apache  header is missing.But if you get rid of it... problem
solved.  :-)

Thanks!

Dan




On Monday, May 21, 2012 07:00:00 AM ningji...@apache.org wrote:


Author: ningjiang
Date: Mon May 21 06:59:59 2012
New Revision: 1340905

URL: http://svn.apache.org/viewvc?rev=1340905&view=rev
Log:
CXF-4326 CXF-4327 add blueprint support on the cxf clustering

Added:

cxf/trunk/rt/features/clustering/src/main/java/org/apache/cxf/clustering/
blueprint/
cxf/trunk/rt/features/clustering/src/main/java/org/apache/cxf/clustering/
blueprint/ClusteringBPNamespaceHandler.java
cxf/trunk/rt/features/clustering/src/main/resources/META-INF/spring.schem
as cxf/trunk/rt/features/clustering/src/main/resources/OSGI-INF/
cxf/trunk/rt/features/clustering/src/main/resources/OSGI-INF/blueprint/
cxf/trunk/rt/features/clustering/src/main/resources/OSGI-INF/blueprint/cx
f-clustering.xml
cxf/trunk/rt/features/clustering/src/main/resources/schemas/
cxf/trunk/rt/features/clustering/src/main/resources/schemas/blueprint/
cxf/trunk/rt/features/clustering/src/main/resources/schemas/blueprint/clu
stering.xsd
cxf/trunk/rt/features/clustering/src/main/resources/schemas/clustering.xs
d Modified:
 cxf/trunk/rt/features/clustering/pom.xml

Modified: cxf/trunk/rt/features/clustering/pom.xml
URL:
http://svn.apache.org/viewvc/cxf/trunk/rt/features/clustering/pom.xml?rev
=1340905&r1=1340904&r2=1340905&view=diff
=
= --- cxf/trunk/rt/features/clustering/pom.xml (original)
+++ cxf/trunk/rt/features/clustering/pom.xml Mon May 21 06:59:59 2012
@@ -55,6 +55,12 @@
  ${project.version}
  
  
+org.apache.aries.blueprint
+org.apache.aries.blueprint.core
+provided
+true
+
+
  org.springframework
  spring-core
  provided

Added:
cxf/trunk/rt/features/clustering/src/main/java/org/apache/cxf/clustering/
blueprint/ClusteringBPNamespaceHandler.java URL:
http://svn.apache.org/viewvc/cxf/trunk/rt/features/clustering/src/main/ja

va/org/apache/cxf/clustering/blueprint/ClusteringBPNamespaceHandler.java?r
ev=1340905&view=auto
=
= ---
cxf/trunk/rt/features/clustering/src/main/java/org/apache/cxf/clustering/
blueprint/ClusteringBPNamespaceHandler.java (added) +++
cxf/trunk/rt/features/clustering/src/main/java/org/apache/cxf/clustering/
blueprint/ClusteringBPNamespaceHandler.java Mon May 21 06:59:59 2012 @@
-0,0 +1,59 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.cxf.clustering.blueprint;
+
+import java.net.URL;
+import java.util.Set;
+
+import org.w3c.dom.Element;
+import org.w3c.dom.Node;
+
+import org.apache.aries.blueprint.NamespaceHandler;
+import org.apache.aries.blueprint.ParserContext;
+import org.apache.cxf.clustering.FailoverFeature;
+import org.apache.cxf.clustering.LoadDistributorTargetSelector;
+import
org.apache.cxf.configuration.blueprint.SimpleBPBeanDefinitionParser;

Re: svn commit: r1329923 - /cxf/branches/2.5.x-fixes/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/ContextUtils.java

[Willem Jiang]

I tried to run full test on my box. JDK 1.6 with Maven 3.0.3.
I got the a check style error
cxf/branches/2.5.x-fixes/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/ContextUtils.java:492:33: 
Nested if-else depth is 4 (max allowed is 3).

Audit done.

I checked the CI it doesn't have this error report.  It looks like JDK 
1.5 doesn't show this kind of error.
I just committed a work around[1] before we decide to change the check 
style configuration file.


[1]http://svn.apache.org/viewvc?rev=1341332&view=rev

On Wed Apr 25 02:42:14 2012, dk...@apache.org wrote:

Author: dkulp
Date: Tue Apr 24 18:42:14 2012
New Revision: 1329923

URL: http://svn.apache.org/viewvc?rev=1329923&view=rev
Log:
Merged revisions 1328463 via  git cherry-pick from
https://svn.apache.org/repos/asf/cxf/trunk


   r1328463 | ay | 2012-04-20 13:49:09 -0400 (Fri, 20 Apr 2012) | 2 lines

   [CXF-4257] Should catch RejectedExecutionException in WS-Addr's 
rebaseResponse



Modified:
 
cxf/branches/2.5.x-fixes/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/ContextUtils.java

Modified: 
cxf/branches/2.5.x-fixes/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/ContextUtils.java
URL: 
http://svn.apache.org/viewvc/cxf/branches/2.5.x-fixes/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/ContextUtils.java?rev=1329923&r1=1329922&r2=1329923&view=diff
==
--- 
cxf/branches/2.5.x-fixes/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/ContextUtils.java
 (original)
+++ 
cxf/branches/2.5.x-fixes/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/ContextUtils.java
 Tue Apr 24 18:42:14 2012
@@ -26,6 +26,7 @@ import java.util.HashSet;
  import java.util.Set;
  import java.util.UUID;
  import java.util.concurrent.Executor;
+import java.util.concurrent.RejectedExecutionException;
  import java.util.logging.Level;
  import java.util.logging.Logger;

@@ -475,12 +476,26 @@ public final class ContextUtils {
  // pause dispatch on current thread ...
  inMessage.getInterceptorChain().pause();

-// ... and resume on executor thread
-getExecutor(inMessage).execute(new Runnable() {
-public void run() {
+
+try {
+// ... and resume on executor thread
+getExecutor(inMessage).execute(new Runnable() {
+public void run() {
+
inMessage.getInterceptorChain().resume();
+}
+});
+} catch (RejectedExecutionException e) {
+LOG.warning(
+"Executor queue is full, use the caller 
thread."
++ "  Users can specify a larger 
executor queue to avoid this.");
+// only block the thread if the prop is unset 
or set to false, otherwise let it go
+if (!MessageUtils.isTrue(
+inMessage.getContextualProperty(
+
"org.apache.cxf.oneway.rejected_execution_exception"))) {
+//the executor queue is full, so run the 
task in the caller thread
  inMessage.getInterceptorChain().resume();
  }
-});
+}
  }
  }
  }






--
Willem
--
CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
 http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Re: svn commit: r1340905 - in /cxf/trunk/rt/features/clustering: ./ src/main/java/org/apache/cxf/clustering/blueprint/ src/main/resources/META-INF/ src/main/resources/OSGI-INF/ src/main/resources/OSGI

[Willem Jiang]

Hi Dan,

Thanks for the hint, I just commit the new patch to get ride of 
blueprint schema.


On Mon May 21 22:41:12 2012, Daniel Kulp wrote:



Willem,

Can we do this without having separate Blueprint and Spring schemas?  Since
this is effectively a new schema for both, I'd hate to have 2 schemas when
one could do.


The configuration/wsrm-manager.xsd did something similar at one point and
ended up defining a very small "identifiedType" complexType to stick the
attributes that are required instead of pulling them from Spring or
Blueprint.

Also:  the blueprint xsd is invalid.   There is a missing closing element
and the Apache  header is missing.But if you get rid of it... problem
solved.  :-)

Thanks!

Dan




On Monday, May 21, 2012 07:00:00 AM ningji...@apache.org wrote:

Author: ningjiang
Date: Mon May 21 06:59:59 2012
New Revision: 1340905

URL: http://svn.apache.org/viewvc?rev=1340905&view=rev
Log:
CXF-4326 CXF-4327 add blueprint support on the cxf clustering

Added:

cxf/trunk/rt/features/clustering/src/main/java/org/apache/cxf/clustering/
blueprint/
cxf/trunk/rt/features/clustering/src/main/java/org/apache/cxf/clustering/
blueprint/ClusteringBPNamespaceHandler.java
cxf/trunk/rt/features/clustering/src/main/resources/META-INF/spring.schem
as cxf/trunk/rt/features/clustering/src/main/resources/OSGI-INF/
cxf/trunk/rt/features/clustering/src/main/resources/OSGI-INF/blueprint/
cxf/trunk/rt/features/clustering/src/main/resources/OSGI-INF/blueprint/cx
f-clustering.xml
cxf/trunk/rt/features/clustering/src/main/resources/schemas/
cxf/trunk/rt/features/clustering/src/main/resources/schemas/blueprint/
cxf/trunk/rt/features/clustering/src/main/resources/schemas/blueprint/clu
stering.xsd
cxf/trunk/rt/features/clustering/src/main/resources/schemas/clustering.xs
d Modified:
 cxf/trunk/rt/features/clustering/pom.xml

Modified: cxf/trunk/rt/features/clustering/pom.xml
URL:
http://svn.apache.org/viewvc/cxf/trunk/rt/features/clustering/pom.xml?rev
=1340905&r1=1340904&r2=1340905&view=diff
=
= --- cxf/trunk/rt/features/clustering/pom.xml (original)
+++ cxf/trunk/rt/features/clustering/pom.xml Mon May 21 06:59:59 2012
@@ -55,6 +55,12 @@
  ${project.version}
  
  
+org.apache.aries.blueprint
+org.apache.aries.blueprint.core
+provided
+true
+
+
  org.springframework
  spring-core
  provided

Added:
cxf/trunk/rt/features/clustering/src/main/java/org/apache/cxf/clustering/
blueprint/ClusteringBPNamespaceHandler.java URL:
http://svn.apache.org/viewvc/cxf/trunk/rt/features/clustering/src/main/ja
va/org/apache/cxf/clustering/blueprint/ClusteringBPNamespaceHandler.java?r
ev=1340905&view=auto
=
= ---
cxf/trunk/rt/features/clustering/src/main/java/org/apache/cxf/clustering/
blueprint/ClusteringBPNamespaceHandler.java (added) +++
cxf/trunk/rt/features/clustering/src/main/java/org/apache/cxf/clustering/
blueprint/ClusteringBPNamespaceHandler.java Mon May 21 06:59:59 2012 @@
-0,0 +1,59 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.cxf.clustering.blueprint;
+
+import java.net.URL;
+import java.util.Set;
+
+import org.w3c.dom.Element;
+import org.w3c.dom.Node;
+
+import org.apache.aries.blueprint.NamespaceHandler;
+import org.apache.aries.blueprint.ParserContext;
+import org.apache.cxf.clustering.FailoverFeature;
+import org.apache.cxf.clustering.LoadDistributorTargetSelector;
+import
org.apache.cxf.configuration.blueprint.SimpleBPBeanDefinitionParser;
+import org.osgi.service.blueprint.reflect.ComponentMetadata;
+import org.osgi.service.blueprint.reflect.Metadata;
+
+public class ClusteringBPNamespaceHandler implements NamespaceHandler {
+public ComponentMetadata decorate(Node node, ComponentMetadata
component, ParserContext context) { +return null;
+}
+
+public Metadata parse(Element element, ParserContext context) {
+String s = element.getLocalName();
+if ("failover".equals(s)) {
+return new
SimpleBPBeanDefinitionParser(FailoverFeature.class).parse(element,
context); +} e

Re: [DISCUSS] Drop 2.3.x patches....

[Willem Jiang]

It makes sense.
+1 for it.

On 4/25/12 2:30 AM, Daniel Kulp wrote:


Just wanted to open up a discussion about dropping support for 2.3.x.
2.3.0 was release over 18 months ago.  Since then, 2.4.x was released over a
year ago and 2.5.x  6 months ago. (and 2.6 last week).   Thus, there has
been plenty of opportunity (a whole year) for people to upgrade to newer
versions.

Right now, we have 4 branches we're supporting (2.6(trunk)/2.5/2.4/2.3) and
we're likely soon going to make a 2.6 branch and open up trunk for 2.7 work
adding yet another one.  Dropping 2.3 will simplify things a bit for us.

The major "con" to it is that there are still a lot of folks using 2.3.x.
According the Nexus stats of central, last month, 2.3.3 was still the second
most downloaded version. (next to 2.5.2)   However, if they are on 2.3.3
which was released over a year ago, they haven't been grabbing the latest
patches anyway so producing more patches won't really matter to them.

In any case, I'm think about doing one more 2.3.x release (2.3.11) which
would be announced as the end of the 2.3.x line.Obviously if any
security issues pop up we can push another release in the future, but
basically end the regular patch releases.

Any objections or other thoughts?




--
Willem
--
CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
 http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Re: Tomcat embedding

[Willem Jiang]

It could be more easy to leverage the servlet transport (which could be 
used across the web container)

instead of starting the engine inside the CXF.

On Tue Apr 24 08:44:13 2012, Benson Margulies wrote:

On Mon, Apr 23, 2012 at 8:09 PM, Glen Mazza  wrote:

Really?  AFAICT the code I linked to *is* using Tomcat, if perhaps not
directly in the manner that you're interested.
Glen


Really. Currently, when you just 'launch an endpoint', CXF launches
Jetty behind your back. I'd love to make it possible for CXF to do the
same with Tomcat; however, your scheme gets me the same end-user
benefits for a lot less effort than building a http_tomcat transport
next to the http_jetty transport.





Benson Margulies wrote


Glen,

This is very helpful if I want to cheap out of actually teaching CXF
to embed tomcat as it currently embeds Jetty:-)

On Mon, Apr 23, 2012 at 1:46 PM, Glen Mazza wrote:


Benson Margulies wrote


Last year, I took a look at tomcat as an alternative to Jetty for
embedding purposes.

I ran aground, I was just too ignorant.

Since I seem, again, to be hitting jetty bugs that close 'idle'
connections inappropriately, I've got myself interested again.

Is anyone who has a grip on server transports willing to help me out?



I had done an example with embedded Tomcat a while back, perhaps it might
help you:
http://www.jroller.com/gmazza/entry/junit_web_service_testing#testtc

Glen

--
View this message in context:
http://cxf.547215.n5.nabble.com/Tomcat-embedding-tp5659578p5660035.html
Sent from the cxf-dev mailing list archive at Nabble.com.





--
View this message in context: 
http://cxf.547215.n5.nabble.com/Tomcat-embedding-tp5659578p5660755.html
Sent from the cxf-dev mailing list archive at Nabble.com.






--
Willem
--
CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Re: [VOTE] Apache CXF BuildUtils and XJC-Utils

[Willem Jiang]

My +1.

Willem
On 3/31/12 12:11 AM, Daniel Kulp wrote:


In preparation for the CXF 2.6.0 release, we need to release a new version
of cxf-xjc that contains the updated plugins and runtime module.   Since we
need that, might as well release cxf-buildutils as well.

Only one minor change in cxf-buildutils:
*  Update the checkstyle line length from 110 to 120 chars as discussed a
couple months ago.


Changes in cxf-xjc
* Move DataTypeAdapter and ToString stuff from cxf-tools-common into new
cxf-xjc-runtime module that has very minimal dependencies (and is an osgi
bundle)
* Update "tostring" xjc plugin to use new cxf-xjc-runtime module classes.


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

Tags:
http://svn.apache.org/repos/asf/cxf/xjc-utils/tags/xjc-utils-2.6.0/
http://svn.apache.org/repos/asf/cxf/build-utils/tags/cxf-build-utils-2.4.1/


Here is my +1, vote open for at least 72 hours.

Re: Winding down 2.6.0

[Willem Jiang]

I think we could add more integration tests of OSGi to catch the new 
bundle bugs.

I'm willing to help that in the next few weeks :)

On Tue Mar 27 02:17:06 2012, Daniel Kulp wrote:


We're fast approaching 6 months since CXF 2.5.0 was released.   The
migration guide keeps getting longer and longer (requires scrolling down
now) which kind of shows we're getting enough 'stuff' to definitely warrant
a release.   Thus, I really think we should get the release out in a couple
weeks.

Last week, Glen, Sergey, and I went through every single CXF sample and made
sure they compiled and ran per the instructions in readme.   With over 40
samples, not a small undertaking.  :-)   We're also in the process of
checking all the extra examples that Talend has (and Glen has on his blog)
and getting things updated.   Part of the reason for all of this is to make
sure the release notes accurately describes any migration steps necessary,
but it also helps to ensure everything actually works, but examples still
make sense, etc...

In the next week or so, I plan to test more with Camel (there are some test
failures with 2.6.0, but they may be issues in the tests) and likely do a
bit more OSGi related testing.   The major change in 2.6.0 is the split of
the big bundle into the little bundles and updating the features.xml to use
the little bundles.Definitely want to test that as thoroughly  as
possible.  I also want to check the distribution and "big bundle" things to
make sure everything that is required is included.   We do have a bunch of
new jars so they may need updating to make sure everything is pulled in.
There are likely some JIRA's I may look at as well.

Anyway, I wanted to toss this out to get an idea of anything else folks may
have on their plates to get in soon.   If everyone could take a look at any
JIRA"s they have assigned to themselves and such and update things, that
would be great.





--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Re: svn commit: r1304181 - /cxf/trunk/api/src/main/java/org/apache/cxf/transport/TransportURIResolver.java

[Willem Jiang]

Hi Dan,
I did some test by using the .
It doesn't work and the created HttpConduit 's getBeanName return null.

I didn't see the   can do the trick.

On Fri Mar 23 19:38:09 2012, Daniel Kulp wrote:


Willem,

Not objecting to this, but wondering why it's necessary?   Such conduits
really should be configured based on URL, not some strange internal name or
similar.   Seriously, a conduit thing like:

  ...

would likely accomplish the exact same thing.

Dan


On Friday, March 23, 2012 04:01:19 AM ningji...@apache.org wrote:

Author: ningjiang
Date: Fri Mar 23 04:01:19 2012
New Revision: 1304181

URL: http://svn.apache.org/viewvc?rev=1304181&view=rev
Log:
CXF-4195 fixed the configuration issue of http conduit for WsdlUrl

Modified:

cxf/trunk/api/src/main/java/org/apache/cxf/transport/TransportURIResolver
.java

Modified:
cxf/trunk/api/src/main/java/org/apache/cxf/transport/TransportURIResolver
.java URL:
http://svn.apache.org/viewvc/cxf/trunk/api/src/main/java/org/apache/cxf/t
ransport/TransportURIResolver.java?rev=1304181&r1=1304180&r2=1304181&view=
diff
=
= ---
cxf/trunk/api/src/main/java/org/apache/cxf/transport/TransportURIResolver
.java (original) +++
cxf/trunk/api/src/main/java/org/apache/cxf/transport/TransportURIResolver
.java Fri Mar 23 04:01:19 2012 @@ -26,6 +26,8 @@ import
java.net.URISyntaxException;
  import java.util.HashSet;
  import java.util.Set;

+import javax.xml.namespace.QName;
+
  import org.xml.sax.InputSource;

  import org.apache.cxf.Bus;
@@ -101,6 +103,8 @@ public class TransportURIResolver extend
  }
  if (ci != null) {
  EndpointInfo info = new EndpointInfo();
+// set the endpointInfo name which could be used for
configuration +info.setName(new
QName("http://cxf.apache.org";, "TransportURIResolver"));
info.setAddress(base.toString());
  final Conduit c = ci.getConduit(info);
  Message message = new MessageImpl();




--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang 
Weibo: willemjiang 

Re: Issue in Virgo Deployment

[Willem Jiang]

Hi,

It looks some thing wrong on the server side which your client want to 
access.


Caused by: java.io.IOException: The https URL hostname does not match 
the

Common Name (CN) on the server certificate.  To disable this check (NOT
recommended for production) set the CXF client TLS configuration 
property

"disableCNCheck" to true.

Can you check if the server certificate Common Name is march to the 
Host Name ?



On Tue Mar 20 14:41:31 2012, rajesh babu wrote:

Hi All,

  I have application that will act as webservices client and i need to
submit to request to  my server which is having an "https" endpoint, my
http-conduit looks like ,





http://www.springframework.org/schema/beans";
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xmlns:sec="http://cxf.apache.org/configuration/security";
   xmlns:http="http://cxf.apache.org/transports/http/configuration";
   xmlns:jaxws="http://java.sun.com/xml/ns/jaxws";
   xmlns:ctx="http://www.springframework.org/schema/context";
   xmlns:camel="http://camel.apache.org/schema/spring";
   xmlns:camel-cxf="http://camel.apache.org/schema/cxf";
   xmlns:http-conf="http://cxf.apache.org/transports/http/configuration";
   xsi:schemaLocation="
http://cxf.apache.org/configuration/security
http://cxf.apache.org/schemas/configuration/security.xsd
http://cxf.apache.org/transports/http/configuration
http://cxf.apache.org/schemas/configuration/http-conf.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
 http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd
 http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd
 http://camel.apache.org/schema/osgi
http://camel.apache.org/schema/osgi/camel-osgi.xsd
 http://camel.apache.org/schema/cxf
http://camel.apache.org/schema/cxf/camel-cxf.xsd
 http://cxf.apache.org/configuration/security
http://cxf.apache.org/schemas/configuration/security.xsd";>




   
   





   

   
   
   
   
   
 
 .*_EXPORT_.*
 .*_EXPORT1024_.*
 .*_WITH_DES_.*
 NULL-SHA
 .*_WITH_NULL_.*
 .*_RSA_.*
 .*_NULL-SHA_.*
 .*_DH_anon_.*
   
   






But when i am trying to send a request i get the following error,

2012-03-19 23:34:09.043] INFO  l Thread 69 - MinaThreadPool System.out
: 15 03 01 00 12 AA
B4 0C   44 D5 99 BE 86 6C 3D 07  Dl=.
[2012-03-19 23:34:09.051] INFO  l Thread 69 - MinaThreadPool System.out
0010: 63 1B 8C 71 56 6C
8F   c..qVl.
[2012-03-19 23:34:09.052] INFO  l Thread 69 - MinaThreadPool System.out
%% Invalidated:
  [Session-13, SSL_RSA_WITH_RC4_128_MD5]
[2012-03-19 23:34:09.052] INFO  l Thread 69 - MinaThreadPool System.out
Camel Thread 69 -
MinaThreadPool, called close()
[2012-03-19 23:34:09.053] INFO  l Thread 69 - MinaThreadPool System.out
Camel Thread 69 -
MinaThreadPool, called closeInternal(true)
[2012-03-19 23:34:09.063] WARN  l Thread 69 - MinaThreadPool
org.apache.cxf.phase.PhaseInterceptorChain
  Interceptor for
{urn:ihe:iti:xds-b:2007}DocumentRepository_Service#{urn:ihe:iti:xds-b:2007}DocumentRepository_ProvideAndRegisterDocumentSet-b
has thrown exception, unwinding now org.apache.cxf.interceptor.Fault:
Marshalling Error: The https URL hostname does not match the Common Name
(CN) on the server certificate.  To disable this check (NOT recommended for
production) set the CXF client TLS configuration property "disableCNCheck"
to true.
at
org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java:252)
at org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:169)
at
org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writeParts(AbstractOutDatabindingInterceptor.java:111)
at
org.apache.cxf.interceptor.BareOutInterceptor.handleMessage(BareOutInterceptor.java:68)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:516)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
at $Proxy199.documentRepositoryProvideAndRegisterDocumentSetB(Unknown
Source)
at
org.openehealth.ipf.platform.camel.ihe.xds.iti41.component.Iti41Producer.callService(Iti41Producer.java:42)
at
org.openehealth.ipf.platform.camel.ihe.xds.iti

Re: svn commit: r1301549 - in /cxf/branches/2.5.x-fixes: ./ common/common/src/main/java/org/apache/cxf/common/logging/LogUtils.java

[Willem Jiang]

Sorry, I didn't realized the change has so many side effects.
I will revert the back port patches and find a better solutioni on the 
trunk.


On Fri Mar 16 22:48:26 2012, Daniel Kulp wrote:



I'm -1 for this change for 2 reasons:

1) This breaks existing logging configuration and thus cannot be pulled back
onto the other branches.   Users may already have j.u.l configs that would
no longer work.

2) Performance issues - the Slf4jLogger does a LOT more work than the j.u.l
loggers and thus we should only use this as a last resort, not the default
which this change pretty much entails.

Dan


On Friday, March 16, 2012 02:38:18 PM ningji...@apache.org wrote:

Author: ningjiang
Date: Fri Mar 16 14:38:18 2012
New Revision: 1301549

URL: http://svn.apache.org/viewvc?rev=1301549&view=rev
Log:
Merged revisions 1301539 via svnmerge from
https://svn.apache.org/repos/asf/cxf/trunk


   r1301539 | ningjiang | 2012-03-16 22:18:01 +0800 (Fri, 16 Mar 2012) | 1
line

   CXF-4180 LogUtils should default to CXF's Slf4jLogger if it can't find
Log4J or JCL driver 

Modified:
 cxf/branches/2.5.x-fixes/   (props changed)

cxf/branches/2.5.x-fixes/common/common/src/main/java/org/apache/cxf/commo
n/logging/LogUtils.java

Propchange: cxf/branches/2.5.x-fixes/
--
 svn:mergeinfo = /cxf/trunk:1301539

Propchange: cxf/branches/2.5.x-fixes/
--
 Binary property 'svnmerge-integrated' - no diff available.

Modified:
cxf/branches/2.5.x-fixes/common/common/src/main/java/org/apache/cxf/commo
n/logging/LogUtils.java URL:
http://svn.apache.org/viewvc/cxf/branches/2.5.x-fixes/common/common/src/m
ain/java/org/apache/cxf/common/logging/LogUtils.java?rev=1301549&r1=130154
8&r2=1301549&view=diff
=
= ---
cxf/branches/2.5.x-fixes/common/common/src/main/java/org/apache/cxf/commo
n/logging/LogUtils.java (original) +++
cxf/branches/2.5.x-fixes/common/common/src/main/java/org/apache/cxf/commo
n/logging/LogUtils.java Fri Mar 16 14:38:18 2012 @@ -97,17 +97,8 @@ public
final class LogUtils {
  }
  if (StringUtils.isEmpty(cname)) {
  Class.forName("org.slf4j.impl.StaticLoggerBinder");
-Class  cls = Class.forName("org.slf4j.LoggerFactory");
-Class  fcls =
cls.getMethod("getILoggerFactory").invoke(null).getClass(); -
if (fcls.getName().contains("Log4j")) {
-cname = "org.apache.cxf.common.logging.Log4jLogger";
-} else if (fcls.getName().contains("JCL")) {
-cls =
Class.forName("org.apache.commons.logging.LogFactory"); -
fcls = cls.getMethod("getFactory").invoke(null).getClass(); -
   if (fcls.getName().contains("Log4j")) {
-cname =
"org.apache.cxf.common.logging.Log4jLogger"; -}
-}
+// using the Slf4jLogger directly
+cname = "org.apache.cxf.common.logging.Slf4jLogger";
  }
  if (!StringUtils.isEmpty(cname)) {
  try {




--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang 
Weibo: willemjiang 

Question about wss4j feature

[Willem Jiang]

Hi,

As you know CXF 2.5.3-SNAPSHOT is moving to use WSS4j 1.6.5-SNAPSHOT
I'm trying to install the WSS4J feature of CXF-2.5.3-SNAPSHOT, and I get 
the complain about packages of xmlsec cannot be resolved.


I compared the META-INF of the WSS4J 1.6.5-SNAPSHOT and WSS4j 1.6.4 and 
found the imports package of xmlsec was changed from optional resolution 
to [1.5, 2).


Is there any reason to introduce these changes in WSS4J?
If it is necessary, we need to update the feature file to add the new 
version of xmlsec dependency accordingly.



Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
 http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Re: DoMerges updates....

[Willem Jiang]

Hi Dan,

It's a great news, with the help of git I don't have to wait merge 
command for minutes.


Cheers,

Willem

On 2/17/12 1:23 AM, Daniel Kulp wrote:


A couple of you have noticed a flurry of updates to my little DoMerges script
thingy.  I'm still tweaking it a bit, but it seems to be in a fairly usable
state now so I thought I'd mention the changes.

Major changes:

1) No longer requires (or even uses) svnmerge.py.  It now uses the svn
executable directly.  Thus, windows folks don't need python or any other wacky
things installed.   However, it records the blocks and merged things in the
exact same way as svnmerge.py so it's completely compatible.  You can use
DoMerges or svnmerge.py, flip back and forth, etc...

2) Now supports a git clone and uses "git cherry-pick" - this is the big one
for me.   You don't need to have a svn checkout for each branch and such.  If
you have a git clone with a branch tracking the appropriate apache branch,
DoMerges will now use git cherry-pick and git commit to handle the merging.
For the merges from trunk ->  2.6, this can help a LOT.  A lot of classes have
moved from module to module on 2.6.  svn merge does a crappy job handling
changes in files that have moved and generally just registers a conflict.
git cherry-pick works much better and generally merges the changes into the
old locations just fine.

HOWEVER, git svn doesn't support setting of svn properties.  (it can get
properties, but not set them).   Thus, to record the stuff that has been
merged, it needs to do a final svn checkout, set the properties, then a
commit.   (in another bizzare thing, you can do an "svn propedit" on an https
url and interactively edit a property in an editor, but you cannot "svn
propset" a url based thing.  Thus, the checkout is needed.)   Thus, using the
git stuff will involve an extra "recording" commit at the end.   However, this
really isn't any different than when Colm or someone does a manual git cherry-
pick and I record them later.

Anyway, the main thing for me was to try and make the merges from trunk/2.6 ->
2.5 as easy as possible.   A bunch of the bugs I've fixed lately are in
classes that have moved so having a quick and easy way to merge  those fixes
was important to me.   git helps with that.The removal of the dependency
on the python script is just an added benefit.   :-)

Re: [VOTE] Apache CXF 2.5.1/2.4.5/2.3.8

[Willem Jiang]

I tests these three version of CXF with camel-cxf 2.7.x, 2.8.x and 
2.9.x. Everything looks good.


Here is my +1.

Willem

On 12/16/11 4:37 AM, Daniel Kulp wrote:



We've resolved over 75 issues since 2.5.0 and thus is time for a release.
We've also ported back over 40 of the fixes to 2.4.5 and 30 of those to 2.3.8.

List of issues:
2.3.8:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12318348
2.4.5:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12318894
2.5.1:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=1231


The Maven staging areas are at:
2.3.8:
https://repository.apache.org/content/repositories/orgapachecxf-327/
2.4.5:
https://repository.apache.org/content/repositories/orgapachecxf-328/
2.5.1:
https://repository.apache.org/content/repositories/orgapachecxf-345/


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.3.8
http://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.5
http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.1


This vote will be open for at least 72 hours.

Re: One other fissile idea, the maven plugins

[Willem Jiang]

On Tue Dec 13 00:56:21 2011, Daniel Kulp wrote:

On Monday, December 12, 2011 11:41:34 AM Benson Margulies wrote:

I'll answer your question with a question.

Could the maven plugins be in the build last, so that they could have
the same sort of integration tests as all the maven plugins at Maven
and Mojo?


Well, no.   We need the plugins (well, at least the wsdl2java one) fairly
early as we use it to generate a LOT of code that the unit tests and system
tests use all over the place.   The only other option would be to use exec
plugin or something to call off to the wsdl2java command line stuff which
would really suck.


If so, I completely withdraw my idea. If not, I guess I
can't make a really good argument, and the tests could just live 'over
there' in systests as they do now.


Well, there is another option.   There is no reason why the systests for the
plugins need to be in /systest.  Feel free to create a /maven-plugins/systests
or something and move them there.   The services (like the sts) pretty much do
that now. That way, you can just go into /maven-plugins and run mvn there
and not run the full build and such.

I guess the question really is "what artifacts do you need from CXF to write
proper ittests for the plugin?"   Is it just the same things that are needed
to run the plugins or do you need more?   I'm certainly OK with requiring a
"mvn -Pfastinstall" prior to running the itests if that would get the
artifacts that are needed installed.


fastinstall is a handy way. That is how I found the wsdl2java maven 
plugin doesn't work by running the system test after that.








--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
 http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Re: thought on spring and blueprint configuration schemas

[Willem Jiang]

Hi Aki，

If you take a look at the camel-blueprint [1], you will find the schema 
is generated from JAXB annotated class and replace the target namespace 
with the blueprint one.


In this way we could reuse the module class as much as possible.

[1]https://svn.apache.org/repos/asf/camel/trunk/components/camel-blueprint/pom.xml

On Tue Dec  6 21:00:26 2011, Aki Yoshida wrote:

hi,
Is it allowed to merge the spring and blueprint versions of
configuration schemas and use the resulting schema for both cases?

If the answer is a definitive no, the rest of this mail can be
ignored. If the answer is yes or maybe, I would like to explain why I
am asking this question.

For the blueprint based configuration, we are using separate BP
specific XML schemas to refer to those BP specific attributes that are
relevant (e.g., for life-cycle management). As an example, a BP based
schema uses its base type Tcomponent while its spring version uses its
base type identifiedType. BP's Tcomponent has some additional
attributes relevant for BP. The BP's schema itself uses this
Tcomponent to define its various BP artifact types such as bean,
service, etc, while the spring's own schema similarly uses its
identifiedType to define its own spring artifact types.

My question is whether it is necessary to have two configuration
schema versions when we are defining our own configuration types.
Could we have a single compound schema that can accept both artifacts
that we can use to derive our configuration object types?

Having two versions of the configuration schema is the right thing to
clearly distinguish the difference of the two. For most components,
this does not introduce any significant overhead other than physically
having to maintain two almost identical schemas because their
configuration objects are not complex.

However, the situation is somewhat different for the ws-rm component.
The ws-rm component uses a few jaxb based complex configuration
objects and these complex jaxb types are currently defined in the
spring version of the ws-rm namespace. When I made ws-rm into
BP-ready, I didn't want to generate the identical jaxb types in
another namespace and at the same time I wanted to keep the ws-rm
configuration simple, I simply reused the spring version of the
namespace for BP. In other words, I created another schema (for BP
with the additional BP artifact attributes) using the same namespace
as in the spring one.

But this approach violates the convention of uniquely associating a
namespace to its schema definition. As such, this needs to be
corrected. And I have considered several options and I would like to
get your comments.

Hera are the 4 options considered for ws-rm:

Option 1
Define two elements (wsrm-mgr:rmManager and wsrm-mgr:jdbcStore) in the
new ws-rm BP namespace and keep the rest in the current ws-rm
namespace and import them into the new ws-rm BP schema.

Pro: straightforward implementation, no schema duplication for the
identical parts, no duplicated jaxb classes
Con: need two ws-rm namespaces for a BP based ws-rm configuration when
the above two elements are configured.


Option 2
Duplicate all the definitions in the new ws-rm BP namespace.

Pro: one namespace in the configuration
Con: schema and jaxb class duplicated, mapping of those jaxb objects
required (however, this could be avoided by not simply duplicating
each definition but making each definitions to be defined as an
extension of its counterpart).


Option 3
Declare only the elements in the new ws-rm BP namespace and keep the
types in the original schema. And set the substitutionGroup property
of each newly defined element to refer to its counterpart element in
the original schema.

Pro: one namespace in the configuration, no jaxb class duplicated, no
jaxb objects mapping required
Con: slightly more complex jaxb classes generated (as each
substitutable element is wrapped in JAXBElement to carry its xml
element information).


Option 4
Merge/collapse the spring and BP artifacts into one bag of attributes
and use one configuration schema for both spring and BP versions. Let
the configuration runtime (i.e., the namespace handlers) recognize the
relevant attributes.

Pro: one shared schema, one namespace, no jaxb class duplication,
straightforward implementation
Con: irrelevant attributes are allowed by the schema (however, these
irrelevant attributes can be checked by the corresponding namespace
handlers during the configuration time).


I am inclined towards option 4 for its simplicity. But I am not sure
if the this approach is somehow discouraged or prohibited. Concretely,
option 4 would derive a configuration type not from either
bp-beans:Tcomponent or s-beans:identifiedType, but from a type that
contains their merged artifact attribute groups and use this base type
for both cases. In that way, we would need one configuration schema to
maintain.

If this approach is disallowed, I am opting for option 1 for ws-rm.
Options 2 and 3 require an unnece

Re: [VOTE] Release Apache CXF 2.4.4-3rd try

[Willem Jiang]

+1

Willem

On 11/4/11 9:58 PM, Freeman Fang wrote:

Hi All,

We've resolved over 35 issues since 2.4.3 and thus is time for a release.
List of issues:
2.4.4:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12318347


The Maven staging areas are at:
2.4.4:
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 release is tagged at:
http://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.4


Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for at least 72 hours.

Best Regards
Freeman
-
Freeman Fang

FuseSource
Email:ff...@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com













--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
 http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Re: Multi destination service and XMPP transport

[Willem Jiang]

I'm afraid you have to use the use the TransportFactory to do such kind 
of job.


We always welcome the contributions, please fill a JIRA[1] and attache a 
patch for it.
BTW, you can share you code in the github once you replace  XMPP library 
to be Smack or others.


[1] https://issues.apache.org/jira/browse/CXF


Willem

On Fri Oct 28 16:31:27 2011, Mina R Waheeb wrote:

Hi CXF folks,

I use non-spring bus, I need to publish service to more than one
destination. I had found bean factory very expensive operation to do
for each transport available, is there any another way to create
message observer for my destination? maybe any docs to explain how
message observer installed on a destination?

Also, I have implement CXF XMPP transport I'd like to contribute to
the project. I'm using in house XMPP API but I think its easy to use
any another XMPP library maybe I could port it for openfire as
example? If anyone interested please tell me how can i share it.

Cheers,
Mina R. Waheeb




--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
 http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Re: [VOTE] Release Apache CXF 2.5.0

[Willem Jiang]

+1,

Willem

On 10/29/11 7:32 AM, Daniel Kulp wrote:


It's been over 6 month since 2.4.0 was released.  Since then, we've added
quite a bit of new functionality, new features, enhancements, etc...   Thus,
time for a release!


The maven staging area:
https://repository.apache.org/content/repositories/orgapachecxf-117/


This release is tagged at:
http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.0

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


Migration guide:
http://cxf.apache.org/docs/25-migration-guide.html


This vote will be open for at least 72 hours.

Re: svn commit: r1182802 - in /cxf/branches/2.4.x-fixes: ./ rt/core/src/main/java/org/apache/cxf/databinding/source/

[Willem Jiang]

Hi Glen,

Thanks for pointing that out, I already committed the fix for it.

On Tue Oct 18 00:57:39 2011, Glen Mazza wrote:

On 10/13/2011 08:30 AM, ningji...@apache.org wrote:

Author: ningjiang
Date: Thu Oct 13 12:30:45 2011
New Revision: 1182802

URL: http://svn.apache.org/viewvc?rev=1182802&view=rev
Log:
Merged revisions 1182754 via svnmerge from
https://svn.apache.org/repos/asf/cxf/trunk


r1182754 | ningjiang | 2011-10-13 18:08:19 +0800 (Thu, 13 Oct 2011) | 
1 line


CXF-3858 Added the cause exception class name into the fault message


Modified:
cxf/branches/2.4.x-fixes/ (props changed)
cxf/branches/2.4.x-fixes/rt/core/src/main/java/org/apache/cxf/databinding/source/Messages.properties 

cxf/branches/2.4.x-fixes/rt/core/src/main/java/org/apache/cxf/databinding/source/NodeDataReader.java 

cxf/branches/2.4.x-fixes/rt/core/src/main/java/org/apache/cxf/databinding/source/NodeDataWriter.java 

cxf/branches/2.4.x-fixes/rt/core/src/main/java/org/apache/cxf/databinding/source/XMLStreamDataReader.java 

cxf/branches/2.4.x-fixes/rt/core/src/main/java/org/apache/cxf/databinding/source/XMLStreamDataWriter.java 



Propchange: cxf/branches/2.4.x-fixes/
-- 


--- svn:mergeinfo (original)
+++ svn:mergeinfo Thu Oct 13 12:30:45 2011
@@ -1 +1 @@
-/cxf/trunk:1179846,1180649,1180653,1181611-1181612,1182637,1182715-1182717,1182752 

+/cxf/trunk:1179846,1180649,1180653,1181611-1181612,1182637,1182715-1182717,1182752,1182754 



Propchange: cxf/branches/2.4.x-fixes/
-- 


Binary property 'svnmerge-integrated' - no diff available.

Modified: 
cxf/branches/2.4.x-fixes/rt/core/src/main/java/org/apache/cxf/databinding/source/Messages.properties 

URL: 
http://svn.apache.org/viewvc/cxf/branches/2.4.x-fixes/rt/core/src/main/java/org/apache/cxf/databinding/source/Messages.properties?rev=1182802&r1=1182801&r2=1182802&view=diff 

== 

--- 
cxf/branches/2.4.x-fixes/rt/core/src/main/java/org/apache/cxf/databinding/source/Messages.properties 
(original)
+++ 
cxf/branches/2.4.x-fixes/rt/core/src/main/java/org/apache/cxf/databinding/source/Messages.properties 
Thu Oct 13 12:30:45 2011

@@ -20,5 +20,5 @@
#
COULD_NOT_READ_XML_STREAM = Could not parse the XML stream.
COULD_NOT_WRITE_XML_STREAM = Could not generate the XML stream.
-COULD_NOT_REDA_XML_STREAM_CAUSED_BY = Could not parse the XML stream 
caused by {0}.
-COULD_NOT_WRITE_XML_STREAM_CAUSED_BY = Could not generate the XML 
stream caused by {0}.
+COULD_NOT_REDA_XML_STREAM_CAUSED_BY = Could not parse the XML stream 
caused by: {0}: {1}.
+COULD_NOT_WRITE_XML_STREAM_CAUSED_BY = Could not generate the XML 
stream caused by: {0}: {1}.




Needs to be spelled "COULD_NOT_READ_..." :)

Glen


Modified: 
cxf/branches/2.4.x-fixes/rt/core/src/main/java/org/apache/cxf/databinding/source/NodeDataReader.java 

URL: 
http://svn.apache.org/viewvc/cxf/branches/2.4.x-fixes/rt/core/src/main/java/org/apache/cxf/databinding/source/NodeDataReader.java?rev=1182802&r1=1182801&r2=1182802&view=diff 

== 

--- 
cxf/branches/2.4.x-fixes/rt/core/src/main/java/org/apache/cxf/databinding/source/NodeDataReader.java 
(original)
+++ 
cxf/branches/2.4.x-fixes/rt/core/src/main/java/org/apache/cxf/databinding/source/NodeDataReader.java 
Thu Oct 13 12:30:45 2011

@@ -66,7 +66,8 @@ public class NodeDataReader implements D
} catch (IOException e) {
throw new Fault("COULD_NOT_READ_XML_STREAM", LOG, e);
} catch (TransformerException e) {
- throw new Fault("COULD_NOT_REDA_XML_STREAM_CAUSED_BY", LOG, e, 
e.getMessage());

+ throw new Fault("COULD_NOT_REDA_XML_STREAM_CAUSED_BY", LOG, e,
+ e.getClass().getCanonicalName(), e.getMessage());
}
}
return read(input);



Modified: 
cxf/branches/2.4.x-fixes/rt/core/src/main/java/org/apache/cxf/databinding/source/XMLStreamDataReader.java 

URL: 
http://svn.apache.org/viewvc/cxf/branches/2.4.x-fixes/rt/core/src/main/java/org/apache/cxf/databinding/source/XMLStreamDataReader.java?rev=1182802&r1=1182801&r2=1182802&view=diff 

== 

--- 
cxf/branches/2.4.x-fixes/rt/core/src/main/java/org/apache/cxf/databinding/source/XMLStreamDataReader.java 
(original)
+++ 
cxf/branches/2.4.x-fixes/rt/core/src/main/java/org/apache/cxf/databinding/source/XMLStreamDataReader.java 
Thu Oct 13 12:30:45 2011

@@ -139,9 +139,11 @@ public class XMLStreamDataReader impleme
} catch (IOException e) {
throw new Fault("COULD_NOT_READ_XML_STREAM", LOG, e);
} catch (XMLStreamException e) {
- throw new Fault("COULD_NOT_REDA_XML_STREAM_CAUSED_BY", LOG, e, 
e.getMessage());

+ throw new Fault("COULD_NOT_REDA_XML_STREAM_CAUSED_BY", LOG, e,
+ e.getClass().getCanonicalName(), e.getMessage());
} catch (SAXException e) {
- throw new Fau

Re: Async http requests and workqueue....

[Willem Jiang]

Hi Dan,

I think the first option is OK, and it can let the user know what's 
wrong immediately.
The other two option will be confused to the user if he just see the 
error and the call is succeed.


On Thu Oct  6 09:31:30 2011, Daniel Kulp wrote:


I have a question for folks to see what folks would think is the "best
option".Basically, if you use one of the JAX-WS async methods on a client
when talking to an HTTP service, we have to put a runnable on the workqueue to
handle the response.   The question is, what should we do if the workqueue is
full?  Could options:

1) (current behavior) Throw the RejectedExecutionException so the user knows
they are exceeding defaults and likely should reconfigure things.

2) Loop in a Thread.yield and retry putting it on the queue until successfull.

3) Run the runnable synchronously on the calling thread.

Likely 2 and 3 would both log a WARNING to let the user know to reconfigure.


Obviously, the best solution would be to finish the work I did to use the
apache http-client instead of the HttpURLConnection, but lets not go there
right now.  :-)

Anyway, thoughts?






--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang 
Weibo: willemjiang 

Re: JettyHTTPServerEngine changes (r1177165 - in /cxf/branches/2.4.x-fixes...)

[Willem Jiang]

On Fri Sep 30 05:39:54 2011, Glen Mazza wrote:

Hi Willem:

On 09/29/2011 01:05 AM, ningji...@apache.org wrote:

Author: ningjiang
Date: Thu Sep 29 05:05:18 2011
New Revision: 1177165

Propchange: cxf/branches/2.4.x-fixes/
-- 


Binary property 'svnmerge-integrated' - no diff available.

Modified: 
cxf/branches/2.4.x-fixes/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/JettyHTTPServerEngine.java 

URL: 
http://svn.apache.org/viewvc/cxf/branches/2.4.x-fixes/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/JettyHTTPServerEngine.java?rev=1177165&r1=1177164&r2=1177165&view=diff 

== 

--- 
cxf/branches/2.4.x-fixes/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/JettyHTTPServerEngine.java 
(original)
+++ 
cxf/branches/2.4.x-fixes/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/JettyHTTPServerEngine.java 
Thu Sep 29 05:05:18 2011

@@ -95,6 +95,7 @@ public class JettyHTTPServerEngine
private Boolean isSessionSupport = false;
private Boolean isReuseAddress = true;
private Boolean continuationsEnabled = true;
+ private int maxIdleTime = 20;
private int servantCount;
private Server server;
private Connector connector;
@@ -281,6 +282,14 @@ public class JettyHTTPServerEngine
isReuseAddress = reuse;
}
+
+ public void setMaxIdleTime(int maxIdel) {
+ maxIdleTime = maxIdel;
+ }


(int maxIdle)



/**

Modified: 
cxf/branches/2.4.x-fixes/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/spring/JettyHTTPServerEngineBeanDefinitionParser.java 

URL: 
http://svn.apache.org/viewvc/cxf/branches/2.4.x-fixes/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/spring/JettyHTTPServerEngineBeanDefinitionParser.java?rev=1177165&r1=1177164&r2=1177165&view=diff 

== 

--- 
cxf/branches/2.4.x-fixes/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/spring/JettyHTTPServerEngineBeanDefinitionParser.java 
(original)
+++ 
cxf/branches/2.4.x-fixes/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/spring/JettyHTTPServerEngineBeanDefinitionParser.java 
Thu Sep 29 05:05:18 2011

@@ -70,6 +70,11 @@ public class JettyHTTPServerEngineBeanDe
if (continuationsStr != null&& continuationsStr.length()> 0) {
bean.addPropertyValue("continuationsEnabled", continuationsStr);
}
+
+ String maxIdleTimeStr = element.getAttribute("maxIdleTime");
+ if (maxIdleTimeStr != null&& !"".equals(maxIdleTimeStr.trim())) {
+ bean.addPropertyValue("maxIdleTime", maxIdleTimeStr);
+ }
ValueHolder busValue = ctx.getContainingBeanDefinition()
.getConstructorArgumentValues().getArgumentValue(0, Bus.class);
bean.addPropertyValue("bus", busValue.getValue());


Modified: 
cxf/branches/2.4.x-fixes/rt/transports/http-jetty/src/main/resources/schemas/configuration/http-jetty.xsd 

URL: 
http://svn.apache.org/viewvc/cxf/branches/2.4.x-fixes/rt/transports/http-jetty/src/main/resources/schemas/configuration/http-jetty.xsd?rev=1177165&r1=1177164&r2=1177165&view=diff 

== 

--- 
cxf/branches/2.4.x-fixes/rt/transports/http-jetty/src/main/resources/schemas/configuration/http-jetty.xsd 
(original)
+++ 
cxf/branches/2.4.x-fixes/rt/transports/http-jetty/src/main/resources/schemas/configuration/http-jetty.xsd 
Thu Sep 29 05:05:18 2011

@@ -144,9 +144,14 @@
type="ptp:ParameterizedBoolean">


Specifies if Jetty Continuations will be explicitly 
supported
- by Jetty destinations. Continuations will be checked if this 
attribute is set to true or omitted, ignored 
otherwise
+ by Jetty destinations. Continuations will be checked if this 
attribute is set to true or omitted, ignored 
otherwise.



+
+
+Set the maximum Idle time for a connection, the 
timer will be reset if there is any read and write option on the 
under layer stream.


I'm not sure what you mean here by "option" and "under layer 
(underlying?) stream"--although it could be my lack of knowledge on 
the topic.


After read the sentence twice, I think the option should be action, 
which means if there is no any data is received or sent, the stream 
will be closed.



Regards,
Glen








--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang 
Weibo: willemjiang 

Re: HttpConduit "name" - Ability required to inject a property for the http:conduit name attribute

[Willem Jiang]

Spring supports the alias name, if you specify the bean id attribute and 
name attribute at the same time, the name value can be the bean's  alias 
name.
I just did some simple test[1] on the CXF core, it show that CXF support 
it out of box.


Please make sure you configure bean as id attribute and name attribute 
at the same time.


[1]http://svn.apache.org/viewvc?rev=1177193&view=rev

On Wed Sep 28 18:31:05 2011, natty wrote:

Hi,

I am also facing the same issue. I too looking for a solution not to hard
code the "name" element of HTTP Conduit.

have you found out the solution for this? if yes, please share with me..!

Thanks,
Natarajan

--
View this message in context: 
http://cxf.547215.n5.nabble.com/HttpConduit-name-Ability-required-to-inject-a-property-for-the-http-conduit-name-attribute-tp4641515p4848664.html
Sent from the cxf-issues mailing list archive at Nabble.com.





--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
 http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
 http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Re: [DISCUSS] Move some modules around

[Willem Jiang]

+1 for the change.
There are some OSGi tests which are based on pax-exam in 
camel/trunk/tests/camel-itest-osgi can be took as an example.


On 9/28/11 3:45 AM, Daniel Kulp wrote:


I'd like to move some modules around in the src tree.   Basically, we've been
hanging some stuff off of modules in distribution that really are no longer
tied completely to the distribution.  In particular, a lot of the stuff in
there is actually more important for OSGi than for the actual CXF
distribution.The karaf stuff, for example, really has nothing to do with
the distribution at all.

I'd like to create a top level /osgi directory.   In there, we'd move the
distribution/karaf and distribution/bundles directories.   Eventually, we
could create an "/osgi/tests" or something that could include specific OSGi
related tests. (pax-exam based maybe?)I don't think the artifact/group
id's of anything needs to change.  Just the parent location entries in the
poms.

Is everyone OK with that?  Does it make sense?




--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
 http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Re: [jira] [Commented] (CXF-3508) Local Transport Factory and HTTP Transport Factory not compatible in cxf-2.4.0 was working in cxf-2.3.3

[Willem Jiang]

Hi monish,

It looks like you doesn't include the cxf.xml, which is important for 
the local transport to share the same bus with who generates the 
service list.





On Mon Sep 26 01:09:50 2011, cogitate wrote:

hi willem :
  it seems when i try to bring up a local service with the same configuration
i get a service listing :
"No services have been found."

  



  

   http://cxf.547215.n5.nabble.com/jira-Created-CXF-3508-Local-Transport-Factory-and-HTTP-Transport-Factory-not-compatible-in-cxf-2-4-03-tp4386588p4838868.html
Sent from the cxf-issues mailing list archive at Nabble.com.





--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang 
Weibo: willemjiang 

Re: mvn install on latest

[Willem Jiang]

What's your JDK version and Maven version ?
Using the mvn -v can tell us lots of useful information :)


On Fri Sep 23 09:00:02 2011, Amish Gandhi wrote:

Hi All,
I have commented the failed tests locally (once I get my first build going I
can uncomment it).

But I am still getting failures on eclipse and mvn install.

The build is passing on Jenkins, so I think its something to do with my
setup. Any ideas?

testEncryptedSignedPartsWithCompleteCoverage(org.apache.cxf.ws.security.wss4j.PolicyBasedWss4JInOutTest)
Time elapsed: 0.072 sec<<<  ERROR!
java.lang.Error: Unresolved compilation problem:
 The method setSymmetricEncAlgorithm(String) is undefined for the type
WSSecEncryptedKey

 at
org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.getEncryptedKeyBuilder(AbstractBindingBuilder.java:1250)
 at
org.apache.cxf.ws.security.wss4j.policyhandlers.SymmetricBindingHandler.setupEncryptedKey(SymmetricBindingHandler.java:789)
 at
org.apache.cxf.ws.security.wss4j.policyhandlers.SymmetricBindingHandler.doEncryptBeforeSign(SymmetricBindingHandler.java:163)
 at
org.apache.cxf.ws.security.wss4j.policyhandlers.SymmetricBindingHandler.handleBinding(SymmetricBindingHandler.java:116)
 at
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:162)
 at
org.apache.cxf.ws.security.wss4j.AbstractPolicySecurityTest.runOutInterceptorAndValidate(AbstractPolicySecurityTest.java:276)
 at
org.apache.cxf.ws.security.wss4j.AbstractPolicySecurityTest.runOutInterceptorAndValidate(AbstractPolicySecurityTest.java:266)
 at
org.apache.cxf.ws.security.wss4j.AbstractPolicySecurityTest.runAndValidate(AbstractPolicySecurityTest.java:124)
 at
org.apache.cxf.ws.security.wss4j.AbstractPolicySecurityTest.runAndValidate(AbstractPolicySecurityTest.java:94)
 at
org.apache.cxf.ws.security.wss4j.PolicyBasedWss4JInOutTest.testEncryptedSignedPartsWithCompleteCoverage(PolicyBasedWss4JInOutTest.java:440)
 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
 at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
 at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
 at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
 at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
 at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
 at
org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
 at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
 at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
 at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
 at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
 at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
 at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
 at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
 at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
 at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
 at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
 at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
 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.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
 at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
 at
org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:172)
 at
org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:104)
 at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70)
Running org.apache.cxf.ws.security.wss4j.RoundTripTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.547 sec
Running org.apache.cxf.ws.security.wss4j.SignatureConfirmationTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.057 sec
Running org.apache.cxf.ws.security.wss4j.UserNameTokenAuthorizationT

Re: Remove the CXF MTOSI examples?

[Willem Jiang]

I don't think we have much user for MTOSI :)
+1 to exclude it from the kit release.

BTW, we need to update the release note for it if we decide to do it.

On 9/22/11 12:26 AM, Glen Mazza wrote:

Hi Team, we have two MTOSI examples in the CXF samples list -- they're rather
old (presently not Mavenized).  MTOSI seems to be largely inactive, with the
last blog post on it 17 months ago and no real analysis since mid-2009.
Should we nuke them (2.4 and Trunk branches)?  If we're down to just 1 in a
1000 possibly interested in it, rather than maintain it along with the rest
of the samples I'd rather we just refer them to the SVN repository.

Here's the Wikipedia article on it: http://en.wikipedia.org/wiki/MTOSI
(also not meaningfully edited since July 2009.)

Thanks,
Glen


--
View this message in context: 
http://cxf.547215.n5.nabble.com/Remove-the-CXF-MTOSI-examples-tp4826982p4826982.html
Sent from the cxf-dev mailing list archive at Nabble.com.




--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
 http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang