Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[p4-feedback] Protege launcher problems

Phillip Lord phillip.lord at newcastle.ac.uk
Sat Oct 19 15:00:15 PDT 2013



Timothy Redmond <tredmond at stanford.edu> writes:
>> Oh, and is
>> there a protege-dev mailing list?
>
> The protege 4 feedback list works fine for this and it would be good to move
> this conversation there so that future googlers may find any answers that we
> find.


I have done so -- apologies to everyone on the list who is missing the
start of this discussion. I'm trying to launch protege from an already
running JVM which has loaded the OWL API and am getting version
conflicts.

This email is quite long; it's in too parts -- problems with conflicts
between the OWL API and protege and a shorter bit about current working
directories near the end.


>> Are you interested? Or I am missing something much easier?
>
> I am the right guy for understanding OSGi issues.  I think though that I don't
> entirely understand your requirements.  The key paragraph seems to be this
> one:
>
>> The reason I am trying to do this is because I want to be able to remote
>> control protege using clojure; actually I have this working, but
>> I have to launch clojure inside protege and then connect to it. Nice,
>> but unfortuately, it means that I don't control the classpath, so my
>> clojure code tends not to work -- I need to manage all the dependencies
>> for myself (for example, my code uses depends on ELK, which isn't
>> available).
>
> In OSGi you have a lot of control over what classes are found by the class
> loader and what classes are not found.  The OSGi class loading mechanism is
> extremely flexible and powerful.


It is, but I am trying to run protege from a JVM that I have already
launched and which has had it's classpath set up by maven (actually
leiningen, but the principle is the same). 


> For example, you could make an elk bundle that supplies the elk libraries to
> Protege.  Alternatively you could include the elk jars in your bundle and put
> them on the Bundle-Classpath (a variable in the manifest).  In addition, if
> you configure things right, you can make the elk classes available to the java
> vm that starts Protege and the Protege classes inside Protege.  This would
> allow classes in the java vm outside Protege to conveniently exchange data
> with classes inside Protege.

This was my idea!


> Are you using a custom version of the owl api? You may need to replace the
> owlapi bundle to make this work properly.  


Yes, and yes, I've done this. I had to patch protege slightly to make it
work with the latest snapshot of the OWL API -- one change was trivial,
and the other involved removing of redundant code.

> So I am not sure exactly which problem you are going to solve here.

Basically, I have a tooling issue. I want leiningen (or maven) to be
able to define a JVM classpath and run protege inside this. Protege can
carry with the OSGI clever ness underneath.

Anyway, I have found the problem, which is sneaky. 

The errors I was getting are of the form...

;; WARNING: Bundle /home/phillord/src/large/protege-4/build/Protege/bundles/org.protege.common.jar failed to install.
;; java.lang.NoSuchMethodError: org.osgi.framework.BundleEvent.<init>(ILorg/osgi/framework/Bundle;Lorg/osgi/framework/Bundle;)V
;; 	at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4408)
;; 	at org.apache.felix.framework.Felix.installBundle(Felix.java:3048)


In other words, Felix is trying to instantiate a BundleEvent with a
constructor which doesn't exist.


Looking at the classes in my JVM I find that this is where they are
coming from...

;; (where org.osgi.framework.BundleEvent)
;; #<URL file:/home/phillord/.m2/repository/org/apache/felix/org.osgi.core/1.4.0/org.osgi.core-1.0.0.jar>
;; (where org.apache.felix.framework.Felix)
;; #<URL file:/home/phillord/src/large/protege-4/build/Protege/bin/felix.jar>
;; (where org.protege.osgi.framework.Launcher)


Now, felix.jar from protege appears to be equivalent to this maven
artifact here; in fact, I tried the rebuilding protege using this
artifact. 

http://mvnrepository.com/artifact/org.apache.felix/org.apache.felix.framework/4.2.1

The OWL API however depends on this artifact.

<groupId>org.apache.felix</groupId>
<artifactId>org.osgi.core</artifactId>
<version>1.0.0</version>

Checking here:

http://mvnrepository.com/artifact/org.apache.felix/org.osgi.core/

Shows that this artifact is out of date. So I updated it to this
version:

http://mvnrepository.com/artifact/org.apache.felix/org.osgi.core/1.4.0

Rebuilt the OWL API distribution, added it to protege, rebuilt protege.
Still crashing.

Opening up felix.jar, and you find org.osgi.framework.BundleEvent.class
inside. So, this is clearly the problem. 

And, now for the killer. Rather than updating it, I just tried deleting
the dependency from the OWL API. And the OWL API builds, and tests just
fine. And it's possible to open protege inside of an existing JVM. So,
it looks like the problem is that the OWL API build file is just out of
date; it's giving a dependency it doesn't use. I'll send a pull request
in on monday to the OWL API!

After all of this, my brilliant plan doesn't work, as I think you'd
already worked out. I can load classes into the external JVM and the
same classes inside protege, but because they are on independent
classloaders they are actually different classes and can't communicate,
even through statics. I can't think of any way around this.





And, to finish with the bit about current working directories.


>> The key problem is in BundleSearchPath which uses this code...
>>
>>          else {
>> 			path.add(new File(dir));
>> 		}
>> 	}
>>
>> which is interpreted relative to the current working directory.
>
> Actually, the original intent was that this directory would be interpreted as
> relative to the Protege home variable that is set up and used in the
> Launcher.java file.  This would allow the config.xml file in the Protege
> distribution to have relative paths that will be interpreted correctly even if
> the java vm is started with a different working directory.
>
> When I look at the logic in this code, it appears - I didn't test it yet -
> that this functionality does not work.  This use of Protege home might work
> for you and this is a change that should find its way into the main protege
> distribution.


Yeah, this sort of works. The config.xml is found relative to the
environment variable I think. But the locations are found relative to
the current working directory; however, the shell script changes the CWD
to the location of the shell script before it starts the JVM, which is
why it all works.


>
> -Timothy
>
>
>
> On 10/18/2013 04:36 AM, Phillip Lord wrote:
>>
>> Guys
>>
>> I'm trying to launch protege from an already launched VM. It's not going
>> very well. The problem is that Protege hard codes various locations wrt
>> to the current working directory.
>>
>> The key problem is in BundleSearchPath which uses this code...
>>
>>          else {
>> 			path.add(new File(dir));
>> 		}
>> 	}
>>
>> which is interpreted relative to the current working directory.
>>
>> The reason I am trying to do this is because I want to be able to remote
>> control protege using clojure; actually I have this working, but
>> I have to launch clojure inside protege and then connect to it. Nice,
>> but unfortuately, it means that I don't control the classpath, so my
>> clojure code tends not to work -- I need to manage all the dependencies
>> for myself (for example, my code uses depends on ELK, which isn't
>> available).
>>
>> I'm working on some patches something like this....
>>
>>        if (dir.startsWith(PROTEGE_HOME_VAR)) {
>>                          String homeDirectory = System.getProperty(PROTEGE_HOME);
>> 			dir = dir.substring(PROTEGE_HOME_VAR.length());
>> 			path.add(new File(homeDirectory, dir));
>>                          System.out.println( "Adding protege dir file" );
>>                          System.out.println( "file is:" + new File(homeDirectory, dir) );
>>                          System.out.println( "System prop" + System.getProperty(PROTEGE_HOME) );
>>       }
>>
>> This does the same thing as with "user.home"; files which are expected
>> relative to Protege install directory are explicitly stated.
>>
>> Are you interested? Or I am missing something much easier? Oh, and is
>> there a protege-dev mailing list?
>>
>> Phil
>
>
>

-- 
Phillip Lord,                           Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics,             Email: phillip.lord at newcastle.ac.uk
School of Computing Science,            http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,               skype: russet_apples
Newcastle University,                   twitter: phillord
NE1 7RU                                 


More information about the p4-feedback mailing list