The Curious Case of tracing Java Serialization NotSerializableException

I say curious, because Java Serialization has been around for a very long time, and yet I could not find any tools to help track down exactly where the NotSerializableExceptions were coming from.

Yes, of course, the stack trace tells you which class has caused the offence, but even in a mildly complex object graph, the source of the error can be tough to find.

So in the end, I wrote SerializationTracer, which walks through the object graph being serialised and identifies objects which fail or succeed in serialising.  Null fields and empty collections are assessed with some static analysis.

The output looks like this:

UIScope -> SerializationResult(outcome=FAIL, info=java.io.NotSerializableException: com.google.inject.Key)
UIScope.cache -> SerializationResult(outcome=FAIL, info=java.io.NotSerializableException: com.google.inject.Key)
UIScope.cache.comparator -> SerializationResult(outcome=NULL_FAILED_STATIC_ANALYSIS, info=Comparator is NOT Serializable. ? super K is NOT Serializable.)

The first part of each line points to the exact field causing the problem, using an object 'path' - pretty trivial in the example above, but of course that could extend a long way down into a deep object graph.
It was designed with testing in mind, but we are now thinking of putting it into 'production' - that is, trapping a failed session serialisation, and using SerializationTracer to give us a more coherent understanding of the source of failure.

RestEasy with embedded Undertow

Keeping it really easy

There is pretty good documentation for RestEasy and Undertow, but piecing together the Gradle dependencies for that combination eluded my for a while.

So very simply, this is it ... the Gradle dependencies, and a test (the test is translated to Spock from the example in the RestEasy docs)

build.gradle dependencies:

   compile 'org.jboss.resteasy:resteasy-jaxrs:3.1.0.Final'  
   compile 'org.jboss.resteasy:resteasy-undertow:3.1.0.Final'  
   compile group: 'io.undertow', name: 'undertow-core', version: '1.4.8.Final'  
   compile group: 'io.undertow', name: 'undertow-servlet', version: '1.4.8.Final'  

the test

 class MyAppTest extends Specification {  
   
   @Path("/test")  
   public static class Resource  
   {  
     @GET  
     @Produces("text/plain")  
     public String get()  
     {  
       return "hello world";  
     }  
   }  
   
   @ApplicationPath("/base")  
   public static class MyApp extends Application  
   {  
     @Override  
     public Set<Class<?>> getClasses()  
     {  
       HashSet<Class<?>> classes = new HashSet<Class<?>>();  
       classes.add(Resource.class);  
       return classes;  
     }  
   }  
   
   static UndertowJaxrsServer server  
   
   Client client  
   
   def setupSpec() {  
     server = new UndertowJaxrsServer().start();  
   }  
   
   def setup() {  
     client = ClientBuilder.newClient();  
   }  
   
   def cleanup() {  
     client.close();  
   }  
   
   def cleanupSpec() {  
     server.stop();  
   }  
   
   def "testApplicationPath"() {  
     given:  
     server.deploy(MyApp.class);  
   
     when:  
     String val = client.target(TestPortProvider.generateURL("/base/test")).request().get(String.class);  
   
     then:  
     val == "hello world"  
   }  
   
   def "testApplicationContext"() {  
     given:  
     server.deploy(MyApp.class, "/root");  
   
     when:  
     String val = client.target(TestPortProvider.generateURL("/root/test"))  
         .request().get(String.class);  
   
     then:  
     val == "hello world"  
   }  
   
   def "testDeploymentInfo"() {  
     given:  
     DeploymentInfo di = server.undertowDeployment(MyApp.class);  
     di.setContextPath("/di");  
     di.setDeploymentName("DI");  
     server.deploy(di);  
   
     when:  
     String val = client.target(TestPortProvider.generateURL("/di/base/test"))  
         .request().get(String.class);  
   
     then:  
     val == "hello world"  
   }  
 }  

Spock the Difference

Back to Testing

It is quite a while ago since I blogged about testing (or about anything else ...) but my last post on the subject concluded that AssertJ was the best option, for me at least.

I was using AssertJ with Mockito and the Mycila runner to support Guice. I was generally happy with that combination, although there were one or two odd syntactical problems in the transition from Java 7 to 8.

And then there was [Spock](http://spockframework.github.io/spock/docs/1.0/index.html).

First thoughts

I'm not even sure why I tried Spock in the first place - I didn't think there was anything especially wrong with the libraries I was using.

I also have to admit I am not a huge fan of Groovy in itself, although I am using Gradle (also written in Groovy of course) more and more.  The power of Groovy, though, is when it is used to provide a well designed DSL.

Spock demonstrates this really well, so I gave it a try ... this post is a quick overview of my experience, based on several months of use.  I am not trying to cover all of Spock's functionality here, but I can say that I have not found anything yet which the AssertJ/Mockito combination could do that Spock cannot do.

The "classic" approach

Using the AssertJ/Mockito approach, a trivial test might look like this

 @Test
 public void doTest() {
 
   //given
   objectUnderTest.prepare(5);
   when(mockCollaborator.getStatus()).thenReturn("x");
 
   //when  
   objectUnderTest.doSomething();
 
   //then
   assertThat(objectUnderTest.getState()).isEqualTo("OK");
   assertThat(objectUnderTest.isActive()).isTrue();
   verify(mockCollaborator, times(2)).getStatus();
 }

The Spock approach

The equivalent in Spock would look like this:

 def "prep value 5, Out returns OK and calls collaborator twice"(){  
   given:  
   objectUnderTest.prepare(5);  
     
   when:  
   objectUnderTest.doSomething();  
     
   then:  
   objectUnderTest.getState().equals('OK')  
   objectUnderTest.isActive()  
   2 * mockCollaborator.getStatus() >> 'x'  
 }  

There are a few things to note:

1. The name of the test, which also appears in the test results, is far more expressive
2. The given / when / then causes are part of the DSL, not just comments, and will tell you if you have got it wrong
3. The static imports have all gone
4. The comparison methods in the 'then' clause are all 'native'
5. The last line of the 'then' clause is an example of the one thing that may trip you up.  It is saying that the mock is expecting to be called twice, and will return a value of 'x' on both occasions.

Spock processes mock interactions in a different way to Mockito, and that can cause some misunderstandings when migrating from one to the other.  It is worth reading that part of the documentation thoroughly.

Not much difference?

At a quick look, apart from being neater, there does not seem to be a massive difference.  In practice, though, I have found that neatness very productive ... even with code completion, 'assertThat  .. isEqualTo' is a bit cumbersome, where using the native comparison methods is far more fluent.

The failure output from Spock is also an improvement on the classic approach, giving a better indication which part of a check has failed:

Condition not satisfied:
stack.size() == 2
|     |      |
|     1      false
[push me]

The only thing I miss are the collection methods of AssertJ - containsOnly(), containsExactly() - for example.  But if I miss them too much, I can still use them in Spock.

Oh, and the Spock data driven tests are neat ...

Conclusions

Spock seems to be one of those tools which grows on you very quickly.  At first, it seemed that its advantages were not that great, but after just a few days, the increase in fluency and productivity convinced me that the change would be worthwhile.

I don't generally convert existing tests unless they need major modification, but conversion is not difficult either.

Now, Spock is all I use in [Krail](https://github.com/davidsowerby/krail) for new unit, and usually integration testing ... and on the rare occasion when I add a test method to existing JUnit tests, the  "classic" method feels very clunky.

The learning curve for Spock is not steep - I just found that the way interactions are used take a little bit of getting used to, but the end result is extremely powerful.

If you are writing tests - I would strongly recommend that you give it a go.  And if you are not writing tests ... well, it might be a very good idea to start :-)

Gradle Multi-Project structure

I am using a combination of Gradle, Github and Bintray for Krail ... probably a popular combination.

I originally had a single Github repository with a Gradle multi-project setup for a number of libraries.

I had been thinking of breaking out some of the libraries anyway, but Bintray really needs a Github repository per library, so with some regret, I broke up the multi-project into single projects.  The regret was because I thought I needed a directory hierarchy to support a Gradle multi-project.

Now I didn't really want to maintain several build files, all very similar, and just as I expected, a pain to keep up to date.

So I went back to the excellent Gradle documentation looking for inspiration, but it still took a while to work out what I needed to do.

I read the Multi-Project Java build and Multi-Build Projects sections again, but still couldn't find an answer to making the build work across a flat directory structure, with the root project at the same directory level as its subprojects.

Eventually I stumbled on the answers, and they are in the documentation - just that I didn't find them the easy way.  So if you are Gradle, Github and Bintray together, for a multi-project build, this is what you need:

Settings.gradle

In the settings.gradle file, which must be in your root project directory, you define your sub-projects with include statements ... but you are not limited to a hierarchical structure.  You can code any structure you like (coding in a settings file is a bit unusual, too).  Ironically, the first example I found was in the Gradle repository on Github (not in the structure I wanted, but it demonstrates the feature).

My own example looks like this:

include 'krail'include 'krail-jpa'include 'krail-demo'include 'krail-testApp'include 

'krail-testUtil'include 'krail-quartz'include 'krail-bench'include 'q3c-testUtil'


rootProject.children.each {project ->

 String fileBaseName = project.name String projectDirName = '../'+fileBaseName
 project.projectDir = new File(projectDirName)

// for example, makes it krail.gradle project.buildFileName = "${fileBaseName}.gradle"

//make sure it exists assert project.projectDir.isDirectory()
 assert project.buildFile.isFile()
}

All this does is map each of the sub-projects at the same directory level as the root project - it also points to *.gradle files which are named the same as their projects (so krail-jpa.gradle for the krail-jpa project). This is to avoid having multiple "build.gradle" files in the IDE, which can be confusing.

Now this almost worked, except I couldn't run the sub-projects from their own directories, I had to call grade from the root project directory.

There must be a master

This time I did find the answer in the documentation, but in the Build Lifecycle section, when I was looking for something else!

....if you execute Gradle from within a project with no settings.gradle file, Gradle looks for a settings.gradle file in the following way:

• It looks in a directory called master which has the same nesting level as the current dir.
• If not found yet, it searches parent directories.
• If not found yet, the build is executed as a single project build.
• If a settings.gradle file is found, Gradle checks if the current project is part of the multiproject hierarchy defined in the found settings.gradle file. If not, the build is executed as a single project build. Otherwise a multiproject build is executed.

For my scenario, all I needed to do was to rename my root project directory as master ... and now I can execute tasks sub-projects from their own directories.

Moving sub-projects in Git

When I started this project I didn't actually know I was starting a project - it was going to be a template application for Vaadin 7, and the sandbox name I gave it was "V7".

I finally got round to changing the name, and decided to go through a major refactoring exercise at the same time.

I had a multi-project set up with a single Git repository and a master repo on Github.

Managing a multi-project set up is simple with the combination of Gradle, Git and IDEA that I use.  There's a Gradle plugin for Vaadin, too, to make life really easy. 

However, I decided I would separate sub-projects into their own repositories .. mainly to provide logical separation, but also because some of the experimental sub-projects will never be completed.

I wasn't looking forward to the task, thinking it would end up in some complex Git manipulation, but I was pleasantly surprised.  

The method described here, works extremely well - and it keeps your Git history.  The only issue I had was IDEA occasionally re-creating references to sub-projects that I had deleted - I'm not sure what was going on there, but I eventually cleared them.

The final step was to "promote" one remaining sub-project to become the main project, in the existing repo.  This again proved straightforward.  Git is quite happy for you move files around, or rename the local repo, as I did, as long as you don't modify the content of the files at the same time.

And finally, Github makes it really easy to change the name of your repo, even re-directing your original URL to the new one.

It makes a change for something you expect to be complicated to turn out to be easy ...

Eclipse to IDEA

Why consider a change?

I have been using Eclipse for many years, and still really only used a small part of its capability.  I had always been reasonably happy with it, despite the occasional issues, I fully appreciated the fact that I was using free software (although I did make a couple of small donations).

But a couple of years ago I started getting problems with its interactions with Ubuntu.  Now to be fair to Eclipse, some of the underlying issues were almost certainly outside Eclipse itself  ..  but I had been losing time from menus disappearing and SWT related random crashes for a long time.

At a suitable break point in developing V7,  I decided to upgrade to Eclipse Luna.  Initially I thought all was well, but when some (but not all) menus stopped working I admit I just lost patience.

So I tried Intellij IDEA.

Making the Change

I knew of course that changing from something very familiar would be a bit of a challenge, so naturally I started with the Community Edition of IDEA.  

Trying to do some very simple things took time, because I had to find out how to do them.  Now the IDEA documentation is pretty good, but sometimes you just have to know the right words to find what you are looking for.

It wasn't helped because I only code in my spare time - my current day job doesn't require it - so I was forgetting new things between sessions.  But I resolved to be patient and give myself a chance to find my way around ...

For reasons I can't explain, I find I use keyboard shortcuts more than I did on Eclipse.  Ironically, if I had used shortcuts more on Eclipse the changeover may have been easier as you can select an Eclipse key mapping for IDEA.

Anyway, after a bit of early frustration just getting used to the differences, I came to like IDEA, and I've been using it for about 3 months now.  The biggest single reason is still that it doesn't crash, or have quirky menu issues.  

My favourite feature is the Live Templates - much more powerful than the Eclipse equivalent and can be a real time saver by generating code for your common coding patterns.

I like the Gradle integration too .. with Eclipse I always used the command line for Gradle, it was just easier.  No great problem, but Gradle actually just feels like part of IDEA.

Of course there isn't the huge array of plugins that Eclipse has available, but even so, there are quite a few;  it seems that most, if not all, of the common requirements would be covered.

Paying the Price

Now the Community Edition is only for pure Java, and for a while that was enough.  But it doesn't take long before you stray into needing the licenced (called 'Ultimate') version.  In my case, I wanted to run a web app on Tomcat, which isn't supported via the Community Edition.

So then I was faced with buying a licence, or returning to Eclipse ... and the licence would cost more than I had contributed to Eclipse. 

I decided to go ahead, still mainly because of stability, but also because I keep finding features, often quite small in themselves, which just make coding a bit easier ... and I am fortunate enough to be able to afford a personal licence.

I must admit though, that I still feel a bit guilty about leaving Eclipse  ... I've always been a keen supporter of the open source movement.

Vaadin, Guice and Quartz

Progress

I can't believe it is so long since I posted to this blog.  I guess I must have been busy!

Those who have read previous posts will know that I have been working on a project called V7 to provide Vaadin, Guice and Shiro integration, with some I18N and navigation support thrown in.

Making Time(r)?

Quartz has become a popular scheduler for Java, and I wanted something to test my V7 design to ensure that I could integrate and add in a library without too much difficulty.

I have recently committed an implementation for this, so there now also an optional V7 library for Quartz, already integrated with Guice.

Observations

I do find some of the Quartz API a little strange, but despite that the integration seems to be fairly robust.  And to be fair, I guess Quartz is popular for a reason - it works!

One thing which I find strangely missing (and I know I am not alone) is the ability to define dependencies between jobs.  

But .. it works, and is now integrated with V7.

JUnit asserts and assertThat

Keeping it simple

Now let's be honest, how many of us enjoy writing tests?  They are pretty tedious, even if some of the results are a bit of a surprise!  After all, the last thing we want is for writing tests to be a challenge - as soon as that happens, the test code is likely to need as much debugging as the code under test.

So the simpler it is to write clear tests the better ...

The path to fluency

Like most developers, I started off using JUnit's Assert methods ... assertEquals, assertTrue etc.  I went to TestNG for a while, and frequently got the expected and actual values the wrong way round.

A while ago, I found Fest "fluent" assertions, then at version 1.4.  I was much happier with that, and found that the claim to fluency was generally valid, and certainly led to more meaningful test failure messages.

But 1.4 was being retired, and 2.0 under development.  I tried early versions of 2.0 and there seemed to be some issues with type recognition, requiring some odd casting.  To be fair, these were milestone versions of Fest and these issues may have been fixed before 2.0 was released.

In the meantime I stumbled across the native JUnit assertThat() method, with Hamcrest matchers, being shipped with JUnit.  I hadn't noticed when this was first released, but I thought it may be a good time to migrate back to native JUnit.

Er, no. It wasn't.  Although the intent of JUnit assertThat() is similar to Fest, I quickly found that I was getting tangled up with the syntax, even allowing time for changing away from Fest.  I then found AssertJ, a fork from Fest 2.0 which seems to be more open to extending what can be "asserted".  So that's where I've ended up, and I am back to being nearly fluent again.

So what's the difference?

It's actually quite hard to quantify why I prefer AssertJ/Fest 2.0, except that it feels more natural - and it does seem that IDE auto-complete gets better results.  This is all purely subjective, and you may find it otherwise.

Fest 2.0 is practically identical in use to AssertJ, but AssertJ seems to be more open to extending the library... and let's face it there are plenty of things to test. 

Having said that, I am certain that all the assertThat() implementations (AssertJ, Fest, Hamcrest) are far more readable (and writeable)  than the original JUnit  Assert statements and all can be extended with custom matchers.

So if you want get more out of writing tests, I'd recommend giving AssertJ a try ... and if you are still using assertEquals, definitely give at least one of the assertThat() implementations a try.

Running a single test in Gradle

Although very simple I had trouble finding the syntax for this.

gradle -Dtest.single=MyTest test

Vaadin 7, Views and a Sitemap (part 2)

Time Flies

I can't believe it is so long since I last posted.  Holidays come and go, and eventually the sun came out.  In my part of the northern hemisphere anyway!

Progress

I described the idea of a Sitemap to define the structure of a site in my last post.  I did actually then get round to writing the documentation - and rather unusually wrote it before developing the code.

I won't repeat that documentation here, hopefully that is clearly enough written (although questions and feedback are always welcome either here or on the forum).

So I now have a Sitemap and associated options, which can be used to generate a set of standard pages, mostly to to with user account management.  More importantly, it lets you describe the structure of your site fairly simply - making good use, I believe, of the main components of Vaadin, Guice and Shiro to simplify development.

It comes with a user navigation tree, created automatically from the Sitemap to enable the user to find their way around.  Eventually, there will also be a breadcrumb to go with it ...

Tutorial

I am in the process of creating a tutorial, which I hope will make things even clearer ....

Vaadin 7, Views and a sitemap

The Start Point

I needed to start on another application - a small one, but one which would benefit from the work I had done on V7.  So I started to build the app (and re-write some of the documentation, of which there is still more to do).

I was quite pleased with the speed with which I had a skeleton app with the core features of V7.

But I dislike writing the same code twice (or writing code once which has already been written and tested by someone else!)

I should say here that I still think Vaadin is a great product, I am just building on it for a particular set of, hopefully, common use cases. 

The "Problem"

When I looked at how I had structured V7, I could see that I was in danger of duplicating page related definitions.   There was still a strong chance of mismatches occurring between URL and View mapping, and navigation components.  And in my view, anything dependent on accurate typing of String literals is likely to cause a maintenance problem at some point.

I felt it was an improvement on the standard Vaadin 7 - but there was room for improvement. 

The Idea

The idea, then was to abstract out the structure of the site into a sitemap.  A sitemap is hardly revolutionary, but in this case it is an input rather than an output.  It acts as the specification of page layout and includes:

URL to View mapping

Packages which contain Views

URL redirection

I18NKey selection

and a fairly comprehensive report

Report

The report identifies a number of sitemap error conditions - things like missing Views, I18NKeys, redirection loops.

Generation

To be honest "Generation" is not strictly the correct word - there is no code generation, but I cannot think of a better term.  

The sitemap created from sitemap.properties is used in a Guice module to map URLs to Views, and is of course available for injection wherever needed.  One obvious use - and the reason I started on this track - is  to use the sitemap with navigation controls.

The sitemap.properties file gives quite a good description of what is needed, but yes, I need to get working on the documentation, too. 

Vaadin 7 I18N - part 2

Completing the I18N Picture

For some reason I forgot to post the fact that I did complete the I18N task I set myself.  Perhaps because it was not quite as difficult as I expected.

When I looked at some of the new Vaadin 7 code, I discovered that the FieldGroup class provided much of what I needed.  (FieldGroup is the successor to the Vaadin 6 Form - and in my opinion, substantially better).

So within V7 now is a reasonably complete I18N approach, though seriously lacking in translations.  For that reason I have not yet added a facility in the demo to switch locales.

Vaadin and I18N

With or Without Guice

If you have read earlier posts, you will know that my V7 project uses Guice.  The I18N implementation I have developed so far does not use Guice a great deal and would be easy to extract to another DI framework, or manual injection.

Approach

I was trying to come up with a design that would simplify some of the repetitive nature of coding for I18N support.  I came to the conclusion that I would actually need two methods which can be used together, as the developer decides.  The documentation gives a better explanation, but I've summarised it in this post.

Using Annotations

Annotations would seem to be quite a neat way to support I18N.  It means that the I18N key is defined alongside the component to which it relates.  There are limitations, however, particularly if you are using translations with parameters, as there is no easy way to define the parameter values to be used.

I have completed the implementation of the annotation based implementation, and it works quite well for many circumstances.  That includes nested components which also need I18N support.  Vaadin tables also need a little special handling because of course, the column headings would normally be translatable.

The code for this is still in the develop branch, but has reasonably well tested.

Using field factories

There also seems to be an opportunity to provide I18N support using the FieldFactory approach provided by Vaadin.  I haven't started on this work yet.

Alternative Java MessageFormat

MessageFormat

I was working on providing I18N support in my Krail project, when I was reminded of the strange characteristics of the standard Java MessageFormat class (java.text.MesssageFormat) ... especially the handling of single quotes.

I thought maybe it had been improved in Java 7, but it seems not.  The javadoc still carries a warning:

Warning:

The rules for using quotes within message format patterns unfortunately have shown to be somewhat confusing. In particular, it isn't always obvious to localizers whether single quotes need to be doubled or not. Make sure to inform localizers about the rules, and tell them (for example, by using comments in resource bundle source files) which strings will be processed by MessageFormat. Note that localizers may need to use single quotes in translated strings where the original version doesn't have them.

The Alternative

I remember being thoroughly confused by MessageFormat and the "solution" offered by the javadoc hardly helpful.  So I started looking for an alternative.  I found quite a few posts also looking for alternatives but still no real solution.  

So I wrote one ... it is based on sl4j, who have a highly tuned message handling routine for logging but which requires the parameter values to be provided in the same order as the message parameters.  That makes perfect sense for logging, but does not work very well for I18N, where different languages put the parameter values in different orders.

So I took the easy option of providing my own MessageFormat class to take the parameters in any order, but then organise them so that the sl4j MessageFormatter can do its work.

The resulting code is here, and its companion test code here.  Even if you have no interest in the Krail project, you may find the alternative MessageFormat useful.

OrientDB deployment

Publishing the V7 Demo

Demo now available 

There is now an online demo of V7.

Last minute snag

I has a situation where everything worked on my desktop, but when deployed to a virtual server, connection to the OrientDB database was being refused.  The error I was getting was:

java.lang.IllegalStateException: Node id is possible to generate only on machine which have at least one network interface with mac address.

at com.orientechnologies.orient.core.util.OHostInfo.getMac(OHostInfo.java:48)

at com.orientechnologies.orient.core.version.OVersionFactory.<clinit>(OVersionFactory.java:32)

at com.orientechnologies.orient.core.storage.impl.local.OTxSegment.<clinit>(OTxSegment.java:68)

at com.orientechnologies.orient.core.storage.impl.local.OStorageLocalTxExecuter.<init>(OStorageLocalTxExecuter.java:53)

at com.orientechnologies.orient.core.storage.impl.local.OStorageLocal.<init>(OStorageLocal.java:111)

at com.orientechnologies.orient.core.engine.local.OEngineLocal.createStorage(OEngineLocal.java:44)

It turns out that my OpenVZ virtual private server (VPS) does not allocate a MAC address - which is why the failure occurred.

This does raise the question why a single node database needs a MAC address, but apparently this question had already been asked - the fix for it was in the latest snapshot.

So, I've updated the code to use OrientDB 1.4.0-SNAPSHOT and that problem is solved.

Enjoy the demo (but I will admit it does not look as good as the Vaadin 7 demo ....)

Vaadin 7 released

Vaadin 7.0.0

It's great to see the Vaadin 7 release finally hit the streets.  I have updated the V7 code to use Vaadin 7.0.0, without any problems.

Demo

I had intended to provide an online demo, and have a server (a VPS to be more specific) all set up and ready to go - but then I ran into a problem with persistence (or to be more accurate, with the VPS set up which is affecting persistence) , so it will have to wait.  Hopefully not for long though.

Persistence

When I started putting the online demo together, I thought it would be interesting to log whether anyone interacts with it.   That meant providing some persistence, so I brought forward my intention to use a database.

I elected to try OrientDB, partly because it provides Object, Graph and Document database options in one.

I will post separately about that experience - but the main obstacle I found was their documentation.  Some of it is quite good, some not so good, but if you Google for it you can very easily end up with different versions of it.  They seem to have moved their code hosting around a bit.

Anyway, if you do want to take a look, do make sure you start the documentation trail here.

It is very early days, and I have only done some trivial tasks with it, but at first sight this database looks simple to use.

Lazy-loading

One thing which did catch me out is the lazy loading of data  ... and it is entirely my fault, as the documentation does say quite clearly that's how it works ... but I fooled myself by looking for values in the debugger;  they were not there of course, because they do not appear until the associated getters are called.

Definitely an RTFM moment that one ....

V7 - Vaadin 7 RC2 Guice and Shiro

Vaadin RC2

I have updated the code to Vaadin 7 release candidate 2, with no issues found.  There was a bug in beta 11 using Chameleon styles, but that is now fixed.

Testing

I've improved the test harness a bit - it pretends now to be a Shiro Web environment, so Shiro generates things like ShiroWebSubject correctly.  This allows a bit more testing within JUnit.

There is a bug in one of the tests - the LoginStatusPanelTest is not configured correctly - but testing is gradually improving overall.

Standard Pages

I have introduced the idea of standard "pages" for things like login, logout and others, to help with some of the Shiro logic.  It is still configurable, so any View could be used to create the "page".

The documentation is still some way behind, and the forum unused, but at least one person contacted me to say they had found it useful.  It is always good to get feedback ...

Vaadin Guice and Shiro - done

Progress

I got there eventually - there is now a working version of the V7 code, which integrates Vaadin 7, Guice 3.0 and Apache Shiro 1.2. 

V7 supports the direct coding of interaction with Shiro, and also the use of Shiro annotations.  If you are not familiar with Shiro then it is worth taking a look.  It greatly simplifies one of those time-consuming development tasks - authentication and authorisation.

Path filtering

The one aspect I have not been able to integrate is the Shiro path filter to apply security according to the URL.  A great idea, and something which could greatly reduce maintenance, but clearly will not work with an AJAX application.

I need to do some more work on that ...

General code state  

I have done quite a bit to tidy up the code, especially for testing.  The test harness is reasonable now, and allows quite a bit of testing of the Vaadin UI, and also incorporates Shiro.

But pretty it is not!  I really have not done justice to Vaadin with the user interface, but just now I am more concerned about function.

Sadly, the documentation  has fallen behind a bit, but I have opened a forum for anyone interested. Comments at the forum, or on this blog would be welcome.

Vaadin, Guice and Shiro

Formalising

Once I made some progress integrating Apache Shiro, I realised that what started as an experimental integration of Vaadin and Guice is becoming a rather more substantial project - something for me to use as a base for future applications, and maybe something others could use too.

So I have started formalising things a bit more.  I've started some documentation, partly to clarify my thoughts, but also to share with anyone who is interested.

The code is still in the same place, but I will start using a proper branching model so that the master branch becomes more stable  - until now I haven't been concerned about that.

Shiro

The integration is extremely rough at the moment, but it does demonstrate a login (hard-coded for now).   I think I will go for the URL based model provided by Shiro, provided I can get that to work with Vaadin.

Refactoring

I've done quite a bit of moving code around to try and separate what should be the base V7 reference, and the demo code

Vaadin 7 beta 11

Changes from beta 10

I noticed a couple of small changes from beta 10:

VaadinRequest parameters

The parameter names have changed.  I was using "loc" to return the location from Page, using a mocked VaadinRequest.  The parameter name has changed to "v-loc".  I notice the width and height parameters are now pre-fixed with "v-" as well.

Chameleon Button style

I was using the "big" style for buttons, but this no longer works, and neither does "small".   I've changed to using "tall" for now, and posted a question on the Vaadin forum