[
https://issues.apache.org/jira/browse/OPENEJB-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294865#comment-13294865
]
Andy Gumbrecht commented on OPENEJB-1791:
-----------------------------------------
I think the system should check the current conf directory and make the
'conf.d' decision based on what it finds. I am looking at this from a 'I
already have N+ servers deployed and configured' perspective.
It is not easy to deploy updates when something like this changes over night.
During the update do I have to or should I move all the 'existing' service
properties to conf.d, or move the new conf.d/newservice.properties up one level
and delete conf.d. Or just leave it as is and when an issue arises think along
the lines of - look 'here' for this and 'there' for that? Then re-write
installers and patches to fit in again.
A system property to maintain the existing schema as an option would also fit
the picture.
OpenEJB is not written exclusively for unix like systems, this is a good thing
when the developer has 'no' control over the end system. 'conf.d' actually
'smells' of unix to a Windows administrator.
> managing a conf.d folder as under unix for services
> ---------------------------------------------------
>
> Key: OPENEJB-1791
> URL: https://issues.apache.org/jira/browse/OPENEJB-1791
> Project: OpenEJB
> Issue Type: Improvement
> Reporter: Romain Manni-Bucau
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
