2

We are trying to use a org.JSON.JSONObject library for some intense json processing in the adapter side. We have Java classes which processes the data received from http adapters.

mobilefirst 6.3.0 and using cli 20150701 build

(the recent one).

This JSON referencing has no issues when building from eclipse mobilefirst studio environment.

We are building this environment in ubuntu linux 14.04. There is an error in referencing org.JSON.JSONObject..x.jar file when we execute 

mfp start or mfp build or mfp deploy

Is there a way to reference this jar file during mfp start or mfp build or mfp deploy as a classpath.

We need to have something like 

mfp -classpath "path/to/json.jar" build

please help.

Futur
  • 8,444
  • 5
  • 28
  • 34
  • Not quite understanding. Is the jar used by your application once it has built and deployed or by some custom step in a build/deploy process? – djna Jan 23 '15 at 15:30
  • where are you using/referencing this jar in an application (android) or in an adapter? – Yoel Nunez Jan 23 '15 at 17:38
  • its in the adapter side. – Futur Jan 23 '15 at 17:40
  • @djna this is used during runtime in the adapter side. this is used by java classes we have written to process the JSON output from an adapter. – Futur Jan 23 '15 at 17:42
  • 1
    See if this approach works for you: http://stackoverflow.com/questions/25093518/how-to-add-java-classes-to-a-worklight-adapter-when-using-cli – Idan Adar Jan 23 '15 at 17:42
  • @IdanAdar this may not help as we have no problem adding java classes to the server/java folder. We need to have something like mfp -classpath "path/to/json.jar" build . – Futur Jan 23 '15 at 17:48

3 Answers3

5

As it turns out, the CLI does not yet recognize jars placed into the server/lib folder of your project. In oder to make this work, you can make a simple edit to the following file:

[cli install folder]/mobilefirst-cli/node_modules/generator-worklight-server/lib/build.xml

At or about line 123, add the third fileset element shown below:

<!-- Classpath for server runtime libraries used when building the WAR -->    
<path id="server-classpath">
    <fileset dir="${worklight.jars.dir}" includes="worklight-jee-library.jar" />
    <fileset dir="${worklight.server.install.dir}/wlp/dev" includes="**/*.jar" />

    <!-- add server/lib folder to classpath -->
    <fileset dir="${worklight.app.dir}/../server/lib" includes="**/*.jar" />
</path>

After that, running 'mfp start' (or 'mfp restart' if your server is already running) will compile your custom Java code with any jars that you add to the server/lib folder included in the classpath.

bjustin_ibm
  • 101
  • 3
  • thanks for the response, however do you think the solution i have posted below is good to go ? any comments ? – Futur Jan 24 '15 at 07:24
1

JARs for use by your adapters should be added to you Project's server directory in the folder lib. They will be included in your Projects WAR file when the project is built (in Studio or by the ant tasks) and when you deploy that WAR it will be visible to your adapters.

djna
  • 54,992
  • 14
  • 74
  • 117
  • 1
    Did exactly this, but the situation is the we have to build and deploy in the ubuntu server again. So then it fails to pick this JAR then. – Futur Jan 23 '15 at 18:49
0

I agree with @bjustin_ibm. Thanks for that. While the above approach works, there's also another way of doing this.

Alternative hack

Just add your required .jars to the following location, it gets added to the classpath during mfp start

/home/instanceubuntu/.ibm/mobilefirst/6.3.0/server/wlp/dev/spi/third-party

This solution is more simple and doesn't really have to maintain the build.xml file.

Hope this helps.

Futur
  • 8,444
  • 5
  • 28
  • 34
  • 1
    Yes, this will work as the 'wlp/dev/' folder is already on the classpath. There are a few downsides to this approach though. 1. This will affect every project deployed to this server. This wouldn't effectively be a problem if you only ever have one project. 2. We generally consider the mobilefirst server contents under ~/.ibm to be somewhat ephemeral. There are certain scenarios that result in these files being removed or overwritten by the CLI - meaning you _may_ lose changes in there in the normal course of using the CLI, at which point this hack may stop working. – bjustin_ibm Jan 26 '15 at 13:45
  • What would those down side be, if you could advice please ? – Futur Jan 26 '15 at 13:47
  • Sorry my comment got submitted before I finished typing it ;) I have updated the original comment with the specific drawbacks of using this approach. – bjustin_ibm Jan 26 '15 at 13:54
  • @bjustin_ibm this makes perfect sense. Thank you again for sharing. Good day :) – Futur Jan 26 '15 at 13:57