Name: AuditTrail
JNDIName: AuditTrail.DataSource
Database Type: <select database_type from drop down>
Name: AuditTrail
The following sections discuss prerequisites that must be performed before Stardust can be deployed within a WebLogic application server.
A basic understanding of WebLogic Administration, Enterprise Application Archive (EAR), and Web Application Archive (WAR) files is required from this point forward.
Note
We we recommend to enable 2nd-level caching for production deployments to optimize
the performance of a secure JCR deployment. For details refer to section
Tuning by using Hazelcast and to chapter
Optimizing the Performance of secure JCR Deployments accordingly.
Before any activities can be done, download WebLogic from the WebLogic Download Site. Once downloaded, install WebLogic onto the host server. The WebLogic installation directory is referred to as %WEBLOGIC_HOME% from this point forward.
Additional WebLogic system properties can be set in the startup script. Refer to the WebLogic Documentation for more information regarding system properties.
Before you can configure the application server you have to create your server domain. For details on that, refer to the application server manual. Additionally, make sure that you have configured your domain to be able to start the server and you are running in development mode for the hot deployment functionality.
To achieve the carnot.ear file or needed war files provided by Stardust, download one of the Maven archetype templates from the Stardust artifactory matching your requirements. The following deployment configurations for WebLogic are provided as archetypes:
Refer to chapter Creating a Stardust Runtime Environment with Apache Maven in the Stardust Installation Guide for details.
Stardust provides predefined deployment configurations for WebLogic including a prepared ear file. Please refer to the Stardust support for details.
WebLogic provides many third party JDBC libraries. If you plan to use a third-party JDBC driver that is not installed with WebLogic Server, you must update the WebLogic Server's classpath to include the location of the JDBC driver classes. Edit the commEnv.cmd / commEnv.sh script, residing in folder %WEBLOGIC_HOME%/common/bin and prepend your classes as described in "Modifying the Classpath" in WebLogic Server Command Reference.
We recommend to cluster your Web application with the data distribution platform Hazelcast as described in section Tuning by using Hazelcast.
This section contains the following information regarding setting up the transactional resources required by Stardust in the WebLogic server.
This section describes the configuration of resources required to use Stardust with WebLogic. Refer to the Release Notes for details on the currently supported WebLogic versions.
Create a WebLogic domain for Stardust. Please refer to the WebLogic manual for instructions.
In case you need a persistent store for JMS messaging, create a non-xa datasource first and add a JDBC persistent store with the created datasource. Select this persistent store while creating JMS Server.
This links the JMS Module to the JMS Server.
Create the JMS Queue Connection Factory that is used for the Stardust JMS queues that are created later.
The following, provides instructions for creating the JMS queues required by Stardust within a EJB deployment.
For client configuration with WebLogic, build a client lib file called wlfullclient.jar.
Make sure your Java home and JVM home apply to the supported versions. Refer to the Stardust Release Notes for details on the supported platform version for the current release. To create the wlfullclient.jar file for a client Web application do the following:
java -jar wljarbuilder.jar -profile wlfullclient
To avoid session timeouts when using principal login, deactivate the KeepAlive option. In the WebLogic Administration Console perform the following steps:
The following sections provide deployment instructions on using the predefined deployment configurations to deploy the Stardust EAR file and deploying Stardust in a WebLogic application server.
The following sections discuss the deployment of the Stardust EAR file provided via the preconfigured deployment configuration into the WebLogic application server.
To prepare a Jackrabbit deployment on WebLogic, download the jackrabbit-jca-2.6.1.rar file from the following location: https://infinity.sungard.com/repository/ipp-3rd-party/org/apache/jackrabbit/jackrabbit-jca/2.6.1-infinity01/jackrabbit-jca-2.6.1-infinity01.rar.
Please refer to the following sections for instructions on how to setup WebLogic for a standalone Jackrabbit deployment.
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-connector xmlns="http://www.bea.com/ns/weblogic/90">
<jndi-name>jcr/infinityRA</jndi-name>
<enable-access-outside-app>true</enable-access-outside-app>
<enable-global-access-to-classes>true
</enable-global-access-to-classes>
<outbound-resource-adapter>
<connection-definition-group>
<connection-factory-interface>javax.jcr.Repository
</connection-factory-interface>
<connection-instance>
<jndi-name>jcr/jackrabbit</jndi-name>
<connection-properties>
<pool-params>
<initial-capacity>10</initial-capacity>
<max-capacity>50</max-capacity>
<capacity-increment>1</capacity-increment>
<shrinking-enabled>true</shrinking-enabled>
<shrink-frequency-seconds>6</shrink-frequency-seconds>
</pool-params>
<properties>
<property>
<name>ConfigFile</name>
<value>classpath:repository.xml</value>
</property>
<property>
<name>HomeDir</name>
<value>D:/servers/applicationServers/weblogic-10.3.3/user_projects/domains/carnot_ejb/jackrabbit</value>
</property>
</properties>
</connection-properties>
</connection-instance>
</connection-definition-group>
</outbound-resource-adapter>
</weblogic-connector>
<?xml version="1.0"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<!DOCTYPE Repository PUBLIC "-//The Apache Software Foundation//DTD Jackrabbit 1.2//EN"
"http://jackrabbit.apache.org/dtd/repository-1.2.dtd">
<!-- Example Repository Configuration File -->
<Repository>
<!--
virtual file system where the repository stores global state
(e.g. registered namespaces, custom node types, etc.)
-->
<FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
<param name="path" value="${rep.home}/repository"/>
</FileSystem>
<!--
security configuration
-->
<Security appName="Jackrabbit">
<!--
access manager:
class: FQN of class implementing the AccessManager interface
-->
<AccessManager class="org.apache.jackrabbit.core.security.SimpleAccessManager">
<!-- <param name="config" value="${rep.home}/access.xml"/> -->
</AccessManager>
<LoginModule class="org.apache.jackrabbit.core.security.SimpleLoginModule">
<!-- anonymous user name ('anonymous' is the default value) -->
<param name="anonymousId" value="anonymous"/>
<!--
default user name to be used instead of the anonymous user
when no login credentials are provided (unset by default)
-->
<!-- <param name="defaultUserId" value="superuser"/> -->
</LoginModule>
</Security>
<!--
location of workspaces root directory and name of default workspace
-->
<Workspaces rootPath="${rep.home}/workspaces" defaultWorkspace="default"/>
<!--
workspace configuration template:
used to create the initial workspace if there's no workspace yet
-->
<Workspace name="${wsp.name}">
<!--
virtual file system of the workspace:
class: FQN of class implementing the FileSystem interface
-->
<FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
<param name="path" value="${wsp.home}"/>
</FileSystem>
<!--
persistence manager of the workspace:
class: FQN of class implementing the PersistenceManager interface
-->
<PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.DerbyPersistenceManager">
<param name="url" value="jdbc:derby:${wsp.home}/db;create=true"/>
<param name="schemaObjectPrefix" value="${wsp.name}_"/>
</PersistenceManager>
<!--
Search index and the file system it uses.
class: FQN of class implementing the QueryHandler interface
-->
<SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
<param name="path" value="${wsp.home}/index"/>
</SearchIndex>
</Workspace>
<!--
Configures the versioning
-->
<Versioning rootPath="${rep.home}/version">
<!--
Configures the filesystem to use for versioning for the respective
persistence manager
-->
<FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
<param name="path" value="${rep.home}/version" />
</FileSystem>
<!--
Configures the persistence manager to be used for persisting version state.
Please note that the current versioning implementation is based on
a 'normal' persistence manager, but this could change in future
implementations.
-->
<PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.DerbyPersistenceManager">
<param name="url" value="jdbc:derby:${rep.home}/version/db;create=true"/>
<param name="schemaObjectPrefix" value="version_"/>
</PersistenceManager>
</Versioning>
<!--
Search index for content that is shared repository wide
(/jcr:system tree, contains mainly versions)
-->
<SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
<param name="path" value="${rep.home}/repository/index"/>
</SearchIndex>
</Repository>
You need to verify the JCR connection factory settings.
To configure the Stardust Workflow Execution Perspective in spring mode:
<resource-env-ref>
<description>Content Repository</description>
<resource-env-ref-name>jcr/jackrabbit</resource-env-ref-name>
<resource-env-ref-type>javax.jcr.Repository</resource-env-ref-type>
</resource-env-ref>
<resource-env-description>
<res-env-ref-name>jcr/jackrabbit</res-env-ref-name>
<jndi-name>jackrabbit</jndi-name>
</resource-env-description>
Please refer to the example
weblogic.xml file.To set up additional Jackrabbit VFS repositories in WebLogic, you need to configure a new connection factory on the server using a different repository home and JNDI name.
This resource can then be bound using the DocumentManagementService#bindRepository API. Please refer to chapter Managing Document Repositories of the Programming Guide for details.
If you like to connect to the engine in an EJB tunneling environment with WebLogic, use the TunnelingSessionFactory provided by Stardust to avoid connection issues. To use this session factory, set the following property in your client-side carnot.properties file:
Secure.Session.Factory = org.eclipse.stardust.engine.api.ejb2.TunnelingSessionFactory
You can use Hazelcast for tuning via retrieving entities from in-memory cache. Hazelcast is a clustering and scalable data distribution platform. For detailed information on Hazelcast refer to http://www.hazelcast.com/product.jsp.
For details on tuning via an in-memory cache in Stardust refer to chapter Retrieving Entities from In-Memory Cache in the Developer Handbook.
The following examples demonstrates the usage of Hazelcast on WebLogic 10.3. Stardust provides a prepared RAR file to be deployed with WebLogic.
To set up Hazelcast on WebLogic for a separate RAR deployment perform the following steps:
Infinity.Engine.Caching = true
Infinity.Engine.Caching.CacheFactory = org.eclipse.stardust.engine.core.cache.hazelcast.HazelcastCacheFactory
Infinity.Engine.Caching.Hazelcast.TxMode = rw
Infinity.Engine.Caching.Hazelcast.ConnectionFactoryJndiName = HazelcastCF
Infinity.Engine.Caching.Hazelcast.GlobalCacheName = ipp-2nd-level-cache
The engine now uses Hazelcast as second level cache provider. This can be monitored as cache size and Hit Rate will change after logging into the Stardust portal, for example.
The cache is configured to remove cached entries after at most 60 seconds for the time
being. This is why Stardust will eventually hit the database again to
repopulate the cache. The time to
live can be adjusted in the hazelcast.xml configuration file
(
Please note that with this setup there will be only one node. Hazelcast either detects or is explicitly told about additional node members. For details on this issue please refer to the Hazelcast documentation or the hazelcast.xml file.
To deploy the Hazelcast resource adapter inside your EAR, perform the following steps:
[...]
<application [...]>
[...]
<module>
<connector>hazelcast-ra-2.4-stardust01.jar</connector>
</module>
[...]
</application>