Getting a valid UIContext from 3rd party apis

[razrsharpe]

As some of you know jphipps and i have been trying to get the ortus api to reliably figure out the UIContext from within the api without having to pass down the UIContext from the STV every single time. I talked with Sage support and they pointed us in the right direction to create a work around until they update their api to support GetUIContextName() for third party apis. They said that they plan to make the UIContext() work for third party api's the way it should in the next version so this is only a temporary solution.

Method A:
This works in an automated fashion in that you do not need to pass anything from the STV to your api. Basically you need to parse the UIContext from the thread name, store that in a ThreadLocal variable and use that variable whenever you need a UIContext().

There are a couple of places when the thread name does not include the UIContext and you need to do something different... Method B... (there may be others but we haven't run into them yet... ):

• ApplicationStartup hook
• BeforeMenuLoad hook of the Main Menu the 1st time the Main Menu is loaded (near as i can tell the UIContext does not get set until the end of the hook)
• Forked() threads

Method B

In cases where you need a UIContext but the thread name does not contain a valid UIContext you need to pass the UIContext from the STV to a method that stores the passed UIContext for that thread (in the same ThreadLocal variable from method A).

Hopefully this is useful to some of you. If you have any questions just ask... I'm not a UIContext expert but learned a fair amount about it with this exercise...

An excerpt of our code to help the explanation

Summary:

• UIC.StoreUIContextFromThread() - Parses the thread name and stores the UIC in the UIC ThreadLocal variable
• UIC.StoreUIContextName( String UIC_Str ) - Stores UIC_Str in the UIC ThreadLocal variable
• UIC.GetUIContextName() - returns the String representation of the current thread's UIContext.
• UIC.GetUIContext ()- returns the UIContext representation for the current thread's UIContext... for sagex so you do not need to create a new UIContext(UIC_Str) all the time

import sagex.UIContext;

public class UIC
{
    private static ThreadLocal UIContext = new ThreadLocal();

    public static String GetUIContextName() {
        StoreUIContextFromThread();
        return (String) UIContext.get();
    }

    public static void StoreUIContextName(String UIC_Str) {
        UIContext.set(UIC_Str);
        return;
    }

    public static UIContext GetUIContext() {
        return new UIContext(GetUIContextName());
    }

    public static void StoreUIContextFromThread() {

        if (UIContext.get() == null) {

            Thread t = Thread.currentThread();
            String tname = t.getName();
            String uiname = tname.substring(tname.lastIndexOf("-") + 1);
            
            //Some Error Checking to make sure we found a valid UIContext

            StoreUIContextName(uiname);
            return;
        }
        return;
    }
}

[stuckless]

Good job Razrsharpe. I spoke with sage support about this as well (many months ago), and they suggusted the same path.

I didn't implement it into the sagex.apis because I wasn't convinced that it would be reliable. So, i'm interested in your testing to see how it works out. The issue that I saw with using the ThreadLocal is that once a thread local variable is set, then the assumption is that sage will ONLY ever use that thread for that given UI context. I'm not sure this is the case. ie, if Sage uses thread pools, then you could get some contamination.

The approach that I started, but never finished, was to ALWAYS figure out the UIContext each time it was needed (using the thread naming hack). It was be slightly more overhead, but it would be more reliable as well.

If you continue to use the ThreadLocal approach (if it proves sucessful) then you might consider changing it to an InheritableThreadLocal, since that would allow all child threads created from the current thread to automatically inherit the ui context variable.

Keep me posted on how this works out. This is important for phoenix as well.

thanks for the info.

[jphipps]

Hello,

That InheritableThreadLocal seems to work pretty well from my preliminary testing... I tested it from a Fork() in the STV ( which doesn't have the context name in the thread name) and a spawned thread from java, and it seem to carry the UIContext through to both...

Thanks for the tip...

Jeff

[razrsharpe]

Sean, like Jeff said thanks for the tip on the InheritableThreadLocal. As we find issues / successes with this method we'll post the info here so we all know whats going on.

By looking through the log and paying attention to the thread names it appears that a given thread is only used for a single UIContext. Only further testing will confirm this but so far it looks promising.

Hopefully, any of these methods are only temporary fixes until Sage releases their next code base. Jeff from sage (narflex) was initially concerned about the amount of overhead keeping track of the UIContext for all methods would add to the core api but then after thinking about it some more he realized/determined that they only need to keep track of it for reflected (ie third party) methods and says that will only be a minimal amount of overhead. So in the next api release they will fix GetUIContextName to work like its supposed to ... who know when that will be though, hence the time spent on the work around...

Aaron