You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Alex Karasulu (JIRA)" <ji...@apache.org> on 2007/09/30 23:07:50 UTC
[jira] Created: (DIRSERVER-1079) Add module under apachds to test
that the server.xml is up to date
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
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.
[jira] Assigned: (DIRSERVER-1079) Add module under apachds to test
that the server.xml is up to date
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alex Karasulu reassigned DIRSERVER-1079:
----------------------------------------
Assignee: Alex Karasulu
> 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.
[jira] Commented: (DIRSERVER-1079) Add module under apachds to test
that the server.xml is up to date
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531602 ]
David Jencks commented on DIRSERVER-1079:
-----------------------------------------
I don't see any good reason this has to be in a new module. I added a simple test in apacheds-server-xml that tries to fire up a spring configured server using the xbean stuff. Due to the changes alex made yesterday in partition setup the current server.xml doesn't work, but now you can see that really quickly :-)
rev 581038.
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. 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. I think at this point what will help us most is simplicity in our tool chain and simplicity of configuration. Perhaps when the server is clearly assembled out of well defined IOC components we can look into additional configuration mechanisms but I think in order to get the current refactoring complete enough to use we shouldn't add any more technologies than provide a clear immediate simplification and advantage.
indeed the test I added does check that server.xml fits the model :-)
> 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.
[jira] Assigned: (DIRSERVER-1079) Add module under apachds to test
that the server.xml is up to date
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alex Karasulu reassigned DIRSERVER-1079:
----------------------------------------
Assignee: David Jencks (was: Alex Karasulu)
David took care of this already it seems.
> 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: David Jencks
> 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.
[jira] Commented: (DIRSERVER-1079) Add module under apachds to test
that the server.xml is up to date
Posted by "Ole Ersoy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531614 ]
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: 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.
[jira] Commented: (DIRSERVER-1079) Add module under apachds to test
that the server.xml is up to date
Posted by "Ole Ersoy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531402 ]
Ole Ersoy commented on DIRSERVER-1079:
--------------------------------------
I'm just commenting here (I've mentioned this in different contexts, but figured I'd mention it again just as a backdrop). I first have to assume the following with respect to the task though:
ASSUMPTION
There's a model instance that's created when server.xml is parsed. When this model (Class files are added, mutated, or deleted) is updated, server.xml must also be upated manually and the parsing of server.xml must then be tested to verify that the xml representation of the model still "Fits" the model.
So that's the assumption. The IDEAL section below will be most useful if the assumption is right :-).
IDEAL
Use XML Schema to generate the model. Then use something like Tuscany or EMF or even Maven modello to generate the corresponding components (Java Beans) to house the model instances. This way server.xml is always up to date and the only concern for the developer is whether the model has configuration needed by server services.
> 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.
[jira] Closed: (DIRSERVER-1079) Add module under apachds to test
that the server.xml is up to date
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alex Karasulu closed DIRSERVER-1079.
------------------------------------
Resolution: Fixed
David took care of this already it seems.
> 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: David Jencks
> 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.
[jira] Issue Comment Edited: (DIRSERVER-1079) Add module under
apachds to test that the server.xml is up to date
Posted by "Ole Ersoy (JIRA)" <ji...@apache.org>.
[ 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.