[JBoss JIRA] (WFBUILD-21) Use Woodstox as the StAX engine
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFBUILD-21:
----------------------------------
Summary: Use Woodstox as the StAX engine
Key: WFBUILD-21
URL: https://issues.jboss.org/browse/WFBUILD-21
Project: WildFly Build Tools
Issue Type: Enhancement
Affects Versions: 1.1.3.Final
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
WildFly's XML persister uses Woodstox as its StAX engine.
By using the same engine for the build tools (especially its maven plug-in), we ensure that the XML generated by the build tools is identical to the XML generated by WildFly's XML persister.
Otherwise, there are differences in the XML declaration (WildFly persisted file have the encoding attribute while the XML generated by the build tools does not).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-6895) TimerService problem(duplicated resource)
by M G (JIRA)
[ https://issues.jboss.org/browse/WFLY-6895?page=com.atlassian.jira.plugin.... ]
M G commented on WFLY-6895:
---------------------------
What is the status of this issue? Was the fix reviewed? Will it be included in the nearest release?
> TimerService problem(duplicated resource)
> -----------------------------------------
>
> Key: WFLY-6895
> URL: https://issues.jboss.org/browse/WFLY-6895
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: Two standalone instances connected into a cluster.
> *Master WildFly*
> {code}
> standalone.bat -c standalone-full-ha.xml -Djboss.node.name=master
> {code}
> *Slave WildFly*
> {code}
> standalone.bat -c standalone-full-ha.xml -Djboss.node.name=slave -Djboss.socket.binding.port-offset=100
> {code}
> Both instances has the same singleton policy defined in singleton-full-ha.xml:
> {code}
> <singleton-policy name="scada-singleton" cache-container="server">
> <simple-election-policy>
> <name-preferences>master</name-preferences>
> </simple-election-policy>
> </singleton-policy>
> {code}
> Reporter: Artur Kowalczyk
> Assignee: Tomasz Adamski
>
> I found a problem with TimerService that occurs when your application is configured as a singleton deployment.
> *Test Case*
> # Start master node, the app is also started - OK
> # Start slave node, the app is deployed but bot stared - OK
> # Stop master node, the app is started on slave - OK
> # Start master node, there is a preference for node name so the app will be started again on master and stopped in slave - OK
> # Stop master node, the app should be started again on slave but an exception occur. - ERROR
> {code}
> 09:50:42,115 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.subunit."wildfly-ejb-in-ear.ear"."wildfly-ejb-in-ear-ejb.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."wildfly-ejb-in-ear.ear"."wildfly-ejb-in-ear-ejb.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "wildfly-ejb-in-ear-ejb.jar" of deployment "wildfly-ejb-in-ear.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0086: Failed to install management resources for TimerEJB
> at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.deploy(EjbManagementDeploymentUnitProcessor.java:82)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource timer-service
> at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
> at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
> at org.jboss.as.server.deployment.DeploymentResourceSupport.register(DeploymentResourceSupport.java:322)
> at org.jboss.as.server.deployment.DeploymentResourceSupport.registerDeploymentSubResource(DeploymentResourceSupport.java:219)
> at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.installManagementResource(EjbManagementDeploymentUnitProcessor.java:119)
> at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.deploy(EjbManagementDeploymentUnitProcessor.java:79)
> ... 6 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-5239) XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-5239?page=com.atlassian.jira.plugin.... ]
Petr Kremensky commented on WFLY-5239:
--------------------------------------
The test fails if -Dnode0 (MYTESTIP_1 != localhost) is used:
{noformat}
./integration-tests.sh -Dts.noSmoke -Dts.clustering -Dtest=XSiteSimpleTestCase -Dnode0=$MYTESTIP_1
{noformat}
{noformat}
Running org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 64.527 sec <<< FAILURE! - in org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase
testPutRelayedToBackups(org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase) Time elapsed: 48.265 sec <<< FAILURE!
java.lang.AssertionError: expected:<200> but was:<500>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase.testPutRelayedToBackups(XSiteSimpleTestCase.java:144)
Results :
Failed tests:
XSiteSimpleTestCase.testPutRelayedToBackups:144 expected:<200> but was:<500>
{noformat}
> XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5239
> URL: https://issues.jboss.org/browse/WFLY-5239
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.Beta2
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 11.0.0.Alpha1
>
>
> I have done some work to stabilize this test a little more by switching both stacks (default stack and the bridge stack) to tcp. This does not help the test completely, it still fails with the well known:
> {noformat}
> rhusar &#27;[0m&#27;[0m15:14:52,808 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "xsite.war" (runtime-name : "xsite.war")
> &#27;[0mExecuting HTTP request: http://[::1]:8080/xsite/cache?operation=put&key=a&value=100
> &#27;[33m15:14:53,513 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:14:55,581 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:14:57,583 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:14:59,584 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:15:01,585 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:15:03,277 WARN [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site NYC: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from NYC (sync, timeout=10000)
> &#27;[0mExecuted HTTP request
> &#27;[33m15:15:03,586 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:15:05,591 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message 17:02
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-6931) add implicit module dependency to configuration directory
by Juergen Weber (JIRA)
[ https://issues.jboss.org/browse/WFLY-6931?page=com.atlassian.jira.plugin.... ]
Juergen Weber resolved WFLY-6931.
---------------------------------
Resolution: Won't Fix
One can use
<subsystem xmlns="urn:jboss:domain:ee:1.2">
<global-modules>
> add implicit module dependency to configuration directory
> ---------------------------------------------------------
>
> Key: WFLY-6931
> URL: https://issues.jboss.org/browse/WFLY-6931
> Project: WildFly
> Issue Type: Feature Request
> Components: Class Loading
> Affects Versions: 10.1.0.CR1
> Reporter: Juergen Weber
> Assignee: David Lloyd
>
> Best practice for loading of property files is via classloading.
> Many applications try to load a custom properties file via class loading (e.g. Apache JSPWiki tries to load /jspwiki-custom.properties). With Tomcat, you simply drop property files into tomcat/lib.
> For Wildfly, you have to create a module and add a jboss-dependency.xml to the application:
> https://developer.jboss.org/wiki/HowToPutAnExternalFileInTheClasspath
> Wildfly should have resource folder which by default should be added to the classpath of all applications, i.e. should be an implicit dependency. At least one should be able to switch this on in standalone.xml
> The folder could be standalone/configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7260) Document in elytron model *-client-auth are mutual exclusive
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.... ]
Martin Choma updated WFLY-7260:
-------------------------------
Summary: Document in elytron model *-client-auth are mutual exclusive (was: Document in model *-client-auth are mutual exclusive)
> Document in elytron model *-client-auth are mutual exclusive
> ------------------------------------------------------------
>
> Key: WFLY-7260
> URL: https://issues.jboss.org/browse/WFLY-7260
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Priority: Minor
>
> Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset.
> Now we just have:
> * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true."
> * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7260) Document in model *-client-auth are mutual exclusive
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.... ]
Martin Choma moved JBEAP-6289 to WFLY-7260:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7260 (was: JBEAP-6289)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR6)
> Document in model *-client-auth are mutual exclusive
> ----------------------------------------------------
>
> Key: WFLY-7260
> URL: https://issues.jboss.org/browse/WFLY-7260
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Priority: Minor
>
> Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset.
> Now we just have:
> * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true."
> * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (DROOLS-1316) Missing MBean for Classpath KieContainer causes RHQ/JON plug-in failure to display the whole hierarchy
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1316?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-1316:
----------------------------------------
This solves the problem of RHQ/JON unable to discover the 1st level parent MXBean for the KieContainer making the MXBean available also when the KieContainer is created from the Classpath, the full 3-level hierarchy is built.
Functional test with RHQ:
!solved.png|thumbnail!
In the screenshot, the Jconsole and JVisualVM is showing the reference nesting of the 3 level, and the actual result on RHQ corresponds correctly. This screenshot has been taken using the demo application(1) using the Classpath KieContainer:
{code:java}
public static void main(String[] args) {
KieServices ks = KieServices.Factory.get();
KieContainer kcontainer = ks.getKieClasspathContainer("abcContainer");
KieSession ksession = kcontainer.newKieSession("rules-session");
...
}
{code}
(1) https://github.com/jomarko/drools-project
> Missing MBean for Classpath KieContainer causes RHQ/JON plug-in failure to display the whole hierarchy
> ------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1316
> URL: https://issues.jboss.org/browse/DROOLS-1316
> Project: Drools
> Issue Type: Bug
> Components: core engine, integration
> Affects Versions: 6.5.0.CR2, 7.0.0.Beta1
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Fix For: 6.5.0.Final, 7.0.0.Beta3, 7.0.0.Final
>
> Attachments: solved.png
>
>
> As RHQ/JON is able to discover the MBean for the KieBase and KieSession but unable to locate the MXBean for the KieContainer, would fail to display the whole hierarchy.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months