I am sorry Sunil. I have not deployed my portlet application on any other container.

Raj

Tiwari, Sunil Kumar wrote:

Hi Raj,

Thanks for replying.
I am not using JSF portal bridge.

I am following the simple steps as described by Stan Silvert in Myfaces 
conference in San Diego.
He says that any myfaces web app can be converted into a JSR 168 compliant 
portlet which shd then ideally run on any JSR 168 compliant portal server.

I downloaded the myfaces web application examples from apache site.
I added portlet.xml to one of the web application with the portlet class as 
MyfacesGenericPortlet and set the default-view init parameter to one of the jsp 
file
described in faces-config.xml

I deployed it on jetspeed and it worked fine. It works fine on JBoss too. But 
it doesnt work on websphere portal server.
Its true that a portal container does add some specific stuff like Jetspeed 
adds JetspeedContainerServlet to the web.xml in the deployment process.
But then all JSR 168 portal server must be able to run a JSR 168 compliant 
portlet.

I just wanted to know if someone has come across this problem and know some 
work around for it.

We have some web apps based on myfaces. And we want to convert them into JSR 
168 portlets so that they can be run on Websphere.

Now the interesting thing is that a JSR 168 compliant portlet devloped using 
IBM tool runs smoothly on Jetspeed without making any jetspeed specific change.
But it doesnt work the other way round :(

Has anyone faced this problem? If yes, Could you share your views on this topic?

Thanks,
Sunil




-----Original Message-----
From: Raj Saini [mailto:[EMAIL PROTECTED]
Sent: Wed 2/8/2006 10:01 PM
To: Jetspeed Users List
Subject: Re: [J2] web.xml configuration requirements

Sunil,

I think you are confused between the JetspeedContainerServlet and portal
bridge. JSF application needs portal bridge to work as Portlet application.
Portal bridges are independent of Jetspeed. Therefore, if you use portlet
bridge liks JSF, your portlet application should (theoretically) on any
other portal server. However, you will need the portel server specific
deployment mechanism

Your JSF portlet application using portal jsf bridge should not be specific
to Jetspeed. It should work on Websphere, provided you use Webspare specific
deployment tools. You will also need the portal jsf bridge library in your
portlet web application.

Regards,

Raj



On 2/8/06, Tiwari, Sunil Kumar <[EMAIL PROTECTED]> wrote:
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]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to