grails/konfiguracja zewnętrzna/grails.config.locations - plik ścieżki absolutnej "Nie istnieje"?

Question

Próbuję użyć wbudowanego mechanizmu Grails do ładowania zewnętrznych plików konfiguracyjnych (* .groovy i * .properties) poza wdrożonym plikiem WAR. Dokumentacja sugeruje, że jest to tylko przypadek ustawienia grails.config.locations z odpowiednimi ścieżkami classpath: lub file:.

mam skonfigurowane Config.groovy z:

String externalConfigLocation = System.getProperty("SYSTEM_PROPERTY_KEY") 
if (!grails.config.locations || !(grails.config.locations instanceof List)) { 
    grails.config.locations = []  
} 
if (classpathExternalConfigLocation) { 
    String pathToResource = "\"file:${basedir}" + File.separator + externalConfigLocation+"\"" 

    print "Loading external configuration file: ${pathToResource}\n" 
    grails.config.locations << pathToResource 
} 

Jednak nie pracował, komunikaty o błędach wskazujących plik „nie istnieje”. Jednak drukowanie bezwzględnej ścieżki zapisanej w grails.config.locations wskazuje, że tak. Próbowałem kilka kombinacji:

• classpath:configurationFile.properties
• file:c:\path_to_file\configurationFile.properties
• c:\path_to_file\configurationFile.properties

ale we wszystkich tych przypadkach plik nie można znaleźć.

Bardzo dziwne - radzę docenić. Lub sugestie dotyczące debugowania.

Answer 1

To co zwykle zrobić:

grails.config.locations = ["classpath:${appName}-config.groovy", 
          "file:./${appName}-config.groovy"] 
if (System.properties["${appName}.config.location"]) { 
    grails.config.locations << "file:" + System.properties["${appName}.config.location"] 
} 

To pozwala mi umieścić plik w katalogu głównym projektu, aby dostosować właściwości lokalnie przy opracowywaniu (przy użyciu pliku: location) i pliku w ścieżce klasy serwera po wdrożeniu jako wojna. Katalog lib Tomcat znajduje się w jego ścieżce klas, więc to dobre miejsce na umieszczanie plików, jeśli używasz Tomcat. Umieszczając nazwę aplikacji w pliku, możesz mieć wiele plików konfiguracyjnych bez wzajemnego narzucania się.

Pamiętaj, aby dodać lokalny plik konfiguracyjny do svn: ignore lub .gitignore, aby nie sprawdzać go w elemencie sterującym źródłami. Każdy programista może wtedy mieć własne ustawienia (lub po prostu użyć wartości domyślnych) bez wpływu na pozostałe.

To świetny sposób na eksternalizację haseł do baz danych i innych wartości produkcyjnych. Aplikator aplikacji (najlepiej nie programista) zarządza plikiem i jego zawartością, dzięki czemu unika się sprawdzania haseł w kontroli kodu źródłowego. Znacznie lepiej niż przy użyciu JNDI IMO.

Answer 2

nie sądzę masz base.dir gdy uruchomiony wojny