cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: My outstanding CXF issues and their feasibility.
Date Wed, 31 Aug 2011 18:55:32 GMT
On Wednesday, August 31, 2011 1:52:21 PM Robert Liguori wrote:
> I've just spent some time closing out a bunch of my Apache issues that
> were not feasible.  In regards to my CXF issues I've opened, most of
> them have already been fixed and implemented by the Apache Team...
> thanks!  However I do have a few left over that I'm trying to bring
> closure to...
> If anyone has time and would like to pass through them quickly, that
> would be cool.  What I'm most interested in, is closing out any of the
> issues that don't make any logical sense to pursue.
> Here they are, thanks!  An e-mail response, an update to the JIRA
> ticket, or a response to this mailing list would be cool! Thanks again!
> ========================
> ========================
> CXF-3739
> Implement XStream Databinding

Honestly, I have no experience with XStream.  A quick look at website and some 
google searches seems to indicate that this may not be feasible.  One 
"requirement" we have for the databinding is the ability to generate an XSD 
for the objects so that we can generate a proper WSDL and/or WADL.   While 
XStream has the API's for streaming the data (good), I don't see anything for 
generating schema (bad).      I could have missed it though.   May require 
some more research.   If there is ability to generate xsd, then sure, it's 

> CXF-3140
> WSDL Validator: Validate against Attachments Profile 1.0

This is definitely doable.   SwA isn't used much anymore though (generally 
preferring MTOM) and thus a low priority for *ME*, but someone else might 
think otherwise.   That said, anything we do to make sure people have valid 
wsdl is always a good thing.

> CXF-3053
> Add generation support of http:binding for the java2ws tool from -http
> argument

I would say this could be closed as "won't fix".  We don't even really support 
the http binding in the runtime so generating it would be irrelevant unless 
you also want to go through all the effort to get it fully supported, which I 
don't see the need for either.

> ============
> ============
> CXF-3055
> Adding -version, -V and -Q switches to all command line tools
> CXF-3125
> Add -validate option to the following utilities: wsdl2xml, wsdl2soap,
> wsdl2service and wsdl2corba.
> CXF-3245
> Adding command line options where appropriate

Sure for all.  Consistency is good.

> CXF-3323
> Update "description" elements in all CXF POM files.


> ===========
> ===========
> CXF-3276
> "Building Apache CXF HTTP Transport for OSGi 2.3.2" - build warnings
> CXF-3086
> "Warning building bundle" message in CXF 2.3 build

I would close these as fixed in "2.4" since the OSGi http transport was 
removed in 2.4.   :-)

> CXF-3779
> Minor WSDL errors in some of the sample projects
> CXF-3690
> Refactor packaging for uniformity across examples.
> CXF-3054
> wsdl12js.bat doesn't immediately exit after return result from version
> query

Yep.  Bugs that should be fixed.

> CXF-3084
> Building Apache CXF Runtime JavaScript Client Generator: SEVERE: send
> state != OPENED.
Would need to check the test.   It could be testing if it cannot send 
something.  In that case, the should be updated to block 
it.   But yes, should be fixed.

> =============
> =============
> CXF-3737
> Comments reference incorrect tool names in several files.
> CXF-3686
> Adjust sample project method calls that should be accessed in a static
> manner.

On my todo list eventually, but the Diff format is relatively non-standard and 
thus not directly apply able on Linux.   Makes applying them very hard and 
time consuming which I just haven't had the patience to deal with lately.    
If you can recreate the diffs using normal svn or git, that may help.   I'm 
not really sure.

Daniel Kulp
Talend -

View raw message