4:43 p.m.
Hi all,
I'm in process to migrate an application from an old Hibernate Search version
to the latest one. We have been used own implementation of Worker.
In the old Hibernate Search version it was possible to define own implementation
of Worker using the property "hibernate.search.worker.scope". But it seems not
possible to do it in the latest version although the Hibernate Search Guide suggest
to use this property.
After studying the sources of Hibernate Search I have found that the property
to be used is "worker.scope". This change was introduced with the work on
the issue HSEARCH-761.
Could you please verify what is the right property name and either correct the
Hibernate Search Guide or change the property name in the Environment
class to the old one.
Thanks in advance!
Best regards
Andrej Golovnin
4:02 a.m.
Hi Andrej,
thanks for pointing this out. This is really a bug in the code rather than a documentation
error.
I created https://hibernate.onjira.com/browse/HSEARCH-1118 to track the issue. There will
be a 4.1.1 release shortly which will include a fix for the issue.
Out of interest though, what is your use case for a custom scope and what is your custom
implementation doing?
--Hardy
On May 6, 2012, at 11:43 PM, Andrej Golovnin wrote:
Hi all,
I'm in process to migrate an application from an old Hibernate Search version
to the latest one. We have been used own implementation of Worker.
In the old Hibernate Search version it was possible to define own implementation
of Worker using the property "hibernate.search.worker.scope". But it seems not
possible to do it in the latest version although the Hibernate Search Guide suggest
to use this property.
After studying the sources of Hibernate Search I have found that the property
to be used is "worker.scope". This change was introduced with the work on
the issue HSEARCH-761.
Could you please verify what is the right property name and either correct the
Hibernate Search Guide or change the property name in the Environment
class to the old one.
Thanks in advance!
Best regards
Andrej Golovnin
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:01 p.m.
Hi Hardy,
thanks for pointing this out. This is really a bug in the code rather
than a documentation error.
I created
https://hibernate.onjira.com/browse/HSEARCH-1118
to track the issue. There will
be a 4.1.1 release shortly which will include a fix for the issue.
Thanks!
Out of interest though, what is your use case for a custom scope and what is your custom
implementation doing?
Our custom implementation is based on TransactionalWorker. We have a requirement
to specify the index base by a system property. I see that in the current Hibernate
Search it is possible to do it by using the system property "indexBase"
(s. DirectoryProviderHelper#INDEX_BASE_PROP_NAME). It would be nice if you could
change this property to "hibernate.search.indexBase" and may be document it.
We have also had in our implementation what you name "Conditional Indexing".
But
it was removed last year or so as we don't need it any more. And our implementation
does not produce messages if it creates directories for indexes. I'm personally not
interested in the fact that Hibernate Search creates some directories (btw. IMHO it
should
be logged with info level and not warning. in other case we must configure nagios to
ignore this warnings.). For me it is pretty useless information.
Best regards,
Andrej Golovnin
4:54 p.m.
Hi Andrej,
On 7 May 2012 22:01, Andrej Golovnin <golovnin(a)gmx.net> wrote:
Hi Hardy,
> thanks for pointing this out. This is really a bug in the code rather than a
documentation error.
> I created
> https://hibernate.onjira.com/browse/HSEARCH-1118
> to track the issue. There will
> be a 4.1.1 release shortly which will include a fix for the issue.
Thanks!
>
> Out of interest though, what is your use case for a custom scope and what is your
custom
> implementation doing?
>
Our custom implementation is based on TransactionalWorker. We have a requirement
to specify the index base by a system property. I see that in the current Hibernate
Search it is possible to do it by using the system property "indexBase"
(s. DirectoryProviderHelper#INDEX_BASE_PROP_NAME). It would be nice if you could
change this property to "hibernate.search.indexBase" and may be document it.
The actual type passed to DirectoryProviderHelper is actually going to
limit the scope of properties being read, so the property key is not
just the "indexBase" constant but it is as documented:
"hibernate.search.default.indexBase"
or with the index name:
"hibernate.search.Animals.indexBase"
just search for "indexBase" in the reference documentation, there are
many examples of how to use this property.
I guess it might surprise you - it's indeed not pointed out in the
Hibernate Search documentation - that *all* configuration properties
can be set via System properties as well, as with all the Hibernate
core properties.
We have also had in our implementation what you name
"Conditional Indexing". But
it was removed last year or so as we don't need it any more.
You should have shared it! So you've been using Hibernate Search for
more than a year, you should have let us know about the annoying
things earlier to stretch them out ;-)
And our implementation
does not produce messages if it creates directories for indexes. I'm personally not
interested in the fact that Hibernate Search creates some directories (btw. IMHO it
should
be logged with info level and not warning. in other case we must configure nagios to
ignore this warnings.). For me it is pretty useless information.
Fair enough, I guess it was initially expected that someone out there
would have prepared the directories correctly, but I agree let's
change that to INFO. Could you open a JIRA, and maybe you could patch
the code and send a pull request?
Thanks for your feedback!
Sanne
Best regards,
Andrej Golovnin
3:33 a.m.
On May 7, 2012, at 11:54 PM, Sanne Grinovero wrote:
> And our implementation
> does not produce messages if it creates directories for indexes. I'm personally
not
> interested in the fact that Hibernate Search creates some directories (btw. IMHO it
should
> be logged with info level and not warning. in other case we must configure nagios to
> ignore this warnings.). For me it is pretty useless information.
Fair enough, I guess it was initially expected that someone out there
would have prepared the directories correctly, but I agree let's
change that to INFO. Could you open a JIRA, and maybe you could patch
the code and send a pull request?
I am not quite sure which message we are talking about concretely, but I just wanted to
say that you
can configure the log level for each single class. You don't have to provide a custom
implementation
just because you don't like the logging in the default implementation.
This does not mean that I am against changing the log level. Just thought it might be
worse mentioning.
As Sanne said, thanks for the feedback :-)
--Hardy
4:12 p.m.
Hi Sanne,
> Our custom implementation is based on TransactionalWorker. We
have a requirement
> to specify the index base by a system property. I see that in the current Hibernate
> Search it is possible to do it by using the system property "indexBase"
> (s. DirectoryProviderHelper#INDEX_BASE_PROP_NAME). It would be nice if you could
> change this property to "hibernate.search.indexBase" and may be document
it.
We have a custom scope implementation and a custom
DirectoryProvider. The custom DirectoryProvider has used a system property
to specify the index base. But now I can remove it and use the default one.
The custom scope implementation were used first to provide
"Conditional Indexing", which is now removed, and it also allows us to
exchange index changes between application nodes using JMS topic and
durable subscribers. Every node has its own index, which it can update
independently of other nodes and posts changes to the index to the JMS
topic. The messages posted to the JMS topic are persistent and contains
unique node id, so that the node may ignore own changes. In our
architecture all nodes are equal. We don't have a master node.
I guess it might surprise you - it's indeed not pointed out in the
Hibernate Search documentation - that *all* configuration properties
can be set via System properties as well, as with all the Hibernate
core properties.
Nice, thanks for the hint!
> We have also had in our implementation what you name "Conditional
Indexing". But
> it was removed last year or so as we don't need it any more.
You should have shared it! So you've been using Hibernate Search for
more than a year, you should have let us know about the annoying
things earlier to stretch them out ;-)
To be exactly we use Hibernate Search since 2007. :-)
Fair enough, I guess it was initially expected that someone out there
would have prepared the directories correctly, but I agree let's
change that to INFO. Could you open a JIRA, and maybe you could patch
the code and send a pull request?
OK, I will do it.
Best regards,
Andrej Golovnin
4:12 p.m.
Hi Hardy,
I am not quite sure which message we are talking about concretely,
but I just wanted to say that you
can configure the log level for each single class. You don't have to provide a custom
implementation
just because you don't like the logging in the default implementation.
I know that I can configure the log level for each single class. But at the time we
started to use
Hibernate Search it was not clear that configuration properties can be set
via System properties. So logging was not the main motivation. :-)
And we are talking about Log#indexDirectoryNotFoundCreatingNewOne().
BTW can you or Sanne or someone else please take look at the class
AvroSerializationProvider, line 73.
Is it really needed to log for every instance of AvroSerializationProvider the same
information? I have started today for the first time the application server with the
new Hibernate Search and our application and I have seen this message more
than 100 times in the log file. I doubt it should be logged in the constructor.
IMHO a static initialization block would be a better place.
Best regards,
Andrej Golovnin
3:35 a.m.
BTW can you or Sanne or someone else please take look at the class
AvroSerializationProvider, line 73.
Is it really needed to log for every instance of AvroSerializationProvider the same
information? I have started today for the first time the application server with the
new Hibernate Search and our application and I have seen this message more
than 100 times in the log file. I doubt it should be logged in the constructor.
IMHO a static initialization block would be a better place.
We have identified the problem but that's a little bit more complicated than that.
https://hibernate.onjira.com/browse/HSEARCH-1100
4380
days inactive
4383
days old
7 comments
4 participants
participants (4)
-
Andrej Golovnin -
Emmanuel Bernard -
Hardy Ferentschik -
Sanne Grinovero