March 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-2945) Change the domain model paths system to not use services

by David Lloyd (Created) (JIRA)

Change the domain model paths system to not use services -------------------------------------------------------- Key: AS7-2945 URL: https://issues.jboss.org/browse/AS7-2945 Project: Application Server 7 Issue Type: Enhancement Components: Domain Management Reporter: David Lloyd Assignee: Brian Stansberry Fix For: Open To Community Using services for path references has two distinct disadvantages: * It makes it difficult or impossible to detect changes (the only way to change a path is to restart the service) * If a path consumer is not a service, it is difficult to use path values What we should have instead is have a registration mechanism so that when a path is used, the reference is tracked in the model. This lets us detect backreferences in the event where a path is to be deleted. This would also enable us to send a notification when a path is changed, so that changing a path also causes an update or "refresh" on all referencing domain attributes. This way, for example, if I change the base path for the log directory, all the log handlers can automatically be updated as well as part of the same operation, using their existing update logic. -- 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, 1 month

3
3
0 / 0

[JBoss JIRA] (AS7-2335) Need to be able to query all filesystem paths from management interface

by Stan Silvert (Created) (JIRA)

Need to be able to query all filesystem paths from management interface ----------------------------------------------------------------------- Key: AS7-2335 URL: https://issues.jboss.org/browse/AS7-2335 Project: Application Server 7 Issue Type: Feature Request Affects Versions: 7.1.0.Alpha1 Reporter: Stan Silvert Assignee: Brian Stansberry For deployment scanners, we have a relative-to attribute with the following description {code} "relative-to" => { "type" => STRING, "description" => "Reference to a filesystem path defined in the \"paths\" section of the server configuration.", "required" => false, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" {code} However, there is nothing in the management interface that will return all the paths including the built-in ones like jboss.server.base.dir. I need the list of all paths to be able to give the user a drop-down in the console. -- 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, 1 month

4
6
0 / 0

[JBoss JIRA] (AS7-2723) ApplicationServerService creates path services for paths that are listed as configurable

by Brian Stansberry (Created) (JIRA)

ApplicationServerService creates path services for paths that are listed as configurable ---------------------------------------------------------------------------------------- Key: AS7-2723 URL: https://issues.jboss.org/browse/AS7-2723 Project: Application Server 7 Issue Type: Bug Components: Domain Management Affects Versions: 7.0.2.Final, 7.0.1.Final, 7.0.0.Final Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 7.1.0.CR1 In ApplicationServerService.start() // Add environment paths AbsolutePathService.addService(ServerEnvironment.HOME_DIR, serverEnvironment.getHomeDir().getAbsolutePath(), serviceTarget); AbsolutePathService.addService(ServerEnvironment.SERVER_BASE_DIR, serverEnvironment.getServerBaseDir().getAbsolutePath(), serviceTarget); AbsolutePathService.addService(ServerEnvironment.SERVER_CONFIG_DIR, serverEnvironment.getServerConfigurationDir().getAbsolutePath(), serviceTarget); AbsolutePathService.addService(ServerEnvironment.SERVER_DATA_DIR, serverEnvironment.getServerDataDir().getAbsolutePath(), serviceTarget); AbsolutePathService.addService(ServerEnvironment.SERVER_LOG_DIR, serverEnvironment.getServerLogDir().getAbsolutePath(), serviceTarget); AbsolutePathService.addService(ServerEnvironment.SERVER_TEMP_DIR, serverEnvironment.getServerTempDir().getAbsolutePath(), serviceTarget); The xsd says these are configurable but if the services are set here, they aren't. Likely fix is to change the xsd to reflect reality. -- 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, 1 month

5
5
0 / 0

[JBoss JIRA] (AS7-2989) TS: Database switch (in datasources)

by Ondrej Zizka (Created) (JIRA)

TS: Database switch (in datasources) ------------------------------------ Key: AS7-2989 URL: https://issues.jboss.org/browse/AS7-2989 Project: Application Server 7 Issue Type: Sub-task Components: Test Suite Reporter: Ondrej Zizka Assignee: Ondrej Zizka Fix For: 7.1.0.Final -- 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, 1 month

4
4
0 / 0

[JBoss JIRA] Created: (JBAS-8695) Deployment repository garbage collection

by Brian Stansberry (JIRA)

Deployment repository garbage collection ---------------------------------------- Key: JBAS-8695 URL: https://jira.jboss.org/browse/JBAS-8695 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Fix For: 7.0.0.CR1 The deployment repository is only loosely coupled to the domain model; i.e. users can add content to the repo and then have a problem or decide to not execute a deployment plan with the result that the deployment is not used in the model. Or they can remove the deployment from the model via an update, which doesn't remove it from the repo (in case the update needs to be rolled back.) Effect of this is unreferenced deployment content can accumulate in the repo, so we need a gc utility that can be used to clean it out. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

4
6
0 / 0

[JBoss JIRA] (SECURITY-652) ClassNotFoundException for custom principal implementation provided in EAR

by Bernd Zeitler (JIRA)

Bernd Zeitler created SECURITY-652: -------------------------------------- Summary: ClassNotFoundException for custom principal implementation provided in EAR Key: SECURITY-652 URL: https://issues.jboss.org/browse/SECURITY-652 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: PicketBox_v3_0_CR2 Reporter: Bernd Zeitler Assignee: Anil Saldhana We implemented our own custom {{ClientLoginModule}} along with the matching {{ServerLoginModule}} and a custom {{Principal}}. I tried to deploy these within an EAR, along with a {{my-jboss-beans.xml}}, where the application policy is configured. The EAR contains an EJB (J2EE) which is secured with this policy. When calling the EJB from a remote client, I get the following exception: {code} 2012-03-02 15:46:39,548 ERROR [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#0[127.0.0.1:54670]) WorkerThread#0[127.0.0.1:54670] exception occurred during first invocation: java.lang.ClassNotFoundException: test.me.MyPrincipal at java.net.URLClassLoader$1.run(URLClassLoader.java:202) [:1.6.0_29] at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_29] at java.net.URLClassLoader.findClass(URLClassLoader.java:190) [:1.6.0_29] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [:1.6.0_29] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) [:1.6.0_29] at java.lang.ClassLoader.loadClass(ClassLoader.java:247) [:1.6.0_29] at java.lang.Class.forName0(Native Method) [:1.6.0_29] at java.lang.Class.forName(Class.java:247) [:1.6.0_29] at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:304) [jboss-classloader.jar:2.2.1.GA] at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1172) [jboss-classloader.jar:2.2.1.GA] at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:886) [jboss-classloader.jar:2.2.1.GA] at org.jboss.classloader.spi.base.BaseClassLoader.doLoadClass(BaseClassLoader.java:505) [jboss-classloader.jar:2.2.1.GA] at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:450) [jboss-classloader.jar:2.2.1.GA] at java.lang.ClassLoader.loadClass(ClassLoader.java:247) [:1.6.0_29] at java.lang.Class.forName0(Native Method) [:1.6.0_29] at java.lang.Class.forName(Class.java:247) [:1.6.0_29] at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:603) [:1.6.0_29] at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:172) [:] at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574) [:1.6.0_29] at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) [:1.6.0_29] at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731) [:1.6.0_29] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_29] at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946) [:1.6.0_29] at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870) [:1.6.0_29] at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752) [:1.6.0_29] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_29] at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) [:1.6.0_29] at java.util.HashSet.readObject(HashSet.java:291) [:1.6.0_29] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_29] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_29] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_29] at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_29] at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) [:1.6.0_29] at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1848) [:1.6.0_29] at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752) [:1.6.0_29] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_29] at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946) [:1.6.0_29] at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870) [:1.6.0_29] at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752) [:1.6.0_29] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_29] at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946) [:1.6.0_29] at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870) [:1.6.0_29] at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752) [:1.6.0_29] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_29] at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) [:1.6.0_29] at org.jboss.invocation.MarshalledInvocation.readExternal(MarshalledInvocation.java:665) [:6.1.0.Final] at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1791) [:1.6.0_29] at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1750) [:1.6.0_29] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_29] at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946) [:1.6.0_29] at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870) [:1.6.0_29] at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752) [:1.6.0_29] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_29] at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) [:1.6.0_29] at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238) [:] at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138) [:] at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123) [:] at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59) [:6.1.0.Final] at org.jboss.remoting.transport.socket.ServerThread.versionedRead(ServerThread.java:900) [:] at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:754) [:] at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:744) [:] at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:548) [:] at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:234) [:] {code} Everything is working as exptected when I am using a JBoss principal implementation (like {{SimplePrincipal}}). But we need a custom principal, since we have to provide additional data. Moving login modules and principal implementation in a jboss lib dir is not an option since we even need some application specific (deployed) resources during the authentication and authorisation process, which leads us to classloading hell and several complicated workarounds. I was hoping to get rid off this unhandy installation and workarounds since JBoss 6.1 supports deployment of application policies. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-4158) domain.xml default server-groups incorrectly show ha-sockets instead of full-ha-sockets

by William Bendrot (JIRA)

William Bendrot created AS7-4158: ------------------------------------ Summary: domain.xml default server-groups incorrectly show ha-sockets instead of full-ha-sockets Key: AS7-4158 URL: https://issues.jboss.org/browse/AS7-4158 Project: Application Server 7 Issue Type: Bug Components: Domain Management Affects Versions: 7.1.1.Final Reporter: William Bendrot Assignee: Brian Stansberry Priority: Minor The default settings show for the server-groups in domain.xml show the use of "ha-sockets" this interface type is now called "full-ha-sockets" ex. <server-group name="other-server-group" profile="full-ha"> <jvm name="default"> <heap size="64m" max-size="512m"/> </jvm> <socket-binding-group ref="ha-sockets"/> </server-group> </server-groups> -- 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, 1 month

2
2
0 / 0

[JBoss JIRA] (REMJMX-35) Run the testsuite with TRACE logging by default for Remoting, XNIO and Remoting JMX

by Darran Lofthouse (JIRA)

Darran Lofthouse created REMJMX-35: -------------------------------------- Summary: Run the testsuite with TRACE logging by default for Remoting, XNIO and Remoting JMX Key: REMJMX-35 URL: https://issues.jboss.org/browse/REMJMX-35 Project: Remoting JMX Issue Type: Task Components: Build Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.3.Final The testsuite is not a performance test so we will be better capturing as much debug information during test runs as is possible so that in the event of a failure in a new environment the information will already be captured to debug it further. -- 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, 1 month

1
1
0 / 0

[JBoss JIRA] (REMJMX-36) The SecurityClientTest currently contains a static reference to the config - this means that depending on the order the tests are executed the wrong config could be used.

by Darran Lofthouse (JIRA)

Darran Lofthouse created REMJMX-36: -------------------------------------- Summary: The SecurityClientTest currently contains a static reference to the config - this means that depending on the order the tests are executed the wrong config could be used. Key: REMJMX-36 URL: https://issues.jboss.org/browse/REMJMX-36 Project: Remoting JMX Issue Type: Bug Components: Tests Affects Versions: 1.0.2.Final Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.3.Final An example failure caused by the differing orders is: - ------------------------------------------------------------------------------- Test set: org.jboss.remotingjmx.SecurityClientTest ------------------------------------------------------------------------------- Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.984 sec <<< FAILURE! testAnonymousAuthentication(org.jboss.remotingjmx.SecurityClientTest) Time elapsed: 0.116 sec <<< ERROR! javax.security.sasl.SaslException: Cannot get userid/password [Caused by javax.security.auth.callback.UnsupportedCallbackException] at com.sun.security.sasl.ClientFactoryImpl.getUserInfo(ClientFactoryImpl.java:157) at com.sun.security.sasl.ClientFactoryImpl.createSaslClient(ClientFactoryImpl.java:94) at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities$1.run(ClientConnectionOpenListener.java:352) -- 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, 1 month

1
1
0 / 0

[JBoss JIRA] (AS7-4161) remote host line for domain controller in default host.xml does not contain the security-realm parameter

by William Bendrot (JIRA)

William Bendrot created AS7-4161: ------------------------------------ Summary: remote host line for domain controller in default host.xml does not contain the security-realm parameter Key: AS7-4161 URL: https://issues.jboss.org/browse/AS7-4161 Project: Application Server 7 Issue Type: Bug Components: Domain Management Affects Versions: 7.1.1.Final Reporter: William Bendrot Assignee: Brian Stansberry The default host.xml contains a commented line indicating what the configuration is when setting up host.xml on a host controller that must connect to a remote domain controller. This line is missing the security-realm parameter that is required. Current: <domain-controller> <local/>   </domain-controller> Should be: <domain-controller> <local/>   </domain-controller> -- 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, 1 month

2
1
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 March 2012