[JBoss JIRA] (WFLY-5710) AS doesn't compile with oracle java 1.8.0_25
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-5710?page=com.atlassian.jira.plugin.... ]
Martin Choma moved JBEAP-1963 to WFLY-5710:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5710 (was: JBEAP-1963)
Workflow: GIT Pull Request workflow (was: CDW v1)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.CR4
(was: 7.0.0.ER1)
> AS doesn't compile with oracle java 1.8.0_25
> --------------------------------------------
>
> Key: WFLY-5710
> URL: https://issues.jboss.org/browse/WFLY-5710
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.CR4
> Reporter: Martin Choma
> Priority: Minor
>
> Adding this issue mainly for reference as on latest java 1.8.0_66 works fine again.
> Whole affected java version is
> {code}
> java version "1.8.0_25"
> Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
> {code}
> Whole compilation error is
> {code}
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project wildfly-clustering-common: Compilation failure
> [ERROR] /home/mchoma/workspace/git-repositories/wildfly/clustering/common/src/main/java/org/jboss/as/clustering/controller/ExecutionHandler.java:[54,48] no suitable method found for collect(java.util.stream.Collector<E,capture#1 of ?,java.util.Map<java.lang.String,java.lang.Object>>)
> [ERROR] method java.util.stream.Stream.<R>collect(java.util.function.Supplier<R>,java.util.function.BiConsumer<R,? super capture#2 of ? extends E>,java.util.function.BiConsumer<R,R>) is not applicable
> [ERROR] (cannot infer type-variable(s) R
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method java.util.stream.Stream.<R,A>collect(java.util.stream.Collector<? super capture#2 of ? extends E,A,R>) is not applicable
> [ERROR] (cannot infer type-variable(s) capture#3 of ?,T,K,U,T
> [ERROR] (argument mismatch; java.util.function.Function<capture#2 of ? extends E,capture#2 of ? extends E> cannot be converted to java.util.function.Function<? super capture#2 of ? extends E,? extends capture#2 of ? extends E>))
> {code}
> Works ok on
> {code}
> java version "1.8.0_05"
> Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
> {code}
> {code}
> java version "1.8.0_66"
> Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (DROOLS-985) Loaded wrong version's jar file after restarting kie-server.
by hoon lee (JIRA)
[ https://issues.jboss.org/browse/DROOLS-985?page=com.atlassian.jira.plugin... ]
hoon lee updated DROOLS-985:
----------------------------
Description:
1. Start unmanaged kie-server
2. Create a container
name : test
kjar : test:test-rule:1.0.0
3. update & release (kjar)
name : test
kjar : test:test-rule:1.0.1
4. Restart unmanaged kie-server
* Issue
=> Container 'test' is automatically started and load a 'test-rule:1.0.0' (not 1.0.1)
was:
1. Start unmanaged kie-server
2. Create a container
* name : test
* kjar : test:test-rule:1.0.0
3. update & release (kjar)
* name : test
* kjar : test:test-rule:1.0.1
4. Restart unmanaged kie-server
* Issue
=> Container 'test' is automatically started and load a 'test-rule:1.0.0' (not 1.0.1)
> Loaded wrong version's jar file after restarting kie-server.
> ------------------------------------------------------------
>
> Key: DROOLS-985
> URL: https://issues.jboss.org/browse/DROOLS-985
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final
> Environment: CentOS
> WAS : wildfly-8.2.1.Final
> Drools : 6.3.0.Final
> Reporter: hoon lee
> Assignee: Edson Tirelli
>
> 1. Start unmanaged kie-server
> 2. Create a container
> name : test
> kjar : test:test-rule:1.0.0
> 3. update & release (kjar)
> name : test
> kjar : test:test-rule:1.0.1
> 4. Restart unmanaged kie-server
> * Issue
> => Container 'test' is automatically started and load a 'test-rule:1.0.0' (not 1.0.1)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (DROOLS-985) Loaded wrong version's jar file after restarting kie-server.
by hoon lee (JIRA)
[ https://issues.jboss.org/browse/DROOLS-985?page=com.atlassian.jira.plugin... ]
hoon lee updated DROOLS-985:
----------------------------
Description:
1. Start unmanaged kie-server
2. Create a container
* name : test
* kjar : test:test-rule:1.0.0
3. update & release (kjar)
* name : test
* kjar : test:test-rule:1.0.1
4. Restart unmanaged kie-server
* Issue
=> Container 'test' is automatically started and load a 'test-rule:1.0.0' (not 1.0.1)
was:
1. Start unmanaged kie-server
2. Create a container
- name : test
- kjar : test:test-rule:1.0.0
3. update & release (kjar)
- name : test
- kjar : test:test-rule:1.0.1
4. Restart unmanaged kie-server
* Issue
=> Container 'test' is automatically started and load a 'test-rule:1.0.0' (not 1.0.1)
> Loaded wrong version's jar file after restarting kie-server.
> ------------------------------------------------------------
>
> Key: DROOLS-985
> URL: https://issues.jboss.org/browse/DROOLS-985
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final
> Environment: CentOS
> WAS : wildfly-8.2.1.Final
> Drools : 6.3.0.Final
> Reporter: hoon lee
> Assignee: Edson Tirelli
>
> 1. Start unmanaged kie-server
> 2. Create a container
> * name : test
> * kjar : test:test-rule:1.0.0
> 3. update & release (kjar)
> * name : test
> * kjar : test:test-rule:1.0.1
> 4. Restart unmanaged kie-server
> * Issue
> => Container 'test' is automatically started and load a 'test-rule:1.0.0' (not 1.0.1)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (DROOLS-985) Loaded wrong version's jar file after restarting kie-server.
by hoon lee (JIRA)
hoon lee created DROOLS-985:
-------------------------------
Summary: Loaded wrong version's jar file after restarting kie-server.
Key: DROOLS-985
URL: https://issues.jboss.org/browse/DROOLS-985
Project: Drools
Issue Type: Bug
Components: kie server
Affects Versions: 6.3.0.Final
Environment: CentOS
WAS : wildfly-8.2.1.Final
Drools : 6.3.0.Final
Reporter: hoon lee
Assignee: Edson Tirelli
1. Start unmanaged kie-server
2. Create a container
- name : test
- kjar : test:test-rule:1.0.0
3. update & release (kjar)
- name : test
- kjar : test:test-rule:1.0.1
4. Restart unmanaged kie-server
* Issue
=> Container 'test' is automatically started and load a 'test-rule:1.0.0' (not 1.0.1)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5596) MessageDrivenComponent startDelivery/stopDelivery is not thread safe
by James Livingston (JIRA)
[ https://issues.jboss.org/browse/WFLY-5596?page=com.atlassian.jira.plugin.... ]
James Livingston edited comment on WFLY-5596 at 11/19/15 9:42 PM:
------------------------------------------------------------------
This is reproducible on WF 10 CR4, and can double-activate the endpoint
was (Author: jameslivingston):
This is reproducible on WF 10 CR4, and it does not actually require a full race condition, merely unlucky ordering. If MdbDeliveryControllerService runs before the component is started, it will double-activate the endpoint.
> MessageDrivenComponent startDelivery/stopDelivery is not thread safe
> --------------------------------------------------------------------
>
> Key: WFLY-5596
> URL: https://issues.jboss.org/browse/WFLY-5596
> Project: WildFly
> Issue Type: Bug
> Components: EJB, JMS
> Affects Versions: 10.0.0.CR4
> Reporter: James Livingston
> Assignee: Jeff Mesnil
>
> WFLY-4470 made a change to prevent MDBs being activated or deactivated multiple times, but it is not thread safe. A volatile boolean is used for the flag, but there is no protection against multiple threads invoking the methods simultaneously.
> Possible effects include:
> * activating the endpoint twice, with (probably) only one deactivation later, leading to not de-registering XA resources from the recovery manager properly
> * activate() and deactivate() running in the wrong order if done by separate threads
> Several simple solutions probably will not work correctly. Using an AtomicBoolean would stop multiple activations/deactivations from concurrent calls, but would mean that startDelivery() could return before the activation was one. Using a synchronized block or other exclusive lock would work, however since it involves invoking non-container code (the resource adapter), there could potentially be a deadlock risk if that invoked some related container functionality.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1144) Space before JVM argument in <jvm-options> causes failure
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1144?page=com.atlassian.jira.plugi... ]
Lin Gao updated WFCORE-1144:
----------------------------
Component/s: Domain Management
> Space before JVM argument in <jvm-options> causes failure
> ---------------------------------------------------------
>
> Key: WFCORE-1144
> URL: https://issues.jboss.org/browse/WFCORE-1144
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: java version "1.7.0_85"
> OpenJDK Runtime Environment (rhel-2.6.1.3.el6_7-x86_64 u85-b01)
> OpenJDK 64-Bit Server VM (build 24.85-b03, mixed mode)
> RHEL 6.5
> Reporter: Lin Gao
> Assignee: Lin Gao
>
> I have this configuration in my host.xml. Note the space before -XX:HeapDumpPath.
> {code}
> <server name="server-one" group="main-server-group">
> <jvm name="default">
> <jvm-options>
> <option value="-agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n"/>
> <option value=" -XX:HeapDumpPath=/tmp/"/>
> </jvm-options>
> </jvm>
> </server>
> {code}
> When I start up EAP, server-one fails to start with this error message:
> {code}
> 17:01:26,218 INFO [org.jboss.as.process.Server:server-one.status] (ProcessController-threads - 3) JBAS012017: Starting process 'Server:server-one'
> [Server:server-one] Listening for transport dt_socket at address: 8787
> [Server:server-one] Error: Could not find or load main class -XX:HeapDumpPath=.tmp.
> 17:01:26,766 INFO [org.jboss.as.process.Server:server-one.status] (reaper for Server:server-one) JBAS012010: Process 'Server:server-one' finished with an exit status of 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1144) Space before JVM argument in <jvm-options> causes failure
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1144?page=com.atlassian.jira.plugi... ]
Lin Gao moved JBEAP-1961 to WFCORE-1144:
----------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1144 (was: JBEAP-1961)
Workflow: GIT Pull Request workflow (was: CDW v1)
Target Release: (was: 7.0.0.GA)
Affects Version/s: (was: 6.4.0.GA)
> Space before JVM argument in <jvm-options> causes failure
> ---------------------------------------------------------
>
> Key: WFCORE-1144
> URL: https://issues.jboss.org/browse/WFCORE-1144
> Project: WildFly Core
> Issue Type: Bug
> Environment: java version "1.7.0_85"
> OpenJDK Runtime Environment (rhel-2.6.1.3.el6_7-x86_64 u85-b01)
> OpenJDK 64-Bit Server VM (build 24.85-b03, mixed mode)
> RHEL 6.5
> Reporter: Lin Gao
> Assignee: Lin Gao
>
> I have this configuration in my host.xml. Note the space before -XX:HeapDumpPath.
> {code}
> <server name="server-one" group="main-server-group">
> <jvm name="default">
> <jvm-options>
> <option value="-agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n"/>
> <option value=" -XX:HeapDumpPath=/tmp/"/>
> </jvm-options>
> </jvm>
> </server>
> {code}
> When I start up EAP, server-one fails to start with this error message:
> {code}
> 17:01:26,218 INFO [org.jboss.as.process.Server:server-one.status] (ProcessController-threads - 3) JBAS012017: Starting process 'Server:server-one'
> [Server:server-one] Listening for transport dt_socket at address: 8787
> [Server:server-one] Error: Could not find or load main class -XX:HeapDumpPath=.tmp.
> 17:01:26,766 INFO [org.jboss.as.process.Server:server-one.status] (reaper for Server:server-one) JBAS012010: Process 'Server:server-one' finished with an exit status of 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5596) MessageDrivenComponent startDelivery/stopDelivery is not thread safe
by James Livingston (JIRA)
[ https://issues.jboss.org/browse/WFLY-5596?page=com.atlassian.jira.plugin.... ]
James Livingston commented on WFLY-5596:
----------------------------------------
This is reproducible on WF 10 CR4, and it does not actually require a full race condition, merely unlucky ordering. If MdbDeliveryControllerService runs before the component is started, it will double-activate the endpoint.
> MessageDrivenComponent startDelivery/stopDelivery is not thread safe
> --------------------------------------------------------------------
>
> Key: WFLY-5596
> URL: https://issues.jboss.org/browse/WFLY-5596
> Project: WildFly
> Issue Type: Bug
> Components: EJB, JMS
> Affects Versions: 10.0.0.CR4
> Reporter: James Livingston
> Assignee: Jeff Mesnil
>
> WFLY-4470 made a change to prevent MDBs being activated or deactivated multiple times, but it is not thread safe. A volatile boolean is used for the flag, but there is no protection against multiple threads invoking the methods simultaneously.
> Possible effects include:
> * activating the endpoint twice, with (probably) only one deactivation later, leading to not de-registering XA resources from the recovery manager properly
> * activate() and deactivate() running in the wrong order if done by separate threads
> Several simple solutions probably will not work correctly. Using an AtomicBoolean would stop multiple activations/deactivations from concurrent calls, but would mean that startDelivery() could return before the activation was one. Using a synchronized block or other exclusive lock would work, however since it involves invoking non-container code (the resource adapter), there could potentially be a deadlock risk if that invoked some related container functionality.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5596) MessageDrivenComponent startDelivery/stopDelivery is not thread safe
by James Livingston (JIRA)
[ https://issues.jboss.org/browse/WFLY-5596?page=com.atlassian.jira.plugin.... ]
James Livingston updated WFLY-5596:
-----------------------------------
Steps to Reproduce:
1) Take the helloworld-mdb quickstart, and add @ClusteredSingleton (from jboss-ejb3-exi-api) to a MDB.
2) Add a breakpoint on MessageDrivenBean.activate()
3) Deploy and start the server
Either one or two threads may hit the breakpoint concurrently, depending on whether the first runs "this.deliveryActive = true" before the second does the check:
org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.activate() line: 238
org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.startDelivery() line: 265
org.jboss.as.ejb3.component.messagedriven.MdbDeliveryControllerService.start(org.jboss.msc.service.StartContext) line: 51
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(org.jboss.msc.service.Service<? extends S>, org.jboss.msc.service.StartContext) line: 1948
org.jboss.msc.service.ServiceControllerImpl$StartTask.run() line: 1881
org.jboss.msc.service.ServiceContainerImpl$ContainerExecutor(java.util.concurrent.ThreadPoolExecutor).runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) line: 1142
java.util.concurrent.ThreadPoolExecutor$Worker.run() line: 617
org.jboss.msc.service.ServiceContainerImpl$ServiceThread(java.lang.Thread).run() line: 745
org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.activate() line: 238
org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start() line: 214
org.jboss.as.ee.component.ComponentStartService$1.run() line: 54
java.util.concurrent.Executors$RunnableAdapter<T>.call() line: 511
java.util.concurrent.FutureTask<V>.run() line: 266
java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) line: 1142
java.util.concurrent.ThreadPoolExecutor$Worker.run() line: 617
org.jboss.threads.JBossThread(java.lang.Thread).run() line: 745
org.jboss.threads.JBossThread.run() line: 320
> MessageDrivenComponent startDelivery/stopDelivery is not thread safe
> --------------------------------------------------------------------
>
> Key: WFLY-5596
> URL: https://issues.jboss.org/browse/WFLY-5596
> Project: WildFly
> Issue Type: Bug
> Components: EJB, JMS
> Affects Versions: 10.0.0.CR4
> Reporter: James Livingston
> Assignee: Jeff Mesnil
>
> WFLY-4470 made a change to prevent MDBs being activated or deactivated multiple times, but it is not thread safe. A volatile boolean is used for the flag, but there is no protection against multiple threads invoking the methods simultaneously.
> Possible effects include:
> * activating the endpoint twice, with (probably) only one deactivation later, leading to not de-registering XA resources from the recovery manager properly
> * activate() and deactivate() running in the wrong order if done by separate threads
> Several simple solutions probably will not work correctly. Using an AtomicBoolean would stop multiple activations/deactivations from concurrent calls, but would mean that startDelivery() could return before the activation was one. Using a synchronized block or other exclusive lock would work, however since it involves invoking non-container code (the resource adapter), there could potentially be a deadlock risk if that invoked some related container functionality.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5621) Cleanup HornetQ xsd files in "docs/schema" directory
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5621?page=com.atlassian.jira.plugin.... ]
Brian Stansberry edited comment on WFLY-5621 at 11/19/15 9:20 PM:
------------------------------------------------------------------
-jboss-as-messaging_x_y.xsd (server configuration files, replaced by "wildfly-messaging-activemq_1_0.xsd").
This schema is still usable, both in a domain where some slaves can be running earlier releases, and to launch a standalone server in --admin-only mode and then use the migrate op.
If the a - jmx.xml using jboss-as-messaging-deployment_1_0.xsd doesn't work any more, and that itself isn't a bug, I agree it should be dropped.
was (Author: brian.stansberry):
-jboss-as-messaging_x_y.xsd (server configuration files, replaced by "wildfly-messaging-activemq_1_0.xsd").
This schema is still usable, both in a domain where some slaves can be running earlier releases, and to launch a standalone server in --admin-only mode and then use the migrate op.
If the a - jmx.xml using jboss-as-messaging-deployment_1_0.xsd doesn't work any more, I agree it should be dropped.
> Cleanup HornetQ xsd files in "docs/schema" directory
> ----------------------------------------------------
>
> Key: WFLY-5621
> URL: https://issues.jboss.org/browse/WFLY-5621
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR4
> Reporter: Wolfgang Knauf
> Assignee: Jeff Mesnil
> Priority: Minor
>
> The download zip for WildFly 10.0CR4 contains the xsd files for HornetQ messaging configurations in "docs/schema". Those are obsoleted by ActiveMQ and should be removed.
> -jboss-as-messaging-deployment_1_0.xsd (deployment of a "-jms.xml" file according to this old schema will fail with an error anyway), replaced by "wildfly-messaging-activemq-deployment_1_0.xsd")
> -jboss-as-messaging_x_y.xsd (server configuration files, replaced by "wildfly-messaging-activemq_1_0.xsd").
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months