October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3337) Logging resources shouldn't be allowed to removed if they are in-use

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3337?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-3337: --------------------------------------- Excellent. It sounds like capabilities are the way to go then. > Logging resources shouldn't be allowed to removed if they are in-use > -------------------------------------------------------------------- > > Key: WFCORE-3337 > URL: https://issues.jboss.org/browse/WFCORE-3337 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > Currently you can remove a logging resource even if it's used by another resource. An example of this would be the ability to remove a formatter even though that formatter is attached to a handler. Removing handlers does validate it's not attached to a logger first. However all logging resources should do this. > Note that logging does not use services which is why this needs to be manually checked. This should be doable via the configuration API. Note too that a fix to validate this will also be done in the logmanager, LOGMGR-179. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8417) Create DistributedWorkManager implementation based on WF clustering API

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-8417?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-8417: ------------------------------- Description: The upgrade to JGroups 4.0 will break the JGroups DistributedWorkManager implementation in IronJacamar (which uses JGroups 3.x). JGroups is only used to broadcast/receive commands to the cluster. This can be easily implemented using the WildFly clustering API. Such an implementation will simplify the transition to JGroups 4.0 and future-proof WildFly from any new API breakage. Additionally, the JGroupsTransport in ironjacamar has some issues: * Performs blocking operations on view change * Does a lot of unnecessary serialization of Address * Doesn't leverage multicasts was:The upgrade to JGroups 4.0 will break the JGroups DistributedWorkManager implementation in IronJacamar (which uses JGroups 3.x). JGroups is only used to broadcast/receive commands to the cluster. This can be easily implemented using the WildFly clustering API. Such an implementation will simplify the transition to JGroups 4.0 and future-proof WildFly from any new API breakage. > Create DistributedWorkManager implementation based on WF clustering API > ----------------------------------------------------------------------- > > Key: WFLY-8417 > URL: https://issues.jboss.org/browse/WFLY-8417 > Project: WildFly > Issue Type: Task > Components: Clustering, JCA > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 12.0.0.Alpha1 > > > The upgrade to JGroups 4.0 will break the JGroups DistributedWorkManager implementation in IronJacamar (which uses JGroups 3.x). JGroups is only used to broadcast/receive commands to the cluster. This can be easily implemented using the WildFly clustering API. Such an implementation will simplify the transition to JGroups 4.0 and future-proof WildFly from any new API breakage. > Additionally, the JGroupsTransport in ironjacamar has some issues: > * Performs blocking operations on view change > * Does a lot of unnecessary serialization of Address > * Doesn't leverage multicasts -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1670) FEEL expression 1 ++++++ 2 passes with result 3

by Fedor Gavrilov (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1670?page=com.atlassian.jira.plugi... ] Fedor Gavrilov reassigned DROOLS-1670: -------------------------------------- Assignee: Fedor Gavrilov (was: Edson Tirelli) > FEEL expression 1 ++++++ 2 passes with result 3 > ----------------------------------------------- > > Key: DROOLS-1670 > URL: https://issues.jboss.org/browse/DROOLS-1670 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.1.0.Final > Reporter: Tibor Zimányi > Assignee: Fedor Gavrilov > Priority: Minor > Labels: reported-by-qe > > When evaluating FEEL expression "1 ++++++ 2", the result is 3. This is grammatically correct, but it doesn't look good. I will provide PR with a reproducer. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3316) Server fails to start after submitting invalid security attributes

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3316?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3316: ------------------------------------- Steps to Reproduce: 1. Create new http connector in remoting subsystem: {code:bash} /subsystem=remoting/http-connector=random:add(connector-ref=default) {code} 2. Enable SASL security in newly created http connector: {code:bash} /subsystem=remoting/http-connector=random/security=sasl:add() {code} 3. Write invalid value to the qop attribute: {code:bash} /subsystem=remoting/http-connector=random/security=sasl:write-attribute(name=qop,value=[aaa]) {code} 4. Reload server {code:bash} reload {code} was: 1. Create new http connector in remoting subsystem: {code:bash} /subsystem=remoting/http-connector=random:add(connector-ref=default) {code} 2. Enable SASL security in newly created http connector: {code:bash} /subsystem=remoting/http-connector=random/security=sasl:add() {code} 3. Write invalid value to the qop attribute: {code:bash} /subsystem=remoting/http-connector=random/security=sasl:write-attribute(name=qop,value=[aaa]) {code} 4. Reload server {code:bash} :reload {code} > Server fails to start after submitting invalid security attributes > ------------------------------------------------------------------ > > Key: WFCORE-3316 > URL: https://issues.jboss.org/browse/WFCORE-3316 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Affects Versions: 3.0.3.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Critical > > Server fails to start after submitting invalid security attributes values for remoting http connector (e.g QOP, strength) > Only fix for the configuration is to manually change the XML file directly -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1755) Debugging of rules with MVEL dialect not working in multithreaded environment

by Peter Durica (JIRA)

Peter Durica created DROOLS-1755: ------------------------------------ Summary: Debugging of rules with MVEL dialect not working in multithreaded environment Key: DROOLS-1755 URL: https://issues.jboss.org/browse/DROOLS-1755 Project: Drools Issue Type: Bug Components: eclipse plugin Affects Versions: 7.3.0.Final Environment: Drools 7.3.0 (and 6.5.0) Drools Eclipse Plugin 7.3.0 (and 6.5.0) Eclipse: Eclipse Oxygen 4.7.0 Jboss Developer Studio 11.0.0.GA Reporter: Peter Durica Assignee: Robert (Bob) Brodt Attachments: drools-module.zip The debugger does not stop on the breakpoint within a rule consequence when the dialect MVEL is used and the rule execution is done in an extra thread. The debugging is done in Eclipse using drools plugin installed. The project is a drools project and is debugged as drools application. See the attached application (drools-module.zip) to reproduce. When the rule execution is done in the main thread, the debugger stops on the breakpoint (workaround) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9422) Wildfly HTTP client 1.0.7.Final

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-9422?page=com.atlassian.jira.plugin.... ] Stuart Douglas updated WFLY-9422: --------------------------------- Summary: Wildfly HTTP client 1.0.7.Final (was: Wildfly HTTP client 1.0.6.Final) > Wildfly HTTP client 1.0.7.Final > ------------------------------- > > Key: WFLY-9422 > URL: https://issues.jboss.org/browse/WFLY-9422 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9425) EJB no-interface view, non-public method behaviour

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/WFLY-9425?page=com.atlassian.jira.plugin.... ] Matej Novotny updated WFLY-9425: -------------------------------- Component/s: CDI / Weld > EJB no-interface view, non-public method behaviour > -------------------------------------------------- > > Key: WFLY-9425 > URL: https://issues.jboss.org/browse/WFLY-9425 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, EJB > Affects Versions: 10.1.0.Final, 11.0.0.CR1 > Reporter: Matej Novotny > Priority: Minor > > First of all, I am not sure whether this is bug or a feature. > This is based on a [SO question|https://stackoverflow.com/questions/46602452] - {{@Stateless}} no-interface view bean with non-public method. You inject this bean into other bean (using CDI) and try to invoke that non-public method. > According to EJB spec, this should throw {{EJBException}} (chapter _Session Bean’s No-Interface View_): > bq. Only public methods of the bean class and of any superclasses except java.lang.Object may be invoked through the no-interface view. Attempted invocations of methods with any other access modifiers via the no-interface view reference must result in the javax.ejb.EJBException. > I put together a [Weld test|https://github.com/manovotn/core/commit/e5fca57be714267154c71b442a99...] for this - feel free to browse the code. > When invoked in Weld, this *does not throw {{EJBException}}* but in fact fails on {{IllegalAccess}} when an attempt is made to access that method. > Note that in Weld code, we are explicitly handling these EJB invocations [using a method which does not override accessibility rules|https://github.com/weld/core/blob/2.3/impl/src/main/java/org/jboss/...] and I suppose it's there for a reason. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9425) EJB no-interface view, non-public method behaviour

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/WFLY-9425?page=com.atlassian.jira.plugin.... ] Matej Novotny commented on WFLY-9425: ------------------------------------- Actually, when I bypass this error on Weld side (modify accessibility of method), I then get the correct error message - so EJB subsystem seems to handle this correctly. {code} javax.ejb.EJBException: WFLYEJB0224: Not a business method java.lang.String org.jboss.weld.tests.ejb.stateless.noInterfaceNonPublic.ProblematicBean.ping(). Do not call non-public methods on EJB's at org.jboss.weld.tests.ejb.stateless.noInterfaceNonPublic.NoInterfaceNonPublicMethodTest.testExceptionThrown(NoInterfaceNonPublicMethodTest.java:53) {code} > EJB no-interface view, non-public method behaviour > -------------------------------------------------- > > Key: WFLY-9425 > URL: https://issues.jboss.org/browse/WFLY-9425 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.1.0.Final, 11.0.0.CR1 > Reporter: Matej Novotny > Priority: Minor > > First of all, I am not sure whether this is bug or a feature. > This is based on a [SO question|https://stackoverflow.com/questions/46602452] - {{@Stateless}} no-interface view bean with non-public method. You inject this bean into other bean (using CDI) and try to invoke that non-public method. > According to EJB spec, this should throw {{EJBException}} (chapter _Session Bean’s No-Interface View_): > bq. Only public methods of the bean class and of any superclasses except java.lang.Object may be invoked through the no-interface view. Attempted invocations of methods with any other access modifiers via the no-interface view reference must result in the javax.ejb.EJBException. > I put together a [Weld test|https://github.com/manovotn/core/commit/e5fca57be714267154c71b442a99...] for this - feel free to browse the code. > When invoked in Weld, this *does not throw {{EJBException}}* but in fact fails on {{IllegalAccess}} when an attempt is made to access that method. > Note that in Weld code, we are explicitly handling these EJB invocations [using a method which does not override accessibility rules|https://github.com/weld/core/blob/2.3/impl/src/main/java/org/jboss/...] and I suppose it's there for a reason. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9425) EJB no-interface view, non-public method behaviour

by Matej Novotny (JIRA)

Matej Novotny created WFLY-9425: ----------------------------------- Summary: EJB no-interface view, non-public method behaviour Key: WFLY-9425 URL: https://issues.jboss.org/browse/WFLY-9425 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 11.0.0.CR1, 10.1.0.Final Reporter: Matej Novotny Priority: Minor First of all, I am not sure whether this is bug or a feature. This is based on a [SO question|https://stackoverflow.com/questions/46602452] - {{@Stateless}} no-interface view bean with non-public method. You inject this bean into other bean (using CDI) and try to invoke that non-public method. According to EJB spec, this should throw {{EJBException}} (chapter _Session Bean’s No-Interface View_): bq. Only public methods of the bean class and of any superclasses except java.lang.Object may be invoked through the no-interface view. Attempted invocations of methods with any other access modifiers via the no-interface view reference must result in the javax.ejb.EJBException. I put together a [Weld test|https://github.com/manovotn/core/commit/e5fca57be714267154c71b442a99...] for this - feel free to browse the code. When invoked in Weld, this *does not throw {{EJBException}}* but in fact fails on {{IllegalAccess}} when an attempt is made to access that method. Note that in Weld code, we are explicitly handling these EJB invocations [using a method which does not override accessibility rules|https://github.com/weld/core/blob/2.3/impl/src/main/java/org/jboss/...] and I suppose it's there for a reason. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9424) Wildfly 10.1.0.Final - Very long deploy time on Windows 10

by Nándor Holozsnyák (JIRA)

Nándor Holozsnyák created WFLY-9424: --------------------------------------- Summary: Wildfly 10.1.0.Final - Very long deploy time on Windows 10 Key: WFLY-9424 URL: https://issues.jboss.org/browse/WFLY-9424 Project: WildFly Issue Type: Bug Affects Versions: 10.1.0.Final Reporter: Nándor Holozsnyák Assignee: Jason Greene Priority: Minor I am having a really annoying "problem" with Wildfly. I have been using it for at least two years now and I really don't know what could be the problem. So I have a fresh Windows 10 64 bit install, and then I started working on my projects as well which was started earlier and there were no problem with the deploy time. I just pulled my stuff from VCS and then when I started to deploy it with Wildfly (as well as with Maven's Wildfly plugin and as well as put the .war into the deployments folder) the server prints out "Starting deployment ..." and then hangs for two minutes!! Always two minutes then deploy the application. It happens with no one project, with at least three, on my other laptop which has Windows 7 everything works fine. I decided to download the wildfly quickstart repo and then try it out. With one EJB project it works well, deploy goes as a new Lambo. I tried to log the wildfly with trace to get some more information but nothing special came. Wildfly maven plugin was in debug too but no more information. Wildfly memory settings are upgraded to 1 GB, but no luck. I am going to write out a ticket, but it is a bit frustrating. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 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 October 2017