Table saw fence

Hello all,

This weekend I set out to make a table saw fence for the table saw in the outfeed table. the fence is made of two perpendicular MDF strips. One going almost the full length of the table parallel to the blade and another perpendicular to it that lines parallel to another strip of MDF placed along the front edge of the table.

IMG_0297

 

On the above image is a part I made to secure the front side strip of MDF to the table. The short perpendicular to the blade fence piece lines up against it.

IMG_0298

The rightmost strip on the above picture is the front sided one. the leftmost strip is the fence. This picture was taken after I cut it on the saw with a temporary fence made from a metal strut.

IMG_0299

Above is the fence completed and in place. Note the front sided strip that serves as a fastening point for the fence’s small strip. It is secured with a grip.

IMG_0300

View of the fence from the opposite side. Only problem now is that the fence isn’t exactly parallel to the blade. I need to fix that maybe by using another kind of joint for both of the MDF strips.

 

 

Crosscut sled groove

For my table saw outfeed table I want to have a crosscut sled. The sled will run longitudinally across the table saw through a groove that the manufacturer already built-in. Because the machine is now fitted to a larger table, I have to extend the groove into the outfeed table, in order to slide the sled all the way past the blade.

I used a portable router to make the groove. Before cutting the outfeed table I made a test run on a piece of MDF, which is the material of the table. MDF is easy to cut. Not a hard material.

IMG_0288

Then I measured the distances to where the groove on the table would continue the groove on the table saw. To guide the movement of the router I made a jig composed of two boards that would bound the width of the groove. The length was equal to the table’s length.

IMG_0289

Below is the router setup before the cut. Note the vacuum cleaner attached to the router, for making the router bit easier to advance through the material.

IMG_0290

Below is the groove already cut, with the jig still in position.

IMG_0291

Below is a piece of plywood and an MDF that will make the sled surface and the guide that will go under for sliding on the groove.

IMG_0292

 

Both pieces are now glued together. Next I will have to glue the sled fence which will have to be square with the blade.

 

CGLib class enhancement and RMI

I am developing some software (hosted on source forge : https://sourceforge.net/projects/jmxbox/) that is basically an application container. One annotates the classes in the application and they are instantiated, remoted and you can schedule classes to run as jobs, work pools, etc. Check-it out.

To implement remoting I wanted to put the least burden on the application developer. RMI requires that a interface that extends remote (the remote interface) is implemented by the object that is to be remoted. I wanted to reduce the requirements imposed by RMI, such as not implementing a remote interface but instead deriving it from the business object.

For that purpose I investigated CGLib, a byte-code manipulation library. The documentation is scarce so a lot of experimenting is in order.

I tried to derive the interface from the object, but I didn’t manage to get CGLib generate an interface that extended another interface (java.rmi.Remote required by the RMI subsystem). So I required that the app developer implement the remote interface. But I didn’t want to make the interface extend java.rmi.Remote. So I tried creating a proxy to the business object that would extend the object AND implement the Remote marker interface. So I developed the following code :

public void bind(Remote objectInstance) {
 try {
 Enhancer classEnhancer = new Enhancer();
 classEnhancer.setSuperclass(objectInstance.getClass());
 classEnhancer.setInterfaces(new Class[]{Remote.class});
 classEnhancer.setCallback(new MethodInterceptor() {
 @Override
 public Object intercept(Object obj, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {
 return methodProxy.invokeSuper(obj, args);
 }
 });
 Object proxy = classEnhancer.create();
 Remote stub =
 (java.rmi.Remote)UnicastRemoteObject.exportObject((Remote)proxy, 0);
 Registry registry = LocateRegistry.getRegistry();
 registry.rebind("Object", stub);
 System.out.println("object instance bound");
 } catch (RemoteException e) {
 System.out.print("error : " + e.getMessage());
 e.printStackTrace();
 } catch (Throwable t) {
 t.printStackTrace();
 }
}

The code ran fine, but when I tried to access the remote object from a java client and casting the stub to the remote interface I got the error that the stub didn’t implement it.

So I used a RMI registry browser to lookup the stub and found out that the only implemented interface was java.rmi.Remote. My interface wasn’t implemented by the stub.

When I coded the remote interface to directly implement the marker interface it worked. So lesson learned. The RMI subsystem requires that the interface extends remote and not the business object. Since CGLib does not allow interface extension AFAIK, I now require that an app developer explicitly extends remote on the business interface.

The methods of the business interface must throw java.rmi.RemoteException, so to really eliminate the requirements of dealing with RMI by the app developer, I would need to wrap the calls to the business object in methods that conform to the RMI spec.