Beehive usage of xmlbeans

[Kenneth Tam <ke...@gmail.com>]

I know the controls component of Beehive doesn't have any dependency
on xmlbeans, but I'd like to understand how netui and WSM depend on
it.

An initial survey suggests that netui uses xmlbeans mostly to process
configuration files.  Is there a reason why we're dependent on
xmlbeans v2 vs. v1?  Did it just come down to "no reason not to use
the latest and greatest" ?

An brief overview of how WSM depends on xmlbeans would also be
appreciated, just to save me some grovelling time :)

thanks,
k

Re: Beehive usage of xmlbeans

[Daryoush Mehrtash <dm...@gmail.com>]

Ken,
 

I have meant to send a note to the list describing the issue and solicit 
opinions/ideas with respect to using XMLBeans with WSM., I try to to answer 
your question and do the issues here.

*Background*

WSM uses XML Beans in two ways: internally to read XML documents, and 
runtime support for XMLBean generated types. 

Internally WSM uses the XMLBeans to parse XML documents it reads. For now 
the only XML file it reads are the WSDL files, but we are in the process of 
adding a new configuration file that would also be read with XMLBeans. Note 
that this has build time ramifications. When you do a clean build of the 
WSM, the schema of the WSDL files is compiled with the XMLBeans to 
beehive-wsdltypes.jar. The generated classes are used to parse the WSDL 
file. It also means that the generated types are compatible only with the 
XMLBean version that is used.

For Runtime there are two different use cases: Web Service "from WSDL", and 
"from JWS". In "from WSDL" use case, the WSM uses XMLBeans to generate the 
types for Document style (as oppose to RPC style) types. The WSM uses 
XMLBeans to parse the WSDL and generate XMLBeans types, and then it 
generates an annotated JWS file that uses the XMLBean types.

 "From JWS" use case is somewhat different. In this case the user authors an 
annotated JWS class that could use XMLBean generated types (as well as 
pojos, or Axis types)  as method parameters. The XMLBean types would be an 
ideal choice if there is an existing schema for the documents that the web 
services needs to process. In this case the user would "compile" the schema 
with XMLBeans and use the resulting types in methods of the JWS.

*Issue*

There is an issue with the current WSM in that it can only deal with "types" 
that are generated by XML beans and not the Documents. See this: 
http://xmlbeans.apache.org/docs/2.0.0/guide/conJavaTypesGeneratedFromUserDerived.html

Using the schema from above, and the current version of the WSM, you can 
*not* write either of these methods:

doFoo(PriceQuoteDocument myDocument) nor

doFoo(PriceQuoteDocument.PriceQuote myPriceQuote)

 The current WSM would not work with types that are generated from
"element" in schema.   But if your schema looked
like the schema in "Global Elements and Attributes" section, you would
be able to write a method like:

  doFoo(creditReportType myCreditReport)

  The schema in this example is similar to the schema you would find in the 
WSDL, which is why our "from WSDL" use case works fine with XMLBeans. But if 
you author the JWS yourself there are more options and we are not currently 
handling them properly. 

I think it is an important use case for us to support the "document" types. I 
am working on this, the fix may require some changes in our implementation, 
but I am still in the prototyping stage to understand the problem better. 

Ideas or comments on this are welcomed.

Hope this helps.

 Daryoush


On 7/8/05, Eddie ONeil <ek...@gmail.com> wrote:
> Ken--
> 
> The XMLBeans usage in WSM is generally around:
> 
> - type handling
> - creating the WSM service object model from a WSDL file
> 
> More details can be found here:
> 
> 
http://mail-archives.apache.org/mod_mbox/incubator-beehive-dev/200506.mbox/%3c4B2B4C417991364996F035E1EE39E2E1027C26DF@uskiex01.bea.com%3e
> 
> The system controls also use XMLBeans for:
> 
> - mapping JDBC ResultSets onto XMLBeans returned from the JdbcControl
> - EJB JAR stuff in the EJBControl (didn't look deeply at this one)
> - passing XmlObject messages in the JMS control
> - parsing WSDLs in the web service control
> 
> The only reason to have used XMLBeans v2 is as you said -- latest
> and greatest.
> 
> Eddie
> 
> 
> On 7/8/05, Rich Feit <ri...@gmail.com> wrote:
> > Right, NetUI uses it for processing config files at build time and at
> > runtime, and also at build time for generating config files (e.g.,
> > Struts config files, Commons Validator config files) that are used by
> > the runtime. I don't know of any specific reason that we're using v2,
> > except to stay up-to-date.
> >
> > Rich
> >
> > Kenneth Tam wrote:
> >
> > >I know the controls component of Beehive doesn't have any dependency
> > >on xmlbeans, but I'd like to understand how netui and WSM depend on
> > >it.
> > >
> > >An initial survey suggests that netui uses xmlbeans mostly to process
> > >configuration files. Is there a reason why we're dependent on
> > >xmlbeans v2 vs. v1? Did it just come down to "no reason not to use
> > >the latest and greatest" ?
> > >
> > >An brief overview of how WSM depends on xmlbeans would also be
> > >appreciated, just to save me some grovelling time :)
> > >
> > >thanks,
> > >k
> > >
> > >
> > >
> >
> 


-- 
Daryoush

Weblog: http://perlustration.blogspot.com/

Re: Beehive usage of xmlbeans

[Eddie ONeil <ek...@gmail.com>]

Ken--

  The XMLBeans usage in WSM is generally around:

- type handling
- creating the WSM service object model from a WSDL file

More details can be found here:

http://mail-archives.apache.org/mod_mbox/incubator-beehive-dev/200506.mbox/%3c4B2B4C417991364996F035E1EE39E2E1027C26DF@uskiex01.bea.com%3e

  The system controls also use XMLBeans for:

- mapping JDBC ResultSets onto XMLBeans returned from the JdbcControl
- EJB JAR stuff in the EJBControl (didn't look deeply at this one)
- passing XmlObject messages in the JMS control
- parsing WSDLs in the web service control

  The only reason to have used XMLBeans v2 is as you said -- latest
and greatest.

Eddie


On 7/8/05, Rich Feit <ri...@gmail.com> wrote:
> Right, NetUI uses it for processing config files at build time and at
> runtime, and also at build time for generating config files (e.g.,
> Struts config files, Commons Validator config files) that are used by
> the runtime.  I don't know of any specific reason that we're using v2,
> except to stay up-to-date.
> 
> Rich
> 
> Kenneth Tam wrote:
> 
> >I know the controls component of Beehive doesn't have any dependency
> >on xmlbeans, but I'd like to understand how netui and WSM depend on
> >it.
> >
> >An initial survey suggests that netui uses xmlbeans mostly to process
> >configuration files.  Is there a reason why we're dependent on
> >xmlbeans v2 vs. v1?  Did it just come down to "no reason not to use
> >the latest and greatest" ?
> >
> >An brief overview of how WSM depends on xmlbeans would also be
> >appreciated, just to save me some grovelling time :)
> >
> >thanks,
> >k
> >
> >
> >
>

Re: Beehive usage of xmlbeans

[Rich Feit <ri...@gmail.com>]

Right, NetUI uses it for processing config files at build time and at 
runtime, and also at build time for generating config files (e.g., 
Struts config files, Commons Validator config files) that are used by 
the runtime.  I don't know of any specific reason that we're using v2, 
except to stay up-to-date.

Rich

Kenneth Tam wrote:

>I know the controls component of Beehive doesn't have any dependency
>on xmlbeans, but I'd like to understand how netui and WSM depend on
>it.
>
>An initial survey suggests that netui uses xmlbeans mostly to process
>configuration files.  Is there a reason why we're dependent on
>xmlbeans v2 vs. v1?  Did it just come down to "no reason not to use
>the latest and greatest" ?
>
>An brief overview of how WSM depends on xmlbeans would also be
>appreciated, just to save me some grovelling time :)
>
>thanks,
>k
>
>  
>