cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Liguori <...@gliesian.com>
Subject Re: My outstanding CXF issues and their feasibility.
Date Wed, 31 Aug 2011 19:40:02 GMT
Thanks!  I've updated the necessary issues accordingly.

-- Robert

On Wed, 31 Aug 2011 14:55:32 -0400, Daniel Kulp <dkulp@apache.org>
wrote:
> 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!
>>
>> ========================
>> FEASIBILITY QUESTIONABLE
>> ========================
>>
>> 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 
> feasible.  
> 
> 
>> 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.
> 
>> ============
>> ENHANCEMENTS
>> ============
>>
>> 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.
> 
> Sure.   
> 
> 
> 
>> ===========
>> NEEDS A FIX
>> ===========
>>
>> 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 logging.properties should be updated to block 
> it.   But yes, should be fixed.
> 
>  
>> =============
>> DIFF IS READY
>> =============
>>
>> 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.

-- 
Sincerely,
Robert J. Liguori
STG Technologies, Inc.

Mime
View raw message