March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-430) Fails to parse DSL variable definition with single dot regex

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-430?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-430: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1065868|https://bugzilla.redhat.com/show_bug.cgi?id=1065868] from ON_QA to VERIFIED > Fails to parse DSL variable definition with single dot regex > ------------------------------------------------------------ > > Key: DROOLS-430 > URL: https://issues.jboss.org/browse/DROOLS-430 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.1.Final > Reporter: Toshiya Kobayashi > Assignee: Edson Tirelli > Fix For: 6.1.0.Beta1 > > > Drools fails to parse DSL variable definition with single dot regex, where I want one any character. > {noformat} > [then]Log {message:.}=list.add(\"{message}\"); > {noformat} > Error message: > {noformat} > [1,19]: DSL parser error > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1891) HTTPSession sharing between wars delivered in an EAR

by Patrick Bajeneza (JIRA)

[ https://issues.jboss.org/browse/WFLY-1891?page=com.atlassian.jira.plugin.... ] Patrick Bajeneza commented on WFLY-1891: ---------------------------------------- Hello Stuart, Do you have any update for this case? Thanks > HTTPSession sharing between wars delivered in an EAR > ---------------------------------------------------- > > Key: WFLY-1891 > URL: https://issues.jboss.org/browse/WFLY-1891 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Reporter: John Doyle > Assignee: Stuart Douglas > > WAS and WL have this feature, and its been requested for several earlier versions of AS. Having this capability will ease the migration of users from WAS and WL to WildFly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-332) Add sessionDrainingStrategy configuration option to modcluster subsystem

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-332?page=com.atlassian.jira.plugin.s... ] Radoslav Husar commented on WFLY-332: ------------------------------------- Rafael, if I understand correctly, you are saying that having session-draining-strategy configuration separately for undeploy and redeploy would make sense? I am somewhat failing to see how. In case #1, the redeployment should not fail, the session just won't be drained in time, then the app will be redeployed. While at it, in such use case, one would use e.g. mod_cluster manager to draing the sessions manually in order to prevent termination of a very long running requests. Those are not common though. Also, there is always n-1 when the app is undeployed. In case #2, you would upgrade whole cluster immediately and won't perform any session draining. > Add sessionDrainingStrategy configuration option to modcluster subsystem > ------------------------------------------------------------------------ > > Key: WFLY-332 > URL: https://issues.jboss.org/browse/WFLY-332 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Radoslav Husar > Assignee: Jean-Frederic Clere > Fix For: 8.0.0.Beta1 > > > Add sessionDrainingStrategy configuration option to modcluster subsystem > * xsd 1.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3007) Ipv6 addresses may not be canonized properly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3007?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3007: ----------------------------------------------- Pavel Jelinek <pjelinek(a)redhat.com> changed the Status of [bug 1067348|https://bugzilla.redhat.com/show_bug.cgi?id=1067348] from ON_QA to VERIFIED > Ipv6 addresses may not be canonized properly > -------------------------------------------- > > Key: WFLY-3007 > URL: https://issues.jboss.org/browse/WFLY-3007 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Final > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > > On an ipv6 environment we may obtain IP addresses that are not properly canonized which may lead to strange issue with http proxies since the JDK ProxySelector relies on char per char matching. > All call to InetAddress.getHostName() may produce such an uncanonized address. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3077) Convert command line IPv6 URL literals to address literals

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3077?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3077: ----------------------------------------------- Miroslav Novak <mnovak(a)redhat.com> changed the Status of [bug 1064771|https://bugzilla.redhat.com/show_bug.cgi?id=1064771] from ON_QA to VERIFIED > Convert command line IPv6 URL literals to address literals > ---------------------------------------------------------- > > Key: WFLY-3077 > URL: https://issues.jboss.org/browse/WFLY-3077 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Fix For: 8.0.1.Final > > > When people provide URL-style values like [::1] for command line args like -b, convert them to address values (i.e. strip the enclosing brackets.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3121) Upgrade to JBossWS 4.3.0.Final

by Alessio Soldano (JIRA)

Alessio Soldano created WFLY-3121: ------------------------------------- Summary: Upgrade to JBossWS 4.3.0.Final Key: WFLY-3121 URL: https://issues.jboss.org/browse/WFLY-3121 Project: WildFly Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: Web Services Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: 9.0.0.CR1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBEE-146) jboss-el-api_2.2_spec 1.0.2.Final cannot access public methods from non-public classes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBEE-146?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on JBEE-146: ---------------------------------------------- Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from POST to MODIFIED > jboss-el-api_2.2_spec 1.0.2.Final cannot access public methods from non-public classes > -------------------------------------------------------------------------------------- > > Key: JBEE-146 > URL: https://issues.jboss.org/browse/JBEE-146 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Reporter: Farah Juma > Assignee: Farah Juma > Fix For: jboss-el-api_2.2_spec-1.0.3.Final, jboss-el-api_3.0_spec-1.0.0.Final > > > When accessing a public method of a non-public class via EL that implements a public interface or has a public superclass, the following exception occurs: > {code}java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "public" > {code} > See https://bugzilla.redhat.com/show_bug.cgi?id=1029387 for more details. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2493) EL cannot access public methods/fields of non-public classes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2493?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2493: ----------------------------------------------- Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from POST to MODIFIED > EL cannot access public methods/fields of non-public classes > ------------------------------------------------------------ > > Key: WFLY-2493 > URL: https://issues.jboss.org/browse/WFLY-2493 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JSF > Environment: JBoss AS 7.2.0.Final > Reporter: Jonáš Trantina > Attachments: elresolver_stack, reproducer.zip > > > When trying to access public method/field of non-public class that implements public interface via EL I get > {noformat} > java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "private" > {noformat} > E.g. accessing Collections.unmodifiableList(..).size() via EL will throw the exception, because #unmodifiableList returns non-public implementation of List interface. > This is apparently caused by JDK-4071957 [1], but since that is opened for over 16 years, it should be probably worth it to implement a workaround. > Workaround for this issue is setting setAccessible(true) on the method before invoking it, thus suppress Java access checking. > I have attached a simple reproducer app as well as a stack trace of the exception. > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1807) UNICAST: skipping of seqnos

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1807?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated JGRP-1807: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1077096 > UNICAST: skipping of seqnos > --------------------------- > > Key: JGRP-1807 > URL: https://issues.jboss.org/browse/JGRP-1807 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.2.13, 3.5 > > > {noformat} > The log starts with: > 10-Mar-2014 13:21:47 WARN [org.jgroups.protocols.UNICAST2] (OOB-105,shared=tcp) node1/web: (requester=node2/web) message node2/web::1511786 not found in retransmission table of node2/web: > [1511785 | 1511785 | 1511857] (53 elements, 19 missing) > The numbers are 1511786-1511804 for "not found in retransmission...." > And end: > 10-Mar-2014 14:48:26 WARN [org.jgroups.protocols.UNICAST2] (OOB-118,shared=tcp) node1/web: (requester=node2/web) message node2/web::1511804 not found in retransmission table of node2/web: > [1511785 | 1511785 | 1514802] (2998 elements, 19 missing) > {noformat} > It seems that node1 is missing messages 1511785-1511804 which it sent to node2. Since a null message cannot be added to the sender table (due to the {{msg.isFlagSet()}} which would throw an NPE), I asume we're skipping a seqno: > In {{UNICAST}}, {{UNICAST2}} and {{UNICAST3}} {{down()}}, if a seqno is skipped, we get endless retransmissions. Example: > * We get the next seqno 1, add the message to the table and send it > * We get the next seqno 2. However, if {{running}} is false, we don't add the message > * We get the next seqno 3. Now {{running}} is true, and we add 3 to the table > --> Now we have a missing message 2 which will always be null as it hasn't been added to the table > This is highly unlikely, as I haven't been able to find a scenario where running flips from true to false to true quickly. If it flips from true to false, this is because {{stop()}} has been called. Also, in {{down()}}, we actually check {{running}} and return if false. > In this scenario, the connections are all removed, so seqno is reset to 1. > Anyway, I'm going to replace the {{while(running)}} loop with a {{do while(running)}} loop, so we always add the message to the table, even if running=false. > [1] https://github.com/belaban/JGroups/blob/Branch_JGroups_3_2/src/org/jgroup... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2648) Review/move the per-logging deployment tests

by Petr Kremensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-2648?page=com.atlassian.jira.plugin.... ] Petr Kremensky commented on WFLY-2648: -------------------------------------- Same here :). I remember there was some issue when we use both logging profile and per-deploy logging, so I cover that. > Review/move the per-logging deployment tests > -------------------------------------------- > > Key: WFLY-2648 > URL: https://issues.jboss.org/browse/WFLY-2648 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Test Suite > Reporter: James Perkins > Assignee: Petr Kremensky > Priority: Minor > > The {{org.jboss.as.logging.per-deployment}} property has been deprecated. There are two tests {{LoggingPerDeployFalseTestCase}} and {{LoggingPreferencesPerDeployFalseTestCase}} that use this property. They need to be copied and/or moved to the manualmode tests and modified to use the new attribute. > Also these tests appear not to work correctly. Breaking the system property during the patch, the tests still seemed to pass. They need to be reviewed and tested when working on this issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 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 March 2014