July 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-800) FRAG/FRAG2: fragments from X are not cleared if X crashes

by Bela Ban (JIRA)

FRAG/FRAG2: fragments from X are not cleared if X crashes --------------------------------------------------------- Key: JGRP-800 URL: https://jira.jboss.org/jira/browse/JGRP-800 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Priority: Critical Fix For: 2.6.4, 2.7 The reason is that we handle VIEW events only in down(), but since FRAG2 usually sits somewhere above GMS, we will never get these events ! SOLUTION: - Handle VIEW in up() as well - Make sure all fragments from a crashed or left member X are discarded - Add a JMX operation to manually clear the fragmentation table for X, or for all members Note that this applies to FRAG as well, but we'll shortly deprecate FRAG anyway -- 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

18 years

1
1
0 / 0

[JBoss JIRA] Created: (JBWEB-110) Setting debug level causes character encoding to fail for jsp's.

by David Stephan (JIRA)

Setting debug level causes character encoding to fail for jsp's. ---------------------------------------------------------------- Key: JBWEB-110 URL: http://jira.jboss.com/jira/browse/JBWEB-110 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Components: Tomcat Module Affects Versions: JBoss Web Server 1.0.1 GA Environment: Application Servers Reporter: David Stephan Assigned To: Mladen Turk Priority: Minor Attachments: log.jsp When debug logging level is enabled for the class org.apache.jasper.servlet.JspServlet, any specific character coding is ignored. In the service() method with debug on, the parameters are retrieved from the request object. This parses the parameters before any character encoding has been set, but it sets the parameters parsed flag to true. Therefore the encoding will never get set. The attached jsp can demonstrate. After setting <category name="org.apache.jasper.servlet.JspServlet"> <priority value="DEBUG"/> </category> in log4j config, enter a Greek character say and the returned text will not be utf-8. -- 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

18 years

2
2
0 / 0

[JBoss JIRA] Created: (JGRP-801) FRAG2: simplification

by Bela Ban (JIRA)

FRAG2: simplification --------------------- Key: JGRP-801 URL: https://jira.jboss.org/jira/browse/JGRP-801 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 2.7 We can remove FragmentationList and FragmentationTable, and simply use concurrent hashmaps -- 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

18 years

1
1
0 / 0

[JBoss JIRA] Created: (HIBERNATE-103) Search default properties are ignored when at least one shard property exist

by Rafal Glowacz (JIRA)

Search default properties are ignored when at least one shard property exist ---------------------------------------------------------------------------- Key: HIBERNATE-103 URL: https://jira.jboss.org/jira/browse/HIBERNATE-103 Project: Hibernate Issue Type: Bug Reporter: Rafal Glowacz Assignee: Steve Ebersole I'm trying to use shared strategy for search. So my basic setup was: common.hibernate.search.default.indexBase = /lucene/index common.hibernate.search.default.optimizer.operation_limit.max = 1000 common.hibernate.search.default.optimizer.transaction_limit.max = 1000 common.hibernate.search.default.directory_provider = org.hibernate.search.store.FSDirectoryProvider common.hibernate.search.default.sharding_strategy = com.newbay.search.sharding.strategy.IdShardingStrategy common.hibernate.search.blogentry.sharding_strategy.nbr_of_shards = 5 But this won't work for me because when sharding configuration properties exist then those default ones are completely ignored - I can't understand that. To change this I changed ".default." to ".blogentry." and then I found the bug that the number of properties decides how many shards I want for current index. (nbrOfShards = nbrOfShards >= indexSpecificDefaultProps.size() ? nbrOfShards : indexSpecificDefaultProps.size();) So in this case I can't do anything. I'm looking for such config: common.hibernate.search.default.indexBase = /lucene/index common.hibernate.search.default.optimizer.operation_limit.max = 1000 common.hibernate.search.default.optimizer.transaction_limit.max = 1000 common.hibernate.search.default.directory_provider = org.hibernate.search.store.FSDirectoryProvider common.hibernate.search.default.sharding_strategy = com.newbay.search.sharding.strategy.IdShardingStrategy common.hibernate.search.website.sharding_strategy.nbr_of_shards = 2 common.hibernate.search.website.indexBase = /lucene/website common.hibernate.search.blogentry.sharding_strategy.nbr_of_shards = 5 common.hibernate.search.blogentry.indexBase = /lucene/blogentry But it doesn't work for now. -- 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

18 years

1
0
0 / 0

[JBoss JIRA] Resolved: (JBWEB-16) scratchdir fails for multi-user installs

by Remy Maucherat (JIRA)

[ https://jira.jboss.org/jira/browse/JBWEB-16?page=com.atlassian.jira.plugi... ] Remy Maucherat resolved JBWEB-16. --------------------------------- Fix Version/s: JBossWeb-2.1.1.GA Resolution: Done I have added a new (optional) catalina.work system property which can be used to base work folders on. If not set it defaults to catalina.base, then catalina.home. > scratchdir fails for multi-user installs > ---------------------------------------- > > Key: JBWEB-16 > URL: https://jira.jboss.org/jira/browse/JBWEB-16 > Project: JBoss Web > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Tomcat Module > Affects Versions: JBossWeb embedded - AS 4.0.1 > Reporter: Norman Richards > Assignee: Remy Maucherat > Fix For: JBossWeb-2.1.1.GA > > > The setup was the basic multi-user scenario described in the dev environment admin training slides (module 8). Each user has his own data/tmp/deploy directory, but the conf directory is shared between all users and not writable. > This produces a a FATAL log message: > 11:37:06,717 FATAL [EmbeddedServletOptions] The scratchDir you specified: > /private/tmp/jboss-4.0.2/server/test/work/jboss.web/localhost/jmx-console is unusable. > This also causes exceptions when the server shuts down. > The jboss.web directory should probably go under the data or tmp directory so that it can exist on a per-user basis. Another option is to allow variable substitution in the server.xml file so that the scratchdir can be set based on the $[user.name} property. > See the admin module 8, slides 5-16 for the complete configuration if my description isn't clear. -- 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

18 years

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-2062) BeanContext.createErrorMessage doesn't deal with error status properly

by Chris Laprun (JIRA)

BeanContext.createErrorMessage doesn't deal with error status properly ---------------------------------------------------------------------- Key: JBPORTAL-2062 URL: http://jira.jboss.com/jira/browse/JBPORTAL-2062 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal WSRP Affects Versions: 2.6.6 Final, 2.7 Final Reporter: Chris Laprun Assigned To: Chris Laprun Fix For: 2.6.6 Final, 2.7 Final More precisely, createErrorMessage requires an internalization key while returned status is, well, a status message... :) -- 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

18 years

2
2
0 / 0

[JBoss JIRA] Created: (JBPORTAL-2061) Add documentation on WSRP relaxed validation mode.

by Chris Laprun (JIRA)

Add documentation on WSRP relaxed validation mode. -------------------------------------------------- Key: JBPORTAL-2061 URL: http://jira.jboss.com/jira/browse/JBPORTAL-2061 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal Reference Guide Affects Versions: 2.6.6 Final, 2.7 Final Reporter: Chris Laprun Assigned To: Chris Laprun Fix For: 2.6.6 Final, 2.7 Final -- 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

18 years

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-5787) Two nodes running on different machines are not coming into cluster setup as they are not recognizing each other

by Sai Prem K (JIRA)

Two nodes running on different machines are not coming into cluster setup as they are not recognizing each other ---------------------------------------------------------------------------------------------------------------- Key: JBAS-5787 URL: https://jira.jboss.org/jira/browse/JBAS-5787 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-4.2.2.GA Environment: WINDOWS 2003 Server Reporter: Sai Prem K Assignee: Brian Stansberry Installed two JBOSS server nodes running on two different machines. Both machines are Multicast enabled windows Server 2003 machines. When iam starting both nodes some time they are recognizing each other (means coming into cluster setup) and sometimes they are not. Can anybody help me in resolving this issue? -- 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

18 years

2
1
0 / 0

[JBoss JIRA] Created: (JBMETA-72) Making Creators declare supported annotation types

by Ales Justin (JIRA)

Making Creators declare supported annotation types -------------------------------------------------- Key: JBMETA-72 URL: http://jira.jboss.com/jira/browse/JBMETA-72 Project: JBoss Metadata Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 1.0.0.Beta27 Reporter: Ales Justin Assigned To: Emanuel Muckenhuber Fix For: 1.0.0.Beta28 Creators should provide additional information in AnnotationMetaDataDeployer, returning the annotation types they are able to handle. This would help with the performance when using AltAnnotationMetaDataDeployer (GenericAnnotationDeployer), since we would only pass-in the classes that contain at least one of creator's supported annotation. The rest of the Creator's logic would remain the same, it's just the amount of classes that they scan that's gonna be a lot smaller. -- 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

18 years

2
1
0 / 0

[JBoss JIRA] Created: (JBMETA-75) Interface-specific JNDI Name clashes with default JNDI name when mappedName is specified

by Andrew Lee Rubinger (JIRA)

Interface-specific JNDI Name clashes with default JNDI name when mappedName is specified ---------------------------------------------------------------------------------------- Key: JBMETA-75 URL: http://jira.jboss.com/jira/browse/JBMETA-75 Project: JBoss Metadata Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.0.0.Beta28 Reporter: Andrew Lee Rubinger Assigned To: Andrew Lee Rubinger Given the following specified mapped-name: "org.jboss.metadata.test.collision.MappedNameCollisionUnitTestCase-mapped-name" JbossSessionBeanJndiNameResolver.resolveRemoteBusinessDefaultJndiName(smd) will return the same when using a BasicJndiBindingPolicy. However, when requesting a target JNDI name for a business remote interface "org.jboss.Interface", the value received from: JbossSessionBeanJndiNameResolver.resolveJndiName(smd, interfaceName) is : org.jboss.metadata.test.collision.MappedNameCollisionUnitTestCase-mapped-name/remote-org.jboss.Interface Because the base name here is not a SubContext, there will be a binding error in JNDI. This causes smoke test org.jboss.test.ejb3.test.SimpleSessionUnitTestCase and TCK tests to fail. -- 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

18 years

1
3
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 July 2008