[MAGNOLIA-2610] ability to use unqualified server names in properties resolution Created: 31/Jan/09  Updated: 23/Jan/13  Resolved: 31/Jan/10

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 4.0
Fix Version/s: 4.3

Type: Improvement Priority: Major
Reporter: Fabrizio Giustina Assignee: Fabrizio Giustina
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

The server name resolved in MgnlServletContextListener.initServername() is usually a not qualified hostname ("hostname" and not "hostname.domain.com"), but sometimes seems that InetAddress.getLocalHost().getHostName() can also return a fully qualified hostname with the domain (not really sure about the logic behind it, I've seen different behaviour on similarly configured linux machines).

I think it will be better to always force an unqualified hostname, so that the behavior is more predictable...



 Comments   
Comment by Fabrizio Giustina [ 01/Feb/09 ]

fixed in svn

Comment by Magnolia International [ 03/Feb/09 ]

Reopening this issue. We can't fix this now, as this might break existing installations.
As per the javadoc, this could only give different results if the servers use a different name resolution.
A proper fix would involve adding an extra property such as magnolia.servername.unqualified and use this new property in the info.magnolia.cms.beans.config.PropertiesInitializer#processPropertyFilesString method.
This could then safely be introduced even in the next minor release.

Comment by Fabrizio Giustina [ 08/Feb/09 ]

> Reopening this issue. We can't fix this now, as this might break existing installations.

Isn't it better to do that in a major release such 4.0 so? Since 4.0 already breaks backward compatibility with several APIs I thinks this is really a minor change compared to that... making the hostname resolution work in a clear way is surely a need, do you think this really could be a problem?

I really would for committing this, adding a new property such as "magnolia.servername.unqualified" for this just adds confusion and will leave the old less clear way as the default... WDYT?

Comment by Magnolia International [ 10/Feb/09 ]

I wouldn't have objected at all if it had happened earlier, but not between RCs.
The name resolution isn't random, and should be consistent. If there was a fix that'd allow both qualified and unqualified names, we could add that to the next minor release. If there's a possibility to fix this without having another intermediate property, it's fine by me, but as far as I could see, that was the only simple way, without rewriting the current PropertiesInitializer/MgnlServletContextListener interactions. (which is something we might do for 4.1 anyway)

Comment by Fabrizio Giustina [ 10/Feb/09 ]

Another option:
what about making both version (qualified and unqualified) work?
That would mean that ${server}/dir will make magnolia look both in "myserver/dir" and "myserver.domain/dir" (optionally deprecating and adding a warning for the qualified version)... this is definitively safe for existing apps, WDYT?

Comment by Magnolia International [ 10/Feb/09 ]

That is exactly what I meant But by looking at the current implementation, the only "simple" way of solving this was by adding an extra property to pass between MgnlServletContextListener and PropertiesInitializer.

Comment by Fabrizio Giustina [ 31/Jan/10 ]

In order to avoid breaking any existing behaviour, I just added a new optional context parameter "magnolia.unqualified.server.name", for a switch.
MgnlServletContextListener javadocs have been updated with details.

Generated at Mon Feb 12 03:38:23 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.