[JBoss JIRA] Created: (JBSER-120) Can't add field to class as the Java Serialization says is compatible
by Tom Saulpaugh (JIRA)
Can't add field to class as the Java Serialization says is compatible
---------------------------------------------------------------------
Key: JBSER-120
URL: https://jira.jboss.org/jira/browse/JBSER-120
Project: JBoss Serialization
Issue Type: Bug
Affects Versions: 1.0.3 GA
Environment: WIndows 2003 server 64-bit
Reporter: Tom Saulpaugh
Assignee: Clebert Suconic
Fix For: 1.1.0 Beta
I traced through this in jboss-serialization and it appears to be a basic coding bug. Look at this code in StreamingClass.readStream(), which includes the exception being thrown:
short numberofFields=inp.readShort();
keyfields[slotIndex] = new short[numberofFields];
ClassMetadataField fields[] = slots[slotIndex].getFields();
if (numberofFields>fields.length)
{
throw new IOException("Current classpath has lesser fields on " + className + " than its original version");
}
for (short fieldIndex=0;fieldIndex<fields.length;fieldIndex++)
{
long hashfield = inp.readLong();
ClassMetadataField fieldOnHash = slots[slotIndex].getField(hashfield);
if (fieldOnHash==null)
{
throw new IOException ("Field hash " + fieldOnHash + " is not available on current classPath for class " + className);
}
keyfields[slotIndex][fieldIndex] = fieldOnHash.getOrder();
}
Note that there are numberOfFields fields on the serialized prior version of the object, while there are fields.length fields in the new version of the class being deserialized to. The code reads the serialized fields and looks up the correspondent fields on the new class by hash.
However, note that it reads fields.length fields from the file instead of numberofFields fields!!!
That is the problem. It reads a long from the file that is not even a hash code of a field and so can't find it in the hash array, whence the null.
This really does mean that the latest version of JBoss serialization has a bug that causes it to fail to handle field additions on new versions of classes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (SECURITY-484) NPE causing authentication failure
by Jeff Mesnil (JIRA)
NPE causing authentication failure
----------------------------------
Key: SECURITY-484
URL: https://jira.jboss.org/jira/browse/SECURITY-484
Project: PicketBox (JBoss Security and Identity Management)
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JBoss AS trunk
Reporter: Jeff Mesnil
Assignee: Anil Saldhana
when running TCK jms tests, tests starts to fail with authentication error.
The failing tests are doing nothing fancy with security, just authenticating JMS user.
I have 300+ tests with the same security settings which pass and then the following tests start to fail because the JMS user can no longer be authenticated.
I enabled jboss security traces and got a NPE just before tests start to fail:
13:13:27,409 TRACE [org.jboss.security.integration.JNDIBasedSecurityManagement] Look up of JNDI for cts/mappingMgr failed with null
13:13:27,410 TRACE [org.jboss.security.integration.JNDIBasedSecurityManagement] Exception in getting MappingManager: java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)
at org.jboss.security.integration.JNDIBasedSecurityManagement.getMappingManager(JNDIBasedSecurityManagement.java:219)
at org.jboss.security.plugins.JBossSecurityContext.getMappingManager(JBossSecurityContext.java:280)
at org.jboss.security.plugins.JBossAuthorizationManager.getCurrentRoles(JBossAuthorizationManager.java:406)
at org.jboss.security.plugins.JBossAuthorizationManager.getCurrentRoles(JBossAuthorizationManager.java:379)
at org.jboss.security.plugins.JBossAuthorizationManager.doesUserHaveRole(JBossAuthorizationManager.java:185)
at org.jboss.security.plugins.auth.JaasSecurityManagerBase.doesUserHaveRole(JaasSecurityManagerBase.java:434)
at org.jboss.security.plugins.JaasSecurityManager.doesUserHaveRole(JaasSecurityManager.java:195)
at org.hornetq.integration.jboss.security.JBossASSecurityManager.validateUserAndRole(JBossASSecurityManager.java:110)
at org.hornetq.core.security.impl.SecurityStoreImpl.check(SecurityStoreImpl.java:172)
...
13:13:27,414 ERROR [org.hornetq.core.protocol.core.ServerSessionPacketHandler] Caught unexpected exception: java.lang.NullPointerException
at org.jboss.security.plugins.JBossAuthorizationManager.getCurrentRoles(JBossAuthorizationManager.java:407)
at org.jboss.security.plugins.JBossAuthorizationManager.getCurrentRoles(JBossAuthorizationManager.java:379)
at org.jboss.security.plugins.JBossAuthorizationManager.doesUserHaveRole(JBossAuthorizationManager.java:185)
at org.jboss.security.plugins.auth.JaasSecurityManagerBase.doesUserHaveRole(JaasSecurityManagerBase.java:434)
at org.jboss.security.plugins.JaasSecurityManager.doesUserHaveRole(JaasSecurityManager.java:195)
at org.hornetq.integration.jboss.security.JBossASSecurityManager.validateUserAndRole(JBossASSecurityManager.java:110)
at org.hornetq.core.security.impl.SecurityStoreImpl.check(SecurityStoreImpl.java:172)
...
13:13:57,453 TRACE [org.jboss.security.auth.spi.UsersRolesLoginModule] logout
13:13:57,454 TRACE [org.jboss.security.auth.login.XMLLoginConfigImpl] Begin getAppConfigurationEntry(cts), size=15
13:13:57,454 TRACE [org.jboss.security.auth.login.XMLLoginConfigImpl] End getAppConfigurationEntry(cts), authInfo=AppConfigurationEntry[]:
[0]
LoginModule Class: org.jboss.security.auth.spi.UsersRolesLoginModule
ControlFlag: LoginModuleControlFlag : required
Options:
name=usersProperties, value=cts-users.properties
name=unauthenticatedIdentity, value=cts-user
name=rolesProperties, value=cts-roles.properties
name=password-stacking, value=useFirstPass
13:13:57,456 TRACE [org.jboss.security.plugins.auth.JaasSecurityManagerBase.cts] Login failure: javax.security.auth.login.LoginException: classe LoginModule introuvable : org.jboss.security.auth.spi.UsersRolesLoginModule
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:808)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:579)
at org.jboss.security.plugins.auth.JaasSecurityManagerBase.defaultLogin(JaasSecurityManagerBase.java:553)
at org.jboss.security.plugins.auth.JaasSecurityManagerBase.authenticate(JaasSecurityManagerBase.java:487)
at org.jboss.security.plugins.auth.JaasSecurityManagerBase.isValid(JaasSecurityManagerBase.java:365)
at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:160)
at org.hornetq.integration.jboss.security.JBossASSecurityManager.validateUser(JBossASSecurityManager.java:81)
at org.hornetq.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:128)
...
This occurs only when I ran the full tests (which takes several hours).
Running again the failing tests did not show the authentication error.
I enabled traces for org.jboss.security. Tell me if you need more info
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (JBREFLECT-111) Annotation class values containing arrays fail for javassist
by Kabir Khan (JIRA)
Annotation class values containing arrays fail for javassist
------------------------------------------------------------
Key: JBREFLECT-111
URL: https://jira.jboss.org/jira/browse/JBREFLECT-111
Project: JBoss Reflection
Issue Type: Bug
Affects Versions: JBossReflection.2.2.0-Alpha4
Reporter: Kabir Khan
Assignee: Kabir Khan
Fix For: JBossReflection.2.2.0-Alpha5
Need to be able to parse things like
public class AnnotatedClass
{
@TestAnnotation(clazz=String.class)
int withPlainClass;
@TestAnnotation(clazz=String[].class)
int withClassArray;
@TestAnnotation(clazz=String[][].class)
int with2DClassArray;
@TestAnnotation(clazz=int[][][].class)
int with3DIntArray;
}
They fail with errors like:
java.lang.reflect.UndeclaredThrowableException
at $Proxy0.clazz(Unknown Source)
at test.javassist.annotation.AnnotationArrayTestCase.checkAnnotation(AnnotationArrayTestCase.java:51)
at test.javassist.annotation.AnnotationArrayTestCase.test1DStringArrayValue(AnnotationArrayTestCase.java:23)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
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.ClassNotFoundException: java/lang/String[]
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at javassist.bytecode.annotation.MemberValue.loadClass(MemberValue.java:55)
at javassist.bytecode.annotation.ClassMemberValue.getValue(ClassMemberValue.java:85)
at javassist.bytecode.annotation.AnnotationImpl.invoke(AnnotationImpl.java:148)
... 21 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (JBAS-7819) Either callerSubject or callerRunAs should be non-null
by Stefan Ries (JIRA)
Either callerSubject or callerRunAs should be non-null
-------------------------------------------------------
Key: JBAS-7819
URL: https://jira.jboss.org/jira/browse/JBAS-7819
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: JBossAS-5.0.0.GA
Environment: WinXP 32
Reporter: Stefan Ries
Assignee: Anil Saldhana
I'm using a custom loginmodule and a custom Principal. As the loginmodule accesses a bean, I stacked the RunAsLoginModule on top of the custom one.
Sometimes, I'm getting the following exception when accessing a bean remotely. I'm not able to find a deterministic way to reproduce it.
java.lang.IllegalArgumentException: Either callerSubject or callerRunAs should be non-null
org.jboss.security.plugins.javaee.EJBAuthorizationHelper.authorize(EJBAuthorizationHelper.java:78)
org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:189)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:897)
org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:768)
org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:721)
org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:548)
org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:234)
org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:213)
org.jboss.remoting.Client.invoke(Client.java:1917)
org.jboss.remoting.Client.invoke(Client.java:768)
org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.remoting.ClusterChooserInterceptor.invoke(ClusterChooserInterceptor.java:84)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.remoting.ClusteredIsLocalInterceptor.invoke(ClusteredIsLocalInterceptor.java:54)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
$Proxy5.invoke(Unknown Source)
org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:188)
$Proxy32.getBatch(Unknown Source)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (JGRP-1153) Shared transport badly broken
by Björn Kautler (JIRA)
Shared transport badly broken
-----------------------------
Key: JGRP-1153
URL: https://jira.jboss.org/jira/browse/JGRP-1153
Project: JGroups
Issue Type: Bug
Affects Versions: 2.7
Environment: EHCache 1.7.2
ehcache-jgroupsreplication 1.3
JGroups 2.7.0.GA
Reporter: Björn Kautler
Assignee: Bela Ban
I tried to use JGroups with a shared transport (while using only one JChannel, the one EHCache uses for replication). At ProtocolStack.java:719 the TP.ProtocolAdapter is added to the protocol stack when a shared transport is used. This leads to problems after shunning. When the JChannel.CloserThread tries in line 2018 to reopen the JChannel, the Protocol Stack is recreated. But now the TP$ProtocolAdapter is part of the protocol stack and thus of the config string created from the protocol stack at JChannel:327. As the ProtocolAdapter does not have a default constructor, the whole thing explodes at Configurator:732 where the newInstance() call of course fails while the ProtocolAdapter probably shouldn't be in the protocol stack anyway at this point in time. I guess it would be added a second time at ProtocolStack.java:719 then. Also after disabling the shared transport it seems that the problem I was able to reproduce halfway reliably through restarting both instances simultaneously doesn't arise again without shared transport.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (JGRP-822) NAKACK: concurrent delivery of messages from the same sender
by Bela Ban (JIRA)
NAKACK: concurrent delivery of messages from the same sender
------------------------------------------------------------
Key: JGRP-822
URL: https://jira.jboss.org/jira/browse/JGRP-822
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.x
JGroups delivers messages from different senders concurrently. However, it delivers messages from the same sender sequentially. Sometimes, we can deliver messages from the same sender concurrently too, if the app tells us it is okay. For example:
- Node N was 3 HTTP sessions: A, B and C
- Clients update those sessions concurrently
- As a result, N sends the following messages: A1, B1, A2, C1, C2, C3, B2, A3
- As NAKACK assigns sequence numbers (seqnos) based on JGroups instances, all messages from N will have to be
delivered in the same order in which they were sent, e.g. (-> means followed by):
A1 -> B1 -> A2 -> C1 -> C2 -> C3 -> B2 -> A3
- This means that, for example, the first update to C (C1) has to wait until A1, B1 and A2 have been delivered
- This is not optimal, as updates for A, B and C are completely independent, and can be delivered in parallel
- So a better delivery would be ('||' means concurrent delivery):
A1 -> A2 -> A3 || B1 -> B2 || C1 -> C2 -> C3
- A3 needs to be delivered after A2 which needs to be delivered after A1. However, all updates for A can be delivered
concurrently with messages for B or C.
- OOB doesn't help: here all messages are delivered concurrently, but there is also no ordering within A, B or C !
SOLUTION: the sender adds a 'scope' token to a Message, e.g. the jsessionid (A, B or C). JGroups maintains NakReceiverWindows per *scope*, not per sender. The sender's address is the default token, so in the absence of a scope token, JGroups of course maintains NakReceiverWindows per sender. (NakReceiverWindows are used to keep track of seqnos).
In the above example, if the scopes sent with *each message* are A, B and C, then we'd have 3 NakReceiverWindows:
N::A, N::B, N::C.
Each window would start with seqno 1, so updates for A, B and C are delivered concurrently with respect to each other, but sequentially within the scope.
Issues:
- This is an API change, and should probably be propagated up to the building blocks, such as RpcDispatcher.
- A scope needs to be associated with an address A (of a JGroups instance): when A leaves or crashes, all associated scopes and their NakReceiverWindows needs to be released, too
- Should this be done for UNICAST too ?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months