@angelborroy : For the love of whatever you hold dear, please do not recommend the use of SearchService.LANGUAGE_LUCENE - especially not in this case. The Lucene search language is not receiving any active support / enhancements, and according to my discussions with (other) Alfresco engineers at conferences is only still included for some low-level test scenarios. Also, this kind of lookup relies on the index, which may not be available / accessible all the time, e.g. during system bootstrap.
Also, app:company_home is not guaranteed to be the proper path - that child name can actually be changed via alfresco-global.properties (only in the initial start / bootstrap though).
The ideal way to resolve any node for which you know the path (or can inject it using Spring from configuration properties) is by using the SearchService selectNodes operation. This performs an XPath lookup using the NodeService in the background, and is always transactionally consistent (as long as you don't use two very specific, very niche selector conditions which do use Lucene in the background). This is best suited for any kind of unique path lookups based on qualified child names, where the FileFolderService might not work. Its use looks something like this (the query in this case is the "/app:company_home" xpath condition from the Lucene example).
@brijeshnk : The service registry, like any configuration value or service reference you may wan to use in a job, typically needs to be provided as part of the job data map. You can see an example of this in Alfresco's DownloadCleanupJob. The values in that map are set up in Spring like this.