Environment Variables

Post any suggestions or enhancement requests about the Verj.io platform or this Forum

Moderators: Jon, Steve, Ian, Dave

Steve James
Ebase User
Posts: 331
Joined: Mon Mar 10, 2014 8:34 am

Environment Variables

#1

Postby Steve James » Fri Feb 26, 2016 11:34 am

I'd like to see Ebase offer the equivalent of environment variables but the code picks up the values form a properties file instead of from within web.xml.

This would mean that Ebase doesn't need to be restarted after a change.
0 x

User avatar
dvanhussel
Ebase User
Posts: 161
Joined: Fri Oct 19, 2007 12:45 pm
Location: Haarlem, the Netherlands

#2

Postby dvanhussel » Tue Mar 01, 2016 9:14 am

Hi Steve,

We use something like this in a before form script:

Code: Select all

var properties = new java.util.Properties(); 
var stream; 
try 
{ 
   stream = system.class.getResourceAsStream("/settings.properties"); 
   properties.load(stream); 
}
catch(ex){
 	print(ex);
} 
finally 
{ 
    if (stream) stream.close(); 
} 
 
const setting1 = properties.getProperty('setting1');

'setting1' is now available in all scripts of this form.

I agree that a build in feature for this would be nice.
0 x

Steve James
Ebase User
Posts: 331
Joined: Mon Mar 10, 2014 8:34 am

#3

Postby Steve James » Tue Mar 01, 2016 3:12 pm

Thanks

Possibly a simple question but where does the settings.properties file need to live?
0 x

User avatar
dvanhussel
Ebase User
Posts: 161
Joined: Fri Oct 19, 2007 12:45 pm
Location: Haarlem, the Netherlands

#4

Postby dvanhussel » Tue Mar 01, 2016 3:26 pm

Steve James wrote:Thanks

Possibly a simple question but where does the settings.properties file need to live?
It should be in this folder:

Ufs/WEB-INF/classes
0 x

Steve James
Ebase User
Posts: 331
Joined: Mon Mar 10, 2014 8:34 am

#5

Postby Steve James » Tue Mar 01, 2016 4:10 pm

Thanks, I must be missing something.

In Ebase 5.0.1 I've managed to get it working (including picking up changes to the properties file) but I can't pick up the constant in a second script.

I'm getting caching in 4.5 by the looks of things as it isn't picking up changes to the properties file.

More investigations tomorrow.
0 x

User avatar
dvanhussel
Ebase User
Posts: 161
Joined: Fri Oct 19, 2007 12:45 pm
Location: Haarlem, the Netherlands

#6

Postby dvanhussel » Tue Mar 01, 2016 7:05 pm

Oops! Sorry... my mistake. This should be in a 'Shared functions script' instead of a 'before form script'. We have one script that is always the first 'Shared functions script' in any form.

In the process of migrating to Ebase V5 we did some refactoring we wanted to do earlier, because we where testing thoroughly anyway. One of the things was moving form properties that we used to have in scripts to properties files.

So I only tested this on Ebase 5.0.1. where it is working ok for us. Changes I make in the properties file are picked up directly when the form is run again, without restarting Tomcat.


Ebase staff can probably say if this should work in 4.5. If I'm correct, in V5 all scripts and resources are loaded when a form is started, in V4 they where loaded 'when needed'. Maybe there is some caching involved too.
0 x

Steve James
Ebase User
Posts: 331
Joined: Mon Mar 10, 2014 8:34 am

#7

Postby Steve James » Wed Mar 02, 2016 8:57 am

Thanks dvanhussel.

Code: Select all

We have one script that is always the first 'Shared functions script' in any form. 
I think this should be an option to configure rather than having to remember to include a script in every form. We have one Ebase installation per environment but in our production environment we have internal and external forms. We include a script in all internal forms to prevent them from being accessed externally. This is an opt out approach so if there was a configured script to run we'd have an opt in approach.
As part of our migration to v5.0.1 we are planning to have an internal and external environment. More support but safer, unless Ebase are planning anything to improve this situation.

So back to environment variables. On my way home last night I thought of another way.

It means all variables exist in a single script but means that they are easily checked. As yours the script needs to be included as a shared function (that could be part of a linked project).
I don't think we'll do anything until we start on the v5.0.1 work proper but we're waiting for the next service pack as there are a couple of gotchas in v5.0.1.

Code: Select all

function getEnv_systemA_URL(){return getVariable("systemA_URL");}
function getEnv_systemB_UNC(){return getVariable("systemB_UNC");}
function getEnv_systemC_DMS(){return getVariable("systemC_DMS");}

var DEVEnv = 
{
	systemA_URL:"http://devurl.company.co.uk/",
	systemB_UNC:"//server/sharename/DEV/",
	systemC_DMS:"//server/import/DEV/"	
}
var UATEnv = 
{
	systemA_URL:"http://uaturl.company.co.uk/",
	systemB_UNC:"//server/sharename/UAT/",
	systemC_DMS:"//server/import/UAT/"	
}
var PRDEnv = {
	systemA_URL:"http://prdurl.company.co.uk/",
	systemB_UNC:"//server/sharename/PRD/",
	systemC_DMS:"//server/import/PRD/"
}

function getVariable(name)
{
	try
	{
		var env = system.variables.$ENV_ENVIRONMENT.value;
	
		if (env == "PRODUCTION")
		{
			return PRDEnv[name];
		}
		else if (env == "DEVELOPMENT")
		{
			return DEVEnv[name];		
		}
		else if (env == "UAT")
		{
			return UATEnv[name];
		}
		else
		{
			return null;
			// log / email ??
		}
	}
	catch (e)
	{
		// log / email ???
		return null;
	}
}
Thanks for the replies, it gets the brain juices flowing.
0 x


Who is online

Users browsing this forum: No registered users and 3 guests