Re: Separate Lists for Wiki Commits?
Mike Kienenberger wrote: more sarcasm Otherwise, why not combine the struts-dev and and struts-user lists? After all, email filters can eliminate whichever list you don't want to receive. In fact, we can just have all apache mailing lists go to one address /more sarcasm -Mike Come one... surely filtering out auto-generated messages with a nice easy to filter subject is easier than filtering out the random How do I do X? messages. :) Maybe not comparing apples to oranges but certainly comparing red apples to green ones. Even for sarcasm it's a stretch. ;) -Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed Action base class change
Frank,
For me it wouldn't be any use unless it also handled DynaBeans. Even then
I'd end up overriding it because I have some formatting utils which do
dates, arrays and collections. Seems to me if we put it in then we would end
up with a monster trying to satisy everyones needs and forever dealing with
bugzilla requests for enhacements (someone would want an i18n version!) -
all just for debugging.
The easiest thing is to just put all that code into a utility method - that
way its only a one liner in the toString() - even better if you have your
own base ActionForm that all you others derive from, then its only in one
place.
Also, there are a set of toString builders in commons lang which you might
like to use - including a reflection one like yours:
http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/builder/package-summary.html
http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/builder/ReflectionToStringBuilder.html
Niall
- Original Message -
From: Frank W. Zammetti [EMAIL PROTECTED]
To: Struts Developer [EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 4:29 AM
Subject: Re: Proposed Action base class change
Obviously I made a typo in the subject... this applies to the ActionForm
base class.
Did anyone have any comment on this? I've noticed a lack of activity on
the list lately...
Hello all...
I find myself all the time overloading toString() of my ActionForms for
debugging
purposes, so I can easily dump the current state of the object. I had
been doing
this for each ActionForm class, specifically for it, but it ocurrs to me
that a
general-purpose reflection-based approach would be better.
I'd like to propose adding this functionality to the ActionForm base
class. Here's
the code I propose adding:
import java.lang.reflect.Field;
public static final AVERAGE_FIELD_SIZE = 25;
public String toString() {
String str = ;
StringBuffer sb = null;
try {
Field[] fields = this.getClass().getDeclaredFields();
sb = new StringBuffer(fields.length * AVERAGE_FIELD_SIZE);
for (int i = 0; i fields.length; i++) {
if (sb.length() 0) { sb.append(, ); }
sb.append(fields[i].getName() + = + fields[i].get(this));
}
str = sb.toString().trim();
} catch (Exception e) {
str = Exception in ActionForm.toString() : + e;
}
return str;
}
The value of AVERAGE_FIELD_SIZE is a matter of debate, and it's of
course impossible
to come up with a real value, so something reasonable is the answer. 25
struck me
as a decent starting point.
What does everyone think? I find this functionality to be very useful
in my work,
and I suspect others may as well. The code doesn't add any dependencies
outside
J2SE, and it's certainly simple enough as to not be particularly risky.
Thanks all!
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Separate Lists for Wiki Commits?
Hi Martin, You make a good point - although I'd probably prefer a digest version of those kinds of events... However having said that I didn't mean it to turn into a controversial issue and was really just making an enquiry. So from my point of view the issue is now dead and I yield to the more senior of you (as I didn't have a strong view either way). Richard. PS When I say senior I mean in terms of Struts work not age :) Martin Cooper wrote: It would seem odd to me that people interested in the development of the Struts project would not be interested in seeing what changes are being made to the code or to the documentation on the wiki. Without tracking those, they would not really be in a position to discuss what needs to be done, since they would be missing the current status of what *is* being done. I am also against splitting the list, based on the above and on the increased overhead of having multiple lists requiring maintenance and moderation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31299] - Refactor RequestUtils to allow subclassing
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31299. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31299 Refactor RequestUtils to allow subclassing --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 08:53 --- Sorry, I did not know the TilesUtil strategy too well. Yes, the proposal sounds reasonable, and I'd like to see it implemented for the next release of Struts. Need some help with that? Hiran - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed Action base class change
I'm -1 on this.
By default, I think the ActionForms toString should be the default
Object.toString. If you need/desire you can easily still create a base
support class for your projects that implement the reflection based
toString you suggest.
The reason I'm anti- this is that it will cause (in some cases) field
values to be unexpectedly logged. And many times there are fields that
you don't want logged. i.e. passwords, credit cards, etc.
BTW - a similar utility is also available in commons-lang -
ToStringBuilder.
- Mike
On Wed, 2004-10-06 at 23:29, Frank W. Zammetti wrote:
Obviously I made a typo in the subject... this applies to the ActionForm
base class.
Did anyone have any comment on this? I've noticed a lack of activity on
the list lately...
Hello all...
I find myself all the time overloading toString() of my ActionForms for debugging
purposes, so I can easily dump the current state of the object. I had been doing
this for each ActionForm class, specifically for it, but it ocurrs to me that a
general-purpose reflection-based approach would be better.
I'd like to propose adding this functionality to the ActionForm base class. Here's
the code I propose adding:
import java.lang.reflect.Field;
public static final AVERAGE_FIELD_SIZE = 25;
public String toString() {
String str = ;
StringBuffer sb = null;
try {
Field[] fields = this.getClass().getDeclaredFields();
sb = new StringBuffer(fields.length * AVERAGE_FIELD_SIZE);
for (int i = 0; i fields.length; i++) {
if (sb.length() 0) { sb.append(, ); }
sb.append(fields[i].getName() + = + fields[i].get(this));
}
str = sb.toString().trim();
} catch (Exception e) {
str = Exception in ActionForm.toString() : + e;
}
return str;
}
The value of AVERAGE_FIELD_SIZE is a matter of debate, and it's of course
impossible
to come up with a real value, so something reasonable is the answer. 25 struck me
as a decent starting point.
What does everyone think? I find this functionality to be very useful in my work,
and I suspect others may as well. The code doesn't add any dependencies outside
J2SE, and it's certainly simple enough as to not be particularly risky.
Thanks all!
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Separate Lists for Wiki Commits?
-1 - use filters. (but my vote is just opinion and has no real weight) - Mike On Wed, 2004-10-06 at 23:52, James Mitchell wrote: I am also -1 on this. Why should I have to subscribe to so many lists? -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Mike Kienenberger [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 7:45 PM Subject: Re: Separate Lists for Wiki Commits? Richard Bywater [EMAIL PROTECTED] wrote: Hi, Just wondering if there has been any consideration to creating new lists to use for Wiki Commit updates? (Or maybe just one update list) I know that I can filter these out in the email client but was thinking it might be useful to be able to only receive discussions. It's a bit more work to maintain, but it'd really be nice to have dev-commit -- commit messages dev-wiki -- wiki messages dev-talk -- discussion dev -- all of the above That maintains backward compatibility, yet also lets those of us who really don't care about the wiki and commit pages to drop them by moving to dev-talk. -Mike (who's finally reduced his active mailbox down to a mere 539 messages) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed Action base class change
Hi Niall,
I certainly agree it would not be possible to satisfy everyone, but
seeing as the intrinsic toString() is all but useless (and people do
generally expect that to be the case with many classes), why not give an
implementation that is of at least some use to some people? Surely it
would be better than what you get now? Obviously it's something many
people will override, and that's of course the whole point of
inheritance. But providing even a slightly more useful default
implementation (and maybe telling people it's a basic default
implementation so as to try and keep the flood of bugzilla requests to a
minimum) seems to me like a good idea.
I can't address your point about dynabeans because I haven't used them
enough to be able to intelligently comment (which is to say I haven't
used them at all! :) )... I wouodn't imagine some basic implementation
would be too tough for them as well.
In any case, I will look at the toString builders you mentioned... I've
come to really like using the commons packages and I try to whenever I
can. This would be a good case I think, if it doesn't get added as I
proposed. I already have an ActionHelpers class with a bunch of
similarly-themed static methods for use from Actions, so maybe it's time
to do so for forms as well.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Niall Pemberton wrote:
Frank,
For me it wouldn't be any use unless it also handled DynaBeans. Even then
I'd end up overriding it because I have some formatting utils which do
dates, arrays and collections. Seems to me if we put it in then we would end
up with a monster trying to satisy everyones needs and forever dealing with
bugzilla requests for enhacements (someone would want an i18n version!) -
all just for debugging.
The easiest thing is to just put all that code into a utility method - that
way its only a one liner in the toString() - even better if you have your
own base ActionForm that all you others derive from, then its only in one
place.
Also, there are a set of toString builders in commons lang which you might
like to use - including a reflection one like yours:
http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/builder/package-summary.html
http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/builder/ReflectionToStringBuilder.html
Niall
- Original Message -
From: Frank W. Zammetti [EMAIL PROTECTED]
To: Struts Developer [EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 4:29 AM
Subject: Re: Proposed Action base class change
Obviously I made a typo in the subject... this applies to the ActionForm
base class.
Did anyone have any comment on this? I've noticed a lack of activity on
the list lately...
Hello all...
I find myself all the time overloading toString() of my ActionForms for
debugging
purposes, so I can easily dump the current state of the object. I had
been doing
this for each ActionForm class, specifically for it, but it ocurrs to me
that a
general-purpose reflection-based approach would be better.
I'd like to propose adding this functionality to the ActionForm base
class. Here's
the code I propose adding:
import java.lang.reflect.Field;
public static final AVERAGE_FIELD_SIZE = 25;
public String toString() {
String str = ;
StringBuffer sb = null;
try {
Field[] fields = this.getClass().getDeclaredFields();
sb = new StringBuffer(fields.length * AVERAGE_FIELD_SIZE);
for (int i = 0; i fields.length; i++) {
if (sb.length() 0) { sb.append(, ); }
sb.append(fields[i].getName() + = + fields[i].get(this));
}
str = sb.toString().trim();
} catch (Exception e) {
str = Exception in ActionForm.toString() : + e;
}
return str;
}
The value of AVERAGE_FIELD_SIZE is a matter of debate, and it's of
course impossible
to come up with a real value, so something reasonable is the answer. 25
struck me
as a decent starting point.
What does everyone think? I find this functionality to be very useful
in my work,
and I suspect others may as well. The code doesn't add any dependencies
outside
J2SE, and it's certainly simple enough as to not be particularly risky.
Thanks all!
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed Action base class change
That's a good point Mike, I didn't think of that. You might have
changed MY mind on this! I'll have to think about it a little more, but
you raise a solid issue.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Mike Stanley wrote:
I'm -1 on this.
By default, I think the ActionForms toString should be the default
Object.toString. If you need/desire you can easily still create a base
support class for your projects that implement the reflection based
toString you suggest.
The reason I'm anti- this is that it will cause (in some cases) field
values to be unexpectedly logged. And many times there are fields that
you don't want logged. i.e. passwords, credit cards, etc.
BTW - a similar utility is also available in commons-lang -
ToStringBuilder.
- Mike
On Wed, 2004-10-06 at 23:29, Frank W. Zammetti wrote:
Obviously I made a typo in the subject... this applies to the ActionForm
base class.
Did anyone have any comment on this? I've noticed a lack of activity on
the list lately...
Hello all...
I find myself all the time overloading toString() of my ActionForms for debugging
purposes, so I can easily dump the current state of the object. I had been doing
this for each ActionForm class, specifically for it, but it ocurrs to me that a
general-purpose reflection-based approach would be better.
I'd like to propose adding this functionality to the ActionForm base class. Here's
the code I propose adding:
import java.lang.reflect.Field;
public static final AVERAGE_FIELD_SIZE = 25;
public String toString() {
String str = ;
StringBuffer sb = null;
try {
Field[] fields = this.getClass().getDeclaredFields();
sb = new StringBuffer(fields.length * AVERAGE_FIELD_SIZE);
for (int i = 0; i fields.length; i++) {
if (sb.length() 0) { sb.append(, ); }
sb.append(fields[i].getName() + = + fields[i].get(this));
}
str = sb.toString().trim();
} catch (Exception e) {
str = Exception in ActionForm.toString() : + e;
}
return str;
}
The value of AVERAGE_FIELD_SIZE is a matter of debate, and it's of course impossible
to come up with a real value, so something reasonable is the answer. 25 struck me
as a decent starting point.
What does everyone think? I find this functionality to be very useful in my work,
and I suspect others may as well. The code doesn't add any dependencies outside
J2SE, and it's certainly simple enough as to not be particularly risky.
Thanks all!
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Proposed Action base class change
Hi, Frank.
I do not agree. While in most cases it is desireable to see inside a bean (hence I
created my
public static String toString(Object bean)
method), there are times when I just have to make sure a bean is not just equal but
the same instance.
The java.lang.Object.toString() methods allows me to that quite quickly as the memory
address is printed.
Unless you have another way to provide that information, I'd rather stick with the
default toString() plus some utility toString(Object) method. The impact for you is
not too much. What you code so far is:
log.debug(mybean=+mybean);
and you'd have to change that to
log.debug(mybean=+BeanUtil.toString(mybean));
which will allow you to either see the memory address or the contents, whatever you
prefer.
Hiran
-
Hiran Chaudhuri
SAG Systemhaus GmbH
Elsenheimer Straße 11
80867 München
Phone +49-89-54 74 21 34
Fax +49-89-54 74 21 99
-Original Message-
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 7. Oktober 2004 13:43
To: Struts Developers List
Subject: Re: Proposed Action base class change
Hi Niall,
I certainly agree it would not be possible to satisfy
everyone, but seeing as the intrinsic toString() is all but
useless (and people do generally expect that to be the case
with many classes), why not give an implementation that is of
at least some use to some people? Surely it would be better
than what you get now? Obviously it's something many people
will override, and that's of course the whole point of
inheritance. But providing even a slightly more useful
default implementation (and maybe telling people it's a basic
default implementation so as to try and keep the flood of
bugzilla requests to a
minimum) seems to me like a good idea.
I can't address your point about dynabeans because I haven't
used them enough to be able to intelligently comment (which
is to say I haven't used them at all! :) )... I wouodn't
imagine some basic implementation would be too tough for them as well.
In any case, I will look at the toString builders you
mentioned... I've come to really like using the commons
packages and I try to whenever I can. This would be a good
case I think, if it doesn't get added as I proposed. I
already have an ActionHelpers class with a bunch of
similarly-themed static methods for use from Actions, so
maybe it's time to do so for forms as well.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Niall Pemberton wrote:
Frank,
For me it wouldn't be any use unless it also handled
DynaBeans. Even
then I'd end up overriding it because I have some formatting utils
which do dates, arrays and collections. Seems to me if we put it in
then we would end up with a monster trying to satisy
everyones needs
and forever dealing with bugzilla requests for enhacements (someone
would want an i18n version!) - all just for debugging.
The easiest thing is to just put all that code into a
utility method -
that way its only a one liner in the toString() - even
better if you
have your own base ActionForm that all you others derive
from, then
its only in one place.
Also, there are a set of toString builders in commons
lang which you
might like to use - including a reflection one like yours:
http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/bui
lder/package-summary.html
http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/bui
lder/ReflectionToStringBuilder.html
Niall
- Original Message -
From: Frank W. Zammetti [EMAIL PROTECTED]
To: Struts Developer [EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 4:29 AM
Subject: Re: Proposed Action base class change
Obviously I made a typo in the subject... this applies to the
ActionForm base class.
Did anyone have any comment on this? I've noticed a lack
of activity
on the list lately...
Hello all...
I find myself all the time overloading toString() of my
ActionForms
for
debugging
purposes, so I can easily dump the current state of the object. I
had
been doing
this for each ActionForm class, specifically for it, but
it ocurrs to
me
that a
general-purpose reflection-based approach would be better.
I'd like to propose adding this functionality to the
ActionForm base
class. Here's
the code I propose adding:
import java.lang.reflect.Field;
public static final AVERAGE_FIELD_SIZE = 25; public String
toString()
{
String str = ;
StringBuffer sb = null;
try {
Field[] fields = this.getClass().getDeclaredFields();
sb = new StringBuffer(fields.length * AVERAGE_FIELD_SIZE);
for (int i = 0; i fields.length; i++) {
if (sb.length() 0) { sb.append(, ); }
tiles-definition - role association issue
Hi, I know this is not a correct place to post this message. But I didn't get any response for this question in User Mailing list. Kindly provide me some inputs on my question. Regards, Ashutosh Q U E S T I O N === As per the Tiles Definition file syntax In the tiles definition we can specify the role (Role to be checked when definition will be inserted in a page.) Similarly, It is possible to associate a role with tiles: put attribute. I'm intending to allow the definition to be used based on the role. The second scenario ( using tiles: put attribute) works fine for me. I have my Login page for the application as stated below. %@ taglib uri=/WEB-INF/struts-tiles.tld prefix=tiles % tiles:insert page=/WEB-INF/mainLayout.jsp flush=true tiles:put name=title value=Welcome Page/ tiles:put name=mainMenu value=/adminMenupanel.jsp role=admin/ tiles:put name=mainMenu value=/mgrMenupanel.jsp role=manager/ tiles:put name=mainMenu value=/usrMenupanel.jsp role=usr/ tiles:put name=mainHeader value=/header.jsp/ tiles:put name=mainBody value=/body.jsp/ tiles:put name=mainFooter value=/footer.jsp/ /tiles:insert Depending upon the user's role, correct definition is inserted. Now going on the same lines, when I have a definition with role specified, it doesn't seem to work. My tiles-definition is as follows. definition name=baseDef path=/WEB-INF/mainLayout.jsp put name=title value=Tomcat Server / put name=header value=/header.jsp/ put name=menu value=/menupanel.jsp/ put name=tab value=/ put name=body value=/ /definition definition name=Add extends=baseDef role=admin put name=tab value=/WEB-INF/pages/tab.jsp/ put name=body value=/WEB-INF/pages/body.jsp/ /definition This definition (Add) gets applied for each of my role, though I was presuming that only for the user with 'admin' role this definition will be executed. What am I missing? Is it not a correct approach? Kindly give some solution to achieve it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Proposed Action base class change
This should always give you the equivalent of Object's toString method:
Integer.toHexString(System.identityHashCode(obj)).
If anything gets added, I'd rather see something like what's used in
java.awt.Component. The toString method is implemented like:
public String toString() {
return getClass().getName() + [ + paramString() + ];
}
Then Component has its own implementation of the paramString method:
protected String paramString() {
...
return str;
}
Finally, subclasses invoke super.paramString and add their own information:
protected String paramString() {
return super.paramString() + ...;
}
The implementation of paramString for ActionForm should probably just look
like:
protected String paramString() {
return ;
}
;-) About the only thing worth adding might be the ActionServlet reference. In
the end, all this is doing is providing a convenient hook for subclasses. The
decision about what information to include is still the responsibility of the
subclasses (as it should be).
Note that DynaActionForm already provides its own implementation of toString,
which is inherited by DynaValidatorForm and DynaValidatorActionForm. So,
DynaActionForm could then be changed to remove its toString method and provide
a paramString method instead:
protected String paramString() {
StringBuffer buff = new StringBuffer();
if (!this.dynaValues.isEmpty()) {
buff.append(, );
for (Iterator iter = this.dynaValues().entrySet().iterator();
iter.hasNext();) {
Map.Entry entry = (Map.Entry)iter.next();
buff.append(entry.getKey()).append(=);
Object propValue = entry.getValue();
if (propValue == null) {
buff.append(NULL);
} else if (propValue.getClass().isArray()) {
buff.append([);
int length = Array.getLength(propValue);
for (int i = 0; i length; i++) {
buff.append(Array.get(propValue, i));
if (i (length - 1)) {
buff.append(, );
}
}
buff.append(]);
} else {
buff.append(propValue);
}
if (iter.hasNext()) {
buff.append(, );
}
}
}
return super.paramString() +
, dynaClass= + getDynaClass().getName() +
buff.toString();
}
Quoting [EMAIL PROTECTED]:
Frank,
I also had to go a long way until I found this approach. It actually came to
me when I saw in my project many data objects (= java beans) were generated
using UML tools that did not care about the toString() method my way. Next I
saw Castor XML/JAXB and JDO code generation, and finally had to decide that a
common base class or implementing each and every toString method is not the
solution.
With the static method I can apply my toString implementation to any object
that comes along - just what you need for debugging. I just wonder why the
Apache commons-beanutils does not provide such a method, and someone
mentioned it might be in commons-lang, but I could not find that either.
Hiran
-
Hiran Chaudhuri
SAG Systemhaus GmbH
Elsenheimer Straße 11
80867 München
Phone +49-89-54 74 21 34
Fax +49-89-54 74 21 99
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 7. Oktober 2004 14:22
To: [EMAIL PROTECTED]
Subject: RE: Proposed Action base class change
Another fair point. :)
Well, that's the reason I put the idea out there... I can't
think of every possible angle to look at it from... If I
thought I could, I wouldn't need to solicit opinions in the
first place.
Kind of depressing though... I'm trying to contribute, but so
far all my ideas have been shot down (but for good reasons,
so I'm not bitter about it). Just have to keep trying I suppose. :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Thu, October 7, 2004 8:56 am, [EMAIL PROTECTED] said:
Hi, Frank.
I do not agree. While in most cases it is desireable to see
inside a
bean (hence I created my
public static String toString(Object bean) method),
there are times
when I just have to make sure a bean is not just equal but the same
instance.
The java.lang.Object.toString() methods allows me to that quite
quickly as the memory address is printed.
Unless you have another way to provide that information, I'd rather
stick with the default toString() plus some utility
toString(Object)
method. The impact for you is not too much. What you code so far is:
log.debug(mybean=+mybean);
and you'd have to change that to
log.debug(mybean=+BeanUtil.toString(mybean));
which will allow you to either see the memory address or
the contents,
RE: Proposed Action base class change
Hi, Mike. Indeed I have not had a look at that class. But then, the ToStringBuilder makes it easier to write the toString method, while my approach saves me completely from writing it. Thanks for the hint anyway. Hiran - Hiran Chaudhuri SAG Systemhaus GmbH Elsenheimer Straße 11 80867 München Phone +49-89-54 74 21 34 Fax +49-89-54 74 21 99 -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 7. Oktober 2004 14:41 To: Struts Developers List Subject: RE: Proposed Action base class change snip With the static method I can apply my toString implementation to any object that comes along - just what you need for debugging. I just wonder why the Apache commons-beanutils does not provide such a method, and someone mentioned it might be in commons-lang, but I could not find that either. http://jakarta.apache.org/commons/lang/apidocs/org/apache/comm ons/lang/builder/ToStringBuilder.html#reflectionToString(java. lang.Object) String objString = ToStringBuilder.reflectionToString(object); - Mike Hiran - Hiran Chaudhuri SAG Systemhaus GmbH Elsenheimer Straße 11 80867 München Phone +49-89-54 74 21 34 Fax +49-89-54 74 21 99 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 7. Oktober 2004 14:22 To: [EMAIL PROTECTED] Subject: RE: Proposed Action base class change Another fair point. :) Well, that's the reason I put the idea out there... I can't think of every possible angle to look at it from... If I thought I could, I wouldn't need to solicit opinions in the first place. Kind of depressing though... I'm trying to contribute, but so far all my ideas have been shot down (but for good reasons, so I'm not bitter about it). Just have to keep trying I suppose. :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Thu, October 7, 2004 8:56 am, [EMAIL PROTECTED] said: Hi, Frank. I do not agree. While in most cases it is desireable to see inside a bean (hence I created my public static String toString(Object bean) method), there are times when I just have to make sure a bean is not just equal but the same instance. The java.lang.Object.toString() methods allows me to that quite quickly as the memory address is printed. Unless you have another way to provide that information, I'd rather stick with the default toString() plus some utility toString(Object) method. The impact for you is not too much. What you code so far is: log.debug(mybean=+mybean); and you'd have to change that to log.debug(mybean=+BeanUtil.toString(mybean)); which will allow you to either see the memory address or the contents, whatever you prefer. Hiran - Hiran Chaudhuri SAG Systemhaus GmbH Elsenheimer Stra?e 11 80867 M?nchen Phone +49-89-54 74 21 34 Fax +49-89-54 74 21 99 -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 7. Oktober 2004 13:43 To: Struts Developers List Subject: Re: Proposed Action base class change Hi Niall, I certainly agree it would not be possible to satisfy everyone, but seeing as the intrinsic toString() is all but useless (and people do generally expect that to be the case with many classes), why not give an implementation that is of at least some use to some people? Surely it would be better than what you get now? Obviously it's something many people will override, and that's of course the whole point of inheritance. But providing even a slightly more useful default implementation (and maybe telling people it's a basic default implementation so as to try and keep the flood of bugzilla requests to a minimum) seems to me like a good idea. I can't address your point about dynabeans because I haven't used them enough to be able to intelligently comment (which is to say I haven't used them at all! :) )... I wouodn't imagine some basic implementation would be too tough for them as well. In any case, I will look at the toString builders you mentioned... I've come to really like using the commons packages and I try to whenever I can. This would be a good case I think, if it doesn't get added as I proposed. I already have an ActionHelpers class with a bunch of similarly-themed static methods for use from Actions, so maybe it's time to do so for forms as well. -- Frank W. Zammetti Founder and Chief Software Architect
RE: Proposed Action base class change
Is this really more convenient than simply overriding toString() ?
- Mike
On Thu, 2004-10-07 at 09:45, Kris Schneider wrote:
This should always give you the equivalent of Object's toString method:
Integer.toHexString(System.identityHashCode(obj)).
If anything gets added, I'd rather see something like what's used in
java.awt.Component. The toString method is implemented like:
public String toString() {
return getClass().getName() + [ + paramString() + ];
}
Then Component has its own implementation of the paramString method:
protected String paramString() {
...
return str;
}
Finally, subclasses invoke super.paramString and add their own information:
protected String paramString() {
return super.paramString() + ...;
}
The implementation of paramString for ActionForm should probably just look
like:
protected String paramString() {
return ;
}
;-) About the only thing worth adding might be the ActionServlet reference. In
the end, all this is doing is providing a convenient hook for subclasses. The
decision about what information to include is still the responsibility of the
subclasses (as it should be).
Note that DynaActionForm already provides its own implementation of toString,
which is inherited by DynaValidatorForm and DynaValidatorActionForm. So,
DynaActionForm could then be changed to remove its toString method and provide
a paramString method instead:
protected String paramString() {
StringBuffer buff = new StringBuffer();
if (!this.dynaValues.isEmpty()) {
buff.append(, );
for (Iterator iter = this.dynaValues().entrySet().iterator();
iter.hasNext();) {
Map.Entry entry = (Map.Entry)iter.next();
buff.append(entry.getKey()).append(=);
Object propValue = entry.getValue();
if (propValue == null) {
buff.append(NULL);
} else if (propValue.getClass().isArray()) {
buff.append([);
int length = Array.getLength(propValue);
for (int i = 0; i length; i++) {
buff.append(Array.get(propValue, i));
if (i (length - 1)) {
buff.append(, );
}
}
buff.append(]);
} else {
buff.append(propValue);
}
if (iter.hasNext()) {
buff.append(, );
}
}
}
return super.paramString() +
, dynaClass= + getDynaClass().getName() +
buff.toString();
}
Quoting [EMAIL PROTECTED]:
Frank,
I also had to go a long way until I found this approach. It actually came to
me when I saw in my project many data objects (= java beans) were generated
using UML tools that did not care about the toString() method my way. Next I
saw Castor XML/JAXB and JDO code generation, and finally had to decide that a
common base class or implementing each and every toString method is not the
solution.
With the static method I can apply my toString implementation to any object
that comes along - just what you need for debugging. I just wonder why the
Apache commons-beanutils does not provide such a method, and someone
mentioned it might be in commons-lang, but I could not find that either.
Hiran
-
Hiran Chaudhuri
SAG Systemhaus GmbH
Elsenheimer Straße 11
80867 München
Phone +49-89-54 74 21 34
Fax +49-89-54 74 21 99
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 7. Oktober 2004 14:22
To: [EMAIL PROTECTED]
Subject: RE: Proposed Action base class change
Another fair point. :)
Well, that's the reason I put the idea out there... I can't
think of every possible angle to look at it from... If I
thought I could, I wouldn't need to solicit opinions in the
first place.
Kind of depressing though... I'm trying to contribute, but so
far all my ideas have been shot down (but for good reasons,
so I'm not bitter about it). Just have to keep trying I suppose. :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Thu, October 7, 2004 8:56 am, [EMAIL PROTECTED] said:
Hi, Frank.
I do not agree. While in most cases it is desireable to see
inside a
bean (hence I created my
public static String toString(Object bean) method),
there are times
when I just have to make sure a bean is not just equal but the same
instance.
The java.lang.Object.toString() methods allows me to that quite
quickly as the memory address is printed.
Unless you have another way to provide that information, I'd rather
stick with the default toString() plus some utility
toString(Object)
RE: Proposed Action base class change
wait a sec, I'm slightly confused. How is this static method different from your static method? Indeed, ToStringBuilder (as the name implies) assists in writing the toString method, but it also provides utility methods for representing objects as strings. There is no restriction on where it is used (it does not neccessarily need to be you toString method). i.e. I have an object instance 'myObject'. The class uses the default Object.toString method. I can then log myObject with either: log.debug(myObject) - which would output the default class name / hash code id or log.debug(ToStringBuilder.reflectionToString(myObject)) - which outputs the class [ parameter = value, ... ] format. I thought this is what you said your utility class did. Perhaps I misunderstood. - Mike On Thu, 2004-10-07 at 09:50, [EMAIL PROTECTED] wrote: Hi, Mike. Indeed I have not had a look at that class. But then, the ToStringBuilder makes it easier to write the toString method, while my approach saves me completely from writing it. Thanks for the hint anyway. Hiran - Hiran Chaudhuri SAG Systemhaus GmbH Elsenheimer Straße 11 80867 München Phone +49-89-54 74 21 34 Fax +49-89-54 74 21 99 -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 7. Oktober 2004 14:41 To: Struts Developers List Subject: RE: Proposed Action base class change snip With the static method I can apply my toString implementation to any object that comes along - just what you need for debugging. I just wonder why the Apache commons-beanutils does not provide such a method, and someone mentioned it might be in commons-lang, but I could not find that either. http://jakarta.apache.org/commons/lang/apidocs/org/apache/comm ons/lang/builder/ToStringBuilder.html#reflectionToString(java. lang.Object) String objString = ToStringBuilder.reflectionToString(object); - Mike Hiran - Hiran Chaudhuri SAG Systemhaus GmbH Elsenheimer Straße 11 80867 München Phone +49-89-54 74 21 34 Fax +49-89-54 74 21 99 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 7. Oktober 2004 14:22 To: [EMAIL PROTECTED] Subject: RE: Proposed Action base class change Another fair point. :) Well, that's the reason I put the idea out there... I can't think of every possible angle to look at it from... If I thought I could, I wouldn't need to solicit opinions in the first place. Kind of depressing though... I'm trying to contribute, but so far all my ideas have been shot down (but for good reasons, so I'm not bitter about it). Just have to keep trying I suppose. :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Thu, October 7, 2004 8:56 am, [EMAIL PROTECTED] said: Hi, Frank. I do not agree. While in most cases it is desireable to see inside a bean (hence I created my public static String toString(Object bean) method), there are times when I just have to make sure a bean is not just equal but the same instance. The java.lang.Object.toString() methods allows me to that quite quickly as the memory address is printed. Unless you have another way to provide that information, I'd rather stick with the default toString() plus some utility toString(Object) method. The impact for you is not too much. What you code so far is: log.debug(mybean=+mybean); and you'd have to change that to log.debug(mybean=+BeanUtil.toString(mybean)); which will allow you to either see the memory address or the contents, whatever you prefer. Hiran - Hiran Chaudhuri SAG Systemhaus GmbH Elsenheimer Stra?e 11 80867 M?nchen Phone +49-89-54 74 21 34 Fax +49-89-54 74 21 99 -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 7. Oktober 2004 13:43 To: Struts Developers List Subject: Re: Proposed Action base class change Hi Niall, I certainly agree it would not be possible to satisfy everyone, but seeing as the intrinsic toString() is all but useless (and people do generally expect that to be the case with many classes), why not give an implementation that is of at least some use to some people? Surely it would be better than what you get now? Obviously it's something many people will override, and that's of course the whole point of inheritance. But providing even a slightly more
Re: Conversion from CVS to Subversion Complete
Hi all. Is there a viewcvs.cgi equivalent for the SVN Repository? I realize I can open the url in a browser and view the latest revision, but I liked that you could see the history on the CVS version. In case its not clear what I am talking about: http://svn.apache.org/repos/asf/struts/trunk/ (in a browser) vs. http://cvs.apache.org/viewcvs/jakarta-struts/ thanks, Matt Don Brown wrote: It is my pleasure to announce the official migration of the Struts CVS repository into Apache Software Foundation's Subversion repository. The previous CVS module, jakarta-struts, has been frozen, and all new development will take place in the Subversion repository. The following links might be helpful: Struts public Subversion repository: http://svn.apache.org/repos/asf/struts Struts committers Subversion repository: https://svn.apache.org/repos/asf/struts Subversion: http://subversion.tigris.org Subversion Red Book: http://svnbook.red-bean.com/ Subversion for CVS Users section: http://svnbook.red-bean.com/svnbook-1.0/apa.html The repository is organized like this: struts/ /trunk - The current development branch (like CVS HEAD) /branches - All Struts branches /tags - All Struts tags If you want to checkout everything with the command-line client, type: svn co http://svn.apache.org/repos/asf/struts But most developers will only be interested in the trunk, so it would be better to type: svn co http://svn.apache.org/repos/asf/struts/trunk There are a number of Subversion client GUI's and IDE plugins linked to on the Subversion web site, for those perfer a GUI tool. Thanks again to the infrastructure team for their assistance! Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ViewSVN (was Re: Conversion from CVS to Subversion Complete)
Yes, there is a version of viewcvs, viewsvn, for subversion: http://svn.apache.org/viewcvs.cgi/struts/?root=Apache-SVN Don Matt Bathje wrote: Hi all. Is there a viewcvs.cgi equivalent for the SVN Repository? I realize I can open the url in a browser and view the latest revision, but I liked that you could see the history on the CVS version. In case its not clear what I am talking about: http://svn.apache.org/repos/asf/struts/trunk/ (in a browser) vs. http://cvs.apache.org/viewcvs/jakarta-struts/ thanks, Matt Don Brown wrote: It is my pleasure to announce the official migration of the Struts CVS repository into Apache Software Foundation's Subversion repository. The previous CVS module, jakarta-struts, has been frozen, and all new development will take place in the Subversion repository. The following links might be helpful: Struts public Subversion repository: http://svn.apache.org/repos/asf/struts Struts committers Subversion repository: https://svn.apache.org/repos/asf/struts Subversion: http://subversion.tigris.org Subversion Red Book: http://svnbook.red-bean.com/ Subversion for CVS Users section: http://svnbook.red-bean.com/svnbook-1.0/apa.html The repository is organized like this: struts/ /trunk - The current development branch (like CVS HEAD) /branches - All Struts branches /tags - All Struts tags If you want to checkout everything with the command-line client, type: svn co http://svn.apache.org/repos/asf/struts But most developers will only be interested in the trunk, so it would be better to type: svn co http://svn.apache.org/repos/asf/struts/trunk There are a number of Subversion client GUI's and IDE plugins linked to on the Subversion web site, for those perfer a GUI tool. Thanks again to the infrastructure team for their assistance! Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ViewSVN (was Re: Conversion from CVS to Subversion Complete)
Excellent, thanks very much. Matt Don Brown wrote: Yes, there is a version of viewcvs, viewsvn, for subversion: http://svn.apache.org/viewcvs.cgi/struts/?root=Apache-SVN Don Matt Bathje wrote: Hi all. Is there a viewcvs.cgi equivalent for the SVN Repository? I realize I can open the url in a browser and view the latest revision, but I liked that you could see the history on the CVS version. In case its not clear what I am talking about: http://svn.apache.org/repos/asf/struts/trunk/ (in a browser) vs. http://cvs.apache.org/viewcvs/jakarta-struts/ thanks, Matt Don Brown wrote: It is my pleasure to announce the official migration of the Struts CVS repository into Apache Software Foundation's Subversion repository. The previous CVS module, jakarta-struts, has been frozen, and all new development will take place in the Subversion repository. The following links might be helpful: Struts public Subversion repository: http://svn.apache.org/repos/asf/struts Struts committers Subversion repository: https://svn.apache.org/repos/asf/struts Subversion: http://subversion.tigris.org Subversion Red Book: http://svnbook.red-bean.com/ Subversion for CVS Users section: http://svnbook.red-bean.com/svnbook-1.0/apa.html The repository is organized like this: struts/ /trunk - The current development branch (like CVS HEAD) /branches - All Struts branches /tags - All Struts tags If you want to checkout everything with the command-line client, type: svn co http://svn.apache.org/repos/asf/struts But most developers will only be interested in the trunk, so it would be better to type: svn co http://svn.apache.org/repos/asf/struts/trunk There are a number of Subversion client GUI's and IDE plugins linked to on the Subversion web site, for those perfer a GUI tool. Thanks again to the infrastructure team for their assistance! Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed Action base class change
I'd just like to point out that the only valid way to tell if two
objects are the same instance if to use ==. Any other approach will not
work.
Comparing the toString() method results as you do is only really
comparing the hashcodes... which are not unique by a long shot (I never
assume people know this). Besides, == is even faster. What cases do
you find that you've had to use .toString().equals(...) where you
couldn't just do an == check?
-Paul
[EMAIL PROTECTED] wrote:
Hi, Frank.
I do not agree. While in most cases it is desireable to see inside a bean (hence I created my
public static String toString(Object bean)
method), there are times when I just have to make sure a bean is not just equal but the same instance.
The java.lang.Object.toString() methods allows me to that quite quickly as the memory address is printed.
Unless you have another way to provide that information, I'd rather stick with the
default toString() plus some utility toString(Object) method. The impact for you is
not too much. What you code so far is:
log.debug(mybean=+mybean);
and you'd have to change that to
log.debug(mybean=+BeanUtil.toString(mybean));
which will allow you to either see the memory address or the contents, whatever you
prefer.
Hiran
-
Hiran Chaudhuri
SAG Systemhaus GmbH
Elsenheimer Straße 11
80867 München
Phone +49-89-54 74 21 34
Fax +49-89-54 74 21 99
-Original Message-
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 7. Oktober 2004 13:43
To: Struts Developers List
Subject: Re: Proposed Action base class change
Hi Niall,
I certainly agree it would not be possible to satisfy
everyone, but seeing as the intrinsic toString() is all but
useless (and people do generally expect that to be the case
with many classes), why not give an implementation that is of
at least some use to some people? Surely it would be better
than what you get now? Obviously it's something many people
will override, and that's of course the whole point of
inheritance. But providing even a slightly more useful
default implementation (and maybe telling people it's a basic
default implementation so as to try and keep the flood of
bugzilla requests to a
minimum) seems to me like a good idea.
I can't address your point about dynabeans because I haven't
used them enough to be able to intelligently comment (which
is to say I haven't used them at all! :) )... I wouodn't
imagine some basic implementation would be too tough for them as well.
In any case, I will look at the toString builders you
mentioned... I've come to really like using the commons
packages and I try to whenever I can. This would be a good
case I think, if it doesn't get added as I proposed. I
already have an ActionHelpers class with a bunch of
similarly-themed static methods for use from Actions, so
maybe it's time to do so for forms as well.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Niall Pemberton wrote:
Frank,
For me it wouldn't be any use unless it also handled
DynaBeans. Even
then I'd end up overriding it because I have some formatting utils
which do dates, arrays and collections. Seems to me if we put it in
then we would end up with a monster trying to satisy
everyones needs
and forever dealing with bugzilla requests for enhacements (someone
would want an i18n version!) - all just for debugging.
The easiest thing is to just put all that code into a
utility method -
that way its only a one liner in the toString() - even
better if you
have your own base ActionForm that all you others derive
from, then
its only in one place.
Also, there are a set of toString builders in commons
lang which you
might like to use - including a reflection one like yours:
http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/bui
lder/package-summary.html
http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/bui
lder/ReflectionToStringBuilder.html
Niall
- Original Message -
From: Frank W. Zammetti [EMAIL PROTECTED]
To: Struts Developer [EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 4:29 AM
Subject: Re: Proposed Action base class change
Obviously I made a typo in the subject... this applies to the
ActionForm base class.
Did anyone have any comment on this? I've noticed a lack
of activity
on the list lately...
Hello all...
I find myself all the time overloading toString() of my
ActionForms
for
debugging
purposes, so I can easily dump the current state of the object. I
had
been doing
this for each ActionForm class, specifically for it, but
it ocurrs to
me
that a
general-purpose reflection-based approach would be better.
I'd like to propose adding this functionality to the
ActionForm base
class. Here's
the code I propose adding:
import java.lang.reflect.Field;
public static final AVERAGE_FIELD_SIZE = 25; public String
toString()
{
Re: Proposed Action base class change
Bah! Realized after I hit send that you were talking about logging. Others have already pointed out how to do that one using the System call. So, nevermind. -Paul Paul Speed wrote: I'd just like to point out that the only valid way to tell if two objects are the same instance if to use ==. Any other approach will not work. Comparing the toString() method results as you do is only really comparing the hashcodes... which are not unique by a long shot (I never assume people know this). Besides, == is even faster. What cases do you find that you've had to use .toString().equals(...) where you couldn't just do an == check? -Paul [EMAIL PROTECTED] wrote: Hi, Frank. I do not agree. While in most cases it is desireable to see inside a bean (hence I created my public static String toString(Object bean) method), there are times when I just have to make sure a bean is not just equal but the same instance. The java.lang.Object.toString() methods allows me to that quite quickly as the memory address is printed. Unless you have another way to provide that information, I'd rather stick with the default toString() plus some utility toString(Object) method. The impact for you is not too much. What you code so far is: log.debug(mybean=+mybean); and you'd have to change that to log.debug(mybean=+BeanUtil.toString(mybean)); which will allow you to either see the memory address or the contents, whatever you prefer. Hiran - Hiran Chaudhuri SAG Systemhaus GmbH Elsenheimer Straße 11 80867 München Phone +49-89-54 74 21 34 Fax +49-89-54 74 21 99 -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 7. Oktober 2004 13:43 To: Struts Developers List Subject: Re: Proposed Action base class change Hi Niall, I certainly agree it would not be possible to satisfy everyone, but seeing as the intrinsic toString() is all but useless (and people do generally expect that to be the case with many classes), why not give an implementation that is of at least some use to some people? Surely it would be better than what you get now? Obviously it's something many people will override, and that's of course the whole point of inheritance. But providing even a slightly more useful default implementation (and maybe telling people it's a basic default implementation so as to try and keep the flood of bugzilla requests to a minimum) seems to me like a good idea. I can't address your point about dynabeans because I haven't used them enough to be able to intelligently comment (which is to say I haven't used them at all! :) )... I wouodn't imagine some basic implementation would be too tough for them as well. In any case, I will look at the toString builders you mentioned... I've come to really like using the commons packages and I try to whenever I can. This would be a good case I think, if it doesn't get added as I proposed. I already have an ActionHelpers class with a bunch of similarly-themed static methods for use from Actions, so maybe it's time to do so for forms as well. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Niall Pemberton wrote: Frank, For me it wouldn't be any use unless it also handled DynaBeans. Even then I'd end up overriding it because I have some formatting utils which do dates, arrays and collections. Seems to me if we put it in then we would end up with a monster trying to satisy everyones needs and forever dealing with bugzilla requests for enhacements (someone would want an i18n version!) - all just for debugging. The easiest thing is to just put all that code into a utility method - that way its only a one liner in the toString() - even better if you have your own base ActionForm that all you others derive from, then its only in one place. Also, there are a set of toString builders in commons lang which you might like to use - including a reflection one like yours: http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/bui lder/package-summary.html http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/bui lder/ReflectionToStringBuilder.html Niall - Original Message - From: Frank W. Zammetti [EMAIL PROTECTED] To: Struts Developer [EMAIL PROTECTED] Sent: Thursday, October 07, 2004 4:29 AM Subject: Re: Proposed Action base class change Obviously I made a typo in the subject... this applies to the ActionForm base class. Did anyone have any comment on this? I've noticed a lack of activity on the list lately... Hello all... I find myself all the time overloading toString() of my ActionForms for debugging purposes, so I can easily dump the current state of the object. I had been doing this for each ActionForm class, specifically for it, but it ocurrs to me that a general-purpose reflection-based approach would be better. I'd like to propose adding this functionality
RE: Proposed Action base class change
Bah2 ;-) Saw this message after I had already responded to the previous one Hiran - Hiran Chaudhuri SAG Systemhaus GmbH Elsenheimer Straße 11 80867 München Phone +49-89-54 74 21 34 Fax +49-89-54 74 21 99 -Original Message- From: Paul Speed [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 7. Oktober 2004 17:41 To: Struts Developers List Subject: Re: Proposed Action base class change Bah! Realized after I hit send that you were talking about logging. Others have already pointed out how to do that one using the System call. So, nevermind. -Paul Paul Speed wrote: I'd just like to point out that the only valid way to tell if two objects are the same instance if to use ==. Any other approach will not work. Comparing the toString() method results as you do is only really comparing the hashcodes... which are not unique by a long shot (I never assume people know this). Besides, == is even faster. What cases do you find that you've had to use .toString().equals(...) where you couldn't just do an == check? -Paul [EMAIL PROTECTED] wrote: Hi, Frank. I do not agree. While in most cases it is desireable to see inside a bean (hence I created my public static String toString(Object bean) method), there are times when I just have to make sure a bean is not just equal but the same instance. The java.lang.Object.toString() methods allows me to that quite quickly as the memory address is printed. Unless you have another way to provide that information, I'd rather stick with the default toString() plus some utility toString(Object) method. The impact for you is not too much. What you code so far is: log.debug(mybean=+mybean); and you'd have to change that to log.debug(mybean=+BeanUtil.toString(mybean)); which will allow you to either see the memory address or the contents, whatever you prefer. Hiran - Hiran Chaudhuri SAG Systemhaus GmbH Elsenheimer Straße 11 80867 München Phone +49-89-54 74 21 34 Fax +49-89-54 74 21 99 -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 7. Oktober 2004 13:43 To: Struts Developers List Subject: Re: Proposed Action base class change Hi Niall, I certainly agree it would not be possible to satisfy everyone, but seeing as the intrinsic toString() is all but useless (and people do generally expect that to be the case with many classes), why not give an implementation that is of at least some use to some people? Surely it would be better than what you get now? Obviously it's something many people will override, and that's of course the whole point of inheritance. But providing even a slightly more useful default implementation (and maybe telling people it's a basic default implementation so as to try and keep the flood of bugzilla requests to a minimum) seems to me like a good idea. I can't address your point about dynabeans because I haven't used them enough to be able to intelligently comment (which is to say I haven't used them at all! :) )... I wouodn't imagine some basic implementation would be too tough for them as well. In any case, I will look at the toString builders you mentioned... I've come to really like using the commons packages and I try to whenever I can. This would be a good case I think, if it doesn't get added as I proposed. I already have an ActionHelpers class with a bunch of similarly-themed static methods for use from Actions, so maybe it's time to do so for forms as well. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Niall Pemberton wrote: Frank, For me it wouldn't be any use unless it also handled DynaBeans. Even then I'd end up overriding it because I have some formatting utils which do dates, arrays and collections. Seems to me if we put it in then we would end up with a monster trying to satisy everyones needs and forever dealing with bugzilla requests for enhacements (someone would want an i18n version!) - all just for debugging. The easiest thing is to just put all that code into a utility method - that way its only a one liner in the toString() - even better if you have your own base ActionForm that all you others derive from, then its only in one place. Also, there are a set of toString builders in commons lang which you might like to use - including a reflection one like yours: http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/b ui lder/package-summary.html http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/b ui lder/ReflectionToStringBuilder.html
Re: Proposed Action base class change
It was bound to happen... sometimes it would be nice to have an unsend button. :) Just need to work out that whole time/space continuum thing. -Paul [EMAIL PROTECTED] wrote: Bah2 ;-) Saw this message after I had already responded to the previous one Hiran - Hiran Chaudhuri SAG Systemhaus GmbH Elsenheimer Straße 11 80867 München Phone +49-89-54 74 21 34 Fax +49-89-54 74 21 99 -Original Message- From: Paul Speed [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 7. Oktober 2004 17:41 To: Struts Developers List Subject: Re: Proposed Action base class change Bah! Realized after I hit send that you were talking about logging. Others have already pointed out how to do that one using the System call. So, nevermind. -Paul Paul Speed wrote: I'd just like to point out that the only valid way to tell if two objects are the same instance if to use ==. Any other approach will not work. Comparing the toString() method results as you do is only really comparing the hashcodes... which are not unique by a long shot (I never assume people know this). Besides, == is even faster. What cases do you find that you've had to use .toString().equals(...) where you couldn't just do an == check? -Paul [EMAIL PROTECTED] wrote: Hi, Frank. I do not agree. While in most cases it is desireable to see inside a bean (hence I created my public static String toString(Object bean) method), there are times when I just have to make sure a bean is not just equal but the same instance. The java.lang.Object.toString() methods allows me to that quite quickly as the memory address is printed. Unless you have another way to provide that information, I'd rather stick with the default toString() plus some utility toString(Object) method. The impact for you is not too much. What you code so far is: log.debug(mybean=+mybean); and you'd have to change that to log.debug(mybean=+BeanUtil.toString(mybean)); which will allow you to either see the memory address or the contents, whatever you prefer. Hiran - Hiran Chaudhuri SAG Systemhaus GmbH Elsenheimer Straße 11 80867 München Phone +49-89-54 74 21 34 Fax +49-89-54 74 21 99 -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 7. Oktober 2004 13:43 To: Struts Developers List Subject: Re: Proposed Action base class change Hi Niall, I certainly agree it would not be possible to satisfy everyone, but seeing as the intrinsic toString() is all but useless (and people do generally expect that to be the case with many classes), why not give an implementation that is of at least some use to some people? Surely it would be better than what you get now? Obviously it's something many people will override, and that's of course the whole point of inheritance. But providing even a slightly more useful default implementation (and maybe telling people it's a basic default implementation so as to try and keep the flood of bugzilla requests to a minimum) seems to me like a good idea. I can't address your point about dynabeans because I haven't used them enough to be able to intelligently comment (which is to say I haven't used them at all! :) )... I wouodn't imagine some basic implementation would be too tough for them as well. In any case, I will look at the toString builders you mentioned... I've come to really like using the commons packages and I try to whenever I can. This would be a good case I think, if it doesn't get added as I proposed. I already have an ActionHelpers class with a bunch of similarly-themed static methods for use from Actions, so maybe it's time to do so for forms as well. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Niall Pemberton wrote: Frank, For me it wouldn't be any use unless it also handled DynaBeans. Even then I'd end up overriding it because I have some formatting utils which do dates, arrays and collections. Seems to me if we put it in then we would end up with a monster trying to satisy everyones needs and forever dealing with bugzilla requests for enhacements (someone would want an i18n version!) - all just for debugging. The easiest thing is to just put all that code into a utility method - that way its only a one liner in the toString() - even better if you have your own base ActionForm that all you others derive from, then its only in one place. Also, there are a set of toString builders in commons lang which you might like to use - including a reflection one like yours: http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/b ui lder/package-summary.html http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/b ui lder/ReflectionToStringBuilder.html Niall - Original Message - From: Frank W. Zammetti [EMAIL PROTECTED] To: Struts Developer [EMAIL
Re: Proposed Action base class change
There are several companies that would agree ;-) On Thu, 2004-10-07 at 13:29, Paul Speed wrote: It was bound to happen... sometimes it would be nice to have an unsend button. :) Just need to work out that whole time/space continuum thing. -Paul [EMAIL PROTECTED] wrote: Bah2 ;-) Saw this message after I had already responded to the previous one Hiran - Hiran Chaudhuri SAG Systemhaus GmbH Elsenheimer Straße 11 80867 München Phone +49-89-54 74 21 34 Fax +49-89-54 74 21 99 -Original Message- From: Paul Speed [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 7. Oktober 2004 17:41 To: Struts Developers List Subject: Re: Proposed Action base class change Bah! Realized after I hit send that you were talking about logging. Others have already pointed out how to do that one using the System call. So, nevermind. -Paul Paul Speed wrote: I'd just like to point out that the only valid way to tell if two objects are the same instance if to use ==. Any other approach will not work. Comparing the toString() method results as you do is only really comparing the hashcodes... which are not unique by a long shot (I never assume people know this). Besides, == is even faster. What cases do you find that you've had to use .toString().equals(...) where you couldn't just do an == check? -Paul [EMAIL PROTECTED] wrote: Hi, Frank. I do not agree. While in most cases it is desireable to see inside a bean (hence I created my public static String toString(Object bean) method), there are times when I just have to make sure a bean is not just equal but the same instance. The java.lang.Object.toString() methods allows me to that quite quickly as the memory address is printed. Unless you have another way to provide that information, I'd rather stick with the default toString() plus some utility toString(Object) method. The impact for you is not too much. What you code so far is: log.debug(mybean=+mybean); and you'd have to change that to log.debug(mybean=+BeanUtil.toString(mybean)); which will allow you to either see the memory address or the contents, whatever you prefer. Hiran - Hiran Chaudhuri SAG Systemhaus GmbH Elsenheimer Straße 11 80867 München Phone +49-89-54 74 21 34 Fax +49-89-54 74 21 99 -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 7. Oktober 2004 13:43 To: Struts Developers List Subject: Re: Proposed Action base class change Hi Niall, I certainly agree it would not be possible to satisfy everyone, but seeing as the intrinsic toString() is all but useless (and people do generally expect that to be the case with many classes), why not give an implementation that is of at least some use to some people? Surely it would be better than what you get now? Obviously it's something many people will override, and that's of course the whole point of inheritance. But providing even a slightly more useful default implementation (and maybe telling people it's a basic default implementation so as to try and keep the flood of bugzilla requests to a minimum) seems to me like a good idea. I can't address your point about dynabeans because I haven't used them enough to be able to intelligently comment (which is to say I haven't used them at all! :) )... I wouodn't imagine some basic implementation would be too tough for them as well. In any case, I will look at the toString builders you mentioned... I've come to really like using the commons packages and I try to whenever I can. This would be a good case I think, if it doesn't get added as I proposed. I already have an ActionHelpers class with a bunch of similarly-themed static methods for use from Actions, so maybe it's time to do so for forms as well. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Niall Pemberton wrote: Frank, For me it wouldn't be any use unless it also handled DynaBeans. Even then I'd end up overriding it because I have some formatting utils which do dates, arrays and collections. Seems to me if we put it in then we would end up with a monster trying to satisy everyones needs and forever dealing with bugzilla requests for enhacements (someone would want an i18n version!) - all just for debugging. The easiest thing is to just put all that code into a utility method - that way its only a one liner in the toString() - even better if you have your own base ActionForm that all you others derive from, then its only in one place. Also, there are a set of toString builders
DO NOT REPLY [Bug 31585] New: - Minor Memory Leak in Iterator Tag
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31585. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31585 Minor Memory Leak in Iterator Tag Summary: Minor Memory Leak in Iterator Tag Product: Struts Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If you supply a collection object instead of a name to the iterator tag, the iterator tag instance will reference the collection until the tag instance will be released. During load tests we noticed that the current tomcat versions (e.g. 5.0.28) pool the tags as expected, but keep our collection objects in memory longer than expected. I think it would be good to reset the protected member collection in the iterator tag in doEndTag() and thus prevent these memory leaks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31585] - Minor Memory Leak in Iterator Tag
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31585. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31585 Minor Memory Leak in Iterator Tag --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 18:26 --- As a current workaround: Don't supply collections as parameter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bundles and JSTL
Could we add code to either the request processor or the action servlet to add the default message resource defined in a struts.config to a scope (app/session/request) under the key javax.servlet.jsp.jstl.fmt.localizationContext, so the default bundle works with fmt:message without having to do a fmt:setBundle. I would think it make sense to do this on a request basis to support different modules. If this is already the case already, then I must be doing something else wrong. If it is being set like this the case... please let me know, ignore this request, and let me be the first to say nice!! Thanks - Mike
svn commit: rev 54006 - struts/trunk/src/share/org/apache/struts/taglib/logic
Author: niallp
Date: Thu Oct 7 11:42:52 2004
New Revision: 54006
Modified:
struts/trunk/src/share/org/apache/struts/taglib/logic/IterateTag.java
Log:
Bug 31585 Minor Memory Leak in Iterator Tag reported by Jens Schumann
Modified: struts/trunk/src/share/org/apache/struts/taglib/logic/IterateTag.java
==
--- struts/trunk/src/share/org/apache/struts/taglib/logic/IterateTag.java
(original)
+++ struts/trunk/src/share/org/apache/struts/taglib/logic/IterateTag.java Thu
Oct 7 11:42:52 2004
@@ -1,7 +1,7 @@
/*
* $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/logic/IterateTag.java,v
1.27 2004/03/14 06:23:44 sraeburn Exp $
* $Revision: 1.27 $
- * $Date: 2004/03/14 06:23:44 $
+ * $Date$
*
* Copyright 1999-2004 The Apache Software Foundation.
*
@@ -42,7 +42,7 @@
* an Iterator, a Collection (which includes Lists, Sets and Vectors),
* or a Map (which includes Hashtables) whose elements will be iterated over.
*
- * @version $Revision: 1.27 $ $Date: 2004/03/14 06:23:44 $
+ * @version $Revision: 1.27 $ $Date$
*/
public class IterateTag extends BodyTagSupport {
@@ -382,6 +382,7 @@
// Clean up our started state
started = false;
iterator = null;
+collection = null;
// Continue processing this page
return (EVAL_PAGE);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31585] - Minor Memory Leak in Iterator Tag
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31585. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31585 Minor Memory Leak in Iterator Tag --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 18:49 --- Thanks for reporting this, I have patched IteratorTag is you suggested. Normally this would be available in the next nightly build, but we have just switched the source repository from CVS to SVN and I believe the nightly builds are still using the old CVS repository. Once the CVS/SVN issue is resolved, I'll let you know - it would be good if you could confirm that the issue is resolved. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31514] - Either insufficient docs on validwhen or a bug
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31514. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31514 Either insufficient docs on validwhen or a bug --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 18:51 --- Yegor, Unfortuantely the fix I implemeted has not yet been picked up in the nightly builds. We have just switched the source repository from CVS to SVN and I believe the nightly builds are still using the old CVS repository. I'll let you know when this is resolved. Sorry about that. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31585] - Minor Memory Leak in Iterator Tag
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31585. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31585 Minor Memory Leak in Iterator Tag --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 19:01 --- Won't that patch potentially cause tag pooling to fail? collection is a tag attribute, it's not a calculated value like started and iterator. collection is set to null in the release method. A different approach may be to use a reference object to wrap the collection. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed Action base class change
I agree with the == comment, but even if you wanted to go hashCode, you could use System.identityHashCode( obj ); Quoting Paul Speed [EMAIL PROTECTED]: I'd just like to point out that the only valid way to tell if two objects are the same instance if to use ==. Any other approach will not work. Comparing the toString() method results as you do is only really comparing the hashcodes... which are not unique by a long shot (I never assume people know this). Besides, == is even faster. What cases do you find that you've had to use .toString().equals(...) where you couldn't just do an == check? -Paul [EMAIL PROTECTED] wrote: Hi, Frank. I do not agree. While in most cases it is desireable to see inside a bean (hence I created my public static String toString(Object bean) method), there are times when I just have to make sure a bean is not just equal but the same instance. The java.lang.Object.toString() methods allows me to that quite quickly as the memory address is printed. Unless you have another way to provide that information, I'd rather stick with the default toString() plus some utility toString(Object) method. The impact for you is not too much. What you code so far is: log.debug(mybean=+mybean); and you'd have to change that to log.debug(mybean=+BeanUtil.toString(mybean)); which will allow you to either see the memory address or the contents, whatever you prefer. Hiran - Hiran Chaudhuri SAG Systemhaus GmbH Elsenheimer Straße 11 80867 München Phone +49-89-54 74 21 34 Fax +49-89-54 74 21 99 -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 7. Oktober 2004 13:43 To: Struts Developers List Subject: Re: Proposed Action base class change Hi Niall, I certainly agree it would not be possible to satisfy everyone, but seeing as the intrinsic toString() is all but useless (and people do generally expect that to be the case with many classes), why not give an implementation that is of at least some use to some people? Surely it would be better than what you get now? Obviously it's something many people will override, and that's of course the whole point of inheritance. But providing even a slightly more useful default implementation (and maybe telling people it's a basic default implementation so as to try and keep the flood of bugzilla requests to a minimum) seems to me like a good idea. I can't address your point about dynabeans because I haven't used them enough to be able to intelligently comment (which is to say I haven't used them at all! :) )... I wouodn't imagine some basic implementation would be too tough for them as well. In any case, I will look at the toString builders you mentioned... I've come to really like using the commons packages and I try to whenever I can. This would be a good case I think, if it doesn't get added as I proposed. I already have an ActionHelpers class with a bunch of similarly-themed static methods for use from Actions, so maybe it's time to do so for forms as well. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Niall Pemberton wrote: Frank, For me it wouldn't be any use unless it also handled DynaBeans. Even then I'd end up overriding it because I have some formatting utils which do dates, arrays and collections. Seems to me if we put it in then we would end up with a monster trying to satisy everyones needs and forever dealing with bugzilla requests for enhacements (someone would want an i18n version!) - all just for debugging. The easiest thing is to just put all that code into a utility method - that way its only a one liner in the toString() - even better if you have your own base ActionForm that all you others derive from, then its only in one place. Also, there are a set of toString builders in commons lang which you might like to use - including a reflection one like yours: http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/bui lder/package-summary.html http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/bui lder/ReflectionToStringBuilder.html Niall - Original Message - From: Frank W. Zammetti [EMAIL PROTECTED] To: Struts Developer [EMAIL PROTECTED] Sent: Thursday, October 07, 2004 4:29 AM Subject: Re: Proposed Action base class change Obviously I made a typo in the subject... this applies to the ActionForm base class. Did anyone have any comment on this? I've noticed a lack of activity on the list lately... Hello all... I find myself all the time overloading toString() of my ActionForms for debugging purposes, so I can easily dump the current state of the object. I
svn commit: rev 54010 - struts/trunk/src/share/org/apache/struts/taglib/logic
Author: niallp Date: Thu Oct 7 12:43:39 2004 New Revision: 54010 Modified: struts/trunk/src/share/org/apache/struts/taglib/logic/IterateTag.java Log: Remove change made in Revision 54006 for Bug 31585 As pointed out by Kris Schneider this could cause Tag Pooling problems Modified: struts/trunk/src/share/org/apache/struts/taglib/logic/IterateTag.java == --- struts/trunk/src/share/org/apache/struts/taglib/logic/IterateTag.java (original) +++ struts/trunk/src/share/org/apache/struts/taglib/logic/IterateTag.java Thu Oct 7 12:43:39 2004 @@ -382,7 +382,6 @@ // Clean up our started state started = false; iterator = null; -collection = null; // Continue processing this page return (EVAL_PAGE); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31585] - Minor Memory Leak in Iterator Tag
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31585. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31585 Minor Memory Leak in Iterator Tag --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 19:47 --- OK thanks Kris for pointing this out. I've removed the change - looks like the workaround is the best option. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bundles and JSTL
After further investigation, I don't see this is being done (at least in
the 1.1 release - I have not investigated further)
This is a straight forward fix. All I did to resolve this was extend
the processLocale method in my request processor as follows:
---
protected void processLocale(HttpServletRequest request,
HttpServletResponse response)
{
super.processLocale(request, response);
// Message Resources
MessageResources msgResources = (MessageResources)
request.getAttribute(Globals.MESSAGES_KEY);
if ((msgResources != null)
(msgResources.getConfig() != null))
{
Config.set(request, Config.FMT_LOCALIZATION_CONTEXT,
msgResources.getConfig());
}
}
---
Note: that I use the core javax.servlet.jsp.jstl.core.Config class.
However, this adds a dependency on the jstl jar itself. For my project
this was acceptable, but for Struts this probably isn't acceptable (yet
at least). Instead you could easily just set the
msgResources.getConfig() value as a request attribute under the key:
javax.servlet.jsp.jstl.fmt.localizationContext.request
That is basically what that set does.
This should be standard behavior of the default request processor. (If
not already.)
- Mike
On Thu, 2004-10-07 at 14:28, Mike Stanley wrote:
Could we add code to either the request processor or the action servlet
to add the default message resource defined in a struts.config to a
scope (app/session/request) under the key
javax.servlet.jsp.jstl.fmt.localizationContext, so the default bundle
works with fmt:message without having to do a fmt:setBundle. I would
think it make sense to do this on a request basis to support different
modules.
If this is already the case already, then I must be doing something else
wrong. If it is being set like this the case... please let me know,
ignore this request, and let me be the first to say nice!!
Thanks
- Mike
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31585] - Minor Memory Leak in Iterator Tag
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31585.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31585
Minor Memory Leak in Iterator Tag
--- Additional Comments From [EMAIL PROTECTED] 2004-10-07 19:59 ---
OTTOMH, something like this:
protected Reference collectionRef = null;
protected Object collection = null;
private Object getCollectionFromRef() {
return ((this.collectionRef == null) ? null : this.collectionRef.get());
}
public Object getCollection() {
return getCollectionFromRef();
}
public void setCollection(Object collection) {
this.collection = null;
this.collectionRef = ((collection == null) ? null : new
WeakReference(collection));
}
public int doStartTag() throws JspException {
...
// create a strong reference during tag processing
this.collection = getCollectionFromRef();
...
}
public int doEndTag() throws JspException {
...
// remove strong reference
this.collection = null;
...
}
public void release() {
...
this.collectionRef = null;
...
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31230] - Multiple classes using deprecated DefinitionsUtil class
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31230. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31230 Multiple classes using deprecated DefinitionsUtil class --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 20:08 --- The proposed change to TilesRequestProcessor would cause backward compatibility issues if anyone is relying on the fact that storing a defintion in the Request under the ACTION_DEFINITION key causes it to be used. Personally I wasn't aware of this behaviour - but since its there should we continue to support it or not? If the answer is that we should support it then we probably need to move the get/set/removeActionDefinition methods to TilesUtils - and in that scenario then the simplest change to DefinitionDispatcherAction would be to just switch from using DefinitionsUtil to TilesUtil. If we don't care about continuing to support it, then Sean's changes look good. It would be good if someone who knows more about the thinking behind that bit of the code could comment. I also wasn't aware that Tiles still supported using init-params in the web.xml until I saw Sean's patch for TilesPlugin. Since most of the configuration that used to use init-params has been moved into the struts-config.xml (including Tiles through the PlugIn) then I think rather than change the code as Sean's proposing, we should just remove it. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31585] - Minor Memory Leak in Iterator Tag
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31585. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31585 Minor Memory Leak in Iterator Tag [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 20:32 --- OK I looked back through the old bugs and found this was fully discussed in Bug 17165, so I'm closing this as a duplicate. Best practice IMO is having the collection store as a request/page attribute and using the name=... attribute on the iterate tag. Niall P.S. Kris since setting the tag atributes and calling release() is up to container then, as discussed in Bug 17165, I don't see there is any solution that we could implement to resolve this. *** This bug has been marked as a duplicate of 17165 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17165] - logic:iterate tag not releasing collections from memory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=17165. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=17165 logic:iterate tag not releasing collections from memory [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 20:32 --- *** Bug 31585 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed Action base class change
Kind of depressing though... I'm trying to contribute, but so far all my ideas have been shot down (but for good reasons, so I'm not bitter about it). Just have to keep trying I suppose. :) But you (and the rest of us) can learn something from the ensuing discussion, even if your ideas are not adopted. So just by raising issues, you *are* contributing. Keep 'em coming :-) Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
