You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Benson Margulies <bi...@gmail.com> on 2007/12/28 22:42:19 UTC
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.
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.
RE: Significant changes to Aegis API
Posted by "Liu, Jervis" <jl...@iona.com>.
> -----Original Message-----
> From: Liu, Jervis [mailto:jliu@iona.com]
> Sent: 2007年12月29日 13:23
> To: cxf-dev@incubator.apache.org
> Subject: RE: Significant changes to Aegis API
>
>
>
> > -----Original Message-----
> > From: Benson Margulies [mailto:bimargulies@gmail.com]
> > 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
RE: Significant changes to Aegis API
Posted by "Liu, Jervis" <jl...@iona.com>.
> -----Original Message-----
> From: Benson Margulies [mailto:bimargulies@gmail.com]
> 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);
}
}
> 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
Re: Significant changes to Aegis API
Posted by Dain Sundstrom <da...@iq80.com>.
On Dec 28, 2007, at 3:32 PM, Benson Margulies wrote:
> Thanks for the kind words. I'll change the name.
>
> I have the compat stuff done, as it happens. I could take it back
> out ... which would be good from a code-size standpoint. I don't love
> making old code silently stop working, which is what will happen
> without
> the compat stuff.
>
> I really don't mean any criticism of your work in my struggle with the
> TM/TMR/URI stuff. I appreciate that some things got into interesting
> states on the way across from XFire, and the whole business is, after
> all, a marvelous (in the Tom Waits sense) ... toy? Really, I intend
> that
> remark to be an entirely positive characterization.
>
> I agree about your target of collapsing things for the very reason you
> say. Now that we don't have some a global TMR, the multi-part
> structure
> doesn't do us any service.
>
> I'm whining because not understanding what is going on is a real
> bee in
> my bonnet. I need to suck it up and read the code until I
> understand it.
>
> Either that or trade Dain an apple core for this next piece of
> remodularization.
This is the next piece of code I must understand to finish SOAP
encoded support, so I may want to do some modularization work anyway :)
-dain
Re: Significant changes to Aegis API
Posted by Benson Margulies <bi...@gmail.com>.
Thanks for the kind words. I'll change the name.
I have the compat stuff done, as it happens. I could take it back
out ... which would be good from a code-size standpoint. I don't love
making old code silently stop working, which is what will happen without
the compat stuff.
I really don't mean any criticism of your work in my struggle with the
TM/TMR/URI stuff. I appreciate that some things got into interesting
states on the way across from XFire, and the whole business is, after
all, a marvelous (in the Tom Waits sense) ... toy? Really, I intend that
remark to be an entirely positive characterization.
I agree about your target of collapsing things for the very reason you
say. Now that we don't have some a global TMR, the multi-part structure
doesn't do us any service.
I'm whining because not understanding what is going on is a real bee in
my bonnet. I need to suck it up and read the code until I understand it.
Either that or trade Dain an apple core for this next piece of
remodularization.
On Fri, 2007-12-28 at 13:19 -1000, Dan Diephouse wrote:
> Hi Benson,
>
> You rock! From my brief look, this looks good. This is definitely only a
> 2.1 thing, but definitely good. I don't think there is a need for
> backward compat of this stuff for 2.1, but others may have more definite
> feelings on that than I.
>
> One tweak - can we change DUMMY_ENCODING to DEFAULT_ENCODING? Just a
> preference of mine really.
>
>
> Benson Margulies wrote:
> > 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
> You have to realize that this is the first code that I ever wrote when
> starting XFire like 4 some years ago. So I don't know that it
> necessarily all makes sense still (but at least it still works, that
> counts for something, no?). :-) The other big change in CXF now is that
> there is one TypeMappingRegistry per service. In XFire there was one
> global TypeMappingRegistry, the default type mapping with the xml schema
> types and then per service type mappings. So a lot of those assumptions
> don't hold true any more. We can probably collapse a lot of that stuff
> and make it a lot simpler. I wonder if we could get rid of the TMR
> altogether and collapse everything into one TypeMapping? Thoughts?
>
> - Dan
>
Re: Significant changes to Aegis API
Posted by Dan Diephouse <da...@mulesource.com>.
Hi Benson,
You rock! From my brief look, this looks good. This is definitely only a
2.1 thing, but definitely good. I don't think there is a need for
backward compat of this stuff for 2.1, but others may have more definite
feelings on that than I.
One tweak - can we change DUMMY_ENCODING to DEFAULT_ENCODING? Just a
preference of mine really.
Benson Margulies wrote:
> 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
You have to realize that this is the first code that I ever wrote when
starting XFire like 4 some years ago. So I don't know that it
necessarily all makes sense still (but at least it still works, that
counts for something, no?). :-) The other big change in CXF now is that
there is one TypeMappingRegistry per service. In XFire there was one
global TypeMappingRegistry, the default type mapping with the xml schema
types and then per service type mappings. So a lot of those assumptions
don't hold true any more. We can probably collapse a lot of that stuff
and make it a lot simpler. I wonder if we could get rid of the TMR
altogether and collapse everything into one TypeMapping? Thoughts?
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog