[JBoss JIRA] (WFLY-11883) Incorrect product name used in readmes for ha-singleton-* QS
by Eduardo Martins (Jira)
[ https://issues.jboss.org/browse/WFLY-11883?page=com.atlassian.jira.plugin... ]
Eduardo Martins moved JBEAP-16582 to WFLY-11883:
------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-11883 (was: JBEAP-16582)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Documentation
Quickstarts
(was: Documentation)
(was: Quickstarts)
Affects Version/s: 16.0.0.Final
(was: 7.2.0.GA)
> Incorrect product name used in readmes for ha-singleton-* QS
> ------------------------------------------------------------
>
> Key: WFLY-11883
> URL: https://issues.jboss.org/browse/WFLY-11883
> Project: WildFly
> Issue Type: Bug
> Components: Documentation, Quickstarts
> Affects Versions: 16.0.0.Final
> Reporter: Eduardo Martins
> Assignee: Eduardo Martins
> Priority: Major
>
> The readmes say {{red_hat_jboss_enterprise_application_platform}} instead of {{Red Hat JBoss Enterprise Application Platform}} or simply {{JBoss EAP}}:
> * ha-singleton-service:
> ** For more information about clustered singleton services, see HA Singleton Service in the Development Guide for red_hat_jboss_enterprise_application_platform located on the Red Hat Customer Portal.
> * ha-singleton-deployment:
> ** For more information about singleton deployments, see HA Singleton Deployments in the Development Guide for red_hat_jboss_enterprise_application_platform located on the Red Hat Customer Portal.
> It's caused by incorrectly defined doc attribute {{DocInfoProductName}} in {{attributes.adoc}}:
> {code}
> :DocInfoProductName: red_hat_jboss_enterprise_application_platform
> :DocInfoProductNameURL: red_hat_jboss_enterprise_application_platform
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (DROOLS-3760) [DMN Designer] Enumeration constraint dialog doesn't scroll to latest entry
by Guilherme Carreiro (Jira)
[ https://issues.jboss.org/browse/DROOLS-3760?page=com.atlassian.jira.plugi... ]
Guilherme Carreiro reassigned DROOLS-3760:
------------------------------------------
Assignee: Guilherme Carreiro (was: Daniel José dos Santos)
> [DMN Designer] Enumeration constraint dialog doesn't scroll to latest entry
> ---------------------------------------------------------------------------
>
> Key: DROOLS-3760
> URL: https://issues.jboss.org/browse/DROOLS-3760
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.19.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Carreiro
> Priority: Minor
> Labels: drools-tools
> Attachments: Screenshot from 2019-03-12 09-53-39.png
>
>
> This issue was spotted during review of the DROOLS-3666 task, however not sure if it is related to changes introduced there.
> If user adds enumeration constraints and they do not fit the dialog size, there appears vertical scrollbar. However the scrollbar moves to the beginning of the list every time the add button is pressed. This forces user to scroll to the latest added entry every time the add button is pressed.
> We have already this functionality of scrolling to latest in the data types list view component - list of all declared data types.
> h3. Current state
> The attached picture show the state of dialog when new constraint was just added and the entries count doesn't fit the dialog size.
> h3. Expected state
> The scrollbar in the attached dialog is scrolled down.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (DROOLS-3760) [DMN Designer] Enumeration constraint dialog doesn't scroll to latest entry
by Guilherme Carreiro (Jira)
[ https://issues.jboss.org/browse/DROOLS-3760?page=com.atlassian.jira.plugi... ]
Guilherme Carreiro updated DROOLS-3760:
---------------------------------------
Story Points: 1
Sprint: 2019 Week 11-13
> [DMN Designer] Enumeration constraint dialog doesn't scroll to latest entry
> ---------------------------------------------------------------------------
>
> Key: DROOLS-3760
> URL: https://issues.jboss.org/browse/DROOLS-3760
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.19.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Carreiro
> Priority: Minor
> Labels: drools-tools
> Attachments: Screenshot from 2019-03-12 09-53-39.png
>
>
> This issue was spotted during review of the DROOLS-3666 task, however not sure if it is related to changes introduced there.
> If user adds enumeration constraints and they do not fit the dialog size, there appears vertical scrollbar. However the scrollbar moves to the beginning of the list every time the add button is pressed. This forces user to scroll to the latest added entry every time the add button is pressed.
> We have already this functionality of scrolling to latest in the data types list view component - list of all declared data types.
> h3. Current state
> The attached picture show the state of dialog when new constraint was just added and the entries count doesn't fit the dialog size.
> h3. Expected state
> The scrollbar in the attached dialog is scrolled down.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Laird Nelson (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Laird Nelson edited comment on WFLY-11858 at 3/20/19 4:20 PM:
--------------------------------------------------------------
Another possibility for a root cause: should the {{getBeanClass()}} method be overridden in the {{AbstractBean<InitialContext>}} subclass to return {{InitialContext.class}}? While reading http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#selection_ee and http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#inter_module_injection I am concerned that if {{getBeanClass()}} returns {{AbstractBean$1.class}} or something similar, as it would, Wildfly might decide that such a class is not visible in the OP's scenario.
was (Author: ljnelson):
Another possibility for a root cause: should the {{getBeanClass()}} method be overridden in {{JNDIBean}} to return the bean type supplied at construction time? While reading http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#selection_ee and http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#inter_module_injection I am concerned that if {{getBeanClass()}} returns {{AbstractBean$1.class}} or something similar, as it would for the bean that represents {{InitialContext}}, Wildfly might decide that such a class is not visible in the OP's scenario.
> [Wildfly16] CDI fails to inject InitialContext during startup
> -------------------------------------------------------------
>
> Key: WFLY-11858
> URL: https://issues.jboss.org/browse/WFLY-11858
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Transactions
> Affects Versions: 16.0.0.Final
> Reporter: Rakesh K. Cherukuri
> Assignee: Matej Novotny
> Priority: Major
> Attachments: stacktrace.log
>
>
> We are in the process of upgrading from 14.0.1.Final. While Wildfly 15.0.1 works fine, 16.0.0.Final is intermittently (3 out of 5 times) failing to start with following error
> _WELD-001334: Unsatisfied dependencies for type InitialContext with qualifiers_
> In our application, a bootstrap servlet startsup services (Stateless EJBs) during server startup. During this process the server fails to start with above error.
> Basically CDI is not able to find the appropriate InitialContext bean *intermittently*. This is not failing in our application code but in the wildfly libraries itself.
> Any pointers on this will be helpful. Don't want to end up with startup issues in stage/production :)
> Unfortunately my efforts to come up with a simplified maven module to showcase the error didn't succeed. So, please let me know if any further information is required and i will be glad to fill it in.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Tomasz Adamski (Jira)
[ https://issues.jboss.org/browse/WFLY-11566?page=com.atlassian.jira.plugin... ]
Tomasz Adamski commented on WFLY-11566:
---------------------------------------
[~ron_sigal] Could you please take a look at the failing test?
> ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
> ----------------------------------------------------------------------------------
>
> Key: WFLY-11566
> URL: https://issues.jboss.org/browse/WFLY-11566
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, EJB, REST
> Affects Versions: 14.0.0.Final, 15.0.1.Final
> Reporter: Alexander Wagner
> Assignee: Tomasz Adamski
> Priority: Critical
> Attachments: WFLY-11566-3.tar
>
>
> You got an exception if you call methods on JAX-RS endpoints which are also e.g. a stateless EJB and have Set or List as query parameters.
> As a workaround we use the "@Context UriInfo info" as parameter an read the parameter manually. As a downside this parameters are missing than in automated api generation with e.g. swagger. Without the @NotEmpty annotation it works fine. Without the generic type parameter ie just List it works fine. Making it a simple CDI bean makes it work fine.
> This issue is caused by [commit - WFLY-9628 Allow to switch to Hibernate Validator 6.0 / Bean Validation 2.0|https://github.com/wildfly/wildfly/commit/02f230d91f55f86ee6cadf53832...]
> Steps to reproduce:
> {code:java}
> @Stateless
> @Path("/")
> public class Resource {
> @POST
> @Path("put/list")
> @Consumes(MediaType.APPLICATION_JSON)
> public String putList(@NotEmpty List<String> a) {
> return "Hello bars " + a.stream().collect(Collectors.joining(", "));
> }
> }
> {code}
> {noformat}
> [mkopecky@dhcp-10-40-5-71 bin]$ curl -d '["a","b","c"]' -H "Content-Type: application/json" -X POST http://localhost:8080/jaxrs-wf/put/list
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> [mkopecky@dhcp-10-40-5-71 bin]$
> {noformat}
> {noformat}
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> at org.hibernate.validator.internal.metadata.aggregated.rule.OverridingMethodMustNotAlterParameterConstraints.apply(OverridingMethodMustNotAlterParameterConstraints.java:24)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.assertCorrectnessOfConfiguration(ExecutableMetaData.java:461)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:377)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BuilderDelegate.build(BeanMetaDataImpl.java:788)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BeanMetaDataBuilder.build(BeanMetaDataImpl.java:648)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.createBeanMetaData(BeanMetaDataManager.java:192)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.lambda$getBeanMetaData$0(BeanMetaDataManager.java:160)
> at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.getBeanMetaData(BeanMetaDataManager.java:159)
> at org.hibernate.validator.internal.engine.ValidationContext$ValidationContextBuilder.forValidateParameters(ValidationContext.java:619)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:254)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:224)
> at org.jboss.resteasy.plugins.validation.GeneralValidatorImpl.validateAllParameters(GeneralValidatorImpl.java:177)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:118)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Links:
> * [forum|https://developer.jboss.org/thread/278822]
> * WFLY-11566
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-11352) WildFly registers multiple distinct drivers for current MySQL driver jar
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11352?page=com.atlassian.jira.plugin... ]
James Perkins reopened WFLY-11352:
----------------------------------
I'm reopening this as https://github.com/wildfly/wildfly/pull/12160 is still open and we may want that in.
> WildFly registers multiple distinct drivers for current MySQL driver jar
> ------------------------------------------------------------------------
>
> Key: WFLY-11352
> URL: https://issues.jboss.org/browse/WFLY-11352
> Project: WildFly
> Issue Type: Enhancement
> Components: JCA
> Affects Versions: 14.0.1.Final
> Reporter: Stephen Fikes
> Assignee: Lin Gao
> Priority: Minor
> Fix For: 16.0.0.Beta1, 16.0.0.Final, 17.0.0.Beta1
>
>
> When MySQL drivers are deployed as jars (rather than [modules|https://issues.jboss.org/browse/WFLY-3218]), multiple named drivers:
> ... INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) WFLYJCA0005: Deploying non-JDBC-compliant driver class com.mysql.jdbc.Driver (version 5.1)
> ... INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) WFLYJCA0005: Deploying non-JDBC-compliant driver class com.mysql.fabric.jdbc.FabricMySQLDriver (version 5.1)
> ... INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0018: Started Driver service with driver-name = mysql-connector-java-5.1.44-bin.jar_com.mysql.jdbc.Driver_5_1
> ... INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0018: Started Driver service with driver-name = mysql-connector-java-5.1.44-bin.jar_com.mysql.fabric.jdbc.FabricMySQLDriver_5_1
> Consequently, references to the driver by name (such as the below) fail to resolve
> {code}
> <datasource jndi-name="java:jboss/datasources/mysql" pool-name="MySQL" enabled="true">
> ...
> <driver>mysql-connector-java-5.1.44-bin.jar</driver>
> ...
> </datasource>
> {code}
> This issue was [already resolved|https://issues.jboss.org/browse/WFLY-3218] for the case where a module was used to deploy the driver.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Laird Nelson (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Laird Nelson edited comment on WFLY-11858 at 3/20/19 3:22 PM:
--------------------------------------------------------------
Another possibility for a root cause: should the {{getBeanClass()}} method be overridden in {{JNDIBean}} to return the bean type supplied at construction time? While reading http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#selection_ee and http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#inter_module_injection I am concerned that if {{getBeanClass()}} returns {{AbstractBean$1.class}} or something similar, as it would for the bean that represents {{InitialContext}}, Wildfly might decide that such a class is not visible in the OP's scenario.
was (Author: ljnelson):
Another possibility for a root cause: should the {{getBeanClass()}} method be overridden in {{JNDIBean}} to return the bean type supplied at construction time? While reading http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#selection_ee I am concerned that if {{getBeanClass()}} returns {{AbstractBean$1.class}} or something similar, as it would for the bean that represents {{InitialContext}}, Wildfly might decide that such a class is not visible in the OP's scenario.
> [Wildfly16] CDI fails to inject InitialContext during startup
> -------------------------------------------------------------
>
> Key: WFLY-11858
> URL: https://issues.jboss.org/browse/WFLY-11858
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Transactions
> Affects Versions: 16.0.0.Final
> Reporter: Rakesh K. Cherukuri
> Assignee: Matej Novotny
> Priority: Major
> Attachments: stacktrace.log
>
>
> We are in the process of upgrading from 14.0.1.Final. While Wildfly 15.0.1 works fine, 16.0.0.Final is intermittently (3 out of 5 times) failing to start with following error
> _WELD-001334: Unsatisfied dependencies for type InitialContext with qualifiers_
> In our application, a bootstrap servlet startsup services (Stateless EJBs) during server startup. During this process the server fails to start with above error.
> Basically CDI is not able to find the appropriate InitialContext bean *intermittently*. This is not failing in our application code but in the wildfly libraries itself.
> Any pointers on this will be helpful. Don't want to end up with startup issues in stage/production :)
> Unfortunately my efforts to come up with a simplified maven module to showcase the error didn't succeed. So, please let me know if any further information is required and i will be glad to fill it in.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Laird Nelson (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Laird Nelson commented on WFLY-11858:
-------------------------------------
Another possibility for a root cause: should the {{getBeanClass()}} method be overridden in {{JNDIBean}} to return the bean type supplied at construction time? While reading http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#selection_ee I am concerned that if {{getBeanClass()}} returns {{AbstractBean$1.class}} or something similar, as it would for the bean that represents {{InitialContext}}, Wildfly might decide that such a class is not visible in the OP's scenario.
> [Wildfly16] CDI fails to inject InitialContext during startup
> -------------------------------------------------------------
>
> Key: WFLY-11858
> URL: https://issues.jboss.org/browse/WFLY-11858
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Transactions
> Affects Versions: 16.0.0.Final
> Reporter: Rakesh K. Cherukuri
> Assignee: Matej Novotny
> Priority: Major
> Attachments: stacktrace.log
>
>
> We are in the process of upgrading from 14.0.1.Final. While Wildfly 15.0.1 works fine, 16.0.0.Final is intermittently (3 out of 5 times) failing to start with following error
> _WELD-001334: Unsatisfied dependencies for type InitialContext with qualifiers_
> In our application, a bootstrap servlet startsup services (Stateless EJBs) during server startup. During this process the server fails to start with above error.
> Basically CDI is not able to find the appropriate InitialContext bean *intermittently*. This is not failing in our application code but in the wildfly libraries itself.
> Any pointers on this will be helpful. Don't want to end up with startup issues in stage/production :)
> Unfortunately my efforts to come up with a simplified maven module to showcase the error didn't succeed. So, please let me know if any further information is required and i will be glad to fill it in.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months