July 2014 - jboss-jira - Jboss List Archives

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

by Chris Kujawa (JIRA)

[ https://issues.jboss.org/browse/WFLY-1415?page=com.atlassian.jira.plugin.... ] Chris Kujawa commented on WFLY-1415: ------------------------------------ I'd like to take a look at this one, but I want to make sure I fully understand what's being asked for first. Is the approach of grabbing the name of the enum being used at the top then comparing to String constants acceptable...something like this: public static final String COOKIE_MODE = "COOKIE"; ... for (SessionTrackingModeType mode : modes) { String mode_string = mode.name(); switch (mode_string) { case COOKIE_MODE: trackingModes.add(SessionTrackingMode.COOKIE); break; ... or are you actually looking to replace the enums altogether? BTW, I apologize for the formatting...tried to add <code> tags to the above block and they didn't seem to have an affect. > 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)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3304) RemoteDomainConnectionService.fetchDomainWideConfiguration() isn't properly implemented

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3304?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3304: ----------------------------------------------- Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1093866|https://bugzilla.redhat.com/show_bug.cgi?id=1093866] from ON_QA to VERIFIED > RemoteDomainConnectionService.fetchDomainWideConfiguration() isn't properly implemented > --------------------------------------------------------------------------------------- > > Key: WFLY-3304 > URL: https://issues.jboss.org/browse/WFLY-3304 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final, 8.1.0.CR1 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 9.0.0.Alpha1 > > > The WFLY-2043 implementation is not working correctly because fetching the config from the master without fully registering is not properly implemented. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3349) Pull cosmetic schema changes from EAP to WildFly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3349?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3349: ----------------------------------------------- Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1097311|https://bugzilla.redhat.com/show_bug.cgi?id=1097311] from ON_QA to VERIFIED > Pull cosmetic schema changes from EAP to WildFly > ------------------------------------------------ > > Key: WFLY-3349 > URL: https://issues.jboss.org/browse/WFLY-3349 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3495) /subsystem=transactions/log-store=log-store type attribute should be read-only

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3495?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3495: ----------------------------------------------- Ondrej Chaloupka <ochaloup(a)redhat.com> changed the Status of [bug 1010847|https://bugzilla.redhat.com/show_bug.cgi?id=1010847] from ON_QA to VERIFIED > /subsystem=transactions/log-store=log-store type attribute should be read-only > ------------------------------------------------------------------------------ > > Key: WFLY-3495 > URL: https://issues.jboss.org/browse/WFLY-3495 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Stefano Maestri > Assignee: Jason Greene > Fix For: 9.0.0.Alpha1 > > > There is non-standard behavior of log-store "address" in jboss-cli. > If you want to change log store type via jboss-cli I suppose that supposed way is via command like: > /subsystem=transactions:write-attribute(name=use-hornetq-store, value=true) > similarly with jdbc store. > But there is a second way how to get name the transaction object store in use: > /subsystem=transactions/log-store=log-store:read-attribute(name=type) > But when you try to set the type via this way: > /subsystem=transactions/log-store=log-store:write-attribute(name=type, value=hornetq) > you'll get operation success > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > but no change in the model is realized. > There should be some info to user that this way is not supported or this way should correctly work. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3324) POJO objects are not removed from logging.properties when manually removing them from JBoss Config XML

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3324?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3324: ----------------------------------------------- Nikoleta Ziakova <nziakova(a)redhat.com> changed the Status of [bug 1095516|https://bugzilla.redhat.com/show_bug.cgi?id=1095516] from ON_QA to VERIFIED > POJO objects are not removed from logging.properties when manually removing them from JBoss Config XML > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-3324 > URL: https://issues.jboss.org/browse/WFLY-3324 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Affects Versions: 8.1.0.CR1 > Reporter: Kyle Lape > Assignee: James Perkins > Fix For: 8.1.0.CR2, 8.1.0.Final > > > If I remove a custom Log4J appender from my standalone.xml and restart JBoss, I can still see the POJO definition for the removed appender in my {{logging.properties}} file. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-1309) CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1309?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1309: ----------------------------------------------- Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1110065|https://bugzilla.redhat.com/show_bug.cgi?id=1110065] from ON_QA to VERIFIED > CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode > ------------------------------------------------------------------------------------------------------------ > > Key: WFLY-1309 > URL: https://issues.jboss.org/browse/WFLY-1309 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Alpha1 > Environment: wildfly build from a git clone on 2013-05-02 > Reporter: Tom Fonteyne > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.CR1 > > Attachments: host-domain-controller.xml, host-slave.xml > > > Setup two boxes: > - on one, run domain mode (full-ha) -> domain controller > - on the other, configure host.xml to point to the DC, and run the host controller > Now in CLI: > # add the group: > /server-group=slaves:add(profile=full-ha,socket-binding-group=full-ha-sockets) > # create server and set a prop > batch > /host=slave1/server-config=i1:add(group=slaves,auto-start=false) > /host=slave1/server-config=i1/system-property=env:add(value=dev) > run-batch > results in: > JBAS010839: Operation failed or was rolled back on all servers. > Debugging (on EAP 6.0.1) showed the real reason: > activeStep.response = (org.jboss.dmr.ModelNode) { > "outcome" => "failed", > "failure-description" => "JBAS010850: No handler for operation > composite at address [ > (\"host\" => \"slave1\"), > (\"server\" => \"i1\") > ]", > "rolled-back" => true > } > More debugging led to : > org.jboss.as.controller.AbstractOperationContext > seems to be where the rollback is set. When debugging, I found that the constructor always sets > ModelController.OperationTransactionControl transactionControl > but at line 332 (eap 6.0.1) / line 372 (wildfly), the end of doCompleteStep() : > // Allow any containing TransactionControl to vote > final AtomicReference<ResultAction> ref = new AtomicReference<ResultAction>(transactionControl == null ? ResultAction.KEEP : ResultAction.ROLLBACK); > and ref becomes a rollback. > I "walked" pretty much of all the code going on in between. The bit where the config is getting persisted is successful. > But I'm afraid I'm out of my depth as there is *a lot* going on to execute such a composite command :) -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3572?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3572: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1110635 > 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: Jason Greene > 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)

12 years

1
0
0 / 0

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

by Lyle Wang (JIRA)

[ https://issues.jboss.org/browse/WFLY-3572?page=com.atlassian.jira.plugin.... ] Lyle Wang updated WFLY-3572: ---------------------------- Attachment: wmq.jmsra.rar > 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: Jason Greene > 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)

12 years

1
0
0 / 0

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

by Lyle Wang (JIRA)

Lyle Wang created WFLY-3572: ------------------------------- Summary: 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: Jason Greene 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)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3227) Replace batching="true|false" with <transaction mode="BATCH"/> in infinispan subsystem schema/model

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-3227?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-3227: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/6470 (was: https://github.com/wildfly/wildfly/pull/6469) > Replace batching="true|false" with <transaction mode="BATCH"/> in infinispan subsystem schema/model > --------------------------------------------------------------------------------------------------- > > Key: WFLY-3227 > URL: https://issues.jboss.org/browse/WFLY-3227 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 8.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 9.0.0.CR1 > > > Currently, one enables use of Infinispan batching via the batching="true" attribute. The implications of batching have evolved over time, but currently batching uses the BatchModeTransactionManager, which makes it incompatible with a <transaction mode="..."/> other than NONE. > To resolve this mutual incompatibility and to remove any ambiguity, I propose replacing the batching attribute with a new transaction mode, i.e. <transaction mode="BATCH"/>. > The complete list of transaction modes would now be: > NONE: the cache is not configured with a transaction manager > BATCH: the cache is configured with a BatchModeTransactionManager > NON_XA: the cache is configured with WF's transaction manager, but will interact via Synchronizations > NON_DURABLE_XA: the cache is configured with WF's transaction manager and will interact via an XAResource w/out recovery. > FULL_XA: the cache is configured with WF's transaction manager and will interact via an XAResource w/recovery. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

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