+1 to all of this.... (although it's <scope>test</scope>) Having an axis/axiom dependency on the "test" phase is possibly OK (although not ideal). Making the actual runtime depend on it is not OK.
Just FYI, the JAXB 2.0 marshaller/unmarshaller has methods for the XMLStream* and XMLEvent* and such as well as those for InputSource, URL, InputStream, Source, etc.... I'm not sure if you care (since SDO is not JAXB), but I thought I'd mention it. Enjoy! Dan On Monday 20 March 2006 12:59, Jeremy Boynes (JIRA) wrote: > [ > http://issues.apache.org/jira/browse/TUSCANY-118?page=comments#action_1 >2371116 ] > > Jeremy Boynes commented on TUSCANY-118: > --------------------------------------- > > I assume having the SDO API depend on the StAX API would not be a > problem? There should perhaps in a "StaxHelper" interface that would > mean that the dependency was only triggered by people using StAX. > > Our SDO implementation should depend only on having an implementation > of StAX available. Perhaps having the user pass the > XMLStreamReader/XMLStreamWriter in the API would be sufficient. I think > this is better than having a load(URL) type method that requires the > implementation discover a StAX implementation. > > If the only dependency on AXIOM is for testing then we can just inlcude > it as a <test> depdency and it would never impact a distribution. If we > are proving a helper for reading/writing an AXIOM model then it should > be isolated to the AXIOM helper class itself so the only users that > need to provide that dependency are the ones using AXIOM. > > > Adding Serializer/Deserializer for DataObject using StAX for better > > Axis2 AXIOM integration > > --------------------------------------------------------------------- > >---------------------- > > > > Key: TUSCANY-118 > > URL: http://issues.apache.org/jira/browse/TUSCANY-118 > > Project: Tuscany > > Type: Improvement > > Components: Java SCA Axis Integration, Java SDO Implementation > > Reporter: Raymond Feng > > Attachments: rfeng_stax.diff, rfeng_stax_axis_095.diff > > > > Here are the key classes: > > 1) DataObjectStAXWrapper > > Implements "org.apache.axis2.databinding.ADBBean" interface by > > feeding elements and attibutes to > > "org.apache.axis2.databinding.utils.ADBPullParser". It can be used as > > a Serializer for DataObject to be serialized as OMElement. > > > > 2) StAXXMLResourceImpl and StAX2SAXAdapter > > StAXXMLResourceImpl extends > > "org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl" to provide > > additional methods to load DataObject directly from XMLStreamReader. > > StAX2SAXAdpter is responsible to pull StAX events from XMLSreamReader > > and generate SAX events so that they can be consumed by > > XMLResourceImpl. 3) DataObjectStAXWrapperTestCase > > It tests the round trip for "DataObject --> OMElment --> DataObject". > > Both static SDO model (pre-generated) and dynamic SDO model (loaded > > from WSDL/XSD) are covered. It also test the cost of the optimized > > roundtrip against the old "quick and dirty" way (DataObject --> > > OutputStream --> InputStream --> OMElement --> OutputStream --> > > InputStream --> DataObject). It shows more that 400% performance > > gain. > > > > It seems that files in set 1 and 2 are more fit to be included in the > > SDO sub-project. The following helper method is desirable. void > > SDOUtil.load(TypeHelper scope, XMLStreamReader reader, Object > > options) XMLStreamReader SDOUtil.save(TypeHelper scope, XMLDocument > > document, Object options) -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED]
