• New Feature
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • teck
  • Reporter: nestrada
  • April 27, 2011
  • 0
  • Watchers: 2
  • July 27, 2012
  • October 13, 2011

Attachments

Description

Hello,

I’m successfully using the Toolkit to much use for basic operations. And I’ve successfully clustered my own objects using the Ehcache TIM and other examples. I’m operating in an OSGi environment which makes this a bit tricky though.

The way I cluster my own objects is by creating a TIM jar nested in the META-INF/terracotta/TIMs path within an OSGi bundle. I also make use of the public-api-types file located at META-INF/terracotta to instruct the {{ClusteredStateLoader}} that these classes are to be loaded by my application, ie. the client bundle.

Now in my use case I’ve “OSGified” the terracotta toolkit API jar and it now registers the {{ClusteringToolkit}} as a service, so for all intents and purposes has its own {{ClassLoader}}. Yet whenever a client bundle attempts to create a new Client with self as an introspection source (so far so good) when it attempts to instanciate a Clustered custom object for instance, the operation fails because the public-api-types files declares classes/interfaces which are not visible to the Terracotta toolkit bundle.

Simply put, when the {{ClientFactoryImpl}} creates a new instance of {{ClientImpl}}, passing the {{getClass().getClassLoader()}} as the {{appClassLoader}} is insufficient. Of course I could add an “dynamic-import: *” entry within the MANIFEST of the Terracotta bundle but this only works if the package in question is being exported, which it isn’t.

I was able to “patch” the {{ClientFactoryImpl}} to support my special use-case by passing a {{BundleClassLoader}} which I’ve joined in my attached {{ClientFactoryImpl}} (BTW I’m still using Toolkit v2.1.0) but this is rough hack and I would simply prefer at best that the introspection modules passed to a Client be also “merged” into the appClassLoader for resolving classes.

Any thoughts would be greatly appreciated. Thanks.

Nicolas

Comments

Fiona OShea 2011-05-03

Tim do you have any thoughts on this? Suggestions?

Tim Eck 2011-05-16

I’m not sure I completely understand the issues at play here but a high level it sounds like you want to logically configure the loader called “appClassLoader” to also delegate to some other loader (in your case an osgi bundle loader different than the one hosting the toolkit runtime).

That doesn’t too hard to do and I could see either lifting this loader reference(s) from the introspection sources, or adding an explicit parameter to the createClient() methods.

At least for the picture in my head, we’d still prefer the defining loader of the toolkit runtime in the places where delegate to the appLoader but a CNFE would then next delegate a client specific “appClassLoader”

Not sure if you were implying this, but compiling against osgi libraries (ie. BundleClassLoader) in the toolkit code doesn’t immediately seem like something we’d do.

I’ll make a patch to see if it matches what you’re thinking

Tim Eck 2011-05-16

A quick (untested) patch against https://svn.terracotta.org/repo/forge/projects/terracotta-toolkit/trunk

Nicolas Estrada 2011-07-22

I finally got around to migrating to 3.5.2 from 3.4.1 and I integrated your patch to the letter on the 3.5.2 toolkit tag and it works like a charm ;) No dependencies to the OSGi API. Thanks again ;)

To refresh your memory, I’m providing using an embedded TIM in an OSGi bundle some clustered classes to a TerracottaClient being provided as a OSGi service to the framework. Works great!