November 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGMGR-86) Create an exception filter

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-86?page=com.atlassian.jira.plugin.... ] James Perkins updated LOGMGR-86: -------------------------------- Forum Reference: https://community.jboss.org/thread/234151 > Create an exception filter > -------------------------- > > Key: LOGMGR-86 > URL: https://issues.jboss.org/browse/LOGMGR-86 > Project: JBoss Log Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: James Perkins > Assignee: James Perkins > Priority: Optional > > For now this is just a thought so that users can filter messages based on an exception in the stack trace. Currently it's not possible to use a regex filter as the stack trace is not used in when testing for matches and it probably shouldn't be 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1307) TimedOutputStream OutputTimerTask call to close on SSL OutputStream blocks

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1307?page=com.atlassian.jira.plugin... ] Ron Sigal updated JBREM-1307: ----------------------------- Attachment: jboss-remoting.jar jboss-remoting-src.jar This fix will be in release 2.5.4.SP5. I'm attaching a jboss-remoting.jar in case someone wants to try it. > TimedOutputStream OutputTimerTask call to close on SSL OutputStream blocks > -------------------------------------------------------------------------- > > Key: JBREM-1307 > URL: https://issues.jboss.org/browse/JBREM-1307 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: transport > Affects Versions: 2.2.3.SP2 > Environment: JBoss EAP 4.3.0 CP08 and CP10 > Reporter: Doug Grove > Assignee: Ron Sigal > Labels: messaging > Attachments: jboss-remoting-src.jar, jboss-remoting.jar > > > In order to provide a mechanism for timing out a network/socket write operation, the org.jboss.remoting.transport.socket.TimedOutputStream class starts a timer. If the duration of the write operation exceeds the timer interval, then the timer will call close() on the output stream. This interrupts the output stream write() operation and causes the write operation to throw an IOException. > When the output stream uses secure sockets (SSL), however, the call to close() on the output stream can block indefinitely. The threads associated with the write() and close() operation will only clear when the tcp keepalive timeout mechanism in the operation system is invoked. > This appears to be related to a know bug in the java runtime: http://bugs.sun.com/view_bug.do?bug_id=6358629 > Specifically, in a thread dump you will see: > "Timer-9" daemon prio=10 tid=0x5016c400 nid=0x2638 waiting on condition [0x4cbad000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x585021a0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114) > at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186) > at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262) > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:720) > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.sendAlert(SSLSocketImpl.java:1720) > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.warning(SSLSocketImpl.java:1564) > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.closeInternal(SSLSocketImpl.java:1362) > - locked <0x58502030> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl) > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.close(SSLSocketImpl.java:1301) > at com.sun.net.ssl.internal.ssl.AppOutputStream.close(AppOutputStream.java:80) > at org.jboss.remoting.transport.socket.TimedOutputStream.close(TimedOutputStream.java:57) > at org.jboss.remoting.transport.socket.TimedOutputStream$OutputTimerTask.run(TimedOutputStream.java:145) > at java.util.TimerThread.mainLoop(Timer.java:512) > at java.util.TimerThread.run(Timer.java:462) -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-86) Create an exception filter

by James Perkins (JIRA)

James Perkins created LOGMGR-86: ----------------------------------- Summary: Create an exception filter Key: LOGMGR-86 URL: https://issues.jboss.org/browse/LOGMGR-86 Project: JBoss Log Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: James Perkins Assignee: James Perkins Priority: Optional For now this is just a thought so that users can filter messages based on an exception in the stack trace. Currently it's not possible to use a regex filter as the stack trace is not used in when testing for matches and it probably shouldn't be 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1702) Investigate module wiring consistency at build time

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-1702?page=com.atlassian.jira.plugin.... ] Thomas Diesler reassigned WFLY-1702: ------------------------------------ Assignee: (was: Thomas Diesler) > Investigate module wiring consistency at build time > --------------------------------------------------- > > Key: WFLY-1702 > URL: https://issues.jboss.org/browse/WFLY-1702 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Build System > Reporter: Thomas Diesler > Fix For: 8.0.0.CR1 > > > Due to the use of human wiring decisions it is possible that the initial modules wiring setup is incomplete/inconsistent. Various inconsistencies can occur > * There are code paths in a module that require a class load for which there is no dependency defined > * Modules define (stale) dependencies that are never used > * Modules define dependencies that are inconsistent in the class space -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-319) "Unknown boolean operator" RuntimeException

by David Tombs (JIRA)

David Tombs created DROOLS-319: ---------------------------------- Summary: "Unknown boolean operator" RuntimeException Key: DROOLS-319 URL: https://issues.jboss.org/browse/DROOLS-319 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.5.0.Final Environment: Windows 8, java version "1.7.0_40" Reporter: David Tombs Assignee: Mark Proctor Steps to reproduce: # Create a decision table with something like {{fooString != ""}} in the constraint and {{true}} in the rule cell. # Execute the rule against a few objects. Actual Result: An internal Drools thread will crash with {{java.lang.RuntimeException: Unknown boolean operator}} when trying to compile {{fooString != "" == true}}. Expected Result: Even if an Exception is thrown, the currently-thrown exception is too low level and took me lots of investigation and debugging inside the drools code to figure out what I did wrong. -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1774) Determine if Jandex can be used to optimize CDI + Bean Validation integration for method validation

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFLY-1774?page=com.atlassian.jira.plugin.... ] Farah Juma commented on WFLY-1774: ---------------------------------- As discussed with Hardy, the two tasks described in this JIRA are low priority. For now, I’ve done an initial investigation around some questions that have been raised and I’m adding my findings below for future reference if/when these tasks are revisited. \\ \\ *How could we get the Jandex index for a deployment?* The Jandex index is available as a deployment unit attachment (e.g., {{deploymentUnit.getAttachment(Attachments.COMPOSITE_ANNOTATION_INDEX)}}). \\ \\ *How could we pass the Jandex index to the Hibernate Validator CDI portable extension?* Currently, CDI portable extensions get loaded by [WeldPortableExtensions#tryRegisterExtension|https://github.com/wildfly/wi...]. Note that this instantiates extensions using the default no-arg constructor. One option would be to add a new constructor to the Hibernate Validator CDI portable extension that takes a {{org.jboss.as.server.deployment.annotation.CompositeIndex}} as an argument and then modify {{WeldPortableExtensions#tryRegisterExtension}} to pass the Jandex index from the deployment unit attachment when registering this particular extension. This option would allow us to make use of the existing portable extension instead of creating a new one specifically for WildFly. This way, the portable extension can still be used outside of WildFly without Jandex via the existing no-arg constructor. \\ \\ *How could we find subtypes of a given class using Jandex?* All known subclasses (even non-direct ones) of a class can be found via {{CompositeIndex#getAllKnownSubclasses}}. All known classes that implement an interface (directly or indirectly) can be found via {{CompositeIndex#getAllKnownImplementors}}. Note that both of these methods return a set of {{org.jboss.jandex.ClassInfo}} objects. When the portable extension’s {{processAnnotatedType}} method is fired for a particular class, the high level idea here would be to get all known subclasses / all known classes that implement it and register the appropriate method validation interceptor bindings for these classes as well. This would allow us to avoid having to specify @ValidateOnExecution(IMPLICIT). \\ \\ *To speed up constraint metadata retrieval, we need to be able to make use of the Jandex index to find classes that contain annotations that are themselves annotated with {{@Constraint}}. How could we do this?* Note that if an annotation class is not part of the deployment, it won’t be part of the Jandex index for that deployment. This means that it’s _not_ possible to just do the following: # Use the Jandex index to find all classes (annotation classes) annotated with {{@Constraint}} # Use the Jandex index to find all classes annotated with the results from (1) Instead, given a particular class, one option would be to do something similar to what Weld currently does with {{@WithAnnotations}}. In particular, to determine if a class contains an annotation specified via {{@WithAnnotations}}, Weld first looks for the class in the Jandex index. If the class is not found, Weld falls back to using reflection. Otherwise, Weld gets the annotations for the class from the Jandex index and tries to find the specified annotation. If the specified annotation isn't found directly, Weld then iterates over all of the annotations from the class to check if any of the annotation classes themselves are annotated with the specified annotation. Again, if the annotation class isn't in the Jandex index, Weld falls back to using reflection (see [WeldAnnotationDiscovery#containsAnnotation|https://github.com/wildfly/wil...]). We could do something similar to this, i.e., try to use the Jandex index when possible and fall back to using reflection when necessary. Since it’s not possible to eliminate the use of reflection completely, we should also determine to what extent this solution will actually speed up constraint metadata retrieval. > Determine if Jandex can be used to optimize CDI + Bean Validation integration for method validation > --------------------------------------------------------------------------------------------------- > > Key: WFLY-1774 > URL: https://issues.jboss.org/browse/WFLY-1774 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Alpha3 > Reporter: Farah Juma > Assignee: Farah Juma > > For CDI + Bean Validation integration for method validation, we're making use of the Hibernate Validator CDI portable extension. We can try to optimize this portable extension by making use of the Jandex index. In particular, we can: > 1) Determine if Jandex can be used for subtype retrieval to avoid having to specify @ValidateOnExecution(IMPLICIT) > 2) Determine if Jandex can be used to speed up constraint metadata retrieval -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-30) @Resource injection of Datasource on clustered SFSB fails with serialization error

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-30?page=com.atlassian.jira.plugin.sy... ] Paul Ferraro commented on WFLY-30: ---------------------------------- FYI, this PR contains a test that reproduces this bug: https://github.com/wildfly/wildfly/pull/5357 See https://github.com/wildfly/wildfly/pull/5357/files#diff-e4c854693bb21914f... > @Resource injection of Datasource on clustered SFSB fails with serialization error > ---------------------------------------------------------------------------------- > > Key: WFLY-30 > URL: https://issues.jboss.org/browse/WFLY-30 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA > Reporter: Paul Ferraro > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 8.0.0.CR1 > > > See JBPAPP6-1762 for details. -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-30) @Resource injection of Datasource on clustered SFSB fails with serialization error

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-30?page=com.atlassian.jira.plugin.sy... ] Paul Ferraro updated WFLY-30: ----------------------------- Assignee: Jesper Pedersen (was: Paul Ferraro) > @Resource injection of Datasource on clustered SFSB fails with serialization error > ---------------------------------------------------------------------------------- > > Key: WFLY-30 > URL: https://issues.jboss.org/browse/WFLY-30 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA > Reporter: Paul Ferraro > Assignee: Jesper Pedersen > Fix For: 8.0.0.CR1 > > > See JBPAPP6-1762 for details. -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-30) @Resource injection of Datasource on clustered SFSB fails with serialization error

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-30?page=com.atlassian.jira.plugin.sy... ] Paul Ferraro commented on WFLY-30: ---------------------------------- Reassigning to JCA. This isn't actually clustering-specific, but rather a serialization issue. I'm also raising the priority of this, since this effects EE spec compliance, specifically section 4.2.1 of the EJB specification. > @Resource injection of Datasource on clustered SFSB fails with serialization error > ---------------------------------------------------------------------------------- > > Key: WFLY-30 > URL: https://issues.jboss.org/browse/WFLY-30 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA > Reporter: Paul Ferraro > Assignee: Jesper Pedersen > Fix For: 8.0.0.CR1 > > > See JBPAPP6-1762 for details. -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-30) @Resource injection of Datasource on clustered SFSB fails with serialization error

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-30?page=com.atlassian.jira.plugin.sy... ] Paul Ferraro updated WFLY-30: ----------------------------- Priority: Critical (was: Major) > @Resource injection of Datasource on clustered SFSB fails with serialization error > ---------------------------------------------------------------------------------- > > Key: WFLY-30 > URL: https://issues.jboss.org/browse/WFLY-30 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA > Reporter: Paul Ferraro > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 8.0.0.CR1 > > > See JBPAPP6-1762 for details. -- 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

12 years, 8 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 November 2013