FWD » Core Development » Runtime Infrastructure

/In #6662, we inserted code to set the FWD_VERSION environment variable in the environment of a child process when we launch it via OS-COMMAND or similar statement. This allows code run in that child process to detect if it is running in FWD or in OE. The value passed down is from the jar.

We've sometimes seen scenarios where the JNI library (libp2j.so/p2j.dll) is build from a different revision than is the FWD code in its matching p2j.jar. This is usually a consequence of a build or deployment failure.

The idea here:

• At build time, we should create a static string literal in the native module that encodes the version.
• At initialization of the native module, we should check if there is a mismatch between p2j.jar and the native module. Any mismatch would be a fatal failure and we would need to exit in a manner that makes the root cause very obvious.
• Instead of passing down the version string in process launching, we can always use the hard coded version.
• As a side-benefit, one will be able to look at the binary module and see the version string (e.g. strings libp2j.so | grep "_p2j_").

Greg Shah wrote:

The idea here:

• At build time, we should create a static string literal in the native module that encodes the version.

• How could we get the version at build time?
• Is init.c the proper file to add the static variable?

How could we get the version at build time?

In build.gradle you can see we write it into code like Version.java.

Is init.c the proper file to add the static variable?

Yes, that is a reasonable place for it.

Greg Shah wrote:

How could we get the version at build time?

In build.gradle you can see we write it into code like Version.java.

Hmm, ok. Should this version be set when for example "ant native" is called?

What i mean is: should we set this through the make file?

In build.gradle you can see we write it into code like Version.java.

Hmm, ok. Should this version be set when for example "ant native" is called?

Yes, sort of. We should not be using ant native directly but it should be processed when we run gradlew native.

What i mean is: should we set this through the make file?

We could but I think it is harder to do that than to write the file out in the gradle processing and just leave makefile alone. I sy this because the make tools are less capable than gradle.

Got it. Is there a way to find the code for gradlew native ? I looked into build.gradle but did not find anything.

Got it. Is there a way to find the code for gradlew native ? I looked into build.gradle but did not find anything.

I think you'll have to add it. When people shift to this version, they will need to use gradle instead of ant.

Greg Shah wrote:

Got it. Is there a way to find the code for gradlew native ? I looked into build.gradle but did not find anything.

I think you'll have to add it. When people shift to this version, they will need to use gradle instead of ant.

But since ./gradlew native works, it must be executing some code right? Can i find somewhere what is it doing under the hood?
There are also other gradlew commands we use (./gradlew core etc.)

In build.gradle you can see we write it into code like Version.java.

Hmm, ok. Should this version be set when for example "ant native" is called?

Yes, sort of. We should not be using ant native directly but it should be processed when we run gradlew native.

I was wrong about this. I don't recall the reason but the native build is all still in ant. Look at the native targets there. We won't change that for this task.

What i mean is: should we set this through the make file?

We could but I think it is harder to do that than to write the file out in the gradle processing and just leave makefile alone. I sy this because the make tools are less capable than gradle.

So the change here should be in the build.xml for ant.

Greg Shah wrote:

Code Review Task Branch 9851a Revision 15934

The change is good. Have you tested the build process and the resulting p2j.dll on Windows?

Yes, tested on both Windows (p2j.dll) and Linux (libp2j.so).

In terms of regression testing, other than harness is there anything else i should test?

The changes should be fairly safe. Please check Hotel GUI and Hotel ChUI and something with batch processes. If the clients all start properly, we are good to go.

The testing passed.

9851a can be added to the merge queue.

Greg, I believe I’ve found an issue where the FWD version cannot be detected, either in standard Java code or in native code.

When the FWD version is not recognized, the hardcoded value in our native code is "undefined". However, in the p2j.code, ClientCore.loadNativeLibrary() and Version.getFWDVersionUnformatted() return "FWD version undefined". These values are not the same, which make the appservers not to start.

I created 9851b and committed to rev 15946.

Please review.

I do want to reiterate that many cases where the FWD version becomes "unknown" are resolved by 7133a, since it can handle bzr repositories from xfer, and other places other than our internal configuration. It is rebased and ready for review/merge, and may prevent some downstream conditions.

Roger Borrello wrote:

I do want to reiterate that many cases where the FWD version becomes "unknown" are resolved by 7133a, since it can handle bzr repositories from xfer, and other places other than our internal configuration. It is rebased and ready for review/merge, and may prevent some downstream conditions.

You did not set #7133 to Review status and set the reviewer.