Develop Reference

Wiring CDI beans and business logic

I am building a JSF (2.2.13) application wired with CDI 2.0 (Weld 3.0.4).
The app contains some real beans (frontend) and some business logic (backend).
Now the question is up to what part of the application CDI should be used?
Obviously the frontend beans shall be managed by CDI
My first guess was to inject the backend services (somehow wrapping them in an #ApplicationScoped scope) to those CDI-managed frontend beans
The backend then would be good old plain Java
I am a little bothered to use CDI in some parts of the application in in some not...

Can you use scoped proxies with Spring Boot 2 #ConfigurationProperties?

Using Spring Boot 1.5.12, we create scoped proxies for #ConfigurationProperties beans. We do this so that we can effectively have property values that are scoped to the user/session/etc. We use a BeanFactoryPostProcessor to register a scoped proxy created by ScopedProxyUtils.createScopedProxy and change the scope of the target bean definition to our custom scope.
This worked great in Spring Boot 1.5.12. However, in Spring Boot 2, the introduction of the Binder API has made this stop working. This is because when Spring Boot binds #ConfigurationProperties in its ConfigurationPropertiesBindingPostProcessor, it uses Bindable.of(type).withExistingValue(bean) passing in a type (e.g. org.example.Foo) and the bean which is an instance of ScopedProxyFactoryBean. Bindable checks that bean is an instance of type which it's not and things blow up.
Does anyone know of a general way to accomplish this? Specifically, to replace the #ConfigurationProperties bean definition with a proxy while still allowing the properties to bind to the instance? I've considered delaying the creation of the proxy until after the target has already been bound by ConfigurationPropertiesBindingPostProcessor (i.e. in my own BeanPostProcessor). However, at this point the bean is instantiated and my proxy can only replace the bean. It can't really leave the original bean in the context as a target. So I'm struggling with how to do this using a BeanPostProcessor.
EDIT: I've created a simple example project that demonstrates the issue (with the ability to check out code that works on Spring Boot 1 and fails on Spring Boot 2).

How to force Spring proxy generation for annotated #Transactional methods

I use multiple TransactionManagers with #Transactional("txXyz") annotations. It works well in beans annotated with #Component and created during Spring startup. I have another type of beans that I create later in runtime via
applicationContext.getAutowireCapableBeanFactory().createBean(beanClassName)
The latter approach successfully injects #Autowired resources and calls all interface hooks (e.g. InitializingBean). However it doesn't create transactional proxies for annotated methods. I have been looking around but haven't found an obvious way to force transactional proxi generation on createBean. My question is there a "legal" way to force transactional proxy processing for beans created when application is already running?

How to access CDI managed bean from JAX-RS MessageBodyWriter?

I'm struggling with accessing CDI managed beans from a JAX-RS message body handler in TomEE.
My handler class (implements MessageBodyWriter<Object>, MessageBodyReader<Object>) is registered via the cxf.jaxrs.providers property in openejb-jar.xml. When I use the #Inject annotation on the constructor, the handler is silently ignored (because it then lacks a no-arg constructor). When using field injection instead, the field stays empty. Obviously, message body handlers are entirely unmanaged in TomEE (CXF).
I tried getting the BeanManager via JNDI, but that fails without logging an exception.
Is there any other way to do this, or am I doing something wrong? Alternatively, I would of course appreciate a way to make the handler itself managed, and register it programmatically somehow.

Injection should work just fine in versions of CXF >= 2.7. Prior versions utilize JAX-RS 1.x, which is not tightly integrated with CDI. In particular, JAX-RS 1.x providers, even in the presence of a CDI container, are managed by the JAX-RS runtime (not the CDI one), and only support the following injection annotations:
#Resource
#Resources
#EJB
#EJBs
#WebServiceRef
#WebServiceRefs
#PersistenceContext
#PersistenceContexts
#PersistenceUnit
#PersistenceUnits
References:
JAX-RS 1.0 specification, Section 6.2
JAX-RS 2.0 specification, Section 10.2.3
Apache CXF - Migrating from JAX-RS 1.1 to 2.0

What is the equivalent of an EJB 3.0 Session Bean in Spring?

Is it as simple as creating a POJO with #Transactional methods?

Yes, spring beans are pojos. You have to declare it in applicationCotnext.xml or annotate it with #Service.

In Spring you create it as normal bean and you specify session scope or #Scope annotation.

Spring beans (i.e. properly declared) annotated with #Transactional are comparable to Local Session Beans. For Remote Session Beans, you would have to add some remoting to your Spring configuration (RMI, Web Services, Hessian, Burlap, HTTP invokers). But Spring remoting does not support out of the box security and transaction propagation (unlike EJBs).