[JBoss JIRA] (WFLY-13433) Improve capability support in EJB3 subsystem
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13433?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz commented on WFLY-13433:
--------------------------------------------
The issue has now been fixed, the default and full profiles for EAP640 did not include an ejb cache-container (with an appropriate local cache defined) and so these had to be added to the mixed domain tests for those profiles via the LegacyConfigAdjuster640 class.
> Improve capability support in EJB3 subsystem
> --------------------------------------------
>
> Key: WFLY-13433
> URL: https://issues.redhat.com/browse/WFLY-13433
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Affects Versions: 20.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Attachments: successfulLegacyConfigTest.txt, unSuccessfulLegacyConfigTest.txt
>
>
> Survey all external subsystem dependencies and introduce capability based dependencies where required.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-13696) [GSS](7.3.z) UT000065: SSL must be specified to connect to a https URL when using ejb over https
by Flavia Rainone (Jira)
Flavia Rainone created WFLY-13696:
-------------------------------------
Summary: [GSS](7.3.z) UT000065: SSL must be specified to connect to a https URL when using ejb over https
Key: WFLY-13696
URL: https://issues.redhat.com/browse/WFLY-13696
Project: WildFly
Issue Type: Bug
Reporter: Flavia Rainone
Assignee: Tomasz Adamski
UT000065: SSL must be specified to connect to a https URL when using ejb over https
There is an XA Recovery Issue when EJB over HTTPS is used.
If an XA transaction fails, when the server is restarted it will find the standalone/data/ejb-xa-recovery files to recover, and the xa recovery runs it will hit this exception below.
./bin/standalone.sh -Djavax.net.ssl.trustStore=./standalone/configuration/application.keystore -Djavax.net.ssl.trustStorePassword=password -DRecoveryEnvironmentBean.periodicRecoveryPeriod=10
cat standalone/data/ejb-xa-recovery/20005_00000000000000000000ffffc0a80141066cd6715eb1b1420000001131_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
https://localhost:8443/wildfly-services
{code}
14:38:10,855 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception ARJUNA016099: Unknown error code:0: javax.transaction.xa.XAException: UT000065: SSL must be specified to connect to a https URL
at org.wildfly.httpclient.transaction.HttpRemoteTransactionPeer.recover(HttpRemoteTransactionPeer.java:107)
at org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:213)
at org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:209)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:171)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
Caused by: java.io.IOException: UT000065: SSL must be specified to connect to a https URL
at io.undertow.client.http.HttpClientProvider.connect(HttpClientProvider.java:72)
at io.undertow.client.http.HttpClientProvider.connect(HttpClientProvider.java:60)
at io.undertow.client.UndertowClient.connect(UndertowClient.java:137)
at org.wildfly.httpclient.common.HttpConnectionPool.runPending(HttpConnectionPool.java:151)
at org.wildfly.httpclient.common.HttpConnectionPool.getConnection(HttpConnectionPool.java:83)
at org.wildfly.httpclient.common.HttpTargetContext.sendRequest(HttpTargetContext.java:142)
at org.wildfly.httpclient.transaction.HttpRemoteTransactionPeer.recover(HttpRemoteTransactionPeer.java:73)
... 7 more
14:38:20,860 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.NullPointerException
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:738)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:519)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:270)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:816)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-13692) Anything in jboss-all.xml after <weld/> element is ignored
by L K (Jira)
[ https://issues.redhat.com/browse/WFLY-13692?page=com.atlassian.jira.plugi... ]
L K commented on WFLY-13692:
----------------------------
Well, as somebody that uses jboss-all.xml I really do not care about javadoc...
But as somebody who wasted some time on this I can tell you that you need to parse the element *completely*. Somebody might put something like this in jboss-all.xml:
<jboss xmlns="urn:jboss:1.0">
<weld xmlns="urn:jboss:weld:1.1>
<some-stupid-element/>
</weld>
</jboss>
Yes, it is incorrect, but this is what WeldJBossAllXYParser must deal with.
Just look at for example JBossDeploymentStructureParserXY: it parses everything until it hits END_ELEMENT.
> Anything in jboss-all.xml after <weld/> element is ignored
> ----------------------------------------------------------
>
> Key: WFLY-13692
> URL: https://issues.redhat.com/browse/WFLY-13692
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 20.0.1.Final
> Reporter: L K
> Assignee: Matěj Novotný
> Priority: Major
>
> Classes org.jboss.as.weld.WeldJBossAll10Parser and org.jboss.as.weld.WeldJBossAll11Parser are incorrect. They do not parse <weld> element as XML, they just check attributes.
> As a result, everything that comes after </weld> is ignored.
> This jboss-all.xml fails, as expected:
> {code:java}
> <jboss xmlns="urn:jboss:1.0">
> <some-stupid-element/>
> <weld xmlns="urn:jboss:weld:1.1"/>
> </jboss>
> {code}
> This one is successfully parsed (but must also fail):
> {code:java}
> <jboss xmlns="urn:jboss:1.0">
> <weld xmlns="urn:jboss:weld:1.1"/>
> <some-stupid-element/>
> </jboss>
> {code}
>
> Now imagine that "some-stupid-element" is in fact "jboss-deployment-structure" which gets ignored...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-13692) Anything in jboss-all.xml after <weld/> element is ignored
by L K (Jira)
[ https://issues.redhat.com/browse/WFLY-13692?page=com.atlassian.jira.plugi... ]
L K edited comment on WFLY-13692 at 7/23/20 3:29 PM:
-----------------------------------------------------
Well, as somebody that uses jboss-all.xml I really do not care about javadoc...
But as somebody who wasted some time on this I can tell you that you need to parse the element *completely*. Somebody might put something like this in jboss-all.xml:
<jboss xmlns="urn:jboss:1.0">
<weld xmlns="urn:jboss:weld:1.1>
<some-stupid-element/>
</weld>
</jboss>
Yes, it is incorrect, but this is what WeldJBossAllXYParser must deal with.
Just look at for example JBossDeploymentStructureParserXY: it parses everything until it hits END_ELEMENT.
was (Author: l-k-test):
Well, as somebody that uses jboss-all.xml I really do not care about javadoc...
But as somebody who wasted some time on this I can tell you that you need to parse the element *completely*. Somebody might put something like this in jboss-all.xml:
<jboss xmlns="urn:jboss:1.0">
<weld xmlns="urn:jboss:weld:1.1>
<some-stupid-element/>
</weld>
</jboss>
Yes, it is incorrect, but this is what WeldJBossAllXYParser must deal with.
Just look at for example JBossDeploymentStructureParserXY: it parses everything until it hits END_ELEMENT.
> Anything in jboss-all.xml after <weld/> element is ignored
> ----------------------------------------------------------
>
> Key: WFLY-13692
> URL: https://issues.redhat.com/browse/WFLY-13692
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 20.0.1.Final
> Reporter: L K
> Assignee: Matěj Novotný
> Priority: Major
>
> Classes org.jboss.as.weld.WeldJBossAll10Parser and org.jboss.as.weld.WeldJBossAll11Parser are incorrect. They do not parse <weld> element as XML, they just check attributes.
> As a result, everything that comes after </weld> is ignored.
> This jboss-all.xml fails, as expected:
> {code:java}
> <jboss xmlns="urn:jboss:1.0">
> <some-stupid-element/>
> <weld xmlns="urn:jboss:weld:1.1"/>
> </jboss>
> {code}
> This one is successfully parsed (but must also fail):
> {code:java}
> <jboss xmlns="urn:jboss:1.0">
> <weld xmlns="urn:jboss:weld:1.1"/>
> <some-stupid-element/>
> </jboss>
> {code}
>
> Now imagine that "some-stupid-element" is in fact "jboss-deployment-structure" which gets ignored...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (JGRP-2494) DNS_PING and failed probes
by Dewayne McNair (Jira)
[ https://issues.redhat.com/browse/JGRP-2494?page=com.atlassian.jira.plugin... ]
Dewayne McNair commented on JGRP-2494:
--------------------------------------
Yes - this can be closed.
> DNS_PING and failed probes
> --------------------------
>
> Key: JGRP-2494
> URL: https://issues.redhat.com/browse/JGRP-2494
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.9
> Reporter: Dewayne McNair
> Assignee: Bela Ban
> Priority: Major
> Attachments: JGRP-2494.txt
>
>
> Using DNS_PING in a DC/OS (marathon) deployment, there are two SRV records returned - one for the web port and one for the jgroups port. When the discovery request is sent, an exception is thrown and logged. The clustering is working, but logs are filling up due to the exception happening and being logged frequently.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-13693) Custom Infinispan cache regions fail when using legacy (non-JPA) Hibernate configuration
by Stephen Fikes (Jira)
[ https://issues.redhat.com/browse/WFLY-13693?page=com.atlassian.jira.plugi... ]
Stephen Fikes updated WFLY-13693:
---------------------------------
Affects Version/s: 18.0.0.Final
> Custom Infinispan cache regions fail when using legacy (non-JPA) Hibernate configuration
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-13693
> URL: https://issues.redhat.com/browse/WFLY-13693
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 14.0.0.Final, 18.0.0.Final
> Reporter: Stephen Fikes
> Assignee: Scott Marlow
> Priority: Major
>
> A custom cache template is defined in the "hibernate" cache container in the {{standalone.xml}}
> {code:java}
> <local-cache name="entities.custom-cache">
> <transaction mode="NONE"/>
> <object-memory size="10"/>
> </local-cache>
> {code}
> In the legacy {{hibernate.cfg.xml}} this is associated with a named cache region.
> {code:java}
> <property name="hibernate.cache.region_prefix">entities</property>
> <property name="hibernate.cache.infinispan.entities.custom-cache.cfg">entities.custom-cache</property>
> <property name="hibernate.cache.use_second_level_cache">true</property>
> {code}
> The cache region is then referenced in an entity annotation:
> {code:java}
> @Entity
> @Cache(usage=CacheConcurrencyStrategy.READ_WRITE, region="custom-cache")
> public class Employee {
> ...
> }
> {code}
> At deployment, an exception is logged:
> {noformat}
> ... HHH025007: Custom cache configuration 'entities.custom-cache' was requested for region entities.custom-cache but it was not found - using configuration by type (entity).
> {noformat}
> This same approach (but using transactional caching) worked in Wildfly 11.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-13694) [GSS](7.3.z) Custom Infinispan cache regions fail when using legacy (non-JPA) Hibernate configuration
by Stephen Fikes (Jira)
Stephen Fikes created WFLY-13694:
------------------------------------
Summary: [GSS](7.3.z) Custom Infinispan cache regions fail when using legacy (non-JPA) Hibernate configuration
Key: WFLY-13694
URL: https://issues.redhat.com/browse/WFLY-13694
Project: WildFly
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 14.0.0.Final
Reporter: Stephen Fikes
Assignee: Scott Marlow
A custom cache template is defined in the "hibernate" cache container in the {{standalone.xml}}
{code:java}
<local-cache name="entities.custom-cache">
<transaction mode="NONE"/>
<object-memory size="10"/>
</local-cache>
{code}
In the legacy {{hibernate.cfg.xml}} this is associated with a named cache region.
{code:java}
<property name="hibernate.cache.region_prefix">entities</property>
<property name="hibernate.cache.infinispan.entities.custom-cache.cfg">entities.custom-cache</property>
<property name="hibernate.cache.use_second_level_cache">true</property>
{code}
The cache region is then referenced in an entity annotation:
{code:java}
@Entity
@Cache(usage=CacheConcurrencyStrategy.READ_WRITE, region="custom-cache")
public class Employee {
...
}
{code}
At deployment, an exception is logged:
{noformat}
... HHH025007: Custom cache configuration 'entities.custom-cache' was requested for region entities.custom-cache but it was not found - using configuration by type (entity).
{noformat}
This same approach (but using transactional caching) worked in Wildfly 11.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months