Thanks! I've updated the necessary issues accordingly. -- Robert
On Wed, 31 Aug 2011 14:55:32 -0400, Daniel Kulp <dk...@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.
