Hi John, > -----Original Message----- > From: John Rousseau [mailto:[EMAIL PROTECTED] > Sent: vendredi 13 ao�t 2004 00:13 > To: Cactus Developers List > Subject: Re: Portlet support > > Hi Vincent, > > I ran my first successful portlet unit test last night. Yea! I've got a > lot of cleanup and testing to do, but I have a thin thread working.
That�s real cool :-) > > Your architecture is very modular and clean. My compliments. Thanks. It can still be improved a lot I think and introducing a new feature is the best way to realize what needs to be refactored... > > Can you give me the same laundry list of things to do to adapt the ant > integration? * There are 2 Ant tasks: <cactifywar> and <cactus>. How is a portlet deployed? As a WAR file? If so, you need to modify cactifywar so that it supports cactifying a portlet war. * For the <cactus> task, you need to implement the classes that starts/ stops the container you're working with (which is?) and the code that configures/deploys the portlet archive. For this, create a o.a.c.integration.ant.container.[containername] package. You can check the other similar packages to see how it's done for the other containers. Let me know if you have more specific questions. Thanks -Vincent > > Thanks > -John > > > On Wed, 11 Aug 2004 08:32:16 +0200, Vincent Massol <[EMAIL PROTECTED]> > wrote: > > > > > > >> -----Original Message----- > >> From: John Rousseau [mailto:[EMAIL PROTECTED] > >> Sent: mardi 10 ao�t 2004 16:07 > >> To: Cactus Developers List > >> Subject: Re: Portlet support > >> > >> 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. > > > > cool > > > >> > >> > 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. > > > > Agreed > > > >> > >> 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. > > > > Agreed > > > >> > >> > 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. > > > > Ok, cool > > > >> > >> > 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. > > > > That's nice ;-) > > > >> > >> 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. > > > > I think it's fine for now. > > > >> > >> > 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. > > > > Very cool. Thanks > > > >> > >> > 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. > > > > ok > > > >> 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! > > > > That's ok and from your description it appears as if making these > implicit > > container objects available from the PortletTestCase is the right way to > go > > (Please note that I am still portlet ignorant... I need to do some > reading). > > > > Thanks John > > -Vincent > > > > > > --------------------------------------------------------------------- > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
