mikrobe
9 1 3

First of all, we've already used ZK in a project and we are very happy with that.
Comparing ZK and Vaadin framework's characteristics side by side, we ended up using ZK for several reasons, XML based UI declaration over everything else and JQuery vs GWT on second place.
So by now we've acquired some expertise on ZK and none on Vaadin.
The point is that for the last few weeks I've been working on a feasibility study for a project that'll require (among other technologies) OSGi, Liferay and Activiti. What I found out is that googleing for documentation about that topics there is more information and examples about Vaadin than ZK.
Vaadin seems to get more momentum, to be more focused on third-party integration, and to be supported by other tools.
Vaadin-OSGi is clearly feasible and well supported using tools like Pax, Vaadin-Liferay has a lot of advanced examples and Vaadin-Activiti, well, Activiti Explorer has been developed with Vaadin.

Could somebody try to convince me that ZK is still the way to go for? Biased comments are welcome :)

delete retag edit

## 3 Replies

vincentjian
2245 6

Hi mikrobe,

ZK also can run on liferay portal, refer to ZK-Liferay
And our contributor also successfully to combine ZK with OSGi, refer to small talk 1 and small talk 2

jeanher
1719 1 6

We aim to create a simple and easy-to-use framework that allows the users to integrate with 3rd party solutions themselves easily. Our users and customers have successfully integrated charting, maps, OSGi, portals, grails, scala, netbeans ... with minimal help from us and have been sharing their experiences in the format of blogs and small talks.

In addition to various 3rd party solutions we have integrated, if there is any other popular 3rd party component/framework missing please do feel free to let us know.

9393 3 7 16
http://www.oxitec.de/

So there is no other independent voice here i will talk a little bit about this complex theme.

Let me begin with a sentence that i found in a forum about OSGi.

"I'm wondering why the suicide rate is not higher by the OSGi developers".


I found that sentence by googeling for a solution for one of the many many error messages and problems that i have by trying to migrate openTruuls (an up drilled clone of Zksample2 framework stack) to a pluggable modular core application as a base for everyone who wants to build modular web applications on top of zk. I stopped now after 4 months of spending time for it. I failed!

OSGi and OSGi in the web environment are two different things.

I will point to several problems that i have found by migrating:
I try first the impala framework but lacks in old documentation so i switched to reading about OSGi because there are a lot of books.
First of all is the biggest problem the documentation. If i read some of my OSGi or Spring Dm books it seems that all is clear. But if i go on the codes i fight with many many problems. Second, the more frameworks and patterns used in the old application so more complex will be the seperation of themselve.

So i work many with the spring framework my first choice for developing/running the OSGi application was the Eclipse Virgo Server (formerly spring dm server). The 3.0.2 and now 3.0.3 seems to run.
So i'm writing database apps i began most with the backend.

openTruuls as a scalable multitenancy db application runs against two databases. One for the users/tenant/rights and the second for the tenants working data in separated table schemas. I need about 2 days to find the reason why i cannot connect to them in the old way. Virgo does not support JNDI datasoucre connections?? Ok i solved this with normal JDBC connections.
The next problem was to get the hibernate stuff to run. Some guys have made code modifications in the hibernate code to get them to run. But thats not my choice. In this case i have luck and found early good articles and a lot of recommendations NOT to use hibernate in OSGi environment.
So i download and study the EclipseLink ORM stuff and ported all my dao's code to eclipselink and for me new to JPA.

All samples in the books are running against one database. So i found it curious that i can started two datasources (seen in the log) but the two seperated persistence bundles are accessing the same database? An really friendly apache karaf comitter pointed me by a phone call to the right direction. While both datasources exported with the java.sql.Datasource interface the running app cannot known which datasource to use. Therefore a so called 'filter' tag helped me to give each of them a unique name for a clear separation. Thanks Christian.

For the frontend as a first try to call the controllers i have used the logic from Erko's article and sample codes.
I can create a composer from a bundle in plain java code and have access to the imported database services.
So 90% of our modules are written with zul files and composers i tried the 'normal' way calling the zul-file with executions.createComponents() and let the composer come up with the 'apply' attribute in zul. This is not running by me.
(Sorry Vincent, i got your last sample not to run, only a white page. But a look in the webcore Manifest.mf showed me a Require-Plugin entry for the 'separated' plugin. That's not the sense of a plugable system. The core should not know of a third party plugin.)

By working with spring in a normal web application we have the application context and spring generates a special sessionContext which is used by us for the transaction management. And ensures that the crud operations are multi user ready (concurrency). These you have only in the webcontainer. So a separated OSGi bundle is not web-aware. And that's the point where the VaadinOSGiBridge comes to play and i really have a tear in my eyes that such helper classes are not ready for zk.

A complete reading of the really famous two smalltalks in the post before shows that Erkos sample is not really OSGi like and the coded Custom Session scope beats to the spring transaction with aspects. The second article from Mirko shows that he makes modifications on the zk code base. That's normal a no go for me as same as self osgifying the zk jars because i try always to get the last actual version to use.

So in summary i will say. OSGi is a really interesting part. All is possible if there is the time and the money for getting to run. As more frameworks or architectural aspects are in it as more complex is the solution to get it to run. So it's a big failure to take only one framework and get it to run under OSGi and think now the complete cake must run too. And here i have only written about a few pieces of my challange.

I know i come back to OSGi and take a second try if i have more time for it or others are interested to finish this part and get early access to the codes.

But overall i must thanks to all peoples by pottix for their great work on the zk framework and incredible help and speed by fixing bugs. zk is the web framework of my choice.

best
Stephan

[hide preview]