June 18, 2008
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.
January 24, 2008
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):
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.
November 23, 2007
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.
November 19, 2007
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!
November 15, 2007
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.
October 14, 2007
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