May 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3345) Compilation error in clustering/web/infinispan w/ JDK 8u20 and Windows

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-3345?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-3345: ------------------------------------ I'm escalating this to blocker, to encourage this to be merged for 8.1.0.Final. > Compilation error in clustering/web/infinispan w/ JDK 8u20 and Windows > ---------------------------------------------------------------------- > > Key: WFLY-3345 > URL: https://issues.jboss.org/browse/WFLY-3345 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 8.1.0.CR2 > Reporter: Juergen Zimmermann > Assignee: Paul Ferraro > Priority: Blocker > Fix For: 8.1.0.Final, 9.0.0.Alpha1 > > > In clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/SimpleImmutableSessionAttributes.java I'm getting the following compilation error which IMHO is also a logical error: > {code} > [ERROR] /C:/temp/wildfly-8.1.0.CR2/clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/SimpleImmutableSessionAttributes.java:[42,17] variable attributes might not have been initialized > {code} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-508) SpEL support for Kie-Spring

by Vinod Kiran Paidimarry (JIRA)

Vinod Kiran Paidimarry created DROOLS-508: --------------------------------------------- Summary: SpEL support for Kie-Spring Key: DROOLS-508 URL: https://issues.jboss.org/browse/DROOLS-508 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Vinod Kiran Paidimarry Assignee: Mark Proctor -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3386) Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-3386?page=com.atlassian.jira.plugin.... ] Martin Kouba commented on WFLY-3386: ------------------------------------ [~andriese] FYI since CDI 1.1 the conversation context is active during any Servlet request. Do you know when is the {{BusinessProcess.startTask()}} method called? Also what versions of CDI does Activiti support? > Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI > --------------------------------------------------------------------------------------- > > Key: WFLY-3386 > URL: https://issues.jboss.org/browse/WFLY-3386 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.Final > Environment: CentOS, Mac (Mountain Lion). > Reporter: Andries Ehlers > Assignee: Martin Kouba > > Background: > The actual exception seems to be very close the one in issue: WFLY-3001 but we are not using JSF at all, but Activiti CDI. > Not sure if this is a Wildfly or Activiti issue - it could very well be that there is a bug in Activiti with how it manages the CDI scopes. Unfortunately we're at a loss and seeing that the nullpointer is thrown from within a weld AbstractSessionBeanStore, I decided to post it here. Please advise. > Error: > We use Activiti CDI within Wildfly 8.0.0.Final. We randomly encounter an issue (sometimes immediately after a redeploy, other times after a few hours of inactivity on the server) the following issue. When Activiti attempts to retrieve the ContextBeanInstance from its ConversationScopedAssociationProxy, a NullPointer exception is thrown while attempting to retrieve the lock store within Weld (see below). > ----------------------------- > 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) java.lang.NullPointerException: null > 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:90) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager$ConversationScopedAssociation$Proxy$_$$_WeldClientProxy.getTask(Unknown Source) ~[activiti-cdi-5.15.jar:na] > 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager.getTask(DefaultContextAssociationManager.java:237) ~[activiti-cdi-5.15.jar:na] > 2014-05-21 10:05:34,432 INFO [stdout] (default task-12) at org.activiti.cdi.BusinessProcess.startTask(BusinessProcess.java:332) ~[activiti-cdi-5.15.jar:na] -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-479) Pseudo Clock doesn't work for 2 not statements

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-479?page=com.atlassian.jira.plugin... ] Davide Sottara commented on DROOLS-479: --------------------------------------- As you pointed out, this test will work if you use the real time clock - there is no concept of "frozen time" there :) > Pseudo Clock doesn't work for 2 not statements > ---------------------------------------------- > > Key: DROOLS-479 > URL: https://issues.jboss.org/browse/DROOLS-479 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.1.Final, 6.1.0.Beta3 > Environment: linux 14.04 > Reporter: Richard Ambridge > Assignee: Mark Proctor > Labels: pseudoclock > > If a rule (event) has the following: > + "when\n" > + " $s : Cheese(type==\"stinky\")\n" > + " not( Cheese(type==\"a\", this after [0s,3s] $s ) )\n" > + " not( Cheese(type==\"b\", this after [0s,5s] $s ) )\n" //2 * not > and pseudo clock is used, the rule doesn't fire. > If realtime clock is used, the rule works. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-479) Pseudo Clock doesn't work for 2 not statements

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-479?page=com.atlassian.jira.plugin... ] Davide Sottara edited comment on DROOLS-479 at 5/30/14 9:13 AM: ---------------------------------------------------------------- Please see my comments on the pull request "The problem is actually a race between the FireThread and the main thread. In Drools 6, the rule is evaluated and enabled when "fire" kicks in for the first time. The rule is then scheduled +3s later as soon as the time advances. In your case, when you advance the pseudo clock. However, it may be the case that the main thread will advance the clock BEFORE the Fire Thread has activated the rule. If so, the rule will be considered the NEXT time you advance (again) the time. To make this test work, you'll have to make sure that the FireThread is awakened at least once before you move the pseudo clock" was (Author: dsotty): Please see my comments on the pull request > Pseudo Clock doesn't work for 2 not statements > ---------------------------------------------- > > Key: DROOLS-479 > URL: https://issues.jboss.org/browse/DROOLS-479 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.1.Final, 6.1.0.Beta3 > Environment: linux 14.04 > Reporter: Richard Ambridge > Assignee: Mark Proctor > Labels: pseudoclock > > If a rule (event) has the following: > + "when\n" > + " $s : Cheese(type==\"stinky\")\n" > + " not( Cheese(type==\"a\", this after [0s,3s] $s ) )\n" > + " not( Cheese(type==\"b\", this after [0s,5s] $s ) )\n" //2 * not > and pseudo clock is used, the rule doesn't fire. > If realtime clock is used, the rule works. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3221) flushOnSessionInvalidation attribute in jboss-web.xml does not flush user credentials

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3221?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-3221: ---------------------------------------- Feel free to comment here if you run into any issues but overall community contributions are always welcome. > flushOnSessionInvalidation attribute in jboss-web.xml does not flush user credentials > ------------------------------------------------------------------------------------- > > Key: WFLY-3221 > URL: https://issues.jboss.org/browse/WFLY-3221 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 8.0.0.Final > Reporter: Jorge Marmolejo > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 9.0.0.Alpha1 > > > The attribute flushOnSessionInvalidation does not flush the user credentials when the session is invalidated or when it times out. If the password or roles change for the user, the only way to get the new changes is by restarting the server. > I tried removing "cache-type=default" from the standalone-full.xml and it works, but for every action made on the site, the login method in the authentication module is called. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3221) flushOnSessionInvalidation attribute in jboss-web.xml does not flush user credentials

by Pavel Kovalenko (JIRA)

[ https://issues.jboss.org/browse/WFLY-3221?page=com.atlassian.jira.plugin.... ] Pavel Kovalenko commented on WFLY-3221: --------------------------------------- I never participated in opensource projects. But I will try to solve this problem on server-side level at the weekend. > flushOnSessionInvalidation attribute in jboss-web.xml does not flush user credentials > ------------------------------------------------------------------------------------- > > Key: WFLY-3221 > URL: https://issues.jboss.org/browse/WFLY-3221 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 8.0.0.Final > Reporter: Jorge Marmolejo > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 9.0.0.Alpha1 > > > The attribute flushOnSessionInvalidation does not flush the user credentials when the session is invalidated or when it times out. If the password or roles change for the user, the only way to get the new changes is by restarting the server. > I tried removing "cache-type=default" from the standalone-full.xml and it works, but for every action made on the site, the login method in the authentication module is called. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3420) UndertowJSRWebSocketDeploymentProcessor uses hard coded IO module dependencies

by Matthias Berndt (JIRA)

Matthias Berndt created WFLY-3420: ------------------------------------- Summary: UndertowJSRWebSocketDeploymentProcessor uses hard coded IO module dependencies Key: WFLY-3420 URL: https://issues.jboss.org/browse/WFLY-3420 Project: WildFly Issue Type: Enhancement Security Level: Public (Everyone can see) Components: IO, Web (Undertow) Environment: any Reporter: Matthias Berndt Assignee: Stuart Douglas Priority: Minor UndertowJSRWebSocketDeploymentProcessor uses hard coded dependencies to a buffer pool und worker pool named "default" of the IO module. My suggestion is to introduce two additional attributes "worker" and "buffer-pool" to the undertow module get rid of the hard coded pools. The default values will garanty a compatibility. If you agree to this approach i'll provide a patch adding und using these attributes. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3221) flushOnSessionInvalidation attribute in jboss-web.xml does not flush user credentials

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3221?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-3221: ---------------------------------------- It sounds like you have a good understanding of the problem and have spent some time understanding the code in this area, why not finish off your solution to make it generic and get a pull request sent over? That way we can get your changes incorporated in master. > flushOnSessionInvalidation attribute in jboss-web.xml does not flush user credentials > ------------------------------------------------------------------------------------- > > Key: WFLY-3221 > URL: https://issues.jboss.org/browse/WFLY-3221 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 8.0.0.Final > Reporter: Jorge Marmolejo > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 9.0.0.Alpha1 > > > The attribute flushOnSessionInvalidation does not flush the user credentials when the session is invalidated or when it times out. If the password or roles change for the user, the only way to get the new changes is by restarting the server. > I tried removing "cache-type=default" from the standalone-full.xml and it works, but for every action made on the site, the login method in the authentication module is called. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3404) Major performance degradation from JBoss 7.1 to Wildfly 8.0.0-Final.

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/WFLY-3404?page=com.atlassian.jira.plugin.... ] jaikiran pai commented on WFLY-3404: ------------------------------------ I think this was fixed in a later release as noted in https://community.jboss.org/message/862500#862500. Try the later releases from here http://wildfly.org/downloads/ > Major performance degradation from JBoss 7.1 to Wildfly 8.0.0-Final. > -------------------------------------------------------------------- > > Key: WFLY-3404 > URL: https://issues.jboss.org/browse/WFLY-3404 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Final > Reporter: Timothy Heider > Assignee: Jason Greene > > I have deployed my application to Wildfly 8.0.0 Final and it is almost unusable now. We have rolled back to JBoss 7.1 (same application WARs) and it works fine. > Specifically what seems to be slow is our SOAP web services are taking up to 8 to 10 seconds to respond. We have user concurrency of probably 10-30 users at once hitting these services every 10 seconds or so. > On JBoss 7.1 these services all respond sub-second. The database is totally unburdened and the server is 90% idle all the time. > We have one service endpoint that is a Comet queue wait call. Probably 10 users are waiting on that. Did something change between JBoss 7 and Wildfly 8 that might cause that to not work now? (e.g. too small a thread pool that blocks until the 10 second comet call breaks on a timeout?) > We will try 8.1.0CR2 but I wanted to report we're investigating this and see if you can help us. Thanks! -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 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 May 2014