Blog of Adam Warski

Using Envers with AS7

Recently I tried deploying a web application which uses Envers into AS7, but unfortunately I encountered some problems (see the forum discussion). Luckily thanks to the helpful JBoss guys I’ve got it working now. Moreover, thanks to the work done by Strong Liu, you should see full Envers integration (included OOTB as a module) in AS7.1!

Until then, here’s how to use Envers in a webapp in AS7.

First, we need to create an Envers module. Create a directory: jboss-as-7.0.0.Final/modules/org/hibernate/envers/main and inside it, create a module.xml with the following content:

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="org.hibernate.envers">
  <resources>
    <resource-root path="hibernate-envers-4.0.0.Beta1.jar"/>
  </resources>

  <dependencies>
    <module name="org.hibernate"/>
    <module name="org.jboss.logging"/>
    <module name="org.dom4j"/>
    <module name="javax.api"/>
    <module name="javax.persistence.api"/>
    <module name="javax.transaction.api"/>
    <module name="org.javassist"/>
  </dependencies>
</module>

Moreover, you’ll need to put the Envers jar inside that directory. You can download it straight from the JBoss Maven repository.

I’ve prepared a ready zip of the module, which can be downloaded here. Just unpack its contents to jboss-as-7.0.0.Final/modules/org/hibernate.

Secondly, you must add an entry in your manifest file (META-INF/MANIFEST.MF) to make the new module available to your application:

Dependencies: org.hibernate.envers services

And you’re done. Enjoy! :)

Adam

Trying to understand CAP

The CAP theorem, stated by Brewer and proved by Gilbert and Lynch specifies a property of distributed systems. It states that such a system cannot guarantee at the same time Consistency, Availability and Partition tolerance. It is also often said as a catchy phrase:

Consistency, Availability, Partition Tolerance – pick any two

used mostly when talking about NoSQL databases and suggesting that a distributed system can be characterized as either CA, AP or CP (see e.g. here).

For some time I’ve been trying to understand the different combinations and what do they mean in practice; having some time at various airports I caught up on reading, and here’s what I came up with.

What’s C, A and P?

First let’s define how I understand the three guarantees, basing on some of the articles I’ve read.

Consistency is the easiest one. It roughly means that the clients get the same view of data. By saying that a system is consistent we often mean strong consistency, but it also can come in different flavors, e.g. casual.

Availability is a property saying that every request to a non-failing node will return a (meaningful) response. The response may not contain all data (so the harvest will not be 100%, see the appropriate section in [3]), but it should be useful for the client.

Partition tolerance means that the system will continue working even if any number of messages sent between nodes is lost. This can be e.g. a network failure between two datacenters, where nodes in each datacenter form a partition. Also note that a failure of any number of nodes forms a partition (it is not possible to distinguish between a network failure and a node failing and stopping to respond to messages).

The hardest part for me is understanding the difference between Availability and Partition tolerance. Also, the various articles don’t specify what they mean by saying that a system is “working” after being e.g. partitioned – does it mean that every request gets a response with useful data, or are responses “Sorry, I can’t give you data right now” acceptable also?

P+C?

Let’s assume that a system is partition tolerant and that it has more than one node. If a partition is formed, splitting the system in two, the system should continue working. Hence both partitions allow clients to write. But then, how to guarantee consistency? If one client writes to partition 1, and another to partition 2? Hence: P => ~C.

A+~P?

Suppose now that a system is available and that we have more than one node. As the system is available, it should respond to requests even if some nodes die. As noted above, some nodes dying are equivalent to a partition. So if the system is still working, we have partition tolerance. Hence: A => P.

A+C?

Summarizing the two implications above (A => P and P => ~C), we get: A => ~C, so that an available system cannot be consistent (if it has more than one node). In practice however, there are of course AC systems, e.g. single-node RDBMS. Or even master-slave/master-master replicated RDBMS, provided there’s a central router knowing which nodes live and directing client appropriately. Such a router is then a single point of failure (SPoF).

Relax?

I suspect that in reality, when e.g. NoSQL/NewSQL systems are characterized with the CAP properties, they assume some relaxed form of C/A/P. Unfortunately, all of the definitions flying around seem to be pretty vague and are more of hand-waving than proper, precise statements. I think it would be much easier to explore the ever-growing ecosystem of new datastores if they could be more easily characterized; maybe the CAP vocabulary is just not enough?

Please correct me if I’m wrong somewhere, and I probably am! :)

Adam

Some articles I used for my research:

[1] http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
[2] http://www.cloudera.com/blog/2010/04/cap-confusion-problems-with-partition-tolerance/
[3] http://codahale.com/you-cant-sacrifice-partition-tolerance/

Envers: track entity types changed in revisions

Łukasz Antoniak, who is a regular contributor to Envers (thanks!), recently finished working on HHH-5580, a feature which enables you to quickly retrieve the entity types that have been modified in a revision, by optionally storing them in a dedicated table.

Łukasz wrote an excellent tutorial on the subject, so if you are intersted, be sure to read it!

The feature described is available since the Hibernate 4.0.0.Beta2 release.

Adam

Static typing is a great static analysis tool

Statically-typed languages are great because, well, they have static typing. However very often developing using a dynamically-typed language is much more convenient. Take writing a webapp in Ruby On Rails – change some code, hit reload and you can see the new code in action. JavaScript – same thing. On the other hand change a bean in a JSF app: first redeploy (*), wait, and only then go and see the changes. Or even, run a very simple Scala unit test in IntelliJ – I don’t know why, but the compilation always takes a long time, even if the change is very minor. The total run time of the unit test far exceeds the milliseconds in which a unit test should run.

I know it’s in fact a compiled vs interpreted thing, but somehow statically-typed languages most often come in the “compiled” flavor, while dynamically typed in the interpreted one (**). I’m a huge fan of static typing, and I think static typing is the best static-analysis tool out there, but why shouldn’t it be left just at that: as a static analysis tool.

Moreover, the code is usually type-checked twice: first by the IDE (e.g. IntelliJ won’t let you run anything as long as there are errors, Eclipse I suppose does the same), then again by the compiler. Isn’t this a waste of time? If the modern virtual machines are so great at run-time optimization, is the compiler still needed, especially during development?

Adam

(*) Or just use e.g. JRebel; I think that JRebel is great, but I still view it as a huge hack on the JVM making our lives easier, rather than a “proper” solution to the redeployments problem.

(**) Scala takes a step in the “right” direction providing the REPL.

After Confitura 2011

Confitura 2011 went past very quickly, it was a great conference and a great occasion to meet with the polish Java community on the SPOINA after-party.

During the conference I had the opportunity to present two talks.

The first, done together with Tomek Szymański was an introduction to cloud computing using Amazon Web Services. We’ve explained how the basic services that Amazon offers (servers, load balancing, databases, queueing) work, and then did a live demo transforming a traditional hosted-server+JMS+JPA application into a version which uses EC2+SQS+SimpleDB. During the presentation we simulated heavy load on our application and started a couple of servers using the EC2 API to show that it scales nicely.

The full code of the (pretty simple) application used in the presentation is available here: https://github.com/softwaremill/aws-demo, and the slides (in polish) are here: http://t.co/nCDan5R.

The second presentation was about CDI Portable Extensions. First I did an introduction to CDI and then explained the idea behind Portable Extensions. The main part of the presentation was a live demo, where I showed how to create two extensions:

• dynamic alternatives – the extension was adding and removing the @Alternative annotation at run-time basing on some configuration file, allowing the application to dynamically choose an implementation of the bean that should be used
• dynamically creating beans which check if methods on a secure bean (secured with an interceptor) can be invoked (allowing the programmer to inject CanAccess<MyBean>)

Again, the full code of the demo extensions is available on GitHub: https://github.com/adamw/portable-extensions-demo and the slides (in polish) here: http://slidesha.re/lvx3hh.

And finally, a huge “thank you” to all of the conference organizers (Łukasz Lenart, Bartek Zdanowski, Tomek Szymański, Michał Margiel, Paweł Wrzeszcz, Sebastian Pietrowski and Jacek Laskowski), volunteers, sponsors and participants for putting together a great event!

Adam

CDI Portable Extensions on Confitura 2011

In less than two weeks (11th June) I will have the opportunity to present a talk on CDI & Portable Extensions during the Confitura 2011 conference, organized by the Warsaw JUG.

The talk will consist mainly of live demos, so fun! :)

I will show how to create two portable extensions:

• one which dynamically chooses which bean implementation will be available to the application
• second which creates new CDI (injectable) beans at startup, exposing some of the other bean meta-data

as well as how to implement “AOP++”. All tested with Arquillian.

All of the examples used in the talk are backed by real-life use-cases from applications created by my company, SoftwareMill.

The registration is over, but the conference is free, so if you know polish and will be in Warsaw, you are welcome to join!

Adam

Envers & TorqueBox on RivieraJUG – May 6th

This Friday (6th of May) I will have the pleasure to present two talks: one on Envers and one on Torquebox, thanks to an invitation from the RivieraJUG.

Envers is a data auditing/versioning module of Hibernate; with a single @Audited annotation all changes to the selected entity will be written and available for easy retrieval.

TorqueBox, which recently reached version 1.0, is a JBoss-based Ruby server, integrating the Ruby and Java worlds. JBoss services are exposed using Ruby APIs, and you can deploy both Ruby (including Ruby On Rails) and “traditional” JEE apps to the server.

Expect a lot of live demos! I will show how to use the basic functionalities of Envers to implement data auditing, some advanced features as well as how Envers maps data to its database schema. I will also roughly explain how Envers is built and what is needed to “build your own Envers” – it’s not as complicated as it looks, Hibernate offers a lot of not-well-known but powerful features.

In the Torquebox talk, we will create a simple Ruby On Rails application and deploy it to Torquebox. Later, we will add a java module which contains CDI beans (CDI is the new dependency injection framework in JEE6) and integrate the Ruby On Rails app with our CDI beans. Also, we will create a simple scheduler service using Torquebox’s API and an integration test of java module using Arquillian.

The meeting will be held at INRIA Sophia-Antipolis on 6pm. See the announcement for details.

And see you there! :)
Adam

DI in Scala: Cake Pattern pros & cons

I’ve been looking at alternatives for java-style DI and DI containers which would use pure Scala; a promising candidate is the Cake Pattern (see my earlier blog post for information on how the Cake Pattern works). FP enthusiast also claim that they don’t need any DI frameworks, as higher-order functions are enough.

Recently Debasish Ghosh also blogged on a similar subject. I think his article is a very good introduction into the subject.

Below are some problems I encountered with the Cake Pattern. (Higher-order functions are coming up in the next post.) If you have solutions to any of them, let me know!

Parametrizing the system with a component implementation

First of all, it is not possible to parametrize a system with a component implementation. Supposing I have three components: DatabaseComponent, UserRepositoryComponent, UserAuthenticatorComponent with implementations, the top-level environment/entry point of the system would be created as follows:

val env = new MysqlDatabaseComponentImpl
   with UserRepositoryComponent
   with UserAuthenticatorComponent

Now to create a testing environment with a mock database, I would have to do:

val env = new MockDatabaseComponentImpl
   with UserRepositoryComponent
   with UserAuthenticatorComponent

Note how much of the code is the same. This isn’t a problem with 3 components, but if there are 20? All of them but one have to be repeated just to change the implementation of one component. This clearly leads to quite a lot of code duplication.

Component configuration

Quite often a component needs to be configured. Let’s say I have a UserAuthenticatorComponent which depends on UserRepositoryComponent. However, the authenticator component has an abstract val encryptionMethod, used to configure the encryption algorithm. How can I configure the component? There are two ways. The abstract val can be concretized when defining the env, e.g.:

val env = new MysqlDatabaseComponentImpl
   with UserRepositoryComponent
   with UserAuthenticatorComponent {
   val encryptionMethod = EncryptionMethods.MD5
}

But what if I want to re-use a configured component? An obvious answer is to extend the UserAuthenticatorComponent trait. However if that component has any dependencies (which, in the Cake Pattern, are expressed using self-types), they need to be repeated, as self-types are not inherited. So a reusable, configured component could look like this:

trait UserAuthenticatorComponentWithMD5
         extends UserAuthenticatorComponent  {
   // dependency specification duplication!
   this: UserRepositoryComponent =>
   val encryptionMethod = EncryptionMethods.MD5
}

If we don’t repeat the self-types, the compiler will complain about incorrect UserAuthenticatorComponent usage.

No control over initialization order

A problem also related to configuration, is that there is no type-safe way to assure that the components are initialized in the proper order. Suppose as above that the UserAuthenticatorComponent has an abstract encryptionMethod which must be specified when creating the component. If we have another component that depends on UserAuthenticatorComponent:

trait PasswordEncoderComponent {
   this: UserAuthenticatorComponent =>
   // encryptionMethod comes from UserAuthenticatorComponent
   val encryptionAlgorithm = Encryption.getAlgorithm(encryptionMethod)
}

and initialize our system as follow:

val env = new MysqlDatabaseComponentImpl
   with UserRepositoryComponent
   with UserAuthenticatorComponent
   with PasswordEncoderComponent {
   val encryptionMethod = EncryptionMethods.MD5
}

then at the moment of initialization of encryptionAlgorithm, encryptionMethod will be null! The only way to prevent this is to mix in the UserAuthenticatorComponentWithMD5 before the PasswordEncoderComponent. But the type checker won’t tell us that.

Pros

Don’t get me wrong that I don’t like the Cake Pattern – I think it offers a very nice way to structure your programs. For example it eliminates the need for factories (which I’m not a very big fan of), or nicely separates dependencies on components and dependencies on data (*). But still, it could be better ;).

(*) Here each code fragment has in fact two types of arguments: normal method arguments, which can be used to pass data, and component arguments, expressed as the self type of the containing component. Whether these two types of arguments should be treated differently is a good question :).

What are your experiences with DI in Scala? Do you use a Java DI framework, one of the approaches used above or some other way?

Adam

Envers and Hibernate 4.0.0.Alpha2 – automatic listener registration

Development of Hibernate4 is well under way, with the Alpha2 version released recently. It contains one major improvement which is quite significant for Envers, namely Integrators (see HHH-5562 & HHH-6081).

Using this mechanism it will no longer be necessary to add the 6 event listeners to your Hibernate configuration – all that is needed for Envers to work is to put it on the classpath! If any of your entities are annotated with @Audited, they will get audited automatically (any changes will be written to the history tables).

It is of course possible to turn off the automatic registration, as well as write your own integrators, which automatically register custom event listeners. The integrators are discovered using java’s service loader, by the presence of a META-INF/services/org.hibernate.spi.Integrator file in the jar, which should contain the name of the class implementing the integration functionality.

Adam

Ruby on Rails + CDI/Weld on Torquebox example app

For almost a year we’ve been successfully using Torquebox together with CDI/Weld as a base for two of our services: JBison and Circular. As we’ll be doing some presentations together with Tomek Szymański we’ve created a small application showing our setup and the CDI<->RoR integration.

The code is available on GitHub: https://github.com/softwaremill/trqbox-demo together with a readme explaining the modules, how to run the application and how to re-create it. Hope it will be helpful.

The application consists of two main modules: the backend and the frontend.

The backend is written using Java and CDI/Weld for dependency injection and management. Here we can use the whole power of CDI, with extensions, interceptors, producers etc. Also nothing stops us from using other JEE components (e.g. EJBs, JAX-RS, servlets), as Torquebox is built on JBoss AS 6, and the deployed application behaves more or less like a .war.

The frontend, on the other hand, is done purely in Ruby on Rails (plus some Javascript). For frontend development static typing is more often an obstacle than help; also, the fact that all changes are immediately visible (no redeploying etc.) is a great gain. Moreover (at least for me) doing rich ajax apps is much easier in RoR than when using e.g. JSF.

To bind the frontend and the backend, with the help from some infrastructure we can “inject” CDI beans into Rails controllers or an arbitrary Ruby class (which runs on JRuby, same JVM), e.g.:

class MyController < ApplicationController
  include_class "pl.softwaremill.demo.HelloWorld"

  def index
    @data = inject(HelloWorld).compute_data
  end
end

So we can easily call our business logic to obtain data that should be displayed or trigger an action. Currently this works as a service locator, but thanks to some feedback from the Poznan JUG presentation we had this week I’ve got some ideas on improving it.

Our normal cycle of development is the following: first we develop the backend, using unit tests and Arquillian (integration tests) to verify that the beans behave as they should (if, for example, there are some new entities or queries, we test them using DB test). When this is done, we can deploy our new beans and proceed with writing the frontend.

This results in pretty fast development and little time spent waiting for the AS to boot. Plus the pleasure of using something new and unconventional ;).

Many thanks to Bob McWhirter and the whole Torquebox team as well as to Ales Justin for helping to solve some MC-related problems.

Adam