Friday was Spring

October 14, 2007

Hello.
Our project spcp7, which should also serve as a more complex example for combining current top notch technologies under one roof, made big progress this weekend. Friday I needed to implement a JPA session within a portlet which will not be opened and closed at every request. An often used solution is to implement a content filter which will be registered in the web.xml. As every solution it has pros and cons and so I decided to use a more “modern” and even better approach. The only framework I really missed in my portlet until this day was Spring and after evaluating its features I found out that there already is a solution for instantiating entityManagers via Spring’s dependency injection. No sooner said than done I worked myself through the Spring documentation. It seemed to me that the most elegant solution for getting an entityManager is inserting the entity manager via the @PersistenceContext annotation. Considering Spring’s documentation http://www.springframework.org/docs/reference/orm.html#orm-jpa it was not clear to me that load-time weaving is also needed for this injection.

The other solution (injecting the entityManager into the class and having to open the transaction by oneself) worked out of the box and so I sticked to that one as I did not want to use container specific code to preserve interoperability. All that was done with Spring version 2.0.7.

Saturday and Sunday I started to develop the front end of the application which also was not without glitches. The last time I used JSF before that project was almost one year ago and so I had to figure out the details again. ICEfaces with Liferay and portals in general is (as you can see in my former posts) not yet considered production ready and that is why experimenting is normal. For editing the properties of my content folders I chose to use the <ice:tree> component which partially did not want to work. After hours I found out that the correct working of the tree depends on the correct timestamp of the surrounding jspx file. Every time I edited the file in the webapp folder directly the tree worked, directly after deploying I did not. Thinking about the problem I came up with the fact that my liferay standard tomcat installation used the wrong timezone. After correcting it the tree worked out of the box. Strange, really strange.

Following I struggled with my own copy paste mistake and the navigation rules not working with liferay 4.3.1 and icefaces 1.6.0. After updating the whole environment to Liferay 4.3.3 and icefaces 1.7.0-DR1 navigation rules like

<navigation-rule>
<from-view-id>*</from-view-id>
<navigation-case>
<from-outcome>success</from-outcome>
<to-view-id>/Success.iface</to-view-id>
</navigation-case>
</navigation-rule>

work if you do not use <redirect/>. Using <redirect/> results in an isolated ICEfaces file without the surrounding portal. Also very important is the new <ice:portlet> tag encapsulating your content and positioned directly below your <f:view> tag. A correct – very basic – nesting would look like this (see also http://www.icefaces.org/JForum/posts/list/5933.page )

<f:view>
<ice:portlet>
<ice:form>
</ice:form>
</ice:portlet>
</f:view>

Another thing I found out is the fact that when a portlet with ICEFaces within Liferay is opened and the portlet is redeployed you will get a “User Session expired” popup which suggests a page reload. This would be perfectly O.K. if the window would go away after reloading. Instead it stays even after reloading the page and even after reading the portlet via liferay “Add content”. As the popup deactivates the whole ICEfaces functionality in the background the portlet is unusable. The only workaround I found so far is to not having opened the portlet when redeploying or to restart the server after getting the “User Session expired” popup. If your session expires the normal way the popup behaves correctly.

Besides it seems to me that the <ice:panelSeries> is not updated without a page reload. Is this behavior correct or even intended?

Update: Updates seem to be possible when looking at the component showcase. I still have to figure out how and if removing and adding of “heavier” components like inputText and command buttons is possible within the same panel.

Bug reports to the errors above will be posted to the appropriate sites when I evaluated them in detail.

Enough of that…

I need something to eat now :-).

Comments and corrections are, as always, welcome

Regards

Phillip Merensky

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: