[Design of JBoss Portal] - exception in HellowIPCportlet
by siyangsi
I downloaded HellowIPCportlet and try to deploy JBOSS portal server 2.4.
It throw me an excpetion says getPortalNode is not a method of JBossRenderRequest, which is true ( at least for the version I used).
I removed this trunk, compile and deploy again, this time I can see two portlets sit side by side in one page, but after I click the submit button.
It throws me an exception again, any advises?
2006-09-19 17:21:31,941 ERROR [org.jboss.portlet.hello.HelloWorldPortletA] The portlet threw an exception
javax.portlet.PortletException: Nothing to invoke
at org.jboss.portlet.JBossPortlet.processView(JBossPortlet.java:231)
at org.jboss.portlet.JBossPortlet.processDispatch(JBossPortlet.java:134)
at org.jboss.portlet.JBossPortlet.processAction(JBossPortlet.java:109)
at org.jboss.portlet.JBossPortlet.processAction(JBossPortlet.java:379)
at org.jboss.portal.portlet.container.PortletContainer.invokeAction(PortletContainer.java:494)
at org.jboss.portal.portlet.container.PortletContainer.dispatch(PortletContainer.java:435)
at org.jboss.portal.portlet.container.PortletContainerInvoker$1.dispatch(PortletContainerInvoker.java:143)
at org.jboss.portal.portlet.invocation.PortletInvocation.dispatch(PortletInvocation.java:242)
at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portlet$TransactionInterceptor$invokeNotSupported$aop(TransactionInterceptor.java:85)
at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:101)
at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeNotSupported(TransactionInterceptor.java)
at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:55)
at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheInterceptor.java:45)
at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:59)
at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:55)
at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(PortletSessionSynchronizationInterceptor.java:76)
at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$InvokeNextCommand.execute(ContextDispatcherInterceptor.java:124)
at sun.reflect.GeneratedMethodAccessor334.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.portal.server.servlet.CommandServlet.doGet(CommandServlet.java:104)
at org.jboss.portal.server.servlet.CommandServlet.doPost(CommandServlet.java:161)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
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:539)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.include(AbstractRequestContext.java:193)
at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.include(ContextDispatcherInterceptor.java:68)
at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:84)
at
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972749#3972749
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972749
19 years, 6 months
[Design of JBoss Portal] - Re: WANTED: Input from administrators & developers
by dhartford
anonymous wrote : 2) CMS control - it would be cool if you could deploy a single (or clustered) CMS "server" and deploy content links as required to all instances of portal via ON. this might be a bit bloated, not sure of implications and whether portal could fully handle it.
Seperating out the CMS "server"/repo would definately help, not only for jboss portal but also as a seperate file-repository to develop against (aka WebDAV/JCR repo for other than just portal-CMS).
It would be great to deploy a 'Jboss Repo' that stores the CMS content and have the jboss-portal upgrades be seperated/less dependent of the repo. Could also setup CMS-bundles that are added to the repo and point to them from jboss-portal.
As another item, would be nice to have seperate administration/backup functionality that is domain-knowledge-specific to the repository versus the portal (i.e. portal admins deal with portal stuff, storage admins deal with storage stuff).
my two coppers,
-D
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972715#3972715
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972715
19 years, 6 months
[Design of JBoss Portal] - Re: WANTED: Input from administrators & developers
by bogdan.sulima
Hallo JBoss Team :)
I just started to evaluate JBoss Portal Server. You did a good job and i am looking forward to help you in improving Portal.
XML import
"thomas.heute(a)jboss.com" wrote :
| - Change datasource (copy data over)
| - Pages definition export from database to XML (-objects.xml, -instances.xml).
WPS (WebSphere Portal Server) has very nice XML import/export interface (XMLAccess) that allows developers and administrators to import/export entire portal configuration or desired parts of the configuration (portlet instances, pages, users and so on). Such robust xml import/export alows you to migrate to new version of the portal, switch from one DB/LDAP to another (without creating some DB-specific scripts or dumps), reproduce portal environment to local development and so on.
So the idea is quite simple:
- all the data that is stored in DB should be also configurable via xml.
- unique names (not DB ids) must be provided/generated for all portal objects.
- unique names offer common and simple lookup in xml scripts, render-url generation (can be used in Themes or CMS portlets for linking to portal pages/portlets).
It is possible to merge contents of the -object.xml and -instances.xml and extend it with additional data for exporting user/group information. Such "config.xml" can evolve with the new versions of the portal, but will still contain data in quite abstract format in order to provide backward compatibility between portal versions.
Portal Model
In object.xml developer may specify custom properties for dirrerent portal nodes. Is it possible to provide read access to these properties via PortalNode interface? In this case developer can access these helpfull properties in jsp (via taglib?) or portlet without using PortalObjectContainer.
Layout
Is it possible to use JSP in order to create custom RenderSet? This will keep layout element consistent as jsp's. Some jsp tags can be provided to access custom properties and other objects that are important for rendering.
Bogdan.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972704#3972704
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972704
19 years, 6 months