> -----Original Message-----
> From: Liu, Jervis [mailto:[EMAIL PROTECTED]
> Sent: 2007年12月29日 13:23
> To: [email protected]
> Subject: RE: Significant changes to Aegis API
>
>
>
> > -----Original Message-----
> > From: Benson Margulies [mailto:[EMAIL PROTECTED]
> > Sent: 2007年12月29日 5:42
> > To: cxf-dev
> > Subject: Significant changes to Aegis API
> >
> > Goaded by Dan D, I went and refactored Aegis in the direction of having
> > a package like JAXB and XmlBeans that could be used independently of
> > CXF.
> >
> > It's not done, but I have the code considerably closer.
> >
> > However, in the process, I've incompatibly changed the API for
> > configuring an Aegis service. Instead of expecting various values to be
> > stuck into a properties of endpoints or services, the configurable items
> > really are just (Spring-configurable) properties of objects.
> >
> > In practical terms, instead of throwing property maps into factories, an
> > app would want to explicitly create an AegisContext, put it into an
> > AegisDatabinding, and put that into a service factory.
> >
>
> Excellent, I am looking forward to this API. This is IMHO, what we really
> need if Aegis binding is to become a standalone data binding that can be
> used outside CXF. Think about the JSR-311 Aegis EntityProvider question I
> raised previously, this use case is about using Aegis binding to
> marshal/unmarshal data in a JSR-311 runtime. If this Aegis EntityProvider
> works, we can not only use it in CXF JSR-311 implementation, but also other
> JSR-311 runtimes, such as Jersey.
>
> The usage of Aegis binding in JSR-311 EntityProvider may look like below,
> very similar to JAXB binding:
>
> public final class AegisEntityProvider implements EntityProvider<Object> {
> public Object readFrom(Class<Object> type, MediaType m,
> MultivaluedMap<String, String> headers,
> InputStream is) {
> AegisContext context = getAegisContext (obj.getClass());
> AegisDatabinding binding = new AegisDatabinding(context);
> DataReader reader = binding.createReader(XMLStreamReader.class);
> XMLStreamReader input =
> XMLInputFactory.newInstance().createXMLStreamReader(is, encoding);
> Object obj = reader.read(type, input);
> return obj;
> }
>
> private AegisContext getAegisContext(Class type) {
> //AegisContext can be registered with a Class, or a directory that
> contains type classes.
> context = AegisContext.newInstance(type);
> }
> }
It's even better if we can hide the creation of XMLStreamReader. Same as JAXB
Unmarshaller:
public Object readFrom(Class<Object> type, MediaType m, MultivaluedMap<String,
String> headers, InputStream is) {
AegisContext context = getAegisContext (obj.getClass());
AegisUnmarshaller unmarshaller = context.createUnmarshaller();
return unmarshaller.unmarshal(is);
}
Internally, we could do:
public Class AegisContext {
AegisUnmarshaller createUnmarshaller() {
AegisDatabinding binding = new AegisDatabinding(this);
DataReader reader = binding.createReader(XMLStreamReader.class);
//
AegisUnmarshaller u = new AegisUnmarshaller(binding, reader);
return u;
}
}
public Class AegisUnmarshaller {
DataReader reader;
public AegisUnmarshaller (DataReader reader) {
}
Object unmarshal (InputStream is) {
XMLStreamReader input =
XMLInputFactory.newInstance().createXMLStreamReader(is, encoding);
....
}
}
> > If this really upsets people, I can, I suppose, graft a compatibility
> > scheme back into the Databinding object which looks for properties and,
> > if present, uses them to initialize.
> >
> > I guess I'll do this unless I hear voices opposed.
> >
> > The doc is another question; I can always add boxes to the doc that say
> > '2.0.x versus 2.1'.
> >
> > My efforts in the process to really understand the use of the 'encoding
> > URIs' remain disappointing. Some places they really are encoding URIs.
> > Some places they are service target namespaces. And one place it has to
> > the the special URL usually associated with the XSD prefix, or the WSDLs
> > that come out of Aegis come out completely wrong.
> >
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
