Expand my Community achievements bar.

SOLVED

how to read from sling.properties

Avatar

Level 6

As per my requirement, I need to read some values from properties file when CQ starts. I'm thinking for a solution where I can update crx-quickstart\conf\sling.properties which will have values depending on my environment and then when CQ will start then it should read value from this properties file and then I can read from OSGI service. Any advice on how to read from sling.properties file?

Another solution that I'm thinking to create OSGI service which will read from some.properties under c:/somefolder/myprop.properties and then I use @Reference.

Please let me know which approach is better.

1 Accepted Solution

Avatar

Correct answer by
Level 8

As someone else was pointing out making these values OSGI service configurations would be a more scalable solution in the long run. You can combine this with the use of run mode specific configurations in the repository in order to do environment specific configurations as well. 

So for example you could use the following run modes:

  1. dev
  2. qa
  3. perftest
  4. prod

To distinguish between environments. This means adding the appropriate run mode to the start script in on each instance (so instead run mode being author you would make it author,dev for example). 

Then you would actually have multiple configuration directories in you repository:

  1. /apps/myapp/config.dev
  2. /apps/myapp/config.author.dev
  3. /apps/myapp/config.qa
  4. /apps/myapp/config.author.qa
  5. etc.

See http://dev.day.com/docs/en/cq/current/deploying/configuring_osgi.html#OSGi Configuration in the Repository for details on this approach. 

View solution in original post

5 Replies

Avatar

Former Community Member
IHi The approach to create a service fr this is better. That way it would become independent frm the underlying cq directory As it will just be a java file which will read a file which sits in say resources which will be compiled as a bundle Othrwise fr the othr approach you will have to take care in keeping that file at that particular place for every environment and every cq instance

Avatar

Former Community Member
IHi The approach to create a service fr this is better. That way it would become independent frm the underlying cq directory As it will just be a java file which will read a file which sits in say resources which will be compiled as a bundle Othrwise fr the othr approach you will have to take care in keeping that file at that particular place for every environment and every cq instance

Avatar

Correct answer by
Level 8

As someone else was pointing out making these values OSGI service configurations would be a more scalable solution in the long run. You can combine this with the use of run mode specific configurations in the repository in order to do environment specific configurations as well. 

So for example you could use the following run modes:

  1. dev
  2. qa
  3. perftest
  4. prod

To distinguish between environments. This means adding the appropriate run mode to the start script in on each instance (so instead run mode being author you would make it author,dev for example). 

Then you would actually have multiple configuration directories in you repository:

  1. /apps/myapp/config.dev
  2. /apps/myapp/config.author.dev
  3. /apps/myapp/config.qa
  4. /apps/myapp/config.author.qa
  5. etc.

See http://dev.day.com/docs/en/cq/current/deploying/configuring_osgi.html#OSGi Configuration in the Repository for details on this approach. 

Avatar

Employee Advisor

A short google search (search terms "AEM configure OSGI") show me this as a first hit:

Configuring OSGi

Jörg