VineetReynolds

1. Configuration XMLs are to be specified using URIs (file:...). Glassfish verifies whether the URI is absolute (containing a scheme) or a not.
2. Glassfish copies the configuration XML to the config directory of the instance root.
3. The specified instanceRoot must have a config directory, and may have a domain.xml file (that is optional).
4. If a configurationXml file is specified in arquillian.xml, then this file is copied into the instance root (but not overwritten). If no configurationXml file is specified in arquillian.xml, then the domain.xml file is extracted from embedded glassfish and copied to the instance root (again not overwritten).
5. The instanceRoot must also have a docRoot directory (not specified in domain.xml), and other files like cacerts.jks and keystore.jks. The latter files are required because they are usually specified in domain.xml, for configuring the https-listener.
6. The installRoot must have subdirectories named 'domains' and 'lib'. Although this is not required in most cases o

VineetReynolds

1. glassfish-embedded-all-3.1.jar has a META-INF/services/javax.xml.bind.JAXBContext file, whose contents indicate that the JAXB context factory to be used is "com.sun.xml.bind.v2.ContextFactory".
2. This overrides the default JAXB-RI within the Oracle/Sun JDK's rt.jar - "com.sun.xml.internal.bind.v2.ContextFactory".
3. Since the codesources are different in both the cases, a ClassNotFoundException is thrown when attempting to load the ContextFactory class from glassfish-embedded-all-3.1.jar. The ContextFactory class from rt.jar is loaded without issues in a typical scenario, as it's codesource is rt.jar, which is the same codesource for the java.* and javax.* classes that are loaded only by the root classloader.
4. To summarize, when the Maven surefire test executes the said test case,
 a. The META-INF/javax.xml.bind.JAXBContext of embedded Glassfish is read by javax.xml.bind.ContextFimder, and is used to locate the JAXB ContextFactory class. In the absence of a validation.xml file, the JAXB provider-config 

VineetReynolds

arquillian.xml contains the following entries:

    <container qualifier="glassfish-auth" default="true">
        <configuration>
            <property name="adminHost">dashost</property>
            <property name="adminPort">4848</property>
            <property name="adminUser">admin</property>
            <property name="adminPassword">admin</property>
            <property name="target">standalone-instance</property>
        </configuration>

VineetReynolds

1. GF has the concept of a virtual server that is used to serve content targetted against specific URLs.
   A request is redirected to a virtual server, based on the URL. A virtual server is associated with a set of network listeners that listen on particular ports.
2. The __asadmin virtual-server cannot host any deployments.
   It's network-listeners should therefore be ignored for creating a HTTPContext.
3. Most deployments will be performed against the default virtual server named "server"; this can be configured during the time of deployment.
   When a virtual server is not specified at the time of deployment, the application can be accessed through all virtual servers (except __asadmin).
   Arquillian does not specify a virtual server at the time of deployment (should it?) and therefore the servlet test runner can be accessed via any of the virtual servers.
   The config of all network-listeners should therefore be read, to prepare the HTTPContext.
4. Any application deployment on GF will store reference

VineetReynolds

Embedded GlassFish

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.

Remote Glassfish

VineetReynolds

   private static final String INSTANCE_APPLICATION_REF = "/servers/server/{server}/application-ref/{application}";

   private List<String> getVirtualServersOfInstanceDeployment(String serverName, String deploymentName)
   {
      String applicationRefPath = INSTANCE_APPLICATION_REF.replace("{server}", serverName).replace("{application}",
            deploymentName);
      Map<String, String> applicationRefAttributes = getClientUtil().getAttributes(applicationRefPath);
      String virtualServersList = applicationRefAttributes.get("virtualservers");
      String[] virtualServers = virtualServersList.split(",");
      return Arrays.asList(virtualServers);

VineetReynolds

The importAsNode(InputStream, boolean) method of the XmlDomNodeImporterImpl class, parses the provided InputStream into a XML document, using a DocumentBuilder. Under the hood, the InputStream is wrapped as an InputSource, whose encoding is unknown - we haven't created the InputSource ourselves, and neither is an explicit encoding specified for the InputSource using the setEncoding method. When the input stream contains umlauts encoded in ISO-8859-1, the parser (in-built Xerces of the Oracle/Sun JRE) incorrectly attempts reading them as UTF-8; see the bug report for the parser behavior.

Going by the API documentation for the InputSource class, the solution is to either use an InputSource with an underlying character stream, or to specify the encoding for the byte stream.

Using a character stream

This would require introduction of anothe

VineetReynolds

Setting up Arquillian-Container-Tomcat in Eclipse for debugging

1. Download the sources. Visit the repo @ GitHub. In the "Current branch:" dropdown, switch to the 1.0.0.CR2 tag; tags are on the second tab. After switching to the required tag/branch, download the repo as a ZIP, via the ZIP button.
2. Extract the downloaded distribution.
3. In Eclipse, import the Maven project -

• Go to File -> Import -> Maven -> Existing Maven Projects.
• Choose the root directory of the extracted distribution that contains the parent project's pom.xml. Arquillian-Container-Tomcat has one pom.xml for the parent project, and has sub-directories tomcat-common, tomcat-embedded-6 etc. containing POMs for the modules in the project.
• The discovered projects should now be shown in the navigator. Ensure that all are selected. Choose Next.
• If any problems are discovered in the POM by m2e, choose the resolution as "Do not execute (add to parent)".

VineetReynolds

• Mercurial Eclipse
• eGit
• Coffee Bytes code folder plugin
• JD-Eclipse update site
• JD-Eclipse re-alignment
• m2e

VineetReynolds

• Invoking weblogic.Deployer is necessary but expensive.
• Removing -debug flag does not seem to improve performance. However, the sample size of 6 deployments may be insufficient. The only point of note was that deploy times lasted 5-10 seconds, with an average of 5/6 seconds for all tests except for WebLogicCDIEarTestCase and WebLogicCDIWarTestCase (lasting 8-11 secs), and undeploy times usually lasted 4 seconds. The latter two could be discounted as they deploy Weld-Servlet which needs to be bootstrapped.
• Attempt using the JSR-88 implementation of WLS; possible only if there are no licensing concerns ~~and if there is indeed a noticeable performance improvement, which brings deployment times down (preferably to the sub-5 second range). Also depends on the deployment strategy chosen by devs - big bang deployments are likely to be favored for black box tests and micro deployments for more focused white box tests. Big bang deployments may not benefit from a JSR-88 implementation, as the `weblogic.De