Of course, your newest solution is better, but it still does not feel right
regarding the MAX_INDEX allowed ;-)

-D
----- Original Message -----
From: "Nicolas De Loof" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Sunday, March 30, 2003 10:44 PM
Subject: Re: Too many session scoped form beans!


> If this hacking scenario makes you nervous, you can set an acceptable max
index value :
>
> private static final int MAX_INDEX = 100;
>
> public void setItem(int index, Object obj) {
>     if (index > MAX_INDEX) {
>         throw new IndexOutOfBoundsException();
>     }
>
>
> Nico.
>
> > Nicolas,
> >
> > Your great suggestion makes me nervous ... It is possible for a hacker
to
> > change the index so big that it can hog the CPU, which busy creating
empty
> > node, for each request.
> >
> > However, I cant come up with another solution
> >
> > Any comments? anyone?
> >
> > -D
> > ----- Original Message -----
> > From: "Nicolas De Loof" <[EMAIL PROTECTED]>
> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> > Sent: Friday, March 28, 2003 5:19 AM
> > Subject: Re: Too many session scoped form beans!
> >
> >
> > > Reading my own post I realize this code will throw an
> > IndexOutOfBoundsException
> > >
> > > You need to put 'empty' datas on the List as needed :
> > >
> > > protected List item;
> > >
> > > public void setItem(int index, Object obj) {
> > >     if (this.item == null) {
> > >         this.item = new ArrayList(index);
> > >     }
> > >     for (int i = this.item.size(); i < index; i++) {
> > >         this.item.add("");
> > >     }
> > >     this.item.add(index, obj);
> > > }
> > >
> > > Nico.
> > >
> > > > I think you can use something like this in a request scoped
form-bean :
> > > >
> > > >
> > > > protected List item;
> > > >
> > > > public void setItem(int index, Object obj) {
> > > >     if (this.item == null) {
> > > >         this.item = new ArrayList(index);
> > > >     } else {
> > > >         this.item.ensureCapacity(index);
> > > >     }
> > > >     this.item.add(index, obj);
> > > > }
> > > >
> > > > This way, when form-bean population occurs, you will get a new
> > Collection when needed.
> > > >
> > > > Nico.
> > > >
> > > >
> > > > > I'd like to know if it's possible to avoid using to many session
> > scoped
> > > > > form beans.
> > > > >
> > > > > I have a bean that contains a collection and I use nested:iterate
to
> > > > > display entry fields on my html:form. When the form is submitted,
I
> > get
> > > > > an error in BeanUtils.populate(), because the new bean (when the
bean
> > is
> > > > > request scoped) contains an empty collection and populate() tries
to
> > set
> > > > > the properties of the elements that existed on the bean of the
> > previous
> > > > > request.
> > > > >
> > > > > If I change the bean to session scope, everything works fine
(because
> > > > > now the bean is the same for both requests), but I think it's kind
of
> > > > > messy to have lots of session scoped beans.
> > > > >
> > > > > I'd appreciate to have any comments on this subject.
> > > > >
> > > > > Thanks
> > > > >
> > > > > Jorge Mascena
> > > > >
> > > > >
> > > >
> ---------------------------------------------------------------------
> > > > > 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]
>
> ---------------------------------------------------------------------
> 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]

Reply via email to