Classes extending BackendQueueProcessor are badly named XYZBackendQueueProcessorFactory
---------------------------------------------------------------------------------------
Key: HSEARCH-855
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-855
Project: Hibernate Search
Issue Type: Improvement
Components: documentation, engine
Reporter: Hardy Ferentschik
Fix For: 4.0.0.Alpha2
See GitHub commit note -
https://github.com/Sanne/hibernate-search/commit/44e50d4a8234fd3e96f0ae38...
{quote}
Haven't really looked at this code for some time, so I have a little bit of a beginner
mind. Why is this thing called 'Factory'. Either the class or the interface is not
named correctly. Should the interface maybe be BackendQueueProcessorFactory? We have a
whole bunch of XYZBackendQueueProcessor, but they are now Runnables. Looking at
BackendQueueProcessor I would say this name is correct, but the implementing classes
should drop the 'Factory'. The current XYZBackendQueueProcessor classes could
become XYZBackendQueueProcessorTask. WDYT?
{quote}
{quote}
right, that's a long standing issue, I agree with that and actually it confuses me
often. Very legacy names, I didn't really want at this point to rename everything so
that - assuming you all knew this code a bit - recognizing old friends would have been
easier. I've changed so much already.
So, with the old design this was a Runnable Factory, as it returned Runnable instances,
but now it still creates and uses Runnables, but this isn't exposed anymore so I like
the interface name as it does a good job in representing the Processor.
WDYT of changing the classname of all *ProcessorFactory to *Processor ? (i.e. this affects
JMS, JGroups, etc...)
Mind you, this affects end users using FQC names so if you agree in doing it (I'm all
for it) I think we should track it both on JIRA and on the migration guide.
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira