jakarta-cactus-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@pivolis.com>
Subject RE: Portlet support
Date Fri, 13 Aug 2004 08:35:40 GMT
Hi John,

> -----Original Message-----
> From: John Rousseau [mailto:JRousseau@novell.com]
> 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 <vmassol@pivolis.com>
> wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: John Rousseau [mailto:JRousseau@novell.com]
> >> 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 <vmassol@pivolis.com>
> >> 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: cactus-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
> >
> >
> 
> 
> 
> --
> ----------------------------------------------------------------
> John Rousseau                               JRousseau@novell.com
> 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: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org


Mime
View raw message