Google App Engine (GAE) is an interesting platform that aims to allow for the development and hosting of Java, Python, and Go web applications.  The pricing scheme is particularly nice:  low-usage applications are hosted for free, pricing is solely dependent on resource usage (with the ability to set budgets and limits), and the minimum charge is only $2.10 per week.  No, I’m not affiliated with or being compensated by Google, but I do think this platform has some potential.

Google supplies a nice Eclipse plugin for use with the Google Web Toolkit and the App Engine, which allows for pretty easy construction of your standard web applications.  I’ve heard that it’s fairly easy to construct user interfaces, JSP pages, etc., but that’s not what we’re talking about here.

The Task

How can we build an application that uses the Google App Engine which uses SOAP for an API?  The primary problem (for me) is that one cannot use the Axis2 libraries (on the server side) due to permission issues, so things must be done a little more manually.

Google has an article covering the topic, but I wanted to do things slightly differently.  Specifically, I wanted to be able to create my service class in Java, generate the WSDL (with appropriately named fields in the XML types – not Parameter1,2,…), generate XML types which will be shared between the server and client projects, and to do it in such a way that I do not have to worry about keeping track of QNAMEs or other low-level details.

Requirements

For this project, I use:

• Eclipse for development, with the Eclipse plugin for GAE

• Axis2 for the client class (also for the java2wsdl and wsdl2java tools)

• JAXB for XML types (auto-generated by Axis2)

The Server

Overview of the Process

Here’s the logic flow for the server:

1. SOAP request arrives via Post into a HttpServlet.

2. HttpServlet builds a SOAPMessage for the request, and passes it to the SoapHandler class.

3. SoapHandler unmarshalls the XML message object, detects its type, and passes a specific application request to the ServiceAdapter class.

4. ServiceAdapter translates from the XML request message (in a safe fashion) to the Service method call.

5. Service method is run, business logic is performed, all the magic happens.

6. ServiceAdapter translates Service method response to XML response message.

7. SoapHandler builds SOAPMessage response (including catching thrown exceptions and turning them into SOAP Fault messages).

8. HttpServlet writes response to client.

All of that seems like a lot of work, but it’s pretty straightforward.  The best part?  I’ll give you the skeleton for all of this; there’s not much application-specific content in all of this.  The process for adding a method to your service class is: implement service class method, run Axis2 generators, modify/fix Axis2 client (the same every time, some auto-gen code must be changed), add 2 lines to SoapHandler, add an adaption method to SoapAdapter, and add a method to the client class.  It’s easier than it sounds.

Part 1 – The HttpServlet

Good news!  There’s no service specific code here.  I’ll just post the relevant parts of what I use:

public class SOAPServerServlet extends HttpServlet {
	public static final String URL = "http://ms4models.appspot.com/service";

	private static final Logger log = Logger
		.getLogger(SOAPServerServlet.class.getName());
	private static MessageFactory messageFactory;
	private static ServiceSOAPHandler soapHandler;

	static {
		try {
			messageFactory = MessageFactory.newInstance();
			soapHandler = new ServiceSOAPHandler();
		} catch (Exception ex) {
			throw new RuntimeException(ex);
		}
	}

	@Override
	public void doPost(HttpServletRequest req, HttpServletResponse resp)
			throws IOException {
		log.info("SOAPAction: " + req.getHeader("SOAPAction"));
		log.entering("SOAPServerServlet", "doPost", new Object[] {
				req, resp });
		try {
			// Get all the headers from the HTTP request
			MimeHeaders headers = getHeaders(req);

			// Construct a SOAPMessage from the XML in the request body
			InputStream is = req.getInputStream();
			SOAPMessage soapRequest = messageFactory.createMessage(headers, is);

			ByteArrayOutputStream out = new ByteArrayOutputStream();
			soapRequest.writeTo(out);
			String strMsg = new String(out.toByteArray());

			log.finer("SOAP request: " + strMsg);

			// Handle soapReqest
			SOAPMessage soapResponse = soapHandler
					.handleSOAPRequest(soapRequest);

			// Write to HttpServeltResponse
			resp.setStatus(HttpServletResponse.SC_OK);
			resp.setContentType("text/xml;charset=\"utf-8\"");
			OutputStream os = resp.getOutputStream();
			soapResponse.writeTo(os);
			os.flush();
		} catch (SOAPException e) {
			throw new IOException("Exception while creating SOAP message.", e);
		}
		log.exiting("SOAPServerServlet", "doPost");
	}

	@SuppressWarnings("rawtypes")
	static MimeHeaders getHeaders(HttpServletRequest req) {
		Enumeration headerNames = req.getHeaderNames();
		MimeHeaders headers = new MimeHeaders();
		while (headerNames.hasMoreElements()) {
			String headerName = (String) headerNames.nextElement();
			String headerValue = req.getHeader(headerName);
			StringTokenizer values = new StringTokenizer(headerValue, ",");
			while (values.hasMoreTokens()) {
				headers.addHeader(headerName, values.nextToken().trim());
			}
		}
		return headers;
	}
}

Leave a comment if you have a question about what’s going on, I’ll not explain it for brevity’s sake (also: because I am lazy).

Coming Soon – Part 2

To set the repositories manually, you can use the same technique as the P2 property page:

import org.eclipse.equinox.internal.p2.ui.model.MetadataRepositoryElement;
import org.eclipse.equinox.internal.p2.ui.model.ElementUtils;

@SuppressWarnings("restriction")
public class P2Util {
  private static String UPDATE_SITE = "http://www.example.com/update_site";

  public static void setRepositories() throws InvocationTargetException {
    try {
      final MetadataRepositoryElement element = new MetadataRepositoryElement(null, new URI(UPDATE_SITE), true);
      ElementUtils.updateRepositoryUsingElements(new MetadataRepositoryElement[] {element}, null);
    } catch (URISyntaxException e) {
      e.printStackTrace();
      throw new InvocationTargetException(e);
    }
  }
}

Note that you need all of the repositories to be present in the

ElementUtils.updateRepositoryUsingElements

call; repositories not in that array will be removed.

I’m currently working on a fairly involved Eclipse RCP project which makes heavy use of Xtext for grammar parsing.  One task that’s come up fairly often is that we need to be able to perform some action on a model object contained in an Xtext file.  For example, we want to provide context menu commands to open up a view to display the structure of a model; to do this we need to load the file, parse it with Xtext, and pass the model object off to the view.

The Xtext FAQ provides instructions for doing this in a standalone Java here, but it involves calling the StandaloneSetup method to create and obtain an injector, which isn’t the best for performance.  If we’re already in a RCP application that includes our Xtext language’s UI plugin, we can efficiently obtain the injector from the activator.  In addition to this, we can wrap the whole thing in a class that ties into Eclipse’s adapter manager framework so that other plugins can load our Xtext models without needing a direct dependency on the UI plugin (though of course they still need to depend on the plugin that  defines the model classes).

The Eclipse adapter framework: IAdapterFactory, IAdaptable, and IAdapterManager

In a nutshell, the Eclipse adapter framework works by letting plugins register ‘adapter factory’ classes (that implement IAdapterFactory).  These classes are designed to attempt the singular task of taking and object of some source class and figuring out how to transform it into an object of another target class.  If the transformation is possible, the AdapterFactory must return an object that can be cast as an instance of the target class.  If it is not possible, the AdapterFactory must return null.  In addition, AdapterFactory classes implement a method that returns a list of all target classes supported by the factory, and their defining plugin must provide an extension to org.eclipse.core.runtime.adapters specifying what transformations can be performed.  Traditionally, objects that support being adapted implement the IAdaptable interface, but this is not strictly required.

Once an adapter has been registered that can perform a transformation, any plugin can use this with a simple call:

final TargetObjType target = (TargetObjType)Platform.getAdapterManager().getAdapter(sourceObject, TargetObjType.class);
if (target==null) { /* Adaptation failed */ }

The caller is guaranteed that getAdapter will either return null or an object that can be cast as TargetObjType.

The ModelLoadingAdapter

To create a ModelLoadingAdapter, we must implement the code to load domain models from files and register this in plugin.xml.  As an easy extension we will also let the same adapter handle selections and structured selections (allowing us to directly adapt a list selection to a domain model, if the item selected is a file).  After this is done, any plugin can easily load Xtext DSL models from files with a minimum performance hit.

For this example we’re going to assume the projects are called “org.xtext.example.mydsl” and “org.xtext.example.mydsl.ui”, the language is called “org.xtext.example.mydsl.MyDsl”,  it uses files with extension “mydsl”, and the root model of a document is a DslModel.

The IAdapterFactory

Our actual adapter must do three things:  Obtain the Injector for our DSL, use the injector to obtain a properly initialized XtextResourceSet, and use the resource set to load the file.

Obtaining the domain-specific language injector

Update: From the comments below, the easy/correct way to use injection in Eclipse RCP/plugin projects is to make use of the ExecutableExtensionFactory class. If you specify, in plugin.xml, the name of your AdapterFactory class as “ExecutableExtensionFactory:AdapterFactory” then you do not need to manually get the injector. You can just specify a private class variable using “@Inject
private XtextResourceSetProvider resourceSetProvider;”

When Xtext generates the .ui project, it creates an activator for this plugin that is responsible for creating and storing the Injector for this language.  We can retrieve the injector from this class using the getInjector method, which takes the name of the language as an argument and either returns the injector or null.  The code for this would be

final private static Injector injector = MyDslActivator.getInstance().getInjector("org.xtext.example.mydsl.MyDsl");

Loading the model

This is very similar to the FAQ’s instructions, we just omit the creation of the injector and use the one that we retrieve from the activator.

XtextResourceSet resourceSet = (XtextResourceSet) injector
	.getInstance(XtextResourceSetProvider.class)
	.get(file.getProject());
resourceSet.addLoadOption(XtextResource.OPTION_RESOLVE_ALL, Boolean.TRUE);
Resource resource = resourceSet.getResource(URI.createURI(file.getLocationURI().toString()),true);
DslModel model = (DslModel) resource.getContents().get(0);

Putting it all together

The only details we’re missing are relatively minor: error checking, transforming selections to files, and the format required by IAdapterFactory.  Our complete class ends up looking like this:

package org.xtext.example.mydsl.util;

import org.eclipse.core.resources.IFile;
import org.eclipse.core.runtime.IAdapterFactory;
import org.eclipse.emf.common.util.URI;
import org.eclipse.emf.ecore.resource.Resource;
import org.eclipse.jface.viewers.ISelection;
import org.eclipse.jface.viewers.IStructuredSelection;
import org.eclipse.xtext.resource.XtextResource;
import org.eclipse.xtext.resource.XtextResourceSet;
import com.google.inject.Injector;
import org.xtext.example.mydsl.myDsl.DslModel;
import org.xtext.example.mydsl.ui.internal.MyDslActivator;
/* Author: Robert Coop
* See: http://coopology.com/2011/06/easily-load-xtext-files-and-objects-in-eclipse-plugin-or-rcp-projects-using-adapters/
*/
@SuppressWarnings("rawtypes")
public class ModelLoadingAdapter implements IAdapterFactory {
	private static org.apache.log4j.Logger log = org.apache.log4j.Logger
		.getLogger(ModelLoadingAdapter.class);
	final private static Injector injector = MyDslActivator
		.getInstance().getInjector("org.xtext.example.mydsl.MyDsl");

	@Override
	public Object getAdapter(Object adaptableObject, Class adapterType) {
		if (adapterType == DslModel.class) {
			if (injector==null) {
				log.error("Could not obtain injector for MyDsl");
				return null;
			}

			if (adaptableObject instanceof ISelection) {
				final ISelection sel = (ISelection)adaptableObject;
				if (!(sel instanceof IStructuredSelection)) return null;
				final IStructuredSelection selection = (IStructuredSelection) sel;
				if (!(selection.getFirstElement() instanceof IFile))
					return null;
				adaptableObject = (IFile)selection.getFirstElement();
			}
			if (adaptableObject instanceof IFile) {
				final IFile file = (IFile)adaptableObject;
				if (!file.getFileExtension().toLowerCase().equals("mydsl")) return null;

				XtextResourceSet resourceSet = (XtextResourceSet) injector
					.getInstance(XtextResourceSetProvider.class)
					.get(file.getProject());
				resourceSet.addLoadOption(XtextResource.OPTION_RESOLVE_ALL, Boolean.TRUE);
				Resource resource = resourceSet.getResource(URI.createURI(file.getLocationURI().toString()),true);
				DslModel model = (DslModel) resource.getContents().get(0);
				return model;
			}
		}

		return null;
	}

	@Override
	public Class[] getAdapterList() {
		return new Class[] { DslModel.class };
	}
}

Finishing Up

To tie everything together, we just need to modify plugin.xml to tell Eclipse about the adapter, then we can use it to load models easily.  Add the following to plugin.xml

<extension point="org.eclipse.core.runtime.adapters">
      <factory adaptableType="org.eclipse.core.resources.IFile" class="org.xtext.example.mydsl.util.ModelLoadingAdapter">
         <adapter type="org.xtext.example.mydsl.myDsl.DslModel" />
      </factory>
      <factory adaptableType="org.eclipse.jface.viewers.ISelection" class="org.xtext.example.mydsl.util.ModelLoadingAdapter">
         <adapter type="org.xtext.example.mydsl.myDsl.DslModel" />
      </factory>
</extension>

Using our new adapter

Using the adapter from any plugin is very simple.  Given any IFile or ISelection object representing a mydsl file, we can obtain a DslModel using this code

DslModel target = (DslModel)Platform.getAdapterManager().getAdapter(sourceObject, DslModel.class);
if (target==null) { /* Adaptation failed */ }

Final Thoughts

This technique can be applied to any adapter with the advantage of not needing direct dependencies on the plugin providing the adapter factory.  Hopefully this will prove useful to you either because it demonstrates a good way to load Xtext files or it demonstrates some of the adapter framework uses.  Enjoy!

My setup: HTC Inspire 4g, rooted running Cyanomodgen 7; Samba Filesharing on Android app (from marketplace, free, version 110130-market); Ubuntu 11.04 (with samba package installed)

Prerequisites

First, you need a Samba server app for your phone (I’m using https://market.android.com/details?id=com.funkyfresh.samba, which seems to work well enough), then you need to go into your Samba app on the Android and set a netbios name for your phone (e.g. I’m using “bcoop-android”, so replace that with whatever name you set). For security reasons, you also want to set a user (e.g. “bcoop”) and a password required to access the share. If you have the option, you need to give the shared directory a name (on my app the name is fixed as “sdcard”).  You’ll also need to make sure that your computer has a samba client installed (this can be installed in Ubuntu by installing the smbclient package).

Using Netbios for IP address resolution

Secondly, we need to tell the computer to try to perform DNS lookups using netbios names if all else fails. You can tell if you need this step by running the command “ping bcoop-android” (making sure your phone is connected to the same network as the desktop via wireless and that the Samba app on the phone is running). If you receive a “unknown host” error, then the desktop is not able to look up names via netbios, which is a simple fix. Run the command

sudo gedit /etc/nsswitch.conf

and look for the line that starts with hosts:. At the end of this line, add wins. You should end up with the line looking something like:
hosts: files [...] wins

This will tell your machine to use Netbios name lookup if all else fails. You want to make sure to add wins at the end of the string of methods so that it does not check this before other methods. Save the file and close gedit.

Update: After an hour or so, my connection started timing out and I couldn’t remount the share.  I was confused about what was going on, but noticed that when I tried to ping the netbios name I suddenly got a response from a 209.XXX.XXX.XXX IP address, and not from my phone.  Long story short, it turns out that my lovely ISP (Comcast) has a policy of hijacking domain names that don’t exist so that they can redirect browsers to a search page with ads.  A side effect of this is that all DNS resolution requests are answered, regardless of whether they exist or not.  This causes the computer to assume that the request has been answered and not to look at the wins netbios name for a possible IP address.  The solution to this was to put wins just before the dns entry in the hosts line.

You should now be able to run the ping command and have the computer try to ping an IP address (it doesn’t matter if you receive a response or not, we’re just checking to see that the computer can translate the netbios name to the ip address of the phone).

Note: If you’re not able to get this to work, you can still move on, but just use the phone’s IP address instead of netbios name for the server.  It will be necessary to either continually change the IP address to the phone’s IP, tell your router to assign the phone the same IP address always, or to use some other method to ensure that the phone’s IP address remains correct.

Testing things out: Temporarily mounting the phone

To test things out, we need to create a directory to use as a mount point.  Run the command sudo mkdir /media/android to do this (using a different directory if you’d prefer). Now, we want to manually mount the phone in this directory. There are a couple different ways to do this, depending on how you want the file permissions to work.  I’ll list the different commands you can use, and you can see the below section for further discussion about which might be best.  You will need to modify this command with some specifics for your setup, see the section immediately afterwards.

To not allow any other users to access your files (the recommended method)

sudo mount -t cifs //bcoop-android/sdcard/ /media/android  -o user=bcoop,uid=bcoop,gid=bcoop,nounix,file_mode=0770,dir_mode=0770

To avoid using ‘nounix’, but allow others to read (but not write) your files

sudo mount -t cifs //bcoop-android/sdcard/ /media/android  -o user=bcoop,uid=nobody,gid=bcoop

To disable permission checking entirely (anyone can read/write your files)

sudo mount -t cifs //bcoop-android/sdcard/ /media/android  -o user=bcoop,noperm

For all methods

You’ll need to replace some parts of this command with your setup information:

• //bcoop-android/sdcard should be your phone’s netbios name (or IP address) followed by the share name:  //NETBIOS_NAME/SHARE_NAME
• /media/android should be your mount point directory
• user=bcoop should be the user name that you set up on the phone for the Samba share:  user=PHONE_SAMBA_USER
• uid=bcoop,gid=bcoop should be your computer user’s name and group (these are likely the same on a typical setup): uid=COMPUTER_USER,gid=COMPUTER_GROUP
• uid=nobody should be the name of a fake user on your computer

After running the command, you’ll need to enter your sudo password, then your password for the phone’s samba share.  If all goes well, you should see no error messages then be able to run

ls /media/android

and see the contents of your phone. In that case, you’re ready to set the share up permanently. If you don’t mind running the mount command every time, you can just stop here.

Notes regarding file permissions

(This section can safely be skipped if you’re not interested in knowing any background about how things work behind the scene…)

When I was trying this out, the thing that took the most amount of time to figure out is the file permissions used on the phone.  When mounting a SMB (Samba) share, there are a few options when it comes to file permissions: accept the uid/gid (user and group owner id) from the phone, force the uid/gid to map to specific users/groups on the computer, or ignore the permissions reported by the phone entirely.

The most convenient option is to ignore the permissions entirely, but it is also the least secure: it would allow any program or user on your computer to have full access to the files on the phone when it is mounted.  The typical approach is to map the user and group from the phone to be equivalent to your computer user.  However, I noticed something odd about the way the permissions are reported on my setup.  I’m not positive if this is just some eccentricity of my specific setup, but the permissions reported by my phone have the user set with no read/write/execute permission, the group set with full read/write/execute permission, and everyone else set with just read/execute permission.  (For comparison, the typical setup is user with full permission, group with either full or read/execute permission, and everyone else with either read/execute permission or no permissions at all.)  So, if one maps the uid/gid to the computer user’s uid/gid then the result is that the current user will have no permissions at all.  One solution is to map the gid to the computer user’s gid, but to map the uid to some fake/unused user (I used ‘nobody’, which is a standard and safe bet).  This results in you having full access to the phone and other users being able to read but not modify the contents, and has the advantage of retaining the maximum amount of functionality (i.e. it doesn’t disable some behind-the-scenes filesystem functionality).  An alternative solution is to disable ‘CIFS Unix Extensions’ and manually set the file/directory permissions as well as the uid/gid.  This has the advantage of allowing you to explicitly remove read permission from other users if desired, but has the possible disadvantage of disabling something that is required (though I have no idea if that is likely to happen or even really possible; please leave a comment if you know something about this that I don’t).

Setting things up permanently

To permanently save these settings, we need to create a credentials file to safely hold your samba share’s username and password and we also need to add the mount information to /etc/fstab so that the system is aware of the settings.  To safely store your credentials, we want to create a file that only your user can read which holds your username and password.  To do that, run

gedit ~/.android_credentials

and add the following to this file:

username=YOUR_USERNAME
password=YOUR_PASSWORD

Save the file, close gedit, and run the command

chmod 0600 ~/.android_credentials

to make sure that only you can read that file.

Now, to save the information into fstab, run

sudo gedit /etc/fstab

and add the following line to the file:

//bcoop-android/sdcard/	/media/android	cifs	credentials=/home/bcoop/.android_credentials,uid=bcoop,gid=bcoop,nounix,file_mode=0770,dir_mode=0770,user,noauto	0	0

(Note that you may need to change the options if you’d like something other than the recommended method from above, and you’ll need to replace credentials=/home/bcoop/.android_credentials with the correct path to your credentials file. Also note that the trailing slash on //bcoop-android/sdcard/ is very important. If you forget this trailing slash then you cannot unmount the share as a regular user.)

If all goes well you should now be able to run

mount /media/android

and access your phone’s SD card contents in /media/android. Remember that you need to unmount this by running

umount /media/android

when done. Enjoy!

• Getting log4j into the environment
• Classloader errors caused by different versions of log4j classes being loaded by different plugins
• Problems accessing/locating the log4j.properties file

I also had a problem where I wanted to use only Log4J for logging, so I wanted to be sure that all log messages from all plugins in my RCP project were being picked up by the logging framework.

A log4j bundle is available in the Eclipse Orbit builds (http://download.eclipse.org/tools/orbit/downloads/drops/R20100519200754/); so, actually getting log4j into the RCP environment just involves downloading that bundle and requiring it in the RCP project.  However, there is still the potential for classloader problems and dependency issues when multiple plugins are developed as part of a project and each brings its own log4j package to the table.  The solution is somewhat simple:  designate one plugin project to initialize and supply the logging bundle, and have all the other plugins rely on this.  The choice of the master plugin is usually fairly simple;  for my project it is the RCP project itself, which actually initializes the application environment and has a dependency on the feature plugins.  That master plugin should have the log4j as a bundle dependency (Required Plug-ins), and the other plugins should simply list org.apache.log4j as an imported package.

To configure the logger using a .properties file, a bit of additional work is needed.  Many resources seem to imply there is a way to accomplish this that results in Log4j automatically loading the properties (because it will search for the log4j.properties file at startup if no config is provided), but I wasn’t able to get that to work and didn’t want to spend that much time one it.  My solution was to include log4j.properties in the project directory of the RCP plugin, make sure to add this file to the binary build under build configuration, and initialize the logger using this properties file when the application starts.  This initialization is done by adding the following to your Activator class in the master plugin:

import java.net.URL;
import org.apache.log4j.Logger;
import org.apache.log4j.PropertyConfigurator;
import org.eclipse.core.runtime.FileLocator;

final private static Logger log = Logger.getLogger(Activator.class);

public void start(final BundleContext context) throws Exception {
	// [...]
	// Setup logging
	URL confURL = getBundle().getEntry("log4j.properties");
	PropertyConfigurator.configure( FileLocator.toFileURL(confURL).getFile());
	log.info("Logging using log4j and configuration " + FileLocator.toFileURL(confURL).getFile());
	hookPluginLoggers(context); // You need to add this method to hook other plugins, described later...
	// [...]
}

That will load and configure the logger using the properties file. The properties file can be modified without needing a re-compile.  To actually log from any class in any plugin now, just add the following:

public class MyClassInAnyPlugin {
	private static org.apache.log4j.Logger log = org.apache.log4j.Logger
			.getLogger(MyClassInAnyPlugin.class);
	void someMethod() {
		log.debug("A debug message");
		log.warn("A warning message");
	}
}

A description of all the log methods and levels can be found in the log4j docs at the official site.  At this point, you should have logging up and running in your project, but we have yet to ensure that _all_ log messages will be sent through log4j.  In particular, other Eclipse plugins use the Eclipse logging framework; without special hooking, these messages will be missed by log4j.  To accomplish that, I used the PluginLogListener class described at http://www.ibm.com/developerworks/library/os-eclog/ in order to add a log listener to each loaded plugin.  To add a listener for each plugin, we need to add the following method (and field):

import org.eclipse.core.runtime.ILog;
import org.eclipse.core.runtime.Platform;

final private List<PluginLogListener> pluginLogHooks = new ArrayList<PluginLogListener>();

// Hook all loaded bundles into the log4j framework
private void hookPluginLoggers(final BundleContext context) {
	for (Bundle bundle : context.getBundles()){
		ILog pluginLogger = Platform.getLog(bundle);
		pluginLogHooks.add(new PluginLogListener(pluginLogger,
				Logger.getLogger(bundle.getSymbolicName())));
		log.trace("Added logging hook for bundle: " + bundle.getSymbolicName());
	}
}

Even though we don’t ever need to read the contents of the pluginLogHooks list, it’s very important to store the PluginLogListener instances we create; without persistent storage they will be reclaimed by the garbage collection process and their logging hooks will be removed.  After adding this method, when your application starts up, you should see something like this:

0    [main] INFO  com.rtsync.devs.rcp.Activator  (Activator.java:76): Logging using log4j and configuration [...]/my.project.rcp/log4j.properties
3    [main] TRACE com.rtsync.devs.rcp.Activator  (Activator.java:103): Added logging hook for bundle: org.eclipse.osgi
4    [main] TRACE com.rtsync.devs.rcp.Activator  (Activator.java:103): Added logging hook for bundle: com.ibm.icu
5    [main] TRACE com.rtsync.devs.rcp.Activator  (Activator.java:103): Added logging hook for bundle: org.apache.commons.logging
5    [main] TRACE com.rtsync.devs.rcp.Activator  (Activator.java:103): Added logging hook for bundle: org.eclipse.ant.core
6    [main] TRACE com.rtsync.devs.rcp.Activator  (Activator.java:103): Added logging hook for bundle: org.eclipse.compare.core
6    [main] TRACE com.rtsync.devs.rcp.Activator  (Activator.java:103): Added logging hook for bundle: org.eclipse.core.commands[...]

Now, any regular log message created by any plugin in your RCP project will be caught and interpreted by the log4j framework, which looks like this:

!ENTRY org.eclipse.core.resources 2 10035 2011-04-19 10:02:03.710!MESSAGE The workspace exited with unsaved changes in the previous session; refreshing workspace to recover changes.
819  [main] WARN  org.eclipse.core.resources  (PluginLogListener.java:91): org.eclipse.core.resources - 10035 - The workspace exited with unsaved changes in the previous session; refreshing workspace to recover changes.

Note that as long as the -consoleLog option is used with Eclipse (which is added by default to your run/debug configurations) you’ll see the original plugin log message and then the Log4J log message.  Now you have the entire environment using the same logging framework, whether it wants to or not!

Good in-depth explanations of logging in Eclipse RCP:

• http://www.ibm.com/developerworks/library/os-eclog/
• http://www.eclipsezone.com/articles/franey-logging/

I’m not quite sure what it is about this, but I immediately noticed work was getting done much sooner!

A note for those not familiar with hosts and other sarcasm-deficient folks: This command makes the computer use localhost for the IP address of Reddit and slashdot, preventing you from accessing those sites.  In a pinch, this command can help people like me that suffer from a lack of self-control when it comes to online distractions…  I’ll return some day…

Functional analysis and prediction of tumor growth

Abstract:

Based on a modified logistic model, simulated growth trajectories of brain tumors are prepared. Simulation trajectories track the number of cancer cells within each 3-dimensional area (voxel) in a 128×128 grid. A novel functional analysis procedure is developed which uses a genetic algorithm combined with systems theory principles in order to determine, for a given voxel, which neighboring voxels have the greatest predictive power when compared to the neighborhood as a whole. The predictive power of these groups, or functional masks, are given a fitness measure based on their relative Shannon entropy and the frequency with which observations occur.

This functional analysis procedure is performed over the simulated trajectories; the functional mask discovered is used to perform growth prediction. The functional mask discovered is used as the basis for probabilistic parameter estimation and prediction of tumor growth. In this fashion, growth predictions are made with significant accuracy in a very general fashion; no domain knowledge about tumor growth or the model being used is incorporated in the analysis and prediction procedure.

Robert Coop is a PhD student at the University of Tennessee in the Machine Intelligence Laboratory. His research interests include machine learning, artificial intelligence algorithms, genetic algorithms, and discrete event system simulation. His work is primarily focused on machine learning methodologies as applied to abstract non-linear domains, and other applications of adaptive optimization methods to problem domains with high dimensionality. Robert Coop holds a B.S. in computer science and a M.S. in electrical engineering from the University of Tennessee and is a student member of the IEEE.

James Nutaro is a member of the Modeling and Simulation Group in the Computational Sciences and Engineering Division at Oak Ridge National Laboratory. His research interests include discrete event and hybrid systems, parallel discrete event simulation, modeling methodologies, and event based numerical methods. This work covers a broad range of application domains, with particular emphasis on control systems operating over IP-based communication links, communication and control in electric power systems, simulating of large transportation systems, and modeling and simulation of wireless communication networks. James Nutaro has authored or coauthored over 25 papers in the open literature. He holds a B.S., M.S., and Ph.D. in computer engineering from the University of Arizona and is a member of the IEEE.

This site provides an accurate satellite view of the Earth; you can see the current areas that are in sunlight and darkness, as well as being able to see the current weather patterns (updated from actual satellite weather imagery). Here’s a script that will download the latest image and set it as your GNOME background.

Note: You can set this script as a cron job and have the background update automatically, but be courteous. The site hosting this image will not be able to continue to do so if everyone sets their computer to update every 5 minutes. The actual site only updates once every few hours, so I would recommend not setting the update to more often than once every 2/3 hours or so.

Here’s the script: update_earth_background

#!/bin/bash
gconftool-2 --type string --set /desktop/gnome/background/picture_options "none"
gconftool-2 --type string --set /desktop/gnome/background/picture_filename ""
wget  http://static.die.net/earth/mercator/1600.jpg -O /home/bcoop/Pictures/Backgrounds/earth.jpg
gconftool-2 --type string --set /desktop/gnome/background/picture_filename "/home/bcoop/Pictures/Backgrounds/earth.jpg"
gconftool-2 --type string --set /desktop/gnome/background/picture_options "scaled"

You’ll need to change the path to be something that is valid for your user and machine, but this should give you all the information you need to make it happen…

So, here are two scripts that accomplish this. When run, they will locate the boot entry for your Windows system, select that as the default boot entry, and either reboot or hibernate (with a restart after hibernation).

There are a couple preliminary things that must be done to allow this to happen. First, the hibernate script requires ‘s2disk’ in order to be able to instruct the system to hibernate and reboot afterwards. This is in the ‘uswsusp’ package and can be installed with sudo apt-get install uswsusp.

Secondly, in order to avoid needing a password prompt to reboot the machine, you need to add permissions for the user to run some commands without needing a password. This is accomplished by adding some lines to the /etc/sudoers file.  Note: Editing the /etc/sudoers file is a potentially dangerous thing. If you get any reported syntax errors from visudo when you save and exit the editor, do not ignore them!  If you mess up the /etc/sudoers file you may end up with a system that will not allow you to use sudo, and this can only be fixed by booting from a live-cd.

To edit the sudoers file, run sudo visudo. It is very important that you use this method; it checks the syntax of the file when you save it, and will prevent you from messing up your ability to use sudo (which can happen if you ignore error messages or edit /etc/sudoers directly).

So, open up the file and add these lines

# Needed for hibernate script
user ALL=NOPASSWD: /usr/sbin/grub-reboot
user ALL=NOPASSWD: /usr/sbin/s2disk
user ALL=NOPASSWD: /sbin/reboot

This will allow ‘user’ to run those three commands with sudo without needing a password. Then, put the following scripts into /usr/local/bin

reboot_to_windows

#!/bin/bash
WINDOWS_ENTRY=`grep menuentry /boot/grub/grub.cfg  | grep --line-number Windows`
MENU_NUMBER=$(( `echo $WINDOWS_ENTRY | sed -e "s/:.*//"` - 1 ))
sudo -n grub-reboot $MENU_NUMBER
sudo reboot

hibernate_to_windows

#!/bin/bash
WINDOWS_ENTRY=`grep menuentry /boot/grub/grub.cfg  | grep --line-number Windows`
MENU_NUMBER=$(( `echo $WINDOWS_ENTRY | sed -e "s/:.*//"` - 1 ))
sudo -n grub-reboot $MENU_NUMBER
gnome-screensaver-command --lock
sudo -n s2disk --parameter "shutdown method=reboot"

Then, all you need to do is add a launcher icon to the desktop, and when run the system will shutdown or hibernate, set the default entry to Windows, and reboot!

So, here’s my script: wma2mp3

Usage: wma2mp3 in-wma out-mp3

#!/bin/bash
IN=$1
O=${2-${IN%\.wma}}
OUT=${O%\.mp3}.mp3
TEMP=`mktemp /tmp/convert.XXXXX.wav`
 
echo Converting \"$IN\" to \"$TEMP\"
mplayer -vc null -vo null -ao pcm:waveheader:fast:file=%`expr length "$TEMP"`%"$TEMP"  "$IN"
 
echo Converting $TEMP to $OUT
lame "$TEMP" "$OUT"
rm $TEMP
echo Fixing ID3 tags
ARTIST=`mutagen-inspect "$IN" |  grep WM/AlbumArtist  | grep -E --only-matching "[^=]+$"`
ALBUM=`mutagen-inspect "$IN" |    grep WM/AlbumTitle  | grep -E --only-matching "[^=]+$"`
NUM=`mutagen-inspect "$IN" |    grep WM/TrackNumber  | grep -E --only-matching "[^=]+$"`
TITLE=`mutagen-inspect "$IN" |   grep -E "^Title=" | grep -E --only-matching "[^=]+$"`
echo Artist = \"$ARTIST\"
echo Album = \"$ALBUM\"
echo Track Number = \"$NUM\"
echo Title = \"$TITLE\"
mp3info -a "$ARTIST" -l "$ALBUM"    -n "$NUM" -t "$TITLE" "$OUT"
echo Done!

Edit: Thanks to a post over on reddit, here’s an update that makes better use of shell scripting:

#!/bin/sh
 
in=$1
out=${in%.[Ww][Mm][Aa]}.mp3
 
mutagen-inspect "$in" | {
    while IFS= read -r tag; do
        case $tag in
        WM/AlbumArtist*)
            ARTIST=${tag#*=}
            ;;
        WM/AlbumTitle*)
            ALBUM=${tag#*=}
            ;;
        WM/TrackNumber*)
            NUM=${tag#*=}
            ;;
        Title=*)
            TITLE=${tag#*=}
            ;;
        esac
    done
 
    mplayer -vc null -vo null -ao pcm:waveheader:fast:file=/dev/stdout |
    lame --tt "$TITLE" --ta "$ARTIST" --tl "$ALBUM"  --tn "$NUM" - "$out"
}