Home› AMX User Forum› Duet/Cafe Duet
Options

Other AMX bundles

JasonSJasonS Posts: 229
in Duet/Cafe Duet
I am having quite a day today. Anybody used any of the other AMX bundles that are in the Java Build Path by default? I am trying to use the JSON bundle. Duet installs it at start up once it is added to "File Dependencies" in manifest.duetmf: 
(0000077765) DA: installing dependency: file:doc:/bundle/json-bundle.jar

But I can't use it. If I add it to the "Import Packages" in manifest.duetmf I get a class not found exception at start up, if I don't put it in the "Import Packages" I get the class not found exception when the code that uses JSON runs.

Other than just using the jar directly, does anybody know how to make this work? (JSON isn't really required for this application, I am now using a Property instead. I want to know how to get it to work because I do need it in the future.)

Comments

  • Options
    mighemighe Posts: 39
    Never use AMX bundles, you can't rely on them very much: they messed up everything with firmware 4.xx!
    Those bundles are also not documented, so it's better to not depend on them.

    When I needed something more, I used generic libraries: this way I had reliable code that can runs on a common JVM.
    I like to see AMX as a platform to run code, not as the target platform.
    My code can be tested via junit ad has been developed in a TDD way, for example.

    Follow the old good software engineering rules: your code should not depend directly on external framework, but encapsulate it in an isolation layer.

    My 2 cents :)
  • Options
    JasonSJasonS Posts: 229
    The JSON bundle is the org.json package with OSGi bundle parameters in its manifest, not AMX specific code, and there is plenty of documentation at www.json.org. I just want to use the JSON package without having to include it in each individual module I use it in. I think this bundle is more specifically a "bundle fragment" and I am just looking for some clues on how to use it.
  • Options
    PhreaKPhreaK Posts: 966
    Where are you getting the JSON bundle from? It sounds like the class you are after is not being exported, hence it won't can't be found by the OSGi framework when it does the dependancy dance. If it's not being imported and you don't have it within the bundle you are deploying, as in your second case, then the JVM will freak out as there's no class to instantiate.
  • Options
    JasonSJasonS Posts: 229
    The bundle is from AMX, it is in the Duet Build Path by default. It is located in "C:\Program Files (x86)\Common Files\AMX Share\Duet\bundles". When I add the file to the "File Dependencies" in Manifest.duetmf and load the program thru Netlinx studio the bundle gets copied to the master and started when Duet starts. I have dug into the Jar file, the org.json package is exported in the manifest but there is no bundle activator code. I was thinking I might have to manually load the classes but all the references I have seen to this online, most notably Neil Barttlet's blog (http://njbartlett.name/2010/08/30/osgi-readiness-loading-classes.html), indicate this as a bit of a hack and not the preferred method of getting this to work.
  • Options
    PhreaKPhreaK Posts: 966
    Ah ok, I was running an old Duet runtime on this computer - can see it now. It looks like that json-bundle exports the package without any version information. If you do an import-package without the version attribute this should get it playing nicely:
    Import-Package: org.json

    *edit*
    This looks like the same issue you faced [post=65963]here[/post].
  • Options
    JasonSJasonS Posts: 229
    It is the same issue, maybe they did not version anything in 4.x firmware? So the version info for the bundle is part of the export package property as opposed to one of the other version properties? I will have to give this a try. Thank you!
  • Options
    PhreaKPhreaK Posts: 966
    JasonS wrote: »
    So the version info for the bundle is part of the export package property as opposed to one of the other version properties?

    Yep. The version attribute is optional within the export-package items. If it's not specified it defaults to 0.0.0. This meant that when you tried to import org.json v1.0.0 is was looking for a minimum version of 1.0.0 which it couldn't find and resulted in your resolution issues.
Sign In or Register to comment.