Bug 793235 (JBEPP-320)

Summary: New mechanism for passing configuration directory location
Product: [JBoss] JBoss Enterprise Portal Platform 5 Reporter: Dominik Pospisil <dpospisi>
Component: unspecifiedAssignee: Martin Podolinsky <martin>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: urgent Docs Contact:
Priority: urgent    
Version: 5.0.0.ER04CC: mstrukel
Target Milestone: ---   
Target Release: 5.0.0.CR01   
Hardware: Unspecified   
OS: Unspecified   
URL: http://jira.jboss.org/jira/browse/JBEPP-320
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
EPP5.CR1-snapshot-100414
Last Closed: 2010-04-22 13:29:10 UTC Type: Feature Request
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
properties-service.xml none

Description Dominik Pospisil 2010-04-21 09:32:17 UTC 
Date of First Response: 2010-04-21 08:35:18
project_key: JBEPP

The Gatein portal configuration directory location is passed to EPP through system property exo.conf.dir.name. This breaks compatibility with current tooling (JBT 3.1, JBDS 3.0.0.GA) as both JBT and JBDS do not read run.conf script to start the runtime. It would be nice if the requirement to pass the property to Gatein is removed in EPP.
Comment 1 Dominik Pospisil 2010-04-21 09:33:08 UTC 
Link: Added: This issue is related to JBIDE-6202
Comment 2 Marko Strukelj 2010-04-21 12:35:18 UTC 
The solution to this is very simple really.

We can just put the required system properties into JBOSS_HOME/server/default/deploy/properties-service.xml

This will set System properties before Kernel's RootContainer is initialized, so effectively there is no difference for us between this and the current configuration approach via -D command line option.

A little downside is that properties-service will override any -D option for the same key - a little bit non-intuitive.


I'll see if I can write a simple alternative for our purposes that would avoid overriding the already set properties, and put it all together in a non-obtrusive way.
Comment 3 Marko Strukelj 2010-04-21 13:46:25 UTC 
Attached  properties-services.xml

This should do the trick.
Comment 4 Marko Strukelj 2010-04-21 13:46:25 UTC 
Attachment: Added: properties-service.xml
Comment 5 Martin Podolinsky 2010-04-22 13:29:10 UTC 
Issue fixed by altering the packaging script as proposed.