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

VineetReynolds

-------------------------------------------------------------------------------
Test set: com.acme.cdi.InjectionTestCase
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 34.235 sec <<< FAILURE!
shouldBeAbleToInjectCDI(com.acme.cdi.InjectionTestCase)  Time elapsed: 0.921 sec  <<< ERROR!
java.lang.RuntimeException: Could not inject members
	at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.injectClass(CDIInjectionEnricher.java:135)
	at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.enrich(CDIInjectionEnricher.java:78)
	at org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:52)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)