[JBoss JIRA] (WFCORE-4993) Organize feature pack code to facilitate separate EE 8 and EE 9 variants
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-4993?page=com.atlassian.jira.plug... ]
Brian Stansberry updated WFCORE-4993:
-------------------------------------
Description:
Separate feature pack code for EE 8 API modules and other modules we may not want in a EE 9 feature pack from the others.
See if the maven dependency set from those two sections can be used by both the legacy feature pack and the galleon feature pack, thus eliminating the duplication of dependency declaration we currently have.
License.xml generation will likely require https://github.com/wildfly/maven-plugins/issues/10 as the split would mean the input would be split as well.
> Organize feature pack code to facilitate separate EE 8 and EE 9 variants
> ------------------------------------------------------------------------
>
> Key: WFCORE-4993
> URL: https://issues.redhat.com/browse/WFCORE-4993
> Project: WildFly Core
> Issue Type: Task
> Components: Build System
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
> Fix For: 13.0.0.Beta1
>
>
> Separate feature pack code for EE 8 API modules and other modules we may not want in a EE 9 feature pack from the others.
> See if the maven dependency set from those two sections can be used by both the legacy feature pack and the galleon feature pack, thus eliminating the duplication of dependency declaration we currently have.
> License.xml generation will likely require https://github.com/wildfly/maven-plugins/issues/10 as the split would mean the input would be split as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[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 updated WFLY-10173:
------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/13314, https://github.com/wildfly/wildfly/pull/13346 (was: https://github.com/wildfly/wildfly/pull/13314)
> 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)
5 years, 11 months
[JBoss JIRA] (WFLY-13566) Ensure that Jandex indexes are released from JPA deployment memory after deployment completes
by Scott Marlow (Jira)
[ https://issues.redhat.com/browse/WFLY-13566?page=com.atlassian.jira.plugi... ]
Scott Marlow updated WFLY-13566:
--------------------------------
Fix Version/s: 21.0.0.Beta1
> Ensure that Jandex indexes are released from JPA deployment memory after deployment completes
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-13566
> URL: https://issues.redhat.com/browse/WFLY-13566
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: JBoss AS7 7.2.0.Final
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> org.jboss.as.jpa.service.PersistenceUnitServiceImpl#start() needs to always call pu.setAnnotationIndex(null) to clear the deployment reference to the Jandex Indexes.
> Currently without the fix, the Jandex Index will be released at application undeployment time. With the fix, the Jandex Index memory will be released after application deployment is complete. Note that the Jandex Index contains metadata for the application deployment classes and are not needed after deployment is complete.
> Note that this problem shouldn't occur when persistence.xml contains:
> {code}
> <property name="wildfly.jpa.twophasebootstrap" value="false"/>
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months