Bug 996981 - Domain mode: Portal not loaded with default profile
Domain mode: Portal not loaded with default profile
Product: JBoss Enterprise Portal Platform 6
Classification: JBoss
Component: Portal (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ER05
: 6.1.0
Assigned To: Marko Strukelj
Dominik Pospisil
Depends On:
  Show dependency treegraph
Reported: 2013-08-14 08:06 EDT by Miroslav Cupák
Modified: 2015-01-05 06:59 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-08-23 04:07:25 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Miroslav Cupák 2013-08-14 08:06:27 EDT
Description of problem:
If a new server group with the default profile is created via admin console and a new server is created in this group and started, the portal is not loaded with the start of the server.

This seems to happen only in this combination - new server group/default profile, i.e. if a new group is created with the full profile or if one of the default groups is changed to use the default profile, the portal is started correctly.

Steps to Reproduce:
1. Run add-user.sh to create a user to access the console. 
2. Run demo-domain-setup.sh to create a sample setup.
3. Start the server in domain mode.
4. Go to the admin console and create a new server group with the default profile.
5. Create a new server via the admin console and assign it to your group.
6. Start the server via admin console.
Comment 2 Marko Strukelj 2013-08-20 10:34:35 EDT
The reason for this behaviour is in the way configuration is constructed. In packaging/jboss-as7/README.txt it says:

The demo configuration shows how a gatein.extensions.dir system property can be used to assign different extensions directories to different servers in order to allow different portals to coexist on the same host.
The first server - 'server-one' - uses the default extensions directory location ($JBOSS_HOME/gatein/extensions). For the second one - 'server-two' - we specify an alternate extensions location in host.xml.

The demo configuration also makes two copies of gatein configuration directory ($JBOSS_HOME/standalone/configuration/gatein) - one for each server.

This means that each new server requires it's own copy of configuration directory. If I create a new server called 'new-server' via admin console, no configuration copying will take place, and when new-server is started I can tail new-server's log file (domain/servers/new-server/log/server.log) where I can see the problem:

15:53:32,487 ERROR [org.exoplatform.container.util.ContainerUtil] (MSC service thread 1-15) Cannot load property file file:/Users/marko/devel/gatein-portal-prod/packaging/jboss-as7/pkg/target/jboss/jbo
ss-jpp-6.1/modules/system/add-ons/gatein/org/gatein/lib/main/exo.core.component.document-2.5.4-GA.jar!/conf/configuration.properties: java.io.FileNotFoundException: JAR entry conf/configuration.propert
ies not found in /Users/marko/devel/gatein-portal-prod/packaging/jboss-as7/pkg/target/jboss/jboss-jpp-6.1/modules/system/add-ons/gatein/org/gatein/lib/main/exo.core.component.document-2.5.4-GA.jar
        at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:140) [rt.jar:1.7.0_06]
        at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150) [rt.jar:1.7.0_06]
        at java.net.URL.openStream(URL.java:1035) [rt.jar:1.7.0_06]
        at org.exoplatform.container.util.ContainerUtil.loadProperties(ContainerUtil.java:252) [exo.kernel.container-2.4.4-GA.jar:2.4.4-GA]
        at org.exoplatform.container.util.ContainerUtil.loadProperties(ContainerUtil.java:232) [exo.kernel.container-2.4.4-GA.jar:2.4.4-GA]
        at org.exoplatform.container.PropertyConfigurator.<init>(PropertyConfigurator.java:117) [exo.kernel.container-2.4.4-GA.jar:2.4.4-GA]


This is due to missing gatein configuration which is looked for in domain/servers/new-server/configuration/gatein.

It is demo-domain-setup.sh script that copies these around for our demo setup. Again, setup specifically wants to demonstrate the ability to have multiple independent configuration.

For this new-server example we would have to run:

mkdir -p "$JB_HOME/domain/servers/new-server/configuration"
cp -r "$JB_HOME/standalone/configuration/gatein" "$JB_HOME/domain/servers/new-server/configuration/"

And restart new-server through admin console.

If we wanted to support the use case of provisioning new servers via admin console we would have to specify configuration in non-server specific manner. i.e. relative to host controller for example, or relative to environment variable that would have to be properly defined on all servers ...

At the moment configuration location is hardcoded to:

File confDir = new File(System.getProperty("jboss.server.config.dir"), "gatein").getAbsolutePath();

which in domain mode with server called new-server becomes: "$JB_HOME/domain/servers/new-server/configuration/gatein".
Comment 3 Lucas Ponce 2013-08-21 09:25:34 EDT
Additional notes to configure domain mode:

Comment 4 Marko Strukelj 2013-08-21 11:23:38 EDT
Looking at this some more, and using Lucas' link above which describes how the necessary system properties can be overridden via admin console for newly created server to point to a non-default configuration directory.

I tried it but it doesn't completely work for me. The problem is that configuration.properties file overrides any system properties set at boot time or at GateInExtension initialization time.

One important property is 'gatein.portlet.config' defined in standalone/configuration/gatein/configuration.properties as:


and 'gatein.conf.dir' is defined as:


which overwrites the system property set through admin console to:


The way to fix this is to simply uncomment / remove gatein.conf.dir line from configuration.properties. It doesn't make any sense anyway, as it's supposed to  point to the location of configuration.properties the very file that would then redefine it.

To sum up, following the instruction at the link pointed to and fixing configuration.properties first, I got the use case working.
Comment 5 Miroslav Cupák 2013-08-22 06:12:07 EDT
All this is true, but it's not the issue I was describing here. By the way, there is also a note about having to comment out gatein.conf.dir when using standalone's configuration.properties in the documentation linked above.

I'm aware of how the demo configuration is constructed and how the system properties need to be set up. Note that demo configuration doesn't use the default profile (which is the one I had problems with) and that my set up was working with the full profile, which should confirm that system properties were set up correctly. I assumed all these details would be configured properly when reproducing the bug (I should have provided more details under steps to reproduce).

Despite the seemingly correct setup, I still experienced an issue with GateIn not being deployed properly when starting the server. Does this scenario work for you after configuring everything according to the provided link?

It's kind of a weird problem and I was suspecting it's some random issue with my setup at first, but I encountered the same problem on a different machine, so I'm hoping you can reproduce it.
Comment 6 Marko Strukelj 2013-08-22 10:18:19 EDT
As I mentioned in my previous comment - when I do the steps outlined in Lucas' document (set system properties), and fix configuration.properties, the scenario then works for me.
Comment 7 Miroslav Cupák 2013-08-23 02:47:59 EDT
Strange, trying this again from scratch, everything seems to work. Not sure what I did differently before. Sorry about that, must have been some kind of an error on my side. Feel free to close this issue.
Comment 8 Peter Palaga 2013-11-19 10:58:27 EST
Pull request URL for the record: https://github.com/gatein/gatein-portal/pull/634

Note You need to log in before you can comment on or make changes to this bug.