Re: FW: Null pointer on sort with 5.3.8 that didn't occur with 5.3.7

[Chris Poulsen]

I guess using t:add is OK as long as the grid is not performing operations
where it needs to access the property in the data source (for operations
like sorting/filtering).

Generally speaking we (@work) almost always end up using bean models,
except in the most simple cases.

-- 
Chris

On Thu, Jun 30, 2016 at 11:04 AM, Davide Vecchi  wrote:

> Thanks for the pointers, creating a BeanModel and adding my extra columns
> to it sounds like the right way to go. As an emergency solution for now I'm
> just going through all grids and adding the t:add columns into
> t:excludeSort in order to avoid the crashes on sorting. Then I will work on
> the actual solution with the BeanModel.
>
> In the meantime, regardless of these crashes and of whether it's 5.3.7 or
> 5.3.8, I'm still wondering if my way of defining these t:add columns
> (pasted below for convenience) has something wrong in general. Any opinion
> about that would be very useful.
>
> 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:
>
> ${ myColumn3}
>
> - In the page Java code, there is the method returning the value for that
> column:
>
> public String getMyColumn3()
> {
> return aStringThatIsNeverNull;
> }
>
> 
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>

RE: FW: Null pointer on sort with 5.3.8 that didn't occur with 5.3.7

[Davide Vecchi]

Thanks for the pointers, creating a BeanModel and adding my extra columns to it 
sounds like the right way to go. As an emergency solution for now I'm just 
going through all grids and adding the t:add columns into t:excludeSort in 
order to avoid the crashes on sorting. Then I will work on the actual solution 
with the BeanModel.

In the meantime, regardless of these crashes and of whether it's 5.3.7 or 
5.3.8, I'm still wondering if my way of defining these t:add columns (pasted 
below for convenience) has something wrong in general. Any opinion about that 
would be very useful.

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:

${ myColumn3}

- In the page Java code, there is the method returning the value for that 
column:

public String getMyColumn3()
{
return aStringThatIsNeverNull;
}




-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: FW: Null pointer on sort with 5.3.8 that didn't occur with 5.3.7

[Dmitry Gusev]

Just a correction, that t:add is not just unnecessary, but it will be
ignored if you specify the beanModel explicitly:


> A comma-seperated list of property names to be added to the
> org.apache.tapestry5.beaneditor.BeanModel. Cells for added columns will be
> blank unless a cell override is provided. This parameter is only used when
> a default model is created automatically.



http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/corelib/components/Grid.html




On Wed, Jun 29, 2016 at 5:57 PM, Chris Poulsen 
wrote:

> I'm guessing that something in the sorting part attempts to pull out the
> value from your passed data source (possibly coerced from a collection).
>
> The thing is that your data source does not contain the property (as it is
> synthetic) and you do not really pull the value from the data source ever,
> but from the "getMyColumn3" getter instead. The sorting stuff that attempts
> to extract the value for comparison has no way of knowing how to retrieve
> the value as the conduit is null.
>
> In order to provide the grid with the means to extract the value for
> "myColumn3" you should provide a conduit (can be done by creating a
> BeanModel and adding your column(s) with proper conduits. Judging from your
> example you can specify the data type as text (or string or what ever it is
> called in DataTypeConstants).
>
> Then the override (p:myColumn3Cell) and the t:add="." is not
> necessary.. You can keep the override if you need to.
>
> --
> Chris
>
> On Wed, Jun 29, 2016 at 12:04 PM, Davide Vecchi  wrote:
>
> > I changed my plan of finding out what causes this difference between
> 5.3.7
> > and 5.3.8. Instead I will go with some re-design, using some suggestions
> I
> > got here.
> >
> > However I am still very interested in knowing whether my way of defining
> > these t:add columns (pasted below) in general has something wrong or not
> so
> > right or not Tapestry-friendly. If it does, I might try to rectify that
> to
> > see if that helps.
> >
> > 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:
> >
> > ${ myColumn3}
> >
> > - In the page Java code, there is the method returning the value for that
> > column:
> >
> > public String getMyColumn3()
> > {
> > return aStringThatIsNeverNull;
> > }
> >
> > Thanks in advance for any possible feedback or hint or any related
> thought.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> > For additional commands, e-mail: users-h...@tapestry.apache.org
> >
>



-- 
Dmitry Gusev

AnjLab Team
http://anjlab.com

Re: FW: Null pointer on sort with 5.3.8 that didn't occur with 5.3.7

[Chris Poulsen]

I'm guessing that something in the sorting part attempts to pull out the
value from your passed data source (possibly coerced from a collection).

The thing is that your data source does not contain the property (as it is
synthetic) and you do not really pull the value from the data source ever,
but from the "getMyColumn3" getter instead. The sorting stuff that attempts
to extract the value for comparison has no way of knowing how to retrieve
the value as the conduit is null.

In order to provide the grid with the means to extract the value for
"myColumn3" you should provide a conduit (can be done by creating a
BeanModel and adding your column(s) with proper conduits. Judging from your
example you can specify the data type as text (or string or what ever it is
called in DataTypeConstants).

Then the override (p:myColumn3Cell) and the t:add="." is not
necessary.. You can keep the override if you need to.

-- 
Chris

On Wed, Jun 29, 2016 at 12:04 PM, Davide Vecchi  wrote:

> I changed my plan of finding out what causes this difference between 5.3.7
> and 5.3.8. Instead I will go with some re-design, using some suggestions I
> got here.
>
> However I am still very interested in knowing whether my way of defining
> these t:add columns (pasted below) in general has something wrong or not so
> right or not Tapestry-friendly. If it does, I might try to rectify that to
> see if that helps.
>
> 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:
>
> ${ myColumn3}
>
> - In the page Java code, there is the method returning the value for that
> column:
>
> public String getMyColumn3()
> {
> return aStringThatIsNeverNull;
> }
>
> Thanks in advance for any possible feedback or hint or any related thought.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>

FW: Null pointer on sort with 5.3.8 that didn't occur with 5.3.7

[Davide Vecchi]

I changed my plan of finding out what causes this difference between 5.3.7 and 
5.3.8. Instead I will go with some re-design, using some suggestions I got here.

However I am still very interested in knowing whether my way of defining these 
t:add columns (pasted below) in general has something wrong or not so right or 
not Tapestry-friendly. If it does, I might try to rectify that to see if that 
helps.

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:

${ myColumn3}

- In the page Java code, there is the method returning the value for that 
column:

public String getMyColumn3()
{
return aStringThatIsNeverNull;
}

Thanks in advance for any possible feedback or hint or any related thought.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

RE: Null pointer on sort with 5.3.8 that didn't occur with 5.3.7

[Davide Vecchi]

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) 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 
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  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 
> 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 
> 
> 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  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:
> >>
> >> ${ myColumn3}
> >>
> >> - 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 

Re: Null pointer on sort with 5.3.8 that didn't occur with 5.3.7

[Chris Poulsen]

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  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 
> 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 
> 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  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:
> >>
> >> ${ myColumn3}
> >>
> >> - 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 
> >> 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  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 

RE: Null pointer on sort with 5.3.8 that didn't occur with 5.3.7

[Davide Vecchi]

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 
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 
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  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:
>>
>> ${ myColumn3}
>>
>> - 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 
>> 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  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
>> > ?
>> > 

Re: Null pointer on sort with 5.3.8 that didn't occur with 5.3.7

[Chris Poulsen]

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 
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  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:
>>
>> ${ myColumn3}
>>
>> - 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 
>> 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  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.compare(
>> > CollectionGridDataSource.java:78)
>> > ?
>> > org.apache.tapestry5.internal.grid.CollectionGridDataSource$3.compare(
>> > 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.prepare(Co
>> > llectionGridDataSource.java:97)
>> > ?
>> > my.package.gui.tapestry.components.AMCGridEmbedded$CachingDataSource.p
>> > repare(AMCGridEmbedded.java:853)
>> > ?
>> > my.package.gui.tapestry.components.AMCGridEmbedded.setupDataSource(AMC
>> > GridEmbedded.java:1174)
>> > ?
>> > 

Re: Null pointer on sort with 5.3.8 that didn't occur with 5.3.7

[Chris Poulsen]

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  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:
>
> ${ myColumn3}
>
> - 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 
> 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  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.compare(
> > CollectionGridDataSource.java:78)
> > ?
> > org.apache.tapestry5.internal.grid.CollectionGridDataSource$3.compare(
> > 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.prepare(Co
> > llectionGridDataSource.java:97)
> > ?
> > my.package.gui.tapestry.components.AMCGridEmbedded$CachingDataSource.p
> > repare(AMCGridEmbedded.java:853)
> > ?
> > my.package.gui.tapestry.components.AMCGridEmbedded.setupDataSource(AMC
> > GridEmbedded.java:1174)
> > ?
> > my.package.gui.tapestry.components.AMCGridEmbedded.setupRender(AMCGrid
> > Embedded.java:655)
> > ?
> > my.package.gui.tapestry.components.AMCGridEmbedded.advised$setupRender
> > _1a14d3f8fd924(AMCGridEmbedded.java)
> > ?
> > my.package.gui.tapestry.components.AMCGridEmbedded$Invocation_setupRen
> > der_1a14d3f8fd923.proceedToAdvisedMethod(Unknown
> > Source)
> 

RE: Null pointer on sort with 5.3.8 that didn't occur with 5.3.7

[Davide Vecchi]

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:

${ myColumn3}

- 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 
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  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.compare(
> CollectionGridDataSource.java:78)
> ?
> org.apache.tapestry5.internal.grid.CollectionGridDataSource$3.compare(
> 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.prepare(Co
> llectionGridDataSource.java:97)
> ?
> my.package.gui.tapestry.components.AMCGridEmbedded$CachingDataSource.p
> repare(AMCGridEmbedded.java:853)
> ?
> my.package.gui.tapestry.components.AMCGridEmbedded.setupDataSource(AMC
> GridEmbedded.java:1174)
> ?
> my.package.gui.tapestry.components.AMCGridEmbedded.setupRender(AMCGrid
> Embedded.java:655)
> ?
> my.package.gui.tapestry.components.AMCGridEmbedded.advised$setupRender
> _1a14d3f8fd924(AMCGridEmbedded.java)
> ?
> my.package.gui.tapestry.components.AMCGridEmbedded$Invocation_setupRen
> der_1a14d3f8fd923.proceedToAdvisedMethod(Unknown
> Source)
> ?
> org.apache.tapestry5.internal.plastic.AbstractMethodInvocation.proceed(AbstractMethodInvocation.java:84)
> ?  
> ?  
>
>

Re: Null pointer on sort with 5.3.8 that didn't occur with 5.3.7

[Cezary Biernacki]

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  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.compare(CollectionGridDataSource.java:78)
> ?
> org.apache.tapestry5.internal.grid.CollectionGridDataSource$3.compare(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.prepare(CollectionGridDataSource.java:97)
> ?
> my.package.gui.tapestry.components.AMCGridEmbedded$CachingDataSource.prepare(AMCGridEmbedded.java:853)
> ?
> my.package.gui.tapestry.components.AMCGridEmbedded.setupDataSource(AMCGridEmbedded.java:1174)
> ?
> my.package.gui.tapestry.components.AMCGridEmbedded.setupRender(AMCGridEmbedded.java:655)
> ?
> my.package.gui.tapestry.components.AMCGridEmbedded.advised$setupRender_1a14d3f8fd924(AMCGridEmbedded.java)
> ?
> my.package.gui.tapestry.components.AMCGridEmbedded$Invocation_setupRender_1a14d3f8fd923.proceedToAdvisedMethod(Unknown
> Source)
> ?
> org.apache.tapestry5.internal.plastic.AbstractMethodInvocation.proceed(AbstractMethodInvocation.java:84)
> ?  
> ?  
>
>

Re: Null pointer on sort with 5.3.8 that didn't occur with 5.3.7

[Kalle Korhonen]

I suspect the culprit is the Java upgrade rather than Tapestry. There are
some internal changes in the sorting algorithm (for example, see
https://bugs.openjdk.java.net/browse/JDK-8062797 although it doesn't
directly match your case). But basically, you have to make sure your grid
data source doesn't contain null values, or you feed a comparator to it
that can handle nulls.

Kalle

On Mon, Jun 27, 2016 at 7:43 AM, Davide Vecchi  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.compare(CollectionGridDataSource.java:78)
> ?
> org.apache.tapestry5.internal.grid.CollectionGridDataSource$3.compare(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.prepare(CollectionGridDataSource.java:97)
> ?
> my.package.gui.tapestry.components.AMCGridEmbedded$CachingDataSource.prepare(AMCGridEmbedded.java:853)
> ?
> my.package.gui.tapestry.components.AMCGridEmbedded.setupDataSource(AMCGridEmbedded.java:1174)
> ?
> my.package.gui.tapestry.components.AMCGridEmbedded.setupRender(AMCGridEmbedded.java:655)
> ?
> my.package.gui.tapestry.components.AMCGridEmbedded.advised$setupRender_1a14d3f8fd924(AMCGridEmbedded.java)
> ?
> my.package.gui.tapestry.components.AMCGridEmbedded$Invocation_setupRender_1a14d3f8fd923.proceedToAdvisedMethod(Unknown
> Source)
> ?
> org.apache.tapestry5.internal.plastic.AbstractMethodInvocation.proceed(AbstractMethodInvocation.java:84)
> ?  
> ?  
>
>

Null pointer on sort with 5.3.8 that didn't occur with 5.3.7

[Davide Vecchi]

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.compare(CollectionGridDataSource.java:78)
?  
org.apache.tapestry5.internal.grid.CollectionGridDataSource$3.compare(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.prepare(CollectionGridDataSource.java:97)
?  
my.package.gui.tapestry.components.AMCGridEmbedded$CachingDataSource.prepare(AMCGridEmbedded.java:853)
?  
my.package.gui.tapestry.components.AMCGridEmbedded.setupDataSource(AMCGridEmbedded.java:1174)
?  
my.package.gui.tapestry.components.AMCGridEmbedded.setupRender(AMCGridEmbedded.java:655)
?  
my.package.gui.tapestry.components.AMCGridEmbedded.advised$setupRender_1a14d3f8fd924(AMCGridEmbedded.java)
?  
my.package.gui.tapestry.components.AMCGridEmbedded$Invocation_setupRender_1a14d3f8fd923.proceedToAdvisedMethod(Unknown
 Source)
?  
org.apache.tapestry5.internal.plastic.AbstractMethodInvocation.proceed(AbstractMethodInvocation.java:84)
?  
?