April 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10304) JAX-WS 2.3 API update

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-10304?page=com.atlassian.jira.plugin... ] Alessio Soldano deleted WFLY-10304: ----------------------------------- > JAX-WS 2.3 API update > --------------------- > > Key: WFLY-10304 > URL: https://issues.jboss.org/browse/WFLY-10304 > Project: WildFly > Issue Type: Task > Reporter: Alessio Soldano > Assignee: Alessio Soldano > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-10304) JAX-WS 2.3 API update

by Alessio Soldano (JIRA)

Alessio Soldano created WFLY-10304: -------------------------------------- Summary: JAX-WS 2.3 API update Key: WFLY-10304 URL: https://issues.jboss.org/browse/WFLY-10304 Project: WildFly Issue Type: Task Components: Web Services Reporter: Alessio Soldano Assignee: Alessio Soldano -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-10285) Upgrade Weld to 3.0.4.Final and Weld API to 3.0.SP3

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/WFLY-10285?page=com.atlassian.jira.plugin... ] Matej Novotny updated WFLY-10285: --------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/11159 > Upgrade Weld to 3.0.4.Final and Weld API to 3.0.SP3 > --------------------------------------------------- > > Key: WFLY-10285 > URL: https://issues.jboss.org/browse/WFLY-10285 > Project: WildFly > Issue Type: Component Upgrade > Components: CDI / Weld > Reporter: Martin Kouba > Assignee: Matej Novotny > Fix For: 13.0.0.Beta1 > > > Also upgrade Weld API to 3.0.SP3. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-10303) Upgrade Weld to 3.0.4.Final and Weld API to 3.0.SP3

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/WFLY-10303?page=com.atlassian.jira.plugin... ] Matej Novotny closed WFLY-10303. -------------------------------- Resolution: Duplicate Issue Accidentally created a duplicate - see https://issues.jboss.org/browse/WFLY-10285 > Upgrade Weld to 3.0.4.Final and Weld API to 3.0.SP3 > --------------------------------------------------- > > Key: WFLY-10303 > URL: https://issues.jboss.org/browse/WFLY-10303 > Project: WildFly > Issue Type: Component Upgrade > Components: CDI / Weld > Affects Versions: 12.0.0.Final > Reporter: Matej Novotny > Assignee: Matej Novotny > > Weld 3.0.4.Final was released and along with it Weld API 3.0.SP3. > Here is release announcement [link|http://weld.cdi-spec.org/news/2018/04/26/weld-304Final/]. > This release should eliminate illegal access problems on JDK 10+ coming from Weld. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-10285) Upgrade Weld to 3.0.4.Final and Weld API to 3.0.SP3

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/WFLY-10285?page=com.atlassian.jira.plugin... ] Matej Novotny updated WFLY-10285: --------------------------------- Summary: Upgrade Weld to 3.0.4.Final and Weld API to 3.0.SP3 (was: Upgrade Weld to 3.0.4.Final) > Upgrade Weld to 3.0.4.Final and Weld API to 3.0.SP3 > --------------------------------------------------- > > Key: WFLY-10285 > URL: https://issues.jboss.org/browse/WFLY-10285 > Project: WildFly > Issue Type: Component Upgrade > Components: CDI / Weld > Reporter: Martin Kouba > Assignee: Matej Novotny > Fix For: 13.0.0.Beta1 > > > Also upgrade Weld API to 3.0.SP3. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-10303) Upgrade Weld to 3.0.4.Final and Weld API to 3.0.SP3

by Matej Novotny (JIRA)

Matej Novotny created WFLY-10303: ------------------------------------ Summary: Upgrade Weld to 3.0.4.Final and Weld API to 3.0.SP3 Key: WFLY-10303 URL: https://issues.jboss.org/browse/WFLY-10303 Project: WildFly Issue Type: Component Upgrade Components: CDI / Weld Affects Versions: 12.0.0.Final Reporter: Matej Novotny Assignee: Matej Novotny Weld 3.0.4.Final was released and along with it Weld API 3.0.SP3. Here is release announcement [link|http://weld.cdi-spec.org/news/2018/04/26/weld-304Final/]. This release should eliminate illegal access problems on JDK 10+ coming from Weld. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-9529) Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry

by Scott Van Wart (JIRA)

[ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.... ] Scott Van Wart commented on WFLY-9529: -------------------------------------- [~emmartins] Do you know what the status of this in wildfly 12 is? Can I use @Injected JMSContexts in CDI event observers? > Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry > --------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9529 > URL: https://issues.jboss.org/browse/WFLY-9529 > Project: WildFly > Issue Type: Bug > Components: JMS, Naming > Affects Versions: 10.1.0.Final, 11.0.0.Final > Environment: Running on Windows 10, Java 64-bit 1.8.0_131 > Reporter: Scott Van Wart > Assignee: Eduardo Martins > Labels: ActiveMQ, jms, transaction > Attachments: injected-jms.zip, injected-jms2.zip, wildfly-11-injected-jms.txt > > > If I try to use an @Injected JMSContext while executing within a background task (ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace. I've experienced this a number of times with Wildfly 10.1.0, including messages sent in Infinispan's expiry task thread. > My original workaround was to submit an additional task on a separate thread to send the message, then wait for it to complete. That seemed unreliable (sometimes it would still produce NameNotFoundException). I've resorted to creating my own JMSContext by using @Resource( lookup="java:/ConnectionFactory" ) and sending messages that way. Both workarounds prevent the message sending logic from participating in any ongoing transactions. > I'm also attaching a sample EAR project. It can be built with Maven. It creates a background task that waits 3 seconds and then tries to send a JMS message in a new transaction using an injected JMS context. I use the standalone-full.xml profile to run it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-10094) [Artemis 2.x upgrade] libAIO does not get loaded on RHEL 6 x86_64

by Clebert Suconic (JIRA)

[ https://issues.jboss.org/browse/WFLY-10094?page=com.atlassian.jira.plugin... ] Clebert Suconic commented on WFLY-10094: ---------------------------------------- We need to compile the library with RHEL6 and update it upstream. Do you have an environment where you can compile it.. and send a PR for the RHEL6 compilation upstream? > [Artemis 2.x upgrade] libAIO does not get loaded on RHEL 6 x86_64 > ----------------------------------------------------------------- > > Key: WFLY-10094 > URL: https://issues.jboss.org/browse/WFLY-10094 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > Priority: Blocker > Labels: activemq, feature-branch-blocker > > LibAIO does not get loaded on RHEL 6 x86_64: > {code} > [hudson@rhel6-large-2723 bin]$ sh standalone.sh -c standalone-full-ha.xml -Djboss.socket.binding.port-offset=1000 > ========================================================================= > JBoss Bootstrap Environment > JBOSS_HOME: /tmp/jboss-eap > JAVA: java > JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true > ========================================================================= > ... > 10:14:31,918 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-1) WFLYMSGAMQ0075: AIO wasn't located on this platform, it will fall back to using pure Java NIO. Your platform is Linux, install LibAIO to enable the AIO journal and achieve optimal performance. > 10:14:32,017 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 75) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/jboss-eap/standalone/data/activemq/journal,bindingsDirectory=/tmp/jboss-eap/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/jboss-eap/standalone/data/activemq/largemessages,pagingDirectory=/tmp/jboss-eap/standalone/data/activemq/paging) > 10:14:32,110 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 75) AMQ221013: Using NIO Journal > ... > {code} > libAIO in artemis journal module from WF branch. Not from Artemis 2.5.0.Final tag. > Wildfly: https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (06c878a313d3cad323889d017e60fd5533204d1a) > Artemis: upstreadm master (577b62d5210cdcc0f86ab9bb1b24e944c877dfe7) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-3666) Provide Elytron alternative to RoleMappingLoginModule

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3666?page=com.atlassian.jira.plugi... ] Martin Choma commented on WFCORE-3666: -------------------------------------- [~msvehla] Can you create EAP7 issue as we have Dev/QE/GSS agreement? > Provide Elytron alternative to RoleMappingLoginModule > ----------------------------------------------------- > > Key: WFCORE-3666 > URL: https://issues.jboss.org/browse/WFCORE-3666 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Affects Versions: 4.0.0.Final > Reporter: Martin Choma > > In picketbox there is RoleMappingLoginModule [1], which takes role as returned from authorization process and maps to different role. I thought something similar should be configurable with some of Elytron role-mappers. But looking into model/code, it is not obvious to me which of them can be used. I know custom role mapper can be still used, but I wonder if we really do not provide this common funcionality out of the box with Elytron. > Another workaround is to use direct roles from realm (e.g. LDAP ) in target (e.g. web.xml). But seems users tend to map IDM Roles to applicaiton roles. > [1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (SWSQE-148) Create Sikuli server environment on selenium server

by Jeeva Kandasamy (JIRA)

[ https://issues.jboss.org/browse/SWSQE-148?page=com.atlassian.jira.plugin.... ] Jeeva Kandasamy resolved SWSQE-148. ----------------------------------- Resolution: Done https://github.com/jkandasa/sekuli > Create Sikuli server environment on selenium server > --------------------------------------------------- > > Key: SWSQE-148 > URL: https://issues.jboss.org/browse/SWSQE-148 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Jeeva Kandasamy > Assignee: Jeeva Kandasamy > > For this task, we have to add Sikuli supported libraries on selenium docker -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2018