I have a service that is managed by spring and I want to use or inject as dependency in drool rule. How can I use the service bean in the Drool rule?
#Service
public class SomeService {
public void doSomething() {}
}
dialect "mvel"
rule "something"
when
................
then
service.doSomething()
end
Pass your bean instance into working memory when you invoke them, the same as you'd pass any other data in. This way you can autowire or otherwise leverage dependency injection to get your Spring-managed singleton bean, and then use that same bean in your rules without having to new up another instance.
#Component
class RuleExecutor {
private final SomeService service; // Bean set via constructor injection
public RuleExecutor(SomeService service) {
this.service = service;
}
public void fireRules( ... ) { // assuming other data passed in via parameter
KieSession kieSession = ...;
kieSession.insert( this.service); // insert bean into the working memory
kieSession.insert( ... ); // insert other data into working memory
kieSession.fireAllRules();
}
}
In this example I used constructor injection to pass in the bean instance. We can assume that both the #Service and this #Component were picked up by the component scan.
Then you could interact with it in the rules in the same way as you'd do any other data:
dialect "mvel"
rule "something"
when
service: SomeService()
then
service.doSomething()
end
Remember that service: SomeService() matches an instance of SomeService in working memory and assigns it to the service variable for use in the rule. It does not new up a new instance.
Related
I'm trying to inject an optional bean into a service. The bean is successfully created but consistently after the dependent service. Any thoughts why this goes wrong?
Spring Boot 2.5.0 is used. Without using the Optional, everything works fine.
Application.java
#SpringBootApplication
#Configuration
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class);
}
#Bean
public Optional<SomeClass> someClass() {
System.out.println("creating bean");
return Optional.of(new SomeClass("someName"));
}
}
SomeClass.java
#Value
public class SomeClass {
String name;
}
SomeService.java
#Service
public class SomeService {
public SomeService(Optional<SomeClass> some) {
System.out.println(
some.map(SomeClass::getName).orElse("empty")
);
}
}
Output:
empty
creating bean
When autowiring dependencies the Optional should be used at the injection point, to indicate that a bean might or might not be available. The bean cannot be available for different reasons (conditional configuration, or just a setup error leading to null for a bean).
Creating an Optional bean is something different then using Optional for the injection point.
Ideally, you would just create the bean, which would be created eagerly, if processing can fail, handle it and return null. Now when using Optional at the injection point it will see null and Optional.empty() will automatically be injected.
As far as I understood, Spring manages autowiring mechanism with AutowiredAnnotationBeanPostProcessor on postProcessBeforeInitialization stage. But how does it inject proxies that ought to be created on postProcessAfterInitialization stage?
EDIT 1
Suppose I have this Spring configuration
#Service
class RegularBean {
// injected on postProcessBeforeInitialization stage
#Autowired
private TransactionBean tBean;
// invoked in between of postProcessBeforeInitialization and postProcessAfterInitialization
#PostConstruct
void init() {
tBean.transactionMethod();
}
}
#Service
class TransactionBean {
// transactional proxy is created on postProcessAfterInitialization stage
#Transactional
public void transactionMethod() { ... }
}
Transactional proxy is created on postProcessAfterInitialization stage. But #PostConstruct is called right before it. Is injected tBean wrapped with transactional proxy? If it so, then why? Because it should not be. If it is not wrapped, then how transactions are going to be handled in the future?
Suppose that I replace field-injection with constructor-injection. Will it change the behavior somehow?
When you use autowiring on method or field ,Spring Container not always create and inject the required field/attribute instance. Spring internally create smart proxies and inject the proxies to your bean. This smart proxy will resolve the bean at later point and delegate call to actual bean during method invocation. This is a common strategy we use to resolve request and session scoped beans to singleton instance (Say service layer beans) using Scope annotation.
Adding small snippet to show Spring internally create proxies for Object. Consider a classic circular dependency case when we use Constructor injection.
#Component
public class CircularDependencyA {
private CircularDependencyB circB;
public CircularDependencyA(#Lazy CircularDependencyB circB) {
System.out.println("CircularDependencyA Ctr ->"+circB.getClass().getName());
this.circB = circB;
}
}
#Component
public class CircularDependencyB {
private CircularDependencyA circA;
public CircularDependencyB(CircularDependencyA circA) {
System.out.println("CircularDependencyB Ctr ->"+circA.getClass().getName());
this.circA = circA;
}
}
#Configuration
#ComponentScan(basePackages = { "com.example.springdemo.cd" })
public class TestConfig {
}
public class TestCircularDependency {
public static void main(String[] args) {
try(AnnotationConfigApplicationContext context
= new AnnotationConfigApplicationContext(TestConfig.class);){
}
}
}
Based on our hints Spring is creating Proxy(using CGLIB) for CircularDependencyB Object and see the op from the CircularDependencyA Constructor
CircularDependencyA Ctr ->com.example.springdemo.cd.CircularDependencyB$$EnhancerBySpringCGLIB$$e6be3b79
Thanks
I have a instance of a class that is created outside of Spring that I'd like to have access to Spring beans so that it may fire an event and be observed by Spring beans. I'm not using Spring web, my application is running from the command-line via spring boot.
The only option you have is to expose the Spring context of your application using a static method so that the object that is not managed by Spring can use it to get references to managed beans it needs.
Start with a wrapper for the context. Create a regular managed bean which required reference to the context in its constructor. The reference is assigned to a static class field, which also has a static getter:
#Service
class ContextWrapper {
private static ApplicationContext context;
#Autowired
public ContextWrapper(ApplicationContext ac) {
context = ac;
}
public static ApplicationContext getContext() {
return context;
}
}
Use the static getter to get access to context in the object which is not managed by Spring and get reference to beans using methods available in the context:
SomeBean bean = ContextWrapper.getContext().getBean("someBean", SomeBean.class);
// do something with the bean
Last thing you need is communication channel from Spring beans to non-managed object. For instance, the SomeBean can expose a setter which will accept the non-managed object as a parameter and store the reference in a field for future use. The object mast get references to managed beans using the static context accessor mentioned above and use the setter to make the bean aware of its existence.
#Service
class SomeBean {
// ... your bean stuff
private SomeClass someclass;
public void setSomeClass(Someclass someclass) {
this.someclass = someclass;
}
private void sendEventToSomeClass() {
// communicate with the object not managed by Spring
if (someClass == null) return;
someClass.sendEvent();
}
}
You can inject by constructor that spring beans, something like:
#Service
class Bean {
...
}
class NotBean {
private Bean bean;
public NotBean(Bean bean) {
this.bean = bean;
}
// your stuff (handle events, etc...)
}
I have the following components, in two different files:
#Component
public class Chauffeur {
Car car;
public Chauffeur(Car car){
this.car = car;
}
public void go(){
System.out.println("Chauffeur");
car.drive();
}
}
#Component
public class Car{
public void drive() {
System.out.println("Drive car");
}
}
the following configuration file:
#Configuration
#ComponentScan
public class DriveableConfiguration {
}
and the following test:
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(classes=DriveableConfiguration.class)
public class DriveableTest {
#Autowired
Chauffeur chauffeur;
#Test
public void chauffeurTest(){
chauffeur.go();
}
}
All the classes above are in the same package and the test is passing.
In the test I annotated chauffer with #Autowired, which should mean that the Spring container looks after the creation of the instance of Chauffeur without the developer needing to explicitly instantiate it.
Now, the constructor for Chauffer needs an instance of Car, so there is no default constructor for that class. Nonetheless the container creates it, injecting the required instance in the constructor.
Is the #Autowired saying to the container to instantiate the element with whatever (Components, Beans) it can provide, included parameters in the constructor? If so, in what case is it needed to use #Autowired to annotate a constructor?
Only if you use Spring 4.3+. In such a case #Autowired on constructor is optional if you have one non default constructor.
You can check the example here.
So as of 4.3, you no longer need to specify an explicit injection annotation in such a single-constructor scenario. This is particularly elegant for classes which otherwise do not carry any container annotations at all, for example when programmatically registered
For versions lower than 4.3 you will an exception will be thrown:
the container will throw an exception looking for a default
constructor, unless you explicitly indicate autowire mode
‘constructor’ in your bean definition setup (e.g. in an XML )
I can't figure out how to get spring to autowire dependencies in a sub resource. I need to specify some request state to the sub resource. I'll also need access to cxf managed #Contexts.
If I have a class
#Path("/resource/")
public class Resource {
#Autowired
private dependency
#Path("{id}/sub/")
public getSub(#PathParam("id") String id){
// I know this is not right. I could autowire subresource, but it needs
// to be request scoped and I get errors about proxying request scoped bean
// into singleton bean.
// I have also tried instantiating the subresource using ResourceContext
// but then Subresource's dependencies don't get injected
return new Subresource(id);
}
}
And another class
public class Subresource{
#Context
private UriInfo uriInfo;
#Autowired
private Dependency2 dependency2;
private String id;
public Subresource(String id){
}
#GET
public Response get(){
return Response.ok(id).build();
}
}
How do I get the spring managed dependencies to be auto injected in the sub resources? How does the sub resource get access to CXF managed dependencies?
I create factory bean to instantiate sub-resource:
public class SubResourceFactory {
#Autowired
private AutowireCapableBeanFactory autowireBeanFactory;
public SubResource createBean(String parameter1, Parameter2 parameter2) {
... creating SubResource instance, setting parameters to it
autowireBeanFactory.autowireBean(subResource);
return (SubResource) autowireBeanFactory.initializeBean(subResource, "subResource");
}
}
AutowireCapableBeanFactory allows to init bean created outside of Spring Context and inject any Spring beans to it.
SubResourceFactory is instantiated as Spring singleton bean in my project and injected in Root Resource, so i can use it like this:
#Resource
private SubResourceFactory subResourceFactory;
#Override
public SubResource getInfoFromSubResource(String parameter1) {
Parameter2 parameter2 = parameter2StoreService.getParameter2(parameter1);
return subResourceFactory.createBean(parameter1, parameter2);
}
But this subResource is managed only by Spring, so You can inject only Spring beans, You can not inject CXF-RS #Context beans.
There must be a way to do same thing to allow Spring and CXF-RS injections with ResourceContext, but I can see now, that it injects only CXF-RS beans, no Spring at all.