Working with Contexts

An initial object providing access to a context tree implements ContextManager interface. There are several ways to obtain a context manager.

The method of getting an instance of ContextManager depends on the current environment:

• If developing an application using Iotellect Server API, use RemoteServerController.getContextManager() to get context tree manager of remote server
• If developing a Device Driver, use DeviceContext.getContextManager() to get server context tree manager
• If developing a plugin, the context manager is passed as a parameter to install(ContextManager cm) and deinstall(ContextManager cm) methods. If inside install(ServerContext context) and deinstall(ServerContext context) methods, use ServerContext.getContextManager().
• When developing a Java-based Agent, remember that your Agent has just a single context. However, its context manager can be accessed via Agent.getContext().getContextManager().
• When writing a server script, call ScriptExecutionEnvironment.getScriptContext().getContextManager() to access server context manager.
• When writing a widget script, call WidgetScriptExecutionEnvironment.getEngine().getServerContextManager() to access remote server's context manager. Alternatively, you can call WidgetScriptExecutionEnvironment.getComponentContext("componentName").getContextManager() to access context manager of widget components' context tree.

An instance of CallerController object incorporating current user's permissions must be passed to most context-related calls if you're writing code that will work inside the Iotellect Server JVM (e.g. if developing a server script or plugin). Failure to do so will result to null results of different access denied exceptions.

See Dealing with Access Permissions for details.

There are two principal ways to retrieve a context having its path:

• Call get(String path) or get(String path, CallerController caller) method of a Context
• Call get(String path) or get(String path, CallerController caller) method of a ContextManager

These generally return the same result unless they are used in distributed architecture. However, in a distributed environment their behavior is fundamentally different:

• Methods of ContextManager interpret provided path String as a local path on the server the ContextManager belongs to.
• Methods of Context interpret provided path as a path on a remove server the Context belongs to. This is valid if the context of a proxy context representing a remote peer connected via distributed architecture.

Thus calling get() methods of a Context is normally a preferred behaviour. Calling get() methods of a ContextManager can often cause unpredictable results in a distributed installation.

Example of retrieving a context with the specified path.

Context deviceContext = anotherContext.get("users.admin.devices.device1");

The get() method will return null if requested context does not exist or is not available with current permissions.

Using get() method of a Context to retrieve another context means that there should be always some context to call this method from. This may mean some additional planning and cogitation during the development phase while code that uses get() methods of a ContextManager still perfectly works in a non-distributed development environment. However, this generally erroneous code will later fail in a distributed production environment.

When working with a specific context, use Context.getParent() and Context.getChild(String name) to access its parent and named child contexts respectively.

Use ContextManager.getRoot() to access the root context of a context tree.

Constants defined in Contexts class and static methods of ContextUtils class provide convenient ways to construct paths of different server contexts, such as Alert or Device contexts. Example: Context alertContext = contextManager.get(ContextUtils.alertContextPath("admin", "myalert"));

To get the list of certain context's children contexts, call Context.getChildren().

Server-side call to getChildren(CallerController caller) will return only children that are accessible to the calling user (represented by CallerController). Call to getChildren() of a proxy context (e.g. when using remote API or developing an Agent) will return only children accessible to the user that is authenticated in the current server connection.

The Context interface has several methods for getting basic information about a context:

• getName()
• getPath()
• getDescription()
• getType()
• getGroup()

If you're developing code running in Iotellect Client or in your third-party application and acquiring a Context via the API, it results to getting a proxy context matching a remote server-side peer. Therefore, even the simplest method calls may result to network I/O and get significantly delayed or even fail due to network issues.

Was this page helpful?

Tell us more

Send

Thank you!