September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBMESSAGING-277) Setting remoting lease period to -1 breaks ASF

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-277?page=all ] Ovidiu Feodorov updated JBMESSAGING-277: ---------------------------------------- Assignee: Ron Sigal Fix Version/s: 1.0.1.CR5 (was: 1.2.0.Alpha1) > Setting remoting lease period to -1 breaks ASF > ---------------------------------------------- > > Key: JBMESSAGING-277 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-277 > Project: JBoss Messaging > Issue Type: Bug > Components: JMS Remoting > Reporter: Ovidiu Feodorov > Assigned To: Ron Sigal > Fix For: 1.0.1.CR5 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > LeasePeriod == -1 is supposed to disable remoting leasing. > However, setting LeasePeriod to -1 breaks ASF. TCK tests don't pass anymore. > Whoever fixes this problem, should add a functional test so the Messaging testsuite catches this problem before TCK does. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-361) WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-361?page=all ] Ovidiu Feodorov updated JBMESSAGING-361: ---------------------------------------- Fix Version/s: (was: 1.2.0.Alpha1) 1.0.1.CR5 > WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid > ----------------------------------------------------------------------------- > > Key: JBMESSAGING-361 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-361 > Project: JBoss Messaging > Issue Type: Sub-task > Components: JMS Facade > Affects Versions: 1.0.0 > Reporter: Ovidiu Feodorov > Assigned To: Ovidiu Feodorov > Fix For: 1.0.1.CR5 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > Switching to jboss-serialization 1.0.0.CR7 uncovered what apparently seems to be an invalid test section in WireFormatTest > public void testNullResponse() throws Exception > { > MessagingMarshallable mm = new MessagingMarshallable((byte)77, null); > InvocationResponse resp = new InvocationResponse(null, mm, false, null); > ByteArrayOutputStream bos = new ByteArrayOutputStream(); > JBossObjectOutputStream oos = new JBossObjectOutputStream(bos); > > wf.write(resp, oos); > oos.flush(); > > ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray()); > DataInputStream dis = new DataInputStream(bis); > > // First byte should be version > assertEquals(77, dis.readByte()); > ........... > } > It doesn't make sense to me to write stuff to a JBossObjectOutputStream and then try to read the serialized content using a DataInputStream, and yet this is what this test section does. JBoss Serialization doesn't guarantee this in its public contract. > Excerpt form a conversation with Clebert: > flanker707: Does JBossSerialization guarantee that something written with on a JBossObjectOutuptStream can be read with DataInputStream? > Clebert Suconic: no... I didn't mean to > flanker707: is this in the public contract? > Clebert Suconic: If you use the same thing with ObjectInputStream.. you would have the same problem > testNullResponse(), testDeactivateResponse() sections commented out until clarified. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBMESSAGING-361) WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-361?page=all ] Ovidiu Feodorov reopened JBMESSAGING-361: ----------------------------------------- Assignee: Ovidiu Feodorov (was: Tim Fox) I need to give it a litte bit more thought. I will close it myself. > WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid > ----------------------------------------------------------------------------- > > Key: JBMESSAGING-361 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-361 > Project: JBoss Messaging > Issue Type: Sub-task > Components: JMS Facade > Affects Versions: 1.0.0 > Reporter: Ovidiu Feodorov > Assigned To: Ovidiu Feodorov > Fix For: 1.0.1.CR5 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > Switching to jboss-serialization 1.0.0.CR7 uncovered what apparently seems to be an invalid test section in WireFormatTest > public void testNullResponse() throws Exception > { > MessagingMarshallable mm = new MessagingMarshallable((byte)77, null); > InvocationResponse resp = new InvocationResponse(null, mm, false, null); > ByteArrayOutputStream bos = new ByteArrayOutputStream(); > JBossObjectOutputStream oos = new JBossObjectOutputStream(bos); > > wf.write(resp, oos); > oos.flush(); > > ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray()); > DataInputStream dis = new DataInputStream(bis); > > // First byte should be version > assertEquals(77, dis.readByte()); > ........... > } > It doesn't make sense to me to write stuff to a JBossObjectOutputStream and then try to read the serialized content using a DataInputStream, and yet this is what this test section does. JBoss Serialization doesn't guarantee this in its public contract. > Excerpt form a conversation with Clebert: > flanker707: Does JBossSerialization guarantee that something written with on a JBossObjectOutuptStream can be read with DataInputStream? > Clebert Suconic: no... I didn't mean to > flanker707: is this in the public contract? > Clebert Suconic: If you use the same thing with ObjectInputStream.. you would have the same problem > testNullResponse(), testDeactivateResponse() sections commented out until clarified. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-431) Socket transports should use configurable port

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-431?page=all ] Ovidiu Feodorov updated JBMESSAGING-431: ---------------------------------------- Fix Version/s: 1.0.1.CR5 (was: 1.2.0.Beta1) > Socket transports should use configurable port > ---------------------------------------------- > > Key: JBMESSAGING-431 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-431 > Project: JBoss Messaging > Issue Type: Task > Affects Versions: 1.0.1.CR4 > Reporter: Tim Fox > Assigned To: Ron Sigal > Fix For: 1.0.1.CR5 > > > Currently, for the socket and ssl transports, callbackservers will be opened on the next available port obtained. > Very occasionally this can fail since some other service uses the port before the callback server can. > Instead, the user should be able to configure a port used by the callbackserver to listen. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-207) HTTP invoker configuration and testing

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-207?page=all ] Ovidiu Feodorov updated JBMESSAGING-207: ---------------------------------------- Fix Version/s: 1.0.1.CR5 (was: 1.2.0.Beta1) > HTTP invoker configuration and testing > -------------------------------------- > > Key: JBMESSAGING-207 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-207 > Project: JBoss Messaging > Issue Type: Task > Components: Configuration and Management > Reporter: Ovidiu Feodorov > Assigned To: Ron Sigal > Priority: Critical > Fix For: 1.0.1.CR5 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Provide a HTTP invoker initial configuration and a working example. > Add the example to docs/examples so it can be used as an integration test. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBSEAM-349) IssueTracker @LoggedIn missing @Interceptors annotation

by Stephan Bublava (JIRA)

IssueTracker @LoggedIn missing @Interceptors annotation ------------------------------------------------------- Key: JBSEAM-349 URL: http://jira.jboss.com/jira/browse/JBSEAM-349 Project: JBoss Seam Issue Type: Bug Components: Examples Reporter: Stephan Bublava Priority: Trivial I believe org.jboss.seam.example.issues.LoggedIn misses a @Interceptors(LoggedInInterceptor.class) annotation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-317) Backport of JGRP 302 to JGroups 2.2.9 SP4

by Bela Ban (JIRA)

Backport of JGRP 302 to JGroups 2.2.9 SP4 ----------------------------------------- Key: JGRP-317 URL: http://jira.jboss.com/jira/browse/JGRP-317 Project: JGroups Issue Type: Task Affects Versions: 2.2.9 SP3 (2.2.9.3) Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.2.9 SP4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-318) Backport of JGRP-304 to JGroups 2.2.9 SP4

by Bela Ban (JIRA)

Backport of JGRP-304 to JGroups 2.2.9 SP4 ----------------------------------------- Key: JGRP-318 URL: http://jira.jboss.com/jira/browse/JGRP-318 Project: JGroups Issue Type: Task Affects Versions: 2.2.9 SP3 (2.2.9.3) Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.2.9 SP4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-316) Backport of JGRP-217

by Bela Ban (JIRA)

Backport of JGRP-217 -------------------- Key: JGRP-316 URL: http://jira.jboss.com/jira/browse/JGRP-316 Project: JGroups Issue Type: Task Affects Versions: 2.2.9 SP3 (2.2.9.3) Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.2.9 SP4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
1
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-264) Provide a mechanism to forward messages from one destination to another automatically

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-264?page=all ] Tim Fox updated JBMESSAGING-264: -------------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.2.0.Alpha1) > Provide a mechanism to forward messages from one destination to another automatically > ------------------------------------------------------------------------------------- > > Key: JBMESSAGING-264 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-264 > Project: JBoss Messaging > Issue Type: Feature Request > Reporter: Chris DeLashmutt > Assigned To: Ovidiu Feodorov > Fix For: 1.2.0.Beta1 > > > I have had requests for this feature many times. Basically, people seem to want to be able to have a component in messaging that will automatically forward messages to another destination. This destination could be in the same messaging server or some remote destination. I'm thinking that the process must either be a daemon or an MDB, and since JBossMsg will also be available standalone I'm thinking we make it an MBean. Another KEY to making this work is the 2PC stuff from Arjuna which isn't there yet (to make the pop and the push transactional). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 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 September 2006