December 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBAS-2245) Build deployer suffixes list dynamically

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2245?page=all ] Dimitris Andreadis updated JBAS-2245: ------------------------------------- Fix Version/s: (was: JBossAS-4.2.0.CR1) > Build deployer suffixes list dynamically > ---------------------------------------- > > Key: JBAS-2245 > URL: http://jira.jboss.com/jira/browse/JBAS-2245 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Deployment services > Affects Versions: JBossAS-4.0.3RC2 > Reporter: Dimitris Andreadis > > The DeploymentScanner makes it's first pass on ./deploy at startup, before the deployers (except for JAR/SAR deployer) are register, so the initial SuffixOrder list is not correct, and this is the reason we need to specify statically in MainDeployer-xmbean.xml some deployment suffixes. > Maybe a solution is to make a first initial pass using a filter to deploy or deployers first, then processed normally with the rest of the deployments. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2113) Tables creation problem on Oracle

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2113?page=all ] Dimitris Andreadis updated JBAS-2113: ------------------------------------- Component/s: Scheduling/Timers (was: EJB2) Fix Version/s: (was: JBossAS-4.2.0.CR1) > Tables creation problem on Oracle > --------------------------------- > > Key: JBAS-2113 > URL: http://jira.jboss.com/jira/browse/JBAS-2113 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Scheduling/Timers > Affects Versions: JBossAS-4.0.3RC1, JBossAS-4.0.2 Final, JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final > Environment: WindowsXp, Oracle 9i > Reporter: Martin Cerba > > When Jboss is configured to use Oracle 9i DB for tables TIMERS table is not created when user for logging is changed. > I found problem in org.jboss.ejb.plugins.cmp.jdbc.SQLUtil class in function > public static boolean tableExists(String tableName, DataSource dataSource) > This function use JDBC3 functionality getTables(catalog, schema, tableName, null) to check for table existence where schema parameter is set to null. > On Oracle this function check all schemas (users) for table existence (user had DBA privilegies set) and may find TIMERS table under different user. > Then jboss assume TIMERS as existing. > I put username to schema parameter and it repairs problem on oracle but then it not works under hypersonic. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBAS-2407) EJB3 integration

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2407?page=all ] Dimitris Andreadis reassigned JBAS-2407: ---------------------------------------- Assignee: Carlo de Wolf Assign to Carlo - will there be any work on this for the next release? > EJB3 integration > ---------------- > > Key: JBAS-2407 > URL: http://jira.jboss.com/jira/browse/JBAS-2407 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: EJB3 > Affects Versions: JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1 > Reporter: Adrian Brock > Assigned To: Carlo de Wolf > Fix For: JBossAS-4.2.0.CR1 > > > Need to review EJB3 integartion such that fixes/features don't get lost across EJB2.1/3.0 -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2848) Tool to analyze class loader consistency

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2848?page=all ] Dimitris Andreadis updated JBAS-2848: ------------------------------------- Component/s: ClassLoading (was: Other) Fix Version/s: JBossAS-4.2.1.CR1 (was: JBossAS-4.2.0.CR1) This tool would have to be described better, in case somebody else can create it. > Tool to analyze class loader consistency > ---------------------------------------- > > Key: JBAS-2848 > URL: http://jira.jboss.com/jira/browse/JBAS-2848 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: ClassLoading > Reporter: Scott M Stark > Fix For: JBossAS-4.2.1.CR1 > > > Since users don't generally care to think about the typesystem ramifications of the generally conflciting class loader setup allowed in ear deployments as evidenced in the associated forum thread, we need better out of the box smarter than the average deployment archive mess that creates an approriate canonical set of classpaths and class loader configuration. A first step is just a tool that identifies potential problems. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1768) Isolating the test harness

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1768?page=all ] Dimitris Andreadis updated JBAS-1768: ------------------------------------- Fix Version/s: JBossAS-4.2.1.CR1 (was: JBossAS-4.2.0.CR1) Assignee: Ryan Campbell Ryan, is there someone from QA that could help with this type of tasks? > Isolating the test harness > -------------------------- > > Key: JBAS-1768 > URL: http://jira.jboss.com/jira/browse/JBAS-1768 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Test Suite > Affects Versions: JBossAS-4.0.1 Final, JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1 > Reporter: Adrian Brock > Assigned To: Ryan Campbell > Fix For: JBossAS-4.2.1.CR1 > > > Since some projects are already using the test harness > org.jboss.test (from the testsuite) > this needs to be isolated to break the circular build dependency. > Additionally, we should look at making this available to users > 1) For their own use > 2) When reporting problems -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1536) Wrong SQL Type for Boolean Mapping for Derby Database

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1536?page=all ] Dimitris Andreadis updated JBAS-1536: ------------------------------------- Fix Version/s: JBossAS-4.2.1.CR1 (was: JBossAS-4.2.0.CR1) > Wrong SQL Type for Boolean Mapping for Derby Database > ----------------------------------------------------- > > Key: JBAS-1536 > URL: http://jira.jboss.com/jira/browse/JBAS-1536 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CMP service > Affects Versions: JBossAS-4.0.1 Final > Environment: JBoss4.0.1; JDK1.5.0update1;Windows XP SP2;Derby 10.0.2.1 Embedded > Reporter: Ingo Bruell > Fix For: JBossAS-4.2.1.CR1 > > > The SQL datatype 'BOOLEAN' is not a valid datatype for the derby database. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1535) PK Constraint name for Datbase Derby to long

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1535?page=all ] Dimitris Andreadis updated JBAS-1535: ------------------------------------- Fix Version/s: JBossAS-4.2.1.CR1 (was: JBossAS-4.2.0.CR1) > PK Constraint name for Datbase Derby to long > -------------------------------------------- > > Key: JBAS-1535 > URL: http://jira.jboss.com/jira/browse/JBAS-1535 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CMP service > Affects Versions: JBossAS-4.0.1 Final > Environment: JBoss4.0.1; JDK1.5.0update1;Windows XP SP2;Derby 10.0.2.1 Embedded > Reporter: Ingo Bruell > Fix For: JBossAS-4.2.1.CR1 > > > In creating time of tables it could happen that a generated name for a pk constraint exceeds the limit of 18 characters. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-3131) Extension-List MANIFEST attribute not honored during deployment of an EAR

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3131?page=all ] Dimitris Andreadis updated JBAS-3131: ------------------------------------- Fix Version/s: (was: JBossAS-4.2.0.CR1) Priority: Minor (was: Major) > Extension-List MANIFEST attribute not honored during deployment of an EAR > ------------------------------------------------------------------------- > > Key: JBAS-3131 > URL: http://jira.jboss.com/jira/browse/JBAS-3131 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Deployment services > Affects Versions: JBossAS-4.0.3 SP1 > Environment: Windows XP SP2, JDK 1.5.0_06 > Reporter: Alexander Sack > Priority: Minor > Fix For: JBossAS-5.0.1.CR1 > > > If a JAR within an EAR specifies an Extension-List MANIFEST attribute, the EAR deployer does not honor it. I have a library, my.jar, that gets deployed that specifies an Extension-Name and Implementation-Version. If any of my jars within an EAR references this library, JBoss ignores the Extension-List attribute. The use of the Extension-List MANIFEST attribute is part of the core J2EE 1.4 spec and the EAR deployment should fail if the Extension-List library is not found (or if it is found and the <name>-Implementatino-Version does not meet the minimal requirements. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-3022) Add support for configuring a DefaultUncaughtExceptionHandler

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3022?page=all ] Dimitris Andreadis updated JBAS-3022: ------------------------------------- Fix Version/s: JBossAS-4.2.1.CR1 (was: JBossAS-4.2.0.CR1) Priority: Minor (was: Major) > Add support for configuring a DefaultUncaughtExceptionHandler > ------------------------------------------------------------- > > Key: JBAS-3022 > URL: http://jira.jboss.com/jira/browse/JBAS-3022 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: MicroContainer bus, Logging > Reporter: Scott M Stark > Priority: Minor > Fix For: JBossAS-4.2.1.CR1 > > > Apparently there can be bad interaction between the jdk default UncaughtExceptionHandler and logging appenders. We should have the ability to install a handler that integrates better with our logging layer. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2967) Incorrect implementation of the Timer service

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2967?page=all ] Dimitris Andreadis updated JBAS-2967: ------------------------------------- Fix Version/s: JBossAS-4.2.1.CR1 (was: JBossAS-4.2.0.CR1) > Incorrect implementation of the Timer service > --------------------------------------------- > > Key: JBAS-2967 > URL: http://jira.jboss.com/jira/browse/JBAS-2967 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Scheduling/Timers > Affects Versions: JBossAS-4.0.1 Final, JBossAS-4.0.0 Final, JBossAS-4.0.2 Final, JBossAS-4.0.2RC1, JBossAS-4.0.1RC1, JBossAS-4.0.1 SP1, JBossAS-4.0.3RC1, JBossAS-4.0.3RC2, JBossAS-4.0.4RC1, JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1 > Environment: Any > Reporter: Andrei Iltchenko > Fix For: JBossAS-4.2.1.CR1 > > > JBoss's implementation of the timer service doesn't account for a potential for SLSB instances of the same bean to concurrently access and modify the same Timer object (I learnt it when inspecting the pertinent source code). > Chapter 22 of the EJB 2.1 spec contains enough information for us to infer how a complaint container must behave provided that a given Timer > object is always accessed and modified in a transactional context: > ? If the reading SLSB instance accesses the Timer object before the transaction of the writing (cancelling) SLSB instance has committed, the reading instance mustn?t see that the timer has been cancelled (seeing it would defeat the very concept of a > transaction); otherwise > ? If the transaction of the writing (cancelling) SLSB instance has already committed, the container must > make the changes to the Timer object visible to the reading SLSB. The spec prescribes that in this case the reading SLSB instance must receive the javax.ejb.NoSuchObjectLocalException. > Thus changes to the state of a timer object (i.e. cancelling it) must be made visible to other instances of the same bean only when the transaction in which the timer was cancelled has been successfully committed. > When I studied JBoss code what I saw was quite alarming ? no effort is put into ensuring that a Timer object cancellation is not visible to other SLSBs that might read the Timer object until the transaction in which it was cancelled is committed. As soon as a SLSB instance cancells the Timer object (and before the transaction is committed or rolled back), all other SLSB instances of the same bean will see it as cancelled and will get > (potentially spurious) NoSuchObjectLocalExceptions. If the canceling transaction is then rolled back, all reading SLSB instances will suddenly succeed in > accessing it (because then the flag in the Timer object will be cleared) comments are mine: > if (status == Status.STATUS_ROLLEDBACK) > { > log.debug("rollback: " + this); > if (timerState == STARTED_IN_TX) > killTimer(); > else if (timerState == CANCELED_IN_TX) > // suddenly again active, even though other beans might already > // have seen it in the cancelled state. > setTimerState(ACTIVE); > I believe the same problem might happend with MDBs 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, 7 months

1
0
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 December 2006