March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3118) <vault> does not have module option

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-3118?page=com.atlassian.jira.plugin.... ] Kabir Khan moved EAP6-192 to WFLY-3118: --------------------------------------- Project: WildFly (was: EAP 6 Planning Pilot) Key: WFLY-3118 (was: EAP6-192) Issue Type: Feature Request (was: Requirement) Workflow: GIT Pull Request workflow (was: CDW v1) Affects Version/s: (was: 6.3.0.GA) Component/s: Security (was: Security) Security: Public Target Release: (was: 6.3.0.GA) > <vault> does not have module option > ----------------------------------- > > Key: WFLY-3118 > URL: https://issues.jboss.org/browse/WFLY-3118 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Security > Reporter: Derek Horton > Assignee: Jimmy Wilson > > The <vault> element in standalone/domain.xml takes a 'code' attribute specifying the class to use as the implementation. It does not let you specify a 'module' option like most similar elements have, and instead always loads the class from the org.picketbox module. > The <vault> element should take a module option too. > The current workaround is to add the custom vault module as a dependency in the org.picketbox module. > Additionally, hanging any module.xml can also result in patching conflicts when customers apply future updates. > Since we have a quite a few customers writing custom vault implementations for various pieces of functionality that it doesn't provide out of the box, we should consider making this type of customer-initiated change patch safe for customers. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3118) <vault> does not have module option

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-3118?page=com.atlassian.jira.plugin.... ] Kabir Khan reassigned WFLY-3118: -------------------------------- Assignee: Kabir Khan (was: Jimmy Wilson) > <vault> does not have module option > ----------------------------------- > > Key: WFLY-3118 > URL: https://issues.jboss.org/browse/WFLY-3118 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Security > Reporter: Derek Horton > Assignee: Kabir Khan > > The <vault> element in standalone/domain.xml takes a 'code' attribute specifying the class to use as the implementation. It does not let you specify a 'module' option like most similar elements have, and instead always loads the class from the org.picketbox module. > The <vault> element should take a module option too. > The current workaround is to add the custom vault module as a dependency in the org.picketbox module. > Additionally, hanging any module.xml can also result in patching conflicts when customers apply future updates. > Since we have a quite a few customers writing custom vault implementations for various pieces of functionality that it doesn't provide out of the box, we should consider making this type of customer-initiated change patch safe for customers. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1765) TP: enable loopback by default and discard own multicasts

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1765?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1765. ---------------------------- Resolution: Done By default, messages looped back up are not copied (governed by {{loopback_copy}}). Also, looped back messages are delivered in a separate thread (configurable via {{loopback_separate_thread}}). > TP: enable loopback by default and discard own multicasts > --------------------------------------------------------- > > Key: JGRP-1765 > URL: https://issues.jboss.org/browse/JGRP-1765 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > Enable {{TP.looback}} by default (deprecate and ignore prop): all messages sent by self are passed right to a thread pool to send them up again. > When a multicast message sent by self is received, it is currently passed to a thread pool, de-serialized and only then discarded if loopback=true. This means that we create an unneeded buffer for de-serializationand perform de-serialization. > SOLUTION: discard the multicast from self immediately when receiving it, in {{TP.receive()}} -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1155) IronJacamar under security manager throws exception

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-1155: -------------------------------------- Summary: IronJacamar under security manager throws exception Key: JBJCA-1155 URL: https://issues.jboss.org/browse/JBJCA-1155 Project: IronJacamar Issue Type: Bug Affects Versions: 1.1.4.Final, 1.0.24.Final Reporter: Jesper Pedersen Assignee: Jesper Pedersen Priority: Blocker Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.CR1 -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-295) maxTime attribute statistic initial display value.

by Jeremy Whiting (JIRA)

Jeremy Whiting created JBWEB-295: ------------------------------------ Summary: maxTime attribute statistic initial display value. Key: JBWEB-295 URL: https://issues.jboss.org/browse/JBWEB-295 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Affects Versions: JBossWeb-7.3.0.GA Environment: Linux. 3.13.5-103.fc19.x86_64 Reporter: Jeremy Whiting Assignee: Remy Maucherat The initial maxTime attribute value when queried on a servlet using the CLI displays a very large value 9223372036854775807L. The expected value is 0 for a system that has just been started and no requests have been processed for the servlet. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-295) maxTime attribute statistic initial display value.

by Jeremy Whiting (JIRA)

[ https://issues.jboss.org/browse/JBWEB-295?page=com.atlassian.jira.plugin.... ] Jeremy Whiting updated JBWEB-295: --------------------------------- Environment: Linux. 3.13.5-103.fc19.x86_64 openjdk 1.7 was: Linux. 3.13.5-103.fc19.x86_64 > maxTime attribute statistic initial display value. > -------------------------------------------------- > > Key: JBWEB-295 > URL: https://issues.jboss.org/browse/JBWEB-295 > Project: JBoss Web > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: JBossWeb-7.3.0.GA > Environment: Linux. > 3.13.5-103.fc19.x86_64 > openjdk 1.7 > Reporter: Jeremy Whiting > Assignee: Remy Maucherat > Labels: attribute, maxTime, statistics > > The initial maxTime attribute value when queried on a servlet using the CLI displays a very large value 9223372036854775807L. The expected value is 0 for a system that has just been started and no requests have been processed for the servlet. > -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-457) TaskModelProvider's ServiceLoader sync problem

by Mariano De Maio (JIRA)

[ https://issues.jboss.org/browse/DROOLS-457?page=com.atlassian.jira.plugin... ] Mariano De Maio updated DROOLS-457: ----------------------------------- Attachment: test-case.zip Test case project attachment > TaskModelProvider's ServiceLoader sync problem > ---------------------------------------------- > > Key: DROOLS-457 > URL: https://issues.jboss.org/browse/DROOLS-457 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1, 6.1.0.Beta2, 6.1.0.Final > Reporter: Mariano De Maio > Assignee: Mark Proctor > Attachments: test-case.zip > > > This bug was found related to jBPM6 components, but its solution needs to be implemented in the kie-internal project, hence we report it in this project. > When the TaskModelProvider access the factory object, it iterates the service loader directly. Unfortunately, the ServiceLoader class states: > "Instances of this class are not safe for use by multiple concurrent threads." (http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html) > This causes that environments that need to use the TaskModelProvider from different threads with no prior invocation. > I'll add a maven test to reproduce the issue. We have also a solution we'll submit in a pull request -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-457) TaskModelProvider's ServiceLoader sync problem

by Mariano De Maio (JIRA)

Mariano De Maio created DROOLS-457: -------------------------------------- Summary: TaskModelProvider's ServiceLoader sync problem Key: DROOLS-457 URL: https://issues.jboss.org/browse/DROOLS-457 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.1.0.Beta1, 6.0.1.Final, 6.0.0.Final, 6.1.0.Beta2, 6.1.0.Final Reporter: Mariano De Maio Assignee: Mark Proctor This bug was found related to jBPM6 components, but its solution needs to be implemented in the kie-internal project, hence we report it in this project. When the TaskModelProvider access the factory object, it iterates the service loader directly. Unfortunately, the ServiceLoader class states: "Instances of this class are not safe for use by multiple concurrent threads." (http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html) This causes that environments that need to use the TaskModelProvider from different threads with no prior invocation. I'll add a maven test to reproduce the issue. We have also a solution we'll submit in a pull request -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2644) Java heap space exceeded looping connect/disconnect cycle

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2644?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2644: ----------------------------------------------- Petr Sakař <psakar(a)redhat.com> changed the Status of [bug 1037574|https://bugzilla.redhat.com/show_bug.cgi?id=1037574] from ON_QA to ASSIGNED > Java heap space exceeded looping connect/disconnect cycle > --------------------------------------------------------- > > Key: WFLY-2644 > URL: https://issues.jboss.org/browse/WFLY-2644 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CLI > Affects Versions: 8.0.0.Beta1 > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Fix For: 8.0.0.Final > > > CLIModelControllerClient implementation is not cleaning up something related to connection handling which leads to OOME repeating a cycle of ensureConnected(...) and close(). On my laptop it happens after around 1400 iterations. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-456) ResourceConfigurationImpl class not found when using drools-karaf-feature

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/DROOLS-456?page=com.atlassian.jira.plugin... ] Gary Brown updated DROOLS-456: ------------------------------ Attachment: fuse-drools-issue.log > ResourceConfigurationImpl class not found when using drools-karaf-feature > ------------------------------------------------------------------------- > > Key: DROOLS-456 > URL: https://issues.jboss.org/browse/DROOLS-456 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.Beta1 > Reporter: Gary Brown > Assignee: Mark Proctor > Attachments: fuse-drools-issue.log > > > While porting RTGov to Karaf, I have been using Drools 2.0.0.CR5 successfully. > However when I updated the version to 2.0.1.Final, and subsequently to 2.1.0.Beta1, I now get a class not found issue: > {noformat} > 11:26:49,440 | ERROR | l Console Thread | ResourceTypeImpl | 290 - org.kie.internalapi - 6.1.0.20140307-1723 | Error loading resource configuration from properties > java.lang.ClassNotFoundException: org.drools.core.builder.conf.impl.ResourceConfigurationImpl not found by org.kie.internalapi [290] > at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1532)[org.apache.felix.framework-4.0.3.redhat-610355.jar:] > at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)[org.apache.felix.framework-4.0.3.redhat-610355.jar:] > at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955) > at java.lang.ClassLoader.loadClass(ClassLoader.java:356)[:1.7.0_07] > at java.lang.Class.forName0(Native Method)[:1.7.0_07] > at java.lang.Class.forName(Class.java:186)[:1.7.0_07] > at org.kie.internal.io.ResourceTypeImpl.fromProperties(ResourceTypeImpl.java:41)[290:org.kie.internalapi:6.1.0.20140307-1723] > {noformat} -- 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

10 years, 10 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 March 2014