[JBoss JIRA] (WFLY-11893) Core test shared classes should be loaded
by Panagiotis Sotiropoulos (Jira)
[ https://issues.jboss.org/browse/WFLY-11893?page=com.atlassian.jira.plugin... ]
Panagiotis Sotiropoulos moved JBEAP-16590 to WFLY-11893:
--------------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-11893 (was: JBEAP-16590)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Test Suite
(was: Test Suite)
> Core test shared classes should be loaded
> ------------------------------------------
>
> Key: WFLY-11893
> URL: https://issues.jboss.org/browse/WFLY-11893
> Project: WildFly
> Issue Type: Task
> Components: Test Suite
> Reporter: Panagiotis Sotiropoulos
> Assignee: Panagiotis Sotiropoulos
> Priority: Major
>
> Core test shared classes should be loaded with EAT tests ...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka commented on WFLY-11858:
----------------------------------------
[~rakcheru] great, thank you. If you have some troubles with installing the new version of narayana to WFLY, let me know. The summary of possible ways how to do so is available e.g. her https://developer.jboss.org/wiki/BuildingNarayanaAndUpdatingWildFlyModules
> [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, 1 month
[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Rakesh K. Cherukuri (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Rakesh K. Cherukuri commented on WFLY-11858:
--------------------------------------------
[~ochaloup] Sure. Will try the fix and get back.
> [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, 1 month
[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka commented on WFLY-11858:
----------------------------------------
[~mkouba][~manovotn] the issue should be solved at the [~ljnelson]'s PR https://github.com/jbosstm/narayana/pull/1403/ (https://github.com/jbosstm/narayana/pull/1403/files#diff-b03d2da401b2b1c3...) where the `new InitialContext()` is used instead of `CDI.current()` as it was discussed here.
[~rakcheru] do you think you would be able to test the fix with your reproducer?
> [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, 1 month
[JBoss JIRA] (JGRP-2332) Port of JGroups to Quarkus
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2332?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2332:
--------------------------------
So I guess you mean that log4j2 is used at compile time (in a static block) to create the loggers? I used log4j2, because it was used as an example in the GraalVM website.
> Port of JGroups to Quarkus
> --------------------------
>
> Key: JGRP-2332
> URL: https://issues.jboss.org/browse/JGRP-2332
> Project: JGroups
> Issue Type: Patch
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.0
>
>
> Port JGroups to Quarkus [1].
> This is a quick and dirty port, to see what needs to be done.
> The goal is to identify changes which can be ported back to JGroups proper to make this port as easy as possible.
> Example: since JMX is not supported, separate JMX into a set of interfaces and 2 implementations: the default impl which is used when JGroups runs on a regular JVM, and another one used when run on GraalVM.
> This is currently scheduled for 4.x, but may as well end up being done in 5.x
> [1] https://quarkus.io
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFCORE-4381) Intermittent failures of ReadOnlyModeTestCase.testConfigurationNotUpdated
by Brian Stansberry (Jira)
Brian Stansberry created WFCORE-4381:
----------------------------------------
Summary: Intermittent failures of ReadOnlyModeTestCase.testConfigurationNotUpdated
Key: WFCORE-4381
URL: https://issues.jboss.org/browse/WFCORE-4381
Project: WildFly Core
Issue Type: Task
Components: Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
https://ci.wildfly.org/project.html?tab=testDetails&testNameId=-274259225...
Failures are mostly
java.lang.IllegalStateException: Function 'org.jboss.as.test.integration.domain.ReadOnlyModeTestCase$$Lambda$210/0x000000010031e840@787a4519' failed to process in 30 s, caused: "WFLYCTL0379: System boot is in process; execution of remote management operations is not currently available"
30s seems too short since the point of the test isn't to check boot speed.
I'm not clear why this needs custom logic for checking start vs using DomainLifecycleUtil.awaitServers(). The less of that kind of thing the better. Also, the domainClient.getServerStatuses() approach has a race risk, as the master can be started but the slave not connected yet, so you get a successful but meaningless result from the master.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11717) Illegal reflective access - org.jboss.invocation.proxy.AbstractProxyFactory
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11717?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-11717:
-----------------------------------------
Notes to self:
AbstractProxyFactory.setupCachedProxyFields() is iterating over 'cachedMethods' and setting the Method to be accessible. So. java.lang.Object.clone() is being made accessible, hence the WARN.
The 'cachedMethods' are all methods that have been in 'methodIdentifiers'.
The 'methodIdentifiers' collection is updated only by the 'loadMethodIdentifier' method., which is only called by ProxyMethodBodyCreator.overrideMethod(ClassMethod method, Method superclassMethod).
That is called by the two AbstractSubclassFactory.overrideMethod methods.
The overrideMethod(ClassMethod method, MethodIdentifier identifier, MethodBodyCreator creator) variant passes null as the Method arg, and null != Object.clone() so that path is not relevant.
The overrideMethod(Method method, MethodIdentifier identifier, MethodBodyCreator creator) is used as follows:
{code}
Method
overrideMethod(Method, MethodIdentifier, MethodBodyCreator)
Found usages (7 usages found)
Unclassified usage (7 usages found)
Maven: org.jboss.invocation:jboss-invocation:1.5.2.Final (7 usages found)
org.jboss.invocation.proxy (7 usages found)
AbstractSubclassFactory (7 usages found)
overridePublicMethods(MethodBodyCreator) (1 usage found)
184 overrideMethod(method, identifier, override);
overrideAllMethods(MethodBodyCreator) (1 usage found)
224 overrideMethod(method, identifier, override);
overrideEquals(MethodBodyCreator) (1 usage found)
254 return overrideMethod(equals, MethodIdentifier.getIdentifierForMethod(equals), creator);
overrideHashcode(MethodBodyCreator) (1 usage found)
281 return overrideMethod(hashCode, MethodIdentifier.getIdentifierForMethod(hashCode), creator);
overrideToString(MethodBodyCreator) (1 usage found)
307 return overrideMethod(toString, MethodIdentifier.getIdentifierForMethod(toString), creator);
overrideFinalize(MethodBodyCreator) (1 usage found)
332 return overrideMethod(finalize, MethodIdentifier.getIdentifierForMethod(finalize), creator);
addInterface(MethodBodyCreator, Class<?>) (1 usage found)
385 overrideMethod(method, MethodIdentifier.getIdentifierForMethod(method), override);
{code}
overridePublicMethods won't handle Object.clone() because it is not public.
overrideAllMethods specifically skips processing of Object.class
overrideEquals|Hashcode|ToString|Finalize won't handle Object.clone() because it's not Equals|Hashcode|ToString|Finalize.
addInterface shouldn't be handling Object.clone because Object is not an interface.
It's possible addInterface is involved, since the param there is Class<?> and Object.class fits that. So perhaps some check for an interface is missing. Looking at usage of ProxyConfiguration.addAdditionalInterface() I see DefaultComponentViewConfigurator.configure, but it is doing a isInterface() check. And then there is JBossMessageEndpointFactory which takes final Class<?> messageListenerInterface. Tracing back where that param comes from it goes pretty far but it seems possible the app could set it to Object.class.
And we have.....
{code}
@Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME)
public @interface MessageDriven
{
String name() default "";
Class messageListenerInterface() default Object.class;
ActivationConfigProperty[] activationConfig() default {};
String mappedName() default "";
String description() default "";
}
{code}
So maybe that's it?
> Illegal reflective access - org.jboss.invocation.proxy.AbstractProxyFactory
> ---------------------------------------------------------------------------
>
> Key: WFLY-11717
> URL: https://issues.jboss.org/browse/WFLY-11717
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 15.0.1.Final
> Reporter: Kris-Gerhard Aabrams
> Assignee: Brian Stansberry
> Priority: Major
> Labels: Java11
>
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.jboss.invocation.proxy.AbstractProxyFactory$1 (jar:file:/opt/jboss/wildfly/modules/system/layers/base/org/jboss/invocation/main/jboss-invocation-1.5.1.Final.jar!/) to method java.lang.Object.clone()
> WARNING: Please consider reporting this to the maintainers of org.jboss.invocation.proxy.AbstractProxyFactory$1
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (JGRP-2332) Port of JGroups to Quarkus
by Sanne Grinovero (Jira)
[ https://issues.jboss.org/browse/JGRP-2332?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on JGRP-2332:
---------------------------------------
{{log42.xml}} is the perfect example of what kind of resource _should not_ be included into a native image. One (typically) doesn't need any resource at all: static configuration should be applied to the libraries upfront, so that constant folding and dead code elimination can do a better job.
> Port of JGroups to Quarkus
> --------------------------
>
> Key: JGRP-2332
> URL: https://issues.jboss.org/browse/JGRP-2332
> Project: JGroups
> Issue Type: Patch
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.0
>
>
> Port JGroups to Quarkus [1].
> This is a quick and dirty port, to see what needs to be done.
> The goal is to identify changes which can be ported back to JGroups proper to make this port as easy as possible.
> Example: since JMX is not supported, separate JMX into a set of interfaces and 2 implementations: the default impl which is used when JGroups runs on a regular JVM, and another one used when run on GraalVM.
> This is currently scheduled for 4.x, but may as well end up being done in 5.x
> [1] https://quarkus.io
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[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 commented on WFLY-11891:
-------------------------------------
I attached bytebuddy.log which wasn't that interesting as deployment fails while ByteBuddy is trying to load "org.jboss.as.ejb3.SerializationProxyHackImplementation"
> 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
> 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)
7 years, 1 month