Null Pointer when trying to access Remote Repository

Post Reply
fgysin
Posts: 3
Joined: 07 Sep 2010, 10:10

Hello
At work we decided to give the essential project a try as we are looking for an architecture modeling tool at the time.
I have successfully set up an essential instance on my local machine and have played a bit with it: incredibly powerful, and easy to use; all in all very promising.

The next step was to try and install a server version with a shared repository. We have now installed an essential instance on the server. It's got an attached mysql database and works fine for itself. When started on the server (via X11 fowarding through ssh) all was up and well.
However it was not possible to connect to the repository: when trying to open the repository (through the menu via File>Open>Server ... as stated in the tutorial section of this website.) nothing happens. No response at all is given.

Mind that the repository service is running (started as 'sudo run_protege_server.sh') - otherwise there would be a message stating that the specified server is not accessible. Also I don't think the problem lies with the user specification in the metaproject, as there is no authorization respond either.

I found out however that the protege.jar throws an exception in the exact moment someone tries to log in remotely. (This also lets us forget about possible networking problems, obviously the connection works.)

The error is as follows:

Code: Select all

WARNING: Could not log in -- java.lang.NullPointerException
        at edu.stanford.smi.protege.server.metaproject.impl.UserImpl.equals(Unknown Source)
        at java.util.HashMap.put(HashMap.java:393)
        at java.util.HashSet.add(HashSet.java:217)
        at edu.stanford.smi.protege.server.metaproject.impl.MetaProjectImpl.getWrappedInstances(Unknown Source)
        at edu.stanford.smi.protege.server.metaproject.impl.MetaProjectImpl.getUsers(Unknown Source)
        at edu.stanford.smi.protege.server.metaproject.impl.PolicyImpl.getUserByName(Unknown Source)
        at edu.stanford.smi.protege.server.Server.isServerOperationAllowed(Unknown Source)
        at edu.stanford.smi.protege.server.Server.isServerOperationAllowed(Unknown Source)
        at edu.stanford.smi.protege.server.Server.openSession(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
        at sun.rmi.transport.Transport$1.run(Transport.java:177)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:636)
        at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:273)
        at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:251)
        at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:160)
        at edu.stanford.smi.protege.server.Server_Stub.openSession(Unknown Source)
        at edu.stanford.smi.protege.server.ServerPanel.createSession(Unknown Source)
        at edu.stanford.smi.protege.server.ServerPanel.isValidConfiguration(Unknown Source)
        at edu.stanford.smi.protege.server.ServerPanel.validateContents(Unknown Source)
        at edu.stanford.smi.protege.util.ProjectChooser.canClose(Unknown Source)
        at edu.stanford.smi.protege.util.ProjectChooser.attemptClose(Unknown Source)
        at edu.stanford.smi.protege.util.ProjectChooser.access$200(Unknown Source)
        at edu.stanford.smi.protege.util.ProjectChooser$2.actionPerformed(Unknown Source)
        at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2012)
        at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2335)
        at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:404)
        at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
        at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:253)
        at java.awt.Component.processMouseEvent(Component.java:6106)
        at javax.swing.JComponent.processMouseEvent(JComponent.java:3276)
        at java.awt.Component.processEvent(Component.java:5871)
        at java.awt.Container.processEvent(Container.java:2105)
        at java.awt.Component.dispatchEventImpl(Component.java:4467)
        at java.awt.Container.dispatchEventImpl(Container.java:2163)
        at java.awt.Component.dispatchEvent(Component.java:4293)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4461)
        at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4125)
        at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4055)
        at java.awt.Container.dispatchEventImpl(Container.java:2149)
        at java.awt.Window.dispatchEventImpl(Window.java:2478)
        at java.awt.Component.dispatchEvent(Component.java:4293)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:604)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:275)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:200)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:194)
        at java.awt.Dialog$1.run(Dialog.java:1072)
        at java.awt.Dialog$3.run(Dialog.java:1126)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.awt.Dialog.show(Dialog.java:1124)
        at javax.swing.JFileChooser.showDialog(JFileChooser.java:740)
        at javax.swing.JFileChooser.showOpenDialog(JFileChooser.java:643)
        at edu.stanford.smi.protege.util.ProjectChooser.showOpenDialog(Unknown Source)
        at edu.stanford.smi.protege.ui.ProjectManager.getRequestedProject(Unknown Source)
        at edu.stanford.smi.protege.ui.ProjectManager.openProjectRequest(Unknown Source)
        at edu.stanford.smi.protege.ui.ProjectManager.openProjectRequest(Unknown Source)
        at edu.stanford.smi.protege.action.OpenProject.actionPerformed(Unknown Source)
        at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2012)
        at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2335)
        at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:404)
        at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
        at javax.swing.AbstractButton.doClick(AbstractButton.java:374)
        at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1688)
        at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1732)
        at java.awt.Component.processMouseEvent(Component.java:6106)
        at javax.swing.JComponent.processMouseEvent(JComponent.java:3276)
        at java.awt.Component.processEvent(Component.java:5871)
        at java.awt.Container.processEvent(Container.java:2105)
        at java.awt.Component.dispatchEventImpl(Component.java:4467)
        at java.awt.Container.dispatchEventImpl(Container.java:2163)
        at java.awt.Component.dispatchEvent(Component.java:4293)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4461)
        at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4125)
        at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4055)
        at java.awt.Container.dispatchEventImpl(Container.java:2149)
        at java.awt.Window.dispatchEventImpl(Window.java:2478)
        at java.awt.Component.dispatchEvent(Component.java:4293)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:604)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:275)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:200)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:185)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:177)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:138)
I would be grateful for any help!
Thanks in advance,
Florian

To sum up some system information:
- The server runs Ubuntu Server 8.04 LTS.
- Installed are Protege 3.4.4, Tomcat 5.5, MySQLServer 5.0.51 and Java 6.
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Hi,

It's great to hear that you are discovering the potential of Essential.
Apologies for the delay in getting back to you.

From what I can see, the first thing to check is what's called the 'metaproject'. This is a Protege project that controls the configuration of the Protege server. It's in here that you specify the users and their access rights etc.

If you haven't already setup the metaproject, this documentation article describes what you need to do. Configure Protege Metaproject

Make sure that the server can see the metaproject. If you have NOT edited the run_protege_server.sh to use a different location for the metaproject, the default location is described in the above article.

Let me know how things are with the metaproject and we can take it from there.

Jonathan
Essential Project Team
fgysin
Posts: 3
Joined: 07 Sep 2010, 10:10

Thanks for your response.
The run_protege_server.sh is configured correctly, it points to the right file.

I've also looked into the config within the metaproject ontology and actually found an error. The path to the annotations project .pprj file was wrong; I've corrected that now.

Sadly it still does not work... ;)

Now, I've checked the log of the server starting up, it looks as if it sees all the relevant files now: metaproject.pprj, <essential_project>.pprj and the corresponding annotation file are all read. Also the server looks like its up and ready... (see last line in the log )

Code: Select all

sudo ./run_protege_server.sh 
Protege server is starting...
Protege 3.4.4 Build 579, JVM 1.6.0_0-b11, memory=520M, Linux, encoding=UTF-8, language=de, country=CH
Server port = 0, registry port = 1099, compressed stream
Using metaproject from: file:/usr/local/EssentialAM/essential_metamodel/metaproject.pprj
Could not set up class specific logging
Exception configuring logger
Could not set logger level
Warning: IO exception getting logger. access denied (java.util.PropertyPermission protege.properties.in.user.home read)
Loading project Team VI from file:/usr/local/EssentialAM/essential_metamodel/Team_VI_v1.0.pprj
...
Loading project Team VI Annotations from file:/usr/local/EssentialAM/essential_metamodel/annotation_essential_baseline_v1.2.pprj
Loading project plugins for project Team VI
Loading project plugins for project Team VI Annotations
Protege server ready to accept connections...
('Team VI' is the name of our project.)

I've tried to access the server from a remote (other PC in network) and also a local (installed on the server) protege version. Again I wanted to connect via File>Open>Server...

The exception I posted does not appear anymore, I encounter a slightly different behavior now when I hit the connect button: The protege client I try to connect to the server with just freezes and does not respond in any way. (I have to kill the client process manually.)

Neither the log of the server, nor the log of the protege client show any kind of info at all upon an attempted connection.

I've now seen that the server startup logs a warning about not being able to log correctly. Maybe that would be a point to start so I can get more info about incoming connections? (And see why they fail?)
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

I've been looking into this one a bit more.

It does look like the server has started correctly but the warning about not being able to setup the logging probably should be looked at to start with as it could be that the inability to log what's causing the problem is leading to the lock-up of the client.

It looks like the warning about the logger is simply that Protege cannot access or create the log file that it wants to write to. Check that Protege (and in particular the user that is being used to execute run_protege_server.sh) has write access to the log directory of Protege. Check this on both clients and server. Protege, by default, logs to:
[Protege Install]/logs

The release notes for Protege 3.4.2 (you and I are using more recent versions) mentions improved logging for client/server connection issues and I think we'll need some more details there.

From the research I've done, I think it may be worth re-visiting the metaproject configuration. I've found the following article on the Protege wiki that mentions that on Unix platforms, the metaproject, out of the box, uses Windows-style '\' characters in file paths, e.g. to the PPRJ file of the projects that you want to serve from the server. I'm guessing that you've already looked at this but worth checking all the Projects that you have defined in the metaproject ontology - and their annotation projects.

I had a dig into the Protege source code to see if I could find the root cause of the original exception that you were experiencing.
Two questions on this:
1. Could you confirm that this exception was reported on the server, not the client?
2. It seems that the exception is occurring when the server is trying to load the list of users from the metaproject. Can you check that you have set up the users in the metaproject ontology and that they have been added to the relevant Groups etc?

Just to make sure I know where you're getting to, you've got the server running to the point where it says that it's ready to accept connections.

From what I can tell, on the client you are getting to the point where you see this dialog Image but that you are not getting to the list of available repositories (from the server) to open. This dialog:
Image

Something else to check is that there are not multiple copies of RMI Registry running on the server, or even that there are multiple copies of the server running. I read on one of the Protege client/server troubleshooting pages that it's possible to accidentally run multiple copies such that the first starts correctly and reports that it's ready but that subsequent copies will not start properly (you can't connect to them) BUT they do not log any errors.
Could this be a reason why the message above is reported about access denied to the logging?

I've just had a look at my Protege Properties file (I'm running on a Unix variant, too) but I can't find any mention of the in.user.read property in there. This is the property that's reporting warnings. I reckon it's worth checking the ownership and access rights for your Protege install directory and the logs sub-directory. Hopefully, we can get the error reporting working and see what's going on.

Last question. When you run the Protege client, can you run that from a command line/terminal? Are there any messages being reported up to and beyond the point when you attempt to connect to the server?

One more thing to try. It looks from your server output that you've installed the sample metaproject in your Essential installation (/usr/local/EssentialAM). Does this mean that you still have the 'default' example metaproject from the Protege team in the [Protege Install]/examples/server directory? If so:
  • Open this, change any '\' to '/' as you are on a Unix platform
  • Tweak your 'run_protege_server.sh' to point to this metaproject.pprj
  • Execute 'run_protege_server.sh' and let the server start up
  • Now try to connect to the Protege server. You should be able to log in as Guest (I believe you can just leave the default username and password in there). If your previous username/passwords appear, go back to the default metaproject and change the Guest password to something appropriate.
  • When you click OK, you should then see the default, sample set of projects available, such as Newspaper, Pizza etc.
If you still cannot connect, then we need to look at your Protege server installation. If you can connect and open any of the simple test Protege projects, then I think the problem lies with your /usr/local/EssentialAM/essential_metamodel/metaproject.pprj file, and we should be able to resolve that quickly.

I hope this all makes sense - there's a lot to look at! - and that we can get closer to identifying the problem.
Let me know how you get on

Jonathan
Essential Project Team
fgysin
Posts: 3
Joined: 07 Sep 2010, 10:10

EDIT:
Wow. I just tried connecting to the server again and it worked. Just like that. Without any changes whatsoever. Strange world we live in... :)

I was presented with the list of projects, chose mine and it loaded without problems.

The only thing happening since the last time might have been a machine restart. Perhaps that cleared some stuck thread. Maybe its magic.

Anyway, it seems to work perfectly now... Thanks again for the help Jonathan! It's great to get feedback like that if you get stuck somewhere. :ugeek:

--------------------------------------------
Thanks for the amount of work you put in your answer. I'll answer your questions/concerns in the order you asked:

- I had a look at the permissions for the log files and that can not be an issue. For one the log folder is set to be writable for all users and groups on the server, secondly I started the protege server via sudo, i.e. as root.
In the ../logs folder I can only see the logs of the protege client.

- I checked the file path separators in the metaproject and they are all set Unix style wise ('/').

1) The exception posted in my first post was indeed thrown by the protege server. The client (at that time) just showed no response at all (didn't get stuck either). However, I was not able to reproduce the above exception since I changed a wrong definition in metaproject. (More specifically it was the definition of the location of the .pprj file of an 'Annotations' project.)

2) I double checked the user and group configuration with the metaproject tutorial. It seems to be alright. (One user is in Architect group, Architect group is set to be able to Read and Write on the project...)


You correctly identified where I got stuck. Server log says 'ready for connections', client freezes after the 'ok' button is hit ton the first open-dialog .


Concerning RMI:
I stumbled upon the RMI registry troubles while searching a solution for my problem. I always manually killed the RMI process before starting the protege server.

Lastly: I started the protege client via command line ('sudo ./run_protege.sh') on the server. I thought this might at least eliminate the possibility of networking problems. I also tried it remotely though, same result.
The log of the client is correctly logged to ../logs folder. The log looks normally.
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Great to hear that you are up and running.
I wonder if, as you say, there was a still a Protege server process running somewhere (probably just called java.exe!) which was cleared by the restart of the server. Could be a case of that comment in the Protege wiki about multiple servers running, where the 1st reports success but you can't connect to it because of the other server instances.

The 'run_protege_server.sh' (or .bat if you're on Windows) always attempts to start the RMIRegistry but the shutdown script does not attempt to stop it. This can sometimes lead to error messages from the run_protege_server.sh as it kicks off the process to run the RMIRegistry but fails (as it's already running) when you restart the Protege Server. These messages can be safely ignored once identified as being from the failed RMIRegistry startup.

A restart of the server is normally a course of action that springs to mind on a Unix platform ;) but it's great to have this experience captured on the forums. Thanks for posting back and hopefully if anyone else has similar issues, between us, our posts should help them resolve it.

I should point out that the Annotations stuff is optional. Sounds like you've got this setup. I would definitely recommend that you use a database backend for the Annotations ontology as it operates at a very fine level or granularity and gets big quickly. However, if the collaborative capabilities of Protege are not a priority, you can turn this off in your Essential ontology. Then, you just need to tweak the metaproject to remove the reference to the Annotations project and restart the server. In fact, I understand that the latest versions of Protege allow you to connect to the server in admin mode and update the metaproject without having to do a restart.

Keep us posted as to how you're getting on

Jonathan
Essential Project Team
Post Reply