Get the domain Payara is running under

[Ulrich Mayring]

Hi all,

how can I find out the FQDN my Payara is serving from within my Java app? The use case is that I want to send a confirmation email to new users, when they register for an account. So that email needs to contain a specific link to my app. I would like to build this link generically, i. e. like so: "https://" + PayaraFQDN + "/myapp/account/confirmation/" + token. That way my app could be installed anywhere. BTW, I don't have a servlet or JSF pages, my frontend ist HTML5 (external to Payara) and it just calls REST endpoints on Payara.

I've entertained various thoughts on how to get that PayaraFQDN, but none really convincing. For example, I could inject a @UriInfo into my REST endpoint and then transport this parameter through several layers of business logic - not elegant. I could also create a custom JNDI resource and configure it with the FQDN when setting up Payara - but that seems pretty overkill for a simple key/value parameter.

Ulrich

[Mike Croft]

Payara Server 173 supports the MicroProfile Config API, which allows you to set properties in one of several places:

• System properties
• Environment variables
• A META-INF/microprofile-config.properties file

In Payara Server, you can also set properties in several additional sources: domain, config, server, application, module and cluster. It will even pick up any JNDI custom resources you create.

For all these extra sources (except JNDI) you can use asadmin commands to set properties. In your case, you will want your FQDN property to be unique for each server since each server might be on a different host. To achieve this, you could run the following asadmin commands:

asadmin set-config-property --propertyName=myapp.FQDN --propertyValue=host.domain --source=server --sourceName=server1

From the Config repository examples, you can use this property in your code like this:

@Inject

@ConfigProperty(name="myapp.FQDN", defaultValue="UNKNOWN")

private String FQDN;

[Ulrich Mayring]

Hi Mike,

this is exactly what I was looking for, many thanks!

Ulrich

[Ulrich Mayring]

But I guess I have to include a library like https://github.com/eclipse/microprofile-config to used that @ConfigProperty annotation? The only one available in Java EE is javax.resource.spi.ConfigProperty and that has no "name" property.

Ulrich

[Mike Croft]

The implementation is already in Payara Server 173, but you will need to include the API as a provided dependency. You can either explicitly add the Config API:

https://search.maven.org/#artifactdetails%7Corg.eclipse.microprofile.config%7Cmicroprofile-config-api%7C1.0%7Cjar

<dependency>     <groupId>org.eclipse.microprofile.config</groupId>     <artifactId>microprofile-config-api</artifactId>     <version>1.0</version> </dependency>

Or add the MicroProfile 1.1 spec as a dependency. I'm not sure that the 1.1 spec has been published to Maven Central yet. For the 1.1 version, there is only the Config API available above what is already there in the Java EE dependency, so that would be fine.

[Ulrich Mayring]

Yep, thanks a lot, that help. Could you elaborate on the options to the asadmin command, I didn't find any docs for those except that:

     Usage: set-config-property --source=domain [--target=server]
      --propertyname=propertyname --propertyvalue=propertyvalue [
     --sourcename=sourcename] [--modulename=modulename]

But what do all those options mean? I have tried to use the command you gave as an example, but am not sure what I should put in the place of "server" and "server1". Using it as-is has not worked, i. e. at the injection point I am getting nothing (or rather the default value of "UNKNOWN").

Also, is there a place in the admin gui, where I can see those properties? There's a section called "Configuration Properties" under my application, is that where the property is supposed to end up?

Many thanks in advance for your help,

Ulrich

[Mike Croft]

The documentation has been delayed slightly for 173, so it's not yet available. I did push the documentation for this feature out early, though, so you can see more information here:
https://docs.payara.fish/documentation/microprofile/config.html

The key part is the table below:

Option	Description	Default	Mandatory
propertyName	The name of the configuration property to set	-	yes
propertyValue	The value of the configuration property to set	-	yes
source	The ConfigSource where the property is to be stored	-	yes
sourceName	The name of the ConfigSource when there may be ambiguity, for example a ConfigSource of type application must specify the name of the application. This property is required for sources of type: config, server, application or module	-	no
moduleName	The name of the module when the ConfigSource is of type module. When this is specified, the sourceName parameter must be provided and must have the name of the application where the module is deployed.	-	no
target	The target configuration where the command should be run	server (the DAS)	no

So, as an example, if you have a source of type "config" (meaning the Payara Server config) you would also need a "sourceName" property so that Payara Server knows which config to use, like "server-config", "cluster-config" or similar. The property "moduleName" is also needed when you have a source of type "module" because you will need to name the application as a sourceName and then specify the module within it separately.

[Ulrich Mayring]

Ok, let's see if I get this:

The "source" is in my case always "server", because we would expect that a FQDN could differ between two servers. Although if if I have just one server, I could also put "domain" there.

The "sourceName" would be the name of the config within "server", where this parameter should be set. So in the case of a fresh Payara installation this could either be "server-config" or "default-config".

Ulrich

[Steve Millidge]

The various sources where configuration properties can be defined are;

domain - The configuration value will be available to all servers in the domain

config - The configuration value will be available to all servers that use the specified config

server - The configuration value will be available to the named server only

application - The configuration value will be available to the named deployed application

module - The configuration value will be available to the specific module within the specified application e.g. war in an ear

cluster - The configuration value will be available to all servers that are members of the Hazelcast cluster 

Currently in the admin console you can view domain, server, application configuration properties.

[Ulrich Mayring]

I'm sorry to report that I don't get this thing to work. Here's the command I executed:

{{ ASADMIN_CMD }} set-config-property --propertyName=FQDN --propertyValue=www.mydomain.com --source=server --sourceName=server-config

And this is my code:

@Inject
@ConfigProperty(name="FQDN", defaultValue="UNKNOWN")
private String FQDN;

However, the value is always "UNKNOWN".

What's more, after a while the EJB Timer Service breaks ("Table/View 'EJB__TIMER__TBL' does not exist") and I cannot deploy my application anymore.

Are there any other ways to get a configuration parameter into Payara? Perhaps deploy a System Property via asadmin?

Kind regards,

Ulrich

[Ondrej Mihályi]

Hi Ulrich,

You need to use --source=domain, without --sourceName to set a config property for all applications in the domain or if you deploy applications to the DAS.

The option --source=server works only for separate server instances (either standalone or cluster instances) and --sourceName doesn't accept configuration name but the name of the instance. This type of config source would work for you if you create and run a separate stanalone instance and deploy your application to it instead of deploying to the DAS. We should probably make it more explicit in the documentation, maybe even rename --source=server to --source=instance. I also found out that --source=server doesn't fail even if the instance with the named defined by --sourceName doesn't exist and the configuration value isn't saved.

I hope that helps,

Ondro

--
You received this message because you are subscribed to the Google Groups "Payara Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to payara-forum+unsubscribe@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/payara-forum/721db114-f45a-41d1-9b2e-8210460de900%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Ulrich Mayring]

Hi Ondro,

many thanks for your help. I've tried a number of combinations of parameters and code, but ultimately wasn't successful. I've then tried to set a System Property via asadmin and that worked right away. I could even see the System Property in the DAS console. So I'm now sticking with the System Property scheme, I believe the microprofile configuration API needs some more work to mature. If it were impossible to set a non-working combination of parameters, then that would make it a lot easier to use.

Ulrich

[Ondrej Mihályi]

Hi Ulrich,

I'm glad you were able to find a solution. 

Setting a config value as a system property certainly works too. But, although not yet documented, you can also view and edit configuration values for source "domain" in the new "Configuration tab" in the domain configuration. You just need to prefix properties added there with "payara.microprofile" as described in the description in the page.

I'm adding a screenshot of the Admin Console page and of a terminal window with asadmin commands to set and get the configuration value:

Ondro

--

You received this message because you are subscribed to the Google Groups "Payara Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to payara-forum+unsubscribe@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/payara-forum/7cbeb70b-b71f-4931-9c6c-e93e02f58fb9%40googlegroups.com.