[JBoss JIRA] Created: (JBPORTAL-1369) problem with mission-critical and render set to divRenderNoAjax
by Prabhat Jha (JIRA)
problem with mission-critical and render set to divRenderNoAjax
---------------------------------------------------------------
Key: JBPORTAL-1369
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1369
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Theme
Affects Versions: 2.6.CR2
Reporter: Prabhat Jha
Assigned To: Julien Viet
1. Login as admin
2. Click on Theme for default portal
3. Change theme to mission-critical and render set to divRenderNoAjax
4. Logout
It takes you to http://localhost:8080/portal/portal/default and you can not see/do a thing. :-( Did I do something stupid or there is something wrong?
The error I see is
2007-04-30 10:56:35,187 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/portal-core].[jsp]] Servlet.service() for servlet jsp threw exception
java.lang.NullPointerException
at org.jboss.portal.theme.impl.render.dynamic.DynaMergeBehavior.mergeForWindow(DynaMergeBehavior.java:51)
at org.jboss.portal.theme.impl.render.dynamic.DynaWindowRenderer.render(DynaWindowRenderer.java:70)
at org.jboss.portal.theme.render.RendererContext.render(RendererContext.java:225)
at org.jboss.portal.theme.impl.JSPRendererContext.render(JSPRendererContext.java:66)
at org.jboss.portal.theme.impl.render.div.DivRegionRenderer.renderBody(DivRegionRenderer.java:69)
at org.jboss.portal.theme.render.RendererContext.render(RendererContext.java:234)
at org.jboss.portal.theme.impl.JSPRendererContext.render(JSPRendererContext.java:66)
[ Show » ]
Prabhat Jha [30/Apr/07 12:13 PM] The error I see is 2007-04-30 10:56:35,187 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/portal-core].[jsp]] Servlet.service() for servlet jsp threw exception java.lang.NullPointerException at org.jboss.portal.theme.impl.render.dynamic.DynaMergeBehavior.mergeForWindow(DynaMergeBehavior.java:51) at org.jboss.portal.theme.impl.render.dynamic.DynaWindowRenderer.render(DynaWindowRenderer.java:70) at org.jboss.portal.theme.render.RendererContext.render(RendererContext.java:225) at org.jboss.portal.theme.impl.JSPRendererContext.render(JSPRendererContext.java:66) at org.jboss.portal.theme.impl.render.div.DivRegionRenderer.renderBody(DivRegionRenderer.java:69) at org.jboss.portal.theme.render.RendererContext.render(RendererContext.java:234) at org.jboss.portal.theme.impl.JSPRendererContext.render(JSPRendererContext.java:66)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 10 months
[JBoss JIRA] Created: (JBPORTAL-1315) CMS content rendered with wrong tx on thread
by David Allen (JIRA)
CMS content rendered with wrong tx on thread
--------------------------------------------
Key: JBPORTAL-1315
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1315
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal CMS
Affects Versions: 2.6.Alpha2
Reporter: David Allen
Assigned To: Roy Russo
This might be a problem in "core" or somewhere else, but this only occurs with windows containing CMS content. The exact steps which cause it are:
1. Display a page with a CMS content window in a new browser window.
2. Click on the login link on the dashboard.
3. When the same page is rendered after successful login (now under authsec), the following exception occurs and the CMS content is not displayed (replaced with exception):
2007-03-09 16:02:06,874 ERROR [org.jboss.portal.server.servlet.PortalServlet] Unexpected exception
java.lang.IllegalStateException: Wrong tx on thread: expected TransactionImpl:XidImpl[FormatId=257, GlobalId=tines/83, BranchQual=, localId=83], actual TransactionImpl:XidImpl[FormatId=257, GlobalId=tines/84, BranchQual=, localId=84]
at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:162)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
at org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:381)
If more of the stack trace is needed, let me know. The rest doesn't look that useful -- just the usual processing. The same exception causes many different classes to log the error along the way, so I hope I picked up the right log message here.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 10 months
[JBoss JIRA] Resolved: (JBPORTAL-859) Support portlet which use GET method in forms.
by Julien Viet (JIRA)
[ http://jira.jboss.com/jira/browse/JBPORTAL-859?page=all ]
Julien Viet resolved JBPORTAL-859.
----------------------------------
Resolution: Rejected
was commented as non feasible, but not resolved
> Support portlet which use GET method in forms.
> ----------------------------------------------
>
> Key: JBPORTAL-859
> URL: http://jira.jboss.com/jira/browse/JBPORTAL-859
> Project: JBoss Portal
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Portal WSRP
> Affects Versions: 2.4 Final
> Reporter: Chris Laprun
> Assigned To: Chris Laprun
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> We probably need to add an element similar to remotable to the jboss portlet descriptors...
> From WSRP spec (10.2.4 Method=get in HTML forms):
> User-Agents often throw away any query string from the URL indicated with the form's action attribute when generating the URL they will activate when the form's method is "get". This is the simplest means for them to generate a valid query string. The difficulty this causes is that Consumer's often prefer to store the information they will use when a portlet URL is activated as query string parameters. As a result, Portlets that include HTML forms with method=get in their markup MUST specify usesMethodGet as "true" in their PortletDescription. Consumers choosing to use such Portlets need to format their portlet URLs such that portlet URL activations are processed correctly, regardless of whether Consumer or Producer URL writing is in use.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 10 months
[JBoss JIRA] Created: (JBPORTAL-1216) Problem with defining user listener service
by Mykola Hryhoryan (JIRA)
Problem with defining user listener service
-------------------------------------------
Key: JBPORTAL-1216
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1216
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Core
Affects Versions: 2.6.Alpha1
Environment: JBoss (MX MicroKernel) [4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)]
Reporter: Mykola Hryhoryan
Assigned To: Julien Viet
User listener service, defined in <app>/META-INF/jboss-service.xml doesn't start.
jboss-service.xml code:
<server>
<mbean
code="org.jboss.portal.core.event.PortalEventListenerServiceImpl"
name="portal:service=ListenerService,type=window_listener"
xmbean-dd=""
xmbean-code="org.jboss.portal.jems.as.system.JBossServiceModelMBean">
<xmbean />
<depends optional-attribute-name="Registry"
proxy-type="attribute">
portal:service=ListenerRegistry
</depends>
<attribute name="RegistryId">window_listener</attribute>
<attribute name="ListenerClassName">
biz.spacepeople.listeners.WindowConstraintEventListener
</attribute>
</mbean>
</server>
libarry with class WindowConstraintEventListener is in <JBOSS_HOME>\server\default\deploy\jboss-portal.sar\lib\
Sservice starts only if put mbean code into <JBOSS_HOME>\server\default\deploy\jboss-portal.sar\META-INF\jboss-service.xml
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 10 months
[JBoss JIRA] Created: (JBPORTAL-1137) Programatic control of portlet caching behavior
by Jerry Lacy (JIRA)
Programatic control of portlet caching behavior
-------------------------------------------------
Key: JBPORTAL-1137
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1137
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Portlet
Affects Versions: 2.4 Final
Environment: Portal 2.4, JDK 1.5, WindowsXP
Reporter: Jerry Lacy
Assigned To: Julien Viet
Attempts to programatically alter the EXPIRATION_CACHE setting of a portlet from within the doView() method has not effect.
e.g.
response.setProperty( RenderResponse.EXPIRATION_CACHE, "0" );
Unless I am missing something, it doesn't appear that this was implemented anywhere (as of the 2.4 final release). I believe the problem is on line 65 of
org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(). The cache expiration value is being updated on each request using the configured EXPIRATION_CACHE value regardless of whether an EXPIRATION_CACHE property was set on the response. I added the following test which seems to work based on what little testing I have done so far:
// Update the fragment cache info only if the value has not been overridden during render processing
if ( fragmentResult.getProperties().getProperty(RenderResponse.EXPIRATION_CACHE) == null ) {
fragmentResult.setExpirationSecs(cacheInfo.getExpirationSecs());
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 10 months