[JBoss JIRA] Created: (AS7-1308) :jndi-view in domain mode on profile returns success
by Heiko Rupp (JIRA)
:jndi-view in domain mode on profile returns success
----------------------------------------------------
Key: AS7-1308
URL: https://issues.jboss.org/browse/AS7-1308
Project: Application Server 7
Issue Type: Bug
Components: Naming
Affects Versions: 7.0.0.Final
Reporter: Heiko Rupp
Assignee: John Bailey
Doing :jndi-view on /profile=default/subsystem=naming gives:
[domain@localhost:9999 subsystem=naming] :jndi-view
{
"outcome" => "success",
"result" => "Jndi view is only available in runtime mode."
}
This makes no sense, as the outcome is not a view on the JNDI-tree, but a failure description.
That operation should return failure instead.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (AS7-1297) Weld claims to be able to inject Principal, but throws RuntimeException("not implemented") at runtime
by Craig Ringer (JIRA)
Weld claims to be able to inject Principal, but throws RuntimeException("not implemented") at runtime
-----------------------------------------------------------------------------------------------------
Key: AS7-1297
URL: https://issues.jboss.org/browse/AS7-1297
Project: Application Server 7
Issue Type: Bug
Components: CDI / Weld, Security
Affects Versions: 7.0.0.Final, 7.1.0.Alpha1
Environment: Windows 7 x64, JDK 6 and 7 both tested. JBoss AS 7.0.0 release, and Jboss AS 7.1.0.Alpha1 nightly build 2011-07-15.
Reporter: Craig Ringer
Assignee: Stuart Douglas
In JBoss AS 7, Weld claims to be able to inject instances of java.security.Principal. CDI archives that try to inject it do not fail at deployment time with unsatisfied dependencies. Instead, they fail later, at runtime, when injection is attempted. At this point a runtime exception indicating that principal injection isn't supported is thrown.
This prevents user code, or external frameworks like Seam 3 Security, from providing their own producers for javax.security.Principal without requiring a qualifier to be used.
If JBoss AS 7's weld integration doesn't support container managed security yet (perhaps because container managed security is not supported in JBoss AS 7 at all yet?) then it should not offer an injection point for the security principal.
Backtrace when calling toString() on an injected proxy for a Principal:
Caused by: java.lang.RuntimeException: not implemented
at org.jboss.as.weld.services.bootstrap.WeldSecurityServices.getPrincipal(WeldSecurityServices.java:53)
at org.jboss.weld.bean.builtin.ee.PrincipalBean$PrincipalCallable.call(PrincipalBean.java:48)
at org.jboss.weld.bean.builtin.ee.PrincipalBean$PrincipalCallable.call(PrincipalBean.java:34)
at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:50)
at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:62)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:125)
at org.jboss.weld.security.Principal$1263393769$Proxy$_$$_Weld$Proxy$.toString(Principal$1263393769$Proxy$_$$_Weld$Proxy$.java)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (AS7-1304) Resource Adapter configuration corrupts standalone.xml
by Andrew Wheeler (JIRA)
Resource Adapter configuration corrupts standalone.xml
------------------------------------------------------
Key: AS7-1304
URL: https://issues.jboss.org/browse/AS7-1304
Project: Application Server 7
Issue Type: Bug
Components: JCA
Affects Versions: 7.0.0.Final
Environment: Linux
Reporter: Andrew Wheeler
Assignee: Jesper Pedersen
Priority: Critical
When defining a resource adapter in the standalone.xml which includes a config-property it is overwriten by the server which modifies the config-properties in a manner which prevents the server from booting on the next restart
>From standalone:
<resource-adapter>
<archive>
jackrabbit-jca.rar
</archive>
<transaction-support>
XATransaction
</transaction-support>
<connection-definitions>
<connection-definition class-name="org.apache.jackrabbit.jca.JCAManagedConnectionFactory" jndi-name="java:/jcr/ConnectionFactory" enabled="true" use-java-context="true" pool-name="jackrabbit" use-ccm="true">
<config-property name="HomeDir">${jboss.server.data.dir}/jackrabbit</config-property>
<config-property name="ConfigFile">${jboss.server.data.dir}/jackrabbit/jackrabbit.xml</config-property>
</connection-definition>
</connection-definitions>
</resource-adapter>
The config-property then becomes in the overwritten standalone.xml:
<config-property>(HomeDir => /opt/jboss7/standalone/data/jackrabbit)</config-property>
this causes the server to fail to parse standalone.xml and subsequently does not start on the next restart with the following error:
ERROR [stderr] Exception in thread "Controller Boot Thread" java.lang.RuntimeException: org.jboss.as.controller.persistence.ConfigurationPersistenceException: Failed to parse configuration
Also, the JCA connector is not getting the correct parameters, so the resource throws an exception:
WARN [org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri] (http--127.0.0.1-8080-6) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Failed to create session: Unable to access a repository with the following settings:
org.apache.jackrabbit.repository.conf: ("ConfigFile" => "/opt/jboss7/standalone/data/jackrabbit/jackrabbit.xml")
org.apache.jackrabbit.repository.home: ("HomeDir" => "/opt/jboss7/standalone/data/jackrabbit")
Perhaps the repository you are trying to access is not available at the moment.
This error is thrown by Jackrabbit as it cannot access the configuration file. I'm guessing that it has trouble parsing the string passed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (JBAS-8797) Logging with SLF4J produces wrong output when using multiple parameters in format
by Jens Reimann (JIRA)
Logging with SLF4J produces wrong output when using multiple parameters in format
---------------------------------------------------------------------------------
Key: JBAS-8797
URL: https://issues.jboss.org/browse/JBAS-8797
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Logging
Affects Versions: 6.0.0.Final
Environment: Ubuntu Linux 64bit
Reporter: Jens Reimann
Assignee: David Lloyd
Logging with SLF4J and passing parameters as Object[] produces wrong output in the JBoss log:
e.g.: logger.debug ( "Logging - Level: {}, Action: {}, Result: {}, UserData: {}, Reference: {}/{}", new Object[] { level, action, result, data, referenceType, referenceId } );
produces
Logging - Level: <parameter #1 as Object[]>, Action: {}, Result: {}, ....
It seems to me that instead of handling the Object[] that is passed as array is used later on as simple Object which reduces the provided parameters to 1 instead. There seems to be no problem with the log calls that take one or two objects (which are separate methods in SLF4J).
I would consider it major since it scrambles all logging messages using the Object[] methods.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (JBLOGGING-56) Setting up of application specific logging context leads to IllegalArgumentException
by jaikiran pai (JIRA)
Setting up of application specific logging context leads to IllegalArgumentException
-------------------------------------------------------------------------------------
Key: JBLOGGING-56
URL: https://issues.jboss.org/browse/JBLOGGING-56
Project: JBoss Logging
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JBoss AS 6.0.0.Final
Reporter: jaikiran pai
Assignee: David Lloyd
Many users have reported that trying to setup application specific logging context leads to IllegalArgumentException in JBoss AS 6.0.0.Final (please see the referenced forum thread for one such example). I tried a simple application (.war file with jboss-logging.xml in WEB-INF) with the following jboss-logging.xml file:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<!-- ===================================================================== -->
<!-- -->
<!-- Logging System Configuration -->
<!-- -->
<!-- ===================================================================== -->
<logging xmlns="urn:jboss:logging:6.0" xmlns:b="urn:jboss:bean-deployer:2.0" context="first">
<!-- Define our logging context -->
<define-context name="first"/>
<!-- A time/date based rolling handler -->
<periodic-rotating-file-handler
file-name="${jboss.server.log.dir}/first-app.log"
name="FILE"
autoflush="true"
append="false"
suffix=".yyyy-MM-dd"> <!-- To roll over at the top of each hour, use ".yyyy-MM-dd-HH" instead -->
<error-manager>
<only-once/>
</error-manager>
<formatter>
<!-- To revert back to simple stack traces without JAR versions, change "%E" to "%e" below. -->
<!-- Uncomment this to get the class name in the log as well as the category
<pattern-formatter pattern="%d %-5p [%c] %C{1} (%t) %s%E%n"/>
-->
<!-- Uncomment this to log without the class name in the log -->
<pattern-formatter pattern="%d %-5p [%c] (%t) %s%E%n"/>
</formatter>
</periodic-rotating-file-handler>
<!-- =============================================== -->
<!-- Limit categories -->
<!-- =============================================== -->
<!-- Limit the org.jboss category to DEBUG -->
<logger category="org.jboss">
<level name="TRACE"/>
</logger>
<logger category="org.myapp">
<level name="TRACE"/>
</logger>
<!-- ======================= -->
<!-- Setup the Root category -->
<!-- ======================= -->
<root-logger>
<!-- Set the root logger priority via a system property, with a default value. -->
<level name="${jboss.server.log.threshold:INFO}"/>
<handlers>
<handler-ref name="FILE"/>
</handlers>
</root-logger>
</logging>
{code}
There's nothing special about this jboss-logging.xml, except that it defines a application specific logging context. During deployment of this application, the server throws the following exception and the deployment fails:
{code}
17:39:35,465 ERROR [AbstractKernelController] Error installing to Configured: name=Logging:REGISTRATION:first:Anonymous-0 state=Instantiated: java.lang.RuntimeException: Error configuring property: selector for Logging:REGISTRATION:first:Anonymous-0
at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:112) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:85) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.ConfigureAction.installActionInternal(ConfigureAction.java:44) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:894) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:641) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:182) [:2.2.0.GA]
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:58) [:2.2.0.GA]
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) [:2.2.0.GA]
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1571) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.GA]
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.GA]
at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.0.0.Final]
at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileDeployAction.deploy(ProfileDeployAction.java:151) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileDeployAction.installActionInternal(ProfileDeployAction.java:94) [:0.2.2]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.profileservice.dependency.ProfileActivationWrapper$BasicProfileActivation.start(ProfileActivationWrapper.java:190) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileActivationWrapper.start(ProfileActivationWrapper.java:87) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileActivationService.activateProfile(ProfileActivationService.java:215) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileActivationService.activate(ProfileActivationService.java:159) [:0.2.2]
at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.activate(AbstractProfileServiceBootstrap.java:112) [:0.2.2]
at org.jboss.profileservice.resolver.BasicResolverFactory$ProfileResolverFacade.deploy(BasicResolverFactory.java:87) [:0.2.2]
at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.start(AbstractProfileServiceBootstrap.java:91) [:0.2.2]
at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:132) [:6.0.0.Final]
at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:56) [:6.0.0.Final]
at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:827) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:417) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
Caused by: java.lang.IllegalArgumentException: Wrong arguments. setSelector for target org.jboss.logging.metadata.ClassLoaderRegistrationHelper@111fce expected=[org.jboss.logmanager.ClassLoaderLogContextSelector] actual=[org.jboss.logmanager.LogContextSelectorService]
at org.jboss.reflect.plugins.introspection.ReflectionUtils.handleErrors(ReflectionUtils.java:404) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:74) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.beans.info.plugins.DefaultPropertyInfo.set(DefaultPropertyInfo.java:143) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.beans.info.plugins.BeanInfoUtil.set(BeanInfoUtil.java:177) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.beans.info.plugins.AbstractBeanInfo.setProperty(AbstractBeanInfo.java:289) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.PropertyDispatchWrapper.execute(PropertyDispatchWrapper.java:114) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:107) [jboss-kernel.jar:2.2.0.GA]
... 64 more
{code}
Looking at the JBoss Logging code, this appears to be a bug. The LoggingMetaDataHelper has this piece of code:
{code}
if (! context.equals("system")) {
// if it's "system", then nothing special needs to be done.
// Otherwise create a bean representing the registration of the deployment unit's classloader with a new log context.
final BeanMetaDataBuilder builder = BeanMetaDataBuilder.createBuilder(new GetClassLoaderBeanMetaData(getAnonymousName(context, Kind.REGISTRATION), ClassLoaderRegistrationHelper.class.getName()));
builder.addPropertyMetaData("logContext", builder.createInject(getContextName(context)));
builder.addPropertyMetaData("selector", builder.createInject("JBossLogManagerContextSelectorService"));
beanMetaDataList.add(builder.getBeanMetaData());
}
{code}
As can be seen, a BeanMetaData is being constructed and a bean named "JBossLogManagerContextSelectorService" is being injected into a field of type LogContextSelector. However, the xml which defines this "JBossLogManagerContextSelectorService" sets up the JBossLogManagerContextSelectorService to be of a different "type":
{code:xml}
<!--
~ These two beans define the per-classloader log context selector which allows per-deployment logging. Since
~ enabling this feature may have a performance impact in certain cases, it's started up lazily (on demand)
~ when a separate log context is defined in a user deployment.
-->
<bean name="JBossLogManagerClassLoaderContextSelector" class="org.jboss.logmanager.ClassLoaderLogContextSelector"/>
<bean name="JBossLogManagerContextSelectorService" class="org.jboss.logmanager.LogContextSelectorService" mode="On Demand">
<property name="selector">
<inject bean="JBossLogManagerClassLoaderContextSelector"/>
</property>
</bean>
{code}
There are 2 ways to fix this, either fix the code to refer to the "selector" field of JBossLogManagerContextSelectorService (I guess the right approach) or rename the beans in the logmanager-jboss-beans.xml to make sure JBossLogManagerContextSelectorService is of type LogContextSelector (I consider this a workaround).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months