Fronting Oracle Maven Repository with Sonatype Nexus

The Sonatype team have announced the release of Nexus 2.1.1 which is a minor update that now works with the Oracle Maven Repository.

I was going to write a bit up about it but Manfred Moser from Sonatype has already put together a blog and video on it:

With the new Nexus 2.11.2 release we are supporting the authentication mechanism used for the Oracle Maven repository in both Nexus OSS and Nexus Pro. This allows you to proxy the repository in Nexus and makes the components discoverable via browsing the index as well as searching for components.

You will only need to set this up once in Nexus and all your projects. Developers and CI servers get access to the components and the need for any manual work disappears.  On the Nexus side, the configuration changes can be done easily as part of your upgrade to the new release.

Check it out @ Using the Oracle Maven Repository with Nexus

Fronting Oracle Maven Repository with Artifactory

The JFrog team announced this week the release of Artifactory 3.5.1, which is a minor update that now works with the Oracle Maven Repository.

http://www.jfrog.com/confluence/display/RTF/Artifactory+3.5.1

I spent a little while yesterday having a look at it, working through the configuration of a remote repository and testing it with a maven project to see how it worked.

Once I'd downloaded it and started it up -- much love for simple and obvious bin/*.sh scripts -- it was a very simple two step process:

1. Since we live behind a firewall first add a proxy configuration to point at our proxy server.

2. Add a new remote repository and pointed it at the Oracle Maven Repository, specifying its URL and using my OTN credentials as username and password.

The Artifactory 3.5.1 documentation stated that the Advanced Settings >  Lenient host authentication and Enable cookie management options must be checked when accessing the Oracle Maven Repository.

The Test button is handy to verify the server settings have been entered correctly.

3. Use the Home tab > Client Settings > Maven Settings link to generate and save a settings.xml file that uses the artifactory server.

With the repository running, configured and the settings.xml saved, its then possible to try it out with an existing maven project such as https://github.com/buttso/weblogic-with-arquillian.

I also nuked my local repository to force/verify that the dependencies were fetched through the specified Artifactory server.

$ rm -fr ~/.m2/repository/com/oracle
$ mvn -s artifactory-settings.xml test

Viewing the output of the mvn process and the running Artifactory server you can see that maven is downloading dependencies from http://localhost:8081/artifactory and correspondingly Artifactory is downloading the requested artifact from https://maven.oracle.com.

Once the maven process has completed and all the requested artifacts downloaded, Artifactory will have cached them locally for future use.
 
Using the Search functionality of the Artifactory Web UI you can search for weblogic artifacts.

Using the Repository Browser functionality of the Artifactory Web UI you can view and navigate around the contents of the remote Oracle Maven Repository.

Nice JFrog > Artifactory team - thanks for the quick support of our repository.

One further thing I'd look at doing is enabling the Configure Passwords Encryption option in the Security settings to encrypt your OTN password, so that it's not stored in cleartext in the etc/artifactory.config.latest.xml file.

Oracle Maven Repository - Viewing Contents in Eclipse

With the Oracle Maven Repository now accessible one way to have explore its contents is to use the Maven Repositories viewer feature available in most development tools. I've seen the repository contents displayed easily in NetBeans so I decided to take a look at what it looks like in Eclipse as well.

I had to make a few minor setting changes to get it to work so decided to document them here.  If you've gotten it to work with less setting changes, let me know!

As initial setup, I configured my local maven environment to support access to the Oracle Maven Repository.  This is documented here https://maven.oracle.com/doc.html.  I also installed maven-3.2.5 that includes the updated Wagon module that supports authentication.

Next I downloaded and used the new network installer that the Oracle Eclipse team has published on OTN to install the latest version of Oracle Enterprise Pack for Eclipse.

This network installer lets developers select the version of Eclipse to install and the set of Oracle extensions --  Weblogic, GlassFish and other stuff -- to add in to it.

 Once Eclipse is installed, you can add the Maven Repository viewer by selecting   Window > Show View > Other > Maven Repositories from the Eclipse toolbar.

I also added a Console > Maven viewer to see what was happening under the covers and arranged them so they were visible at the same time:

With the Maven views ready to go, expand the Global Repositories node. This will show Maven Central (any other repositories you may have configured) and the Oracle Maven Repository if you have configured it correctly in the settings.xml file.

The initial state of the Oracle Maven Repository doesn't show any contents indicating that its index hasn't been downloaded to display.

Right mouse clicking on it and selecting the Rebuild Index option causes an error to be shown in the console output indicating that the index could not be accessed.

To get it to work, I made the following changes to my environment.  

Configure Eclipse to Use Maven 3.2.5

Using the Eclipse > Preferences > Maven > Installation dialog, configure Eclipse to use Maven 3.2.5.  This is preferred version of Maven to use to access the Oracle Maven Repository since it automatically includes the necessary version of the Wagon HTTP module that supports the required authentication configuration and request flow.

Configure Proxy Settings in Maven Settings File

** If you don't need a proxy to access the Internet then step won't be needed **
 
If you sit behind a firewall and need to use a proxy server to access public repositories then you need to configure a proxy setting inside the maven settings file.

Interestingly for command line maven use and NetBeans a single proxy configuration in settings.xml was enough to allow the Oracle Maven Repository to be successfully accesses and its index and artifacts used.

	<proxies>
	<proxy>
	<active>true</active>
	<protocol>http</protocol>
	<host>__PROXY_SERVER__</host>
	<port>80</port>
	<nonProxyHosts>
	www.oracle.com|localhost|127.0.0.1
	</nonProxyHosts>
	</proxy>
	</proxies>

view raw settings.xml hosted with ❤ by GitHub

However with Eclipse, this setting alone didn't allow the Oracle Maven Repository to be accessed.  Looking at the repository URL for the Oracle Maven Repository you can see ity's HTTPS based -- https://maven.oracle.com and it appears for Eclipse that a specific HTTPS based proxy setting is required for Eclipse to access HTTPS based repositories.

	<proxies>
	<proxy>
	<active>true</active>
	<protocol>http</protocol>
	<host>__PROXY_SERVER__</host>
	<port>80</port>
	<nonProxyHosts>
	www.oracle.com|localhost|127.0.0.1
	</nonProxyHosts>
	</proxy>
	<proxy>
	<active>true</active>
	<protocol>https</protocol>
	<host>__PROXY_SERVER__</host>
	<port>80</port>
	<nonProxyHosts>
	www.oracle.com|localhost|127.0.0.1
	</nonProxyHosts>
	</proxy>
	</proxies>

view raw settings.xml hosted with ❤ by GitHub

Rebuild Index Success

With the settings in place, the Rebuild Index operation succeeds and the contents of the Oracle Maven Repository are displayed in the repository viewer.

Bare-Bones Example of Using WebLogic and Arquillian

The Arquillian project is proving to be very popular for testing code and applications.  It's particularly useful for Java EE projects since it allows for in-container testing to be performed, enabling unit tests to use dependency injection and all the common services  provided by the Java EE platform.

Arquillian uses the concept of container adapters to allow it to execute test code with a  specific test environment.  For the Java EE area,  most of the Java EE implementations have an adapter than can be used to perform the deployment of the archive under test and to execute and report on the results of the unit tests.

A handy way to see all the WebLogic Server related content on the Arquillian blog is this URL: http://arquillian.org/blog/tags/wls/

For WebLogic Server the current set of adapters are listed here: http://arquillian.org/blog/2015/01/09/arquillian-container-wls-1-0-0-Alpha3/

There are multiple adapters available for use.  Some of them are historical and some are for use with older versions of WebLogic Server (10.3).

We are actively working with the Arquillian team on finalizing the name, version and status of a WebLogic Server adapter.

The preferred adapter set from the WebLogic Server perspective are these:

• org.jboss.arquillian.container » arquillian-wls-remote-12.1.2
• org.jboss.arquillian.container » arquillian-wls-managed-12.1.2

These adapters utilize the WebLogic Server JMX API to perform their tasks and are the adapters used internally by the development teams when working with Arquillian.  They have been tested to work with WebLogic Server [12.1.1, 12.1.2, 12.1.3].  We also have been using them internally with the 12.2.1 version under development to run the CDI TCK and other tests.

To demonstrate WebLogic Server working with Arquillian a bare-bones example is available on GitHub here: https://github.com/buttso/weblogic-with-arquillian

This example has the most basic configuration you can use to employ Arquillian with a Maven project to deploy and execute tests using WebLogic Server 12.1.3.
 
The README.md file in the project contains more details and a longer description.  In summary though:

1. The first step is to add the Arquillian related dependencies in the Maven pom.xml:

	<project>
	...
	<dependencyManagement>
	<dependencies>
	<dependency>
	<groupId>org.jboss.arquillian</groupId>
	<artifactId>arquillian-bom</artifactId>
	<version>1.1.5.Final</version>
	<scope>import</scope>
	<type>pom</type>
	</dependency>
	</dependencies>
	</dependencyManagement>
	<dependencies>
	...
	<!-- ###################################### -->
	<!-- #### Arquillian Test Dependencies ### -->
	<!-- ###################################### -->
	<dependency>
	<groupId>org.jboss.arquillian.junit</groupId>
	<artifactId>arquillian-junit-container</artifactId>
	<scope>test</scope>
	</dependency>
	<dependency>
	<groupId>org.jboss.arquillian.container</groupId>
	<artifactId>arquillian-wls-remote-12.1.2</artifactId>
	<version>1.0.0.Alpha3</version>
	<scope>test</scope>
	</dependency>
	</dependencies>
	...
	</project>

view raw weblogic-with-arquillian-pom.xml hosted with ❤ by GitHub

2. The next step is to create an arquillian.xml file that the container adapter uses to connect to the remote server that is being used as the server to run the tests:

	<?xml version="1.0"?>
	<arquillian
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns="http://jboss.org/schema/arquillian"
	xsi:schemaLocation="http://jboss.org/schema/arquillian
	http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
	<!--
	<engine>
	<property name="deploymentExportPath">target/</property>
	</engine>
	-->
	<container qualifier="weblogic" default="true">
	<defaultProtocol type="Servlet 3.0" />
	<configuration>
	<property name="wlHome">/Users/sbutton/Oracle/Middleware/wlserver</property>
	<property name="adminUrl">t3://localhost:7001</property>
	<property name="adminUserName">weblogic</property>
	<property name="adminPassword">welcome1</property>
	<property name="target">AdminServer</property>
	</configuration>
	</container>
	</arquillian>

view raw weblogic-with-arquillian-arquillian.xml hosted with ❤ by GitHub

3. The last step is to create a unit test which is run with Arquillian.  The unit test is responsible for implementing the @Deployment method which constructs an archive to deploy that contains the code to be tested.  The unit test then provides @Test methods in which the deployment is tested to verify its behaviour:

	package buttso.demo.weblogic.wlsarq;
	import com.gargoylesoftware.htmlunit.WebClient;
	import com.gargoylesoftware.htmlunit.html.HtmlPage;
	import java.net.URL;
	import java.util.logging.Logger;
	import org.jboss.arquillian.container.test.api.Deployment;
	import org.jboss.arquillian.container.test.api.RunAsClient;
	import org.jboss.arquillian.junit.Arquillian;
	import org.jboss.arquillian.test.api.ArquillianResource;
	import org.jboss.shrinkwrap.api.ShrinkWrap;
	import org.jboss.shrinkwrap.api.spec.WebArchive;
	import org.junit.Assert;
	import org.junit.Test;
	import org.junit.runner.RunWith;
	/**
	* Test case to perform simple verifications of the
	* index.html that is included as part of the @Deployment
	*
	* @author sbutton
	*/
	@RunWith(Arquillian.class)
	public class IndexPageTest {
	private static final Logger LOG = Logger.getLogger(IndexPageTest.class.getName());
	private static final int INDEX_PAGE_LINE_COUNT = 15;
	private static final String INDEX_PAGE_TITLE = "wlsarq";
	@Deployment
	public static WebArchive createDeployment() {
	WebArchive war = ShrinkWrap.create(WebArchive.class)
	.addAsWebResource("index.html");
	return war;
	}
	@Test
	@RunAsClient
	public void test_index_page_present(@ArquillianResource URL testURL) {
	LOG.info("Testing deployment @ " + testURL);
	WebClient webClient = null;
	try {
	webClient = new WebClient();
	HtmlPage page = webClient.getPage(testURL);
	Assert.assertTrue("Line count doesn't match", INDEX_PAGE_LINE_COUNT == page.getEndLineNumber());
	} catch (Exception e) {
	// Swallow me whole
	} finally {
	webClient.closeAllWindows();
	}
	}
	@Test
	@RunAsClient
	public void test_index_title(@ArquillianResource URL testURL) {
	LOG.info("Testing deployment @ " + testURL);
	WebClient webClient = null;
	try {
	webClient = new WebClient();
	final HtmlPage page = webClient.getPage(testURL);
	Assert.assertEquals(INDEX_PAGE_TITLE, page.getTitleText());
	} catch (Exception e) {
	// Swallowed, doh!
	} finally {
	webClient.closeAllWindows();
	}
	}
	}

view raw weblogic-with-arquillian - index_page_test.java hosted with ❤ by GitHub

Executing the unit tests, with the associated archive creation and deployment to the server is performed using the maven test goal:

	[sbutton] wlsarq $ mvn test
	[INFO] Scanning for projects...
	[INFO]
	[INFO] ------------------------------------------------------------------------
	[INFO] Building wlsarq 1.0
	[INFO] ------------------------------------------------------------------------
	[INFO]
	[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ wlsarq ---
	[INFO] Using 'UTF-8' encoding to copy filtered resources.
	[INFO] Copying 0 resource
	[INFO]
	[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ wlsarq ---
	[INFO] Nothing to compile - all classes are up to date
	[INFO]
	[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ wlsarq ---
	[INFO] Using 'UTF-8' encoding to copy filtered resources.
	[INFO] Copying 1 resource
	[INFO] Copying 1 resource
	[INFO]
	[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ wlsarq ---
	[INFO] Nothing to compile - all classes are up to date
	[INFO]
	[INFO] --- maven-surefire-plugin:2.18:test (default-test) @ wlsarq ---
	[INFO] Surefire report directory: /Users/sbutton/Projects/Java/weblogic-with-arquillian/wlsarq/target/surefire-reports
	-------------------------------------------------------
	T E S T S
	-------------------------------------------------------
	Running buttso.demo.weblogic.wlsarq.IndexPageTest
	Feb 02, 2015 11:34:08 PM buttso.demo.weblogic.wlsarq.IndexPageTest test_index_page_present
	INFO: Testing deployment @ http://192.168.0.13:7001/f6a033f4-07a9-462b-8e0b-2946dd19d577/
	Feb 02, 2015 11:34:09 PM buttso.demo.weblogic.wlsarq.IndexPageTest test_index_title
	INFO: Testing deployment @ http://192.168.0.13:7001/f6a033f4-07a9-462b-8e0b-2946dd19d577/
	Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.201 sec - in buttso.demo.weblogic.wlsarq.IndexPageTest
	Running buttso.demo.weblogic.wlsarq.PingPongBeanTest
	Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.975 sec - in buttso.demo.weblogic.wlsarq.PingPongBeanTest
	Results :
	Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
	[INFO] ------------------------------------------------------------------------
	[INFO] BUILD SUCCESS
	[INFO] ------------------------------------------------------------------------
	[INFO] Total time: 6.772 s
	[INFO] Finished at: 2015-02-02T23:34:11+10:30
	[INFO] Final Memory: 12M/331M
	[INFO] ------------------------------------------------------------------------

view raw weblogic-with-arquillian - test execution hosted with ❤ by GitHub

The tests can be executed directly from IDEs such as NetBeans and Eclipse using the Run Test features:

Executing Tests using NetBeans

Social Coding Resolves JAX-RS and CDI Producer Problem

The inimitable Bruno Borges picked up tweet earlier today commenting on a problem using @Produces with non-CDI libraries with WebLogic Server 12.1.3.

The tweeter put his example up on a github repository to share - quite a nice example of using JAX-RS, CDI integration and of using Arquillian to verify it works correctly.  Ticked a couple of boxes for what I've been looking at lately

Forking his project to have a look at it locally:

https://github.com/buttso/weblogic-producers

Turns out that the issue was quite a simple and common one - a missing reference to the jax-rs:2.0 shared-library that is needed to use JAX-RS 2.0 on WebLogic Server 12.1.3.   Needs a weblogic.xml to reference that library.

I made the changes in a local branch and tested it again:

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] producers .......................................... SUCCESS [  0.002 s]
[INFO] bean ............................................... SUCCESS [  0.686 s]
[INFO] web ................................................ SUCCESS [  7.795 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

With the tests now passing, pushed the branch to my fork and sent Kuba a pull request to have a look at the changes I made:

https://github.com/buttso/weblogic-producers/tree/steve_work

I now just hope it works in his environment too :-)

The GitHub model is pretty magical really.

Using the WebLogic Embedded EJB Container

The WebLogic Server 12.1.3 EJB Developers Guide was recently updated to note that the embedded EJB container can be used by adding a reference to weblogic.jar to the CLASSPATH when the EJB client is being executed.

https://docs.oracle.com/middleware/1213/wls/EJBAD/embedejb.htm#EJBAD1403

This is very convenient since it enables the WebLogic Server embedded EJB container to used by simply adding weblogic.jar to the classpath when running the client:

$ java -classpath ${CLASSPATH}:${ORACLE_HOME}/wlserver/server/lib/weblogic.jar

view raw cmd line run with weblogic.jar hosted with ❤ by GitHub

Or for example if you are developing unit tests using JUnit and running them from a maven project, you can configure the maven-surefire-plugin to use WebLogic Server to run the EJB test code in its embedded EJB container:

	<properties>
	<weblogic.jar.path>${oracle.home}/wlserver/server/lib/weblogic.jar</weblogic.jar.path>
	</properties>
	....
	<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-surefire-plugin</artifactId>
	<version>2.18</version>
	<configuration>
	<argLine>-Xmx128m</argLine>
	<enableAssertions>false</enableAssertions>
	<classpathDependencyScopeExclude>compile</classpathDependencyScopeExclude>
	<additionalClasspathElements>
	<additionalClasspathElement>${weblogic.jar.path}</additionalClasspathElement>
	</additionalClasspathElements>
	</configuration>
	</plugin>

view raw pom.xml for maven-surefire-plugin with wls hosted with ❤ by GitHub

A fully working example of using this is available in this GitHub repository:

https://github.com/buttso/weblogic-embedded-ejb

For more information have a look at the repository and check out the example.