Posts

Spring bean instantiation errors in application contexts and OSGi

One thing that keeps biting me is when instantiating beans in the application context that have no other references to that class in direct java code—typically I get a class not found error. The resolution to this of course is to put the package on the classpath so that the class is found when the class loader tries to load it. The easiest way to do this is to include an import-package directive for that package. This puts the package and the classes in it, on the classpath. You can exclude or include individual classes in the import statement if you want finer grain control.

OSGi and logback configuration

There are issues with logging in an OSGi environment. There are many official ways to do this, some of which requires re-routing OSGi logging services and traditional services through another logger and configuring the logger implementation. All of that can be done, but in the end you have to configure your logger.  I was using spring dm but was having problems getting logback to configure correctly and I was therefore receiving too many logging messages that I could not control. Here are some links to different blogs that describe what to do. However, none of them worked for me: http://ekkes-corner.blogspot.com/2008/10/logging-in-osgi-enterprise-applications_31.html http://ekkes-corner.blogspot.com/2008/10/logging-in-osgi-enterprise-applications_20.html http://markmail.org/message/wpe25gwceanfqev2 http://groups.google.com/group/spring-osgi/msg/738a8d8e85fbf96b http://springosgi.googlepages.com/ch02.html No matter what, I could not get the logback.xml to configure correctly...

Creating a target eclipse platform and bundling non-osgi bundles on the fly

One challenge even in eclipse 3.5 is managing the target platform for your eclipse RCP.  It turns out that while many enterprise level bundles are already OSGi ready, many are not. If you want to create a target platform more easily, and have an automated build facility that does not require manual conversion of non-OSGi bundles, you need to create process to build the target platform with your 3rd party bundles. The idea is very similar to what is described in this blog http://springosgi.googlepages.com/ where a target platform is built for a spring dm (spring dynamic modules) environment. Follow the instructions at http://springosgi.googlepages.com/ch01.html carefully. But the question is, if you have non-OSGi bundles, what do you do? Can you automate the process? Lets assume that you have a bundle that should be in the target but is not OSGi. I’ll use miglayout-3.7-swt.jar as an example. Prepare Your Eclipse Environment Install m2eclipse, http://docs.codehaus.org/display/M...

Eclipse RCP+Spring+EMF+Teneo and the data source

One issue when using these technologies together is the configuration of the HbSessionDataStore. Under spring, you can configure the LocalSessionFactoryBean by setting the data source directly. The data source is typically defined in your context XML as well. But there is no data source property setter under HbSessionDataStore.  Under standard hibernate you can set configuration parameter hibernate.connection.provider_class to the name of the connection provider class and spring provides a data source called LocalDataSourceConnectionProvider which can be instantiated without parameters to get a data source. The trick of this spring class is that it access a thread local storage (therefore global location for that thread) to retrieve the data source you may have set in the LocalSessionFactoryBean instance under setDataSource(). The LocalSessionFactoryBean sets the thread local storage when you call setDataSource(). So under teneo’s HbSessionDataStore, we can just extend the class t...