Fórum

Store all portal.properties to the db and add a new table to store them

thumbnail
Ed Shin, modificado 16 Anos atrás.

Store all portal.properties to the db and add a new table to store them

Junior Member Postagens: 71 Data de Entrada: 24/03/05 Postagens Recentes
It would be nice to store all the portal.properties in the database. Then we could modify them via the GUI without having to restart the server. For example, imagine being able to add or remove dl.file.extensions via the GUI. We could easily add new extensions without having to compromise on security or miss out on the customized gif image.

(I'm guessing that some properties would require a server restart, but we could put in a message that tells the user that a server restart is required in those cases.)

Here's another use case where it would be helpful:

On my current project, we have many installations that have the same code base, but different portal-ext.properties. Since we can't install SVN on every server, we have to check which properties have been added since the last update or use a diff utility to see what has changed. If all properties were stored in the database, we could overwrite portal-ext.properties without having to worry about losing custom changes.

(Another useful benefit would be that it would be easier to implement pagination.)

This leads us to where the properties will be stored. Currently, we store portal preferences in the portletpreferences table using LIFERAY_PORTAL as the key. It would be more intuitive to add a new portalpreferences table or similar that would contain all portal preferences.

I suggest that we add all portal.properties to the db on startup. This should be configurable so we don't slow down server startup for developers.

Thoughts?
thumbnail
Jorge Ferrer, modificado 16 Anos atrás.

RE: Store all portal.properties to the db and add a new table to store them

Liferay Legend Postagens: 2871 Data de Entrada: 31/08/06 Postagens Recentes
Hi Ed,

I think it's a very good idea.

We already have several of those properties that can be configured through the administration properties and I think they are stored in the portletpreferences table. But it would be great to have an advanced configuration screen that is just like about:config in Firefox which gives you access to all properties.

What I'm not sure I like is automatically copying from the file to the db all properties, because some times being able to modify the properties file and distribute the changes is useful. I would just keep the modified properties and make the code first check the db and if there is nothing there check the files.

BTW, EasyConf supports all of this transparently but I'm not sure if that's the way to do it in Liferay.
thumbnail
Jorge Ferrer, modificado 16 Anos atrás.

RE: Store all portal.properties to the db and add a new table to store them

Liferay Legend Postagens: 2871 Data de Entrada: 31/08/06 Postagens Recentes
Some extra ideas that we just talked about via IM:
  • How to solve the problem of having a lot of properties: Paginate? no it would be better to show the whole list with a scroll bar and use a Javascript based way to filter those shown (just like about:config works in Firefox)
  • It would be cool to parse the documentation in the portal.properties file and show it in the web UI.
thumbnail
Tobias Hofmann, modificado 16 Anos atrás.

RE: Store all portal.properties to the db and add a new table to store them

Junior Member Postagens: 82 Data de Entrada: 20/06/07 Postagens Recentes
Hi Jorge,

storing the configuration properties inside a DB is a really good idea. I assume you are talking about moving the properties files to the DB.

I would like to see also the following being considered/implemented:

1. A separate Configuration DB/table. This would allow us to use 1 central DB/table for storing the information. Several Liferay systems could read this information. I only would have to change the information one time in one place to get it distributed to several systems.
2. Tag the tables, so Testing, DEV, QA and (pre-)productive systems can use different tables from the DB. Ths would allow to have only one DB, but populated with different configuration information for each landscape.
3. Versioning of the data. After changing a value it should be easy to undo the change (like, change to version 1.1 and than back to 1.0 again)
4. Despite one configuration for all systems in a landscape, allow also to define for each system a separated, and isolated configuration.

What do you think? For me, right now, maintaining the configuration across landscapes is more work than I like to have. This would also allow to get Liferay more "ITIL ready" in terms of Release/Change Management.

br,
Tobias
thumbnail
Jorge Ferrer, modificado 16 Anos atrás.

RE: Store all portal.properties to the db and add a new table to store them

Liferay Legend Postagens: 2871 Data de Entrada: 31/08/06 Postagens Recentes
Hi Tobias,

Tobias Hofmann:

storing the configuration properties inside a DB is a really good idea. I assume you are talking about moving the properties files to the DB.


I also think it's a very good idea. What I don't like that much is to have *all* property values automatically copied. I would prefer to store only modified values and read the others from the properties file. That way changes in the configuration can be applied through deployment also (if the changed props are not in the db).

Tobias Hofmann:

I would like to see also the following being considered/implemented:

1. A separate Configuration DB/table. This would allow us to use 1 central DB/table for storing the information. Several Liferay systems could read this information. I only would have to change the information one time in one place to get it distributed to several systems.


You mean besides PortletPreferences? what's wrong with that table right now?

Tobias Hofmann:

2. Tag the tables, so Testing, DEV, QA and (pre-)productive systems can use different tables from the DB. Ths would allow to have only one DB, but populated with different configuration information for each landscape.


That's a good idea. All it'd take is a new property to specify a prefix for all db tables. Different environments could have different values for that property to avoid table name collisions.

Tobias Hofmann:

3. Versioning of the data. After changing a value it should be easy to undo the change (like, change to version 1.1 and than back to 1.0 again)


Would you do that for *every* Liferay table? I'm in favor with any change to allow undo, but I see several drawbacks with that method, from complexity to lots of extra needs for space.

Anyway, I may be wrong and just need to see it working to realize it's a good idea. Do you have a working example of something like this?

Tobias Hofmann:

4. Despite one configuration for all systems in a landscape, allow also to define for each system a separated, and isolated configuration.

What do you think? For me, right now, maintaining the configuration across landscapes is more work than I like to have.


Have you taken a look at this: http://easyconf.sourceforge.net/user/properties/multienvironments.html. It may be helpful for you. Liferay is using EasyConf so you can use its features for free.

Tobias Hofmann:

This would also allow to get Liferay more "ITIL ready" in terms of Release/Change Management.


Sorry for my ignorance, What's "ITIL"?
thumbnail
Björn Ryding, modificado 16 Anos atrás.

RE: Store all portal.properties to the db and add a new table to store them

Liferay Master Postagens: 582 Data de Entrada: 16/05/07 Postagens Recentes
Jorge Ferrer:
What's "ITIL"?

http://en.wikipedia.org/wiki/ITIL
thumbnail
Tobias Hofmann, modificado 16 Anos atrás.

RE: Store all portal.properties to the db and add a new table to store them

Junior Member Postagens: 82 Data de Entrada: 20/06/07 Postagens Recentes
Jorge Ferrer:
Hi Tobias,

Tobias Hofmann:

storing the configuration properties inside a DB is a really good idea. I assume you are talking about moving the properties files to the DB.


I also think it's a very good idea. What I don't like that much is to have *all* property values automatically copied. I would prefer to store only modified values and read the others from the properties file. That way changes in the configuration can be applied through deployment also (if the changed props are not in the db).


What I do have in mind is the following:
1. Do have a fixed starting point, a more or less read-only set of configuration properties. The same way it is right now. These should be values that will never change. The values should get read from the filesystem and stored inside the DB, marked read-only. A good value could be the company name or the file storage location. But this should be changeable to customer/location demand. For a testing location it can be quite convinient to be able to change the file storage location (eg performance tests).
2. Do have a huge custimizable set of configuration parameters. The values from these should be stored inside a DB. Again, have a fixed starting point, but this time, there has to be a check, wheter inside the DB are already values defined. These DB-values should be used and the file system configuration properties discarded. Changes in the DB should be automatically be distributed "on-the-fly" to all affected systems. For example, the list of the allowed file extensions for the document library or the email server.

The properties files should only be used for an initial population of the DB. To me, it just makes more sense to use a propertie file as a template, as a suggestion of values that I can later easily adopt to my needs.

Jorge Ferrer:

Tobias Hofmann:

I would like to see also the following being considered/implemented:

1. A separate Configuration DB/table. This would allow us to use 1 central DB/table for storing the information. Several Liferay systems could read this information. I only would have to change the information one time in one place to get it distributed to several systems.


You mean besides PortletPreferences? what's wrong with that table right now?


PortletPreferences is fine for Portlets, but I am looking for a way to configure the entire Portal, in one central place, with (hopefully) one central administration tool. This way, I have all the configuration information in one central place, the DB. It isn´t distributed over many configuration files. Sure, I can use the easyconfig-way-to-do-it, but there I do have a real mess. One big configuration file, shared for all instances over NFS/CIFS, no log, no undo, no easy forking for a new system. In a DB, I can copy the content of selected tables for the landscape Test1 (thank you SQL) into a new table tagged: Test2 and apply there 1 or 2 small changes, apply a (perhaps already existing) Liferay instance to this new table just to check if my transport will work. With easyconf, I do have to open the file, copy/paste, tag new (property-Test2-...). Restart the system, apply the startup parameter for easyconf, to point to the new Test2, etc. And I do need to have access to the filesystem and liferay startup procedure to do this.

Jorge Ferrer:

Tobias Hofmann:

3. Versioning of the data. After changing a value it should be easy to undo the change (like, change to version 1.1 and than back to 1.0 again)


Would you do that for *every* Liferay table? I'm in favor with any change to allow undo, but I see several drawbacks with that method, from complexity to lots of extra needs for space.

Anyway, I may be wrong and just need to see it working to realize it's a good idea. Do you have a working example of something like this?


Well, I would do it for every Liferay table that get´s affected from a configuration change. Like adding a new Journal Content portlet or entire page with several Journal Content portlets in Dev, Transport it to QA, there it would be nice to have an undo mechanism in QA. Of corse for the whole transport package. Or changing the E-Mail Server in Dev, I would be happy to have an undo mechanism for that change, too.

If you want to have a working example, well, the only thing I do have is how SAP is doing it with their NetWeaver product, Enterprise Portal and Solution Manager. There every configuration value is stored inside a DB (one for every landscape, so it´s not one big config-DB for all landscapes/systems), transports are managed via Solution Manager, tracked, and can be undone.

Jorge Ferrer:

Tobias Hofmann:

4. Despite one configuration for all systems in a landscape, allow also to define for each system a separated, and isolated configuration.

What do you think? For me, right now, maintaining the configuration across landscapes is more work than I like to have.


Have you taken a look at this: http://easyconf.sourceforge.net/user/properties/multienvironments.html. It may be helpful for you. Liferay is using EasyConf so you can use its features for free.


Like I said above, it´s a nice feature, but really hard to maintain. If you have to work in an environment, where you can´t access the filesystem directly (security considerations, access not possible, because you don´t have a user/ssh terminal) and have to open a call, request and ask people to do a backup of the old-file, even do a restart of the server, etc, than the file-based configuration really isn´t of any help.

br,
Tobias
thumbnail
Jorge Ferrer, modificado 16 Anos atrás.

RE: Store all portal.properties to the db and add a new table to store them

Liferay Legend Postagens: 2871 Data de Entrada: 31/08/06 Postagens Recentes
Tobias Hofmann:

The properties files should only be used for an initial population of the DB. To me, it just makes more sense to use a propertie file as a template, as a suggestion of values that I can later easily adopt to my needs.


While I understand that in some scenarios the properties file will not be used to change the configuration I don't thing that's the case for *all* scenarios. I've worked in many projects where the configuration was distributed as properties files from the developers which allowed for an automated way to deploy changes done during development.

Also, IMO copying all the values at once doesn't provide any value to those scenarios where the files are not used in this way.

So I still think that it would be a bad idea to copy all the values.

Tobias Hofmann:

PortletPreferences is fine for Portlets, but I am looking for a way to configure the entire Portal, in one central place, with (hopefully) one central administration tool.
...


Yeah, that's what I was talking about too. Take a look at the Enterprise Admin portlet, settings tab. That's the tool you are looking for, already implemented (although not as complete yet as we are talking about). The settings stored there are saved in the PortletPreferences table (although they are portal settings, not portlet preferences).
thumbnail
Björn Ryding, modificado 16 Anos atrás.

RE: Store all portal.properties to the db and add a new table to store them

Liferay Master Postagens: 582 Data de Entrada: 16/05/07 Postagens Recentes
Jorge Ferrer:
I've worked in many projects where the configuration was distributed as properties files from the developers which allowed for an automated way to deploy changes done during development.

That's how we primarily use the properties files.

Why does it not exist a setting that wipes the current portal configuration? It would be very convenient if there was a way to force the portal to use the settings you provide in the properties files.
thumbnail
Tobias Hofmann, modificado 16 Anos atrás.

RE: Store all portal.properties to the db and add a new table to store them

Junior Member Postagens: 82 Data de Entrada: 20/06/07 Postagens Recentes
Jorge Ferrer:

Tobias Hofmann:

The properties files should only be used for an initial population of the DB. To me, it just makes more sense to use a propertie file as a template, as a suggestion of values that I can later easily adopt to my needs.


While I understand that in some scenarios the properties file will not be used to change the configuration I don't thing that's the case for *all* scenarios. I've worked in many projects where the configuration was distributed as properties files from the developers which allowed for an automated way to deploy changes done during development.

Also, IMO copying all the values at once doesn't provide any value to those scenarios where the files are not used in this way.

So I still think that it would be a bad idea to copy all the values.


I don´t understand why you would have more than one repository to store configuration information. It´s a bad idea to have a file-based repository and a DB-based repository. If you store one part of the information in a file, and the other in the DB, it is hard to find out, from where the actual configuration value is coming from and you do have to check the file and the DB. This is how it is right now, and it is not really practical.

For this, I suggested to have the configuration file as a starting point. And you can define as many fixed values as you like, but if you want to change a value, the only place to go to is the DB. RIght now, I do have the file for eg. allowd file extensions for the document library and the PortletPreferences-table for created Portlets (like Navigation, Journal Content). Doing here a consolidation would be a great benefit for Liferay.

Transporting the configuration file from a developers workstation to a production system is not a good style. Honestly, the last thing I want is that a developer transports his file to a production environment (which is, btw also not possible). To reach production, normaly a developer sends a change request and adds the configuration parameters, which than go into the QA property file, than to Pre-Production and finally to Production. And the only thing that is of interest here is the parameter, but not the whole configuration file from a developers workstation.

My idea is more like an initial configuration (file), and a delta (Demoticon. And this delta DB should contain all information for one landscape (or for all landscapes. as configured/requested by the requirements).

To get this a little bit more clear, a easy, but real live example:
Say, I do have a preconfigured page, with layout, portlets and content. I want to define this page as a template for a community. To do this, I have to edit the portel-ext.properties file and insert for each column the ID of the portlet (but, unfortunately, without content).
With the DB configuration, I could make a transport of this information form DEV to QA and to PROD (btw.: defining pre-defined transport workflows would be a plus with approve/reject/hold). For doing so, I construct the page and tag this page in DEV as a transport to QA.
(well, maybe this example isn´t so easy. but i think, in another thread there is a discussion going on about creating template pages.)

Jorge Ferrer:

Tobias Hofmann:

PortletPreferences is fine for Portlets, but I am looking for a way to configure the entire Portal, in one central place, with (hopefully) one central administration tool.
...


Yeah, that's what I was talking about too. Take a look at the Enterprise Admin portlet, settings tab. That's the tool you are looking for, already implemented (although not as complete yet as we are talking about). The settings stored there are saved in the PortletPreferences table (although they are portal settings, not portlet preferences).



The Enterprise Admin portlet is a good start, but far from being a Change/Release Management driven portlet. I can configure the basics of the portal, but transport management, undos, remote administration of other liferay servers (via DB, just tag the table for a system from QA to DEV) is not possible.

Maybe you don´t think that all of my proposals are worth considering, but if I do a comparison with some "enterprise" products, Liferay has definive to catch up in sense of Management abilities (like ITIL, COBIT) and has to lose the developer view at things. This would allow Liferay to gain momentum in the Enterprise.

I hope some proposals will get considered in one of future releases of Liferay.
br,
Tobias
thumbnail
Jorge Ferrer, modificado 16 Anos atrás.

RE: Store all portal.properties to the db and add a new table to store them

Liferay Legend Postagens: 2871 Data de Entrada: 31/08/06 Postagens Recentes
Hi Tobias,

Tobias Hofmann:

...
Maybe you don´t think that all of my proposals are worth considering, but if I do a comparison with some "enterprise" products, Liferay has definive to catch up in sense of Management abilities (like ITIL, COBIT) and has to lose the developer view at things. This would allow Liferay to gain momentum in the Enterprise.


Of course your proposals are worth considering. I really appreciate you sharing your experience with us in the forums. I always learn from reading from people which experience in large deployments.

We definitely want to improve, and will improve, Liferay Portal to make it a better product in terms of management abilities. We just have to find a way that keeps things simple and everybody happy. That's why this discussions are so useful.

I admit that in this case I'm still not fully convinced of what's the best way to proceed in this case, but your comments got me thinking. So I'll keep all of this in mind for future improvements. Please, keep your comments and suggestions coming.
thumbnail
Tobias Hofmann, modificado 16 Anos atrás.

RE: Store all portal.properties to the db and add a new table to store them

Junior Member Postagens: 82 Data de Entrada: 20/06/07 Postagens Recentes
Jorge Ferrer:
Hi Tobias,

We definitely want to improve, and will improve, Liferay Portal to make it a better product in terms of management abilities. We just have to find a way that keeps things simple and everybody happy. That's why this discussions are so useful.

I admit that in this case I'm still not fully convinced of what's the best way to proceed in this case, but your comments got me thinking. So I'll keep all of this in mind for future improvements. Please, keep your comments and suggestions coming.


Well, if I got you thinking ... let´s continue.
In my experience, Liferay is mainly placed against Typo and SharePoint. Typo for the Web 2.0 and web pages publishing, SharePoint as a collaboration platform. When it comes to the decision to implement one of the 3 potential platforms, normaly SharePoint is the biggest competitor, Liferay can win over Typo quite easy (PHP vs. Java, portability, security, etc). It often happens that end-users just don´t have anything to say. The (non-IT) CIO, CTO and the consulting guy from the VC company define what will be used and what not. For this decision, they use a checklist, and one of the biggest weighted points there is Compliance (btw, a definition that really depends on you view).

SharePoint does have a central DB Instance for the configuration, it is integrated with the Operations Manager and does have AD integration out of the box. Some of these things does Liferay also provide, but a Change/Release Management compliant tool isn´t provided (MS does have OM, SAP Solution Manager, Oracle Enterprise Admin). That´s where SharePoint makes the race and Liferay simply not.

And to be honest, I´m surprised that Liferay doesn´t provide these tools. When I read the blogs, there are news that the people from Liferay are going to Germany, consulting on a fincancial portal for a bank. The SoX-Act doesn´t affect a German based companies directly, but there is the IDW and Basel II. So, compliance in the sense of SoX is also a really big issue. But Liferay isn´t providing great help in achieving compliance. But, especially when there is financial information involved, you do have to track it, when was it published by whom, etc. I can´t believe that the german people do every transport, change and release by hand. But they do have to keep track via Excel of every single change and go through the complete process step by step. A big win here for Liferay will be to have a central storage of the configuration data inside a DB, central distribution of that data to the landscapes and the ability to define a fixed workflow for the transportation (1. DEV, 2. QA, 3. PROD) that is obrigatory for every change.

It´s nice that Liferay gets more and more Web 2.0 (eg Blog) functionality, but in the maiority of companies using these technology is not allowed. It is too dangerous that someone publishes internal information without going through an official release and Corporate Identity process.
People are willing to use/by SharePoint (Server), buy the Content Management Server, Operations Management Server, SQL Server and so on just to achieve Compliance (or what they believe is compliance). If you go to these people (mainly SME) and tell them:
I do have a great product, the configuration is splitted into filesystem and DB, the transport is via copying on the filesystem level, but you can you easyconfig to tag the landscapes and put everything in one file (which, btw, is definitiv versus compliance) and doing a transport of one portlet (say, CMS with financial information for the public audience) results in the export/import of the whole page, maybe database copy, ... well, they won´t use Liferay. That´s not while the product isn´t usable, it´s just they fear their VC, the competition, the law, etc.

br,
Tobias
thumbnail
Jorge Ferrer, modificado 16 Anos atrás.

RE: Store all portal.properties to the db and add a new table to store them

Liferay Legend Postagens: 2871 Data de Entrada: 31/08/06 Postagens Recentes
Hi Tobias,

Thanks a lot for all the information. Do you have some links to articles and documents about all of this that I and other Liferay developers could read?
thumbnail
Tobias Hofmann, modificado 16 Anos atrás.

RE: Store all portal.properties to the db and add a new table to store them

Junior Member Postagens: 82 Data de Entrada: 20/06/07 Postagens Recentes
Jorge Ferrer:
Hi Tobias,

Thanks a lot for all the information. Do you have some links to articles and documents about all of this that I and other Liferay developers could read?


Hi Jorge,
as stated before, Compliance is a definition that really depends on how you interprete it. You can achive compliance using Office and a simple file server. But this compliance won´t stand up in a real audit. That´s why many decision maker choose a software that is sold as "compliance" ready.
Comliance is mainly about financial information, so you are not affected for creating an internal portal that´s not related to any business operation. You are affected, when this internal portal is desinged to gather information from employees about violated internal rules related to a SOx topic (in this case, it is business relevant information that is communicated).

Here are some general informations about compliance (mainly wikipedia). Nothing technical, only the business perspective is covered:

SoX
http://en.wikipedia.org/wiki/Sarbanes-Oxley_Act

Specially: SOX 404 and information technology

COSO
http://en.wikipedia.org/wiki/COSO
COSO Enterprise Risk Management Framework

ITGC
http://en.wikipedia.org/wiki/Information_technology_audit
Management of IT and Enterprise Architecture: An audit to verify that IT management has developed an organizational structure and procedures to ensure a controlled and efficient environment for information processing.

Information technology audit
http://en.wikipedia.org/wiki/Information_technology_audit_-_operations
http://en.wikipedia.org/wiki/Information_technology_controls
http://en.wikipedia.org/wiki/Change_management_auditing


Basel II
http://en.wikipedia.org/wiki/Basel_accord

SAP information about transcations and tracking:
SAP SolMan http://help.sap.com/saphelp_sm40/helpdata/en/45/51fbdbd4941803e10000000a1553f7/frameset.htm
SAP CTS http://help.sap.com/saphelp_sm40/helpdata/en/14/94fc3f8fc2c542e10000000a1550b0/frameset.htm

The following Whitepapers are in german, sorry. But some paragraphs are in english and some of the literature is english, too. Maybe it will help.

[german] http://www.ie.iwi.unibe.ch/publikationen/berichte/resource/WP-190.pdf
[german] http://www.ie.iwi.unibe.ch/publikationen/berichte/resource/WP-179.pdf

Short: the relevant thing that needs to adressed is Change and Release Management (ITIL or COBIT). And this is exactly where Liferay needs improvement. It´s hard to integrate into a CM/RM process mainly because transportation of portlets/content/configuration is a lot of manual work.

br,
Tobias
thumbnail
Björn Ryding, modificado 16 Anos atrás.

RE: Store all portal.properties to the db and add a new table to store them

Liferay Master Postagens: 582 Data de Entrada: 16/05/07 Postagens Recentes
Tobias Hofmann:
I don´t understand why you would have more than one repository to store configuration information. It´s a bad idea to have a file-based repository and a DB-based repository. If you store one part of the information in a file, and the other in the DB, it is hard to find out, from where the actual configuration value is coming from and you do have to check the file and the DB. This is how it is right now, and it is not really practical.

Agreed!

Tobias Hofmann:
Transporting the configuration file from a developers workstation to a production system is not a good style. Honestly, the last thing I want is that a developer transports his file to a production environment (which is, btw also not possible). To reach production, normaly a developer sends a change request and adds the configuration parameters, which than go into the QA property file, than to Pre-Production and finally to Production. And the only thing that is of interest here is the parameter, but not the whole configuration file from a developers workstation.

I do not think that this was the scenario Jorge was thinking of, it was sure not the scenario I was thinking of in my previous post.

Tobias Hofmann:
My idea is more like an initial configuration (file), and a delta (Demoticon. And this delta DB should contain all information for one landscape (or for all landscapes. as configured/requested by the requirements).

...

The Enterprise Admin portlet is a good start, but far from being a Change/Release Management driven portlet. I can configure the basics of the portal, but transport management, undos, remote administration of other liferay servers (via DB, just tag the table for a system from QA to DEV) is not possible.

Maybe you don´t think that all of my proposals are worth considering, but if I do a comparison with some "enterprise" products, Liferay has definive to catch up in sense of Management abilities (like ITIL, COBIT) and has to lose the developer view at things. This would allow Liferay to gain momentum in the Enterprise.

I hope some proposals will get considered in one of future releases of Liferay.


I agree that Liferay should do more within this area. However, if the ONLY thing you change is to automatically load all the properties into the database you lose a lot from a developer perspective, without gaining much.
thumbnail
Tobias Hofmann, modificado 16 Anos atrás.

RE: Store all portal.properties to the db and add a new table to store them

Junior Member Postagens: 82 Data de Entrada: 20/06/07 Postagens Recentes
Björn Ryding:
I do not think that this was the scenario Jorge was thinking of, it was sure not the scenario I was thinking of in my previous post.


I believe you and Jorge are thinking in a developer scenario, while I am thinking and seeing things as a change and release manager.

...

Björn Ryding:

I agree that Liferay should do more within this area. However, if the ONLY thing you change is to automatically load all the properties into the database you lose a lot from a developer perspective, without gaining much.


Sure you lose a lot, but once the data is inside the DB, you can start develop the changes. Getting the configuration data inside the DB is only the first step in a long series of steps to develop a superior administration tool.

br,
Tobias
thumbnail
Björn Ryding, modificado 16 Anos atrás.

RE: Store all portal.properties to the db and add a new table to store them

Liferay Master Postagens: 582 Data de Entrada: 16/05/07 Postagens Recentes
Tobias Hofmann:
Björn Ryding:

I do not think that this was the scenario Jorge was thinking of, it was sure not the scenario I was thinking of in my previous post.

I believe you and Jorge are thinking in a developer scenario, while I am thinking and seeing things as a change and release manager.

I believe so too, that is why I made the comment.

Tobias Hofmann:
Björn Ryding:

I agree that Liferay should do more within this area. However, if the ONLY thing you change is to automatically load all the properties into the database you lose a lot from a developer perspective, without gaining much.


Sure you lose a lot, but once the data is inside the DB, you can start develop the changes. Getting the configuration data inside the DB is only the first step in a long series of steps to develop a superior administration tool.

I agree with you, that is why I emphasized the word only.

However, EasyConf is quite flexible and we have our properties files in SVN under version control. If Liferay were to automatically load all the properties into the database, our current solution would lose much of its power.
thumbnail
Florencia Gadea, modificado 11 Anos atrás.

RE: Store all portal.properties to the db and add a new table to store them

Regular Member Postagens: 146 Data de Entrada: 27/03/12 Postagens Recentes
Hi Ed,

I know this is an old post, but, did this project ever happen?

Regards,

Flor.
thumbnail
Hitoshi Ozawa, modificado 11 Anos atrás.

RE: Store all portal.properties to the db and add a new table to store them

Liferay Legend Postagens: 7942 Data de Entrada: 24/03/10 Postagens Recentes
In the recent version of liferay, most of the properties can be set from pages in the Control Panel. Settings such as database settings which are required before starting the portal should be set in the configuration file.
Most of settings in the portal.properties are now treated as "default" settings to be overwritten from pages in the Control Panel.
thumbnail
Florencia Gadea, modificado 11 Anos atrás.

RE: Store all portal.properties to the db and add a new table to store them

Regular Member Postagens: 146 Data de Entrada: 27/03/12 Postagens Recentes
Ok, thanks.