[
https://issues.apache.org/jira/browse/DIRSERVER-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531614
]
ole edited comment on DIRSERVER-1079 at 10/1/07 1:12 PM:
---------------------------------------------------------------
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 (Or Java Interfaces) 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 we have now (Or corresponding java
interfaces) add defaults to it so that beans are initialized with default
values, 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.
was (Author: ole):
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: https://issues.apache.org/jira/browse/DIRSERVER-1079
> 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.
