January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1336) Upgrade jboss-modules to 1.5.1

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1336?page=com.atlassian.jira.plugi... ] Tomaz Cerar reassigned WFCORE-1336: ----------------------------------- Assignee: David Lloyd (was: David Laffranchi) > Upgrade jboss-modules to 1.5.1 > ------------------------------ > > Key: WFCORE-1336 > URL: https://issues.jboss.org/browse/WFCORE-1336 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Modules > Affects Versions: 2.0.7.Final > Reporter: Tomaz Cerar > Assignee: David Lloyd > Priority: Blocker > Fix For: 2.0.8.Final > > > We need new jboss-modules release that addresses MODULES-239 > so we can fix JBEAP-2112 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1336) Upgrade jboss-modules to 1.5.1

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFCORE-1336: ----------------------------------- Summary: Upgrade jboss-modules to 1.5.1 Key: WFCORE-1336 URL: https://issues.jboss.org/browse/WFCORE-1336 Project: WildFly Core Issue Type: Component Upgrade Components: Modules Affects Versions: 2.0.7.Final Reporter: Tomaz Cerar Assignee: David Laffranchi Priority: Blocker Fix For: 2.0.8.Final We need new jboss-modules release that addresses MODULES-239 so we can fix JBEAP-2112 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1959) Getting establishLease Thread Blocked even after applying JBREM1297

by Rajesh Malla (JIRA)

Rajesh Malla created JBMESSAGING-1959: ----------------------------------------- Summary: Getting establishLease Thread Blocked even after applying JBREM1297 Key: JBMESSAGING-1959 URL: https://issues.jboss.org/browse/JBMESSAGING-1959 Project: JBoss Messaging Issue Type: Patch Components: JMS Remoting Reporter: Rajesh Malla Priority: Critical We are getting following error even after applying JBREM-1297 patch applied. Hence we are not able to find out cause for this. Caused by: java.lang.Exception: Error setting up client lease at org.jboss.remoting.MicroRemoteClientInvoker.establishLease(MicroRemoteClientInvoker.java:563) at org.jboss.remoting.Client.setupClientLease(Client.java:2070) at org.jboss.remoting.Client.connect(Client.java:1924) ... 83 more Caused by: org.jboss.remoting.InvocationFailureException: Socket timed out. Waited 30000 milliseconds for response while calling on InvokerLocator [bisocket://denalicm002:4457/?JBM_clientMaxPoolSize=200&clientLeasePeriod=10000&clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper&dataType=jms&failureDisconnectTimeout=0&generalizeSocketException=true&marshaller=org.jboss.jms.wireformat.JMSWireFormat&numberOfCallRetries=5&pingFrequency=30000&pingWindowFactor=71582&socket.check_connection=false&stopLeaseOnFailure=true&timeout=300000&unmarshaller=org.jboss.jms.wireformat.JMSWireFormat&useClientConnectionIdentity=true&validatorPingPeriod=10000&validatorPingTimeout=5000]; nested exception is: java.net.SocketTimeoutException: Read timed out at org.jboss.remoting.transport.socket.SocketClientInvoker.handleException(SocketClientInvoker.java:137) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.handleOtherException(MicroSocketClientInvoker.java:1079) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:941) at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:470) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:169) at org.jboss.remoting.MicroRemoteClientInvoker.establishLease(MicroRemoteClientInvoker.java:529) ... 85 more Caused by: java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:152) at java.net.SocketInputStream.read(SocketInputStream.java:122) at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) at java.io.BufferedInputStream.read(BufferedInputStream.java:254) at java.io.FilterInputStream.read(FilterInputStream.java:83) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.readVersion(MicroSocketClientInvoker.java:1342) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:895) ... 88 more -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

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

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6079?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-6079: ------------------------------ Affects Version/s: 10.0.0.CR5 > 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 > Affects Versions: 10.0.0.CR5 > 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)

10 years, 3 months

1
0
0 / 0

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

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6079?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-6079: ------------------------------ Component/s: JPA / Hibernate > 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 > Components: JPA / Hibernate > Affects Versions: 10.0.0.CR5 > 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)

10 years, 3 months

1
0
0 / 0

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

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6079?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-6079: ------------------------------ Priority: Critical (was: Major) > 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 > Components: JPA / Hibernate > Affects Versions: 10.0.0.CR5 > Reporter: Gunnar Morling > Assignee: Jason Greene > Priority: Critical > 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)

10 years, 3 months

1
0
0 / 0

[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)

10 years, 3 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)

10 years, 3 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)

10 years, 3 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)

10 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2016