[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
[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
[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
[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
[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
[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
[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/>
<!-- Alternative remote domain controller configuration with a host and port -->
<!-- <remote host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9999}"/> -->
</domain-controller>
Should be:
<domain-controller>
<local/>
<!-- Alternative remote domain controller configuration with a host and port -->
<!-- <remote host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm"/> -->
</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