Assuming that you know this page:
http://cwiki.apache.org/WICKET/portal-howto.html
You should just copy the web.xml portlet.xml of an already working uPortal
porlet (even if it's not Wicket based) and use the same filters /
listeners... Theses are portal-dependent plumbery, and I use eXo, so I
Yep I've seen that page. uPortal is Portlet 1.0 based (Pluto).
Do you mean add the same filters/listeners as a Wicket based application would
normally use to the normal uPortal descriptors? Because a uPortal portlet can
have an empty web.xml (it gets re-written by the Pluto assembly) and a
eXo is currently portlet 2.0 so I know nothing regarding portlet 1.0 Wicket
integration. You'll find working portlets for eXo in the standard eXo
distribution. Just copy their filters listeners into your own
Wicket-portlet.
What I mean regarding this copy: depending upon your portal, your
Thanks Pierre.
Ok so a basic uPortal portlet doesn't need anything in web.xml. When you
deploy, as part of the spec it must be run through the Pluto Assembly which
writes the necessary config (also available as a Maven plugin which is what I
use). So you can just leave it empty and then it's
Steve,
Unfortunately, I ran out of time, so I could not test in uPortal. Anyway,
just mail me and I'll send you my (eXo) standard web.xml and portlet.xml.
I'd like not to pollute the list with two annotated, big files.
Moreover, here's a useful link: http://portals.apache.org/bridges/
I used to
I've got a simple Wicket based portlet working in uPortal 3.1.1 now.
However, my implementation of ServletContextProvider is just a stub so have
a feeling it's going to eventually explode again. I'm really interested in
seeing a working implementation of ServletContextProvider if anyone has come