Hi Vincent,
On Sun, 8 Aug 2004 12:21:40 +0200, Vincent Massol <[EMAIL PROTECTED]> wrote:
Hi John,
I think you're the first one to ask how to use Cactus to unit test Portlets!
Ok. There's a lot of interest here in being able to use this, so I'm hoping that the community can benefit from it too.
It should be relatively easy (but a big and long task) to implement support for Portlets inside Cactus and I'm all for integrating it into the project should you or someone provide a patch for it. Actually if someone is really keen to work on this and support it on the long term, I'd even prefer to make that person a committer on the project (after he's proved himself of course ;-)) as that person will be the best placed to fix bugs, improve the code, etc.
As a quickstart, here are the Java classes that would need to be implemented in the Cactus framework subproject:
* Create a PortletTestCase class (similar to the ServletTestCase one) * Create a PortletConfiguration interface + DefaultPortletConfiguration implementation class (again similar to the Servlet one) * Create PortletImplicitObjects, PortletTestCaller and PortletTestController classes * Create wrappers around Portlet implicit objects *if* need be only
Great. Thanks!
I have all of these (roughly) implemented, but it required a lot of duplicate code. I can't make use of most of the *Web* base classes even though much of the functionality is the same. Some of the problems are that many of the methods throw ServletException where I need to throw something like a PortletException (see the TestCaller implementations). Once I have this working, we should talk about some refactoring. It might be nice to have these methods throw something like a Cactus ContainerException and we could then wrap that in an API-specific exception in the redirectors.
It might make things cleaner if we added another abstract base class layer above the *Web* ones that had the common functionality to both sides.
That's the easy part but would be enough for users to start benefiting from it. They would need to manunally start their portlet container and manually deploy their Cactus tests into it though.
Cool.
The next step is to add support for Portlets inside the Cactus integrations subprojects, namely: the Ant integration subproject, the Maven integration subproject, create a Portlet Test Runner (similar to the Servlet Test Runner), etc.
Ant integration would be at the top of my list and I probably would not release anything until I had this. I've yet to use Maven, so this support would probably come later.
But again, this can be implemented bit by bit over time.
If you're interested in implementing this for Cactus, you would also need to follow the Cactus development guidelines (http://jakarta.apache.org/cactus/participating/coding_conventions.html, http://jakarta.apache.org/cactus/participating/apis.html).
Yup. Your coding standards are close enough to mine so that it's easy to stick to the rules.
I've created a separate "portlet" tree, parellel to share, j2ee12 and j2ee13 since the portlet spec is not part of J2EE yet. Let me know if you would like me to do otherwise.
The only request I'm asking is that if you wish to start this initiative, that you do it seriously and consistently over time. There's nothing as detrimental for an open source project as someone who start working on something and then stops midway (It happened to us with the Eclipse plugin for Cactus - The guy started and then left the project with something halfway working).
I totally understand. There are a few discussions going on internally about product focus and as soon as they are resovled I will know if I can commit to this project. I won't submit any code until I am sure I can dedicate the time / resources. The QA group in my division will be using this and I can use them to help support the functionality.
Let me know what you think and fire any specific questions you have!
So far, so good. Not that you have to deal with this, but the two biggest problems that I am going to face are:
1) Portlet invocation is done through a portal. All portals that I am familiar with provide the ability to render a single portlet, but everybody does it a bit differently. I'm going to need some flexible URL invocation code to make this work on multiple portals. 2) Servlets, JSPs and Filters have a single request/response object pair that they share for invoking the service() method. They then dispatch to the do*() methods via the HttpServlet. Portlets have two "service"-like methods, processAction() and render(). These methods take different request/response objects (although they are both subclasses of a base). The render() method dispatches to various do*() methods based on portlet mode. Unlike servlets which have well-defined HTTP methods that they handle, portlet developers can write custom modes. I hope to hide these differences in the TestController, but I may need to spider these changes all the way down to the tests themselves. Ugh!
Thanks! -John
Thanks -Vincent
-----Original Message----- From: John Rousseau [mailto:[EMAIL PROTECTED] Sent: vendredi 6 ao�t 2004 23:27 To: [EMAIL PROTECTED] Subject: Portlet support
Hi,
I'm new to cactus, but not to the concept. I wrote my own testbed (cactus- lite?) to exercise our servlet and JSP container using HttpUnit and some other tools early last year.
I'm currently working on our portlet container and I'd like to use cactus to exercise the implementation instead of rolling my own. We also have portlet writers here that would make use of this. Can somebody give me a quick laundry list of what I would need to implement / change to support testing portlets? Some of the classes needed are obvious, but any pointers to get me going would be very much appreciated.
I've searched the dev archives and didn't find any references to portlet. Has anyone done any work to support testing portlets with cactus before?
I'd, of course, be willing to contribute the changes back once I'm done.
Thanks -John
-- ---------------------------------------------------------------- John Rousseau [EMAIL PROTECTED] Novell, Inc. Phone: +1 781 464 8377 404 Wyman Street Fax: +1 781 464 8100 Waltham, MA 02451 http://www.novell.com ----------------------------------------------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- ---------------------------------------------------------------- John Rousseau [EMAIL PROTECTED] Novell, Inc. Phone: +1 781 464 8377 404 Wyman Street Fax: +1 781 464 8100 Waltham, MA 02451 http://www.novell.com ----------------------------------------------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
