Re: [Stripes-users] Strange introspection issue after upgrade to 1.5.2
Hi John,
In order to narrow down the search, have you tried the 1.5.2 webapp in your
previous app server etc. ?
That way you could know if Stripes is the problem, or if it's your app
server...
Cheers
Remi
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
AbstractEntityShort {
// overrides for equals and hashcode for a 3 part business key (ID,
version, revision)
}
public abstract class AbstractEntityPK extends Serializable implements
EntityPK {
// equals and hashcode for 1 part key, ID
}
public interface EntityPK 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
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
AbstractEntityShort {
// overrides for equals and hashcode for a 3 part business key (ID,
version, revision)
}
public abstract class AbstractEntityPK extends Serializable implements
EntityPK {
// equals and hashcode for 1 part key, ID
}
public interface EntityPK 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.
Re: [Stripes-users] UTF-8 in forms problem
Daniil,
There was a thread in February IIRC on this and solutions were
mentioned. End-to-end UTF-8 support requires multiple layers.
If you are looking at simply posting data and having it encoded in
UTF-8 then AFAIK Stripes already performs
request.setCharacterEncoding(...) passing in the result of the call to
getCharacterEncoding() (if I recall the method name correctly) and is
easily subclassed in your own LocalePicker. I simply hard code that
method to return UTF-8 as I deal with many languages and only care
about enabling UTF-8.
The filter should be unnecessary and some have argued that the filter
provides a generic foundation for enabling UTF-8 support across
multiple frameworks and projects. I'd be curious to see why this
doesn't work with Stripes but would need to see your custom LocalePicker
and if necessary web.xml (if you set the character encoding in web.xml
vs. hard coding in your custom LocalePicker).
Cheers,
--Nikolaos
Daniil Sosonkin wrote:
After writing to the group, I've managed to fix the problem! Solution
was to add request.setCharacterEncoding(UTF-8); in my filter. After
that - it all works peaches.
On 5/3/2011 1:43 PM, Daniil Sosonkin wrote:
Hi all - I've been out of this for some time, but now back to UTF-8
issue with Stripes and mySQL. First and foremost, I'd like to resolve
Stripes on this topic. In my case, I'm interested in UTF-8 and only
in UTF8. No other character sets will appear as we're are
international. I have partial success, not enough to proceed to
production. It seems as if I'm missing something.
Here's how I test it. There's MyLocalePicker which picks picks
appropriate Locale and ALWAYS returns encoding as UTF-8. I have no
problems outputting UTF-8 text because header is always set to:
Content-type: text/html;charset=UTF-8. Necessary JSPs that contain
UTF, have proper pageEncoding set on them as well.
Then I have very very simple test.jsp that takes the text.
s:form beanclass=com.orbis.web.actions.Test
s:text name=str /s:submit name=add /
/s:form
The action bean looks as following:
package com.orbis.web.actions;
import com.orbis.web.*;
import net.sourceforge.stripes.action.*;
@UrlBinding(/test.action)
public class Test extends MyActionBean
{
private String str;
public String getStr()
{
return str;
}
public void setStr(String str)
{
this.str = str;
}
public Resolution test() throws SQLException
{
return new ForwardResolution(/test2.jsp);
}
}
And test2.jsp looks as simple as the following:
%--@elvariable id=actionBean type=com.orbis.web.actions.Test--%
%@ taglib prefix=fmt uri=http://java.sun.com/jsp/jstl/fmt; %
%@ taglib prefix=fn uri=http://java.sun.com/jsp/jstl/functions; %
%@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; %
%@ taglib prefix=s
uri=http://stripes.sourceforge.net/stripes-dynattr.tld; %
%@ taglib prefix=o uri=/TLDs/tags.tld %
%@ page isELIgnored=false %
Added: ${actionBean.str}
The problem is that resulting text is all grumbled. The success comes
when I change setStr to the following:
this.str = new String(str.getBytes(ISO-8859-1), UTF-8);
Then text becomes true UTF and result of action bean is all fine. The
problem with that solution is that I don't want to do it, I'd like to
have Stripes do that for me. I really think that its not problem with
Stripes, but I did something wrong and not utilizing Stripes
correctly. Will happily provide source to MyLocalePicker if needed.
BTW - tomcat 7.0.11 server.xml contains URIEncoding=UTF-8 for GET
requests.
We sort of need to resolve this as we have to start supporting
international input and not just output.
Thank you,
Daniil
--
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
--
Nikolaos Giannopoulos
Director, Information Technology
BrightMinds Software Inc.
e. nikol...@brightminds.org
w. www.brightminds.org
t. 1.613.822.1700
c. 1.613.797.0036
f. 1.613.822.1915
--
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.
