December 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4947) Upgrade to Undertow 1.1.8.Final

by SATISH POKALWAR (JIRA)

[ https://issues.jboss.org/browse/WFLY-4947?page=com.atlassian.jira.plugin.... ] SATISH POKALWAR commented on WFLY-4947: --------------------------------------- Hi Team , Is it possible for URL re-writing through standalone-full.xml file like we used to do in jboss 6.4 > Upgrade to Undertow 1.1.8.Final > ------------------------------- > > Key: WFLY-4947 > URL: https://issues.jboss.org/browse/WFLY-4947 > Project: WildFly > Issue Type: Component Upgrade > Components: Web (Undertow) > Reporter: Jason Greene > Assignee: Stuart Douglas > Fix For: 8.2.1.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1448) API Compatibility for org.wildfly.security.mechanism.MechanismUtil

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1448?page=com.atlassian.jira.plugin.s... ] Jan Kalina commented on ELY-1448: --------------------------------- The API breaking is already handled by ELY-1452 - this issue should aim the class deprecating/moving into private package. > API Compatibility for org.wildfly.security.mechanism.MechanismUtil > ------------------------------------------------------------------ > > Key: ELY-1448 > URL: https://issues.jboss.org/browse/ELY-1448 > Project: WildFly Elytron > Issue Type: Bug > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Blocker > Fix For: 1.2.0.Beta11 > > > Backwards compatibility has been broken on the public handleCallbacks methods so this needs to be fixed. > However this class should not really be a public API, it has been picked up in the package as we have the AuthenticationMechanismException which does need to be public. > The entire class should be deprecated and the impl moved to a private package. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-728) The map backing SimpleMapBackedSecurityRealm should be an identity map not a password map.

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-728?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-728: -------------------------------- So the realm should be backed by {{Map<String, SimpleMapRealmIdentity>}} instead of {{Map<String, SimpleRealmEntry>}} and creating identities on obtaining - what is the point? The realm can be used without stored credentials already now, or not? > The map backing SimpleMapBackedSecurityRealm should be an identity map not a password map. > ------------------------------------------------------------------------------------------ > > Key: ELY-728 > URL: https://issues.jboss.org/browse/ELY-728 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI, Realms > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.2.0.Beta12 > > > This realm is useful in cases where we need an identity to exist where the mechanism has performed validation without requiring access to credentials. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9509) Default SFSB Lifecycle methods transaction attribute causing warnings

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-9509?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-9509: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1508105|https://bugzilla.redhat.com/show_bug.cgi?id=1508105] from POST to MODIFIED > Default SFSB Lifecycle methods transaction attribute causing warnings > --------------------------------------------------------------------- > > Key: WFLY-9509 > URL: https://issues.jboss.org/browse/WFLY-9509 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 11.0.0.Final > Reporter: Brad Maxwell > Assignee: Brad Maxwell > Fix For: 12.0.0.Alpha1 > > Attachments: warning-reproducer.zip > > > EJB 2 deployment that does not specify transaction attribute for lifecycle methods such as: ejbActivate, ejbRemove, ejbPassivate are logging this warning. > JBAS014279: Invalid transaction attribute type REQUIRED on SFSB lifecyle method Method ejbRemove(), valid types are REQUIRES_NEW and NOT_SUPPORTED. Method will be treated as NOT_SUPPORTED. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2162) Error evaluating constraint

by Herve Remisio (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2162?page=com.atlassian.jira.plugi... ] Herve Remisio closed DROOLS-2162. --------------------------------- Release Notes Text: The issue was happening because we need to check if the attribute is NULL first. Maybe the exception should be more clear. That would help to understand that the issue is a simple NPE. Resolution: Rejected > Error evaluating constraint > --------------------------- > > Key: DROOLS-2162 > URL: https://issues.jboss.org/browse/DROOLS-2162 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.4.1.Final > Reporter: Herve Remisio > Assignee: Mario Fusco > Priority: Blocker > Attachments: 2017-12-04_12-33-29.png > > > We detected a very strange behavior when processing Rules that contain expressions like "...startsWith(..". > !2017-12-04_12-33-29.png|thumbnail! > Sometimes this error disappears when we simply re-upload the Rule file and it gets recompiled. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9592) Arrays in Method Parameters are causing EJBAccessException for @PermitAll Methods

by Marcus Handte (JIRA)

[ https://issues.jboss.org/browse/WFLY-9592?page=com.atlassian.jira.plugin.... ] Marcus Handte commented on WFLY-9592: ------------------------------------- Ok, I have done some more testing with Wildfly-11.0.0.Final and again with Wildfly-10.1.0.Final just to double check that I am not making this up. You were right, Wildfly-11.0.0.Final does not have the problem with arrays anymore. On Wildfly-10.1.0.Final I am certain that the problem is solely caused by having an array in the parameter list of an accessible (and @PermitAll) session bean method: java.lang.AssertionError: Should not receive exception. expected null, but was:<javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public com.maptology.api.user.User com.maptology.service.session.UserSessionBean.registerUser(com.maptology.api.user.UserRegistration,com.maptology.api.access.Roles[],long) throws com.maptology.service.entity.EntityConflictException of bean: UserSessionBean is not allowed> at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotNull(Assert.java:755) at org.junit.Assert.assertNull(Assert.java:737) at com.maptology.service.test.session.UserSessionTest.testRegisterAndEmailVerify(UserSessionTest.java:119) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) If I change Roles[] to List<Roles>, everything works as expected (meaning that I do not get an EJBAccessException anymore9. > Arrays in Method Parameters are causing EJBAccessException for @PermitAll Methods > --------------------------------------------------------------------------------- > > Key: WFLY-9592 > URL: https://issues.jboss.org/browse/WFLY-9592 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.1.0.Final > Environment: Wildfly 10.1.0.Final in an Arquillian Managed Container Test > Reporter: Marcus Handte > Priority: Minor > > EJB methods with array parameters are causing EJBAccessExceptions when they are annotated with @PermitAll. This bug seemed to be present in 8.0.0.Alpha2 and was fixed (see WFLY-1658). But it seems to be present again in 10.1.0.Final. > For my own use case, this is not a problem since I can simply change the method signatures to use lists instead of arrays. However, I can imagine that this could be a more significant problem for people trying to run existing code that they do not want to (or cannot) touch. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3446) Upgrade JBoss Modules to 1.6.2.Final

by David Lloyd (JIRA)

David Lloyd created WFCORE-3446: ----------------------------------- Summary: Upgrade JBoss Modules to 1.6.2.Final Key: WFCORE-3446 URL: https://issues.jboss.org/browse/WFCORE-3446 Project: WildFly Core Issue Type: Component Upgrade Components: Modules Reporter: David Lloyd Assignee: David Lloyd Fix For: 3.0.2.Final, 4.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9592) Arrays in Method Parameters are causing EJBAccessException for @PermitAll Methods

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-9592?page=com.atlassian.jira.plugin.... ] David Lloyd reopened WFLY-9592: ------------------------------- [~ctomc], I do not believe that this code is part of or is affected by Elytron. I think that this regression was possibly re-introduced here: https://github.com/dmlloyd/wildfly/commit/d7675fb0b19d3d22978e79954f441ee... This commit was merged before the 10.0.0.Beta1 tag. I think the better way to handle this is to say: would it be possible to give this a try on WildFly 11 to ensure that it is still valid? > Arrays in Method Parameters are causing EJBAccessException for @PermitAll Methods > --------------------------------------------------------------------------------- > > Key: WFLY-9592 > URL: https://issues.jboss.org/browse/WFLY-9592 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.1.0.Final > Environment: Wildfly 10.1.0.Final in an Arquillian Managed Container Test > Reporter: Marcus Handte > Priority: Minor > > EJB methods with array parameters are causing EJBAccessExceptions when they are annotated with @PermitAll. This bug seemed to be present in 8.0.0.Alpha2 and was fixed (see WFLY-1658). But it seems to be present again in 10.1.0.Final. > For my own use case, this is not a problem since I can simply change the method signatures to use lists instead of arrays. However, I can imagine that this could be a more significant problem for people trying to run existing code that they do not want to (or cannot) touch. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2136) Remove not used mvn dependencies

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2136?page=com.atlassian.jira.plugi... ] Jozef Marko closed DROOLS-2136. ------------------------------- Resolution: Rejected > Remove not used mvn dependencies > -------------------------------- > > Key: DROOLS-2136 > URL: https://issues.jboss.org/browse/DROOLS-2136 > Project: Drools > Issue Type: Task > Affects Versions: 7.4.1.Final > Reporter: Jozef Marko > Assignee: Jozef Marko > > In the drools-wb repository, remove all mvn dependencies that > {code:mvn} > mvn dependency:analyze > {code} > marks as declared but not used -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2007) [Test Scenario] Upgrade UI to gwt-bootstrap-3 components

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2007?page=com.atlassian.jira.plugi... ] Jozef Marko reopened DROOLS-2007: --------------------------------- > [Test Scenario] Upgrade UI to gwt-bootstrap-3 components > -------------------------------------------------------- > > Key: DROOLS-2007 > URL: https://issues.jboss.org/browse/DROOLS-2007 > Project: Drools > Issue Type: Enhancement > Components: Test Scenarios Editor > Affects Versions: 7.2.0.Final > Reporter: Jozef Marko > Assignee: Jozef Marko > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

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 December 2017