December 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9624) Improper handling of application exceptions on asynchronous ejb invocations

by Andrej Kolontai (JIRA)

Andrej Kolontai created WFLY-9624: ------------------------------------- Summary: Improper handling of application exceptions on asynchronous ejb invocations Key: WFLY-9624 URL: https://issues.jboss.org/browse/WFLY-9624 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 11.0.0.Final Reporter: Andrej Kolontai If an asynchronous invocation of an ejb method throws an application exception (declared exception) then the returned future will always return false on isDone(). That means: the client will never know that the operation has finished (unscuccessfully) unless get() is called which would rethrow the original exception. This behavior has changed from wildfly 10.1.0.Final to 11.0.0.Final. I pretty sure that the problem is in org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask. The isDone Method is implemented like this: {{ @Override public boolean isDone() { return status == ST_DONE; } }} But status can be one of: {{ private static final int ST_RUNNING = 0; private static final int ST_DONE = 1; private static final int ST_CANCELLED = 2; private static final int ST_FAILED = 3; }} And and exception sets the status to {{ private synchronized void setFailed(final Exception e) { this.failed = e; status = ST_FAILED; done(); } }} So it's pretty obvious. The javadoc on java.util.concurrent.Future states: {quote} Completion may be due to normal termination, an exception, or cancellation -- in all of these cases, this method will return true. {quote} So the isDone() method should look more like this: {{ @Override public boolean isDone() { return status == ST_DONE || status == ST_FAILED || status == ST_CANCELLED; } }} In wildfly 10, there was a single boolean variable "done" which was set to true in all three cases: * cancel() * setResult(...) and * setFailed(...) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-3468) Get rid of multiple deployment-scanner AbstractWriteAttributeHandler subclasses; use a single class

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3468: ---------------------------------------- Summary: Get rid of multiple deployment-scanner AbstractWriteAttributeHandler subclasses; use a single class Key: WFCORE-3468 URL: https://issues.jboss.org/browse/WFCORE-3468 Project: WildFly Core Issue Type: Enhancement Components: Deployment Scanner Reporter: Brian Stansberry Assignee: Brian Stansberry The deployment-scanner has a bunch of write-attribute handlers that are basically just 1 or 2 line implementations of a method in a superclass. Just put it all in the superclass. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-3467) Require existence of the AttributeDefinition in AbstractWriteAttributeHandler

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3467: ---------------------------------------- Summary: Require existence of the AttributeDefinition in AbstractWriteAttributeHandler Key: WFCORE-3467 URL: https://issues.jboss.org/browse/WFCORE-3467 Project: WildFly Core Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry AbstractWriteAttributeHandler has logic to deal with the case where it has no reference to an AttributeDefinition for the relevant attribute. This is compatibility code from the days before AttributeDefinition. But using AD has been the standard for many years now, so lets drop this and fail if there is no AD. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-2193) MVEL Dialect cannot find the FH when using modify on a DataSource

by Lance Leverich (JIRA)

Lance Leverich created DROOLS-2193: -------------------------------------- Summary: MVEL Dialect cannot find the FH when using modify on a DataSource Key: DROOLS-2193 URL: https://issues.jboss.org/browse/DROOLS-2193 Project: Drools Issue Type: Bug Components: core engine Reporter: Lance Leverich Assignee: Mario Fusco Attempting to use _modify_ on a fact that is retrieved from a DataSource will sometimes cause an error that reads: {{Update error: handle not found for object: ...}} Using dialect "java" fixes the issue. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-3466) Add reflection option to org.jboss.as.controller.parsing.ExtensionParsingContext

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3466?page=com.atlassian.jira.plugi... ] Brian Stansberry edited comment on WFCORE-3466 at 12/19/17 6:28 PM: -------------------------------------------------------------------- Besides eliminating the cost of the Suppliers, we really want to get rid of the loading of the parser impl Class, and only load it if we actually encounter the namespace that demands it. Exception being the current parser, which we often want to load during Extension.initializeParsers, since in most subsystems that means the subsystem static initialization stuff (AttributeDefinition etc) gets run during the concurrent part of boot. was (Author: brian.stansberry): Besides eliminating the cost of the Suppliers, we really want to get rid of the loading of the parser impl Class, and only load it if we actually encounter the namespace that demands it. > Add reflection option to org.jboss.as.controller.parsing.ExtensionParsingContext > -------------------------------------------------------------------------------- > > Key: WFCORE-3466 > URL: https://issues.jboss.org/browse/WFCORE-3466 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: David Lloyd > > As a way to combat aggressive class initialization, WFCORE-1841 added a variant method to {{ExtensionParsingContext}} which allowed a supplier of a parser to be provided. > This has resulted in an explosion of lambda usage; around 150 calls to this method exist, most of which supply constructor references as the {{Supplier}} argument. > We can theoretically save considerable metaspace by doing one of the following: > * Add a variation of the method which accepts a {{Class}} instead of a {{Supplier}}; it uses {{Class.newInstance()}} or {{Class.getConstructor().newInstance()}} to instantiate the parser on demand > * Create a reflective {{Supplier}} implementation which, given a {{Class}}, uses it in this way to construct instances > Performance impact should be very minimal, as the overhead of calling a constructor is less than that of compiling a method reference, and the overhead in metaspace is nearly non-existent in comparison. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-3466) Add reflection option to org.jboss.as.controller.parsing.ExtensionParsingContext

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3466?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-3466: ------------------------------------------ Besides eliminating the cost of the Suppliers, we really want to get rid of the loading of the parser impl Class, and only load it if we actually encounter the namespace that demands it. > Add reflection option to org.jboss.as.controller.parsing.ExtensionParsingContext > -------------------------------------------------------------------------------- > > Key: WFCORE-3466 > URL: https://issues.jboss.org/browse/WFCORE-3466 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: David Lloyd > > As a way to combat aggressive class initialization, WFCORE-1841 added a variant method to {{ExtensionParsingContext}} which allowed a supplier of a parser to be provided. > This has resulted in an explosion of lambda usage; around 150 calls to this method exist, most of which supply constructor references as the {{Supplier}} argument. > We can theoretically save considerable metaspace by doing one of the following: > * Add a variation of the method which accepts a {{Class}} instead of a {{Supplier}}; it uses {{Class.newInstance()}} or {{Class.getConstructor().newInstance()}} to instantiate the parser on demand > * Create a reflective {{Supplier}} implementation which, given a {{Class}}, uses it in this way to construct instances > Performance impact should be very minimal, as the overhead of calling a constructor is less than that of compiling a method reference, and the overhead in metaspace is nearly non-existent in comparison. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-3466) Add reflection option to org.jboss.as.controller.parsing.ExtensionParsingContext

by David Lloyd (JIRA)

David Lloyd created WFCORE-3466: ----------------------------------- Summary: Add reflection option to org.jboss.as.controller.parsing.ExtensionParsingContext Key: WFCORE-3466 URL: https://issues.jboss.org/browse/WFCORE-3466 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: David Lloyd As a way to combat aggressive class initialization, WFCORE-1841 added a variant method to {{ExtensionParsingContext}} which allowed a supplier of a parser to be provided. This has resulted in an explosion of lambda usage; around 150 calls to this method exist, most of which supply constructor references as the {{Supplier}} argument. We can theoretically save considerable metaspace by doing one of the following: * Add a variation of the method which accepts a {{Class}} instead of a {{Supplier}}; it uses {{Class.newInstance()}} or {{Class.getConstructor().newInstance()}} to instantiate the parser on demand * Create a reflective {{Supplier}} implementation which, given a {{Class}}, uses it in this way to construct instances Performance impact should be very minimal, as the overhead of calling a constructor is less than that of compiling a method reference, and the overhead in metaspace is nearly non-existent in comparison. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-9539) wsconsume.sh does not support the -secmgr setting properly

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9539?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-9539: -------------------------------------- Fix Version/s: 12.0.0.Alpha1 Assignee: R Searls (was: Tomaz Cerar) Resolution: Done > wsconsume.sh does not support the -secmgr setting properly > ---------------------------------------------------------- > > Key: WFLY-9539 > URL: https://issues.jboss.org/browse/WFLY-9539 > Project: WildFly > Issue Type: Bug > Components: Scripts, Web Services > Affects Versions: 10.0.0.Final > Reporter: R Searls > Assignee: R Searls > Fix For: 12.0.0.Alpha1 > > > wsconsume.sh, and wsconsume.bat does not properly support the -secmgr flag in the > generated command. Changes to jboss-module.jar requires the -secmgr flag be positioned > immediately after the jboss-module.jar declaration. > {code:java} > eval \"$JAVA\" $JAVA_OPTS \ > -classpath \""$JBOSS_CLASSPATH"\" \ > org.jboss.modules.Main \ > -secmgr \ > -mp \""$JBOSS_HOME"/modules\" \ > org.jboss.ws.tools.wsconsume \ > '"$@"' > {code} > This value is pass to this utility via the JAVA_OPTS env variable. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-9538) wsprovide.sh does not support the -secmgr setting properly

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9538?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-9538: -------------------------------------- Assignee: R Searls (was: Tomaz Cerar) > wsprovide.sh does not support the -secmgr setting properly > ---------------------------------------------------------- > > Key: WFLY-9538 > URL: https://issues.jboss.org/browse/WFLY-9538 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 10.0.0.Final > Reporter: R Searls > Assignee: R Searls > > wsprovide.sh, wsprovide.bat does not generate the cmd with the -secmgr flag in the > proper position. Changes to jboss-module.jar requires -segmgr to reside just after > the jboss-module.jar reference like this. > {code:java} > eval \"$JAVA\" $JAVA_OPTS \ > -jar \""$JBOSS_HOME"/jboss-modules.jar\" \ > *-secmgr \ * > -mp \""$JBOSS_HOME"/modules\" \ > org.jboss.ws.tools.wsprovide \ > '"$@"' > {code} > Current the old style and this new style value is passed in via the JAVA_OPTS env var. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-7247) Wildfly 10 JSESSIONIDSSOs not being created

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7247?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-7247. ---------------------------------- Resolution: Duplicate Issue Fixed under WFLY-8774 > Wildfly 10 JSESSIONIDSSOs not being created > ------------------------------------------- > > Key: WFLY-7247 > URL: https://issues.jboss.org/browse/WFLY-7247 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final, 10.1.0.Final > Reporter: M Wardell > Assignee: Stuart Douglas > > Found on wildfly 10.1 and 10.0. With SSO enabled, the server can startup in a state where not all the deployments get the SSO auth mechanism. Possibly caused by a missing dependency between the UndertowDeploymentInfoService and SingleSignOnService, which could be allowing the deployments to start before the SSO auth mechanism is registered in the host service. > Issue in intermittent on startup. After most startups the JESSSIONIDSSO is reliably generated during login. After some startups the JSESSIONIDSSO is never created after login. > Details in the referenced forum thread. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

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 December 2017