Maven repo central and project status

[marekjagielski]

Hi,
Does project Dirmi is still active? Do you plan to deploy the last version it to central maven repo ?
Thanks,

Marek

[broneill]

Yes, the project is still active. In the past I've found to to be a pain to get anything into the central repo, which is why I don't ever get around to doing it. Do you know of a simple way to upload artifacts? Have you gone through the process recently?

[marekjagielski]

Thanks for your reply. I will give your project a try and see if it fits my needs. If it works as it is described at your site I think that it is really worth to share it via maven central repo. More, this will help to increase the popularity of the project. Unfortunately, I haven't shared nothing in central repo yet so I can't help you with that.
However, I will notify you any issue I will met during my tests.

[marekjagielski]

Can I register more server objects in one session? As it is in RMI, that objects are mapped by a key?

[marekjagielski]

I have problem with a basic sample (dirmi-1.1.2). As a standalone application, it is working fine. However when I try to integrate this example in my application I get:

java.lang.ClassCastException: com.systemincloud.modeler.launch.impl.rmi.RemoteExample$Stub$141 cannot be cast to com.systemincloud.modeler.launch.impl.rmi.RemoteExample

I want to establish a connection between a plugin eclipse and run of Java process via launch button.
Can you give me a hint how can I investigate this.
First two lines seems to be ok:
Environment env = new Environment();
Session session = env.newSessionConnector("localhost", 1234).connect();
However an object received by:
RemoteExample example = (RemoteExample) session.receive();
can't be cast to RemoteExample.
Thanks,

[broneill]

Make sure that both client and server have all the classes available -- common class paths.

To register more objects in a session, create a "root" remote object which has methods to return more remote objects from a method that takes a name argument. The root object is the only one passed through the session directly.

[marekjagielski]

Ok, I understad what is going on.
In my case is:
Eclipse run a new java process. During initialization all classpaths to this process came from eclipse. Process starts dirmi server and register objects.
// What I assume that in dirmi you change RemoteExample class injecting a Stub.
Next, my eclipse try to communicate to the new process. However it has already loaded RemoteExample, so it hasn't the new definition and from where java.lang.ClassCastException.
I will try now to write my Classloader that will reload RemoteExample class to confirm my assumptions.

[marekjagielski]

Can you confirm my hypothesis? Reloading of class is not so clean and easy as I thought. If yes, is it possible to prepare stubs before in the client application (eclipse). I think that the problem is that the client (eclipse) starts before than server (new process). And the eclipse plugin has references to remote interfaces that it makes it loaded before.
Please, correct me if I am wrong.

[broneill]

You shouldn't need to do anything with class loaders. I don't use Eclipse, and so I cannot help you set it up properly.

[broneill]

I recall a couple of years ago someone using OSGi was having class loading issues and provided a patch. I'll apply it to a branch, and then you can see if it works for you.

[broneill]

Here's the link to the branch: https://github.com/cojen/Dirmi/tree/bridge-classloader

You'll need to pull the branch using Git and then build the project with Maven.

[marekjagielski]

Ok, I tried the patched branch but the problem is still the same.
I tried version that dirmi server is on the side of eclipse plugin and this works ok (with and without patch). If I decide to use dirmi this would be my workaround. But I want to investigate a little bit more why it's not working in other way.

[marekjagielski]

The same issue I get when using dirmi server on the side eclipse but in different context.
I have a "root" service in my plugin eclipse. Plugin starts a new process. This process successfully communicate with "root" service. However when the new process sends remote objects to make available callbacks from eclipse these remote objects in eclipse can't be cast to their interfaces (also using patched dirmi):

java.lang.ClassCastException: com.systemincloud.modeler.launch.impl.common.ConsoleIApi$Stub$163 cannot be cast to com.systemincloud.modeler.launch.impl.common.ConsoleIApi

[marekjagielski]

Do you know how can I debug this problem? Still, I don't fully understand low level Java topics. As I use on received object:
object.getClass().getInterfaces();
I get only [interface java.rmi.Remote, interface org.cojen.dirmi.core.Stub]

In working example that you provided on the site there are:
[interface test.RemoteExample, interface org.cojen.dirmi.core.Stub]

[broneill]

Before casting, print the ClassLoader used by ConsoleApi.class and the remote object you receive (of type ...Stub). The two should be different. On the stub class, call getInterfaces and print them all out. For each, also print the ClassLoader. One of the interfaces should be ConsoleApi, and it should have the same ClassLoader as what you printed earlier. If not, then you'll get a ClassCastException when casting to ConsoleApi.

[marekjagielski]

Ok,
ConsoleIApi.class.getClassLoader() :
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@6c382376[com.systemincloud.modeler.launch.impl:0.1.0.qualifier(id=794)]

stub.getClass().getClassLoader() :
org.cojen.classfile.RuntimeClassFile$Loader@34c82244

stub.getClass().getInterfaces()[0] :
interface java.rmi.Remote

stub.getClass().getInterfaces()[0].getClassLoader() :
null

stub.getClass().getInterfaces()[1] :
interface org.cojen.dirmi.core.Stub

stub.getClass().getInterfaces()[1].getClassLoader() :
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@6d41c14b[com.systemincloud.modeler.libs:0.1.0.qualifier(id=815)]

It is true that I put dirmi libraries in a seperate plugin modeler.libs and I run the dirmi server from modeler.launch.impl.

[marekjagielski]

I am looking on Glerup's (@glerup) patch. As I understand he delegates creating stubs to the Dirmi bundle. To use this patch I should create a separate dirmi bundle. Am I right? In my case dirmi is in org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@6d41c14[com.systemincloud.modeler.libs:0.1.0.qualifier(id=815)]

[broneill]

On the client Session object, try calling setClassLoader(ConsoleApi.class.getClassLoader()) before calling receive. ConsoleApi came from a class loader which is different than what loaded Dirmi classes. (@6c38237 != @6d41c14)

Look at the Dirmi's ClassLoaderResolver class, which does the work of resolving client-side remote interfaces.

[marekjagielski]

I shared an example of what I try to do:
https://github.com/marekjagielski/eclipse-launcher-with-dirmi-server
Tomorrow I will write a description of example and how to run it.

[marekjagielski]

I've written a description how to run the example as well a small description of project. I will try to find some advices on eclipse forum as it is an issue related to classloaders and osgi.

[glerup]

@marekjagielski

We are using Dirmi (with a few patches) as part of our OSGi based server application, so I may be able to help you.

I will take a look at your example as soon as possible.

[marekjagielski]

Issue solved thanks to @glerup (marekjagielski/eclipse-launcher-with-dirmi-server#1). @broneill , maybe you can edit the issue title that others can find it easier if they will meet similar problems. I will leave also my example what can be useful for others.

It is a really good library !