Hi, I can confirm this only happens with stripes 1.5.2 . The changes for STS-664 appear to be the problem. I am working on digging through those a bit and coming up with a reproducible test case. It is not due to idle time, I just got it to happen shortly after startup. Our session timeout is set to 4 hours and we have a timeout listener built to pop up a dialog, so it's not anything related to session. Some other thread is disturbing the cache maintained by the introspector. Ben, does this ring any bells? I'm specifically looking at the comment on rev 1184, it really looks like something is that cache is somehow changing from one minute to the next.
1177 10/20/09 12:36 PM 2 bengunter Fixed STS-664: JDK bug in bean introspection prevents Stripes validation. Also added a unit test. 1181 10/21/09 3:17 PM 6 bengunter A more complete fix for STS-664: JDK bug in bean introspection prevents Stripes validation. I added several useful methods to help deal with this problem in ReflectUtil and updated several classes to get the property descriptors from ReflectUtil instead of directly from Introspector. ReflectUtil transparently handles bridge methods in PropertyDescriptors so that calling code need not be concerned with them. 1182 10/21/09 3:25 PM 1 bengunter Minor fix for STS-664. Null the setter after logging the error when a bridge goes nowhere. (This should not happen, but I have observed it on Java 1.6.0_03.) 1183 10/21/09 10:25 PM 1 bengunter STS-664: In the BridgedPropertyDescriptor constructor, pass "this" to resolvePropertyType(..) to get the correct result. Also override setReadMethod and setWriteMethod. *****1184 10/21/09 10:43 PM 2 bengunter STS-664: Create a copy of the array of property descriptors so that if and when we poke a BridgePropertyDescriptor into the array, we don't affect the cache maintained by Introspector. Also added a missing @Override to the unit test class. **1185 10/21/09 11:50 PM 1 bengunter STS-664: Never return null from resolveBridgedWriteMethod(..). If a better write method can't be found, then return the write method that was passed in. Sun's compiler marks certain methods as bridge while the Eclipse compiler does not **1186 10/21/09 11:56 PM 1 bengunter STS-664: Earlier commit (r1181) broke loadForClass(..) by repeatedly looking at the property descriptors for the bean type instead of each superclass as it climbs the hierarchy. Fixed here. . I can't say which is correct, but they definitely differ. This new behavior of not returning null seems to work well enough for both cases. Anyway, I will continue trying to pin the problem down... just wondering if Ben or anyone else would know what might be changing the introspector cache. It should always return Short - it always does after startup, but after a period of time / activity, it changes its mind and starts returning serializable. I have to say this is one of the most bizarre issues I've ever been up against =) .. no worries Thanks, John -----Original Message----- From: Gérald Quintana [mailto:gerald.quint...@gmail.com] Sent: Thursday, May 05, 2011 3:37 AM To: Stripes Users List Subject: Re: [Stripes-users] Strange introspection issue after upgrade to 1.5.2 Hello, The "~30min" delay may be a clue. Does it match your HTTP Session timeout (30min by default on Tomcat) ? You could control what's being stored in your HTTP Session... Gérald 2011/5/4 Newman, John W <newma...@d3onc.com>: > No sir, just the core jar .. we're not really doing anything too > wild.. if anything the object hierarchy we have is a bit weird due to > jaxb generation. But these same classes have always worked just fine. > Now after > 1.5.2 it works fine .. for a while then something happens to disturb it. > > > > net.sourceforge.stripes.util.bean.PropertyExpressionEvaluation > #fillInTypeInformation() > > > > one minute says java.lang.Short > > Same class, same field, next minute says java.lang.Serializable. > > > > We are not doing any crazy class reloading on the fly or anything like > that. I know bean introspection is cached somewhere, but as far as I > know there is no background thread going on updating those results as > they should never change. > > > > Our class hierarchy is a bit wild like I said. > > > > public class TheBindingTarget extends AbstractCompositeKeyEntity { > > private Short id; // initially this is detected as Short, at some > point it changes to Serializable. > > public Short getID() { return this.ID; } > > public void setID(Short id) { this.ID = id; } > > // other fields, not important > > } > > > > public abstract class AbstractCompositeKeyEntity extends > AbstractEntity<Short> { > > // overrides for equals and hashcode for a 3 part business key (ID, > version, revision) > > } > > > > public abstract class AbstractEntity<PK extends Serializable> > implements Entity<PK> { > > // equals and hashcode for 1 part key, ID > > } > > > > public interface Entity<PK extends Serializable> extends Serializable > { > > PK getID(); > > void setID(PK id); > > } > > > > The uppercase of "ID" comes from jaxb generated classes, which come > from someone else's xsd that I cannot control. I don't think the case > is an issue however. Given the nature of that hierarchy with generics > and all that, I can understand how the "get type" code could be > slightly thrown off for this case given the complexity going on in > there. However, it should be giving the same result every time - not > changing from one minute to the next right? > > > > -John > > > > From: Samuel Santos [mailto:sama...@gmail.com] > Sent: Wednesday, May 04, 2011 11:35 AM > To: Stripes Users List > Subject: Re: [Stripes-users] Strange introspection issue after upgrade > to > 1.5.2 > > > > Hi John, > > Do you use any Stripes extension/plugin? > > Cheers, > > -- > Samuel Santos > http://www.samaxes.com/ > > On Wed, May 4, 2011 at 3:24 PM, Newman, John W <newma...@d3onc.com> wrote: > > All, > > > > We've been using jdk5 / jboss4.22 / stripes 1.5 in production, stable > for a long time now. We've decided it's about time to do some > upgrades to jdk6 / jboss 5. The classpath scanner in stripes 1.5 does > not work on jboss 5, which was fixed in 1.5.2 as a result of > http://www.stripesframework.org/jira/browse/STS-655 > > > > Ok so in addition to jdk / jboss upgrade, we have to upgrade stripes.jar. > Not a big deal. Everything has gone smoothly, except for one > remaining issue that is about as bizarre as it gets. The application > starts up and runs fine. But, if you leave it sit idle for a period > of time, say ~30 minutes, sometimes, the bean introspection results will > somehow change. > This doesn't make a whole lot of sense to me, but it's what we're seeing. > > > > After startup, DefaultActionBeanPropertyBinder says this one field is > of type java.lang.Short (which it is), it will take a value and bind > into that no problem. You can click around all you want and > everything is good. Now, > ~30 minutes of idle time go by, all of a sudden > DefaultActionBeanPropertyBinder now decides to say this same field is > of type java.lang.Serializable, foolishly tries to do new > Serializable("value"); and fails. I can't explain why that result > would change over time. > > > > Might we be running into a regression that came from the changes in > http://www.stripesframework.org/jira/browse/STS-664 also in 1.5.2 ? > That's the only thing I'm seeing related to introspection. Because > this is such a weird issue, I'm not even sure if it's stripes related. > We are working on narrowing it down and continuing to research, but I > thought I'd ask here first. Unfortunately I can't run 1.5 in jboss5, > but we are trying > 1.5.2 in jboss4 right now (I suspect this will still show the issue). > > > > Is there any reasonable explanation for that change causing the > result to say "java.lang.Short" one minute, and "java.lang.Serializable" the > next? > Has anyone else ran into this? > > > > > > Thanks in advance for any ideas. > > -John > > ---------------------------------------------------------------------- > -------- WhatsUp Gold - Download Free Network Management Software The > most intuitive, comprehensive, and cost-effective network management > toolset available today. Delivers lowest initial acquisition cost and > overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Stripes-users mailing list > Stripes-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/stripes-users > > > > ---------------------------------------------------------------------- > -------- WhatsUp Gold - Download Free Network Management Software The > most intuitive, comprehensive, and cost-effective network management > toolset available today. Delivers lowest initial acquisition cost and > overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Stripes-users mailing list > Stripes-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/stripes-users > > ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
