A DeployableContainer implementation that connects to a remote GlassFish 3.1 instance and deploys the test archive using the admin REST api.
Container Injection Support Matrix
|@EJB||@EJB (no-interface)||@Inject (CDI)||@Inject (MC)||@PersistenceContext||@PersistenceUnit|
Default Protocol: Servlet 3.0
Container Configuration Options
| adminPort or
|int||4848||The administrative port the client should connect to.|
| adminHost or
|String||localhost||Glassfish Admin Server (DAS) host address.|
| adminHttps or
|boolean||false||Use SSL for communicating with the admin server.|
|remoteServerHttpPort (deprecated)||int||8080||The HTTP port of the remote server.|
|adminUser||String||The name of the admin user of your DAS. If omitted, no authentication will be used to access the DAS. This case you must have empty password for your admin user.|
|adminPassword||String||The password of the admin user of your DAS. Canot be omitted if you declare the admin user. If no authentication will be used to access the DAS you must have empty password for your admin user.|
|| Specifies the target to which you are deploying. We use the “target” as property key with the same semantics as the standard GlassFish utilities do.
- server: Deploys the component to the default Admin Server instance (on your DAS server). It is not a recommended practice to use the DAS as test instance.
- instance_name: Deploys the component to the specified stand-alone sever instance, which may be on the same hosts or can be on a different one as the DAS server.
- cluster_name: Deploys the component to every server instance in the cluster. They can be on the same or on several other hosts as the DAS server. Note: Arquillion use only one instance to run the test case, trying to find a running instance if any.
Note: The domain name as a target (which is valid for GlasFish) is not a reasonable deployment scenario in case of testing.
The HOST address and port numbers of the test server instance used by Arquillian (determined by the target property) been retrieved automatically from the DAS server. You have to make them accessible for your test environment (consider any firewall or proxy configuration).
|libraries||String||A comma-separated list of library JAR files. Specify the library JAR files by their relative or absolute paths. Specify relative paths relative to domain-dir/lib/applibs. The libraries are made available to the application in the order specified. For more detail, please refer to GlassFish Server 3.1 Administration Guide.|
|properties||String|| Optional keyword-value pairs that specify additional properties for the deployment. The available properties are determined by the implementation of the component that is being deployed. For
more detail, please refer to GlassFish Server 3.1 Administration Guide.
|type||String||The packaging archive type of the component that is being deployed. Only valid value is: osgi meaning that the component is packagedas an OSGi Alliance bundle. The type option is optional. If the component is packaged as a regular archive, omit this option. For more detail, please refer to "OSGi Application Development using GlassFish Server"|
The contextroot that will be used to run the tests is retrieved automatically from the DAS server. If you do not have sun-web.xml or glassfish-web.xml file in your web application, the GlassFish will use the name of your deployment without the extension as contextroot. The same rule is applied for enterprise applications if you do not have application.xml file. The jar test-deployments are treated as a web application. In case of OSGi Alliance bundle, use the “Web-ContextPath” metadata in the META-INF/MANIFEST.MF to specify the context root.
You can use the above standard GlassFish xml files as normal to declare your contextroot to be applied. For more detail, please refer to GlassFish Server 3.1 Administration Guide. You should consider the above to avoid any conflict with your already deployed web or enterprise applications in your administrative domain.
Example of Maven profile setup