Yep. Sounds like some CXF bugs... The place to look is in:
common/common/src/main/java/org/apache/cxf/jaxb/JAXBUtils.java Specifically the method: public static String nameSpaceURIToPackage(URI uri) I would definitely start there. Dan On Monday 26 July 2010 8:59:24 pm Glen Mazza wrote: > Daniel Kulp wrote: > >> Metro wsimport places all classes in the "rosette" folder, so we either > >> have a CXF bug in using "rosette_analysis" or a JAXB and Metro wsimport > >> bug in using "rosette". > > > > I would say Metro/JAXB bug in using rosette and dropping the ".analysis" > > part. > > I'm looking at the algorithm of Appendix D in the JAXB spec and really > > don't > > see anywhere where it would drop that. > > I think all three have a bug, actually. A dot is a valid character in the > "NSS" as defined here: [1] > > From JAXB 2.2 (8 Jan 2009), section D.5.1 (and also JAXB 2.0 of 2006): > > 2. Remove the trailing file type, one of .?? or .??? or .html. > The spec is defining a "file type" to mean .?? or .??? or .html, anything > else is not a file type. (It is similar to Step #1, which defines the URI > schemes to be removed to be only "http" or "urn", even though more could be > considered uri schemes.) > > //www.acme.com/go/espeak.xsd ==> //www.acme.com/go/espeak > > Metro and JAXB are always treating everything after the dot as a file > extension and wrongfully removing it: > .xml -> removed (good) > .pumpkin -> removed (bad) > > CXF is *never* removing the trailing file type : > .pumpkin -> not removed (good) > .xsd -> not removed (bad) > .html -> not removed (bad) > > I think CXF has another bug: > given uri of "https:basistech.com:rosette.analysis" > > Metro/JAXB treats https as part of the package (good): > https.basistech_com.rosette > > CXF returns this error: > [INFO] org.apache.cxf.tools.common.ToolException: : is not a valid char in > the targetNamespace > > So I think we have a JIRA ticket also for CXF. (What class handles this?) > > Glen > > [1] http://xml.resource.org/public/rfc/html/rfc2141.html#anchor4 -- Daniel Kulp [email protected] http://dankulp.com/blog
