Open Brian-z opened 7 years ago
The properties in application.properties are available, IIRC, via Spring's Environment API. So within the Spring Boot application, it's straightforward to get the properties.
The next issue is how to send those in a call to MarkLogic. A common approach is to stuff them into HTTP headers, and then access those in code in MarkLogic via xdmp:get-request-header.
Hi rjrudin, thanks for the guidance, but Im not sure I understand / expressed my issue properly.
The Spring side of things is fine, I can access those variables. (WebApp configuration)
the Mark Logic Resource of things does not have access to those variables. (Mark Logic Endpoint Configuration)
when I run ./gradlew build, everything works fine, the webapp is built with all the approproate environment variables.
When I run ./mlgradle mldeploy,
I am starting to investigate the ability to have Gradle rewrite the part of the endpoint where the credentials are issued, using the appropriate application.properties file, but am not sure if this is possible/preferable and havent had a chance to dig in yet today.
I'm not quite following - at runtime, do you want the xqy endpoint to know the username/password so they can e.g. make xdmp:http-post calls?
Or is this a matter of controlling what username/password are used for deploying the xqy endpoints?
The first one, at runtime I want the xqy endpoint to know the usr/pass so they can make xdmp:http-post calls.
I think the rewriter strategy may work but haven't had a chance to test it yet. My idea is to replace the piece of the xdmp:http-post()
call that references the username and password with something like !!USERNAME!!
and !!PASSWORD!!
Then, from the gradle script, during gradlew build
I can have the gradle script open the XQY file, do a REGEX search for the !! values, write the lines to include the mlusername mlpassword variables, do the build, and then rewrite the values back to the !! !!
structure
I will let you know if I get the time to test it and how it goes. I've been busy with some other challenges and may get to this over the weekend
You could always write a custom task that mlPostDeploy depends on where you use the /v1/eval endpoint of a REST API server - can use port 8000 and connect to your modules database - to fiddle with the contents of any module in your modules database.
Another approach I've used is to have a configuration document, perhaps in your content database, that defines values for connecting to external systems.
Hi All,
I created a resource at src/main/ml-modules/ext/resource.xqy.
This resource requires a dynamic setting, depending on which environment I am deploying to. Is there a way to read the application.properties file, and leverage those variables within the xquery resource so that I can properly automate deployments across environments etc?
For instance, I would like to be able to read the mlHost and mlRestPort variables from the application.properties file, at deployment time.