March 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBXB-127) Collection types should be repeatable

by Adrian Brock (JIRA)

Collection types should be repeatable ------------------------------------- Key: JBXB-127 URL: http://jira.jboss.com/jira/browse/JBXB-127 Project: JBoss XML Binding (JBossXB) Issue Type: Bug Affects Versions: JBossXB-2.0.0.CR6 Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: JBossXB-2.0.0.CR7 Annotated collection types should have models that are minOccurs=0 maxOccurs=unbounded rather than 1 and 1 for normal types. -- 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

17 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-249) DependencyBuilderListItem should have a removeDependency()

by Adrian Brock (JIRA)

DependencyBuilderListItem should have a removeDependency() ---------------------------------------------------------- Key: JBMICROCONT-249 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-249 Project: JBoss MicroContainer Issue Type: Task Components: AOP Reporter: Adrian Brock Assigned To: Kabir Khan Fix For: JBossMC-2.0.0.CR1 The DepedencyBuilderListItem should have a removedDependency() method with it invoked from the uninstallAction in the MC. Writing the following test would the problem. 1) Create a class that is annotationed with @Whatever 2) Deploy two aspects (A1, A2) that introduce dependencies for @Whatever 3) Deploy the bean 4) The bean should be deployed with A1, A2 5) Move the bean back to the preinstall stage 6) Undeploy aspect A2 7) Try to move the bean back to INSTALLED. It won't work because the bean still remembers the dependency on A2 without a removeDependency() method. -- 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

17 years, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1296) Deleting and readding parent node in tx causes deleted children to survive

by Brian Stansberry (JIRA)

Deleting and readding parent node in tx causes deleted children to survive -------------------------------------------------------------------------- Key: JBCACHE-1296 URL: http://jira.jboss.com/jira/browse/JBCACHE-1296 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.1.0.CR4 Reporter: Brian Stansberry Assigned To: Manik Surtani If a parent node is deleted in a tx, and then in the same tx the parent node is reestablished, pre-existing children of the parent will remain in the cache after the tx commits. They should not. See test org.jboss.cache.api.DeletedChildResurrectionTest for examples. There are 4 tests, 2 each with pessimistic and optimistic locking. One variant reestablishes the parent by simple re-adding it. Another indirectly reestablishes the parent by adding a new child. All fail, but not always in the same way. -- 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

17 years, 9 months

2
6
0 / 0

[JBoss JIRA] Commented: (EJBTHREE-597) javax.persistence.SequenceGenerator mapped to "seqhilo" and not "sequence" by org.hibernate.cfg.AnnotationBinder

by Steve McIntyre (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-597?page=comments#action_12401457 ] Steve McIntyre commented on EJBTHREE-597: ----------------------------------------- Is there a way to get hibernate to map sequence generators to a pooled sequence strategy? Specifically, we need hibernate to honor and use the sequence. However, we'd also like hibernate to grab N sequence values at a time and use them. We don't want hibernate to use an allocationSize multiplier to "calculate" a value, that isn't directly tied to the sequence. > javax.persistence.SequenceGenerator mapped to "seqhilo" and not "sequence" by org.hibernate.cfg.AnnotationBinder > ---------------------------------------------------------------------------------------------------------------- > > Key: EJBTHREE-597 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-597 > Project: EJB 3.0 > Issue Type: Bug > Affects Versions: EJB 3.0 RC7 - FD > Environment: JBoss 4.0.4.GA (using EJB3 packaged in that version of JBoss), Windows XP SP1, Java 1.5.04, Oracle 9 > Reporter: David Richmond > Assigned To: Emmanuel Bernard > > @javax.persistence.SequenceGenerator(name = "Question_id_sequence", sequenceName = "S_QUESTION") > is mapped to a "seqhilo" generator by org.hibernate.cfg.AnnotationBinder (line 332) which causes strange ids to be generated. These ids appear to have no relation to the actual sequence state, even though "select S_QUESTION.nextVal from dual" is generated by Hibernate through JDBC. The ids start at 50 for an intial deployment, 150 after a redeployment, then 250 for the following deployment, etc, etc. > If stored procedures are used which use the S_QUESTION sequence to insert rows into the same table then a conflict will happen sometime in the future, since Hibernate does not use the value from the sequence. > If I replace the above @javax.persistence.SequenceGenerator definition with: > @org.hibernate.annotations.GenericGenerator(name="Question_id_sequence", strategy = "sequence", > parameters = { @Parameter(name="sequence", value="S_QUESTION") } ) > the actual S_QUESTION.nextVal value is used correctly by Hibernate. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1294) remove issues for tx and optimistic locking

by Mircea Markus (JIRA)

remove issues for tx and optimistic locking -------------------------------------------- Key: JBCACHE-1294 URL: http://jira.jboss.com/jira/browse/JBCACHE-1294 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mircea Markus Assigned To: Manik Surtani Fix For: 2.2.0.GA Added following test in NodeAPITest public void testChildrenMissingOnParentRemoval() throws Exception { cache.put("/foo/1/2/3", "item", 1); assertTrue(cache.exists("/foo/1/2/3")); tm.begin(); cache.removeNode("/foo/1"); assertFalse(cache.exists("/foo/1")); //FAILS HERE!!! tm.commit(); assertFalse(cache.exists("/foo/1")); } -- 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

17 years, 9 months

2
4
0 / 0

[JBoss JIRA] Created: (JBXB-126) PropertyHandler is not registered for XmlElementWrapper

by Alexey Loubyansky (JIRA)

PropertyHandler is not registered for XmlElementWrapper ------------------------------------------------------- Key: JBXB-126 URL: http://jira.jboss.com/jira/browse/JBXB-126 Project: JBoss XML Binding (JBossXB) Issue Type: Bug Affects Versions: JBossXB-2.0.0.CR6 Reporter: Alexey Loubyansky Assigned To: Alexey Loubyansky Fix For: JBossXB-2.0.0.CR7 PropertyHandler is not added to the beanAdapterFactory when processing XmlElementWrapper annotation. Due to differences in impl details between handling collections and arrays, the issue affected only properties of array types in combination with XmlElements annotations, i.e. arrays of different elements. -- 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

17 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-5275) org.jboss.test.security.test.XMLLoginModulesUnitTestCase failing on Z-servers

by Martin Malina (JIRA)

org.jboss.test.security.test.XMLLoginModulesUnitTestCase failing on Z-servers ----------------------------------------------------------------------------- Key: JBAS-5275 URL: http://jira.jboss.com/jira/browse/JBAS-5275 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Test Suite Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-4.2.2.GA Environment: Java Version 1.5.0 Java Vendor IBM Corporation Java VM Name IBM J9 VM Java VM Version 2.3 Java VM Info J2RE 1.5.0 IBM J9 2.3 Linux s390-31 j9vmxz3123-20070426 (JIT enabled) J9VM - 20070420_12448_bHdSMr JIT - 20070419_1806_r8 GC - 200704_19 OS Name Linux OS Version 2.6.9-55.EL OS Arch s390 Reporter: Martin Malina Fix For: JBossAS-5.0.0.CR1, JBossAS-4.2.3.GA Getting this: testXmlLoginModuleParsing Failure roles in (Role2, Role3) junit.framework.AssertionFailedError: roles in (Role2, Role3) at org.jboss.test.security.test.XMLLoginModulesUnitTestCase.testXmlLoginModuleParsing(XMLLoginModulesUnitTestCase.java:210) I found out that for some reason when the testsuite is run on Z-systems with IBM 1.5 JDK, the roles from the XML file load in backwards order. That's the only problem here. This is the piece of the XML: <lm:user name="jdukeman" password="anotherduke"> <lm:role name="Role2"/> <lm:role name="Role3"/> <lm:role name="callerJdukeman" group="CallerPrincipal" /> </lm:user> So the problem is that Role3 is loaded as first and Role2 as second which is causing the 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

17 years, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1200) SecondaryTable and insert/update

by Mateusz Mrozewski (JIRA)

SecondaryTable and insert/update -------------------------------- Key: EJBTHREE-1200 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1200 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.1.GA Environment: Linux, Mysql 5 Reporter: Mateusz Mrozewski I have an Entity which is mapped to two tables with @SecondaryTable annotation. The entity has a composite Primary Key. Most of the things work fine. Only the following scenario fails: 1) I have a record in a primary table which corresponds to my entity instance. 2) I have a record in a secondary table too, but only the PK fields are filled. Other are null. 3) I perform the following code: MyEntityPk pk = new MyEntityPk(); pk.setValue1(value1); pk.setValue2(value2); MyEntity entity = em.find(MyEntity.class, pk); entity.setSomeFieldMappedToSecondaryTable(value3); I am expecting an update, because I already have a row in secondary table, but the em tries to perform an insert. When I change value of any field of that row in secondary table (besides pk), an update is performed. It looks like ejb3 recognizes secondary table rows an non existing if all fields beside PK are null. -- 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

17 years, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (JBXB-124) marshalling should fail if required attribute value is missing

by Alexey Loubyansky (JIRA)

marshalling should fail if required attribute value is missing -------------------------------------------------------------- Key: JBXB-124 URL: http://jira.jboss.com/jira/browse/JBXB-124 Project: JBoss XML Binding (JBossXB) Issue Type: Bug Affects Versions: JBossXB-2.0.0.CR6 Reporter: Alexey Loubyansky Assigned To: Alexey Loubyansky Fix For: JBossXB-2.0.0.CR7 Currently if the value for a requied attribute is missing, marshalling proceeds excluding the attribute from the resulting 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

17 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-5080) Need to check transaction status on SQL operations

by Adrian Brock (JIRA)

Need to check transaction status on SQL operations -------------------------------------------------- Key: JBAS-5080 URL: http://jira.jboss.com/jira/browse/JBAS-5080 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.2.2.GA Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: JBossAS-5.0.0.Beta3, JBossAS-4.2.3.GA In 4.2.x the transaction timeout rollsback the transaction rather than marking it rollback only. This means that for the local transaction datasource the connection has effectively moved onto the next transaction. Actual code: Connection c = datasource.getConnection(); // tx timeout here Statement s = createStatement(); s.executeUpdate(); // should not work Actual Code executed in 4.0.x Connection c = pool.getConnection(); // tx timeout here transaction.setRollbackOnly(); Statement s = createStatement(); s.executeUpdate(); tx.rollback(); // Rollsback the update Actual Code executed in 4.2.x Connection c = pool.getConnection(); // tx timeout here transaction.rollback(); Statement s = createStatement(); s.executeUpdate(); // happens "in the next local transaction" -- 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

17 years, 9 months

3
6
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2008