Open Systems Gateway Initiative (OSGI)

OSGi has developed a specification to build modular and extensible applications. The OSGi module system allows building applications as a set of reloadable and strongly encapsulated services. OSGi “bundles” run inside an “OSGi container”, which manages relations among bundles. Again, bundles are simply JAR files that contain extra metadata indicating what services they require and which they provide.

OSGi Framework

The OSGi Framework is made up of three layers which define how extensible applications are built and deployed.

  • Module
  • Lifecycle
  • Services.

The responsibilities of the layers are:

1. Module:

Defines how a module, or a Bundle in OSGi is defined. Basically, a bundle is just a plain old JAR file, whose manifest file has some defined entries. These entries identify the bundle with a symbolic name, a version and more. In addition there are headers which define what a bundle provides – Export-Package – and what a bundle requires to be operative – Import-Package and Require-Bundle.

2.Lifecycle:

The lifecycle layer defines the states a bundle may be in and describes the state changes. By providing a class, which implements the BundleActivator interface and which is named in the Bundle-Activator manifest header, a bundle may hook into the lifecycle process when the bundle is started and stopped.

3. Services:

For the application to be able to interact, the OSGi Core Specification defines the service layer. This describes a registry for services, which may be shared.

Sample Manifest information:

Export-Package: *
Import-Package: *
Private-Package: *
# Include-Resource: 
Bundle-Name: Workflow Purge
Bundle-Description: Allow automatic & scheduled purge of workflows
Bundle-SymbolicName: com.adobe.daycare.workflow.purge
Bundle-Version: 1.7.1
Bundle-Activator: com.adobe.daycare.workflow.purge.Activator



Apache Sling

Apache Sling is a web framework that uses a Java Content Repository, such as Apache Jackrabbit or Adobe CRX to store and manage content. Sling applications use either scripts or Java servlets to process HTTP requests in a RESTful way. The Sling application is built as a series of OSGi bundles and makes heavy use of a number of OSGi services. Being a REST framework, Sling is oriented around resources, which usually map into JCR nodes.

Traditional web applications select processing script based on the URL, and then attempt to load data to render a result.

In Apache Sling,  request URL is first resolved to a resource, then based on the resource it selects the actual servlet or script to handle the request.

The Resource is one of the central parts of Sling. Sling assumes that “Everything is a Resource”. Sling resources usually map to a JCR node.

Every script, servlet, filter, error handler, etc. is available from the ResourceResolver just like normal content providing data to be rendered upon requests, and they are accessible by a resource path.

Using Sling, the type of content to be rendered is not the first processing consideration. Instead the main consideration is whether the URL resolves to a content object for which a script can then be found to perform the rendering.

In Sling, and therefore also in AEM, processing is driven by the URL of the HTTP
request. This defines the content to be displayed by the appropriate scripts. To do this, information is extracted from the URL. When the appropriate resource (content node) is located, the resource type is extracted from the resource properties. The sling:resourceType property is a path, which locates the script to be used for rendering the content.

Advertisements

Welcome Page: http://server:port/libs/cq/core/content/welcome.html

Site Admin: http://server:port/siteadmin

CRX explorer: http://server:port/crx/explorer/index.jsp

CRX DE Lite:  http://server:port/crx/de

Workflow Management: http://server:port/libs/cq/workflow/content/console.html

System Console: http://server:port/system/console

User Management:  http://server:port/libs/granite/security/content/useradmin.html

Group Management:  http://server:port/libs/granite/security/content/groupadmin.html

JVM Memory usage:  http://server:<port/system/console/memoryusage

JVM Runtime Properties:  http://server:port/system/console/jmx/java.lang:type=Runtime

System Information:  http://server:port/system/console/vmstat

Product Version and License Information:  http://server:port/system/console/productinfo

OSGi Bundle Configuration:  http://server:port/system/console/configMgr

List of Backups: http://server:port/libs/granite/backup/content/admin.html

Package Share:  http://server:port/crx/packageshare

Replication Management:  http://server:port/etc/replication.html

Replication Agents on Author: http://server:port/etc/replication/agents.author.html

Replication Agents on Publish: http://server:port/etc/replication/agents.publish.html

Tagging:   http://server:port/tagging

Sling properties: http://server:port/system/console/status-slingsettings

Version Purge:  http://server:port/etc/versioning/purge.html


Like every product, AEM might also have some bugs/performance issues. These are solved by supplying hot fixes (simply like patches in Oracle WebCenter Sites) to the specific AEM version.

The Hot fixes for AEM 6.1 can be found at the below url

https://helpx.adobe.com/experience-manager/kb/aem61-available-hotfixes.html

How to apply these AEM Hot Fixes?

The hot fixes can be applied either through the package share or manually.

AEM 6.1 introduced the concept of deploying the Hotfixes manually. We will now see how to deploy the downloaded hotfixes manually.

1.   Login to the server

2.   Stop the instance.

3.   Create a new directory called install in <path-to-installation>/crx-quickstart/ directory.

4.   Copy the downloaded hot fixes to the install directory.

5.   Restart the instance.

6.   Go to the package manager and check whether all the hot-fixes are installed properly or not.


Below are the different logs which are generated by AEM. These logs can be found at <path-to-installation>/crx-quickstart/logs folder.

  1. access.log   –      All access requests to AEM WCM and the repository are registered here.
  2. audit.log      –      Moderation actions are registered here.
  3. error.log       –      Error messages (of varying levels of severity) are registered here.
  4. request.log  –      Each access request is registered here together with the response.
  5. stdout.log    –      Holds logging messages indicating events during startup.

In an AEM Instance,  error.log is the file which logs all the error messages. To change this file’s location and name, search for the below bundles in the AEM Web Console, and open them.

  1. Apache Sling Logging Configuration
  2. Apache Sling Logging Logger Configuration

AEM Web Console can be opened at  http:// :/system/console/configMgr

The log file location and name can be changed under the LOG FILE text field.


We have seen in the previous post about how to Export using CSDT Command Line Tool in Oracle WebCenter Sites / Fatwire.

Today we will see how we can Import using CSDT Command Line Tool in Oracle WebCenter Sites / Fatwire utilizing the exported data which is created earlier.

Before seeing how to use the Import using csdt command line tools, we should know what is meant by import first.

Import:

As the name itself is suggesting, it is the process of creating / importing the assets in(to) the content server. Here, assets means any thing inside the Content Server, right from start menus to templates. Everything. So we can import everything using this process.

Ok..How to use it?

Lets come to the point of how to do the import process using CSDT command line tools.

The syntax of csdt command line is as follows, which is common for both export and import.

java com.fatwire.csdt.client.main.CSDT [ContentServer url]  username= username password= password cmd=export|import|listcs|listds [options]

What are the parameters?

1. SERVER_INFO=http://:ContentServer         —- This is the server into which the assets need to be imported.

2. USER_NAME=fwadmin (or any other user name)

3. PASSWORD=xceladmin (or any other user’s password)

4. CLASSPATH= Path to the  csdt-client-11.1.1.8.0.jar and lib folders present inside the csdt-client folder. For example:

If you have placed your csdt-client folder inside the Content server installation directory, then the class path should be:

/csdt-client/csdt-client-11.1.1.8.0.jar:/csdt-client/lib/*
5. IMPORT_FOLDER_LOCATION=<Content server installation directory>/export/envision/cs_workspace/

This is the location where CSDT files needs to be moved before importing
6. DATA_STORE=/src

Say for example if your folder is CSDT_Backup_Files, then the path should be    /CSDT_Backup_Files/src.

Finally to execute the Import process , make sure that your target content server is running, and run the below command.

In the export process earlier, we have given the 13 digit content server id of the CSElement. But now to import, we need to give the UID created by the content server.

java -classpath $CLASSPATH com.fatwire.csdt.client.main.CSDT $SERVER_INFO username=$USER_NAME password=$PASSWORD resources=CSElement:ca572d73-ade3-4535-bc32-e2311b43fbb8 cmd=import

The above command exports the CSElement  which has the id 1326492057112, to the directory said above called CSDT_Backup_files.

How do I import other resources?

Below are the different resources which can be specified in the import script.

– @SITE – Specify the desired sites
– @ROLE – Specify the desired roles
– @ASSET_TYPE – Specify the desired asset types
– @TREETAB – Specify the desired tree tabs
– @STARTMENU – Specify the desired start menu items
– @ELEMENTCATALOG – Specify the desired ElementCatalog entries
– @SITECATALOG – Specify the desired site catalog entries
– @ALL_NONASSETS – Use this short-hand notation to select all non-asset resources
– @ALL_ASSETS – Use this short-hand notation to select all available assets
– asset type – Specify assets of a certain type.

That’s it.. your content is imported to the target machine.


We have seen the introduction of the CSDT Command Line Tools provided by Oracle WebCenter Sites / Fatwire in my last article here.

 EXPORT USING CSDT COMMAND LINE TOOLS:

Before seeing how to use the csdt command line tools, we should know what is meant by export first.

Export: As the name itself is suggesting, it is the process of getting the assets from the content server. Here, assets means any thing inside the Content Server, right from start menus to templates. Everything. So we can export everything using this process.

What is the use of this export?

As said above, what is your main motto? To Export and to import the assets from one server instance to another server instance. So, to move the assets from one instance to the other we need the exported data (assets). That is what we are going to do here.

Ok..How to use it?

Lets come to the point of how to use the export process using CSDT command line tools.

The syntax of csdt command line is as follows.

java com.fatwire.csdt.client.main.CSDT [ContentServer url]  username= username password= password cmd=export|import|listcs|listds [options]

This is generic, and the syntax is same for both export and import, except you need to change a few parameters.

So, what are the parameters?

1. SERVER_INFO=http://:ContentServer    –   This is the server from where the assets need to be exported.

2. USER_NAME=fwadmin (or any other user name)

3. PASSWORD=xceladmin (or any other user’s password)

4. CLASSPATH= Path to the  csdt-client-11.1.1.8.0.jar and lib folders present inside the csdt-client folder. For example:

If you have placed your csdt-client folder inside the Content server installation directory, then the class path should be:

/csdt-client/csdt-client-11.1.1.8.0.jar:/csdt-client/lib/*

5.  CSDT_EXPORT_FOLDER=CSDT_Backup_files

This backup folder will be created under /export/envision/

Finally to execute the export process , make sure that your content server is running, and run the below command.

java -classpath $CLASSPATH com.fatwire.csdt.client.main.CSDT $SERVER_INFO username=$USER_NAME password=$PASSWORD resources=CSElement:1326492057112 cmd=export datastore=$CSDT_EXPORT_FOLDER

The above command exports the CSElement  which has the id 1326492057112, to the directory said above called CSDT_Backup_files.

How do I export other resources?

Below are the different resources which can be specified in the export script.

– @SITE – Specify the desired sites
– @ROLE – Specify the desired roles
– @ASSET_TYPE – Specify the desired asset types
– @TREETAB – Specify the desired tree tabs
– @STARTMENU – Specify the desired start menu items
– @ELEMENTCATALOG – Specify the desired ElementCatalog entries
– @SITECATALOG – Specify the desired site catalog entries
– @ALL_NONASSETS – Use this short-hand notation to select all non-asset resources
– @ALL_ASSETS – Use this short-hand notation to select all available assets
– asset type – Specify assets of a certain type.

In the next post, we will see how to Import the assets using CSDT command line tools.