December 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1558) Discovery: don't suppress response when merging for non-merge triggered discovery requests

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1558?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1558: -------------------------------- Another change we could make is to return only the physical address (and logical name) of X when a GET_PHYSICAL_ADDR event is received in Discovery. Currently, this results in a multicast GET_MBRS_REQ to which every node responds with a GET_MBRS_RSP including its own physical address. This should be changed to have only members who actually have the physical address for X respond to the original sender. Perhaps a new header request type ? > Discovery: don't suppress response when merging for non-merge triggered discovery requests > ------------------------------------------------------------------------------------------ > > Key: JGRP-1558 > URL: https://issues.jboss.org/browse/JGRP-1558 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3 > > > In Discovery, when receiving a discovery request, we discard it if a merge is running (isMergeRunning()). The condition should be moved into the if-clause above (hdr.view_id != null), as it only applies to merge-triggered discoveries. When handling a regular discovery, e.g. at startup or when a physical address is looked up, a discovery response should be sent. -- 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

1
0
0 / 0

[JBoss JIRA] (JGRP-1558) Discovery: don't suppress response when merging for non-merge triggered discovery requests

by Bela Ban (JIRA)

Bela Ban created JGRP-1558: ------------------------------ Summary: Discovery: don't suppress response when merging for non-merge triggered discovery requests Key: JGRP-1558 URL: https://issues.jboss.org/browse/JGRP-1558 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.3 In Discovery, when receiving a discovery request, we discard it if a merge is running (isMergeRunning()). The condition should be moved into the if-clause above (hdr.view_id != null), as it only applies to merge-triggered discoveries. When handling a regular discovery, e.g. at startup or when a physical address is looked up, a discovery response should be sent. -- 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

1
0
0 / 0

[JBoss JIRA] (JASSIST-189) Bridge methods are proxied instead of desired methods

by Donnchadh Ó Donnabháin (JIRA)

[ https://issues.jboss.org/browse/JASSIST-189?page=com.atlassian.jira.plugi... ] Donnchadh Ó Donnabháin commented on JASSIST-189: ------------------------------------------------ The following patch seems to fix the problem for us: {noformat} Index: src/main/javassist/util/proxy/ProxyFactory.java =================================================================== --- src/main/javassist/util/proxy/ProxyFactory.java (revision 698) +++ src/main/javassist/util/proxy/ProxyFactory.java (working copy) @@ -1123,6 +1123,9 @@ // we tried to overwrite a public definition with a non-public definition, // use the old definition instead. hash.put(key, oldMethod); + } else if (null != oldMethod && !oldMethod.isBridge() && methods[i].isBridge() + && oldMethod.getDeclaringClass() == methods[i].getDeclaringClass()) { + hash.put(key, oldMethod); } } } {noformat} > Bridge methods are proxied instead of desired methods > ----------------------------------------------------- > > Key: JASSIST-189 > URL: https://issues.jboss.org/browse/JASSIST-189 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.17.1-GA > Environment: OS X, Java 1.7.0_09 > Reporter: Donnchadh Ó Donnabháin > Assignee: Shigeru Chiba > > The following test intermittently fails: > {code} > package org.javassist.test.covariantproxy; > import java.lang.reflect.Method; > import javassist.util.proxy.MethodHandler; > import javassist.util.proxy.ProxyFactory; > import javassist.util.proxy.ProxyObject; > import junit.framework.TestCase; > public class CovariantProxyTest extends TestCase { > > public interface TestProxy { > > } > > public static class TestMethodHandler implements MethodHandler { > > boolean invoked = false; > public Object invoke(Object self, Method thisMethod, Method proceed, Object[] args) throws Throwable { > invoked = true; > return proceed.invoke(self, args); > } > > public boolean wasInvoked() { > return invoked; > } > public void reset() { > invoked = false; > } > } > public static class Issue { > > private Integer id; > > public Integer getId() { > return id; > } > > public void setId(Integer id) { > this.id = id; > } > } > > public static class PublishedIssue extends Issue { > > } > public static abstract class Article { > > private Integer id; > > public Integer getId() { > return id; > } > > public void setId(Integer id) { > this.id = id; > } > > public abstract Issue getIssue(); > } > public static class PublishedArticle extends Article { > > private PublishedIssue issue; > > @Override > public PublishedIssue getIssue() { > return issue; > } > > public void setIssue(PublishedIssue issue) { > this.issue = issue; > } > > } > > public void testThatCallingAMethodWithCovariantReturnTypeCallsProxy() throws Exception { > Class persistentClass = PublishedArticle.class; > ProxyFactory factory = new ProxyFactory(); > factory.setUseCache(false); > factory.setSuperclass(persistentClass); > factory.setInterfaces(new Class[] {TestProxy.class}); > Class cl = factory.createClass(); > TestProxy proxy = ( TestProxy ) cl.newInstance(); > TestMethodHandler methodHandler = new TestMethodHandler(); > ( ( ProxyObject ) proxy ).setHandler( methodHandler ); > > ((Article)proxy).getIssue(); > assertTrue(methodHandler.wasInvoked()); > > methodHandler.reset(); > > PublishedArticle article = (PublishedArticle) proxy; > > article.getIssue(); > > assertTrue(methodHandler.wasInvoked()); > > } > > } > {code} > Were there tests added for JASSIST-24 ? I don't see any associated source. > This bug causes a problem in hibernate, described in https://hibernate.onjira.com/browse/HHH-7884 . > This may be related to JASSIST-162 but the circumstances are slightly different. > The problem occurs intermittently so it appears to depend on the order in which the methods are processed. -- 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

1
0
0 / 0

[JBoss JIRA] (AS7-6246) Naming context read-only during legacy SAR deployment

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/AS7-6246?page=com.atlassian.jira.plugin.s... ] Eduardo Martins reassigned AS7-6246: ------------------------------------ Assignee: Eduardo Martins (was: Stuart Douglas) > Naming context read-only during legacy SAR deployment > ----------------------------------------------------- > > Key: AS7-6246 > URL: https://issues.jboss.org/browse/AS7-6246 > Project: Application Server 7 > Issue Type: Bug > Components: JMX > Affects Versions: 7.2.0.Alpha1 > Reporter: Philippe Marschall > Assignee: Eduardo Martins > Labels: jmx, jndi, naming, sar > > When the {{#startService()}} and {{#stopService()}} methods of a sublass of {{ServiceMBeanSupport}} are invoked the JNDI context is read only. > Consider the following MBean: > {code} > public class LegacySample extends ServiceMBeanSupport implements LegacySampleMBean { > private static final String NAME = "java:global/env/foo/legacy"; > private static final String VALUE = "BAR"; > private static final Logger LOG = Logger.getLogger("sar-legacy"); > public LegacySample() { > super(); > } > @Override > protected void startService() throws Exception { > InitialContext ic = new InitialContext(); > ic.rebind(NAME, VALUE); > LOG.info("started"); > } > @Override > protected void stopService() throws Exception { > InitialContext ic = new InitialContext(); > ic.unbind(NAME); > LOG.info("stopped"); > } > @Override > public String getMessage() { > return "legacy"; > } > } > {code} > This will fail. -- 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

1
0
0 / 0

[JBoss JIRA] (AS7-6247) Officially deprecate host model attributes

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-6247: ------------------------------------- Summary: Officially deprecate host model attributes Key: AS7-6247 URL: https://issues.jboss.org/browse/AS7-6247 Project: Application Server 7 Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 7.2.0.Alpha1 There are a few attributes in the host model that have a description saying they are deprecated, but not the official deprecation metadata. Add the metadata. -- 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

1
0
0 / 0

[JBoss JIRA] (AS7-6235) Reconsider expressions for model reference attributes in server-group and server-config

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6235?page=com.atlassian.jira.plugin.s... ] Brian Stansberry reassigned AS7-6235: ------------------------------------- Assignee: Brian Stansberry > Reconsider expressions for model reference attributes in server-group and server-config > --------------------------------------------------------------------------------------- > > Key: AS7-6235 > URL: https://issues.jboss.org/browse/AS7-6235 > Project: Application Server 7 > Issue Type: Sub-task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > Fix For: 7.2.0.Alpha1 > > > There are some attributes in the server-group and server-config resources that represent references to other resources that support expressions. For example the "group" attribute in a server-config and the "profile" attribute in a server-group. Supporting expressions on such attributes is problematic because it precludes accurately validating that the reference is valid during operation execution Stage.MODEL. This is because expression resolution sources may not be fully populated until Stage.RUNTIME. > I wanted to remove expression support from these attributes but was unwilling to do so because of concerns about breaking compatibility. But some recent testing showed me that on *master* for at least some of these, setting an expression would not work -- the HC could not launch servers. If these expressions didn't work *in previous releases* as well, we can remove support for them without breaking compatibility. > The task here is to test setting these attributes to expressions in 7.1.2 and 7.1.3. For any attribute like this where expression support didn't actually work, we should remove the support in 7.2. > Testing can be done by simply taking the current xml attribute value, e.g. "foo" and using it as the default in an expression, e.g. "${exp-test:foo}" and then starting the HC. There is no need to mess with setting system property "exp-test". -- 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

1
0
0 / 0

[JBoss JIRA] (AS7-6186) Mojarra 2.1.16 upgrade breaks Seam2.3.0 conversations

by Stan Silvert (JIRA)

[ https://issues.jboss.org/browse/AS7-6186?page=com.atlassian.jira.plugin.s... ] Stan Silvert resolved AS7-6186. ------------------------------- Resolution: Done > Mojarra 2.1.16 upgrade breaks Seam2.3.0 conversations > ----------------------------------------------------- > > Key: AS7-6186 > URL: https://issues.jboss.org/browse/AS7-6186 > Project: Application Server 7 > Issue Type: Bug > Components: JSF > Affects Versions: 7.1.4.Final (EAP) > Environment: Current 7.1.4.Final-SNAPSHOT (2012-12-15), Mojarra 2.1.16, Seam2.3.0.Final > Reporter: Marek Schmidt > Assignee: Stan Silvert > Priority: Critical > Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP) > > Attachments: AS7-6186-viewMap-v3.tar, AS7-6186-viewMap-v3.war, AS7-6186-viewMap.tar, AS7-6186-viewMap.war, seam-booking.ear > > > Recent Mojarra upgrade seems to break Seam 2.3.0 conversations. > Not exactly sure yet what has changed and whether it is a Mojarra bug or Seam depending on something it shouldn't. -- 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

1
0
0 / 0

[JBoss JIRA] (AS7-6246) Naming context read-only during legacy SAR deployment

by Philippe Marschall (JIRA)

Philippe Marschall created AS7-6246: --------------------------------------- Summary: Naming context read-only during legacy SAR deployment Key: AS7-6246 URL: https://issues.jboss.org/browse/AS7-6246 Project: Application Server 7 Issue Type: Bug Components: JMX Affects Versions: 7.2.0.Alpha1 Reporter: Philippe Marschall Assignee: Stuart Douglas When the {{#startService()}} and {{#stopService()}} methods of a sublass of {{ServiceMBeanSupport}} are invoked the JNDI context is read only. Consider the following MBean: {code} public class LegacySample extends ServiceMBeanSupport implements LegacySampleMBean { private static final String NAME = "java:global/env/foo/legacy"; private static final String VALUE = "BAR"; private static final Logger LOG = Logger.getLogger("sar-legacy"); public LegacySample() { super(); } @Override protected void startService() throws Exception { InitialContext ic = new InitialContext(); ic.rebind(NAME, VALUE); LOG.info("started"); } @Override protected void stopService() throws Exception { InitialContext ic = new InitialContext(); ic.unbind(NAME); LOG.info("stopped"); } @Override public String getMessage() { return "legacy"; } } {code} This will fail. -- 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

1
0
0 / 0

[JBoss JIRA] (AS7-6186) Mojarra 2.1.16 upgrade breaks Seam2.3.0 conversations

by Stan Silvert (JIRA)

[ https://issues.jboss.org/browse/AS7-6186?page=com.atlassian.jira.plugin.s... ] Stan Silvert updated AS7-6186: ------------------------------ Fix Version/s: 7.2.0.Alpha1 7.1.4.Final (EAP) Git Pull Request: https://github.com/jbossas/jboss-as/pull/3736, https://github.com/jbossas/jboss-as/pull/3747 Upstream Mojarra issue is http://java.net/jira/browse/JAVASERVERFACES-2656 > Mojarra 2.1.16 upgrade breaks Seam2.3.0 conversations > ----------------------------------------------------- > > Key: AS7-6186 > URL: https://issues.jboss.org/browse/AS7-6186 > Project: Application Server 7 > Issue Type: Bug > Components: JSF > Affects Versions: 7.1.4.Final (EAP) > Environment: Current 7.1.4.Final-SNAPSHOT (2012-12-15), Mojarra 2.1.16, Seam2.3.0.Final > Reporter: Marek Schmidt > Assignee: Stan Silvert > Priority: Critical > Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP) > > Attachments: AS7-6186-viewMap-v3.tar, AS7-6186-viewMap-v3.war, AS7-6186-viewMap.tar, AS7-6186-viewMap.war, seam-booking.ear > > > Recent Mojarra upgrade seems to break Seam 2.3.0 conversations. > Not exactly sure yet what has changed and whether it is a Mojarra bug or Seam depending on something it shouldn't. -- 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

1
0
0 / 0

[JBoss JIRA] (AS7-5584) Naming context read-only during SAR deployment

by Philippe Marschall (JIRA)

[ https://issues.jboss.org/browse/AS7-5584?page=com.atlassian.jira.plugin.s... ] Philippe Marschall commented on AS7-5584: ----------------------------------------- The patch only works for "pojo" sars, at the time when the patch was made there was no {{ServiceMBeanSupport}} class in AS7. So {{ServiceMBeanSupport}} don't work. I'll see what I can do and file a separate JIRA. > Naming context read-only during SAR deployment > ---------------------------------------------- > > Key: AS7-5584 > URL: https://issues.jboss.org/browse/AS7-5584 > Project: Application Server 7 > Issue Type: Bug > Components: POJO > Affects Versions: 7.1.1.Final > Reporter: Philippe Marschall > Assignee: Philippe Marschall > Fix For: 7.2.0.Alpha1 > > > During the #start() #stop() method of a legacy SAR the naming context is read only. The problem seems to be that {{org.jboss.as.service.AbstractService.invokeLifecycleMethod(Method)}} only sets the thread context class loader and does not do {{WritableServiceBasedNamingStore.pushOwner}} > http://stackoverflow.com/questions/12419234/how-to-bind-an-object-to-jndi... -- 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

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 December 2012