Hugo,

Note that Appajee said this: "pure Java RPC implementation (for
servers >=7.0)". Are you connecting to a ">=7.0" ARS server?

-- 
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)

Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.



On Feb 1, 2008 4:01 AM, Hugo Visser <[EMAIL PROTECTED]> wrote:
> ** 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

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Reply via email to