• Bug
  • Status: Resolved
  • 2 Major
  • Resolution: Fixed
  • teck
  • Reporter: zaraki
  • January 31, 2011
  • 1
  • Watchers: 5
  • June 25, 2013
  • October 19, 2012


I am using the terracotta-trunk-nightly-rev17042 a Jan 2011 build. So we are currently using Felix OSGI. With Standalone ehcache there were no issues but in the terracotta clustered mode things break down.

I found that I was able to start up TC with Equinox OSGI which was suggested in http://forums.terracotta.org/forums/posts/list/3529.page dated April 2010. I noticed the same : Code: Caused by: java.io.IOException: FakeURLStreamHandler can not be used! at org.apache.felix.framework.FakeURLStreamHandler.openConnection(FakeURLStreamHandler.java:39) at java.net.URL.openConnection(URL.java:945) at java.net.URL.openStream(URL.java:1010) at org.terracotta.express.ClientFactoryImpl.(ClientFactoryImpl.java:49)

Now upon investigating more I came across http://www.mail-archive.com/[email protected]/msg04556.html the Apache felix mailing list which outlined the cause of the exception as using the code source url to refer to jars, which according to them is not part of the OSGI spec. So, In short the current implementation of terracotta seems to be relying on a Equinox OSGI specific solution.


Tim Eck 2011-01-31

This problem will effect all express usage in felix I believe.

Fiona OShea 2011-01-31

Is this easy to fix?

Phillip Kruger 2011-09-07

This seems to effect using terracotta in glassfish 3.1.1 (when loading it as an OSGi bundle) as glassfish use felix. Are there a workaround ?

Phillip Kruger 2011-09-07

To solve the issue in Glassfish follow this http://blogs.oracle.com/arungupta/entry/totd_103_glassfish_v3_with to change the OSGi implementation from Felix to Equinox

Antony Hutchison 2011-10-04

This has been raised on the Felix Jira issue tracker:


and I’ve put together some sample files that demonstrate this with Felix Framework 4.0.0 - these are downloadable from https://public.me.com/antonyhutchison

We are seeing this issue in Adobe Day CQ5 WCM; we have no option to switch OSGi implementations.

Thanks, Antony

Tim Eck 2012-10-19

I believe the new classloading scheme in trunk should fix this. We no longer use codesource to discover the toolkit runtime contents

Chris Geer 2012-10-20

Tim, can you provide any more details on how to get access to the “fixed” version and what version that would be? I’m assuming trunk would be 2.7.0-SNAPSHOT but there aren’t any 2.7.0-SNAPSHOT versions in the maven repo.

Tim Eck 2012-10-23

This bit of pom.xml I think should help you get access to this new stuff:



Tim Eck 2012-10-23

It would be fantastic if you can confirm things load correctly in felix now :-)

Chris Geer 2012-10-25


Well, I’ve been able to mangle together something that is starting to look promising but I think I’m still doing something wrong. When I include just the two dependencies you listed above I get errors about not being able to find classes from the com.terracotta.express package. When I add terracotta-toolkit-1.6-runtime 5.1.0-SNAPSHOT, I can successfully load the client but I get errors loading the configuration from the server. No matter what server config I use I get this error (using terracotta 3.7.0 server - maybe I need to upgrade my server to 3.8.0? Where would I get that?):

Caused by: com.tc.config.schema.setup.ConfigurationSetupException: ******************************************************************************* The configuration data in the base configuration from server at ‘localhost:9510’ does not obey the Terracotta schema: [0]: Line 333, column 5: Element not allowed: application in element [email protected]://www.terracotta.org/config


at com.tc.config.schema.setup.StandardXMLFileConfigurationCreator.getConfigFromSourceStream(StandardXMLFileConfigurationCreator.java:493)
at com.tc.config.schema.setup.StandardXMLFileConfigurationCreator.loadConfigurationData(StandardXMLFileConfigurationCreator.java:419)
at com.tc.config.schema.setup.StandardXMLFileConfigurationCreator.loadConfigDataFromSources(StandardXMLFileConfigurationCreator.java:235)
at com.tc.config.schema.setup.StandardXMLFileConfigurationCreator.loadConfigAndSetIntoRepositories(StandardXMLFileConfigurationCreator.java:124)
at com.tc.config.schema.setup.StandardXMLFileConfigurationCreator.createConfigurationIntoRepositories(StandardXMLFileConfigurationCreator.java:108)
at com.terracotta.toolkit.express.StandaloneL1Boot.resolveEmbedded(StandaloneL1Boot.java:144)
at com.terracotta.toolkit.express.StandaloneL1Boot.resolveConfig(StandaloneL1Boot.java:106)

Tim Eck 2012-10-26

The I gave above are for 3.8.0-SNAPSHOT client and server. It doesn't look like a 3.8.0-SNAPSHOT server is readily available unfortunately as that release is undergoing a lot change right now.

I’m confused why you’d get a schema exception like that using terracotta-toolkit-1.6-runtime 5.1.0-SNAPSHOT, but since I think only the trunk version of the new toolkit will avoid this issue in felix I don’t think it is worth it to track it down.

I think I can put together a 3.8.0-SNAPSHOT distribution that I can share with you. At least for the purposes of testing this felix aspect. We definitely have changes to the xml schema for tc-config.xml in this release. If you don’t mind sharing your tc-config.xml I can help you adjust it. Alternatively if you don’t mind sharing your entire test application we could work on it together.

Can you contact me at teck terracotta.org if you're interested in working a little more closely as described?

Michael Dop 2013-05-15


Is there any further information on either a work around or a fix that will be coming up in the future. We are running into the same issue with:

Caused by: java.io.IOException: FakeURLStreamHandler can not be used!

I have built a bundle that is osgi compliant which includes the ehcache-core, ehcache-terracotta, and the terracotta-toolkit. We are using ehcache 2.6.5 and terracotta server 3.7.4.

I am also confused on the conflicting bug reports CDV-1547, CDV-1652. They seem to be the same issue to me. This one says that it is fixed, while 1652 says unresolved. Any information would be greatly appreciated.

Thanks, Michael

Chris Geer 2013-05-15

This is definitely not resolved. In Tim’s last comment he asked me to work with him offline which I did and he provided a beta copy of terracotta 3.8 and ehcache 2.7. Using those we were able to get it to work but it looks like those still haven’t been released. On March 4th, Ehcache was released but it looks like it’s been pulled form the website now. The announcement is there but the download points to 2.6.6.



Tim Eck 2013-06-25

It is my believe that this is resolved starting with terracotta core (aka toolkit/big-memory-max) version 4.0.0+ coupled with ehcache 2.7.0+

terracotta 3.8.x never saw the light of day and the fixes have not been backported to 3.7.x / ehcache-2.6.x