[JBoss JIRA] (DROOLS-1703) When incompatible varargs constructors exist, resolution sometimes incorrect
by Gerard Krupa (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1703?page=com.atlassian.jira.plugi... ]
Gerard Krupa updated DROOLS-1703:
---------------------------------
Steps to Reproduce:
Clone the repo https://github.com/GJKrupa/DROOLS-1703.git
Run mvn clean test
was:Create a class with the stated constructor types and attempt to call the first constructor from a rule. Rebuild multiple times (the error is intermittent depending on the order in which the constructors are evaluated).
> When incompatible varargs constructors exist, resolution sometimes incorrect
> ----------------------------------------------------------------------------
>
> Key: DROOLS-1703
> URL: https://issues.jboss.org/browse/DROOLS-1703
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final
> Environment: CentOS 7 (x86_64)
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (build 1.8.0_131-b12)
> OpenJDK 64-Bit Server VM (build 25.131-b12, mixed mode)
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T19:39:06Z)
> Reporter: Gerard Krupa
> Assignee: Mario Fusco
>
> We have a class with 3 constructors:
> Thingy(String name)
> Thingy(String name, Object... args)
> Thingy(String name, String version, Object... args)
> When calling the constructor with a single paramater from a DRL:
> Thingy(drools.getRule().getName())
> we sometimes get an odd exception in our unit tests:
> {{[INFO] java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> [INFO] at java.lang.String.substring(String.java:1927)
> [INFO] at org.mvel2.util.ErrorUtil.rewriteIfNeeded(ErrorUtil.java:17)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:975)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:396)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:163)}}
> The root cause of the issue appears to be the selection of varargs constructors by ParseTools.getBestConstructorCandidate and getMethodScore. The scoring checks that the arguments from left to right match the expected parameter classes and scores based on their coerce-ability. The scoring then compares the number of parameters to arguments *only* if the accumulated score is still 0 (and at this point it's not zero because the first parameter matched the expected type).
> All 3 constructors in this list score and match the same and if the incompatible constructor is examined first then it's used. This in turn causes VarArgs.normalizeArgsForVarArgs to attempt to create an array of size -1 as it calculates the needed size of the varargs array. The reported exception seems to be generated as the exception handler itself crashes, being unable to deal with the root cause error.
> https://github.com/GJKrupa/DROOLS-1703
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (DROOLS-1703) When incompatible varargs constructors exist, resolution sometimes incorrect
by Gerard Krupa (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1703?page=com.atlassian.jira.plugi... ]
Gerard Krupa updated DROOLS-1703:
---------------------------------
Description:
We have a class with 3 constructors:
Thingy(String name)
Thingy(String name, Object... args)
Thingy(String name, String version, Object... args)
When calling the constructor with a single paramater from a DRL:
Thingy(drools.getRule().getName())
we sometimes get an odd exception in our unit tests:
{{[INFO] java.lang.StringIndexOutOfBoundsException: String index out of range: -1
[INFO] at java.lang.String.substring(String.java:1927)
[INFO] at org.mvel2.util.ErrorUtil.rewriteIfNeeded(ErrorUtil.java:17)
[INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:975)
[INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:396)
[INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:163)}}
The root cause of the issue appears to be the selection of varargs constructors by ParseTools.getBestConstructorCandidate and getMethodScore. The scoring checks that the arguments from left to right match the expected parameter classes and scores based on their coerce-ability. The scoring then compares the number of parameters to arguments *only* if the accumulated score is still 0 (and at this point it's not zero because the first parameter matched the expected type).
All 3 constructors in this list score and match the same and if the incompatible constructor is examined first then it's used. This in turn causes VarArgs.normalizeArgsForVarArgs to attempt to create an array of size -1 as it calculates the needed size of the varargs array. The reported exception seems to be generated as the exception handler itself crashes, being unable to deal with the root cause error.
https://github.com/GJKrupa/DROOLS-1703
was:
We have a class with 3 constructors:
Thingy(String name)
Thingy(String name, Object... args)
Thingy(String name, String version, Object... args)
When calling the constructor with a single paramater from a DRL:
Thingy(drools.getRule().getName())
we sometimes get an odd exception in our unit tests:
{{[INFO] java.lang.StringIndexOutOfBoundsException: String index out of range: -1
[INFO] at java.lang.String.substring(String.java:1927)
[INFO] at org.mvel2.util.ErrorUtil.rewriteIfNeeded(ErrorUtil.java:17)
[INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:975)
[INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:396)
[INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:163)}}
The root cause of the issue appears to be the selection of varargs constructors by ParseTools.getBestConstructorCandidate and getMethodScore. The scoring checks that the arguments from left to right match the expected parameter classes and scores based on their coerce-ability. The scoring then compares the number of parameters to arguments *only* if the accumulated score is still 0 (and at this point it's not zero because the first parameter matched the expected type).
All 3 constructors in this list score and match the same and if the incompatible constructor is examined first then it's used. This in turn causes VarArgs.normalizeArgsForVarArgs to attempt to create an array of size -1 as it calculates the needed size of the varargs array. The reported exception seems to be generated as the exception handler itself crashes, being unable to deal with the root cause error.
> When incompatible varargs constructors exist, resolution sometimes incorrect
> ----------------------------------------------------------------------------
>
> Key: DROOLS-1703
> URL: https://issues.jboss.org/browse/DROOLS-1703
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final
> Environment: CentOS 7 (x86_64)
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (build 1.8.0_131-b12)
> OpenJDK 64-Bit Server VM (build 25.131-b12, mixed mode)
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T19:39:06Z)
> Reporter: Gerard Krupa
> Assignee: Mario Fusco
>
> We have a class with 3 constructors:
> Thingy(String name)
> Thingy(String name, Object... args)
> Thingy(String name, String version, Object... args)
> When calling the constructor with a single paramater from a DRL:
> Thingy(drools.getRule().getName())
> we sometimes get an odd exception in our unit tests:
> {{[INFO] java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> [INFO] at java.lang.String.substring(String.java:1927)
> [INFO] at org.mvel2.util.ErrorUtil.rewriteIfNeeded(ErrorUtil.java:17)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:975)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:396)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:163)}}
> The root cause of the issue appears to be the selection of varargs constructors by ParseTools.getBestConstructorCandidate and getMethodScore. The scoring checks that the arguments from left to right match the expected parameter classes and scores based on their coerce-ability. The scoring then compares the number of parameters to arguments *only* if the accumulated score is still 0 (and at this point it's not zero because the first parameter matched the expected type).
> All 3 constructors in this list score and match the same and if the incompatible constructor is examined first then it's used. This in turn causes VarArgs.normalizeArgsForVarArgs to attempt to create an array of size -1 as it calculates the needed size of the varargs array. The reported exception seems to be generated as the exception handler itself crashes, being unable to deal with the root cause error.
> https://github.com/GJKrupa/DROOLS-1703
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3187) add-user.sh tool prints unexpected characters if arrow keys are pushed during interactive mode
by Marek Marusic (JIRA)
Marek Marusic created WFCORE-3187:
-------------------------------------
Summary: add-user.sh tool prints unexpected characters if arrow keys are pushed during interactive mode
Key: WFCORE-3187
URL: https://issues.jboss.org/browse/WFCORE-3187
Project: WildFly Core
Issue Type: Bug
Components: CLI, Security
Affects Versions: 3.0.0.Beta29
Reporter: Marek Marusic
Assignee: Marek Marusic
Priority: Minor
*Description of problem:*
add-user.sh tool prints unexpected characters if arrow keys are pushed during interactive mode.
*How reproducible:*
Always
*Steps to Reproduce:*
# ./add-user.sh
# press ←,↑,→,↓ keys
*Actual results:*
{noformat}
[mkopecky@localhost bin]$ ./add-user.sh
What type of user do you wish to add?
a) Management User (mgmt-users.properties)
b) Application User (application-users.properties)
(a): ^[[D^[[A^[[C^[[B
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-4572) wildfly-arquillian uses slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-4572?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos edited comment on WFLY-4572 at 8/16/17 5:09 AM:
----------------------------------------------------------------------
One question, while trying to build wildfly locally using the build bat, I am confronted with unfound dependenicies.
So now trying to do the following on my local machine:
{panel}
SET GROUP_ID=org.slf4j
SET ARTIFACT_ID=slf4j-api
SET ARTIFACT_VERSION=1.7.7.jbossorg-1
mvn org.apache.maven.plugins:maven-dependency-plugin:copy -Dmdep.useBaseVersion=true -DoutputAbsoluteArtifactFilename -DoutputDirectory=%WORKING_DIR% -Dartifact=%GROUP_ID%:%ARTIFACT_ID%:%ARTIFACT_VERSION%
{panel}
I end up getting that this artifact is not to be found in the remote repositories.
I am getting this for multiple artifacts.
Now looking at the mirror file system:
http://uk.maven.org/maven2/org/slf4j/slf4j-api/
We can see that this true the dependencyh is not there.
But looking at maven central page.
https://mvnrepository.com/artifact/org.slf4j/slf4j-api/1.7.7.jbossorg-1
The dependency should be found.
What exactly is going on?
Kindest regards.
was (Author: nuno.godinhomatos):
One question, while trying to build wildfly locally using the build bat, I am confronted with unfound dependenicies.
So now trying to do the following on my local machine:
{panel}
SET GROUP_ID=org.slf4j
SET ARTIFACT_ID=slf4j-api
SET ARTIFACT_VERSION=1.7.7.jbossorg-1
mvn org.apache.maven.plugins:maven-dependency-plugin:copy -Dmdep.useBaseVersion=true -DoutputAbsoluteArtifactFilename -DoutputDirectory=%WORKING_DIR% -Dartifact=%GROUP_ID%:%ARTIFACT_ID%:%ARTIFACT_VERSION%
{panel}
I end up getting that this artifact is not to be found in the remote repositories.
{panel}
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.8:copy (default-cli) on project standalone-pom: Unable to resolve artifact. Could not transfer art
ifact org.slf4j:slf4j-api:jar:1.7.7.jbossorg-1 from/to snapshots (http://repository.scdc.swisslog.com:8080/nexus/content/repositories/snaps...): Failed to transfer file: http://r
epository.scdc.swisslog.com:8080/nexus/content/repositories/snapshots/org/slf4j/slf4j-api/1.7.7.jbossorg-1/slf4j-api-1.7.7.jbossorg-1.jar. Return code is: 400 , ReasonPhrase:Reposi
tory version policy: SNAPSHOT does not allow version: 1.7.7.jbossorg-1.
{panel}
I am getting this for multiple artifacts.
Now looking at the mirror file system:
http://uk.maven.org/maven2/org/slf4j/slf4j-api/
We can see that this true the dependencyh is not there.
But looking at maven central page.
https://mvnrepository.com/artifact/org.slf4j/slf4j-api/1.7.7.jbossorg-1
The dependency should be found.
What exactly is going on?
Kindest regards.
> wildfly-arquillian uses slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-4572
> URL: https://issues.jboss.org/browse/WFLY-4572
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 8.2.0.Final, 9.0.0.Beta2
> Reporter: Martin Kouba
> Assignee: James Perkins
> Fix For: 9.0.0.CR1
>
>
> GAV: {{org.slf4j:slf4j-api:1.7.7.jbossorg-1}}
> As a result, it's not possible to build a project which depends on some referencing module, e.g. {{wildfly-arquillian-common}}, and does not define JBoss repository at the same time.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (DROOLS-1703) When incompatible varargs constructors exist, resolution sometimes incorrect
by Gerard Krupa (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1703?page=com.atlassian.jira.plugi... ]
Gerard Krupa edited comment on DROOLS-1703 at 8/16/17 4:47 AM:
---------------------------------------------------------------
There is something odd I'm seeing, where this fails randomly on our CI box because the constructors appear to be enumerated in a random order each time and doesn't fail on developer PCs because they seem to be enumerated in declaration order. The CI box is an 8-core EC2 instance running CentOS 7 and the dev machines are dual core i7s running Ubuntu 16.04. They are running identical versions of OpenJDK and Maven. If I change the order of the constructor declaration on the dev box then it fails every time.
was (Author: gjkrupa):
There is something odd I'm seeing, where this fails randomly on our CI box because the constructors appear to be enumerated in a random order each time and doesn't fail on developer PCs because they seem to be enumerated in declaration order. The CI box is an 8-core EC2 instance running CentOS 7 and the dev machines are dual core i7s running Ubuntu 16.04. They are running identical versions of OpenJDK and Maven.
> When incompatible varargs constructors exist, resolution sometimes incorrect
> ----------------------------------------------------------------------------
>
> Key: DROOLS-1703
> URL: https://issues.jboss.org/browse/DROOLS-1703
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final
> Environment: CentOS 7 (x86_64)
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (build 1.8.0_131-b12)
> OpenJDK 64-Bit Server VM (build 25.131-b12, mixed mode)
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T19:39:06Z)
> Reporter: Gerard Krupa
> Assignee: Mario Fusco
>
> We have a class with 3 constructors:
> Thingy(String name)
> Thingy(String name, Object... args)
> Thingy(String name, String version, Object... args)
> When calling the constructor with a single paramater from a DRL:
> Thingy(drools.getRule().getName())
> we sometimes get an odd exception in our unit tests:
> {{[INFO] java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> [INFO] at java.lang.String.substring(String.java:1927)
> [INFO] at org.mvel2.util.ErrorUtil.rewriteIfNeeded(ErrorUtil.java:17)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:975)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:396)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:163)}}
> The root cause of the issue appears to be the selection of varargs constructors by ParseTools.getBestConstructorCandidate and getMethodScore. The scoring checks that the arguments from left to right match the expected parameter classes and scores based on their coerce-ability. The scoring then compares the number of parameters to arguments *only* if the accumulated score is still 0 (and at this point it's not zero because the first parameter matched the expected type).
> All 3 constructors in this list score and match the same and if the incompatible constructor is examined first then it's used. This in turn causes VarArgs.normalizeArgsForVarArgs to attempt to create an array of size -1 as it calculates the needed size of the varargs array. The reported exception seems to be generated as the exception handler itself crashes, being unable to deal with the root cause error.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (DROOLS-1703) When incompatible varargs constructors exist, resolution sometimes incorrect
by Gerard Krupa (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1703?page=com.atlassian.jira.plugi... ]
Gerard Krupa updated DROOLS-1703:
---------------------------------
Environment:
CentOS 7 (x86_64)
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-b12)
OpenJDK 64-Bit Server VM (build 25.131-b12, mixed mode)
Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T19:39:06Z)
was:
Ubuntu 16..0.4 (x86_64)
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-b12)
OpenJDK 64-Bit Server VM (build 25.131-b12, mixed mode)
Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T19:39:06Z)
> When incompatible varargs constructors exist, resolution sometimes incorrect
> ----------------------------------------------------------------------------
>
> Key: DROOLS-1703
> URL: https://issues.jboss.org/browse/DROOLS-1703
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final
> Environment: CentOS 7 (x86_64)
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (build 1.8.0_131-b12)
> OpenJDK 64-Bit Server VM (build 25.131-b12, mixed mode)
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T19:39:06Z)
> Reporter: Gerard Krupa
> Assignee: Mario Fusco
>
> We have a class with 3 constructors:
> Thingy(String name)
> Thingy(String name, Object... args)
> Thingy(String name, String version, Object... args)
> When calling the constructor with a single paramater from a DRL:
> Thingy(drools.getRule().getName())
> we sometimes get an odd exception in our unit tests:
> {{[INFO] java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> [INFO] at java.lang.String.substring(String.java:1927)
> [INFO] at org.mvel2.util.ErrorUtil.rewriteIfNeeded(ErrorUtil.java:17)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:975)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:396)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:163)}}
> The root cause of the issue appears to be the selection of varargs constructors by ParseTools.getBestConstructorCandidate and getMethodScore. The scoring checks that the arguments from left to right match the expected parameter classes and scores based on their coerce-ability. The scoring then compares the number of parameters to arguments *only* if the accumulated score is still 0 (and at this point it's not zero because the first parameter matched the expected type).
> All 3 constructors in this list score and match the same and if the incompatible constructor is examined first then it's used. This in turn causes VarArgs.normalizeArgsForVarArgs to attempt to create an array of size -1 as it calculates the needed size of the varargs array. The reported exception seems to be generated as the exception handler itself crashes, being unable to deal with the root cause error.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (DROOLS-1703) When incompatible varargs constructors exist, resolution sometimes incorrect
by Gerard Krupa (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1703?page=com.atlassian.jira.plugi... ]
Gerard Krupa commented on DROOLS-1703:
--------------------------------------
There is something odd I'm seeing, where this fails randomly on our CI box because the constructors appear to be enumerated in a random order each time and doesn't fail on developer PCs because they seem to be enumerated in declaration order. The CI box is an 8-core EC2 instance running CentOS 7 and the dev machines are dual core i7s running Ubuntu 16.04. They are running identical versions of OpenJDK and Maven.
> When incompatible varargs constructors exist, resolution sometimes incorrect
> ----------------------------------------------------------------------------
>
> Key: DROOLS-1703
> URL: https://issues.jboss.org/browse/DROOLS-1703
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final
> Environment: CentOS 7 (x86_64)
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (build 1.8.0_131-b12)
> OpenJDK 64-Bit Server VM (build 25.131-b12, mixed mode)
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T19:39:06Z)
> Reporter: Gerard Krupa
> Assignee: Mario Fusco
>
> We have a class with 3 constructors:
> Thingy(String name)
> Thingy(String name, Object... args)
> Thingy(String name, String version, Object... args)
> When calling the constructor with a single paramater from a DRL:
> Thingy(drools.getRule().getName())
> we sometimes get an odd exception in our unit tests:
> {{[INFO] java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> [INFO] at java.lang.String.substring(String.java:1927)
> [INFO] at org.mvel2.util.ErrorUtil.rewriteIfNeeded(ErrorUtil.java:17)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:975)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:396)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:163)}}
> The root cause of the issue appears to be the selection of varargs constructors by ParseTools.getBestConstructorCandidate and getMethodScore. The scoring checks that the arguments from left to right match the expected parameter classes and scores based on their coerce-ability. The scoring then compares the number of parameters to arguments *only* if the accumulated score is still 0 (and at this point it's not zero because the first parameter matched the expected type).
> All 3 constructors in this list score and match the same and if the incompatible constructor is examined first then it's used. This in turn causes VarArgs.normalizeArgsForVarArgs to attempt to create an array of size -1 as it calculates the needed size of the varargs array. The reported exception seems to be generated as the exception handler itself crashes, being unable to deal with the root cause error.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9162) EEConcurrentManagementTestCase fails with security manager
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-9162?page=com.atlassian.jira.plugin.... ]
Chao Wang reassigned WFLY-9162:
-------------------------------
Assignee: Chao Wang
> EEConcurrentManagementTestCase fails with security manager
> ----------------------------------------------------------
>
> Key: WFLY-9162
> URL: https://issues.jboss.org/browse/WFLY-9162
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
> Assignee: Chao Wang
>
> EEConcurrentManagementTestCase fails with security manager
> {code}
> Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
> JBOSS-LOCAL-USER: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/hsvabek/securityworkspace/VERIFICATION/2017_08_02_BEAP-7584/jboss-eap-7.1.0.ER3-src/testsuite/integration/basic/target/jbossas/standalone/tmp/auth/local55625406098549935.challenge" "read")" in code source "(vfs:/content/EEConcurrentManagementTestCase.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.EEConcurrentManagementTestCase.jar" from Service Module Loader")
> DIGEST-MD5: javax.security.sasl.SaslException: DIGEST-MD5: Server rejected authentication
> at org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:109)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:400)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:542)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:504)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:492)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:194)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:118)
> ... 157 more
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9163) FlushOperationsTestCase fails with security manager
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-9163?page=com.atlassian.jira.plugin.... ]
Chao Wang reassigned WFLY-9163:
-------------------------------
Assignee: Chao Wang
> FlushOperationsTestCase fails with security manager
> ---------------------------------------------------
>
> Key: WFLY-9163
> URL: https://issues.jboss.org/browse/WFLY-9163
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
> Assignee: Chao Wang
>
> FlushOperationsTestCase fails with security manager
> {code}
> Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
> JBOSS-LOCAL-USER: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/hsvabek/securityworkspace/VERIFICATION/2017_08_02_BEAP-7584/jboss-eap-7.1.0.ER3-src/testsuite/integration/basic/target/jbossas/standalone/tmp/auth/local7024820816277944867.challenge" "read")" in code source "(vfs:/content/flush-operations.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.flush-operations.jar" from Service Module Loader")
> DIGEST-MD5: javax.security.sasl.SaslException: DIGEST-MD5: Server rejected authentication
> at org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:109)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:400)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:542)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:504)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:492)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:194)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:118)
> ... 148 more
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-4572) wildfly-arquillian uses slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-4572?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos commented on WFLY-4572:
---------------------------------------------
One question, while trying to build wildfly locally using the build bat, I am confronted with unfound dependenicies.
So now trying to do the following on my local machine:
{panel}
SET GROUP_ID=org.slf4j
SET ARTIFACT_ID=slf4j-api
SET ARTIFACT_VERSION=1.7.7.jbossorg-1
mvn org.apache.maven.plugins:maven-dependency-plugin:copy -Dmdep.useBaseVersion=true -DoutputAbsoluteArtifactFilename -DoutputDirectory=%WORKING_DIR% -Dartifact=%GROUP_ID%:%ARTIFACT_ID%:%ARTIFACT_VERSION%
{panel}
I end up getting that this artifact is not to be found in the remote repositories.
{panel}
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.8:copy (default-cli) on project standalone-pom: Unable to resolve artifact. Could not transfer art
ifact org.slf4j:slf4j-api:jar:1.7.7.jbossorg-1 from/to snapshots (http://repository.scdc.swisslog.com:8080/nexus/content/repositories/snaps...): Failed to transfer file: http://r
epository.scdc.swisslog.com:8080/nexus/content/repositories/snapshots/org/slf4j/slf4j-api/1.7.7.jbossorg-1/slf4j-api-1.7.7.jbossorg-1.jar. Return code is: 400 , ReasonPhrase:Reposi
tory version policy: SNAPSHOT does not allow version: 1.7.7.jbossorg-1.
{panel}
I am getting this for multiple artifacts.
Now looking at the mirror file system:
http://uk.maven.org/maven2/org/slf4j/slf4j-api/
We can see that this true the dependencyh is not there.
But looking at maven central page.
https://mvnrepository.com/artifact/org.slf4j/slf4j-api/1.7.7.jbossorg-1
The dependency should be found.
What exactly is going on?
Kindest regards.
> wildfly-arquillian uses slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-4572
> URL: https://issues.jboss.org/browse/WFLY-4572
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 8.2.0.Final, 9.0.0.Beta2
> Reporter: Martin Kouba
> Assignee: James Perkins
> Fix For: 9.0.0.CR1
>
>
> GAV: {{org.slf4j:slf4j-api:1.7.7.jbossorg-1}}
> As a result, it's not possible to build a project which depends on some referencing module, e.g. {{wildfly-arquillian-common}}, and does not define JBoss repository at the same time.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months