Blog Archives

February 2nd, 2011
7:56 pm
Primefaces Table Sorting–Common Gotchas

Posted under JSF
Tags , , , , , , , ,

Update 2/2/2011

According to this post here by Cagatay Civici, the Primefaces Project Leader, as at Primefaces 2.2M1, client side datatable is not supported and the dynamic attribute is deprecated from then on.
Seemingly it was becoming too hard to support all the table features on both client and server sides.
It is a shame that this was not documented better and more widely – the user manual still documents the dynamic attribute, and there are a number of posts about client side sorting (though in fairness they probably predate 2.2M1).

This behaviour exactly ties up with what I am seeing in my testing – the dynamic attribute does nothing, sortFunction is ignored, and all sorting is done via Ajax server side.

Original Post 2/2/2011

Having successfully got sorting working I was frustrated to find that a new simple example failed to work. Primefaces table sorting is pretty much transparent, requiring minimal effort and working out of the box. The lessons learned on this one are instructive so I summarise them below.

Details of Example and Problem

  1. The example fetched a list using JPA, stored the list in a view backing bean, then displayed it in a table with a sortable header.
  2. When the header was clicked, the up/down arrows were correctly displayed, but the data was not sorted – it was as if the request was ignored.
  3. It was not immediately obvious how the header click was handled – there was no obvious click event on the HTML element, and I could not see any Javascript running after a quick test with Firefox/Firebug. I gave up this line of attack but may look into it later as to how it all works. Some dynamic CSS pseudo classes/jQuery trickery may be involved.
  4. I was not certain as to whether the table was client side or server side/Ajax, even though it should have been client side by default. To diagnose the problem, I changed the value of the sortBy attribute in the column header to be an invalid bean property. The symptoms did not change, but an errors were logged in the Glassfish server log for each header click – “[#|2011-02-02T18:22:14.557+0000|SEVERE|glassfish3.0.1|org.primefaces.model.BeanPropertyComparator|_ThreadID=24;_ThreadName=Thread-1;|Error in sorting|#]”.
  5. This showed that the sort was being attempted but was failing due to the invalid property, which indicates that the sort was attempted server side. According to the Primefaces forum, for client side sorting, the sortBy property is not used as the displayed data is sorted.
  6. Interestingly, I would have expected Primefaces to use a client side table by default, but clearly it was not. Changing the dynamic property on the table tag to false explicitly had no effect and the behaviour was unchanged, so I will need to investigate client side tables further as for small data sets they are faster – I will update this post when I have done this.
  7. I turned on FINEST logging with Eclipselink in persistence.xml. Use <property name="eclipselink.logging.level" value="FINEST" /> to do this, and note that you need to bounce Glassfish to for a logging level change to be picked up. I noticed after this that the JPA query seemed to be rerunning very often, perhaps for every click of the sort header. This lead me to wonder if the backing bean was being recreated each time.

 

Cause and Solution

In the end, it was simply that I had not annotated the JSF backing bean as @SessionScoped (the example used CDI throughout, and did not use JSF managed beans). This meant the bean was request scoped by default, and was indeed being recreated – the sort was trying to do the correct thing, but the data was getting reloaded from the database in the original sort order each time!

Adding the correct annotation as above (and making a couple of the beans correctly implement serialisable to satisfy CDI/Weld) solved the problem.

This is a good example of where a problem cause is not immediately apparent from the symptoms.

Sample JSF page fragment showing the form containing the table

<h:form id="frmTest">   
    <util:themeSwitcher form="frmTest" outerStyle="clear: both; float: left; margin-bottom:20px;" innerStyleClass="ui-widget"/>
    <h:panelGroup layout="block" style="width:300px;">   
        <p:dataTable var="taxonomyNodes" value="#{taxonomyBrowser.taxonomyNodes}" scrollable="true"
             styleClass="clear #{fn:length(taxonomyBrowser.taxonomyNodes) lt 20 ? ‘ss-tableheader-scrolladjust-nobars’ : ‘ss-tableheader-scrolladjust-bars’}"
             height="460" > 
             <f:facet name="header">
                Client Side Sorting
             </f:facet>
             <p:column headerText="Category List"  sortBy="#{taxonomyNodes.text}">
                 <h:outputText value="#{taxonomyNodes.text}" />
             </p:column>           
        </p:dataTable>
    </h:panelGroup>
</h:form>

No Comments »

January 23rd, 2011
1:41 pm
Eclipse JPA table generation fails with Eclipslink 2.1.2, Glassfish V3.0.1

Posted under JPA
Tags , , , , ,

I was attempting to create a database for a new project which just contained entities – I had imported the entity classes from Enterprise Architect and added the required annotations, getters & setters etc.

My first attempt used the following persistence.xml (I have removed most of the classes for the example)

<?xml version=”1.0″ encoding=”UTF-8″?>
<persistence version=”2.0″ xmlns=http://java.sun.com/xml/ns/persistence
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation=”http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd”>
    
    <persistence-unit name=”Test” transaction-type=”RESOURCE_LOCAL”>
      <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>

      <non-jta-data-source>jdbc/TestPool</non-jta-data-source>
      <class>uk.co.salientsoft.Test.domain.Address</class>
      <class>uk.co.salientsoft.Test.domain.AddressLine</class>
      <class>uk.co.salientsoft.Test.domain.Campaign</class>
      <class>uk.co.salientsoft.Test.domain.CampaignText</class>      
      <exclude-unlisted-classes>false</exclude-unlisted-classes>     
      <properties>
       <property name=”eclipselink.logging.level” value=”INFO” />
       <property name=”eclipselink.target-server” value=”None” />
       <!– <property name=”eclipselink.target-server” value=”SunAS9″ />–>
       <property name=”eclipselink.target-database” value=”Oracle” />      
       <property name=”eclipselink.ddl-generation.output-mode” value=”database” />
      </properties>
     </persistence-unit>
</persistence>

 Having created the database and validated the connection/datasource etc., I attempted to create the tables from  Eclipse by right clicking the project and selecting JPA Tools/Create Tables from Entities…

This resulted in the following error:-

[EL Config]: Connection(5226838)–connecting(DatabaseLogin(
    platform=>OraclePlatform
    user name=> “Test”
    connector=>JNDIConnector datasource name=>jdbc/TestPool
))
[EL Severe]: Local Exception Stack:
Exception [EclipseLink-7060] (Eclipse Persistence Services – 2.0.1.v20100213-r6600): org.eclipse.persistence.exceptions.ValidationException
Exception Description: Cannot acquire data source [jdbc/TestPool].
Internal Exception: javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file:  java.naming.factory.initial

The error occurred even though the data source was being used outside the container as a non-jta data source (this worked previously for JPA1/Glassfish V2, allowing JPA to be used outside the container but still using a datasource defined in Glassfish). A previous post here (in the section Notes on Persistence.xml) also reports that when running outside the container, it is vital to have eclipselink.target-server defaulted or set to none. In this case, the setting caused no difference either way. After a fair bit of research/Googling, I could not find the cause of the problem, so I simply reverted to specifying the connection explicitly in persistence.xml,  without using the connection defined in Glassfish at all.

This worked correctly. I will not need to create the database very often, and it only involved tweaking a few lines in the file, so I’m happy to live with it. Here is my modified persistence.xml which uses a direct connection specified in the file. This version created the database correctly. Note that as detailed in this post here (near the bottom of the post), the property names for JDBC url, user, password and driver have now been standardised and are no longer eclipslink specific.

<?xml version=”1.0″ encoding=”UTF-8″?>
<persistence version=”2.0″ xmlns=”http://java.sun.com/xml/ns/persistence” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=”http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd”>

    <persistence-unit name=”Test” transaction-type=”RESOURCE_LOCAL”>   
    <!– <persistence-unit name=”Test” transaction-type=”JTA”>–>
   
      <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>

     <!–<jta-data-source>jdbc/TestPool</jta-data-source>–>
     <!–<non-jta-data-source>jdbc/TestPool</non-jta-data-source>–>
    
      <class>uk.co.salientsoft.Test.domain.Address</class>
      <class>uk.co.salientsoft.Test.domain.AddressLine</class>
      <class>uk.co.salientsoft.Test.domain.Campaign</class>
      <class>uk.co.salientsoft.Test.domain.CampaignText</class>      
      <exclude-unlisted-classes>false</exclude-unlisted-classes>     
      <properties> 
      
        <property name=”javax.persistence.jdbc.url” value=”jdbc:oracle:thin:@localhost:1521:xe”/>     
        <property name=”javax.persistence.jdbc.user” value=”Test”/>
        <property name=”javax.persistence.jdbc.password” value=”Test”/>
        <property name=”javax.persistence.jdbc.driver” value=”oracle.jdbc.OracleDriver”/>     
     
       <property name=”eclipselink.logging.level” value=”INFO” />
        <property name=”eclipselink.target-server” value=”None” />
       <!– <property name=”eclipselink.target-server” value=”SunAS9″ />–>
       <property name=”eclipselink.target-database” value=”Oracle” />      
       <property name=”eclipselink.ddl-generation.output-mode” value=”database” />
      </properties>
     </persistence-unit>
</persistence>

No Comments »

January 6th, 2011
10:57 am
Nebula DigiTV Issues

Posted under DigiTV
Tags , , ,

There are 2 main issues – the latest version (3.7.12) is needed to auto tune correctly as it deals with split NIT, a new broadcast feature of freeview.

There may be other issues with 3.7.12 so you can use an older version (e.g. 3.7.06) to get a working EPG and for normal watching etc.

This post has the details about the split NIT and EPG problems. Extract from the relevant comment is as follows:-

Yes. Use 05. It will work.
Please read the other threads if you want details. There are way too many threads being started on this same question as it is.
Use 3.7.05 to watch TV, make records, and have an EPG that works.
Use 3.7.12 ONLY to do a fresh Auto-tune as this deals with the “Split NIT” issue. (Not sure if that is relevant in Germany, so just stick with 3.7.05)

 

As at 1/1/2011, I had EPG issues. I switched to the latest V4 release, but it crashed during recording and proved rather a resource hog.

I then rolled back to 3.7.06 (needed to do restore a restore point, as it appears the registry settings in V4 blanked all the button labels in V3 – the registry settings are not removed even on an uninstall.

Then tried 3.7.10 and then 3.7.12 on top, and this seems to work fine so sticking with it at present.

No Comments »

December 3rd, 2010
9:42 am
JPA error “Class is mapped, but is not included in any persistence unit”

Posted under JPA
Tags , , , ,

I received this compile time error from Eclipse with one of my test projects which was previously fine, using Eclipse Helios with Eclipselink 2.1.0 (and container managed JPA in EJBs). The error occurred when I was autodiscovering the entities rather than listing them in persistence.xml explicitly, even when <exclude-unlisted-classes>false</exclude-unlisted-classes> was explicitly present.

Supposedly, as the annotated entity sources for the classes are in a subfolder of the parent of the META-INF folder containing persistence.xml, they should be discovered automatically. Listing the fully qualified classes explicitly in persistence.xml solved the problem, however this is not ideal as it would mean having an alternative version of persistence.xml for testing.

I googled for the problem but could not find a solution listed anywhere. For now this is just one to be aware of – I’ll stick with listing the classes explicitly and look further for a solution later on as and when it becomes a nuisance!

No Comments »

November 8th, 2010
1:18 pm
Header width incorrect on Primefaces scrollable table

Posted under JSF
Tags , , , , ,

If a header facet is used on a Primefaces table, the header does not allow for the scrollbars if present. the column headers do adjust for the scrollbars (although there are issues with column alignment between the headers and the data – a number of such errors have been posted to the Primefaces forum).

One workaround for this is to selectively include a CSS selector to adjust the header <div> width when the scrollbars are present.
The following selector achieves this:-

<style type=”text/css”>       

    .ss-tableheader-scrolladjust > div.ui-datatable-header {
        width:495px;
    }
</style>

The following table definition selectively includes this when enough rows are present to require scroll bars (this must be derived empirically as it depends on the height of the table, font size used etc. :-

     <h:panelGroup layout=”block” style=”width:500px;”>    
     <p:dataTable var=”car” value=”#{tableBean.carsSmall}” scrollable=”true” 
         styleClass=”#{fn:length(tableBean.carsSmall) lt 8 ? ” : ‘ss-tableheader-scrolladjust’}” height=”200″ > 
         <f:facet name=”header”>
            Ajax Sorting        
         </f:facet>
         <p:column headerText=”Model”  sortBy=”#{car.model}”>
             <h:outputText value=”#{car.model}” />
         </p:column>

         <p:column headerText=”Year”  sortBy=”#{car.year}”>
             <h:outputText value=”#{car.year}” />
         </p:column>

         <p:column headerText=”Manufacturer”  sortBy=”#{car.manufacturer}”>
             <h:outputText value=”#{car.manufacturer}” />
         </p:column>

         <p:column headerText=”Color” sortBy=”#{car.color}”>
             <h:outputText value=”#{car.color}” />
         </p:column>
     </p:dataTable>
    </h:panelGroup>

No Comments »

November 5th, 2010
6:34 pm
Issues with JSF h:outputStylesheet and Primefaces/jQuery skinning

Posted under JSF
Tags , , , , ,

I tried to use this whilst experimenting with dyamic style sheets, but this support post here confirms that it does not work due to an issue with the way the images are referenced.
The symptom is that you get basically correct looking layout/colours but none of the images have loaded.
The solution is to use a link tag directly e.g.:-

<link type=”text/css” rel=”stylesheet”
href=”#{request.contextPath}/resources/themes/#{themeSelectorBean.theme}/skin.css” />

Whilst on the subject of h:outputStylesheet, it should be noted that for the following example:-

<h:outputStylesheet library=”css” name=”styles.css”/>

Whilst the href of the resulting generated link tag looks like this:-

<link href=”/context-root/faces/javax.faces.resource/styles.css?ln=css”
rel=”stylesheet” type=”text/css”/>

the actual physical directory containing the style sheet in this case will be

…\WebContent\resources\css\style.css

i.e. the logical to physical mapping of the web path in this case is not straightforward and obvious. If you just create the resources folder under your project’s WebContent folder and place all your libraries as subfolders under that, it should all work correctly (the above issue with jQuery/Primefaces notwithstanding)!

No Comments »

November 2nd, 2010
12:10 pm
Panther–Asus P6T SATA Drive Errors & Port Allocations

Posted under Windows 7
Tags , , , , ,

Update 24/3/2011 09:08

The event log reported an error on boot today (after a very slow boot with a long blank screen), seemingly for SATA 3 again (unless I am still confused about how the port mapping works)!

The driver detected a controller error on \Device\Ide\IdePort2

This is very strange as SATA 3 is no longer connected, so it appeared to be winging about an unused port. It is possible that Windows interrogated the port on boot and got an error even though nothing was connected, but it is still a bit weird. No immediate action has been taken – will monitor over the next few weeks.

The next step would probably be to add a new PCI express SATA controller and disable all the onboard SATA completely. This Startech controller offers 4 internal and 2 external ports, and needs a pci express X4 slot. It would therefore fit in the spare pci express X16 slot in my P6T, as pci express cards with less lanes can fit happily in a larger slot and use it partially. At the time of writing it is available from Lambdatek for around £66 inc VAT. It appears to get very mixed reviews, although my experience with startech has been good. A search did not reveal any other obvious cadidates for a reasonable price – just some higher end raid ones which also seem to have fans so hot and noisy as well as pricey!

Update 7/2/2011 12:54

I examined the event log again over the last few weeks and new errors were present for SATA 3:-

Error, Event 11, Atapi – The driver detected a controller error on \Device\Ide\IdePort2

This appears to be a new problem affecting the Samsung 1TB data drive. The drive has therefore been moved to SATA 6 and will be monitored over the next month.
It is still not clear whether these issues are due to one or more faulty cables or to faulty ports on the motherboard. The next test will probably be to swap the cables for new ones and monitor again, as this is much easier and cheaper than a full motherboard swap. Given that a single cause is more likely than multiple independant failures (unless a whole batch of cables were faulty or of poor design), a fault on the motherboard looks most likely for all the issues.
As multiple disks have now been affected (The Vertex and one of the Samsungs), at least it does not appear to be a fault with a particular device.

Update 7/11/2010 8:33

I examined the event log and the drive error has not occurred since before moving the cable to port SATA 5 (last occurrence of error was 2/11/2010 at 9:51)
Therefore my conclusion is that either port SATA 1 on the motherboard is faulty, or there was a poor connection, or a faulty cable issue which has been rectified when the cable was moved.

I may try some further tests – perhaps moving back to port SATA 1 with a new cable to further narrow down the issue.
I will check again in a couple of weeks for any errors and perhaps try a further test then.

The good news is that the evidence does not point to a faulty OCZ Vertex drive.

 

P6T Port

PM/PS Bios Designation

Drive

SATA 1 PM (Primary Master) was OCZ Vertex 128GB (moved to SATA 5 to diagnose port event errors)
SATA 2 PS (Primary Slave) Sony/Optiarc DVD writer
SATA 3 SM (Secondary Master) not used (possibly faulty, moved to SATA 6
SATA 4 SS (Secondary Slave) Samsung HD0103SJ 1TB, old System drives, top/cooler mounted
SATA 5   OCZ Vertex 128GB (moved from SATA 1)
SATA 6 N/A Samsung HD0103SJ 1TB, Data drive, bottom/Vert mounted – moved from SATA3

 

I have had occasional drive errors logged, as follows :-

Error, Event 11, Atapi – The driver detected a controller error on \Device\Ide\IdePort0.

It appears that this error relates to SATA 1, the OCZ Vertex, although the mapping between the event and the actual disk is hard to establish. There are Microsoft posts on how to do this here and here, however they do not use the same disk/port designation as above so they are not all that helpful.

The problem could be the drive, the motherboard controller, or the cable. To start to diagnose it, as at 12 noon on 2/11/2010 I have moved the OCZ Vertex onto Port SATA 5 with the same cable. I will monitor the issue and try further diagnosis over the next few days/weeks and post the outcomes here.

IF I do have to replace the existing OCZ Vertex (should be under warranty though…) there is now a Vertex 2 which is faster, and also a Vertex 2e which reduces the overprovisioning in the SSD. This overprovisioning is the area used for read-modify-writes/block cleaning where a block is swapped for one in the overprovisioning area. It is also used for wear levelling and bad block replacement. See here and here for for a discussion by AnandTech on this. See here for a  review of the Vertex 2e and comparisons with the Vertex 2.

No Comments »

September 25th, 2010
11:32 am
Primefaces test application does not display correctly with Google Chrome

Posted under JSF
Tags , , , , ,

A simple Primefaces table sample application was not displaying in Chrome. Some of the output data from the cells plus some other metadata was displayed as raw text with no formatting.

This answer to FAQ question 6 in the documentation PDF details the problem and the solution:-

6. With facelets some components like charts do not work in Safari or Chrome but there?s no problem with Firefox.
The common reason is the response mimeType when using with PrimeFaces with facelets. You need to make sure responseType is “text/html”. With facelets you can use the <f:view contentType=”text/html”> to enforce this setting.

I added this to the sample code and Chrome then worked correctly. I checked the Primefaces Showcase and note that the same is done there.

No Comments »

September 22nd, 2010
5:28 pm
Simple Primefaces JSF app displays blank page – incorrect glassfish deployment

Posted under Eclipse
Tags , , , , ,

I recreated a new simple JSF application from scratch, in the end making it identical to an existing one that worked.
Each time I ran it on Glassfish 3.0.1 from Eclipse, it displayed a blank page as if not being sent to the faces servlet.
I checked every detail in making the apps identical – checking every configuration file and the xhtml page.
I cleaned and republished to Glassfish, but still no joy.

In the end I did a detailed examination of the deployment folders under the Glassfish domain (Eclipse deploys its apps under domain1\eclipseApps\ assuming you are using the default domain of domain1). I discovered that the Primefaces jar, primefaces-2.2M1.jar had not been deployed, even though the library was added and the web deployment assembly page had an entry for it.

I tried explicitly removing the app from Glassfish by using the Add and Remove… option on Eclipse’s server context menu for the Glassfish server, and then adding it back. This time, the deployment folders were correct and the library was deployed correctly. The application then ran correctly and displayed the page.

The lesson from this is that deployment to Glassfish 3.0.1 from Helios can be flakey, and just using a clean in Eclipse is not always enough to really clean out any issues. Removing the app and re-adding may be needed. If there is any strange behaviour, the deployment folders under the Glassfish domain should be examined early on to check that everything did in fact deploy – sometimes Eclipse will say it is all ‘synchronised’ when it may not be, and you will not always get smoking gun errors to lead you to the problem!

No Comments »

September 19th, 2010
8:46 pm
Servlet Mapping Issues with Glassfish V3.0.1

Posted under Glassfish
Tags , , , ,

There seem to be some servlet mapping issues with Glassfish V3.0.1.

To summarize, the following outlines what the servlet mapping logic should do:-

  1. The <url-pattern> as below matches the input url and if there is a match, passes the url to the designated servlet (in this case the faces servlet).
  2. The url parts that match are stripped out, so that for extension mapping e.g. “*.jsf” pattern the “.jsf” is removed, and for path mapping e.g. “/faces/*” pattern the /faces subdirectory is removed.
  3. The javax.faces.DEFAULT_SUFFIX as below is applied to the result as a file type if one is not present, to give an actual file to be searched for. This is passed to the faces servlet for processing.

I tried the same combination in web.xml that I had used previously on Glassfish V2.1 with ICEfaces:-

<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.jsf</url-pattern>
</servlet-mapping>
<context-param>
<param-name>javax.faces.DEFAULT_SUFFIX</param-name>
<param-value>.jsf</param-value>
</context-param>

The actual file type was also .jsf (index.jsf in this case)
This gave rise to the following intermittent error when run – it would run once or twice and then blow up:-

url:  http://localhost/PrimeTest1/index.jsf
error:  javax.servlet.ServletException: PWC1232: Exceeded maximum depth for nested request dispatches: 20

Changing the actual file type and the above javax.faces.DEFAULT_SUFFIX value to .xhtml worked correctly in every case.
This error occurred both with a simple Primefaces test page:-

<html xmlns=’http://www.w3c.org/1999/xhtml’
xmlns:f=’http://java.sun.com/jsf/core’
xmlns:h=’http://java.sun.com/jsf/html’
xmlns:p=’http://primefaces.prime.com.tr/ui’>
<h:head> </h:head>
<h:body>
<p:editor />
</h:body>
</html>

and also with a simple JSF page in a non Primefaces JSF 2 faceted eclipse web project:-

<html xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<title>Test Page Title</title>
</head>
<body>
Test page body
</body>
</html>

It was therefore clear that the error was not Primefaces related, but appeared to be recursion caused by a servlet mapping issue. This post on the Glassfish Forums reported the issue – there was some discussion but no resolution, and I don’t think a bug has been raised.  This post also reported the same issue. Whilst I found a number of other posts too with what seemed like a related issue, there appeared to be no clear conclusion on any of them re the nature of the problem or a fix for it. I tried other combinations such as path mapping using “/faces/*” for the url pattern, “.jsf” for the default suffix, and “http://localhost/PrimeTest1/faces/index.jsf” for the url, but in this case the above error did not occur but a blank page was displayed. On examining the source for the page, it turned out to be the original page source i.e. it had not passed through the faces servlet.

My conclusion is that the servlet mapping/url pattern handling for Glassfish V3.0.1 has some issues, the precise nature of which is not clear. My solution is to use “.xhtml” for the actual filetypes and for the default suffix, and extension mapping using “*.jsf” for the url pattern – this combination works fine with no issues.

No Comments »