My Résumé

Hello.

The last blog post dates January of which I am fully aware. I am also fully aware of the fact that I announced the (with my project partner aligned) release of our project for the first half of February and that we now write the month of June. Finally – only four months late 😉 – the project files for the Image Gallery (my part) are available for download. As you can see from the subversion changelog I only made minor changes within the last four months. These last months I have waited for the completion of my project partner’s part and now cannot wait any longer. That is why my part (the image gallery) is released now. The Banner Advertisement portlet will be released sometime in the future.

Altogether I am glad to finally have finished. Because the project already got bigger than expected my résumé will be compact.

In short I learned, that:

• beta software has to be considered beta, especially when talking about the maven site generation plug-in and hierarchical multimodule builds.
• documentation is essential, but can cost a lot of time.
• the more you rely on external software, the more can go wrong, especially if the software is complex.
• the more time a project consumes the more important is testing and documenting to avoid confusion and destroying functionality which worked a few months ago.
• open source portlet development with JSR-168 (or JSR-286 in future) is the way to go when professional and maintainable enterprise applications are needed.
• you have to pick your project partners carefully.

To download the release of the Image Gallery, please navigate to the download site at sourceforge.net at https://sourceforge.net/project/showfiles.php?group_id=207117 and consider reading the documentation at http://spcp7.sf.net.

Happy deploying.

Regards,

Phillip Merensky

Preface and Maven Site Generation Problems

The last post was a long time ago but we have not been lazy since then and that is why our project and the documentation are nearly complete. We plan to release versions of the banner management and the image gallery in the first half of February. So stay tuned!

In the last days I suffered from maven site generation and I had to conclude that correct multi project site generation is not possible when the projects are not laid out in an hierarchical manner. That means the following in short:

Arranging of projects like this works:

spcp7
 \
  image-gallery
      \
      image-gallery-war
         \
          another sub project
 \
  bannermanagement

This does not work (projects on the same level in the file system):

spcp7
image-gallery
image-gallery-war
bannermanagement


So if you plan to do a maven multi project build which will be used for site generation later do NOT under NO circumstances try to arrange your projects on the same level. Always use a hierarchical structure as it is proposed in the Maven guide. If you do not do this you will get terrible problems with paths and reporting (especially concerning the subversion changelog).

If you want to use a hierarchical multi project in eclipse just lay out the projects in maven manner, generate the eclipse project files with

mvn eclipse:clean eclipse:eclipse

and import the projects with the help of the m2eclipse plugin from codehaus. Currently the m2eclipse import does not work well when your project hierarchy lies within the workspace. Just put it outside for a first test.
After that commit the whole structure to your version management system check it out as new into your workspace after that and do the project importing with the m2eclipse plugin and everything will work fine. Cost me more than a day to find this out. So hopefully you will get this working with this small guide a bit faster.

Regards,

Phillip

Alfresco Content Creation

I spent round about 4 hours on Wednesday because of a tiny little mistake in the Alfresco Web Service Sample. Sadly enough it took that long to find out because I assumed a bug in my code first. Anyway…

If you create binary content with the help of the web service API like described in org.alfresco.sample.webservice.ContentReadAndWrite of the Alfresco SDK you will not be able to retrieve the single new created content by a Lucene “PATH”-query afterwards.

For details on this issue look at http://issues.alfresco.com/browse/AR-1895.

Regards,

Phillip

lesson learned

As mentioned from my Project Partner, i had (do have) some Computer problems.
All of a sudden my Notebook an ASUS A6T didn’t boot anymore.
After ruling out causes that I could have repaired myself,
I went to my computer dealer and he said he will sent it in to ASUS and care for the rest..
(The Notebook has still half a year left of a 2 Year warranty)
At first I was told that it would need only 2-3 days till I’ll get it back..well that was 3 weeks ago.
After some talk to the Asus Hotline they told me, that they are waiting for parts from Taiwan to repair my Notebook..
and this may need some time..
So what do I learn from that ?
Next time spent some more money and buy a Computer with a good on location service, where you don’t have to wait weeks for some parts.
It is definitely worth the more cost!

Springification

It has been a while since our last post which does not mean that we were unproductive. We had some outer project problems though. I was ill for almost a week, my bike got broken and the notebook of my project partner (ASUS) packed up and still was not returned although the actual break down was almost threee weeks (or 4) ago.

Despite these pitfalls I made big progress. A week ago I decided to use spring for the whole application because the loose coupling pleased me and also seemed very useful for the project. Using spring within the deep layers worked without a hassle. After that I tried to use Spring also within the view for my JSF backing beans. This did not work because I did not get the WebApplicationContext initialized. Not having an WebApplicationContext means no web side initialization of the jsf backingBeans which renders Spring unuseful for the view part. I even tried to follow the solution of http://cagataycivici.wordpress.com/2007/09/10/using-spring-to-manage-jsf-beans/. It did not work either. I suppose that maybe ICEFaces and/or Liferay destroy the request handling/web context initialization of Spring. I did not follow the problems very far as handling view beans is not important for my application. Handling the deeper layers with Spring suffices entirely for me.

So far so good.

I know that this post could have been a bit more detailed but I am focusing completely on the completion of the project now and thus blogging is at the moment a bit unproductive for me.

Regards,

Phillip

Friday was Spring

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

spcp7.sourceforge.net

Hereby we proudly announce our approval as sourceforge.net project. You can find the project summary page at

http://sourceforge.net/projects/spcp7/

and the project homepage (which currently points to this blog) at

http://spcp7.sourceforge.net

Regards,

Phillip

Image Gallery Portlet – Overview

Hello.

It has been quite a while now since our last post. But this time we have pretty good news. The development of our portlets made progress. My part – the image gallery – is near completion. The web front end part will be developed this weekend. Compared to other big open source galleries the set of user features is basic. Special though, comparing to other galleries, is the possibility to transparently use completely different content providers per folder for getting the images. One content folder could get its content from a content management system like Alfresco (this part is being developed at the moment), another content folder for example from the file system, Flickr or another CMS.

The user has the ability to create content folders and specify content providers for each of them. Each content provider has a different set of default properties which can be edited by the user. Via web front end the user can choose which content of the underlying content provider should be displayed.

A new content provider can be developed easily as there exists an API. To use the new content provider only two steps are necessary:

1. Put the jar with the implemented content provider interfaces into the classpath of the image gallery and
2. provide the full classpath to the content provider “main” class within the image gallery configuration file

As you can see the code is prepared to be enhanced easily and that is why we hope to elate other developers to join our project when the project thesis has been completed. When the interface development has been stabilized I will provide an UML-Class-Diagram to get an overview of the API.

Like any other image gallery the user will be able to organize his pictures in folders and have thumbnail images to preview them. ICEFaces 1.6 is used to provide the user with a rich Web 2.0 Experience and a clear user interface. At the moment there does not exist a possibility to upload pictures via the portlet itself. The upload is done via the content provider (eg CMS like Alfresco) and only displaying is done via the portlet.

Regards,

Phillip Merensky

BannerAd Portlet – Update

I finished implementing the basic functions of the BannerAD portlet.It is now possible to let it show a Banner defined through an Image and Url, or custom HTML code e.g. an Iframe.
In the administration part of the portlet, you can add the banners and remove them.

As we do not want to develop a very basic portlet there is still there is some work left..
For example to let the user define on which portlet one banner is shown and on which banner is not. Also I have to optimize the Database access through 
Hibernate to avoid unnecessary read and write operations on the DB.
And finally clean up and comment my Code, so that fellow programmers interested in this portlet may understand it.

BannerAd Portlet

I am doing an BannerAd portlet, a portlet to show advertisments on the page similar to GoogleAdsense, but accessible for own Banners.
The portlet uses Icefaces and will show the Banner as Imagelink.

I am also working on an alternative to let the User execute Html Code in the Banner Portlet through an Iframe, but I am stuggling here with a refreshing Problem.

For persisting we chose to use Hibernate , I am still getting in this materia but it looks quite promising 😉