Hey Janne and others working on the Portlet support,
Great job of getting portlet support for Wicket finally started up!
I've build and deployed the portlet-samples to Jetspeed-2 (trunk) and first
impressions are good!
After playing around a bit, I did encounter some issues though ;)
And I have a few questions about some choices you made for the implementation.
- you removed the web.xml from the portlet-samples, but you definitely do need
it as it won't build
otherwise, although it shouldn't contain a Pluto PortletServlet for sure.
I fixed it by simply adding an empty web.xml with only a display-name
element.
On Jetspeed, you don't need nothing more to get it running.
- I noticed you configure the PortletApplication in portlet.xml as a preference.
That I find a bit odd as those kind of setup info is usually provided
through init parameters
(just as you would do with servlets). I think Preferences really are meant
for a different usage.
- In my initial shot at portlet support for Wicket I intended to provide a
solution which would allow
Wicket web applications easily migrated to portlet applications or even run
in dual mode.
For this, I tried to start with an inheritance model which would require
hardly (if even needed)
modification by a developer. As far as I can see (but I must admit I have
only yet glanced at the code),
you choose to use a parallel class model which will make this much harder.
Know that I'm not criticizing this choice at all (I hardly have credits to
do so), and your route is
somewhat easier to follow this way, but I'd like to know if this is a
deliberate choice or more one
to get a quicker working result (which I definitely can agree to).
- Now the "issue" I encountered: I added the same WicketPortlet twice on the
same page, to check how it
would handle independent state between the two instances... Well, there it
currently breaks down.
Now, when I click the "click here" link in the first PortletWindow, no "Lick
clicked" message is displayed,
and if I subsequently click the "click here" link in the second
PortletWindow, I get the following
stack trace:
java.lang.NullPointerException
at wicket.PageMap.removeEntry(PageMap.java:335)
at wicket.PageMap.access(PageMap.java:635)
at wicket.PageMap.get(PageMap.java:459)
at wicket.Session.getPage(Session.java:413)
at
wicket.protocol.http.portlet.PortletRequestTargetResolverStrategy.resolveRenderedPage(PortletRequestTargetResolverStrategy.java:157)
at
wicket.protocol.http.portlet.PortletRequestTargetResolverStrategy.resolve(PortletRequestTargetResolverStrategy.java:120)
at
wicket.request.compound.AbstractCompoundRequestCycleProcessor.resolve(AbstractCompoundRequestCycleProcessor.java:48)
at wicket.RequestCycle.step(RequestCycle.java:942)
at wicket.RequestCycle.steps(RequestCycle.java:1034)
at wicket.RequestCycle.request(RequestCycle.java:453)
at
wicket.protocol.http.portlet.WicketPortlet.render(WicketPortlet.java:240)
at
org.apache.jetspeed.factory.JetspeedPortletInstance.render(JetspeedPortletInstance.java:102)
at
org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:230)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
at
org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:215)
at
org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(ServletPortletInvoker.java:126)
at
org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119)
at
org.apache.jetspeed.container.JetspeedPortletContainerWrapper.renderPortlet(JetspeedPortletContainerWrapper.java:120)
[...]
After looking around a bit in the code, I noticed that the
PortletApplication.getSessionAttributePrefix(...) method uses
(only) the request contextPath for build up the prefix.
But, because two instances of the same portlet will share both the same name
and the contextPath, I've got the feeling this
might be causing them to share the same key and thus clashing in their state
management. As far as I could see, you don't
use (yet) PortletSession.PORTLET_SCOPE attributes to keep these apart.
I haven't yet had time to really debug this so maybe I'm way off track here
though.
- A somewhat related issue is the WicketPortlet.destroy() method.
A Portlet container is allowed to destroy portlet instances under certain
conditions (like a Portlet throwing a
PortletNotAvailableException). Now, the current implementation of
PortletApplication seems only capable of handling one portlet
and is destroyed it self when the WicketPortlet.destroy() method is called.
So, I think this part definitely needs to be extended because only one
portlet per each portlet application is a bit too limiting.
Besides these issues, I really find it great to be able to look at and already
somewhat interact with a WicketPortlet.
I certainly never got that far :)
Definitely thumbs up from me.
And while I don't have much time to actively help out right now, I certainly am
willing to run tests now and then
and give more feedback if you like.
Regards,
Ate
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop
