Excellent blog about resolving project dependencies into a Shrinkwrap archive for Arquillian. Now I just hope Pax Exam takes note for OSGi testing.
For a long time the SQL Server JDBC driver was not available in Maven Central but this has changed so I have updated this post accordingly but you can still use this method should you require a version of the driver that is not in Maven Central.
Documentation: https://docs.microsoft.com/en-us/sql/connect/jdbc/download-microsoft-jdbc-driver-for-sql-server
<dependency>
<groupId>com.microsoft.sqlserver</groupId>
<artifactId>mssql-jdbc</artifactId>
<version>6.2.2.jre8</version>
</dependency>
</pre>
The Microsoft SQL Server JDBC driver was not available in public repositories because of licensing issues but it is easy to install into a company wide repository like Sonatype Nexus or into the local repository on your machine. This procedure can be used for other libraries as well.
Step 1 : Download the driver from <a title="Microsoft JDBC driver version 4.0" href="http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=11774" target="_blank" rel="noopener">http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=11774</a>
Step 2: Extract the file and locate the sqljdbc.jar and sqljdbc4.jar. The table below indicates the usage of the jars respectively.
<table border="1" width="1001">
<tbody>
<tr>
<td>
<p align="center"><strong>JAR</strong></p>
</td>
<td>
<p align="center"><strong>Description</strong></p>
</td>
</tr>
<tr>
<td>sqljdbc.jar</td>
<td>sqljdbc.jar class library provides support for JDBC 3.0.sqljdbc.jar class library requires a Java Runtime Environment (JRE) of version 5.0. Using sqljdbc.jar on JRE 6.0 will throw an exception when connecting to a database.The JDBC Driver does not support JRE 1.4. You must upgrade JRE 1.4 to either JRE 5.0 or JRE 6.0 when using the JDBC Driver. In some cases, you might need to recompile your application because it might not be compatible with JDK 5.0 or later. For more information, see the documentation on Sun Microsystems Web site.</td>
</tr>
<tr>
<td>sqljdbc4.jar</td>
<td>sqljdbc4.jar class library provides support for JDBC 4.0. It includes all of the features of the sqljdbc.jar as well as the new JDBC 4.0 methods.sqljdbc4.jar class library requires a Java Runtime Environment (JRE) of version 6.0. Using sqljdbc4.jar on JRE 1.4 or 5.0 will throw an exception.Use sqljdbc4.jar when your application must run on JRE 6.0, even if your application does not use JDBC 4.0 features.</td>
</tr>
</tbody>
</table>
Step 3: If you have Nexus then use the following pom.xml to add the sqljdbc.jar
<pre>
<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<groupId>com.microsoft.sqlserver</groupId>
<artifactId>sqljdbc</artifactId>
<version>4.0.2206.100</version>
</project>
Step 4: Select the 3rd Party Releases repository in Nexus. In the image I am showing my local Nexus 2.0 repository
Step 5: Click the Artifact Upload tab.
a. Select the GAV Definition: From POM
b. POM file name: Select the file containing the pom.xml from step 3
c. Select artifacts to upload: Select the sqljdbc.jar from enu folder in the extracted zip folder
Step 6: Select Upload
Step 7: Installing the sqljdbc4.jar uses the following pom.xml and the steps outlined above
<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<groupId>com.microsoft.sqlserver</groupId>
<artifactId>sqljdbc4</artifactId>
<version>4.0.2206.100</version>
</project>
Step 8: If you do not have Sonatype Nexus, then to install the libraries into the local repository using the following command. You do not need the pom.xml files since these will be created by Maven.
mvn install:install-file -Dfile=sqljdbc4.jar -Dpackaging=jar -DgroupId=com.microsoft.sqlserver -DartifactId=sqljdbc4 -Dversion=4.0.2206.100
Step 9: Reference the library in you project
<dependency> <groupId>com.microsoft.sqlserver</groupId> <artifactId>sqljdbc4</artifactId> <version>4.0.2206.100</version> </dependency>
NOTE: Tomorrow I will be deploying the driver into Apache Karaf.
A friend of mine,John Steinberg, introduced me to the high performance currency framework LMAX Disruptor. In a recent project I wanted to use the Disruptor as an OSGi bundle that my application could make use of but the MANIFEST.MF supplied with the library just contained the default build information.
I have contributed a patch that adds the relevant bundle information, but if you would like LMAX Disruptor 2.9 built library with the OSGi information then have a look here. I did get confirmation from the LMAX Disruptor developers that the patch has been committed and will be available in the next release.
Below is a screen shot of Apache Karaf with the LMAX Disruptor deployed.
The JCP voted 8 no, 5 yes and 3 abstains for the Social Media API (JSR 357) with the main complaint being that the specification is too broad in it’s current form and would hamper the natural formation of the technology since it is still early days for this technology.
The JSR review ballot can be found here.
This version should actually be called JMS 1.2 since the minor changes and clarifications in the specification (a total of 18 defects). However these defects will address many of the frustrations that developers have had when trying to implement business critical software against the specification and I hope the clarification of interchangeability between JMS providers, i.e. JMS_SPEC-42.
Some my personal highlights are:-
JMS_SPEC-63 : The idea of a default connection factory (akin to the java:/ConnectionFactory in JBoss 7.x)
JMS_SPEC-7 : Similar to the HTTP and SOAP bindings that Oracle has in their Weblogic Server offering
JMS_SPEC-42 / 54 : Defining a standard way to define the message destination without the convoluted message-destination-link, although the message-destination-link will still be used if the current naming of resources between JBoss, Glassfish and Weblogic continues with the one application server requiring java:/ or java:jboss and the others not.
JMS_SPEC-56 : Although there is no mention of the reason for requesting allowing batches of messages to be delivered listeners, it seems like it was requested to improve performance, but probably opens more issues than it would solve since it would require the application developer to custom build logic to handle the different nuances when a failure occurs. A better alternative would be for example like Weblogic Server messaging, which has a process where it batches off a set of messages that is then delivered to the listeners.
References
Java 6 EOL has been extended to November 2012 to give time to transition to Java 7, see public announcement and here is another link explaining the EOLining process.
Here is the short and curly of the dates:-
|
Major |
GA Date |
EOL |
EOL |
|
|
|
||||
| 1.4 | Feb 2002 | Dec 2006 | Oct 2008 | |
|
|
||||
| 5.0 | May 2004 | Apr 2008 | Oct 2009 | |
|
|
||||
| 6 | Dec 2006 | Feb 2011 | Nov 2012 | |
|
|
||||
| 7 | July 2011 | TBD | July 2014 | |
Mark Ashworth 