April 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2338) RpcDispatcher: non-reflective method invocations

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2338?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2338. ---------------------------- Resolution: Done > RpcDispatcher: non-reflective method invocations > ------------------------------------------------ > > Key: JGRP-2338 > URL: https://issues.jboss.org/browse/JGRP-2338 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.0 > > > Running a native image produced by the GraalVM AOT (ahead-of-time) compiler prohibits the use of Java Reflection. > However, RpcDispatcher uses {{java.lang.reflect.Method}} to invoke remote method calls. > h4. Goal > Provide a mode (in {{MethodCall}}) which doesn't require a {{MethodLookup}} table but rather takes user-provided code (e.g. a lambda) to find and invoke the correct method. > This could be done by introducing an additional mode in {{MethodCall}} based on {{ID}} which calls the (user-provided) lambda to invoke a method. The lambda would read the arguments and invoke the method based on the received ID, then return the result. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-684) UI Automation - Routing Wizard

by Hayk Hovsepyan (Jira)

[ https://issues.jboss.org/browse/SWSQE-684?page=com.atlassian.jira.plugin.... ] Hayk Hovsepyan commented on SWSQE-684: -------------------------------------- first PR merged https://github.com/Kiali-QE/kiali-qe-python/pull/159 > UI Automation - Routing Wizard > ------------------------------ > > Key: SWSQE-684 > URL: https://issues.jboss.org/browse/SWSQE-684 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > > Need to automate Service Detail's Routing Wizard. > At least the default options to create. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1761) Unicode normalization in SASL client breaks some non-ASCII passwords

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1761?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1761: ---------------------------------- Fix Version/s: 1.9.0.CR3 > Unicode normalization in SASL client breaks some non-ASCII passwords > -------------------------------------------------------------------- > > Key: ELY-1761 > URL: https://issues.jboss.org/browse/ELY-1761 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.7.0.Final > Reporter: Philippe Marschall > Priority: Major > Fix For: 1.9.0.CR3 > > > We have users that use U+00A8 ([diaeresis|https://en.wikipedia.org/wiki/Diaeresis_(diacritic)]) as an Active Directory password. They can not log in using the Elytron LDAP realm. Here's the sequence of events: > * PlainSaslClient.evaluateChallenge calls StringPrep.encode with the profile StringPrep.PROFILE_SASL_STORED https://github.com/wildfly-security/wildfly-elytron/blob/fd74e43caf3e7019... > * StringPrep.PROFILE_SASL_STORED ors PROFILE_SASL_QUERY which ors NORMALIZE_KC https://github.com/wildfly-security/wildfly-elytron/blob/fd74e43caf3e7019... > * StringPrep.encode then normalises using NFKC which replaces U+00A8 with U+0020 U+0308 https://github.com/wildfly-security/wildfly-elytron/blob/fd74e43caf3e7019... > * Active Directory rejects the login > We would be wiling to work on a patch but we need some guidance on the desired solution. A simple solution would be a new profile in StringPrep that doesn't normalize and is used for passwords. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1761) Unicode normalization in SASL client breaks some non-ASCII passwords

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1761?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse reassigned ELY-1761: ------------------------------------- Assignee: Darran Lofthouse > Unicode normalization in SASL client breaks some non-ASCII passwords > -------------------------------------------------------------------- > > Key: ELY-1761 > URL: https://issues.jboss.org/browse/ELY-1761 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.7.0.Final > Reporter: Philippe Marschall > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.9.0.CR3 > > > We have users that use U+00A8 ([diaeresis|https://en.wikipedia.org/wiki/Diaeresis_(diacritic)]) as an Active Directory password. They can not log in using the Elytron LDAP realm. Here's the sequence of events: > * PlainSaslClient.evaluateChallenge calls StringPrep.encode with the profile StringPrep.PROFILE_SASL_STORED https://github.com/wildfly-security/wildfly-elytron/blob/fd74e43caf3e7019... > * StringPrep.PROFILE_SASL_STORED ors PROFILE_SASL_QUERY which ors NORMALIZE_KC https://github.com/wildfly-security/wildfly-elytron/blob/fd74e43caf3e7019... > * StringPrep.encode then normalises using NFKC which replaces U+00A8 with U+0020 U+0308 https://github.com/wildfly-security/wildfly-elytron/blob/fd74e43caf3e7019... > * Active Directory rejects the login > We would be wiling to work on a patch but we need some guidance on the desired solution. A simple solution would be a new profile in StringPrep that doesn't normalize and is used for passwords. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-11956: ----------------------------------------- [~mkouba] -- [~guillaume.smet] was having trouble accessing JIRA but posted this input in Zulip: Guillaume Smet: the gist of the issue is - I think - that the rest endpoint has a getter name Guillaume Smet: HV considers it is a property and tries to validate as it is validating the bean is properly configured Guillaume Smet: just removing the get prefix should fix the issue if my assumption is right [~jbaesner] ^^^ is a possible workaround. > @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method > ---------------------------------------------------------------------------------------------------------- > > Key: WFLY-11956 > URL: https://issues.jboss.org/browse/WFLY-11956 > Project: WildFly > Issue Type: Bug > Components: Bean Validation, REST > Affects Versions: 16.0.0.Final > Reporter: Joerg Baesner > Assignee: Alessio Soldano > Priority: Major > Attachments: logging.txt, playground.zip > > > Having a bean class with {{@ApplicationScoped}}, which has a {{@PostConstruct}} and is implementing the following _Interface_: > {code} > @Path("/validated") > public interface ValidatedJaxRsInterface { > > @GET > @Valid > @Produces(MediaType.APPLICATION_JSON) > GreetingModel getHelloGreeting(); > } > {code} > will result in calling the {{getHelloGreeting}} method of the implementation class twice *_before_* the {{@PostConstruct}} is getting executed. > This can be reproduced with the attached reproducer application... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method

by Martin Kouba (Jira)

[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ] Martin Kouba commented on WFLY-11956: ------------------------------------- I don't understand why any {{InjectionTarget}} method should trigger method-level validation? Or even call the method? Method-level validation should be performed when a method is invoked. Or am I missing something? [~guillaume.smet] do you have an idea? > @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method > ---------------------------------------------------------------------------------------------------------- > > Key: WFLY-11956 > URL: https://issues.jboss.org/browse/WFLY-11956 > Project: WildFly > Issue Type: Bug > Components: Bean Validation, REST > Affects Versions: 16.0.0.Final > Reporter: Joerg Baesner > Assignee: Alessio Soldano > Priority: Major > Attachments: logging.txt, playground.zip > > > Having a bean class with {{@ApplicationScoped}}, which has a {{@PostConstruct}} and is implementing the following _Interface_: > {code} > @Path("/validated") > public interface ValidatedJaxRsInterface { > > @GET > @Valid > @Produces(MediaType.APPLICATION_JSON) > GreetingModel getHelloGreeting(); > } > {code} > will result in calling the {{getHelloGreeting}} method of the implementation class twice *_before_* the {{@PostConstruct}} is getting executed. > This can be reproduced with the attached reproducer application... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-998) Upgrade Undertow to 2.0.19.Final

by Darran Lofthouse (Jira)

Darran Lofthouse created SECURITY-998: ----------------------------------------- Summary: Upgrade Undertow to 2.0.19.Final Key: SECURITY-998 URL: https://issues.jboss.org/browse/SECURITY-998 Project: PicketBox Issue Type: Component Upgrade Components: Negotiation Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: Negotiation_3_0_6_CR1 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11891) Add tests that enable JPA entity class bytecode enhancement

by Scott Marlow (Jira)

[ https://issues.jboss.org/browse/WFLY-11891?page=com.atlassian.jira.plugin... ] Scott Marlow reassigned WFLY-11891: ----------------------------------- Assignee: Scott Marlow (was: Gail Badner) > Add tests that enable JPA entity class bytecode enhancement > ----------------------------------------------------------- > > Key: WFLY-11891 > URL: https://issues.jboss.org/browse/WFLY-11891 > Project: WildFly > Issue Type: Enhancement > Components: JPA / Hibernate > Affects Versions: 16.0.0.Final > Reporter: Scott Marlow > Assignee: Scott Marlow > Priority: Minor > Attachments: bytebuddy.log, javassist.log > > > Pick a few unit tests and add the following settings to enable [entity bytecode enhancement|http://docs.jboss.org/hibernate/orm/5.3/userguide/html_single...]: > {code} > <property name="hibernate.enhancer.enableDirtyTracking" value="true"/> > <property name="hibernate.enhancer.enableLazyInitialization" value="true"/> > <property name="hibernate.enhancer.enableAssociationManagement" value="true"/> > {code} > Steps to reproduce: > * Build WildFly > * cd testsuite/integration/basic > * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.transaction.TransactionTestCase > * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.hibernate.management.ManagementTestCase > * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.entitylistener.EntityListenersTestCase > * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase > Note that the org.jboss.as.test.integration.jpa.transaction.TransactionTestCase test should pass since javassist is specified in the persistence.xml but that seems to be ignored (we still get the ByteBuddy failure). > To workaround failures, prestart wildfly via: ./standalone.sh -Dhibernate.bytecode.provider=javassist and then run tests. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-3770) Fix generic type retrieval inside SetPropertyHeaderCommand

by Gabriele Cardosi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3770?page=com.atlassian.jira.plugi... ] Gabriele Cardosi closed DROOLS-3770. ------------------------------------ Resolution: Done Fixed with other PR > Fix generic type retrieval inside SetPropertyHeaderCommand > ---------------------------------------------------------- > > Key: DROOLS-3770 > URL: https://issues.jboss.org/browse/DROOLS-3770 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: ScenarioSimulation > Attachments: dmn-map.dmn > > > The property editing information for a given column (included the DOMELEmentFactory) are set inside SetPropertyHeaderColumn. > If the property is a collection, its generic type is retrieved with informations from the context. > Currently, this mechanism uses the "steps" stored inside "elements", that point to full path of the property (and a mapped entry must exists). > This is broken for top-level collection because are mapped in a different way, so a compatible method for different situations must be implemented -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method

by Matěj Novotný (Jira)

[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ] Matěj Novotný commented on WFLY-11956: -------------------------------------- I took a glance at this (as a CDI guy, with resteasy and validator and I am greenhorn so mind that please). Looking at what jaxrs does, there is a wrapper for CDI's {{InjectionTarget}} - that's the {{JaxrsInjectionTarget}} Brian mentioned earlier. Behind the scenes, it enriches the invocation of {{inject()}} that CDI performs with jaxrs property injection and finally with validation. Since {{InjectionTarget}} also has {{postConstruct()}} method, the validation could theoretically be moved there - I did a dirty check with this and it worked for me (for the test application). Notably this works even if the class itself does not use any {{@PostConstruct}}, the method on {{InjectionTarget}} will be invoked all the same. Not a clue what else it can possibly break though ;-) Nonetheless, none of the above explains why hibernate validator calls the method *twice* which it IMO shouldn't. It does so from [these two subsequent lines|https://github.com/hibernate/hibernate-validator/blob/6.0.15.Final/...] - the if check and the following line both end up with a reflective method invocation. I suppose this could be done once and the result stored if it's needed for several separate validations? > @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method > ---------------------------------------------------------------------------------------------------------- > > Key: WFLY-11956 > URL: https://issues.jboss.org/browse/WFLY-11956 > Project: WildFly > Issue Type: Bug > Components: Bean Validation, REST > Affects Versions: 16.0.0.Final > Reporter: Joerg Baesner > Assignee: Alessio Soldano > Priority: Major > Attachments: logging.txt, playground.zip > > > Having a bean class with {{@ApplicationScoped}}, which has a {{@PostConstruct}} and is implementing the following _Interface_: > {code} > @Path("/validated") > public interface ValidatedJaxRsInterface { > > @GET > @Valid > @Produces(MediaType.APPLICATION_JSON) > GreetingModel getHelloGreeting(); > } > {code} > will result in calling the {{getHelloGreeting}} method of the implementation class twice *_before_* the {{@PostConstruct}} is getting executed. > This can be reproduced with the attached reproducer application... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

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 2019