You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by "Henning P. Schmiedehausen" <hp...@intermeta.de> on 2003/04/07 10:32:41 UTC
Another Question about Intake
In the revisions before 1.7 there was a small code optimization in
getFieldSetter/getFieldGetter:
// we have already completed the reflection on the getter, so
// save it so we do not have to repeat
synchronized(getterMap)
{
try
{
Method getter = pd.getReadMethod();
((Map)getterMap.get(className)).put(propName, getter);
}
catch (Exception e)
{
Log.error(e);
}
}
and similiar in getFieldGetter
This fell out of 1.7 without much of a comment. Were there problems
with this code or is this an oversight? Quinton?
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Another Question about Intake
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Quinton McCombs" <qm...@nequalsone.com> writes:
>> >It has something to do with error handling from what I remember. It
>> >was not an oversight though.
>>
>> The code did report an error for the getter in the
>> getFieldSetter if you had a setter but no getter and vice
>> versa. If we remove that error logging, then I'd like to put
>> this code back in. Reason: Most of the times, the
>> getFieldSetter and getFieldGetter are called in sequence and
>> this would definitely speed things up with large forms
>> (Reflection is a real performance killer here and we do not
>> need to do it twice).
>>
>> Does anyone have a real objection to this?
>I would rather keep the error logging. When it fails due to an error in
>intake.xml, it becomes difficult to track down the source of the problem
>without the error logging in place.
That would be no problem. In this case, nothing is put into the
"other" map (getter map for getFieldSetter and vice versa) and the
error is reported in the "right" method call.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: Another Question about Intake
Posted by Quinton McCombs <qm...@nequalsone.com>.
> -----Original Message-----
> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> Sent: Tuesday, April 08, 2003 3:15 AM
> To: turbine-dev@jakarta.apache.org
> Subject: Re: Another Question about Intake
>
>
> "Quinton McCombs" <qm...@nequalsone.com> writes:
>
> >> -----Original Message-----
> >> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> >> Sent: Monday, April 07, 2003 3:33 AM
> >> To: turbine-dev@jakarta.apache.org
> >> Subject: Another Question about Intake
> >>
> >>
> >> In the revisions before 1.7 there was a small code optimization in
> >> getFieldSetter/getFieldGetter:
> >>
> >> // we have already completed the reflection on the getter, so
> >> // save it so we do not have to repeat
> >> synchronized(getterMap)
> >> {
> >> try
> >> {
> >> Method getter = pd.getReadMethod();
> >> ((Map)getterMap.get(className)).put(propName, getter);
> >> }
> >> catch (Exception e)
> >> {
> >> Log.error(e);
> >> }
> >> }
> >>
> >> and similiar in getFieldGetter
> >>
> >> This fell out of 1.7 without much of a comment. Were there
> >> problems with this code or is this an oversight? Quinton?
>
> >It has something to do with error handling from what I remember. It
> >was not an oversight though.
>
> The code did report an error for the getter in the
> getFieldSetter if you had a setter but no getter and vice
> versa. If we remove that error logging, then I'd like to put
> this code back in. Reason: Most of the times, the
> getFieldSetter and getFieldGetter are called in sequence and
> this would definitely speed things up with large forms
> (Reflection is a real performance killer here and we do not
> need to do it twice).
>
> Does anyone have a real objection to this?
I would rather keep the error logging. When it fails due to an error in
intake.xml, it becomes difficult to track down the source of the problem
without the error logging in place.
> Regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> Java, perl, Solaris, Linux, xSP Consulting, Web Services
> freelance consultant -- Jakarta Turbine Development -- hero for hire
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Another Question about Intake
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Quinton McCombs" <qm...@nequalsone.com> writes:
>> -----Original Message-----
>> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
>> Sent: Monday, April 07, 2003 3:33 AM
>> To: turbine-dev@jakarta.apache.org
>> Subject: Another Question about Intake
>>
>>
>> In the revisions before 1.7 there was a small code optimization in
>> getFieldSetter/getFieldGetter:
>>
>> // we have already completed the reflection on the getter, so
>> // save it so we do not have to repeat
>> synchronized(getterMap)
>> {
>> try
>> {
>> Method getter = pd.getReadMethod();
>> ((Map)getterMap.get(className)).put(propName, getter);
>> }
>> catch (Exception e)
>> {
>> Log.error(e);
>> }
>> }
>>
>> and similiar in getFieldGetter
>>
>> This fell out of 1.7 without much of a comment. Were there
>> problems with this code or is this an oversight? Quinton?
>It has something to do with error handling from what I remember. It was
>not an oversight though.
The code did report an error for the getter in the getFieldSetter if
you had a setter but no getter and vice versa. If we remove that error
logging, then I'd like to put this code back in. Reason: Most of the
times, the getFieldSetter and getFieldGetter are called in sequence
and this would definitely speed things up with large forms (Reflection
is a real performance killer here and we do not need to do it twice).
Does anyone have a real objection to this?
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: Another Question about Intake
Posted by Quinton McCombs <qm...@nequalsone.com>.
> -----Original Message-----
> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> Sent: Monday, April 07, 2003 3:33 AM
> To: turbine-dev@jakarta.apache.org
> Subject: Another Question about Intake
>
>
> In the revisions before 1.7 there was a small code optimization in
> getFieldSetter/getFieldGetter:
>
> // we have already completed the reflection on the getter, so
> // save it so we do not have to repeat
> synchronized(getterMap)
> {
> try
> {
> Method getter = pd.getReadMethod();
> ((Map)getterMap.get(className)).put(propName, getter);
> }
> catch (Exception e)
> {
> Log.error(e);
> }
> }
>
> and similiar in getFieldGetter
>
> This fell out of 1.7 without much of a comment. Were there
> problems with this code or is this an oversight? Quinton?
It has something to do with error handling from what I remember. It was
not an oversight though.
> Regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> Java, perl, Solaris, Linux, xSP Consulting, Web Services
> freelance consultant -- Jakarta Turbine Development -- hero for hire
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org