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
