July 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1415) Move away from expensive enum switch

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-1415?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-1415: ----------------------------------- The most important thing to look at are the XML parsers. They use enums for element and attribute names; instead we can just switch and match on the literal string. As for JIRA formatting, click on the circled ? symbol for information on the tags and formatting. It's not HTML. > Move away from expensive enum switch > ------------------------------------ > > Key: WFLY-1415 > URL: https://issues.jboss.org/browse/WFLY-1415 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: David Lloyd > Priority: Minor > Labels: janitor > Fix For: 9.0.0.CR1 > > > We use enums and enum switch extensively. These constructs generate many, many additional classes and bloat the code base unnecessarily. > All cases where we are using enum-based switches for our XML parsers should be converted to use Java 7 String switch instead. The enum values shall be replaced with String constant fields, all enum switches converted to String switches, and all enum types removed from these classes. The net result should be a reduction by dozens if not hundreds of .class files, and possibly a measurable performance boost as well. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3574) management API blocking write requests during initialization

by Michael Mutschler (JIRA)

[ https://issues.jboss.org/browse/WFLY-3574?page=com.atlassian.jira.plugin.... ] Michael Mutschler updated WFLY-3574: ------------------------------------ Steps to Reproduce: In this simple example I try to remove the default ExampleDS (it should fail, but the bug is, that I get no result) Here is the Listener I use: {code:title=ConfigListener.java|borderStyle=dashed} @WebListener public class ConfigListener implements ServletContextListener { @Override public void contextInitialized(ServletContextEvent servletContextEvent) { RemoveExampleDS.run(); } @Override public void contextDestroyed(ServletContextEvent servletContextEvent) {} } {code} RemoveExampleDS has the actual code to remove the Datasource: {code:title=RemoveExampleDS.java|borderStyle=dashed} public class RemoveExampleDS { public static void run() { try { deleteDataSource("ExampleDS"); } catch (IOException e) { log(e); } } private static void deleteDataSource(String dsName) throws IOException { log("removing datasource " + dsName); final ModelNode request = new ModelNode(); request.get(ClientConstants.OP).set(ClientConstants.REMOVE_OPERATION); request.get(ClientConstants.OP_ADDR).add("subsystem", "datasources"); request.get(ClientConstants.OP_ADDR).add("data-source", dsName); execute(request); log("datasource " + dsName + " removed"); } private static void execute(ModelNode request) throws IOException { log("connecting to management"); ModelControllerClient client = ModelControllerClient.Factory.create("localhost", 9990); log("executing: " + request); ModelNode response = client.execute(request); log("response: " + response); client.close(); log(response.get(ClientConstants.RESULT)); } private static void log(Object o) { System.out.println(o); } } {code} I packed this into a war, and it is the only war I am running in a default wildfly installation. The log looks like this. Note: there is no response for the remove! {noformat} 2014-07-02 14:26:54,280 INFO [stdout] (MSC service thread 1-12) removing datasource ExampleDS 2014-07-02 14:26:54,292 INFO [stdout] (MSC service thread 1-12) connecting to management 2014-07-02 14:26:54,317 INFO [stdout] (MSC service thread 1-12) executing: { 2014-07-02 14:26:54,318 INFO [stdout] (MSC service thread 1-12) "operation" => "remove", 2014-07-02 14:26:54,319 INFO [stdout] (MSC service thread 1-12) "address" => [ 2014-07-02 14:26:54,319 INFO [stdout] (MSC service thread 1-12) ("subsystem" => "datasources"), 2014-07-02 14:26:54,319 INFO [stdout] (MSC service thread 1-12) ("data-source" => "ExampleDS") 2014-07-02 14:26:54,320 INFO [stdout] (MSC service thread 1-12) ] 2014-07-02 14:26:54,320 INFO [stdout] (MSC service thread 1-12) } 2014-07-02 14:26:54,344 INFO [org.xnio] (MSC service thread 1-12) XNIO version 3.2.2.Final 2014-07-02 14:26:54,359 INFO [org.xnio.nio] (MSC service thread 1-12) XNIO NIO Implementation Version 3.2.2.Final {noformat} was: In this simple example I try to remove the default ExampleDS (it should fail, but the bug is, that I get no result) Here is the Listener I use: {code:title=ConfigListener.java|borderStyle=dashed} @WebListener public class ConfigListener implements ServletContextListener { @Override public void contextInitialized(ServletContextEvent servletContextEvent) { RemoveExampleDS.run(); } @Override public void contextDestroyed(ServletContextEvent servletContextEvent) {} } {code} RemoveExampleDS has the actual code to remove the Datasource: {code:title=RemoveExampleDS.java|borderStyle=dashed} public class RemoveExampleDS { public static void run() { try { deleteDataSource("ExampleDS"); } catch (IOException e) { log(e); } } private static void deleteDataSource(String dsName) throws IOException { log("removing datasource " + dsName); final ModelNode request = new ModelNode(); request.get(ClientConstants.OP).set(ClientConstants.REMOVE_OPERATION); request.get(ClientConstants.OP_ADDR).add("subsystem", "datasources"); request.get(ClientConstants.OP_ADDR).add("data-source", dsName); execute(request); log("datasource " + dsName + " removed"); } private static void execute(ModelNode request) throws IOException { log("connecting to management"); ModelControllerClient client = ModelControllerClient.Factory.create("localhost", 9990); log("executing: " + request); ModelNode response = client.execute(request); log("response: " + response); client.close(); log(response.get(ClientConstants.RESULT)); } private static void log(Object o) { System.out.println(o); } } {code} I packed this into a war, and it is the only war I am running in a default wildfly installation. The log looks like this. Note: there is no response for the remove! {{ 2014-07-02 14:26:54,280 INFO [stdout] (MSC service thread 1-12) removing datasource ExampleDS 2014-07-02 14:26:54,292 INFO [stdout] (MSC service thread 1-12) connecting to management 2014-07-02 14:26:54,317 INFO [stdout] (MSC service thread 1-12) executing: { 2014-07-02 14:26:54,318 INFO [stdout] (MSC service thread 1-12) "operation" => "remove", 2014-07-02 14:26:54,319 INFO [stdout] (MSC service thread 1-12) "address" => [ 2014-07-02 14:26:54,319 INFO [stdout] (MSC service thread 1-12) ("subsystem" => "datasources"), 2014-07-02 14:26:54,319 INFO [stdout] (MSC service thread 1-12) ("data-source" => "ExampleDS") 2014-07-02 14:26:54,320 INFO [stdout] (MSC service thread 1-12) ] 2014-07-02 14:26:54,320 INFO [stdout] (MSC service thread 1-12) } 2014-07-02 14:26:54,344 INFO [org.xnio] (MSC service thread 1-12) XNIO version 3.2.2.Final 2014-07-02 14:26:54,359 INFO [org.xnio.nio] (MSC service thread 1-12) XNIO NIO Implementation Version 3.2.2.Final }} > management API blocking write requests during initialization > ------------------------------------------------------------ > > Key: WFLY-3574 > URL: https://issues.jboss.org/browse/WFLY-3574 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CLI > Affects Versions: 8.1.0.Final > Environment: default configuration > Reporter: Michael Mutschler > Assignee: Alexey Loubyansky > Priority: Critical > > I want to apply some configuration before the real application is starting. Mainly I want to update a datasource. Therefore I wrote a WebListener, and during the initialization I want to modify the wildfly configuration via management API. > I can read the configuration, but when I want to execute a delete or add request, nothing happens; the command does not return! There seems to be a deadlock. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3574) management API blocking write requests during initialization

by Michael Mutschler (JIRA)

Michael Mutschler created WFLY-3574: --------------------------------------- Summary: management API blocking write requests during initialization Key: WFLY-3574 URL: https://issues.jboss.org/browse/WFLY-3574 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: CLI Affects Versions: 8.1.0.Final Environment: default configuration Reporter: Michael Mutschler Assignee: Alexey Loubyansky Priority: Critical I want to apply some configuration before the real application is starting. Mainly I want to update a datasource. Therefore I wrote a WebListener, and during the initialization I want to modify the wildfly configuration via management API. I can read the configuration, but when I want to execute a delete or add request, nothing happens; the command does not return! There seems to be a deadlock. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2929) Create maven modules to build all the new distributions

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-2929?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-2929. ---------------------------------- Resolution: Done > Create maven modules to build all the new distributions > ------------------------------------------------------- > > Key: WFLY-2929 > URL: https://issues.jboss.org/browse/WFLY-2929 > Project: WildFly > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Build System > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 9.0.0.CR1 > > > This involves creating the following new maven modules: > core-build > web-build > ee-build > clustering-build > These will create distributions that correspond to the output of the split up repositories. The final build step will be changed to merge all these distributions together. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3570) I get NullPointerException when using ManagedScheduledExecutorService.scheduleAtFixedRate

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3570?page=com.atlassian.jira.plugin.... ] Stuart Douglas updated WFLY-3570: --------------------------------- Assignee: Eduardo Martins (was: Jason Greene) Component/s: EE > I get NullPointerException when using ManagedScheduledExecutorService.scheduleAtFixedRate > ----------------------------------------------------------------------------------------- > > Key: WFLY-3570 > URL: https://issues.jboss.org/browse/WFLY-3570 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EE > Reporter: Pavel Abizyaev > Assignee: Eduardo Martins > > When I try to run a task with a small period (1 second or less) using ManagedScheduledExecutorService.scheduleAtFixedRate sometimes I get NullPointerException at http://grepcode.com/file/repo1.maven.org/maven2/org.wildfly/wildfly-ee/8.... line 167 (resetHandles is null). I think it occurs when a next task has run before a previous finishes. On 8.1.0 I have the same problem. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3572) Deployment Overlay feature is not able to add jar files for resource adapter (rar) deployments

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3572?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-3572: -------------------------------------- What is the error that you see? > Deployment Overlay feature is not able to add jar files for resource adapter (rar) deployments > ---------------------------------------------------------------------------------------------- > > Key: WFLY-3572 > URL: https://issues.jboss.org/browse/WFLY-3572 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 8.1.0.Final > Reporter: Lyle Wang > Assignee: Stuart Douglas > Attachments: wmq.jmsra.rar > > > According to WFLY-1359[1], we should be able to add a jar for an existing deployment. > Testing against WildFly 8.1.0 Final, the deployment-overlay feature reports errors on adding a new .jar for a .rar resource adapter deployment. > [1] - https://issues.jboss.org/browse/WFLY-1359 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3572) Deployment Overlay feature is not able to add jar files for resource adapter (rar) deployments

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3572?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-3572: ------------------------------------ Assignee: Stuart Douglas (was: Jason Greene) > Deployment Overlay feature is not able to add jar files for resource adapter (rar) deployments > ---------------------------------------------------------------------------------------------- > > Key: WFLY-3572 > URL: https://issues.jboss.org/browse/WFLY-3572 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 8.1.0.Final > Reporter: Lyle Wang > Assignee: Stuart Douglas > Attachments: wmq.jmsra.rar > > > According to WFLY-1359[1], we should be able to add a jar for an existing deployment. > Testing against WildFly 8.1.0 Final, the deployment-overlay feature reports errors on adding a new .jar for a .rar resource adapter deployment. > [1] - https://issues.jboss.org/browse/WFLY-1359 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-537) Use maven plugins (animal-sniffer?) to ensure that code and dependencies conform to the supported minimum version

by Marco Rietveld (JIRA)

Marco Rietveld created DROOLS-537: ------------------------------------- Summary: Use maven plugins (animal-sniffer?) to ensure that code and dependencies conform to the supported minimum version Key: DROOLS-537 URL: https://issues.jboss.org/browse/DROOLS-537 Project: Drools Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 6.1.0.CR1 Reporter: Marco Rietveld Assignee: Michael Biarnes Kiefer Every now and then, one of us uses syntax or a class from a higher version of Java than what we use. Or otherwise, one of us will use a dependency that's been compiled in Java X+1 while the build is based on Java X. Can we prevent discovering these mistakes too late by using the animal-sniffer plugin? One of the more important points here is that using the animal-sniffer (or another plugin that can be used for this) must *not* significantly delay or prolong the build! -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3573) Adding incorrect JGroups protocol should provide better error description than CNFE

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3573?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-3573: --------------------------------- Priority: Minor (was: Major) > Adding incorrect JGroups protocol should provide better error description than CNFE > ----------------------------------------------------------------------------------- > > Key: WFLY-3573 > URL: https://issues.jboss.org/browse/WFLY-3573 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: JBoss AS7 7.2.0.Final, 8.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > Fix For: 9.0.0.CR1 > > > As reported by the community user: > {noformat} > [standalone@localhost:9990 / #] list-batch > #1 /subsystem=jgroups/stack=test:add() > #2 /subsystem=jgroups/stack=test/transport=TRANSPORT:add(type="udp",socket-binding=jgroups-udp) > #3 /subsystem=jgroups/stack=test:add-protocol(type=FD_SOCK,socket-binding=jgroups-udp-fd) > [standalone@localhost:9990 / #] run-batch > The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0158: Operation handler failed: java.lang.ClassNotFoundException: org.jgroups.protocols.udp from [Module \"org.jboss.as.clustering.jgroups:main\" from local module loader @4d9f6ce5 (finder: local module finder @1da65633 (roots: /home/rhusar/as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules,/home/rhusar/as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]"}} > [standalone@localhost:9990 / #] > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3573) Adding incorrect JGroups protocol should provide better error description than CNFE

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-3573: ------------------------------------ Summary: Adding incorrect JGroups protocol should provide better error description than CNFE Key: WFLY-3573 URL: https://issues.jboss.org/browse/WFLY-3573 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Affects Versions: 8.1.0.Final, JBoss AS7 7.2.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar Fix For: 9.0.0.CR1 As reported by the community user: {noformat} [standalone@localhost:9990 / #] list-batch #1 /subsystem=jgroups/stack=test:add() #2 /subsystem=jgroups/stack=test/transport=TRANSPORT:add(type="udp",socket-binding=jgroups-udp) #3 /subsystem=jgroups/stack=test:add-protocol(type=FD_SOCK,socket-binding=jgroups-udp-fd) [standalone@localhost:9990 / #] run-batch The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0158: Operation handler failed: java.lang.ClassNotFoundException: org.jgroups.protocols.udp from [Module \"org.jboss.as.clustering.jgroups:main\" from local module loader @4d9f6ce5 (finder: local module finder @1da65633 (roots: /home/rhusar/as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules,/home/rhusar/as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]"}} [standalone@localhost:9990 / #] {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 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 2014