[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Matej Novotny (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Matej Novotny updated WFLY-11858:
---------------------------------
Component/s: Transactions
> [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 Matej Novotny (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Matej Novotny edited comment on WFLY-11858 at 3/18/19 4:27 AM:
---------------------------------------------------------------
Hi [~rakcheru]
Can you please draft what does your application look like? Are we talking WAR or EAR?
What do your beans looks like and what functionality they use to trigger this behaviour? What interceptors you have there? Any transactional behaviour (see below)?
I know you are saying that the error comes up in WFLY libraries but I suppose that's still triggered by something in your code because otherwise this would show up in many tests WFLY has.
[~ochaloup] I suspect Narayana's deps here. In the stacktrace, the actual bean that tries to grab {{InitialContext}} is [{{JNDIBean}}|https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/JNDIBean.java#L68]. I am guessing that based on this log line:
bq. {{at org.jboss.jts//com.arjuna.ats.jta.cdi.JNDIBean.create(JNDIBean.java:68)}}
Might be something to do with how WFLY services boot up or rather in what order? Hard to tell without reproducer...
was (Author: manovotn):
Hi [~rakcheru]
Can you please draft what does your application look like? Are we talking WAR or EAR?
What do your beans looks like and what functionality they use to trigger this behaviour? What interceptors you have there? Any transactional behaviour (see below)?
I know you are saying that the error comes up in WFLY libraries but I suppose that's still triggered by something in your code because otherwise this would show up in many tests WFLY has.
[~ochaloup] I suspect Narayana's deps here. In the stacktrace, the actual bean that tries to grab {{InitialContext}} is [{{JNDIBean}}|https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/JNDIBean.java#L68]. I am guessing that based on this log line:
bq. {{at org.jboss.jts//com.arjuna.ats.jta.cdi.JNDIBean.create(JNDIBean.java:68)}}
> [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
> 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 Matej Novotny (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Matej Novotny commented on WFLY-11858:
--------------------------------------
Hi [~rakcheru]
Can you please draft what does your application look like? Are we talking WAR or EAR?
What do your beans looks like and what functionality they use to trigger this behaviour? What interceptors you have there? Any transactional behaviour (see below)?
I know you are saying that the error comes up in WFLY libraries but I suppose that's still triggered by something in your code because otherwise this would show up in many tests WFLY has.
[~ochaloup] I suspect Narayana's deps here. In the stacktrace, the actual bean that tries to grab {{InitialContext}} is [{{JNDIBean}}|https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/JNDIBean.java#L68]. I am guessing that based on this log line:
bq. {{at org.jboss.jts//com.arjuna.ats.jta.cdi.JNDIBean.create(JNDIBean.java:68)}}
> [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
> 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 Matej Novotny (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Matej Novotny updated WFLY-11858:
---------------------------------
Priority: Major (was: Blocker)
> [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
> 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] (DROOLS-3715) Zipkiemodule nullpointerexception
by Tibor Zimányi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3715?page=com.atlassian.jira.plugi... ]
Tibor Zimányi commented on DROOLS-3715:
---------------------------------------
[~lukaszkrot] could you please try with the latest master? I fixed the path for now here [1]. You need to rebuild the Drools repository to get the new jars. The fix is in drools-compiler module. I will leave the issue open for now to get a confirmation from you, that it is fixed also for your case.
[1] https://github.com/kiegroup/drools/pull/2282
> Zipkiemodule nullpointerexception
> ---------------------------------
>
> Key: DROOLS-3715
> URL: https://issues.jboss.org/browse/DROOLS-3715
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.16.0.Final, 7.17.0.Final
> Reporter: Łukasz Szmolke
> Assignee: Tibor Zimányi
> Priority: Major
>
> o During ZipKieModule loading in “org.drools.compiler.kie.builder.impl.ZipKieModule:142” nullpointerexception is thrown:
>
> urlPath = urlPath.substring( urlPath.lastIndexOf( '!' ) + 1 );
> ArrayList<ZipEntry> entries = new ArrayList<>();
> // read jar file from uber-jar
> InputStream in = this.getClass().getResourceAsStream(urlPath); // nullpointerexception
>
> For example full UrlPath on windows to internal .jar is:
> C:\Users\xbbnv0c\IdeaProjects\ais-data-exchange\data-exchange-app\target\data-exchange-app-1.0.1-SNAPSHOT.jar!\BOOT-INF\lib\data-exchange-brms-1.0.1-SNAPSHOT.jar
> So the result of this first line will be:
> \BOOT-INF\lib\data-exchange-brms-1.0.1-SNAPSHOT.jar
> It will be perfect, but during accessing internal resource file separator should be “/” not “\”. So InputStream in = null.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-11565) WildFly Server Adds Transfer Encoding Chunk Header to the HttpResponse with status code 204
by jaikiran pai (Jira)
[ https://issues.jboss.org/browse/WFLY-11565?page=com.atlassian.jira.plugin... ]
jaikiran pai commented on WFLY-11565:
-------------------------------------
FWIW - Like I noted way back in this JIRA, there's no development happening on WildFly community 9.x edition. Even if it was a bug in that version, I don't see a release happening with a fix for the issue. You will have to really test your application against WildFly recently released version and see if it's reproducible there. Whatever other issues that you run into while porting the application to that newer version will have to be addressed separately.
If you do need timely and more ETA based responses, JBoss EAP https://developers.redhat.com/products/eap/overview/ is what you will have to buy a subscription for. WildFly community versions are volunteer driven and although you will receive help on issues you run into, it's mostly volunteer driven and depends on the time and efforts that the community can spare.
> WildFly Server Adds Transfer Encoding Chunk Header to the HttpResponse with status code 204
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-11565
> URL: https://issues.jboss.org/browse/WFLY-11565
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 9.0.0.Final
> Reporter: Deepak Sahu
> Assignee: Bartosz Baranowski
> Priority: Major
> Attachments: API.war
>
>
> I am using WildFly Server 9.0.0 Final, Javax ws, Jersey for developing Rest APIs. For all the responses whose httpStatus code is 204, the wildfly server adds Transfer encoding Chunked in the response header, which is not correct as per the Rest Standards. Because of this behavior some of the RestAPI clients hang, as they keep waiting for the response (which is not at all there).
> To verify the issue, I tried the same with Springboot instead of deploying the war in WildFly and the Response Header was not added with Transfer Encoding Chuncked.
> Let me know if some other information is required to fix this issue, if this is already fixed is there any patch for this issue.
--
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:
---------------------------------------
I was able to eliminate the exception above by changing the way the EJB proxy is generated. Specifically, I propagated method signature information in jboss-classfilewriter project (as in attached PR).
[~mkopecky] Could you please double check that it fixes the problem in your reproducer as well?
> 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-10057) EJB subsystem configure max threads and core threads independently
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-10057?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-10057:
-----------------------------------------
I want this handled as its own RFE. EAP7-488 is very broadly scoped, is partially done, other parts perhaps will not be done for a long time, and David Lloyd is no longer actively involved. Further work related to it should be handled individually.
> EJB subsystem configure max threads and core threads independently
> ------------------------------------------------------------------
>
> Key: WFLY-10057
> URL: https://issues.jboss.org/browse/WFLY-10057
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 12.0.0.Final
> Reporter: Richard Janík
> Priority: Major
>
> EJB3 subsystem currently only allows setting the {{max-threads}}, not {{core-threads}}.
> {noformat}
> [standalone@localhost:9990 /] /subsystem=ejb3/thread-pool=default:write-attribute(name=
> keepalive-time max-threads thread-factory
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-10255) Swagger Integration does not honor JAXB @XmlTransient annotation (and possibly more)
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-10255?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-10255:
-----------------------------------------
I'm not clear on how this is a WIldFly issue. AFAIK we don't do anything related to Swagger.
> Swagger Integration does not honor JAXB @XmlTransient annotation (and possibly more)
> ------------------------------------------------------------------------------------
>
> Key: WFLY-10255
> URL: https://issues.jboss.org/browse/WFLY-10255
> Project: WildFly
> Issue Type: Bug
> Components: JAXR
> Affects Versions: 12.0.0.Final
> Reporter: Jonathan Fisher
> Assignee: Kurt Stam
> Priority: Major
>
> Swagger does not honor JAXB annotations. If you mark a field on an Object as @XmlTransient, it will not be rendered in the XML or JSON output to the client. However, if will still be shown in the swagger.json. If you annotate the field with @JsonIgnore (jackson annotation), it will be omitted from the swagger.json as expected.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months