[JBoss JIRA] (WFLY-13498) @ApplicationScoped Bean Not Eagerly Instantiated on Wildfly 16
by Matěj Novotný (Jira)
[ https://issues.redhat.com/browse/WFLY-13498?page=com.atlassian.jira.plugi... ]
Matěj Novotný commented on WFLY-13498:
--------------------------------------
So after looking a bit more closely to the code, you would be getting only the {{ServletContext}} event in this case (you still get notified even for {{Object}} since {{ServletContext}} is assignable to it).
I am looking into Weld code to see if I can spot a place where this could be happening. I would assume it needs to be sometime when we have complete information about modules, but haven't yet created all beans in them. But with no way to reproduce/verify it, I am pretty much shooting blind.
BTW are you seeing this failure intermittently or is it consistent with your app?
Another path worth exploring is whether there is any synchronization between bootstrap of Weld and that of Servlet within WFLY. Though I don't suppose there is since each one can exist without the other in some use cases.
> @ApplicationScoped Bean Not Eagerly Instantiated on Wildfly 16
> --------------------------------------------------------------
>
> Key: WFLY-13498
> URL: https://issues.redhat.com/browse/WFLY-13498
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 16.0.0.Final
> Reporter: Fearghal O Maolcatha
> Assignee: Matěj Novotný
> Priority: Major
>
> I have an @ApplicationScoped bean that I want to be instantiated on application startup (see sample code below). I've registered for the servlet context initialization event but the init method is never invoked. The FactoryLocator is contained in a jar within my war's WEB-INF/lib directory. This same code was working on Wildfly 9 but no longer works after upgrading to Wildfly 16.
> {code:java}
> import javax.enterprise.context.ApplicationScoped;
> import javax.enterprise.context.Initialized;
> import javax.enterprise.event.Observes;
> import javax.servlet.ServletContext;
> @ApplicationScoped
> public class FactoryLocator {
> public FactoryLocator() {
> System.out.println("In the constructor.........................");
> }
> private void init(@Observes @Initialized(ApplicationScoped.class) ServletContext sc) {
> System.out.println("Invoking the event observer method..................");
> }
> }
> {code}
> One workaround I discovered was to extract the contents of the jars in my war's WEB-INF/lib/ directory to my war's WEB-INF/classes directory. When I did this my FactorLocator bean was instantiated successfully. I'd prefer not to have to do this.
> After debugging through the war's deployment, I noticed that the ServletContext is initialized before all the beans in the war's lib directory are processed (org.jboss.weld.bootstrap.BeanDeploymentModules:processBeanDeployments). The war's module is not aware of all observers until all the beans are processed. However, the ServletContextEvent is fired before all the observers are known.
> Should this happen that ServletContext is created before all observers are known about? I've debugged one of the Wildfly QuickStart applications and the ServletContext isn't created until all bean deployments are processed and the code below is executed successfully. Is the order in which this happens supposed to be guaranteed?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-10173) EjbInvocationStatisticsTestCase fails on Windows: wait-time=0
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-10173?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-10173:
-----------------------------------
I'm running on Mac, and this test has been failing on Linux only in WildFly CI. I'll try to rework the test and update the PR.
> EjbInvocationStatisticsTestCase fails on Windows: wait-time=0
> -------------------------------------------------------------
>
> Key: WFLY-10173
> URL: https://issues.redhat.com/browse/WFLY-10173
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 12.0.0.Final
> Reporter: Jan Kalina
> Assignee: Cheng Fang
> Priority: Major
> Fix For: 20.0.0.Final
>
>
> Sometime, when running EjbInvocationStatisticsTestCase on Windows, assertion fails, as wait-time is 0 (verified it is 0 by adding debug message).
> For me it fails allTests in most of cases, but when running test standalone, it fails only in 1 of 4 cases.
> I suppose it is because of too short sleep in AbstractManagedBean. (in test is called 4 times, each invocation include 50ms sleep, so I consider probable the wait-time is 0 - need to use longer sleeps to fulfill the test)
> {code}
> [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.078 s <<< FAILURE! - in org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase
> [ERROR] testSingletonWaitTime(org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase) Time elapsed: 0.438 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.validateWaitTimeStatistic(EjbInvocationStatisticsTestCase.java:179)
> at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.testSingletonWaitTime(EjbInvocationStatisticsTestCase.java:148)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:379)
> ...
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-10173) EjbInvocationStatisticsTestCase fails on Windows: wait-time=0
by Lukas Vydra (Jira)
[ https://issues.redhat.com/browse/WFLY-10173?page=com.atlassian.jira.plugi... ]
Lukas Vydra commented on WFLY-10173:
------------------------------------
I'm still able to reproduce it even with you PR, I have been trying similar way, but test were still failing intermittently. Are you reproducing it on Windows?
> EjbInvocationStatisticsTestCase fails on Windows: wait-time=0
> -------------------------------------------------------------
>
> Key: WFLY-10173
> URL: https://issues.redhat.com/browse/WFLY-10173
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 12.0.0.Final
> Reporter: Jan Kalina
> Assignee: Cheng Fang
> Priority: Major
> Fix For: 20.0.0.Final
>
>
> Sometime, when running EjbInvocationStatisticsTestCase on Windows, assertion fails, as wait-time is 0 (verified it is 0 by adding debug message).
> For me it fails allTests in most of cases, but when running test standalone, it fails only in 1 of 4 cases.
> I suppose it is because of too short sleep in AbstractManagedBean. (in test is called 4 times, each invocation include 50ms sleep, so I consider probable the wait-time is 0 - need to use longer sleeps to fulfill the test)
> {code}
> [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.078 s <<< FAILURE! - in org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase
> [ERROR] testSingletonWaitTime(org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase) Time elapsed: 0.438 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.validateWaitTimeStatistic(EjbInvocationStatisticsTestCase.java:179)
> at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.testSingletonWaitTime(EjbInvocationStatisticsTestCase.java:148)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:379)
> ...
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5358) Add a way to define ResourceType inside kiebase
by Gabriele Cardosi (Jira)
Gabriele Cardosi created DROOLS-5358:
----------------------------------------
Summary: Add a way to define ResourceType inside kiebase
Key: DROOLS-5358
URL: https://issues.redhat.com/browse/DROOLS-5358
Project: Drools
Issue Type: Task
Reporter: Gabriele Cardosi
Assignee: Mario Fusco
Step to reproduce
1) create a project with multiple pmml files, each in its own package (eg. resources/package_name/file.pmml)
2) create a kmodule xml and define one kiebase for each package
3) compile the kjar
4) in the kjar the files/classes are all in the proper place (i.e. in the expected package)
5) add the kjar in a new project
6) in the new project invoke
KieServices.get().newKieClasspathContainer().getKieBase(kbaseName);
The jar packages are inside the kieBase.getPackages(), but they are not marked as "PMMLType" packages - so it is necessary to invoke the (PMML)AssemblerService to wrap the content of the (jar) packages inside correct PMMLType packages and put them in the knowledge base
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFCORE-4976) Where ModelControllerClient is initialised in process with CBH AuthenticationConfiguration takes priority.
by Ilia Vassilev (Jira)
[ https://issues.redhat.com/browse/WFCORE-4976?page=com.atlassian.jira.plug... ]
Ilia Vassilev updated WFCORE-4976:
----------------------------------
Labels: downstream_dependency (was: )
> Where ModelControllerClient is initialised in process with CBH AuthenticationConfiguration takes priority.
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4976
> URL: https://issues.redhat.com/browse/WFCORE-4976
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Labels: downstream_dependency
> Fix For: 12.0.0.Beta4
>
>
> In ProtocolConnectionUtils we have the following code to pass in the provided CallbackHanldler: -
> {code:java}
> if (handler != null) {
> mergedConfiguration = mergedConfiguration.useCallbackHandler(handler, DEFAULT_CALLBACK_KINDS);
> }
> {code}
> However the AuthenticationClient performs the following sanitation of the specified KINDS: -
> {code:java}
> case SET_USER_CB_KINDS:
> // SANITAZE on above content
> if (this.principal != null) {
> sanitazeOnMutation(SET_PRINCIPAL);
> }
> if (this.credentialSource != null) {
> sanitazeOnMutation(SET_CRED_SOURCE);
> }
> if (this.setRealm != null) {
> sanitazeOnMutation(SET_REALM);
> }
> if (this.parameterSpecs != null) {
> sanitazeOnMutation(SET_PARAM_SPECS);
> }
> if (this.keyManagerFactory != null) {
> sanitazeOnMutation(SET_KEY_MGR_FAC);
> }
> break;
> {code}
> Before passing in the CallbackHandler and specifying which KINDS is applies to the ProtocolConnectionUtils call should first remove the duplicates from the configuration.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-10173) EjbInvocationStatisticsTestCase fails on Windows: wait-time=0
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-10173?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-10173:
-----------------------------------
I was able to reproduce it about 1 out of 5 times running {{org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase}}. After the fix in my PR (extending the sleep time in the singleton busiess method to 1000 ms), I no longer see this failure in many runs.
I think the problem with the test was test singleton method sleeps for 50 ms, and the test client submits 4 tasks to a thread pool to invoke this singleton business method concurrently. If the first request gets the singleton instance and the rest 3 are forced to wait, then the theoretic test result will be 150 ms.
But the scheduling of the client-side thread pool is undeterministic. It may submit invocation tasks one by one, or after some pause. So it's possible when a request comes in, the singleton bean instance may already be free, hence 0 wait-time. When wait happens at the client side, there is no or less wait for the singleton bean.
> EjbInvocationStatisticsTestCase fails on Windows: wait-time=0
> -------------------------------------------------------------
>
> Key: WFLY-10173
> URL: https://issues.redhat.com/browse/WFLY-10173
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 12.0.0.Final
> Reporter: Jan Kalina
> Assignee: Cheng Fang
> Priority: Major
> Fix For: 20.0.0.Final
>
>
> Sometime, when running EjbInvocationStatisticsTestCase on Windows, assertion fails, as wait-time is 0 (verified it is 0 by adding debug message).
> For me it fails allTests in most of cases, but when running test standalone, it fails only in 1 of 4 cases.
> I suppose it is because of too short sleep in AbstractManagedBean. (in test is called 4 times, each invocation include 50ms sleep, so I consider probable the wait-time is 0 - need to use longer sleeps to fulfill the test)
> {code}
> [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.078 s <<< FAILURE! - in org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase
> [ERROR] testSingletonWaitTime(org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase) Time elapsed: 0.438 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.validateWaitTimeStatistic(EjbInvocationStatisticsTestCase.java:179)
> at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.testSingletonWaitTime(EjbInvocationStatisticsTestCase.java:148)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:379)
> ...
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFCORE-4977) (7.3.z) Where ModelControllerClient is initialised in process with CBH AuthenticationConfiguration takes priority.
by Ilia Vassilev (Jira)
Ilia Vassilev created WFCORE-4977:
-------------------------------------
Summary: (7.3.z) Where ModelControllerClient is initialised in process with CBH AuthenticationConfiguration takes priority.
Key: WFCORE-4977
URL: https://issues.redhat.com/browse/WFCORE-4977
Project: WildFly Core
Issue Type: Bug
Components: Management, Security
Reporter: Ilia Vassilev
Assignee: Darran Lofthouse
Fix For: 12.0.0.Beta4
In ProtocolConnectionUtils we have the following code to pass in the provided CallbackHanldler: -
{code:java}
if (handler != null) {
mergedConfiguration = mergedConfiguration.useCallbackHandler(handler, DEFAULT_CALLBACK_KINDS);
}
{code}
However the AuthenticationClient performs the following sanitation of the specified KINDS: -
{code:java}
case SET_USER_CB_KINDS:
// SANITAZE on above content
if (this.principal != null) {
sanitazeOnMutation(SET_PRINCIPAL);
}
if (this.credentialSource != null) {
sanitazeOnMutation(SET_CRED_SOURCE);
}
if (this.setRealm != null) {
sanitazeOnMutation(SET_REALM);
}
if (this.parameterSpecs != null) {
sanitazeOnMutation(SET_PARAM_SPECS);
}
if (this.keyManagerFactory != null) {
sanitazeOnMutation(SET_KEY_MGR_FAC);
}
break;
{code}
Before passing in the CallbackHandler and specifying which KINDS is applies to the ProtocolConnectionUtils call should first remove the duplicates from the configuration.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13504) XSiteSimpleTestCase should use separate cache-container/cache
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-13504:
-----------------------------------
Summary: XSiteSimpleTestCase should use separate cache-container/cache
Key: WFLY-13504
URL: https://issues.redhat.com/browse/WFLY-13504
Project: WildFly
Issue Type: Task
Components: Clustering
Affects Versions: 20.0.0.Beta1
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Currently, this test uses the same cache container as used for web failover tests. Changing this test to use a distinct container and cache should help eliminate issues resulting from artifacts (e.g. cache entries) left over from previous tests.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month