[INFO] org.apache.tapestry5.ioc.RegistryBuilder Adding module definition for class org.apache.tapestry5.ioc.services.TapestryIOCModule
[INFO] org.apache.tapestry5.ioc.RegistryBuilder Adding module definition for class org.apache.tapestry5.hibernate.HibernateModule
[INFO] org.apache.tapestry5.ioc.RegistryBuilder Adding module definition for class org.apache.tapestry5.hibernate.HibernateCoreModule
[INFO] org.apache.tapestry5.ioc.RegistryBuilder Adding module definition for class org.apache.tapestry5.spring.SpringModule
[INFO] org.apache.tapestry5.ioc.RegistryBuilder Adding module definition for class org.apache.tapestry5.services.TapestryModule
[INFO] org.apache.tapestry5.ioc.RegistryBuilder Adding module definition for class org.apache.tapestry5.internal.services.InternalModule

thanks a lot for this great article!

I’ve got a little question regarding the architecture of an app with modules. Is there any possibility to list all loaded modules?

Thanks a lot
Alex

I think an other advantage of OSGi inside Tapestry is deployment of Tapestry-OSGi app in the Google App Engine environment

Thank for your reply.

I knew all dependency libraries of a bundle are managed by OSGi container. I meant the ‘private’ dependency libraries of a bundle, they can package together by using ‘Bundle-ClassPath’ header field (In this case, you can easily remove all related files of a module from the application)

About OSGi inside Tapestry: I think the advantage is Tapestry application becomes OSGi container. And you easily develop/active/inactive extension modules for that. Otherwise, it is easy to deploy on ‘traditional’ servlet container like Tomcat, Jetty with no OSGi configurations…

I am enthusiastic in a next your port about integrate Tapestry 5 into Spring dm Server and the way make Tapestry/Spring/Hibernate(JPA) work together in Spring dm Server

In OSGi you put small pieces of functionality into a bundle. The bundle and its dependencies are not packaged together. This level of granularity leads to enormous amount of installed bundles but gives you a lot of freedom and flexibility. In the described Tapestry IoC approach you put certain functionality into small IoC modules, which are then dropped into a web application. These modules should not be packed together with their dependencies.

Regarding OSGi inside Tapestry: I don’t see any advantage of starting Felix or Equinox inside Tapestry. But it is possible to integrate Tapestry into OSGi. In my day job we implemented a bundle management application similar to Felix Web Console. This application
is based on Tapestry and HttpService. Fur this purpose the issues TAP5-503 and TAPESTRY-2519 has been fixed. I’ll describe how to integrate Tapestry into OSGi in some later posts.

Usually a module have many dependency libraries and related file configurations. How do if I want to package all of them in a ‘bundle’ like OSGi bundle for easily add to or remove from the application?

How do you think if we embed Felix inside Tapestry, like the way Struts 2 do? (They have a Struts-OSGi plugin: http://cwiki.apache.org/WW/osgi-plugin.html)

take a look at Tapestry/Hibernate Integration Library. This library provides the per-thread service HibernateSessionManager, which creates a new session for every request. When the session is first created, a transaction is started. At the end of the request the transaction is aborted and your changes are lost unless you commit the transaction manually or you annotate a method with @CommitAfter annotation.

If you need a more comprehensive transaction support you should use Spring.

It is clear to me that Tapestry is no JEE container. My question targeted at the end of your answer. So there is no pooling available. Is there a possibility to facilitate Tapestry as a container, which manages transactions and similar services for me? Or should I use Tapestry to inject Spring Beans in my pages, which support transactions? A nice feature would be to have a transaction per Page request, which I can achieve with PageRenderRequestFilter opening and commiting an transaction for me.

best regards,
Johannes Neubauer

Nice article! We met at the technical university of dortmund, after your talk. I got your book today and will read it in the near future.

I like your ideas using tapestry for product lining. It is definitively a powerful feature. The constraint to have to restart the system isn’t too hard. Reload features like hot deployment and others seem not to work properly or even reliably. Restarting a tomcat or jetty is not that time consuming at all.

My question is: You have your own IoC container and I can configure my own types of Injection in the service configuration. Additionally you have a page pool for delivering pages fast and being scalable, since you can configure the pool. But is it possible to use a PoJo-Pool or something similar for Injecting some business logic, too? I ask that question, because I have scalable business logic by using session beans in a Java EE container like JBoss (Heavy-Weight thing isn’t it). I Inject such a session bean to my Tapestry pages using a JNDI lookup, because tapestry service classes are not managed classes of the web container. I annotate the build-method with @Scope(ScopeConstants.PERTHREAD), so that the bean is retrieved only once per request. If I could use the tapestry injection to simulate scalable stateless session beans, that would be really really nice.

best regards
Johannes Neubauer