XMLBeans Based Configuration

[Cetin Karakus <ce...@gmail.com>]

Hi,
I have been working on the task of creating infrastructure to read/manipulate
XML configuration files. We have decided to use XMLBeans as our XML read/write
machinery. To summarize the problem we would like to solve:

1-	
We have  XML Schemas that define the structure of valid configuration files.
The configuration data is going to be stored in XML files conforming
to these schemas.

2-	We have Java interfaces that reflects the information structure present in
XML schemas mentioned in 1. These interfaces are what we would like to see
in our Java universe as far as configuration related things concerned.

3-
We want to use XMLBeans to generate boiler-plate Java code to
read/write configuration
data that is stored in XML files conforming certain types of XML schemas.

Normally, an XML schema is all you need to use XMLBeans to read XML
documents conforming
this schema. XMLBeans uses code generation to create Java code that
read/write the
XML document. This trivial use of XMLBeans does not satisfy our needs because 
we want to interact with configuration data through Java interfaces "we write" 
not those generated by XMLBeans.

Yesterday I have talked to Alex on possible design choices to satisfy
the requirements.
These are the available options to the best of my knowledge:

1-
Let XMLBeans to generate the boiler-plate XML code in such a way that
the generated
code implement our interfaces. My current limited knowledge about
XMLBeans tell me
it is not possible to do this. Alex also told me that this feature has
not yet been
implemented in XMLBeans later on.

2-
Write adapter objects that implement the desired interfaces and
delegate XML related
operations to XMLBeans generated code. For each type of configuration file 
we need to write an adapter.

3-
This is also an adapter based solution with one important difference:
Instead of writing a brand new adapter for each type of configuration file,
write a generic adapter that can deal with any type of configuration file
using a mechanism like Dynamic proxies.
This method will be based on existence of certain naming conventions otherwise
generic configuration adapter has no way of routing method invocations to the
XMLBeans generated objects that does actual XML operations.


My favorite is third one. There are pros and cons for it:

pros:
----
	*It will result in less code 
	*It will require no maintenance in case new configuration files added
in the future
cons:
----
	*more sophisticated implementation 

I am going to start working on this method and see whether it is troublesome. 
Meanwhile, any ideas are welcome.

cheers,

Re: XMLBeans Based Configuration

[Alex Karasulu <ao...@bellsouth.net>]

Cetin,

Your description of the problem, tool synopsis, and possible solutions
for it are excellent.  I like your approach ;) and  I like idea #3 very
much.   It sounds perfect to me now having encountered some issues with
XMLBeans 1.  The next version might address these issues with the
extension mechanism but we're not going to see that in prod use soon. 
So go for it and let me know what I can do to help you out.

Cheers,
Alex

On Sat, 2004-10-02 at 11:54, Cetin Karakus wrote:
> Hi,
> I have been working on the task of creating infrastructure to read/manipulate
> XML configuration files. We have decided to use XMLBeans as our XML read/write
> machinery. To summarize the problem we would like to solve:
> 
> 1-	
> We have  XML Schemas that define the structure of valid configuration files.
> The configuration data is going to be stored in XML files conforming
> to these schemas.
> 
> 2-	We have Java interfaces that reflects the information structure present in
> XML schemas mentioned in 1. These interfaces are what we would like to see
> in our Java universe as far as configuration related things concerned.
> 
> 3-
> We want to use XMLBeans to generate boiler-plate Java code to
> read/write configuration
> data that is stored in XML files conforming certain types of XML schemas.
> 
> Normally, an XML schema is all you need to use XMLBeans to read XML
> documents conforming
> this schema. XMLBeans uses code generation to create Java code that
> read/write the
> XML document. This trivial use of XMLBeans does not satisfy our needs because 
> we want to interact with configuration data through Java interfaces "we write" 
> not those generated by XMLBeans.
> 
> Yesterday I have talked to Alex on possible design choices to satisfy
> the requirements.
> These are the available options to the best of my knowledge:
> 
> 1-
> Let XMLBeans to generate the boiler-plate XML code in such a way that
> the generated
> code implement our interfaces. My current limited knowledge about
> XMLBeans tell me
> it is not possible to do this. Alex also told me that this feature has
> not yet been
> implemented in XMLBeans later on.
> 
> 2-
> Write adapter objects that implement the desired interfaces and
> delegate XML related
> operations to XMLBeans generated code. For each type of configuration file 
> we need to write an adapter.
> 
> 3-
> This is also an adapter based solution with one important difference:
> Instead of writing a brand new adapter for each type of configuration file,
> write a generic adapter that can deal with any type of configuration file
> using a mechanism like Dynamic proxies.
> This method will be based on existence of certain naming conventions otherwise
> generic configuration adapter has no way of routing method invocations to the
> XMLBeans generated objects that does actual XML operations.
> 
> 
> My favorite is third one. There are pros and cons for it:
> 
> pros:
> ----
> 	*It will result in less code 
> 	*It will require no maintenance in case new configuration files added
> in the future
> cons:
> ----
> 	*more sophisticated implementation 
> 
> I am going to start working on this method and see whether it is troublesome. 
> Meanwhile, any ideas are welcome.
> 
> cheers,