July 2008 - jboss-jira - Jboss List Archives

[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

16 years, 2 months

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

16 years, 2 months

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

16 years, 2 months

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

16 years, 2 months

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

16 years, 2 months

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

16 years, 2 months

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

16 years, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JBMETA-42) Default JNDI naming of EJB3 beans is broken

by Carlo de Wolf (JIRA)

Default JNDI naming of EJB3 beans is broken ------------------------------------------- Key: JBMETA-42 URL: http://jira.jboss.com/jira/browse/JBMETA-42 Project: JBoss Metadata Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.0.0.Beta15 Reporter: Carlo de Wolf Priority: Critical Fix For: 1.0.0.CR1 -- 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

5
15
0 / 0

[JBoss JIRA] Created: (JBMETA-57) JBossEnterpriseBeanMetaData.determineResolvedJndiName does not honor @JndiBindingPolicy

by Andrew Lee Rubinger (JIRA)

JBossEnterpriseBeanMetaData.determineResolvedJndiName does not honor @JndiBindingPolicy --------------------------------------------------------------------------------------- Key: JBMETA-57 URL: http://jira.jboss.com/jira/browse/JBMETA-57 Project: JBoss Metadata Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.0.0.Beta20 Reporter: Andrew Lee Rubinger Assigned To: Andrew Lee Rubinger Put this logic in place -- 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: (JBMETA-78) BasicJndiBindingPolicy does not honor deploymentScopeBaseName

by Andrew Lee Rubinger (JIRA)

BasicJndiBindingPolicy does not honor deploymentScopeBaseName ------------------------------------------------------------- Key: JBMETA-78 URL: https://jira.jboss.org/jira/browse/JBMETA-78 Project: JBoss Metadata Issue Type: Task Security Level: Public (Everyone can see) Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Given metadata with: deploymentSummary.setDeploymentScopeBaseName("base"); And: String resolved = beanMD.getHomeJndiName(); ...then: resolved == "testResolvedJndiName-ejb/home"; ...when is should be: resolved == "base/testResolvedJndiName-ejb/home"; The tests in ResolveJndiNameDecoratorUnitTestCase and ResolvedJndiNamesUnitTestCase are incorrect and will need to be updated. 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
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