Reintroduce instance specific properties and make it configurable

• Type: Feature Request
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Affects Version/s: 5.1.2, 5.2.2
• Fix Version/s: None
• Component/s: Portal Services, Portal Services > LDAP
• Labels: None
• Branch Version/s:
  5.1.x
• Backported to Branch:
  Committed
• Liferay Contributor's Agreement:
  Accept
• Similar Issues: Show 5 results ; ;

  LPS-31820	Make session.timeout property configurable per Portal Instance
  LPS-45814	Move portlet instance specific properties to portlet configuration (as opposed to service configuration)
  LPS-39673	Broaden the number of properties that are configurable by instance
  LPS-53740	Allow user.reminder.queries.enabled to be instance specific
  LPS-3469	Multiple Instance Properties Over-Riding

As I prefer to have instance specific configuration already on instance creation (eg. default admin and ldap settings) I ported it from 4.3 to current head and made it configurable in portal-ext.properties to avoid confusion (LEP-6390).

Attached is ConfigurationImpl.java and PropsUtil.java (rev 21163).
Set include-and-override=portal-$

{easyconf:companyId}

.properties in portal-ext.properties to enable the feature.

I'd very much like to have this included again. Please let me know if I can do something else.

[Tuomo Kujanpää]

Great! Yeah, this feature is really needed. It is not enough to give a few properties to the instance in Enterprise Admin portlet after instance creation.

[Ben Starr]

I would also very much like to see this feature included back into the main code base.

[Marc Champion]

I updated the patches to current head. Attached is ConfigurationImpl.java and PropsUtil.java (rev 27078).

Set include-and-override=portal-$

{easyconf:companyId}

.properties in portal-ext.properties to enable the feature.

Instance specific configuration was a killer feature of the liferay portal. When you realize even smaller projects with liferay such as we do it's hard to convince the customers to pay $700+ for a whole liferay instance with 1GB RAM. When you can share an instance with other customers the hosting price comes down and we can fully profit from the portal infrastructure.

Are there others that miss this feature? Maybe we can convince Liferay inc. that it wasn't a good idea to remove it? If that's somehow impossible I ask for help in the community to test and contribute to the patches I made. Some settings such as layout.default.template.id and locales don't work properly in the instance specific configuration files but most of it works for me. Maybe we can at least provide a patchset that makes instance specific configuration fully work again.

[Ben Starr]

I totally agree with you Marc. I've submitted a feature suggestion to the message boards to have it re-introduced. Hopefully it will raise awareness of the issue:

http://www.liferay.com/web/guest/community/forums/-/message_boards/message/2447165

Ben

[Jorge Ferrer]

Hey Marc, Ben,

That feature lead to several issues, confusion and inconsistencies, which is why it was removed.

The alternative now is the Portal > Settings item within the Control Panel.

[Ben Starr]

Hi Jorge,

Thanks for the information. I assume that the feature in Portal > Settings is only available in 5.2 and not 5.1? I'm currently using 5.1 and couldn't find anywhere that provides equivalent functionality. Can you confirm that the Portal > Settings function allows properties to be defined per-instance/company? Can these properties then be programmatically queried via the PrefsPropsUtil.getXxx(companyId, name) methods? That is the kind of functionality that I need.

Thanks,

Ben

[Marc Champion]

Hi Jorge,

Thank you for your answer! I need to specify the following settings per instance. Is there currently a way to set them instance specific or are you planning to make them configurable via the settings page in the control panel?

Kind regards,
Marc

##

1. 1. Users
      ##

users.form.add.main=
users.form.add.identification=
users.form.add.miscellaneous=

users.form.update.main=
users.form.update.identification=
users.form.update.miscellaneous=

##

1. 1. Languages and Time Zones
      ##

locales=

##

1. 1. Look and Feel
      ##

default.regular.theme.id=

##

1. 1. Default User
      ##

default.user.layout.name=
default.user.public.layout.template.id=
default.user.layout.column-1=

##

1. 1. Layouts
      ##

layout.static.portlets.start.column-0[community]=
layout.add.portlets=
layout.show.portlet.inactive=

layout.default.template.id=

##

1. 1. Navigation Portlet
      ##

navigation.display.style.options=
navigation.display.style[7]=

[Ben Starr]

I think there are two different issues here. The first is the ability to specify your own per-instance properties. The second is the ability to set standard portal properties per-instance. I'm not sure if both were previously possible or only the first.

I am particularly interested in being able to specify my own per-instance properties as a way to customise the portal for different instances. However, it would also be useful to be able to set many of the standard portal properties on a per-instance basis. I would have thought this should include all standard portal properties that don't need to apply globally. Some ones I can think of in addition to the list above are those related to user layouts:

layout.user.private.layouts.enabled=true
layout.user.private.layouts.modifiable=true
layout.user.private.layouts.auto.create=true

layout.user.public.layouts.enabled=true
layout.user.public.layouts.modifiable=true
layout.user.public.layouts.auto.create=true

It would be useful to be able to configure these on a per-instance basis. I'm not sure whether both of the issues mentioned above are provided for in Portal > Settings in the Control Panel?

[Andrea Vacondio]

Hi,
I added this patch and tried to have a "per instance" configuration using the include-and-override=portal-$

{easyconf:companyId}

.properties. My need is to have different subsets of available locales so I added the following property to the portal-$

{easyconf:companyId}

.properties:

locales=it_IT,en_US,fr_FR,es_ES,de_DE

The problem is that this property seems to be ignored and when i publish a webcontent the combobox "Language" is populated with the full list and not my "per instance" list. Everything works if I set this property in the portal-ext.properties but I need a different list for each instance, could it be fixed?
Thank you
Andrea

[Marc Champion]

Hi Andrea

If you aren't sure if your setup works in general add the following property to an instance specific configuration file:

field.enable.com.liferay.portal.model.Contact.birthday=false

This should remove the birthday field from the create account portlet on the instance with the specific configuration.

But even if this works, I know that locales don't work properly with my patch (see my comment from 10/Mar/09). I've already tried to fix this but didn't have enough time to track it down. In LanguageImpl.java the _getInstance() function creates a LanguageImpl per instance. This LanguageImpl get's it's locales from PropsValues.LOCALES which itself calls PropsUtil.getArray(PropsKeys.LOCALES) which is already patched to read the instance specific configuration file. That's how far I came. But there must be some other locale functionality which makes it stop working. Maybe others could help?

Regards
Marc

[Andrea Vacondio]

Hi Mark,
I'm new to Liferay (it's just a week I'm working on it) but digging into the code I found a possible solution to the locales issue.
in PropsValues there's

public static String[] LOCALES = PropsUtil.getArray(PropsKeys.LOCALES);

that is a class variable and is accessed by the LanguageImpl constructor to get the locales list. While the PropsUtil.getArray(PropsKeys.LOCALES); has the logic to manage per instace configuration, the PropsValues.LOCALES is static and, from the Sun website:
"If the declarator is for a class variable (that is, a static field), then the variable initializer is evaluated and the assignment performed exactly once, when the class is initialized" so the LOCALES field once initialized wont be reevaluated and every LanguageImpls will have the same locales list.
To solve this i modified the LanguageImpl line 548 with:

String[] localesArray = PropsUtil.getArray(PropsKeys.LOCALES);

It seems working to me but as said I'm totally new to Liferay and perhaps I'm missing something thus it would be nice if some expert could confirm this.

Regards
Andrea

[Marc Champion]

Hey Andrea

Great, that sounds like the solution. I'll try it next week and create a new patchset of the current 5.2.x branch.

Thanks
Marc

[Andrea Vacondio]

Hi Marc,
I'm still tring to understand the code (the "per instance" property file seems to be very important to my company) so this is what i found.
Your PropsUtil.java seems to come from the 5.1 version and gives some error on the 5.2.2 (the version i patched). in particular there was an error with the default.liferay.home property thus I adapted your patched version to the PropsUtil in the 5.2.2 (hopefully with no errors) and everything seems fine now (I'll attach the PropsUtil.java).
I also thought about the PropsValues class and it seems to me that a very structural change is needed to have your patch fully working (in 5.2.2, don't know about the 5.1). I think all the class variables in this class are populated with the portal.properties/portal-ext.properties logic ignoring the portal-$

{easyconf:companyId}

.properties and, if so, everywhere in the Liferay code where a PropsValue static filed is accessed the "per instance" logic doesn't apply. To have your patch fully working, class variables in PropsValues should be replaced by static method calls where the method body is something like:

PropsUtil.getSOMETHING(PropsKeys.SOMETHING);

This would call your "per instance" logic everytime a PropsValues is requested but, as said, it would have a very big impact on the Liferay code.

[Andrea Vacondio]

Patched version from the 5.2.2

[Brian Chan]

Alrighty guys, back by popular demand.

Disabled by default though,

java ... company-id-properties=true

to enable it.

I disabled it by default because if you enable it, it forces a creation of a new ConfigurationImpl for every instance, and for those who don't want it, it's unnecessary memory usage. I also updated the documentation on it to make it easier to understand.

Thanks to all who wanted this (it helps when the community shouts, cause then we know ppl care).

#

1. Specify where to get the overridden properties. Updates should not be made
2. on this file but on the overridden version of this file.
   #
3. The default read order is: portal.properties and then
4. portal-ext.properties.
   #
   include-and-override=portal-ext.properties
   include-and-override=$ {liferay.home}

   /portal-ext.properties

#

1. Each portal instance can have its own overriden property file following
2. the convention portal-companyId.properties. To enable this feature, set
3. the "company-id-properties" system property to true.
   #
4. To enable:
   #
5. java ... company-id-properties=true
   #
6. The read order will now be: portal.properties, then portal-ext.properties,
7. and then portal-liferay.com.properties.
   #
   include-and-override=portal-$ {easyconf:companyId}

   .properties

#

1. Additional property files can be used by setting the "external-properties"
2. system property.
   #
3. A common use case is to keep legacy property values when upgrading to
4. newer versions of Liferay. To enable:
   #
5. java ... -Dexternal-properties=portal-legacy-5.1.properties
   #
6. The read order will now be: portal.properties, then portal-ext.properties,
7. and then portal-legacy-5.1.properties.
   #
   include-and-override=$ {external-properties}

[Marc Champion]

Thank you Brian!

[Josh Asbury]

Great! Thanks, Brian!

[Jorge Ferrer]

Hey Marc, Josh,

Note that although this has been added back the recommended way to set instance specific properties is through the Control Panel >> Portal >> Settings UI.

If there are some settings that you miss there, let us know and we'll add them

[Mika Koivisto]

Jorge, most of the options starting with layout. are the ones that come to my mind. For instance in some instances you might want to have user pages and on other you might not.

[Marc Champion]

Hi Jorge, this is what I usually want to define instance specific:

##

1. 1. Theme
      ##

theme.css.fast.load=
theme.images.fast.load=

##

1. 1. JavaScript
      ##

javascript.fast.load=
javascript.log.enabled=

##

1. 1. Users
      ##

users.screen.name.always.autogenerate=

1. 2. Groups and Roles
      ##

terms.of.use.required=

##

1. 1. Organizations and Locations
      ##

organizations.location.enabled=

##

1. 1. Velocity Engine
      ##

velocity.engine.resource.manager.cache.enabled=

##

1. 1. Languages and Time Zones
      ##

locales=

##

1. 1. Look and Feel
      ##

default.regular.theme.id=

##

1. 1. Default User
      ##

default.user.public.layout.name=
default.user.public.layout.template.id=
default.user.layout.column-1=

##

1. 1. Layouts
      ##

layout.show.portlet.access.denied=
layout.show.portlet.inactive=
layout.template.cache.enabled=

##

1. 1. Fields
      ##

field.enable.com.liferay.portal.model.Contact.male=
field.enable.com.liferay.portal.model.Contact.birthday=

##

1. 1. Servlet Filters
      ##

com.liferay.portal.servlet.filters.cache.CacheFilter=

##

1. 1. Passwords
      ##

passwords.encryption.algorithm=

##

1. 1. Default Admin
      ##

default.admin.password=
default.admin.screen.name=
default.admin.email.address.prefix=
default.admin.first.name=
default.admin.last.name=

##

1. 1. Listeners
      ##

value.object.listener.com.liferay.portal.model.Layout=
value.object.listener.com.liferay.portal.model.PortletPreferences=

[Josh Asbury]

In addition to the aforementioned, here are the properties that I use:

##

1. 1. Default Landing Page
      ##
      default.landing.page.path=
      auth.forward.by.last.path=

##

1. 1. Calendar Portlet
      ##
      calendar.event.types=

[Andrea Vacondio]

Great!
Here are mine properties:

locales=
layout.user.private.layouts.enabled=
layout.user.public.layouts.enabled=
dl.file.max.size=
ig.image.max.size=
journal.template.velocity.restricted.variables=

It seems there are a lot of properties here and, in general every different Liferay user could have the need to set any of the available properties. If you aim to have the Panel >> Portal >> Settings interface like the place to go to set instace specific properties I think you should provide there some kind of interface to set every property or to edit the property file. Just a suggestion.

[Jorge Ferrer]

Thanks Marc, Josh, Andrea,

That's very useful.

[Ben Starr]

Brian, thank you very much for adding this feature back in! Having it disabled by default is fine with me as it is easy to enable if needed.

Jorge, I think it would be useful to include all portal properties that do not need to apply globally to allow instances to be customised as much as possible.

While it is good to be able to configure these settings in the GUI there are reasons why you might want to use the properties files. The first is that it means you can pre-configure a properties file and just deploy it to a Liferay Portal instance rather than having to configure each property manually in the GUI. The second is if you want to add your own custom properties that aren't part of the standard set. I'm using the latter to customise certain parts of the system that can't otherwise be customised. Any chance that we could also add our own properties in the GUI?

[Ben Starr]

In previous versions PropsUtil had a method get(long companyId, String key). This method does not seem to have been reintroduced. What if I want to retrieve a property for an instance other than the instance of the current thread? An example of this would be a background job that is not associated with a request. If the job was for a specific instance then it would be nice to store the properties for the job in the instance-specific properties even though the job runs in a separate thread.

I'm also a bit confused about the difference between PropsUtil and PrefsPropsUtil. The latter seems to load overriden properties from the instance-specific properties file in some circumstances but when I looked in the code all I could see was it loading properties from the database so I'm not sure how it is getting them from the file. When should PropsUtil be used and when should PrefsPropsUtil be used?

Thanks.

[Jorge Ferrer]

Hi Ben,

You should use PrefsPropsUtil for any property whose value can also be set from the Portal >> Settings UI. BTW, we added many more properties to that UI as suggested by previous comments and the change were backported to 5.2.x so you may want to check if you find what you want. You can check the changes in LPS-3457

[Ben Starr]

Hi Jorge,

Thanks for the clarification. Can you confirm that PrefsPropsUtil will load properties from the database and then from the properties files? If that is the case then I think there is a problem with the way this functionality has been re-introduced. From what I can tell there are versions of each method in PrefsPropsUtil to specify the company ID to retrieve the property for. However, in PropsUtil there is no way to specify the company ID but the way this functionality has been re-introduced it will retrieve the instance-specific property for the company ID of the current thread.

I am assuming that if PrefsPropsUtil does not find the property in the database it will fall back to PropsUtil to load it from the properties files? In the case that the company ID has been specified in the call to PrefsPropsUtil this will work fine if the company ID is the same as the current thread since any fall-back to PropsUtil (i.e. the properties files) will use the correct company ID. However, if the company ID specified in the call to PrefsPropsUtil is not the same company ID as the current thread then the fall-back to PropsUtil may load the incorrect property value since it will use the company ID of the current thread.

I think the fix for this would be to add methods to PropsUtil to load properties by a specified company ID and if PrefsPropsUtil falls back to PropsUtil because the property is not set in the database then it should pass through the company ID if specified.

I hope this makes sense. An example of a situation where I have found this to be a problem is loading instance-specific properties from a background scheduled job where the current thread has no company ID associated with it. In this case a call to PrefsPropsUtil does not use the specified company ID to load the property from the instance-specific properties file, it just uses the default properties files (portal-ext.properties, portal.properties).

[Ben Starr]

I have reopened this issue because I do not believe the fix addresses the situation where you need to load an instance-specific property for a company that is not the company of the current thread (e.g. in a background scheduled job). See my previous comment for further information about this issue.

[Edgar Vonk]

Hi,

I would primarily like to change:

default.landing.page.path=

per portal instance.

I have enabled the feature by including in my portal-ext.properties:

include-and-override=portal-${easyconf:companyId}.properties

and by setting:

JAVA_OPTS="$JAVA_OPTS -Dcompany-id-properties=true"

in my run.conf

I have created a portal-mysecondportalinstance.properties file where mysecondportalinstance is the webId of my second portal instance. It does not seem to pick up any overriden properties however. Am I missing something?

I read here:

Also, my understanding is that at this stage only some of the properties in the portal.properties file can be overridden per-instance. I'm not sure exactly which ones can and can't - you might just have to experiment.

Is this true?

PS: liferay.com is de webId of the default portal instance, not the companyId?

[Marc Champion]

Hi Edgar

default.landing.page.path cannot be set in portal-$

{companyId}

.properties. Since the 5.2 branch, additional settings can be made in Control Panel > Portal > Settings. On the first tab you'll find Default Landing Page. These settings are instance specific. Please note that these additional settings were not in the 5.2 bundle but they should be in the current 5.3.0 bundle.

Regards, Marc

[Edgar Vonk]

Thanks Marc! Looking forward to work with the 5.3.0 bundle when it is out.

I have not looked at the latest 5.2 branch code but is there also support for custom instance specific properties from the Control Panel?

[Marc Champion]

Hi Edgar

Yes, we are working with the latest 5.2 branch and can set "Default Landing Page" for every instance in the portal over the control panel.

Regards, Marc

[Edgar Vonk]

Ok clear, but can you also edit all the other portal properties there for every instance? And can you also add your own custom portal properties? We have some custom portal properties in our portal-ext.properties that we would like to configure differently for the portal instances we have.

[Ben Starr]

I would also like to be able to edit custom properties through the UI. Custom properties are an important way to customise Liferay outside of the customisations that are already possible.

[Marc Champion]

Hi Edgar and Ben

I see the following situation:

portal-ext.properties:
Configure the default portal properties for all instances here. Some of them may also be configured instance specific over the ui. In that case the ui takes precedence. Of cause you can also define your custom, global portal properties here.

portal-$

{companyId}

.properties:
You can only configure custom, instance specific properties here. Liferay properties cannot be overridden instance specific, as the calls to the getProperty() functions are static. Again, this is where you want to put your custom, instance specific portal properties.

UI:
Configure a subset of the portal properties on an instance specific basis over the ui. Not all properties may be configured here. In the past liferay developers asked which properties we wished and implemented them. So give it a try if you need more properties.

Thank you for any corrections!

Regards, Marc

[Edgar Vonk]

ok. thanks Marc! all clear now.

[Lisa Simpson]

I'd like to see almost everything be configured at the per instance level at most. I keep debating on the database connection. I can think of a couple of use cases where even the database connection should be set on a per instance basis. And I can't see where it would break the people who don't need it.

[Edgar Vonk]

Same here. We run into big issues now because this is not possible. We might even have to run two completely separate Liferay installations because we need to quite different portals. It is a big shame that we would need two Liferay installations to achieve this.

[Ben Starr]

Hi Marc,

Thanks for the information. Personally I think the ideal situation would be as follows:

portal-ext.properties
Global modified Liferay properties and custom properties. Overrides portal.properties.

portal-$

{companyId}.properties
Instance-specific Liferay properties and custom properties. Overrides portal-ext.properties and portal.properties.

UI
Instance-specific Liferay properties (subset) and custom properties. Overrides portal-${companyId}

.properties, portal-ext.properties and portal.properties.

This would provide the greatest flexibility. It is often desirable to configure properties in the various properties files because then you can pre-configure appropriate settings rather than having to manually enter them into the UI on each deployment. It is also desirable to be able to configure custom properties in the UI in addition to the Liferay properties as a way to override the properties files.

If this is not possible then it would at least be useful to be able to configure custom properties in the UI in addition to Marc's specification above.

Ben

[Marc Champion]

Hi Ben

The big plus of the instance specific configuration over the ui is that you don't have to restart the application server after
changing settings. In my case most of the settings are the same for all instances and I can easily configure the varying settings manually over the ui. I think it's just confusing that portal-$

{companyId}

.properties was reintroduced but it just doesn't work for liferay properties, only for custom properties. This should be clarified in the portal.properties description. Maybe something like this:

1. Each portal instance can have it's own overridden property file following
2. the convention portal-companyWebId.properties. Use it to define or override
3. your custom properties. You cannot override the default Liferay properties here.
4. Use the settings section in the enterprise admin instead.

Regards, Marc

[Milan Jaroš]

Hi guys, thank you for that great improvement.
IMHO it can be useful to have specified in portal.properties something like this:

1. 1. This property can be set in Portal settings portlet.

[Cynthia Wilburn (Inactive)]

Can you please update this ticket with a proper component selection?

If you do not have edit permissions, please add it as a comment.

Thanks!

[Arjun Mullick]

I am using Liferay 6.0 and saw that some properties are made instance configurable like properties for
terms of use and authentication type by keeping them as preference configurable setting ,
can there be a way I can customize other property from PropsValues like (PropsValues.USERS_REMINDER_QUERIES_ENABLED) which are static variables.

Though I am able yo fetch instance specific properties by kernel PropsUtil but PropsValues are referenced in many places in existing Liferay code and cant change it to PropsUtil , please suggest an alternate way to load instance specific class .

[Milan Jaroš]

According to my earlier comment:
I mean that if something can be set at both Portal settings portlet and portal.properties there should be some comment line in portal.properties nearby that value.

[Milan Jaroš]

Arjun, I know this is not answer to your question but maybe it could be helpful for you.
From my experience: Avoid using portal instances feature as long as it is possible. I prefer to create new server and database instance.

[Randy Zhu]

In preparation for Ideation; we are merging New Feature and Improvement tickets into a singular ticket type called “Feature Request”. Additional information to follow soon.