ServiceLocator and Java Web Start

Liquibase Users
#1

I’m using Liquibase 2.0.1 in a Java Web Start application, by way of the SpringLiquibase integration. While snooping on my application’s http traffic using Fiddler, I noticed that the liquibase jar was being repeatedly retrieved 72 times. At almost 1MB each time, that’s a lot of overhead.

This behavior pretty much makes Liquibase unacceptable to use in my situation. Any thoughts on how to work around it? For example, is there a way to configure in advance what classes to use, to avoid the need for ServiceLocator to scan for them?

#2

Hi all,

We’re using liquibase since 2 or 3 monthes now in v2.0.3.

We are using it inside a JWS (JDK 1.6 or 1.7 behaves the same) application to be able to update local databases automatically on users computers, but I’m now noticing, after some bugtracking in our code, that the same situation applies to us.

When I start the application on a user’s computer, I can see informations from the attached file in Apache Logs (Apache is serving the JWS repository).


It appears that ServiceLocator still tries to get information from the remote liquibase.jar when doing this call (DatabaseFactory constructor):

            Class classes[] = ServiceLocator.getInstance().findClasses(liquibase/database/Database);


Is it a known bug ? Do you think the problem comes from JWS or Liquibase ?

Is there, please, any workaround I could apply there to avoid getting rid of Liquibase which I found very usefull in the way it works ?


Thanks in advance


Cédric

#3

Cédric,

The project I was working on was abandoned for other reasons, so I never resolved this issue.

As for whether the problem comes from JWS or Liquibase, it depends on your point of view. Liquibase makes the assumption that searching jars is a relatively cheap operation. That’s not a bad assumption in most circumstances. You could argue that it shouldn’t search so aggressively, but doing so probably resolves other problems. You could argue that JWS is badly designed if it breaks common assumptions in the Java world. You could question why JNLPClassLoader returns the location of the remote jar rather than the location of the cached jar, but it probably considers the cache to be a private implementation detail that shouldn’t be exposed.

However, I ran into enough problems like this with JWS that I probably would not use it again for a project of any complexity.

#4

The fact that JWS has different constraints and expectations than a “normal” java instance would cause problems with liquibase’s class scanner. It woudl definitely be possible to plug in a different ServiceLocator implementation that would deal with JWS better, but I haven’t gotten a chance to look into it yet. If anyone has a chance, I would welcome any patches you could send.


Nathan

#5

My solution was to prepare text file resource with a list of classes that Liquibase wants to load dynamically:
http://blog.raigedas.info/liquibase-on-jws-applet-javafx/

#6

Have you had a chance to look into this?

I was able to get raigedas’ example working, but I found I had to add a few more packages, which makes me fearful that this is not a good longterm solution as I will have to rerun and manage this as liquibase evolves

            addPackageToScan(“liquibase.change”);
            addPackageToScan(“liquibase.database”);
            addPackageToScan(“liquibase.datatype.core”);
            addPackageToScan(“liquibase.diff”);
            addPackageToScan(“liquibase.parser”);
            addPackageToScan(“liquibase.precondition”);
            addPackageToScan(“liquibase.serializer”);
            addPackageToScan(“liquibase.sqlgenerator”);
            addPackageToScan(“liquibase.executor”);
            addPackageToScan(“liquibase.snapshot”);
            addPackageToScan(“liquibase.logging”);
            addPackageToScan(“liquibase.lockservice”);
            addPackageToScan(“liquibase.ext”);