Sure, I was in the process of debugging. This is what I found so far that happens when clicking the column header to sort (skipping the non-relevant steps):
1) Method GridSortModel.updateSort(String) gets called with the column name as the arg. 2) CollectionGridDataSource.prepare(int, int, List<SortConstraint>) gets called. Its last arg (sortConstraints) contains only one element (a SortConstraint). This SortConstraint instance has a propertyModel field that contains a PropertyModelImpl instance whose 'conduit' field is null. 3) This prepare method retrieves that conduit (null) and defines a Comparator instance where the conduit is used to retrieve the two values to compare: conduit.get(row1) and conduit.get(row2) . But 'conduit' is null so the null pointer occurs. However I don't know how to tell from this what is the behavior difference from 5.3.7 because I should undo and then redo too much configuration in order to go back to 5.3.7 . If I could have this figured out it would be very useful, but I'm starting to think that I should just forget about 5.3.7, do it right in 5.3.8 and test heavily to find possible other code that needs the same fix. -----Original Message----- From: Chris Poulsen [mailto:mailingl...@nesluop.dk] Sent: Tuesday, June 28, 2016 16:35 To: Tapestry users <users@tapestry.apache.org> Subject: Re: Null pointer on sort with 5.3.8 that didn't occur with 5.3.7 Hook up a debugger and see what is going on when the NPE is thrown? On Tue, Jun 28, 2016 at 3:43 PM, Davide Vecchi <d...@amc.dk> wrote: > Thanks, those are interesting options to change my design, which I > will probably have to do. > > But at this stage I need to focus on why the outcome of defining > columns in that way is different in 5.3.8, because it might be that > more areas of this web application are affected by differences in > 5.3.8 and I haven't found out these areas yet. > > Or perhaps, would it be correct to say that that way of defining > columns is not correct in general, regardless of Tapestry version ? > Maybe this is the case and this incorrect way was being somehow "forgiven" by > 5.3.7 ? > > > -----Original Message----- > From: Chris Poulsen [mailto:mailingl...@nesluop.dk] > Sent: Tuesday, June 28, 2016 15:32 > To: Tapestry users <users@tapestry.apache.org> > Subject: Re: Null pointer on sort with 5.3.8 that didn't occur with > 5.3.7 > > Also you can control the display blocks using the data-type on the > bean model, if you need something special. > > -- > Chris > > On Tue, Jun 28, 2016 at 3:30 PM, Chris Poulsen > <mailingl...@nesluop.dk> > wrote: > > > You can use a bean model for variable number of columns, that one > > also gives you full control over conduits etc. > > > > Inject BeanModelSource and create a display model for your data > > source, use .include (or similar) to whitelist the desired > > attributes in the generated model and model.add to get your > > synthetic columns > defined. > > > > -- > > Chris > > > > On Tue, Jun 28, 2016 at 3:13 PM, Davide Vecchi <d...@amc.dk> wrote: > > > >> Thanks for the answers, it's becoming more clear. > >> > >> The possibility suggested by Kalle makes sense, however I made some > >> test about it and I don't think it's the cause of my problem. This > >> grid column was being sorted without exceptions with Java 7 + > >> Tapestry 5.3.7, plus I checked and none of the values in the column > >> is null. I have also tested calling Arrays.sort with some null > >> elements and it throws a null pointer both with Java 7 and Java 8. > >> My problem has most probably to do with the fact that that column > >> is not part of the grid data source, as Cezary suggested, and it > >> was so also when we were using Java 7. > >> > >> About Cezary's hypothesis, I think my problem is definitely in that > >> area, but there is probably also something going on related to the > >> different Tapestry version because the column was defined in the > >> same way when using > >> 5.3.7 and in that case there was no exception. > >> > >> The column is defined like this: > >> > >> - In the page template, one param of the grid tag is > >> > >> t:add="prop:gridAdd" > >> > >> - In the page Java code, there is the corresponding > >> > >> public String getGridAdd() { > >> return " myColumn1, myColumn2, myColumn3, myColumn4"; > >> } > >> > >> where let's say that "myColumn3" is the column whose sorting fails. > >> > >> - In the page template, within the t:grid tag there is the > >> definition of the customized content of that column: > >> > >> <p: myColumn3Cell>${ myColumn3}</p: myColumn3Cell> > >> > >> - In the page Java code, there is the method returning the value > >> for that > >> column: > >> > >> public String getMyColumn3() > >> { > >> return aStringThatIsNeverNull; > >> } > >> > >> So I'm trying to find out if this way of defining my column is not > >> right in 5.3.8 although it was not failing in 5.3.7, in order to > rectify it. > >> > >> > >> -----Original Message----- > >> From: Cezary Biernacki [mailto:cezary...@gmail.com] > >> Sent: Monday, June 27, 2016 18:10 > >> To: Tapestry users <users@tapestry.apache.org> > >> Subject: Re: Null pointer on sort with 5.3.8 that didn't occur with > >> 5.3.7 > >> > >> Your stack trace seems to indicate that conduit (a mechanism > >> connecting Tapestry with a column) is not available. It can happen > >> if the column is manually added to the model. Was the column > >> sortable with > Tapestry 5.3.7? > >> How is this column defined? > >> > >> Best regards, > >> Cezary > >> > >> > >> On Mon, Jun 27, 2016 at 4:43 PM, Davide Vecchi <d...@amc.dk> wrote: > >> > >> > Hi everybody > >> > > >> > For now I cannot post code to reproduce this problem because it > >> > only occurs with one columns of a specific grid from a big > >> > application and so far I wasn't able to extract the code to > >> > reproduce the error into a runnable example. But after posting > >> > this I will keep trying and if I manage I will post that. > >> > > >> > We migrated this web application from Java 1.7 + Tapestry 5.3.7 > >> > to Java > >> > 1.8 with Tapestry 5.3.8 . > >> > > >> > Clicking on the column header of this column - which contains > >> > String values - causes the exception below. > >> > > >> > While I'm investigating this error I was wondering if someone is > >> > aware of differences in the grid sorting of Tapestry 5.3.8 that > >> > might cause it to throw a null-pointer where Tapestry 5.3.7 > >> > wouldn't (and maybe should; it's likely that there is a mistake > >> > of mine that was somehow being "forgiven" by 5.3.7). > >> > > >> > Stacktrace: > >> > > >> > java.lang.NullPointerException > >> > ? > >> > org.apache.tapestry5.internal.grid.CollectionGridDataSource$2.com > >> > pa > >> > re( > >> > CollectionGridDataSource.java:78) ? > >> > org.apache.tapestry5.internal.grid.CollectionGridDataSource$3.com > >> > pa > >> > re( > >> > CollectionGridDataSource.java:91) ? > >> > java.util.TimSort.countRunAndMakeAscending(TimSort.java:355) > >> > ? java.util.TimSort.sort(TimSort.java:234) > >> > ? java.util.Arrays.sort(Arrays.java:1512) > >> > ? java.util.ArrayList.sort(ArrayList.java:1454) > >> > ? java.util.Collections.sort(Collections.java:175) > >> > ? > >> > org.apache.tapestry5.internal.grid.CollectionGridDataSource.prepa > >> > re > >> > (Co > >> > llectionGridDataSource.java:97) > >> > ? > >> > my.package.gui.tapestry.components.AMCGridEmbedded$CachingDataSou > >> > rc > >> > e.p > >> > repare(AMCGridEmbedded.java:853) > >> > ? > >> > my.package.gui.tapestry.components.AMCGridEmbedded.setupDataSourc > >> > e( > >> > AMC > >> > GridEmbedded.java:1174) > >> > ? > >> > my.package.gui.tapestry.components.AMCGridEmbedded.setupRender(AM > >> > CG > >> > rid > >> > Embedded.java:655) > >> > ? > >> > my.package.gui.tapestry.components.AMCGridEmbedded.advised$setupR > >> > en > >> > der > >> > _1a14d3f8fd924(AMCGridEmbedded.java) > >> > ? > >> > my.package.gui.tapestry.components.AMCGridEmbedded$Invocation_set > >> > up Ren der_1a14d3f8fd923.proceedToAdvisedMethod(Unknown > >> > Source) > >> > ? > >> > > >> org.apache.tapestry5.internal.plastic.AbstractMethodInvocation.proc > >> ee > >> d(AbstractMethodInvocation.java:84) > >> > ? .... > >> > ? .... > >> > > >> > > >> > > > > >
