January 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6408) Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT

by Bernd Koecke (JIRA)

[ https://issues.jboss.org/browse/AS7-6408?page=com.atlassian.jira.plugin.s... ] Bernd Koecke updated AS7-6408: ------------------------------ Attachment: standalone-ha-jgroups.cli standalone-jgroups-fragment.xml The *.cli file contains the commands which I send to the running server. The *.xml file contains the subsystem configuration from standalone.xml after the batch was run successfully. > Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT > --------------------------------------------------------------------------- > > Key: AS7-6408 > URL: https://issues.jboss.org/browse/AS7-6408 > Project: Application Server 7 > Issue Type: Bug > Components: Clustering > Affects Versions: 7.2.0.Alpha1 > Environment: Git checkout of JBossAS 7.2.0.ALPHA1 from today (28/Jan/2013) > Reporter: Bernd Koecke > Assignee: Paul Ferraro > Attachments: standalone-ha-jgroups.cli, standalone-jgroups-fragment.xml > > > When I try to configure extension and subsystem JGroups with a CLI script, the attribute "protocols" of the stack=tcp- or stack=udp-node contains the list of configured protocols twice. The result is that the list of protocols is doubled in the standalone.xml. But having a protocol twice in one stack results in an error at next server startup. I will attach the CLI script and the resulting XML fragment. > When I shutdown the server, remove the doubled second part of each protocol list, the server comes up and all is working fine. But I can't configure it only with a CLI script. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6408) Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT

by Bernd Koecke (JIRA)

Bernd Koecke created AS7-6408: --------------------------------- Summary: Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT Key: AS7-6408 URL: https://issues.jboss.org/browse/AS7-6408 Project: Application Server 7 Issue Type: Bug Components: Clustering Affects Versions: 7.2.0.Alpha1 Environment: Git checkout of JBossAS 7.2.0.ALPHA1 from today (28/Jan/2013) Reporter: Bernd Koecke Assignee: Paul Ferraro When I try to configure extension and subsystem JGroups with a CLI script, the attribute "protocols" of the stack=tcp- or stack=udp-node contains the list of configured protocols twice. The result is that the list of protocols is doubled in the standalone.xml. But having a protocol twice in one stack results in an error at next server startup. I will attach the CLI script and the resulting XML fragment. When I shutdown the server, remove the doubled second part of each protocol list, the server comes up and all is working fine. But I can't configure it only with a CLI script. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (EJBTHREE-2294) Application exception lost if thrown in method annotated with @PostConstruct

by Matti Linnanvuori (JIRA)

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (EJBTHREE-2294) Application exception lost if thrown in method annotated with @PostConstruct

by Matti Linnanvuori (JIRA)

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (EJBTHREE-2294) Application exception lost if thrown in method annotated with @PostConstruct

by Matti Linnanvuori (JIRA)

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-980) It should be an exception thrown, if administered object class, that implements more than one interface, isn't explicitly marked with adminObjectInterfaces annotation

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-980?page=com.atlassian.jira.plugin.... ] Jesper Pedersen updated JBJCA-980: ---------------------------------- Priority: Minor (was: Major) > It should be an exception thrown, if administered object class, that implements more than one interface, isn't explicitly marked with adminObjectInterfaces annotation > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBJCA-980 > URL: https://issues.jboss.org/browse/JBJCA-980 > Project: IronJacamar > Issue Type: Bug > Components: Validator > Affects Versions: 1.0.15.Final, 1.1.0.Beta3 > Reporter: Vladimir Rastseluev > Assignee: Jesper Pedersen > Priority: Minor > Fix For: 1.0.16.Final, 1.1.0.Beta4 > > > Due to JCA 1.6 spec. page 18-16, > If the JavaBean class implements more than one Java interface, the resource > adapter provider must explicitly state the interfaces supported by the > administered object either through the adminObjectInterfaces annotation > element or through the deployment descriptor. It is an error if the resource > adapter provider does not use either of the two schemes to specify the Java types > of the interfaces supported by the administered object. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-981) Wrong validator rule "Section: 13.4.2.2 Description: An ActivationSpec class must implement the ActivationSpec interface" in case of @Activation annotation applied

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-981?page=com.atlassian.jira.plugin.... ] Jesper Pedersen closed JBJCA-981. --------------------------------- Resolution: Rejected Error in spec text - remove test > Wrong validator rule "Section: 13.4.2.2 Description: An ActivationSpec class must implement the ActivationSpec interface" in case of @Activation annotation applied > -------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBJCA-981 > URL: https://issues.jboss.org/browse/JBJCA-981 > Project: IronJacamar > Issue Type: Bug > Reporter: Vladimir Rastseluev > Assignee: Jesper Pedersen > > Due to JCA 1.6 spec. page 18-14, > The JavaBean is not required to implement the javax.resource.spi.ActivationSpec interface if the JavaBean is annotated with the Activation annotation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-1805) Empty directories under "tmp/vfs" keeps on growing between server restarts

by Taras Tielkes (JIRA)

[ https://issues.jboss.org/browse/AS7-1805?page=com.atlassian.jira.plugin.s... ] Taras Tielkes commented on AS7-1805: ------------------------------------ We still see this in 7.1.3-Final > Empty directories under "tmp/vfs" keeps on growing between server restarts > -------------------------------------------------------------------------- > > Key: AS7-1805 > URL: https://issues.jboss.org/browse/AS7-1805 > Project: Application Server 7 > Issue Type: Bug > Components: VFS > Affects Versions: 7.0.1.Final > Reporter: Ramesh Reddy > Assignee: David Lloyd > > When you have active deployment deployed to the server and you are restarting server for various reasons, the tmp/vfs keeps on growing with empty directories. It deletes the contents under the directory but not the directory itself. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6407) security xxx-module child resource to xxx-modules attribute transformation

by Kabir Khan (JIRA)

Kabir Khan created AS7-6407: ------------------------------- Summary: security xxx-module child resource to xxx-modules attribute transformation Key: AS7-6407 URL: https://issues.jboss.org/browse/AS7-6407 Project: Application Server 7 Issue Type: Feature Request Components: Security Reporter: Kabir Khan Assignee: Tomaz Cerar Fix For: 7.2.0.Alpha1 /subsystem=security/security-domain=other/authentication=classic/login-module=Remoting:write-attribute(name=flag,value=required) should become /subsystem=security/security-domain=other/authentication=classic/login-modules:write-attribute(name=Remoting, value = {whole-attribute-model}) add seems handled, need something similar for undefine-attribute and xxx-module=*:remove -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-4529) a "failure-causes-rollback="false"" attribute for the filesystem scanner

by ma shaohui (JIRA)

[ https://issues.jboss.org/browse/AS7-4529?page=com.atlassian.jira.plugin.s... ] ma shaohui commented on AS7-4529: --------------------------------- this problem got me there > a "failure-causes-rollback="false"" attribute for the filesystem scanner > ------------------------------------------------------------------------ > > Key: AS7-4529 > URL: https://issues.jboss.org/browse/AS7-4529 > Project: Application Server 7 > Issue Type: Feature Request > Components: Domain Management > Reporter: Max Rydahl Andersen > Fix For: 7.3.0.Alpha1 > > > JBIDE-11509, AS7-783 and TORQUE-576 all talk about the problem of all deployments found at startup is deployed in one operation and if one deployment fails all is rolled back resulting in some rather bad usability issues - especially at development time, but even also at production time for those using file deployments. > Suggestion on irc was that there could be an option on the file scanner (possibly false by default?) to say that failure causes rollback. > Individual deployments could then still fail, but at least not everything would be rolledback and it would still allow proper interdependent deployments to work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 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 January 2013