You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Irv Salisbury <ir...@gmail.com> on 2005/02/11 20:56:48 UTC
XMLBeans and request attributes
This is really a follow up to some questions I asked earlier about XML
in request attributes. I wanted to show how I went about solving what
I needed, and to get feedback if there is a better way.
To recap, my basic problem was that I wanted to call internal
pipelines and pass them XML. The cocoon: protocol does not support
POST, so the easiest way I was told to use request attributes. I
decided to incorporate XMLBeans into the mix to make my life easier.
So, all of my business objects in the system are XMLBeans that have
been generated from a set of XMLSchema files. I have a series of
internal pipelines that can generate XML of these schemas. To "pass"
the objects around, I use a combination of flowscript and a generator
I wrote that generates XML from a request attribute that happens to be
an XMLObject. (Borrowing from the RequestAttributeGenerator)
So, here is a simple flow snippet:
var sessionInfo = getSessionInfo();
cocoon.request.setAttribute( "sessionInfo", sessionInfo );
cocoon.sendPage( "internal/style/catalog" );
So, the goal of the getSessionInfo call is to create a SessionInfo
object, which happens to be an XMLBeans object. Here is the
getSessionInfo method:
function getSessionInfo() {
var pipelineUtil = cocoon.createObject( PipelineUtil );
var xmlSaxHandler =
XmlBeans.getContextTypeLoader().newXmlSaxHandler(
SessionInfoDocument.type, null );
pipelineUtil.processToSAX(
"internal/sessionInfo/getSessionInfo",
null,
xmlSaxHandler.getContentHandler() );
var sessionInfo = xmlSaxHandler.getObject();
return sessionInfo;
}
Then, my generator for internal/style/catalog is such:
<map:generate type="xmlbeansAttribute">
<map:parameter name="attributeName" value="sessionInfo"/>
</map:generate>
This really seems to work great. Has anyone had experience with doing
this before? Does this seem like a good idea? Anything I am missing
here?
The main reason for choosing XMLBeans was the ability to go back and
forth from Java - XML easily. Boy, if this was merged with Hibernate,
that would be something!
I realize I could do this with straight Java objects and the
JXTemplateGenerator, but I really need everything in the Java object
to be turned into XML. XMLBeans seemed the easiest way to do this.
Thanks for any advice.
Irv
Re: XMLBeans and request attributes
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Irv Salisbury wrote:
> On Sun, 13 Feb 2005 16:43:01 +0100, Daniel Fagerstrom
> <da...@nada.kth.se> wrote:
<snip/>
>>Concerning the XMLBean and flow stuff, it would IMO be a
>>good idea to have an XMLBean block. That block would contain the XMLBean
>>jar, some support stuff like the XMLizable embeding described above and
>>maybe an XMLBean aware version of PipelineUtil. It would also contain
>>some samples showing how one can use XMLBean and flow. Currently the
>>XMLBean jar is part of core in the trunk, but that is unnecesary as
>>nothing in core depends on XMLBean and it is a rather large jar.
>>
>>I have not found any time to experiment with the new XML stuff in Rhino,
>>if you or someone else does, describing your experiences of it or even
>>patches are always welcome :)
>>
>>/Daniel
>
> I would love to have XMLBeans integrated closer into cocoon. I looked
> more into the XModule stuff as well as the XMLizable and the way that
> would work. It seems like it would actually get streamed in and out.
> The way I am currently doing things, so streams are used at all, just
> SAX events. It seems like this is more efficient. I saw some
> discussions on the wiki link you sent me that talk about having some
> additional interfaces such that a stream would not be used if SAX
> could be determined. I understand the challenges to doing that. Am I
> correct in the way I was reading this? The way I am currently doing
> things, I know I have an XMLObject, so I can always use the SAX
> directly.
If you embed the XMLBean in an XMLizable object and put this object in a
request parameter and read this object with an XModuleSource that is
used as src parameter to a FileGenerator, then it will be SAXEvents all
the way.
The FileGenerator will check if its input source is XMLizable wich the
XModuleSource is. The XModuleSource will in turn check if the value of
the used input module is XMLizable which also will be the case as you
embeded the XMLBean in an XMLizable interface. At last the
contenthandler that the generator will write to will be sent to the save
method in the XMLObject through a number of toSAX methods.
If you want to send SAX events _to_ an XModuleSource, things are less
smooth. But in your example I would guess that the important thing is to
make it easy to read from an XMLBean. Anyway if you want to use the
XModuleSource for writing to a DOM in a request attribute e.g. and want
to avoid parsing of the input SAX events, there is a getContentHandler
method. What I meant in the wiki documentation was that it would have
been even better if the XModuleSource would have implemented the
ContentHandler interface instead of returning it from a method. But I
was to lazy to implement that.
> All the links you sent were great. Having a hibernate and XMLBeans
> integration would be incredible for me. I have usually shied away
> from flowscript, trying to do all things in XML. However, using
> XMLBeans to go back and forth between Java and XML is great.
>
> The XML stuff in Rhino, I don't think, helps me much. It allows you
> to do "XML like" things right in flowscript. However, I deal with the
> XMLBeans classes directly in flowscript, so don't need the things I
> saw as XML as a first class type. Now, if I removed XMLBeans and
> built the XML up directly in flowscript, it would be really useful.
> Maybe I am missing something here?
Rhino's XML functionality is implemented in terms of XMLBean, so you can
use all the XML instructions in Rhino _directly_ at your XMLBean, i.e.
you don't need to import it to any internal XML representation. But I
have not experimented with it yet so I don't know how usefull it would
be in practice.
> I'd love to spend more time helping out. The best I can do now is
> submit small patches, answer questions, and contribute as I can.
>
> As long as we are talking, the other thing I could have found a use
> for (and as an alternative to the flowscript approach) is BPEL like
> scripting language that would let you store results of pipelines and
> pass that to other internal pipelines. BPEL is a really nice language
> for orchestrating XML "web services". Seems like it would be a great
> addition to cocoon.
>
> Keep in mind my original problem was being able to take results of one
> internal pipeline and pass it as input to another. I really don't
> NEED flowscript, but am using it to move my XML around. A BPEL like
> solution would allow me to stay pure XML if desired.
I agree with that it would be a usefull addition to Cocoon. To achieve
this we need:
1. Create mechanisms so that we glue together "web service" pipelines in
an efficient way in Cocoon.
2. Write a BPEL component that use the mechanism in point 1. and found
out how to integrate the BPEL component in Cocoon in a smooth way, is it
a generator or a transformer or something else?
I don't know much about BPEL so I focus on point 1., which must be
solved first in any case.
What we have is a number of web service pipelines:
<match pattern="service1">
<generate src="module:request:inputStream"/>
<!-- do something -->
<serialize type="xml"/>
</match>
...
We also need web service components that takes multiple input. Reading
from a multi part mime could be one way to package that as a web service:
<match pattern="combineService1">
<aggregate element="root"/>
<part src="module:raw-request-param:input1"/>
<part src="module:raw-request-param:input2"/>
</aggregate>
<!-- do something -->
<serialize type="xml"/>
</match>
Info about the ModuleSource can be found in
http://wiki.apache.org/cocoon/ModuleSource.
Then we want to orchestrate our web services:
function myCompound webservice(in) {
var in1 = compose(in, "cocoon:webservice1");
var in2 = compose("context:myConfig.xml", "cocoon:webservice2");
var out = aggregate({input1: in1, input2: in2},
"cocoon:combineService1");
return out;
}
function doIt() {
cocoon.sendPage("copy", webservice("module:request:inputStream"));
}
It's just a quick scetch don't care to much about the details.
The idea is that the first argument to compose is something that can be
converted to an XMLizable and the second is a Cocoon pipeline. The
inputStream of the second argument will be set to the first argument and
returned (as an XMLizable). Observe that the pipelines are only put
together, nothing is executed this far.
The aggregate function works in a similar way but the request attributes
will be set from the input map instead.
Then the resulting XMLizable will be sent to a copy pipeline:
<match pattern="copy">
<generate src="module:request:inputStream"/>
<serialize type="xml"/>
</match>
and the "orchestration" will at last be executed.
What's described above will not work in Cocoon today. One reason is that
the inputStream is expected to be an InputStream rather than an
XMLizable. But the most important reason is that all the pipelines that
are used in the orchestration AFAIK are executed in the same global
environment sharing the same inputStream, overwriting the inputStream
would therefore not have the intended result.
So what we need to do is to make it possible for cocoon pipelines to be
executed in an own local environment with its own request object. Then
the above ideas would be possible to implement.
/Daniel
Re: XMLBeans and request attributes
Posted by Irv Salisbury <ir...@gmail.com>.
On Sun, 13 Feb 2005 16:43:01 +0100, Daniel Fagerstrom
<da...@nada.kth.se> wrote:
> Irv Salisbury wrote:
>
> >On Sat, 12 Feb 2005 14:52:57 +0100, Daniel Fagerstrom
> ><da...@nada.kth.se> wrote:
> >
> >
> >>Irv Salisbury wrote:
> >>
> >>
> >>>This is really a follow up to some questions I asked earlier about XML
> >>>in request attributes. I wanted to show how I went about solving what
> >>>I needed, and to get feedback if there is a better way.
> >>>
> >>>To recap, my basic problem was that I wanted to call internal
> >>>pipelines and pass them XML. The cocoon: protocol does not support
> >>>POST, so the easiest way I was told to use request attributes. I
> >>>decided to incorporate XMLBeans into the mix to make my life easier.
> >>>
> >>>So, all of my business objects in the system are XMLBeans that have
> >>>been generated from a set of XMLSchema files. I have a series of
> >>>internal pipelines that can generate XML of these schemas. To "pass"
> >>>the objects around, I use a combination of flowscript and a generator
> >>>I wrote that generates XML from a request attribute that happens to be
> >>>an XMLObject. (Borrowing from the RequestAttributeGenerator)
> >>>
> >>>So, here is a simple flow snippet:
> >>>
> >>> var sessionInfo = getSessionInfo();
> >>> cocoon.request.setAttribute( "sessionInfo", sessionInfo );
> >>> cocoon.sendPage( "internal/style/catalog" );
> >>>
> >>>So, the goal of the getSessionInfo call is to create a SessionInfo
> >>>object, which happens to be an XMLBeans object. Here is the
> >>>getSessionInfo method:
> >>>
> >>> function getSessionInfo() {
> >>> var pipelineUtil = cocoon.createObject( PipelineUtil );
> >>> var xmlSaxHandler =
> >>> XmlBeans.getContextTypeLoader().newXmlSaxHandler(
> >>>
> >>>SessionInfoDocument.type, null );
> >>> pipelineUtil.processToSAX(
> >>> "internal/sessionInfo/getSessionInfo",
> >>> null,
> >>> xmlSaxHandler.getContentHandler() );
> >>> var sessionInfo = xmlSaxHandler.getObject();
> >>> return sessionInfo;
> >>> }
> >>>
> >>>Then, my generator for internal/style/catalog is such:
> >>>
> >>> <map:generate type="xmlbeansAttribute">
> >>> <map:parameter name="attributeName" value="sessionInfo"/>
> >>> </map:generate>
> >>>
> >>>This really seems to work great. Has anyone had experience with doing
> >>>this before? Does this seem like a good idea? Anything I am missing
> >>>here?
> >>>
> >>>
> >>Seem like a reasonable approach. You can simplify things a little bit by
> >>embeding the XMLBean in an object that implements
> >>org.apache.excalibur.xml.sax.XMLizable,
> >>http://svn.apache.org/viewcvs.cgi/excalibur/trunk/components/xmlutil/src/java/org/apache/excalibur/xml/sax/XMLizable.java?view=markup
> >>The toSAX method could be implemented in terms of the XMLObject.save method.
> >>
> >>Both JXTG and the XModuleSource
> >>http://wiki.apache.org/cocoon/XModuleSource are XMlizable aware, so you
> >>don't need any specialized generator.
> >>
> >>Also, if you are using trunk, it might be interesting to know that Rhino
> >>1.6, (that is used for flowscripts) has extensive XMLBean support:
> >>http://marc.theaimsgroup.com/?t=110009028500003&r=1&w=2.
> >>
> >>
> >>
> >>>The main reason for choosing XMLBeans was the ability to go back and
> >>>forth from Java - XML easily. Boy, if this was merged with Hibernate,
> >>>that would be something!
> >>>
> >>>
> >>They are at least discussing it: http://wiki.apache.org/xmlbeans/V2Features.
> >>
> >>/Daniel
> >>
> >>
> >>
> >
> >This is why I ask this list! Thanks for the info. Great references.
> >You know, if only some of this could be put into book form...
> >
> >
> I would guess that the potential authors waiting for a stable 2.2 to
> come closer.
>
> Concerning the XMLBean and flow stuff, it would IMO be a
> good idea to have an XMLBean block. That block would contain the XMLBean
> jar, some support stuff like the XMLizable embeding described above and
> maybe an XMLBean aware version of PipelineUtil. It would also contain
> some samples showing how one can use XMLBean and flow. Currently the
> XMLBean jar is part of core in the trunk, but that is unnecesary as
> nothing in core depends on XMLBean and it is a rather large jar.
>
> I have not found any time to experiment with the new XML stuff in Rhino,
> if you or someone else does, describing your experiences of it or even
> patches are always welcome :)
>
> /Daniel
>
>
I would love to have XMLBeans integrated closer into cocoon. I looked
more into the XModule stuff as well as the XMLizable and the way that
would work. It seems like it would actually get streamed in and out.
The way I am currently doing things, so streams are used at all, just
SAX events. It seems like this is more efficient. I saw some
discussions on the wiki link you sent me that talk about having some
additional interfaces such that a stream would not be used if SAX
could be determined. I understand the challenges to doing that. Am I
correct in the way I was reading this? The way I am currently doing
things, I know I have an XMLObject, so I can always use the SAX
directly.
All the links you sent were great. Having a hibernate and XMLBeans
integration would be incredible for me. I have usually shied away
from flowscript, trying to do all things in XML. However, using
XMLBeans to go back and forth between Java and XML is great.
The XML stuff in Rhino, I don't think, helps me much. It allows you
to do "XML like" things right in flowscript. However, I deal with the
XMLBeans classes directly in flowscript, so don't need the things I
saw as XML as a first class type. Now, if I removed XMLBeans and
built the XML up directly in flowscript, it would be really useful.
Maybe I am missing something here?
I'd love to spend more time helping out. The best I can do now is
submit small patches, answer questions, and contribute as I can.
As long as we are talking, the other thing I could have found a use
for (and as an alternative to the flowscript approach) is BPEL like
scripting language that would let you store results of pipelines and
pass that to other internal pipelines. BPEL is a really nice language
for orchestrating XML "web services". Seems like it would be a great
addition to cocoon.
Keep in mind my original problem was being able to take results of one
internal pipeline and pass it as input to another. I really don't
NEED flowscript, but am using it to move my XML around. A BPEL like
solution would allow me to stay pure XML if desired.
Thanks,
Irv
Irv
Re: XMLBeans and request attributes
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Irv Salisbury wrote:
>On Sat, 12 Feb 2005 14:52:57 +0100, Daniel Fagerstrom
><da...@nada.kth.se> wrote:
>
>
>>Irv Salisbury wrote:
>>
>>
>>>This is really a follow up to some questions I asked earlier about XML
>>>in request attributes. I wanted to show how I went about solving what
>>>I needed, and to get feedback if there is a better way.
>>>
>>>To recap, my basic problem was that I wanted to call internal
>>>pipelines and pass them XML. The cocoon: protocol does not support
>>>POST, so the easiest way I was told to use request attributes. I
>>>decided to incorporate XMLBeans into the mix to make my life easier.
>>>
>>>So, all of my business objects in the system are XMLBeans that have
>>>been generated from a set of XMLSchema files. I have a series of
>>>internal pipelines that can generate XML of these schemas. To "pass"
>>>the objects around, I use a combination of flowscript and a generator
>>>I wrote that generates XML from a request attribute that happens to be
>>>an XMLObject. (Borrowing from the RequestAttributeGenerator)
>>>
>>>So, here is a simple flow snippet:
>>>
>>> var sessionInfo = getSessionInfo();
>>> cocoon.request.setAttribute( "sessionInfo", sessionInfo );
>>> cocoon.sendPage( "internal/style/catalog" );
>>>
>>>So, the goal of the getSessionInfo call is to create a SessionInfo
>>>object, which happens to be an XMLBeans object. Here is the
>>>getSessionInfo method:
>>>
>>> function getSessionInfo() {
>>> var pipelineUtil = cocoon.createObject( PipelineUtil );
>>> var xmlSaxHandler =
>>> XmlBeans.getContextTypeLoader().newXmlSaxHandler(
>>>
>>>SessionInfoDocument.type, null );
>>> pipelineUtil.processToSAX(
>>> "internal/sessionInfo/getSessionInfo",
>>> null,
>>> xmlSaxHandler.getContentHandler() );
>>> var sessionInfo = xmlSaxHandler.getObject();
>>> return sessionInfo;
>>> }
>>>
>>>Then, my generator for internal/style/catalog is such:
>>>
>>> <map:generate type="xmlbeansAttribute">
>>> <map:parameter name="attributeName" value="sessionInfo"/>
>>> </map:generate>
>>>
>>>This really seems to work great. Has anyone had experience with doing
>>>this before? Does this seem like a good idea? Anything I am missing
>>>here?
>>>
>>>
>>Seem like a reasonable approach. You can simplify things a little bit by
>>embeding the XMLBean in an object that implements
>>org.apache.excalibur.xml.sax.XMLizable,
>>http://svn.apache.org/viewcvs.cgi/excalibur/trunk/components/xmlutil/src/java/org/apache/excalibur/xml/sax/XMLizable.java?view=markup
>>The toSAX method could be implemented in terms of the XMLObject.save method.
>>
>>Both JXTG and the XModuleSource
>>http://wiki.apache.org/cocoon/XModuleSource are XMlizable aware, so you
>>don't need any specialized generator.
>>
>>Also, if you are using trunk, it might be interesting to know that Rhino
>>1.6, (that is used for flowscripts) has extensive XMLBean support:
>>http://marc.theaimsgroup.com/?t=110009028500003&r=1&w=2.
>>
>>
>>
>>>The main reason for choosing XMLBeans was the ability to go back and
>>>forth from Java - XML easily. Boy, if this was merged with Hibernate,
>>>that would be something!
>>>
>>>
>>They are at least discussing it: http://wiki.apache.org/xmlbeans/V2Features.
>>
>>/Daniel
>>
>>
>>
>
>This is why I ask this list! Thanks for the info. Great references.
>You know, if only some of this could be put into book form...
>
>
I would guess that the potential authors waiting for a stable 2.2 to
come closer.
Concerning the XMLBean and flow stuff, it would IMO be a
good idea to have an XMLBean block. That block would contain the XMLBean
jar, some support stuff like the XMLizable embeding described above and
maybe an XMLBean aware version of PipelineUtil. It would also contain
some samples showing how one can use XMLBean and flow. Currently the
XMLBean jar is part of core in the trunk, but that is unnecesary as
nothing in core depends on XMLBean and it is a rather large jar.
I have not found any time to experiment with the new XML stuff in Rhino,
if you or someone else does, describing your experiences of it or even
patches are always welcome :)
/Daniel
Re: XMLBeans and request attributes
Posted by Irv Salisbury <ir...@gmail.com>.
On Sat, 12 Feb 2005 14:52:57 +0100, Daniel Fagerstrom
<da...@nada.kth.se> wrote:
> Irv Salisbury wrote:
> > This is really a follow up to some questions I asked earlier about XML
> > in request attributes. I wanted to show how I went about solving what
> > I needed, and to get feedback if there is a better way.
> >
> > To recap, my basic problem was that I wanted to call internal
> > pipelines and pass them XML. The cocoon: protocol does not support
> > POST, so the easiest way I was told to use request attributes. I
> > decided to incorporate XMLBeans into the mix to make my life easier.
> >
> > So, all of my business objects in the system are XMLBeans that have
> > been generated from a set of XMLSchema files. I have a series of
> > internal pipelines that can generate XML of these schemas. To "pass"
> > the objects around, I use a combination of flowscript and a generator
> > I wrote that generates XML from a request attribute that happens to be
> > an XMLObject. (Borrowing from the RequestAttributeGenerator)
> >
> > So, here is a simple flow snippet:
> >
> > var sessionInfo = getSessionInfo();
> > cocoon.request.setAttribute( "sessionInfo", sessionInfo );
> > cocoon.sendPage( "internal/style/catalog" );
> >
> > So, the goal of the getSessionInfo call is to create a SessionInfo
> > object, which happens to be an XMLBeans object. Here is the
> > getSessionInfo method:
> >
> > function getSessionInfo() {
> > var pipelineUtil = cocoon.createObject( PipelineUtil );
> > var xmlSaxHandler =
> > XmlBeans.getContextTypeLoader().newXmlSaxHandler(
> >
> > SessionInfoDocument.type, null );
> > pipelineUtil.processToSAX(
> > "internal/sessionInfo/getSessionInfo",
> > null,
> > xmlSaxHandler.getContentHandler() );
> > var sessionInfo = xmlSaxHandler.getObject();
> > return sessionInfo;
> > }
> >
> > Then, my generator for internal/style/catalog is such:
> >
> > <map:generate type="xmlbeansAttribute">
> > <map:parameter name="attributeName" value="sessionInfo"/>
> > </map:generate>
> >
> > This really seems to work great. Has anyone had experience with doing
> > this before? Does this seem like a good idea? Anything I am missing
> > here?
>
> Seem like a reasonable approach. You can simplify things a little bit by
> embeding the XMLBean in an object that implements
> org.apache.excalibur.xml.sax.XMLizable,
> http://svn.apache.org/viewcvs.cgi/excalibur/trunk/components/xmlutil/src/java/org/apache/excalibur/xml/sax/XMLizable.java?view=markup
> The toSAX method could be implemented in terms of the XMLObject.save method.
>
> Both JXTG and the XModuleSource
> http://wiki.apache.org/cocoon/XModuleSource are XMlizable aware, so you
> don't need any specialized generator.
>
> Also, if you are using trunk, it might be interesting to know that Rhino
> 1.6, (that is used for flowscripts) has extensive XMLBean support:
> http://marc.theaimsgroup.com/?t=110009028500003&r=1&w=2.
>
> > The main reason for choosing XMLBeans was the ability to go back and
> > forth from Java - XML easily. Boy, if this was merged with Hibernate,
> > that would be something!
>
> They are at least discussing it: http://wiki.apache.org/xmlbeans/V2Features.
>
> /Daniel
>
This is why I ask this list! Thanks for the info. Great references.
You know, if only some of this could be put into book form...
Irv
Re: XMLBeans and request attributes
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Irv Salisbury wrote:
> This is really a follow up to some questions I asked earlier about XML
> in request attributes. I wanted to show how I went about solving what
> I needed, and to get feedback if there is a better way.
>
> To recap, my basic problem was that I wanted to call internal
> pipelines and pass them XML. The cocoon: protocol does not support
> POST, so the easiest way I was told to use request attributes. I
> decided to incorporate XMLBeans into the mix to make my life easier.
>
> So, all of my business objects in the system are XMLBeans that have
> been generated from a set of XMLSchema files. I have a series of
> internal pipelines that can generate XML of these schemas. To "pass"
> the objects around, I use a combination of flowscript and a generator
> I wrote that generates XML from a request attribute that happens to be
> an XMLObject. (Borrowing from the RequestAttributeGenerator)
>
> So, here is a simple flow snippet:
>
> var sessionInfo = getSessionInfo();
> cocoon.request.setAttribute( "sessionInfo", sessionInfo );
> cocoon.sendPage( "internal/style/catalog" );
>
> So, the goal of the getSessionInfo call is to create a SessionInfo
> object, which happens to be an XMLBeans object. Here is the
> getSessionInfo method:
>
> function getSessionInfo() {
> var pipelineUtil = cocoon.createObject( PipelineUtil );
> var xmlSaxHandler =
> XmlBeans.getContextTypeLoader().newXmlSaxHandler(
>
> SessionInfoDocument.type, null );
> pipelineUtil.processToSAX(
> "internal/sessionInfo/getSessionInfo",
> null,
> xmlSaxHandler.getContentHandler() );
> var sessionInfo = xmlSaxHandler.getObject();
> return sessionInfo;
> }
>
> Then, my generator for internal/style/catalog is such:
>
> <map:generate type="xmlbeansAttribute">
> <map:parameter name="attributeName" value="sessionInfo"/>
> </map:generate>
>
> This really seems to work great. Has anyone had experience with doing
> this before? Does this seem like a good idea? Anything I am missing
> here?
Seem like a reasonable approach. You can simplify things a little bit by
embeding the XMLBean in an object that implements
org.apache.excalibur.xml.sax.XMLizable,
http://svn.apache.org/viewcvs.cgi/excalibur/trunk/components/xmlutil/src/java/org/apache/excalibur/xml/sax/XMLizable.java?view=markup
The toSAX method could be implemented in terms of the XMLObject.save method.
Both JXTG and the XModuleSource
http://wiki.apache.org/cocoon/XModuleSource are XMlizable aware, so you
don't need any specialized generator.
Also, if you are using trunk, it might be interesting to know that Rhino
1.6, (that is used for flowscripts) has extensive XMLBean support:
http://marc.theaimsgroup.com/?t=110009028500003&r=1&w=2.
> The main reason for choosing XMLBeans was the ability to go back and
> forth from Java - XML easily. Boy, if this was merged with Hibernate,
> that would be something!
They are at least discussing it: http://wiki.apache.org/xmlbeans/V2Features.
/Daniel