The embedded GF-integration uses the bindHttpPort
property in arquillian.xml to set the listener port for embedded GlassFish; the setPort
API method is used to this extent.
According to the embedded GlassFish Server Guide, the setPort
method must not be used in conjunction with the setInstanceRoot
and setConfigFileURI
API method calls.
We must conditionally invoke setPort
in such a scenario. Nevertheless, we'll require the user to provide the listener port in the bindHttPort
property of arquillian.xml. This will not be used to bind the embedded GF instance to the specified port; instead, it should match the listener port number in domain.xml. Embedded GF will use the value in domain.xml to bind itself to the port, and Arquillian would use the matching value in arquillian.xml to connect to the embedded instance at the correct port.
The current design could be improved in a few places:
- Listener ports for a server, are read from the system properties like
HTTP_LISTENER_PORT
andHTTP_SSL_LISTENER_PORT
for the server. This need not be the case for all listeners. We should get the actual ports by reading the network listener configuration at/configs/config/{config}/network-config/network-listeners/network-listener/{listener}
. Only when a system property is referenced, should we read the corresponding system property. - The "default" port for a server is obtained by reading the
HTTP_LISTENER_PORT
/HTTP_SSL_LISTENER_PORT
system properties from/configs/config/{config}/system-property/{http-listener}
where{http-listener}
is eitherHTTP_LISTENER_PORT
orHTTP_SSL_LISTENER_PORT
and{config}
is the configuration element for the standalone server or the cluster. This is followed by reading theHTTP_LISTENER_PORT
/HTTP_SSL_LISTENER_PORT
properties from/servers/server/{server}/system-property/{http-listener}
, where{server}
is name of the server instance. This is because a system property defined globally in a configuration, can be overridden in a server instance; a network listener's port may reference a global system property which may be overridden at the level of a server. If the second system property overrides the first (the default), then it will be used. As stated in the above point, listeners need not have system properties to define the port numbers, and they should be read only when they are referenced in the listener configuration.
We could incorporate the logic pertaining to system properties and while reading the port numbers in the following manner:
- Obtain the list of all virtual servers in the target - the DAS, a standalone instance or a cluster. The
__asadmin
virtual server will be omitted, as it does not host any deployments. In all the three cases, especially in the cases of clusters, a virtual server defined in the configuration will be present in all the GlassFish instances. - Obtain the list of all network listeners for all the virtual servers obtained in the previous step.
- Iterate through all the network listeners and read the port numbers associated with the listener. If the port number is not represented as a number, but as a system property i.e. the value is
${sys-property}
, then we'll read the value of the propertysys-property
for that GlassFish instance (possibly later, when we construct theNodeAddress
instance). To verify HTTP/HTTPS support, we'll read the associated protocol as well, and verify it's securityEnabled property. - For now, the first enabled HTTP and HTTPS network listeners will be used to construct the
NodeAddress
instance. We may consider using all network listeners found, to create separateNodeAddress
instances. - To construct the
NodeAddress
instances, we'll fetch all the GlassFish instances for the target. If the target is the DAS or a standalone instance, only oneNodeAddress
instances will be constructed. For a cluster, all running GlassFish instances in the cluster will have correspondingNodeAddress
instances. Thehost
attribute of theNodeAddress
instance will contain the hostname where the corresponding GlassFish instance resides. The HTTP and HTTPS port numbers obtained from the previous step will be used to populate the port information. If the port numbers were obtained as system properties, we'll resolve these now, as the values are context-sensitive (a property defined in a cluster config, may be overridden by a cluster member).