Application Development Meanderings

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 to in

First, having to obtain the application context created by spring DM should be a rare event. The spring dm context is designed for inter-bunde communication and the primary way to access pojos in the spring dm context is through service publishing and referencing. Within a bundle, or just in your application you can create application contexts as you normally do and within this contexts you can access service using references. So the traditional way of creating contexts continues with the idea that there is a per-bunde context that you can access through services and reference publishing.  The note below assumes you need to access the spring dm context as part of the infrastructure of your application, for example, for always accessing objects at the top-level of your application in a well-known location. Obtaining a service from spring dm and equinox may be more tricky than you think. Because spring dm by default starts application contexts asynchronously, it is possible that the appl

  I am trying to use the spring dynamic modules. It’s been a rough road because I did not fully understand what spring dm was trying to do. Essentially, it is creating an application context on the behalf of properly configured osgi bundles and then providing that application context as a service published by the respective bundle. Because proper osgi bundles cannot share resources easily across bundles, the basic model of your application once you use spring dm is to further straight-jacket sharing. This decreases coupling which is good. The proper way using spring dm to share “service” (POJOs with a specific purpose) across bundles is to publish them as osgi services and hence collaborating bundles are really about wiring up services across bundles. Within a bundle you can create hierarchical contexts by first accessing the service using ServiceTracker then using that “service” (which is really the application context) as the parent context. Hence, you use osgi preferred methods s

I’m further along with logging in an OSGi environment especially eclipse RCP. I found these blogs that are very useful: http://ekkes-corner.blogspot.com/2008/10/index-blogseries-logging-in-osgi.html http://blog.kornr.net/index.php/2008/12/16/writing-an-osgi-logging-back-end http://ekkes-corner.blogspot.com/2008/10/logging-in-osgi-enterprise-applications_31.html http://www.dynamicjava.org/articles/osgi-matters/logging-osgi-the-simple-way/11-osgi-matters/110-logging-osgi-the-simple-way The real issue is that OSGi is a much stricter environment in terms of how the classpath is built and hence, the standard logging and logging facades (like slf4j) do not work properly in a strict OSGi environment. Eclipse equinox provides some relief through equinox specific or eclipse specific mechanisms but we need a logging solution that can operate in a strict OSGi environment but integrate multiple logging and logging facade APIs because most likely, in any decent sized application, you will nee