Search

Mark Ashworth

Designing applications, writing, photography and reading

Using BND to create OSGi bundles for sysmemcached and couchbase client

The link to the article can be found:-
http://blogs.nologin.es/rickyepoderi/index.php?/archives/55-Using-BND-to-Create-OSGi-Bundles.html

Adding Microsoft SQL Server JDBC driver to Nexus and local maven repository

The Microsoft SQL Server JDBC driver is 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 http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=11774

Step 2: Extract the file and locate the sqljdbc.jar and sqljdbc4.jar. The table below indicates the usage of the jars respectively.

JAR

Description

sqljdbc.jar 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.
sqljdbc4.jar 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.

Step 3: If you have Nexus then use the following pom.xml to add the sqljdbc.jar

<?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

3rd party 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

Adding sqljdbc.jar to Nexus 3rd Party Releases

Step 6: Select Upload

Uploaded

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.

OSGi enabled LMAX Disruptor

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.

Apache Karaf showing deployed Disruptor bundle

Social Media JSR 357 is voted no go in current form

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.

JSR 343: JMS 2.0 – the next version of the JMS Specification

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

http://java.net/projects/jms-spec/pages/Home

http://java.net/projects/jms-spec/pages/JSR343EarlyDraft

JBoss 7.1 Console 1.1.0 Released

The most notable changes in this release are the addition of four new subsystems, that are manageable through the console now.

New Subsystem Support

  • mail
  • modcluster
  • infinispan
  • jgroups

This release can be downloaded here.

The original blog post can be found here.

JBoss 7.1 Final realeased

JBoss 7.1 has been released and in the process of downloading it so that I can start using it 🙂 Cannot wait!!!

Download

Java 6 end of life extension

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
Release

GA Date

EOL
Notification

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

Handling persistence.xml datasource name discrepancy between Glassfish and JBoss

I have been developing the Yellowfire project against Glassfish 3.1 ever since that application server made a beta release but of late wanted to get Yellowfire to deploy to JBoss 7.1 as well. The snag I kept hitting my head against was that of the JNDI naming of the data source used in the persistence.xml since Glass wanted the global name, i.e. yellowfire/ds whereas JBoss 7.1 was adamant that it should be either java:/yellowfire/ds or java:jboss/yellowfire/ds.

I then brushed up on the use of the resource-refs and tried to apply the same logic to the persistence.xml data source name, much to my frustration but found that I was not alone. The Beware of soapy frogs JEE pitfalls webpage.

The only option was then to make this a build process requirement and at first I made the maven-war-plugin filter the different persistence.xml files for each application server depending on the Maven profile. Needless to say, maintaining 3 persistence.xml files (Glassfish, JBoss and Weblogic) is not child’s play when actively developing a new piece of software and is much harder when there are more than 1 developer.

The next step was to make the Maven build generate the persistence.xml file from a template and that is the objective of this post.

First we start with a profile for each application server in which the dependencies for that server is required that are different from the others. Sometimes this dependency management is an issue all on it’s own.

<profiles>
  <profile>
    <id>glassfish-3.1</id>
    .....
    <properties>
      <application.server>glassfish</application.server>
    </properties>
  </profile>
  <profile>
    <id>jboss-7.1</id>
    .....
    <properties>
      <application.server>jboss</application.server>
    </properties>
  </profile>
</profiles>

Notice that each profile has the same property application.server which will be used in the maven-resources-plugin do perform a bit of filtering.
The next step is to get a list of the entity classes used by the application. Once again this can be crafted by hand or since entity classes have annotations this list can be generated. In Yellowfire, the entity class list is generated using the jpa-maven-plugin.

<plugin>
 <groupId>com.edugility</groupId>
 <artifactId>jpa-maven-plugin</artifactId>
 <version>1.0</version>
 <executions>
   <execution>
     <id>Generate persistence-classes.properties</id>
     <goals>
       <goal>list-entity-classnames</goal>
     </goals>
     <configuration>
       <defaultPropertyName>entity-class-names</defaultPropertyName>
       <firstItemPrefix>&lt;class&gt;</firstItemPrefix>
       <lastItemSuffix>&lt;/class&gt;</lastItemSuffix>
       <outputFile>${basedir}/src/main/filter/persistence-classes.properties</outputFile>
     </configuration>
   </execution>
 </executions>
</plugin>

And then provide properties files for the different application servers. First is the glassfish-persistence-xml.properties

jta-data-source=yellowfire/ds
eclipselink.target-server=

#Note: Use this with application-scoped data sources
#<property name="javax.persistence.jtaDataSource" value="java:/app/jdbc/yellowfire" /-->
#Enable or disable EclipseLink's generation of database platform-specific SQL (as opposed to generic SQL).
# true – enable EclipseLink's generation of database platform-specific SQL.
# false – disable generation of database platform-specific SQL by EclipseLink.
eclipselink.jdbc.native-sql=true

# Logging
# OFF This setting disables the generation of the log output. You may want to set logging to OFF during production to avoid the overhead of logging.
# SEVERE This level enables reporting of failure cases only. Usually, if the failure occurs, the application stops.
# WARNING This level enables logging of issues that have a potential to cause problems. For example, a setting that is picked by the application and not by the user.
# INFO This level enables the standard output. The contents of this output is very limited. It is the default logging level if a logging level is not set.
# CONFIG This level enables logging of such configuration details as your database login information and some metadata information. You may want to use the CONFIG log level at deployment time.
# FINE This level enables logging of the first level of the debugging information and SQL. You may want to use this log level during debugging and testing, but not at production.
# FINER This level enables logging of more debugging information than the FINE setting. For example, the transaction information is logged at this level. You may want to use this log level during debugging and testing, but not at production.
# FINEST This level enables logging of more debugging information than the FINER setting, such as a very detailed information about certain features (for example, sequencing). You may want to use this log level during debugging and testing, but not at production.
# ALL This level currently logs at the same level as FINEST.
eclipselink.logging.level=INFO
eclipselink.logging.timestamp=true
eclipselink.logging.session=true
eclipselink.logging.thread=true
eclipselink.logging.exceptions=true

# Control whether or not the query uses parameter binding
# Note: Default is true
# true – bind all parameters.
# false – do not bind parameters.
eclipselink.jdbc.bind-parameters=false

# Specify the use of batch writing to optimize transactions with multiple write operations
# JDBC – use JDBC batch writing.
# Buffered – do not use either JDBC batch writing nor native platform batch writing.
# Oracle-JDBC – use both JDBC batch writing and Oracle native platform batch writing.
# Use OracleJDBC in your property map.
# None – do not use batch writing (turn it off).
eclipselink.jdbc.batch-writing=JDBC

# Enable or disable EclipseLink internal statement caching
# Note: Default is false
# Note: we recommend enabling this functionality if you are using EclipseLink connection pooling.
# true – enable EclipseLink's internal statement caching.
# false – disable internal statement caching.
eclipselink.jdbc.brokerCache-statements=true

# The number of statements held when using internal statement caching.
# Note: Default is 50
eclipselink.jdbc.brokerCache-statements.size=50

# Specify when a write connection is acquired lazily. For more information, see Lazy Connection Acquisition
# Note: Default is true
# true - aquire the write connection lazily.
# false - do not aquire the write connection lazily.
eclipselink.jdbc.exclusive-connection.is-lazy=true

# Specify when EclipseLink should perform reads through a write connection. For more information, see Exclusive Write Connections.
# Note: Default is Transactional
#
# You can set this property while creating either an EntityManagerFactory (either in the map passed to the createEntityManagerFactory method, or in the persistence.xml file), or an EntityManager (in the map passed to the createEntityManager method). Note that the latter overrides the former.
#
# The following are the valid values for the use in a persistence.xml file and for the org.eclipse.persistence.config.ExclusiveConnectionMode:
#
# Transactional - Create an isolated client session (see Isolated Client Sessions) if some or all entities require isolated brokerCache 4 ; otherwise, create a client session.
# Note: EclipseLink keeps the connection exclusive for the duration of the transaction. Inside the transaction, EclipseLink performs all writes and reads through the exclusive connection. However, outside the Eclipelink transaction, a new connection is acquired from the connection pool for each read and released back immediately after the query is executed.
# Isolated - Create an exclusive isolated client session if reading an isolated Entity; otherwise, raise an error.
# Note: EclipseLink keeps the connection exclusive for the lifetime of the owning EntityManager. Inside the transaction, EclipseLink performs all writes and reads through the exclusive connection. However, outside the Eclipelink transaction only isolated entities are read through the exclusive connection; for nonisolated entities, a new connection is acquired from the connection pool for each read and released back immediately after the query is executed.
# Always - Create an exclusive isolated client session (see Isolated Client Sessions) if reading an isolated Entity; otherwise, create an exclusive client session.
# Note: EclipseLink keeps the connection exclusive for the lifetime of the owning EntityManager and performs all writes and reads through the exclusive connection.
# For more information, see Configuring Connection Policy.
eclipselink.jdbc.exclusive-connection.mode=Transactional

# Profiler
# PerformanceProfiler – Use EclipseLink performance profiler (org.eclipse.persistence.tools.profiler.PerformanceProfiler class). For more information, see Measuring EclipseLink Performance with the EclipseLink Profiler.
# QueryMonitor – Monitor query executions and brokerCache hits (org.eclipse.persistence.tools.profiler.QueryMonitor class).This option provides a simple low-overhead means for measuring performance of query executions and brokerCache hits. You may want to use this option for performance analysis in a complex system.
# NoProfiler – Do not use a performance profiler.
# Custom profiler – Use your own custom profiler class. Create it by implementing the org.eclipse.persistence.sessions.SessionProfiler interface and providing a no-argument constructor.
eclipselink.profiler=NoProfiler
eclipselink.orm.validate.schema=true
eclipselink.exclude-eclipselink-orm=true

Then it is the jboss-persistence-xml.properties

jta-data-source=java:/yellowfire/ds
eclipselink.target-server=JBoss

#Note: Use this with application-scoped data sources
#<property name="javax.persistence.jtaDataSource" value="java:/app/jdbc/yellowfire" /-->
#Enable or disable EclipseLink's generation of database platform-specific SQL (as opposed to generic SQL).
# true – enable EclipseLink's generation of database platform-specific SQL.
# false – disable generation of database platform-specific SQL by EclipseLink.
eclipselink.jdbc.native-sql=true

# Logging
# OFF This setting disables the generation of the log output. You may want to set logging to OFF during production to avoid the overhead of logging.
# SEVERE This level enables reporting of failure cases only. Usually, if the failure occurs, the application stops.
# WARNING This level enables logging of issues that have a potential to cause problems. For example, a setting that is picked by the application and not by the user.
# INFO This level enables the standard output. The contents of this output is very limited. It is the default logging level if a logging level is not set.
# CONFIG This level enables logging of such configuration details as your database login information and some metadata information. You may want to use the CONFIG log level at deployment time.
# FINE This level enables logging of the first level of the debugging information and SQL. You may want to use this log level during debugging and testing, but not at production.
# FINER This level enables logging of more debugging information than the FINE setting. For example, the transaction information is logged at this level. You may want to use this log level during debugging and testing, but not at production.
# FINEST This level enables logging of more debugging information than the FINER setting, such as a very detailed information about certain features (for example, sequencing). You may want to use this log level during debugging and testing, but not at production.
# ALL This level currently logs at the same level as FINEST.
eclipselink.logging.level=INFO
eclipselink.logging.timestamp=true
eclipselink.logging.session=true
eclipselink.logging.thread=true
eclipselink.logging.exceptions=true

# Control whether or not the query uses parameter binding
# Note: Default is true
# true – bind all parameters.
# false – do not bind parameters.
eclipselink.jdbc.bind-parameters=false

# Specify the use of batch writing to optimize transactions with multiple write operations
# JDBC – use JDBC batch writing.
# Buffered – do not use either JDBC batch writing nor native platform batch writing.
# Oracle-JDBC – use both JDBC batch writing and Oracle native platform batch writing.
# Use OracleJDBC in your property map.
# None – do not use batch writing (turn it off).
eclipselink.jdbc.batch-writing=JDBC

# Enable or disable EclipseLink internal statement caching
# Note: Default is false
# Note: we recommend enabling this functionality if you are using EclipseLink connection pooling.
# true – enable EclipseLink's internal statement caching.
# false – disable internal statement caching.
eclipselink.jdbc.brokerCache-statements=true

# The number of statements held when using internal statement caching.
# Note: Default is 50
eclipselink.jdbc.brokerCache-statements.size=50

# Specify when a write connection is acquired lazily. For more information, see Lazy Connection Acquisition
# Note: Default is true
# true - aquire the write connection lazily.
# false - do not aquire the write connection lazily.
eclipselink.jdbc.exclusive-connection.is-lazy=true

# Specify when EclipseLink should perform reads through a write connection. For more information, see Exclusive Write Connections.
# Note: Default is Transactional
#
# You can set this property while creating either an EntityManagerFactory (either in the map passed to the createEntityManagerFactory method, or in the persistence.xml file), or an EntityManager (in the map passed to the createEntityManager method). Note that the latter overrides the former.
#
# The following are the valid values for the use in a persistence.xml file and for the org.eclipse.persistence.config.ExclusiveConnectionMode:
#
# Transactional - Create an isolated client session (see Isolated Client Sessions) if some or all entities require isolated brokerCache 4 ; otherwise, create a client session.
# Note: EclipseLink keeps the connection exclusive for the duration of the transaction. Inside the transaction, EclipseLink performs all writes and reads through the exclusive connection. However, outside the Eclipelink transaction, a new connection is acquired from the connection pool for each read and released back immediately after the query is executed.
# Isolated - Create an exclusive isolated client session if reading an isolated Entity; otherwise, raise an error.
# Note: EclipseLink keeps the connection exclusive for the lifetime of the owning EntityManager. Inside the transaction, EclipseLink performs all writes and reads through the exclusive connection. However, outside the Eclipelink transaction only isolated entities are read through the exclusive connection; for nonisolated entities, a new connection is acquired from the connection pool for each read and released back immediately after the query is executed.
# Always - Create an exclusive isolated client session (see Isolated Client Sessions) if reading an isolated Entity; otherwise, create an exclusive client session.
# Note: EclipseLink keeps the connection exclusive for the lifetime of the owning EntityManager and performs all writes and reads through the exclusive connection.
# For more information, see Configuring Connection Policy.
eclipselink.jdbc.exclusive-connection.mode=Transactional

# Profiler
# PerformanceProfiler – Use EclipseLink performance profiler (org.eclipse.persistence.tools.profiler.PerformanceProfiler class). For more information, see Measuring EclipseLink Performance with the EclipseLink Profiler.
# QueryMonitor – Monitor query executions and brokerCache hits (org.eclipse.persistence.tools.profiler.QueryMonitor class).This option provides a simple low-overhead means for measuring performance of query executions and brokerCache hits. You may want to use this option for performance analysis in a complex system.
# NoProfiler – Do not use a performance profiler.
# Custom profiler – Use your own custom profiler class. Create it by implementing the org.eclipse.persistence.sessions.SessionProfiler interface and providing a no-argument constructor.
eclipselink.profiler=NoProfiler
eclipselink.orm.validate.schema=true
eclipselink.exclude-eclipselink-orm=true

The persistence.xml template that is in the src\main\resources\META-INF look as follows.

<?xml version="1.0" encoding="UTF-8"?></pre>
<persistence version="2.0"
 xmlns="http://java.sun.com/xml/ns/persistence"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
 <persistence-unit name="yellowfire" transaction-type="JTA">

<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
 <jta-data-source>${jta-data-source}</jta-data-source>

${entityClassnames}

<properties>
 <!--property name="eclipselink.session-name" value="yellowfire"/-->
 <property name="eclipselink.target-server" value="${eclipselink.target-server}"/>
 <property name="eclipselink.target-database" value="SQLServer"/>

<property name="eclipselink.jdbc.native-sql" value="${eclipselink.jdbc.native-sql}"/>

<property name="eclipselink.logging.level" value="${eclipselink.logging.level}"/>
 <property name="eclipselink.logging.timestamp" value="${eclipselink.logging.timestamp}"/>
 <property name="eclipselink.logging.session" value="${eclipselink.logging.session}"/>
 <property name="eclipselink.logging.thread" value="${eclipselink.logging.thread}"/>
 <property name="eclipselink.logging.exceptions" value="${eclipselink.logging.exceptions}"/>

<property name="eclipselink.jdbc.bind-parameters" value="${eclipselink.jdbc.bind-parameters}"/>

<property name="eclipselink.jdbc.batch-writing" value="${eclipselink.jdbc.batch-writing}"/>

<property name="eclipselink.jdbc.brokerCache-statements" value="${eclipselink.jdbc.brokerCache-statements}"/>

<property name="eclipselink.jdbc.brokerCache-statements.size" value="${eclipselink.jdbc.brokerCache-statements.size}"/>

<property name="eclipselink.jdbc.exclusive-connection.is-lazy" value="${eclipselink.jdbc.exclusive-connection.is-lazy}"/>

<property name="eclipselink.jdbc.exclusive-connection.mode" value="${eclipselink.jdbc.exclusive-connection.mode}"/>

<property name="eclipselink.profiler" value="${eclipselink.profiler}"/>
 <property name="eclipselink.orm.validate.schema" value="${eclipselink.orm.validate.schema}"/>
 <property name="eclipselink.exclude-eclipselink-orm" value="${eclipselink.exclude-eclipselink-orm}"/>
 </properties>
 </persistence-unit>
</persistence>

And it is the maven-resources-plugin that makes all this magic possible 😉

<plugin>
  <artifactId>maven-resources-plugin</artifactId>
  <version>2.5</version>
  <executions>
    <execution>
      <id>persistence</id>
      <phase>process-test-classes</phase>
      <goals>
        <goal>copy-resources</goal>
      </goals>
      <configuration>
        <filters>
          <filter>${basedir}/src/main/filter/persistence-classes.properties</filter>
          <filter>${basedir}/src/main/filter/${application.server}-persistence-xml.properties</filter>
        </filters>
        <outputDirectory>${project.build.outputDirectory}/META-INF</outputDirectory>
        <resources>
          <resource>
            <filtering>true</filtering>
            <directory>src/main/resources/META-INF</directory>
            <includes>
              <include>persistence.xml</include>
            </includes>
          </resource>
        </resources>
      </configuration>
    </execution>
  </executions>
</plugin>

Create a free website or blog at WordPress.com.

Up ↑