Running a simple servlet in a model   

To run a servlet in any web application, basically you need the servlet implementation available to the appserver's classloader (eg, either in a shared location or preferably in the WAR's WEB-INF/lib folder) and you need an entry in the web application's web.xml deployment descriptor.

The web.xml deployment descriptor is generated from a template when WPF generates the WAR, depending on which type of WAR it's generating, where the templates live under the project's WEB-INF/bin/deployment/... folder.

For WPF 6.1.2 and prior, you have to edit the web.xml template itself, which will allow you to add to the generated web.xml, but has the side effect that during upgrade you are prompted whether to overwrite your changes (and thus lose your changes unless you copy them and reapply them) or not overwrite (and thus possibly miss an important update that the WPF upgrade provides). In the WPF next beta that's out there now, and in the upcoming WPF 6.1.5 release, there is a new capability to add "fragments" of a web.xml (and portlet.xml) in separate files under WEB-INF/bin/deployment/extensions/... which will then be added to web.xml and/or portlet.xml when we generate them, thus avoiding the upgrade issue with out of the box WPF files.

What is it that these servlet(s) do that you're trying to preserve? Sometimes the classes from former projects are better used via LJOs than via hard coded servlets (since the latter often means you're not making best use of WPF automation capabilities).

..mb1

You may not have placed the servlet info in the right template.
I believe Tomcat would use standalone.web.xml as the template, WASCE would use wasce.web.xml and a jsr portlet WAR would use portlet.standard.web.xml as the template for web.xml.

I still recommend trying to convince the customer that using the code (as opposed to the old servlets) in your WPF portlets would give you a lot more flexibility and value out of WPF rather than hardwiring old servlets into the WAR.

Another option may be to use WP Web Clipping (outside of WPF) for the old servlet based stuff, and build the new portlets with WPF.

..mb1

No, they wouldn't by default do that.

Portlets receive a PortletRequest from the Portal, do their thing, and then the PortletResponse is handed back to the Portal's controller and the portal takes any output sent to portlet response and figures out how and where to place it within the portal page.

Servlets receive a Servlet Request from the AppServer's servlet container, and typically write to the Servlet output stream (either directly or by dispatching to a JSP page). So if you go directly to a servlet, you're not going through the portal controller and thus your output won't by default be part of the portal page.

If you put a link to a servlet URL in a portlet page (WPF or any other) then what's most likely to happen is that the browser will go directly to that servlet when you click on it, and get the servlet's output and render that as the entire response page, so you'd effectively be leaving the portal.

You may be able to use an IFrame builder and have the IFrame go to the servlet (thus the browser would continue to hang onto the outer portal page). Or you may be able to use the Portal's Web Clipping functionality to turn the existing servlet based app into a portlet.

But in either of those cases, you're not really using the value of WPF, which is automating the back end access and automating and customizing the user interface. The best case would be to try to use the existing Java code that the servlets are based on, from portlet model(s), so that you can actually make use of a lot of WPF's automation and benefits..

..mb1