I've been meaning to replay to Tim's private email for ages but got
sidetracked with epic stomach flu and work.
I've actually forked clojure-osgi and brought it up to date to Clojure
1.6:
<dependency>
<groupId>com.theoryinpractise</groupId>
<artifactId>clojure.osgi</artifactId>
<version>1.6.0-1</version>
</dependency>
This wraps a copy of clojure 1.6 itself, along with the clojure.osgi
support namespace, there's a very simple clojure+osgi demo at
https://github.com/talios/clojure.osgi.demo/blob/master/pom.xml
I've been meaning to write up a blog post for ages on this, but since
I've been sidetracked and we've not yet got this working in production (
it works, we've just not yet found a suitable part of our app to rework
yet - without other major changes ).
The key part in the pom.xml are the two OSGi Manifest headers:
<Clojure-Require>com.theoryinpractise.clojureosgi.demo</Clojure-Require>
<Clojure-ActivatorNamespace>com.theoryinpractise.clojureosgi.demo</Clojure-ActivatorNamespace>
The first being the namespace to (require) into the clojure runtime, and
the other the namespace to "executute" to startup.
You can see in the
https://github.com/talios/clojure.osgi.demo/blob/master/src/main/clojure/com/theoryinpractise/clojureosgi/demo.clj
file we define two functions `bundle-start` and `bundle-stop` which, as
you can guess trigger when the bundle starts/stops.
There's also the `(os/register-service)` macro call which takes an
interface, and a bunch of terms that reify into the interfaces methods
and registers this as an OSGi service for that interface. From within
these methods you just do your normal clojure stuff.
One thing to note with a lot of the Clojure/OSGi stuff is that things
_really_ like being AOT'd so that bnd picks up the exports/imports etc.
etc.
Tim - sorry for not getting back to you sooner.
Mark
On 19 Aug 2014, at 11:45, Neil Bartlett wrote:
As far as I can tell Clojure is a black box to everybody, with the
possible exception of Mr Rich Hickey…
Sorry I can’t help further.
Neil
On 19 August 2014 at 00:36:05, Tim McIver ([email protected]) wrote:
I should also mention that I get different errors with this problem
bundle depending on how I bring the system up - and this could
indicate
that it is a Clojure issue.
If I start the Felix console and install and start the bundles "by
hand", I get the error that I showed before. But if I start the Felix
console and the bundles are cached, then Felix automatically starts
them
and I get an error like the following:
java.io.FileNotFoundException: Could not locate
com/example/MyClass__init.class or com/example/myclass.clj on
classpath
(the .clj file is a Clojure source file). Now that I think about it
this could be due to the order in which the bundles are started.
Perhaps one of these bundles does not properly handle a missing
dependency. And the Clojure bundle is a bit of a black box to me at
this point.
Tim
On 08/18/2014 07:25 PM, Tim McIver wrote:
Neil,
Running that command shows that the correct package is being imported
and resolved to the correct bundle.
I should probably also mention that both the class that is being
instantiated as well as the class from which it is derived are
compiled
from Clojure code. This /shouldn't/ matter as there are .class files
for both of these classes that are normal Java byte code. But one of
the bundles that I'm using is a Clojure OSGi bundle. Clojure is
problematic in OSGi as it has its own classloader but this bundle
(not
created by me) /should/ handle this correctly, but I don't know for
sure.
Tim
On 08/18/2014 05:29 PM, Neil Bartlett wrote:
Does the “problem bundle” import the package? You can check this
with the following command:
inspect req osgi.wiring.package <bundle-id>
Regards,
Neil
On 18 August 2014 at 22:09:17, Tim McIver ([email protected])
wrote:
Hello,
I'm getting a NoClassDefFoundError when trying to start a bundle
that
resolves without error. This happens when trying to instantiate a
class
(in the bundle activator) whose .class file resides in the bundle
itself. But the class being instantiated is derived from a class
found
in another bundle, already resolved and started. To confirm that
I've
got things wired up in the way that I think I do, I ran the
following
command at the Felix console:
g! which <problem-bundle-id>
<fully-qualified-name-of-class-that-gives-noclassdeffounderror>
and the response is good (I think):
Loaded from: <com.example.impl> [50]
where 50 is indeed the ID of the bundle where I'm exporting package
com.example.impl. Any idea what could be causing this?
Thanks,
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
