springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Re: struts integration - alternate approach

[<jue...@we...>]

Just committed them: There's =
org.springframework.web.struts.DelegatingRequestProcessor and =
org.springframework.web.struts.DelegatingTilesRequestProcessor now - =
check out the javadoc for details.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Seth Ladd
Gesendet: Mi 28.04.2004 23:39
An: spr...@li...
Betreff: Re: [Springframework-developer] Re: struts integration - =
alternate approach



j=FCrgen h=F6ller [werk3AT] wrote:
> OK, I'll commit them tomorrow morning - please give them a try once =
they're in CVS, to verify that they address your needs.
>

Will do.  Thanks!
Seth



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Spring Portlet MVC layer is rendering JSTL Views!!!

[William G. T. Jr. <wg...@ru...>]

Folks,

Spring Portlet MVC layer is rendering JSTL Views with full 
ApplicationContext support!!!

I ended having to port just about the entire 
org.springframework.web.servlet.* package.

Should this go into the sandbox?  I suspect that it may still need some 
refactoring...after we play with it a bit more.

later.
Bill
-- 
William G. Thompson, Jr.
Associate Director of New Technologies
Administrative Computing Services, Rutgers University
voice: 732 445-5428 | fax: 732 445-5493 | wg...@ru...

Re: [Springframework-developer] Testing Controllers and FormControllers

[<jue...@we...>]

BTW, I've already committed the factored-out "mock" tree, including =
adapted build scripts etc.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Mi 28.04.2004 21:32
An: spr...@li...
Betreff: Re: [Springframework-developer] Testing Controllers and =
FormControllers



The classes currently slated to go there are external classes (to
Spring), in any case.

For mocks for Spring internal classes (if and when they appear), they
may belong in the mocked class's package, and stored under the existing
test tree or the mock tree as appropriate.

Alef Arendsen wrote:

>+1 on the org.springframework.mock.* packages,
>
>although you loose the possibility of having access to package visible =
stuff
>when not putting the mocks in the same package as the stuff they =
mock...
>
>Alef
>
>
>=20
>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On =
Behalf
>>Of j=FCrgen h=F6ller [werk3AT]
>>Sent: Wednesday, April 28, 2004 2:57 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Testing Controllers and
>>FormControllers
>>
>>Works nicely: spring-mock.jar is currently 26 KB, including the JNDI =
and
>>the web mocks. The size of spring.jar went down from 973 KB to 956 KB,
>>because of the JNDI mocks not being included there anymore.
>>
>>In total, I completely agree that a separate mock tree makes sense. =
The
>>only remaining question is the package naming: I tend to prefer the
>>"org.springframework.mock" subpackages, for having a clear package =
subtree
>>in the "mock" directory.
>>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On =
Behalf
>>Of j=FCrgen h=F6ller [werk3AT]
>>Sent: Wednesday, April 28, 2004 2:32 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Testing Controllers and
>>FormControllers
>>
>>
>>If we move them to a separate JAR and separate tree, the mock classes =
in
>>the jndi.support package more or less have to join them for =
consistency
>>reasons. I prefer the name "spring-mock.jar" to "spring-test.jar", as =
the
>>latter is already used as directory name for the test suite.
>>
>>Given our decoupling from JNDI, I doubt that anyone those JNDI mocks
>>anyway: They are mainly used in our framework test suite. And whoever =
uses
>>them in a test suite can seamlessly adapt the package name.
>>
>>So this looks like:
>>
>>* a new "mock" directory (alongside "docs", "src", etc), containing =
the
>>mock sources (without "src" subdirectory, as there is not much point =
in
>>testing mocks, therefore there won't be a "test" subdirectory there)
>>
>>* a "spring-mock.jar", generated from the "mock" directory by the =
build
>>script, shipped in the "dist" directory of our distribution
>>
>>The remaining question is: How to name the packages there?
>>org.springframework.jndi.mock / org.springframework.web.mock or
>>org.springframework.mock.jndi / org.springframework.mock.web? I guess =
the
>>latter is more appropriate, given that they are in a separate source =
tree.
>>
>>As a side note: I doubt that those mocks will expand significantly, =
but I
>>still see the point in keeping them in a dedicated tree.
>>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On =
Behalf
>>Of Rod Johnson
>>Sent: Tuesday, April 27, 2004 11:13 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Re: [Springframework-user]
>>Testing Controllers and FormControllers
>>
>>
>>Thanks for the cleaning up: they needed it. However, I feel uneasy =
about
>>these classes being included in spring.jar. I would like to see them =
in a
>>spring-test.jar.
>>
>>I don't particularly object to them going in the main /src tree, =
although
>>I'd really prefer a dedicated tree there as well. I'm sure that other
>>stuff
>>will join them in such a new tree.
>>
>>Rgds,
>>Rod
>>
>>----- Original Message -----
>>From: "Colin Sampaleanu" <col...@ex...>
>>To: <spr...@li...>
>>Cc: <spr...@li...>
>>Sent: Tuesday, April 27, 2004 9:30 PM
>>Subject: Re: [Springframework-developer] Re: [Springframework-user]
>>Testing
>>Controllers and FormControllers
>>
>>
>>I'm ok with including these in Spring; if people feel they are too =
big,
>>they could be a spring-test add-on jar, that's not even included in =
the
>>main spring.jar which normally included all the optional stuff. That
>>makes some sense since this is for testing.
>>
>>j=FCrgen h=F6ller [werk3AT] wrote:
>>
>>  =20
>>
>>>Matt, everybody,
>>>
>>>Essentially, the Servlet API mocks in Spring's test directory are =
just
>>>    =20
>>>
>>there because the MockObjects (http://www.mockobjects.com) Servlet API
>>mocks
>>are so inconvenient to use. The current Spring-provided Servlet API =
mocks
>>are by no means in a polished state, though: They're just good enough =
for
>>being used within the framework test suite. They'd need some serious
>>refinement for making them public - after all, we have a reputation to
>>lose
>>:-)
>>  =20
>>
>>>So on that occasion, I've reworked those mocks today, making them
>>>    =20
>>>
>>significantly more complete than before, and ready for getting =
included in
>>the Spring distribution. The question is: Where to include them? I'd =
like
>>to
>>include them in the main Spring sources, in a =
org.springframework.web.mock
>>package: They would naturally be part of spring.jar and spring-web.jar
>>then.
>>The test directory (where they currently reside) is no appropriate =
place,
>>as
>>it is about testing the framework rather than providing infrastructure
>>classes.
>>  =20
>>
>>>While it isn't in general appropriate to include mocks in the main =
Spring
>>>    =20
>>>
>>codebase, I guess this is a different case: Those mocks are =
specifically
>>provided to ease testing of Spring web contexts (like
>>XmlWebApplicationContext or StaticWebApplicationContext that need a
>>ServletContext) and controllers (the Controller.handleRequest method =
needs
>>an HttpServletRequest and an HttpServletResponse). Including them in =
the
>>standard distribution would also indicate our strong focus on =
testability.
>>  =20
>>
>>>The new MockServletContext implementation uses the
>>>    =20
>>>
>>org.springframework.core.io.Resource API for resource loading, to =
allow
>>for
>>ServletContext.getResourceAsStream from any resource base. So partly, =
the
>>mock implementations depend on low-level Spring API. We could of =
course
>>keep
>>the mocks in a separate part of the Spring CVS, but it's just about a
>>couple
>>of classes, thus hardly worth a separate source tree.
>>  =20
>>
>>>IMO, the main concern regarding additions to the main Spring codebase =
is
>>>    =20
>>>
>>whether those additions can potentially grow significantly: While =
Keith's
>>rules API in the sandbox has definite potential there (so had Ben =
Alex'
>>security framework that became the Acegi Security System), the recent
>>Struts
>>support classes and those Servlet API mocks will at best see slight
>>refinements but certainly not exponential growth. So the former seems =
like
>>a
>>candidate for a separate module to me, while the latter should fit =
into
>>the
>>main Spring codebase.
>>  =20
>>
>>>An important point to consider is that there are simply no mocks
>>>    =20
>>>
>>necessary
>>for testing most parts of a typical Spring app, respectively just
>>interfaces
>>that can conveniently be mocked in a dynamic fashion with EasyMock. =
There
>>are just two exceptions, as far I see: Our SimpleNamingContext stuff =
eases
>>custom JNDI environments, and the newly refined set of Servlet API =
mocks
>>allows for convenient testing of Spring web MVC (and web contexts).
>>  =20
>>
>>>Mocking an EJB container is next to impossible, so that's not worth
>>>    =20
>>>
>>further
>>consideration. JDBC can quite nicely be mocked with EasyMock; it's
>>preferable to use the JdbcOperations interface as far as possible, =
though.
>>Same for a Hibernate Session, with HibernateOperations being =
preferable.
>>It's more or less just the Servlet API that's really tedious to mock =
with
>>EasyMock, due to all those interdependent methods (e.g. URL paths,
>>parameters, attributes).
>>  =20
>>
>>>What does everybody think? Does anyone mind including those polished
>>>    =20
>>>
>>Servlet API mocks in the main Spring codebase, already for 1.0.2? Any
>>suggestions for alternatives?
>>  =20
>>
>>>Juergen
>>>
>>>
>>>-----Original Message-----
>>>From: spr...@li...
>>>[mailto:spr...@li...]On Behalf Of
>>>Matt Raible
>>>Sent: Saturday, April 24, 2004 2:02 PM
>>>To: spr...@li...
>>>Subject: Re: [Springframework-user] Testing Controllers and
>>>FormControllers
>>>
>>>
>>>I use StrutsTestCase (http://strutstestcase.sf.net), which allows you
>>>to write very little code to test an Action.  Here is a simple =
example
>>>of testing an "execute" method:
>>>
>>>package org.appfuse.webapp.action;
>>>
>>>import servletunit.struts.CactusStrutsTestCase;
>>>import org.appfuse.Constants;
>>>
>>>public class PersonActionTest extends CactusStrutsTestCase {
>>>
>>>   public PersonActionTest(String name) {
>>>       super(name);
>>>   }
>>>
>>>   public void testExecute() {
>>>       // test execute method
>>>       setRequestPathInfo("/editPerson");
>>>       addRequestParameter("id", "1");
>>>       actionPerform();
>>>       verifyNoActionErrors();
>>>        =
assertNotNull(getRequest().getAttribute(Constants.PERSON_KEY));
>>>    }
>>>
>>>    public static void main(String[] args) {
>>>        junit.textui.TestRunner.run(PersonActionTest.class);
>>>    }
>>>}
>>>
>>>Since CactusStrutsTestCase extends from Cactus, I can also use =
Cactus's
>>>FormAuthentication support to mimic container-managed authentication.
>>>
>>>To test a "Save" is also pretty simple.
>>>
>>>    public void testSave() throws Exception {
>>>        setRequestPathInfo("/editPerson");
>>>        addRequestParameter("action", "Edit");
>>>        addRequestParameter("id", "1");
>>>
>>>        actionPerform();
>>>
>>>        assertTrue(getRequest().getAttribute(Constants.PERSON_KEY) =
!=3D
>>>null);
>>>
>>>        setRequestPathInfo("/savePerson");
>>>        addRequestParameter("action", "Save");
>>>        actionPerform();
>>>        verifyForward("edit");
>>>        verifyNoActionErrors();
>>>    }
>>>
>>>I think you have something similar to this with the Mock Object =
you're
>>>using in Spring.  It just needs to be packaged up as a JAR.  I'll be
>>>more than happy to write up some documentation on how to use it.
>>>
>>>Matt
>>>
>>>
>>>On Apr 24, 2004, at 4:27 AM, j=FCrgen h=F6ller [werk3AT] wrote:
>>>
>>>
>>>
>>>    =20
>>>
>>>>Matt,
>>>>
>>>>I just tried using MockHttpServletRequest and =
MockHttpServletResponse
>>>>      =20
>>>>
>>>>from MockObjects with a Spring FormController. Unfortunately, those
>>>    =20
>>>
>>>>MockObjects mocks are really not well-suited for testing here, as =
it's
>>>>so much hassle to setup any kind of HttpServletRequest method =
access.
>>>>What request/response mocks do you use for testing Struts Actions?
>>>>
>>>>Juergen
>>>>
>>>>
>>>>________________________________
>>>>
>>>>Von: spr...@li... im Auftrag von
>>>>j=FCrgen h=F6ller [werk3AT]
>>>>Gesendet: Sa 24.04.2004 10:57
>>>>An: spr...@li...
>>>>Betreff: Re: [Springframework-user] Testing Controllers and
>>>>FormControllers
>>>>
>>>>
>>>>
>>>>I don't see much difference between testing Controllers and
>>>>FormControllers: Both share the same "ModelAndView
>>>>handleRequest(HttpServletRequest, HttpServletResponse)" method that
>>>>you need to invoke for testing. As of 1.0.1, you shouldn't need a
>>>>ServletContext mock anymore (except when actually accessing the
>>>>ServletContext), so all you need are HttpServletRequest and
>>>>HttpServletResponse mocks. The mocks provided by the MockObjects
>>>>project should be fine for this.
>>>>
>>>>Juergen
>>>>
>>>>
>>>>________________________________
>>>>
>>>>Von: spr...@li... im Auftrag von
>>>>Matt Raible
>>>>Gesendet: Fr 23.04.2004 20:48
>>>>An: spr...@li...
>>>>Betreff: [Springframework-user] Testing Controllers and =
FormControllers
>>>>
>>>>
>>>>
>>>>I've found it pretty simple to test Controllers, but FormControllers
>>>>are
>>>>a different story.  From looking at the FormControllerTestSuite (URL
>>>>below), as well as many other Spring tests, it seems that a lot of
>>>>internal mocks are used to test this stuff.
>>>>
>>>>So my question is - what do you recommend for the average Spring MVC
>>>>person?  What is the strategy we should be using to test our
>>>>controllers?  Should we be using the Mocks that Spring provides?  =
This
>>>>would certainly make things easier.  If we're supposed to do that - =
is
>>>>it possible to get these mocks distributed in a JAR?
>>>>
>>>>Thanks,
>>>>
>>>>Matt
>>>>
>>>>http://monkeymachine.co.uk/spring/xref-test/org/springframework/web/
>>>>serv
>>>>let/mvc/FormControllerTestSuite.html
>>>>
>>>>
>>>>      =20
>>>>



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: struts integration - alternate approach

[Seth L. <se...@eh...>]

jürgen höller [werk3AT] wrote:
> OK, I'll commit them tomorrow morning - please give them a try once they're in CVS, to verify that they address your needs.
> 

Will do.  Thanks!
Seth

Re: [Springframework-developer] Testing Controllers and FormControllers

[Colin S. <col...@ex...>]

The classes currently slated to go there are external classes (to=20
Spring), in any case.

For mocks for Spring internal classes (if and when they appear), they=20
may belong in the mocked class's package, and stored under the existing=20
test tree or the mock tree as appropriate.

Alef Arendsen wrote:

>+1 on the org.springframework.mock.* packages,=20
>
>although you loose the possibility of having access to package visible s=
tuff
>when not putting the mocks in the same package as the stuff they mock...
>
>Alef
>
>
> =20
>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On Behal=
f
>>Of j=FCrgen h=F6ller [werk3AT]
>>Sent: Wednesday, April 28, 2004 2:57 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Testing Controllers and
>>FormControllers
>>
>>Works nicely: spring-mock.jar is currently 26 KB, including the JNDI an=
d
>>the web mocks. The size of spring.jar went down from 973 KB to 956 KB,
>>because of the JNDI mocks not being included there anymore.
>>
>>In total, I completely agree that a separate mock tree makes sense. The
>>only remaining question is the package naming: I tend to prefer the
>>"org.springframework.mock" subpackages, for having a clear package subt=
ree
>>in the "mock" directory.
>>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf
>>Of j=FCrgen h=F6ller [werk3AT]
>>Sent: Wednesday, April 28, 2004 2:32 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Testing Controllers and
>>FormControllers
>>
>>
>>If we move them to a separate JAR and separate tree, the mock classes i=
n
>>the jndi.support package more or less have to join them for consistency
>>reasons. I prefer the name "spring-mock.jar" to "spring-test.jar", as t=
he
>>latter is already used as directory name for the test suite.
>>
>>Given our decoupling from JNDI, I doubt that anyone those JNDI mocks
>>anyway: They are mainly used in our framework test suite. And whoever u=
ses
>>them in a test suite can seamlessly adapt the package name.
>>
>>So this looks like:
>>
>>* a new "mock" directory (alongside "docs", "src", etc), containing the
>>mock sources (without "src" subdirectory, as there is not much point in
>>testing mocks, therefore there won't be a "test" subdirectory there)
>>
>>* a "spring-mock.jar", generated from the "mock" directory by the build
>>script, shipped in the "dist" directory of our distribution
>>
>>The remaining question is: How to name the packages there?
>>org.springframework.jndi.mock / org.springframework.web.mock or
>>org.springframework.mock.jndi / org.springframework.mock.web? I guess t=
he
>>latter is more appropriate, given that they are in a separate source tr=
ee.
>>
>>As a side note: I doubt that those mocks will expand significantly, but=
 I
>>still see the point in keeping them in a dedicated tree.
>>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf
>>Of Rod Johnson
>>Sent: Tuesday, April 27, 2004 11:13 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Re: [Springframework-user]
>>Testing Controllers and FormControllers
>>
>>
>>Thanks for the cleaning up: they needed it. However, I feel uneasy abou=
t
>>these classes being included in spring.jar. I would like to see them in=
 a
>>spring-test.jar.
>>
>>I don't particularly object to them going in the main /src tree, althou=
gh
>>I'd really prefer a dedicated tree there as well. I'm sure that other
>>stuff
>>will join them in such a new tree.
>>
>>Rgds,
>>Rod
>>
>>----- Original Message -----
>>From: "Colin Sampaleanu" <col...@ex...>
>>To: <spr...@li...>
>>Cc: <spr...@li...>
>>Sent: Tuesday, April 27, 2004 9:30 PM
>>Subject: Re: [Springframework-developer] Re: [Springframework-user]
>>Testing
>>Controllers and FormControllers
>>
>>
>>I'm ok with including these in Spring; if people feel they are too big,
>>they could be a spring-test add-on jar, that's not even included in the
>>main spring.jar which normally included all the optional stuff. That
>>makes some sense since this is for testing.
>>
>>j=FCrgen h=F6ller [werk3AT] wrote:
>>
>>   =20
>>
>>>Matt, everybody,
>>>
>>>Essentially, the Servlet API mocks in Spring's test directory are just
>>>     =20
>>>
>>there because the MockObjects (http://www.mockobjects.com) Servlet API
>>mocks
>>are so inconvenient to use. The current Spring-provided Servlet API moc=
ks
>>are by no means in a polished state, though: They're just good enough f=
or
>>being used within the framework test suite. They'd need some serious
>>refinement for making them public - after all, we have a reputation to
>>lose
>>:-)
>>   =20
>>
>>>So on that occasion, I've reworked those mocks today, making them
>>>     =20
>>>
>>significantly more complete than before, and ready for getting included=
 in
>>the Spring distribution. The question is: Where to include them? I'd li=
ke
>>to
>>include them in the main Spring sources, in a org.springframework.web.m=
ock
>>package: They would naturally be part of spring.jar and spring-web.jar
>>then.
>>The test directory (where they currently reside) is no appropriate plac=
e,
>>as
>>it is about testing the framework rather than providing infrastructure
>>classes.
>>   =20
>>
>>>While it isn't in general appropriate to include mocks in the main Spr=
ing
>>>     =20
>>>
>>codebase, I guess this is a different case: Those mocks are specificall=
y
>>provided to ease testing of Spring web contexts (like
>>XmlWebApplicationContext or StaticWebApplicationContext that need a
>>ServletContext) and controllers (the Controller.handleRequest method ne=
eds
>>an HttpServletRequest and an HttpServletResponse). Including them in th=
e
>>standard distribution would also indicate our strong focus on testabili=
ty.
>>   =20
>>
>>>The new MockServletContext implementation uses the
>>>     =20
>>>
>>org.springframework.core.io.Resource API for resource loading, to allow
>>for
>>ServletContext.getResourceAsStream from any resource base. So partly, t=
he
>>mock implementations depend on low-level Spring API. We could of course
>>keep
>>the mocks in a separate part of the Spring CVS, but it's just about a
>>couple
>>of classes, thus hardly worth a separate source tree.
>>   =20
>>
>>>IMO, the main concern regarding additions to the main Spring codebase =
is
>>>     =20
>>>
>>whether those additions can potentially grow significantly: While Keith=
's
>>rules API in the sandbox has definite potential there (so had Ben Alex'
>>security framework that became the Acegi Security System), the recent
>>Struts
>>support classes and those Servlet API mocks will at best see slight
>>refinements but certainly not exponential growth. So the former seems l=
ike
>>a
>>candidate for a separate module to me, while the latter should fit into
>>the
>>main Spring codebase.
>>   =20
>>
>>>An important point to consider is that there are simply no mocks
>>>     =20
>>>
>>necessary
>>for testing most parts of a typical Spring app, respectively just
>>interfaces
>>that can conveniently be mocked in a dynamic fashion with EasyMock. The=
re
>>are just two exceptions, as far I see: Our SimpleNamingContext stuff ea=
ses
>>custom JNDI environments, and the newly refined set of Servlet API mock=
s
>>allows for convenient testing of Spring web MVC (and web contexts).
>>   =20
>>
>>>Mocking an EJB container is next to impossible, so that's not worth
>>>     =20
>>>
>>further
>>consideration. JDBC can quite nicely be mocked with EasyMock; it's
>>preferable to use the JdbcOperations interface as far as possible, thou=
gh.
>>Same for a Hibernate Session, with HibernateOperations being preferable=
.
>>It's more or less just the Servlet API that's really tedious to mock wi=
th
>>EasyMock, due to all those interdependent methods (e.g. URL paths,
>>parameters, attributes).
>>   =20
>>
>>>What does everybody think? Does anyone mind including those polished
>>>     =20
>>>
>>Servlet API mocks in the main Spring codebase, already for 1.0.2? Any
>>suggestions for alternatives?
>>   =20
>>
>>>Juergen
>>>
>>>
>>>-----Original Message-----
>>>From: spr...@li...
>>>[mailto:spr...@li...]On Behalf Of
>>>Matt Raible
>>>Sent: Saturday, April 24, 2004 2:02 PM
>>>To: spr...@li...
>>>Subject: Re: [Springframework-user] Testing Controllers and
>>>FormControllers
>>>
>>>
>>>I use StrutsTestCase (http://strutstestcase.sf.net), which allows you
>>>to write very little code to test an Action.  Here is a simple example
>>>of testing an "execute" method:
>>>
>>>package org.appfuse.webapp.action;
>>>
>>>import servletunit.struts.CactusStrutsTestCase;
>>>import org.appfuse.Constants;
>>>
>>>public class PersonActionTest extends CactusStrutsTestCase {
>>>
>>>   public PersonActionTest(String name) {
>>>       super(name);
>>>   }
>>>
>>>   public void testExecute() {
>>>       // test execute method
>>>       setRequestPathInfo("/editPerson");
>>>       addRequestParameter("id", "1");
>>>       actionPerform();
>>>       verifyNoActionErrors();
>>>        assertNotNull(getRequest().getAttribute(Constants.PERSON_KEY))=
;
>>>    }
>>>
>>>    public static void main(String[] args) {
>>>        junit.textui.TestRunner.run(PersonActionTest.class);
>>>    }
>>>}
>>>
>>>Since CactusStrutsTestCase extends from Cactus, I can also use Cactus'=
s
>>>FormAuthentication support to mimic container-managed authentication.
>>>
>>>To test a "Save" is also pretty simple.
>>>
>>>    public void testSave() throws Exception {
>>>        setRequestPathInfo("/editPerson");
>>>        addRequestParameter("action", "Edit");
>>>        addRequestParameter("id", "1");
>>>
>>>        actionPerform();
>>>
>>>        assertTrue(getRequest().getAttribute(Constants.PERSON_KEY) !=3D
>>>null);
>>>
>>>        setRequestPathInfo("/savePerson");
>>>        addRequestParameter("action", "Save");
>>>        actionPerform();
>>>        verifyForward("edit");
>>>        verifyNoActionErrors();
>>>    }
>>>
>>>I think you have something similar to this with the Mock Object you're
>>>using in Spring.  It just needs to be packaged up as a JAR.  I'll be
>>>more than happy to write up some documentation on how to use it.
>>>
>>>Matt
>>>
>>>
>>>On Apr 24, 2004, at 4:27 AM, j=FCrgen h=F6ller [werk3AT] wrote:
>>>
>>>
>>>
>>>     =20
>>>
>>>>Matt,
>>>>
>>>>I just tried using MockHttpServletRequest and MockHttpServletResponse
>>>>       =20
>>>>
>>>>from MockObjects with a Spring FormController. Unfortunately, those
>>>     =20
>>>
>>>>MockObjects mocks are really not well-suited for testing here, as it'=
s
>>>>so much hassle to setup any kind of HttpServletRequest method access.
>>>>What request/response mocks do you use for testing Struts Actions?
>>>>
>>>>Juergen
>>>>
>>>>
>>>>________________________________
>>>>
>>>>Von: spr...@li... im Auftrag von
>>>>j=FCrgen h=F6ller [werk3AT]
>>>>Gesendet: Sa 24.04.2004 10:57
>>>>An: spr...@li...
>>>>Betreff: Re: [Springframework-user] Testing Controllers and
>>>>FormControllers
>>>>
>>>>
>>>>
>>>>I don't see much difference between testing Controllers and
>>>>FormControllers: Both share the same "ModelAndView
>>>>handleRequest(HttpServletRequest, HttpServletResponse)" method that
>>>>you need to invoke for testing. As of 1.0.1, you shouldn't need a
>>>>ServletContext mock anymore (except when actually accessing the
>>>>ServletContext), so all you need are HttpServletRequest and
>>>>HttpServletResponse mocks. The mocks provided by the MockObjects
>>>>project should be fine for this.
>>>>
>>>>Juergen
>>>>
>>>>
>>>>________________________________
>>>>
>>>>Von: spr...@li... im Auftrag von
>>>>Matt Raible
>>>>Gesendet: Fr 23.04.2004 20:48
>>>>An: spr...@li...
>>>>Betreff: [Springframework-user] Testing Controllers and FormControlle=
rs
>>>>
>>>>
>>>>
>>>>I've found it pretty simple to test Controllers, but FormControllers
>>>>are
>>>>a different story.  From looking at the FormControllerTestSuite (URL
>>>>below), as well as many other Spring tests, it seems that a lot of
>>>>internal mocks are used to test this stuff.
>>>>
>>>>So my question is - what do you recommend for the average Spring MVC
>>>>person?  What is the strategy we should be using to test our
>>>>controllers?  Should we be using the Mocks that Spring provides?  Thi=
s
>>>>would certainly make things easier.  If we're supposed to do that - i=
s
>>>>it possible to get these mocks distributed in a JAR?
>>>>
>>>>Thanks,
>>>>
>>>>Matt
>>>>
>>>>http://monkeymachine.co.uk/spring/xref-test/org/springframework/web/
>>>>serv
>>>>let/mvc/FormControllerTestSuite.html
>>>>
>>>>
>>>>       =20
>>>>

Re: [Springframework-developer] Re: struts integration - alternate approach

[<jue...@we...>]

OK, I'll commit them tomorrow morning - please give them a try once =
they're in CVS, to verify that they address your needs.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Seth Ladd
Sent: Wednesday, April 28, 2004 8:05 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: struts integration -
alternate approach


j=FCrgen h=F6ller [werk3AT] wrote:
> I see.
> =20
> I wonder whether it's worth adding a DelegatingRequestProcessor and a =
DelegatingTilesRequestProcessor to our org.springframework.web.struts =
package then: That approach is mainly useful when generating =
struts-config via XDoclet, if I understand correctly. Of course, quite a =
lot of people do use Struts with XDoclet.
> =20
> What does everybody think? I've got those RequestProcessor subclasses =
lying around already; the question is whether to include them in Spring =
1.0.2. Else, I'll add them to the sandbox for the time being. Votes, =
please :-)
> =20

I definitely vote +1.  I'd love to throw away our implementation and use =

a Spring-blessed implementation.

Thanks!
Seth



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. =

Take an Oracle 10g class now, and we'll give you the exam FREE.=20
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: struts integration - alternate approach

[Seth L. <se...@eh...>]

jürgen höller [werk3AT] wrote:
> I see.
>  
> I wonder whether it's worth adding a DelegatingRequestProcessor and a DelegatingTilesRequestProcessor to our org.springframework.web.struts package then: That approach is mainly useful when generating struts-config via XDoclet, if I understand correctly. Of course, quite a lot of people do use Struts with XDoclet.
>  
> What does everybody think? I've got those RequestProcessor subclasses lying around already; the question is whether to include them in Spring 1.0.2. Else, I'll add them to the sandbox for the time being. Votes, please :-)
>  

I definitely vote +1.  I'd love to throw away our implementation and use 
a Spring-blessed implementation.

Thanks!
Seth

RE: [Springframework-developer] Testing Controllers and FormControllers

[Alef A. <al...@jt...>]

+1 on the org.springframework.mock.* packages,=20

although you loose the possibility of having access to package visible =
stuff
when not putting the mocks in the same package as the stuff they mock...

Alef


> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of j=FCrgen h=F6ller [werk3AT]
> Sent: Wednesday, April 28, 2004 2:57 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Testing Controllers and
> FormControllers
>=20
> Works nicely: spring-mock.jar is currently 26 KB, including the JNDI =
and
> the web mocks. The size of spring.jar went down from 973 KB to 956 KB,
> because of the JNDI mocks not being included there anymore.
>=20
> In total, I completely agree that a separate mock tree makes sense. =
The
> only remaining question is the package naming: I tend to prefer the
> "org.springframework.mock" subpackages, for having a clear package =
subtree
> in the "mock" directory.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of j=FCrgen h=F6ller [werk3AT]
> Sent: Wednesday, April 28, 2004 2:32 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Testing Controllers and
> FormControllers
>=20
>=20
> If we move them to a separate JAR and separate tree, the mock classes =
in
> the jndi.support package more or less have to join them for =
consistency
> reasons. I prefer the name "spring-mock.jar" to "spring-test.jar", as =
the
> latter is already used as directory name for the test suite.
>=20
> Given our decoupling from JNDI, I doubt that anyone those JNDI mocks
> anyway: They are mainly used in our framework test suite. And whoever =
uses
> them in a test suite can seamlessly adapt the package name.
>=20
> So this looks like:
>=20
> * a new "mock" directory (alongside "docs", "src", etc), containing =
the
> mock sources (without "src" subdirectory, as there is not much point =
in
> testing mocks, therefore there won't be a "test" subdirectory there)
>=20
> * a "spring-mock.jar", generated from the "mock" directory by the =
build
> script, shipped in the "dist" directory of our distribution
>=20
> The remaining question is: How to name the packages there?
> org.springframework.jndi.mock / org.springframework.web.mock or
> org.springframework.mock.jndi / org.springframework.mock.web? I guess =
the
> latter is more appropriate, given that they are in a separate source =
tree.
>=20
> As a side note: I doubt that those mocks will expand significantly, =
but I
> still see the point in keeping them in a dedicated tree.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of Rod Johnson
> Sent: Tuesday, April 27, 2004 11:13 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Re: [Springframework-user]
> Testing Controllers and FormControllers
>=20
>=20
> Thanks for the cleaning up: they needed it. However, I feel uneasy =
about
> these classes being included in spring.jar. I would like to see them =
in a
> spring-test.jar.
>=20
> I don't particularly object to them going in the main /src tree, =
although
> I'd really prefer a dedicated tree there as well. I'm sure that other
> stuff
> will join them in such a new tree.
>=20
> Rgds,
> Rod
>=20
> ----- Original Message -----
> From: "Colin Sampaleanu" <col...@ex...>
> To: <spr...@li...>
> Cc: <spr...@li...>
> Sent: Tuesday, April 27, 2004 9:30 PM
> Subject: Re: [Springframework-developer] Re: [Springframework-user]
> Testing
> Controllers and FormControllers
>=20
>=20
> I'm ok with including these in Spring; if people feel they are too =
big,
> they could be a spring-test add-on jar, that's not even included in =
the
> main spring.jar which normally included all the optional stuff. That
> makes some sense since this is for testing.
>=20
> j=FCrgen h=F6ller [werk3AT] wrote:
>=20
> >Matt, everybody,
> >
> >Essentially, the Servlet API mocks in Spring's test directory are =
just
> there because the MockObjects (http://www.mockobjects.com) Servlet API
> mocks
> are so inconvenient to use. The current Spring-provided Servlet API =
mocks
> are by no means in a polished state, though: They're just good enough =
for
> being used within the framework test suite. They'd need some serious
> refinement for making them public - after all, we have a reputation to
> lose
> :-)
> >
> >So on that occasion, I've reworked those mocks today, making them
> significantly more complete than before, and ready for getting =
included in
> the Spring distribution. The question is: Where to include them? I'd =
like
> to
> include them in the main Spring sources, in a =
org.springframework.web.mock
> package: They would naturally be part of spring.jar and spring-web.jar
> then.
> The test directory (where they currently reside) is no appropriate =
place,
> as
> it is about testing the framework rather than providing infrastructure
> classes.
> >
> >While it isn't in general appropriate to include mocks in the main =
Spring
> codebase, I guess this is a different case: Those mocks are =
specifically
> provided to ease testing of Spring web contexts (like
> XmlWebApplicationContext or StaticWebApplicationContext that need a
> ServletContext) and controllers (the Controller.handleRequest method =
needs
> an HttpServletRequest and an HttpServletResponse). Including them in =
the
> standard distribution would also indicate our strong focus on =
testability.
> >
> >The new MockServletContext implementation uses the
> org.springframework.core.io.Resource API for resource loading, to =
allow
> for
> ServletContext.getResourceAsStream from any resource base. So partly, =
the
> mock implementations depend on low-level Spring API. We could of =
course
> keep
> the mocks in a separate part of the Spring CVS, but it's just about a
> couple
> of classes, thus hardly worth a separate source tree.
> >
> >IMO, the main concern regarding additions to the main Spring codebase =
is
> whether those additions can potentially grow significantly: While =
Keith's
> rules API in the sandbox has definite potential there (so had Ben =
Alex'
> security framework that became the Acegi Security System), the recent
> Struts
> support classes and those Servlet API mocks will at best see slight
> refinements but certainly not exponential growth. So the former seems =
like
> a
> candidate for a separate module to me, while the latter should fit =
into
> the
> main Spring codebase.
> >
> >An important point to consider is that there are simply no mocks
> necessary
> for testing most parts of a typical Spring app, respectively just
> interfaces
> that can conveniently be mocked in a dynamic fashion with EasyMock. =
There
> are just two exceptions, as far I see: Our SimpleNamingContext stuff =
eases
> custom JNDI environments, and the newly refined set of Servlet API =
mocks
> allows for convenient testing of Spring web MVC (and web contexts).
> >
> >Mocking an EJB container is next to impossible, so that's not worth
> further
> consideration. JDBC can quite nicely be mocked with EasyMock; it's
> preferable to use the JdbcOperations interface as far as possible, =
though.
> Same for a Hibernate Session, with HibernateOperations being =
preferable.
> It's more or less just the Servlet API that's really tedious to mock =
with
> EasyMock, due to all those interdependent methods (e.g. URL paths,
> parameters, attributes).
> >
> >What does everybody think? Does anyone mind including those polished
> Servlet API mocks in the main Spring codebase, already for 1.0.2? Any
> suggestions for alternatives?
> >
> >Juergen
> >
> >
> >-----Original Message-----
> >From: spr...@li...
> >[mailto:spr...@li...]On Behalf Of
> >Matt Raible
> >Sent: Saturday, April 24, 2004 2:02 PM
> >To: spr...@li...
> >Subject: Re: [Springframework-user] Testing Controllers and
> >FormControllers
> >
> >
> >I use StrutsTestCase (http://strutstestcase.sf.net), which allows you
> >to write very little code to test an Action.  Here is a simple =
example
> >of testing an "execute" method:
> >
> >package org.appfuse.webapp.action;
> >
> >import servletunit.struts.CactusStrutsTestCase;
> >import org.appfuse.Constants;
> >
> >public class PersonActionTest extends CactusStrutsTestCase {
> >
> >    public PersonActionTest(String name) {
> >        super(name);
> >    }
> >
> >    public void testExecute() {
> >        // test execute method
> >        setRequestPathInfo("/editPerson");
> >        addRequestParameter("id", "1");
> >        actionPerform();
> >        verifyNoActionErrors();
> >         =
assertNotNull(getRequest().getAttribute(Constants.PERSON_KEY));
> >     }
> >
> >     public static void main(String[] args) {
> >         junit.textui.TestRunner.run(PersonActionTest.class);
> >     }
> >}
> >
> >Since CactusStrutsTestCase extends from Cactus, I can also use =
Cactus's
> >FormAuthentication support to mimic container-managed authentication.
> >
> >To test a "Save" is also pretty simple.
> >
> >     public void testSave() throws Exception {
> >         setRequestPathInfo("/editPerson");
> >         addRequestParameter("action", "Edit");
> >         addRequestParameter("id", "1");
> >
> >         actionPerform();
> >
> >         assertTrue(getRequest().getAttribute(Constants.PERSON_KEY) =
!=3D
> >null);
> >
> >         setRequestPathInfo("/savePerson");
> >         addRequestParameter("action", "Save");
> >         actionPerform();
> >         verifyForward("edit");
> >         verifyNoActionErrors();
> >     }
> >
> >I think you have something similar to this with the Mock Object =
you're
> >using in Spring.  It just needs to be packaged up as a JAR.  I'll be
> >more than happy to write up some documentation on how to use it.
> >
> >Matt
> >
> >
> >On Apr 24, 2004, at 4:27 AM, j=FCrgen h=F6ller [werk3AT] wrote:
> >
> >
> >
> >>Matt,
> >>
> >>I just tried using MockHttpServletRequest and =
MockHttpServletResponse
> >>from MockObjects with a Spring FormController. Unfortunately, those
> >>MockObjects mocks are really not well-suited for testing here, as =
it's
> >>so much hassle to setup any kind of HttpServletRequest method =
access.
> >>What request/response mocks do you use for testing Struts Actions?
> >>
> >>Juergen
> >>
> >>
> >>________________________________
> >>
> >>Von: spr...@li... im Auftrag von
> >>j=FCrgen h=F6ller [werk3AT]
> >>Gesendet: Sa 24.04.2004 10:57
> >>An: spr...@li...
> >>Betreff: Re: [Springframework-user] Testing Controllers and
> >>FormControllers
> >>
> >>
> >>
> >>I don't see much difference between testing Controllers and
> >>FormControllers: Both share the same "ModelAndView
> >>handleRequest(HttpServletRequest, HttpServletResponse)" method that
> >>you need to invoke for testing. As of 1.0.1, you shouldn't need a
> >>ServletContext mock anymore (except when actually accessing the
> >>ServletContext), so all you need are HttpServletRequest and
> >>HttpServletResponse mocks. The mocks provided by the MockObjects
> >>project should be fine for this.
> >>
> >>Juergen
> >>
> >>
> >>________________________________
> >>
> >>Von: spr...@li... im Auftrag von
> >>Matt Raible
> >>Gesendet: Fr 23.04.2004 20:48
> >>An: spr...@li...
> >>Betreff: [Springframework-user] Testing Controllers and =
FormControllers
> >>
> >>
> >>
> >>I've found it pretty simple to test Controllers, but FormControllers
> >>are
> >>a different story.  From looking at the FormControllerTestSuite (URL
> >>below), as well as many other Spring tests, it seems that a lot of
> >>internal mocks are used to test this stuff.
> >>
> >>So my question is - what do you recommend for the average Spring MVC
> >>person?  What is the strategy we should be using to test our
> >>controllers?  Should we be using the Mocks that Spring provides?  =
This
> >>would certainly make things easier.  If we're supposed to do that - =
is
> >>it possible to get these mocks distributed in a JAR?
> >>
> >>Thanks,
> >>
> >>Matt
> >>
> >>http://monkeymachine.co.uk/spring/xref-test/org/springframework/web/
> >>serv
> >>let/mvc/FormControllerTestSuite.html
> >>
> >>
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Auto-wiring by type - too many instances when proxying?

[Rod J. <rod...@in...>]

>That's indeed a fairly typical scenario. I've considered 
this repeatedly, but haven't come to any conclusion 
yet. "Hiding" certain beans in a generic fashion is not as 
simple as it might seem: After all, at least the 
transactional proxy needs to reference its target, so the 
target can't be completely hidden.

Indeed it isn't simple. I've also thought about this. 

>Note that when auto-proxying targets, for example with 
BeanNameAutoProxyCreator, there's just one visible bean: The 
target automatically gets wrapped with a proxy. However, this 
is just appropriate for transaction demarcation if all your 
targets stick to the same method naming pattern; else, all 
those different transaction attributes in a single 
TransactionAttributeSource will get messy.
This is where attribute-driven transactions (with the advisor 
auto proxy creator) are attractive. The problem right now is 
that that means Commons Attributes slightly complicating the 
build process. JSR-175 will solve that one eventually, but of 
course it's too early to migrate most projects to 1.5 beta.

I want to do a JSR-175 preview integration with Spring, 
focused on attribute-driven transactions, as soon as I get 
time. (It's not a big piece of work.)

Rgds,
Rod

Re: [Springframework-developer] Auto-wiring by type - too many instances when proxying?

[<jue...@we...>]

Hi Mike,

That's indeed a fairly typical scenario. I've considered this =
repeatedly, but haven't come to any conclusion yet. "Hiding" certain =
beans in a generic fashion is not as simple as it might seem: After all, =
at least the transactional proxy needs to reference its target, so the =
target can't be completely hidden.

When autowiring bean properties, you could use AUTOWIRE_BY_NAME as =
alternative - matching a "spaceManager" property to a "spaceManager" =
bean. However, with constructors, autowiring constructor arguments by =
type remains the only option.

Note that when auto-proxying targets, for example with =
BeanNameAutoProxyCreator, there's just one visible bean: The target =
automatically gets wrapped with a proxy. However, this is just =
appropriate for transaction demarcation if all your targets stick to the =
same method naming pattern; else, all those different transaction =
attributes in a single TransactionAttributeSource will get messy.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Mike Cannon-Brookes
Sent: Wednesday, April 28, 2004 4:43 PM
To: <spr...@li...>
<spr...@li...>
Subject: [Springframework-developer] Auto-wiring by type - too many
instances when proxying?


Hey guys,

Just wondering how you get around this scenario.

We were playing around with autowiring today, specifically using the=20
ListableBeanFactory.autowire(Class,=20
AutowiringBeanFactory.AUTOWIRE_CONSTRUCTOR, false) method.

Now the problem is that if I have two beans of effectively the same=20
type (say SpaceManager) - the autowiring no longer works.

The reason we have two beans implementing SpaceManager interface is=20
that there's an implementation defined with all it's properties=20
('spaceManagerTarget') and then a transaction proxy factory bean=20
wrapping the impl with transaction attributes ('spaceManager'). I think=20
this is a fairly standard type of scenario.

However both are exposing the SpaceManager interface, hence the auto=20
wiring fails.

What to do? Has anyone else faced this problem?

I never access the 'spaceManagerTarget' from within my application, is=20
it possible to 'hide' this instance somehow?

Cheers,
Mike

--
ATLASSIAN - http://www.atlassian.com/

Confluence - the professional J2EE wiki - tried it yet?
http://www.atlassian.com/confluence/



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. =

Take an Oracle 10g class now, and we'll give you the exam FREE.=20
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Auto-wiring by type - too many instances when proxying?

[Jozsa K. <dy...@on...>]

On Thu, Apr 29, 2004 at 12:42:58AM +1000, Mike Cannon-Brookes wrote:
> Hey guys,
> 
> Just wondering how you get around this scenario.
> 
> We were playing around with autowiring today, specifically using the 
> ListableBeanFactory.autowire(Class, 
> AutowiringBeanFactory.AUTOWIRE_CONSTRUCTOR, false) method.
> 
> Now the problem is that if I have two beans of effectively the same 
> type (say SpaceManager) - the autowiring no longer works.
> 
> The reason we have two beans implementing SpaceManager interface is 
> that there's an implementation defined with all it's properties 
> ('spaceManagerTarget') and then a transaction proxy factory bean 
> wrapping the impl with transaction attributes ('spaceManager'). I think 
> this is a fairly standard type of scenario.
> 
> However both are exposing the SpaceManager interface, hence the auto 
> wiring fails.
> 
> What to do? Has anyone else faced this problem?
> 
> I never access the 'spaceManagerTarget' from within my application, is 
> it possible to 'hide' this instance somehow?

Mike, 

cant you use autoproxy for your AOP scenario?

dyn
-- 
.Digital.Yearning.for.Networked.Assassination.and.Xenocide

[Springframework-developer] PropertyValue cvs patch

[Les A. H. <le...@ha...>]

All,

I've created an issue for a patch of the PropertyValue class:

http://opensource.atlassian.com/projects/spring/browse/SPR-108

For some reason, I can't find how to attach a file to a Jira issue, so I've sent
it to this list for convenience (as opposed to copying-n-pasting from the issue
into your own local file).

Anyone see any problems with this?

Thanks,

Les

[Springframework-developer] Auto-wiring by type - too many instances when proxying?

[Mike Cannon-B. <mi...@at...>]

Hey guys,

Just wondering how you get around this scenario.

We were playing around with autowiring today, specifically using the 
ListableBeanFactory.autowire(Class, 
AutowiringBeanFactory.AUTOWIRE_CONSTRUCTOR, false) method.

Now the problem is that if I have two beans of effectively the same 
type (say SpaceManager) - the autowiring no longer works.

The reason we have two beans implementing SpaceManager interface is 
that there's an implementation defined with all it's properties 
('spaceManagerTarget') and then a transaction proxy factory bean 
wrapping the impl with transaction attributes ('spaceManager'). I think 
this is a fairly standard type of scenario.

However both are exposing the SpaceManager interface, hence the auto 
wiring fails.

What to do? Has anyone else faced this problem?

I never access the 'spaceManagerTarget' from within my application, is 
it possible to 'hide' this instance somehow?

Cheers,
Mike

--
ATLASSIAN - http://www.atlassian.com/

Confluence - the professional J2EE wiki - tried it yet?
http://www.atlassian.com/confluence/

Re: [Springframework-developer] Building Spring tidbit...

[Rod J. <rod...@in...>]

Even better: you should be able to run all the unit tests in 
a couple of minutes. If you run them inside Eclipse, which 
keeps the JVM up, it takes under a minute.

So many projects I see have ridiculously slow build/test 
cycles. 8 minutes is fast compared to a lot I've seen. I'm 
more and more convinced that speed of build and test cycles 
is critical to productivity. With "traditional" J2EE 
architecture it's always slow and usually involves deploying 
to a container. With a lightweight solution such as Spring 
the productivity benefit can be huge.

---- Original message ----
>Date: Wed, 28 Apr 2004 09:23:32 -0400
>From: "Les A. Hazlewood" <le...@ha...>  
>Subject: [Springframework-developer] Building Spring 
tidbit...  
>To: spr...@li...
>
>I did a cvs checkout and did a complete build.
>
>On my year-old computer, it took just 19 seconds.
>
>I compare this to our enterprise product's 8 minute, 11 
second build (XDoclet's
>running time sucks our life dry, lol).
>
>What a breath of fresh air!!!
>
>Les
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... 
Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam 
FREE. 
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-
developer

RE: [Springframework-developer] Petclinic Demo with mysql

[Tom K <tk...@co...>]

Thanks Juergen,

	I was getting a bit frustrated with Petclinc although it forced
me to do some book learning :-) It's probability be a good idea to
update the sample directory with the newer Connector/J 3.x for
Petclinic.

Tom K.


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Wednesday, April 28, 2004 12:31 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Petclinic Demo with mysql

I assume you're running the Hibernate version: As of release 2.1.2,
Hibernate requires a JDBC 3.0 driver when running on J2SE 1.4, because
it auto-detects the capability for auto-generated keys - in the JDBC
interfaces, not in the driver implementation. So you need to use MySQL
Connector/J 3.x on J2SE 1.4, else you'll end up with an error that the
driver doesn't implement that particular method (like you did). On J2SE
1.3, MySQL Connector/J 2.x is fine.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag
von Tom K
Gesendet: Mi 28.04.2004 06:26
An: spr...@li...
Betreff: [Springframework-developer] Petclinic Demo with mysql


I'm "trying" to get the petclinic demo to work with mySQL. I can do
selects and updates but when I try to do an insert I get the error:
=20
java.lang.AbstractMethodError:
com.mysql.jdbc.jdbc2.Connection.prepareStatement(Ljava/lang/String;I)Lja
va/sql/PreparedStatement;
=20
After hours of studying the documentation, I don't have a clue where my
problem is.
=20
Any ideas what might be wrong?
=20
TIA
=20
Tom K.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.557 / Virus Database: 349 - Release Date: 12/30/2003



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.

Take an Oracle 10g class now, and we'll give you the exam FREE.=20
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.557 / Virus Database: 349 - Release Date: 12/30/2003
=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.557 / Virus Database: 349 - Release Date: 12/30/2003
=20

Re: [Springframework-developer] Testing Controllers and FormControllers

[Colin S. <col...@ex...>]

+1 on org.springframework.mock

j=FCrgen h=F6ller [werk3AT] wrote:

>Works nicely: spring-mock.jar is currently 26 KB, including the JNDI and=
 the web mocks. The size of spring.jar went down from 973 KB to 956 KB, b=
ecause of the JNDI mocks not being included there anymore.
>
>In total, I completely agree that a separate mock tree makes sense. The =
only remaining question is the package naming: I tend to prefer the "org.=
springframework.mock" subpackages, for having a clear package subtree in =
the "mock" directory.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of j=FCrgen h=F6ller [werk3AT]
>Sent: Wednesday, April 28, 2004 2:32 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Testing Controllers and
>FormControllers
>
>
>If we move them to a separate JAR and separate tree, the mock classes in=
 the jndi.support package more or less have to join them for consistency =
reasons. I prefer the name "spring-mock.jar" to "spring-test.jar", as the=
 latter is already used as directory name for the test suite.
>
>Given our decoupling from JNDI, I doubt that anyone those JNDI mocks any=
way: They are mainly used in our framework test suite. And whoever uses t=
hem in a test suite can seamlessly adapt the package name.
>
>So this looks like:
>
>* a new "mock" directory (alongside "docs", "src", etc), containing the =
mock sources (without "src" subdirectory, as there is not much point in t=
esting mocks, therefore there won't be a "test" subdirectory there)
>
>* a "spring-mock.jar", generated from the "mock" directory by the build =
script, shipped in the "dist" directory of our distribution
>
>The remaining question is: How to name the packages there? org.springfra=
mework.jndi.mock / org.springframework.web.mock or org.springframework.mo=
ck.jndi / org.springframework.mock.web? I guess the latter is more approp=
riate, given that they are in a separate source tree.
>
>As a side note: I doubt that those mocks will expand significantly, but =
I still see the point in keeping them in a dedicated tree.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Rod Johnson
>Sent: Tuesday, April 27, 2004 11:13 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Re: [Springframework-user]
>Testing Controllers and FormControllers
>
>
>Thanks for the cleaning up: they needed it. However, I feel uneasy about
>these classes being included in spring.jar. I would like to see them in =
a
>spring-test.jar.
>
>I don't particularly object to them going in the main /src tree, althoug=
h
>I'd really prefer a dedicated tree there as well. I'm sure that other st=
uff
>will join them in such a new tree.
>
>Rgds,
>Rod
>
>----- Original Message -----
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Cc: <spr...@li...>
>Sent: Tuesday, April 27, 2004 9:30 PM
>Subject: Re: [Springframework-developer] Re: [Springframework-user] Test=
ing
>Controllers and FormControllers
>
>
>I'm ok with including these in Spring; if people feel they are too big,
>they could be a spring-test add-on jar, that's not even included in the
>main spring.jar which normally included all the optional stuff. That
>makes some sense since this is for testing.
>
>j=FCrgen h=F6ller [werk3AT] wrote:
>
> =20
>
>>Matt, everybody,
>>
>>Essentially, the Servlet API mocks in Spring's test directory are just
>>   =20
>>
>there because the MockObjects (http://www.mockobjects.com) Servlet API m=
ocks
>are so inconvenient to use. The current Spring-provided Servlet API mock=
s
>are by no means in a polished state, though: They're just good enough fo=
r
>being used within the framework test suite. They'd need some serious
>refinement for making them public - after all, we have a reputation to l=
ose
>:-)
> =20
>
>>So on that occasion, I've reworked those mocks today, making them
>>   =20
>>
>significantly more complete than before, and ready for getting included =
in
>the Spring distribution. The question is: Where to include them? I'd lik=
e to
>include them in the main Spring sources, in a org.springframework.web.mo=
ck
>package: They would naturally be part of spring.jar and spring-web.jar t=
hen.
>The test directory (where they currently reside) is no appropriate place=
, as
>it is about testing the framework rather than providing infrastructure
>classes.
> =20
>
>>While it isn't in general appropriate to include mocks in the main Spri=
ng
>>   =20
>>
>codebase, I guess this is a different case: Those mocks are specifically
>provided to ease testing of Spring web contexts (like
>XmlWebApplicationContext or StaticWebApplicationContext that need a
>ServletContext) and controllers (the Controller.handleRequest method nee=
ds
>an HttpServletRequest and an HttpServletResponse). Including them in the
>standard distribution would also indicate our strong focus on testabilit=
y.
> =20
>
>>The new MockServletContext implementation uses the
>>   =20
>>
>org.springframework.core.io.Resource API for resource loading, to allow =
for
>ServletContext.getResourceAsStream from any resource base. So partly, th=
e
>mock implementations depend on low-level Spring API. We could of course =
keep
>the mocks in a separate part of the Spring CVS, but it's just about a co=
uple
>of classes, thus hardly worth a separate source tree.
> =20
>
>>IMO, the main concern regarding additions to the main Spring codebase i=
s
>>   =20
>>
>whether those additions can potentially grow significantly: While Keith'=
s
>rules API in the sandbox has definite potential there (so had Ben Alex'
>security framework that became the Acegi Security System), the recent St=
ruts
>support classes and those Servlet API mocks will at best see slight
>refinements but certainly not exponential growth. So the former seems li=
ke a
>candidate for a separate module to me, while the latter should fit into =
the
>main Spring codebase.
> =20
>
>>An important point to consider is that there are simply no mocks necess=
ary
>>   =20
>>
>for testing most parts of a typical Spring app, respectively just interf=
aces
>that can conveniently be mocked in a dynamic fashion with EasyMock. Ther=
e
>are just two exceptions, as far I see: Our SimpleNamingContext stuff eas=
es
>custom JNDI environments, and the newly refined set of Servlet API mocks
>allows for convenient testing of Spring web MVC (and web contexts).
> =20
>
>>Mocking an EJB container is next to impossible, so that's not worth fur=
ther
>>   =20
>>
>consideration. JDBC can quite nicely be mocked with EasyMock; it's
>preferable to use the JdbcOperations interface as far as possible, thoug=
h.
>Same for a Hibernate Session, with HibernateOperations being preferable.
>It's more or less just the Servlet API that's really tedious to mock wit=
h
>EasyMock, due to all those interdependent methods (e.g. URL paths,
>parameters, attributes).
> =20
>
>>What does everybody think? Does anyone mind including those polished
>>   =20
>>
>Servlet API mocks in the main Spring codebase, already for 1.0.2? Any
>suggestions for alternatives?
> =20
>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf Of
>>Matt Raible
>>Sent: Saturday, April 24, 2004 2:02 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-user] Testing Controllers and
>>FormControllers
>>
>>
>>I use StrutsTestCase (http://strutstestcase.sf.net), which allows you
>>to write very little code to test an Action.  Here is a simple example
>>of testing an "execute" method:
>>
>>package org.appfuse.webapp.action;
>>
>>import servletunit.struts.CactusStrutsTestCase;
>>import org.appfuse.Constants;
>>
>>public class PersonActionTest extends CactusStrutsTestCase {
>>
>>   public PersonActionTest(String name) {
>>       super(name);
>>   }
>>
>>   public void testExecute() {
>>       // test execute method
>>       setRequestPathInfo("/editPerson");
>>       addRequestParameter("id", "1");
>>       actionPerform();
>>       verifyNoActionErrors();
>>        assertNotNull(getRequest().getAttribute(Constants.PERSON_KEY));
>>    }
>>
>>    public static void main(String[] args) {
>>        junit.textui.TestRunner.run(PersonActionTest.class);
>>    }
>>}
>>
>>Since CactusStrutsTestCase extends from Cactus, I can also use Cactus's
>>FormAuthentication support to mimic container-managed authentication.
>>
>>To test a "Save" is also pretty simple.
>>
>>    public void testSave() throws Exception {
>>        setRequestPathInfo("/editPerson");
>>        addRequestParameter("action", "Edit");
>>        addRequestParameter("id", "1");
>>
>>        actionPerform();
>>
>>        assertTrue(getRequest().getAttribute(Constants.PERSON_KEY) !=3D
>>null);
>>
>>        setRequestPathInfo("/savePerson");
>>        addRequestParameter("action", "Save");
>>        actionPerform();
>>        verifyForward("edit");
>>        verifyNoActionErrors();
>>    }
>>
>>I think you have something similar to this with the Mock Object you're
>>using in Spring.  It just needs to be packaged up as a JAR.  I'll be
>>more than happy to write up some documentation on how to use it.
>>
>>Matt
>>
>>
>>On Apr 24, 2004, at 4:27 AM, j=FCrgen h=F6ller [werk3AT] wrote:
>>
>>
>>
>>   =20
>>
>>>Matt,
>>>
>>>I just tried using MockHttpServletRequest and MockHttpServletResponse
>>>     =20
>>>
>>>from MockObjects with a Spring FormController. Unfortunately, those
>>   =20
>>
>>>MockObjects mocks are really not well-suited for testing here, as it's
>>>so much hassle to setup any kind of HttpServletRequest method access.
>>>What request/response mocks do you use for testing Struts Actions?
>>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: spr...@li... im Auftrag von
>>>j=FCrgen h=F6ller [werk3AT]
>>>Gesendet: Sa 24.04.2004 10:57
>>>An: spr...@li...
>>>Betreff: Re: [Springframework-user] Testing Controllers and
>>>FormControllers
>>>
>>>
>>>
>>>I don't see much difference between testing Controllers and
>>>FormControllers: Both share the same "ModelAndView
>>>handleRequest(HttpServletRequest, HttpServletResponse)" method that
>>>you need to invoke for testing. As of 1.0.1, you shouldn't need a
>>>ServletContext mock anymore (except when actually accessing the
>>>ServletContext), so all you need are HttpServletRequest and
>>>HttpServletResponse mocks. The mocks provided by the MockObjects
>>>project should be fine for this.
>>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: spr...@li... im Auftrag von
>>>Matt Raible
>>>Gesendet: Fr 23.04.2004 20:48
>>>An: spr...@li...
>>>Betreff: [Springframework-user] Testing Controllers and FormController=
s
>>>
>>>
>>>
>>>I've found it pretty simple to test Controllers, but FormControllers
>>>are
>>>a different story.  From looking at the FormControllerTestSuite (URL
>>>below), as well as many other Spring tests, it seems that a lot of
>>>internal mocks are used to test this stuff.
>>>
>>>So my question is - what do you recommend for the average Spring MVC
>>>person?  What is the strategy we should be using to test our
>>>controllers?  Should we be using the Mocks that Spring provides?  This
>>>would certainly make things easier.  If we're supposed to do that - is
>>>it possible to get these mocks distributed in a JAR?
>>>
>>>Thanks,
>>>
>>>Matt
>>>
>>>http://monkeymachine.co.uk/spring/xref-test/org/springframework/web/
>>>serv
>>>let/mvc/FormControllerTestSuite.html
>>>     =20
>>>

Re: [Springframework-developer] Testing Controllers and FormControllers

[Thomas R. <tho...@tr...>]

+1: spring-mock.jar
+1: separate mock tree
+1: org.springframework.mock.* subpackages

Thomas



jürgen höller [werk3AT] wrote:

>Works nicely: spring-mock.jar is currently 26 KB, including the JNDI and the web mocks. The size of spring.jar went down from 973 KB to 956 KB, because of the JNDI mocks not being included there anymore.
>
>In total, I completely agree that a separate mock tree makes sense. The only remaining question is the package naming: I tend to prefer the "org.springframework.mock" subpackages, for having a clear package subtree in the "mock" directory.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of jürgen höller [werk3AT]
>Sent: Wednesday, April 28, 2004 2:32 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Testing Controllers and
>FormControllers
>
>
>If we move them to a separate JAR and separate tree, the mock classes in the jndi.support package more or less have to join them for consistency reasons. I prefer the name "spring-mock.jar" to "spring-test.jar", as the latter is already used as directory name for the test suite.
>
>Given our decoupling from JNDI, I doubt that anyone those JNDI mocks anyway: They are mainly used in our framework test suite. And whoever uses them in a test suite can seamlessly adapt the package name.
>
>So this looks like:
>
>* a new "mock" directory (alongside "docs", "src", etc), containing the mock sources (without "src" subdirectory, as there is not much point in testing mocks, therefore there won't be a "test" subdirectory there)
>
>* a "spring-mock.jar", generated from the "mock" directory by the build script, shipped in the "dist" directory of our distribution
>
>The remaining question is: How to name the packages there? org.springframework.jndi.mock / org.springframework.web.mock or org.springframework.mock.jndi / org.springframework.mock.web? I guess the latter is more appropriate, given that they are in a separate source tree.
>
>As a side note: I doubt that those mocks will expand significantly, but I still see the point in keeping them in a dedicated tree.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Rod Johnson
>Sent: Tuesday, April 27, 2004 11:13 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Re: [Springframework-user]
>Testing Controllers and FormControllers
>
>
>Thanks for the cleaning up: they needed it. However, I feel uneasy about
>these classes being included in spring.jar. I would like to see them in a
>spring-test.jar.
>
>I don't particularly object to them going in the main /src tree, although
>I'd really prefer a dedicated tree there as well. I'm sure that other stuff
>will join them in such a new tree.
>
>Rgds,
>Rod
>
>----- Original Message -----
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Cc: <spr...@li...>
>Sent: Tuesday, April 27, 2004 9:30 PM
>Subject: Re: [Springframework-developer] Re: [Springframework-user] Testing
>Controllers and FormControllers
>
>
>I'm ok with including these in Spring; if people feel they are too big,
>they could be a spring-test add-on jar, that's not even included in the
>main spring.jar which normally included all the optional stuff. That
>makes some sense since this is for testing.
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>Matt, everybody,
>>
>>Essentially, the Servlet API mocks in Spring's test directory are just
>>    
>>
>there because the MockObjects (http://www.mockobjects.com) Servlet API mocks
>are so inconvenient to use. The current Spring-provided Servlet API mocks
>are by no means in a polished state, though: They're just good enough for
>being used within the framework test suite. They'd need some serious
>refinement for making them public - after all, we have a reputation to lose
>:-)
>  
>
>>So on that occasion, I've reworked those mocks today, making them
>>    
>>
>significantly more complete than before, and ready for getting included in
>the Spring distribution. The question is: Where to include them? I'd like to
>include them in the main Spring sources, in a org.springframework.web.mock
>package: They would naturally be part of spring.jar and spring-web.jar then.
>The test directory (where they currently reside) is no appropriate place, as
>it is about testing the framework rather than providing infrastructure
>classes.
>  
>
>>While it isn't in general appropriate to include mocks in the main Spring
>>    
>>
>codebase, I guess this is a different case: Those mocks are specifically
>provided to ease testing of Spring web contexts (like
>XmlWebApplicationContext or StaticWebApplicationContext that need a
>ServletContext) and controllers (the Controller.handleRequest method needs
>an HttpServletRequest and an HttpServletResponse). Including them in the
>standard distribution would also indicate our strong focus on testability.
>  
>
>>The new MockServletContext implementation uses the
>>    
>>
>org.springframework.core.io.Resource API for resource loading, to allow for
>ServletContext.getResourceAsStream from any resource base. So partly, the
>mock implementations depend on low-level Spring API. We could of course keep
>the mocks in a separate part of the Spring CVS, but it's just about a couple
>of classes, thus hardly worth a separate source tree.
>  
>
>>IMO, the main concern regarding additions to the main Spring codebase is
>>    
>>
>whether those additions can potentially grow significantly: While Keith's
>rules API in the sandbox has definite potential there (so had Ben Alex'
>security framework that became the Acegi Security System), the recent Struts
>support classes and those Servlet API mocks will at best see slight
>refinements but certainly not exponential growth. So the former seems like a
>candidate for a separate module to me, while the latter should fit into the
>main Spring codebase.
>  
>
>>An important point to consider is that there are simply no mocks necessary
>>    
>>
>for testing most parts of a typical Spring app, respectively just interfaces
>that can conveniently be mocked in a dynamic fashion with EasyMock. There
>are just two exceptions, as far I see: Our SimpleNamingContext stuff eases
>custom JNDI environments, and the newly refined set of Servlet API mocks
>allows for convenient testing of Spring web MVC (and web contexts).
>  
>
>>Mocking an EJB container is next to impossible, so that's not worth further
>>    
>>
>consideration. JDBC can quite nicely be mocked with EasyMock; it's
>preferable to use the JdbcOperations interface as far as possible, though.
>Same for a Hibernate Session, with HibernateOperations being preferable.
>It's more or less just the Servlet API that's really tedious to mock with
>EasyMock, due to all those interdependent methods (e.g. URL paths,
>parameters, attributes).
>  
>
>>What does everybody think? Does anyone mind including those polished
>>    
>>
>Servlet API mocks in the main Spring codebase, already for 1.0.2? Any
>suggestions for alternatives?
>  
>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf Of
>>Matt Raible
>>Sent: Saturday, April 24, 2004 2:02 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-user] Testing Controllers and
>>FormControllers
>>
>>
>>I use StrutsTestCase (http://strutstestcase.sf.net), which allows you
>>to write very little code to test an Action.  Here is a simple example
>>of testing an "execute" method:
>>
>>package org.appfuse.webapp.action;
>>
>>import servletunit.struts.CactusStrutsTestCase;
>>import org.appfuse.Constants;
>>
>>public class PersonActionTest extends CactusStrutsTestCase {
>>
>>   public PersonActionTest(String name) {
>>       super(name);
>>   }
>>
>>   public void testExecute() {
>>       // test execute method
>>       setRequestPathInfo("/editPerson");
>>       addRequestParameter("id", "1");
>>       actionPerform();
>>       verifyNoActionErrors();
>>        assertNotNull(getRequest().getAttribute(Constants.PERSON_KEY));
>>    }
>>
>>    public static void main(String[] args) {
>>        junit.textui.TestRunner.run(PersonActionTest.class);
>>    }
>>}
>>
>>Since CactusStrutsTestCase extends from Cactus, I can also use Cactus's
>>FormAuthentication support to mimic container-managed authentication.
>>
>>To test a "Save" is also pretty simple.
>>
>>    public void testSave() throws Exception {
>>        setRequestPathInfo("/editPerson");
>>        addRequestParameter("action", "Edit");
>>        addRequestParameter("id", "1");
>>
>>        actionPerform();
>>
>>        assertTrue(getRequest().getAttribute(Constants.PERSON_KEY) !=
>>null);
>>
>>        setRequestPathInfo("/savePerson");
>>        addRequestParameter("action", "Save");
>>        actionPerform();
>>        verifyForward("edit");
>>        verifyNoActionErrors();
>>    }
>>
>>I think you have something similar to this with the Mock Object you're
>>using in Spring.  It just needs to be packaged up as a JAR.  I'll be
>>more than happy to write up some documentation on how to use it.
>>
>>Matt
>>
>>
>>On Apr 24, 2004, at 4:27 AM, jürgen höller [werk3AT] wrote:
>>
>>
>>
>>    
>>
>>>Matt,
>>>
>>>I just tried using MockHttpServletRequest and MockHttpServletResponse
>>>      
>>>
>>>from MockObjects with a Spring FormController. Unfortunately, those
>>    
>>
>>>MockObjects mocks are really not well-suited for testing here, as it's
>>>so much hassle to setup any kind of HttpServletRequest method access.
>>>What request/response mocks do you use for testing Struts Actions?
>>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: spr...@li... im Auftrag von
>>>jürgen höller [werk3AT]
>>>Gesendet: Sa 24.04.2004 10:57
>>>An: spr...@li...
>>>Betreff: Re: [Springframework-user] Testing Controllers and
>>>FormControllers
>>>
>>>
>>>
>>>I don't see much difference between testing Controllers and
>>>FormControllers: Both share the same "ModelAndView
>>>handleRequest(HttpServletRequest, HttpServletResponse)" method that
>>>you need to invoke for testing. As of 1.0.1, you shouldn't need a
>>>ServletContext mock anymore (except when actually accessing the
>>>ServletContext), so all you need are HttpServletRequest and
>>>HttpServletResponse mocks. The mocks provided by the MockObjects
>>>project should be fine for this.
>>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: spr...@li... im Auftrag von
>>>Matt Raible
>>>Gesendet: Fr 23.04.2004 20:48
>>>An: spr...@li...
>>>Betreff: [Springframework-user] Testing Controllers and FormControllers
>>>
>>>
>>>
>>>I've found it pretty simple to test Controllers, but FormControllers
>>>are
>>>a different story.  From looking at the FormControllerTestSuite (URL
>>>below), as well as many other Spring tests, it seems that a lot of
>>>internal mocks are used to test this stuff.
>>>
>>>So my question is - what do you recommend for the average Spring MVC
>>>person?  What is the strategy we should be using to test our
>>>controllers?  Should we be using the Mocks that Spring provides?  This
>>>would certainly make things easier.  If we're supposed to do that - is
>>>it possible to get these mocks distributed in a JAR?
>>>
>>>Thanks,
>>>
>>>Matt
>>>
>>>http://monkeymachine.co.uk/spring/xref-test/org/springframework/web/
>>>serv
>>>let/mvc/FormControllerTestSuite.html
>>>
>>>
>>>      
>>>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
>For a limited time only, get FREE Ground shipping on all orders of $35
>or more. Hurry up and shop folks, this offer expires April 30th!
>http://www.thinkgeek.com/freeshipping/?cpg297
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE. 
>http://ads.osdn.com/?ad_id149&alloc_id66&op=ick
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE. 
>http://ads.osdn.com/?ad_id149&alloc_id66&op=ick
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE. 
>http://ads.osdn.com/?ad_id149&alloc_id66&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>  
>

[Springframework-developer] Building Spring tidbit...

[Les A. H. <le...@ha...>]

I did a cvs checkout and did a complete build.

On my year-old computer, it took just 19 seconds.

I compare this to our enterprise product's 8 minute, 11 second build (XDoclet's
running time sucks our life dry, lol).

What a breath of fresh air!!!

Les

Re: [Springframework-developer] Testing Controllers and FormControllers

[<jue...@we...>]

Works nicely: spring-mock.jar is currently 26 KB, including the JNDI and =
the web mocks. The size of spring.jar went down from 973 KB to 956 KB, =
because of the JNDI mocks not being included there anymore.

In total, I completely agree that a separate mock tree makes sense. The =
only remaining question is the package naming: I tend to prefer the =
"org.springframework.mock" subpackages, for having a clear package =
subtree in the "mock" directory.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Wednesday, April 28, 2004 2:32 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Testing Controllers and
FormControllers


If we move them to a separate JAR and separate tree, the mock classes in =
the jndi.support package more or less have to join them for consistency =
reasons. I prefer the name "spring-mock.jar" to "spring-test.jar", as =
the latter is already used as directory name for the test suite.

Given our decoupling from JNDI, I doubt that anyone those JNDI mocks =
anyway: They are mainly used in our framework test suite. And whoever =
uses them in a test suite can seamlessly adapt the package name.

So this looks like:

* a new "mock" directory (alongside "docs", "src", etc), containing the =
mock sources (without "src" subdirectory, as there is not much point in =
testing mocks, therefore there won't be a "test" subdirectory there)

* a "spring-mock.jar", generated from the "mock" directory by the build =
script, shipped in the "dist" directory of our distribution

The remaining question is: How to name the packages there? =
org.springframework.jndi.mock / org.springframework.web.mock or =
org.springframework.mock.jndi / org.springframework.mock.web? I guess =
the latter is more appropriate, given that they are in a separate source =
tree.

As a side note: I doubt that those mocks will expand significantly, but =
I still see the point in keeping them in a dedicated tree.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: Tuesday, April 27, 2004 11:13 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: [Springframework-user]
Testing Controllers and FormControllers


Thanks for the cleaning up: they needed it. However, I feel uneasy about
these classes being included in spring.jar. I would like to see them in =
a
spring-test.jar.

I don't particularly object to them going in the main /src tree, =
although
I'd really prefer a dedicated tree there as well. I'm sure that other =
stuff
will join them in such a new tree.

Rgds,
Rod

----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Cc: <spr...@li...>
Sent: Tuesday, April 27, 2004 9:30 PM
Subject: Re: [Springframework-developer] Re: [Springframework-user] =
Testing
Controllers and FormControllers


I'm ok with including these in Spring; if people feel they are too big,
they could be a spring-test add-on jar, that's not even included in the
main spring.jar which normally included all the optional stuff. That
makes some sense since this is for testing.

j=FCrgen h=F6ller [werk3AT] wrote:

>Matt, everybody,
>
>Essentially, the Servlet API mocks in Spring's test directory are just
there because the MockObjects (http://www.mockobjects.com) Servlet API =
mocks
are so inconvenient to use. The current Spring-provided Servlet API =
mocks
are by no means in a polished state, though: They're just good enough =
for
being used within the framework test suite. They'd need some serious
refinement for making them public - after all, we have a reputation to =
lose
:-)
>
>So on that occasion, I've reworked those mocks today, making them
significantly more complete than before, and ready for getting included =
in
the Spring distribution. The question is: Where to include them? I'd =
like to
include them in the main Spring sources, in a =
org.springframework.web.mock
package: They would naturally be part of spring.jar and spring-web.jar =
then.
The test directory (where they currently reside) is no appropriate =
place, as
it is about testing the framework rather than providing infrastructure
classes.
>
>While it isn't in general appropriate to include mocks in the main =
Spring
codebase, I guess this is a different case: Those mocks are specifically
provided to ease testing of Spring web contexts (like
XmlWebApplicationContext or StaticWebApplicationContext that need a
ServletContext) and controllers (the Controller.handleRequest method =
needs
an HttpServletRequest and an HttpServletResponse). Including them in the
standard distribution would also indicate our strong focus on =
testability.
>
>The new MockServletContext implementation uses the
org.springframework.core.io.Resource API for resource loading, to allow =
for
ServletContext.getResourceAsStream from any resource base. So partly, =
the
mock implementations depend on low-level Spring API. We could of course =
keep
the mocks in a separate part of the Spring CVS, but it's just about a =
couple
of classes, thus hardly worth a separate source tree.
>
>IMO, the main concern regarding additions to the main Spring codebase =
is
whether those additions can potentially grow significantly: While =
Keith's
rules API in the sandbox has definite potential there (so had Ben Alex'
security framework that became the Acegi Security System), the recent =
Struts
support classes and those Servlet API mocks will at best see slight
refinements but certainly not exponential growth. So the former seems =
like a
candidate for a separate module to me, while the latter should fit into =
the
main Spring codebase.
>
>An important point to consider is that there are simply no mocks =
necessary
for testing most parts of a typical Spring app, respectively just =
interfaces
that can conveniently be mocked in a dynamic fashion with EasyMock. =
There
are just two exceptions, as far I see: Our SimpleNamingContext stuff =
eases
custom JNDI environments, and the newly refined set of Servlet API mocks
allows for convenient testing of Spring web MVC (and web contexts).
>
>Mocking an EJB container is next to impossible, so that's not worth =
further
consideration. JDBC can quite nicely be mocked with EasyMock; it's
preferable to use the JdbcOperations interface as far as possible, =
though.
Same for a Hibernate Session, with HibernateOperations being preferable.
It's more or less just the Servlet API that's really tedious to mock =
with
EasyMock, due to all those interdependent methods (e.g. URL paths,
parameters, attributes).
>
>What does everybody think? Does anyone mind including those polished
Servlet API mocks in the main Spring codebase, already for 1.0.2? Any
suggestions for alternatives?
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf Of
>Matt Raible
>Sent: Saturday, April 24, 2004 2:02 PM
>To: spr...@li...
>Subject: Re: [Springframework-user] Testing Controllers and
>FormControllers
>
>
>I use StrutsTestCase (http://strutstestcase.sf.net), which allows you
>to write very little code to test an Action.  Here is a simple example
>of testing an "execute" method:
>
>package org.appfuse.webapp.action;
>
>import servletunit.struts.CactusStrutsTestCase;
>import org.appfuse.Constants;
>
>public class PersonActionTest extends CactusStrutsTestCase {
>
>    public PersonActionTest(String name) {
>        super(name);
>    }
>
>    public void testExecute() {
>        // test execute method
>        setRequestPathInfo("/editPerson");
>        addRequestParameter("id", "1");
>        actionPerform();
>        verifyNoActionErrors();
>         =
assertNotNull(getRequest().getAttribute(Constants.PERSON_KEY));
>     }
>
>     public static void main(String[] args) {
>         junit.textui.TestRunner.run(PersonActionTest.class);
>     }
>}
>
>Since CactusStrutsTestCase extends from Cactus, I can also use Cactus's
>FormAuthentication support to mimic container-managed authentication.
>
>To test a "Save" is also pretty simple.
>
>     public void testSave() throws Exception {
>         setRequestPathInfo("/editPerson");
>         addRequestParameter("action", "Edit");
>         addRequestParameter("id", "1");
>
>         actionPerform();
>
>         assertTrue(getRequest().getAttribute(Constants.PERSON_KEY) =
!=3D
>null);
>
>         setRequestPathInfo("/savePerson");
>         addRequestParameter("action", "Save");
>         actionPerform();
>         verifyForward("edit");
>         verifyNoActionErrors();
>     }
>
>I think you have something similar to this with the Mock Object you're
>using in Spring.  It just needs to be packaged up as a JAR.  I'll be
>more than happy to write up some documentation on how to use it.
>
>Matt
>
>
>On Apr 24, 2004, at 4:27 AM, j=FCrgen h=F6ller [werk3AT] wrote:
>
>
>
>>Matt,
>>
>>I just tried using MockHttpServletRequest and MockHttpServletResponse
>>from MockObjects with a Spring FormController. Unfortunately, those
>>MockObjects mocks are really not well-suited for testing here, as it's
>>so much hassle to setup any kind of HttpServletRequest method access.
>>What request/response mocks do you use for testing Struts Actions?
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von
>>j=FCrgen h=F6ller [werk3AT]
>>Gesendet: Sa 24.04.2004 10:57
>>An: spr...@li...
>>Betreff: Re: [Springframework-user] Testing Controllers and
>>FormControllers
>>
>>
>>
>>I don't see much difference between testing Controllers and
>>FormControllers: Both share the same "ModelAndView
>>handleRequest(HttpServletRequest, HttpServletResponse)" method that
>>you need to invoke for testing. As of 1.0.1, you shouldn't need a
>>ServletContext mock anymore (except when actually accessing the
>>ServletContext), so all you need are HttpServletRequest and
>>HttpServletResponse mocks. The mocks provided by the MockObjects
>>project should be fine for this.
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von
>>Matt Raible
>>Gesendet: Fr 23.04.2004 20:48
>>An: spr...@li...
>>Betreff: [Springframework-user] Testing Controllers and =
FormControllers
>>
>>
>>
>>I've found it pretty simple to test Controllers, but FormControllers
>>are
>>a different story.  From looking at the FormControllerTestSuite (URL
>>below), as well as many other Spring tests, it seems that a lot of
>>internal mocks are used to test this stuff.
>>
>>So my question is - what do you recommend for the average Spring MVC
>>person?  What is the strategy we should be using to test our
>>controllers?  Should we be using the Mocks that Spring provides?  This
>>would certainly make things easier.  If we're supposed to do that - is
>>it possible to get these mocks distributed in a JAR?
>>
>>Thanks,
>>
>>Matt
>>
>>http://monkeymachine.co.uk/spring/xref-test/org/springframework/web/
>>serv
>>let/mvc/FormControllerTestSuite.html
>>
>>



-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. =

Take an Oracle 10g class now, and we'll give you the exam FREE.=20
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. =

Take an Oracle 10g class now, and we'll give you the exam FREE.=20
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Testing Controllers and FormControllers

[Dmitriy K. <dko...@ru...>]

Juergen,

I would vote for org.springframework.mock.* package names.

Regards,
Dmitriy.


jürgen höller [werk3AT] wrote:
> If we move them to a separate JAR and separate tree, the mock classes in the jndi.support package more or less have to join them for consistency reasons. I prefer the name "spring-mock.jar" to "spring-test.jar", as the latter is already used as directory name for the test suite.
> 
> Given our decoupling from JNDI, I doubt that anyone those JNDI mocks anyway: They are mainly used in our framework test suite. And whoever uses them in a test suite can seamlessly adapt the package name.
> 
> So this looks like:
> 
> * a new "mock" directory (alongside "docs", "src", etc), containing the mock sources (without "src" subdirectory, as there is not much point in testing mocks, therefore there won't be a "test" subdirectory there)
> 
> * a "spring-mock.jar", generated from the "mock" directory by the build script, shipped in the "dist" directory of our distribution
> 
> The remaining question is: How to name the packages there? org.springframework.jndi.mock / org.springframework.web.mock or org.springframework.mock.jndi / org.springframework.mock.web? I guess the latter is more appropriate, given that they are in a separate source tree.
> 
> As a side note: I doubt that those mocks will expand significantly, but I still see the point in keeping them in a dedicated tree.
> 
> Juergen
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Rod Johnson
> Sent: Tuesday, April 27, 2004 11:13 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Re: [Springframework-user]
> Testing Controllers and FormControllers
> 
> 
> Thanks for the cleaning up: they needed it. However, I feel uneasy about
> these classes being included in spring.jar. I would like to see them in a
> spring-test.jar.
> 
> I don't particularly object to them going in the main /src tree, although
> I'd really prefer a dedicated tree there as well. I'm sure that other stuff
> will join them in such a new tree.
> 
> Rgds,
> Rod
> 
> ----- Original Message -----
> From: "Colin Sampaleanu" <col...@ex...>
> To: <spr...@li...>
> Cc: <spr...@li...>
> Sent: Tuesday, April 27, 2004 9:30 PM
> Subject: Re: [Springframework-developer] Re: [Springframework-user] Testing
> Controllers and FormControllers
> 
> 
> I'm ok with including these in Spring; if people feel they are too big,
> they could be a spring-test add-on jar, that's not even included in the
> main spring.jar which normally included all the optional stuff. That
> makes some sense since this is for testing.
> 
> jürgen höller [werk3AT] wrote:
> 
> 
>>Matt, everybody,
>>
>>Essentially, the Servlet API mocks in Spring's test directory are just
> 
> there because the MockObjects (http://www.mockobjects.com) Servlet API mocks
> are so inconvenient to use. The current Spring-provided Servlet API mocks
> are by no means in a polished state, though: They're just good enough for
> being used within the framework test suite. They'd need some serious
> refinement for making them public - after all, we have a reputation to lose
> :-)
> 
>>So on that occasion, I've reworked those mocks today, making them
> 
> significantly more complete than before, and ready for getting included in
> the Spring distribution. The question is: Where to include them? I'd like to
> include them in the main Spring sources, in a org.springframework.web.mock
> package: They would naturally be part of spring.jar and spring-web.jar then.
> The test directory (where they currently reside) is no appropriate place, as
> it is about testing the framework rather than providing infrastructure
> classes.
> 
>>While it isn't in general appropriate to include mocks in the main Spring
> 
> codebase, I guess this is a different case: Those mocks are specifically
> provided to ease testing of Spring web contexts (like
> XmlWebApplicationContext or StaticWebApplicationContext that need a
> ServletContext) and controllers (the Controller.handleRequest method needs
> an HttpServletRequest and an HttpServletResponse). Including them in the
> standard distribution would also indicate our strong focus on testability.
> 
>>The new MockServletContext implementation uses the
> 
> org.springframework.core.io.Resource API for resource loading, to allow for
> ServletContext.getResourceAsStream from any resource base. So partly, the
> mock implementations depend on low-level Spring API. We could of course keep
> the mocks in a separate part of the Spring CVS, but it's just about a couple
> of classes, thus hardly worth a separate source tree.
> 
>>IMO, the main concern regarding additions to the main Spring codebase is
> 
> whether those additions can potentially grow significantly: While Keith's
> rules API in the sandbox has definite potential there (so had Ben Alex'
> security framework that became the Acegi Security System), the recent Struts
> support classes and those Servlet API mocks will at best see slight
> refinements but certainly not exponential growth. So the former seems like a
> candidate for a separate module to me, while the latter should fit into the
> main Spring codebase.
> 
>>An important point to consider is that there are simply no mocks necessary
> 
> for testing most parts of a typical Spring app, respectively just interfaces
> that can conveniently be mocked in a dynamic fashion with EasyMock. There
> are just two exceptions, as far I see: Our SimpleNamingContext stuff eases
> custom JNDI environments, and the newly refined set of Servlet API mocks
> allows for convenient testing of Spring web MVC (and web contexts).
> 
>>Mocking an EJB container is next to impossible, so that's not worth further
> 
> consideration. JDBC can quite nicely be mocked with EasyMock; it's
> preferable to use the JdbcOperations interface as far as possible, though.
> Same for a Hibernate Session, with HibernateOperations being preferable.
> It's more or less just the Servlet API that's really tedious to mock with
> EasyMock, due to all those interdependent methods (e.g. URL paths,
> parameters, attributes).
> 
>>What does everybody think? Does anyone mind including those polished
> 
> Servlet API mocks in the main Spring codebase, already for 1.0.2? Any
> suggestions for alternatives?
> 
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf Of
>>Matt Raible
>>Sent: Saturday, April 24, 2004 2:02 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-user] Testing Controllers and
>>FormControllers
>>
>>
>>I use StrutsTestCase (http://strutstestcase.sf.net), which allows you
>>to write very little code to test an Action.  Here is a simple example
>>of testing an "execute" method:
>>
>>package org.appfuse.webapp.action;
>>
>>import servletunit.struts.CactusStrutsTestCase;
>>import org.appfuse.Constants;
>>
>>public class PersonActionTest extends CactusStrutsTestCase {
>>
>>   public PersonActionTest(String name) {
>>       super(name);
>>   }
>>
>>   public void testExecute() {
>>       // test execute method
>>       setRequestPathInfo("/editPerson");
>>       addRequestParameter("id", "1");
>>       actionPerform();
>>       verifyNoActionErrors();
>>        assertNotNull(getRequest().getAttribute(Constants.PERSON_KEY));
>>    }
>>
>>    public static void main(String[] args) {
>>        junit.textui.TestRunner.run(PersonActionTest.class);
>>    }
>>}
>>
>>Since CactusStrutsTestCase extends from Cactus, I can also use Cactus's
>>FormAuthentication support to mimic container-managed authentication.
>>
>>To test a "Save" is also pretty simple.
>>
>>    public void testSave() throws Exception {
>>        setRequestPathInfo("/editPerson");
>>        addRequestParameter("action", "Edit");
>>        addRequestParameter("id", "1");
>>
>>        actionPerform();
>>
>>        assertTrue(getRequest().getAttribute(Constants.PERSON_KEY) !=
>>null);
>>
>>        setRequestPathInfo("/savePerson");
>>        addRequestParameter("action", "Save");
>>        actionPerform();
>>        verifyForward("edit");
>>        verifyNoActionErrors();
>>    }
>>
>>I think you have something similar to this with the Mock Object you're
>>using in Spring.  It just needs to be packaged up as a JAR.  I'll be
>>more than happy to write up some documentation on how to use it.
>>
>>Matt
>>
>>
>>On Apr 24, 2004, at 4:27 AM, jürgen höller [werk3AT] wrote:
>>
>>
>>
>>
>>>Matt,
>>>
>>>I just tried using MockHttpServletRequest and MockHttpServletResponse
>>
>>>from MockObjects with a Spring FormController. Unfortunately, those
>>
>>>MockObjects mocks are really not well-suited for testing here, as it's
>>>so much hassle to setup any kind of HttpServletRequest method access.
>>>What request/response mocks do you use for testing Struts Actions?
>>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: spr...@li... im Auftrag von
>>>jürgen höller [werk3AT]
>>>Gesendet: Sa 24.04.2004 10:57
>>>An: spr...@li...
>>>Betreff: Re: [Springframework-user] Testing Controllers and
>>>FormControllers
>>>
>>>
>>>
>>>I don't see much difference between testing Controllers and
>>>FormControllers: Both share the same "ModelAndView
>>>handleRequest(HttpServletRequest, HttpServletResponse)" method that
>>>you need to invoke for testing. As of 1.0.1, you shouldn't need a
>>>ServletContext mock anymore (except when actually accessing the
>>>ServletContext), so all you need are HttpServletRequest and
>>>HttpServletResponse mocks. The mocks provided by the MockObjects
>>>project should be fine for this.
>>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: spr...@li... im Auftrag von
>>>Matt Raible
>>>Gesendet: Fr 23.04.2004 20:48
>>>An: spr...@li...
>>>Betreff: [Springframework-user] Testing Controllers and FormControllers
>>>
>>>
>>>
>>>I've found it pretty simple to test Controllers, but FormControllers
>>>are
>>>a different story.  From looking at the FormControllerTestSuite (URL
>>>below), as well as many other Spring tests, it seems that a lot of
>>>internal mocks are used to test this stuff.
>>>
>>>So my question is - what do you recommend for the average Spring MVC
>>>person?  What is the strategy we should be using to test our
>>>controllers?  Should we be using the Mocks that Spring provides?  This
>>>would certainly make things easier.  If we're supposed to do that - is
>>>it possible to get these mocks distributed in a JAR?
>>>
>>>Thanks,
>>>
>>>Matt
>>>
>>>http://monkeymachine.co.uk/spring/xref-test/org/springframework/web/
>>>serv
>>>let/mvc/FormControllerTestSuite.html
>>>
>>>
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg297
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE. 
> http://ads.osdn.com/?ad_id149&alloc_id66&op=ick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE. 
> http://ads.osdn.com/?ad_id149&alloc_id66&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Testing Controllers and FormControllers

[<jue...@we...>]

If we move them to a separate JAR and separate tree, the mock classes in =
the jndi.support package more or less have to join them for consistency =
reasons. I prefer the name "spring-mock.jar" to "spring-test.jar", as =
the latter is already used as directory name for the test suite.

Given our decoupling from JNDI, I doubt that anyone those JNDI mocks =
anyway: They are mainly used in our framework test suite. And whoever =
uses them in a test suite can seamlessly adapt the package name.

So this looks like:

* a new "mock" directory (alongside "docs", "src", etc), containing the =
mock sources (without "src" subdirectory, as there is not much point in =
testing mocks, therefore there won't be a "test" subdirectory there)

* a "spring-mock.jar", generated from the "mock" directory by the build =
script, shipped in the "dist" directory of our distribution

The remaining question is: How to name the packages there? =
org.springframework.jndi.mock / org.springframework.web.mock or =
org.springframework.mock.jndi / org.springframework.mock.web? I guess =
the latter is more appropriate, given that they are in a separate source =
tree.

As a side note: I doubt that those mocks will expand significantly, but =
I still see the point in keeping them in a dedicated tree.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: Tuesday, April 27, 2004 11:13 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: [Springframework-user]
Testing Controllers and FormControllers


Thanks for the cleaning up: they needed it. However, I feel uneasy about
these classes being included in spring.jar. I would like to see them in =
a
spring-test.jar.

I don't particularly object to them going in the main /src tree, =
although
I'd really prefer a dedicated tree there as well. I'm sure that other =
stuff
will join them in such a new tree.

Rgds,
Rod

----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Cc: <spr...@li...>
Sent: Tuesday, April 27, 2004 9:30 PM
Subject: Re: [Springframework-developer] Re: [Springframework-user] =
Testing
Controllers and FormControllers


I'm ok with including these in Spring; if people feel they are too big,
they could be a spring-test add-on jar, that's not even included in the
main spring.jar which normally included all the optional stuff. That
makes some sense since this is for testing.

j=FCrgen h=F6ller [werk3AT] wrote:

>Matt, everybody,
>
>Essentially, the Servlet API mocks in Spring's test directory are just
there because the MockObjects (http://www.mockobjects.com) Servlet API =
mocks
are so inconvenient to use. The current Spring-provided Servlet API =
mocks
are by no means in a polished state, though: They're just good enough =
for
being used within the framework test suite. They'd need some serious
refinement for making them public - after all, we have a reputation to =
lose
:-)
>
>So on that occasion, I've reworked those mocks today, making them
significantly more complete than before, and ready for getting included =
in
the Spring distribution. The question is: Where to include them? I'd =
like to
include them in the main Spring sources, in a =
org.springframework.web.mock
package: They would naturally be part of spring.jar and spring-web.jar =
then.
The test directory (where they currently reside) is no appropriate =
place, as
it is about testing the framework rather than providing infrastructure
classes.
>
>While it isn't in general appropriate to include mocks in the main =
Spring
codebase, I guess this is a different case: Those mocks are specifically
provided to ease testing of Spring web contexts (like
XmlWebApplicationContext or StaticWebApplicationContext that need a
ServletContext) and controllers (the Controller.handleRequest method =
needs
an HttpServletRequest and an HttpServletResponse). Including them in the
standard distribution would also indicate our strong focus on =
testability.
>
>The new MockServletContext implementation uses the
org.springframework.core.io.Resource API for resource loading, to allow =
for
ServletContext.getResourceAsStream from any resource base. So partly, =
the
mock implementations depend on low-level Spring API. We could of course =
keep
the mocks in a separate part of the Spring CVS, but it's just about a =
couple
of classes, thus hardly worth a separate source tree.
>
>IMO, the main concern regarding additions to the main Spring codebase =
is
whether those additions can potentially grow significantly: While =
Keith's
rules API in the sandbox has definite potential there (so had Ben Alex'
security framework that became the Acegi Security System), the recent =
Struts
support classes and those Servlet API mocks will at best see slight
refinements but certainly not exponential growth. So the former seems =
like a
candidate for a separate module to me, while the latter should fit into =
the
main Spring codebase.
>
>An important point to consider is that there are simply no mocks =
necessary
for testing most parts of a typical Spring app, respectively just =
interfaces
that can conveniently be mocked in a dynamic fashion with EasyMock. =
There
are just two exceptions, as far I see: Our SimpleNamingContext stuff =
eases
custom JNDI environments, and the newly refined set of Servlet API mocks
allows for convenient testing of Spring web MVC (and web contexts).
>
>Mocking an EJB container is next to impossible, so that's not worth =
further
consideration. JDBC can quite nicely be mocked with EasyMock; it's
preferable to use the JdbcOperations interface as far as possible, =
though.
Same for a Hibernate Session, with HibernateOperations being preferable.
It's more or less just the Servlet API that's really tedious to mock =
with
EasyMock, due to all those interdependent methods (e.g. URL paths,
parameters, attributes).
>
>What does everybody think? Does anyone mind including those polished
Servlet API mocks in the main Spring codebase, already for 1.0.2? Any
suggestions for alternatives?
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf Of
>Matt Raible
>Sent: Saturday, April 24, 2004 2:02 PM
>To: spr...@li...
>Subject: Re: [Springframework-user] Testing Controllers and
>FormControllers
>
>
>I use StrutsTestCase (http://strutstestcase.sf.net), which allows you
>to write very little code to test an Action.  Here is a simple example
>of testing an "execute" method:
>
>package org.appfuse.webapp.action;
>
>import servletunit.struts.CactusStrutsTestCase;
>import org.appfuse.Constants;
>
>public class PersonActionTest extends CactusStrutsTestCase {
>
>    public PersonActionTest(String name) {
>        super(name);
>    }
>
>    public void testExecute() {
>        // test execute method
>        setRequestPathInfo("/editPerson");
>        addRequestParameter("id", "1");
>        actionPerform();
>        verifyNoActionErrors();
>         =
assertNotNull(getRequest().getAttribute(Constants.PERSON_KEY));
>     }
>
>     public static void main(String[] args) {
>         junit.textui.TestRunner.run(PersonActionTest.class);
>     }
>}
>
>Since CactusStrutsTestCase extends from Cactus, I can also use Cactus's
>FormAuthentication support to mimic container-managed authentication.
>
>To test a "Save" is also pretty simple.
>
>     public void testSave() throws Exception {
>         setRequestPathInfo("/editPerson");
>         addRequestParameter("action", "Edit");
>         addRequestParameter("id", "1");
>
>         actionPerform();
>
>         assertTrue(getRequest().getAttribute(Constants.PERSON_KEY) =
!=3D
>null);
>
>         setRequestPathInfo("/savePerson");
>         addRequestParameter("action", "Save");
>         actionPerform();
>         verifyForward("edit");
>         verifyNoActionErrors();
>     }
>
>I think you have something similar to this with the Mock Object you're
>using in Spring.  It just needs to be packaged up as a JAR.  I'll be
>more than happy to write up some documentation on how to use it.
>
>Matt
>
>
>On Apr 24, 2004, at 4:27 AM, j=FCrgen h=F6ller [werk3AT] wrote:
>
>
>
>>Matt,
>>
>>I just tried using MockHttpServletRequest and MockHttpServletResponse
>>from MockObjects with a Spring FormController. Unfortunately, those
>>MockObjects mocks are really not well-suited for testing here, as it's
>>so much hassle to setup any kind of HttpServletRequest method access.
>>What request/response mocks do you use for testing Struts Actions?
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von
>>j=FCrgen h=F6ller [werk3AT]
>>Gesendet: Sa 24.04.2004 10:57
>>An: spr...@li...
>>Betreff: Re: [Springframework-user] Testing Controllers and
>>FormControllers
>>
>>
>>
>>I don't see much difference between testing Controllers and
>>FormControllers: Both share the same "ModelAndView
>>handleRequest(HttpServletRequest, HttpServletResponse)" method that
>>you need to invoke for testing. As of 1.0.1, you shouldn't need a
>>ServletContext mock anymore (except when actually accessing the
>>ServletContext), so all you need are HttpServletRequest and
>>HttpServletResponse mocks. The mocks provided by the MockObjects
>>project should be fine for this.
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von
>>Matt Raible
>>Gesendet: Fr 23.04.2004 20:48
>>An: spr...@li...
>>Betreff: [Springframework-user] Testing Controllers and =
FormControllers
>>
>>
>>
>>I've found it pretty simple to test Controllers, but FormControllers
>>are
>>a different story.  From looking at the FormControllerTestSuite (URL
>>below), as well as many other Spring tests, it seems that a lot of
>>internal mocks are used to test this stuff.
>>
>>So my question is - what do you recommend for the average Spring MVC
>>person?  What is the strategy we should be using to test our
>>controllers?  Should we be using the Mocks that Spring provides?  This
>>would certainly make things easier.  If we're supposed to do that - is
>>it possible to get these mocks distributed in a JAR?
>>
>>Thanks,
>>
>>Matt
>>
>>http://monkeymachine.co.uk/spring/xref-test/org/springframework/web/
>>serv
>>let/mvc/FormControllerTestSuite.html
>>
>>



-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. =

Take an Oracle 10g class now, and we'll give you the exam FREE.=20
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] minor annoyances

[<jue...@we...>]

Hi Tom,
=20
I've just addressed your first two issues (already in CVS):
=20
* HttpServletBean and GenericFilterBean provide "initBeanWrapper" =
callbacks now. They also auto-register a ResourceEditor with a =
ServletContextResourceLoader, to interpret relative resource paths as =
ServletContext resources.
=20
* ResourceBundleViewResolver has an alternative "basenames" property =
now, just like ResourceBundleMessageSource, loading view definitions =
from all given bundles.
=20
Gonna look at the AbstractWizardFormController issues later this week.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Tom Turelinckx
Gesendet: Mi 28.04.2004 09:38
An: spr...@li...
Betreff: [Springframework-developer] minor annoyances



Hello,

While upgrading to spring 1.0.1, I've noticed some minor annoyances that
may be easy to fix, possibly for 1.0.2:

1. HttpServletBean apparently does not support properties of type
Resource, because BeanWrapperImpl does not register a Resource property
editor by default. However, there's no possibility to register custom
editors with the BeanWrapper used by HttpServletBean. Maybe an
"initBeanWrapper" protected method could be added here, like initBinder
in BaseCommandController?

2. Unlike ResourceBundleMessageSource, ResourceBundleViewResolver only
has a basename property, no basenames property. As we keep controller
cfg, dao cfg and messages in separate resource files by functional
domain, it also makes sense to keep the view cfg in different files.
We're currently using an adapted ResourceBundleViewResolver, but maybe
this functionality could be added to spring, or maybe there's a good
reason to keep all view cfg in a single file?

3. In AbstractWizardFormController, it would be useful if processFinish
had an extra "int submissionPage" parameter (the currentPage value in
processFormSubmission could be passed to validatePagesAndFinish and on =
to
processFinish), though I have no suggestion how to add this in a
backward-compatible way...
It would be useful, because some of our legacy stored procedures perform
validation logic that we can't duplicate in java, i.e. the result of a
stored procedure could indicate a user-correctable error, which we would
like to display in the same way as a global validation error, e.g.:

protected ModelAndView processFinish( HttpServletRequest request,
        HttpServletResponse response, Object command,
        BindException errors, int page ) throws Exception {
    // stored procedure is called in onSubmit,
    // messageInfo is an output parameter
    MessageInfo messageInfo =3D onSubmit( command );
    if ( messageInfo.isError() ) {
        errors.reject( "", messageInfo.getMessage() );
        return showPage( request, errors, page );
    }
    if ( messageInfo.isWarning() ) {
        return handleWarning( command, messageInfo );
    }
    return handleSuccess( command, messageInfo );
}

Note that getCurrentPage can't be called in processFinish, as we are
"after processFormSubmission".

Even if the page parameter can't be added to processFinish, it would
still be useful to add it to validatePagesAndFinish:

private ModelAndView validatePagesAndFinish(HttpServletRequest request,
        HttpServletResponse response, Object command,
        BindException errors, int currentPage) throws Exception {

    // in case of binding errors  -> show current page
    if (errors.getErrorCount() - errors.getGlobalErrorCount() > 0) {
        return showPage(request, errors, currentPage);
    }

    for (int page =3D 0; page < pages.length; page++) {
        validatePage(command, errors, page);
        // in case of field errors on a page -> show the page
        if (errors.getErrorCount() - errors.getGlobalErrorCount() > 0) {
            return showPage(request, errors, page);
        }
    }
    // no field errors -> maybe global errors, or none at all
    return processFinish(request, response, command, errors,
    currentPage);
}

The first if was added to ensure the current page is shown again if =
there
were binding errors, such as typeMismatch. Otherwise, those errors will
always result in the first page being shown, instead of the submission
page where the error actually occured.

Also, shouldn't the "if (pages =3D=3D null | pages.length =3D=3D 0)" in =
setPages
use "||" instead of "|"?

Kind regards,
Tom.


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Wiring VelocityEngine with a DataSourceResourceLoader

[Matt R. <li...@ra...>]

Awesome - thanks for adding this.  With the patched
DataSourceResourceLoader from Velocity, I'm able to do this:

<!-- Configure Velocity for sending e-mail -->
<bean id=3D"velocityEngine"
class=3D"org.springframework.ui.velocity.VelocityEngineFactoryBean"
singleton=3D"true">
    <property name=3D"velocityPropertiesMap">
        <map>
            <entry key=3D"resource.loader"><value>ds</value></entry>
            <entry key=3D"ds.resource.loader.instance"><ref
bean=3D"templateLoader"/></entry>
            <entry
key=3D"ds.resource.loader.resource.table"><value>template</value></entry>=

            <entry
key=3D"ds.resource.loader.resource.keycolumn"><value>name</value></entry>=

            <entry
key=3D"ds.resource.loader.resource.templatecolumn"><value>content</value>=
<
/entry>
            <entry
key=3D"ds.resource.loader.resource.timestampcolumn"><value>last_modified<=
/
value></entry>
        </map>
    </property>
</bean>

<!-- Velocity Database Template Loader -->
<bean id=3D"templateLoader" singleton=3D"true"
=20
class=3D"org.apache.velocity.runtime.resource.loader.DataSourceResourceLo=
a
der">
    <property name=3D"dataSource"><ref local=3D"dataSource"/></property>
</bean>

Now I have the power of Velocity and a template stored in the database
with no JNDI environment.

Matt

> How late is it in Denver? 4 o'clock in the morning?=20

Not that late, it's only 2:45... ;-)


> -----Original Message-----
> From: spr...@li...=20
> [mailto:spr...@li...]
>  On Behalf Of j=FCrgen h=F6ller [werk3AT]
> Sent: Wednesday, April 28, 2004 1:23 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Wiring=20
> VelocityEngine with a DataSourceResourceLoader
>=20
>=20
> Matt,
> =20
> VelocityEngineFactoryBean's "resourceLoader" property is=20
> meant to take an implementation of Spring's=20
> org.springframework.core.io.ResourceLoader interface. When=20
> setting this, VelocityEngineFactoryBean will auto-configure=20
> the Velocity resource loader to load file-based templates via=20
> the Spring ResourceLoader. When running in an=20
> ApplicationContext, the context will set itself as the=20
> ResourceLoader, through the ResourceLoaderAware interface=20
> (implemented by VelocityEngineFactoryBean).
> =20
> What you need to do in your scenario is to set Velocity's=20
> "ds.resource.loader.instance" property accordingly.=20
> Unfortunately, VelocityEngineFactoryBean's=20
> "velocityProperties" property takes a java.util.Properties=20
> instance, just intended for String values. So I've just added=20
> a "velocityPropertiesMap" property that takes a=20
> java.util.Map, allowing for non-String values:
> =20
> <bean id=3D"velocityEngine"=20
> class=3D"org.springframework.ui.velocity.VelocityEngineFactoryBean"=20
> singleton=3D"true">
>      <property name=3D"velocityProperties">
>          <props>
>              <prop key=3D"resource.loader">ds</prop>
>              <prop=20
> key=3D"ds.resource.loader.resource.table">template</prop>
>              <prop=20
> key=3D"ds.resource.loader.resource.keycolumn">name</prop>
>              <prop=20
> key=3D"ds.resource.loader.resource.templatecolumn">content</prop>
>              <prop=20
> =
key=3D"ds.resource.loader.resource.timestampcolumn">last_modified</prop>
>          </props>
>      </property>
>      <property name=3D"velocityPropertiesMap">
>          <map>
>              <entry key=3D"ds.resource.loader.instance"><ref=20
> bean=3D"dataSource"/></prop>
>          </map>
>      </property>
> </bean>
>=20
> Of course, you can also define all your Velocity properties=20
> via "velocityPropertiesMap": You need to use the=20
> <map>/<entry> syntax for all properties then, though,=20
> wrapping all your String values with <value> tags.
> =20
> Juergen
> =20
>=20
> ________________________________
>=20
> Von: spr...@li... im=20
> Auftrag von Matt Raible
> Gesendet: Mi 28.04.2004 05:20
> An: spr...@li...
> Betreff: [Springframework-developer] Wiring VelocityEngine=20
> with a DataSourceResourceLoader
>=20
>=20
>=20
> I've been talking with some Velocity folks about modifying their=20
> DataSourceResourceLoader to allow setting the DataSource=20
> (currently it=20
> makes you specify a JNDI string in your properties).  They have done=20
> this and provided a patch:
>=20
> http://issues.apache.org/bugzilla/show_bug.cgi?id=3D28611
>=20
> This is my idea of how it would be configured in Spring:
>=20
> <!-- Configure Velocity for sending e-mail -->
> <bean id=3D"velocityEngine"=20
> class=3D"org.springframework.ui.velocity.VelocityEngineFactoryBean"=20
> singleton=3D"true">
>      <property name=3D"velocityProperties">
>          <props>
>              <prop key=3D"resource.loader">ds</prop>
>              <prop=20
> key=3D"ds.resource.loader.resource.table">template</prop>
>              <prop=20
> key=3D"ds.resource.loader.resource.keycolumn">name</prop>
>              <prop=20
> key=3D"ds.resource.loader.resource.templatecolumn">content</prop>
>              <prop=20
> =
key=3D"ds.resource.loader.resource.timestampcolumn">last_modified</prop>
>          </props>
>      </property>
>      <property name=3D"resourceLoader"><ref=20
> local=3D"templateLoader"/></property>
> </bean>
>=20
> <bean id=3D"templateLoader" singleton=3D"true"
>     =20
> class=3D"org.apache.velocity.runtime.resource.loader.DataSourceR
> esourceLoa
> der">
>      <property name=3D"dataSource"><ref=20
> local=3D"dataSource"/></property> </bean>
>=20
> However, I get the following error:
>=20
>      [junit] Caused by:=20
> org.springframework.beans.factory.BeanCreationException:=20
> Error creating=20
> bean with name 'velocityEngine' defined in class path resource=20
> [applicationContext.xml]: Error setting property values; nested=20
> exception is=20
> org.springframework.beans.PropertyAccessExceptionsException:=20
> PropertyAccessExceptionsException (1 errors); nested=20
> propertyAccessExceptions are:=20
> [org.springframework.beans.TypeMismatchException: Failed to convert=20
> property value of type=20
> [org.apache.velocity.runtime.resource.loader.DataSourceResourc
> eLoader]=20
> to required type [org.springframework.core.io.ResourceLoader] for=20
> property 'resourceLoader'; nested exception is=20
> java.lang.IllegalArgumentException: argument type mismatch]
>=20
> Is it possible to allow this, or some other way of initializing this=20
> ResourceLoader and putting it in the Engine?  Here's the code you can=20
> use if you were programming this:
>=20
>   DataSourceResourceLoader ds =3D new DataSourceResourceLoader();
>   ds.setDataSource(DATASOURCE);
>   Velocity.setProperty("ds.resource.loader.instance",ds);
>   Velocity.init();
>=20
> Thanks,
>=20
> Matt
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market...=20
> Oracle 10g. Take an Oracle 10g class now, and we'll give you=20
> the exam FREE. =
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market...=20
> Oracle 10g.=20
> Take an Oracle 10g class now, and we'll give you the exam FREE.=20
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op=CCk
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

Re: [Springframework-developer] Re: struts integration - alternate approach

[<jue...@we...>]

Essentially, using DelegatingActionProxy or DelegatingRequestProcessor =
even becomes a configuration-time choice then: Both access =
Spring-configured Action beans in the ContextLoaderPlugIn context. I =
wouldn't mind adding the RequestProcessor subclasses, although they =
clearly have the disadvantage of interfering with a custom =
RequestProcessor. However, most people will use either Struts' default =
RequestProcessor or the TilesRequestProcessor, so we'd definitely cover =
more than 90%. The rest can still use DelegatingActionProxy, just =
needing to adapt struts-config accordingly.
=20
Juergen
=20
P.S.:
How late is it in Denver? 4 o'clock in the morning? ;-)
=20

________________________________

Von: spr...@li... im Auftrag =
von Matt Raible
Gesendet: Mi 28.04.2004 10:01
An: spr...@li...
Betreff: RE: [Springframework-developer] Re: struts integration - =
alternate approach



+1 for adding them to the org.springframework.web.struts package.  I use
XDoclet for all my Actions in AppFuse and therefore, I'm not using the
ContextLoaderPlugIn.  I'd like to use it b/c then I can use
MockStrutsTestCase to test my actions.  This change would make it
possible.

Matt

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]
>  On Behalf Of j=FCrgen h=F6ller [werk3AT]
> Sent: Wednesday, April 28, 2004 1:36 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Re: struts
> integration - alternate approach
>
>
> I see.
>=20
> I wonder whether it's worth adding a
> DelegatingRequestProcessor and a
> DelegatingTilesRequestProcessor to our
> org.springframework.web.struts package then: That approach is
> mainly useful when generating struts-config via XDoclet, if I
> understand correctly. Of course, quite a lot of people do use
> Struts with XDoclet.
>=20
> What does everybody think? I've got those RequestProcessor
> subclasses lying around already; the question is whether to
> include them in Spring 1.0.2. Else, I'll add them to the
> sandbox for the time being. Votes, please :-)
>=20
> Juergen
>=20
>
> ________________________________
>
> Von: spr...@li... im
> Auftrag von Seth Ladd
> Gesendet: Mo 26.04.2004 23:54
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Re: struts
> integration - alternate approach
>
>
>
> j=FCrgen h=F6ller [werk3AT] wrote:
> > Dan,
> >
> > I've just done some prototypical tests. As far as I can
> tell, the only
> > benefit of the RequestProcessor approach is that you can write
> >
> >   <action path=3D"/test"/>
> >
> > rather than
> >
> >   <action path=3D"/test"
> > class=3D"org.springframework.web.struts.DelegatingActionProxy"/>
> >
> > The disadvantage is that you need to have a special
> subclass of every
> > RequestProcessor that you might use: at least of the default
> > RequestProcessor and of TilesRequestProcessor. Some amount of code
> > duplication is inevitable there. And if you already have a custom
> > RequestProcessor, you need to subclass it on your own.
> >
> > So all things considered, I still tend to recommend the
> > DelegatingActionProxy approach, which doesn't affect
> RequestProcessor
> > choice at all. Just saving the "class" attribute above does
> not seem
> > to be enough benefit to accept the RequestProcessor
> subclass hassle.
> > Is there anything I miss here?
> >
> > Juergen
> >
> > P.S.:
> > I'm forwarding this to developer list for further feedback.
>
> Juergen,
>
> For our integration here, we ended up subclassing
> RequestProcessor.  The reason was because we're using xdoclet
> to build our struts-config.xml file.  So IIRC we couldn't use
> DelegatingActionProxy (or the similar
> alternatives) because we needed Xdoclet to read into our
> action classes.
>
> Hope that helps,
> Seth
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at
> ThinkGeek For a limited time only, get FREE Ground shipping
> on all orders of $35 or more. Hurry up and shop folks, this
> offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=3D> 12297
>
> _______________________________________________
>
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market...
> Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Re: struts integration - alternate approach

[Matt R. <li...@ra...>]

+1 for adding them to the org.springframework.web.struts package.  I use
XDoclet for all my Actions in AppFuse and therefore, I'm not using the
ContextLoaderPlugIn.  I'd like to use it b/c then I can use
MockStrutsTestCase to test my actions.  This change would make it
possible.

Matt

> -----Original Message-----
> From: spr...@li...=20
> [mailto:spr...@li...]
>  On Behalf Of j=FCrgen h=F6ller [werk3AT]
> Sent: Wednesday, April 28, 2004 1:36 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Re: struts=20
> integration - alternate approach
>=20
>=20
> I see.
> =20
> I wonder whether it's worth adding a=20
> DelegatingRequestProcessor and a=20
> DelegatingTilesRequestProcessor to our=20
> org.springframework.web.struts package then: That approach is=20
> mainly useful when generating struts-config via XDoclet, if I=20
> understand correctly. Of course, quite a lot of people do use=20
> Struts with XDoclet.
> =20
> What does everybody think? I've got those RequestProcessor=20
> subclasses lying around already; the question is whether to=20
> include them in Spring 1.0.2. Else, I'll add them to the=20
> sandbox for the time being. Votes, please :-)
> =20
> Juergen
> =20
>=20
> ________________________________
>=20
> Von: spr...@li... im=20
> Auftrag von Seth Ladd
> Gesendet: Mo 26.04.2004 23:54
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Re: struts=20
> integration - alternate approach
>=20
>=20
>=20
> j=FCrgen h=F6ller [werk3AT] wrote:
> > Dan,
> >=20
> > I've just done some prototypical tests. As far as I can=20
> tell, the only=20
> > benefit of the RequestProcessor approach is that you can write
> >=20
> >   <action path=3D"/test"/>
> >
> > rather than
> >=20
> >   <action path=3D"/test"=20
> > class=3D"org.springframework.web.struts.DelegatingActionProxy"/>
> >=20
> > The disadvantage is that you need to have a special=20
> subclass of every=20
> > RequestProcessor that you might use: at least of the default=20
> > RequestProcessor and of TilesRequestProcessor. Some amount of code=20
> > duplication is inevitable there. And if you already have a custom=20
> > RequestProcessor, you need to subclass it on your own.
> >=20
> > So all things considered, I still tend to recommend the=20
> > DelegatingActionProxy approach, which doesn't affect=20
> RequestProcessor=20
> > choice at all. Just saving the "class" attribute above does=20
> not seem=20
> > to be enough benefit to accept the RequestProcessor=20
> subclass hassle.=20
> > Is there anything I miss here?
> >=20
> > Juergen
> >=20
> > P.S.:
> > I'm forwarding this to developer list for further feedback.
>=20
> Juergen,
>=20
> For our integration here, we ended up subclassing=20
> RequestProcessor.  The reason was because we're using xdoclet=20
> to build our struts-config.xml file.  So IIRC we couldn't use=20
> DelegatingActionProxy (or the similar
> alternatives) because we needed Xdoclet to read into our=20
> action classes.
>=20
> Hope that helps,
> Seth
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at=20
> ThinkGeek For a limited time only, get FREE Ground shipping=20
> on all orders of $35 or more. Hurry up and shop folks, this=20
> offer expires April 30th!=20
> http://www.thinkgeek.com/freeshipping/?cpg=3D> 12297
>=20
> _______________________________________________
>=20
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market...=20
> Oracle 10g.=20
> Take an Oracle 10g class now, and we'll give you the exam FREE.=20
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op=CCk
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20