Modules

Modules are installable parts of an application, or even a complete application, that can contain:

Services
Themes
Business contexts
Monitoring events
Components
Java classes
Hibernate entities
RESTful Web Services (JAX-RS)
Internal libraries
Workflow

Services

A module can have services that will be made available by the portal while the module is available. The services can be located anywhere within the module.

Themes

A module can have themes that will be made available by the portal while the module is available. The themes can be located anywhere within the module.

Business contexts

A module can have business contexts that will be made available by the portal while the module is available. The business contexts can be located anywhere within the module.

Monitoring events

A module can have monitoring events that will be used by the portal while the module is available. The monitoring events can be located anywhere within the module except for the root.

<?xml version="1.0" encoding="UTF-8"?><monitor xmlns="http://www.lumis.com.br/lumisportal/xsd/monitor-definition">
	<fields>
		<field id="my.event.field1">
			<name>STR_MY_EVENT_FIELD1</name>
			<data-type>string</data-type>
		</field>

<field id="my.event.field2">
			<name>STR_MY_EVENT_FIELD2</name>
			<data-type>keyword</data-type>
		</field>

<field id="my.event.field3">
			<name>STR_MY_EVENT_FIELD3</name>
			<data-type>datetime</data-type>
		</field>
	</fields>

<field-groups>
		<field-group id="my.event.fieldGroup1">
			<field id="my.event.field1"/>
			<field id="my.event.field2"/>
		</field-group>
	</field-groups>

<events>
		<event id="my.event">
			<name>STR_MY_EVENT</name>
			<description>STR_DESCRIPTION_MY_EVENT</description>
			<string-resource-path>myevent/strings</string-resource-path>
			<image>myevent/img/icon.svg</image>
			<verb>STR_VERB</verb>
			<fields>
				<field-group required="false" id="lum_request"/>
				<field-group required="false" id="my.event.fieldGroup1"/>
				<field required="true" id="my.event.field3"/>
			</fields>
		</event>
	</events>
</monitor>

Java Classes

When a Java class is made available, it becomes available through the portal's class loader. It is not recommended for a Java class made available in one module to use a Java class made available in another module. If it does, the class that references the other can only do so using reflection, which would make this situation impractical.

Hibernate Entities

The Hibernate entities present in the installed module will, by default, be automatically registered and ready for use in the standard EntityManagerFactory, once the module has been installed. If there is a need to change which EntityManagerFactory the entity will be made available in or if the entity cannot be made available automatically, just annotate the class with the annotation lumis.portal.dao.jpa.PortalEntity.

RESTful Web Services (JAX-RS)

Java classes present in the module containing @Path or @Provider annotations from JAX-RS will be processed and included in the portal application's REST execution engine. Below is an example of a class that provides RESTful operations, such that when accessed "<portal base URL>/hello/text" returns a text, and when accessed "<portal base URL>/hello/bean" returns an object converted to XML or JSON based on the preference indicated by the request header. For more information on how to implement a RESTful Web Service using JAX-RS, refer to the JAX-RS documentation.

In order to facilitate development, during REST calls, which are usually dynamic, the LumisXP by default includes the response header "Cache-Control" with the value private, no-cache, no-store, no-transform. This can be altered using the annotation lumis.portal.rest.util.CacheControl or by explicitly specifying another value for that header in the response.

For possible troubleshooting solutions, see this page.

Availability of module resources

The resources of a module are maintained as long as it exists in the portal. The portal will properly execute resource changes when there are changes (inclusions, updates, and deletions) of modules.

Module definition

The module must contain a definition file that contains general information about the module, such as its identifier. See more about the identifier in Module Definition.

Internal libraries

Each LumisXP module can optionally contain .jar files of necessary libraries for its proper functioning.
These files must be located within the module, in the META-INF/lib folder.

For example, if you want to use the Apache Commons Math library in a module, just add its .jar file in the META-INF/lib folder of the module, as in the following figure.

Workflow

A module can have workflows that will be made available by the portal while the module is available. The workflows can be located anywhere within the module.

Module classloaders

To understand how modules constitute classloaders, see the page Portal Classloader.

Module lifecycle callbacks

LumisXP has module lifecycle callbacks. For more information, see the page Module Lifecycle Callbacks.