November 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4975) Usage of read-ahead on-find with entity beans containing binary attributes (mapped to BLOB, VARBINAR, ...) breaks eager loading.

by Rothe Marco (JIRA)

Usage of read-ahead on-find with entity beans containing binary attributes (mapped to BLOB, VARBINAR, ...) breaks eager loading. -------------------------------------------------------------------------------------------------------------------------------- Key: JBAS-4975 URL: http://jira.jboss.com/jira/browse/JBAS-4975 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: CMP service Affects Versions: JBossAS-4.2.2.GA Reporter: Rothe Marco Assigned To: Alexey Loubyansky I' ve found out that using the read ahead strategy "on-find" on an EJB2 entity bean which contains at least one binary persistent attribute (e.g public abstract byte[] getBinaryImage();) can break the eager loading of attributes causing "strange" exceptions. It is related to the fix of issue http://jira.jboss.org/jira/browse/JBAS-3800. This fix brought in the following code to the JDBCEJBQLQuery.java // exclude non-searchable columns if distinct is used if(compiler.isSelectDistinct()) { boolean[] mask = getEagerLoadMask(); JDBCFieldBridge[] tableFields = selectEntity.getTableFields(); for(int i = 0; i < tableFields.length; ++i) { if(mask[i] && !tableFields[i].getJDBCType().isSearchable()) { mask[i] = false; } Manipulation of mask[i] has the side effect to be visible on ALL finders defined for entity because the mask array is hold by JDBCEntityBridge and shared through all JDBCAbstractQueryCommand instances referencing to this JDBCEntityBridge as selectEntity. Executing an non distinct query on the bean can cause calls with wrong parameters to the method loadArgumentResults in JDBCAbstractQueryCommand.EagerCollectionFactory at line 756 and the following. JDBCFieldBridge[] tableFields = selectEntity.getTableFields(); for(int i = 0; i < eagerLoadMask.length; i++) { if(eagerLoadMask[i]) { JDBCFieldBridge field = tableFields[i]; ref[0] = null; // read the value and store it in the readahead cache index = field.loadArgumentResults(rs, index, ref); if(addPk) { selectReadAheadCache.addPreloadData(curPk, field, ref[0]); } } } Depending on the order of declaring the ejb-find methods for the entity the sql-string of an JDBCAbstractQueryCommand instance maybe compiled before the mask array is changed (by compiling an dictinct-query). In such cases the jdbc-resultset contains the binary column but the if-statement if(eagerLoadMask[i]) skip to load it into the JDBCFieldBridge object. An increment on the index variable (which point to the position to process next from the resultset) is skipped too. Processing the following result set columns cause errors because now JDBC-type at position index does not match the JDBCFieldBridge at tableFields[i]. -- 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, 6 months

3
2
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-188) Incomplete Deployment calculation should be done upfront

by Adrian Brock (JIRA)

Incomplete Deployment calculation should be done upfront -------------------------------------------------------- Key: JBMICROCONT-188 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-188 Project: JBoss MicroContainer Issue Type: Task Reporter: Adrian Brock Fix For: JBossMC-2.0.0.GA Some of the calculation of the IncompleteDeploymentException is done in the exception class itself when it should be done in the Incomplete processing upfront. -- 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, 6 months

3
5
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-183) ManifestDeployer has a TODO relating to VFS snapshot update

by Adrian Brock (JIRA)

ManifestDeployer has a TODO relating to VFS snapshot update ----------------------------------------------------------- Key: JBMICROCONT-183 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-183 Project: JBoss MicroContainer Issue Type: Task Components: Deployment Reporter: Adrian Brock Assigned To: Ales Justin Fix For: JBossMC_2_0_0_CR1 Ales, you added this comment @Override protected T parse(VFSDeploymentUnit unit, VirtualFile file, T root) throws Exception { // todo - update once we have new vfs snapshot InputStream is = SecurityActions.openStream(file); Manifest manifest; try { manifest = new Manifest(is); } finally { try { is.close(); } catch (Exception ignored) { } } return createMetaData(manifest); } -- 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, 6 months

2
3
0 / 0

[JBoss JIRA] Reopened: (JBMICROCONT-93) Add JBossRetro builds for Microcontainer projects

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBMICROCONT-93?page=all ] Adrian Brock reopened JBMICROCONT-93: ------------------------------------- > Add JBossRetro builds for Microcontainer projects > ------------------------------------------------- > > Key: JBMICROCONT-93 > URL: http://jira.jboss.com/jira/browse/JBMICROCONT-93 > Project: JBoss MicroContainer > Issue Type: Sub-task > Components: General > Reporter: Adrian Brock > Assigned To: Paul Gier > Fix For: JBossMC-2.0.0.Beta7 > > > Make JBossRetro builds for the microcontainer projects > such that they can use JDK5 features. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMICROCONT-93) Add JBossRetro builds for Microcontainer projects

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBMICROCONT-93?page=all ] Adrian Brock closed JBMICROCONT-93. ----------------------------------- Fix Version/s: JBossMC-2.0.0.Beta7 (was: JBossMC-2.0.0.CR1) Resolution: Done > Add JBossRetro builds for Microcontainer projects > ------------------------------------------------- > > Key: JBMICROCONT-93 > URL: http://jira.jboss.com/jira/browse/JBMICROCONT-93 > Project: JBoss MicroContainer > Issue Type: Sub-task > Components: General > Reporter: Adrian Brock > Assigned To: Paul Gier > Fix For: JBossMC-2.0.0.Beta7 > > > Make JBossRetro builds for the microcontainer projects > such that they can use JDK5 features. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-216) Drop the DeploymentUnit.getTypes

by Scott M Stark (JIRA)

Drop the DeploymentUnit.getTypes -------------------------------- Key: JBMICROCONT-216 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-216 Project: JBoss MicroContainer Issue Type: Task Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: JBossMC-2.0.0.CR1 The deployment unit types qualifiers should be part of the management view, not part of the DeploymentUnit api. -- 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, 6 months

3
3
0 / 0

[JBoss JIRA] Created: (JBPM-1045) test suite has to trow a runtime exception on error so meaningful report is generated

by Aleksandar Kostadinov (JIRA)

test suite has to trow a runtime exception on error so meaningful report is generated ------------------------------------------------------------------------------------- Key: JBPM-1045 URL: http://jira.jboss.com/jira/browse/JBPM-1045 Project: JBoss jBPM Issue Type: Bug Affects Versions: jBPM jPDL 3.2.2 Reporter: Aleksandar Kostadinov Assigned To: Tom Baeyens When there are test suite initialization problems, test suite ignores exception (just prints it to the output) that causes junit to crash. I identified the issue in the following files: jpdl/jar/src/test/java/org/jbpm/AllDBTests.java jpdl/jar/src/test/java/org/jbpm/AllTests.java have to have "throw t;" after "t.printStackTrace();" As well the following test cases seem suspicious to me. I mean I'm not sure if an exception by these tests will cause a test suite crash. Please inspect if trowing an axception is desirable after printStackTrace method is used in these files: ./msg/command/AsyncExecutionDbTest.java ./perf/MemLeakTest.java -- 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, 6 months

3
8
0 / 0

[JBoss JIRA] Created: (JBREM-792) Provide to the client local address of a TCP/IP connection, as seen from the server

by Ron Sigal (JIRA)

Provide to the client local address of a TCP/IP connection, as seen from the server ----------------------------------------------------------------------------------- Key: JBREM-792 URL: http://jira.jboss.com/jira/browse/JBREM-792 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) When org.jboss.remoting.Client.addListener() creates a callback org.jboss.remoting.transport.Connector, by default it calls InetAddress.getLocalHost().getHostAddress() to get a local address for the callback org.jboss.remoting.InvokerLocator. If the machine happens to have multiple addresses, getLocalHost() might return the wrong one. A solution, due to Ovidiu Feodorov, is to implement an internal invocation to which the server replies by returning the remote address of the connection over which the invocation was made. This solution has been implemented for the socket transport (and bisocket, by inheritance) in conjunction with JBREM-781. It should be implemented for the other transports. -- 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, 6 months

1
4
0 / 0

[JBoss JIRA] Created: (JBREM-758) Associate remote socket address with the invocation

by Carlo de Wolf (JIRA)

Associate remote socket address with the invocation --------------------------------------------------- Key: JBREM-758 URL: http://jira.jboss.com/jira/browse/JBREM-758 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Carlo de Wolf Add remote socket address to the InvocationRequest to allow it to be used for auditing and filtering. -- 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, 6 months

2
7
0 / 0

[JBoss JIRA] Created: (JGRP-633) Connection table should remove connection that throws Exception

by Vladimir Blagojevic (JIRA)

Connection table should remove connection that throws Exception --------------------------------------------------------------- Key: JGRP-633 URL: http://jira.jboss.com/jira/browse/JGRP-633 Project: JGroups Issue Type: Bug Affects Versions: 2.6 Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Priority: Minor Fix For: 2.6.1, 2.7 When reading thread that fetches data from a peer connection encounters Exception that is caused by broken socket it should remove related connection object from connection table. -- 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, 6 months

1
2
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 November 2007