August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3561) InvokerInterceptor.invokeLocalMarshalled it not marshalling PayLoad and invocationContext

by Clebert Suconic (JIRA)

InvokerInterceptor.invokeLocalMarshalled it not marshalling PayLoad and invocationContext ----------------------------------------------------------------------------------------- Key: JBAS-3561 URL: http://jira.jboss.com/jira/browse/JBAS-3561 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB2 Affects Versions: JBossAS-4.0.4.GA Reporter: Clebert Suconic Assigned To: Clebert Suconic Fix For: JBossAS-4.0.5.CR1 InvocationContext and PayLoad should also be marshalled as this could cause classLoading isolation problems with CMP layer, as the CMP Layer uses payLoad and invocationContext heavily. -- 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

19 years, 11 months

1
3
0 / 0

[JBoss JIRA] Created: (JBRULES-448) Refactor ValueHandler resolvers to be standalone

by Mark Proctor (JIRA)

Refactor ValueHandler resolvers to be standalone ------------------------------------------------ Key: JBRULES-448 URL: http://jira.jboss.com/jira/browse/JBRULES-448 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Rule Assemply/SPI Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m1 ValueHandlers should be standalone and should include maps and lists, which can also be nested. -- 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

19 years, 11 months

1
1
0 / 0

[JBoss JIRA] Commented: (JBSEAM-86) Pass ResourceBundle to Hibernate Validator

by Valerij Timofeev (JIRA)

[ http://jira.jboss.com/jira/browse/JBSEAM-86?page=comments#action_12341774 ] Valerij Timofeev commented on JBSEAM-86: ---------------------------------------- It doesn't work for me in Seam 1.0.1.GA > Pass ResourceBundle to Hibernate Validator > ------------------------------------------ > > Key: JBSEAM-86 > URL: http://jira.jboss.com/jira/browse/JBSEAM-86 > Project: JBoss Seam > Issue Type: Feature Request > Components: Core > Reporter: Gavin King > Assigned To: Gavin King > > We need to let the user specify a resource bundle for internationalized messages. Hibernate Validator supports it. -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Commented: (JGRP-39) A TCP stack does not correctly detect failure (pulled cable) for certain TCPPING configurations

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-39?page=comments#action_12341769 ] Brian Stansberry commented on JGRP-39: -------------------------------------- This issue says is affects 2.2.9 and was fixed in 2.2.8. Illogical combination. The 2.2.9 is likely a mistake as that release didn't exist when this issue was created. I just tried to change it to 2.2.7, but that wasn't available on the menu. > A TCP stack does not correctly detect failure (pulled cable) for certain TCPPING configurations > ----------------------------------------------------------------------------------------------- > > Key: JGRP-39 > URL: http://jira.jboss.com/jira/browse/JGRP-39 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.2.9 > Reporter: Ovidiu Feodorov > Assigned To: Ovidiu Feodorov > Fix For: 2.2.8 > > > Physical hosts "A" (192.168.1.1, coordinator) and "B" (192.168.1.2) run JGroups processes configured with TCP/TCPPING stacks. > "A" stack configuration: > TCP(bind_addr=192.168.1.1;start_port=11800;loopback=true): > TCPPING(initial_hosts=192.168.1.2[11800];port_range=3;timeout=3500;num_initial_members=3;up_thread=true;down_thread=true): > MERGE2(min_interval=5000;max_interval=10000): > FD(shun=true;timeout=1500;max_tries=3;up_thread=true;down_thread=true): > VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false): > pbcast.NAKACK(down_thread=true;up_thread=true;gc_lag=100;retransmit_timeout=3000): > pbcast.STABLE(desired_avg_gossip=20000;down_thread=false;up_thread=false): > pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=false;print_local_addr=false;down_thread=true;up_thread=true) > "B" stack configuration: > TCP(bind_addr=192.168.1.2;start_port=11800;loopback=true): > TCPPING(initial_hosts=192.168.1.1[11800];port_range=3;timeout=3500;num_initial_members=3;up_thread=true;down_thread=true): > MERGE2(min_interval=5000;max_interval=10000): > FD(shun=true;timeout=1500;max_tries=3;up_thread=true;down_thread=true): > VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false): > pbcast.NAKACK(down_thread=true;up_thread=true;gc_lag=100;retransmit_timeout=3000): > pbcast.STABLE(desired_avg_gossip=20000;down_thread=false;up_thread=false): > pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=false;print_local_addr=false;down_thread=true;up_thread=true) > If I pull the cable under B, the B stack immediately and correctly indentifies A as suspect and installs a new view containing itself only. > However, A does not recognizes B as suspect and undeterministically spews out various info and warning messages. The view (A, B) stays incorrectly "valid" for a long time; sometimes gets replaced by (A), sometimes not. > I tracked down the cause of the problem down to the A TCPPING configuration and TCP queue . If A's TCPPING is configured with a port_range=1, the problem goes away and the new view immediately installs into the A stack. It seems that if there are messages in the TCP queue except the SUSPECT message generated by FD, they mess up things and the SUSPECT message gets stuck in the queue, with undeterministic results. -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3542) jboss-web_5_0.dtd is malformed

by Matthew L Daniel (JIRA)

jboss-web_5_0.dtd is malformed ------------------------------ Key: JBAS-3542 URL: http://jira.jboss.com/jira/browse/JBAS-3542 Project: JBoss Application Server Issue Type: Patch Security Level: Public (Everyone can see) Components: Documentation Affects Versions: JBossAS-5.0.0.Beta Reporter: Matthew L Daniel Assigned To: Norman Richards Fix For: JBossAS-5.0.0.Beta The jboss-web_5_0.dtd is not syntatically valid, causing all kinds of SAXExceptions when deploying. There are two distinct problems with the DTD: 1. The ELEMENT instruction is written as "Element" twice 2. An angle-bracket is substituted for an opening paren before a PCDATA declaration. This patch is against SVN from this morning. -- 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

19 years, 11 months

2
3
0 / 0

[JBoss JIRA] Commented: (JGRP-181) Threadless stack

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-181?page=comments#action_12341748 ] Bela Ban commented on JGRP-181: ------------------------------- One idea is to have a thread pool handle incoming messages, so that for messages A1, B10, B11, B12, A2, {A1,A2} and {B10-12} can be processed concurrently with respect to each other. However, in the following case: A1, A2, A3, A4, B1. Let's assume we have a threadpool of 2 configured. In this example, thread-1 (T1) will handle A1 and T2 will handle A2. T2 will have to block until A1 has been processed. This is bad, as we could deliver B1 on a separate thread in the meantime. So, using a threadpool for each message, regardless of the message's sender, isn't good. We should rather categorize messages by sender, e.g. have 1 queue per sender: {A1-4} and {B1}, and have T1 process the queue {A1-4} and T2 process the queue {B1}. Need to investigate whther this is possible with QueuedExecutor > Threadless stack > ---------------- > > Key: JGRP-181 > URL: http://jira.jboss.com/jira/browse/JGRP-181 > Project: JGroups > Issue Type: Task > Affects Versions: 2.2.9.1, 2.2.9, 2.2.8 > Reporter: Bela Ban > Assigned To: Bela Ban > Priority: Critical > Fix For: 2.5 > > > Investigate setting all down_thread and up_thread properties to false by default > Performance tests have shown that in almost all cases this is always faster, so why not make it the default. This is e.g. already the case in fc-fast-minimalthreads.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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Resolved: (EJBTHREE-400) Timer transaction warning problem

by Carlo de Wolf (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-400?page=all ] Carlo de Wolf resolved EJBTHREE-400. ------------------------------------ Resolution: Cannot Reproduce Bug In the current head the warning doesn't appear anymore. > Timer transaction warning problem > --------------------------------- > > Key: EJBTHREE-400 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-400 > Project: EJB 3.0 > Issue Type: Bug > Reporter: Bill Burke > Assigned To: Carlo de Wolf > Fix For: EJB 3.0 RC9 - FD > > -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3547) Display ENC for web applications in JNDIView

by Darran Lofthouse (JIRA)

Display ENC for web applications in JNDIView -------------------------------------------- Key: JBAS-3547 URL: http://jira.jboss.com/jira/browse/JBAS-3547 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Naming Affects Versions: JBossAS-4.0.4.GA Reporter: Darran Lofthouse Assigned To: Darran Lofthouse Fix For: JBossAS-4.0.5.CR1 I have been asked why the JNDIView MBean does not show the ENC for web applications. Previously I think there might have been problems when JBoss was bundled with Tomcat and Jetty which made getting access to the classloader difficult. Currently we have the AbstractWebContainer class which makes available the list of 'DeployedApplications', the deployed applications are instances of WebApplication which makes available the classloader of the application which we can use for listing the ENC. -- 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

19 years, 11 months

2
5
0 / 0

[JBoss JIRA] Closed: (JBIDE-313) Seam generation needs updating

by Max Andersen (JIRA)

[ http://jira.jboss.com/jira/browse/JBIDE-313?page=all ] Max Andersen closed JBIDE-313. ------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 1.6.1) Resolution: Done afaik this is fixed. > Seam generation needs updating > ------------------------------ > > Key: JBIDE-313 > URL: http://jira.jboss.com/jira/browse/JBIDE-313 > Project: JBoss IDE > Issue Type: Bug > Components: Hibernate Tools > Affects Versions: 1.6 > Reporter: Marshall Culpepper > Assigned To: Gavin King > Fix For: 2.0.0.Beta1 > > > Apparently with the new 1.0 version of Seam (currently from CVS) we will need to update the codegen parts of Hibernate Tools for Seam to be reflective of the new changes. -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-588) Fix multiplex performance tests.

by Ron Sigal (JIRA)

Fix multiplex performance tests. -------------------------------- Key: JBREM-588 URL: http://jira.jboss.com/jira/browse/JBREM-588 Project: JBoss Remoting Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Some of the multiplex performance tests are failing: "With java serialization, only one of the three test runs produced results and jboss serialization is never able to produce results" - Tom Elrod. -- 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

19 years, 11 months

1
1
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 August 2006