January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5932) Invalidating a session of an SSO on a different node than where the session was created does not logout the user

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/WFLY-5932?page=com.atlassian.jira.plugin.... ] Richard Janík commented on WFLY-5932: ------------------------------------- Hi Stuart, first, I created a branch of the 1.3.12.Final Undertow tag (which is the version of Undertow in current Wildfly master) and cherry-picked the last commit of sso-fix branch (394c7b8). I rebuilt Undertow, which replaced 1.3.12.Final in my local repository and then I rebuilt Wildfly with this spoofed dependency. I verified (by decompilation) that the commit is in there and then run my reproducer, which failed, unfortunately. Second, I rebuilt Undertow from the sso-fix branch, where I just changed versions to 1.3.12.Final (again, to spoof the dependency for Wildfly), then I rebuilt Wildfly (branch master, last commit 4ca733c), verified modules/system/layers/base/io/undertow/servlet/main/undertow-servlet-1.3.12.Final.jar contains the fix from last commit of sso-fix branch. Then I run my reproducer, which failed again. (I'm detailing the process in case you have something to say about it) What reproducer are you using? If you're using the reproducer from WFLY-5473, which step causes problems? tl;dr I don't think commit 394c7b8 fixes the issue - I'm still seeing it. > Invalidating a session of an SSO on a different node than where the session was created does not logout the user > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5932 > URL: https://issues.jboss.org/browse/WFLY-5932 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.CR5 > Reporter: Richard Janík > Assignee: Stuart Douglas > Priority: Blocker > > See steps to reproduce for description. Additional scenario with a failover where we don't need to authenticate with the last request (but where we should be required to authenticate): > * Access A1, authenticate, fail A1 (e.g. shutdown the server), access A2, invalidate session on A2, access A2 > Scenarios where the SSO context is destroyed (where we need to authenticate with the last request as expected): > * Access A1, authenticate, invalidate session on A1, access A1 > * Access A1, authenticate, access A2, invalidate session on A1, access A1 > Possibly related to JBEAP-1228, JBEAP-1282. Note that we always only have a single session bound to an SSO. I'm not flagging this as a blocker, since the issue usually doesn't manifest thanks to sticky sessions on a load balancer. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-260) Stack frame corruption after writing to attribute on injected after method

by Rafael Campos (JIRA)

[ https://issues.jboss.org/browse/JASSIST-260?page=com.atlassian.jira.plugi... ] Rafael Campos updated JASSIST-260: ---------------------------------- Steps to Reproduce: Stack frame corruption after writing to attribute contain on class that contains method with injected code via {code:java} CtMethod.insertAfter(String src) {code} This writing happens inside of the injected code src it self. Example: {code:java} public class Animal { public String ret; public AnimalRoles(){ ret = "Before"; } public String hello() { return ret; } public String die(String age) { return ""; } } {code} {code:java} // Some how get the method hello from Animal into a var name methodHello methodHello.insertAfter("this.ret = \"After\";"); {code} {code:java} // Call the method hello in a fresh Animal instance Animal a = new Animal(); System.out.println(a.hello()); System.out.println(a.ret); {code} Result: Before After Expected: After After Debugging the program a in the method hello it is possible to observe the following message: "com.sun.jdi.InternalException: Got error code in repIy:35 occurred retrieving ‘this' from stack frame." !Image1.png|thumbnail! Tried several work arounds but basically the problem is that the newly written data can not be read at the return statement. No workaround found so far. Also tested with previous versions of javaassist from 3.12.1.GA until 3.20.0GA and all yield the same result. Tried search the web for similar issues but with very little luck. Just some cryptic message with some weird workarounds that I could not get to work by any means. UPDATE: A workaround is possible using method.setBody. was: Stack frame corruption after writing to attribute contain on class that contains method with injected code via {code:java} CtMethod.insertAfter(String src) {code} This writing happens inside of the injected code src it self. Example: {code:java} public class Animal { public String ret; public AnimalRoles(){ ret = "Before"; } public String hello() { return ret; } public String die(String age) { return ""; } } {code} {code:java} // Some how get the method hello from Animal into a var name methodHello methodHello.insertAfter("this.ret = \"After\";"); {code} {code:java} // Call the method hello in a fresh Animal instance Animal a = new Animal(); System.out.println(a.hello()); System.out.println(a.ret); {code} Result: Before After Expected: After After Debugging the program a in the method hello it is possible to observe the following message: "com.sun.jdi.InternalException: Got error code in repIy:35 occurred retrieving ‘this' from stack frame." !Image1.png|thumbnail! Tried several work arounds but basically the problem is that the newly written data can not be read at the return statement. No workaround found so far. Also tested with previous versions of javaassist from 3.12.1.GA until 3.20.0GA and all yield the same result. Tried search the web for similar issues but with very little luck. Just some cryptic message with some weird workarounds that I could not get to work by any means. > Stack frame corruption after writing to attribute on injected after method > -------------------------------------------------------------------------- > > Key: JASSIST-260 > URL: https://issues.jboss.org/browse/JASSIST-260 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.20.0-GA > Environment: Using java 1.8, also tested with java 1.7 same behavior on eclipse Version: Mars.1 Release (4.5.1) on windows 7 x64 bits. > Reporter: Rafael Campos > Assignee: Shigeru Chiba > Priority: Minor > Attachments: Image1.png > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6044) Relative path names in jsp includes do not resolve properly

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6044?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-6044: ----------------------------------- Fix is already in core, when core is updated in full, this will be fixed. > Relative path names in jsp includes do not resolve properly > ----------------------------------------------------------- > > Key: WFLY-6044 > URL: https://issues.jboss.org/browse/WFLY-6044 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.CR5 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Priority: Blocker > Fix For: 10.0.0.Final > > > Hi, I have noticed that jsp:include behaves differently in EAP 7.0.0.ER2 than in WildFly 10.0.0.CR4. > > To reproduce this, use kitchensink-jsp quickstart (1) and in index.jsp replace > {code} > <%@ include file="registrationForm.jsp"%> > {code} > with > {code} > <jsp:include page="./registrationForm.jsp"/> > {code} > With this modification the quickstart no longer works on EAP 7.0.0.ER2 but it still works on WildFly 10.0.0.CR4 and EAP 7.0.0.Alpha. > (1) https://github.com/trepel/jboss-eap-quickstarts/tree/7.0.x-develop/kitche... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2007) Adapt code to use new Java 8 features

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2007?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2007 at 1/27/16 6:02 AM: --------------------------------------------------------- Also look at * -MessageBatch-: DONE * Table (Visitor) * Replace Filter with Predicate * -Condition / CondVar- : DONE was (Author: belaban): Also look at * -MessageBatch-: DONE * Table (Visitor) * Use default methods in interfaces * -Condition / CondVar- : DONE > Adapt code to use new Java 8 features > ------------------------------------- > > Key: JGRP-2007 > URL: https://issues.jboss.org/browse/JGRP-2007 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > E.g replace loops for forEach() etc -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-989) Saving/Restoring drools session prevents timer-related rules from firing

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-989?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-989. -------------------------------- Resolution: Rejected The KieSessionConfiguration is not part of the marshalled session and has to be passed to the Marshaller when the session is unmarshalled. In your case replacing {code} KieSession kSession = marshaller.unmarshall(baos); {code} with {code} KieSession kSession = marshaller.unmarshall(baos, ksConf, null); {code} fixes your test case. > Saving/Restoring drools session prevents timer-related rules from firing > ------------------------------------------------------------------------ > > Key: DROOLS-989 > URL: https://issues.jboss.org/browse/DROOLS-989 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: David Weir > Assignee: Mario Fusco > Priority: Blocker > Attachments: DroolsTimerTest.java, DroolsTimerTest.java, DroolsTimerTest.java, DroolsTimerTest.java > > > Attached test case shows a timer-base rule firing. Then the session is saved and restored per the manual. When the trigger is inserted again, the rule does not fire. > This is killing my system whenever I have to restart and restore the current sessions. > The workaround is to create the session again from scratch -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6080) Hibernate validator fails most deployments on JDK9

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6080?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-6080: ------------------------------ Parent: (was: WFLY-3854) Issue Type: Bug (was: Sub-task) > Hibernate validator fails most deployments on JDK9 > -------------------------------------------------- > > Key: WFLY-6080 > URL: https://issues.jboss.org/browse/WFLY-6080 > Project: WildFly > Issue Type: Bug > Components: EE, JPA / Hibernate > Affects Versions: 7.0.0.ER4 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 10.0.0.Beta2 > > > Hibernate validator wrongly parser java version string, which fails on JDK9 with Verona project based versioning. > {noformat} > javax.validation.ValidationException: Unable to instantiate Configuration. > at org.hibernate.validator.internal.util.Version.getJavaRelease(Version.java:36) > at org.hibernate.validator.internal.engine.ConfigurationImpl.<init>(ConfigurationImpl.java:120) > at org.hibernate.validator.internal.engine.ConfigurationImpl.<init>(ConfigurationImpl.java:96) > at org.hibernate.validator.HibernateValidator.createGenericConfiguration(HibernateValidator.java:31) > at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:276) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6080) Hibernate validator fails most deployments on JDK9

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFLY-6080: --------------------------------- Summary: Hibernate validator fails most deployments on JDK9 Key: WFLY-6080 URL: https://issues.jboss.org/browse/WFLY-6080 Project: WildFly Issue Type: Sub-task Components: EE, JPA / Hibernate Affects Versions: 10.0.0.CR5 Reporter: Tomaz Cerar Assignee: Tomaz Cerar Hibernate validator wrongly parser java version string, which fails on JDK9 with Verona project based versioning. {noformat} javax.validation.ValidationException: Unable to instantiate Configuration. at org.hibernate.validator.internal.util.Version.getJavaRelease(Version.java:36) at org.hibernate.validator.internal.engine.ConfigurationImpl.<init>(ConfigurationImpl.java:120) at org.hibernate.validator.internal.engine.ConfigurationImpl.<init>(ConfigurationImpl.java:96) at org.hibernate.validator.HibernateValidator.createGenericConfiguration(HibernateValidator.java:31) at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:276) {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6043) Hibernate validator fails most deployments on JDK9

by Gunnar Morling (JIRA)

[ https://issues.jboss.org/browse/WFLY-6043?page=com.atlassian.jira.plugin.... ] Gunnar Morling commented on WFLY-6043: -------------------------------------- Hey [~ctomc], I've released Hibernate Validator 5.2.3.Final with the version parsing fix and sent PR https://github.com/wildfly/wildfly/pull/8614 for updating HV in WildFly. > Hibernate validator fails most deployments on JDK9 > -------------------------------------------------- > > Key: WFLY-6043 > URL: https://issues.jboss.org/browse/WFLY-6043 > Project: WildFly > Issue Type: Sub-task > Components: EE, JPA / Hibernate > Affects Versions: 10.0.0.CR5 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > Hibernate validator wrongly parser java version string, which fails on JDK9 with Verona project based versioning. > {noformat} > javax.validation.ValidationException: Unable to instantiate Configuration. > at org.hibernate.validator.internal.util.Version.getJavaRelease(Version.java:36) > at org.hibernate.validator.internal.engine.ConfigurationImpl.<init>(ConfigurationImpl.java:120) > at org.hibernate.validator.internal.engine.ConfigurationImpl.<init>(ConfigurationImpl.java:96) > at org.hibernate.validator.HibernateValidator.createGenericConfiguration(HibernateValidator.java:31) > at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:276) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6079) Upgrade to Hibernate Validator 5.2.3.Final

by Gunnar Morling (JIRA)

[ https://issues.jboss.org/browse/WFLY-6079?page=com.atlassian.jira.plugin.... ] Gunnar Morling commented on WFLY-6079: -------------------------------------- This upgrade fixes WFLY-6043. > Upgrade to Hibernate Validator 5.2.3.Final > ------------------------------------------ > > Key: WFLY-6079 > URL: https://issues.jboss.org/browse/WFLY-6079 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Gunnar Morling > Assignee: Jason Greene > Fix For: 10.0.0.Final > > > Hibernate Validator 5.2.3.Final brings compatability with Java 9 and some other bug fixes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6079) Upgrade to Hibernate Validator 5.2.3.Final

by Gunnar Morling (JIRA)

Gunnar Morling created WFLY-6079: ------------------------------------ Summary: Upgrade to Hibernate Validator 5.2.3.Final Key: WFLY-6079 URL: https://issues.jboss.org/browse/WFLY-6079 Project: WildFly Issue Type: Component Upgrade Reporter: Gunnar Morling Assignee: Jason Greene Fix For: 10.0.0.Final Hibernate Validator 5.2.3.Final brings compatability with Java 9 and some other bug fixes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2016