July 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMETA-77) DefaultJndiBindingPolicy must be Seralizable

by Andrew Lee Rubinger (JIRA)

DefaultJndiBindingPolicy must be Seralizable --------------------------------------------- Key: JBMETA-77 URL: https://jira.jboss.org/jira/browse/JBMETA-77 Project: JBoss Metadata Issue Type: Task Security Level: Public (Everyone can see) Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Because Decorators may associate a DefaultJndiBindingPolicy with JBoss*BeanMetadata objects, and these objects must be Serializable, the DefaultJndiBindingPolicy implementations themselves must also be Serializable. Else errors, as exhibited by Seam AS TestSuite org.jboss.test.deployers.seam.test.SeamNumberguessExampleUnitTestCase.testExample java.io.NotSerializableException: org.jboss.metadata.ejb.jboss.jndipolicy.plugins.BasicJndiBindingPolicy ... at org.jboss.deployers.plugins.attachments.AttachmentsImpl.writeExternal(AttachmentsImpl.java:145) Targeted for Beta30. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

2
4
0 / 0

[JBoss JIRA] Created: (GPD-220) Make GPD Ganymede ready

by Koen Aers (JIRA)

Make GPD Ganymede ready ----------------------- Key: GPD-220 URL: https://jira.jboss.org/jira/browse/GPD-220 Project: JBoss jBPM GPD Issue Type: Task Components: jpdl Affects Versions: jBPM jPDL Designer 3.1.3 Reporter: Koen Aers Assignee: Koen Aers Fix For: jBPM jPDL Designer 3.1.4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-5788) Replace Oswego usage with java.util.concurrent

by Jesper Pedersen (JIRA)

Replace Oswego usage with java.util.concurrent ---------------------------------------------- Key: JBAS-5788 URL: https://jira.jboss.org/jira/browse/JBAS-5788 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: JCA service Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: JBossAS-5.0.0.CR2 Replace Oswego usage with java.util.concurrent in order to remove the dependency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (HIBERNATE-102) DirectoryProviderFactory configuration problem

by Rafal Glowacz (JIRA)

DirectoryProviderFactory configuration problem ---------------------------------------------- Key: HIBERNATE-102 URL: https://jira.jboss.org/jira/browse/HIBERNATE-102 Project: Hibernate Issue Type: Bug Reporter: Rafal Glowacz Assignee: Steve Ebersole Priority: Critical Because IdHashShardingStrategy fails after 1.7m ID is reached I decided to use my own version of strategy. I set up property common.hibernate.search.blogentry.sharding_strategy = com. ... .IdShardingStrategy and didn't work for me. As I checked problem exist in DirectoryProviderFactory and the way how properties are created ( new Properties( defaultProperties ) ). This constructor and the way how default properties are stored in this Object this both together doesn't work well. Problem exist: //define sharding strategy IndexShardingStrategy shardingStrategy; Properties shardingProperties = new Properties(); for (Map.Entry entry : indexProps[0].entrySet()) { if ( ( (String) entry.getKey() ).startsWith( SHARDING_STRATEGY ) ) { shardingProperties.put( entry.getKey(), entry.getValue() ); } } String shardingStrategyName = shardingProperties.getProperty( SHARDING_STRATEGY ); if ( shardingStrategyName == null) { if ( indexProps.length == 1 ) { shardingStrategy = new NotShardedStrategy(); } else { shardingStrategy = new IdHashShardingStrategy(); } } else { in this loop "for (Map.Entry entry : indexProps[0].entrySet()) {" this set is just empty so custom properties for sharding have been ignored. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (HIBERNATE-101) IdHashShardingStrategy fails after 1.7M id is generated

by Rafal Glowacz (JIRA)

IdHashShardingStrategy fails after 1.7M id is generated ------------------------------------------------------- Key: HIBERNATE-101 URL: https://jira.jboss.org/jira/browse/HIBERNATE-101 Project: Hibernate Issue Type: Bug Reporter: Rafal Glowacz Assignee: Steve Ebersole public class IdShardingStrategyTest extends TestCase { private IdHashShardingStrategy _defaultIdStrategy; private IdShardingStrategy _idStrategy; protected void setUp() throws Exception { _idStrategy = new IdShardingStrategy(); _idStrategy.initialize(null, createDirectoryProviders()); _defaultIdStrategy = new IdHashShardingStrategy(); _defaultIdStrategy.initialize(null, createDirectoryProviders()); } private DirectoryProvider[] createDirectoryProviders() { return new DirectoryProvider[]{new MockDirectoryProvider(), new MockDirectoryProvider(), new MockDirectoryProvider()}; } public void testIdSharding() { long id = 1; long limit = 1000 * 1000000 * 1000000L; try { while (id < limit) { generateForAddition(_idStrategy, id); generateForDeletion(_idStrategy, id); id += 129653153; } } catch (Exception e) { fail("Couldn't get directory for id " + id); } } public void testIdHashSharding() { long id = 1; long limit = 1000 * 1000000 * 1000000L; try { while (id < limit) { generateForAddition(_defaultIdStrategy, id); generateForDeletion(_defaultIdStrategy, id); id += 129653153; } fail("Should fail with ArrayIndexOutOfBoundsException for long id"); } catch (Exception e) { } } private MockDirectoryProvider generateForAddition(IndexShardingStrategy strategy, long id) { return (MockDirectoryProvider) strategy.getDirectoryProviderForAddition(null, id, id + "", null); } private DirectoryProvider[] generateForDeletion(IndexShardingStrategy strategy, long id) { return strategy.getDirectoryProvidersForDeletion(null, id, id + ""); } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-1688) BRMS: Commit comments are not displayed

by Jaroslaw Kijanowski (JIRA)

BRMS: Commit comments are not displayed --------------------------------------- Key: JBRULES-1688 URL: https://jira.jboss.org/jira/browse/JBRULES-1688 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-brms Affects Versions: 5.0.0.M1 Reporter: Jaroslaw Kijanowski Assignee: Michael Neale Fix For: 5.0.0.M2 When I create a rule and save it I'm asked for a commit comment. It then shows up on the right side as a "Note". When I save it again, the version gets incremented, however the new comment does not show up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (JGRP-797) Document all protocol properties

by Vladimir Blagojevic (JIRA)

Document all protocol properties --------------------------------- Key: JGRP-797 URL: http://jira.jboss.com/jira/browse/JGRP-797 Project: JGroups Issue Type: Task Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Currently we maintain description of protocol properties in code and documentation separately. We should leverage new Property annotation and describe all properties directly in our code by using description attribute of Property annotation. After we complete describing all properties we should make a Java utility program that traverses all JGroups protocols, extracts properties for all protocols along with the specified description, and finally converts it to a suitable output format. -- 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

16 years, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JGRP-757) Merge Event.INFO and Event.CONFIG into one event

by Bela Ban (JIRA)

Merge Event.INFO and Event.CONFIG into one event ------------------------------------------------ Key: JGRP-757 URL: http://jira.jboss.com/jira/browse/JGRP-757 Project: JGroups Issue Type: Task Reporter: Bela Ban Assigned To: Bela Ban Priority: Optional Fix For: 2.7 We don't need both events, remove one of them -- 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

16 years, 2 months

2
6
0 / 0

[JBoss JIRA] Created: (JBREM-961) Context closing handshake is broken

by David Lloyd (JIRA)

Context closing handshake is broken ----------------------------------- Key: JBREM-961 URL: http://jira.jboss.com/jira/browse/JBREM-961 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 Guess I just half-finished it. It needs to be rethought/fixed. See ContextClient.handlerClosing(boolean). -- 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

16 years, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBWEB-96) ATTRIBUTE level replication granularity not replicating session metadata

by Mike Van Noord (JIRA)

ATTRIBUTE level replication granularity not replicating session metadata ------------------------------------------------------------------------ Key: JBWEB-96 URL: http://jira.jboss.com/jira/browse/JBWEB-96 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Components: Tomcat Module Environment: JBoss AS 4.2.1, replication-trigger: SET, replication-granularity: ATTRIBUTE Reporter: Mike Van Noord Assigned To: Mladen Turk When setting attributes in a session and using ATTRIBUTE-level replication granularity and the SET replication trigger, I expect certain session meta-data to be replicated along with the attribute being set (namely last access time). This isn't happening. Since ClusteredSession only flags the metadata as dirty on access when the ACCESS replication trigger is used, the sessionMetadataDirty flag will only be set at the beginning and end of a session's lifecycle thereby preventing any metadata replication between those times. It seems appropriate to flag the metadata as dirty when using ATTRIBUTE-level replication whenever the replication trigger specifies, in this case when an attribute is set. -- 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

16 years, 2 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2008