Terracotta Discussion Forums

Ryan, would you tell me which web-container you were trying to use, as specified in the File->Servers dialog?

Also, how were you starting Configurator? Using the script or from the SampleLauncher?

Are you saying that even after adding the required system properties to your test.ini, and making sure a Terracotta server is running, executing test.exe is still failing?

Just to be clear:

(1) you need to add the following to test.ini, in addition to the -Xbootclasspath entry:

-Dtc.install-root=C:\Program Files\Terracotta\terracotta-2.3-stable1
-Dtc.config=C:\Program Files\Terracotta\terracotta-2.3-stable1\samples\tc-config.xml

You can't run a DSO client without providing a config specification, so above I'm specifying the demo config.

(2) Start the demo server:

$ C:\Program Files\Terracotta\terracotta-2.3-stable1\samples\start-demo-server.bat

You can't run a DSO client without having an active Terracotta server for it to connect with.

I made these changes with the example you posted, and it worked fine.

I'll check, but what SHOULD happen if you export your real DSO RCP app is that the DSO plugin should be included, and those system properties should be automatically added to test.ini. It's not clear that is what you would want with respect to including the DSO plugin. You may prefer to install the regular kit on each client machine. Either way, it just takes changing the value of tc.install-root in test.ini.

There are two problems here. First, you need to have a server running or your client will endlessly try to connect and the window will never appear. Second, you need to specify -Dtc.install-root and -Dtc.config in test.ini. Failing to specify either of these will cause a runtime error, which you see if you run the app like so:

java -Xbootclasspath/p:<bootjar-path> -jar startup.jar -name Test

java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.createGlobalContext(ClassProcessorHelper.java:391)
at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.init(ClassProcessorHelper.java:284)
at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.defineClass0Pre(ClassProcessorHelper.java:421)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
Caused by: com.tc.config.schema.setup.ConfigurationSetupException:
*******************************************************************************
You must specify the location of the Terracotta configuration file for this process, using the 'tc.config' system property.
*******************************************************************************

at com.tc.config.schema.setup.StandardTVSConfigurationSetupManagerFactory.<init>(StandardTVSConfigurationSetupManagerFactory.java:98)
at com.tc.config.schema.setup.StandardTVSConfigurationSetupManagerFactory.<init>(StandardTVSConfigurationSetupManagerFactory.java:50)
at com.tc.config.schema.setup.StandardTVSConfigurationSetupManagerFactory.<init>(StandardTVSConfigurationSetupManagerFactory.java:44)
at com.tc.object.bytecode.hook.impl.DSOContextImpl.getGlobalConfigHelper(DSOContextImpl.java:163)
at com.tc.object.bytecode.hook.impl.DSOContextImpl.createGlobalContext(DSOContextImpl.java:61)

The trunk AdminConsole can now display enums correctly.

I'm not sure that is a mutable enum. I think what you're seeing is that roots cannot be reassigned. See http://www.terracotta.org/confluence/display/docs1/Concept+and+Architecture+Guide#ConceptandArchitectureGuide-Roots

If you declared the enum value a bit deeper in the root object graph, I think you'll see it can be changed. Stick it in a HashMap or another type that is the root.

Regarding the AdminConsole, yes, I've made the fix but I haven't pushed it yet.

Regarding getting your Eclipse application to launch, in the launch configuration Main tab you must select 'Program to run' -> 'Run an application' and choose your Eclipse application name.

Regarding sharing data across Eclipse applications (plugins), Terracotta needs to be able to determine the classloader from which a shared object has been created. That is done by giving classloaders names. Everything is fine for a regular application because most everything comes from either the boot- or application-classloader. With plugins things are more complicated, since each plugin is loaded by it's own classloader.

So, to share data across plugins, each plugin needs to use some Terracotta code to name the classloader of the plugin. To accomplish this, add the following code to each of your Terracotta-ized plugin activators:

static {
NamedClassLoader ncl = (NamedClassLoader) Activator.class.getClassLoader();
ncl.__tc_setClassLoaderName("plugin:"+PLUGIN_ID);
ClassProcessorHelper.registerGlobalLoader(ncl);
}

The above assumes you are using the standard plugin project template that creates an Activator type defining a PLUGIN_ID. You can get this to compile by building a boot jar via the Terracotta menu and adding it to your project build path.

I've added a demonstration of using DSO across multiple Eclipse applications in our forge labs SVN repository here:

https://svn.terracotta.org/repo/forge/projects/labs/eclipse-apps

The 2.3 Configurator on Linux is working fine for me.
Do you happen to have the TC_CONFIG environment variable set to something? That's about the only way -Dtc.config=9081 could be getting set like that.

Check the environment in which your running the Configurator for anything TC_*.

The plugin will always ensure that a local server is running, and it uses the first named server it finds in the config for that. I guess it may be wrong that it automatically does this and I'll remove it if the community agrees.

To accomplish your goal you should have your client get its config from the remote server. Start your remote servers with the config you currently have in your Eclipse project and then add -Dtc.config=server1-host:server1-dso-port,server2-host:server2-dso-port to your client's launch configuration VM arguments. You can find your launch configuration in the Debug... or Run... dialog under the Terracotta DSO JUnit Test section.

So, the local server will still be started, but the client will get its config from a remote server and connect to the servers listed there.

Since you have declared multiple servers I assume that you're trying out clustered servers in persistent mode with a shared data directory.

Yes, you need to create a bootjar for 1.6.

Update: the use of JMX is no longer optional, so a jmx-port must be specified.

We don't document the contents of tc.properties as it's considered internal, configurable implementation details. It's a sort of staging area for properties that may ultimately be moved out into the public (XML) configuration file.

By the time the feature is completed, it will be configurable in the standard way.

I'm sorry to say I haven't been following closely the current state of the AWT-SWT bridge, as we're going to go all SWT in the plugin soon.

For now I can only suggest using a different platform or wait until the updated all-SWT plugin is ready in our nightly builds of trunk. I'm working on cleaning it up right now.

The Config Editor uses Swing and that is problematic in several ways, including the types of problems you're seeing on the Mac. Eclipse uses another GUI framework called SWT. You need to make sure you have the most current AWT-SWT bridge, which can be downloaded here: http://connect.apple.com

In our next major release the Swing stuff will be replaced with SWT, making the Mac version of the plugin a first-class citizen.

Just to be clear:

(1) you need to work around the aforementioned JIRA issue by having a tc.properties in the lib directory that includes the session.serverid key.

(2) you need to override that value by passing -Dcom.tc.session.serverid=.N as a system property to your web container.

I've validated that it works in the 2.3-stable release.

The problem with getting the system property to work is described here:

https://jira.terracotta.org/jira/browse/CDV-228

I've attached a version of tc.properties with the session.serverid property uncommented. Place it in the lib directory and you should be able to override properly.