July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9

by Marco Rietveld (JIRA)

[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ] Marco Rietveld reassigned DROOLS-355: ------------------------------------- Assignee: Petr Široký (was: Marco Rietveld) > Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9 > ------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-355 > URL: https://issues.jboss.org/browse/DROOLS-355 > Project: Drools > Issue Type: Task > Affects Versions: 6.0.0.Final > Reporter: Geoffrey De Smet > Assignee: Petr Široký > Priority: Blocker > > By importing com.sun.tools.xjc, 3 problems arise: > * OSGi and Karaf trip over it. > {code} > [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final) > {code} > * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013. > * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this? > Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now. > Where do we use it? > {code} > Targets > String 'com.sun.tools.xjc' > Found usages (38 usages found) > drools-compiler (7 usages found) > /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found) > pom.xml (1 usage found) > (246: 15) com.sun.tools.xjc.*;resolution:=optional, > org.drools.compiler.builder.impl (1 usage found) > KnowledgeBuilderFactoryServiceImpl.java (1 usage found) > (18: 8) import com.sun.tools.xjc.Options; > org.drools.compiler.runtime.pipeline.impl (5 usages found) > DroolsJaxbHelperProviderImpl.java (5 usages found) > (77: 8) import com.sun.tools.xjc.BadCommandLineException; > (78: 8) import com.sun.tools.xjc.ErrorReceiver; > (79: 8) import com.sun.tools.xjc.ModelLoader; > (80: 8) import com.sun.tools.xjc.Options; > (81: 8) import com.sun.tools.xjc.model.Model; > drools-core (2 usages found) > org.drools.core.builder.conf.impl (2 usages found) > JaxbConfigurationImpl.java (2 usages found) > (28: 8) import com.sun.tools.xjc.Language; > (34: 8) import com.sun.tools.xjc.Options; > kie-internal (6 usages found) > /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found) > pom.xml (1 usage found) > (27: 15) com.sun.tools.xjc;resolution:=optional, > org.kie.internal.builder (3 usages found) > JaxbConfiguration.java (1 usage found) > (23: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderFactory.java (1 usage found) > (24: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderFactoryService.java (1 usage found) > (24: 8) import com.sun.tools.xjc.Options; > org.kie.internal.builder.help (2 usages found) > DroolsJaxbHelperProvider.java (1 usage found) > (29: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderHelper.java (1 usage found) > (30: 8) import com.sun.tools.xjc.Options; > knowledge-api (8 usages found) > org.drools.builder (3 usages found) > JaxbConfiguration.java (1 usage found) > (21: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderFactory.java (1 usage found) > (24: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderFactoryService.java (1 usage found) > (24: 8) import com.sun.tools.xjc.Options; > org.drools.builder.help (3 usages found) > DroolsJaxbHelperProvider.java (1 usage found) > (29: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderHelper.java (2 usages found) > (32: 8) import com.sun.tools.xjc.Language; > (33: 8) import com.sun.tools.xjc.Options; > org.drools.impl (1 usage found) > KnowledgeBuilderFactoryServiceImpl.java (1 usage found) > (16: 8) import com.sun.tools.xjc.Options; > org.drools.impl.adapters (1 usage found) > JaxbConfigurationAdapter.java (1 usage found) > (3: 8) import com.sun.tools.xjc.Options; > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6660) Allow to dump Artemis journal to file by CLI operation

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFLY-6660?page=com.atlassian.jira.plugin.... ] Miroslav Novak commented on WFLY-6660: -------------------------------------- [~jmesnil] Clebert added force option so journal can be dumped during runtime - https://issues.apache.org/jira/browse/ARTEMIS-599 > Allow to dump Artemis journal to file by CLI operation > ------------------------------------------------------ > > Key: WFLY-6660 > URL: https://issues.jboss.org/browse/WFLY-6660 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > Attachments: journal.txt > > > For debugging and investigation purposes it would useful to have CLI operation which would dump content of Artemis journal directory. > New CLI operation like {{print-journal-date-content}} would print content of journal to a file. > It would do the same thing like following Artemis CLI command: > {code} > .../activemq-artemis/artemis-distribution/target/apache-artemis-1.3.0-SNAPSHOT-bin/apache-artemis-1.3.0-SNAPSHOT/bin/artemis data print --bindings bindings --journal journal --paging paging --large-messages largemessages > {code} > This should work only in Admin only mode as dumping journal in run-time is not possible when data changes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2052) Timer: make timer thread pool and timer queue configurable

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2052?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2052: --------------------------- Summary: Timer: make timer thread pool and timer queue configurable (was: Timer: make queue configurable) > Timer: make timer thread pool and timer queue configurable > ---------------------------------------------------------- > > Key: JGRP-2052 > URL: https://issues.jboss.org/browse/JGRP-2052 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > Currently the timer thread pool always has the queue enabled; the user can only define a max queue size. > Change this to make a queue configurable, e.g. if we want a 0 or 1 min core threads size and a large max-size, and no queue enabled. > This would enable users to play with small timer thread pool sizes; as a matter of fact, there would be _no timer threads_ if no tasks are running. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2089) Potential deadlocks after cluster split

by Bram Klein Gunnewiek (JIRA)

[ https://issues.jboss.org/browse/JGRP-2089?page=com.atlassian.jira.plugin.... ] Bram Klein Gunnewiek updated JGRP-2089: --------------------------------------- Description: We encountered deadlocks in some rare situations where a cluster split and/or merged. The dealocks happend when using the UDP transport protocol and where caused by received lock requests from members not present in the current view. We fixed this with: https://github.com/belaban/JGroups/pull/311 was: We encountered in some rare situations where a cluster split and/or merged. The dealocks happend when using the UDP transport protocol and where caused by received lock requests from members not present in the current view. We fixed this with: https://github.com/belaban/JGroups/pull/311 > Potential deadlocks after cluster split > --------------------------------------- > > Key: JGRP-2089 > URL: https://issues.jboss.org/browse/JGRP-2089 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.10 > Reporter: Bram Klein Gunnewiek > Assignee: Bela Ban > Fix For: 3.6.11, 4.0 > > > We encountered deadlocks in some rare situations where a cluster split and/or merged. The dealocks happend when using the UDP transport protocol and where caused by received lock requests from members not present in the current view. > We fixed this with: https://github.com/belaban/JGroups/pull/311 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2089) Potential deadlocks after cluster split

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2089?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2089: --------------------------- Fix Version/s: 3.6.11 4.0 > Potential deadlocks after cluster split > --------------------------------------- > > Key: JGRP-2089 > URL: https://issues.jboss.org/browse/JGRP-2089 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.10 > Reporter: Bram Klein Gunnewiek > Assignee: Bela Ban > Fix For: 3.6.11, 4.0 > > > We encountered in some rare situations where a cluster split and/or merged. The dealocks happend when using the UDP transport protocol and where caused by received lock requests from members not present in the current view. > We fixed this with: https://github.com/belaban/JGroups/pull/311 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2042) Improve performance of Message#writeHeader

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2042?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2042: -------------------------------- This has not been backported to 3.6 though, so you'd have to change Infinispan to use 4.0... I will port Infinispan to use 4.0 in a few weeks and run benchmarks then. > Improve performance of Message#writeHeader > ------------------------------------------ > > Key: JGRP-2042 > URL: https://issues.jboss.org/browse/JGRP-2042 > Project: JGroups > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > The following stacktrace, taken with JFR, is highlighting a CPU consumer which could be optimised. > {noformat}Stack Trace Sample Count Percentage(%) > java.util.IdentityHashMap.get(Object) 66 2.224 > org.jgroups.conf.ClassConfigurator.getMagicNumber(Class) 66 2.224 > org.jgroups.Message.writeHeader(Header, DataOutput) 66 2.224 > {noformat} > One idea could be to use an ad-hoc implementation of Map which takes advantage of the key being a {{Class}}. An interesting alternative would be to avoid the map lookup altogether, by having the Header expose a method like "writeMagicNumber(DataInput to)". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2089) Potential deadlocks after cluster split

by Bram Klein Gunnewiek (JIRA)

Bram Klein Gunnewiek created JGRP-2089: ------------------------------------------ Summary: Potential deadlocks after cluster split Key: JGRP-2089 URL: https://issues.jboss.org/browse/JGRP-2089 Project: JGroups Issue Type: Feature Request Affects Versions: 3.6.10 Reporter: Bram Klein Gunnewiek Assignee: Bela Ban We encountered in some rare situations where a cluster split and/or merged. The dealocks happend when using the UDP transport protocol and where caused by received lock requests from members not present in the current view. We fixed this with: https://github.com/belaban/JGroups/pull/311 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2089) Potential deadlocks after cluster split

by Bram Klein Gunnewiek (JIRA)

[ https://issues.jboss.org/browse/JGRP-2089?page=com.atlassian.jira.plugin.... ] Bram Klein Gunnewiek updated JGRP-2089: --------------------------------------- Issue Type: Bug (was: Feature Request) > Potential deadlocks after cluster split > --------------------------------------- > > Key: JGRP-2089 > URL: https://issues.jboss.org/browse/JGRP-2089 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.10 > Reporter: Bram Klein Gunnewiek > Assignee: Bela Ban > > We encountered in some rare situations where a cluster split and/or merged. The dealocks happend when using the UDP transport protocol and where caused by received lock requests from members not present in the current view. > We fixed this with: https://github.com/belaban/JGroups/pull/311 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6779) Add WISE for Web console access

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/WFLY-6779?page=com.atlassian.jira.plugin.... ] Rostislav Svoboda updated WFLY-6779: ------------------------------------ Git Pull Request: https://github.com/wildfly/wildfly/pull/8998 > Add WISE for Web console access > ------------------------------- > > Key: WFLY-6779 > URL: https://issues.jboss.org/browse/WFLY-6779 > Project: WildFly > Issue Type: Feature Request > Components: Web Console > Reporter: R Searls > Assignee: R Searls > Priority: Minor > > Wise is a Java framework for easily invoking webservices, which can be used as base for zero-code webservice invocation applications. (see http://wise.jboss.org/) > Based upon Brian Stansberry's advise WISE is added to wfly using the "Mixed-Approach" > for adding a feature. > Once this is available in wfly. HAL can provide a link to it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1657) Confusing tab completion for adding a module dependencies

by Bartosz Spyrko-Śmietanko (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1657?page=com.atlassian.jira.plugi... ] Bartosz Spyrko-Śmietanko moved JBEAP-5221 to WFCORE-1657: --------------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1657 (was: JBEAP-5221) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: CLI (was: CLI) Affects Version/s: 2.2.0.CR7 3.0.0.Alpha3 (was: 7.0.0.GA) > Confusing tab completion for adding a module dependencies > --------------------------------------------------------- > > Key: WFCORE-1657 > URL: https://issues.jboss.org/browse/WFCORE-1657 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 2.2.0.CR7, 3.0.0.Alpha3 > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Bartosz Spyrko-Śmietanko > > Using tab completion for adding a module dependencies with {{module add}} command could lead to invalid module.xml as CLI prompt user to use module name with "system.layers.base" prefix, which is not a part of module name. > *reproduce* > Add a new module via {{module add}} command, use tab-completion for dependencies > {noformat} > module add --name=<name> --resources=<path_to_jar> --dependencies=<TAB> > module add --name=<name> --resources=<path_to_jar> --dependencies=system.<TAB> > module add --name=<name> --resources=<path_to_jar> --dependencies=system.layers.<TAB> > module add --name=<name> --resources=<path_to_jar> --dependencies=system.layers.base.<TAB> > asm ch com gnu ibm io javaee javax net nu org sun > {noformat} > this way something like following is generated in module.xml file > {code:xml} > <dependencies> > <module name="system.layers.base.org.jboss.as.controller"/> > </dependencies> > {code} > however correct module name is {{org.jboss.as.controller}} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

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 July 2016