0000115: ClassDependency issues with fields.length

Viewing Issue Simple Details [ Jump to Notes ]

[ View Advanced ] [ Issue History ] [ Print ]

Category

Severity

Reproducibility

Date Submitted

Last Update

0000115

[Resin]

minor

always

04-21-05 00:00

11-30-05 14:43

Reporter

sam

View Status

public

Assigned To

Priority

normal

Resolution

fixed

Status

closed

Product Version

3.0.12

Summary

0000115: ClassDependency issues with fields.length

Description

RSN-106
(rep by D Becker)

We have modified some code to print out some debugging
statements during our jsp compile process and have uncovered the following
bit of information. It looks as though, on those iterations that generate a
different digest, that the fields aren't being reported properly (jvm bug?).
Note that on the iteration with a wrong digest the fields.length is zero!

If that's the case, adding additional sorting on exceptions (which has already
been done for 3.0.13) won't solve our problem.

     checking it out ->
             digest after name: 9215447334371289679
             digest after modifiers: 6070610980392654982
             digest after super: 584557973813134322
             digest after interfaces: 584557973813134322
             check fields? true
             fields.length: 5
             digest after fields: -2324391753151957246
             digest after methods: -2298811758055344843
             digest for class com.hogwarts.ebuy.jsp.tag.ContactLensOrder == -2298811758055344843
             last investigated: null
             same as last? false
     checking it out ->
             digest after name: 9215447334371289679
             digest after modifiers: 6070610980392654982
             digest after super: 584557973813134322
             digest after interfaces: 584557973813134322
             check fields? true
             fields.length: 0
             digest after fields: 584557973813134322
             digest after methods: -3537301654060149217
             digest for class com.hogwarts.ebuy.jsp.tag.ContactLensOrder == -3537301654060149217
             last investigated: class com.hogwarts.ebuy.jsp.tag.ContactLensOrder
             same as last? true
     checking it out ->
             digest after name: 9215447334371289679
             digest after modifiers: 6070610980392654982
             digest after super: 584557973813134322
             digest after interfaces: 584557973813134322
             check fields? true
             fields.length: 5
             digest after fields: -2324391753151957246
             digest after methods: -2298811758055344843
             digest for class com.hogwarts.ebuy.jsp.tag.ContactLensOrder == -2298811758055344843
             last investigated: class
com.hogwarts.ebuy.jsp.tag.ContactLensOrder
             same as last? true

That "same as last?" thing refers to an "==" check of the Class objects
themselves.

Oh, and during some runs everything comes out fine with 5 fields found
each time and the same digest being generated in each case. Buggy VM or
subtle bug in the Resin code? I have yet to determine. But if all they
changed for 3.0.13 is some extra sorting, then there's still a problem
here.

Additional Information

Attached Files

Relationships

Notes
(0000136) ferg 04-21-05 00:00	The JVM version and OS would be helpful for this case. Thanks for the debugging code. I can't see, though, how the cl.getFields() returns different values for separate calls, unless it's a JVM bug. Looking at the 1.4 JVM code, there is caching in the getFields() that uses SoftReferences. The code in there looks okay, but there may be some kind of subtle bug in the JVM version in the bug report.

Issue History
Date Modified	Username	Field	Change
04-21-05 00:00	sam	New Issue
11-30-05 00:00	administrator	Fixed in Version	=> 3.0.14
11-30-05 14:43	ferg	Status	resolved => closed

Mantis 1.0.0rc3[^]

29 total queries executed.
27 unique queries executed.