April 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3935) [DMN Designer] Data Types tab - Improve action buttons

by Elizabeth Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-3935?page=com.atlassian.jira.plugi... ] Elizabeth Clayton updated DROOLS-3935: -------------------------------------- Sprint: (was: 2019 Week 17-19) > [DMN Designer] Data Types tab - Improve action buttons > ------------------------------------------------------ > > Key: DROOLS-3935 > URL: https://issues.jboss.org/browse/DROOLS-3935 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Daniel José dos Santos > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: Screen Shot 2019-04-24 at 2.06.47 PM.png > > > In the Data Types list, the "Save" button must be changed to a PatternFly primary button (https://www.patternfly.org/v4/design-guidelines/usage-and-behavior/button...), and the "X" must be changed to PatternFly default button with the "Cancel" text. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4446) Migrate AbsolutePathService and RelativePathService to new MSC service builder API

by Richard Opalka (Jira)

Richard Opalka created WFCORE-4446: -------------------------------------- Summary: Migrate AbsolutePathService and RelativePathService to new MSC service builder API Key: WFCORE-4446 URL: https://issues.jboss.org/browse/WFCORE-4446 Project: WildFly Core Issue Type: Task Components: Server Reporter: Richard Opalka Assignee: Richard Opalka Fix For: 9.0.0.Beta4 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 4 months

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 Christian Zambrano (Jira)

[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ] Christian Zambrano commented on WFLY-11956: ------------------------------------------- One more thing I would like to make sure we all understand, is that the sequence of events on EAP 6(Jax-rs 1.1 and bean validation 1.0) is different and doesn't have this issue. Only mentioning this to provide context as to why we chose methods that start with 'get' > @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: Ronald Sigal > 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)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1797) Make the certificate authority used by a certificate-authority-account configurable

by Diana Vilkolakova (Jira)

Diana Vilkolakova created ELY-1797: -------------------------------------- Summary: Make the certificate authority used by a certificate-authority-account configurable Key: ELY-1797 URL: https://issues.jboss.org/browse/ELY-1797 Project: WildFly Elytron Issue Type: Feature Request Components: Certificate Authority Reporter: Diana Vilkolakova Currently, Let's Encrypt (https://acme-v02.api.letsencrypt.org/directory) is the only certificate authority that can be used by a certificate-authority-account. In the future, if/when other certificate authorities implement the server side of the ACME protocol, this will need to be configurable. In addition, making this configurable would also allow local Let's Encrypt server instances to be used for testing purposes. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1797) Make the certificate authority used by a certificate-authority-account configurable

by Diana Vilkolakova (Jira)

[ https://issues.jboss.org/browse/ELY-1797?page=com.atlassian.jira.plugin.s... ] Diana Vilkolakova reassigned ELY-1797: -------------------------------------- Assignee: Diana Vilkolakova > Make the certificate authority used by a certificate-authority-account configurable > ----------------------------------------------------------------------------------- > > Key: ELY-1797 > URL: https://issues.jboss.org/browse/ELY-1797 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Certificate Authority > Reporter: Diana Vilkolakova > Assignee: Diana Vilkolakova > Priority: Major > > Currently, Let's Encrypt (https://acme-v02.api.letsencrypt.org/directory) is the only certificate authority that can be used by a certificate-authority-account. In the future, if/when other certificate authorities implement the server side of the ACME protocol, this will need to be configurable. In addition, making this configurable would also allow local Let's Encrypt server instances to be used for testing purposes. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 4 months

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 Guillaume Smet (Jira)

[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ] Guillaume Smet commented on WFLY-11956: --------------------------------------- Hi Ron, Well, for the first one, you'll see that the HV part does not have the value, just the root object and the property name: it's Hibernate ORM doing the value resolution in the end. I asked on the hibernate-dev list if we could have a way to know if a class is potentially managed by ORM because it doesn't make sense to ask ORM if a property is loaded if the root object is not managed by ORM. The issue is that we are talking JPA here as the current model supports potentially having several persistence providers. About your getter question: Bean Validation really supposes that your objects are following the Java Beans specification. > @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: Ronald Sigal > 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)

5 years, 4 months

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 Christian Zambrano (Jira)

[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ] Christian Zambrano commented on WFLY-11956: ------------------------------------------- [~ron_sigal] [~gunnar.morling] To help other people(or myself) following the case here is the section of the spec quoted: JAX-RS implementations SHOULD use the following process to validate resource class instances after theyhave been instantiated: Phase 1 - Inject field values and initialize bean properties as described in Section 3.2. Phase 2 - Validate annotations on fields, property getters (if enabled) and the resource class. The order inwhich these validations are executed is implementation dependent. Phase 3 - Validate annotations on parameters passed to the resource method matched. Phase 4 - If no constraint violations found thus far, invoke resource method and validate returned value I don't think the spec forbids an implementation to perform phase 2 after the call to PostConstruct, so you are correct the current implementation is not wrong but I think it is hard to argue that it has undesirable side effects. Calling the PostConstruct before Phase 2 would still be in compliance with the spec and would better fit the sequence of events that are expected from CDI which is for the PostConstruct to be called after injections. > @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: Ronald Sigal > 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)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4445) Make the certificate authority used by a certificate-authority-account configurable

by Diana Vilkolakova (Jira)

[ https://issues.jboss.org/browse/WFCORE-4445?page=com.atlassian.jira.plugi... ] Diana Vilkolakova deleted WFCORE-4445: -------------------------------------- > Make the certificate authority used by a certificate-authority-account configurable > ----------------------------------------------------------------------------------- > > Key: WFCORE-4445 > URL: https://issues.jboss.org/browse/WFCORE-4445 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Diana Vilkolakova > Assignee: Diana Vilkolakova > Priority: Major > > Currently, Let's Encrypt (https://acme-v02.api.letsencrypt.org/directory) is the only certificate authority that can be used by a {{certificate-authority-account}}. In the future, if/when other certificate authorities implement the server side of the ACME protocol, this will need to be configurable. In addition, making this configurable would also allow local Let's Encrypt server instances to be used for testing purposes. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4445) Make the certificate authority used by a certificate-authority-account configurable

by Diana Vilkolakova (Jira)

Diana Vilkolakova created WFCORE-4445: ----------------------------------------- Summary: Make the certificate authority used by a certificate-authority-account configurable Key: WFCORE-4445 URL: https://issues.jboss.org/browse/WFCORE-4445 Project: WildFly Core Issue Type: Feature Request Components: Security Reporter: Diana Vilkolakova Assignee: Diana Vilkolakova Currently, Let's Encrypt (https://acme-v02.api.letsencrypt.org/directory) is the only certificate authority that can be used by a {{certificate-authority-account}}. In the future, if/when other certificate authorities implement the server side of the ACME protocol, this will need to be configurable. In addition, making this configurable would also allow local Let's Encrypt server instances to be used for testing purposes. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 4 months

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 updated WFLY-11891: -------------------------------- Fix Version/s: 17.0.0.Beta1 (was: No Release) > 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 > Fix For: 17.0.0.Beta1 > > 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)

5 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2019