Chapter 6 Programmer's Guide
Prev 6.12 Plugins Next

6.12 Plugins

6.12.1 Accessing Plugins

Plugin-implementations are accessed using the fully qualified name of the interface defining the behavior of the plugin. Suppose your project decides to implement a plugin for searching customers in the customer-database and the designers agree on the following interface: 

package at.spardat.xy;

public interface ICustomerSearch {
    public List search (String lastNamePraefix);
}
Then, the name at.spardat.xy.ICustomerSearch denotes the fully qualified interface name which is needed below to access the implementations.

At runtime, the implementation-class, i.e., the class implementing ICustomerSearch, is retrieved using the class PluginManager . The following code-fragment shows how the implementation is accessed at the Xma client:

    PluginManager      piManager = yourSession.getPluginManager();
    ICustomerSearch    impl = (ICustomerSearch) piManager.getPlugin (ICustomerSearch.class);

Here, the session is used as starting-point to get the PluginManager . At the server-side of XMA, the PluginManager is a singleton within the web-application: 

    PluginManager      piManager = PluginManagerServer.getInstance();
    ICustomerSearch    impl = (ICustomerSearch) piManager.getPlugin (ICustomerSearch.class);

Every plugin may have a server-side and/or a client-side implementation. The names and resource-references (the names of the jar-files where the implementation is packaged in) of the implementation-classes is defined in the xma-app.xml -file.

Given a particular plugin interface, the PluginManager stores at most one corresponding implementation-instance. Internally, the PluginManager uses a HashMap whose keys are the names of the interfaces and whose values are instances of the implementation-classes. This implies that the constructor (default-constructor) of a plugins implementation-class is called at most once within a web-application at the server and within a session at the client. The implementation object is lazily constructed, when the first client uses the access-methods defined above. The implementation object lives until the web-application is shut down (server side), or the client-session is destroyed (client side).

To summarize: There exists (at most) a single plugin implementation object in the web-application at the server or in the session at the client.

Since the server-side implementation object is shared by all sessions of a web-application, it must be properly synchronized.

6.12.2 Dummy Plugin

Dummy Plugin provides security plugins for development only. It can be used to start development before the needed users and permissions are configured in the underlaying authentication and authorisation systems. Do not use it in production!

Dummy Plugin contains dummy implementations for the following three plugins:

  • Client Login Module(Client side Login Plugin) The DummyLoginModule automatically logs in a user named "Dummy" in the mandant "188". The environment is always development and the Locale is the default local of the client side Java virtual machine is used, which is de_AT in Austria. It does not ask for a username or password.

  • Server Login Module(Server side Login Plugin) The DummyLoginModuleServer checks if any user was logged in by the DummyLoginModule. The check only fails if an other plugin was used for client side login.

  • Authorisation Module(Authorisation Plugin) The DummyAuthorisation allows every function to everybody. The check only fails if an other plugin was used for client side login. All numerical values are zero.

XMA projects are configured to use Dummy Plugin by default. If you want to change from a different plugin to Dummy Plugin:

The javadoc documentation of Dummy Plugin can be found at Dummy Plugin Javadoc

Prev Up Next
6.11 Security Home 6.13 Implementing Help