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. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
