directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ole Ersoy (JIRA)" <>
Subject [jira] Commented: (DIRSERVER-1079) Add module under apachds to test that the server.xml is up to date
Date Mon, 01 Oct 2007 20:08:51 GMT


Ole Ersoy commented on DIRSERVER-1079:

Hey David,

I've inlined some comments.

Ole -- the schema for the xbean server.xml is generated from javadoc like annotations on the
source classes. Therefore any xml tool or parser can be used to validate server.xml against
the generated schema. 

Very cool.  

At this point I don't see that an xml schema first approach from which we generate the component
classes would be an improvement or even workable. 
Maybe a little elaboration would help.  Suppose EMF were used.  You cold take the XML Schema
generated from the annotations and regenerate the model.  So now we went full circle.  Java
Class > XML Schema > Java Classes.  What focusing only on the XML Schema as the model
does is take away the "Let me see if my model fits now" work, because the java bean model
always fits the default server.xml file.  A different way of saying this is that we could
generate the java model, create the default instance, serialize it, and that's the updated
server.xml version.

So we would just take the XML Schema (Add defaults to it so that beans are initialized with
default values) we have now and regenerate the corresponding java model.  Then always update
the xml schema and generate the java model.  This keeps everything up to date automatically.
 Thus you eliminate the need to verify that server.xml can still be loaded.  It's really very
simple.  We get the same result by just tweaking the process slightly.  However there is a
little (Very little) EMF learning in there for the developer that wants to use the approach.

I think at this point what will help us most is simplicity in our tool chain and simplicity
of configuration. 

Sure - I can definitely understand that some developer are more comfortable annotating  java

and generating the model correspondingly.  However we can do this with EMF too.  Just annotate
the java interfaces and use these to generate the xmi version of the model.  Then generate
the schema and 
java implementation from there.

So it's really a question of "Do I what to learn EMF and always save myself the work of having
to update 
server.xml ?" or "Do I want to stick with the current approach and just update server.xml
each time the model changes?"

indeed the test I added does check that server.xml fits the model :-)

If the test fails then we have to tweak server.xml.  Using EMF eliminates this step.  We would
just serialize the default instance of the model to create server.xml.  I still totally understand
if we prefer to just tweak server.xml though.  Plenty of balls up in the air right now :-).
  However if tweaking server.xml gets old someday I'll be glad to elaborate further on the
EMF approach.

> Add module under apachds to test that the server.xml is up to date
> ------------------------------------------------------------------
>                 Key: DIRSERVER-1079
>                 URL:
>             Project: Directory ApacheDS
>          Issue Type: Sub-task
>    Affects Versions: bigbang
>            Reporter: Alex Karasulu
>            Assignee: Alex Karasulu
>             Fix For: bigbang
> As we make changes we need to remember to update the server.xml default file.  However
since this is overlooked quit often it's a good idea to just add a module to test that this
server.xml file is working.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message