Gyrex 1.3 Changelog

If you want to have a more detailed into what has changed with Gyrex 1.3, here’s the Changelog

gyrex 1.3 changelog (compared to 1.2)

– complete maven build support
– bundle directory restructuring
– fixed unit tests
– introduced SystemSetting concept for better property access (Gunnar)
– Console command for updating context service filters
– introduce try-with-ressources
– Job definitions by annotations
– inject job params and logger
– Support Jersey’s per request tracing using X-Jersey-Trace-Accept header
– make JMX connector start async
– add latency of jetty requests to log
– support WebServlet annotation in ScanningJaxRSApplication
– Gyrex admin ui: enhancements in job page
– Updates: Eclipselink 2.6, Gemnini JPA 1.2
– Jetty 9.1 Servlet 3.1
– Bug 411016: Introduce Solr cloud repositories and configuration
– distributed event bus
– Updates: RAP 2.3
– Bug 413417: Fallback to “invalid” if there is not job id on load
– Bug 432561: Compute and store node addresses in ZooKeeper
– websocket based event transport
– Update: Equinox 3.10

Advertisements

Gyrey 1.3. Release

As part of the Eclipse Luna release train the Gyrex development team has released version 1.3 of Eclipse Gyrex. Eclipse Gyrex is an cluster application framework on top of Equinox OSGi. It provides seamless and pain-free creation and operation of OSGi clusters.

With Gyrex 1.3. the following new functionality is available:

Distributed EventBus

With the EventBus it’s now possible to distribute events between cluster nodes. Events can be of any type, i.e. they don’t need to implement a specific interface or extend an abstract class. This allows for a broad set of use-cases supporting pojos as well as sophisticated objects entities. Out of the box, strings byte arrays and byte buffers are supported event types. The (de-)serialization of event objects is extensible so that any preferred serialization mechanism can be used. Event handling is supported using either annotations on any public method with a compatible signature or by implementing a handler interface. They will be triggered once events of those types are distributed. With the EventBus feature you can support use cases like cluster wide cache invalidation of local (in-process) caches.

Servlet 3.1 API and WebSockets in JAX-RS application

Gyrex applications are mainly focused on providing REST-API resources, but with 1.3 it’s now also very easy to provide web sockets in your application. In addition to JAX-RS annotated resources and provides, servlets annotated with @WebServlet will be found and deployed. Also based on annotations you can build web socket endpoints and once you’ve configured your application in the Gyrex Admin Console and map it to an URL, the web socket is available immediately on all cluster nodes.

Of course, servlets support dependency injection using the @Inject JSR-330 DI mechanism, which includes injection of tenant specific objects (in a multi-tenant environment) as well as OSGi service proxies.

New Editor for Gyrex Context preferences in Admin Console

The web-based Admin Console got a new editor for modifying Gyrex context preferences. Previously, it was possible to modify preferences from the Gyrex shell (via telnet or ssh). The new editor provides a generic way to manage the preferences in a browser and will help you to more easily introduce and use preferences in your application.

Dependency Injection in distributed Eclipse Jobs API

The development of batch processing using the Eclipse Jobs API now support dependency injection. Instead of implementing and providing a custom JobProvider, Gyrex provides a ScanningJobProviderComponent implementation which can be registered as an OSGi DS component by any bundle. The component will scan the registering bundle for Eclipse Jobs annotated with @JobType. The jobs instances will be created on demand and support dependency injection using the @Inject JSR-330 DI mechanism, which includes injection of tenant specific objects (in a multi-tenant environment) as well as OSGi service proxies.

Dependency updates

With Gyrex 1.3. we’ve updated many of the tools and dependencies we use in Gyrex. Most notably are the upgrades of Jetty 9.1,  RAP 2.3 and EclipseLink 2.5.

Download

Gyrex 1.3 can be downloaded here:
http://download.eclipse.org/gyrex/1.3/

For more information, support and contributor engagement please visit eclipse.org/gyrex.

How we do release engineering?

One of the challenging parts at Eclipse is doing the release engineering work. Large projects may have dedicated resources as well as well established processes. We don’t. However, I like the way the Eclipse project is doing their builds. They have (over simplified) a “version.properties” file that contains a list of bundles and a SCM tag to use. They are called map files and they drive the build.

For a long piece of Eclipse history, the map files were tagged manually by hand. Whenever a committer modified a bundle (aka. plug-in or feature). He also had to release those changes by tagging the bundle and updating the map file. When the Eclipse project migrated to Git they automated this process. A script is started before the real build begins. The script scans a branch for new commits since the last tag. If any new commits are found, the repository will be tag with a new tag and the map file will be updated.

I started migrating Gyrex to Git last week. The CVS to Git part was easy. Our build is running again. Thanks to an update to PDE Build it fully supports Git map files. Our process has always been as close to the Eclipse project as possible. We also use the map files which drive our build. We also used to tag our (CVS) projects by hand and we also used to update the map files by hand. Now with the change to Git we’ll also stop doing that.

I took the scripts from the Eclipse project and adapted them. We don’t run the script as part of our Hudson build job. Due to security concerns, the Hudson machines aren’t able to push changes back to Git repos. Thus, I run the tagging scripts on build.eclipse.org by cron. At the end of the run, a Hudson build will be triggered by the script via and Hudson API call.

You can find the scripts here:
gyrex-releng.git/tree/org.eclipse.gyrex.releng/builder/environments/build.eclipse.org/tagging