Sunil, Each portal vendor has its own proprietary way of deploying a JSR-168 compliant portlets (containing a basic web.xml & portlet.xml) into the container.
Jetspeed2 comes with its own deployer (that will listen on the jetspeed\web-inf\deploy folder for the arrival of WAR files). Jetspeed takes the WAR file and enriches it with some jetspeed specific artifacts. Among other things, it will add the JetspeedContainerServlet (and mapping) to the web.xml At that point, The JSR-168 compliant portlet has been changed into a Jetspeed specific portlet. That WAR file shouldn't be deployed on any other portal server besides jetspeed. It doesn't make any sense to deploy it on Jboss as it would a) require Jboss to have jetspeed JAR files in it's classpath b) not make any sense, as jboss will effectively do something similar to the WAR at deploy time (turning the jetspeed specific WAR file into a jboss specific WAR file by adding jboss specific elements). I highly doubt that Jboss would ever use the JetspeedContainerServlet when accessing your portlet. The only thing it does is create an unnecessary dependency with the jetspeed libraries. The starting point should always be a JSR-168 compliant portlet with no vendor specific extensions. It should only have a dependency with the portlet-api.jar, and should not have any dependencies on jetspeed. As far as your JSF question goes; Turning JSF into a portlet has nothing to do with Jetspeed. The portal bridges project provides a JSF bridge to produce JSR-168 compliant portlets. (http://portals.apache.org/bridges/multiproject/portals-bridges-jsf/inde x.html) These can off course be deployed on jetspeed2 (effectively causing the JetspeedContainerServlet to be added to web.xml), but it can also be deployed on Jboss (causing Jboss specific items to be added to web.xml) Greetings, Davy -----Oorspronkelijk bericht----- Van: Tiwari, Sunil Kumar [mailto:[EMAIL PROTECTED] Verzonden: woensdag 8 februari 2006 18:36 Aan: Jetspeed Users List Onderwerp: RE: [J2] web.xml configuration requirements Hi Raj, A few questions on JetspeedContainerServlet. This is required when you try to convert a myfaces web app into a JSR 168 portlet(based on the guidelines provided by Stan Silvert). This works fine on jetspeed2 but I tried running the same war file on IBM Webpshere portal and it didn't run. Now the question is whether this conversion of web app into a portlet is specifically meant for jetspeed2 portal only? JetspeedContainerServlet seems to be very specific to jetspeed2. But Stan has said that it works fine on JBoss portal server also. It means either that the resultant portlet is a JSR 168 one which can run on any JSR168 compliant portal server or jetspeed2 and Jboss are very similar in architecture. Have you tried running it on some other portal server like liferay, webspehere etc? Thanks, Sunil -----Original Message----- From: Raj Saini [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 08, 2006 12:50 PM To: Jetspeed Users List Subject: Re: [J2] web.xml configuration requirements Aaron Evans wrote: >Raj Saini <rajsaini <at> gmail.com> writes: > > > >>You need JetspeedContainerServlet and its mapping in your web.xml if you >>dont drop your .war in jetspeed deploy folder. Jetspeed deploy folder will >>add servlet and its mapping into web.xml when it deploys the wars. >> >>If you deploy your portlets as directory (expanded wars) you will need to >>add JetspeedContainerServlets and its mapping in your web.xml file. >> >>Regards, >> >>Raj >> >> >> > >Thanks, I must have copied my web.xml from a portlet web application that was >already deployed when I was building my latest one. > >I am still puzzled about having to include the following block in my web.xml. > > <security-role> > <description>The admin role</description> > <role-name>admin</role-name> > </security-role> > >If I do not include this block, the deployment of the war file via jetspeed >will fail. > > > I am not sure, why do you need this in your portlet application's web.xml. However, this is required in portal application's web.xml and I never explored why it is needed. My portal uses Jetspeed's default security configration. Thanks, Raj >Why must I include this role declaration? > >The logs are not helpful in determining the problem. deployment.log just says: > >Failed to load portlet application for portlet-app > >And the tomcat logs have this stack trace, but again, not very useful: > > INFO: Remove all registry entries defined for portlet application portlet-app > INFO: Loading portlet.xml....portlet-app > INFO: No extended metadata found. > INFO: Loading web.xml....portlet-app >ERROR: Failed to load portlet application for portlet-app >- JetspeedContainerServlet: initialization failed for Portlet Application at: >portlet-app >org.apache.jetspeed.components.portletregistry.RegistryException: >Failed to load portlet application for portlet-app > at org.apache.jetspeed.tools.pamanager.PortletApplicationManager. >registerPortletApplication(PortletApplicationManager.java:273) > at org.apache.jetspeed.tools.pamanager.PortletApplicationManager. >startPA(PortletApplicationManager.java:372) > at org.apache.jetspeed.tools.pamanager.PortletApplicationManager. >startPortletApplication(PortletApplicationManager.java:120) > at org.apache.jetspeed.container.JetspeedContainerServlet. >attemptStart(JetspeedContainerServlet.java:168) > at org.apache.jetspeed.container.JetspeedContainerServlet. >access$200(JetspeedContainerServlet.java:52) > at org.apache.jetspeed.container.JetspeedContainerServlet$1. >run(JetspeedContainerServlet.java:139) > at java.util.TimerThread.mainLoop(Timer.java:512) > at java.util.TimerThread.run(Timer.java:462) > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
