[JBoss JIRA] (WFLY-7266) BOM wildfly-javaee7-with-tools mismanages some dependencies
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7266?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-7266.
-------------------------------
Fix Version/s: No Release
Resolution: Done
I've released jboss-javaee-specs 1.0.4.Final that has updated deps to spec apis.
In related to that I've also released wildfly boms 10.1.1.Final that uses this jboss-javaee-specs which should fix problems you are seeing.
> BOM wildfly-javaee7-with-tools mismanages some dependencies
> -----------------------------------------------------------
>
> Key: WFLY-7266
> URL: https://issues.jboss.org/browse/WFLY-7266
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.1.0.Final
> Environment: org.wildfly.bom:wildfly-javaee7-with-tools:10.1.0.Final
> org.wildfly:wildfly-spec-api:10.1.0.Final
> Reporter: kostd kostd
> Assignee: Tomaz Cerar
> Priority: Optional
> Fix For: No Release
>
> Attachments: pom.xml
>
>
> Earlier was created WFLY-6621 wildfly-spec-api:10.0.0.Final mismanages el-api, jsf-api
> Problem still exists in 10.1.0.Final. At this time I understood problem more clearly, so:
> 1. I have a dummy project with deps:
> {code:title:bom and spec}
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>org.wildfly.bom</groupId>
> <artifactId>wildfly-javaee7-with-tools</artifactId>
> <version>10.1.0.Final</version>
> <type>pom</type>
> <scope>import</scope>
> </dependency>
> </dependencies>
> </dependencyManagement>
>
> <dependencies>
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-spec-api</artifactId>
> <version>10.1.0.Final</version>
> <type>pom</type>
> <scope>provided</scope>
> </dependency>
> </dependencies>
> {code}
> Maven dependency tree for my project shows that it depends on el-api and jsf-api older than contained in wildfly-dist:10.1.0.Final`s modules:
> {code:title=mvn dependency:tree fragment}
> [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ test-maven-project ---
> [INFO] ru.argustelecom.argus:test-maven-project:ejb:333
> [INFO] \- org.wildfly:wildfly-spec-api:pom:10.1.0.Final:provided
> [INFO] +- org.glassfish:javax.json:jar:1.0.3:provided
> [INFO] +- org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.0_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.batch:jboss-batch-api_1.0_spec:jar:1.0.0.Final:provided
> [INFO] | \- javax.inject:javax.inject:jar:1:provided
> [INFO] +- org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.el:jboss-el-api_3.0_spec:jar:1.0.4.Final:provided
> [INFO] +- org.jboss.spec.javax.enterprise.concurrent:jboss-concurrency-api_1.0_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.faces:jboss-jsf-api_2.2_spec:jar:2.2.11:provided
> [INFO] +- org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.jms:jboss-jms-api_2.0_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.resource:jboss-connector-api_1.7_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.security.jacc:jboss-jacc-api_1.5_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.servlet.jsp:jboss-jsp-api_2.3_spec:jar:1.0.1.Final:provided
> [INFO] +- org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final:provided
> [INFO] +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final:provided
> [INFO] +- org.jboss.spec.javax.xml.bind:jboss-jaxb-api_2.2_spec:jar:1.0.4.Final:provided
> [INFO] +- org.jboss.spec.javax.xml.rpc:jboss-jaxrpc-api_1.1_spec:jar:1.0.1.Final:provided
> [INFO] +- org.jboss.spec.javax.xml.soap:jboss-saaj-api_1.3_spec:jar:1.0.3.Final:provided
> [INFO] +- org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:provided
> [INFO] +- org.hibernate.javax.persistence:hibernate-jpa-2.1-api:jar:1.0.0.Final:provided
> [INFO] +- javax.enterprise:cdi-api:jar:1.2:provided
> [INFO] +- com.sun.mail:javax.mail:jar:1.5.3:provided
> [INFO] | \- javax.activation:activation:jar:1.1.1:provided
> [INFO] +- org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO] +- javax.validation:validation-api:jar:1.1.0.Final:provided
> [INFO] +- org.jboss.spec.javax.management.j2ee:jboss-j2eemgmt-api_1.1_spec:jar:1.0.1.Final:provided
> [INFO] \- org.wildfly.checkstyle:wildfly-checkstyle-config:jar:1.0.4.Final:provided
> {code}
> el-api and jsf-api must have 1.0.7.Final and 2.2.13 versions respectively
> 2. This is because wildly-javaee7-with-tools inherits from wildfly-javaee7 which imports org.jboss.spec:jboss-javaee-7.0:1.0.3.Final who depends on too old el-api and jsf-api:
> {code:title=wildfly-javaee7 pom fragment}
> ..
> <version.org.jboss.spec.jboss.javaee.7>1.0.3.Final</version.org.jboss.spec.jboss.javaee.7>
> ...
> <!-- BOM imports -->
> <!-- JBoss distributes a complete set of Java EE 7 APIs including
> a Bill of Materials (BOM). A BOM specifies the versions of a "stack" (or
> a collection) of artifacts. We use this here so that we always get the correct
> versions of artifacts. Here we use the jboss-javaee-7.0 stack (you can read
> this as the JBoss stack of the Java EE full Profile 7 APIs). You can actually use
> this stack with any version of WildFly that implements Java EE 7! -->
> <dependency>
> <groupId>org.jboss.spec</groupId>
> <artifactId>jboss-javaee-7.0</artifactId>
> <version>${version.org.jboss.spec.jboss.javaee.7}</version>
> <type>pom</type>
> <scope>import</scope>
> </dependency>
> {code}
> {code:title=jboss-javaee-7.0 pom fragment}
> ...
> <version.org.jboss.spec.javax.el>1.0.4.Final</version.org.jboss.spec.javax.el>
> ...
> <version.org.jboss.spec.javax.faces>2.2.11</version.org.jboss.spec.javax.faces>
> ...
> <dependency>
> <groupId>org.jboss.spec.javax.el</groupId>
> <artifactId>jboss-el-api_3.0_spec</artifactId>
> <version>${version.org.jboss.spec.javax.el}</version>
> </dependency>
> ...
> <dependency>
> <groupId>org.jboss.spec.javax.faces</groupId>
> <artifactId>jboss-jsf-api_2.2_spec</artifactId>
> <version>${version.org.jboss.spec.javax.faces}</version>
> </dependency>
> {code}
> 3. Also can see some other dependencies (not only el-api and jsf-api), which version doubtful:
> org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final (must be 1.1.3.Final)
> org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final (must be 1.1.1.Final)
> org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final (must be 2.0.3.Final)
> com.sun.mail:javax.mail:jar:1.5.3 (must be 1.5.5)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1993) Logging MBean not available in platform-mbean core service
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1993?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved JBEAP-7322 to WFCORE-1993:
-------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1993 (was: JBEAP-7322)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: Domain Management)
(was: User Experience)
Affects Version/s: (was: 7.1.0.DR7)
> Logging MBean not available in platform-mbean core service
> ----------------------------------------------------------
>
> Key: WFCORE-1993
> URL: https://issues.jboss.org/browse/WFCORE-1993
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Pavel Jelinek
> Assignee: Brian Stansberry
>
> {code}
> /core-service=platform-mbean:read-resource-description
> {
> "outcome" => "success",
> "result" => {
> "description" => "Provides the management interface for monitoring and management of the Java virtual machine as well as the operating system on which the Java virtual machine is running. Exposes the JDK-provided JMX MBeans in the java.lang, java.nio and java.util.logging JMX domains.", ...
> {code}
> but java.util.logging JMX domain is not available in this service.
> Either add the 'Logging' type to the platform-mbean or change the description.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1993) Logging MBean not available in platform-mbean core service
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1993?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1993:
-------------------------------------
Description:
{code}
/core-service=platform-mbean:read-resource-description
{
"outcome" => "success",
"result" => {
"description" => "Provides the management interface for monitoring and management of the Java virtual machine as well as the operating system on which the Java virtual machine is running. Exposes the JDK-provided JMX MBeans in the java.lang, java.nio and java.util.logging JMX domains.", ...
{code}
but java.util.logging JMX domain is not available in this service.
Not exposing those mbeans is deliberate, so change the description.
was:
{code}
/core-service=platform-mbean:read-resource-description
{
"outcome" => "success",
"result" => {
"description" => "Provides the management interface for monitoring and management of the Java virtual machine as well as the operating system on which the Java virtual machine is running. Exposes the JDK-provided JMX MBeans in the java.lang, java.nio and java.util.logging JMX domains.", ...
{code}
but java.util.logging JMX domain is not available in this service.
Either add the 'Logging' type to the platform-mbean or change the description.
> Logging MBean not available in platform-mbean core service
> ----------------------------------------------------------
>
> Key: WFCORE-1993
> URL: https://issues.jboss.org/browse/WFCORE-1993
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Pavel Jelinek
> Assignee: Brian Stansberry
>
> {code}
> /core-service=platform-mbean:read-resource-description
> {
> "outcome" => "success",
> "result" => {
> "description" => "Provides the management interface for monitoring and management of the Java virtual machine as well as the operating system on which the Java virtual machine is running. Exposes the JDK-provided JMX MBeans in the java.lang, java.nio and java.util.logging JMX domains.", ...
> {code}
> but java.util.logging JMX domain is not available in this service.
> Not exposing those mbeans is deliberate, so change the description.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7600) Cache creation requires specific permissions when using security manager
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-7600:
----------------------------------
Summary: Cache creation requires specific permissions when using security manager
Key: WFLY-7600
URL: https://issues.jboss.org/browse/WFLY-7600
Project: WildFly
Issue Type: Bug
Components: Test Suite
Reporter: Paul Ferraro
Assignee: Ingo Weiss
Fix For: 11.0.0.Alpha1
*org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase#test*
{{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase -Dsecurity.manager}}
{code}
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/infinispan-resource-ref.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.infinispan-resource-ref.war:main" from Service Module Loader")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1442)
at org.infinispan.commons.util.Util.getClassLoaders(Util.java:127)
at org.infinispan.commons.util.Util.loadClassStrict(Util.java:163)
at org.infinispan.commons.util.ReflectionUtil.getClassForName(ReflectionUtil.java:319)
at org.infinispan.commons.util.ReflectionUtil.toClassArray(ReflectionUtil.java:313)
at org.infinispan.factories.AbstractComponentRegistry$Component.buildInjectionMethodsList(AbstractComponentRegistry.java:810)
at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:213)
at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:193)
at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:171)
at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:163)
at org.infinispan.factories.ComponentRegistry.<init>(ComponentRegistry.java:79)
... 210 more
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7589) Wrong description for injecting the same realm to Elytron security-domain in CLI
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7589?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev reassigned WFLY-7589:
-----------------------------------
Assignee: Ilia Vassilev (was: Darran Lofthouse)
> Wrong description for injecting the same realm to Elytron security-domain in CLI
> --------------------------------------------------------------------------------
>
> Key: WFLY-7589
> URL: https://issues.jboss.org/browse/WFLY-7589
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Ilia Vassilev
> Labels: user_experience
>
> Adding the same realms to one Elytron security-domain is denied in CLI. However failure-description is wrong. See:
> {code}
> /subsystem=elytron/security-domain=securityDomain:add(realms=[{realm=ApplicationRealm},{realm=ApplicationRealm}],default-realm=ApplicationRealm)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYELY00002: Can not inject the same realm 'securityDomain' in a single security domain 'ApplicationRealm'.",
> "rolled-back" => true
> }
> {code}
> It should says: "WFLYELY00002: Can not inject the same realm 'ApplicationRealm' in a single security domain 'securityDomain'.".
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (JGRP-2129) Schema generation fails on JDK9
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2129?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2129:
--------------------------------
Hmm, we'll still need to look into this as I'm using maven (to your suprise! :-)) when uploading artifacts to maven central, ie. mvn -DskipTests deploy
> Schema generation fails on JDK9
> -------------------------------
>
> Key: JGRP-2129
> URL: https://issues.jboss.org/browse/JGRP-2129
> Project: JGroups
> Issue Type: Task
> Reporter: Radoslav Husar
> Assignee: Bela Ban
> Priority: Minor
> Labels: jdk9
> Fix For: 4.1
>
>
> Not going to be a problem for a while until base is compiled with JDK9 by default, but just in case.
> {noformat}
> main:
> [mkdir] Created dir: /Users/rhusar/git/jgroups/target/schema
> [java] java.lang.ExceptionInInitializerError
> [java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:194)
> [java] at org.apache.tools.ant.taskdefs.Java.run(Java.java:771)
> [java] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:221)
> [java] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:135)
> [java] at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
> [java] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> [java] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> [java] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> [java] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:537)
> [java] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> [java] at org.apache.tools.ant.Task.perform(Task.java:348)
> [java] at org.apache.tools.ant.Target.execute(Target.java:390)
> [java] at org.apache.tools.ant.Target.performTasks(Target.java:411)
> [java] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
> [java] at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
> [java] at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:327)
> [java] at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> [java] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> [java] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> [java] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> [java] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> [java] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> [java] at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> [java] at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [java] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> [java] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> [java] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> [java] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> [java] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> [java] at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> [java] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> [java] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> [java] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:537)
> [java] at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> [java] at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> [java] at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> [java] at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> [java] Caused by: java.lang.ExceptionInInitializerError
> [java] at org.jgroups.conf.ClassConfigurator.<clinit>(ClassConfigurator.java:56)
> [java] at org.jgroups.protocols.ASYM_ENCRYPT.<clinit>(ASYM_ENCRYPT.java:55)
> [java] at java.lang.Class.forName0(java.base@9-ea/Native Method)
> [java] at java.lang.Class.forName(java.base@9-ea/Class.java:291)
> [java] at org.jgroups.util.XMLSchemaGenerator.getClasses(XMLSchemaGenerator.java:127)
> [java] at org.jgroups.util.XMLSchemaGenerator.generateProtocolSchema(XMLSchemaGenerator.java:106)
> [java] at org.jgroups.util.XMLSchemaGenerator.main(XMLSchemaGenerator.java:80)
> [java] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> [java] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> [java] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:537)
> [java] at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217)
> [java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152)
> [java] ... 38 more
> [java] Caused by: java.lang.NullPointerException
> [java] at org.jgroups.conf.ClassConfigurator.init(ClassConfigurator.java:229)
> [java] at org.jgroups.conf.ClassConfigurator.<clinit>(ClassConfigurator.java:53)
> [java] ... 50 more
> [java] Java Result: -1
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1980) Property file passed via CLI does not resolve expressions with relative path value in vault attributes
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1980?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1980:
------------------------------------------
I don't think the workaround should be included here, as it doesn't look like true workaround. And it confused me from the main issue. :)
Having to use server side properties instead of client side is analogous to just not using properties at all. It means the user was unable to control the value in the process where they want to control it. So I don't think it counts as a workaround.
> Property file passed via CLI does not resolve expressions with relative path value in vault attributes
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1980
> URL: https://issues.jboss.org/browse/WFCORE-1980
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha12
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
>
> Property file passed via CLI with --properties option does not resolve expressions in EAP 7, where in EAP 6 it works fine.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months