[JBoss JIRA] (SECURITY-933) The root cause of login module failures gets lost when multiple login modules are stacked
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/SECURITY-933?page=com.atlassian.jira.plug... ]
Tomas Hofman moved WFLY-6007 to SECURITY-933:
---------------------------------------------
Project: PicketBox (was: WildFly)
Key: SECURITY-933 (was: WFLY-6007)
Workflow: classic default workflow (was: GIT Pull Request workflow )
Component/s: Negotiation
(was: Security)
Affects Version/s: (was: 10.0.0.CR5)
> The root cause of login module failures gets lost when multiple login modules are stacked
> -----------------------------------------------------------------------------------------
>
> Key: SECURITY-933
> URL: https://issues.jboss.org/browse/SECURITY-933
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1288668
> The root cause of login module failures gets lost when multiple login modules are stacked and the "flag" attribute is set to "optional".
> When the login attempt fails (invalid bindCredential on the LdapExtLoginModule for example) the authentication request will continue to the next login module in the stack. In this situation, the exceptions "cause" attribute is getting overwritten during the processing of the other login modules. This results in the actual cause to get lost during processing.
> This makes troubleshooting authentication failures difficult.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-102) Remove the need for OSH authors to deal with ServiceVerificationHandler or removal of installed services in rollback
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-102?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated WFCORE-102:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1299102
Bugzilla Update: Perform
> Remove the need for OSH authors to deal with ServiceVerificationHandler or removal of installed services in rollback
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-102
> URL: https://issues.jboss.org/browse/WFCORE-102
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Alpha9
>
>
> The various base classes OSH authors use to create handlers force the author to deal with ServiceVerificationHandler and, during rollback, with removing any services the OSH added. This task is to have the OperationContext handle these things transparently, removing the need for authors to do so.
> To preserve compatibility, the various API methods authors may have overridden that expose the SVH and the list of added ServiceControllers will be retained (but deprecated), but the SVH and the list of handlers won't be used. The API javadoc will encourage use of method variants that don't use these parameters.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1012) kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1012?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on DROOLS-1012:
-------------------------------------------------
Jiri Petrlik <jpetrlik(a)redhat.com> changed the Status of [bug 1293965|https://bugzilla.redhat.com/show_bug.cgi?id=1293965] from VERIFIED to RELEASE_PENDING
> kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-1012
> URL: https://issues.jboss.org/browse/DROOLS-1012
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.4.x
>
> Attachments: brms-fuse-integration-master.tgz
>
>
> kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry. This implies that when the KieContainer is created in a OSGi environment it is not able to get an instance of the MavenClassLoaderResolver and then cannot create a ClassLoader including all the transitive dependencies of the kjar to be compiled.
> The attached project reproduces this issue. In order to run it, it's enough to do a mvn clean install of the project and issue the following commands in fuse:
> features:addurl mvn:com.redhat/brms-fuse-integration-features/0.0.1-SNAPSHOT/xml/features
> features:install brms-integration-bundle
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1012) kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1012?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on DROOLS-1012:
-------------------------------------------------
Jiri Petrlik <jpetrlik(a)redhat.com> changed the Status of [bug 1293965|https://bugzilla.redhat.com/show_bug.cgi?id=1293965] from ON_QA to VERIFIED
> kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-1012
> URL: https://issues.jboss.org/browse/DROOLS-1012
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.4.x
>
> Attachments: brms-fuse-integration-master.tgz
>
>
> kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry. This implies that when the KieContainer is created in a OSGi environment it is not able to get an instance of the MavenClassLoaderResolver and then cannot create a ClassLoader including all the transitive dependencies of the kjar to be compiled.
> The attached project reproduces this issue. In order to run it, it's enough to do a mvn clean install of the project and issue the following commands in fuse:
> features:addurl mvn:com.redhat/brms-fuse-integration-features/0.0.1-SNAPSHOT/xml/features
> features:install brms-integration-bundle
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6016) jboss-cli returns success when WFLYCTL0009: Failed to store configuration occurred
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6016?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6016:
-----------------------------------------------
Dominik Pospisil <dpospisi(a)redhat.com> changed the Status of [bug 1299177|https://bugzilla.redhat.com/show_bug.cgi?id=1299177] from NEW to ASSIGNED
> jboss-cli returns success when WFLYCTL0009: Failed to store configuration occurred
> ----------------------------------------------------------------------------------
>
> Key: WFLY-6016
> URL: https://issues.jboss.org/browse/WFLY-6016
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: 10.0.0.CR5
> Reporter: Brad Maxwell
> Assignee: Alexey Loubyansky
>
> If the server is started, and a cli call is made that fails to persist to the standalone.xml returns success even though it failed.
> Start the server.
> Simple way to reproduce is to change the permissions on the configuration directory then run some cli commands such as shown below:
> {code}
> $ ./bin/jboss-cli.sh -c
> [standalone@localhost:9990 /] /system-property=foo1:add(value=bar1)
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=ejb3:write-attribute(name=enable-statistics,value=true)
> {"outcome" => "success"}
> {code}
> {code}
> 19:53:17,823 ERROR [stderr] (management-handler-thread - 1) java.nio.file.AccessDeniedException: /tmp/wildfly-10.0.0.CR5/standalone/configuration/standalone.xml.tmp
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at java.nio.file.Files.newByteChannel(Files.java:361)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at java.nio.file.Files.createFile(Files.java:632)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:125)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at java.security.AccessController.doPrivileged(Native Method)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at javax.security.auth.Subject.doAs(Subject.java:422)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 19:53:17,831 ERROR [stderr] (management-handler-thread - 1) at java.lang.Thread.run(Thread.java:745)
> 19:53:17,831 ERROR [stderr] (management-handler-thread - 1) at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 19:53:17,831 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0009: Failed to store configuration to standalone.xml: java.nio.file.AccessDeniedException: /tmp/wildfly-10.0.0.CR5/standalone/configuration/standalone.xml.tmp
> at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
> at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
> at java.nio.file.Files.deleteIfExists(Files.java:1165)
> at java.nio.file.Files.copy(Files.java:3004)
> at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:109)
> at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55)
> at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JASSIST-258) java.lang.IllegalStateException: Failed to transform class with … javassist.bytecode.Utf8Info cannot be cast to javassist.bytecode.ClassInfo
by Mark Warner (JIRA)
Mark Warner created JASSIST-258:
-----------------------------------
Summary: java.lang.IllegalStateException: Failed to transform class with … javassist.bytecode.Utf8Info cannot be cast to javassist.bytecode.ClassInfo
Key: JASSIST-258
URL: https://issues.jboss.org/browse/JASSIST-258
Project: Javassist
Issue Type: Feature Request
Reporter: Mark Warner
Assignee: Shigeru Chiba
I did search all the issues.But this issue doesn't seem have been resolved.
When a large class with 2000+ lines is added to @prepareForTest, the following error is encountered:
java.lang.IllegalStateException: Failed to transform class with name com.gnx.company.UtilityClass Reason: javassist.bytecode.Utf8Info cannot be cast to javassist.bytecode.ClassInfo
at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:247)
at org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:177)
at org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:68)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:274)
at sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:114)
at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:125)
at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:49)
at sun.reflect.annotation.AnnotationParser.parseSig(AnnotationParser.java:432)
at sun.reflect.annotation.AnnotationParser.parseClassValue(AnnotationParser.java:413)
at sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:715)
at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:522)
at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:348)
at sun.reflect.annotation.AnnotationParser.parseAnnotation2(AnnotationParser.java:283)
at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:117)
at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:70)
at java.lang.Class.initAnnotationsIfNecessary(Class.java:3271)
at java.lang.Class.getAnnotation(Class.java:3219)
at org.junit.internal.MethodSorter.getDeclaredMethods(MethodSorter.java:52)
at org.junit.internal.runners.TestClass.getAnnotatedMethods(TestClass.java:45)
at org.junit.internal.runners.MethodValidator.validateTestMethods(MethodValidator.java:71)
at org.junit.internal.runners.MethodValidator.validateStaticMethods(MethodValidator.java:44)
at org.junit.internal.runners.MethodValidator.validateMethodsForDefaultRunner(MethodValidator.java:50)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.validate(PowerMockJUnit44RunnerDelegateImpl.java:108)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.<init>(PowerMockJUnit44RunnerDelegateImpl.java:70)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl.<init>(PowerMockJUnit47RunnerDelegateImpl.java:42)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit49RunnerDelegateImpl.<init>(PowerMockJUnit49RunnerDelegateImpl.java:25)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:149)
at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:39)
at org.powermock.tests.utils.impl.AbstractTestSuiteChunkerImpl.createTestDelegators(AbstractTestSuiteChunkerImpl.java:218)
at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.<init>(JUnit4TestSuiteChunkerImpl.java:59)
at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.<init>(AbstractCommonPowerMockRunner.java:32)
at org.powermock.modules.junit4.PowerMockRunner.<init>(PowerMockRunner.java:33)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:29)
at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:21)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:26)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.<init>(JUnit4TestReference.java:33)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.<init>(JUnit4TestClassReference.java:25)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoader.java:48)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoader.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.lang.ClassCastException: javassist.bytecode.Utf8Info cannot be cast to javassist.bytecode.ClassInfo
at javassist.bytecode.ConstPool.getClassInfo(ConstPool.java:232)
at javassist.bytecode.stackmap.Tracer.doOpcode148_201(Tracer.java:631)
at javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:81)
at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:187)
at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199)
..............
The UtilityClass consists of 2300 lines of code. There are static methods inside the class that needs to be accessed. So, I need to add the class to @prepareForTest.
Anyone knows how to fix this issue?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1281) NPE in principal-to-group group searching
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1281?page=com.atlassian.jira.plugi... ]
Ondrej Lukas updated WFCORE-1281:
---------------------------------
Steps to Reproduce:
1) use following security realm:
{code:xml}
<security-realm name="ldap-security-realm">
<authentication>
<ldap connection="ldap_connection" base-dn="dc=jboss,dc=org" recursive="true">
<username-filter attribute="uid"/>
</ldap>
</authentication>
<authorization>
<ldap connection="ldap_connection">
<group-search group-name="SIMPLE" iterative="false" group-dn-attribute="dn" group-name-attribute="description">
<principal-to-group group-attribute="sn"/>
</group-search>
</ldap>
</authorization>
</security-realm>
{code}
...
{code:xml}
<outbound-connections>
<ldap name="ldap_connection" url="ldap://localhost:10389" search-dn="uid=admin,ou=system" search-credential="secret"/>
</outbound-connections>
{code}
2) Use this security domain for RBAC access to management console:
{code:xml}
<management-interfaces>
<native-interface security-realm="ManagementRealm">
<socket-binding native="management-native"/>
</native-interface>
<http-interface security-realm="ldap-security-realm">
<socket-binding http="management-http"/>
</http-interface>
</management-interfaces>
<access-control provider="rbac">
<role-mapping>
<role name="SuperUser">
<include>
<user name="$local"/>
<group name="JBossAdmin"/>
</include>
</role>
</role-mapping>
</access-control>
{code}
3) Use ldap server with attached ldif
4) Try to access management console with jduke/Password - it will fail.
5) Uncomment line 'description: Monitor' from ldif and try to access management console again - it will be successful.
was:
1) use following security domain:
{code:xml}
<security-realm name="ldap-security-realm">
<authentication>
<ldap connection="ldap_connection" base-dn="dc=jboss,dc=org" recursive="true">
<username-filter attribute="uid"/>
</ldap>
</authentication>
<authorization>
<ldap connection="ldap_connection">
<group-search group-name="SIMPLE" iterative="false" group-dn-attribute="dn" group-name-attribute="description">
<principal-to-group group-attribute="sn"/>
</group-search>
</ldap>
</authorization>
</security-realm>
{code}
...
{code:xml}
<outbound-connections>
<ldap name="ldap_connection" url="ldap://localhost:10389" search-dn="uid=admin,ou=system" search-credential="secret"/>
</outbound-connections>
{code}
2) Use this security domain for RBAC access to management console:
{code:xml}
<management-interfaces>
<native-interface security-realm="ManagementRealm">
<socket-binding native="management-native"/>
</native-interface>
<http-interface security-realm="ldap-security-realm">
<socket-binding http="management-http"/>
</http-interface>
</management-interfaces>
<access-control provider="rbac">
<role-mapping>
<role name="SuperUser">
<include>
<user name="$local"/>
<group name="JBossAdmin"/>
</include>
</role>
</role-mapping>
</access-control>
{code}
3) Use ldap server with attached ldif
4) Try to access management console with jduke/Password - it will fail.
5) Uncomment line 'description: Monitor' from ldif and try to access management console again - it will be successful.
> NPE in principal-to-group group searching
> -----------------------------------------
>
> Key: WFCORE-1281
> URL: https://issues.jboss.org/browse/WFCORE-1281
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 2.0.5.Final
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Attachments: groupsearch.ldif
>
>
> In case when ldap authorization with principal-to-group group searching is used in security realm and LDAP entry found by value of 'group-attribute' does not include attribute mentioned in 'group-name-attribute' then it causes authentication fail. It is caused by missing null check for groupNameAttr and hidden NPE thrown from [1].
> [1] https://github.com/wildfly/wildfly-core/blob/18393273a1c9e464fb0cc9597951...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6018) WFLYCTL0013: Operation ("clean-obsolete-content") failed .. StringIndexOutOfBoundsException when OS puts metadata files in content repo
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6018?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6018:
-----------------------------------------------
Chao Wang <chaowan(a)redhat.com> changed the Status of [bug 1299189|https://bugzilla.redhat.com/show_bug.cgi?id=1299189] from NEW to ASSIGNED
> WFLYCTL0013: Operation ("clean-obsolete-content") failed .. StringIndexOutOfBoundsException when OS puts metadata files in content repo
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6018
> URL: https://issues.jboss.org/browse/WFLY-6018
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Reporter: Brad Maxwell
> Assignee: Jason Greene
>
> Mac OS can put .DS_Store files into the content repo directory. This can also be reproduced on Linux by creating a file under the content dir and when clean-obsolete-content() runs it will log this error. It seems it runs every 10 minutes.
> {code}
> 22:59:48,289 INFO [org.jboss.as.repository] (ServerService Thread Pool -- 1) WFLYDR0009: Content /Users/bradley/Desktop/wildfly-10.0.0.CR5/standalone/data/content/9b/.DS_Store is obsolete and will be removed
> 22:59:48,290 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 1) WFLYCTL0013: Operation ("clean-obsolete-content") failed - address: ([]): java.lang.StringIndexOutOfBoundsException: String index out of range: 11
> at java.lang.String.charAt(String.java:658)
> at org.jboss.as.repository.HashUtil.hexStringToByteArray(HashUtil.java:62)
> at org.jboss.as.repository.ContentReference.getHash(ContentReference.java:68)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.removeContent(ContentRepository.java:365)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.markAsObsolete(ContentRepository.java:427)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.cleanObsoleteContent(ContentRepository.java:403)
> at org.jboss.as.server.operations.CleanObsoleteContentHandler.execute(CleanObsoleteContentHandler.java:76)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204)
> at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:659)
> at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:649)
> at org.jboss.as.server.deployment.ContentRepositoryCleaner.cleanObsoleteContent(ContentRepositoryCleaner.java:132)
> at org.jboss.as.server.deployment.ContentRepositoryCleaner$ContentRepositoryCleanerTask.run(ContentRepositoryCleaner.java:67)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 22:59:48,292 ERROR [org.jboss.as.server] (ServerService Thread Pool -- 1) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0158: Operation handler failed: java.lang.StringIndexOutOfBoundsException: String index out of range: 11
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6018) WFLYCTL0013: Operation ("clean-obsolete-content") failed .. StringIndexOutOfBoundsException when OS puts metadata files in content repo
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-6018?page=com.atlassian.jira.plugin.... ]
Chao Wang reassigned WFLY-6018:
-------------------------------
Assignee: Chao Wang (was: Jason Greene)
> WFLYCTL0013: Operation ("clean-obsolete-content") failed .. StringIndexOutOfBoundsException when OS puts metadata files in content repo
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6018
> URL: https://issues.jboss.org/browse/WFLY-6018
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Reporter: Brad Maxwell
> Assignee: Chao Wang
>
> Mac OS can put .DS_Store files into the content repo directory. This can also be reproduced on Linux by creating a file under the content dir and when clean-obsolete-content() runs it will log this error. It seems it runs every 10 minutes.
> {code}
> 22:59:48,289 INFO [org.jboss.as.repository] (ServerService Thread Pool -- 1) WFLYDR0009: Content /Users/bradley/Desktop/wildfly-10.0.0.CR5/standalone/data/content/9b/.DS_Store is obsolete and will be removed
> 22:59:48,290 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 1) WFLYCTL0013: Operation ("clean-obsolete-content") failed - address: ([]): java.lang.StringIndexOutOfBoundsException: String index out of range: 11
> at java.lang.String.charAt(String.java:658)
> at org.jboss.as.repository.HashUtil.hexStringToByteArray(HashUtil.java:62)
> at org.jboss.as.repository.ContentReference.getHash(ContentReference.java:68)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.removeContent(ContentRepository.java:365)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.markAsObsolete(ContentRepository.java:427)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.cleanObsoleteContent(ContentRepository.java:403)
> at org.jboss.as.server.operations.CleanObsoleteContentHandler.execute(CleanObsoleteContentHandler.java:76)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204)
> at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:659)
> at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:649)
> at org.jboss.as.server.deployment.ContentRepositoryCleaner.cleanObsoleteContent(ContentRepositoryCleaner.java:132)
> at org.jboss.as.server.deployment.ContentRepositoryCleaner$ContentRepositoryCleanerTask.run(ContentRepositoryCleaner.java:67)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 22:59:48,292 ERROR [org.jboss.as.server] (ServerService Thread Pool -- 1) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0158: Operation handler failed: java.lang.StringIndexOutOfBoundsException: String index out of range: 11
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months