OK, but my code isn't using any of the things you mention. In fact the code
that I tested ran on 7.1 beta without any native dependencies. The following
snippet triggers JNI loading stuff and errors if it fails:
ARServerUser context = new ARServerUser("Demo","","","ltvisserh71");
context.setPort(8001);
context.login();
Which is about as trivial as it gets...
But if I understand correctly BMC wouldn't consider this a bug as the goal
was not to eliminate the native libs right? Well I guess it's too bad for me
then, I'd hoped for the day that I would not need all the native libs
deployed with my apps.
This also means that for now 7.1 API code won't run on non-supported
platforms such as the Mac, I was under the impression that someone stated
earlier that it would be possible now, if you'd avoid the functions that
require JNI.
But thanks for the clarification and confirmation.
Hugo
On Feb 1, 2008 3:38 AM, Papolu, Appajee <[EMAIL PROTECTED]> wrote:
> **
>
> Hi All,
>
>
>
> >>>
>
> So can anybody on the list confirm that this scenario does work (hint:
> make sure there are no 7.1 libraries in you PATH)? Maybe Appajee can step
> up and shed some light on this.
> <<<
>
>
>
> As of now 7.1 indeed still has some native code in it. If you will, you
> can see the version 7.1 of Java API as – result of an effort in
> simplifying the Java API (with collections use, elimination of redundant
> wrapper classes and so on) and ground-up implementation of pure Java RPC
> client stub. Unfortunately we have not attained 100% of the pure RPC client
> stub implementation (& other behaviors that were depended upon the
> underlying C layer in the olden JNI layer). Actually, the goal of 7.1 is
> NOT to attain the complete 'JNI elimination goal' in one shot, considering
> what is realistic. So what we ended up at the end of 7.1 is – mostly
> 'pure' Java implementation and much simplified API but with little JNI
> dependency clinging on. So you can be assured that we are aware of the
> "remaining" JNI dependent pieces and we're making strides to eventual
> elimination of that. Beyond that, I can't make any comments on future
> product deliverables/commitments etc.
>
>
>
> As to specific areas where this native code dependency remains as of 7.1,
> they are as follows:
>
> - Qualification parsing/formatting
>
> - Assignment parsing/formatting
>
> - Alert API
>
> - To leverage RPC version mapping that allows for 7.1 Java API to
> talk to older than 7.0. [BTW, 7.1's new Java RPC code is validated for
> talking to 7.0/7.1/above]. So, to interact with a specific AR Server,
> while it is all seamless to API client code, 7.1 Java API engages its pure
> Java RPC implementation (for servers >=7.0) OR the underlying JNI code
> (which in turn talks to C API) for talking to servers older than 7.0.
>
> - I can't remember any more on top of my head right now, but there
> could be a couple more not-so-critical but unfinished work items.
>
>
>
> >>>
>
> . I've disabled JNI loading through the arsys_api.xml file and set the
> JRPC mode to true. Calls to Config.getInstance().getJrpcMode() and
> Config.getInstance().getJniLoadMode() confirm this at runtime.
> <<<
>
> I have not lately played with this stuff. But as long as, you do not
> exercise the functionality noted above & configured the mode to be Java RPC
> & JNI load mode is set to zero – Java API should proceed without looking for
> JNI code as much as possible.
>
> <jrpcMode>true</jrpcMode>
>
> <jniLoadMode>1</jniLoadMode>
>
> Of course, this is unsupported and I would not encourage you to put
> production/serious apps based on this kind of configuration tweaking.
>
>
>
> Regards
>
> Appajee
>
>
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers
> Are" html___
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
