Re: Backwards compatibility of configuration files (Was: [jira] Commented: (JCR-1462) repository.xml: throw an exception on error)
-1 for having the security-manager optional. the security section has been completely reworked and the security-manager is a key functionality. up to know the access-manager was the only mandatory element in the security section. with the new security code it could even be the other way round: the access manager could be make optional. apart: the access-manager interface has been heavily extended and the old methods have been deprecated. someone having an 1.4 configuration with a custom access manager would be forced to change it anyway. angela
Re: Backwards compatibility of configuration files (Was: [jira] Commented: (JCR-1462) repository.xml: throw an exception on error)
Why is that? If we want to be backward compatible, that means if Jackrabbit 1.5 should 'just work' with old repository.xml files, then we need to 'make it work' if no SecurityManager is configured. That means we need to define what is the default security manager. Once we say 'use the default SecurityManager if not configured' we might as well _not_ log a warning if it is missing. Why insist in having an explicit SecurityManager if it works without it? -1 for having the security-manager optional. If it is not optional, we are obviously not backward compatible. someone having an 1.4 configuration with a custom access manager would be forced to change it anyway. I believe most users use the default settings. Regards, Thomas
Re: Backwards compatibility of configuration files (Was: [jira] Commented: (JCR-1462) repository.xml: throw an exception on error)
Alexander Klimetschek wrote: On Wed, Sep 24, 2008 at 2:25 PM, Jukka Zitting [EMAIL PROTECTED] wrote: The question is, should the 1.5 upgrade changes in configuration files or not? I would rather opt for a smoother upgrade with more backwards compatibility, but I acknowledge that there are good reasons why we might want people to update their configurations. WDYT? +1 for being backwards compatible in a minor 1.x release In the SecurityManager case I would let the parser allow the old config, use defaults for the new required component, and log a big warning on the console that this old config is deprecated. We can really remove it with Jackrabbit 2.0. +1 regards marcel
Re: Backwards compatibility of configuration files (Was: [jira] Commented: (JCR-1462) repository.xml: throw an exception on error)
-1 for having the security-manager optional. If it is not optional, we are obviously not backward compatible. someone having an 1.4 configuration with a custom access manager would be forced to change it anyway. I believe most users use the default settings. so, the question is whether we want to stress out the changes made to code base and have users being aware of that or if want to focus on backwards compatibility taking the risk that people don't change their config and can't start the repository afterwards. to me the first variant looks better. but i can live with both... angela
Re: Backwards compatibility of configuration files (Was: [jira] Commented: (JCR-1462) repository.xml: throw an exception on error)
Angela Schreiber schrieb: -1 for having the security-manager optional. If it is not optional, we are obviously not backward compatible. someone having an 1.4 configuration with a custom access manager would be forced to change it anyway. I believe most users use the default settings. so, the question is whether we want to stress out the changes made to code base and have users being aware of that or if want to focus on backwards compatibility taking the risk that people don't change their config and can't start the repository afterwards. to me the first variant looks better. but i can live with both... I think it's important to focus on backwards compatibility and that the repository still starts up, whereas I think at the same time one should add big WARNINGS to the log file and pointing out what needs to be changed in order to be up-to-date. At some later stage (for example Release 2.0) one can announce that older configurations are EOL Cheers Michael angela
Re: Backwards compatibility of configuration files (Was: [jira] Commented: (JCR-1462) repository.xml: throw an exception on error)
thomas and myself had a private conversation on that issue and found a compromise: have everything in the security configuration optional would avoid any misconception regarding the relation between security-manager and access-manager. i.e. change dtd from !ELEMENT Security (SecurityManager, AccessManager, LoginModule?) to !ELEMENT Security (SecurityManager?, AccessManager?, LoginModule?) and change the configuration parsing and repository initialization accordingly. i will open an issue for that. angela
Backwards compatibility of configuration files (Was: [jira] Commented: (JCR-1462) repository.xml: throw an exception on error)
Hi, On Wed, Sep 24, 2008 at 2:06 PM, Thomas Mueller (JIRA) [EMAIL PROTECTED] wrote: Compatibility: Jackrabbit 1.5 will not work with 1.4 repository.xml files because of JCR-1472 (SecurityManager). If we want to make the repository.xml backward compatible, we should have a look at that as well. This touches a more generic issue about how strictly backwards compatible we want to be across minor release upgrades like 1.4 - 1.5. So far at least my guideline has been to try to make all minor release upgrades as easy as possible, with minimum manual intervention (including configuration file updates) required unless the user explicitly wants to enable new functionality. As far as I'm aware it's still possible to start and run Jackrabbit 1.4 with a Jackrabbit 1.0 repository and configuration. However, this isn't a strict guideline and we do include upgrade instructions in release notes, so it would not be too big a problem to require manual configuration updates during a minor version upgrade. The question is, should the 1.5 upgrade changes in configuration files or not? I would rather opt for a smoother upgrade with more backwards compatibility, but I acknowledge that there are good reasons why we might want people to update their configurations. WDYT? BR, Jukka Zitting
Re: Backwards compatibility of configuration files (Was: [jira] Commented: (JCR-1462) repository.xml: throw an exception on error)
On Wed, Sep 24, 2008 at 2:25 PM, Jukka Zitting [EMAIL PROTECTED] wrote: The question is, should the 1.5 upgrade changes in configuration files or not? I would rather opt for a smoother upgrade with more backwards compatibility, but I acknowledge that there are good reasons why we might want people to update their configurations. WDYT? +1 for being backwards compatible in a minor 1.x release In the SecurityManager case I would let the parser allow the old config, use defaults for the new required component, and log a big warning on the console that this old config is deprecated. We can really remove it with Jackrabbit 2.0. Regards, Alex -- Alexander Klimetschek [EMAIL PROTECTED]
Re: Backwards compatibility of configuration files (Was: [jira] Commented: (JCR-1462) repository.xml: throw an exception on error)
+1 for being backwards compatible in a minor 1.x release In that case the SecurityManager setting should be truly optional: no warning should be logged if it is missing.
Re: Backwards compatibility of configuration files (Was: [jira] Commented: (JCR-1462) repository.xml: throw an exception on error)
Hi, On Wed, Sep 24, 2008 at 8:52 PM, Thomas Müller [EMAIL PROTECTED] wrote: In that case the SecurityManager setting should be truly optional: no warning should be logged if it is missing. Why is that? We can (and should) deprecate old configurations like ones with no SecurityManager or no DOCTYPE, and logging warnings about deprecated features is IMHO perfectly fine, even preferable as an aid to make a future 2.x upgrade (where we probably will drop deprecated stuff) less painful. But IMHO such deprecated stuff should still continue to work across minor version upgrades. BR, Jukka Zitting
