I installed a custom rescorer plugin on Elasticsearch but I couldn't find a way to call it by using ElasticsearchOperations.
I'm using the NativeSearchQuery built by a NativeSearchQueryBuilder but I could only find a method to add a QueryRescore and not a custom one.
Is there a way to use a custom rescorer plugin?
Actually I don't see such a possibility in the code of org.elasticsearch.search.builder.SearchSourceBuilder. There is the method addRescorer(RescorerBuilder<?> rescoreBuilder) but the only RescorerBuilder that Elasticsearch offers is the org.elasticsearch.search.rescore.QueryRescorerBuilder.
So for Spring Data Elasticsearch there is currently no way to add custom rescorers.
Elasticserach offer the abstract class org.elasticsearch.search.rescore.RescorerBuilder that can be extented for custom implementation.
Is there any chance to work in org.springframework.data.elasticsearch.core.RequestFactory#prepareSearchRequest method and org.springframework.data.elasticsearch.core.query.Query interface to accept generic RescorerBuilder<RB extends RescorerBuilder> and not only the elasticsearch provided implementation ?
Related
Is there a way to change the HTML given by the method render(), on Laravel's pagination?
Note: I solved this creating a helper that uses str_replace, but I don't think this is the most correct way...
Thanks
First you need to create a CustomPaginator Class that extends
Illuminate\Pagination\BootstrapThreePresenter
And override its methods.
I needed a custom class attached pagination with 1 onEachSide instead of 3.
So I did this:
https://gist.github.com/aykutcan/495d43041571854a7507
I've found this library -
Landish/Pagination
- that already brings some paginators and lets you easily create your own.
I am using Spring security rest plugin to authenticate the user. In this, there is a class named RestAuthenticationFilter. Now I want to call the methods of some custom class say CustomRestAuthenticationFilter (which extends RestAuthenticationFilter) instead of RestAuthenticationFilter. How to do this?
Is there any way that we define in resources.groovy or somewhere else that to use CustomRestAuthenticationFilter instead of RestAuthenticationFilter ?
I believe the filtering is nicely described ... in the documentation!
https://grails-plugins.github.io/grails-spring-security-core/guide/filters.html
Just amend the grails.plugin.springsecurity.filterChain.filterNamesvalue in the Config.groovy file so it contains your RestAuthenticationFilter instead of RestAuthenticationFilter and you should be good to go.
When validating domainclasses in Grails, it uses the DefaultMessageCodesResolver from Spring to "extend" the set of i18n-keys to try and lookup. I would like to simplify this, and have therefore implemented my own SimpleMessageCodesResolver by extending the MessageCodesResolver interface.
However, I can't seem to make Grails pick up on this. I've declared it as a custom dependency injection, trying to override, what Spring normally does:
messageCodesResolver(SimpleMessageCodesResolver)
I still see the DefaultMessageCodesResolver when looking at the domain object... Any ideas how to make this work?
I belive your custom dependency injection should be:
defaultMessageCodesResolver(SimpleMessageCodesResolver)
MessageCodesResolver is an interface, but not spring bean as DefaultMessageCodesResolver instance is.
I have to implement a webservice client using Spring WS.
I've read the documentation at http://static.springsource.org/spring-ws/site/reference/html/client.html but it's not clear to me what are the advantages of extending WebServiceGatewaySupport versus directly using WebServiceTemplate in my service class.
As far as I can tell from the source, the WebServiceGatewaySupport only has a couple of wrapper methods for the WebServiceTemplate and some initialization support.
So why should I extend WebServiceGatewaySupport instead of directly using a WebServiceTemplate ?
Thank you!
I think this sums it all up (found in the client reference you linked):
Alternatively, consider deriving from Spring-WS's
WebServiceGatewaySupport convenience base class, which exposes
convenient bean properties to enable easy configuration. (You do not
have to extend this base class... it is provided as a convenience
class only.)
So, if the WebserviceTemplate offers all you need, that'll probably suffice. If you need anything extra you can use the WebServiceGatewaySupport as an example on how to wrap your own convenience methods around the WebserviceTemplate.
In my client software, I just configure the WebserviceTemplate in my #Configuration class like this:
#Bean
public WebServiceTemplate webServiceTemplate() {
WebServiceTemplate template = new WebServiceTemplate();
template.setMessageFactory(messageFactory());
template.setDefaultUri(defaultUri);
template.setMarshaller(marshaller());
template.setUnmarshaller(marshaller());
template.setInterceptors(new ClientInterceptor[] {interceptor()});
return template;
}
(All the method calls are references to other methods in the configuration which aren't that relevant in this example).
I can use that bean everywhere in my code to send messages.
I'm using the resources.groovy to declare a service e.g.
aService(com.foo.OrganizationService)
so that I can tie aService to my controllers instead of using organizationService which could change in the future.
I've noticed that the OrganizationService doesn't get treated special like other services "not" declared in the resources.groovy. For example it doesn't get injected with grailsApplication, and likely a hibernateSession etc and other things I've not hit yet....
Now, I know I can manually wire in stuff to my service but I'd rather not have to maintain that...
Is there a special way to declare a service in the resources.groovy so that gets treated like another service that grails loads up?
TIA
The short answer to your question is "no".
Under the covers, Grails services are driven by some intelligent code that is referencing a specific location and expecting certain properties.
Viewing the source code (especially around the ServicesGrailsPlugin.groovy) is a good way to see the "magic" in how these are wired together.
Is there a reason you wouldn't want to use a bonafide Grails service to solve your problem? If you are expecting things like a grailsApplication, it seems like that use is pretty specific to Grails and would be a good candidate for porting over to a "true" Grails service.
Good luck!
So I've come full circle on this. This is a timing problem. Where services haven't been grails initialized yet.
Basically when you use the resources.groovy to do service wiring you run the risk of using a Service that might initialize itself e.g. afterPropertiesSet method or static initializers that use grails services (log, hibernate session, ..) that haven't been injected yet.
So... What I've turned to instead is to create my own BeanBuilder in a BootStrap.groovy file.
BeanBuilder builder = new BeanBuilder(grailsApplication.parentContext)
def bb = builder.beans {
LoginListener(com.foo.LoginListener) {
springSecurityService = ref("springSecurityService")
userService = ref("userService")
}
}
bb.registerBeans(grailsApplication.mainContext)