[JBoss JIRA] (WFWIP-5) Prompt behaves differently with color ouput and without it
by Erich Duda (JIRA)
Erich Duda created WFWIP-5:
------------------------------
Summary: Prompt behaves differently with color ouput and without it
Key: WFWIP-5
URL: https://issues.jboss.org/browse/WFWIP-5
Project: WildFly WIP
Issue Type: Bug
Reporter: Erich Duda
Assignee: Ingo Weiss
When I run the CLI with option {{--no-color-output}}, the batch or workflow mode is not highlighted by changing of prompt.
{code}
[disconnected /] batch
[disconnected /]
{code}
If I do the same with colors enabled, the batch mode adds extra # character into the prompt.
{code}
[disconnected /] batch
[disconnected / #]
{code}
The behavior is inconsistent. There is no reason to add # character to prompt only in color enabled mode. The same applies for if/for/try commands.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10278) Bean discovery in deployment dependencies (modules) fails to inject from static module-alias's exported dependency
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-10278?page=com.atlassian.jira.plugin... ]
Lin Gao updated WFLY-10278:
---------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/11161
> Bean discovery in deployment dependencies (modules) fails to inject from static module-alias's exported dependency
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10278
> URL: https://issues.jboss.org/browse/WFLY-10278
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Reporter: Lin Gao
> Assignee: Bartosz Spyrko-Śmietanko
> Priority: Critical
> Labels: downstream_dependency
>
> WAR CDI bean is failing to inject a CDI bean from a module-alias exported dependency. war -module-alias -> static module X -> static module Y (containing CDI Beans)
> A WAR uses a module-alias with the slot attribute. This module-alias is referenced in jboss-deployment-structure.xml:
> {code:java}
> <jboss-deployment-structure>
> <deployment>
> <dependencies>
> <module name="mycompany.test.CDIJarMaven" slot="moduloAliasError" meta-inf="export" annotations="true" />
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
> {code}
> moduleAliasError which the app has the target moduloNivel2:
> {code}
> <module-alias xmlns="urn:jboss:module:1.1" name="mycompany.test.CDIJarMaven" slot="moduloAliasError" target-name="mycompany.test.CDIJarMaven" target-slot="moduloNivel2"/>
> {code}
> moduloNivel2 which the modulo-alias references depends on main module and is including/exporting META-INF where the beans.xml is located:
> {code:java}
> <module xmlns="urn:jboss:module:1.5" name="mycompany.test.CDIJarMaven">
> <resources>
> <resource-root path="CDIJarMaven.jar"/>
> </resources>
> <dependencies>
> <module name="javax.faces.api" export="true"/>
>
> <!-- Timer de ejbs para el log de acceso-->
> <module name="javax.ejb.api"/>
> <module name="javax.enterprise.api" />
> </dependencies>
> </module>
> {code:java}
> modulo main contains the jar with the CDI beans and has a META-INF/beans.xml in it:
> {code:java}
> <module xmlns="urn:jboss:module:1.1" name="mycompany.test.CDIJarMaven" slot="moduloNivel2">
> <dependencies>
> <module name="mycompany.test.CDIJarMaven" slot="main" export="true">
> <imports>
> <include path="META-INF**" />
> </imports>
> <exports>
> <include path="META-INF**" />
> </exports>
> </module>
> </dependencies>
> </module>
> {code}
> The error we get is:
> {code:java}
> WELD-001408: Unsatisfied dependencies for type PruebaDTO with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private backingbeans.Page1.paginacion
> at backingbeans.Page1.paginacion(Page1.java:0)
> {code}
> Checking the code one can see how the beans.xml is seen :
> {code:java}
> EXTERNAL BeanDeploymentArchive (awar-mock02.war.external.jar:file:/jboss-eap-7.1/modules/mycompany/test/CDIJarMaven/main/CDIJarMaven.jar!/META-INF/beans.xml)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10278) Bean discovery in deployment dependencies (modules) fails to inject from static module-alias's exported dependency
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-10278?page=com.atlassian.jira.plugin... ]
Lin Gao reassigned WFLY-10278:
------------------------------
Assignee: Bartosz Spyrko-Śmietanko
> Bean discovery in deployment dependencies (modules) fails to inject from static module-alias's exported dependency
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10278
> URL: https://issues.jboss.org/browse/WFLY-10278
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Reporter: Lin Gao
> Assignee: Bartosz Spyrko-Śmietanko
> Priority: Critical
> Labels: downstream_dependency
>
> WAR CDI bean is failing to inject a CDI bean from a module-alias exported dependency. war -module-alias -> static module X -> static module Y (containing CDI Beans)
> A WAR uses a module-alias with the slot attribute. This module-alias is referenced in jboss-deployment-structure.xml:
> {code:java}
> <jboss-deployment-structure>
> <deployment>
> <dependencies>
> <module name="mycompany.test.CDIJarMaven" slot="moduloAliasError" meta-inf="export" annotations="true" />
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
> {code}
> moduleAliasError which the app has the target moduloNivel2:
> {code}
> <module-alias xmlns="urn:jboss:module:1.1" name="mycompany.test.CDIJarMaven" slot="moduloAliasError" target-name="mycompany.test.CDIJarMaven" target-slot="moduloNivel2"/>
> {code}
> moduloNivel2 which the modulo-alias references depends on main module and is including/exporting META-INF where the beans.xml is located:
> {code:java}
> <module xmlns="urn:jboss:module:1.5" name="mycompany.test.CDIJarMaven">
> <resources>
> <resource-root path="CDIJarMaven.jar"/>
> </resources>
> <dependencies>
> <module name="javax.faces.api" export="true"/>
>
> <!-- Timer de ejbs para el log de acceso-->
> <module name="javax.ejb.api"/>
> <module name="javax.enterprise.api" />
> </dependencies>
> </module>
> {code:java}
> modulo main contains the jar with the CDI beans and has a META-INF/beans.xml in it:
> {code:java}
> <module xmlns="urn:jboss:module:1.1" name="mycompany.test.CDIJarMaven" slot="moduloNivel2">
> <dependencies>
> <module name="mycompany.test.CDIJarMaven" slot="main" export="true">
> <imports>
> <include path="META-INF**" />
> </imports>
> <exports>
> <include path="META-INF**" />
> </exports>
> </module>
> </dependencies>
> </module>
> {code}
> The error we get is:
> {code:java}
> WELD-001408: Unsatisfied dependencies for type PruebaDTO with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private backingbeans.Page1.paginacion
> at backingbeans.Page1.paginacion(Page1.java:0)
> {code}
> Checking the code one can see how the beans.xml is seen :
> {code:java}
> EXTERNAL BeanDeploymentArchive (awar-mock02.war.external.jar:file:/jboss-eap-7.1/modules/mycompany/test/CDIJarMaven/main/CDIJarMaven.jar!/META-INF/beans.xml)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3787) JMX audit logging should support all the handlers supported by core audit logging
by Yeray Borges (JIRA)
Yeray Borges created WFCORE-3787:
------------------------------------
Summary: JMX audit logging should support all the handlers supported by core audit logging
Key: WFCORE-3787
URL: https://issues.jboss.org/browse/WFCORE-3787
Project: WildFly Core
Issue Type: Feature Request
Components: JMX
Affects Versions: 5.0.0.Alpha5
Reporter: Yeray Borges
Assignee: Yeray Borges
Users can enable audit logging for the management interfaces, which will log all operations performed using the management console, management CLI, or custom application that uses the Management API.
JMX subsystem can use the handlers defined for audit logging, but at this moment, only {{file-handler}} and {{syslog-handler}} can be used in JMX subsystem.
This issue will extend the list of supported handlers for JMX subsystem to all handlers supported by core audit logging.
The handlers supported by core audit logging are:
* file-handler
* in-memory-handler
* periodic-rotating-file-handler
* size-rotating-file-handler
* syslog-handler
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (ELY-1572) japicmp force source compatibility, but only binary compatibility is required
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1572?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1572:
----------------------------
Description:
As part of ELY-1523 japicmp was configured to force binary and source compatibility.
By last discussion, only binary compatibility is required.
{panel}
*Honza Kalina* jaspicmp reports it as source incompatibility, not as binary incompatibility - so it maybe it is false positive, as I would say it should be source-compatible...
*Darran Lofthouse* Binary is the only one we are really interested in, i.e. will an update to a later version of Elytron break something. Most of our backwards compatibility strategy is more about breaking things and upsetting people
{panel}
Japicmp currently reports adding default method into interface as source incompatible change (see https://github.com/siom79/japicmp/issues/201) -> blocks adding IV into MaskedPassword in ELY-867
was:
As part of ELY-1523 japicmp was configured to force binary and source compatibility.
By last discussion, only binary compatibility is required.
{panel}
*Honza Kalina* jaspicmp reports it as source incompatibility, not as binary incompatibility - so it maybe it is false positive, as I would say it should be source-compatible...
*Darran Lofthouse* Binary is the only one we are really interested in, i.e. will an update to a later version of Elytron break something. Most of our backwards compatibility strategy is more about breaking things and upsetting people
{panel}
Japicmp currently reports adding default method into interface as source incompatible change (see https://github.com/siom79/japicmp/issues/201) -> blocks adding IV into MaskedPassword in ELY-867
> japicmp force source compatibility, but only binary compatibility is required
> -----------------------------------------------------------------------------
>
> Key: ELY-1572
> URL: https://issues.jboss.org/browse/ELY-1572
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Build
> Affects Versions: 1.3.0.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> As part of ELY-1523 japicmp was configured to force binary and source compatibility.
> By last discussion, only binary compatibility is required.
> {panel}
> *Honza Kalina* jaspicmp reports it as source incompatibility, not as binary incompatibility - so it maybe it is false positive, as I would say it should be source-compatible...
> *Darran Lofthouse* Binary is the only one we are really interested in, i.e. will an update to a later version of Elytron break something. Most of our backwards compatibility strategy is more about breaking things and upsetting people
> {panel}
> Japicmp currently reports adding default method into interface as source incompatible change (see https://github.com/siom79/japicmp/issues/201) -> blocks adding IV into MaskedPassword in ELY-867
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (ELY-1572) japicmp force source compatibility, but only binary compatibility is required
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1572?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1572:
----------------------------
Description:
As part of ELY-1523 japicmp was configured to force binary and source compatibility.
By last discussion, only binary compatibility is required.
{panel}
*Honza Kalina* jaspicmp reports it as source incompatibility, not as binary incompatibility - so it maybe it is false positive, as I would say it should be source-compatible...
*Darran Lofthouse* Binary is the only one we are really interested in, i.e. will an update to a later version of Elytron break something. Most of our backwards compatibility strategy is more about breaking things and upsetting people
{panel}
Japicmp currently reports adding default method into interface as source incompatible change (see https://github.com/siom79/japicmp/issues/201) -> blocks adding IV into MaskedPassword in ELY-867
was:
As part of ELY-1523 japicmp was configured to force binary and source compatibility.
By last discussion, only binary compatibility is required.
{panel}
*Honza Kalina* jaspicmp reports it as source incompatibility, not as binary incompatibility - so it maybe it is false positive, as I would say it should be source-compatible...
*Darran Lofthouse* Binary is the only one we are really interested in, i.e. will an update to a later version of Elytron break something. Most of our backwards compatibility strategy is more about breaking things and upsetting people
{panel}
Also because of probably bug in japicmp, which causes new method in interface with default implementation is reported as source compatibility issue. -> blocks adding IV into masked password in ELY-876
> japicmp force source compatibility, but only binary compatibility is required
> -----------------------------------------------------------------------------
>
> Key: ELY-1572
> URL: https://issues.jboss.org/browse/ELY-1572
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Build
> Affects Versions: 1.3.0.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> As part of ELY-1523 japicmp was configured to force binary and source compatibility.
> By last discussion, only binary compatibility is required.
> {panel}
> *Honza Kalina* jaspicmp reports it as source incompatibility, not as binary incompatibility - so it maybe it is false positive, as I would say it should be source-compatible...
> *Darran Lofthouse* Binary is the only one we are really interested in, i.e. will an update to a later version of Elytron break something. Most of our backwards compatibility strategy is more about breaking things and upsetting people
> {panel}
> Japicmp currently reports adding default method into interface as source incompatible change (see https://github.com/siom79/japicmp/issues/201) -> blocks adding IV into MaskedPassword in ELY-867
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (ELY-1572) japicmp force source compatibility, but only binary compatibility is required
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1572?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1572:
----------------------------
Description:
As part of ELY-1523 japicmp was configured to force binary and source compatibility.
By last discussion, only binary compatibility is required.
{panel}
*Honza Kalina* jaspicmp reports it as source incompatibility, not as binary incompatibility - so it maybe it is false positive, as I would say it should be source-compatible...
*Darran Lofthouse* Binary is the only one we are really interested in, i.e. will an update to a later version of Elytron break something. Most of our backwards compatibility strategy is more about breaking things and upsetting people
{panel}
Also because of probably bug in japicmp, which causes new method in interface with default implementation is reported as source compatibility issue. -> blocks adding IV into masked password in ELY-876
was:
As part of ELY-1523 japicmp was configured to force binary and source compatibility.
By last discussion, only binary compatibility is required.
{panel}
*Honza Kalina* jaspicmp reports it as source incompatibility, not as binary incompatibility - so it maybe it is false positive, as I would say it should be source-compatible...
*Darran Lofthouse* Binary is the only one we are really interested in, i.e. will an update to a later version of Elytron break something. Most of our backwards compatibility strategy is more about breaking things and upsetting people
{panel}
Also because of probably bug in japicmp, which causes adding method into interface, even through default implementation is provided, is reported as source compatibility issue. -> blocks adding IV into masked password in ELY-867
> japicmp force source compatibility, but only binary compatibility is required
> -----------------------------------------------------------------------------
>
> Key: ELY-1572
> URL: https://issues.jboss.org/browse/ELY-1572
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Build
> Affects Versions: 1.3.0.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> As part of ELY-1523 japicmp was configured to force binary and source compatibility.
> By last discussion, only binary compatibility is required.
> {panel}
> *Honza Kalina* jaspicmp reports it as source incompatibility, not as binary incompatibility - so it maybe it is false positive, as I would say it should be source-compatible...
> *Darran Lofthouse* Binary is the only one we are really interested in, i.e. will an update to a later version of Elytron break something. Most of our backwards compatibility strategy is more about breaking things and upsetting people
> {panel}
> Also because of probably bug in japicmp, which causes new method in interface with default implementation is reported as source compatibility issue. -> blocks adding IV into masked password in ELY-876
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (ELY-1572) japicmp force source compatibility, but only binary compatibility is required
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1572?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1572:
----------------------------
Description:
As part of ELY-1523 japicmp was configured to force binary and source compatibility.
By last discussion, only binary compatibility is required.
{panel}
*Honza Kalina* jaspicmp reports it as source incompatibility, not as binary incompatibility - so it maybe it is false positive, as I would say it should be source-compatible...
*Darran Lofthouse* Binary is the only one we are really interested in, i.e. will an update to a later version of Elytron break something. Most of our backwards compatibility strategy is more about breaking things and upsetting people
{panel}
Also because of probably bug in japicmp, which causes adding method into interface, even through default implementation is provided, is reported as source compatibility issue. -> blocks adding IV into masked password in ELY-867
was:
As part of ELY-1523 japicmp was configured to force binary and source compatibility.
By last discussion, only binary compatibility is required.
{panel}
*Honza Kalina* jaspicmp reports it as source incompatibility, not as binary incompatibility - so it maybe it is false positive, as I would say it should be source-compatible...
*Darran Lofthouse* Binary is the only one we are really interested in, i.e. will an update to a later version of Elytron break something. Most of our backwards compatibility strategy is more about breaking things and upsetting people
{panel}
Also because of probably bug in japicmp, which causes adding method into interface, even through default implementation is provided, is reported as source compatibility issue. -> blocks adding IV into masked password in ELY-876
> japicmp force source compatibility, but only binary compatibility is required
> -----------------------------------------------------------------------------
>
> Key: ELY-1572
> URL: https://issues.jboss.org/browse/ELY-1572
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Build
> Affects Versions: 1.3.0.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> As part of ELY-1523 japicmp was configured to force binary and source compatibility.
> By last discussion, only binary compatibility is required.
> {panel}
> *Honza Kalina* jaspicmp reports it as source incompatibility, not as binary incompatibility - so it maybe it is false positive, as I would say it should be source-compatible...
> *Darran Lofthouse* Binary is the only one we are really interested in, i.e. will an update to a later version of Elytron break something. Most of our backwards compatibility strategy is more about breaking things and upsetting people
> {panel}
> Also because of probably bug in japicmp, which causes adding method into interface, even through default implementation is provided, is reported as source compatibility issue. -> blocks adding IV into masked password in ELY-867
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (ELY-1572) japicmp force source compatibility, but only binary compatibility is required
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1572?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1572:
----------------------------
Description:
As part of ELY-1523 japicmp was configured to force binary and source compatibility.
By last discussion, only binary compatibility is required.
{panel}
*Honza Kalina* jaspicmp reports it as source incompatibility, not as binary incompatibility - so it maybe it is false positive, as I would say it should be source-compatible...
*Darran Lofthouse* Binary is the only one we are really interested in, i.e. will an update to a later version of Elytron break something. Most of our backwards compatibility strategy is more about breaking things and upsetting people
{panel}
Also because of probably bug in japicmp, which causes adding method into interface, even through default implementation is provided, is reported as source compatibility issue. -> blocks adding IV into masked password in ELY-876
was:
As part of ELY-1523 japicmp was configured to force binary and source compatibility.
By last discussion, only binary compatibility is required.
{panel}
*Honza Kalina* jaspicmp reports it as source incompatibility, not as binary incompatibility - so it maybe it is false positive, as I would say it should be source-compatible...
*Darran Lofthouse* Binary is the only one we are really interested in, i.e. will an update to a later version of Elytron break something. Most of our backwards compatibility strategy is more about breaking things and upsetting people
{panel}
Also because of probably bug in japicmp, which causes adding method into interface, even through default implementation is provided, is reported as source compatibility issue.
> japicmp force source compatibility, but only binary compatibility is required
> -----------------------------------------------------------------------------
>
> Key: ELY-1572
> URL: https://issues.jboss.org/browse/ELY-1572
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Build
> Affects Versions: 1.3.0.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> As part of ELY-1523 japicmp was configured to force binary and source compatibility.
> By last discussion, only binary compatibility is required.
> {panel}
> *Honza Kalina* jaspicmp reports it as source incompatibility, not as binary incompatibility - so it maybe it is false positive, as I would say it should be source-compatible...
> *Darran Lofthouse* Binary is the only one we are really interested in, i.e. will an update to a later version of Elytron break something. Most of our backwards compatibility strategy is more about breaking things and upsetting people
> {panel}
> Also because of probably bug in japicmp, which causes adding method into interface, even through default implementation is provided, is reported as source compatibility issue. -> blocks adding IV into masked password in ELY-876
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month