April 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBJCA-1028) Wrong UserTransaction instance used in callback

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1028?page=com.atlassian.jira.plugin... ] Jesper Pedersen resolved JBJCA-1028. ------------------------------------ Resolution: Done > Wrong UserTransaction instance used in callback > ----------------------------------------------- > > Key: JBJCA-1028 > URL: https://issues.jboss.org/browse/JBJCA-1028 > Project: IronJacamar > Issue Type: Bug > Components: Embedded, Standalone > Affects Versions: 1.0.16.Final, 1.1.0.Beta4 > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.17.Final, 1.1.0.Beta5 > > -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1028) Wrong UserTransaction instance used in callback

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-1028: -------------------------------------- Summary: Wrong UserTransaction instance used in callback Key: JBJCA-1028 URL: https://issues.jboss.org/browse/JBJCA-1028 Project: IronJacamar Issue Type: Bug Components: Embedded, Standalone Affects Versions: 1.1.0.Beta4, 1.0.16.Final Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.17.Final, 1.1.0.Beta5 -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (AS7-5620) @Resource injection isn't done on static members

by John Doyle (JIRA)

[ https://issues.jboss.org/browse/AS7-5620?page=com.atlassian.jira.plugin.s... ] John Doyle commented on AS7-5620: --------------------------------- David, it did get opened as an RFE. Can you give me some info or a link on "Jaikiran's component-level interceptor functionality". Is that something that the customer implements, or a new feature? > @Resource injection isn't done on static members > ------------------------------------------------- > > Key: AS7-5620 > URL: https://issues.jboss.org/browse/AS7-5620 > Project: Application Server 7 > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 7.1.3.Final (EAP) > Reporter: Miroslav Novak > Assignee: Stuart Douglas > > There is a change in behaviour of: > {code} > @Resource(mappedName = "java:/JmsXA") > private static ConnectionFactory cf; > {code} > In EAP6/AS7.1.2.Final this property is initialized but in EAP6.0.1.ER2/AS7.1.3.Final is not. > This could also break backward compatibility. Is there a reason why this feature should not work? > Used MDB: > {code} > import java.util.concurrent.atomic.AtomicInteger; > import javax.annotation.Resource; > import javax.ejb.*; > import javax.jms.*; > import org.apache.log4j.Level; > import org.apache.log4j.Logger; > @MessageDriven(name = "mdb", > activationConfig = { > @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"), > @ActivationConfigProperty(propertyName = "destination", propertyValue = "jms/queue/InQueue")}) > @TransactionManagement(value = TransactionManagementType.CONTAINER) > @TransactionAttribute(value = TransactionAttributeType.REQUIRED) > public class LocalMdbFromQueue implements MessageDrivenBean, MessageListener { > @Resource(mappedName = "java:/JmsXA") > private static ConnectionFactory cf; > @Resource(mappedName = "java:/jms/queue/OutQueue") > private static Queue queue; > public static AtomicInteger globalCounter = new AtomicInteger(); > private static final long serialVersionUID = 2770941392406343837L; > private static final Logger log = Logger.getLogger(LocalMdbFromQueue.class.getName()); > private MessageDrivenContext context = null; > public LocalMdbFromQueue() { > super(); > } > @Override > public void setMessageDrivenContext(MessageDrivenContext ctx) { > this.context = ctx; > } > public void ejbCreate() { > } > @Override > public void ejbRemove() { > } > @Override > public void onMessage(Message message) { > Connection con = null; > Session session; > try { > long time = System.currentTimeMillis(); > int counter = 0; > try { > counter = message.getIntProperty("count"); > } catch (Exception e) { > log.log(Level.ERROR, e.getMessage(), e); > } > String messageInfo = message.getJMSMessageID() + ", count:" + counter; > log.log(Level.INFO, " Start of message: " + globalCounter.incrementAndGet() + ", message info:" + messageInfo); > con = cf.createConnection(); > con.start(); > session = con.createSession(false, Session.AUTO_ACKNOWLEDGE); > String text = message.getJMSMessageID() + " processed by: " + hashCode(); > MessageProducer sender = session.createProducer(queue); > TextMessage newMessage = session.createTextMessage(text); > newMessage.setStringProperty("inMessageId", message.getJMSMessageID()); > sender.send(newMessage); > log.log(Level.INFO, " End of " + messageInfo + " in " + (System.currentTimeMillis() - time) + " ms"); > } catch (Exception t) { > t.printStackTrace(); > log.log(Level.FATAL, t.getMessage(), t); > } finally { > if (con != null) { > try { > con.close(); > } catch (JMSException e) { > log.log(Level.FATAL, e.getMessage(), e); > } > } > } > } > } > {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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-69) Allow syslog severity level to log level mapping to be user defined

by James Perkins (JIRA)

James Perkins created LOGMGR-69: ----------------------------------- Summary: Allow syslog severity level to log level mapping to be user defined Key: LOGMGR-69 URL: https://issues.jboss.org/browse/LOGMGR-69 Project: JBoss Log Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: James Perkins Assignee: David Lloyd Priority: Minor -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-69) Allow syslog severity level to log level mapping to be user defined

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-69?page=com.atlassian.jira.plugin.... ] James Perkins reassigned LOGMGR-69: ----------------------------------- Assignee: James Perkins (was: David Lloyd) > Allow syslog severity level to log level mapping to be user defined > ------------------------------------------------------------------- > > Key: LOGMGR-69 > URL: https://issues.jboss.org/browse/LOGMGR-69 > Project: JBoss Log Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-967) ClassLoader memory leak with JSF

by Stan Silvert (JIRA)

[ https://issues.jboss.org/browse/WFLY-967?page=com.atlassian.jira.plugin.s... ] Stan Silvert commented on WFLY-967: ----------------------------------- I'm not seeing an actual leak. The instances do go away eventually. It looks like something is timing out after 30 minutes, which makes these instances eligible for GC. That made me thing it had something to do with session timeout. But I'm not sure at this point. When I tried setting session timeout to a lower value, I found a bug in Undertow, UNDERTOW-42. Can you try to replicate my results on your end? > ClassLoader memory leak with JSF > -------------------------------- > > Key: WFLY-967 > URL: https://issues.jboss.org/browse/WFLY-967 > Project: WildFly > Issue Type: Bug > Components: JSF > Reporter: Vlad Arkhipov > Assignee: Stan Silvert > Priority: Critical > Attachments: war-leak.tar.gz > > > JSF application's classes are not unloaded properly when undeployed. The test case is in the attachment. Steps to reproduce: > # mvn package > # deploy war-leak.war > # open http://localhost:8080/war-leak > # undeploy war-leak.war > # analyze a heap dump to find unloaded ModuleClassLoader of war-leak.war > References to the WAR classes are hold by java.beans.Introspector caches. It seems to be a known bug (feature?). For example Tomcat automatically invokes java.beans.Introspector.flushCaches() when WAR undeploys. There is also IntrospectorCleanupListener in Spring for the same purpose. > http://wiki.apache.org/commons/Logging/UndeployMemoryLeak > http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/... -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1610) LockingService and rpc on the same cluster, tryLock() hangs

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1610?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1610: -------------------------------- OK, it is clear why this fails: - A invokes a *synchronous* (blocking) RPC on B - UNICAST delivers the RPC from A at B - The RPC tries to acquire the lock from A (who already holds it) - A sends back a LOCK-DENIED unicast to B - However, because B is already processing the RPC from A; the LOCK-DENIED messages won't get processed until the RPC returns. However, the RPC will only return when the lock has been granted or denied ==> A classic deadlock ! SOLUTION: #1 Invoke the initial RPC as ASYNC RPC, or hold a future to it #2 JGroups sends all messages which have no ordering contraints as OOBs, e.g. LOCK-GRANTED / LOCK-DENIED > LockingService and rpc on the same cluster, tryLock() hangs > ----------------------------------------------------------- > > Key: JGRP-1610 > URL: https://issues.jboss.org/browse/JGRP-1610 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3 > > Attachments: RpcLockingTest.java > > > Hi, > Yes, the sequence diagram only depicted the second part of my description. > Anyway, I've attached a test file that reproduce the problem. > It contains two test cases, one where the coordinator of the lock is the one who > sends the message first, and a second case where the non-coordinator sends > the message first. > In the first case the receiver, non-coordinator, will hang in tryLock. In the second > case though, everything works fine. > Regards, > Daniel Olausson > On 25 March 2013 16:15, Bela Ban <belaban(a)yahoo.com> wrote: > Hi Daniel, > the sequence diagram differs from your description, can you submit a > test case (e.g. copy MessageDispatcherRSVPTest and modify it), so I can > take a look ? > I assume your RPCs are blocking (sync) and non-OOB ? Could be a > recursive invocation, where FIFO order (default) leads to a distributed > deadlock. > A test case would clarify what you want to do, and if I can reproduce > the problem, I can fix it. > On 3/25/13 1:54 PM, Daniel Olausson wrote: > > Hi, > > > > We trying to use the same channel for our lockingService and > > rpcDispatcher. But we are noticing some weird behavior. > > > > The end result is that lock.tryLock(lockName) never returns, which it > > should always do. > > > > This happens when we do the following: > > > > On computer A, we lock the lock. > > Do a rpc to a function on computer B, this function tries to take the > > lock(lock.tryLock(lockName)), but it can't because the lock is locked. > > This is correct behavior. > > Computer A unlocks the lock. > > > > On computer B we now do the same procedure, we lock the lock and do a > > rpc to computer A, but here is when the strange thing happens. Computer > > A tries to take the lock by executing tryLock, but it never returns. > > > > Here is a sequence diagram: > > http://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgQXV0aGVudGljY... > > > > > > In this example we use the standard udp.xml with <CENTRAL_LOCK/> added > > on the top of the stack. Everything works if we use PEER_LOCK but then > > we need the messages to arrive in the same order everywhere, e.g. atomic > > broadcast. > > > > It also works if we use different clusters for locking and rpc, but it > > would be convenient if we could use the same cluster. > > > > > > Is it recommended to use the same channel for different services? > > -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-518) JSR-245 JSP 2.3 Support

by Shelly McGowan (JIRA)

[ https://issues.jboss.org/browse/WFLY-518?page=com.atlassian.jira.plugin.s... ] Shelly McGowan commented on WFLY-518: ------------------------------------- Proposed Changes for JSP 2.3: http://jcp.org/aboutJava/communityprocess/maintenance/jsr245/245-MR3.html > JSR-245 JSP 2.3 Support > ----------------------- > > Key: WFLY-518 > URL: https://issues.jboss.org/browse/WFLY-518 > Project: WildFly > Issue Type: Sub-task > Components: Web (JBoss Web) > Reporter: David Lloyd > Fix For: 8.0.0.Alpha1 > > > Per Java EE 7, update to JSP 2.3 API and implementation. -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-111) Ruleflow group activation/deactivation calls wrong listener methods

by Ales Dolecek (JIRA)

[ https://issues.jboss.org/browse/DROOLS-111?page=com.atlassian.jira.plugin... ] Ales Dolecek updated DROOLS-111: -------------------------------- Summary: Ruleflow group activation/deactivation calls wrong listener methods (was: Ruleflow group activation/deactivation calls weong listener methods) > Ruleflow group activation/deactivation calls wrong listener methods > ------------------------------------------------------------------- > > Key: DROOLS-111 > URL: https://issues.jboss.org/browse/DROOLS-111 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Reporter: Ales Dolecek > Assignee: Mark Proctor > Priority: Minor > Labels: listeners > Original Estimate: 10 minutes > Remaining Estimate: 10 minutes > > Method org.drools.impl.StatefulKnowledgeSessionImpl$AgendaEventListenerWrapper.beforeRuleFlowGroupActivated delegates to listener.afterRuleFlowGroupActivated. > Method beforeRuleFlowGroupDeactivated delegates to listener.afterRuleFlowGroupDeactivated. > Thus when (de)activating ruleflow-group the before methods of any registered listener are NOT invoked while the after methods are invoked TWICE. -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-111) Ruleflow group activation/deactivation calls weong listener methods

by Ales Dolecek (JIRA)

Ales Dolecek created DROOLS-111: ----------------------------------- Summary: Ruleflow group activation/deactivation calls weong listener methods Key: DROOLS-111 URL: https://issues.jboss.org/browse/DROOLS-111 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.5.0.Final Reporter: Ales Dolecek Assignee: Mark Proctor Priority: Minor Method org.drools.impl.StatefulKnowledgeSessionImpl$AgendaEventListenerWrapper.beforeRuleFlowGroupActivated delegates to listener.afterRuleFlowGroupActivated. Method beforeRuleFlowGroupDeactivated delegates to listener.afterRuleFlowGroupDeactivated. Thus when (de)activating ruleflow-group the before methods of any registered listener are NOT invoked while the after methods are invoked TWICE. -- 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

11 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2013