October 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-1553) Improve google gadgets support

by Boleslaw Dawidowicz (JIRA)

Improve google gadgets support ------------------------------ Key: JBPORTAL-1553 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1553 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal Widget Affects Versions: 2.6 Final Reporter: Boleslaw Dawidowicz Assigned To: Boleslaw Dawidowicz Priority: Optional Fix For: 2.6.1 Final, 2.8 Final Parent task - Improve support for google gadgets support. -- 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

16 years, 4 months

2
4
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1556) Use 'gmodules.com/ig/gadgetsettings?url=' instead of gmodules.com/ig/ifr?url=

by Boleslaw Dawidowicz (JIRA)

Use 'gmodules.com/ig/gadgetsettings?url=' instead of gmodules.com/ig/ifr?url= ----------------------------------------------------------------------------- Key: JBPORTAL-1556 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1556 Project: JBoss Portal Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Boleslaw Dawidowicz -- 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

16 years, 4 months

4
16
0 / 0

[JBoss JIRA] Created: (JBAS-4399) @EJB in JSF ignores mappedName

by Carlo de Wolf (JIRA)

@EJB in JSF ignores mappedName ------------------------------ Key: JBAS-4399 URL: http://jira.jboss.com/jira/browse/JBAS-4399 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.0.Beta2 Reporter: Carlo de Wolf Using mappedName on an @EJB in a JSF managed bean doesn't work. DefaultAnnotationProcessor ignores mappedName and will then perform a standard field lookup <bean>/<field>, resulting in a NameNotFoundException. 16:12:46,859 ERROR [JBossInjectionProvider] Injection failed on managed bean. javax.naming.NameNotFoundException: com.genloop.web.Projektabrechnung.Projektabrechnung_v13.beans.screen.Partner_Einzelperson_Screen not bound at org.jnp.server.NamingServer.getBinding(NamingServer.java:542) at org.jnp.server.NamingServer.getBinding(NamingServer.java:550) at org.jnp.server.NamingServer.getObject(NamingServer.java:556) at org.jnp.server.NamingServer.lookup(NamingServer.java:267) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:628) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:590) at javax.naming.InitialContext.lookup(InitialContext.java:351) at org.apache.catalina.util.DefaultAnnotationProcessor.lookupFieldResource(DefaultAnnotationProcessor.java:203) at org.apache.catalina.util.DefaultAnnotationProcessor.processAnnotations(DefaultAnnotationProcessor.java:139) at org.jboss.web.jsf.integration.injection.JBossInjectionProvider.inject(JBossInjectionProvider.java:104) at com.sun.faces.config.ManagedBeanFactoryImpl.newInstance(ManagedBeanFactoryImpl.java:298) at com.sun.faces.application.ApplicationAssociate.createAndMaybeStoreManagedBeans(ApplicationAssociate.java:531) at com.sun.faces.el.ManagedBeanELResolver.getValue(ManagedBeanELResolver.java:82) at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53) at com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:64) at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:45) at org.apache.el.parser.AstValue.getValue(AstValue.java:86) at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186) at org.apache.jasper.el.JspValueExpression.getValue(JspValueExpression.java:101) at javax.faces.component.UIOutput.getValue(UIOutput.java:173) at com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer.getValue(HtmlBasicInputRenderer.java:189) at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.getCurrentValue(HtmlBasicRenderer.java:320) at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeEnd(HtmlBasicRenderer.java:200) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:833) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:896) at javax.faces.render.Renderer.encodeChildren(Renderer.java:137) at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:809) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:886) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:892) at com.sun.faces.application.ViewHandlerImpl.doRenderView(ViewHandlerImpl.java:244) at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:175) at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:106) -- 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

16 years, 4 months

6
13
0 / 0

[JBoss JIRA] Created: (JBAS-3591) For SESSION and ATTRIBUTE don't marshal values if UseRegionBasedMarshalling is on

by Brian Stansberry (JIRA)

For SESSION and ATTRIBUTE don't marshal values if UseRegionBasedMarshalling is on --------------------------------------------------------------------------------- Key: JBAS-3591 URL: http://jira.jboss.com/jira/browse/JBAS-3591 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.CR1 Storing session or attributes in the cache as byte[] or MarshalledValue is unnecessary if region based marshalling is used. Doing it greatly increases the memory footprint of distributed sessions. Need to benchmark the performance impact of this (could be positive or negative), although the memory savings would outweigh all but a major performance loss. Can't do this in Branch_4_0 is it breaks binary compatibility. -- 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

16 years, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-4580) "INFO [STDOUT] fromPath: <fieldname>" is logged during startup

by Wolf-Dieter Fink (JIRA)

"INFO [STDOUT] fromPath: <fieldname>" is logged during startup -------------------------------------------------------------- Key: JBAS-4580 URL: http://jira.jboss.com/jira/browse/JBAS-4580 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: CMP service Affects Versions: JBossAS-4.0.5.GA Environment: JBoss_4_0_5_GA_CP04 date=200705011622 Reporter: Wolf-Dieter Fink Assigned To: Alexey Loubyansky Priority: Trivial After the migration from 4.0.4=>4.0.5_GA_CP04 the following is logged: INFO [STDOUT] fromPath: o.validFrom INFO [STDOUT] fromPath: o.validTo TRACE [org.jboss.ejb.plugins.cmp.jdbc.EJBQLToSQL92Compiler] ejbql: SELECT OBJECT(o) FROM SoldComponentAssoc o, SoldComponent sc, SoldProduct sp WHERE o.sold Component.soldComponentId = sc.soldComponentId AND o.soldProduct.soldProductId = sp.soldProductId AND sp.isDead = false AND sc.account.accountId = ?1 AND o.validFrom <= ?2 AND o.validTo > ?2 AND o.soldComponentName LIKE ?3 all fields that are displayed are special classes which are mapped with JDBCParameterSetter, JDBCResultSetReader, Mapper Classes. looks like a forgotten System.out.println() -- 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

16 years, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-3914) Thread dumps from ServerInfo MBean do not contain line breaks.

by Darran Lofthouse (JIRA)

Thread dumps from ServerInfo MBean do not contain line breaks. -------------------------------------------------------------- Key: JBAS-3914 URL: http://jira.jboss.com/jira/browse/JBAS-3914 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JMX Affects Versions: JBossAS-4.0.5.GA Reporter: Darran Lofthouse Assigned To: Darran Lofthouse Fix For: JBossAS-4.2.0.CR1 Thread dumps from ServerInfo MBean do not contain line breaks, as the output HTML and displayed in a browser this is generally not a problem as the browser formats the output using the HTML tags not based on the presence of line breaks. If users copy the data from the web browser to a text editor as there are no line breaks in the original output the data is pasted to the text editor without breaks which causes everything to be on one line. The ouput thread dumps should have line breaks added to get round this. -- 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

16 years, 4 months

5
7
0 / 0

[JBoss JIRA] Created: (JBAS-4852) EJB3 web service endpoints ignore metadata in jboss.xml

by Thomas Diesler (JIRA)

EJB3 web service endpoints ignore metadata in jboss.xml ------------------------------------------------------- Key: JBAS-4852 URL: http://jira.jboss.com/jira/browse/JBAS-4852 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Thomas Diesler Assigned To: Carlo de Wolf Fix For: JBossAS-4.2.2.GA This is related to JBWS-1813 It needs to be decided whether jboss-4.2.2 can go out despite this issue. Currently, users are forced to use annotations on the bean. -- 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

16 years, 4 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-4636) Fix org.jboss.test.deployers.* failures

by Dimitris Andreadis (JIRA)

Fix org.jboss.test.deployers.* failures --------------------------------------- Key: JBAS-4636 URL: http://jira.jboss.com/jira/browse/JBAS-4636 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Dimitris Andreadis Fix For: JBossAS-5.0.0.Beta3 Looking at the testsuite runs: http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-sun-1.5/... There is a whole group of deployer tests that need to be further qualified/fixed, with linked issues created org.jboss.test.deployers.client.test 4 4 0 6.208 org.jboss.test.deployers.ear.test 5 5 0 10.343 org.jboss.test.deployers.ejb.test 4 4 0 9.456 org.jboss.test.deployers.jbas2904.test 1 1 0 1.659 org.jboss.test.deployers.rar.test 4 4 0 6.285 org.jboss.test.deployers.sar.test 4 4 0 16.937 org.jboss.test.deployers.web.test 4 4 0 30.319 -- 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

16 years, 4 months

4
12
0 / 0

[JBoss JIRA] Created: (JGRP-528) NAKACK: spurious retransmission requests

by Bela Ban (JIRA)

NAKACK: spurious retransmission requests ----------------------------------------- Key: JGRP-528 URL: http://jira.jboss.com/jira/browse/JGRP-528 Project: JGroups Issue Type: Task Affects Versions: 2.5 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.6 Every now and then, spurious retransmission requests are received: NAKACK.handleXmitReq(): (requester=192.168.5.2:4397, local_addr=192.168.5.2:4393) message 192.168.5.2:4393::600 not found in retransmission table of 192.168.5.2:4393: [650 : 1050 (1100) (size=x, missing=0, highest stability=650)] It turns out that message #600 *was* actually retransmitted correctly, but the retransmission timer was cancelled too late, so that we got 1 or 2 spurious retransmit requests for the same message. This doesn't happen very frequently, and only under heavy load (e.g. 8 nodes, every node sends 5M 5K messages with 500 threads). Note that this issue DOES NOT LEAD TO INCORRECT BEHAVIOR ! -- 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

16 years, 5 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-4083) Ejb timers fire before the ear completely deploys

by Vadim Kopichenko (JIRA)

Ejb timers fire before the ear completely deploys ------------------------------------------------- Key: JBAS-4083 URL: http://jira.jboss.com/jira/browse/JBAS-4083 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB2, Scheduling/Timers Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.4.GA Environment: WinNT, Sun JDK 1.5 Reporter: Vadim Kopichenko Assigned To: Scott M Stark Consider the following usecase. The is an ear containing several ejb modules. One of them has a ejb2.1 timed cmp entity bean. If the timer associated with the bean fires during application deployment unexpected errors happen, cause other beans could be not already deployed. This breaks application logic. The problem happens both while server starts/stops and while hot ear's redeployment. It would be much better if timers began to fire after the application had completely deployed. I've also experienced a similar problem with undeployment. Timer code was executed about a half of second after the undeployment had begun. Several ejb modules had been already undeployed by that moment. I guess that timer actually fired exactly before the undeployment had begun but the ejbTimeout executed later due to threads syncronization issue. Please, try also to investigate if this can be avoided. PS Some kind of patch or workaround for 4.0.5 (or even a hint about how this can be fixed) would be greatly appreciated. -- 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

16 years, 5 months

4
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2007