February 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6356) Locally transmitted context data is not received

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/AS7-6356?page=com.atlassian.jira.plugin.s... ] jaikiran pai updated AS7-6356: ------------------------------ Fix Version/s: 7.3.0.Alpha1 (was: 7.2.0.CR1) > Locally transmitted context data is not received > ------------------------------------------------ > > Key: AS7-6356 > URL: https://issues.jboss.org/browse/AS7-6356 > Project: Application Server 7 > Issue Type: Bug > Components: EJB > Affects Versions: 7.1.3.Final (EAP) > Reporter: Wouter De Borger > Assignee: jaikiran pai > Labels: ejb > Fix For: 7.3.0.Alpha1 > > > ContextData attached to request is not transmitted when LocalEJBReceiver is used. > org.jboss.as.ejb3.remote.LocalEJBReceiver:177 > context.setContextData(new HashMap<String, Object>()); > see also https://issues.jboss.org/browse/AS7-5021 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-987) Connectable resource

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-987?page=com.atlassian.jira.plugin.... ] Jesper Pedersen resolved JBJCA-987. ----------------------------------- Resolution: Done > Connectable resource > -------------------- > > Key: JBJCA-987 > URL: https://issues.jboss.org/browse/JBJCA-987 > Project: IronJacamar > Issue Type: Task > Components: Core, JDBC > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.1.0.Beta4 > > > Allow XAResource resources to implement a connectable resource SPI which will allow access to the underlying resource being used -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-6526) It is difficult to identify an EJB Timer with the logged timer-id, especially if it is non persistent

by Wolf-Dieter Fink (JIRA)

[ https://issues.jboss.org/browse/AS7-6526?page=com.atlassian.jira.plugin.s... ] Wolf-Dieter Fink updated AS7-6526: ---------------------------------- Fix Version/s: 7.3.0.Alpha1 (was: 7.2.0.CR1) > It is difficult to identify an EJB Timer with the logged timer-id, especially if it is non persistent > ----------------------------------------------------------------------------------------------------- > > Key: AS7-6526 > URL: https://issues.jboss.org/browse/AS7-6526 > Project: Application Server 7 > Issue Type: Bug > Components: EJB > Affects Versions: 7.2.0.Alpha1 > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > Priority: Minor > Fix For: 7.3.0.Alpha1 > > > The JBAS14143 message and other skip messages log the timer id, but this is not very helpful as it is complicated to find the related application bean if the timer is persistent or not possible if it is a non persistent timer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-263) Remove WeakHash map from BeanELResolver and depend on proper callback to remove bean properties

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/JBWEB-263?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski commented on JBWEB-263: ------------------------------------------ Well, there is no other way to fix JBPAPP-6530( because instance of ELResolver is not visible to AS). Looks like EL resolver in EAP5 must use Class as key. > Remove WeakHash map from BeanELResolver and depend on proper callback to remove bean properties > ----------------------------------------------------------------------------------------------- > > Key: JBWEB-263 > URL: https://issues.jboss.org/browse/JBWEB-263 > Project: JBoss Web > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Bartosz Baranowski > Assignee: Remy Maucherat > Attachments: JBWEB-263.patch > > > As in subject. Even though its a weakhashmap( and current source has the ConcurrentCache. > Affected version: 2.1.12.GA - http://svn.jboss.org/repos/jbossweb/branches/2.1.x/ > Fix version: next( EAP depends on 2.1.13.GA-patch01 or JBOSSWEB_2_1_12_GA_patch03 ) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-263) Remove WeakHash map from BeanELResolver and depend on proper callback to remove bean properties

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/JBWEB-263?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski updated JBWEB-263: ------------------------------------- Comment: was deleted (was: Why wouldnt it work?) > Remove WeakHash map from BeanELResolver and depend on proper callback to remove bean properties > ----------------------------------------------------------------------------------------------- > > Key: JBWEB-263 > URL: https://issues.jboss.org/browse/JBWEB-263 > Project: JBoss Web > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Bartosz Baranowski > Assignee: Remy Maucherat > Attachments: JBWEB-263.patch > > > As in subject. Even though its a weakhashmap( and current source has the ConcurrentCache. > Affected version: 2.1.12.GA - http://svn.jboss.org/repos/jbossweb/branches/2.1.x/ > Fix version: next( EAP depends on 2.1.13.GA-patch01 or JBOSSWEB_2_1_12_GA_patch03 ) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-263) Remove WeakHash map from BeanELResolver and depend on proper callback to remove bean properties

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/JBWEB-263?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski commented on JBWEB-263: ------------------------------------------ Why wouldnt it work? > Remove WeakHash map from BeanELResolver and depend on proper callback to remove bean properties > ----------------------------------------------------------------------------------------------- > > Key: JBWEB-263 > URL: https://issues.jboss.org/browse/JBWEB-263 > Project: JBoss Web > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Bartosz Baranowski > Assignee: Remy Maucherat > Attachments: JBWEB-263.patch > > > As in subject. Even though its a weakhashmap( and current source has the ConcurrentCache. > Affected version: 2.1.12.GA - http://svn.jboss.org/repos/jbossweb/branches/2.1.x/ > Fix version: next( EAP depends on 2.1.13.GA-patch01 or JBOSSWEB_2_1_12_GA_patch03 ) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1567) RetransmitTask throws NPE

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1567?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1567: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 903234|https://bugzilla.redhat.com/show_bug.cgi?id=903234] from ON_QA to VERIFIED > RetransmitTask throws NPE > ------------------------- > > Key: JGRP-1567 > URL: https://issues.jboss.org/browse/JGRP-1567 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.6 > Reporter: Radim Vansa > Assignee: Bela Ban > Fix For: 3.2.7, 3.3 > > > After the UNICAST2.STABLE message is received, {{sent_msgs.purge()}} is called for the sender's entry and Table's {{low == hd == hr}}. Then the {{SenderEntry.getFirstMessage()}} returns null and that causes the NPE below. > There is another race condition when this may happen: When the message is sent down the stack for a new destination a {{SenderEntry}} is inserted into {{send_table}}. This entry, however, contains no messages yet, and, therefore, as the RetransmitTask in {{triggerXmit}} retrieves the first message, it gets null and throws NPE. > {code} > 08:19:05,716 ERROR [org.jgroups.util.TimeScheduler2] (Timer-2,edg-perf09-2672) failed running task UNICAST2: RetransmitTask (interval=500 ms) > java.lang.NullPointerException > at org.jgroups.protocols.UNICAST2.triggerXmit(UNICAST2.java:1326) > at org.jgroups.protocols.UNICAST2$RetransmitTask.run(UNICAST2.java:1294) > at org.jgroups.util.TimeScheduler2$RecurringTask.run(TimeScheduler2.java:591) > at org.jgroups.util.TimeScheduler2$MyTask.run(TimeScheduler2.java:523) > at org.jgroups.util.TimeScheduler2$Entry.execute(TimeScheduler2.java:428) > at org.jgroups.util.TimeScheduler2$1.run(TimeScheduler2.java:286) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > {code} > Theoretically there is another race condition in the {{SenderEntry.getFirstMessage()}} itself - the low value may change between the {{getLow}} and {{get}} calls, but I am not sure when this may happen. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1572) TP.sendToAllPhysicalAddresses does not handle singleton TP

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1572?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1572: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 905387|https://bugzilla.redhat.com/show_bug.cgi?id=905387] from ON_QA to VERIFIED > TP.sendToAllPhysicalAddresses does not handle singleton TP > ---------------------------------------------------------- > > Key: JGRP-1572 > URL: https://issues.jboss.org/browse/JGRP-1572 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.6 > Reporter: Radim Vansa > Assignee: Bela Ban > Fix For: 3.2.7, 3.3 > > > Method {{TP.sendToAllPhysicalAddresses}} does not handle correctly TP being singleton, on line 1419 it calls directly up_prot.up(...) instead of up(...) which can handle multiple stacks based on this TP. > Result is NPE. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-45) Compilation failure caused by a CCE when building a rule with a unification in the LHS

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-45?page=com.atlassian.jira.plugin.... ] Mario Fusco resolved DROOLS-45. ------------------------------- Fix Version/s: 5.6 6.0.0.Alpha1 Resolution: Done > Compilation failure caused by a CCE when building a rule with a unification in the LHS > -------------------------------------------------------------------------------------- > > Key: DROOLS-45 > URL: https://issues.jboss.org/browse/DROOLS-45 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 5.6, 6.0.0.Alpha1 > > > The following DRL doesn't compile and in particular fails with a java.lang.ClassCastException: org.drools.rule.GroupElement cannot be cast to org.drools.rule.Pattern > {code} > declare A > end > declare B > inner : A > end > rule "Init" > when > then > A a = new A(); > insert( a ); > insert( new B( a ) ); > end > rule "Check" > when > B( $in := inner ) > $in := A() > then > end > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-45) Compilation failure caused by a CCE when building a rule with a unification in the LHS

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-45: --------------------------------- Summary: Compilation failure caused by a CCE when building a rule with a unification in the LHS Key: DROOLS-45 URL: https://issues.jboss.org/browse/DROOLS-45 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco The following DRL doesn't compile and in particular fails with a java.lang.ClassCastException: org.drools.rule.GroupElement cannot be cast to org.drools.rule.Pattern {code} declare A end declare B inner : A end rule "Init" when then A a = new A(); insert( a ); insert( new B( a ) ); end rule "Check" when B( $in := inner ) $in := A() then end {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 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 February 2013