April 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBXB-97) org.w3c.dom.Element is being mapped incorrectly

by David Boeren (JIRA)

org.w3c.dom.Element is being mapped incorrectly ----------------------------------------------- Key: JBXB-97 URL: http://jira.jboss.com/jira/browse/JBXB-97 Project: JBoss XML Binding (JBossXB) Issue Type: Bug Affects Versions: JBossXB-1.0.0.CR7 Reporter: David Boeren This comes from support case 14372. Customer has a webservice taking and returning an org.w3c.dom.Element type, but it appears that it is not being correctly mapped by JBossXB. The error message states: Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Failed to find read method or field for property '_value' in class org.apache.xerces.dom.ElementImpl Attached to the case you can find a WAR file to deploy for the service side and an Eclipse project with a client that demonstrates the error. -- 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, 3 months

2
5
0 / 0

[JBoss JIRA] Commented: (JBPM-578) remove JbpmSession and JbpmSessionFactory

by Ronald van Kuijk (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-578?page=comments#action_12359711 ] Ronald van Kuijk commented on JBPM-578: --------------------------------------- deprecating them means to express the intend to remove them in the not so distant future. I would therefore not 'won't fix' them, but reopen the issue and do a 'fix version of 3.3 or 4) > remove JbpmSession and JbpmSessionFactory > ----------------------------------------- > > Key: JBPM-578 > URL: http://jira.jboss.com/jira/browse/JBPM-578 > Project: JBoss jBPM > Issue Type: Task > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Tom Baeyens > > those are deprecated in jbpm 3.1 and will be removed in 3.2 -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBWEB-78) Default Compiler should be jdt compiler

by Vicky Kak (JIRA)

Default Compiler should be jdt compiler --------------------------------------- Key: JBWEB-78 URL: http://jira.jboss.com/jira/browse/JBWEB-78 Project: JBoss Web Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Tomcat Module Affects Versions: JBoss Web Server 1.0.1 GA Reporter: Vicky Kak Assigned To: Jean-Frederic Clere Priority: Optional The default values mentioned in the web.xml comments for the compiler is wrong    The Java compiler from Eclipse JDT in included as the default compiler. This is explained here http://tomcat.apache.org/tomcat-5.5-doc/jasper-howto.html -- 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, 3 months

2
2
0 / 0

[JBoss JIRA] Closed: (JBBUILD-202) Bootstrap jboss build with maven

by Paul Gier (JIRA)

[ http://jira.jboss.com/jira/browse/JBBUILD-202?page=all ] Paul Gier closed JBBUILD-202. ----------------------------- Resolution: Won't Fix The way that maven builds itself when there is no existing maven installation, is that it uses ant to build itself initially. This still requires an ant installation. For now, the jboss builds will have to require a maven installation. At a later time we can look again at whether this is doable if this feature is needed. > Bootstrap jboss build with maven > -------------------------------- > > Key: JBBUILD-202 > URL: http://jira.jboss.com/jira/browse/JBBUILD-202 > Project: JBoss Build System > Issue Type: Feature Request > Components: Maven > Reporter: Ruel Loehr > Assigned To: Paul Gier > Fix For: MavenBuild 1.2 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Make a script similiar to the build.sh which can boot strap the build process with a maven installation. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4345) Missing jboss-ejb3x.jar in ../deploy/ejb3.deployer directory

by Perry Rhodan (JIRA)

Missing jboss-ejb3x.jar in ../deploy/ejb3.deployer directory ------------------------------------------------------------ Key: JBAS-4345 URL: http://jira.jboss.com/jira/browse/JBAS-4345 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: JBossAS-4.2.0.CR2 Environment: ALL Reporter: Perry Rhodan Assigned To: Carlo de Wolf Priority: Minor Since 4.2CR2 i'm (or especially the jbossIDE 2.0.0.Beta2) is missing the jboss-ejb3x.jar in $SERVER_HOME/server/default/deploy/ejb3.deployer directory. Packaging failure ? -- 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, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JGRP-475) Logging IOExceptions in BasicConnectionTable

by Galder Zamarreno (JIRA)

Logging IOExceptions in BasicConnectionTable -------------------------------------------- Key: JGRP-475 URL: http://jira.jboss.com/jira/browse/JGRP-475 Project: JGroups Issue Type: Bug Affects Versions: 2.4.1 SP1 Reporter: Galder Zamarreno Assigned To: Bela Ban Fix For: 2.5 BasicConnectionTable contains this code: private void _send(byte[] data, int offset, int length) { synchronized(send_mutex) { try { doSend(data, offset, length); updateLastAccessed(); } catch(IOException io_ex) { if(log.isWarnEnabled()) log.warn("peer closed connection, trying to re-send msg"); try { doSend(data, offset, length); updateLastAccessed(); } catch(IOException io_ex2) { if(log.isErrorEnabled()) log.error("2nd attempt to send data failed too"); } catch(Exception ex2) { if(log.isErrorEnabled()) log.error("exception is " + ex2); } } catch(InterruptedException iex) {} catch(Throwable ex) { if(log.isErrorEnabled()) log.error("exception is " + ex); } } } io_ex and io_ex2 should be logged, otherwise you get these messages without any reason why it failed: 2007-04-15 01:04:43,425 WARN [org.jgroups.blocks.ConnectionTable] sender thread was interrupted, but is still alive: Thread[ConnectionTable.Connection.Sender [143.61.17.44:55413 - 209.82.241.31:7100],5,ConnectionTableGroup] 2007-04-15 01:04:43,425 WARN [org.jgroups.blocks.ConnectionTable] peer closed connection, trying to re-send msg 2007-04-15 01:04:43,426 ERROR [org.jgroups.blocks.ConnectionTable] 2nd attempt to send data failed too -- 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, 3 months

2
5
0 / 0

[JBoss JIRA] Created: (JGRP-471) FC leaks memory under sustained overload

by Brian Stansberry (JIRA)

FC leaks memory under sustained overload ---------------------------------------- Key: JGRP-471 URL: http://jira.jboss.com/jira/browse/JGRP-471 Project: JGroups Issue Type: Task Affects Versions: 2.4.1 SP1 Reporter: Brian Stansberry Assigned To: Bela Ban Fix For: 2.4.1 SP2 FC does not control flow tightly enough. I believe this may be because credit replenishments bring a sender up to max_credits from *whatever credit level* the sender is at, which has no direct relationship to how many bytes the receiver had seen. This is more of a problem under sustained over load when sender threads are timing out while blocking and sending credit requests. For example, with a config of max_credits = 1,000,000 and min_credits = 100,000. Sender is under enough client load that it basically always has sender threads blocking with messages totalling 1,000,000 bytes. Sender sends 1,000,000 bytes and blocks. Receiver processes slowly. Receiver processes 900,000, sends credit replenishment 1. Meanwhile, sender times out; sends credit request 1. Sender gets credit replenishment 1; unblocks, sends another 1,000,000, blocks again. Receiver processes 100,000, then gets credit request 1 and sends replenishment 2. Sender times out; sends credit request 2. Sender gets replenishment 2 and unblocks, sends 1,000,000 bytes. At this point, the sender has sent 3,000,000 and the receiver has received 1,000,000. Further, there is a credit request in the channel, so after the receiver sees the next 1,000,000 bytes, it will have sent two more replenishments, theoretically allowing the sender to send 2,000,000 more bytes. This is an extreme example, but the key point is a credit replenishment gives the sender the right to send up to max_credits, even though the receiver may have only seen min_credits when it sent the message. Solution to this problem is two-fold: 1) Credit replenishment messages should include a payload indicating the number of bytes received. The sender only gives itself that many credits. 2) #1 alone will hurt performance in a steady-state system. If A and B are sending messages to each other, with a config of max_credits = 1,000,000 and min_credits=100,000, B will send A 900,000 credits when it has read that many. It will take a while for the credit replenishment to reach A (since B is also sending), so A will send 100,000 more and begin blocking. It will then get the 900,000 credit replenishment, send 900,000 and begin blocking again. Under the old system it would have gotten 1,000,000 bytes -- now it only gets 900,000. Solution to that is to change the meaning of min_credits. Currently, receiver sends credit when it has received_bytes >= (max_credits - min_credits). If min_credits is 100,000, credits will only be sent when the sender is almost out. The standard value of min_threshold=0.10 is very conservative, but was needed because the more frequently replenishment messages with no set number of bytes get sent, the more likely the sender is to get too many credits and OOME. If credit replenishment messages only give the number of bytes the receiver has read, then there is no OOME risk. Therefore, sending replenishment messages frequently makes sense. So, I propose the receiver should send credit when received_bytes >= min_credits, rather than the current approach of sending when received_bytes >= max_credit - min_credit. Bela, we discussed making this change to FC. But #2 above is a pretty significant change in behavior, since it changes the meaning of config parameters. Should I check this in as something else, e.g. FC2? -- 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, 3 months

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-4341) Double index creation in alterTable

by Jesper Pedersen (JIRA)

Double index creation in alterTable ----------------------------------- Key: JBAS-4341 URL: http://jira.jboss.com/jira/browse/JBAS-4341 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: CMP service Affects Versions: JBossAS-4.2.0.CR1 Environment: Branch_4_2 and JDK5 Reporter: Jesper Pedersen Assigned To: Alexey Loubyansky Priority: Minor The following makes the double index creation check more fail-safe. -- 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, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-4340) Key generators for StoreManager2

by Jesper Pedersen (JIRA)

Key generators for StoreManager2 --------------------------------- Key: JBAS-4340 URL: http://jira.jboss.com/jira/browse/JBAS-4340 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: CMP service Affects Versions: JBossAS-4.2.0.CR1 Environment: Branch_4_2 and JDK5 Reporter: Jesper Pedersen Assigned To: Alexey Loubyansky Attachments: AbstractCreateCommand.java, HsqldbCreateCommand.java, PostgreSQLCreateCommand.java, standardjbosscmp-jdbc.xml.patch The following patches provides support for key generator for the JDBCStoreManager2 class. Work was sponsored by World League Sports and licensed under LGPL. -- 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, 3 months

2
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-944) ejb-4.2-testsuite failures seen with webservices tests after integration of JBoss WS 1.2.1GA

by Shelly McGowan (JIRA)

ejb-4.2-testsuite failures seen with webservices tests after integration of JBoss WS 1.2.1GA -------------------------------------------------------------------------------------------- Key: EJBTHREE-944 URL: http://jira.jboss.com/jira/browse/EJBTHREE-944 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.0 CR2 Reporter: Shelly McGowan Assigned To: Carlo de Wolf JBoss WS 1.2.1GA was integrated into Branch_4_2 on April 15. Prior to then the ejb-4.2-testsuite was running with a 99.38% pass rate with one test failure (MDBUnitTestCase-testExpiration where the failure seems to be understood). Since 04/15, the ejb-4.2-testsuite has 5 additional failures related to web services; namely, org.jboss.ejb3.test.webservices.unit - JSR181TestCase - testWebService, testWebServiceRef1, testWebServiceRef2 org.jboss.ejb3.test.jaxws.unit - ContextEJBTestCase - testClientAccessWS, testClientAccessRPC The tests are failing due to : javax.xml.ws.WebServiceException: java.io.IOException: Could not transmit message Need to understand whether this is a test case issue or a regression due to the upgraded WS component. -- 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, 3 months

2
3
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 April 2007