Re: [hibernate-dev] [HSEARCH] package split in API/SPI/private aka HSEARCH-746
2011/5/10 Emmanuel Bernard : > I've started the work to split classes between API, SPI and private classes. > Some areas went very well, some are more problematic but that was to be > expected. Anyways it did generate a couple of questions from philosophical to > concrete. Please try and chime in. > > 1. > API vs SPI: > http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-746 > > I have a question on API vs SPI. > The Hibernate Core team uses the following rule: > - any "public" API not directly called by the user application is a SPI (for > example a Bridge would be SPI and I imagine BootStrategy would be too etc). > > We could however sue a different rule: > - any API targeted at frameworks integrating with Hibernate Search are SPIs > For example SearchConfiguration and SearchFactoryIntegrator would be SPIs but > Bridge classes and BoostStrategy would not > > I'm tempted by the second definition as it separate user focused classes from > integration / framework focused classes. Of course nothing is in back and > white and some classes can be hard to categorize. +1, reasoning in next paragraph > > An aternative approach is to mix the two definitions: > - any "public" API not directly called by the user application is a SPI (for > example a Bridge would be SPI and I imagine BootStrategy would be too etc). > - any API targeted at frameworks integrating with Hibernate Search are SPIs > For example SearchConfiguration and SearchFactoryIntegrator would be SPIs > > But then we lose the distinction between framework APIs and user APIs. > > What do you think? I'd consider a BoostStrategy or a FieldBridge part of the API as people do directly refer to it in the model: @DynamicBoost(MyStrategy.class), so it's one of those things that if we change the package, class name or interface it breaks the user's application. I mention the interface because for example the BoostStrategy implementation is very likely provided by the users and strongly coupled to their code (both model and business). I agree it's not black/white, but when integrating search with Infinispan Query for example we definitely don't care about the DynamicBoost & co, we don't use them to integrate with third party projects, app servers, grids, but I consider them "user facing". > > > 2. Specific issues: > o org.hibernate.search.batchindexing.impl.Executors is used by > MutablefactoryTest > should we keep executors as private or should we consider it an actual API or > SPI? I don't think exposing this as SPI is very useful to people, but at some point in future it's possible we might want to make this a replaceable component, to let the AS (for example) provide threads and monitor them. Even if it's private, wouldn't our tests still be able to use it? > > o Should built-in types be public APIs/SPIs? > I was tempted to put some if not all as private classes but there are use > cases where these classes are used by actual users: > - the programmatic API (ProgrammaticSearchMappingFactory uses them) > - provided id settings Can't we keep stuff in .impl packages but not necessarily private? > > Should we consider some / all as public classes? For example what about > ClassBridge? > > o Is NumericFieldUtils a public class? It is used by NumericFieldTest, > ProjectionQueryTest but it seems a user should not use this helper class Having something like NumericFieldUtils is useful to write numeric queries, but it doesn't necessarily have to have the current API. I'm fine in hiding it and suggest people to use the DSL, and eventually add a better helper later on if needed. > > o SearchConfiguration is very likely an SPI which means we will need to break > Infinispan's query module, is that OK? I'ts definitely and SPI. what do you mean by breaking Query? if you only want to move it to a different package that's not an issue; if you want to change the exposed methods please suggest how and I'll check with Query if that is arrangeable. > o Programmatic API > *Mapping objects are messed up with *Descriptor objects > It seems to be that *Descriptors should be private while *Mapping should be > API, do you think it's worth working on this? The programmatic mapping si > still considered experimental so we have some time I guess. +1 let's do that, as you say not very urgent. > > o SearchFactoryIntegrator vs SearchFactoryImplementor > In my mind, I introduced SearchFactoryIntegrator to separate private > SearchFactory usage from frameworks usage. > Does the Infinispan Query module depends on SearchFactoryImplementor only? Or > is it depending on SearchFactoryImplementor? It's built on top of SearchFactoryIntegrator, in some tests this is cast to SearchFactoryImplementor to be able to verify some state but I think you can ignore that. Currently Query needs only #getDocumentBuildersIndexedEntities(), in worst case we could expose that. Sanne > > That's all for now but more will come :) > > Emmanuel > > >
Re: [hibernate-dev] [HSEARCH] package split in API/SPI/private aka HSEARCH-746
See answers inline >> 1. >> API vs SPI: >> http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-746 >> >> I have a question on API vs SPI. >> The Hibernate Core team uses the following rule: >> - any "public" API not directly called by the user application is a >> SPI (for example a Bridge would be SPI and I imagine BootStrategy would >> be too etc). >> >> We could however sue a different rule: >> - any API targeted at frameworks integrating with Hibernate Search >> are SPIs For example SearchConfiguration and SearchFactoryIntegrator >> would be SPIs but Bridge classes and BoostStrategy would not >> >> I'm tempted by the second definition as it separate user focused >> classes from integration / framework focused classes. Of course nothing >> is in back and white and some classes can be hard to categorize. > > +1, reasoning in next paragraph +1 from me as well. Still not convinced that this rigorous package naming is really a good idea, but it seems we are committed. >> o SearchFactoryIntegrator vs SearchFactoryImplementor >> In my mind, I introduced SearchFactoryIntegrator to separate private >> SearchFactory usage from frameworks usage. >> Does the Infinispan Query module depends on SearchFactoryImplementor >> only? Or is it depending on SearchFactoryImplementor? > > It's built on top of SearchFactoryIntegrator, in some tests this is > cast to SearchFactoryImplementor to be able to verify some state but I > think you can ignore that. > Currently Query needs only #getDocumentBuildersIndexedEntities(), in > worst case we could expose that. I don't have much to say to the other points, but if we could get rid of one of these I would give it a big +1. --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HSEARCH] package split in API/SPI/private aka HSEARCH-746
2011/5/11 Hardy Ferentschik : > See answers inline > >>> 1. >>> API vs SPI: >>> http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-746 >>> >>> I have a question on API vs SPI. >>> The Hibernate Core team uses the following rule: >>> - any "public" API not directly called by the user application is a SPI >>> (for example a Bridge would be SPI and I imagine BootStrategy would be too >>> etc). >>> >>> We could however sue a different rule: >>> - any API targeted at frameworks integrating with Hibernate Search are >>> SPIs For example SearchConfiguration and SearchFactoryIntegrator would be >>> SPIs but Bridge classes and BoostStrategy would not >>> >>> I'm tempted by the second definition as it separate user focused classes >>> from integration / framework focused classes. Of course nothing is in back >>> and white and some classes can be hard to categorize. >> >> +1, reasoning in next paragraph > > +1 from me as well. > Still not convinced that this rigorous package naming is really a good idea, > but it seems we are committed. > >>> o SearchFactoryIntegrator vs SearchFactoryImplementor >>> In my mind, I introduced SearchFactoryIntegrator to separate private >>> SearchFactory usage from frameworks usage. >>> Does the Infinispan Query module depends on SearchFactoryImplementor >>> only? Or is it depending on SearchFactoryImplementor? >> >> It's built on top of SearchFactoryIntegrator, in some tests this is >> cast to SearchFactoryImplementor to be able to verify some state but I >> think you can ignore that. >> Currently Query needs only #getDocumentBuildersIndexedEntities(), in >> worst case we could expose that. I see my wording wasn't very clear. I meant to say that Query only needs #getDocumentBuildersIndexedEntities() in a single test - no need at all in the main code for the SearchFactoryImplementor. > > I don't have much to say to the other points, but if we could get rid of > one of these I would give it a big +1. Maybe we could remove the lowest level interface, so that real low level has to deal with the implementation. I'm +/-0 about it, ok we have a bit too many interfaces stacked but they look useful. I could add an additional module - or reuse the integration-tests - to actually depend on infinispan-query and run a smoke test; this won't add any circular dependency but might give immediate feedback on breaking Query during a test run, might make you more relaxed in changing anything around this interface stack as it would provide quick feedback on what's ok to do. The drawback would be when we actually agree we need to break it, we'd need to a bit more work. Sanne > > --Hardy > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate OGM
Hey, I've taken some time and, in an attempt to port Hibernate OGM to use Ehcache instead of Infinispan, abstracted it from Infinispan. As the doc on that task states, I've made all calls use ConcurrentMap (rather than Map actually). I had a little trouble understanding the "Skip locking proposed by Sanne" in OgmTableGenerator.doWorkInCurrentTransactionIfAny, so that this does a simple Map.get now (that might have been a specialization for a Dialect, but couldn't understand what it was all about). And finally introduced a new hibernate.grid.manager prop to instantiate the proper provider... The changes are available here: https://github.com/alexsnaps/hibernate-ogm/commit/d0fcbffed4c4bcc2aa5208c049ca5e870e07424e Hope that can be made useful… I also wanted to start looking into queries next. But I'll send another mail on that later. Thanks, Alex -- Alex Snaps Senior Software Engineer - Terracotta http://twitter.com/alexsnaps http://www.linkedin.com/in/alexsnaps ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate OGM
Hi Alex, thank you I'm having a look and will comment more on github directly. A first comment: I see that a big part of your patch is about replaceing "Cache" with "ConcurrentMap" and renaming variables to be consistent with this change; at the same time in the JSR-107 forum it seems that everybody is agreeing on *not* extending Map, while there's going to be something similar to a Map, this is going to be called "Cache", so I'd stick with our current name. I understand this is a bit in flux now and nothing is cast in stone, but at the moment it would be better to keep your patch smaller and avoiding these conversions, or at least keeping these refactorings as a separate commit. The plan is to build the first version of queries on top of Hibernate Search, so basically that's already an abstraction on top of any "Grid implementation" and it should work fine with EHCache as well; Lucene won't be able to solve all use cases though so for some cases we'll need to tap into special functionalities offered by the grid provider, but that's going to be a second step. Suggestions welcome of course! As far as the "skip locking" pattern, that's currently the way to build a sequence generator on top of Infinispan, in case of EHCache you might want to suggest a totally different approach, I'd expect that this should be an implementation detail at the dialect level, not necessarily common code. Regards, Sanne 2011/5/11 Alex Snaps : > Hey, > I've taken some time and, in an attempt to port Hibernate OGM to use Ehcache > instead of Infinispan, abstracted it from Infinispan. > As the doc on that task states, I've made all calls use ConcurrentMap (rather > than Map actually). I had a little trouble understanding the "Skip locking > proposed by Sanne" in OgmTableGenerator.doWorkInCurrentTransactionIfAny, so > that this does a simple Map.get now (that might have been a specialization > for a Dialect, but couldn't understand what it was all about). > And finally introduced a new hibernate.grid.manager prop to instantiate the > proper provider... > > The changes are available here: > https://github.com/alexsnaps/hibernate-ogm/commit/d0fcbffed4c4bcc2aa5208c049ca5e870e07424e > > Hope that can be made useful… I also wanted to start looking into queries > next. But I'll send another mail on that later. > Thanks, > Alex > > > -- > Alex Snaps > Senior Software Engineer - Terracotta > http://twitter.com/alexsnaps > http://www.linkedin.com/in/alexsnaps > > ___ > 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] Hibernate OGM
Unintentionally left the ML out. Sanne, wrt jsr107 fair enough. I then feel that we should not leverage Map and use a custom type that only declare what's needed (and avoids the return value, when not required). I think that'd make it simpler, wdyt ? How should we name that thing ? My first attempt was GridMap... On Wednesday 11 May 2011 at 16:50, Sanne Grinovero wrote: > 2011/5/11 Alex Snaps : > > On Wednesday 11 May 2011 at 15:38, Sanne Grinovero wrote: > > Hi Alex, > > > thank you I'm having a look and will comment more on github directly. > > I'll look into your comments and will adapt. thanks! > > > > > > > > A first comment: I see that a big part of your patch is about > > > replaceing "Cache" with "ConcurrentMap" and renaming variables to be > > > consistent with this change; at the same time in the JSR-107 forum it > > > seems that everybody is agreeing on *not* extending Map, while there's > > > going to be something similar to a Map, this is going to be called > > > "Cache", so I'd stick with our current name. > > > I understand this is a bit in flux now and nothing is cast in stone, > > > but at the moment it would be better to keep your patch smaller and > > > avoiding these conversions, or at least keeping these refactorings as > > > a separate commit. > > > > I think that makes sense, I actually started with neither Map nor > > ConcurrentMap, but some other random Grib interface. > > I then saw the wiki page mentioning Map... I certainly can review this, but > > it does look like the plan is to have this tailored to jsr-107, I didn't > > know that. I'll stick to ConcurrentMap return values, but will not rename > > further. > > Sorry I didn't mean to state that we're going to support jsr-107, we > should discuss that but it's unlikely in practice as we want to > support more alternatives than key/value stores. > I'm only mentioning it as the abstraction you're introducing now will > make OGM support only Infinispan and EHCache, and they happen to have > this common API which gives names the building blocks as "Cache" and > "CacheManager". So for the time being there's no need to change all > variable names. It will definitely be more complex when other storage > engines will be added; it might be an option to use JSR-107 or JSR-347 > at least for the key/value implementors but I don't think either is > going to cover all of noSQL. > Also even if we wanted to finish only Infinispan and EHCache, I don't > think the ConcurrentMap API would be good enough, we likely need a > more intrusive definition of "dialect" here. > > > > > The plan is to build the first version of queries on top of Hibernate > > > Search, so basically that's already an abstraction on top of any "Grid > > > implementation" and it should work fine with EHCache as well; Lucene > > > won't be able to solve all use cases though so for some cases we'll > > > need to tap into special functionalities offered by the grid provider, > > > but that's going to be a second step. Suggestions welcome of course! > > I have seen that Hibernate Search approach, I wondered whether a real query > > bridge to the grid wouldn't make more sense. But I totally agree that that > > approach makes total sense as a first step. > > > > > > > > As far as the "skip locking" pattern, that's currently the way to > > > build a sequence generator on top of Infinispan, in case of EHCache > > > you might want to suggest a totally different approach, I'd expect > > > that this should be an implementation detail at the dialect level, not > > > necessarily common code. > > Alright, that makes sense as well... I'll look into abstracting that nicely > > behind the Dialect then. > > > > > > > > Regards, > > > Sanne > > > > > > > > > 2011/5/11 Alex Snaps : > > > > Hey, > > > > I've taken some time and, in an attempt to port Hibernate OGM to use > > > > Ehcache instead of Infinispan, abstracted it from Infinispan. > > > > As the doc on that task states, I've made all calls use ConcurrentMap > > > > (rather than Map actually). I had a little trouble understanding the > > > > "Skip locking proposed by Sanne" in > > > > OgmTableGenerator.doWorkInCurrentTransactionIfAny, so that this does a > > > > simple Map.get now (that might have been a specialization for a > > > > Dialect, but couldn't understand what it was all about). > > > > And finally introduced a new hibernate.grid.manager prop to instantiate > > > > the proper provider... > > > > > > > > The changes are available here: > > > > https://github.com/alexsnaps/hibernate-ogm/commit/d0fcbffed4c4bcc2aa5208c049ca5e870e07424e > > > > > > > > Hope that can be made useful… I also wanted to start looking into > > > > queries next. But I'll send another mail on that later. > > > > Thanks, > > > > Alex > > > > > > > > > > > > -- > > > > Alex Snaps > > > > Senior Software Engineer - Terracotta > > > > http://twitter.com/alexsnaps > > > > http://www.linkedin.com/in/alexsnaps > > > > > > > >
Re: [hibernate-dev] Hibernate OGM
2011/5/11 Alex Snaps : > Unintentionally left the ML out. oops, sorry didn't realize that. for everyone else: please find my previous reply below; > Sanne, wrt jsr107 fair enough. I then feel that we should not leverage Map > and use a custom type that only declare what's needed (and avoids the return > value, when not required). I think that'd make it simpler, wdyt ? How should > we name that thing ? My first attempt was GridMap... So you need something like a Cache, but 1- avoid the org.infinispan package 2- provide non-return value methods (Infinispan does this setting flags in the context to avoid an explosion of methods - does EHCache have something similar?) ? GridMap sounds fine, but again it's just a temporary solution until non-grids are supported as well. Other opinions ? Sanne > On Wednesday 11 May 2011 at 16:50, Sanne Grinovero wrote: >> 2011/5/11 Alex Snaps : >> > On Wednesday 11 May 2011 at 15:38, Sanne Grinovero wrote: >> > Hi Alex, >> > > thank you I'm having a look and will comment more on github directly. >> > I'll look into your comments and will adapt. thanks! >> > >> > > >> > > A first comment: I see that a big part of your patch is about >> > > replaceing "Cache" with "ConcurrentMap" and renaming variables to be >> > > consistent with this change; at the same time in the JSR-107 forum it >> > > seems that everybody is agreeing on *not* extending Map, while there's >> > > going to be something similar to a Map, this is going to be called >> > > "Cache", so I'd stick with our current name. >> > > I understand this is a bit in flux now and nothing is cast in stone, >> > > but at the moment it would be better to keep your patch smaller and >> > > avoiding these conversions, or at least keeping these refactorings as >> > > a separate commit. >> > >> > I think that makes sense, I actually started with neither Map nor >> > ConcurrentMap, but some other random Grib interface. >> > I then saw the wiki page mentioning Map... I certainly can review this, >> > but it does look like the plan is to have this tailored to jsr-107, I >> > didn't know that. I'll stick to ConcurrentMap return values, but will not >> > rename further. >> >> Sorry I didn't mean to state that we're going to support jsr-107, we >> should discuss that but it's unlikely in practice as we want to >> support more alternatives than key/value stores. >> I'm only mentioning it as the abstraction you're introducing now will >> make OGM support only Infinispan and EHCache, and they happen to have >> this common API which gives names the building blocks as "Cache" and >> "CacheManager". So for the time being there's no need to change all >> variable names. It will definitely be more complex when other storage >> engines will be added; it might be an option to use JSR-107 or JSR-347 >> at least for the key/value implementors but I don't think either is >> going to cover all of noSQL. >> Also even if we wanted to finish only Infinispan and EHCache, I don't >> think the ConcurrentMap API would be good enough, we likely need a >> more intrusive definition of "dialect" here. >> >> >> > > The plan is to build the first version of queries on top of Hibernate >> > > Search, so basically that's already an abstraction on top of any "Grid >> > > implementation" and it should work fine with EHCache as well; Lucene >> > > won't be able to solve all use cases though so for some cases we'll >> > > need to tap into special functionalities offered by the grid provider, >> > > but that's going to be a second step. Suggestions welcome of course! >> > I have seen that Hibernate Search approach, I wondered whether a real >> > query bridge to the grid wouldn't make more sense. But I totally agree >> > that that approach makes total sense as a first step. >> > >> > > >> > > As far as the "skip locking" pattern, that's currently the way to >> > > build a sequence generator on top of Infinispan, in case of EHCache >> > > you might want to suggest a totally different approach, I'd expect >> > > that this should be an implementation detail at the dialect level, not >> > > necessarily common code. >> > Alright, that makes sense as well... I'll look into abstracting that >> > nicely behind the Dialect then. >> > >> > > >> > > Regards, >> > > Sanne >> > > >> > > >> > > 2011/5/11 Alex Snaps : >> > > > Hey, >> > > > I've taken some time and, in an attempt to port Hibernate OGM to use >> > > > Ehcache instead of Infinispan, abstracted it from Infinispan. >> > > > As the doc on that task states, I've made all calls use ConcurrentMap >> > > > (rather than Map actually). I had a little trouble understanding the >> > > > "Skip locking proposed by Sanne" in >> > > > OgmTableGenerator.doWorkInCurrentTransactionIfAny, so that this does a >> > > > simple Map.get now (that might have been a specialization for a >> > > > Dialect, but couldn't understand what it was all about). >> > > > And finally introduced a new hibernate.grid.manager prop to >> > > >
[hibernate-dev] providing AnalyzerUtils in Hibernate Search
We're using AnalyzerUtils in some of the tests in Hibernate Search, but I'm finding myself recommending people to "write something like that" quite often lately, it seems that otherwise people have an hard time to figure if their analyzer definitions make any sense. What do you think in moving this class into the main jar, polish the javadoc a bit and add a note on how to check your analyzer in the docs? Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] providing AnalyzerUtils in Hibernate Search
+1 - this thought crossed my mind before as well. As a continuation I thought about it would be nice to be able analyze a sentence in the JMX console. This ties a little in with the ability of a meta data api which would allow to get more information about the indexed fields. Anyways, just day dreaming here On Wed, 11 May 2011 17:45:28 +0200, Sanne Grinovero wrote: > We're using AnalyzerUtils in some of the tests in Hibernate Search, > but I'm finding myself recommending people to "write something like > that" quite often lately, it seems that otherwise people have an hard > time to figure if their analyzer definitions make any sense. > > What do you think in moving this class into the main jar, polish the > javadoc a bit and add a note on how to check your analyzer in the > docs? > > 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] providing AnalyzerUtils in Hibernate Search
2011/5/11 Hardy Ferentschik : > +1 - this thought crossed my mind before as well. Created HSEARCH-749 > As a continuation I thought about it would be nice to be able analyze a > sentence in the JMX console. This ties a little in with the ability of > a meta data api which would allow to get more information about the > indexed fields. Anyways, just day dreaming here +1, please create another issue as I'm not sure how to describe that > > > On Wed, 11 May 2011 17:45:28 +0200, Sanne Grinovero > wrote: > >> We're using AnalyzerUtils in some of the tests in Hibernate Search, >> but I'm finding myself recommending people to "write something like >> that" quite often lately, it seems that otherwise people have an hard >> time to figure if their analyzer definitions make any sense. >> >> What do you think in moving this class into the main jar, polish the >> javadoc a bit and add a note on how to check your analyzer in the >> docs? >> >> 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] Hibernate Search 3.5 or 4
Hello, To conclude this thread, there are still three notes "being discussed" on the wiki: http://community.jboss.org/wiki/PlansforHibernateSearch4 1) assume exclusive_index_use=true as default That was my proposal, I'm not sure we're all agreeing on that. Emmanuel was concerned for the index safety but I replied that it doesn't remove locking. 2) Make it possible to configure different backends per index (there can currently be only one backend Another proposal, the wiki points out the 3 main reasons to do that: * tune different backends for different purposes * make it possible to have sync / async on different entities/indexes. * use different clustering/replication options or even technologies per index 3)Service instances for the public extensions points sometimes it's useful to pass instances instead of mere classnames to a SearchConfiguration * Infinispan Query would love it to pass a self-built Directory factory so that Search could use that to store indexes on the same Infinispan instance (instead of starting a second cluster). So if we clarify this plan I'd like to start filling up JIRAs, we can then mark the most urgent ones for the next alpha and try making a plan. We especially need to coordinate on some of the issues, as if one of us is going to change all package names while the other rewrites the indexmanager, that creates some work we could avoid. Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] jira down
JIRA Startup Failed You cannot access JIRA at present. Look at the table below to identify the reasons Description The jira.home directory '/opt/j2ee/domains/atlassian.com/opensource/projects/webapps/atlassian-jira/hibernate/data' is already locked. Please see the JIRA documentation for more information on locked jira.home directories. --- Strong Liu http://hibernate.org http://github.com/stliu ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
