March 2014 - jboss-jira - Jboss List Archives

[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

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

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

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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1547) deploy directories not cleaned up

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1547: ----------------------------------------------- James Livingston <jlivings(a)redhat.com> changed the Status of [bug 901210|https://bugzilla.redhat.com/show_bug.cgi?id=901210] from ASSIGNED to POST > deploy directories not cleaned up > --------------------------------- > > Key: WFLY-1547 > URL: https://issues.jboss.org/browse/WFLY-1547 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Alpha1 > Reporter: Shaun Appleton > Assignee: jaikiran pai > Fix For: 8.0.0.Beta1 > > Attachments: deployment_with_hack_no_hook.txt > > > JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories. > The following reproduces this - > i) ensure run.conf has the -Xrs set > ii) ensure deployments has a deployable .ear in it > iii) ./run standalone.sh and allow the deployments to deploy > iv) stop the EAP process ie kill <process_id> > v) observe content tmp/vfs > (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP) > This will eventually cause problems with lack of disk space. > Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems. > It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-457) TaskModelProvider's ServiceLoader sync problem

by Mariano De Maio (JIRA)

[ https://issues.jboss.org/browse/DROOLS-457?page=com.atlassian.jira.plugin... ] Mariano De Maio resolved DROOLS-457. ------------------------------------ Fix Version/s: 6.1.0.Beta2 Resolution: Done Pull request merged into master by Maciej Swiderski > TaskModelProvider's ServiceLoader sync problem > ---------------------------------------------- > > Key: DROOLS-457 > URL: https://issues.jboss.org/browse/DROOLS-457 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1, 6.1.0.Beta2, 6.1.0.Final > Reporter: Mariano De Maio > Assignee: Mark Proctor > Fix For: 6.1.0.Beta2 > > Attachments: test-case.zip > > > This bug was found related to jBPM6 components, but its solution needs to be implemented in the kie-internal project, hence we report it in this project. > When the TaskModelProvider access the factory object, it iterates the service loader directly. Unfortunately, the ServiceLoader class states: > "Instances of this class are not safe for use by multiple concurrent threads." (http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html) > This causes that environments that need to use the TaskModelProvider from different threads with no prior invocation. > I'll add a maven test to reproduce the issue. We have also a solution we'll submit in a pull request -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3108) Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3108?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3108: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1076066|https://bugzilla.redhat.com/show_bug.cgi?id=1076066] from ASSIGNED to POST > Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml > -------------------------------------------------------------------------------------------- > > Key: WFLY-3108 > URL: https://issues.jboss.org/browse/WFLY-3108 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.0.1.Final > > > The prescribed mechanism for converting a slave HC to master is to: > 1) Start the slave with --backup so a local copy of the domain config is maintained (in file domain.cached-remote.xml). > 2) Stop the existing master. > 3) Use the cli to connect to the slave and > /host=<slavename>:write-local-domain-controller > 4) Then, in the CLI > reload --host=<slavename> > Problem is this fails because the HC expects to have a domain config file "domain.xml". > 2014-03-13 09:54:04,829 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:514) [wildfly-host-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45] > Caused by: java.io.FileNotFoundException: /Users/bstansberry/tmp/WF801/slave/domain/configuration/domain.xml (No such file or directory) > at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_45] > at java.io.FileInputStream.<init>(FileInputStream.java:146) [rt.jar:1.7.0_45] > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > ... 3 more > Or, MUCH WORSE, there happens to be a random domain.xml in the filesystem, which has content that is out of sync with the correct domain config. This domain.xml config will be used. -- 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

10 years, 10 months

1
0
0 / 0

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

by rafael liu (JIRA)

[ https://issues.jboss.org/browse/WFLY-332?page=com.atlassian.jira.plugin.s... ] rafael liu commented on WFLY-332: --------------------------------- Also there's have a more specific use case where the user can set a certain sessionDrainingStrategy value at the moment of the *redeploy*. I think mod_cluster doesn't support this kind o ad-hoc configuration, but IMO that has some real usages: 1. Suppose sessionDrainingStrategy=DEFAULT/ALWAYS, if there's 1 user hanging (say doing a huge download) the redeploy will timeout. Even worst, in a N node scenario, there will be N-1 nodes active during that time. 2. Again with sessionDrainingStrategy=DEFAULT/ALWAYS, if there's a critical bug, draining may not make sense or may introduce an undesirable delay. > 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-455) Event expiration calculation may overflow

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-455?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-455: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1076361|https://bugzilla.redhat.com/show_bug.cgi?id=1076361] from ASSIGNED to MODIFIED > Event expiration calculation may overflow > ----------------------------------------- > > Key: DROOLS-455 > URL: https://issues.jboss.org/browse/DROOLS-455 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1 > Reporter: Davide Sottara > Assignee: Mario Fusco > Priority: Critical > Fix For: 6.1.0.Beta2 > > > The calculation of the expiration timestamp of an event in the OTN is effectively given by the combination : > {code} > Handle.startTimeStamp + Handle.duration + OTN.expirationOffset > {code} > If the addition overflows, the event will be scheduled for expiration immediately. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3120) Upgrade JSF based on Mojarra 2.2.6 Final

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFLY-3120?page=com.atlassian.jira.plugin.... ] Farah Juma updated WFLY-3120: ----------------------------- Summary: Upgrade JSF based on Mojarra 2.2.6 Final (was: Upgrade jsf-impl to 2.2.5-jbossorg-4) > Upgrade JSF based on Mojarra 2.2.6 Final > ---------------------------------------- > > Key: WFLY-3120 > URL: https://issues.jboss.org/browse/WFLY-3120 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: JSF > Affects Versions: 8.0.0.Final > Reporter: Farah Juma > Assignee: Farah Juma > > Incorporate the patch for WFLY-2594/[JAVASERVERFACES-3189|https://java.net/jira/browse/JAVASERVERFA... for WildFly 8.0.1.Final. -- 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

10 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2014