Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] Official Releases
[CDO] Official Releases [message #1832937] Tue, 29 September 2020 16:24 Go to next message
Gabe Colburn is currently offline Gabe ColburnFriend
Messages: 28
Registered: December 2012
Junior Member
I just wanted to confirm that the following are official releases from the downloads page:
4.9 (R20200311-1513)
4.10 (R20200610-0035)
4.11 (R20200902-0430)

The reason I ask is we were testing updating our production systems from 4.7 (R20180613-0111) to 4.11 (R20200902-0430) and had a number of new errors being generated. We tried 4.10 and couldn't even get the CDO server to connect, but no errors were being generated. We tried 4.9, and it works no problem and doesn't generate any new errors. We will continue testing and likely move to 4.9 until we can figure out why the newer builds don't seem to be working for us.

I assume these are official releases that shouldn't have any significant new bugs?

Re: [CDO] Official Releases [message #1832959 is a reply to message #1832937] Wed, 30 September 2020 05:13 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6659
Registered: July 2009
Senior Member
Yes, they're all official releases. I hope that new releases are better than older ones, but of course they also can contain new bugs. I'm not aware of any such bugs, though.

In particular 4.10 ( ) contains a few small but fundamental changes in the network transport protocols that require both clients and servers be updated. But this is always recommended/required, so I'm not sure if this causes your problems.

What are your error messages?

Re: [CDO] Official Releases [message #1833073 is a reply to message #1832959] Thu, 01 October 2020 17:54 Go to previous messageGo to next message
Gabe Colburn is currently offline Gabe ColburnFriend
Messages: 28
Registered: December 2012
Junior Member
Hi Eike,
Thanks for your response.

I had to add some additional logging to see the root errors our system produces with 4.10 and 4.11. After adding some logging, the TCPClientConnector raises a host == null exception when creating the connector:

java.lang.IllegalStateException: host == null
        at org.eclipse.net4j.internal.tcp.TCPClientConnector.doBeforeActivate(
        at org.eclipse.net4j.util.lifecycle.Lifecycle.internalActivate(
        at org.eclipse.net4j.util.lifecycle.ShareableLifecycle.internalActivate(
        at org.eclipse.net4j.util.lifecycle.Lifecycle.activate(
        at org.eclipse.net4j.util.lifecycle.LifecycleUtil.activate(
        at org.eclipse.net4j.util.lifecycle.LifecycleUtil.activate(
        at org.eclipse.net4j.util.container.ManagedContainer.activateElement(
        at org.eclipse.net4j.util.container.ManagedContainer.getElement(
        at org.eclipse.net4j.util.container.ManagedContainer.getElement(
        at org.eclipse.net4j.Net4jUtil.getConnector(
        at org.eclipse.net4j.Net4jUtil.getConnector(
        at org.eclipse.net4j.Net4jUtil.getConnector(

Here is the code we use to create the connector:
IPluginContainer container = IPluginContainer.INSTANCE;
String serverName = "dev_cdo-server";
IConnector connector = Net4jUtil.getConnector(container, "tcp://" + serverName );

In the TCPConnectorFactory (line 42) the host seems to not get extracted:

  public TCPConnector create(String description)
    ConnectorData data = new ConnectorData(description);

    TCPConnector connector = createConnector();
    return connector;


The cdo server runs as docker container and the server name resolves via DNS as the container name. This has worked no problem for a number of years with CDO.

With our current naming convention for the container, it appears that the characters '_' and '-' cause the parser to only set the authority to the servername, and the host as null. If you remove those characters it sets the authority and host to the server name.

Since the ConnectorData uses uri.getHost() and not authority (not saying that is necessarily the right approach, although it maybe an option), we get the IllegalStateException.

It appears that the connector data parser used to use URL and an "http://" scheme and now uses URI and "tcp://" resulting in the different behavior in parsing the hostname. The change appears to have been made when introducing websocket support in this commit:

Here are some simple test cases illustrating the change in behavior for getHost():

try { uri1 = new"tcp://dev_cdo-server:8000");
	assert uri1.getAuthority().equals("dev_cdo-server:8000");
	assert uri1.getHost() == null; 
	assert uri1.getPort() == 8000;
} catch (URISyntaxException e) {
try { uri2 = new"tcp://dev_cdoserver:8000");
	assert uri2.getAuthority().equals("dev_cdoserver:8000");
	assert uri2.getHost() == null; 
	assert uri2.getPort() == 8000;
} catch (URISyntaxException e) {
try { uri3 = new"tcp://devcdoserver:8000");
	assert uri3.getAuthority().equals("devcdoserver:8000");
	assert uri3.getHost().equals("devcdoserver");
	assert uri3.getPort() == 8000;
} catch (URISyntaxException e) {

try { url1 = new"http://dev_cdo-server:8000");
	assert url1.getAuthority().equals("dev_cdo-server:8000");
	assert url1.getHost().equals("dev_cdo-server"); 
	assert url1.getPort() == 8000;
} catch (MalformedURLException e) {

try { url2 = new"http://dev_cdoserver:8000");
	assert url2.getAuthority().equals("dev_cdoserver:8000");
	assert url2.getHost().equals("dev_cdoserver"); 
	assert url2.getPort() == 8000;
} catch (MalformedURLException e) {
try { url3 = new"http://devcdoserver:8000");
	assert url3.getAuthority().equals("devcdoserver:8000");
	assert url3.getHost().equals("devcdoserver");
	assert url3.getPort() == 8000;
} catch (MalformedURLException e) {

Would you consider this a new bug?

Thanks in advance, and thanks for your work on CDO!
Re: [CDO] Official Releases [message #1833088 is a reply to message #1833073] Fri, 02 October 2020 05:11 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6659
Registered: July 2009
Senior Member
This issue is annoying but also a bit interesting. I found out the following:

According to RFC2396 (URI Generic Syntax), section 3.2.2. (Server-based Naming Authority), the hostname MUST NOT contain underscore characters:

hostport      = host [ ":" port ]
host          = hostname | IPv4address
hostname      = *( domainlabel "." ) toplabel [ "." ]
domainlabel   = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel      = alpha | alpha *( alphanum | "-" ) alphanum
IPv4address   = 1*digit "." 1*digit "." 1*digit "." 1*digit
port          = *digit

This is in line with RFC1034 (Domain Concepts and Facilities), section 3.5. (Preferred name syntax):

<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case
<digit> ::= any one of the ten digits 0 through 9

I think we can conclude that your hostname "dev_cdo-server" is INVALID because it contains an underscore character (and not because it contains a hyphen character). For example, "dev-cdo-server" is a valid hostname. In case you're not happy with my wording "invalid", think of it as "invalid w.r.t the aforementioned RFCs" ;-)

The class is very strict about RFC2396, so I wondered why we see no exception being thrown when you pass in your hostname with the underscore character. The reason is RFC2396, section 3.2.1. (Registry-based Naming Authority):

authority     = server | reg_name
reg_name      = 1*( unreserved | escaped | "$" | "," |
                          ";" | ":" | "@" | "&" | "=" | "+" )

I.e., your complete URI (with the underscore character) is not invalid. It's just not a "Server-based Naming Authority", but falls back to a "Registry-based Naming Authority". In fact internally throws a URISyntaxException with the expected message:

Exception in thread "main" Illegal character in hostname at index 9: tcp://dev_cdo-server:8000
	at java.base/$
	at java.base/$Parser.parseHostname(
	at java.base/$Parser.parseServer(
	at java.base/$Parser.parseAuthority(
	at java.base/$Parser.parseHierarchical(
	at java.base/$Parser.parse(

Because of the section 3.2.1. loophole this exception is caught higher up in the call chain. I learned now that you can explicitly provoke this exception with the following code: uri = new"tcp://dev_cdo-server:8000");

Go figure!

BTW., according to RFC2396, section 1.2. (URI, URL, and URN), URLs are a subset of URIs. It just happens that Java's parser for URLs,, is much more lax than its URI counterpart.

You're right that your problem is caused by this change in Net4j: . Notice the former "//TODO Don't use URL". I still think that it's better to use for parsing because it doesn't rely on a registered protocol/URLStreamHandler. But I can offer to provide a system property that you can use to switch back to the legacy behavior, in case you can't/don't want to change your hostname to be RFC2396-compliant. Please submit a bugzilla then.

Re: [CDO] Official Releases [message #1833184 is a reply to message #1833088] Mon, 05 October 2020 23:03 Go to previous message
Gabe Colburn is currently offline Gabe ColburnFriend
Messages: 28
Registered: December 2012
Junior Member
Thanks Eike. It probably makes most sense for us to remove the '_' to make it compliant. I'll let you know if we need a legacy flag. Thanks for offering that. We will try to avoid going down that route for now if feasible.

Previous Topic:Ecore containment property.
Next Topic:Loading / deserializing non-transient derived features
Goto Forum:

Current Time: Sun Jan 29 10:38:55 GMT 2023

Powered by FUDForum. Page generated in 0.13281 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top