April 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-4496) Jboss 7.1.1 Final StartException on Domain Mode in Windows XP, It shows "Brontes" Starting

by Paul Chan (JIRA)

Paul Chan created AS7-4496: ------------------------------ Summary: Jboss 7.1.1 Final StartException on Domain Mode in Windows XP, It shows "Brontes" Starting Key: AS7-4496 URL: https://issues.jboss.org/browse/AS7-4496 Project: Application Server 7 Issue Type: Bug Components: Clustering Affects Versions: 7.1.1.Final Environment: Maser on Windows 7 and Slave on Windows XP SP2 Reporter: Paul Chan Assignee: Paul Ferraro Maser on Windows 7 and Slave on Windows XP SP2. Master has started without any error on windows 7. when i start slave on windows xp, it is registered with master but all the servers on slave are not starting. it shows "Brontes" starting. CNTR+C(stopping) gives the error below Server:server-one] 10:00:26,859 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.as: org.jboss.msc.service.S tartException in service jboss.as: Failed to start service [Server:server-one] at org.jboss.msc.service.ServiceControllerImpl$StartTask .run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.runTas k(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31] [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(Th readPoolExecutor.java:908) [rt.jar:1.6.0_31] [Server:server-one] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_3 1] [Server:server-one] Caused by: java.lang.IllegalStateException: Container is dow n [Server:server-one] at org.jboss.msc.service.ServiceContainerImpl.install(Se rviceContainerImpl.java:508) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] [Server:server-one] at org.jboss.msc.service.ServiceTargetImpl.install(Servi ceTargetImpl.java:201) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] [Server:server-one] at org.jboss.msc.service.ServiceControllerImpl$ChildServ iceTarget.install(ServiceControllerImpl.java:2228) [jboss-msc-1.0.2.GA.jar:1.0.2 .GA] [Server:server-one] at org.jboss.msc.service.ServiceBuilderImpl.install(Serv iceBuilderImpl.java:307) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] [Server:server-one] at org.jboss.as.server.DomainServerMain.addCommunication Services(DomainServerMain.java:192) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final ] [Server:server-one] at org.jboss.as.server.DomainServerMain.access$000(Domai nServerMain.java:73) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final] [Server:server-one] at org.jboss.as.server.DomainServerMain$HostControllerCo mmunicationActivator.activate(DomainServerMain.java:227) [jboss-as-server-7.1.1. Final.jar:7.1.1.Final] [Server:server-one] at org.jboss.as.server.ApplicationServerService.start(Ap plicationServerService.java:155) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final] [Server:server-one] at org.jboss.msc.service.ServiceControllerImpl$StartTask .startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] [Server:server-two] 10:00:26,843 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.as: org.jboss.msc.service.S tartException in service jboss.as: Failed to start service [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask .run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] [Server:server-two] at java.util.concurrent.ThreadPoolExecutor$Worker.runTas k(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31] [Server:server-two] at java.util.concurrent.ThreadPoolExecutor$Worker.run(Th readPoolExecutor.java:908) [rt.jar:1.6.0_31] [Server:server-two] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_3 1] [Server:server-two] Caused by: java.lang.IllegalStateException: Container is dow n [Server:server-one] at org.jboss.msc.service.ServiceControllerImpl$StartTask .run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] [Server:server-one] ... 3 more [Server:server-one] [Server:server-two] at org.jboss.msc.service.ServiceContainerImpl.install(Se rviceContainerImpl.java:508) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] [Server:server-two] at org.jboss.msc.service.ServiceTargetImpl.install(Servi ceTargetImpl.java:201) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$ChildServ iceTarget.install(ServiceControllerImpl.java:2228) [jboss-msc-1.0.2.GA.jar:1.0.2 .GA] [Server:server-two] at org.jboss.msc.service.ServiceBuilderImpl.install(Serv iceBuilderImpl.java:307) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] [Server:server-two] at org.jboss.as.server.DomainServerMain.addCommunication Services(DomainServerMain.java:192) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final ] [Server:server-two] at org.jboss.as.server.DomainServerMain.access$000(Domai nServerMain.java:73) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final] 10:00:26,953 INFO [org.jboss.as.process.Server:server-one.status] (reaper for S erver:server-one) JBAS012010: Process 'Server:server-one' finished with an exit status of 0 [Server:server-two] at org.jboss.as.server.DomainServerMain$HostControllerCo mmunicationActivator.activate(DomainServerMain.java:227) [jboss-as-server-7.1.1. Final.jar:7.1.1.Final] [Server:server-two] at org.jboss.as.server.ApplicationServerService.start(Ap plicationServerService.java:155) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final] [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask .startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask .run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] [Server:server-two] ... 3 more [Server:server-two] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-4494) When deploying an ear file, VFS

by Thomas Smith (JIRA)

Thomas Smith created AS7-4494: --------------------------------- Summary: When deploying an ear file, VFS Key: AS7-4494 URL: https://issues.jboss.org/browse/AS7-4494 Project: Application Server 7 Issue Type: Bug Components: Class Loading, VFS Affects Versions: 7.1.1.Final Reporter: Thomas Smith Assignee: David Lloyd When resolving classpath entries in an ear file the org.jboss.as.server.deployment.module.ManifestClassPathProcessor calls resourceRoot.getRoot().getParent(), which returns an incorrect path (bin/content); causing it to not find the classpath jars. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-792) Include ValidatingManagedConnectionFactory information

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-792: ------------------------------------- Summary: Include ValidatingManagedConnectionFactory information Key: JBJCA-792 URL: https://issues.jboss.org/browse/JBJCA-792 Project: IronJacamar Issue Type: Task Components: AS Reporter: Jesper Pedersen Assignee: Jeff Zhang Include information if a ManagedConnectionFactory implements the javax.resource.spi.ValidatingManagedConnectionFactory interface in the resource adapter information tool. Class: com.mycompany.rar.MyMCF Validating: Yes/No Config-property: myProperty (java.lang.String) ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
2
0 / 0

[JBoss JIRA] (AS7-4413) shutting down slave host with jboss-cli.sh stops Domain Controller when slave is started with --cached-dc

by Manel Martinez (JIRA)

Manel Martinez created AS7-4413: ----------------------------------- Summary: shutting down slave host with jboss-cli.sh stops Domain Controller when slave is started with --cached-dc Key: AS7-4413 URL: https://issues.jboss.org/browse/AS7-4413 Project: Application Server 7 Issue Type: Bug Components: Domain Management Affects Versions: 7.1.1.Final Reporter: Manel Martinez Assignee: Brian Stansberry Priority: Critical NOTE: this is related to AS7-4281 (see https://issues.jboss.org/browse/AS7-4281?focusedCommentId=12682058&page=c... ) when a slave host is started with -cached-dc option, executing "jboss-cli.sh -c command=/host=$SLAVE_HOSTNAME:shutdown --controller=$DOMAIN_CONTROLLER_HOST:$DOMAIN_CONTROLLER_PORT --user=$HOSTNAME --password=$PASSWORD" will stop the Domain Controller instead stopping slave host. If I execute the same command without using --cached-dc option when starting slave host, it will shutdown the slave host as I expected. I am not really sure about what should do this command (stopping DC or slave -I think it should stop slave host) but it's kind of weird the behaviour depending on the --cached-dc option. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
2
0 / 0

[JBoss JIRA] (AS7-4417) permissions for security roles are not redefined by jboss-ejb3.xml

by Radim Hatlapatka (JIRA)

[ https://issues.jboss.org/browse/AS7-4417?page=com.atlassian.jira.plugin.s... ] Radim Hatlapatka edited comment on AS7-4417 at 4/12/12 5:58 PM: ---------------------------------------------------------------- If this is intended behaviour then it works the way as you described. In this I see mainly one problem: if I deny method (add it to exclude list) in one descriptor and in second I permit it, then the access to (call of) this method is allowed. If I look to many other systems with setting permissions, there is if some access is blocked it has higher priority than allowing access. For Example on MS Windows if you set that users from one group has denied access (specified deny), then even if he is in another group which has access he can't access it. I am not certain how it is in older versions of JBoss AS and therefore which behaviour are users of JBoss AS accustomed to. So from my point of view I would expect as most reasonable either override or additive behaviour with preference for denying access if somewhere is explicitly defined denying of access to the method. So please just confirm that behaviour you specified is the desired one and I will close this issue as solved. was (Author: rhatlapa): If this is intended behaviour then it works the way as you described. In this I see mainly one problem: if I deny method (add it to exclude list) in one descriptor and in second I permit it, then the access to (call of) this method is allowed. If I look to many other systems with setting permissions, there is if some access is blocked it has higher priority than allowing access. For Example on MS Windows if you set that users from one group has denied access (specified deny), then even if he is in another group which has access he can't access it. I am not certain how it is in older versions of JBoss AS and therefore which behaviour are users of JBoss AS accustomed to. So please just confirm that behaviour you specified is the desired one and I will close this issue as solved. > permissions for security roles are not redefined by jboss-ejb3.xml > ------------------------------------------------------------------ > > Key: AS7-4417 > URL: https://issues.jboss.org/browse/AS7-4417 > Project: Application Server 7 > Issue Type: Bug > Reporter: Radim Hatlapatka > Assignee: jaikiran pai > Labels: descriptor, security > Fix For: 7.1.2.Final-redhat1 > > > When I have defined permissions using security roles in ejb-jar.xml (ejb-spec) for certain methods and if I define them differently in jboss-ejb3.xml (jboss-spec) the permissions remain as their are defined in ejb-jar.xml. But I would expect that ejb-spec will redefine the permissions (because merging is not possible). > For details see written tests here: https://github.com/rhatlapa/jboss-as/commit/62adba59b288a53672a6b08c8a710... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-4417) permissions for security roles are not redefined by jboss-ejb3.xml

by Radim Hatlapatka (JIRA)

[ https://issues.jboss.org/browse/AS7-4417?page=com.atlassian.jira.plugin.s... ] Radim Hatlapatka commented on AS7-4417: --------------------------------------- If this is intended behaviour then it works the way as you described. In this I see mainly one problem: if I deny method (add it to exclude list) in one descriptor and in second I permit it, then the access to (call of) this method is allowed. If I look to many other systems with setting permissions, there is if some access is blocked it has higher priority than allowing access. For Example on MS Windows if you set that users from one group has denied access (specified deny), then even if he is in another group which has access he can't access it. I am not certain how it is in older versions of JBoss AS and therefore which behaviour are users of JBoss AS accustomed to. So please just confirm that behaviour you specified is the desired one and I will close this issue as solved. > permissions for security roles are not redefined by jboss-ejb3.xml > ------------------------------------------------------------------ > > Key: AS7-4417 > URL: https://issues.jboss.org/browse/AS7-4417 > Project: Application Server 7 > Issue Type: Bug > Reporter: Radim Hatlapatka > Assignee: jaikiran pai > Labels: descriptor, security > Fix For: 7.1.2.Final-redhat1 > > > When I have defined permissions using security roles in ejb-jar.xml (ejb-spec) for certain methods and if I define them differently in jboss-ejb3.xml (jboss-spec) the permissions remain as their are defined in ejb-jar.xml. But I would expect that ejb-spec will redefine the permissions (because merging is not possible). > For details see written tests here: https://github.com/rhatlapa/jboss-as/commit/62adba59b288a53672a6b08c8a710... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-3383) Check modules/com/sun/xml/bind/main/jaxb-xjc-2.2.jar for potential packaging error.

by Ondrej Zizka (JIRA)

Ondrej Zizka created AS7-3383: --------------------------------- Summary: Check modules/com/sun/xml/bind/main/jaxb-xjc-2.2.jar for potential packaging error. Key: AS7-3383 URL: https://issues.jboss.org/browse/AS7-3383 Project: Application Server 7 Issue Type: Task Affects Versions: 7.1.0.CR1b Reporter: Ondrej Zizka Assignee: Carlo de Wolf There's one quirk in modules/com/sun/xml/bind/main/jaxb-xjc-2.2.jar : modules/com/sun/xml/bind/main/jaxb-xjc-2.2.jar/com/sun/codemodel vs. modules/com/sun/xml/bind/main/jaxb-xjc-2.2.jar/1.0/com/sun/codemodel Is the 1.0 some packaging error? Or what's its the purpose? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

5
6
0 / 0

[JBoss JIRA] (AS7-4417) permissions for security roles are not redefined by jboss-ejb3.xml

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/AS7-4417?page=com.atlassian.jira.plugin.s... ] Stuart Douglas commented on AS7-4417: ------------------------------------- I have already pushed a fix for this into metadata, should I revert it? I was not aware of the previous behaviour, but I just figured that override was more flexible than additive. > permissions for security roles are not redefined by jboss-ejb3.xml > ------------------------------------------------------------------ > > Key: AS7-4417 > URL: https://issues.jboss.org/browse/AS7-4417 > Project: Application Server 7 > Issue Type: Bug > Reporter: Radim Hatlapatka > Assignee: jaikiran pai > Labels: descriptor, security > Fix For: 7.1.2.Final-redhat1 > > > When I have defined permissions using security roles in ejb-jar.xml (ejb-spec) for certain methods and if I define them differently in jboss-ejb3.xml (jboss-spec) the permissions remain as their are defined in ejb-jar.xml. But I would expect that ejb-spec will redefine the permissions (because merging is not possible). > For details see written tests here: https://github.com/rhatlapa/jboss-as/commit/62adba59b288a53672a6b08c8a710... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-4108) The default of depoyment-timeout is different to the description within the schema

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created AS7-4108: ------------------------------------- Summary: The default of depoyment-timeout is different to the description within the schema Key: AS7-4108 URL: https://issues.jboss.org/browse/AS7-4108 Project: Application Server 7 Issue Type: Bug Components: Server Affects Versions: 7.1.0.Final Reporter: Wolf-Dieter Fink Assignee: Jason Greene Priority: Trivial The description of deployment-timeout default and the real used default is different. jboss-as-deployment-scanner_1_1.xsd is: <xs:attribute name="deployment-timeout" type="xs:int" use="optional" default="600"> and the real default is "60" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
4
0 / 0

[JBoss JIRA] (AS7-3305) java.lang.IllegalAccessError when invoking protected method from another class in the same package path but different jar.

by Rodney Kite (JIRA)

Rodney Kite created AS7-3305: -------------------------------- Summary: java.lang.IllegalAccessError when invoking protected method from another class in the same package path but different jar. Key: AS7-3305 URL: https://issues.jboss.org/browse/AS7-3305 Project: Application Server 7 Issue Type: Bug Components: Class Loading Affects Versions: 7.1.0.CR1b Environment: Windows 7 64 bit, Sun JDK 1.6.0_30 32bit Reporter: Rodney Kite Assignee: David Lloyd tried to access method com.tis.utilities.AbstractJavaBeanSelectionPagination.selectObject(IZ)V from class com.tis.utilities.GenericPaginationBean I have an EJB jar which uses a MANIFEST.MF CLASS-PATH: entry to include a jar with some utility code. The two jars are packaged in the same ear file. Compiles and deploys fine. For some reason the EJB jar's classes can not invoke protected methods in classes that are in the same package path but in different jars. Invocation of public methods works fine. By the Java spec protected methods should be friends and thus accessible from other classes in the same package path. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

4
5
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 April 2012