January 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6322) Upgrade Jackson to 1.9.9 (due to RESTEasy)

by Juergen Zimmermann (JIRA)

Juergen Zimmermann created AS7-6322: --------------------------------------- Summary: Upgrade Jackson to 1.9.9 (due to RESTEasy) Key: AS7-6322 URL: https://issues.jboss.org/browse/AS7-6322 Project: Application Server 7 Issue Type: Bug Components: REST Affects Versions: 7.2.0.Alpha1 Reporter: Juergen Zimmermann Assignee: Stuart Douglas RESTEasy 2.3.5 is using Jackson 1.9.9, but JBossAS is using Jackson 1.9.2. BTW, the previously included RESTEasy 2.3.3 was also using Jackson 1.9.9. -- 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

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (AS7-6321) update transformers API to better support chaining and recursion

by Emanuel Muckenhuber (JIRA)

Emanuel Muckenhuber created AS7-6321: ---------------------------------------- Summary: update transformers API to better support chaining and recursion Key: AS7-6321 URL: https://issues.jboss.org/browse/AS7-6321 Project: Application Server 7 Issue Type: Task Components: Domain Management Reporter: Emanuel Muckenhuber Assignee: Emanuel Muckenhuber Priority: Critical Fix For: 7.2.0.CR1 The current transformation APIs have no support for chaining multiple transformers, which is mainly problematic for recursive resource transformations and alias operations. We need to review the core concepts and update them if necessary before 7.2 to properly support this. This may also involve updating the registration process and moving all transformers into a specific DomainExtension (or at least remove the deprecation of the current ExtensionContext.isRegisterTransformers()). -- 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

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (AS7-6320) follow IJ changes for recovery-plugin's properties

by Stefano Maestri (JIRA)

Stefano Maestri created AS7-6320: ------------------------------------ Summary: follow IJ changes for recovery-plugin's properties Key: AS7-6320 URL: https://issues.jboss.org/browse/AS7-6320 Project: Application Server 7 Issue Type: Task Components: JCA Affects Versions: 7.1.3.Final (EAP) Reporter: Stefano Maestri Assignee: Stefano Maestri Fix For: 7.2.0.Alpha1 -- 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

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (AS7-6319) EJBEndpointAuthenticationTestCase is failing intermittently

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/AS7-6319?page=com.atlassian.jira.plugin.s... ] jaikiran pai updated AS7-6319: ------------------------------ Attachment: log.txt Log from a lightning run, attached. > EJBEndpointAuthenticationTestCase is failing intermittently > ------------------------------------------------------------ > > Key: AS7-6319 > URL: https://issues.jboss.org/browse/AS7-6319 > Project: Application Server 7 > Issue Type: Bug > Components: Web Services > Environment: AS7 upstream (Jan 11 2013) > Reporter: jaikiran pai > Assignee: Alessio Soldano > Attachments: log.txt > > > The org.jboss.as.test.integration.ws.authentication.EJBEndpointAuthenticationTestCase has started failing intermittently but regularly on lightning. The failure shows messages like these: > {code} > java.lang.AssertionError: String 'not allowed' was expected in SocketException invoking http://127.0.0.1:8080/jaxws-authentication-ejb3/EJB3AuthService: Socket Closed > at org.junit.Assert.fail(Assert.java:93) > at org.junit.Assert.assertTrue(Assert.java:43) > at org.jboss.as.test.integration.ws.authentication.EJBEndpointAuthenticationTestCase.accessHelloForNoneWithValidRole3(EJBEndpointAuthenticationTestCase.java:352 > {code} > It looks like the testcase expects a specific text in the exception cause. -- 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

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (AS7-6319) EJBEndpointAuthenticationTestCase is failing intermittently

by jaikiran pai (JIRA)

jaikiran pai created AS7-6319: --------------------------------- Summary: EJBEndpointAuthenticationTestCase is failing intermittently Key: AS7-6319 URL: https://issues.jboss.org/browse/AS7-6319 Project: Application Server 7 Issue Type: Bug Components: Web Services Environment: AS7 upstream (Jan 11 2013) Reporter: jaikiran pai Assignee: Alessio Soldano The org.jboss.as.test.integration.ws.authentication.EJBEndpointAuthenticationTestCase has started failing intermittently but regularly on lightning. The failure shows messages like these: {code} java.lang.AssertionError: String 'not allowed' was expected in SocketException invoking http://127.0.0.1:8080/jaxws-authentication-ejb3/EJB3AuthService: Socket Closed at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.jboss.as.test.integration.ws.authentication.EJBEndpointAuthenticationTestCase.accessHelloForNoneWithValidRole3(EJBEndpointAuthenticationTestCase.java:352 {code} It looks like the testcase expects a specific text in the exception cause. -- 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

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1549) TCP: handle concurrent connections more gracefully

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1549?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1549: -------------------------------- I changed the code according to the above proposal, and added byteman based tests (see TCPConnectionMapTest) to enforce concurrent connections. The test suite passes, but I want to do more testing before I merge my change to master. This code will only live in 3.3, as there were quite a few changes, and I don't want to de-stabilize 3.2.x. After all, the existing code isn't incorrect, just inefficient. > TCP: handle concurrent connections more gracefully > -------------------------------------------------- > > Key: JGRP-1549 > URL: https://issues.jboss.org/browse/JGRP-1549 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3 > > Attachments: cft.log.gz > > > When A connects to B and B connects to A *concurrently*, and no existing connections are present, then one member (with the higher address) will prevail, and the other one will close its connection and drop the message. > This is not usually an issue, as higher-up layers will retransmit the message, thus re-establishing the connection. > However, if we have a protocol based on negative acks, such as UNICAST2, the retransmission might take a while if that message was the last one. > SOLUTION: > The end that closes the connection should simply resend the message *once*, thus re-creating the connection. -- 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

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (AS7-5722) Backward compatibility issue with JMS clients

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/AS7-5722?page=com.atlassian.jira.plugin.s... ] Jeff Mesnil resolved AS7-5722. ------------------------------ Resolution: Done > Backward compatibility issue with JMS clients > --------------------------------------------- > > Key: AS7-5722 > URL: https://issues.jboss.org/browse/AS7-5722 > Project: Application Server 7 > Issue Type: Bug > Components: JMS > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > Priority: Critical > Fix For: 7.2.0.Alpha1 > > > When standalone jms client is trying to connect with "old" jboss-client.jar from AS 7.1.2.Final (HornetQ 2.2.16.Final) to AS 7.2.0.Alpha1 (HornetQ 2.3.0.Beta1) then ClassNotFoundException it thrown: > Console log of jms client: > {code} > [jbossqa@station4 as7-with-hq-replicated]$ java -cp /home/jbossqa/hornetq_eap6_testsuite/as7-with-hq-replicated/client-1.0-SNAPSHOT.jar:/home/jbossqa/hornetq_eap6_testsuite/server1/jboss-eap-6.0/bin/client/jboss-client.jar org.jboss.jms.client.TestProducer 192.168.40.1 jms/queue/testQueue0 10 > remote://192.168.40.1:4447 > Oct 10, 2012 11:44:41 AM org.xnio.Xnio <clinit> > INFO: XNIO Version 3.0.6.GA-redhat-1 > Oct 10, 2012 11:44:41 AM org.xnio.nio.NioXnio <clinit> > INFO: XNIO NIO Implementation Version 3.0.6.GA-redhat-1 > Oct 10, 2012 11:44:41 AM org.jboss.remoting3.EndpointImpl <clinit> > INFO: JBoss Remoting version 3.2.8.SP1-redhat-1 > Oct 10, 2012 11:44:42 AM org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver handleEnd > ERROR: Channel end notification received, closing channel Channel ID f6fa08e1 (outbound) of Remoting connection 2a0ab444 to /192.168.40.1:4447 > org.jboss.naming.remote.protocol.NamingIOException: Failed to lookup [Root exception is java.io.IOException: java.lang.ClassNotFoundException: org.hornetq.api.core.BroadcastEndpointFactoryConfiguration] > at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:49) > at org.jboss.naming.remote.protocol.v1.Protocol$1.execute(Protocol.java:104) > at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1.lookup(RemoteNamingStoreV1.java:78) > at org.jboss.naming.remote.client.HaRemoteNamingStore$1.operation(HaRemoteNamingStore.java:227) > at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:119) > at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:223) > at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79) > at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83) > at javax.naming.InitialContext.lookup(InitialContext.java:409) > at org.jboss.jms.client.TestProducer.startClient(TestProducer.java:47) > at org.jboss.jms.client.TestProducer.main(TestProducer.java:28) > Caused by: java.io.IOException: java.lang.ClassNotFoundException: org.hornetq.api.core.BroadcastEndpointFactoryConfiguration > at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:159) > at org.jboss.naming.remote.protocol.v1.BaseProtocolCommand.readResult(BaseProtocolCommand.java:60) > at org.jboss.naming.remote.protocol.v1.Protocol$1.handleClientMessage(Protocol.java:149) > at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver$1.run(RemoteNamingStoreV1.java:210) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) > Caused by: java.lang.ClassNotFoundException: org.hornetq.api.core.BroadcastEndpointFactoryConfiguration > at java.net.URLClassLoader$1.run(URLClassLoader.java:217) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:205) > at java.lang.ClassLoader.loadClass(ClassLoader.java:321) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) > at java.lang.ClassLoader.loadClass(ClassLoader.java:266) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:264) > at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135) > at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:871) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:903) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:903) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1205) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) > at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1678) > at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1594) > at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1558) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1236) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) > at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37) > at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:156) > ... 6 more > Oct 10, 2012 11:44:42 AM org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver handleEnd > ERROR: Channel end notification received, closing channel Channel ID dac0f594 (outbound) of Remoting connection 16e1eea8 to /192.168.40.1:4447 > {code} > How to reproduce: > 1) Download reproducer.zip from QA Lab and unzip reproducer.zip: {code}scp -r messaging-18.jbm.lab.bos.redhat.com:/home/mnovak/reproducer-backward-compatibility .{code} > 2) Start AS7 server:{code}cd jboss-as-7.2.0.Alpha1-SNAPSHOT/bin;sh standalone.sh -c standalone-full-ha.xml -b localhost{code} > 3) Start jms producer:{code}java -cp $PWD/client-1.0-SNAPSHOT.jar:$PWD/jboss-old-hq226-client.jar org.jboss.jms.client.TestProducer localhost jms/queue/testQueue0 10{code} -- 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

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-961) AverageBlockingTime should be based on invocations

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-961?page=com.atlassian.jira.plugin.... ] Jesper Pedersen resolved JBJCA-961. ----------------------------------- Resolution: Done > AverageBlockingTime should be based on invocations > -------------------------------------------------- > > Key: JBJCA-961 > URL: https://issues.jboss.org/browse/JBJCA-961 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.14.Final, 1.1.0.Beta3 > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.15.Final, 1.1.0.Beta4 > > -- 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

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-961) AverageBlockingTime should be based on invocations

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-961?page=com.atlassian.jira.plugin.... ] Jesper Pedersen updated JBJCA-961: ---------------------------------- Summary: AverageBlockingTime should be based on invocations (was: AvergaeBlockingTime should be based on invocations) > AverageBlockingTime should be based on invocations > -------------------------------------------------- > > Key: JBJCA-961 > URL: https://issues.jboss.org/browse/JBJCA-961 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.14.Final, 1.1.0.Beta3 > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.15.Final, 1.1.0.Beta4 > > -- 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

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-961) AvergaeBlockingTime should be based on invocations

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-961: ------------------------------------- Summary: AvergaeBlockingTime should be based on invocations Key: JBJCA-961 URL: https://issues.jboss.org/browse/JBJCA-961 Project: IronJacamar Issue Type: Bug Components: Core Affects Versions: 1.1.0.Beta3, 1.0.14.Final Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.15.Final, 1.1.0.Beta4 -- 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

13 years, 6 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 January 2013