July 2007 - jboss-jira - Jboss List Archives

[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

18 years, 1 month

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

18 years, 1 month

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

18 years, 1 month

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

18 years, 1 month

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

18 years, 1 month

5
7
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

18 years, 1 month

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

18 years, 1 month

4
3
0 / 0

[JBoss JIRA] Created: (JBWEB-84) Class Cast Exception - when using CometProcessor - Jboss 4.2.0

by Vali Dumitru (JIRA)

Class Cast Exception - when using CometProcessor - Jboss 4.2.0 -------------------------------------------------------------- Key: JBWEB-84 URL: http://jira.jboss.com/jira/browse/JBWEB-84 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Environment: Windows Reporter: Vali Dumitru Assigned To: Mladen Turk I have a servlet that implements CometProcessor interface. Whenever I try to access it I get : java.lang.ClassCastException: org.jboss.web.tomcat.filters.ReplyHeaderFilter at org.apache.catalina.core.ApplicationFilterChain.internalDoFilterEvent(ApplicationFilterChain.java:398) at org.apache.catalina.core.ApplicationFilterChain.doFilterEvent(ApplicationFilterChain.java:363) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:227) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241) at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:896) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:701) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2031) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) What is this? Is there a workaround? -- 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, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-4508) Add a way to defined dependencies for a JCA adapter

by Georges Berscheid (JIRA)

Add a way to defined dependencies for a JCA adapter --------------------------------------------------- Key: JBAS-4508 URL: http://jira.jboss.com/jira/browse/JBAS-4508 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.2.0.GA Environment: Any Reporter: Georges Berscheid Currently there is no way to define that a resource adapter has a dependency on different component. Adrian has suggested to add support for a jboss-ra.xml file that let you define those dependencies (see forum entry). -- 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, 1 month

3
8
0 / 0

[JBoss JIRA] Created: (BPEL-268) provide a people task management example

by Alejandro Guizar (JIRA)

provide a people task management example ---------------------------------------- Key: BPEL-268 URL: http://jira.jboss.com/jira/browse/BPEL-268 Project: JBoss jBPM BPEL Issue Type: Task Security Level: Public (Everyone can see) Components: Documents Affects Versions: jBPM BPEL 1.1 beta 3 Reporter: Alejandro Guizar Assigned To: Alejandro Guizar Fix For: jBPM BPEL 1.1 GA Put together a simple example demonstrating how the task management facilities found in jPDL can be leveraged in BPEL. -- 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, 1 month

2
6
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2007