>From: "CONNER, BRENDAN (SBCSI)" <[EMAIL PROTECTED]> 
>
> Are you saying I should register my delegates as JSF managed beans? 
> 

Sure, why not?  The faces IoC container is not spring but you could still have 
some of the same benefits.  In fact, you could snap in Spring down the road 
using the Shale Spring integration 
(http://struts.apache.org/struts-shale/features-spring-integration.html).

Gary


> - Brendan 
> 
> -----Original Message----- 
> From: Gary VanMatre [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, February 22, 2006 2:49 PM 
> To: Struts Users Mailing List 
> Subject: RE: Re: [SHALE] Using the Test Framework 
> 
> 
> >From: "CONNER, BRENDAN (SBCSI)" 
> > 
> > In case anyone else was in the same boat I was in trying to run the 
> Shale Test 
> > Framework "in isolation" on the Web Tier of a 3-tier application, I 
> did come up 
> > with a technique that doesn't depend upon Spring. This is in the 
> context of 
> > using IBM's RSA IDE, but I imagine a similar technique would work in 
> other 
> > development environments. 
> > 
> > 1. I defined a simple Java project to contain the Shale Test framework 
> code (and 
> > JAR files) 
> > 2. I set up a dependency between that Java project and the Web 
> (application) 
> > project 
> > 3. I copied the delegate classes from the application to my new test 
> project, 
> > keeping the package names the same 
> > 4. I modified the new "mock" delegate classes to be stubs so they did 
> not try to 
> > invoke the EJB tier 
> > 
> > Then when I ran JUnit on the test project, it invoked the application 
> method, 
> > which proceeded to invoke the delegate, but the classloader loaded the 
> "mock" 
> > delegate class ahead of the application's delegate class, so the test 
> proceeded 
> > without invoking the EJB tier. 
> > 
> 
> If you registered your delegate's as managed beans, you wouldn't have to 
> make your mock delegates live in the same packages with the same names 
> (#3). Rather, you would have to register them with the Shale mock JSF 
> test framework in your test cases (design with more spring :-). 
> 
> Gary 
> 
> --------------------------------------------------------------------- 
> To unsubscribe, e-mail: [EMAIL PROTECTED] 
> For additional commands, e-mail: [EMAIL PROTECTED] 
> 

Reply via email to