Affects: Release Notes project_key: JBEWS There are at least 2 pieces, where can be used IP literal addresses: - <Engine defaultHost="XYZ" ...> - <Host name="XYZ" ...> Instead of XYZ we can use some name or literal IP address. Unfortunately, IPv6 literal address uses new character ':' as group delimiter and if I've used it, I got a such exception: {code}Sep 18, 2012 9:34:37 AM org.apache.catalina.mbeans.ServerLifecycleListener processContainerRemoveChild SEVERE: processContainerRemoveChild: Throwable javax.management.MalformedObjectNameException: Invalid character ':' in value part of property at javax.management.ObjectName.construct(ObjectName.java:602) {code} Enclose a such IPv6 address with '\[' and '\]' doesn't help, moreover, IPv6 address itself doesn't contain these characters (this notation should be used when we are using IPv6 address with port together and need to be unambiguous only).
Assigning to David for investigation.
Please attach your server.xml On the queue
that won't work. name must be a name look to http://tomcat.apache.org/tomcat-7.0-doc/config/host.html
Hi David, excuse me, but I don't agree with you... On-line docs for Tomcat7 says about element *Host* and its attribute *name*: {quote} Usually the network name of this virtual host, as registered in your Domain Name Service server. Regardless of the case used to specify the host name, Tomcat will convert it to lower case internally. One of the Hosts nested within an Engine MUST have a name that matches the defaultHost setting for that Engine. See Host Name Aliases for information on how to assign more than one network name to the same virtual host. {quote} In this case, it is not a mandatory requirement to have there reasonable name from DNS... There isn't any objection to have: {code} <Host name="127.0.0.1" .../> {code} and therefore there shouldn't be any compliant about: {code} <Host name="::1" .../> {code}
Well if you think so open a upstream bug.
Should be reported upstream
Link: Added: This issue Cloned to JBPAPP-10019
I think, this JIRA should stay in state Open until fix will be in place in EWS.
Link: Added: This issue relates to JBPAPP-9551
Affects: Added: Documentation (Ref Guide, User Guide, etc.),Release Notes
Release Notes Docs Status: Added: Not Yet Documented
Release Notes Text: Added: Tomcat6/7 doesn't allow character ':' in server.xml for hostname specifications. Affects: Removed: Release Notes,Documentation (Ref Guide, User Guide, etc.) Added: Release Notes
Release Notes Docs Status: Removed: Not Yet Documented Added: Documented as Known Issue Writer: Added: mhusnain Release Notes Text: Removed: Tomcat6/7 doesn't allow character ':' in server.xml for hostname specifications. Added: JBoss Enterprise Web Server's version of Tomcat6/7 does not allow the character ':' in server.xml for hostname specifications. Normally, the character is used as a delimiter for IP addresses.
Release Notes Text: Removed: JBoss Enterprise Web Server's version of Tomcat6/7 does not allow the character ':' in server.xml for hostname specifications. Normally, the character is used as a delimiter for IP addresses. Added: JBoss Enterprise Web Server's version of Tomcat6/7 does not allow the character ':' in server.xml for hostname specifications. Normally, the character is used as a delimiter for IPv6 addresses.
Release Notes Docs Status: Removed: Documented as Known Issue Writer: Removed: mhusnain Release Notes Text: Removed: JBoss Enterprise Web Server's version of Tomcat6/7 does not allow the character ':' in server.xml for hostname specifications. Normally, the character is used as a delimiter for IPv6 addresses. Docs QE Status: Removed: NEW
Did this ever get logged upstream? I've searched but did not find a Tomcat bugzilla.
(In reply to comment #4) Pavel, > There isn't any objection to have: > {code} > <Host name="127.0.0.1" .../> > {code} > and therefore there shouldn't be any compliant about: > {code} > <Host name="::1" .../> > {code} Yes, there is no objection to not have name="::1", but I'd like you to consider one thing. Since there is no upstream bug for this issue, it seems to me that no tomcat user/customer was ever bothered by this flaw to the extent to file a bug for it. If that is the case, I think it is not worth the work and effort that would be put into fixing and testing this issue. I propose to close this bug with NOTABUG resolution.
@Michal You are right, but the root of this issue is some of property fields accept character '.' (used as delimiter for a literal IPv4 addresses), but don't accept ':' (used as group delimiter for a literal IPv6 addresses). I guess, while IPv6 is more and more critical for production environment over the world, this issue will become more and more critical.
A factor of the problem is that some of the property names are used as bits of MBean object names where ":" is not allowed. it makes correcting the problem that much more complicated. That said, i am working on rhbz 900779 where, like tomcat7, the 'address' attribute has been added to the Server element of server.xml. Testing hasn't surfaced any problems using "::1" there.
If you look to jbossweb for the connector we had to add: +++ public String getJmxName() { String encodedAddr = ""; if (getAddress() != null) { encodedAddr = "" + getAddress(); encodedAddr = URLEncoder.encode(encodedAddr.replace('/', '-').replace(':', '_').replace('%', '-')) + "-"; } return ("http-" + encodedAddr + endpoint.getPort()); } +++ To get a name that can be used as ObjectName... I am not sure we should do that for all properties of server.xml.
Giving qa_ack+ in case devel_ack- will be cleared.
that's simple to apply for this case. i've set devel_ack+. the change will be applied to both tomcat6 and tomcat7 as needed.
Added DocText. @David, can you please review the Doc Text content?
Excluded from Release Notes as part of the internal group.
lowering the priority because this problem can be overcome with proper configuration of default host.
It isn't about configuration of default host. It is about the fact we can't use literal IPv6 addresses in the same way how we can use IPv4's one. Product (including Tomcat6) is fully certified under IPv6, so this is real defect (known issue at least) and we should document it (if the decision is we don't fix it).
This will be known issue with workaround in 2.0.1 release notes, not bug fix.
Adding release note for a known issue but the workaround is unclear. Can someone provide this information?
I did a slight modification of RN text, please correct more (especially grammar) if needed. Thank you.
My mistake, for some reason I did not notice the Red Hat internal group for this one. Unfortunately as it is internal only, it cannot be included in public release notes. Removing flag.
I think, it is a mistake that this BZ is marked as Private itself. This bug should be documented in RN of EWS 2.0.1. Libor, can you clarify it please?
I agree, this should be public and in release notes
I don't agree on the text of the doc, the problem is a _hostname_ shouldn't be an IP address (and it is unfortunate that a IPV4 address is accepted there). That is not really a bug that is a misuse of a field that should just contains an alpha numeric string.
Jean-frederic, could you please clarify about what attribute you are speaking now? Because there are several a such attributes, but nowhere we can place literal IPv6 addresses. If placing there literal IP address (either IPv4 or IPv6) is only misuse of a such field, why this bad practice is supported in Tomcat over decade? Why isn't a such practice banned by un-accepting a such server.xml? I don't agree _hostname_ has to be a alphabetical sequence of characters, but I can be wrong. From which RFC this requirement comes?
1- "nowhere we can place literal IPv6 addresses" Wrong in address no problem it is the only place with IP address should be. 2 - blame me :-( 3 - It is just a good practice usually most customer have localhost (or defaulthost) there.
I fully agree with you, but how we should describe this meaning to customers without confusing them?
Attempt to make it public.
we should report the BZ upstream and see what happens with it.
i'm considering closing this as not-a-bug. An IP addy should not be used as a defaulthost name in the Engine element, nor should an IP addy be used as the name in the Host element. The attribute is supposed to be a name. Because ipv4 addy-s work is purely circumstantial. There are no characters in a ipv4 address that mbeans disallow. Users should use a legal name and configure /etc/hosts correctly to correlate the host name with an ip address.
Can we agree on whether this is to be closed as NOTABUG (in which case we should not need to add it to release notes) or if this will be developed and we want to document this as a known issue for 2.0.1? Holding off adding this to release notes till we have a verdict.
This character is normally used as a group delimiter for the IPv6 addressed. ... for the IPv6 addresses
QA have no problem with this, but we have it in release notes 2.0.1 like known issues. So we should move it in release notes 2.0.2 to resolved issues with some note.
made some edits and corrections to doc text.