August 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCOMMON-102) Release jboss-common-core 2.2.18

by Dimitris Andreadis (JIRA)

Release jboss-common-core 2.2.18 -------------------------------- Key: JBCOMMON-102 URL: https://jira.jboss.org/jira/browse/JBCOMMON-102 Project: JBoss Common Issue Type: Release Security Level: Public (Everyone can see) Components: common-core (2.x) Reporter: Dimitris Andreadis Assignee: Dimitris Andreadis Fix For: 2.2.18.GA -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
3
0 / 0

[JBoss JIRA] Created: (JBAOP-794) JBoss AOP deadlocks on JBoss AS with pluggable instrumentor

by Flavia Rainone (JIRA)

JBoss AOP deadlocks on JBoss AS with pluggable instrumentor ----------------------------------------------------------- Key: JBAOP-794 URL: https://jira.jboss.org/browse/JBAOP-794 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.1.Alpha2, 1.5.6.GA, 1.5.5 CP04 Reporter: Flavia Rainone Assignee: Flavia Rainone Fix For: 1.5.7.GA, 2.1.6 CP01 JBoss AOP deadlocks in loadtime weaving mode on JBoss AS. This is the scenario: -one thread loading a class starts loadtime weaving. In the process, the classloader performing the loading is locked. The thread ends up needing a concurrency lock held by the other thread. - another thread loading a class also starts loadtime weaving. In the process, this threads locks one of the concurrency locks and ends up needing to load a class (JBoss AOP or Javassist class). For loading this class, however, this thread needs the class loader lock held by the first thread. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

2
4
0 / 0

[JBoss JIRA] Created: (JBAOP-793) Enable AspectManager's write lock during aspect loading

by Flavia Rainone (JIRA)

Enable AspectManager's write lock during aspect loading ------------------------------------------------------- Key: JBAOP-793 URL: https://jira.jboss.org/browse/JBAOP-793 Project: JBoss AOP Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.1.Alpha2, 1.5.6.GA, 1.5.5 CP04 Reporter: Flavia Rainone Assignee: Flavia Rainone Fix For: 1.5.7.GA, 2.1.6 CP01 Both AspectXMLLoader and AspectAnnotationLoader eventually trigger several operations at AspectManager that require write lock. Between two operations, on a multi-threaded loadtime-weaving scenario, a class loading in the Aspect***Loader thread may result in a dead lock. To avoid this scenario, we can enable the write during the entire aspect loading operation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-4514) CLONE -Deadlock when logging trace

by chris effenberger (JIRA)

CLONE -Deadlock when logging trace ---------------------------------- Key: JBAS-4514 URL: http://jira.jboss.com/jira/browse/JBAS-4514 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: chris effenberger Assigned To: Scott M Stark SourceForge Submitter: genman . This was caused when trace was enabled. I imagine it was caused by the classloader trying to load a class while it was being rendered (?) to disk. Probably not a big issue, unless trace-logging is enabled. Java stack information for the threads listed above: =================================================== "SMPP-TIMER-0": at com.logica.smpp.util.ByteBuffer.getHexDump(ByteBuffer.java:379) at com.logica.smpp.util.ByteBuffer.toString(ByteBuffer.java:387) at org.apache.log4j.or.DefaultRenderer.doRender(DefaultRenderer.java:26) at org.apache.log4j.or.RendererMap.findAndRender(RendererMap.java:70) at org.apache.log4j.spi.LoggingEvent.getRenderedMessage(LoggingEvent.java:288) at org.apache.log4j.helpers.PatternParser$BasicPatternConverter.convert(PatternParser.java:395) at org.apache.log4j.helpers.PatternConverter.format(PatternConverter.java:56) at org.apache.log4j.PatternLayout.format(PatternLayout.java:495) at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:292) at org.apache.log4j.WriterAppender.append(WriterAppender.java:150) at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:221) - locked <0x473874c8> (a org.apache.log4j.ConsoleAppender) at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:57) at org.apache.log4j.Category.callAppenders(Category.java:187) - locked <0x46829180> (a org.apache.log4j.spi.RootCategory) at org.apache.log4j.Category.forcedLog(Category.java:372) at org.apache.log4j.Category.debug(Category.java:241) at com.logica.smpp.debug.Log4JDebug.write(Log4JDebug.java:79) at com.logica.smpp.TCPIPConnection.send(TCPIPConnection.java:301) at com.logica.smpp.Transmitter.send(Transmitter.java:81) at com.logica.smpp.Session.send(Session.java:983) at com.logica.smpp.Session.bind(Session.java:452) at ... "SMSC-Accept-16910": at org.apache.log4j.Category.callAppenders(Category.java:185) - waiting to lock <0x46829180> (a org.apache.log4j.spi.RootCategory) at org.apache.log4j.Category.forcedLog(Category.java:372) at org.apache.log4j.Category.log(Category.java:864) at org.jboss.logging.Log4jLoggerPlugin.trace(Log4jLoggerPlugin.java:96) at org.jboss.logging.Logger.trace(Logger.java:113) at org.jboss.mx.loading.UnifiedClassLoader3.attempt(UnifiedClassLoader3.java:242) at org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:126) - locked <0x472e2f38> (a org.jboss.mx.loading.UnifiedClassLoader3) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) - locked <0x472e2f38> (a org.jboss.mx.loading.UnifiedClassLoader3) at com.proteusmobile.smsgw.server.ServerService.listen(ServerService.java:187) at com.proteusmobile.smsgw.server.ServerService.access$3(ServerService.java:46) at com.proteusmobile.smsgw.server.ServerService$Listener.run0(ServerService.java:163) at com.proteusmobile.smsgw.server.ServerService$Listener.run(ServerService.java:154) at java.lang.Thread.run(Thread.java:536) Found 1 deadlock. -- 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

13 years, 1 month

3
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1037) JDBCPersistenceManager.java - reference should be inserted after message (ORA-02291: integrity constraint)

by Mariusz Olejnik (JIRA)

JDBCPersistenceManager.java - reference should be inserted after message (ORA-02291: integrity constraint) ---------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1037 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1037 Project: JBoss Messaging Issue Type: Patch Components: Messaging Core Persistence Affects Versions: 1.4.0.CR1 Environment: Windows XP / Oracle 10g Reporter: Mariusz Olejnik Assigned To: Tim Fox Priority: Critical Fix For: 1.4.0.CR1 Reference should be inserted after message because: oracle-persistence-service.xml CREATE TABLE JBM_MSG_REF ( CHANNEL_ID INTEGER, MESSAGE_ID INTEGER REFERENCES JBM_MSG(MESSAGE_ID) [...] -- 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

13 years, 2 months

5
5
0 / 0

[JBoss JIRA] Created: (JBVFS-160) FileSystemContext.getFileURI returns wrong URI for UNC paths on Windows

by James Livingston (JIRA)

FileSystemContext.getFileURI returns wrong URI for UNC paths on Windows ----------------------------------------------------------------------- Key: JBVFS-160 URL: https://jira.jboss.org/browse/JBVFS-160 Project: JBoss VFS Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.1.3.SP1 Environment: Windows Reporter: James Livingston Assignee: John Bailey Attachments: UncPathTest.java When passed a File for something with a UNC path (e.g. \\127.0.0.1\shared), FileSystemContext.getFileURI() return a URI like "file://127.0.0.1/shared" (which is what Windows itself uses) rather than "file:////127.0.0.1/shared" (which Java uses, and converts for OS calls). This will cause JBoss to fail to deploy things if they are located on an unmapped UNC location. I'm attaching a test case for this. To use it, you need to run it on a Windows system and have access to a something with a UNC path. The code as written expects there to be a SMB share called "shared" on the machine it is run on, but it can easily be change to point elsewhere. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

3
12
0 / 0

[JBoss JIRA] Created: (JBRULES-2487) NPE on line 69 of ConcurrentNodeMemories.java when calling JPAKnowledgeService.loadStatefulKnowledgeSession

by hoogenbj (JIRA)

NPE on line 69 of ConcurrentNodeMemories.java when calling JPAKnowledgeService.loadStatefulKnowledgeSession ----------------------------------------------------------------------------------------------------------- Key: JBRULES-2487 URL: https://jira.jboss.org/jira/browse/JBRULES-2487 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Environment: JBoss 4.2.3, Java 6 64-bit, Windows Vista 64-bit Reporter: hoogenbj Assignee: Mark Proctor Hi, I get a NullPointerException on line 69 of ConcurrentNodeMemories when calling JPAKnowledgeService.loadStatefulKnowledgeSession(...) in order to complete a work item using session.getWorkItemManager().completeWorkItem(...). Further investigation reveals that the objectType on line 332 of InputMarshaller refers to one of my objects that I passed as part of the second argument object when calling startProcess on the knowledge session that I got with JPAKnowledgeService.newStatefulKnowledgeSession. The objectTypeNode on line 333 of InputMarshaller is null which eventually causes the NPE in ConcurrentNodeMemories. This error does not occurr when starting and completing the whole process without retrieving the session from the database. Which seems to indicate that something is not persisted or correctly retrieved from the database. This is a serious problem for us. It means we have to find an alternative for Drools flow... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

6
9
0 / 0

[JBoss JIRA] Created: (JBRULES-2279) Cached ObjectTypeNodes are not restored when deserializing session

by Kris Verlaenen (JIRA)

Cached ObjectTypeNodes are not restored when deserializing session ------------------------------------------------------------------ Key: JBRULES-2279 URL: https://jira.jboss.org/jira/browse/JBRULES-2279 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (expert) Reporter: Kris Verlaenen Assignee: Edson Tirelli When the InputMarshaller is restoring facts in the working memory, it is using the ObjectTypeNodes of the rete tree to link the facts to their object type nodes. This currently fails if no ObjectTypeNode is present for that type (because the type is not used in a rule somewhere). This ObjectTypeNode should be recreated on request if necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

4
9
0 / 0

[JBoss JIRA] Created: (JBAS-8245) Fix org.jboss.test.profileservice.test.Ejb3MetricsUnitTestCase

by Brian Stansberry (JIRA)

Fix org.jboss.test.profileservice.test.Ejb3MetricsUnitTestCase -------------------------------------------------------------- Key: JBAS-8245 URL: https://jira.jboss.org/browse/JBAS-8245 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: EJB3, Test Suite Reporter: Brian Stansberry Fix For: 6.0.0.Final http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

5
10
0 / 0

[JBoss JIRA] Created: (JBAS-8268) Should we add a relax flag for people using out of order content inside elements of their XML files

by Emmanuel Bernard (JIRA)

Should we add a relax flag for people using out of order content inside elements of their XML files --------------------------------------------------------------------------------------------------- Key: JBAS-8268 URL: https://jira.jboss.org/browse/JBAS-8268 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Deployers Affects Versions: 6.0.0.M4 Reporter: Emmanuel Bernard Assignee: Ales Justin Fix For: 6.0.0.Final It seems that JBoss AS 6 and JBoss XB are stricter than they used to wrt the order of the content in elements https://jira.jboss.org/browse/JBAS-8265?focusedCommentId=12542087#action_... Would it make sense to have a flag to relax this rule? I am thinking of people with existing applications trying to deploy into AS 6 from 5 and seeing such errors (ease of use and less pain in support down the road). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

6
15
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2010