February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-660) Inline JCI and remove uneeded dependencies

by Mark Proctor (JIRA)

Inline JCI and remove uneeded dependencies ------------------------------------------ Key: JBRULES-660 URL: http://jira.jboss.com/jira/browse/JBRULES-660 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: All Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m1 Inline JCI and strip all uneeded dependencies, like collections, lang, io and logger. -- 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, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-449) Logical dependency bug, justifier tuple contains retracted handles, logically depend object stays in working memory

by Juergen none (JIRA)

Logical dependency bug, justifier tuple contains retracted handles, logically depend object stays in working memory ------------------------------------------------------------------------------------------------------------------- Key: JBRULES-449 URL: http://jira.jboss.com/jira/browse/JBRULES-449 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 3.0.4 Environment: jdk 1.4.2_10 Reporter: Juergen none Assigned To: Mark Proctor A rather complicated, intertwined set of rules leads to a logically asserted fact, that remains in working memory, even after its justifiers have been retracted. Sadly I have no unit-test, but I can outline the rules and execution sequence as reported by a listener (a ... assert, al ... assert logical, r ... retract) Its a buggy (R5 twice) implementation of a accumulating set of rules I posted in the user list some time ago. FFF(A), FFF(B) are of same class but not equal, @... is systemHashCode, so different instances, but possible equal (as mentioned) classes without @ have only one instance in working memory a XXX R0: XXX -> al DDD a AAA (external assert) Sequence of rules fired R1: AAA -> al GGG R2: DDD, GGG -> al CCC R3: GGG -> al EEE R4: EEE, DDD, CCC -> a BBB@15737ca, al FFF@b2d75c(A) (BBB@15737ca contributes to hash/equals of FFF@b2d75c) R5: BBB, CCC, FFF(A), not FFF(B) -> mod CCC (hashcodes changes, but all rules are still fulfilled as before), a FFF@b274de(B) R5 again (modify triggered): EEE, DDD, CCC -> a BBB@16d8ba (but equals(BBB@15737ca) is true), (+ my guess, object created and assert called but no listener info: al FFF@2aefe3(A) (equals FFF@b2d75c, backing its logical dependency) (BBB@16d8ba contributes to Hash/equals)) --- r AAA (external retract) -> (according to listener): r AAA r GGG r EEE r CCC breakpoint, screenshot --> justifier list is invalid, contains retracted handles PoolCondition would be DDD, the only valid handle in the (EEE, DDD, CCC) tuple r XXX (retract of XXX has no consequence, just the last handle, still valid in the screenshot, becomes invalid too) -> r XXX r DDD workingMemory.getObjects() lists FFF@b2d75c(A) and FFF@b274de(B) for Rulebase-properties: - RuleBaseConfiguration.PROPERTY_ASSERT_BEHAVIOR -> RuleBaseConfiguration.WM_BEHAVIOR_IDENTITY - empty Major lead could be that after commenting out "mod CCC", FFF(A) is retracted (+ R5 not fired a second time) + problem with changed hashcode of CCC ? + problem with second instances of BBB and FFF(A) being asserted + FFF(B) being assert normally, not logically -- 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, 2 months

4
12
0 / 0

[JBoss JIRA] Created: (JBCACHE-964) Optional 1.x marshalling for CacheLoaders using VersionAwareMarshaller

by Galder Zamarreno (JIRA)

Optional 1.x marshalling for CacheLoaders using VersionAwareMarshaller ---------------------------------------------------------------------- Key: JBCACHE-964 URL: http://jira.jboss.com/jira/browse/JBCACHE-964 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: Cache loaders Reporter: Galder Zamarreno Assigned To: Galder Zamarreno Priority: Minor Fix For: 2.0.0.BETA2, 2.0.0.GA Customers that want to use JBossCache 2.x might be reluctant to migrate their data from one format to the other. I can see how an existing customer might think this is a proper pain in the ass, independent of the benefits, and might reduce adoption among them. We want to remove barriers upgrading, but at the same time, we want new customer to use new marshalling, so I'd actually implement the possibility to use 1.x marshalling which is plan java serialization at the CacheLoader level. This could easily achieved adding a property to the <properties> section. The default in 2.x should be to use VAM and only people who are resilient to change their existing stores to VAM should use the 1.x option, which would need explicitly definition. This option also makes it easier for migration purpouses as customers should be able to start two cache instances with different cache loader marshalling method set. They could then loop through the first one using get operations and call put in the second instance. Just note that this does not apply to the marshalling done at replication level as there's no hard data that needs migrating. -- 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, 2 months

3
13
0 / 0

[JBoss JIRA] Created: (JBBUILD-337) Change the JBoss Common Maven build scripts so that they use an inheritance model, and add JBossRetro

by Paul Gier (JIRA)

Change the JBoss Common Maven build scripts so that they use an inheritance model, and add JBossRetro ----------------------------------------------------------------------------------------------------- Key: JBBUILD-337 URL: http://jira.jboss.com/jira/browse/JBBUILD-337 Project: JBoss Build System Issue Type: Feature Request Components: Maven Reporter: Paul Gier Assigned To: Paul Gier The plugin configuration can be moved to the main build pom. Also the jar plugin should be changed to specify a minimum version of 2.1 so that the configuration parameters will always work. JBoss retro should also be called using the antrun plugin. -- 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, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-885) Connecting to two JBoss messaging servers causes interference

by Ben Anderson (JIRA)

Connecting to two JBoss messaging servers causes interference ------------------------------------------------------------- Key: JBMESSAGING-885 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-885 Project: JBoss Messaging Issue Type: Bug Components: JMS Client Manager Affects Versions: 1.0.1.SP4 Environment: Windows XP, Java 1.4.2-b28, JBoss 4.0.4.GA, Pentium 4 2GB RAM Reporter: Ben Anderson Assigned To: Ovidiu Feodorov When connected to two JBoss messaging servers, shutting down one server can affect (i.e. stop) the message listeners connected to the other server. -- 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, 2 months

3
5
0 / 0

[JBoss JIRA] Created: (JBTM-195) Unexpected exception thrown with single readonly participant

by Kevin Conner (JIRA)

Unexpected exception thrown with single readonly participant ------------------------------------------------------------ Key: JBTM-195 URL: http://jira.jboss.com/jira/browse/JBTM-195 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: WS-T Implementation Affects Versions: 4.2.2 Reporter: Kevin Conner Assigned To: Kevin Conner An AT transaction with a single readonly participant results in an unexpected exception being through from the completion client. More details can be found in the associated forum entry. -- 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, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBTM-189) transaction manager is not properly closing connections on slave server when slave server has exceptions.

by Quande Ren (JIRA)

transaction manager is not properly closing connections on slave server when slave server has exceptions. --------------------------------------------------------------------------------------------------------- Key: JBTM-189 URL: http://jira.jboss.com/jira/browse/JBTM-189 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTS Implementation Environment: JBossAS4.0.5, JBossTS4.2.2, multiple servers, distributed transactions. Reporter: Quande Ren Assigned To: Mark Little Priority: Critical This is fully discussed at the forum: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=97856 I am using JBoss4.0.5.GA and JBossTS4.2.2. I have a ServerA and ServerB and a client. here is my flow senario: Code: 1. client call a stateless session BeanA on ServerA, 2. BeanA do some pre work, 3. BeanA then call another stateless session BeanB on serverB, 4. BeanB do some work, 5. BeanA do some post work. the result shows that if either step 2 or step 5 failed, then the whole transaction get rollbacked correctly. but if step 4 failed, then transaction on ServerA rollback, but the transaction on ServerB does not get rollbacked or committed, we can see the debug information says the xa datasource transaction get started but never get rollbacked. and the database connection remains in use, and when we run the test several times, all the database connections will used up. -- 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, 2 months

4
5
0 / 0

[JBoss JIRA] Created: (JBAS-4041) jboss_init_redhat.sh is incompatible with a clustered config

by Jeff Schnitzer (JIRA)

jboss_init_redhat.sh is incompatible with a clustered config ------------------------------------------------------------ Key: JBAS-4041 URL: http://jira.jboss.com/jira/browse/JBAS-4041 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Other Affects Versions: JBossAS-4.0.5.GA Reporter: Jeff Schnitzer The jboss_init_redhat.sh by default specifies a bind address of 0.0.0.0. This won't work with cluster-service.xml, which cannot accept a 0.0.0.0 bind address for the following entry:  <attribute name="NodeAddress">${jboss.bind.address}</attribute> The proper fix to the init script is to by default NOT specify a -b bind address at all. Thanks, Jeff -- 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, 2 months

3
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-828) Use of pre configured ClientID on the database will change the pre configured clientID on the datasource

by Clebert Suconic (JIRA)

Use of pre configured ClientID on the database will change the pre configured clientID on the datasource -------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-828 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-828 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.0.1.SP4 Reporter: Clebert Suconic Assigned To: Clebert Suconic Fix For: 1.0.1.SP5 This is about merging JBMESSAGING-826 into SP5 -- 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, 2 months

2
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-886) Client unable to reconnect to JBoss 1.0.1.SP4 after restart

by Ben Anderson (JIRA)

Client unable to reconnect to JBoss 1.0.1.SP4 after restart ----------------------------------------------------------- Key: JBMESSAGING-886 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-886 Project: JBoss Messaging Issue Type: Bug Components: JMS Client Manager Affects Versions: 1.0.1.SP4 Environment: Windows XP, Java 1.4.2-b28, JBoss 4.0.4.GA, Pentium 4 2GB Reporter: Ben Anderson Assigned To: Ovidiu Feodorov When JBoss is shutdown our producer/consumer threads appear to become 'stuck' in the jboss client when attempting to tidy-up after the problem with the Connection is detected. By tidy-up I mean we attempt to close our producers/consumers, sessions and finally the connections themselves - before starting over and recreating everything (i.e. the connection, session etc). Restarting the server again will often 'unlock' the producer/consumer threads This issue may be a dupe of http://jira.jboss.com/jira/browse/JBMESSAGING-836 -- 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, 2 months

3
5
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 February 2007