mockobjects-java-users

[MO-java-users] setting attributes in a mock request

[Bill L. <bi...@ji...>]

All,

I haven't been able to figure out how to set attributes in a 
MockHttpServletRequest. I searched the mailing list archives for clues, but 
didn't find any (and there's no javadocs for that class!).

The method that looks like it might work only takes one param:

request.setupGetAttribute(Object)

I'd expect that to be

request.setupGetAttribute(String, Object)

I've also tried passing in a vector of name/value pairs to that method, but when 
I call getAttribute(String) on that request object I get this error:

There was 1 failure:
1) testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedError: 
attributes has run out of objects.
	at com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:61)
	at 
com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServletRequest.java:58)


Thanks in advance,
--Bill

Re: [MO-java-users] setting attributes in a mock request

[Steve F. <st...@m3...>]

This implementation /is/ a little hazy.

The idea is that you should preload your attributes in the order in 
which they are requested, and then they'll just be returned as the code 
runs. It's not actually doing a lookup. Checking which attributes are 
asked for is actually a separate concept and handled by a different 
expectation. There are some arguments for doing this but it does look a 
little clumsy.

If you don't like this, I suggest you replace this part of the mock 
request with an ExpectationMap which might be closer to the behaviour 
you want.

S.

Bill Lynch wrote:
> All,
> 
> I haven't been able to figure out how to set attributes in a 
> MockHttpServletRequest. I searched the mailing list archives for clues, 
> but didn't find any (and there's no javadocs for that class!).
> 
> The method that looks like it might work only takes one param:
> 
> request.setupGetAttribute(Object)
> 
> I'd expect that to be
> 
> request.setupGetAttribute(String, Object)
> 
> I've also tried passing in a vector of name/value pairs to that method, 
> but when I call getAttribute(String) on that request object I get this 
> error:
> 
> There was 1 failure:
> 1) 
> testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedError: 
> attributes has run out of objects.
>     at 
> com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:61)
>     at 
> com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServletRequest.java:58) 

Re: [MO-java-users] setting attributes in a mock request

[Jeff M. <je...@cu...>]

Should probably be a ReturnObjectBag as this lets you setup a list of
return values for a key.


On Thu, 2003-07-17 at 08:47, Steve Freeman wrote:
> This implementation /is/ a little hazy.
> 
> The idea is that you should preload your attributes in the order in 
> which they are requested, and then they'll just be returned as the code 
> runs. It's not actually doing a lookup. Checking which attributes are 
> asked for is actually a separate concept and handled by a different 
> expectation. There are some arguments for doing this but it does look a 
> little clumsy.
> 
> If you don't like this, I suggest you replace this part of the mock 
> request with an ExpectationMap which might be closer to the behaviour 
> you want.
> 
> S.
> 
> Bill Lynch wrote:
> > All,
> > 
> > I haven't been able to figure out how to set attributes in a 
> > MockHttpServletRequest. I searched the mailing list archives for clues, 
> > but didn't find any (and there's no javadocs for that class!).
> > 
> > The method that looks like it might work only takes one param:
> > 
> > request.setupGetAttribute(Object)
> > 
> > I'd expect that to be
> > 
> > request.setupGetAttribute(String, Object)
> > 
> > I've also tried passing in a vector of name/value pairs to that method, 
> > but when I call getAttribute(String) on that request object I get this 
> > error:
> > 
> > There was 1 failure:
> > 1) 
> > testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedError: 
> > attributes has run out of objects.
> >     at 
> > com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:61)
> >     at 
> > com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServletRequest.java:58) 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
-- 
Jeff Martin

Memetic Engineer

http://www.custommonkey.org/

Re: [MO-java-users] setting attributes in a mock request

[Bill L. <bi...@ji...>]

Guys,

I took Steve's advice and created my own extention to 
MockHttpServletRequest - my first attempt is below:

private class MyMockHttpServletRequest extends MockHttpServletRequest {

     private Hashtable attributes;

     public JiveMockHttpServletRequest() {
         attributes = new Hashtable();
     }

     public Object getAttribute(String s) {
         return attributes.get(s);
     }

     public Enumeration getAttributeNames() {
         return attributes.elements();
     }

     public void setAttribute(String s, Object o) {
         attributes.put(s,o);
     }
}

After doing this and reading Jeff's mail I implemented it with a 
ReturnObjectBag - however, I don't see what that buys me:

private class MyMockHttpServletRequest extends MockHttpServletRequest {

     private ReturnObjectBag attributes;

     public MyMockHttpServletRequest() {
         attributes = new ReturnObjectBag("attributes");
     }

     public Object getAttribute(String s) {
         return attributes.getHashTable().get(s);
     }

     public Enumeration getAttributeNames() {
         return attributes.getHashTable().elements();
     }

     public void setAttribute(String s, Object o) {
         attributes.getHashTable().put(s,o);
     }
}

Is there a benefit to either approach? Both work perfectly in my test 
case and I'm more inclined to go with the first approach just because 
it's simpler (and the ReturnObjectBag does nothing for me in this case).

Cheers,
--Bill

Jeff Martin wrote:
> Should probably be a ReturnObjectBag as this lets you setup a list of
> return values for a key.
> 
> 
> On Thu, 2003-07-17 at 08:47, Steve Freeman wrote:
> 
>>This implementation /is/ a little hazy.
>>
>>The idea is that you should preload your attributes in the order in 
>>which they are requested, and then they'll just be returned as the code 
>>runs. It's not actually doing a lookup. Checking which attributes are 
>>asked for is actually a separate concept and handled by a different 
>>expectation. There are some arguments for doing this but it does look a 
>>little clumsy.
>>
>>If you don't like this, I suggest you replace this part of the mock 
>>request with an ExpectationMap which might be closer to the behaviour 
>>you want.
>>
>>S.
>>
>>Bill Lynch wrote:
>>
>>>All,
>>>
>>>I haven't been able to figure out how to set attributes in a 
>>>MockHttpServletRequest. I searched the mailing list archives for clues, 
>>>but didn't find any (and there's no javadocs for that class!).
>>>
>>>The method that looks like it might work only takes one param:
>>>
>>>request.setupGetAttribute(Object)
>>>
>>>I'd expect that to be
>>>
>>>request.setupGetAttribute(String, Object)
>>>
>>>I've also tried passing in a vector of name/value pairs to that method, 
>>>but when I call getAttribute(String) on that request object I get this 
>>>error:
>>>
>>>There was 1 failure:
>>>1) 
>>>testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedError: 
>>>attributes has run out of objects.
>>>    at 
>>>com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:61)
>>>    at 
>>>com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServletRequest.java:58) 

Re: [MO-java-users] setting attributes in a mock request

[Jeff M. <je...@cu...>]

That's amazing. I give up, i've had enough of the request, it's a really
bad API to start with. Might as well get rid of all the servlet mocks
and use the dynamic stuff.

On Thu, 2003-07-17 at 14:37, Bill Lynch wrote:
> Guys,
> 
> I took Steve's advice and created my own extention to 
> MockHttpServletRequest - my first attempt is below:
> 
> private class MyMockHttpServletRequest extends MockHttpServletRequest {
> 
>      private Hashtable attributes;
> 
>      public JiveMockHttpServletRequest() {
>          attributes = new Hashtable();
>      }
> 
>      public Object getAttribute(String s) {
>          return attributes.get(s);
>      }
> 
>      public Enumeration getAttributeNames() {
>          return attributes.elements();
>      }
> 
>      public void setAttribute(String s, Object o) {
>          attributes.put(s,o);
>      }
> }
> 
> After doing this and reading Jeff's mail I implemented it with a 
> ReturnObjectBag - however, I don't see what that buys me:
> 
> private class MyMockHttpServletRequest extends MockHttpServletRequest {
> 
>      private ReturnObjectBag attributes;
> 
>      public MyMockHttpServletRequest() {
>          attributes = new ReturnObjectBag("attributes");
>      }
> 
>      public Object getAttribute(String s) {
>          return attributes.getHashTable().get(s);
>      }
> 
>      public Enumeration getAttributeNames() {
>          return attributes.getHashTable().elements();
>      }
> 
>      public void setAttribute(String s, Object o) {
>          attributes.getHashTable().put(s,o);
>      }
> }
> 
> Is there a benefit to either approach? Both work perfectly in my test 
> case and I'm more inclined to go with the first approach just because 
> it's simpler (and the ReturnObjectBag does nothing for me in this case).
> 
> Cheers,
> --Bill
> 
> Jeff Martin wrote:
> > Should probably be a ReturnObjectBag as this lets you setup a list of
> > return values for a key.
> > 
> > 
> > On Thu, 2003-07-17 at 08:47, Steve Freeman wrote:
> > 
> >>This implementation /is/ a little hazy.
> >>
> >>The idea is that you should preload your attributes in the order in 
> >>which they are requested, and then they'll just be returned as the code 
> >>runs. It's not actually doing a lookup. Checking which attributes are 
> >>asked for is actually a separate concept and handled by a different 
> >>expectation. There are some arguments for doing this but it does look a 
> >>little clumsy.
> >>
> >>If you don't like this, I suggest you replace this part of the mock 
> >>request with an ExpectationMap which might be closer to the behaviour 
> >>you want.
> >>
> >>S.
> >>
> >>Bill Lynch wrote:
> >>
> >>>All,
> >>>
> >>>I haven't been able to figure out how to set attributes in a 
> >>>MockHttpServletRequest. I searched the mailing list archives for clues, 
> >>>but didn't find any (and there's no javadocs for that class!).
> >>>
> >>>The method that looks like it might work only takes one param:
> >>>
> >>>request.setupGetAttribute(Object)
> >>>
> >>>I'd expect that to be
> >>>
> >>>request.setupGetAttribute(String, Object)
> >>>
> >>>I've also tried passing in a vector of name/value pairs to that method, 
> >>>but when I call getAttribute(String) on that request object I get this 
> >>>error:
> >>>
> >>>There was 1 failure:
> >>>1) 
> >>>testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedError: 
> >>>attributes has run out of objects.
> >>>    at 
> >>>com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:61)
> >>>    at 
> >>>com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServletRequest.java:58) 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
-- 
Jeff Martin

Memetic Engineer

http://www.custommonkey.org/

Re: [MO-java-users] setting attributes in a mock request

[Bill L. <bi...@ji...>]

Nat et al,

Thanks for the advice - I can change that code (I'm new to the class). I 
have a few more questions:

1) Why should I keep using a ReturnObjectBag as an internal object? In 
my example, does it its use benefit me, or can I use it in a better way?

2) If I shouldn't mess with the internal Hashtable, why is it exposed? 
Seems like poor design then.

3) Any reason there's no Javadocs for any of these classes? :) Having 
better documentation would have steered me away from using the internal 
hashtable probably.

Cheers,
--Bill

Nat Pryce wrote:

> Try using the putObjectToReturn and getNextReturnObject methods rather than
> messing around with the ReturnObjectBag's internal hash table.
> 
> Cheers,
>             Nat.
 >
> ----- Original Message -----
> From: Bill Lynch
> To: <moc...@li...>
> Sent: Thursday, July 17, 2003 2:37 PM
> Subject: Re: [MO-java-users] setting attributes in a mock request
> 
>>Guys,
>>
>>I took Steve's advice and created my own extention to
>>MockHttpServletRequest - my first attempt is below:
>>
>>private class MyMockHttpServletRequest extends MockHttpServletRequest {
>>
>>     private Hashtable attributes;
>>
>>     public JiveMockHttpServletRequest() {
>>         attributes = new Hashtable();
>>     }
>>
>>     public Object getAttribute(String s) {
>>         return attributes.get(s);
>>     }
>>
>>     public Enumeration getAttributeNames() {
>>         return attributes.elements();
>>     }
>>
>>     public void setAttribute(String s, Object o) {
>>         attributes.put(s,o);
>>     }
>>}
>>
>>After doing this and reading Jeff's mail I implemented it with a
>>ReturnObjectBag - however, I don't see what that buys me:
>>
>>private class MyMockHttpServletRequest extends MockHttpServletRequest {
>>
>>     private ReturnObjectBag attributes;
>>
>>     public MyMockHttpServletRequest() {
>>         attributes = new ReturnObjectBag("attributes");
>>     }
>>
>>     public Object getAttribute(String s) {
>>         return attributes.getHashTable().get(s);
>>     }
>>
>>     public Enumeration getAttributeNames() {
>>         return attributes.getHashTable().elements();
>>     }
>>
>>     public void setAttribute(String s, Object o) {
>>         attributes.getHashTable().put(s,o);
>>     }
>>}
>>
>>Is there a benefit to either approach? Both work perfectly in my test
>>case and I'm more inclined to go with the first approach just because
>>it's simpler (and the ReturnObjectBag does nothing for me in this case).
>>
>>Cheers,
>>--Bill
>>
>>Jeff Martin wrote:
>>
>>>Should probably be a ReturnObjectBag as this lets you setup a list of
>>>return values for a key.
>>>
>>>
>>>On Thu, 2003-07-17 at 08:47, Steve Freeman wrote:
>>>
>>>
>>>>This implementation /is/ a little hazy.
>>>>
>>>>The idea is that you should preload your attributes in the order in
>>>>which they are requested, and then they'll just be returned as the code
>>>>runs. It's not actually doing a lookup. Checking which attributes are
>>>>asked for is actually a separate concept and handled by a different
>>>>expectation. There are some arguments for doing this but it does look a
>>>>little clumsy.
>>>>
>>>>If you don't like this, I suggest you replace this part of the mock
>>>>request with an ExpectationMap which might be closer to the behaviour
>>>>you want.
>>>>
>>>>S.
>>>>
>>>>Bill Lynch wrote:
>>>>
>>>>
>>>>>All,
>>>>>
>>>>>I haven't been able to figure out how to set attributes in a
>>>>>MockHttpServletRequest. I searched the mailing list archives for clues,
>>>>>but didn't find any (and there's no javadocs for that class!).
>>>>>
>>>>>The method that looks like it might work only takes one param:
>>>>>
>>>>>request.setupGetAttribute(Object)
>>>>>
>>>>>I'd expect that to be
>>>>>
>>>>>request.setupGetAttribute(String, Object)
>>>>>
>>>>>I've also tried passing in a vector of name/value pairs to that method,
>>>>>but when I call getAttribute(String) on that request object I get this
>>>>>error:
>>>>>
>>>>>There was 1 failure:
>>>>>1)
>>
>>>>testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedError
> 
> :
> 
>>>>>attributes has run out of objects.
>>>>>   at
>>
>>>>com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:6
> 
> 1)
> 
>>>>>   at
>>
>>>>com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServl
> 
> etRequest.java:58)
> 

Re: [MO-java-users] setting attributes in a mock request

[Jeff M. <je...@cu...>]

On Thu, 2003-07-17 at 16:06, Bill Lynch wrote:
> Nat et al,
> 
> Thanks for the advice - I can change that code (I'm new to the class). I 
> have a few more questions:
> 
> 1) Why should I keep using a ReturnObjectBag as an internal object? In 
> my example, does it its use benefit me, or can I use it in a better way?
Simplest (not best) example is this. How can you tell if your code is
doing this.

for(int i=0;i<100000;i++){
  att = request.getAttribute("name");
}

or this

att = request.getAttribute("name");

> 
> 2) If I shouldn't mess with the internal Hashtable, why is it exposed? 
> Seems like poor design then.

Not bad design, just unusual environmental pressures, it's probably
vestigial by now.

>
> 3) Any reason there's no Javadocs for any of these classes? :) Having 
> better documentation would have steered me away from using the internal 
> hashtable probably.
> 

cough,
http://mockobjects.sourceforge.net/javadoc/1.4/com/mockobjects/ReturnObjectBag.html

> 
> Cheers,
> --Bill
> 
> Nat Pryce wrote:
> 
> > Try using the putObjectToReturn and getNextReturnObject methods rather than
> > messing around with the ReturnObjectBag's internal hash table.
> > 
> > Cheers,
> >             Nat.
>  >
> > ----- Original Message -----
> > From: Bill Lynch
> > To: <moc...@li...>
> > Sent: Thursday, July 17, 2003 2:37 PM
> > Subject: Re: [MO-java-users] setting attributes in a mock request
> > 
> >>Guys,
> >>
> >>I took Steve's advice and created my own extention to
> >>MockHttpServletRequest - my first attempt is below:
> >>
> >>private class MyMockHttpServletRequest extends MockHttpServletRequest {
> >>
> >>     private Hashtable attributes;
> >>
> >>     public JiveMockHttpServletRequest() {
> >>         attributes = new Hashtable();
> >>     }
> >>
> >>     public Object getAttribute(String s) {
> >>         return attributes.get(s);
> >>     }
> >>
> >>     public Enumeration getAttributeNames() {
> >>         return attributes.elements();
> >>     }
> >>
> >>     public void setAttribute(String s, Object o) {
> >>         attributes.put(s,o);
> >>     }
> >>}
> >>
> >>After doing this and reading Jeff's mail I implemented it with a
> >>ReturnObjectBag - however, I don't see what that buys me:
> >>
> >>private class MyMockHttpServletRequest extends MockHttpServletRequest {
> >>
> >>     private ReturnObjectBag attributes;
> >>
> >>     public MyMockHttpServletRequest() {
> >>         attributes = new ReturnObjectBag("attributes");
> >>     }
> >>
> >>     public Object getAttribute(String s) {
> >>         return attributes.getHashTable().get(s);
> >>     }
> >>
> >>     public Enumeration getAttributeNames() {
> >>         return attributes.getHashTable().elements();
> >>     }
> >>
> >>     public void setAttribute(String s, Object o) {
> >>         attributes.getHashTable().put(s,o);
> >>     }
> >>}
> >>
> >>Is there a benefit to either approach? Both work perfectly in my test
> >>case and I'm more inclined to go with the first approach just because
> >>it's simpler (and the ReturnObjectBag does nothing for me in this case).
> >>
> >>Cheers,
> >>--Bill
> >>
> >>Jeff Martin wrote:
> >>
> >>>Should probably be a ReturnObjectBag as this lets you setup a list of
> >>>return values for a key.
> >>>
> >>>
> >>>On Thu, 2003-07-17 at 08:47, Steve Freeman wrote:
> >>>
> >>>
> >>>>This implementation /is/ a little hazy.
> >>>>
> >>>>The idea is that you should preload your attributes in the order in
> >>>>which they are requested, and then they'll just be returned as the code
> >>>>runs. It's not actually doing a lookup. Checking which attributes are
> >>>>asked for is actually a separate concept and handled by a different
> >>>>expectation. There are some arguments for doing this but it does look a
> >>>>little clumsy.
> >>>>
> >>>>If you don't like this, I suggest you replace this part of the mock
> >>>>request with an ExpectationMap which might be closer to the behaviour
> >>>>you want.
> >>>>
> >>>>S.
> >>>>
> >>>>Bill Lynch wrote:
> >>>>
> >>>>
> >>>>>All,
> >>>>>
> >>>>>I haven't been able to figure out how to set attributes in a
> >>>>>MockHttpServletRequest. I searched the mailing list archives for clues,
> >>>>>but didn't find any (and there's no javadocs for that class!).
> >>>>>
> >>>>>The method that looks like it might work only takes one param:
> >>>>>
> >>>>>request.setupGetAttribute(Object)
> >>>>>
> >>>>>I'd expect that to be
> >>>>>
> >>>>>request.setupGetAttribute(String, Object)
> >>>>>
> >>>>>I've also tried passing in a vector of name/value pairs to that method,
> >>>>>but when I call getAttribute(String) on that request object I get this
> >>>>>error:
> >>>>>
> >>>>>There was 1 failure:
> >>>>>1)
> >>
> >>>>testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedError
> > 
> > :
> > 
> >>>>>attributes has run out of objects.
> >>>>>   at
> >>
> >>>>com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:6
> > 
> > 1)
> > 
> >>>>>   at
> >>
> >>>>com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServl
> > 
> > etRequest.java:58)
> > 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
-- 
Jeff Martin

Memetic Engineer

http://www.custommonkey.org/

Re: [MO-java-users] setting attributes in a mock request

[Jeff M. <je...@cu...>]

Maybe a slightly better example is what happens when you do this.

//test setup
setAttribute("att", null);

//actual code
if(getAttribute("wrong att")==null){
	// do something
}


On Thu, 2003-07-17 at 16:34, Jeff Martin wrote:
> On Thu, 2003-07-17 at 16:06, Bill Lynch wrote:
> > Nat et al,
> > 
> > Thanks for the advice - I can change that code (I'm new to the class). I 
> > have a few more questions:
> > 
> > 1) Why should I keep using a ReturnObjectBag as an internal object? In 
> > my example, does it its use benefit me, or can I use it in a better way?
> Simplest (not best) example is this. How can you tell if your code is
> doing this.
> 
> for(int i=0;i<100000;i++){
>   att = request.getAttribute("name");
> }
> 
> or this
> 
> att = request.getAttribute("name");
> 
> > 
> > 2) If I shouldn't mess with the internal Hashtable, why is it exposed? 
> > Seems like poor design then.
> 
> Not bad design, just unusual environmental pressures, it's probably
> vestigial by now.
> 
> >
> > 3) Any reason there's no Javadocs for any of these classes? :) Having 
> > better documentation would have steered me away from using the internal 
> > hashtable probably.
> > 
> 
> cough,
> http://mockobjects.sourceforge.net/javadoc/1.4/com/mockobjects/ReturnObjectBag.html
> 
> > 
> > Cheers,
> > --Bill
> > 
> > Nat Pryce wrote:
> > 
> > > Try using the putObjectToReturn and getNextReturnObject methods rather than
> > > messing around with the ReturnObjectBag's internal hash table.
> > > 
> > > Cheers,
> > >             Nat.
> >  >
> > > ----- Original Message -----
> > > From: Bill Lynch
> > > To: <moc...@li...>
> > > Sent: Thursday, July 17, 2003 2:37 PM
> > > Subject: Re: [MO-java-users] setting attributes in a mock request
> > > 
> > >>Guys,
> > >>
> > >>I took Steve's advice and created my own extention to
> > >>MockHttpServletRequest - my first attempt is below:
> > >>
> > >>private class MyMockHttpServletRequest extends MockHttpServletRequest {
> > >>
> > >>     private Hashtable attributes;
> > >>
> > >>     public JiveMockHttpServletRequest() {
> > >>         attributes = new Hashtable();
> > >>     }
> > >>
> > >>     public Object getAttribute(String s) {
> > >>         return attributes.get(s);
> > >>     }
> > >>
> > >>     public Enumeration getAttributeNames() {
> > >>         return attributes.elements();
> > >>     }
> > >>
> > >>     public void setAttribute(String s, Object o) {
> > >>         attributes.put(s,o);
> > >>     }
> > >>}
> > >>
> > >>After doing this and reading Jeff's mail I implemented it with a
> > >>ReturnObjectBag - however, I don't see what that buys me:
> > >>
> > >>private class MyMockHttpServletRequest extends MockHttpServletRequest {
> > >>
> > >>     private ReturnObjectBag attributes;
> > >>
> > >>     public MyMockHttpServletRequest() {
> > >>         attributes = new ReturnObjectBag("attributes");
> > >>     }
> > >>
> > >>     public Object getAttribute(String s) {
> > >>         return attributes.getHashTable().get(s);
> > >>     }
> > >>
> > >>     public Enumeration getAttributeNames() {
> > >>         return attributes.getHashTable().elements();
> > >>     }
> > >>
> > >>     public void setAttribute(String s, Object o) {
> > >>         attributes.getHashTable().put(s,o);
> > >>     }
> > >>}
> > >>
> > >>Is there a benefit to either approach? Both work perfectly in my test
> > >>case and I'm more inclined to go with the first approach just because
> > >>it's simpler (and the ReturnObjectBag does nothing for me in this case).
> > >>
> > >>Cheers,
> > >>--Bill
> > >>
> > >>Jeff Martin wrote:
> > >>
> > >>>Should probably be a ReturnObjectBag as this lets you setup a list of
> > >>>return values for a key.
> > >>>
> > >>>
> > >>>On Thu, 2003-07-17 at 08:47, Steve Freeman wrote:
> > >>>
> > >>>
> > >>>>This implementation /is/ a little hazy.
> > >>>>
> > >>>>The idea is that you should preload your attributes in the order in
> > >>>>which they are requested, and then they'll just be returned as the code
> > >>>>runs. It's not actually doing a lookup. Checking which attributes are
> > >>>>asked for is actually a separate concept and handled by a different
> > >>>>expectation. There are some arguments for doing this but it does look a
> > >>>>little clumsy.
> > >>>>
> > >>>>If you don't like this, I suggest you replace this part of the mock
> > >>>>request with an ExpectationMap which might be closer to the behaviour
> > >>>>you want.
> > >>>>
> > >>>>S.
> > >>>>
> > >>>>Bill Lynch wrote:
> > >>>>
> > >>>>
> > >>>>>All,
> > >>>>>
> > >>>>>I haven't been able to figure out how to set attributes in a
> > >>>>>MockHttpServletRequest. I searched the mailing list archives for clues,
> > >>>>>but didn't find any (and there's no javadocs for that class!).
> > >>>>>
> > >>>>>The method that looks like it might work only takes one param:
> > >>>>>
> > >>>>>request.setupGetAttribute(Object)
> > >>>>>
> > >>>>>I'd expect that to be
> > >>>>>
> > >>>>>request.setupGetAttribute(String, Object)
> > >>>>>
> > >>>>>I've also tried passing in a vector of name/value pairs to that method,
> > >>>>>but when I call getAttribute(String) on that request object I get this
> > >>>>>error:
> > >>>>>
> > >>>>>There was 1 failure:
> > >>>>>1)
> > >>
> > >>>>testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedError
> > > 
> > > :
> > > 
> > >>>>>attributes has run out of objects.
> > >>>>>   at
> > >>
> > >>>>com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:6
> > > 
> > > 1)
> > > 
> > >>>>>   at
> > >>
> > >>>>com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServl
> > > 
> > > etRequest.java:58)
> > > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: VM Ware
> > With VMware you can run multiple operating systems on a single machine.
> > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> > _______________________________________________
> > Mockobjects-java-users mailing list
> > Moc...@li...
> > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
-- 
Jeff Martin

Memetic Engineer

http://www.custommonkey.org/

Re: [MO-java-users] setting attributes in a mock request

[Bill L. <bi...@ji...>]

Jeff,

>>Thanks for the advice - I can change that code (I'm new to the class). I 
>>have a few more questions:
>>
>>1) Why should I keep using a ReturnObjectBag as an internal object? In 
>>my example, does it its use benefit me, or can I use it in a better way?
> 
> Simplest (not best) example is this. How can you tell if your code is
> doing this.
> 
> for(int i=0;i<100000;i++){
>   att = request.getAttribute("name");
> }
> 
> or this
> 
> att = request.getAttribute("name");

So in the ReturnObjectBag's internal ReturnObjectList remove the object 
it returns from the list?

>>2) If I shouldn't mess with the internal Hashtable, why is it exposed? 
>>Seems like poor design then. 
> 
> Not bad design, just unusual environmental pressures, it's probably
> vestigial by now.

Gotcha.

>>3) Any reason there's no Javadocs for any of these classes? :) Having 
>>better documentation would have steered me away from using the internal 
>>hashtable probably.
> 
> cough,
> http://mockobjects.sourceforge.net/javadoc/1.4/com/mockobjects/ReturnObjectBag.html

Woa, my bad! Clearly I didn't dig deep enough. :)

Thanks,
--Bill



>>Nat Pryce wrote:
>>
>>
>>>Try using the putObjectToReturn and getNextReturnObject methods rather than
>>>messing around with the ReturnObjectBag's internal hash table.
>>>
>>>Cheers,
>>>            Nat.
>>
>> >
>>
>>>----- Original Message -----
>>>From: Bill Lynch
>>>To: <moc...@li...>
>>>Sent: Thursday, July 17, 2003 2:37 PM
>>>Subject: Re: [MO-java-users] setting attributes in a mock request
>>>
>>>
>>>>Guys,
>>>>
>>>>I took Steve's advice and created my own extention to
>>>>MockHttpServletRequest - my first attempt is below:
>>>>
>>>>private class MyMockHttpServletRequest extends MockHttpServletRequest {
>>>>
>>>>    private Hashtable attributes;
>>>>
>>>>    public JiveMockHttpServletRequest() {
>>>>        attributes = new Hashtable();
>>>>    }
>>>>
>>>>    public Object getAttribute(String s) {
>>>>        return attributes.get(s);
>>>>    }
>>>>
>>>>    public Enumeration getAttributeNames() {
>>>>        return attributes.elements();
>>>>    }
>>>>
>>>>    public void setAttribute(String s, Object o) {
>>>>        attributes.put(s,o);
>>>>    }
>>>>}
>>>>
>>>>After doing this and reading Jeff's mail I implemented it with a
>>>>ReturnObjectBag - however, I don't see what that buys me:
>>>>
>>>>private class MyMockHttpServletRequest extends MockHttpServletRequest {
>>>>
>>>>    private ReturnObjectBag attributes;
>>>>
>>>>    public MyMockHttpServletRequest() {
>>>>        attributes = new ReturnObjectBag("attributes");
>>>>    }
>>>>
>>>>    public Object getAttribute(String s) {
>>>>        return attributes.getHashTable().get(s);
>>>>    }
>>>>
>>>>    public Enumeration getAttributeNames() {
>>>>        return attributes.getHashTable().elements();
>>>>    }
>>>>
>>>>    public void setAttribute(String s, Object o) {
>>>>        attributes.getHashTable().put(s,o);
>>>>    }
>>>>}
>>>>
>>>>Is there a benefit to either approach? Both work perfectly in my test
>>>>case and I'm more inclined to go with the first approach just because
>>>>it's simpler (and the ReturnObjectBag does nothing for me in this case).
>>>>
>>>>Cheers,
>>>>--Bill
>>>>
>>>>Jeff Martin wrote:
>>>>
>>>>
>>>>>Should probably be a ReturnObjectBag as this lets you setup a list of
>>>>>return values for a key.
>>>>>
>>>>>
>>>>>On Thu, 2003-07-17 at 08:47, Steve Freeman wrote:
>>>>>
>>>>>
>>>>>
>>>>>>This implementation /is/ a little hazy.
>>>>>>
>>>>>>The idea is that you should preload your attributes in the order in
>>>>>>which they are requested, and then they'll just be returned as the code
>>>>>>runs. It's not actually doing a lookup. Checking which attributes are
>>>>>>asked for is actually a separate concept and handled by a different
>>>>>>expectation. There are some arguments for doing this but it does look a
>>>>>>little clumsy.
>>>>>>
>>>>>>If you don't like this, I suggest you replace this part of the mock
>>>>>>request with an ExpectationMap which might be closer to the behaviour
>>>>>>you want.
>>>>>>
>>>>>>S.
>>>>>>
>>>>>>Bill Lynch wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>All,
>>>>>>>
>>>>>>>I haven't been able to figure out how to set attributes in a
>>>>>>>MockHttpServletRequest. I searched the mailing list archives for clues,
>>>>>>>but didn't find any (and there's no javadocs for that class!).
>>>>>>>
>>>>>>>The method that looks like it might work only takes one param:
>>>>>>>
>>>>>>>request.setupGetAttribute(Object)
>>>>>>>
>>>>>>>I'd expect that to be
>>>>>>>
>>>>>>>request.setupGetAttribute(String, Object)
>>>>>>>
>>>>>>>I've also tried passing in a vector of name/value pairs to that method,
>>>>>>>but when I call getAttribute(String) on that request object I get this
>>>>>>>error:
>>>>>>>
>>>>>>>There was 1 failure:
>>>>>>>1)
>>>>
>>>>>>testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedError
>>>
>>>:
>>>
>>>
>>>>>>>attributes has run out of objects.
>>>>>>>  at
>>>>
>>>>>>com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:6
>>>
>>>1)
>>>
>>>
>>>>>>>  at
>>>>
>>>>>>com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServl
>>>
>>>etRequest.java:58)
>>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: VM Ware
>>With VMware you can run multiple operating systems on a single machine.
>>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
>>same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
>>_______________________________________________
>>Mockobjects-java-users mailing list
>>Moc...@li...
>>https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users

-- 
----------------------------------
Bill Lynch, Jive Software
bi...@ji...

[MO-java-users] RegEx-like method names for matchAndReturn?

[<mai...@ji...>]

Is there any way to have Mock.matchAndReturn() match against method
names using wildcards?  For example, I'd like to:

Mock mock = new Mock( InterfaceWithLotsOfBooleans.class );
mock.matchAndReturn( "is*", false );

Which for any isProperty method call would return false.

I figure that some kind of callable subclass is necessary, but with very
little in the way of javadocs (and the unit tests aren't helpful here),
I don't know where to go.

;ted

Re: [MO-java-users] RegEx-like method names for matchAndReturn?

[Nat P. <nat...@b1...>]

The MockObjects website has example code that does almost exactly what you
want.

Look at http://www.mockobjects.com/wiki/CallableDecorators

Cheers,
            Nat.
_______________________
Dr. Nathaniel Pryce
B13media Ltd.
http://www.b13media.com
+44 (0)7712 526 661

----- Original Message -----
From: <mai...@ji...>
To: <moc...@li...>
Sent: Thursday, July 17, 2003 7:26 PM
Subject: [MO-java-users] RegEx-like method names for matchAndReturn?


> Is there any way to have Mock.matchAndReturn() match against method
> names using wildcards?  For example, I'd like to:
>
> Mock mock = new Mock( InterfaceWithLotsOfBooleans.class );
> mock.matchAndReturn( "is*", false );
>
> Which for any isProperty method call would return false.
>
> I figure that some kind of callable subclass is necessary, but with very
> little in the way of javadocs (and the unit tests aren't helpful here),
> I don't know where to go.
>
> ;ted
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users

RE: [MO-java-users] RegEx-like method names for matchAndReturn?

[Jitterpig D. <jit...@ji...>]

I looked at that page already, but it doesn't seem to be compatible with
the latest mock objects download (0.09).  Mainly, the version of Mock
that I have doesn't implement the add() method...unless I'm looking in
the wrong place?

Thanks,
Ted

> -----Original Message-----
> From: moc...@li... 
> [mailto:moc...@li...] 
> On Behalf Of Nat Pryce
> Sent: Thursday, July 17, 2003 12:44 PM
> 
> The MockObjects website has example code that does almost 
> exactly what you
> want.
> 
> Look at http://www.mockobjects.com/wiki/CallableDecorators
> 
> Cheers,
>             Nat.
> _______________________
> Dr. Nathaniel Pryce
> B13media Ltd.
> http://www.b13media.com
> +44 (0)7712 526 661
> 
> ----- Original Message -----
> From: <mai...@ji...>
> To: <moc...@li...>
> Sent: Thursday, July 17, 2003 7:26 PM
> Subject: [MO-java-users] RegEx-like method names for matchAndReturn?
> 
> 
> > Is there any way to have Mock.matchAndReturn() match against method
> > names using wildcards?  For example, I'd like to:
> >
> > Mock mock = new Mock( InterfaceWithLotsOfBooleans.class );
> > mock.matchAndReturn( "is*", false );
> >
> > Which for any isProperty method call would return false.
> >
> > I figure that some kind of callable subclass is necessary, 
> but with very
> > little in the way of javadocs (and the unit tests aren't 
> helpful here),
> > I don't know where to go.
> >
> > ;ted
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: VM Ware
> > With VMware you can run multiple operating systems on a 
> single machine.
> > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual 
> machines at the
> > same time. Free trial click here: 
> http://www.vmware.com/wl/offer/345/0
> > 
> _______________________________________________
> > Mockobjects-java-users mailing list
> > Moc...@li...
> > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a 
> single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual 
> machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
> 

Re: [MO-java-users] RegEx-like method names for matchAndReturn?

[Joe W. <jo...@tr...>]

Not sure if this has been mentioned yet...

It would be much more flexible if the first argument of all the match 
and expect methods (i.e. the name) took a Constraint instead of a String.

-joe

Nat Pryce wrote:

>The MockObjects website has example code that does almost exactly what you
>want.
>
>Look at http://www.mockobjects.com/wiki/CallableDecorators
>
>Cheers,
>            Nat.
>_______________________
>Dr. Nathaniel Pryce
>B13media Ltd.
>http://www.b13media.com
>+44 (0)7712 526 661
>
>----- Original Message -----
>From: <mai...@ji...>
>To: <moc...@li...>
>Sent: Thursday, July 17, 2003 7:26 PM
>Subject: [MO-java-users] RegEx-like method names for matchAndReturn?
>
>
>  
>
>>Is there any way to have Mock.matchAndReturn() match against method
>>names using wildcards?  For example, I'd like to:
>>
>>Mock mock = new Mock( InterfaceWithLotsOfBooleans.class );
>>mock.matchAndReturn( "is*", false );
>>
>>Which for any isProperty method call would return false.
>>
>>I figure that some kind of callable subclass is necessary, but with very
>>little in the way of javadocs (and the unit tests aren't helpful here),
>>I don't know where to go.
>>
>>;ted
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: VM Ware
>>With VMware you can run multiple operating systems on a single machine.
>>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
>>same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
>>_______________________________________________
>>Mockobjects-java-users mailing list
>>Moc...@li...
>>https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
>>    
>>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: VM Ware
>With VMware you can run multiple operating systems on a single machine.
>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
>same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
>_______________________________________________
>Mockobjects-java-users mailing list
>Moc...@li...
>https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
>  
>

Re: [MO-java-users] RegEx-like method names for matchAndReturn?

[Nat P. <nat...@b1...>]

We've talked about that and I think everybody agrees that it's a good idea.
It's just that nobody has implemented it yet.  I think that their should be
an overloaded version that takes a String that means the same as passing an
IsEqual constraint.

Cheers,
            Nat.
_______________________
Dr. Nathaniel Pryce
B13media Ltd.
http://www.b13media.com
+44 (0)7712 526 661

----- Original Message -----
From: "Joe Walnes" <jo...@tr...>
To: "Nat Pryce" <nat...@b1...>
Cc: <moc...@li...>
Sent: Friday, July 18, 2003 9:27 AM
Subject: Re: [MO-java-users] RegEx-like method names for matchAndReturn?


> Not sure if this has been mentioned yet...
>
> It would be much more flexible if the first argument of all the match
> and expect methods (i.e. the name) took a Constraint instead of a String.
>
> -joe
>
> Nat Pryce wrote:
>
> >The MockObjects website has example code that does almost exactly what
you
> >want.
> >
> >Look at http://www.mockobjects.com/wiki/CallableDecorators
> >
> >Cheers,
> >            Nat.
> >_______________________
> >Dr. Nathaniel Pryce
> >B13media Ltd.
> >http://www.b13media.com
> >+44 (0)7712 526 661
> >
> >----- Original Message -----
> >From: <mai...@ji...>
> >To: <moc...@li...>
> >Sent: Thursday, July 17, 2003 7:26 PM
> >Subject: [MO-java-users] RegEx-like method names for matchAndReturn?
> >
> >
> >
> >
> >>Is there any way to have Mock.matchAndReturn() match against method
> >>names using wildcards?  For example, I'd like to:
> >>
> >>Mock mock = new Mock( InterfaceWithLotsOfBooleans.class );
> >>mock.matchAndReturn( "is*", false );
> >>
> >>Which for any isProperty method call would return false.
> >>
> >>I figure that some kind of callable subclass is necessary, but with very
> >>little in the way of javadocs (and the unit tests aren't helpful here),
> >>I don't know where to go.
> >>
> >>;ted
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.net email is sponsored by: VM Ware
> >>With VMware you can run multiple operating systems on a single machine.
> >>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> >>same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> >>_______________________________________________
> >>Mockobjects-java-users mailing list
> >>Moc...@li...
> >>https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
> >>
> >>
> >
> >
> >
> >-------------------------------------------------------
> >This SF.net email is sponsored by: VM Ware
> >With VMware you can run multiple operating systems on a single machine.
> >WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> >same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> >_______________________________________________
> >Mockobjects-java-users mailing list
> >Moc...@li...
> >https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
> >
> >
>
>

Re: [MO-java-users] setting attributes in a mock request

[Nat P. <nat...@b1...>]

The putObjectToReturn and getNextReturnObject methods are more descriptive
and check the expectations.  Using a hashtable does not check expectations:
if the class under test asks for an unexpected attribute it will receive a
null value and eventually throw a null pointer exception sometime down the
line. Using getNextReturnObject to ask for an unexpected attribute will fail
immediately with a descriptive error message.

For documentation, read through the tests for the library itself.  They show
it in use, and should describe the behaviour of the classes in a readable
manner.

Finally, I don't know why the hash table is exposed.  Perhaps somebody
needed to pass a hashtable to some other piece of code.  I would avoid using
it.

Cheers,
            Nat.

_______________________
Dr. Nathaniel Pryce
B13media Ltd.
http://www.b13media.com
+44 (0)7712 526 661

----- Original Message -----
From: "Bill Lynch" <bi...@ji...>
To: <moc...@li...>; "Nat Pryce"
<nat...@b1...>
Sent: Thursday, July 17, 2003 4:06 PM
Subject: Re: [MO-java-users] setting attributes in a mock request


> Nat et al,
>
> Thanks for the advice - I can change that code (I'm new to the class). I
> have a few more questions:
>
> 1) Why should I keep using a ReturnObjectBag as an internal object? In
> my example, does it its use benefit me, or can I use it in a better way?
>
> 2) If I shouldn't mess with the internal Hashtable, why is it exposed?
> Seems like poor design then.
>
> 3) Any reason there's no Javadocs for any of these classes? :) Having
> better documentation would have steered me away from using the internal
> hashtable probably.
>
> Cheers,
> --Bill
>
> Nat Pryce wrote:
>
> > Try using the putObjectToReturn and getNextReturnObject methods rather
than
> > messing around with the ReturnObjectBag's internal hash table.
> >
> > Cheers,
> >             Nat.
>  >
> > ----- Original Message -----
> > From: Bill Lynch
> > To: <moc...@li...>
> > Sent: Thursday, July 17, 2003 2:37 PM
> > Subject: Re: [MO-java-users] setting attributes in a mock request
> >
> >>Guys,
> >>
> >>I took Steve's advice and created my own extention to
> >>MockHttpServletRequest - my first attempt is below:
> >>
> >>private class MyMockHttpServletRequest extends MockHttpServletRequest {
> >>
> >>     private Hashtable attributes;
> >>
> >>     public JiveMockHttpServletRequest() {
> >>         attributes = new Hashtable();
> >>     }
> >>
> >>     public Object getAttribute(String s) {
> >>         return attributes.get(s);
> >>     }
> >>
> >>     public Enumeration getAttributeNames() {
> >>         return attributes.elements();
> >>     }
> >>
> >>     public void setAttribute(String s, Object o) {
> >>         attributes.put(s,o);
> >>     }
> >>}
> >>
> >>After doing this and reading Jeff's mail I implemented it with a
> >>ReturnObjectBag - however, I don't see what that buys me:
> >>
> >>private class MyMockHttpServletRequest extends MockHttpServletRequest {
> >>
> >>     private ReturnObjectBag attributes;
> >>
> >>     public MyMockHttpServletRequest() {
> >>         attributes = new ReturnObjectBag("attributes");
> >>     }
> >>
> >>     public Object getAttribute(String s) {
> >>         return attributes.getHashTable().get(s);
> >>     }
> >>
> >>     public Enumeration getAttributeNames() {
> >>         return attributes.getHashTable().elements();
> >>     }
> >>
> >>     public void setAttribute(String s, Object o) {
> >>         attributes.getHashTable().put(s,o);
> >>     }
> >>}
> >>
> >>Is there a benefit to either approach? Both work perfectly in my test
> >>case and I'm more inclined to go with the first approach just because
> >>it's simpler (and the ReturnObjectBag does nothing for me in this case).
> >>
> >>Cheers,
> >>--Bill
> >>
> >>Jeff Martin wrote:
> >>
> >>>Should probably be a ReturnObjectBag as this lets you setup a list of
> >>>return values for a key.
> >>>
> >>>
> >>>On Thu, 2003-07-17 at 08:47, Steve Freeman wrote:
> >>>
> >>>
> >>>>This implementation /is/ a little hazy.
> >>>>
> >>>>The idea is that you should preload your attributes in the order in
> >>>>which they are requested, and then they'll just be returned as the
code
> >>>>runs. It's not actually doing a lookup. Checking which attributes are
> >>>>asked for is actually a separate concept and handled by a different
> >>>>expectation. There are some arguments for doing this but it does look
a
> >>>>little clumsy.
> >>>>
> >>>>If you don't like this, I suggest you replace this part of the mock
> >>>>request with an ExpectationMap which might be closer to the behaviour
> >>>>you want.
> >>>>
> >>>>S.
> >>>>
> >>>>Bill Lynch wrote:
> >>>>
> >>>>
> >>>>>All,
> >>>>>
> >>>>>I haven't been able to figure out how to set attributes in a
> >>>>>MockHttpServletRequest. I searched the mailing list archives for
clues,
> >>>>>but didn't find any (and there's no javadocs for that class!).
> >>>>>
> >>>>>The method that looks like it might work only takes one param:
> >>>>>
> >>>>>request.setupGetAttribute(Object)
> >>>>>
> >>>>>I'd expect that to be
> >>>>>
> >>>>>request.setupGetAttribute(String, Object)
> >>>>>
> >>>>>I've also tried passing in a vector of name/value pairs to that
method,
> >>>>>but when I call getAttribute(String) on that request object I get
this
> >>>>>error:
> >>>>>
> >>>>>There was 1 failure:
> >>>>>1)
> >>
>
>>>>testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedErro
r
> >
> > :
> >
> >>>>>attributes has run out of objects.
> >>>>>   at
> >>
>
>>>>com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:
6
> >
> > 1)
> >
> >>>>>   at
> >>
>
>>>>com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServ
l
> >
> > etRequest.java:58)
> >
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users

Re: [MO-java-users] setting attributes in a mock request

[Bill L. <bi...@ji...>]

Nat,

Nat Pryce wrote:
> The putObjectToReturn and getNextReturnObject methods are more descriptive
> and check the expectations.  Using a hashtable does not check expectations:
> if the class under test asks for an unexpected attribute it will receive a
> null value and eventually throw a null pointer exception sometime down the
> line. Using getNextReturnObject to ask for an unexpected attribute will fail
> immediately with a descriptive error message.

Ok, got it - thanks.

> For documentation, read through the tests for the library itself.  They show
> it in use, and should describe the behaviour of the classes in a readable
> manner.

Thanks, I'll check those out.

Cheers,
--Bill

> Finally, I don't know why the hash table is exposed.  Perhaps somebody
> needed to pass a hashtable to some other piece of code.  I would avoid using
> it.
> 
> Cheers,
>             Nat.
> 
> _______________________
> Dr. Nathaniel Pryce
> B13media Ltd.
> http://www.b13media.com
> +44 (0)7712 526 661
> 
> ----- Original Message -----
> From: "Bill Lynch" <bi...@ji...>
> To: <moc...@li...>; "Nat Pryce"
> <nat...@b1...>
> Sent: Thursday, July 17, 2003 4:06 PM
> Subject: Re: [MO-java-users] setting attributes in a mock request
> 
> 
> 
>>Nat et al,
>>
>>Thanks for the advice - I can change that code (I'm new to the class). I
>>have a few more questions:
>>
>>1) Why should I keep using a ReturnObjectBag as an internal object? In
>>my example, does it its use benefit me, or can I use it in a better way?
>>
>>2) If I shouldn't mess with the internal Hashtable, why is it exposed?
>>Seems like poor design then.
>>
>>3) Any reason there's no Javadocs for any of these classes? :) Having
>>better documentation would have steered me away from using the internal
>>hashtable probably.
>>
>>Cheers,
>>--Bill
>>
>>Nat Pryce wrote:
>>
>>
>>>Try using the putObjectToReturn and getNextReturnObject methods rather
> 
> than
> 
>>>messing around with the ReturnObjectBag's internal hash table.
>>>
>>>Cheers,
>>>            Nat.
>>
>> >
>>
>>>----- Original Message -----
>>>From: Bill Lynch
>>>To: <moc...@li...>
>>>Sent: Thursday, July 17, 2003 2:37 PM
>>>Subject: Re: [MO-java-users] setting attributes in a mock request
>>>
>>>
>>>>Guys,
>>>>
>>>>I took Steve's advice and created my own extention to
>>>>MockHttpServletRequest - my first attempt is below:
>>>>
>>>>private class MyMockHttpServletRequest extends MockHttpServletRequest {
>>>>
>>>>    private Hashtable attributes;
>>>>
>>>>    public JiveMockHttpServletRequest() {
>>>>        attributes = new Hashtable();
>>>>    }
>>>>
>>>>    public Object getAttribute(String s) {
>>>>        return attributes.get(s);
>>>>    }
>>>>
>>>>    public Enumeration getAttributeNames() {
>>>>        return attributes.elements();
>>>>    }
>>>>
>>>>    public void setAttribute(String s, Object o) {
>>>>        attributes.put(s,o);
>>>>    }
>>>>}
>>>>
>>>>After doing this and reading Jeff's mail I implemented it with a
>>>>ReturnObjectBag - however, I don't see what that buys me:
>>>>
>>>>private class MyMockHttpServletRequest extends MockHttpServletRequest {
>>>>
>>>>    private ReturnObjectBag attributes;
>>>>
>>>>    public MyMockHttpServletRequest() {
>>>>        attributes = new ReturnObjectBag("attributes");
>>>>    }
>>>>
>>>>    public Object getAttribute(String s) {
>>>>        return attributes.getHashTable().get(s);
>>>>    }
>>>>
>>>>    public Enumeration getAttributeNames() {
>>>>        return attributes.getHashTable().elements();
>>>>    }
>>>>
>>>>    public void setAttribute(String s, Object o) {
>>>>        attributes.getHashTable().put(s,o);
>>>>    }
>>>>}
>>>>
>>>>Is there a benefit to either approach? Both work perfectly in my test
>>>>case and I'm more inclined to go with the first approach just because
>>>>it's simpler (and the ReturnObjectBag does nothing for me in this case).
>>>>
>>>>Cheers,
>>>>--Bill
>>>>
>>>>Jeff Martin wrote:
>>>>
>>>>
>>>>>Should probably be a ReturnObjectBag as this lets you setup a list of
>>>>>return values for a key.
>>>>>
>>>>>
>>>>>On Thu, 2003-07-17 at 08:47, Steve Freeman wrote:
>>>>>
>>>>>
>>>>>
>>>>>>This implementation /is/ a little hazy.
>>>>>>
>>>>>>The idea is that you should preload your attributes in the order in
>>>>>>which they are requested, and then they'll just be returned as the
> 
> code
> 
>>>>>>runs. It's not actually doing a lookup. Checking which attributes are
>>>>>>asked for is actually a separate concept and handled by a different
>>>>>>expectation. There are some arguments for doing this but it does look
> 
> a
> 
>>>>>>little clumsy.
>>>>>>
>>>>>>If you don't like this, I suggest you replace this part of the mock
>>>>>>request with an ExpectationMap which might be closer to the behaviour
>>>>>>you want.
>>>>>>
>>>>>>S.
>>>>>>
>>>>>>Bill Lynch wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>All,
>>>>>>>
>>>>>>>I haven't been able to figure out how to set attributes in a
>>>>>>>MockHttpServletRequest. I searched the mailing list archives for
> 
> clues,
> 
>>>>>>>but didn't find any (and there's no javadocs for that class!).
>>>>>>>
>>>>>>>The method that looks like it might work only takes one param:
>>>>>>>
>>>>>>>request.setupGetAttribute(Object)
>>>>>>>
>>>>>>>I'd expect that to be
>>>>>>>
>>>>>>>request.setupGetAttribute(String, Object)
>>>>>>>
>>>>>>>I've also tried passing in a vector of name/value pairs to that
> 
> method,
> 
>>>>>>>but when I call getAttribute(String) on that request object I get
> 
> this
> 
>>>>>>>error:
>>>>>>>
>>>>>>>There was 1 failure:
>>>>>>>1)
>>>>
>>>>>testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedErro
> 
> r
> 
>>>:
>>>
>>>
>>>>>>>attributes has run out of objects.
>>>>>>>  at
>>>>
>>>>>com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:
> 
> 6
> 
>>>1)
>>>
>>>
>>>>>>>  at
>>>>
>>>>>com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServ
> 
> l
> 
>>>etRequest.java:58)
>>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: VM Ware
>>With VMware you can run multiple operating systems on a single machine.
>>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
>>same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
>>_______________________________________________
>>Mockobjects-java-users mailing list
>>Moc...@li...
>>https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users

-- 
----------------------------------
Bill Lynch, Jive Software
bi...@ji...