Re: [hibernate-dev] lookup of Infinispan cachemanager for Search's own dirty reasons
On Nov 17, 2010, at 4:31 PM, Sanne Grinovero wrote: > Hello, > thanks all for the clarifications; I was wrongly assuming that we > should have just one CacheManager running in AS6. > Now I see, I'll use my own independent one. > > I'm making sure Hibernate Search is able to start (and stop) it's own > CacheManager, or instead retrieve one via JNDI. Just make sure you don't stop it if bound to JNDI! :) > So now I don't see anymore a strong reason to define a default name, > nor bundle a configuration into JBoss6 - agree? It's not so easy to make that decision. You should check with the AS6 guys to see what they'd need. Best persons to contact are Paul Ferraro and Scott Marlow. But to give you an idea, this is what happens with 2LC, which you might wanna follow: The Infinispan 2LC does ship a configuration for standalone usage. But when running within AS, it's often the case that AS might wanna centrally manage some things, such as the JGroups transport level. So, what AS take the the 2LC config and put it within a file called infinispan-configs.xml that allows it to centrally manage it. See http://anonsvn.jboss.org/repos/jbossas/trunk/cluster/src/resources/infinispan/infinispan-configs.xml > > So it will first try to find a CacheManager via JNDI using the name > defined with the following configuration property: > > "hibernate.search.infinispan.cachemanager_jndiname" > (underscore is a convention used in many other Search's properties) > > If this property is undefined, it will look for this one: > > hibernate.search.infinispan.configuration_resourcename > > which should point to an Infinispan configuration file. > > If this is not defined either, we fall back to the resourcename > "default-hibernatesearch-infinispan.xml" > which will be included in Hibernate Search, providing general purpose > defaults but no cachestore. > > Cheers, > Sanne > > 2010/11/17 Galder Zamarreño : >> >> On Nov 16, 2010, at 6:25 PM, Sanne Grinovero wrote: >> >>> Hi, >>> I see that the Infinispan second level cache defines a nice property >>> "hibernate.cache.infinispan.cachemanager" to search an existing >>> CacheManager via JNDI. >>> >>> Now in case of Hibernate Search's DirectoryProvider making use of >>> Infinispan, I suppose that people will want to lookup the same >>> CacheManager, >>> which then would be used for both purposes, even if very likely the >>> configuration will contain different caches for each use case. >> >> Hmmm, not so sure about that actually. >> >> Your cache manager and the 2LC one have different purposes and can you >> guarantee that your app won't end up using a 2LC cache by mistake? You'd >> need to have some kind of knowledge of the cache naming there. >> >> So, -1 to this. >> >>> >>> So from Hibernate Search's new module, shall I look for the same >>> property? The "cache" part in the name is unfortunate, still I would >>> like to define it just once. >>> >>> Ideas> >>> >>> 1 - add a new property "hibernate.infinispan.jndiname", and have the >>> 2LC look for this as fallback, I'll look for the same >> >> No, you need your own property. Why not start naming it with >> hibernate.search.X and that way you avoid collisions with other hibernate >> properties? >> >>> >>> 2 - I suppose JBoss6 will bind it to JNDI by default, could we use >>> this name as default in Hibernate to bring configuration need to the >>> minimum? >> >> JBoss6 uses different cache managers, not just one: i.e. WebSessions, 2LC, >> EJb3SFSB, so I doubt there's a single JNDI name there. >> >>> In that case I'd love to add some cache configurations for the dirty >>> purposes of Hibernate Search in the AS distribution, so that stuff >>> works with minimal configuration hazards. >>> >>> Cheers, >>> Sanne >>> ___ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> -- >> Galder Zamarreño >> Sr. Software Engineer >> Infinispan, JBoss Cache >> >> -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Search test module
I was not aware that the current setup does not work in Eclipse :( On the other hand, we haven't had an additional module yet within the project depending on the testing module. The duplication of classes is there because of the cycle you mentioned. It is really a chicken and hen problem. The only solution to completely remove the duplicates would be moving the tests into a testing module. I also don't like this option. The other option would be to ditch the additional hibernate-search-testing module and go back to the pom "hack" we had initially which was creating a jar of the test classes. We just have to look at the version control history to get it back. I didn't like it initially and somehow preferred the solution with some duplicated classes. However, if the current setup causes trouble we might as well revert to what we had. I don't think there is a perfect solution for this issue, except maybe to switch to gradle ;-) --Hardy On Wed, 17 Nov 2010 19:07:45 +0100, Sanne Grinovero wrote: > Hello, > I'm in need to use some of the test classes from Hibernate Search > (core module) in the tests for the new Infinispan module; > > I was initially depending on the "hibernate-search-testing" Maven > module, which was recently split from our core test classes, > but then I started having seriously weird issues, finally finding out > that classes which were moved to the new module where > never removed from the old place; > in practice with eclipse's (totally broken) merging of classpaths I > was having both copies on classpath and picking the wrong > versions: this is because eclipse does merge the main and the test > classpaths (it has no notion of the different scopes), > and the new Infinispan module obviously does need to depend to the core > module. > > So I started cleaning up, deleting duplicate files from the core tests > to make sure I was going to use the ones provided > by hibernate-search-testing; this resulted in another blocking issue: > "A cycle was detected in the build path of project", > i.e. Eclipse now refuses to build anything, as core Search depends on > another artifact to run its tests. > >> From what I remember from the discussion when we created this module, > we followed this way because it was similar > to what core did; I'm now stuck and would like to use the same > approach used by Infinispan: it creates Maven > artifacts for the tests of the same module, test-jar. > This was the other alternative we discussed at the time, > as far as I remember we decided to go for the current configuration > because of consistency with core. > > The only alternative I see it so move all tests into the separate > project, but don't really like that; > final alternative is for me to ditch eclipse, but I'd rather keep > options open for everyone and > I'm not sure how far you tested this same things on IDEA either? > > Maybe you could try removing classes such as > org.hibernate.search.test.SearchTestCase from the core module > and see how far you get in IDEA, but I wouldn't expect a great > experience either. > > Cheers, > Sanne > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Fisheye for Search and Metamodelgen
Hi, seems the following URLs are live now: https://fisheye2.atlassian.com/changelog/Hibernate-Metamodelgen https://fisheye2.atlassian.com/changelog/Hibernate-Search The Jira source tab is functional again as well :) --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Search test module
To keep the happy end on the mailing list: while we might have gradle in the future, as a current solution I fixed the test classes (clones where actually different), and kept the module but removed all classes. The parent pom.xml now uses the maven-jar-plugin plugin to also create the "test" artifacts, and the module which is now empty takes this dependency and the others it was already providing, so it should work the same in practice for people using it as it provides the same classes and dependencies. https://github.com/hibernate/hibernate-search/pull/6 HSEARCH-635 - Hardy is reviewing it. Sanne 2010/11/18 Hardy Ferentschik : > I was not aware that the current setup does not work in Eclipse :( > On the other hand, we haven't had an additional module yet within the > project depending on the testing module. > > The duplication of classes is there because of the cycle you mentioned. > It is really a chicken and hen problem. The only solution to completely > remove the duplicates would be moving the tests into a testing module. > I also don't like this option. > > The other option would be to ditch the additional hibernate-search-testing > module and go back to the pom "hack" we had initially which was creating a > jar > of the test classes. We just have to look at the version control history to > get > it back. I didn't like it initially and somehow preferred the solution > with some duplicated classes. However, if the current setup causes trouble > we > might as well revert to what we had. > > I don't think there is a perfect solution for this issue, except maybe to > switch > to gradle ;-) > > --Hardy > > > > On Wed, 17 Nov 2010 19:07:45 +0100, Sanne Grinovero > wrote: > >> Hello, >> I'm in need to use some of the test classes from Hibernate Search >> (core module) in the tests for the new Infinispan module; >> >> I was initially depending on the "hibernate-search-testing" Maven >> module, which was recently split from our core test classes, >> but then I started having seriously weird issues, finally finding out >> that classes which were moved to the new module where >> never removed from the old place; >> in practice with eclipse's (totally broken) merging of classpaths I >> was having both copies on classpath and picking the wrong >> versions: this is because eclipse does merge the main and the test >> classpaths (it has no notion of the different scopes), >> and the new Infinispan module obviously does need to depend to the core >> module. >> >> So I started cleaning up, deleting duplicate files from the core tests >> to make sure I was going to use the ones provided >> by hibernate-search-testing; this resulted in another blocking issue: >> "A cycle was detected in the build path of project", >> i.e. Eclipse now refuses to build anything, as core Search depends on >> another artifact to run its tests. >> >>> From what I remember from the discussion when we created this module, >> >> we followed this way because it was similar >> to what core did; I'm now stuck and would like to use the same >> approach used by Infinispan: it creates Maven >> artifacts for the tests of the same module, test-jar. >> This was the other alternative we discussed at the time, >> as far as I remember we decided to go for the current configuration >> because of consistency with core. >> >> The only alternative I see it so move all tests into the separate >> project, but don't really like that; >> final alternative is for me to ditch eclipse, but I'd rather keep >> options open for everyone and >> I'm not sure how far you tested this same things on IDEA either? >> >> Maybe you could try removing classes such as >> org.hibernate.search.test.SearchTestCase from the core module >> and see how far you get in IDEA, but I wouldn't expect a great >> experience either. >> >> Cheers, >> Sanne >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Validator] method level validation
Hi, I'm writing this mail to give a short summary of a meeting on the method level validation feature for HV Emmanuel and I had yesterday. Basically there are not too many changes to what has previously been in discussion (see below). We agreed upon the following things to be probably useful: * The type hosting the method at which's parameter or return value a constraint violation occured should be marked as the root bean in resulting ConstraintViolation instances. Previously I thought this not to be a good idea but I rather changed my mind as this seems consistent , if we also do the following points: * There should be dedicated path Node derivations to describe a method/parameter/return value which would have all the specific required attributes (e.g. parameter index). That way we can create a semantically useful property path for the constraint violation. * MethodConstraintViolation from the current prototype should probably be decomposed into ParameterConstraintViolation and ReturnValueConstraintViolation * The issues related to the meta data API (a potential ParameterDescriptor interface etc.) should at least be investigated before shipping the method validation feature in order to be sure not to hinder the development of the meta data stuff in a meaningful way possibly later on. I'll continue on the prototyp based on that input and hopefully will have something to show in the near future. Any comments are warmly welcome. Gunnar 2010/10/4 Gunnar Morling > Hi, > > I pushed a first rough draft for the method-level validation to GitHub at > http://github.com/gunnarmorling/hibernate-validator/tree/method-level-preparations > > Currently only validateParameter() is implemented, but it shows, where the > journey could be going. The draft is implemented as outlined in my previous > mail: > > * MethodConstraintViolation extends ConstraintViolation with two attributes > "method" and "parameterIndex", which are always set > * ConstraintViolation#rootBean and propertyPath are set relative to any > parameter annotated with @Valid, otherwise they are null > > The test at > http://github.com/gunnarmorling/hibernate-validator/blob/method-level-preparations/hibernate-validator/src/test/java/org/hibernate/validator/test/engine/methodlevel/MethodLevelValidationTest.java > > should give you an impression. Validation is triggered by a dynamic > proxy/invocation handler in the test. > > I think I'll have a look at the property path stuff next. I'm still not > sure, whether the path API is the right thing to represent parameters. > > Using annotations for parameter names is a good idea, but as you said it > should be optional. Method-level validation should not require name > annotations. > > Gunnar > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] How can I configure sharding for customer data
Hi, In my application, I have configured hibernate search to index my customer data I have data specific to client and each client having the clientid. I need to create separate shards for each client dynamically and whenever search or update or create happens I need to find the specific shard using the client id. if its not supported, is it possible to customise ourselves. in order to customise how to go for it and what are all the changes do I need to do? Cheers, Suganya. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
