September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (HIBERNATE-45) ehcache-1.1.jar, bsh-2.0b1.jar declared in classpath are missing

by Christian Buggle (JIRA)

ehcache-1.1.jar, bsh-2.0b1.jar declared in classpath are missing ---------------------------------------------------------------- Key: HIBERNATE-45 URL: http://jira.jboss.com/jira/browse/HIBERNATE-45 Project: Hibernate Issue Type: Bug Environment: win32 Eclipse 3.2 Reporter: Christian Buggle Assigned To: Steve Ebersole There are 2 jars missing which are declared in the classpath of Plugin 'org.hibernate.eclipse_3.2.0.beta6.jar' and 'org.hibernate.eclipse_3.2.0.beta7.jar' namely: lib/hibernate/ehcache-1.1.jar lib/tools/bsh-2.0b1.jar No actual crashes or problems noticed yet. -- 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

17 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-472) Correct lines in RHS to match up with lines in rule source

by Michael Neale (JIRA)

Correct lines in RHS to match up with lines in rule source ---------------------------------------------------------- Key: JBRULES-472 URL: http://jira.jboss.com/jira/browse/JBRULES-472 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 3.0.4 Reporter: Michael Neale Assigned To: Michael Neale Fix For: 3.1-m1 This means to calculate the correct line number, and make sure the RHS matches up with it for line number debugging. -- 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

17 years, 8 months

1
1
0 / 0

[JBoss JIRA] Closed: (JBMICROCONT-35) Allow retrieval of the collection instance from the bean

by Ales Justin (JIRA)

[ http://jira.jboss.com/jira/browse/JBMICROCONT-35?page=all ] Ales Justin closed JBMICROCONT-35. ---------------------------------- Resolution: Done Fixed Custom[Collection|List|Map|Set] so that default constructor doesn't set preinstantiated = true. Added xml files for all preinstantiated tests. Since preinstantiated lookup must pass through MetaDataVisitor.initialVisit(), instantiation method with KernelController was added. > Allow retrieval of the collection instance from the bean > -------------------------------------------------------- > > Key: JBMICROCONT-35 > URL: http://jira.jboss.com/jira/browse/JBMICROCONT-35 > Project: JBoss MicroContainer > Issue Type: Task > Components: MetaData > Reporter: Adrian Brock > Assigned To: Ales Justin > Fix For: JBossMC_2_0_0M1 > > > See org.jboss.test.kernel.config.test.CollectionTestCase#TODOtestCustomCollectionPreInstantiated > Same issues apply to Lists, Sets, Maps, Arrays, etc. > i.e. If the bean already has a collection value for the property that can be > retrieved using the getter, we should be able to use that collection instance. > Need to think about the configuration options and rules. > Current rules are: > 1) Use class specified in metadata > 2) Use class specified on setter (if not an interface) > 3) Use ArrayList -- 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

17 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-294) Introduce system property to preserve backwards compatibility of Util.object{To,From}ByteBuffer()

by Bela Ban (JIRA)

Introduce system property to preserve backwards compatibility of Util.object{To,From}ByteBuffer() ------------------------------------------------------------------------------------------------- Key: JGRP-294 URL: http://jira.jboss.com/jira/browse/JGRP-294 Project: JGroups Issue Type: Feature Request Affects Versions: 2.3 SP1 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4 Because of the HAPartitionImpl marshalling issue we found in 4.0.x last night, 2.4 is not going to work in 4.0.2 (or any 4.0 before 4.0.5.GA). A workaround for this is to check a system property in a static initializer in Util. If "compatibility mode" or whatever, fall back to the old Util.objectTo/FromByteBuffer impl. Users of old AS releases would have to set this property to use 2.4 or higher. But, it seems I have system properties on the brain these days; its starting to look like a golden hammer, so proceed with caution ;) BTW, the JIRA to ensure this isn't an issue for 4.0.5.GA is http://jira.jboss.com/jira/browse/JBAS-3593. -- 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

17 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBIDE-358) Look into WTP Facet's as a unified api for handling "lib" and "project" configuration

by Max Andersen (JIRA)

Look into WTP Facet's as a unified api for handling "lib" and "project" configuration ------------------------------------------------------------------------------------- Key: JBIDE-358 URL: http://jira.jboss.com/jira/browse/JBIDE-358 Project: JBoss IDE Issue Type: Task Affects Versions: 2.0.0.Beta1 Reporter: Max Andersen Assigned To: Marshall Culpepper Fix For: 2.0.0.Beta2 -- 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

17 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-595) Fix the spring http performance tests.

by Ron Sigal (JIRA)

Fix the spring http performance tests. -------------------------------------- Key: JBREM-595 URL: http://jira.jboss.com/jira/browse/JBREM-595 Project: JBoss Remoting Issue Type: Sub-task Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta1 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.0.Beta1 (Bluto) The changes made for the spring rmi performance test need to be applied to the spring http tests. See JBREM-592 for more information. -- 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

17 years, 8 months

1
1
0 / 0

[JBoss JIRA] Commented: (JBPORTAL-328) CMS security

by orionyiu (JIRA)

[ http://jira.jboss.com/jira/browse/JBPORTAL-328?page=comments#action_12342566 ] orionyiu commented on JBPORTAL-328: ----------------------------------- When creating/editng CMS folder, files, there should be a feature for setting the security level for that object (like that in setting security for portlet instance/page). Subsequently when user browse through the CMS directory tree they should only be able to see the folder/files they are entitiled to see. Preferably when setting security, there should be options for setting whether a role has permission to "view" and/or "edit". > CMS security > ------------ > > Key: JBPORTAL-328 > URL: http://jira.jboss.com/jira/browse/JBPORTAL-328 > Project: JBoss Portal > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Portal CMS > Affects Versions: 2.6 Final > Reporter: Julien Viet > Assigned To: Roy Russo > Fix For: 2.6 Final > > > Improve the current CMS security. > No check is done at the CMSPortlet level, this is a important missing feature. -- 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

17 years, 8 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-127) Delayed delivery, redelivery count and pluggable expiration behavior

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-127?page=all ] Ovidiu Feodorov updated JBMESSAGING-127: ---------------------------------------- Priority: Critical (was: Major) > Delayed delivery, redelivery count and pluggable expiration behavior > -------------------------------------------------------------------- > > Key: JBMESSAGING-127 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-127 > Project: JBoss Messaging > Issue Type: Feature Request > Components: Messaging Core, JMS Facade > Reporter: Ovidiu Feodorov > Priority: Critical > Fix For: 1.2.0.Beta1 > > Original Estimate: 1 week, 2 days > Remaining Estimate: 1 week, 2 days > -- 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

17 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-477) Messages are left in the Messages table after retry message is printed and are retried every time the server is restarted

by Joel Lindheimer (JIRA)

Messages are left in the Messages table after retry message is printed and are retried every time the server is restarted ------------------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-477 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-477 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 1.0.1.CR2 Environment: Windows XP Reporter: Joel Lindheimer Assigned To: Ovidiu Feodorov I am testing Consumer.receive() with a userTransaction rollback scenario; the messages rollback and are retried. Eventually the follwoing message is printed: JBossMessage[49410]:PERSISTENT has exceed maximum delivery attempts and will be removed. However, the messages are never deleted from the messages table; it is therefore retried upon every subsequent server restart. To reproduce just send a simple message with a consumer that does the following: while (true) { log.warn("whileloop+"); ut = (UserTransaction) getInitialContext().lookup("UserTransaction"); ut.begin(); conn = (QueueConnection) this.getQueueFactory().createQueueConnection(); conn.start(); session = conn.createQueueSession(false, Session.AUTO_ACKNOWLEDGE); receiver = session.createReceiver(getQueue()); // Note: starting the ut here does causes other issues... so i moved it up // ut = (UserTransaction) getInitialContext().lookup("UserTransaction"); // ut.begin(); TextMessage msg = (TextMessage) receiver.receive(5000); receiver.close(); session.close(); conn.close(); log.warn("msg: " + msg); if(msg!=null) { log.warn("msg.text: " +msg.getText()); } ut.rollback(); (...) Here is the server console print: 12:41:30,946 WARN [TestConsumer] msg: null 12:41:30,946 WARN [TestConsumer] whileloop- 12:41:30,946 WARN [TestConsumer] whileloop+ 12:41:30,946 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT 12:41:30,946 WARN [TestConsumer] msg.text: Payload #2 12:41:30,946 WARN [TestConsumer] whileloop- 12:41:30,946 WARN [TestConsumer] whileloop+ 12:41:30,946 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT 12:41:30,946 WARN [TestConsumer] msg.text: Payload #2 12:41:30,946 WARN [TestConsumer] whileloop- 12:41:30,946 WARN [TestConsumer] whileloop+ 12:41:30,962 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT 12:41:30,962 WARN [TestConsumer] msg.text: Payload #2 12:41:30,962 WARN [TestConsumer] whileloop- 12:41:30,962 WARN [TestConsumer] whileloop+ 12:41:30,962 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT 12:41:30,962 WARN [TestConsumer] msg.text: Payload #2 12:41:30,962 WARN [TestConsumer] whileloop- 12:41:30,962 WARN [TestConsumer] whileloop+ 12:41:30,962 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT 12:41:30,962 WARN [TestConsumer] msg.text: Payload #2 12:41:30,962 WARN [TestConsumer] whileloop- 12:41:30,962 WARN [TestConsumer] whileloop+ 12:41:30,962 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT 12:41:30,962 WARN [TestConsumer] msg.text: Payload #2 12:41:30,962 WARN [TestConsumer] whileloop- 12:41:30,962 WARN [TestConsumer] whileloop+ 12:41:30,977 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT 12:41:30,977 WARN [TestConsumer] msg.text: Payload #2 12:41:30,977 WARN [TestConsumer] whileloop- 12:41:30,977 WARN [TestConsumer] whileloop+ 12:41:30,977 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT 12:41:30,977 WARN [TestConsumer] msg.text: Payload #2 12:41:30,977 WARN [TestConsumer] whileloop- 12:41:30,977 WARN [TestConsumer] whileloop+ 12:41:31,009 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT 12:41:31,009 WARN [TestConsumer] msg.text: Payload #2 12:41:31,009 WARN [TestConsumer] whileloop- 12:41:31,009 WARN [TestConsumer] whileloop+ 12:41:31,009 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT 12:41:31,009 WARN [TestConsumer] msg.text: Payload #2 12:41:31,009 WARN [TestConsumer] whileloop- 12:41:31,009 WARN [TestConsumer] whileloop+ 12:41:31,024 WARN [TestConsumer] msg: delegator->JBossMessage[49410]:PERSISTENT 12:41:31,024 WARN [TestConsumer] msg.text: Payload #2 12:41:31,024 WARN [TestConsumer] whileloop- 12:41:31,024 WARN [TestConsumer] whileloop+ 12:41:31,024 WARN [ServerConsumerEndpoint] JBossMessage[49410]:PERSISTENT has exceed maximum delivery attempt s and will be removed -- 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

17 years, 8 months

4
8
0 / 0

[JBoss JIRA] Created: (JBAS-3491) Test failure - org.jboss.test.webservice.samples.ServerSideJMSTestCase

by Rajesh Rajasekaran (JIRA)

Test failure - org.jboss.test.webservice.samples.ServerSideJMSTestCase ---------------------------------------------------------------------- Key: JBAS-3491 URL: http://jira.jboss.com/jira/browse/JBAS-3491 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Test Suite Affects Versions: JBossAS-4.0.5.CR1 Reporter: Rajesh Rajasekaran Fix For: JBossAS-4.0.5.CR1 org.jboss.test.webservice.samples.ServerSideJMSTestCase test: testSOAPMessageToEndpointQueue Response received by the client is null. expected:<<env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'><env:Header/><env:Body><ns1:getContactInfoResponse xmlns:ns1='http://org.jboss.test.webservice/samples'><result>The 'mafia' boss is currently out of office, please call again.</result></ns1:getContactInfoResponse></env:Body></env:Envelope>> but was:<null> junit.framework.ComparisonFailure: expected:<<env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'><env:Header/><env:Body><ns1:getContactInfoResponse xmlns:ns1='http://org.jboss.test.webservice/samples'><result>The 'mafia' boss is currently out of office, please call again.</result></ns1:getContactInfoResponse></env:Body></env:Envelope>> but was:<null> at org.jboss.test.webservice.samples.ServerSideJMSTestCase.testSOAPMessageToEndpointQueue(ServerSideJMSTestCase.java:95) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) http://cruisecontrol.jboss.com/cc/artifacts/jboss-4.0-testsuite-sun-1.4/2... -- 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

17 years, 8 months

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2006