Sage API Imports....?

[broconne]

As an experience Java developer (but new Sage Developer), I feel like this might be a really stupid question.. But where exactly are the libraries listed here http://download.sage.tv/api/?

I have added sage.jar to my path - but I don't see a "sage.api" package? I looked for other likely jars in the sage dir.. I was looking to call a method in sage.api.Global that returned a sage.MetaImage. I can't seem to find Global or MetaImage.

[PLUCKYHD]

You need to call it per the instructions at the bottom of that

public static Object api(String methodName, Object[] methodArgs) throws java.lang.reflect.InvocationTargetException;

where methodName would be the call you are wanting to make.

Also method name is simply
"GetLogo"

If that is the call you are wanting to make.

or if you want to use the UIContext when calling it which I think you would in this case

public static Object apiUI(String uiContextName, String methodName, Object[] methodArgs) throws java.lang.reflect.InvocationTargetException;

I believe of the top of my head it is something like sage.SageTV.apiUI() when calling from java but that is from memory so don't hold me to it. It is probably the leading SageTv package that is throwing you off.

I would also recommend looking at the sagex api by stuckless it is object oriented and really friendly/easy to use as it builds the object[] so you don't have to each time manually.

[Fonceur]

You can also look at using GKusnick's Studio Tools...

[PLUCKYHD]

Originally Posted by Fonceur

You can also look at using GKusnick's Studio Tools...

Yeah sorry I forget about his sometimes but he has some good api wrappers as well.

[GKusnick]

Originally Posted by Fonceur

You can also look at using GKusnick's Studio Tools...

Thanks for the plug. To clarify a bit, my Studio Tools plugin adds some searching and editing commands to the Studio menus. My Tools Library plugin contains the API wrappers. So if all you want are the wrappers, you don't need the Tools, just the Library. (Although I recommend the Tools as well if you're doing serious Studio work.)

[broconne]

Originally Posted by PLUCKYHD

You need to call it per the instructions at the bottom of that

public static Object api(String methodName, Object[] methodArgs) throws java.lang.reflect.InvocationTargetException;

where methodName would be the call you are wanting to make.

Also method name is simply
"GetLogo"

If that is the call you are wanting to make.

or if you want to use the UIContext when calling it which I think you would in this case

public static Object apiUI(String uiContextName, String methodName, Object[] methodArgs) throws java.lang.reflect.InvocationTargetException;

I believe of the top of my head it is something like sage.SageTV.apiUI() when calling from java but that is from memory so don't hold me to it. It is probably the leading SageTv package that is throwing you off.

Holy "Lack of Static Type Checking" Hell.....

There must be an architectural reason for it - but it just seems crazy.

So - I call the method, I get back an Object... How do I cast it to a MetaImage so I can work with it - since I can't seem to find the MetaImage class to import either?

I would also recommend looking at the sagex api by stuckless it is object oriented and really friendly/easy to use as it builds the object[] so you don't have to each time manually.

Will do.

[PLUCKYHD]

Originally Posted by broconne

So - I call the method, I get back an Object... How do I cast it to a MetaImage so I can work with it - since I can't seem to find the MetaImage class to import either?

I do it bass ackwards for the same thing getting a sagemediaobject class, but there surely is a better way so hopefully someone chimes in. Basically I take an object that i know is a sagemediaobject and say

Object = currmediaobject
Class currclass = crrmediaobject.getClass()

That currclass at least lets me cast to it from on object later on.

As I like you couldn't see anway to import the MediaObject class of sagetv. Hopefully someone else knows a better way

[PLUCKYHD]

of course I just realized my method wouldn't help you much...sorry

[GKusnick]

Originally Posted by broconne

There must be an architectural reason for it - but it just seems crazy.

The Sage core libraries are obfuscated. I assume it seemed preferable to them to provide just one unobfuscated entry point to their code, rather than exposing the entire API.

Originally Posted by broconne

So - I call the method, I get back an Object... How do I cast it to a MetaImage so I can work with it - since I can't seem to find the MetaImage class to import either?

You don't. There's nothing you can do with a MetaImage except pass it to other API methods that expect one. So you might as well leave as an Object.

I haven't used the sagex wrappers, but mine cast the returned objects to the appropriate types in cases where those types are not obfuscated.

[tmiranda]

Another vote for the sagex wrappers....

[Slugger]

I live and die by GKusnick's wrappers! Strongly typed API calls save massive headaches with typos, etc. I've never actually written plugin code with anything else. Just recently I've started using Stuckless' remote API wrappers as some of my current work involved interacting with the Sage server outside of its JVM process, which means GKusnick's wrappers aren't an option. If you're writing code that will only live inside the Sage JVM then I recommend GKusnick's wrappers. If you're writing code that will run outside the Sage JVM then Stuckless' wrappers are the answer. Both very good, both very easy to use. I give both two thumbs up! Just a slight edge to GKusnick's because I really love the strongly typed aspect of them.

[stuckless]

When I wrote the sagex-apis, I needed a set of apis that suited my development process. I like to code, debug and run my code all from eclipse, and that's not something I could do using the native sage calls or greg's wrappers. sagex-apis enabled me to live in eclipse 100% of the time, and I only deploy and restart my sage server when I'm about to deploy my code. This ability to run code directly from eclipse has saved me litterally 100s of hours.

When I first started out with Sage, I used Greg's wrappers as well. They are a great alternative to simply calling the sage apis from java. I didn't create a set of statically typed apis because I didn't want to simply recreate what greg had done, so I went route of creating the APIs to mirror how SageTV documented them.

It would be interesting, if greg's apis could somehow use the sagex apis to make it's calls, rather than the core sagetv call. This would give the ability to use Greg's apis in development and remotely. I actually contacted greg about doing just that. At the time, he wasn't interested, but he did say that if the development community asked for it, then he might consider it. Obviously it would have to be done in such as way that his apis do not depend on mine, but rather, if mine are present, then you have to option to use either my api or the native api when invoking sagetv calls.

I have since looked at creating a set of statically typed API calls for sagex as well, and it's not hard to do, but it's not high on my priority list, at the moment.

[PLUCKYHD]

I never have luck running code direct from netbeans using the sagex API. Te console always says something like we must be running remotely in the print out but it never seems to work. Am I missing something I need to be doing?

[stuckless]

Originally Posted by PLUCKYHD

I never have luck running code direct from netbeans using the sagex API. Te console always says something like we must be running remotely in the print out but it never seems to work. Am I missing something I need to be doing?

sagex-api uses an automatic discovery to find a server. When it starts it first tries to see if it can use the apis natively, and if can, then it will use direct sage calls. But if it can't then it will ask the network for any available sage server that it can use. If none reply, then it will fail.

To start, you'll need do a simply test program...

package test.junit;

import sagex.api.Global;

public class TestRemote {
	public static void main(String args[]) {
		System.out.println("Server: " + Global.GetServerAddress());
	}
}

When this runs it should return something like...

INFO - Configured Root Logger
LOG4J: Configured Root Logger
INFO - Configured Logging for: sagex-api using file: sagex-api.log4j.properties
LOG4J: Configured Logging for: sagex-api using file: sagex-api.log4j.properties
Embedded SageAPI is not functional.  We are most likely running remotely.
Adding Remote Server: seans-desktop
Adding Remote Server: mediaserver
Server: seans-desktop

If you don't see, Adding Remote Server:, or Server: is null, then it did not find a remote server. While I've never had this happen, personally, I do know that others have mentioned that it doesn't find a remote server. You need to make sure that you have the sagex-services installed on the sage server. Without that, then it cannot connect. If you have that installed, but you still cannot connect, then you can force the server.

package test.junit;

import sagex.SageAPI;
import sagex.api.Global;
import sagex.remote.rmi.RMISageAPI;

public class TestRemote {
	public static void main(String args[]) {
		SageAPI.setProvider(new RMISageAPI("mediaserver"));
		System.out.println("Server: " + Global.GetServerAddress());
	}
}

then the output should look like...
INFO - Configured Root Logger
LOG4J: Configured Root Logger
INFO - Configured Logging for: sagex-api using file: sagex-api.log4j.properties
LOG4J: Configured Logging for: sagex-api using file: sagex-api.log4j.properties
Server: mediaserver

Notice the messages about running remotely and adding servers are not gone, since you've force the implementation to be a specific server. You'd only ever do this in a test stub... ie, never force the implementation inside of "real" code

[Slugger]

Sean:

We need to get together for an afternoon sometime when you have the time to debug the auto discovery code because auto discovery has never worked for me. As it turns out, in the context I've been using the remote APIs, I really want to explicitly set the provider anyways so this issue doesn't affect me. I don't hardcode the ip/port for RMI in my code, it's provided to the external JVM by other means and then I set the provider with that data, but I can also envision plenty of future use cases where I would really want auto discovery to function so I'm more than willing to spend some time digging into it with you. Email me if you want to dig into it sometime.

[stuckless]

Originally Posted by Slugger

Sean:

We need to get together for an afternoon sometime when you have the time to debug the auto discovery code because auto discovery has never worked for me. As it turns out, in the context I've been using the remote APIs, I really want to explicitly set the provider anyways so this issue doesn't affect me. I don't hardcode the ip/port for RMI in my code, it's provided to the external JVM by other means and then I set the provider with that data, but I can also envision plenty of future use cases where I would really want auto discovery to function so I'm more than willing to spend some time digging into it with you. Email me if you want to dig into it sometime.

I agree... I've been pretty busy, but I haven't forgotten about it... maybe we can try do it over a lunch hr some day. I'm wondering if it's a windows vs linux thing. I'm wondering if windows is blocking the udp packets. I've been meaning to test this in my windows vm, but I haven't got around to that either

[PLUCKYHD]

Originally Posted by stuckless

Notice the messages about running remotely and adding servers are not gone, since you've force the implementation to be a specific server. You'd only ever do this in a test stub... ie, never force the implementation inside of "real" code

Wow do I get the dunce cap for the day I didn't have the remote service general plugin installed only the sagex jar

It works remotely now what I life saver. I had it working under v6 long ago and just assumed it was a v7 issue.

Thanks