Carey,
Yes I am connecting to a 7.1 server.
Hugo
On Feb 1, 2008 2:04 PM, Carey Matthew Black <[EMAIL PROTECTED]> wrote:
> 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"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
