Message Title

Mincong HUANG commented on

For the 1st issue: Currently, the @BatchProperty injection is attribute-based. I'm wondering if we can replace them by constructor-based or method-based injection, so that the validation can be inside the constructor. Even better, we can use the new JBoss logger, implemented in HSEARCH-2627 Resolved , to handle the exception inside the constructor.
For the 2nd issue. We have a basic check through our utility class org.hibernate.search.jsr352.massindexing.MassIndexingJob before the start of the job, but you're right, we don't have any check when a job execution is starting. We could add a job-level listener to handle this check: if any validation fails, then the job will fail immediately.
For the 3rd issue: according to spec 9.3 Batch property, batch properties are string values:

Batch applications need a way to receive parameters when a job is initiated for execution. Properties can be defined by batch programming model artifacts, then have values passed to them when a job is initiated. Batch properties are string values.

So we have to use String values. But you're right, it would be great if batch properties could be parsed only once, and could be re-used in the hot path of the mass-indexing code.

This message was sent by Atlassian JIRA