You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-dev@jakarta.apache.org by John Rousseau <JR...@novell.com> on 2004/08/06 23:27:24 UTC
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 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
Re: Portlet support
Posted by John Rousseau <JR...@novell.com>.
Hi Vincent,
Sorry for the delay in responding. I was away for a few days.
On Mon, 23 Aug 2004 10:59:39 +0200, Vincent Massol <vm...@pivolis.com> wrote:
>> I'm a bit stuck with the ant tasks. Let me give you a little background.
>>
>> A portlet (or set of portlets) is deployed as a class(es) in a WAR file.
>> It's a regular WAR file which also contains a /WEB-INF/portlet.xml
>> descriptor.
>
> Ok. So there is no web.xml file, right?
Yes there it. It's a regular WAR file. Portlets can include (properly written) servlets and JSPs through a RequestDispatcher. The portlet model is very similar to the servlet one in many ways. There is no association with the servlets and servlet mappings in the web.xml with the portlets in the WAR though. There's also a required portlet.xml DD, which we probably should modify so that it lists the PortletTestRedirector, but there is no direct URL assoication with the portlets in the portlet.xml. It's all up to the portal.
>> The portlet
>> redirector will be deployed in the portlet WAR being tested. Any ideas on
>> how you would like the task syntax to look to handle this?
>
> From what I understood, there are no web.xml file in a portlet application
> and thus the cactifywar should not try modify the web.xml file. However it
> should add the Cactus jars. Then at execution time (i.e. the <cactus> task,
> we need to pass some information, namely the URLs to call the portlet
> redirector.
>
> I think the best solution would be to:
>
> 1/ create a separate Ant task: <cactifyportletwar> or something like this
> that would reuse some code from cactifywar but not try to modify a web.xml
> file. Alternatively maybe there is a possibility of modifying the existing
> cactifywar and add an attribute to it (such as: cactifywebxml =
> "true|false", defaults to true).
Ok. Sounds good.
> 2/ create a nested element for the <cactus> task, say <novellportal> (I
> don't know the portal container name) and make it support the portlet
> redirector URLs as attributes.
Yeah. We need this for all the common portals. It's a tiny bit of code for each portal, but I don't think a simple "redirectorUrl" element will suffice.
> Of course it won't be that easy (there might be some issues with ping URLs
> for example) :-).
Yup. Already ran into this. :-)
Ok. Thanks. Others reading this list have already sent me mail privately, so there does seem to be some interest.
I'm still waiting for Novell to say it's ok for me to contribute. Once that happens, I'll send you my code to review.
> Thanks
> -Vincent
Thanks
-John
--
----------------------------------------------------------------
John Rousseau JRousseau@novell.com
Novell, Inc. 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
RE: Portlet support
Posted by Vincent Massol <vm...@pivolis.com>.
Hi John,
> -----Original Message-----
> From: John Rousseau [mailto:JRousseau@novell.com]
> Sent: vendredi 13 août 2004 18:38
> To: Cactus Developers List
> Subject: Re: Portlet support
>
> On Fri, 13 Aug 2004 10:35:40 +0200, Vincent Massol <vm...@pivolis.com>
> wrote:
>
> >> 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.
>
> Hi Vincent,
>
> I'm a bit stuck with the ant tasks. Let me give you a little background.
>
> A portlet (or set of portlets) is deployed as a class(es) in a WAR file.
> It's a regular WAR file which also contains a /WEB-INF/portlet.xml
> descriptor.
Ok. So there is no web.xml file, right?
> This is called a portlet application. There is no URL mapping
> information in the portlet.xml file. It's up to the portal (a separate
> peice of software, often "installed" on the app server, not deployed) to
> determine how to call the portlets. The common pattern is that a portal
> renders pages with portlets on them, so there is no direct link between a
> portlet and the URL that invokes it. Most portals do however have some URL
> syntax that allows you to invoke a portlet directly for testing purposes.
> As I mentioned earlier, all portals do this differently.
>
> Currently the catifywar task modifies the web.xml to add the URL mapping
> to the appropriate redirector. This isn't meaningful in the portlet case
> because there is no mapping to the portlet in the portlet war.
>
> What I need to do is add some parameter to the cactus task to specify the
> URL to use to get the portal to render the portlet redirector.
Ok
> The portlet
> redirector will be deployed in the portlet WAR being tested. Any ideas on
> how you would like the task syntax to look to handle this?
>From what I understood, there are no web.xml file in a portlet application
and thus the cactifywar should not try modify the web.xml file. However it
should add the Cactus jars. Then at execution time (i.e. the <cactus> task,
we need to pass some information, namely the URLs to call the portlet
redirector.
I think the best solution would be to:
1/ create a separate Ant task: <cactifyportletwar> or something like this
that would reuse some code from cactifywar but not try to modify a web.xml
file. Alternatively maybe there is a possibility of modifying the existing
cactifywar and add an attribute to it (such as: cactifywebxml =
"true|false", defaults to true).
2/ create a nested element for the <cactus> task, say <novellportal> (I
don't know the portal container name) and make it support the portlet
redirector URLs as attributes.
Of course it won't be that easy (there might be some issues with ping URLs
for example) :-).
>
> I'm currently deploying our (Novell's) own portable portal and portlet
> container on JBoss 3.2.5, but we can run on the Novell ExteNd app server
> as well as WebLogic, WebSphere and straight Tomcat. The current appserver
> specific invocation code should work fine, we just need a way to tell it
> what URL to invoke.
>
> Thoughts?
See above and let me know if it would work.
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: Portlet support
Posted by John Rousseau <JR...@novell.com>.
On Fri, 13 Aug 2004 10:35:40 +0200, Vincent Massol <vm...@pivolis.com> wrote:
>> 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.
Hi Vincent,
I'm a bit stuck with the ant tasks. Let me give you a little background.
A portlet (or set of portlets) is deployed as a class(es) in a WAR file. It's a regular WAR file which also contains a /WEB-INF/portlet.xml descriptor. This is called a portlet application. There is no URL mapping information in the portlet.xml file. It's up to the portal (a separate peice of software, often "installed" on the app server, not deployed) to determine how to call the portlets. The common pattern is that a portal renders pages with portlets on them, so there is no direct link between a portlet and the URL that invokes it. Most portals do however have some URL syntax that allows you to invoke a portlet directly for testing purposes. As I mentioned earlier, all portals do this differently.
Currently the catifywar task modifies the web.xml to add the URL mapping to the appropriate redirector. This isn't meaningful in the portlet case because there is no mapping to the portlet in the portlet war.
What I need to do is add some parameter to the cactus task to specify the URL to use to get the portal to render the portlet redirector. The portlet redirector will be deployed in the portlet WAR being tested. Any ideas on how you would like the task syntax to look to handle this?
I'm currently deploying our (Novell's) own portable portal and portlet container on JBoss 3.2.5, but we can run on the Novell ExteNd app server as well as WebLogic, WebSphere and straight Tomcat. The current appserver specific invocation code should work fine, we just need a way to tell it what URL to invoke.
Thoughts?
Thanks
-John
--
----------------------------------------------------------------
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
RE: Portlet support
Posted by Vincent Massol <vm...@pivolis.com>.
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.
Thats 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 <vm...@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 <vm...@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
Re: Portlet support
Posted by John Rousseau <JR...@novell.com>.
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.
Your architecture is very modular and clean. My compliments.
Can you give me the same laundry list of things to do to adapt the ant integration?
Thanks
-John
On Wed, 11 Aug 2004 08:32:16 +0200, Vincent Massol <vm...@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 <vm...@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
RE: Portlet support
Posted by Vincent Massol <vm...@pivolis.com>.
> -----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 <vm...@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
Re: Portlet support
Posted by John Rousseau <JR...@novell.com>.
Hi Vincent,
On Sun, 8 Aug 2004 12:21:40 +0200, Vincent Massol <vm...@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.
> 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:JRousseau@novell.com]
>> Sent: vendredi 6 août 2004 23:27
>> To: cactus-dev@jakarta.apache.org
>> 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 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
>
>
--
----------------------------------------------------------------
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
RE: Portlet support
Posted by Vincent Massol <vm...@pivolis.com>.
Hi John,
I think you're the first one to ask how to use Cactus to unit test Portlets!
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
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.
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.
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).
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).
Let me know what you think and fire any specific questions you have!
Thanks
-Vincent
> -----Original Message-----
> From: John Rousseau [mailto:JRousseau@novell.com]
> Sent: vendredi 6 août 2004 23:27
> To: cactus-dev@jakarta.apache.org
> 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 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