Luke is a small desktop client for browsing Lucene indices. It is very useful for troubleshooting when you work with Lucene directly embedded in your application.
While upgrading an application from Lucene 3.4 to Lucene 4.3.1, I realized that Luke is not quite up-to-date with Lucene, it is stuck somewhere in 4.0.0 alpha.
But the good thing about Open Source is, if the original project owners lose time, resources or interest, others may show up and fork or continue the work.
A number of people have forked or copied Luke to GitHub. tarzanek/luke also offers binary builds on java.net, and this version works fine for me with Lucene 4.3.1 so far.
08 July 2013
11 December 2012
Eclipse Juno Patch for XML Editor Performance
Eclipse Juno has a number of performance regressions compared to Indigo. Switching back and forth between XML and Java editors can be tediously slow even in Juno SR1.
The patch provided for bug 394588 solves the issue or at least significantly improves the response time of the IDE.
In my team, we have tested the patch successfully on Windows 32 bit and Ubuntu Linux 64 bit with Oracle Java 6 and 7.
The patch can be installed from a special update site via Help | Install New Software.
The patch provided for bug 394588 solves the issue or at least significantly improves the response time of the IDE.
In my team, we have tested the patch successfully on Windows 32 bit and Ubuntu Linux 64 bit with Oracle Java 6 and 7.
The patch can be installed from a special update site via Help | Install New Software.
23 November 2012
Logging with SLF4J and Logback in Tomcat and TomEE
Logging in Java would be a lot easier if every open source project out there would use SLF4J logging API, but of course this will never happen.
The fact that
In my own applications, I always use SLF4J with Logback. Working with Tomcat, this means I'm getting an ugly mixture of log messages in different formats from my web application logging to System.out with Logback, and from Tomcat itself logging to System.err via JULI and java.util.logging, not to mention any third-party libraries contained in my application which use log4j, Apache Commons Logging or whatever.
There are two independent but similar approaches of replacing the official Tomcat JULI libraries by an SLF4J or Logback adapter: tomcat-slf4j and tomcat-slf-logback.
I've tried both, but in the end, I think it's easier to use nothing but the JUL-to-SLF4J bridge and other standard artifacts.
The fact that
java.util.logging made it into the JRE does not make it any better than it is, so there's a good reason to hide it behind a facade and never use it directly. But there is no reason for everyone to invent their own logging facades instead of simply using SLF4J.In my own applications, I always use SLF4J with Logback. Working with Tomcat, this means I'm getting an ugly mixture of log messages in different formats from my web application logging to System.out with Logback, and from Tomcat itself logging to System.err via JULI and java.util.logging, not to mention any third-party libraries contained in my application which use log4j, Apache Commons Logging or whatever.
There are two independent but similar approaches of replacing the official Tomcat JULI libraries by an SLF4J or Logback adapter: tomcat-slf4j and tomcat-slf-logback.
I've tried both, but in the end, I think it's easier to use nothing but the JUL-to-SLF4J bridge and other standard artifacts.
20 October 2012
Using the Maven 3 API with Maven 2 Components
Working on a Maven plugin, I was trying to upgrade the Maven API from 2.x to 3.0.4. After the upgrade, the plugin would no longer compile due to an unsatisfied transitive dependency of the
The same issue was posted on the Maven Users list, but never answered.
Solution: Add a dependency on
maven-archiver used by the plugin: The class org.apache.maven.artifact.DependencyResolutionRequiredException could not be resolved.The same issue was posted on the Maven Users list, but never answered.
Solution: Add a dependency on
maven-core, or on maven-compat which should handle all compatibility issues with Maven 2.
Labels:
Maven
20 August 2012
New OSGi Console in Equinox 3.8.0
Equinox 3.8.0, the OSGi framework running Eclipse Juno, comes with a new console built on top of Apache Felix Gogo Shell.
It is debatable whether or not this is an improvement. Veteran Equinox users are greeted with the following message when trying to activate the console:
It is debatable whether or not this is an improvement. Veteran Equinox users are greeted with the following message when trying to activate the console:
08 August 2012
Maven Build Info for Web Applications
Problem
* You want to include build info like build number, revision number etc. as a web resource in your web applications.* You have a multi-module Maven project with more than one WAR module and a number of JAR modules.
* You want to minimize copy-and-paste configuration in your POMs.
* The mechanism should not depend on a CI server.
Solution
This can be achieved using the Build Number Maven Plugin and the overlay feature of the Maven WAR plugin.
Labels:
Maven
18 July 2012
OSGi and CDI Combined
Pax CDI is a new OPS4J community project I've started to combine the best of OSGi and CDI.
Once you've worked with CDI or with an up-to-date annotation-based flavour of Spring, the service registry API or XML-based dependency injection in the Blueprint or Declarative Services style suddenly appears rather verbose.
On the other hand, even though Java EE 6 is more lightweight than ever, its monolithic nature feels rather a burden when you're used to OSGi.
Why not have the best of both worlds? The idea is not new, it has been implemented to some extent both in weld-osgi and in the FighterFish subproject of GlassFish.
Unlike these two projects, Pax CDI is independent of any given CDI, Java EE or OSGi implementation. The first proof-of-concept release is based on Apache OpenWebBeans and Equinox. In contrast to weld-osgi, which required some modifications in Weld itself, Pax CDI works with an unmodified version of OpenWebBeans.
Trying to do the same with Weld is one of the next goals for Pax CDI.
An alpha release Pax CDI 0.1.0 is available from Maven Central.
Once you've worked with CDI or with an up-to-date annotation-based flavour of Spring, the service registry API or XML-based dependency injection in the Blueprint or Declarative Services style suddenly appears rather verbose.
On the other hand, even though Java EE 6 is more lightweight than ever, its monolithic nature feels rather a burden when you're used to OSGi.
Why not have the best of both worlds? The idea is not new, it has been implemented to some extent both in weld-osgi and in the FighterFish subproject of GlassFish.
Unlike these two projects, Pax CDI is independent of any given CDI, Java EE or OSGi implementation. The first proof-of-concept release is based on Apache OpenWebBeans and Equinox. In contrast to weld-osgi, which required some modifications in Weld itself, Pax CDI works with an unmodified version of OpenWebBeans.
Trying to do the same with Weld is one of the next goals for Pax CDI.
An alpha release Pax CDI 0.1.0 is available from Maven Central.
Labels:
CDI,
Declarative Services,
Equinox,
Glassfish,
Java EE 6,
OpenWebBeans,
OSGi,
Weld
28 June 2012
Fixing Editor Tab Fonts in Eclipse Juno
Eclipse Juno is out! It starts a good deal faster than Indigo, shows a more colourful (but ill-proportioned) splash screen, and then opens a workbench window with oversized and truncated labels in all editor tabs.
This applies to Ubuntu 12.04 with KDE and the QtCurve GTK+ theme.
This issue is not due to QtCurve or SWT, as I had first suspected, but to the new CSS-based widget styling of the e4 platform. There is an E4 CSS Editor which is not included in Juno by default, but can be installed via the Update Manager.
With this editor, you can change the
Much better!
Update 14 Aug 2012: If you develop web applications and edit CSS files in Eclipse, you'd better deinstall the E4 CSS editor after customizing the workbench layout to fall back to the standard WTP CSS editor. The XText-based E4 editor does not recognize some legal syntax like unquoted URLs.
Actually, you don't need any Eclipse plugin to change the CSS, you can directly edit the CSS file in your Eclipse installation at
This applies to Ubuntu 12.04 with KDE and the QtCurve GTK+ theme.
This issue is not due to QtCurve or SWT, as I had first suspected, but to the new CSS-based widget styling of the e4 platform. There is an E4 CSS Editor which is not included in Juno by default, but can be installed via the Update Manager.
With this editor, you can change the
font-size and font-family properties of the MPartStack style used by the editor tabs.Much better!
Update 14 Aug 2012: If you develop web applications and edit CSS files in Eclipse, you'd better deinstall the E4 CSS editor after customizing the workbench layout to fall back to the standard WTP CSS editor. The XText-based E4 editor does not recognize some legal syntax like unquoted URLs.
Actually, you don't need any Eclipse plugin to change the CSS, you can directly edit the CSS file in your Eclipse installation at
plugins/org.eclipse.platform_4.2.0.v20120608140/css/e4_default_gtk.css.25 June 2012
Pax JDBC: An OSGi JDBC Service
Pax JDBC is a new project under the OPS4J umbrella which simplifies the use of JDBC drivers in OSGi applications by providing a generic driver extender and various native driver adapters for your favourite database.
This project aims at compliance with the OSGi Enterprise Release 5.0 specification.
Pax JDBC 0.1.0 is available from Maven Central, with native adapters for Apache Derby and PostgreSQL. Since this first release, support for H2 and MySQL has been added, and further contributions are always welcome.
This project aims at compliance with the OSGi Enterprise Release 5.0 specification.
Pax JDBC 0.1.0 is available from Maven Central, with native adapters for Apache Derby and PostgreSQL. Since this first release, support for H2 and MySQL has been added, and further contributions are always welcome.
24 May 2012
OSGi, Java EE and CDI Integration Testing with Pax Exam 3
In-container testing is an approach shared by many testing frameworks like Pax Exam, jeeunit, Arquillian and Spring's test context.
Pax Exam 2.x is a mature solution for testing OSGi bundles and applications, jeeunit was created to simplify Java EE 6 integration testing and has been extended to handle stand-alone CDI applications and non-CDI setups based on Tomcat and Spring.
Taking the best of both worlds, the next major release line Pax Exam 3.x is designed to provide a unified testing experience by incorporating additional test containers for Java EE and CDI from jeeunit while staying backward compatible with Pax Exam 2.x for OSGi.
The first public milestone release Pax Exam 3.0.0.M1 is now available from The Central Repository (aka Maven Central), including test containers for GlassFish, OpenWebBeans and Weld.
While jeeunit works with Embedded GlassFish which lacks all OSGi capabilities of the GlassFish server, the Pax Exam GlassFish Container launches GlassFish 3.1.2 on top of an OSGi framework, enabling users to deploy or provision both WAR modules and OSGi bundles, thus providing a test environment for hybrid Java EE/OSGi applications.
A plain old JUnit test class can be turned into an in-container integration test simply by adding a
See the Pax Exam 3.0.0.M1 Release Notes for more details and use the OPS4J mailing list (general@lists.ops4j.org) for feedback and support.
Pax Exam 2.x is a mature solution for testing OSGi bundles and applications, jeeunit was created to simplify Java EE 6 integration testing and has been extended to handle stand-alone CDI applications and non-CDI setups based on Tomcat and Spring.
Taking the best of both worlds, the next major release line Pax Exam 3.x is designed to provide a unified testing experience by incorporating additional test containers for Java EE and CDI from jeeunit while staying backward compatible with Pax Exam 2.x for OSGi.
The first public milestone release Pax Exam 3.0.0.M1 is now available from The Central Repository (aka Maven Central), including test containers for GlassFish, OpenWebBeans and Weld.
While jeeunit works with Embedded GlassFish which lacks all OSGi capabilities of the GlassFish server, the Pax Exam GlassFish Container launches GlassFish 3.1.2 on top of an OSGi framework, enabling users to deploy or provision both WAR modules and OSGi bundles, thus providing a test environment for hybrid Java EE/OSGi applications.
A plain old JUnit test class can be turned into an in-container integration test simply by adding a
@RunWith(PaxExam.class) annoation and some configuration data in a properties file.See the Pax Exam 3.0.0.M1 Release Notes for more details and use the OPS4J mailing list (general@lists.ops4j.org) for feedback and support.
Subscribe to:
Posts (Atom)


