IIOP enabled jackrabbit-jcr-rmi, .NET 2.0 Remoting Layer Implementation, .NET 2.0 Repository Explorer implementation, .NET 2.0 implementation of JSR-170 API

• Key: JCRRMI-24
• Type: New Feature
• Status: Open
• Priority: Minor
• Assignee: Unassigned
• Reporter: Michael Singer

Description

I developed this stuff about a year ago. I sent that to David Nuescheler and Dominique Pfister for demonstration purposes, David told me that it all worked well and asked me if I would like to contribute all this. So here it is...

Comments

[Michael Singer]

The .NET 2.0 stuff...

[Michael Singer]

the IIOP enabled jackrabbit-jcr-rmi stuff...

[Michael Singer]

The file JCR.NET.zip contains 3 folders, ContentRepository, CRExplorer and JackrabbitIIOPConnector.

The project ContentRepository is a contribution from Joern von Holten from Reddot and is the .NET 2.0 implementation of the JSR-170 API.
The project CRExplorer is a WinForms GUI and contains the solution file (which can be opened with VS.NET 2005).
The project JackrabbitIIOPConnector is the remoting layer implementation.

You also need the latest version of IIOP.NET, you can get that from http://iiop-net.sourceforge.net
This tool contains the file IIOPChannel.dll which is needed by the .NET projects.

The file jcr-iiop.zip contains the iiop enabled jackrabbit-jcr-rmi. The folder in this zip-file is an eclipse-project.
You will have to add all the jackrabbit dependencies to the build-path to make the project compile.
The file buildiiop.cmd contains the commands to generate all the stubs and .idl-files.
The commands are for the Windows Command Shell and you will of course have change all the paths in there
according to your system.
The last call in this command chain will generate a .dll-file which has to be included in the .NET-Project "JackrabbitIIOPConnector"

There is a class "Server" in the package org.hms.jackrabbit.rmi.server which contains a main method and is used to
start the ORBD and jackrabbit. All the configuration also done in this class.
After startup of the server you should be able to type "help" in the console to get hints how to auto generate some nodes
and properties in jackrabbit (if you don't have some already )

You can shutdown the server by typing "exit" and hitting enter...

If the java-side is running startup the .NET GUI. This is done with Program.cs in the Project CRExplorer. The configuration stuff
is in ContentExplorer.cs (you have to set the RemoteHost and the RemotePort).

If everything is OK you should see at least a treeview of the nodes stored in jackrabbit...

I know it is very tricky to get this stuff working, so, good luck and don't hesitate to ask...

And of course maybe David and Dominique have useful input since they used this stuff during the last months

[Jukka Zitting]

Re: IIOP, did you think of a solution to the lack of distributed garbage collection in IIOP? See JCR-206 for a related effort that I didn't commit partly due to the lack of garbage collection.

[Michael Singer]

I changed the class o.a.j.r.s.ServerObject to extend PortableRemoteObject instead of UnicastRemoteObject. PortableRemoteObject has a static method unexportObject(Remote obj) which deregisteres a server object from the runtime allowing the object to become available for garbage collection. I therefore added a method to ServerObject:

public synchronized void unexport() throws RemoteException {
PortableRemoteObject.unexportObject(this);
}

On the .NET side I implemented the destructor which is called by the .NET garbage collector. This destructor calls the unexport method of the remote object which makes the object on the java side available for garbage collection. For example I have a class Session in .NET and implemented ~Session(){...}:

public class Session : ISession
{
private RemoteSession session = null;

public Session(RemoteSession session)

{ this.session = session; }

/// <summary>
/// <para>
/// Called by the Garbage Collector to remove the ORB-Object-Reference.
/// </para>
/// </summary>
~Session()

{ session.unexport(); }

...
}

So if an object on the .NET side is garbage collected it calls the unexport method of the remote object which then also should become garbage collected.

[Jukka Zitting]

Looks like a good solution! I'm sorry I haven't had time to look at this earlier, I'll see if I can get this included in new future.