[JBoss JIRA] (WFLY-11870) abstract classes with @EJB annotation included in libraries will cause deployment failures
by Wolf-Dieter Fink (Jira)
Wolf-Dieter Fink created WFLY-11870:
---------------------------------------
Summary: abstract classes with @EJB annotation included in libraries will cause deployment failures
Key: WFLY-11870
URL: https://issues.jboss.org/browse/WFLY-11870
Project: WildFly
Issue Type: Bug
Components: EJB, Server
Reporter: Wolf-Dieter Fink
Assignee: Brian Stansberry
Attachments: ReproducerInjection.zip
If an archive include libraries with interfaces and abstract classes the deployment will fail if there are annotations for injection like @EJB.
Only if the injected EJB is available within the deployed file (or any other deployment) it is possible to deploy it.
As the abstract class can not cause any instance the failure does not make sense.
Also former versions are deploying the same file correct and work fine.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3780) DMN DT Analysis report warn for HitPolicy First
by Matteo Mortari (Jira)
Matteo Mortari created DROOLS-3780:
--------------------------------------
Summary: DMN DT Analysis report warn for HitPolicy First
Key: DROOLS-3780
URL: https://issues.jboss.org/browse/DROOLS-3780
Project: Drools
Issue Type: Feature Request
Components: dmn engine
Reporter: Matteo Mortari
Assignee: Matteo Mortari
{quote}"First" hit policy decision tables are not considered good practice because they do not offer a clear overview of the decision logic
{quote}
(quoted from: Decision Model and Notation specification)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11446) Bring consistency to use of TransactionSynchronizationRegistry in WildFly
by Tom Jenkinson (Jira)
[ https://issues.jboss.org/browse/WFLY-11446?page=com.atlassian.jira.plugin... ]
Tom Jenkinson reassigned WFLY-11446:
------------------------------------
Assignee: Ondra Chaloupka (was: Tom Jenkinson)
> Bring consistency to use of TransactionSynchronizationRegistry in WildFly
> -------------------------------------------------------------------------
>
> Key: WFLY-11446
> URL: https://issues.jboss.org/browse/WFLY-11446
> Project: WildFly
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 15.0.0.Beta1
> Reporter: Scott Marlow
> Assignee: Ondra Chaloupka
> Priority: Major
>
> See [https://github.com/wildfly/wildfly/pull/11784#discussion_r237172364] discussion about JNDI lookup of "java:jboss/TransactionSynchronizationRegistry" returning org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper but other internal code sites (like EJB3, JPA container, JCA container) are directly using the org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry.
> My suggestion is that we consider taking steps to eliminate some of the duplicate classes, so that the same TSR is always used. I think some discussion is needed to get there, but wanted to have this tracking jira.
> Somewhat related is that Hibernate ORM 5.3 now has direct references to org.wildfly.transaction.client.ContextTransactionManager + org.wildfly.transaction.client.LocalUserTransaction. Just mentioning in case its helpful to know for whomever looks at this jira.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3778) Receiving error InvocationTargetException on jdk11
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3778?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-3778:
-------------------------------------
[~jfomin] thank you for reporting this, it can be solved by getting rid of powermockito.
It means the test that currently mock static methods will change to
{code:java}
@Test
public void testGetHasTypeRefs() {
final Expression expression = mock(Expression.class);
final InformationItem parameter = mock(InformationItem.class);
final HasTypeRef hasTypeRef1 = mock(HasTypeRef.class);
final HasTypeRef hasTypeRef2 = mock(HasTypeRef.class);
final HasTypeRef hasTypeRef3 = mock(HasTypeRef.class);
final HasTypeRef hasTypeRef4 = mock(HasTypeRef.class);
doReturn(expression).when(binding).getExpression();
doReturn(Arrays.asList(hasTypeRef1, hasTypeRef2)).when(expression).getHasTypeRefs();
doReturn(parameter).when(binding).getParameter();
doReturn(Arrays.asList(hasTypeRef3, hasTypeRef4)).when(parameter).getHasTypeRefs();
final List<HasTypeRef> actualHasTypeRefs = binding.getHasTypeRefs();
final List<HasTypeRef> expectedHasTypeRefs = asList(hasTypeRef1, hasTypeRef2, hasTypeRef3, hasTypeRef4);
assertEquals(expectedHasTypeRefs, actualHasTypeRefs);
}
{code}
> Receiving error InvocationTargetException on jdk11
> --------------------------------------------------
>
> Key: DROOLS-3778
> URL: https://issues.jboss.org/browse/DROOLS-3778
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.20.0.Final
> Environment: * jdk11
> * Apache Maven 3.5.4 (Red Hat 3.5.4-4)
> Reporter: Yevgeniy Fomin
> Assignee: Yevgeniy Fomin
> Priority: Major
> Labels: drools-tools, jdk11
> Attachments: Error log powermock.txt
>
>
> There is InvocationTargetException on test classes if they are run on jdk11. The tests can be found in [module|https://github.com/kiegroup/kie-wb-common/tree/master/kie-wb-commo...]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month