[JBoss JIRA] (JBMETA-399) Metadata doesn't compile with Java 9 EA
by Carlo de Wolf (JIRA)
Carlo de Wolf created JBMETA-399:
------------------------------------
Summary: Metadata doesn't compile with Java 9 EA
Key: JBMETA-399
URL: https://issues.jboss.org/browse/JBMETA-399
Project: JBoss Metadata
Issue Type: Task
Reporter: Carlo de Wolf
{code}
Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 9-ea, vendor: Oracle Corporation
Java home: /opt/oracle/jdk-9-ea+161
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-62-generic", arch: "amd64", family: "unix"
{code}
Results in:
{code}
$ JAVA_HOME=/opt/oracle/jdk-9-ea+161/ mvn clean package
---------------------------------------------------
constituent[0]: file:/usr/share/maven/lib/maven-repository-metadata-3.x.jar
constituent[1]: file:/usr/share/maven/lib/sisu-inject.jar
constituent[2]: file:/usr/share/maven/lib/eclipse-aether-spi.jar
constituent[3]: file:/usr/share/maven/lib/cdi-api.jar
constituent[4]: file:/usr/share/maven/lib/maven-plugin-api-3.x.jar
constituent[5]: file:/usr/share/maven/lib/sisu-plexus.jar
constituent[6]: file:/usr/share/maven/lib/wagon-provider-api.jar
constituent[7]: file:/usr/share/maven/lib/eclipse-aether-transport-wagon.jar
constituent[8]: file:/usr/share/maven/lib/maven-core-3.x.jar
constituent[9]: file:/usr/share/maven/lib/eclipse-aether-util.jar
constituent[10]: file:/usr/share/maven/lib/slf4j-simple.jar
constituent[11]: file:/usr/share/maven/lib/javax.inject.jar
constituent[12]: file:/usr/share/maven/lib/plexus-component-annotations.jar
constituent[13]: file:/usr/share/maven/lib/slf4j-api.jar
constituent[14]: file:/usr/share/maven/lib/eclipse-aether-api.jar
constituent[15]: file:/usr/share/maven/lib/guava.jar
constituent[16]: file:/usr/share/maven/lib/maven-embedder-3.x.jar
constituent[17]: file:/usr/share/maven/lib/plexus-utils.jar
constituent[18]: file:/usr/share/maven/lib/commons-lang.jar
constituent[19]: file:/usr/share/maven/lib/maven-builder-support-3.x.jar
constituent[20]: file:/usr/share/maven/lib/maven-compat-3.x.jar
constituent[21]: file:/usr/share/maven/lib/maven-model-3.x.jar
constituent[22]: file:/usr/share/maven/lib/maven-settings-builder-3.x.jar
constituent[23]: file:/usr/share/maven/lib/eclipse-aether-connector-basic.jar
constituent[24]: file:/usr/share/maven/lib/maven-artifact-3.x.jar
constituent[25]: file:/usr/share/maven/lib/plexus-interpolation.jar
constituent[26]: file:/usr/share/maven/lib/commons-io.jar
constituent[27]: file:/usr/share/maven/lib/plexus-cipher.jar
constituent[28]: file:/usr/share/maven/lib/commons-cli.jar
constituent[29]: file:/usr/share/maven/lib/wagon-file.jar
constituent[30]: file:/usr/share/maven/lib/commons-lang3.jar
constituent[31]: file:/usr/share/maven/lib/maven-settings-3.x.jar
constituent[32]: file:/usr/share/maven/lib/aopalliance.jar
constituent[33]: file:/usr/share/maven/lib/maven-model-builder-3.x.jar
constituent[34]: file:/usr/share/maven/lib/wagon-http-shared.jar
constituent[35]: file:/usr/share/maven/lib/wagon-http-shaded.jar
constituent[36]: file:/usr/share/maven/lib/plexus-sec-dispatcher.jar
constituent[37]: file:/usr/share/maven/lib/eclipse-aether-impl.jar
constituent[38]: file:/usr/share/maven/lib/guice.jar
constituent[39]: file:/usr/share/maven/lib/maven-aether-provider-3.x.jar
constituent[40]: file:/usr/share/maven/lib/jsoup.jar
constituent[41]: file:/usr/share/maven/conf/logging/
---------------------------------------------------
Exception in thread "main" com.google.common.util.concurrent.ExecutionError: java.lang.NoClassDefFoundError: Could not initialize class com.google.inject.internal.cglib.core.$ReflectUtils
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2203)
at com.google.common.cache.LocalCache.get(LocalCache.java:3951)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3955)
at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4870)
at com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4876)
at com.google.inject.internal.FailableCache.get(FailableCache.java:48)
at com.google.inject.internal.ConstructorInjectorStore.get(ConstructorInjectorStore.java:50)
at com.google.inject.internal.ConstructorBindingImpl.initialize(ConstructorBindingImpl.java:137)
at com.google.inject.internal.InjectorImpl.initializeBinding(InjectorImpl.java:533)
at com.google.inject.internal.AbstractBindingProcessor$Processor$1.run(AbstractBindingProcessor.java:160)
at com.google.inject.internal.ProcessedBindingData.initializeBindings(ProcessedBindingData.java:44)
at com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:123)
at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)
at com.google.inject.Guice.createInjector(Guice.java:99)
at com.google.inject.Guice.createInjector(Guice.java:73)
at com.google.inject.Guice.createInjector(Guice.java:62)
at org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:481)
at org.codehaus.plexus.DefaultPlexusContainer.<init>(DefaultPlexusContainer.java:206)
at org.apache.maven.cli.MavenCli.container(MavenCli.java:545)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:281)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:547)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.google.inject.internal.cglib.core.$ReflectUtils
at com.google.inject.internal.cglib.reflect.$FastClass$Generator.getProtectionDomain(FastClass.java:73)
at com.google.inject.internal.cglib.core.$AbstractClassGenerator.create(AbstractClassGenerator.java:206)
at com.google.inject.internal.cglib.reflect.$FastClass$Generator.create(FastClass.java:65)
at com.google.inject.internal.BytecodeGen.newFastClass(BytecodeGen.java:204)
at com.google.inject.internal.DefaultConstructionProxyFactory.create(DefaultConstructionProxyFactory.java:55)
at com.google.inject.internal.ProxyFactory.create(ProxyFactory.java:159)
at com.google.inject.internal.ConstructorInjectorStore.createConstructor(ConstructorInjectorStore.java:90)
at com.google.inject.internal.ConstructorInjectorStore.access$000(ConstructorInjectorStore.java:29)
at com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:37)
at com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:33)
at com.google.inject.internal.FailableCache$1.load(FailableCache.java:37)
at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3540)
at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2321)
at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2284)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199)
... 28 more
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1021) GSS mechanisms OIDs into OidsUtil
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1021?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1021:
----------------------------
Labels: eap71_beta kerberos (was: eap71_beta kerberos management-model model-review)
> GSS mechanisms OIDs into OidsUtil
> ---------------------------------
>
> Key: ELY-1021
> URL: https://issues.jboss.org/browse/ELY-1021
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Utils
> Affects Versions: 1.1.0.Beta32
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
> Labels: eap71_beta, kerberos
>
> * {{mechanism-oids}}
> ** Minimal command for kerberos security factory creation is {code}/subsystem=elytron/kerberos-security-factory=kerberos:add(principal=mchoma, path=/path/to/keytab, mechanism-oids=[1.2.840.113554.1.2.2]){code}
> ** I don't think it is user-friendly to require user to specify mechanism-oids. I think some reasonable default value should be used here.
> * {{minimum-remaining-lifetime}}
> ** please, specify units in documentation, e.g. seconds/minutes
> * {{relative-to}}
> ** as just path reference can be used here, probably should be just "expressions-allowed" => false
> ** In legacy settings it is documented better: "The name of another previously named path, or of one of the standard paths provided by the system. If 'relative-to' is provided, the value of the 'path' attribute is treated as relative to the path specified by this attribute."
> * {{server}}
> ** I assume based on {{server}} attribute INITIATE_ONLY or ACCEPT_ONLY is configured on GSSCredential [1]. Wouldn't it be useful to have also possibility to set INITIATE_AND_ACCEPT? Couldn't that be useful for example in case of identity propagation.
> * -{{for-hosts}}-
> ** -comparing to legacy security {{kerberosIdentityType}} I am missing for-hosts. Elytron won't provide such feature?-
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1021) GSS mechanisms OIDs into OidsUtil
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1021?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1021:
----------------------------
Description:
* {{mechanism-oids}}
** Minimal command for kerberos security factory creation is {code}/subsystem=elytron/kerberos-security-factory=kerberos:add(principal=mchoma, path=/path/to/keytab, mechanism-oids=[1.2.840.113554.1.2.2]){code}
** I don't think it is user-friendly to require user to specify mechanism-oids. I think some reasonable default value should be used here.
was:
* {{mechanism-oids}}
** Minimal command for kerberos security factory creation is {code}/subsystem=elytron/kerberos-security-factory=kerberos:add(principal=mchoma, path=/path/to/keytab, mechanism-oids=[1.2.840.113554.1.2.2]){code}
** I don't think it is user-friendly to require user to specify mechanism-oids. I think some reasonable default value should be used here.
* {{minimum-remaining-lifetime}}
** please, specify units in documentation, e.g. seconds/minutes
* {{relative-to}}
** as just path reference can be used here, probably should be just "expressions-allowed" => false
** In legacy settings it is documented better: "The name of another previously named path, or of one of the standard paths provided by the system. If 'relative-to' is provided, the value of the 'path' attribute is treated as relative to the path specified by this attribute."
* {{server}}
** I assume based on {{server}} attribute INITIATE_ONLY or ACCEPT_ONLY is configured on GSSCredential [1]. Wouldn't it be useful to have also possibility to set INITIATE_AND_ACCEPT? Couldn't that be useful for example in case of identity propagation.
* -{{for-hosts}}-
** -comparing to legacy security {{kerberosIdentityType}} I am missing for-hosts. Elytron won't provide such feature?-
> GSS mechanisms OIDs into OidsUtil
> ---------------------------------
>
> Key: ELY-1021
> URL: https://issues.jboss.org/browse/ELY-1021
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Utils
> Affects Versions: 1.1.0.Beta32
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
> Labels: eap71_beta, kerberos
>
> * {{mechanism-oids}}
> ** Minimal command for kerberos security factory creation is {code}/subsystem=elytron/kerberos-security-factory=kerberos:add(principal=mchoma, path=/path/to/keytab, mechanism-oids=[1.2.840.113554.1.2.2]){code}
> ** I don't think it is user-friendly to require user to specify mechanism-oids. I think some reasonable default value should be used here.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2566) Subsystem parsing tests ignores wrong END_ELEMENT
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2566?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-2566:
------------------------------------------
[~honza889] I think in the short term we could possibly fix this while loop in the ElytronSubsystemParser
{code:java}
while (reader.hasNext() && reader.nextTag() != END_ELEMENT) {
{code}
Removing the reader.hasNext() check may be sufficient for the reader.nextTag to blow up if we have overshot and over parsed.
> Subsystem parsing tests ignores wrong END_ELEMENT
> -------------------------------------------------
>
> Key: WFCORE-2566
> URL: https://issues.jboss.org/browse/WFCORE-2566
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 3.0.0.Beta9
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Minor
>
> Tests based on *AbstractSubsystemBaseTest* ignores bugs like excessive {code}requireNoContent(reader);{code}
> Tests will fail only if some next element follows - its parsing fails in such case correctly.
> Would be better to add same check in the end of *<test>* parsing, which would check not only there is END_ELEMENT, but also that its name really equals *test*.
> Because this can stay bugs like https://github.com/wildfly-security-incubator/wildfly-core/pull/85/files unnoticed.
> Probably can be added into org.jboss.as.subsystem.test.SubsystemTestDelegate#parse(org.jboss.as.subsystem.test.AdditionalParsers, java.lang.String)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8415) Remove Elytron integration tests module from default build chain
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8415?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar moved JBEAP-9750 to WFLY-8415:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8415 (was: JBEAP-9750)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Build System
Test Suite
(was: Build System)
Affects Version/s: (was: 7.1.0.DR12)
> Remove Elytron integration tests module from default build chain
> ----------------------------------------------------------------
>
> Key: WFLY-8415
> URL: https://issues.jboss.org/browse/WFLY-8415
> Project: WildFly
> Issue Type: Task
> Components: Build System, Test Suite
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
>
> Elytron module is always part of the build chain now. We use separate jobs to run unit tests, integration tests and mixed domain tests and Elytron integration tests are now run in all of them.
> e.g. command we use to run just unit tests {{mvn test -DskipTests -Dts.noSmoke}} now starts also Elytron module (same goes to mixed domain, domain and others).
> Elytron integration module should behave as other test suite modules - be part of {{all-modules.module.profile}} profile, have its own {{elytron.module.profile}} with {{ts.elytron}} activation property.
> see http://pastebin.test.redhat.com/457432
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1021) GSS mechanisms OIDs into OidsUtil
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1021?page=com.atlassian.jira.plugin.s... ]
Jan Kalina moved JBEAP-9749 to ELY-1021:
----------------------------------------
Project: WildFly Elytron (was: JBoss Enterprise Application Platform)
Key: ELY-1021 (was: JBEAP-9749)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Utils
(was: Security)
(was: User Experience)
Affects Version/s: 1.1.0.Beta32
(was: 7.1.0.DR6)
> GSS mechanisms OIDs into OidsUtil
> ---------------------------------
>
> Key: ELY-1021
> URL: https://issues.jboss.org/browse/ELY-1021
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Utils
> Affects Versions: 1.1.0.Beta32
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
> Labels: eap71_beta, kerberos, management-model, model-review
>
> * {{mechanism-oids}}
> ** Minimal command for kerberos security factory creation is {code}/subsystem=elytron/kerberos-security-factory=kerberos:add(principal=mchoma, path=/path/to/keytab, mechanism-oids=[1.2.840.113554.1.2.2]){code}
> ** I don't think it is user-friendly to require user to specify mechanism-oids. I think some reasonable default value should be used here.
> * {{minimum-remaining-lifetime}}
> ** please, specify units in documentation, e.g. seconds/minutes
> * {{relative-to}}
> ** as just path reference can be used here, probably should be just "expressions-allowed" => false
> ** In legacy settings it is documented better: "The name of another previously named path, or of one of the standard paths provided by the system. If 'relative-to' is provided, the value of the 'path' attribute is treated as relative to the path specified by this attribute."
> * {{server}}
> ** I assume based on {{server}} attribute INITIATE_ONLY or ACCEPT_ONLY is configured on GSSCredential [1]. Wouldn't it be useful to have also possibility to set INITIATE_AND_ACCEPT? Couldn't that be useful for example in case of identity propagation.
> * -{{for-hosts}}-
> ** -comparing to legacy security {{kerberosIdentityType}} I am missing for-hosts. Elytron won't provide such feature?-
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2566) Subsystem parsing tests ignores wrong END_ELEMENT
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2566?page=com.atlassian.jira.plugi... ]
Jan Kalina updated WFCORE-2566:
-------------------------------
Description:
Tests based on *AbstractSubsystemBaseTest* ignores bugs like excessive {code}requireNoContent(reader);{code}
Tests will fail only if some next element follows - its parsing fails in such case correctly.
Would be better to add same check in the end of *<test>* parsing, which would check not only there is END_ELEMENT, but also that its name really equals *test*.
Because this can stay bugs like https://github.com/wildfly-security-incubator/wildfly-core/pull/85/files unnoticed.
Probably can be added into org.jboss.as.subsystem.test.SubsystemTestDelegate#parse(org.jboss.as.subsystem.test.AdditionalParsers, java.lang.String)
was:
Tests based on *AbstractSubsystemBaseTest* ignores bugs like excessive {code}requireNoContent(reader);{code}
Tests will fail only if some next element follows - its parsing fails in such case correctly.
Would be better to add same check in the end of *<test>* parsing, which would check not only there is END_ELEMENT, but also that its name really equals *test*.
Because this can stay bugs like https://github.com/wildfly-security-incubator/wildfly-core/pull/85/files unnoticed.
> Subsystem parsing tests ignores wrong END_ELEMENT
> -------------------------------------------------
>
> Key: WFCORE-2566
> URL: https://issues.jboss.org/browse/WFCORE-2566
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 3.0.0.Beta9
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Minor
>
> Tests based on *AbstractSubsystemBaseTest* ignores bugs like excessive {code}requireNoContent(reader);{code}
> Tests will fail only if some next element follows - its parsing fails in such case correctly.
> Would be better to add same check in the end of *<test>* parsing, which would check not only there is END_ELEMENT, but also that its name really equals *test*.
> Because this can stay bugs like https://github.com/wildfly-security-incubator/wildfly-core/pull/85/files unnoticed.
> Probably can be added into org.jboss.as.subsystem.test.SubsystemTestDelegate#parse(org.jboss.as.subsystem.test.AdditionalParsers, java.lang.String)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month