Stupid Java Error: java.lang.NoClassDefFoundError: java.awt.Container

I got this while trying to install the LDS Chruch Indexing software on Xubuntu 13.10, turns out it is 64 bit Ubuntu problem:



java.lang.NoClassDefFoundError: java.awt.Container
    at com.install4j.runtime.installer.frontend.headless.AbstractHeadlessScreenExecutor.init(Unknown Source)
    at com.install4j.runtime.installer.frontend.headless.ConsoleScreenExecutor.(Unknown Source)
    at com.install4j.runtime.installer.frontend.headless.InstallerConsoleScreenExecutor.(Unknown Source)
    at com.install4j.runtime.installer.Installer.getScreenExecutor(Unknown Source)
    at com.install4j.runtime.installer.Installer.runInProcess(Unknown Source)
    at com.install4j.runtime.installer.Installer.main(Unknown Source)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at com.exe4j.runtime.LauncherEngine.launch(Unknown Source)
    at com.install4j.runtime.launcher.Launcher.main(Unknown Source)



Although this topic seemed to help,  ia32-libs is obsolete and the suggested replacements (lib32z1 lib32ncurses5 lib32bz2-1.0) do not have the "right stuff".



Seems like the installer wants its own version of Java that is pre-1.7.  This version wants some (a lot) extra 32 bitty stuff:

sudo apt-get update

sudo apt-get install libgtk2.0-0:i386 libxtst6:i386

sudo apt-get install libxtst6:i386

sudo apt-get install libx11-dev:i386

sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0
sudo apt-get install libxi6 libxtst6 libxrender1

        ./Indexing_unix.sh -J-Djava.awt.headless=true

    



Seemed to do the trick.

Read More

Archiva startup error

We started seeing this problem in Archiva:

SQL Exception: An SQL data change is not permitted for a read-only connection, user or database.




The problem ended up being Apache was started as root and so the derby lock file (db.lck) was owned by root. When it was restarted as the proper user it could not update the lock file and so opened the database as read-only.



Solution:



Change the owner of the lock file to the one that owns the process.  NOTE: The lock file was not where I assumed it was but was mentioned in the log file with this error:

org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (Failed to start database '/usr/local/maven/db/archiva/users', see the next exception for details.)

I never did find the promised exception with detail, just lots of these errors.

Read More

Clojure: What is my IP address?

I needed to get the IP address of the current host and came across an article Detect your host IP with Clojure which had some good ideas. Unfortunately, this code does not take into account some of issues like network interfaces that are not up. My box is a Windows 7 64-bit box with VirtualBox installed as well as sometimes being docked and sometimes working wirelessly. Using that code as a base, I wrote this code:

This code returns a seq of vectors of IP address and the interface name. It only returns interfaces that are up and are not the loopback.

Read More

lein-resource 0.2.0 hits clojars

I just deployed lein-resource to clojars.

What is lein-resource?

A Leiningen plugin that can be used to copy files from mulitiple source directories to a target directory while maintaining the sub-directories. Also, each file will be transformed using stencil. The map that is passed to stencil contains a combination of:

The project map
The system properties (with .prop added to the name )
Additional values (currently only :timestamp)
Values set in the project.clj using :resource :extra-values

Read More

Hammock driven development pays off with a ClojureScript pipe function - ok not really - See core.async instead

Again, with only using the think method, here is the ClojureScript version of the pipe method


Thanks to Are pipe dreams made of promises? for writing it and Clojure - From Callbacks to Sequences for pointing it out to me.

EDIT: While still a good idea, futures and promises are not ClojureScript approved.



Another EDIT:  See core.async for the right way to do this.

Read More

Clojure - From Callbacks to Sequences

I have been spending some hammock time on the problem of converting a stream of events into a sequence.  And Lo and Behold, the answer falls in my lap.  I may need to see if I can implement the pipe function in ClojureScript.  Maybe if I spend more time in the hammock, someone will have already done it.



Be sure and read Clojure - From Callbacks to Sequences for a nice explanation and examples.



Here is the function that does the magic:

Read More

Clojure: lazy seq + database = bad

In my work on topoged-hibernate I naively thought that it would be great to return a lazy-seq of the results of a query like:






However, this has several problems, not the least of which is that the underlying session is closed and the data is inaccessible.  When the with-session macro finishes, the session and transaction are closed and then the lazy-seq is returned.  However, it no longer has a connection to the database and so an exception is thrown once sequence is read.  This is just one problem with accessing data from a database via a lazy-seq.



The same problem applies to any attempt to use a lazy-seq to access a database.  The problem is that this is no way to know when the seq is no longer in use to close the connection.  One could easily add to the seq to check once the end of the dataset had been reached.  At that point, it could close the connection.



However, a lot of the time the entire dataset need not be read as (take 10 dataset).   The seq would be never get to the end and leave to connection open.  This is not really a Clojure problem, but a problem with Java.  In Java, there is no way to know when an Object is done being used.  On course there is the finalizer but that has proven to has so many problems that its use is discouraged.



One solution is to read all the data before returning.  This is a common way of handing data and works for small datasets (small enough to fit into memory).  It is an easy and efficient way to get the desired results and still manage the database connections.



Larger datasets, that cannot be stored in memory, have to be processed as the data is read, thusly:






Now the data is processed within a closure that will close the connection once the processing is completed.  Of course, one must take care to not accidentally return a lazy-seq by returning a map or filter of the data.



What I wish we could do is to return a seq that could then close its own connection once it is no longer in use.  There are some huge issues with that including:

• Java is not helpful and only figures out if an Object is no longer in use at garbage collection which is not guaranteed to happen for any given Object.


• The onus then falls on Clojure to keep track of each resultset and "determine" when it is no longer in use.  This might entail writing a secondary garabage collection in Clojure.


• Another problem is that the seq might never be cleaned up, like if it were "def"ed.

In conclusion, while using lazy-seqs to process datasets might seem like a good idea, you will quickly find it is not worth the trouble.

Read More