March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6280) Can not call "visibility" bridged methods

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-6280?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-6280: ------------------------------- Fix Version/s: 10.1.0.Final > Can not call "visibility" bridged methods > ----------------------------------------- > > Key: WFLY-6280 > URL: https://issues.jboss.org/browse/WFLY-6280 > Project: WildFly > Issue Type: Bug > Affects Versions: 9.0.2.Final, 10.0.0.Final > Reporter: Trond G. Ziarkowski > Assignee: Scott Marlow > Labels: el > Fix For: 10.1.0.Final > > > After fix of WFLY-3456 all bridged methods are filtered which causes javax.el.MethodNotFoundException for "visibility" bridged methods. > This has been commented by [~bodist] in WFLY-3456, but nothing has been done to fix it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBEE-159) PropertyNotFoundException when the property is a JDK8 defender method

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBEE-159?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on JBEE-159: ----------------------------------- A patch would be helpful as well as reporting this issue upstream. I'm not yet sure of where the upstream repo is yet, otherwise I would mention it here. I assume its near [https://java.net/projects/glassfish/sources]. Thanks for reporting this Rich! :-) > PropertyNotFoundException when the property is a JDK8 defender method > --------------------------------------------------------------------- > > Key: JBEE-159 > URL: https://issues.jboss.org/browse/JBEE-159 > Project: JBoss JavaEE Spec APIs > Issue Type: Enhancement > Components: jboss-el-api > Affects Versions: jboss-el-api_3.0_spec-1.0.2.Final > Reporter: Rich DiCroce > Assignee: Scott Marlow > Priority: Minor > Labels: java8 > > I have a class that implements an interface that uses Java 8's new defender methods feature. Some getters on the interface have default implementations, and the concrete classes don't override them. > If I try to refer to one of these getters as a property like so: > {code:xml} > value="#{cc.filter.filter.valueChoices}" > {code} > Then I get this exception: > {noformat} > Caused by: javax.el.PropertyNotFoundException: The class 'com.lapis.jsf.framework.dao.search.DefaultEntityFilter' does not have the property 'valueChoices'. > at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:731) [jboss-el-api_3.0_spec-1.0.3.Final.jar:1.0.3.Final] > at javax.el.BeanELResolver.getValue(BeanELResolver.java:351) [jboss-el-api_3.0_spec-1.0.3.Final.jar:1.0.3.Final] > at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) [jsf-impl-2.2.6-jbossorg-4.jar:] > at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) [jsf-impl-2.2.6-jbossorg-4.jar:] > at com.sun.el.parser.AstValue.getValue(AstValue.java:140) [javax.el-3.0.0.jar:] > at com.sun.el.parser.AstValue.getValue(AstValue.java:204) [javax.el-3.0.0.jar:] > at com.sun.el.parser.AstEmpty.getValue(AstEmpty.java:66) [javax.el-3.0.0.jar:] > at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226) [javax.el-3.0.0.jar:] > at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] > at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] > at com.sun.faces.facelets.el.ContextualCompositeValueExpression.getValue(ContextualCompositeValueExpression.java:158) [jsf-impl-2.2.6-jbossorg-4.jar:] > at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109) [jsf-impl-2.2.6-jbossorg-4.jar:] > ... 68 more > {noformat} > Two workarounds exist. One: you can override the default method in a concrete class and have it just call the default super method. Two: you can call the getter using a method expression instead of a value expression. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6280) Can not call "visibility" bridged methods

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6280?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-6280: --------------------------------- Assignee: Scott Marlow (was: Tomaz Cerar) > Can not call "visibility" bridged methods > ----------------------------------------- > > Key: WFLY-6280 > URL: https://issues.jboss.org/browse/WFLY-6280 > Project: WildFly > Issue Type: Bug > Affects Versions: 9.0.2.Final, 10.0.0.Final > Reporter: Trond G. Ziarkowski > Assignee: Scott Marlow > Labels: el > > After fix of WFLY-3456 all bridged methods are filtered which causes javax.el.MethodNotFoundException for "visibility" bridged methods. > This has been commented by [~bodist] in WFLY-3456, but nothing has been done to fix it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-442) Fix copyright

by David Lloyd (JIRA)

David Lloyd created ELY-442: ------------------------------- Summary: Fix copyright Key: ELY-442 URL: https://issues.jboss.org/browse/ELY-442 Project: WildFly Elytron Issue Type: Bug Reporter: David Lloyd Assignee: David Lloyd Priority: Critical We have a mix of LGPL and ASL. Fix it all to ASL. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1090) Cached modificationMask in property reactivity is correctly retrieved but not set into the propagation context

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1090?page=com.atlassian.jira.plugi... ] Mario Fusco reassigned DROOLS-1090: ----------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > Cached modificationMask in property reactivity is correctly retrieved but not set into the propagation context > -------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1090 > URL: https://issues.jboss.org/browse/DROOLS-1090 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1090) Cached modificationMask in property reactivity is correctly retrieved but not set into the propagation context

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1090?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1090: -------------------------------- Component/s: core engine > Cached modificationMask in property reactivity is correctly retrieved but not set into the propagation context > -------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1090 > URL: https://issues.jboss.org/browse/DROOLS-1090 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1090) Cached modificationMask in property reactivity is correctly retrieved but not set into the propagation context

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1090: ----------------------------------- Summary: Cached modificationMask in property reactivity is correctly retrieved but not set into the propagation context Key: DROOLS-1090 URL: https://issues.jboss.org/browse/DROOLS-1090 Project: Drools Issue Type: Bug Reporter: Mario Fusco Assignee: Mark Proctor -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBAS-9576) Vault configuration with Tomcat without Jboss instance

by vip Singh (JIRA)

vip Singh created JBAS-9576: ------------------------------- Summary: Vault configuration with Tomcat without Jboss instance Key: JBAS-9576 URL: https://issues.jboss.org/browse/JBAS-9576 Project: Application Server 3 4 5 and 6 Issue Type: Bug Components: Security Reporter: vip Singh Assignee: Anil Saldanha Is it possible to use vault with tomcat without using any jboss instance. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6350) Configuration differences between default configuration and read/persisted in messaging and IIOP

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6350?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-6350: ------------------------------ Priority: Minor (was: Blocker) > Configuration differences between default configuration and read/persisted in messaging and IIOP > ------------------------------------------------------------------------------------------------ > > Key: WFLY-6350 > URL: https://issues.jboss.org/browse/WFLY-6350 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > > Following up on JBEAP-3093, there are still differences in these 2 subsystems: > {noformat} > 258a255 > > <orb socket-binding="iiop" ssl-socket-binding="iiop-ssl"/> > 337c334 > < <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/> > --- > > <role name="guest" send="true" consume="true" create-non-durable-queue="true" delete-non-durable-queue="true"/> > 339,341c336,338 > < <address-setting name="#" redistribution-delay="1000" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/> > < <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="http"/> > < <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"> > --- > > <address-setting name="#" dead-letter-address="jms.queue.DLQ" expiry-address="jms.queue.ExpiryQueue" max-size-bytes="10485760" page-size-bytes="2097152" message-counter-history-day-limit="10" redistribution-delay="1000"/> > > <http-connector name="http-connector" socket-binding="http" endpoint="http-acceptor"/> > > <http-connector name="http-connector-throughput" socket-binding="http" endpoint="http-acceptor-throughput"> > 353c350 > < <cluster-connection name="my-cluster" discovery-group="dg-group1" connector-name="http-connector" address="jms"/> > --- > > <cluster-connection name="my-cluster" address="jms" connector-name="http-connector" discovery-group="dg-group1"/> > 356,358c353,355 > < <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/> > < <connection-factory name="RemoteConnectionFactory" reconnect-attempts="-1" block-on-acknowledge="true" ha="true" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector"/> > < <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/> > --- > > <connection-factory name="InVmConnectionFactory" connectors="in-vm" entries="java:/ConnectionFactory"/> > > <connection-factory name="RemoteConnectionFactory" ha="true" block-on-acknowledge="true" reconnect-attempts="-1" connectors="http-connector" entries="java:jboss/exported/jms/RemoteConnectionFactory"/> > > <pooled-connection-factory name="activemq-ra" transaction="xa" connectors="in-vm" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory"/> > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1089) Reentrant working memory actions aren't flushed immediately even when eager evaluation is forced

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1089?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration updated DROOLS-1089: -------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1316860 Bugzilla Update: Perform > Reentrant working memory actions aren't flushed immediately even when eager evaluation is forced > ------------------------------------------------------------------------------------------------ > > Key: DROOLS-1089 > URL: https://issues.jboss.org/browse/DROOLS-1089 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.4.0.CR2, 7.0.0.Final > > > jBPM requires Drools working memory actions to be immediately flushed and then uses Drools force eager activation option. However even when this option is enabled working memory actions that aren't created in a reentrant way (during a rule firing) are enqueued instead of being flushed as expected by jBPM. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

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 2016