From do-not-reply at jboss.org Tue Sep 27 00:42:43 2011
Content-Type: multipart/mixed; boundary="===============2780821938182020368=="
MIME-Version: 1.0
From: do-not-reply at jboss.org
To: gatein-commits at lists.jboss.org
Subject: [gatein-commits] gatein SVN: r7510 - in
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR:
jcr-with-gtn and 1 other directory.
Date: Tue, 27 Sep 2011 00:42:42 -0400
Message-ID: <201109270442.p8R4ggxR030069@svn01.web.mwc.hst.phx2.redhat.com>
--===============2780821938182020368==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Author: smumford
Date: 2011-09-27 00:42:42 -0400 (Tue, 27 Sep 2011)
New Revision: 7510
Removed:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced=
/eXoJCR/jcr-with-gtn/how-to-extend-my-gatein-instance.xml
Modified:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced=
/eXoJCR/jcr-with-gatein.xml
Log:
Removed How to extend GateIn section
Modified: epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/A=
dvanced/eXoJCR/jcr-with-gatein.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advance=
d/eXoJCR/jcr-with-gatein.xml 2011-09-27 04:40:31 UTC (rev 7509)
+++ epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advance=
d/eXoJCR/jcr-with-gatein.xml 2011-09-27 04:42:42 UTC (rev 7510)
@@ -4,9 +4,9 @@
%BOOK_ENTITIES;
]>
- eXo JCR with GateIn
-
-
+ eXo JCR with GateIn
+
+
=
=
Deleted: epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Ad=
vanced/eXoJCR/jcr-with-gtn/how-to-extend-my-gatein-instance.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advance=
d/eXoJCR/jcr-with-gtn/how-to-extend-my-gatein-instance.xml 2011-09-27 04:40=
:31 UTC (rev 7509)
+++ epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advance=
d/eXoJCR/jcr-with-gtn/how-to-extend-my-gatein-instance.xml 2011-09-27 04:42=
:42 UTC (rev 7510)
@@ -1,2242 +0,0 @@
-
-
-%BOOK_ENTITIES;
-]>
-
- How to extend my GateIn instance?
-
- Introduction
-
- Overview
-
- Since GateIn beta 2, we added a set of features in order t=
o customize a GateIn instance without modifying the GateIn binary, this use=
case will be called portal extension in this documenta=
tion. Those features are also required to be able to launch several portal =
instances at the same time, in "eXo terminology" that means to have several=
"portal.war".
-
-
-
- =
-
- Motivations
-
- Up to now, to create an application over an eXo portal suc=
h as DMS, WCM, CS and KS, we need to modify files into the "portal.war". Th=
is has many painful consequences, such as:
-
-
-
-
- It is quite hard to manage from the support point =
of view since we never know if or how the customer changed his eXo product.
-
-
-
-
-
- It is hard to be able to package several eXo produ=
cts (WCM, CS...) as we need to merge everything manually which is quite err=
or prone.
-
-
-
-
-
-
- Finally, at the very beginning, eXo was developed to be ab=
le to support several portal instances (which also means several portal con=
tainers) but with the time several bad practices made it impossible. So it =
was important to review the whole code base in order to help/enforce all th=
e GateIn developers to follow the "good practices".
-
-
-
- =
-
-
- =
-
- Prerequisites
-
- To be able to migrate an application to GateIn, the first thin=
g we need to do is to ensure that our application supports properly several=
portal container instances. The following section aims to help you to be c=
ompatible with GateIn.
-
-
- Removing all the hard coded portal container name (i.e.=
"portal")
-
- Now if we need to get the portal container name we can:
-
-
-
-
- If the component is instantiated by Pico container=
, you can add in the constructor of your component, the component ExoContainerContext, then call the method getPortalCo=
ntainerName()
-
-
-
-
-
- If the component is not instantiated by Pico conta=
iner, you can call at runtime the static method PortalContainer.g=
etCurrentPortalContainerName()
-
-
-
-
-
- In js files, you can use the variable cu=
rrentContext if your script must be loaded before the variable <=
emphasis>eXo.env.server.context, otherwise use eXo.env=
.server.context instead.
-
-
-
-
-
- In jsp files, you can use request.getCon=
textPath().
-
-
-
-
-
-
-
- =
-
- Removing all the hard coded rest context name (i.e. "re=
st")
-
- Now if we need to get the rest context name we can:
-
-
-
-
- If the component is instantiated by Pico container=
, you can add in the constructor of your component, the component ExoContainerContext, then call the method getRestCont=
extName()
-
-
-
-
-
- If the component is not instantiated by Pico conta=
iner, you can call at runtime the static method PortalContainer.g=
etCurrentRestContextName()
-
-
-
-
-
-
-
- =
-
- Removing all the hard coded realm name (i.e. "exo-domai=
n")
-
- Now if we need to get the realm name we can:
-
-
-
-
- If the component is instantiated by Pico container=
, you can add in the constructor of your component, the component ExoContainerContext, then call the method getRealmNam=
e()
-
-
-
-
-
- If the component is not instantiated by Pico conta=
iner, you can call at runtime the static method PortalContainer.g=
etCurrentRealmName()
-
-
-
-
-
-
-
- =
-
- Making your Http Filters compatible
-
- Now all your Http Filters that need to get the current ExoContainer must extends org.exoplatform.conta=
iner.web.AbstractFilter. You just need to call the method getContainer() to get the current ExoContainer.
-
-
-
- =
-
- Making your HttpServlets compatible
-
- Now all your HttpServlets that need to get the current ExoContainer must extends org.exoplatform.conta=
iner.web.AbstractHttpServlet. This abstract class will ensure th=
at the environment has been properly set, so you will be able to call the u=
sual methods such as PortalContainer.getInstance().
-
-
- If you had to implement the method service(HttpS=
ervletRequest req, HttpServletResponse res), now you will need t=
o implement onService(ExoContainer container, HttpServletRequest =
req, HttpServletResponse res), this method will directly give yo=
u the current ExoContainer in its signature.
-
-
- Useful Information
-
- In the class org.exoplatform.container.web.A=
bstractHttpServlet you have a method called requirePor=
talEnvironment() that is used to indicate that we would like the=
abstract class to setup or not the full portal environment ( Por=
talContainer, ClassLoader and Ser=
vletContext) before executing the servlet. This value should ret=
urn true when the servlet is executed within the web application of a porta=
l container. By default, it checks if the name of the current Ser=
vletContext is a portal container name, it is sufficient in most=
of cases but you can still overload this method if you already know that t=
he servlet will always been executed within the web application of portal c=
ontainer (i.e. the method always return true) or will never be executed wit=
hin the web application of a portal container (i.e. the method always retur=
n false) .
-
-
-
-
-
- =
-
- Making your HttpSessionListeners compatible
-
- Now all your HttpSessionListeners that need to get the cur=
rent ExoContainer must extends org.exoplatfo=
rm.container.web.AbstractHttpSessionListener. This abstract clas=
s will give you the current ExoContainer directly in t=
he signature of the methods to implement which are _ onSessionCreated(ExoCo=
ntainer container, HttpSessionEvent event)\_ and onSessionDestroy=
ed(ExoContainer container, HttpSessionEvent event)
-
-
- You will also need to implement the method called requirePortalEnvironment() that is used to indicate that we wo=
uld like the abstract class to setup or not the full portal environment ( <=
emphasis>PortalContainer and ClassLoader) b=
efore processing the event. This value should return true when the event is=
processed within the web application of a portal container.
-
-
-
- =
-
- Use init tasks if you need a PortalContainer to initial=
ize an Http Filter or an HttpServlet
-
- If your Http Filter or your HttpServlet requires a PortalContainer to initialize, you need =
to convert your code in order to launch the code responsible for the initia=
lization in the method onAlreadyExists of an org.exoplatform.container.RootContainer.PortalContainerInitTask.
-
-
- We need to rely on init tasks, in order to be sure that th=
e portal container is at the right state when the task is executed, in othe=
r words the task could be delayed if you try to execute it too early. Each =
task is linked to a web application, so when we add a new task, we first re=
trieve all the portal containers that depend on this web application accord=
ing to the PortalContainerDefinitions, and for each co=
ntainer we add the task in a sorted queue which order is in fact the order =
of the web applications dependencies defined in the PortalContain=
erDefinition. If no PortalContainerDefinition can be found we execute synchronously the task which is in fact the old =
behavior (i.e. without the starter).
-
-
- The supported init tasks are:
-
-
-
-
- The org.exoplatform.container.RootContai=
ner.PortalContainerPreInitTask which are executed before the por=
tal container has been initialized
-
-
-
-
-
- The org.exoplatform.container.RootContai=
ner.PortalContainerPostInitTask which are executed after the por=
tal container has been initialized
-
-
-
-
-
- The org.exoplatform.container.RootContai=
ner.PortalContainerPostCreateTask which are executed after the p=
ortal container has been fully created (i.e. after all the post init tasks).
-
-
-
-
-
-
- An init task is defined as below:
-
-
- PortalContainerPreInitTask
- =
- /**
- * This interface is used to define a task that needs to be launched at=
a given state during the
- * initialization of a portal container
- */
- public static interface PortalContainerInitTask
- {
-
- /**
- * This method allows the implementation to define what the state "a=
lready exists"
- * means for a portal container
- *
- * @param portalContainer the value of the current portal container
- * @return <code>true</code> if the portal container exi=
sts according to the task
- * requirements, <code>false</code> otherwise
- */
- public boolean alreadyExists(PortalContainer portalContainer);
-
- /**
- * This method is called if the related portal container has already=
been registered
- *
- * @param context the servlet context of the web application
- * @param portalContainer the value of the current portal container
- */
- public void onAlreadyExists(ServletContext context, PortalContainer =
portalContainer);
-
- /**
- * Executes the task
- *
- * @param context the servlet context of the web application
- * @param container The portal container on which we would like to e=
xecute the task
- */
- public void execute(ServletContext context, PortalContainer portalCo=
ntainer);
-
- /**
- * @return the type of the task
- */
- public String getType();
- }
-
-
-
- To add a task, you can either call:
-
-
-
-
- PortalContainer.addInitTask(ServletConte=
xt context, PortalContainerInitTask task) in order to execute th=
e task on all the portal containers that depend on the given Serv=
letContext according to the PortalContainerDefinitions=
.
-
-
-
-
-
- PortalContainer.addInitTask(ServletConte=
xt context, PortalContainerInitTask task, String portalContainerName) in order to execute the task on a given portal container.
-
-
-
-
-
- RootContainer.addInitTask(ServletContext=
context, PortalContainerInitTask task) in order to execute the =
task on the portal container which name is the name of the given =
ServletContext.
-
-
-
-
-
-
- We will take for example the class GadgetRegiste=
r that is used to register new google gadgets on a given portal =
container.
-
-
- The old code was:
-
-
- Old GadgetRegister.java
- =
-...
-public class GadgetRegister implements ServletContextListener
-{
-...
- public void contextInitialized(ServletContextEvent event)
- {
- try
- {
- ExoContainer pcontainer =3D ExoContainerContext.getContainerByName(=
"portal") ;
- SourceStorage sourceStorage =3D (SourceStorage)pcontainer.getCompone=
ntInstanceOfType(SourceStorage.class);
- ...
- }
- ...
-}
-
-
-
- The new code relies on a org.exoplatform.contain=
er.RootContainer.PortalContainerPostInitTask, as you can see bel=
ow
-
-
- New GadgetRegister.java
- =
-...
-public class GadgetRegister implements ServletContextListener {
-...
- public void contextInitialized(ServletContextEvent event)
- {
- // Create a new post init task
- final PortalContainerPostInitTask task =3D new PortalContainerPostIn=
itTask()
- {
-
- public void execute(ServletContext context, PortalContainer porta=
lContainer)
- {
- contextInitialized(context, portalContainer);
- }
- };
- // Add the init task to all the related portal containers
- PortalContainer.addInitTask(event.getServletContext(), task);
- }
-
- private void contextInitialized(ServletContext context, PortalContainer=
pcontainer)
- {
- try
- {
- SourceStorage sourceStorage =3D (SourceStorage)pcontainer.getComp=
onentInstanceOfType(SourceStorage.class);
- ...
- }
- ...
-}
-
-
-
-
- =
-
- Making your LoginModules compatible
-
- Now all your LoginModules that need to get the current ExoContainer must extends org.exoplatform.servi=
ces.security.jaas.AbstractLoginModule. You just need to call the=
method getContainer() to get the current Ex=
oContainer.
-
-
- Useful Information
-
- The class org.exoplatform.services.security.=
jaas.AbstractLoginModule supports 2 login module options which a=
re portalContainerName and realmName, to allow you to indicate the realm name and the portal container name,=
if you want to change the default value.
-
-
-
-
-
- =
-
- Avoiding <emphasis>static</emphasis> modifier on compon=
ent dependency
-
- A local variable that stores a component dependency must n=
ot be static. In other words, when you create a component A that depends on=
component B, we don't store B in a static variable of A otherwise we canno=
t have several different instances of A in the same JVM which is not compat=
ible with a multi-portal instance.
-
-
-
- =
-
- Avoid component initialization based on component depen=
dency in the constructor
-
- We will have more and more extensible components (i.e. tha=
t can be extended thanks to an external plugin) which means that those comp=
onents can only be initialized in the start method, th=
us it is not a good practice to initialize a component in its constructor i=
f this initialization uses other components because those components may no=
t be initialized. For example, now the ResourceBundleService is extensible,=
so if you create a component that depends on the ResourceBundleService and=
you need the ResourceBundleService to initialize your component, your comp=
onent will need to be "Startable" and you will have to initialize your comp=
onent in a start method.
-
-
-
- =
-
-
- =
-
- FAQ
-
- What has changed since the previous versions?
-
- The main difference with previous versions is the way to p=
ackage your application, in the previous versions you had to change the con=
tent of the file portal.war in order to customize the =
portal. Now we more consider your application as an add-on that you can pac=
kaged in another ear/war file. You just need to follow some rules in order =
to notify the platform that it must take into account your add-on in order =
to customize the portal.
-
-
- Among other things, you will have to:
-
-
-
-
- Indicate the platform how to initialize and manage=
your application by defining and registering the PortalContainer=
Definition related to your portal instance.
-
-
-
-
-
- Deploy the starter ear/war fi=
le that is used to create and start all the portals (i.e. portal containers=
).
-
-
-
-
-
-
- Warning
-
- Please take into account, that you need to ensure that=
the starter is launched after all the other ear/war f=
iles.
-
-
-
-
- Nota Bene
-
- If you don't need to customize the portal, you don't h=
ave to deploy the starter. The old way to deploy an application is still co=
mpatible.
-
-
-
-
-
- =
-
- What is the main purpose of a <emphasis>portal extensio=
n</emphasis>?
-
- An extension is just a set of files t=
hat we use to customize or add new features to a given portal. An extension=
must be the least intrusive as possible, as we could potentially have seve=
ral extensions for the same portal. In other words, we are supposed to only=
add what is missing in the portal and avoid changing or duplicated files t=
hat are in the portal.war.
-
-
-
- =
-
- What is the main purpose of the <emphasis>starter</emph=
asis>?
-
- The sarter is a web application that =
has been added to create and start all the portals (i.e. portal containers)=
at the same time when all the other web applications have already been sta=
rted. In fact all other web applications can potentially defined several th=
ings at startup such as skins, javascripts, google gadgets and configuratio=
n files, thus the loading order is important as we can redefine skins or co=
nfiguration files or a javascript from a web application 1 could depend on =
another javascript from a web application 2 so if the web application 2 is =
loaded after the web application 1, we will get errors in the merged javasc=
ript file.
-
-
- If a PortalContainerDefinition has be=
en defined, the loading order will be the order that has been used to defin=
e the list of dependency. And if you defined a PortalContainerDef=
inition you need to deploy the starter otherwise the loading ord=
er will be the default one (i.e. the loading order of the Application Serve=
r)
-
-
- So if you need to customize your portal by adding a new ex=
tension and/or a new portal, you need to defined the related Port=
alContainerDefinitions so you need to deploy also the starter. O=
therwise, you don't need to define any PortalContainerDefinition<=
/emphasis> and to deploy the starter.
-
-
-
- =
-
- How a portal and a portal container are related?
-
- Each portal instance has its own portal container which al=
lows the portal to have its own set of components/services. It will ensure =
the isolation between the different portal instances.
-
-
-
- =
-
- How to define and register a <emphasis>PortalContainerD=
efinition</emphasis>?
-
- A PortalContainerDefinition allows yo=
u to indicate the platform how it must initialize and manage your portal. I=
n a PortalContainerDefinition, you can define a set of=
properties, such as:
-
-
-
-
- The name of the portal container
-
-
-
-
-
- The name of the context name of the rest web appli=
cation
-
-
-
-
-
- The name of the realm
-
-
-
-
-
- The list of all the dependencies of the portal con=
tainer ordered by priority
-
-
-
-
-
-
- You can define and register a PortalContainerDef=
inition thanks to an external plugin that has to be treated at t=
he RootContainer level. In other words, your configura=
tion file must be a file conf/configuration.xml packag=
ed into a jar file or $AS_HOME/exo-conf/configuration.xml (for more details=
, please have a look to the article ).
-
-
- See below an example of confi=
guration file that define and register a PortalContainerDefinition:
-
- =
-<?xml version=3D"1.0" enc=
oding=3D"UTF-8"?>
-<configuration
- xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd ht=
tp://www.exoplaform.org/xml/ns/kernel_1_0.xsd"
- xmlns=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd">
- <external-component-plugins>
- <!-- The full qualified name of the PortalContainerConfig -->
- <target-component>org.exoplatform.container.definition.PortalCon=
tainerConfig</target-component>
- <component-plugin>
- <!-- The name of the plugin -->
- <name>Add PortalContainer Definitions</name>
- <!-- The name of the method to call on the PortalContainerConfig =
in order to register the PortalContainerDefinitions -->
- <set-method>registerPlugin</set-method>
- <!-- The full qualified name of the PortalContainerDefinitionPlug=
in -->
- <type>org.exoplatform.container.definition.PortalContainerDefi=
nitionPlugin</type>
- <init-params>
- <object-param>
- <name>portal</name>
- <object type=3D"org.exoplatform.container.definition.PortalCo=
ntainerDefinition">
- <!-- The name of the portal container -->
- <field name=3D"name"><string>portal</string>=
</field>
- <!-- The name of the context name of the rest web applicati=
on -->
- <field name=3D"restContextName"><string>rest</s=
tring></field>
- <!-- The name of the realm -->
- <field name=3D"realmName"><string>exo-domain</s=
tring></field>
- <!-- All the dependencies of the portal container ordered b=
y loading priority -->
- <field name=3D"dependencies">
- <collection type=3D"java.util.ArrayList">
- <value>
- <string>eXoResources</string>
- </value>
- <value>
- <string>portal</string>
- </value>
- <value>
- <string>dashboard</string>
- </value>
- <value>
- <string>exoadmin</string>
- </value>
- <value>
- <string>eXoGadgets</string>
- </value>
- <value>
- <string>eXoGadgetServer</string>
- </value>
- <value>
- <string>rest</string>
- </value>
- <value>
- <string>web</string>
- </value>
- <value>
- <string>wsrp-producer</string>
- </value>
- <value>
- <string>sample-ext</string>
- </value>
- </collection>
- </field>
- </object>
- </object-param>
- </init-params>
- </component-plugin>
- </external-component-plugins>
-</configuration>
-
- In the previous example, we define a portal container call=
ed "portal", which rest context name is "rest", which realm name is "exo-do=
main" and which dependencies are the web applications "eXoResources", "port=
al"... The platform will load first "eXoResources", then "portal" and so on.
-
-
-
- =
-
- =
-
- How to change the ServletContext name, the realm name a=
nd/or the rest context name of my portal without using a PortalContainerDef=
inition?
-
- To do that you need first to change the default values use=
d by a PortalContainer that has not been defined thanks to a Port=
alContainerDefinition. Those default values can be modified than=
ks to a set of init parameters of the component PortalContainerCo=
nfig.
-
-
- The component PortalContainerConfig m=
ust be registered at the RootContainer level. In other=
words, your configuration file must be a file conf/configuration=
.xml packaged into a jar file or $AS_HOME/exo-conf/configuration=
.xml (for more details please have a look to the article ).
-
-
- In the example below we will =
rename:
-
-
-
-
- The portal name "portal" to "myPortal".
-
-
-
-
-
- The rest servlet context name "rest" to "myRest".
-
-
-
-
-
- The realm name "exo-domain" to "my-exo-domain".
-
-
-
-
-
-
- See below an example
-
- =
-<?xml version=3D"1.0" enc=
oding=3D"UTF-8"?>
-<configuration
- xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd ht=
tp://www.exoplaform.org/xml/ns/kernel_1_0.xsd"
- xmlns=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd">
- <component>
- <!-- The full qualified name of the PortalContainerConfig -->
- <type>org.exoplatform.container.definition.PortalContainerConfig=
</type>
- <init-params>
- <!-- The name of the default portal container -->
- <value-param>
- <name>default.portal.container</name>
- <value>myPortal</value>
- </value-param>
- <!-- The name of the default rest ServletContext -->
- <value-param>
- <name>default.rest.context</name>
- <value>myRest</value>
- </value-param>
- <!-- The name of the default realm -->
- <value-param>
- <name>default.realm.name</name>
- <value>my-exo-domain</value>
- </value-param>
- </init-params>
- </component>
-</configuration>
-
- Once your configuration is ready, you need to:
-
-
-
-
- Update the file WEB-INF/web.xml of the file "portal.war" by changing the "display-name" (the new value i=
s "myPortal") and the "realm-name" in the "login-config" (the new value is =
"my-exo-domain").
-
-
-
-
-
- If you use JBoss AS: Update the file WEB=
-INF/jboss-web.xml of the file "portal.war" by changing the "sec=
urity-domain" (the new value is "java:/jaas/my-exo-domain").
-
-
-
-
-
- Rename the "portal.war" to "myPortal.war" (or "02p=
ortal.war" to "02myPortal.war")
-
-
-
-
-
- Update the file WEB-INF/web.xml of the file "rest.war" by changing the "display-name" (the new value is =
"myRest") and the "realm-name" in the "login-config" (the new value is "my-=
exo-domain").
-
-
-
-
-
- If you use JBoss AS: Update the file WEB=
-INF/jboss-web.xml of the file "rest.war" by changing the "secur=
ity-domain" (the new value is "java:/jaas/my-exo-domain").
-
-
-
-
-
- Rename the "rest.war" to "myRest.war"
-
-
-
-
-
- If "portal.war" and "rest.war" were embedded into =
an ear file: Update the file META-INF/application.xml =
of the file "exoplatform.ear" by remaming "02portal.war" to "02myPortal.war=
", "portal" to "myPortal", "rest.war" to "myRest.war" and "rest" to "myRest=
".
-
-
-
-
-
-
- The end of the process depends on your application server
-
-
- On JBoss (tested on JBoss 5.1.0.GA)
-
- You need to change the name of the application policy =
in your file conf/login-config.xml (the new name is "m=
y-exo-domain").
-
-
-
- =
-
- On Tomcat (tested on Tomcat 6.0.20)
-
- You need to:
-
-
-
-
- Update the file tomcat/conf/Catalina=
/localhost/portal.xml by changing the "path" (the new value is "=
/myPortal"), the "docBase" (the new value is "myPortal") and the "appName" =
in the "Realm" definition (the new value is "my-exo-domain").
-
-
-
-
-
- Rename the file tomcat/conf/Catalina=
/localhost/portal.xml to myPortal.xml.
-
-
-
-
-
- Update the file tomcat/conf/Catalina=
/localhost/rest.xml by changing the "path" (the new value is "/m=
yRest"), the "docBase" (the new value is "myRest") and the "appName" in the=
"Realm" definition (the new value is "my-exo-domain").
-
-
-
-
-
- Rename the file tomcat/conf/Catalina=
/localhost/rest.xml to myRest.xml.
-
-
-
-
-
- Change the realm name in the file to=
mcat/conf/jaas.conf (the new name is "my-exo-domain").
-
-
-
-
-
-
-
- =
-
-
- =
-
- How to add new configuration file to a given portal fro=
m a war file?
-
- To indicate the platform that a given web application has =
configuration file to provide, you need to:
-
-
-
-
- Add the ServletContextListener org.exopl=
atform.container.web.PortalContainerConfigOwner in its web.xml.
-
-
-
-
-
- Add the servlet context name of this web applicati=
on as a new dependency in the PortalContainerDefinition of all the portal containers for which you want to share the configuratio=
n file embedded into the war file, located at WEB-INF/conf/config=
uration.xml.
-
-
-
-
-
-
- The simple fact to add this Servlet Context Listener, will=
add the Servlet Context of this web application to the Unified Servlet Con=
text of all the PortalContainers that depend on this w=
eb application according to their PortalContainerDefinition.
-
-
- Useful Information #1
-
- The position of the servlet context name of this web a=
pplication in the dependency list is important since the last configuration=
file loaded has always right towards other configuration files. Each confi=
guration file loaded, could potentially redefine a configuration file that =
has already been loaded. Moreover, as we now use a unified Servlet Context =
to load the configuration files, if you want for instance to import the fil=
e war:/conf/database/database-configuration.xml and th=
is file exists in 2 different web applications, the file from the last (acc=
ording to the dependency order) web application will be loaded.
-
-
-
-
- Useful Information #2
-
- A portal is implicitly considered as a Porta=
lContainerConfigOwner without having to define the ServletContex=
tListener org.exoplatform.container.web.PortalContainerConfigOwne=
r in its web.xml.
-
-
-
-
- See an example of a web.xml below:
-
- =
-<?xml version=3D"1.0" enc=
oding=3D"ISO-8859-1" ?>
-<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Applicatio=
n 2.3//EN"
- "http://java.sun.com/dtd/web-app_2_3.dtd">
-<web-app>
- <display-name>sample-ext</display-name>
-
- <context-param>
- <param-name>org.exoplatform.frameworks.jcr.command.web.fckeditor=
.digitalAssetsWorkspace</param-name>
- <param-value>collaboration</param-value>
- <description>Binary assets workspace name</description>
- </context-param>
-
- <context-param>
- <param-name>org.exoplatform.frameworks.jcr.command.web.fckeditor=
.digitalAssetsPath</param-name>
- <param-value>/Digital Assets/</param-value>
- <description>Binary assets path</description>
- </context-param>
-
- <context-param>
- <param-name>CurrentFolder</param-name>
- <param-value>/Digital Assets/</param-value>
- <description>Binary assets workspace name</description>
- </context-param>
-
- <!-- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -->
- <!-- RESOURCE FILTER TO CACHE MERGED JAVASCRIPT AND CSS =
-->
- <!-- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -->
- <filter>
- <filter-name>ResourceRequestFilter</filter-name>
- <filter-class>org.exoplatform.portal.application.ResourceRequest=
Filter</filter-class>
- </filter>
-
- <filter-mapping>
- <filter-name>ResourceRequestFilter</filter-name>
- <url-pattern>/*</url-pattern>
- </filter-mapping>
-
-
- <!-- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -->
- <!-- LISTENER =
-->
- <!-- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -->
- <listener>
- <listener-class>org.exoplatform.container.web.PortalContainerCon=
figOwner</listener-class>
- </listener>
- <!-- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -->
- <!-- SERVLET =
-->
- <!-- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -->
- <servlet>
- <servlet-name>GateInServlet</servlet-name>
- <servlet-class>org.gatein.wci.api.GateInServlet</servlet-clas=
s>
- <load-on-startup>0</load-on-startup>
- </servlet>
- <!-- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -->
- <servlet-mapping>
- <servlet-name>GateInServlet</servlet-name>
- <url-pattern>/gateinservlet</url-pattern>
- </servlet-mapping>
-</web-app>
-
-
- =
-
- How to create/define a portal extension?
-
- A portal extension is in fact a web application declared a=
s a PortalContainerConfigOwner (see previous section f=
or more details about a PortalContainerConfigOwner) th=
at has been added to the dependency list of the PortalContainerDe=
finition of a given portal.
-
-
- See below an example of confi=
guration file that add the portal extension "portal-ext" to the dependency =
list of the portal "portal":
-
- =
-<?xml version=3D"1.0" enc=
oding=3D"UTF-8"?>
-<configuration
- xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd ht=
tp://www.exoplaform.org/xml/ns/kernel_1_0.xsd"
- xmlns=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd">
- <external-component-plugins>
- <!-- The full qualified name of the PortalContainerConfig -->
- <target-component>org.exoplatform.container.definition.PortalCon=
tainerConfig</target-component>
- <component-plugin>
- <!-- The name of the plugin -->
- <name>Add PortalContainer Definitions</name>
- <!-- The name of the method to call on the PortalContainerConfig =
in order to register the PortalContainerDefinitions -->
- <set-method>registerPlugin</set-method>
- <!-- The full qualified name of the PortalContainerDefinitionPlug=
in -->
- <type>org.exoplatform.container.definition.PortalContainerDefi=
nitionPlugin</type>
- <init-params>
- <object-param>
- <name>portal</name>
- <object type=3D"org.exoplatform.container.definition.PortalCo=
ntainerDefinition">
- <!-- The name of the portal container -->
- <field name=3D"name"><string>portal</string>=
</field>
- <!-- The name of the context name of the rest web applicati=
on -->
- <field name=3D"restContextName"><string>rest</s=
tring></field>
- <!-- The name of the realm -->
- <field name=3D"realmName"><string>exo-domain</s=
tring></field>
- <!-- All the dependencies of the portal container ordered b=
y loading priority -->
- <field name=3D"dependencies">
- <collection type=3D"java.util.ArrayList">
- <value>
- <string>eXoResources</string>
- </value>
- <value>
- <string>portal</string>
- </value>
- <value>
- <string>dashboard</string>
- </value>
- <value>
- <string>exoadmin</string>
- </value>
- <value>
- <string>eXoGadgets</string>
- </value>
- <value>
- <string>eXoGadgetServer</string>
- </value>
- <value>
- <string>rest</string>
- </value>
- <value>
- <string>web</string>
- </value>
- <value>
- <string>wsrp-producer</string>
- </value>
- <!-- The sample-ext has been added at the end of the de=
pendency list in order to have the highest priority towards
- the other web applications and particularly towards "porta=
l" -->
- <value>
- <string>sample-ext</string>
- </value>
- </collection>
- </field>
- </object>
- </object-param>
- </init-params>
- </component-plugin>
- </external-component-plugins>
-</configuration>
-
-
- =
-
- How to deploy a portal extension?
-
- Refer to How to deploy the sample extension?
-
-
-
- =
-
- How to create/define a new portal?
-
- To duplicate the entire "portal.war" file to create a new =
portal, you just need to duplicate the following files from the original "p=
ortal.war":
-
-
-
-
- login/jsp/login.jsp
-
-
-
-
-
- login/skin: You can customize the css files and pi=
ctures
-
-
-
-
-
- bookmark.jsp
-
-
-
-
-
- favicon.ico: You can replace it by your own logo
-
-
-
-
-
- index.jsp
-
-
-
-
-
- portal-unavailable.jsp
-
-
-
-
-
- portal-warning.jsp
-
-
-
-
-
- WEB-INF/web.xml: You just need to change the "disp=
lay-name" and set a different value for the "realm-name" in the "login-conf=
ig". Indeed, we must have one realm name per portal.
-
-
-
-
-
- WEB-INF/jboss-web.xml: If you use JBoss AS, you ne=
ed to duplicate also this file and set the new "security-domain" with the n=
ew realm name.
-
-
-
-
-
-
- You need also to duplicate the "rest.war" file to create a=
dedicated rest web application for your portal as we must have one rest we=
b application per portal, in fact you just need to duplicate the following =
files from the original "rest.war":
-
-
-
-
- WEB-INF/web.xml: You just need to change the "disp=
lay-name" and set a different value for the "realm-name" in the "login-conf=
ig". Indeed, we must have one realm name per portal.
-
-
-
-
-
- WEB-INF/jboss-web.xml: If you use JBoss AS, you ne=
ed to duplicate also this file and set the new "security-domain" with the n=
ew realm name.
-
-
-
-
-
-
- Finally, you need to register and define the corresponding=
PortalContainerDefinition. The PortalContai=
nerDefinition of your portal will be composed of:
-
-
-
-
- The name of new portal
-
-
-
-
-
- The name of the context name of the new rest web a=
pplication
-
-
-
-
-
- The name of the new realm
-
-
-
-
-
- The list of all the dependencies of the original p=
ortal, with the new name of the rest web application instead of the old nam=
e (i.e. "rest") and with a new dependency which is in fact the name of your=
portal. As we leave the dependency of the original portal in the list of d=
ependencies, it will load the configuration files of original "portal.war" =
file.
-
-
-
-
-
-
- See an example below:
-
- =
-<?xml version=3D"1.0" enc=
oding=3D"UTF-8"?>
-<configuration
- xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd ht=
tp://www.exoplaform.org/xml/ns/kernel_1_0.xsd"
- xmlns=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd">
- <external-component-plugins>
- <!-- The full qualified name of the PortalContainerConfig -->
- <target-component>org.exoplatform.container.definition.PortalCon=
tainerConfig</target-component>
- <component-plugin>
- <!-- The name of the plugin -->
- <name>Add PortalContainer Definitions</name>
- <!-- The name of the method to call on the PortalContainerConfig =
in order to register the PortalContainerDefinitions -->
- <set-method>registerPlugin</set-method>
- <!-- The full qualified name of the PortalContainerDefinitionPlug=
in -->
- <type>org.exoplatform.container.definition.PortalContainerDefi=
nitionPlugin</type>
- <init-params>
- <object-param>
- <name>sample-portal</name>
- <object type=3D"org.exoplatform.container.definition.PortalCo=
ntainerDefinition">
- <!-- The name of the portal container -->
- <field name=3D"name"><string>sample-portal</str=
ing></field>
- <!-- The name of the context name of the rest web applicati=
on -->
- <field name=3D"restContextName"><string>rest-sampl=
e-portal</string></field>
- <!-- The name of the realm -->
- <field name=3D"realmName"><string>exo-domain-sampl=
e-portal</string></field>
- <!-- All the dependencies of the portal container ordered b=
y loading priority -->
- <field name=3D"dependencies">
- <collection type=3D"java.util.ArrayList">
- <value>
- <string>eXoResources</string>
- </value>
- <value>
- <string>portal</string>
- </value>
- <value>
- <string>dashboard</string>
- </value>
- <value>
- <string>exoadmin</string>
- </value>
- <value>
- <string>eXoGadgets</string>
- </value>
- <value>
- <string>eXoGadgetServer</string>
- </value>
- <value>
- <string>rest-sample-portal</string>
- </value>
- <value>
- <string>web</string>
- </value>
- <value>
- <string>wsrp-producer</string>
- </value>
- <value>
- <string>sample-portal</string>
- </value>
- </collection>
- </field>
- </object>
- </object-param>
- </init-params>
- </component-plugin>
- </external-component-plugins>
-</configuration>
-
- Useful Information #1
-
- A portal is implicitly a PortalContainerConf=
igOwner which means that it shares the configuration file embedd=
ed into the war file, located at WEB-INF/conf/configuration.xml
-
-
-
-
- Useful Information #2
-
- The position of the servlet context name of this web a=
pplication in the dependency list is important since the last configuration=
file loaded has always right towards other configuration files. Each confi=
guration file loaded, could potentially redefine a configuration file that =
has already been loaded. Moreover, as we now use a unified Servlet Context =
to load the configuration files, if you want for instance to import the fil=
e war:/conf/database/database-configuration.xml and th=
is file exists in 2 different web applications, the file from the last (acc=
ording to the dependency order) web application will be loaded.
-
-
-
-
-
- =
-
- How to deploy a new portal?
-
- Refer to How to deploy the sample portal?
-
-
-
- =
-
- How to import properly a configuration file using the p=
refix "war:"?
-
- Now, the ConfigurationManager uses by=
default the unified servlet context of the portal in order to get any reso=
urces in particular the configuration files. The unified servlet context is=
aware of the priorities that has been set in the PortalContainer=
Definition of the portal. In other words, if you want for instan=
ce to import the file war:/conf/database/database-configuration.x=
ml and this file exists in 2 different web applications, the fil=
e from the last (according to the dependency order) web application will be=
loaded.
-
-
- So, in order to avoid issues when we would like to package=
several products at the same time (i.e. WCM, DMS, CS, KS), we need to:
-
-
-
-
- Avoid the best you can to redefine a configuration=
file from the "portal.war" by using the exact same path (like the previous=
example)
-
-
-
-
-
- Add your configuration files in a dedicated folder=
which name will be the name of the product, in oder to ensure that no othe=
r products will use the same path
-
-
-
-
-
-
- The example below, is an the example of a file W=
EB-INF/conf/configuration.xml of the product "sample-ext".
-
- =
-<?xml version=3D"1.0" enc=
oding=3D"ISO-8859-1"?>
-<configuration
- xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd ht=
tp://www.exoplaform.org/xml/ns/kernel_1_0.xsd"
- xmlns=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd">
- <import>war:/conf/sample-ext/common/common-configuration.xml</i=
mport>
- <import>war:/conf/sample-ext/jcr/jcr-configuration.xml</import&=
gt;
- <import>war:/conf/sample-ext/portal/portal-configuration.xml</i=
mport>
- <import>war:/conf/sample-ext/web/web-inf-extension-configuration.x=
ml</import>
-</configuration>
-
-
- =
-
- How to avoid duplicating configuration files just to re=
name a simple value?
-
- In your configuration file, you can use a special variable=
called container.name.suffix in order to add a suffix=
to values that could change between portal containers. The value of this v=
ariable will be an empty sting if no PortalContainerDefinition has been defined otherwise the value will be \-$portal.c=
ontainer.name. See an example below=
:
-
- =
-<?xml version=3D"1.0" enc=
oding=3D"ISO-8859-1"?>
-<configuration
- xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd h=
ttp://www.exoplaform.org/xml/ns/kernel_1_0.xsd"
- xmlns=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd">
- <component>
- <key>org.exoplatform.services.database.HibernateService</key&=
gt;
- <jmx-name>database:type=3DHibernateService</jmx-name>
- <type>org.exoplatform.services.database.impl.HibernateServiceImp=
l</type>
- <init-params>
- <properties-param>
- <name>hibernate.properties</name>
- <description>Default Hibernate Service</description>
- <property name=3D"hibernate.show_sql" value=3D"false"/>
- <property name=3D"hibernate.cglib.use_reflection_optimizer" val=
ue=3D"true"/>
- <property name=3D"hibernate.connection.url" value=3D"jdbc:hsqld=
b:file:../temp/data/exodb${container.name.suffix}"/>
- <property name=3D"hibernate.connection.driver_class" value=3D"o=
rg.hsqldb.jdbcDriver"/>
- <property name=3D"hibernate.connection.autocommit" value=3D"tru=
e"/>
- <property name=3D"hibernate.connection.username" value=3D"sa"/&=
gt;
- <property name=3D"hibernate.connection.password" value=3D""/>
- <property name=3D"hibernate.dialect" value=3D"org.hibernate.dia=
lect.HSQLDialect"/>
- <property name=3D"hibernate.c3p0.min_size" value=3D"5"/>
- <property name=3D"hibernate.c3p0.max_size" value=3D"20"/>
- <property name=3D"hibernate.c3p0.timeout" value=3D"1800"/>
- <property name=3D"hibernate.c3p0.max_statements" value=3D"50"/&=
gt;
- </properties-param>
- </init-params>
- </component>
-</configuration>
-
-
- =
-
- How to add or change a Repository and/or a Workspace?</=
title>
- <para>
- Now you can add new JCR repositories or workspaces thanks =
to an external plugin, the configuration of your JCR Repositories will be m=
erged knowing that the merge algorithm will:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Add missing Repository Definitions and/or Workspac=
e Definitions.
- </para>
-
- </listitem>
- <listitem>
- <para>
- Change the properties of a Repository Definition i=
f it has already been defined.
- </para>
-
- </listitem>
- <listitem>
- <para>
- Replace the Workspace Definition if it has already=
been defined.
- </para>
-
- </listitem>
-
- </itemizedlist>
- <para>
- <emphasis role=3D"underline">See an example of jcr-configu=
ration.xml below:</emphasis>
- </para>
- =
-<programlisting language=3D"XML" role=3D"XML"><?xml version=3D"1.0" enc=
oding=3D"ISO-8859-1"?>
-<configuration
- xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd ht=
tp://www.exoplaform.org/xml/ns/kernel_1_0.xsd"
- xmlns=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd">
- <external-component-plugins>
- <!-- The full qualified name of the RepositoryServiceConfiguration =
-->
- <target-component>org.exoplatform.services.jcr.config.Repository=
ServiceConfiguration</target-component>
- <component-plugin>
- <!-- The name of the plugin -->
- <name>Sample RepositoryServiceConfiguration Plugin</name>
- <!-- The name of the method to call on the RepositoryServiceConfi=
guration in order to add the RepositoryServiceConfigurations -->
- <set-method>addConfig</set-method>
- <!-- The full qualified name of the RepositoryServiceConfiguratio=
nPlugin -->
- <type>org.exoplatform.services.jcr.impl.config.RepositoryServi=
ceConfigurationPlugin</type>
- <init-params>
- <value-param>
- <name>conf-path</name>
- <description>JCR configuration file</description>
- <value>war:/conf/sample-ext/jcr/repository-configuration.x=
ml</value>
- </value-param>
- </init-params>
- </component-plugin>
- </external-component-plugins>
-</configuration></programlisting>
- <para>
- See an example of repository-configuration.xml below:
- </para>
- =
-<programlisting language=3D"XML" role=3D"XML"><repository-service defau=
lt-repository=3D"repository">
- <repositories>
- <repository name=3D"repository" system-workspace=3D"system" default=
-workspace=3D"portal-system">
- <security-domain>exo-domain</security-domain>
- <access-control>optional</access-control>
- <authentication-policy>org.exoplatform.services.jcr.impl.core.=
access.JAASAuthenticator</authentication-policy>
- <workspaces>
- <workspace name=3D"sample-ws">
- <container class=3D"org.exoplatform.services.jcr.impl.storage=
.jdbc.JDBCWorkspaceDataContainer">
- <properties>
- <property name=3D"source-name" value=3D"jdbcexo${containe=
r.name.suffix}" />
- <property name=3D"dialect" value=3D"hsqldb" />
- <property name=3D"multi-db" value=3D"false" />
- <property name=3D"update-storage" value=3D"true" />
- <property name=3D"max-buffer-size" value=3D"204800" />
- <property name=3D"swap-directory" value=3D"../temp/swap/s=
ample-ws${container.name.suffix}" />
- </properties>
- <value-storages>
- <value-storage id=3D"sample-ws" class=3D"org.exoplatform.=
services.jcr.impl.storage.value.fs.TreeFileValueStorage">
- <properties>
- <property name=3D"path" value=3D"../temp/values/sampl=
e-ws${container.name.suffix}" />
- </properties>
- <filters>
- <filter property-type=3D"Binary" />
- </filters>
- </value-storage>
- </value-storages>
- </container>
- <initializer class=3D"org.exoplatform.services.jcr.impl.core.=
ScratchWorkspaceInitializer">
- <properties>
- <property name=3D"root-nodetype" value=3D"nt:unstructured=
" />
- <property name=3D"root-permissions"
- value=3D"any read;*:/platform/administrators read;*:/platf=
orm/administrators add_node;*:/platform/administrators set_property;*:/plat=
form/administrators remove" />
- </properties>
- </initializer>
- <cache enabled=3D"true">
- <properties>
- <property name=3D"max-size" value=3D"20000" />
- <property name=3D"live-time" value=3D"30000" />
- </properties>
- </cache>
- <query-handler class=3D"org.exoplatform.services.jcr.impl.cor=
e.query.lucene.SearchIndex">
- <properties>
- <property name=3D"index-dir" value=3D"../temp/jcrlucenedb=
/sample-ws${container.name.suffix}" />
- </properties>
- </query-handler>
- <lock-manager>
- <time-out>15m</time-out><!-- 15min -->
- <persister class=3D"org.exoplatform.services.jcr.impl.core.=
lock.FileSystemLockPersister">
- <properties>
- <property name=3D"path" value=3D"../temp/lock/sample-ws=
${container.name.suffix}" />
- </properties>
- </persister>
- </lock-manager>
- </workspace>
- </workspaces>
- </repository>
- </repositories>
-</repository-service></programlisting>
- <warning>
- <title>Warning
-
- If you have to change the default repository or the de=
fault workspace, please be careful since it could cause side effects as you=
could be incompatible with some portal configuration files that refer expl=
icitly to portal-system and/or to repository=
. To solve this problem you can either redefine the configuratio=
n file in a portal extension to change the workspace name and/or the reposi=
tory name or you could also add your own repository instead of your own wor=
kspace.
-
-
-
-
-
- =
-
- How to add new ResourceBundles to my portal?
-
- Now you can add new Resource Bundles, thanks to an externa=
l plugin.
-
-
- See an example below:
-
- =
-<?xml version=3D"1.0" enc=
oding=3D"ISO-8859-1"?>
-<configuration
- xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd ht=
tp://www.exoplaform.org/xml/ns/kernel_1_0.xsd"
- xmlns=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd">
- <external-component-plugins>
- <!-- The full qualified name of the ResourceBundleService -->
- <target-component>org.exoplatform.services.resources.ResourceBun=
dleService</target-component>
- <component-plugin>
- <!-- The name of the plugin -->
- <name>Sample ResourceBundle Plugin</name>
- <!-- The name of the method to call on the ResourceBundleService =
in order to register the ResourceBundles -->
- <set-method>addResourceBundle</set-method>
- <!-- The full qualified name of the BaseResourceBundlePlugin --&g=
t;
- <type>org.exoplatform.services.resources.impl.BaseResourceBund=
lePlugin</type>
- <init-params>
- <!--values-param>
- <name>classpath.resources</name>
- <description>The resources that start with the following p=
ackage name should be load from file system</description>
- <value>locale.portlet</value>
- </values-param-->
- <values-param>
- <name>init.resources</name>
- <description>Store the following resources into the db for=
the first launch </description>
- <value>locale.portal.sample</value>
- </values-param>
- <values-param>
- <name>portal.resource.names</name>
- <description>The properties files of the portal , those fi=
le will be merged
- into one ResoruceBundle properties </description>
- <value>locale.portal.sample</value>
- </values-param>
- </init-params>
- </component-plugin>
- </external-component-plugins>
-</configuration>
-
-
- =
-
- How to overwrite existing ResourceBundles in my portal?=
-
- Now each portal container has its own ClassLoade=
r which is automatically set for you at runtime (FYI: it could b=
e retrieved thanks to portalContainer.getPortalClassLoader()). This ClassLoader is an unified Clas=
sLoader that is also aware of the dependency order defined into =
the PortalContainerDefinition, so to add new keys or u=
pdate key values, you just need to:
-
-
-
-
- Add the corresponding resource bundle with the sam=
e name, with the same extension (xm=
l or properties) at the same location into the classpath of your Web application (i.e. directly into the WEB-INF/classe=
s directory or into a jar file in the WEB-INF/lib directory)
-
-
-
-
-
- Ensure that your web application is defined after =
the web application of the portal in the dependency list of the related PortalContainerDefinition.
-
-
-
-
-
-
- In the example below, we want to change the values of the =
keys UIHomePagePortlet.Label.Username and UI=
HomePagePortlet.Label.Password, and add the new key UI=
HomePagePortlet.Label.SampleKey into the Resource Bundle locale.portal.webui.
-
-
- WEB-INF/classes/local/portal/webui_en.properties</t=
itle>
- =
-<programlisting>##########################################################=
###################
-#org.exoplatform.portal.webui.component.UIHomePagePortlet =
#
-##########################################################################=
###
-
-UIHomePagePortlet.Label.Username=3DUsr:
-UIHomePagePortlet.Label.Password=3DPwd:
-UIHomePagePortlet.Label.SampleKey=3DThis is a new key that has been added =
to the Resource Bundle "locale.portal.webui" of "sample-ext"</programlistin=
g>
-
- </note>
-
- </section>
- =
- <section id=3D"sect-Reference_Guide-FAQ-How_to_replace_a_groovy_t=
emplate_of_my_portal">
- <title>How to replace a groovy template of my portal?
-
- Now each portal container has its own ServletCon=
text which is automatically set for you at runtime (FYI: it coul=
d be retrieved thanks to portalContainer.getPortalContext()). This ServletContext is an unified Se=
rvletContext that is also aware of the dependency order defined =
into the PortalContainerDefinition so to replace a gro=
ovy template of the portal, you just need to:
-
-
-
-
- Add the corresponding groovy template with the sam=
e name at the same location into your Web application
-
-
-
-
-
- Ensure that your web application is defined after =
the web application of the portal in the dependency list of the related PortalContainerDefinition.
-
-
-
-
-
-
-
- =
-
- How to add new Portal Configurations, Navigations, Page=
s or Portlet Preferences to my portal?
-
- Now you can add new Portal Configurations, Navigations, Pa=
ges or Portlet Preferences thanks to an external plugin.
-
-
- See an example below:
-
- =
-<?xml version=3D"1.0" enc=
oding=3D"ISO-8859-1"?>
-<configuration
- xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd ht=
tp://www.exoplaform.org/xml/ns/kernel_1_0.xsd"
- xmlns=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd">
- <external-component-plugins>
- <!-- The full qualified name of the UserPortalConfigService -->
- <target-component>org.exoplatform.portal.config.UserPortalConfig=
Service</target-component>
- <component-plugin>
- <!-- The name of the plugin -->
- <name>new.portal.config.user.listener</name>
- <!-- The name of the method to call on the UserPortalConfigServic=
e in order to register the NewPortalConfigs -->
- <set-method>initListener</set-method>
- <!-- The full qualified name of the NewPortalConfigListener -->
- <type>org.exoplatform.portal.config.NewPortalConfigListener<=
;/type>
- <description>this listener init the portal configuration</d=
escription>
- <init-params>
- <object-param>
- <name>portal.configuration</name>
- <description>description</description>
- <object type=3D"org.exoplatform.portal.config.NewPortalConfig=
">
- <field name=3D"predefinedOwner">
- <collection type=3D"java.util.HashSet">
- <value>
- <string>classic</string>
- </value>
- </collection>
- </field>
- <field name=3D"ownerType">
- <string>portal</string>
- </field>
- <field name=3D"templateLocation">
- <string>war:/conf/sample-ext/portal</string>
- </field>
- </object>
- </object-param>
- <object-param>
- <name>group.configuration</name>
- <description>description</description>
- <object type=3D"org.exoplatform.portal.config.NewPortalConfig=
">
- <field name=3D"predefinedOwner">
- <collection type=3D"java.util.HashSet">
- <value>
- <string>platform/users</string>
- </value>
- </collection>
- </field>
- <field name=3D"ownerType">
- <string>group</string>
- </field>
- <field name=3D"templateLocation">
- <string>war:/conf/sample-ext/portal</string>
- </field>
- </object>
- </object-param>
- <object-param>
- <name>user.configuration</name>
- <description>description</description>
- <object type=3D"org.exoplatform.portal.config.NewPortalConfig=
">
- <field name=3D"predefinedOwner">
- <collection type=3D"java.util.HashSet">
- <value>
- <string>root</string>
- </value>
- </collection>
- </field>
- <field name=3D"ownerType">
- <string>user</string>
- </field>
- <field name=3D"templateLocation">
- <string>war:/conf/sample-ext/portal</string>
- </field>
- </object>
- </object-param>
- </init-params>
- </component-plugin>
- </external-component-plugins>
-</configuration>
-
-
- =
-
- How to add new Http Filters to my portal without modify=
ing the portal binary?
-
- We added a GenericFilter that allows =
you to define new Http Filters thanks to an external plugin. Your filter wi=
ll need to implement the interface org.exoplatform.web.filter.Fil=
ter.
-
-
- See an example of configurati=
on below:
-
- =
-<?xml version=3D"1.0" enc=
oding=3D"UTF-8"?>
-<configuration
- xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd ht=
tp://www.exoplaform.org/xml/ns/kernel_1_0.xsd"
- xmlns=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd">
- <external-component-plugins>
- <!-- The full qualified name of the ExtensibleFilter -->
- <target-component>org.exoplatform.web.filter.ExtensibleFilter<=
;/target-component>
- <component-plugin>
- <!-- The name of the plugin -->
- <name>Sample Filter Definition Plugin</name>
- <!-- The name of the method to call on the ExtensibleFilter in or=
der to register the FilterDefinitions -->
- <set-method>addFilterDefinitions</set-method>
- <!-- The full qualified name of the FilterDefinitionPlugin -->
- <type>org.exoplatform.web.filter.FilterDefinitionPlugin</ty=
pe>
- <init-params>
- <object-param>
- <name>Sample Filter Definition</name>
- <object type=3D"org.exoplatform.web.filter.FilterDefinition"&=
gt;
- <!-- The filter instance -->
- <field name=3D"filter"><object type=3D"org.exoplatfor=
m.sample.ext.web.SampleFilter"/></field>
- <!-- The mapping to use -->
- <!-- WARNING: the mapping is expressed with regular express=
ions -->
- <field name=3D"patterns">
- <collection type=3D"java.util.ArrayList" item-type=3D"jav=
a.lang.String">
- <value>
- <string>/.*</string>
- </value>
- </collection>
- </field>
- </object>
- </object-param>
- </init-params>
- </component-plugin>
- </external-component-plugins>
-</configuration>
-
- See an example of Filter below:
-
-
- SampleFilter.java
- =
-...
-import org.exoplatform.web.filter.Filter;
-
-import java.io.IOException;
-
-import javax.servlet.FilterChain;
-import javax.servlet.ServletException;
-import javax.servlet.ServletRequest;
-import javax.servlet.ServletResponse;
-
-public class SampleFilter implements Filter
-{
-
- public void doFilter(ServletRequest request, ServletResponse response, =
FilterChain chain) throws IOException,
- ServletException
- {
- System.out.println("SampleFilter start");
- try
- {
- chain.doFilter(request, response);
- }
- finally
- {
- System.out.println("SampleFilter end");
- }
- }
-}
-
-
-
-
- =
-
- How to add new <emphasis>HttpSessionListeners</emphasis=
> and/or <emphasis>ServletContextListeners</emphasis> to my portal without =
modifying the portal binary?
-
- We added a GenericHttpListener that a=
llows you to define new HttpSessionListeners and/or ServletContextListeners thanks to an external plugin. Ac=
tually, the GenericHttpListener will broadcast events =
thanks to the ListenerService that you can easily capt=
ure. The events that it broadcasts are:
-
-
-
-
- org.exoplatform.web.GenericHttpListener.=
sessionCreated: When a new session is created in the portal.
-
-
-
-
-
- org.exoplatform.web.GenericHttpListener.=
sessionDestroyed: When a session is destroyed in the portal.
-
-
-
-
-
- org.exoplatform.web.GenericHttpListener.=
contextInitialized: When the servlet context of the portal is in=
itialized.
-
-
-
-
-
- org.exoplatform.web.GenericHttpListener.=
contextDestroyed: When the servlet context of the portal is dest=
royed.
-
-
-
-
-
-
- If you want to listen to org.exoplatform.web.Gen=
ericHttpListener.sessionCreated, you will need to create a Liste=
ner that extends _Listener<PortalContainer, HttpSessionEvent>_If you =
want to listen to \_org.exoplatform.web.GenericHttpListener.sessionDestroye=
d_, you will need to create a Listener that extends _Listener<PortalCont=
ainer, HttpSessionEvent>_If you want to listen to \_org.exoplatform.web.=
GenericHttpListener.contextInitialized_, you will need to create a Listener=
that extends _Listener<PortalContainer, ServletContextEvent>_If you =
want to listen to \_org.exoplatform.web.GenericHttpListener.contextDestroye=
d_, you will need to create a Listener that extends Listener<P=
ortalContainer, ServletContextEvent>
-
-
- See an example of configurati=
on below:
-
- =
-<?xml version=3D"1.0" enc=
oding=3D"UTF-8"?>
-<configuration
- xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd ht=
tp://www.exoplaform.org/xml/ns/kernel_1_0.xsd"
- xmlns=3D"http://www.exoplaform.org/xml/ns/kernel_1_0.xsd">
- <external-component-plugins>
- <!-- The full qualified name of the ListenerService -->
- <target-component>org.exoplatform.services.listener.ListenerServ=
ice</target-component>
- <component-plugin>
- <!-- The name of the listener that is also the name of the target=
event -->
- <name>org.exoplatform.web.GenericHttpListener.sessionCreated&l=
t;/name>
- <!-- The name of the method to call on the ListenerService in ord=
er to register the Listener -->
- <set-method>addListener</set-method>
- <!-- The full qualified name of the Listener -->
- <type>org.exoplatform.sample.ext.web.SampleHttpSessionCreatedL=
istener</type>
- </component-plugin>
- <component-plugin>
- <!-- The name of the listener that is also the name of the target=
event -->
- <name>org.exoplatform.web.GenericHttpListener.sessionDestroyed=
</name>
- <!-- The name of the method to call on the ListenerService in ord=
er to register the Listener -->
- <set-method>addListener</set-method>
- <!-- The full qualified name of the Listener -->
- <type>org.exoplatform.sample.ext.web.SampleHttpSessionDestroye=
dListener</type>
- </component-plugin>
- <component-plugin>
- <!-- The name of the listener that is also the name of the target=
event -->
- <name>org.exoplatform.web.GenericHttpListener.contextInitializ=
ed</name>
- <!-- The name of the method to call on the ListenerService in ord=
er to register the Listener -->
- <set-method>addListener</set-method>
- <!-- The full qualified name of the Listener -->
- <type>org.exoplatform.sample.ext.web.SampleContextInitializedL=
istener</type>
- </component-plugin>
- <component-plugin>
- <!-- The name of the listener that is also the name of the target=
event -->
- <name>org.exoplatform.web.GenericHttpListener.contextDestroyed=
</name>
- <!-- The name of the method to call on the ListenerService in ord=
er to register the Listener -->
- <set-method>addListener</set-method>
- <!-- The full qualified name of the Listener -->
- <type>org.exoplatform.sample.ext.web.SampleContextDestroyedLis=
tener</type>
- </component-plugin>
- </external-component-plugins>
-</configuration>
-
- See an example of Session Listener below:
-
-
- SampleHttpSessionCreatedListener.java
- =
-..
-import org.exoplatform.container.PortalContainer;
-import org.exoplatform.services.listener.Event;
-import org.exoplatform.services.listener.Listener;
-
-import javax.servlet.http.HttpSessionEvent;
-
-public class SampleHttpSessionCreatedListener extends Listener<PortalCo=
ntainer, HttpSessionEvent>
-{
-
- @Override
- public void onEvent(Event<PortalContainer, HttpSessionEvent> even=
t) throws Exception
- {
- System.out.println("Creating a new session");
- }
-}
-
-
-
- See an example of Context Listener below:
-
-
- SampleContextInitializedListener.java
- =
-..
-import org.exoplatform.container.PortalContainer;
-import org.exoplatform.services.listener.Event;
-import org.exoplatform.services.listener.Listener;
-
-import javax.servlet.ServletContextEvent;
-
-public class SampleContextInitializedListener extends Listener<PortalCo=
ntainer, ServletContextEvent>
-{
-
- @Override
- public void onEvent(Event<PortalContainer, ServletContextEvent> e=
vent) throws Exception
- {
- System.out.println("Initializing the context");
- }
-}
-
-
-
-
- =
-
- How to add new <emphasis>HttpServlet</emphasis> to my p=
ortal without modifying the portal binary?
-
- Actually, it is not possible but you can create a rest com=
ponent instead. For more details about rest, please refer to the following =
article .
-
-
-
- =
-
- How to override or add a Context Parameter to my portal=
without modifying the portal binary?
-
- Actually, you have nothing to do, you just need to ensure =
that you get the context parameter value from the unified servlet context o=
f the portal, that should be set for you but you can still get it from portalContainer.getPortalContext().
-
-
-
- =
-
- Where can I found an example of how to extend my portal=
?
-
- We added an example of portal extension (i.e. ability to c=
ustomize a portal without changing anything in the portal.ear) that you can=
find in the svn of gatein at gatein/sample/extension.
-
-
-
- =
-
- How to deploy the sample extension?
-
- On JBoss (tested on JBoss 5.1.0.GA)
-
- We assume that you have a clean JBoss version of GateI=
n, in other words, we assume that you have already the file exopl=
atform.ear in the deploy directory of JBoss=
and you have the related application policy in your conf/login-c=
onfig.xml.
-
-
- You need to:
-
-
-
-
- Add the file sample-ext.ear from sample/extension/ear/target/ to the deploy directory of JBoss, this=
file contains:
-
-
-
-
- The file sample-ext.war which is the web application that contains (potentially) configurati=
on files, groovy templates, resource bundles, skins and javascript files, t=
hat will extend the portal.
-
-
-
-
-
- The file exo.portal.sample.e=
xtension.config-X.Y.Z.jar which is the file in which we defined =
the PortalContainerDefinition of the original portal i=
n which we added sample-ext at the end of dependency l=
ist.
-
-
-
-
-
- The file exo.portal.sample.e=
xtension.jar-X.Y.Z.jar which is the file in which we have intern=
al classes that are actualy a set of sample classes (SampleFilter=
, SampleContextInitializedListener, SampleContextDestroyedListener, SampleH=
ttpSessionCreatedListener and SampleHttpSessionDestroyedListener)
-
-
-
-
-
-
-
-
-
- Add the file starter.ear =
from starter/ear/target/ to the deploy directory of JBoss, this file contai=
ns:
-
-
-
-
- The file starter.war which is the web application that will create and start all the portal =
containers, that is why it must be launched after all the other web applica=
tions.
-
-
-
-
-
-
-
-
-
-
- Warning #1
-
- This can only work if a Unified ClassLoader has be=
en configured on your JBoss (default behavior) and the load order is first =
the exoplatform.ear then the sample-ext.ear<=
/emphasis> and finally the starter.ear.
-
-
-
-
- Warning #2
-
- The file starter.ear must alw=
ays been started last.
-
-
-
-
-
- =
-
- On Tomcat (tested on Tomcat 6.0.20)
-
- We assume that you have a clean Tomcat version of Gate=
In, in other words, we assume that you have already all the jar files of Ga=
teIn and their dependencies into tomcat/lib, you have =
all the war files of GateIn into tomcat/webapps and yo=
u have the realm name "exo-domain" defined into the file tomcat/c=
onf/jaas.conf.
-
-
-
-
- Add the file sample-ext.war from sample/extension/war/target/ to the tomcat/webapps directory. (See the purpose of this file in the JBoss sectio=
n).
-
-
-
-
-
- Add the folder starter fr=
om starter/war/target/ to the tomcat/webapps directory=
. (See the purpose of this file in the JBoss section).
-
-
-
-
-
- Rename the directory (unzipped folder) starter to starter.war (for more details=
see the warning below)
-
-
-
-
-
- Add the jar file exo.portal.sample.e=
xtension.config-X.Y.Z.jar from sample/extension/config/target/ t=
o the tomcat/lib directory. (See the purpose=
of this file in the JBoss section).
-
-
-
-
-
- Add the jar file exo.portal.sample.e=
xtension.jar-X.Y.Z.jar from sample/extension/jar/target/ to the =
tomcat/lib directory. (See the purpose of th=
is file in the JBoss section).
-
-
-
-
-
-
- Warning
-
- This can only work if the starter.war is the last war file to be loaded, so don't hesitate to rename it =
if your war files are loaded following to the alphabetic order.
-
-
-
-
-
- =
-
-
- =
-
- Where can I find an example of how to create a new port=
al?
-
- We added an example of new portal (i.e. ability to create =
a new portal from another portal without changing anything in the portal.ea=
r) that you can find in the svn of gatein at gatein/sample/portal.
-
-
-
- =
-
- How to deploy the sample portal?
-
- On JBoss (tested on JBoss 5.1.0.GA)
-
- We assume that you have a clean JBoss version of GateI=
n, in other words, we assume that you have already the file exopl=
atform.ear in the deploy directory of JBoss=
and you have the related application policy in your conf/login-c=
onfig.xml.
-
-
- You need to:
-
-
-
-
- Add the file sample-portal.ear from sample/portal/ear/target/ to the deploy dir=
ectory of JBoss, this file contains:
-
-
-
-
- The file sample-portal.war which is the entry point of the new portal
-
-
-
-
-
- The file rest-sample-portal.=
war which is the entry point for rest outsi=
de the portal (in the portal you can access to rest th=
anks to path prefix /sample-portal/rest)
-
-
-
-
-
- The file exo.portal.sample.p=
ortal.config-X.Y.Z.jar which is the file in which we defined the=
PortalContainerDefinition of this portal
-
-
-
-
-
- The file exo.portal.sample.p=
ortal.jar-X.Y.Z.jar which is the file in which we have internal =
classes that are actualy a set of sample classes (SampleFilter, S=
ampleContextInitializedListener, SampleContextDestroyedListener, SampleHttp=
SessionCreatedListener and SampleHttpSessionDestroyedListener)
-
-
-
-
-
-
-
-
-
- Add the file starter.ear =
from starter/ear/target/ to the deploy directory of JBoss, this file contai=
ns:
-
-
-
-
- The file starter.war which is the web application that will create and start all the portal =
containers, that is why it must be launched after all the other web applica=
tions.
-
-
-
-
-
-
-
-
-
- Define the related application policy in your =
file conf/login-config.xml, as below:
-
-
-
-
-
- =
- <application-policy nam=
e=3D"exo-domain-sample-portal">
- <authentication>
- <login-module code=3D"org.exoplatform.web.security.PortalLoginMod=
ule" flag=3D"required">
- <module-option name=3D"portalContainerName">sample-portal<=
;/module-option>
- <module-option name=3D"realmName">exo-domain-sample-portal&l=
t;/module-option>
- </login-module>
- <login-module code=3D"org.exoplatform.services.security.jaas.Shar=
edStateLoginModule" flag=3D"required">
- <module-option name=3D"portalContainerName">sample-portal<=
;/module-option>
- <module-option name=3D"realmName">exo-domain-sample-portal&l=
t;/module-option>
- </login-module>
- <login-module code=3D"org.exoplatform.services.security.j2ee.Jbos=
sLoginModule" flag=3D"required">
- <module-option name=3D"portalContainerName">sample-portal<=
;/module-option>
- <module-option name=3D"realmName">exo-domain-sample-portal&l=
t;/module-option>
- </login-module>
- </authentication>
- </application-policy>
-
- Warning #1
-
- This can only work if a Unified ClassLoader has be=
en configured on your JBoss (default behavior) and the load order is first =
the exoplatform.ear then the sample-portal.e=
ar and finally the starter.ear.
-
-
-
-
- Warning #2
-
- The file starter.ear must alw=
ays been started last.
-
-
-
-
-
- =
-
- On Tomcat (tested on Tomcat 6.0.20)
-
- We assume that you have a clean Tomcat version of Gate=
In, in other words, we assume that you have already all the jar files of Ga=
teIn and their dependencies into tomcat/lib, you have =
all the war files of GateIn into tomcat/webapps and yo=
u have the realm name "exo-domain" defined into the file tomcat/c=
onf/jaas.conf.
-
-
-
-
- Add the file sample-portal.war from sample/portal/war/target/ to the tomcat/webapps directory. (See the purpose of this file in the JBoss sectio=
n).
-
-
-
-
-
- Add the file rest-sample-portal.war<=
/emphasis> from sample/portal/rest-war/target/ to the tomcat/weba=
pps directory. (See the purpose of this file in the JB=
oss section).
-
-
-
-
-
- Add the folder starter fr=
om starter/war/target/ to the tomcat/webapps directory=
. (See the purpose of this file in the JBoss section).
-
-
-
-
-
- Rename the directory (unzipped folder) starter to starter.war (for mo=
re details see the warning below).
-
-
-
-
-
- Add the jar file exo.portal.sample.p=
ortal.config-X.Y.Z.jar from sample/portal/config/target/ to the =
tomcat/lib directory. (See the purpose of th=
is file in the JBoss section).
-
-
-
-
-
- Add the jar file exo.portal.sample.p=
ortal.jar-X.Y.Z.jar from sample/portal/jar/target/ to the tomcat/lib directory. (See the purpose of this fil=
e in the JBoss section).
-
-
-
-
-
- Define the related realm in your file tomcat/conf/jaas.conf, as below:
-
-
-
-
-
-
- tomcat/conf/jaas.conf
- =
-...
-exo-domain-sample-portal {
- org.exoplatform.web.security.PortalLoginModule required
- portalContainerName=3D"sample-portal"
- realmName=3D"exo-domain-sample-portal";
- org.exoplatform.services.security.jaas.SharedStateLoginModule required
- portalContainerName=3D"sample-portal"
- realmName=3D"exo-domain-sample-portal";
- org.exoplatform.services.security.j2ee.TomcatLoginModule required
- portalContainerName=3D"sample-portal"
- realmName=3D"exo-domain-sample-portal";
-};
-
-
-
-
-
- Define the context of sample-portal<=
/emphasis> by creating a file called sample-portal.xml=
into tomcat/conf/Catalina/localhost/ with the followi=
ng content:
-
-
-
-
-
-
- tomcat/conf/Catalina/localhost/sample-portal.xm=
l
- =
-<Context path=3D'/sample-=
portal' docBase=3D'sample-portal' debug=3D'0' reloadable=3D'true' crossCont=
ext=3D'true' privileged=3D'true'>
- <Logger className=3D'org.apache.catalina.logger.SystemOutLogger'
- prefix=3D'localhost_portal_log.' suffix=3D'.txt' timestamp=3D'tr=
ue'/>
- <Manager className=3D'org.apache.catalina.session.PersistentManager' =
saveOnRestart=3D'false'/>
- <Realm className=3D'org.apache.catalina.realm.JAASRealm'
- appName=3D'exo-domain-sample-portal'
- userClassNames=3D'org.exoplatform.services.security.jaas.UserPrin=
cipal'
- roleClassNames=3D'org.exoplatform.services.security.jaas.RolePrin=
cipal'
- debug=3D'0' cache=3D'false'/>
- <Valve className=3D'org.apache.catalina.authenticator.FormAuthenticat=
or' characterEncoding=3D'UTF-8'/></Context>
-
-
-
-
-
- Define the context of rest-sample-po=
rtal by creating a file called rest-sample-portal.xml<=
/emphasis> into tomcat/conf/Catalina/localhost/ with t=
he following content:
-
-
-
-
-
-
- tomcat/conf/Catalina/localhost/rest-sample-port=
al.xml
- =
-<Context path=3D"/rest-sa=
mple-portal" docBase=3D"rest-sample-portal" reloadable=3D"true" crossContex=
t=3D"false">
-
- <Logger className=3D'org.apache.catalina.logger.SystemOutLogger'
- prefix=3D'localhost_portal_log.' suffix=3D'.txt' timestamp=3D'=
true'/>
- <Manager className=3D'org.apache.catalina.session.PersistentManager=
' saveOnRestart=3D'false'/>
- <Realm className=3D'org.apache.catalina.realm.JAASRealm'
- appName=3D'exo-domain-sample-portal'
- userClassNames=3D"org.exoplatform.services.security.jaas.UserPr=
incipal"
- roleClassNames=3D"org.exoplatform.services.security.jaas.RolePr=
incipal"
- debug=3D'0' cache=3D'false'/>
-</Context>
-
-
-
- Warning
-
- This can only work if the starter.war is the last war file to be loaded, so don't hesitate to rename it =
if your war files are loaded following to the alphabetic order.
-
-
-
-
-
- =
-
-
- =
-
- I get "java.lang.IllegalStateException: No pre init tas=
ks can be added to the portal container 'portal', because it has already be=
en initialized." what can I do to fix it?
-
- To fix this issue you need to check if:
-
-
-
-
- The file starter-gatein.ear (=
which will be starter.war for Tomcat) has been deployed
-
-
-
-
-
- The file starter-gatein.ear (=
which will be starter.war for Tomcat) is the last ear =
file to be launched
-
-
-
-
-
-
- Note
-
- With Tomcat to prevent any alphabetic issue, the good =
way to solve this problem is to:
-
-
-
-
- Unzip the archive starter.war into a directory called starter
-
-
-
-
-
- Remove the archive starter.war
-
-
-
-
-
- Rename the folder starter=
to starter.war
-
-
-
-
-
-
- This tip works because folders corresponding to unzipp=
ed wars are launched after war files.
-
-
-
-
-
- =
-
-
- =
-
- Recommendations
-
- Don't ship your configuration files with your jar files=
?
-
- Remove all the configuration files from the jar files ( conf/configuration.xml and conf/portal/configu=
ration.xml) and move them to the war file of your extension, oth=
erwise your configuration files will be loaded for all the portal container=
s which could cause incompatibility issues with other portals.
-
-
- Each extension should manage independently, its css files,=
js files, google gadgets and configuration files. If you add configuration=
files into the jar files of your extension, you brake this law.
-
-
-
- =
-
- Using a dedicated workspace/repository for your extensi=
on?
-
- In order to avoid conflicts with other extensions and to m=
anage each extension independently, it is highly recommended to use a dedic=
ated workspace or repository per extension.
-
-
-
- =
-
-
-
-
-
-
--===============2780821938182020368==--