[JBoss JIRA] (JGRP-1872) Table: purge() with incorrect seqnos moves HD/LOW back
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1872?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1872:
---------------------------
Fix Version/s: 3.4.6
> Table: purge() with incorrect seqnos moves HD/LOW back
> ------------------------------------------------------
>
> Key: JGRP-1872
> URL: https://issues.jboss.org/browse/JGRP-1872
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4.6, 3.5
>
>
> When we have a Table with {{low=40, hd=40, hr=45}} and receive a {{purge(30,true)}}, then the table will be {{low=30,hd=30,hr=45}}.
> This only happens with parameter {{force}} being {{true}}.
> This doesn't cause any bugs, but until the next (correct) {{purge()}} is invoked, the table will show and incorrect number of missing messages.
> SOLUTION: add the check to the start of {{purge()}}:
> {code}
> if(seqno <= low) // perhaps check for force as well
> return;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (JGRP-1872) Table: purge() with incorrect seqnos moves HD/LOW back
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1872?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1872:
---------------------------
Description:
When we have a Table with {{low=40, hd=40, hr=45}} and receive a {{purge(30,true)}}, then the table will be {{low=30,hd=30,hr=45}}.
This only happens with parameter {{force}} being {{true}}.
This doesn't cause any bugs, but until the next (correct) {{purge()}} is invoked, the table will show and incorrect number of missing messages.
SOLUTION: add the check to the start of {{purge()}}:
{code}
if(seqno <= low) // perhaps check for force as well
return;
{code}
was:
When we have a Table with {{low=40, hd=40, hr=45}} and receive a {{purge(30,true)}}, then the table will be {{low=20,hd=20,hr=45}}.
This only happens with parameter {{force}} being {{true}}.
This doesn't cause any bugs, but until the next (correct) {{purge()}} is invoked, the table will show and incorrect number of missing messages.
SOLUTION: add the check to the start of {{purge()}}:
{code}
if(seqno <= low) // perhaps check for force as well
return;
{code}
> Table: purge() with incorrect seqnos moves HD/LOW back
> ------------------------------------------------------
>
> Key: JGRP-1872
> URL: https://issues.jboss.org/browse/JGRP-1872
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> When we have a Table with {{low=40, hd=40, hr=45}} and receive a {{purge(30,true)}}, then the table will be {{low=30,hd=30,hr=45}}.
> This only happens with parameter {{force}} being {{true}}.
> This doesn't cause any bugs, but until the next (correct) {{purge()}} is invoked, the table will show and incorrect number of missing messages.
> SOLUTION: add the check to the start of {{purge()}}:
> {code}
> if(seqno <= low) // perhaps check for force as well
> return;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (JGRP-1872) Table: purge() with incorrect seqnos moves HD/LOW back
by Bela Ban (JIRA)
Bela Ban created JGRP-1872:
------------------------------
Summary: Table: purge() with incorrect seqnos moves HD/LOW back
Key: JGRP-1872
URL: https://issues.jboss.org/browse/JGRP-1872
Project: JGroups
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.5
When we have a Table with {{low=40, hd=40, hr=45}} and receive a {{purge(30,true)}}, then the table will be {{low=20,hd=20,hr=45}}.
This only happens with parameter {{force}} being {{true}}.
This doesn't cause any bugs, but until the next (correct) {{purge()}} is invoked, the table will show and incorrect number of missing messages.
SOLUTION: add the check to the start of {{purge()}}:
{code}
if(seqno <= low) // perhaps check for force as well
return;
{code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-3464) Nonexistent ldap group causes authentication to fail in security-realm
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3464?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3464:
-----------------------------------------------
baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1128176|https://bugzilla.redhat.com/show_bug.cgi?id=1128176] from POST to MODIFIED
> Nonexistent ldap group causes authentication to fail in security-realm
> -----------------------------------------------------------------------
>
> Key: WFLY-3464
> URL: https://issues.jboss.org/browse/WFLY-3464
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.1.0.Final
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
>
> The LdapGroupSearcher code will fail if it tries to lookup a group that
> does not exist on the local ldap server.
> This can happen when the ldap systems are configured as trusted domains.
> Even though the security-realm is not configured to use the trusted domain
> (it is configured to only look at a single ldap server), the
> user's entry on one ldap server could point at a group that exists on
> the other (trusted) ldap server.
> The LdapGroupSearcher code attempts to lookup this role and it fails. This
> failure is sent back to the http server which results in an HTTP 500 error
> and leaves the user with no way to authenticate/login.
> There is currently not a way to tell the group searcher code to ignore the
> group/role that cannot be found.
> 2014-06-06 12:44:39,819 TRACE [org.jboss.as.domain.management.security] (XNIO-1 task-1) Group found with distinguishedName=cn=TestManagedRole,ou=People,dc=my-ds-domain,dc=com
> 2014-06-06 12:44:39,821 TRACE [org.jboss.as.domain.management.security] (XNIO-1 task-1) Failure supplementing Subject: javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; remaining name 'cn=TestManagedRole,ou=People,dc=my-ds-domain,dc=com'
> at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3112) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3033) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1332) [rt.jar:1.7.0_45]
> at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:231) [rt.jar:1.7.0_45]
> at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:139) [rt.jar:1.7.0_45]
> at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:127) [rt.jar:1.7.0_45]
> at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.7.0_45]
> at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.7.0_45]
> at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:256) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:191) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:223) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroupEntries(LdapSubjectSupplementalService.java:218) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:195) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:188) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.supplementSubject(LdapSubjectSupplementalService.java:163) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.SecurityRealmService$1.createSubjectUserInfo(SecurityRealmService.java:200) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:155) [wildfly-domain-http-interface-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:120) [wildfly-domain-http-interface-8.1.0.Final.jar:8.1.0.Final]
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:110) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:57) [wildfly-domain-http-interface-8.1.0.Final.jar:8.1.0.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 months
[JBoss JIRA] (JASSIST-228) Powermock / Javassist creates illegal constructors for JDK 1.7.0u65 and 1.8.0u11 with -target 7.
by Lauri Vasko (JIRA)
[ https://issues.jboss.org/browse/JASSIST-228?page=com.atlassian.jira.plugi... ]
Lauri Vasko commented on JASSIST-228:
-------------------------------------
I stumbled upon this issue as well with java7u65 that failed my unit-tests. Upon researching the _interwebs_ i discovered workaround for this.
You need to add *-XX:-UseSplitVerifier* parameter when starting your unit-tests (_or failing program in general_).
In order to make unit-tests ran w/ maven work i had to add this parameter to _maven-surefire-plugin_ like so:
{code}
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.10</version>
<configuration>
<argLine>-XX:-UseSplitVerifier</argLine>
</configuration>
</plugin>
</plugins>
</build>
{code}
> Powermock / Javassist creates illegal constructors for JDK 1.7.0u65 and 1.8.0u11 with -target 7.
> ------------------------------------------------------------------------------------------------
>
> Key: JASSIST-228
> URL: https://issues.jboss.org/browse/JASSIST-228
> Project: Javassist
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.18.2-GA
> Environment: JDK 1.7.0u65 and 1.8.0u11
> Reporter: Florian Burka
> Assignee: Shigeru Chiba
> Attachments: powermock-javassist-bug.tar.gz
>
>
> Javassist creates illegal constructors for JDK 1.7.0u65 and 1.8.0u11 with -target 7, I have a test that reproduces it at https://github.com/burka/powermock-javassist-bug .
> Somewhere in MainMockTransformer.transform(clazz), I think inside the PowerMockExpressionEditor, the responsible action must have taken place.
> If you remove -target 7 it works for both JDK 1.7.0u65 and 1.8.0u11.
> {code}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.003 sec <<< FAILURE! - in ConstructorTest
> testConstructorManipulationFailure(ConstructorTest) Time elapsed: 0.002 sec <<< ERROR!
> java.lang.VerifyError: Bad <init> method call from inside of a branch
> Exception Details:
> Location:
> MockedClass.<init>()V @32: invokespecial
> Reason:
> Error exists in the bytecode
> Bytecode:
> 0000000: 2a4c 120f b800 1503 bd00 0d12 16b8 001a
> 0000010: b800 204e 2db2 0024 a500 0e2a 01c0 0026
> 0000020: b700 29a7 0009 2bb7 002b 0157 b1
> Stackmap Table:
> full_frame(@38,{UninitializedThis,UninitializedThis,Top,Object[#13]},{})
> full_frame(@44,{Object[#2],Object[#2],Top,Object[#13]},{})
> at java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2658)
> at java.lang.Class.getDeclaredConstructors(Class.java:2007)
> at ConstructorTest.testConstructorManipulationFailure(ConstructorTest.java:13)
> {code}
> I created a powermock ticket at
> https://code.google.com/p/powermock/issues/detail?id=505
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 months
[JBoss JIRA] (WFCORE-63) Define default List marshallers
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFCORE-63:
---------------------------------
Summary: Define default List marshallers
Key: WFCORE-63
URL: https://issues.jboss.org/browse/WFCORE-63
Project: WildFly Core
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
For primitive list marshaller we should have one or two default marshallers people can use.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 months
[JBoss JIRA] (WFCORE-62) PersistentResourceXMLDescription enancements
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFCORE-62:
---------------------------------
Summary: PersistentResourceXMLDescription enancements
Key: WFCORE-62
URL: https://issues.jboss.org/browse/WFCORE-62
Project: WildFly Core
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Domain Management
Affects Versions: 1.0.0.Alpha4
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
PersistentResourceXMLDescription & PersistentResourceDefinition need to be updated to add support for
- use arbitrary attribute for "name"
- have custom ElementParser
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 months
[JBoss JIRA] (WFLY-3756) Rename package name of whole Arquillian Wildfly adapter
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3756?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-3756:
-----------------------------------
[~swd847] you fine with this?
> Rename package name of whole Arquillian Wildfly adapter
> -------------------------------------------------------
>
> Key: WFLY-3756
> URL: https://issues.jboss.org/browse/WFLY-3756
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Affects Versions: 8.1.0.Final
> Reporter: Stefan Miklosovic
> Assignee: Karel Piwko
>
> Speaking about Arquillian Wildfly container adapter, some time ago it seems to me it was directly embedded into wildfly repository at github when I recall that correctly.
> Right now, it is deleted from there and is moved to https://github.com/wildfly/wildfly-arquillian
> The problem is that when you want to make a test which mixes two containers together, to be concrete, good old AS7 and new Wildfly, you can not do that since its package name are just same so you have naming clash on your class path.
> I am author of multiple container extension (1) (2) under Arquillian umbrella which enables the usage of two different container adapters in one test run which is not possible normally. While it was possible to make the difference between Jboss AS 7 and Wildfly since theirs package names were org.jboss.as and org.wildfly respectively when Wildfly was embedded in Wildfly repo itself, you can not do this anymore.
> This affects e.g. guys from Infinispan project which are trying to cover the migration from JBoss AS to Wildfly and they are writing tests for it. (you have old Jbosses and Wildflies and Infinispan can migrate data from one server to another and drop the old ones).
> I suggest to rename package name to org.wildfly to not collide anymore.
> Thanks a lot!
> (1) https://github.com/arquillian/arquillian-droidium/tree/master/droidium-co...
> (2) https://github.com/arquillian/arquillian-droidium/tree/master/droidium-co...
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 months
[JBoss JIRA] (WFLY-3756) Rename package name of whole Arquillian Wildfly adapter
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3756?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-3756:
---------------------------------
Assignee: Karel Piwko
> Rename package name of whole Arquillian Wildfly adapter
> -------------------------------------------------------
>
> Key: WFLY-3756
> URL: https://issues.jboss.org/browse/WFLY-3756
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Affects Versions: 8.1.0.Final
> Reporter: Stefan Miklosovic
> Assignee: Karel Piwko
>
> Speaking about Arquillian Wildfly container adapter, some time ago it seems to me it was directly embedded into wildfly repository at github when I recall that correctly.
> Right now, it is deleted from there and is moved to https://github.com/wildfly/wildfly-arquillian
> The problem is that when you want to make a test which mixes two containers together, to be concrete, good old AS7 and new Wildfly, you can not do that since its package name are just same so you have naming clash on your class path.
> I am author of multiple container extension (1) (2) under Arquillian umbrella which enables the usage of two different container adapters in one test run which is not possible normally. While it was possible to make the difference between Jboss AS 7 and Wildfly since theirs package names were org.jboss.as and org.wildfly respectively when Wildfly was embedded in Wildfly repo itself, you can not do this anymore.
> This affects e.g. guys from Infinispan project which are trying to cover the migration from JBoss AS to Wildfly and they are writing tests for it. (you have old Jbosses and Wildflies and Infinispan can migrate data from one server to another and drop the old ones).
> I suggest to rename package name to org.wildfly to not collide anymore.
> Thanks a lot!
> (1) https://github.com/arquillian/arquillian-droidium/tree/master/droidium-co...
> (2) https://github.com/arquillian/arquillian-droidium/tree/master/droidium-co...
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 months