April 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3732) upgrade core to depend on aesh 1.3

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3732?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-3732: ---------------------------------------------- in addition aesh-readline 1.7 and aesh-extensions 1.2 > upgrade core to depend on aesh 1.3 > ---------------------------------- > > Key: WFCORE-3732 > URL: https://issues.jboss.org/browse/WFCORE-3732 > Project: WildFly Core > Issue Type: Component Upgrade > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3732) upgrade core to depend on aesh 1.3

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3732?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-3732: ----------------------------------------- Summary: upgrade core to depend on aesh 1.3 (was: upgrade core to depend on aesh 1.2) > upgrade core to depend on aesh 1.3 > ---------------------------------- > > Key: WFCORE-3732 > URL: https://issues.jboss.org/browse/WFCORE-3732 > Project: WildFly Core > Issue Type: Component Upgrade > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 5 months

1
0
0 / 0

[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: --------------------------- Priority: Critical (was: Major) > 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 > 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"/> > >  > <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)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2266) RouterStubManager.run() endless reconnect loop burning a CPU

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2266?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2266: --------------------------- Fix Version/s: 4.0.12 > RouterStubManager.run() endless reconnect loop burning a CPU > ------------------------------------------------------------ > > Key: JGRP-2266 > URL: https://issues.jboss.org/browse/JGRP-2266 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.11 > Environment: Small cluster (~ 20 nodes), some nodes are connected through OpenVPN tunnels. MacOS and Linux nodes. > Reporter: Emmeran Seehuber > Assignee: Bela Ban > Fix For: 4.0.12 > > Attachments: cs_stack.xml > > > RouterStubManager.run() tries in a loop to reconnect all stubs currently not connected. When for whatever reason it is not possible to connect one of this stubs, the method spins in a endless loop and burns a CPU. > E.g. sometimes the VPN tunnel is down or one of the TCPGOSSIP hosts is down. > No idea if it is really required to loop here, but at least it should do some some Thread.yield() or or sleep() here. As this run() method is called periodically it should not be required to do a endless loop here, should it? Maybe only loop e.g. three times and then give up? > As the all nodes in the cluster are iMac workstations or special render Linux slaves, burning a CPU is very annoying. The CPU should rather be spend on the Blender render jobs or for the interactive work the people are doing on their iMacs. (JGroups is used here to distribute render jobs within the cluster) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2266) RouterStubManager.run() endless reconnect loop burning a CPU

by Emmeran Seehuber (JIRA)

Emmeran Seehuber created JGRP-2266: -------------------------------------- Summary: RouterStubManager.run() endless reconnect loop burning a CPU Key: JGRP-2266 URL: https://issues.jboss.org/browse/JGRP-2266 Project: JGroups Issue Type: Bug Affects Versions: 4.0.11 Environment: Small cluster (~ 20 nodes), some nodes are connected through OpenVPN tunnels. MacOS and Linux nodes. Reporter: Emmeran Seehuber Assignee: Bela Ban Attachments: cs_stack.xml RouterStubManager.run() tries in a loop to reconnect all stubs currently not connected. When for whatever reason it is not possible to connect one of this stubs, the method spins in a endless loop and burns a CPU. E.g. sometimes the VPN tunnel is down or one of the TCPGOSSIP hosts is down. No idea if it is really required to loop here, but at least it should do some some Thread.yield() or or sleep() here. As this run() method is called periodically it should not be required to do a endless loop here, should it? Maybe only loop e.g. three times and then give up? As the all nodes in the cluster are iMac workstations or special render Linux slaves, burning a CPU is very annoying. The CPU should rather be spend on the Blender render jobs or for the interactive work the people are doing on their iMacs. (JGroups is used here to distribute render jobs within the cluster) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3577) Add support for coloured output to CLI

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3577?page=com.atlassian.jira.plugi... ] Ingo Weiss updated WFCORE-3577: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/3232 (was: https://github.com/iweiss/wildfly-core/tree/WFCORE-3577) > Add support for coloured output to CLI > -------------------------------------- > > Key: WFCORE-3577 > URL: https://issues.jboss.org/browse/WFCORE-3577 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Affects Versions: 4.0.0.Alpha10 > Reporter: Ingo Weiss > Assignee: Jean-Francois Denise > > Add support to colour for CLI outputs -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10258) Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-10258?page=com.atlassian.jira.plugin... ] Lin Gao updated WFLY-10258: --------------------------- Labels: downstream_dependency (was: ) > Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew > --------------------------------------------------------------------------------------------- > > Key: WFLY-10258 > URL: https://issues.jboss.org/browse/WFLY-10258 > Project: WildFly > Issue Type: Bug > Components: EJB, Transactions > Affects Versions: 12.0.0.Final > Reporter: Jörg Bäsner > Labels: downstream_dependency > > Scenario: > - server-1 (intermediary) > -- Running standalone profile > -- Has a remote-outbound-connection pointing at server-2 through server-2's public IP address > -- Intermediary bean need to lookup the Target bean in server-2 and also inject the {{TransactionManager}} > -- Intermediary bean need to enlist a _dummy_ XAResource > - server-2 (target) > -- disable {{JBOSS-LOCAL-USER}} auth > -- Target bean needs to be annotated with {{@REQUIRES_NEW}} (important) > - Standalone EJB client invokes an intermediary bean server-1, which as a result invokes target bean on server-2. > The _dummy_ XAResource should log in the {{commit}} method whether one-phase optimization is being used like: > {code} > @Override > public void commit(Xid arg0, boolean onePhaseOptim) throws XAException { > logger.info("-- Committing in the client resource. One-phase optimisation is: " + onePhaseOptim + " --" > + (onePhaseOptim ? "" : " -> TWO-PHASE COMMIT !!!")); > } > {code} > In this scenario it is expected that the one-phase optimization is being used! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2506) Lexical scope for FEEL Function invocation

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-2506: -------------------------------------- Summary: Lexical scope for FEEL Function invocation Key: DROOLS-2506 URL: https://issues.jboss.org/browse/DROOLS-2506 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari A script like {code:java} { myimport : { f1 : function() \"Hi\", x1 : function(name) f1() + \" \" + name }, r1 : myimport.x1(\"John\") }.r {code} shoudl evaluate to "Hi John" but the invocation of "myimport.x1" is not being evaluated with the correct lexical scope -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2257) UDP#PacketReceiver stuck in busy loop when socket throws closed exception but socket is not closed

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2257?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2257: -------------------------------- So you're saying that the socket read throws a SocketClosedException, but Socket.isClosed() returns false? Hmm, is this a bug in the JVM? I don't see how I could fix this... > UDP#PacketReceiver stuck in busy loop when socket throws closed exception but socket is not closed > -------------------------------------------------------------------------------------------------- > > Key: JGRP-2257 > URL: https://issues.jboss.org/browse/JGRP-2257 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.12 > Environment: Windows Server 2016, 32GBytes memory running as a Hyper-V guest > java version "1.8.0_131" > Java(TM) SE Runtime Environment (build 1.8.0_131-b11) > Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode) > It was reported with just a single node running. > Reporter: Paul Illingworth > Assignee: Bela Ban > Fix For: 4.0.12 > > > I have a had a report of a scenario where it looks like the UDP#PacketReceiver is stuck spinning in a busy loop. The following is a snippet of the log file from the system in question. > {noformat} > 2018-03-16 14:05:43,273 SEVERE [] (214,unicast receiver,shared=udp) JGRP000190: failed receiving packet > java.net.SocketException: socket closed > at java.net.TwoStacksPlainDatagramSocketImpl.peekData(Native Method) > at java.net.DatagramSocket.receive(DatagramSocket.java:743) > at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:694) > at java.lang.Thread.run(Thread.java:748) > > 2018-03-16 14:05:43,273 SEVERE [] (214,unicast receiver,shared=udp) JGRP000190: failed receiving packet > java.net.SocketException: socket closed > at java.net.TwoStacksPlainDatagramSocketImpl.peekData(Native Method) > at java.net.DatagramSocket.receive(DatagramSocket.java:743) > at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:694) > at java.lang.Thread.run(Thread.java:748) > > 2018-03-16 14:05:43,273 SEVERE [] (214,unicast receiver,shared=udp) JGRP000190: failed receiving packet > java.net.SocketException: socket closed > at java.net.TwoStacksPlainDatagramSocketImpl.peekData(Native Method) > at java.net.DatagramSocket.receive(DatagramSocket.java:743) > at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:694) > at java.lang.Thread.run(Thread.java:748) > {noformat} > Looking at the code it looks like the call to receive a packet > {code:java} > receiver_socket.receive(packet); > {code} > results in an exception being thrown because the socket is closed but then when the exception is caught > {code:java} > if(receiver_socket.isClosed()) { > {code} > method is queried which says the socket has not been closed and the loop then continues for ever. > I guess this is related to JGRP-1669. To quote > _I hope there is no condition which causes the socket receive() to spit out endless exceptions while not being closed..._ -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9731) The fix for WFLY-4625 breaks PolicyContext("javax.security.auth.subject.container") in CXF web service with STS

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-9731?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-9731: ----------------------------------------------- Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1352418|https://bugzilla.redhat.com/show_bug.cgi?id=1352418] from ON_QA to VERIFIED > The fix for WFLY-4625 breaks PolicyContext("javax.security.auth.subject.container") in CXF web service with STS > --------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9731 > URL: https://issues.jboss.org/browse/WFLY-9731 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Petr Jurak > Assignee: Petr Jurak > > Web service with STS (Picketlink) returns wrong subject with PolicyContext("javax.security.auth.subject.container"). > It seems that configured login modules are not called since SecurityContext was created by SAML2Handler for the same security domain and are skipped because of WFLY-4625. > Reproducer is attached in BZ-1352418. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2018