Stardust executes within a variety of run-time environments. Based on the level of redundancy, availability, throughput and application management, an appropriate deployment option is available for your production environment. Stardust can be deployed in a Web server/servlet container or a fully compliant J2EE application server container. Each option offers strengths and weaknesses over the other options.
Full J2EE implementations of Stardust utilize JMS queues and EJB Session and Message Driven Beans and therefore provide more control, management and scalability of the deployed system. Stardust deployments residing on Web server/servlet containers offer a more light weight, low cost solution, while offering the same functional capabilities as the J2EE deployment. Web server/servlet container deployments do not offer the same level of tuning and performance management as J2EE based deployments but are viable production environments.
The following pages guide you through the setup and deployment of the Stardust Portal and the Process Engine within the supported application servers.
Stardust requires XA-compliant datasources for the JDBC, JCR and JMS connections.
To enable JCR security on an application server deployment which Jackrabbit standalone configuration, the jcr-vfs.jar residing in the WEB-INF/lib folder of your portal WAR file needs to be split into two jar files, one containing factories with spring dependency and one containing the remaining classes.
Extract the following files from jcr-vfs.jar and move them to a new jar named jcr-vfs-factory.jar:
Please make sure these classes are deleted from the original jar and only appear in the new jcr-vfs-factory.jar.
The new jcr-vfs-factory.jar now contains all factories which have a dependency to Spring and can be deployed in the Web application. jcr-vfs.jar now does not have any classes with Spring dependency and can not be added to the Jackrabbit standalone RAR deployment.
Note that in case you are in an EJB deployment the MANIFEST.MF files in your ipp-portal.war and carnot-engine.jar files have to be adapted from jcr-vfs.jar to jcr-vfs-factory.jar.
Create or adapt your repository configuration file repository-with-full-text-search.xml as in the following example:
<!-- Example Repository Configuration File -->
<Repository>
<!-- FileSystem for global information -->
<FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
<param name="path" value="${rep.home}/repository"/>
</FileSystem>
<!-- Security configuration -->
<Security appName="Jackrabbit">
<SecurityManager class="org.apache.jackrabbit.core.JcrVfsSecurityManager" workspaceName="security">
<!-- <WorkspaceAccessManager class="..."/> -->
<!-- <param name="config" value="${rep.home}/security.xml"/> -->
</SecurityManager>
<AccessManager class="org.eclipse.stardust.vfs.impl.jcr.jackrabbit.JcrVfsAccessManager">
<!-- <param name="config" value="${rep.home}/access.xml"/> -->
</AccessManager>
<LoginModule class="org.eclipse.stardust.vfs.impl.jcr.jackrabbit.JcrVfsLoginModule">
<!-- administrator user name -->
<param name="adminId" value="admin"/>
<!-- anonymous user name -->
<param name="anonymousId" value="anonymous"/>
</LoginModule>
</Security>
<!-- Workspace configuration -->
<Workspaces rootPath="${rep.home}/workspaces" defaultWorkspace="default"/>
<!-- Workspace template (is used to create workspaces that do not exist yet)-->
<Workspace name="${wsp.name}">
<!-- FileSystem for workspace -->
<FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
<param name="path" value="${wsp.home}"/>
</FileSystem>
<!-- Persistence manager for workspace:-->
<PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.BundleFsPersistenceManager" />
<!-- Search index for workspace -->
<SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
<param name="path" value="${wsp.home}/index"/>
<param name="extractorPoolSize " value="2"/>
<param name="supportHighlighting" value="true"/>
</SearchIndex>
</Workspace>
<!-- Versioning -->
<Versioning rootPath="${rep.home}/version">
<FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
<param name="path" value="${rep.home}/version" />
</FileSystem>
<PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.BundleFsPersistenceManager" />
</Versioning>
<!-- Search index configuration (for global information) -->
<SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
<param name="path" value="${rep.home}/repository/index"/>
<param name="extractorPoolSize " value="2"/>
<param name="supportHighlighting" value="true"/>
</SearchIndex>
<DataStore class="org.apache.jackrabbit.core.data.FileDataStore" />
</Repository>
Change your JcrSessionFactory configuration to have a JCR user based on the user containing participant information:
In your carnot.properties file set the following:
ContentRepository.User = {JCR_SECURITY}
Use the IppJcrSessionFactory, which creates JCR sessions using the Stardust user Id, in the WEB-INF/config/ipp/spring/jackrabbit-jcr-context.xml file, e.g.:
<beans>
<bean id="jcrPassword" class="java.lang.String">
<constructor-arg index="0" value="jcr-password" />
</bean>
<!-- must be lazy-init="true" as the Jackrabbit startup servlet will be executed after the Spring context listener -->
<bean lazy-init="true" id="carnotJackrabbitRepository" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="jackrabbit.repository" />
</bean>
<bean lazy-init="true"
name="jcrSessionFactory" class="org.eclipse.stardust.engine.api.spring.IppJcrSessionFactory">
<property name="repository" ref="xaJcrConnectionFactory" />
</bean>
<!-- Wrap Jackrabbit repository as JCA resource to hook into JTA TX management. -->
<bean lazy-init="true"
id="xaJcrConnectionFactory" class="org.springframework.jca.support.LocalConnectionFactoryBean">
<property name="managedConnectionFactory">
<bean
class="org.eclipse.stardust.vfs.jcr.jca.JackrabbitRepositoryMCF">
<property name="repository" ref="carnotJackrabbitRepository" />
<property name="bindSessionToTransaction" value="true" />
</bean>
</property>
<property name="connectionManager">
<bean class="org.jencks.factory.ConnectionManagerFactoryBean">
<property name="transactionManager" ref="xaTransactionManager" />
<property name="transaction" value="xa" />
<!-- http://docs.codehaus.org/display/JCA/notcm+Connection+Manager -->
<property name="partitionStrategy" value="by-connector-properties"/>
</bean>
</property>
</bean>
<bean class="org.eclipse.stardust.engine.spring.integration.jca.JcaResourceBinding">
<property name="name" value="jcr/ContentRepository" />
<property name="resource" ref="jcrSessionFactory" />
</bean>
</beans>
The default configuration uses default credentials which allows JCR sessions to be shared between users.
Existing repositories do not automatically get default policies set. This only happens when a virtual folder is created with JCR security enabled. For existing repositories which should be JCR security enabled a few policies need to be set by an administrator, e.g. on the process-instances folder to enable users having no administrator rights to use process-attachments etc.
| Repository path | Default policy on creation with enabled JCR security |
|---|---|
| /realms/<realmId>/users/<userId>/ | everyone=all |
| /process-instances/ | everyone=all |
Note that the default policies might in most cases not be restrictive enough and can be changed to certain Roles or Organizations as desired.