You're finding some interesting things. If you find anything that would be easier to implement by changing an implementation of pluto, let us know. It's possible that any enhancements you'd need would also make someone else's life easier.
David On 12/5/05, Graham Klyne <[EMAIL PROTECTED]> wrote: > David, > > Thanks for your thoughts on my unit testing problems. > > This message is for information, in case anyone else should tread the same > path... > > David H. DeWolf wrote: > > You are correct. I'm not sure what your solution should be, but can't > > you do one of the following: > > > > 1) create your own ServletContext implementation and tell ServletUnit to > > use it > > I tried this, but ended up with another problem; this is an excerpt from my > notes at [http://wiki.oss-watch.ac.uk/PlutoNotes]: > > I tried modifying ServletUnitServletContext.getServletContext to return 'this' > in conjunction with a revised 'ServletRunner' setup that registers the > portlets > with the original 'ServletRunner' class, but this fails because it looks for > the > 'WEB-INF/portlet.xml' file in the 'portal' directory, when it is actually in > 'testsuite'. Further analysis of 'ServletRunner' shows that it contains a > single 'WebApplication' value, which in turn contains the context directory > and > path values. > > I also note that the 'ServletContext' implementation in uses a > 'WebApplication' > value to determine the location of a resource for 'getResourceAsStream', so > the > strategy of item (2) above cannot be used to serve different servlets from > different context directories. This suggests that multiple 'WebApplication's > must be created, and a common directory of path->'ServletContext' values be > maintained. A static 'Hashtable' value in 'WebApplication' could serve this > purpose, 'getServletContext' using this map returning a context value. > > I tried doing the change noted above, and the application ran a good deal > further. But, eventually, the portal driver uses 'getServletContext' > implemented by 'javax.servlet.GenericServlet.getServletContext()', meaning > that > attributes are not carried over from the ServletUnit environment. > Consequently, > the 'driverConfig' value set up for the testsuite is not defined, which > eventually results in a null pointer exception. (The Pluto portal driver > catches this and uses the exception stack-trace for the portlet rendering in > place of the intended portlet content; this is more difficult to detect than, > say, raising an exception when the target portlet cannot be located.) > > ... > > I am now reconsidering my options -- I'm not sure if it will be fruitful to > pursue this path. (Replacing the javax.servlet.GenericServlet implementation > that is accessed up by the Pluto portal driver might be an option...) > > #g > -- > > > 2) explicitly set ServletContext attributes during test initialization > > > > 3) Submit a patch to ServletUnit to let you do one of the above. > > > > David > > > > Graham Klyne wrote: > > > >> I seem to have run into a limitation of ServletUnit for testing Pluto > >> code. It > >> appears that when the portal driver attempts to retrieve a > >> ServerContext value > >> for the target portlet, ServletUnit simply returns a hard-coded null, > >> which > >> (unsurprisingly) results in portlet invocation failure. Also, it is > >> not clear > >> to me that ServletUnit has the ability to deal with more than one > >> servlet and/or > >> context in a single run (i.e. it reads a single application's web.xml > >> file, > >> without any obvious provision for dealing with more). > >> > >> I may take a little while longer to look at the ServletUnit code, but > >> it is > >> looking as if I may have to fall back on using HTTPUnit to test via a > >> running > >> Tomcat instance, which will make the tests slower to run than I would > >> have liked. > >> > >> Does anyone have any edifying thoughts, comments or pointers? > >> > >> #g > >> > > > > -- > Graham Klyne > For email: > http://www.ninebynine.org/#Contact > >
