1 War, 1 Portlet, 1 Page, 2 Portlet Instances... Supported?

Hi Everyone,
First, G.R.E.A.T. job Vaadin team, I must say, “You had me at samples”
Keep up the great work, I’m really impressed with the quality of Vaadin, from code elegance to UI richness.

Apologies if this sounds a bit naive, I can’t make such assumptions without going much deeper into Vaadin and hence my question which is.

Is it supported to run two instances of the same portlet onto a single page in liferay, if so, apart from the steps mentioned in configuring Liferay with com.vaadin.portal.gwt.PortalDefaultWidgetSet, what can be missing ?

Please spare the time of reasoning behind such multiple instances approach, for the use case why I’m doing this it makes great sense.


Currently each user (session) can only have one instance of each application. This instance can of course be on any number of pages (and they share the state), but you can not put the same application twice to the same page. In order to overcome this limitation, you could easily extend the application with an empty class to give it a second name - this way you would have two different applications.

Please, could you describe your use case a bit so that we could understand why you would like to put the same application twice to the same page?

Dear Joonas,
Thanks for replying, I’m afraid that static typing is not an option; at least as per my current requirements.

The great thing about Vaadin is that you can do any thing that is Java, which includes dynamic (runtime) generation of forms based on metadata. i.e. Have one generic portlet that loads metadata from any persistent store (XML, YAML, JSON, even DB ) and dynamically render the entire UI.

Using this approach clearly depends on the ability to assemble a single page from a number of instances of the “Same generic” portlet. With each instance serving a dynamically loaded form.

You Answer did explain the limitation, but do you suggest any workarounds without resorting to static typing ???

I’m willing to go as far as patching current version of vaadin but not as far as making architectural modifications to vaadin itself, it’s simply not containable.

I would really really hate moving away from vaadin for such a limitation.

Best regards,

Is it a possibility to design the application in a way where you only have one application running, but the view is split up into two parts? Sounds maybe a little quirky but you could have two separate views open at all time. Best idea I can come up with with the current known information.

If I understood correctly, you are trying to create a generic form viewer application and show that twice on the same page with different parameters (that define which form to show). This sounds like a 100% valid use-case, but it seems that Vaadin does not support it directly.

I would implement this by creating GenericFormApplication that reads the which dynamic form should be constructed from the portlet parameters. Then I would create empty extensions apps (Form1App extends GenericFormApplication, Form2App extends GenericFormApplication, …) to enable multiple instances of the same application and drag those applications to the different parts of the page. Instead of 1,2,3, … you could use some more desciptive names like SidebarFormApp, BodyFormApp, FooterFormApp, … Note that you do not have to anyhow make the form generation less dynamic - Form1App can still read which form to create from the portlet parameters.

In any case, this use-case should be resolved in a generic manner in Vaadin ApplicationPortlet. I created a ticket
for this and hope that in future you would not have to create such “empty application extension classes” just to identify separate Application instances.

Dear Jens,
Thanks for replying, I’m trying to see through your answer, while I admit I don’t fully understand what you meant these are my concerns:

  1. Manually managing views is a portlet design anti-pattern IMHO.
  2. Currently my problem is that I don’t have an overlapping functionality from one portlet to the other, the second instance
    fails to display completely
    . with such a limitation, how do you suggest I workaround not being able to render the second instance of the portlet. If there’s such a workaround I think this would solve the entire issue.

Best regards,

P.S. if you have any Arabic speaking friends, I would suggest you ask them to translate (transliterate) your name, you’d be “happy”. you’d come up with endless lines from there. couldn’t help it; boys will always be boys.

Dear Joonas,
Thank you very much for your time, I do appreciate your help.
Yes, you correctly understand what I’m trying to do, and regarding your suggested solutions please read my comments:

  1. Inheritance as a static work around would work well If I was building my application statically. unfortunately I’m not. please read the trailing section of my reply for explanation.

  2. Thank you very much for the ticket creation, If I can be helpful in any way, I’d really like to help.

OK, I think I owe you some explanation regarding this “Application” I’m building.
If you haven’t heard of Oracle’s ApEx, (Application Express) please spare 5 minutes and you’d be thrilled.

What is ApEx

Basically ApEx represents a realization of Metadata driven data-centric application lifecycle. every thing is metadata from developer workspace to page composition to logic handling various user interface events.

The down side of ApEx is that it’s PL/SQL based :frowning: and they have already done a “huge” amount of effort to compensate for the lack of existence of such a mature set of frameworks/products as that of Servlet/Portlet/GWT/Vaadin.

While I do like ApEx, I see huge potential to building an ApEx clone in Java. with database agnosia of course.

Liferay represents a very solid foundation for Application composition, view composition, multi-technology environment.

Vaadin represents a fantastic foundation for building individual (still generic) view fragments (portlet) ,that is a “Region” in ApEx terminology.

If my project (I call it “Paramount” for now) matures, just as building an application today in ApEx involves NO IDE’s what so ever, I think it would be a massive popularity boost for both liferay and vaadin, when it comes to building data centric applications that is.

I have to say: with years of Java /J2EE experience in building data-centric application; ApEx stands out as a revelation against manually coding such applications at all. I’m hoping to build a replica of ApEx but 100% java. and I was hoping I could use Vaadin in that. JSF is too “statically” oriented with stress on IDE, Wicket is not as polished as Vaadin.

I hope I explained “Why”
And I’m really looking forward to seeing the ticket resolved.

Best Regards

Thanks for the explanation. There is one developer currently working on the next generation portlet support that should fix the issue. I think that we will see the results in couple of weeks. If the “next generation portlet support” project will fail for some reason, we will try to fix the issue in the “current generation portlet support” by making it possible to support separate states for different portlet instances.

If you want to try to resolve this today - you should take a look of the following classes:

You should try to find a way to get AbstractApplicationServlet.findApplicationInstance() to return the correct application instance. In order to pass the portlet instance id to the this method and use it in the application instance selection, you must probably change this method (or AbstractApplicationServlet.getExistingApplication()). Unfortunately these are private. If you manage to get it to work, we could change the required methods from private to protected to make fixing this possible without lots of cut-n-pasting.

Just to add - building Vaadin from sources is easy. See

Dear Joonas,
Thanks for the pointer, I’ll attempt to follow your recommendation and would definitely keep you posted. Of course I will have to understand many internals of both Vaadin and GWT, but I will sure give it a shot.

Best regards,