February 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6280) Can not call "visibility" bridged methods

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFLY-6280?page=com.atlassian.jira.plugin.... ] Farah Juma updated WFLY-6280: ----------------------------- Labels: el (was: ) > Can not call "visibility" bridged methods > ----------------------------------------- > > Key: WFLY-6280 > URL: https://issues.jboss.org/browse/WFLY-6280 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 9.0.2.Final, 10.0.0.Final > Reporter: Trond G. Ziarkowski > Assignee: Farah Juma > Labels: el > > After fix of WFLY-3456 all bridged methods are filtered which causes javax.el.MethodNotFoundException for "visibility" bridged methods. > This has been commented by [~bodist] in WFLY-3456, but nothing has been done to fix it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1970) Make mod_cluster status interval configurable

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-1970?page=com.atlassian.jira.plugin.... ] Radoslav Husar closed WFLY-1970. -------------------------------- > Make mod_cluster status interval configurable > --------------------------------------------- > > Key: WFLY-1970 > URL: https://issues.jboss.org/browse/WFLY-1970 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 8.0.0.Final, 8.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 9.0.0.Alpha1 > > > There is a TODO in UndertowEventHandlerAdapter.start(StartContext) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3575) Parameterize subsystem version in xsite/jgroups testsuite xslt stylesheet

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3575?page=com.atlassian.jira.plugin.... ] Radoslav Husar closed WFLY-3575. -------------------------------- > Parameterize subsystem version in xsite/jgroups testsuite xslt stylesheet > ------------------------------------------------------------------------- > > Key: WFLY-3575 > URL: https://issues.jboss.org/browse/WFLY-3575 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 8.1.0.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Fix For: 9.0.0.Alpha1 > > > I wasted a good couple of hours today trying to figure out why my changes broke the xsite tests. It turns out that the xslt scripts have the subsystem schema version hardcoded, and I had created a new schema version. > We should parameterize this, in the same way as the addCacheContainer.xsl stylesheet does. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6257) Allow Narayanas list of XAOrphanFilters to include a check of the transaction status manager

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-6257?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated WFLY-6257: -------------------------------- Fix Version/s: 11.0.0.Alpha1 (was: 10.1.0.Final) > Allow Narayanas list of XAOrphanFilters to include a check of the transaction status manager > -------------------------------------------------------------------------------------------- > > Key: WFLY-6257 > URL: https://issues.jboss.org/browse/WFLY-6257 > Project: WildFly > Issue Type: Enhancement > Components: Transactions > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 11.0.0.Alpha1 > > > Narayana has added a check of the transaction status manager to check the status of the transaction with a transaction manager. This needs to be exposed in WildFly. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6257) Allow Narayanas list of XAOrphanFilters to include a check of the transaction status manager

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-6257?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated WFLY-6257: -------------------------------- Fix Version/s: 10.1.0.Final > Allow Narayanas list of XAOrphanFilters to include a check of the transaction status manager > -------------------------------------------------------------------------------------------- > > Key: WFLY-6257 > URL: https://issues.jboss.org/browse/WFLY-6257 > Project: WildFly > Issue Type: Enhancement > Components: Transactions > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 10.1.0.Final > > > Narayana has added a check of the transaction status manager to check the status of the transaction with a transaction manager. This needs to be exposed in WildFly. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5857) HASingleton Stop is called in Node1 (Master) during down of Node2 in cluster, but start is not called in Node1 again after Node1 is selected Master again

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5857?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-5857: ------------------------------------ Please see the documentation for this feature here: https://docs.jboss.org/author/display/WFLY10/HA+Singleton+Features > HASingleton Stop is called in Node1 (Master) during down of Node2 in cluster, but start is not called in Node1 again after Node1 is selected Master again > --------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5857 > URL: https://issues.jboss.org/browse/WFLY-5857 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.1.Final > Environment: Wildfly-9.0.1.Final. Full HA Configuration. Cluster Full Ha > Reporter: Serg Jakean19019 > Assignee: Paul Ferraro > > HASingleton Stop is called in Node1 (Master) during down of Node2 in cluster, but Start is not called in Node1 again after Node1 is selected Master again. > If Node2 ist started again, than Start is called in Node1 again. > This Solution worked in 8.2.0.Final and was taken from GitHub > Part of Log after Stop in Singletone: > 2015-12-16 10:25:39,832 WARN [org.wildfly.clustering.server] (remote-thread--p8-t5) WFLYCLSV0007: Just reached required quorum of 1 for jboss.quickstart.ha.singleton.default service. If this cluster loses another member, no node will be chosen to provide this service. > 2015-12-16 10:25:39,832 INFO [org.wildfly.clustering.server] (remote-thread--p8-t5) WFLYCLSV0003: DevNode1 elected as the singleton provider of the jboss.quickstart.ha.singleton.default service > 2015-12-16 10:25:40,410 WARN [org.hornetq.core.client] (Thread-514 (HornetQ-client-global-threads-816000930)) HQ212037: Connection failure has been detected: HQ119015: The connection was disconnected because of server shutdown [code=DISCONNECTED] > 2015-12-16 10:25:40,424 WARN [org.hornetq.core.client] (Thread-515 (HornetQ-client-global-threads-816000930)) HQ212037: Connection failure has been detected: HQ119015: The connection was disconnected because of server shutdown [code=DISCONNECTED] > 2015-12-16 10:25:40,442 INFO [org.hornetq.core.server] (Thread-16 (HornetQ-server-HornetQServerImpl::serverUUID=5f62a17c-a33d-11e5-b968-cda4b2119720-1601129088)) HQ221029: stopped bridge sf.my-cluster.b27b8fc6-a33e-11e5-84b8-b7bbc6dfe24c > 2015-12-16 10:25:40,495 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,ee,DevNode1) ISPN000094: Received new cluster view for channel server: [Node1|2] (1) [DevNode1] > 2015-12-16 10:25:40,496 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,ee,DevNode1) ISPN000094: Received new cluster view for channel ejb: [Node1|2] (1) [DevNode1] > 2015-12-16 10:25:40,497 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,ee,DevNode1) ISPN000094: Received new cluster view for channel hibernate: [DevNode1|2] (1) [DevNode1] > 2015-12-16 10:25:57,010 WARNING [org.jgroups.protocols.UDP] (INT-1,hq-cluster,DevNode1) JGRP000012: discarded message from different cluster ee (our cluster is hq-cluster). Sender was DevNode1 (received 38 identical messages from DevNode1 in the last 63946 ms) > 2015-12-16 10:26:30,810 WARNING [org.jgroups.protocols.UDP] (Incoming-13,ee,DevNode1) JGRP000012: discarded message from different cluster hq-cluster (our cluster is ee). Sender was DevNode1 (received 80 identical messages from DevNode1 in the last 60008 ms) > This issue also in: > https://developer.jboss.org/thread/266831 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6298) Test suite crashes at : "jipijapa Hibernate 4.3.x (JPA 2.1) integration"

by Shishir Subramanyam (JIRA)

Shishir Subramanyam created WFLY-6298: ----------------------------------------- Summary: Test suite crashes at : "jipijapa Hibernate 4.3.x (JPA 2.1) integration" Key: WFLY-6298 URL: https://issues.jboss.org/browse/WFLY-6298 Project: WildFly Issue Type: Bug Components: Test Suite Affects Versions: 10.0.0.Final Reporter: Shishir Subramanyam Priority: Trivial Attachments: Wildfly test suite error.JPG The test suite fails at the step : "jipijapa Hibernate 4.3.x (JPA 2.1) integration". I did not make any changes to the code before running "mvn install" through cmd(windows) in the base directory -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1020) Add withVars query attribute to getProcessInstance operation for finished processes

by Ivo Bek (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1020?page=com.atlassian.jira.plugi... ] Ivo Bek updated DROOLS-1020: ---------------------------- Fix Version/s: 6.4.0.CR1 7.0.0.Final > Add withVars query attribute to getProcessInstance operation for finished processes > ----------------------------------------------------------------------------------- > > Key: DROOLS-1020 > URL: https://issues.jboss.org/browse/DROOLS-1020 > Project: Drools > Issue Type: Enhancement > Components: kie server > Affects Versions: 6.3.0.Final > Reporter: Ivo Bek > Assignee: Ivo Bek > Priority: Minor > Labels: reported-by-qe > Fix For: 6.4.0.CR1, 7.0.0.Final > > Original Estimate: 1 week > Remaining Estimate: 1 week > > KIE Server already provides getProcessInstance operation with query attribute withVars but only for an active process instance [1]. The enhancement will add this functionality to RuntimeDataResource to be able to query completed and aborted processes including their variables. > Additionally, the changes will require to change KIE Server client and it would be nice to add functionality to both REST and JMS. > [1] https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/kie-serv... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1020) Add withVars query attribute to getProcessInstance operation for finished processes

by Ivo Bek (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1020?page=com.atlassian.jira.plugi... ] Ivo Bek updated DROOLS-1020: ---------------------------- Git Pull Request: https://github.com/droolsjbpm/droolsjbpm-integration/pull/331, https://github.com/droolsjbpm/droolsjbpm-integration/pull/332 (was: https://github.com/droolsjbpm/droolsjbpm-integration/pull/331) > Add withVars query attribute to getProcessInstance operation for finished processes > ----------------------------------------------------------------------------------- > > Key: DROOLS-1020 > URL: https://issues.jboss.org/browse/DROOLS-1020 > Project: Drools > Issue Type: Enhancement > Components: kie server > Affects Versions: 6.3.0.Final > Reporter: Ivo Bek > Assignee: Ivo Bek > Priority: Minor > Labels: reported-by-qe > Fix For: 6.4.0.CR1, 7.0.0.Final > > Original Estimate: 1 week > Remaining Estimate: 1 week > > KIE Server already provides getProcessInstance operation with query attribute withVars but only for an active process instance [1]. The enhancement will add this functionality to RuntimeDataResource to be able to query completed and aborted processes including their variables. > Additionally, the changes will require to change KIE Server client and it would be nice to add functionality to both REST and JMS. > [1] https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/kie-serv... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-232) Unclean shutdown of deployment scanner

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-232?page=com.atlassian.jira.plugin... ] Ondrej Zizka commented on WFCORE-232: ------------------------------------- I'm working with EAP 7 Beta. Un/Deploying using wildfly maven plugin. EAP sometimes gets to a state when writes this exception repeatedly and can't deploy and run the app. > Unclean shutdown of deployment scanner > -------------------------------------- > > Key: WFCORE-232 > URL: https://issues.jboss.org/browse/WFCORE-232 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha11 > Reporter: Brian Stansberry > Assignee: ehsavoie Hugonnet > Fix For: 1.0.0.Beta4 > > > I happened to see this in a testsuite log file: > {code} > 2014-11-07 02:59:41,808 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0012: Scan of /opt/buildAgent/work/8feb0abb503148fe/testsuite/manualmode/target/deployment-test-bc636b67-df54-462d-9a13-3618a1755d3f threw Exception: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@146a4b2 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@e6cbcd[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 3] > at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048) > at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) > at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:325) > at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:530) > at java.util.concurrent.ScheduledThreadPoolExecutor.execute(ScheduledThreadPoolExecutor.java:619) > at org.jboss.as.controller.ModelControllerImpl$3.executeAsync(ModelControllerImpl.java:669) > at org.jboss.as.controller.ModelControllerImpl$3.executeAsync(ModelControllerImpl.java:605) > at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.deploy(DefaultDeploymentOperations.java:61) > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:449) > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$UndeployScanRunnable.run(FileSystemDeploymentService.java:538) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > DeploymentScannerService is calling stopScanner() on the scanner and then is shutting down the executor. But stopScanner does not wait for in progress tasks to complete, nor do the in-progress tasks recognize that shutdown is occurring and handle any problems differently (e.g. don't toss the above in the log.) > Waiting for tasks to complete could be tricky, e.g. imagine this race: > 1) Admin submits op to shutdown/reload, which has the controller lock and is now stopping services. > 2) Scan job kicks off, finds changes and wants to modify the model, so the task is blocking waiting for the controller lock. > Deadlock. > Now, this may not be a problem, as server reload tells MSC to remove the root service on the way out (i.e. after the bit where it blocks for stability) and then MSC threads take over, allowing the op thread to continue and release the lock. The shutdown handler spawns a thread to call System.exit. > But ^^^ is just a quick look, so be cautious! -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2016