Today I was working on a Seam project and after modifying the pages.xml file and re-exploding to JBOSS the application server went into a loop and kept re-exploding over and over.
After some digging around I found out that it is a bug in JBOSS AS 5.1 and is being fixed in 5.2. Basically it is due to an Eclipse temp file being in either your WEB-INF/ or META-INF directory. The temp files to look for are either *.jsfdia or *.spdia and can be deleted. In my case the file was named pages.xml.spdia and was located in the WEB-INF/ directory along with my pages.xml file that was modified. After I deleted the file and re-exploded everything worked just fine.
Over the weekend I was working on a Seam project that required images to be uploaded so I took a look at the rich:fileUpload component. Looking at the RichFaces sample code it looked very straightforward and I assumed it would take just a couple of hours to implement. 2 days later I still couldn’t get it to work. I was so frustrated that I started questioning my intelligence. Fortunately I am stubborn, just ask my wife, and I refused to give up. This time it paid off. I finally found out via the Seam framework forums that the a:mediaOutput RichFaces component is not compatible with Seam long running conversations. The file was uploading fine and the listener method could see the object but when it came time for a:mediaOutput to paint the object to the screen it could not be found.
The solution was to simply add an s:conversationID component to a:mediaOutput so that Seam would know the conversation id. Once I added this everything worked fine. UGH! Below is an example.
1 2 3 4 5 6
| <a4j:mediaOutput element="img" mimeType="#{file.mime}"
createContent="#{fileUploadBean.paint}" value="#{row}"
style="width:100px; height:100px;" cacheable="false">
<f:param value="#{fileUploadBean.timeStamp}" name="time"/>
<s:conversationId value="#{conversation.id}"/>
</a4j:mediaOutput> |
These are the kind of things that drive me crazy when programming. Things like this can totally blow a schedule out of the water.
By default Seam maps all of your Hibernate collections as Sets. This is also the most common Hibernate collection type. Keep in mind though that this may not always be the collection type you need.
The other day I was working on a project and I was adding objects to my collection and displaying them in the view. I noticed however in the view that they weren’t displaying in the order that they were added. After scratching my head for a while I finally realized that it was because they were being added to a Set which doesn’t preserve the order of the elements. To resolve the problem I simply changed my collection type from Set and List in my Entity class.
Here is a quick rundown of the collection types supported by Hibernate. For more detailed information check the Hibernate documentation.
- A java.util.Set is mapped with a <set> element. Initialize the collection with a java.util.HashSet.
- The order of its elements aren’t preserved.
- Duplicate elements aren’t allowed.
- This is the most common persistent collection and the default collection type for Seam.
- A java.util.SortedSet is mapped with a <set> element. Initialize the collection with a java.util.TreeSet.
- The sort attribute can be set to either a comparator or natural ordering for in-memory sort.
- A java.util.List is mapped with a <list> element. Initialize the collection with a java.util.ArrayList.
- The position of each element is preserved with an additional index column in the collection table.
- A java.util.Collection is mapped with a <bag> or <idbag> element. Initialize the collection with a java.util.ArrayList.
- Allows possible duplicates.
- The order of the elements aren’t preserved.
- Uses a list internally but ignores the index of the elements.
- A java.util.Map is mapped with a <map> element. Initialize the collection with a java.util.HashMap.
- Preserves key and value pairs.
- A java.util.SortedMap is mapped with a <map> element. Initialize the collection with a java.util.TreeMap.
- The sort attribute can be set to either a comparator or natural ordering for in-memory sort.
- Arrays are supported as well by Hibernate however they are rarely used and aren’t supported by the JPA standard.