We Keep Coding

Spring serializable proxy

I have spring session scoped bean. That bean is using application scoped beans, and there's and error when the container tries to serialize the session.
I remember that problem from JSF applications, and in one project, we've solved that using serializable proxies. The injected bean was the proxy wrapper which fetched the singleton instance from the application context. Unfortunately, I can't remember how exactly it was called and was it a build-in solution or some external thing.
How to wrap spring beans in serializable proxies? Does Spring provide such functionality? AFAIR there was some special annotation to mark the references that should be wrapped in such proxy.

The feature is called scoped proxy and can be triggered via annotation to the service, that will be injected to session scoped beans:
#Scope(proxyMode = ScopedProxyMode.INTERFACES)
More details in question:
Spring session-scoped beans (controllers) and references to services, in terms of serialization

JEE7: Do EJB and CDI beans support container-managed transactions?

Java EE7 consists of a bunch of "bean" definitions:
Managed Beans 1.0 (JSR-316 / JSR-250)
Dependency Injection for Java 1.0 (JSR-330)
CDI 1.1 (JSR-346)
JSF Managed Beans 2.2 (JSR-344)
EJB 3.2 (JSR-345)
In order to get rid of the chaos in my mind, I studies several articles of "when to use which bean type". One of the pros for EJB seems to be that they alone support declarative container-managed transactions (the famous transaction annotations). I'm not sure, though, if this is correct. Can anyone approve this?
Meanwhile, I came up with a simple demo application to check if this was actually true. I just defined a CDI bean (not an EJB - it has no class level annotations) as follows, based on this snippet:
public class CdiBean {
#Resource
TransactionSynchronizationRegistry tsr;
#Transactional(Transactional.TxType.REQUIRED)
public boolean isTransactional() {
return tsr.getTransactionStatus() == Status.STATUS_ACTIVE;
}
}
Now, the outcome on GlassFish 4.0 is that this method actually returns true, which, according to my inquiries, is not working as expected. I did expect the container to ignore the #Transactional annotation on a CDI bean method, or to even throw an exception. I use a freshly-installed GlassFish 4 server, so there are no interferences.
So my question is really:
Which bean types do actually support container-managed transactions?
Just for the sake of curiosity, how could I test it with a simple demo application if the code above is wrong?
(BTW: Someone described a similar problem here, but its solution does not apply to my case.

Until Java EE 7 only EJB was transactional and the #Transactional annotation didn't exist.
Since Java EE 7 and JTA 1.2 you can use transactional interceptor in CDI with #Transactional annotation.
To answer your question about the best type of bean to use, the answer is CDI by default.
CDI beans are lighter than EJB and support a lot of feature (including being an EJB) and is activated by default (when you add beans.xml file to your app).
Since Java EE 6 #Inject supersede #EJB. Even if you use remote EJBs (feature not existing in CDI) the best practice suggest that you #EJB once to inject remote EJB and a CDI producer to expose it as a CDI bean
public class Resources {
#EJB
#Produces
MyRemoteEJB ejb;
}
The same is suggested for Java EE resources
public class Resources2 {
#PersistenceContext
#Produces
EntityManager em;
}
These producers will be used later
public class MyBean {
#Inject
MyRemoteEJB bean;
#Inject
EntityManager em;
}
EJB continue to make sense for certain services they include like JMS or Asynchronous treatment, but you'll use them as CDI bean.

The javadoc of Transactional says:
The javax.transaction.Transactional annotation provides the application the ability to declaratively control transaction boundaries on CDI managed beans, as well as classes defined as managed beans by the Java EE specification, at both the class and method level where method level annotations override those at the class level.
So, your assumptions are wrong. EJBs, until Java EE 6, were the only kinds of components to support declarative transactions. The Transactional annotation has precisely been introduced in Java EE 7 to make non-EJB, managed CDI beans transactional.

JBoss bean validation needs to call an EJB

I am writing bean validation on my persistence model. I need to call my EJB Bean in order to retrieve some configuration parammeter from DB. How can I achieve this?
I tried to mark my EntityValidator as #Stateless and #LocalBean, but JBoss is still treats my EntityValidator as POJO. Can I do something about it? Alternatively, how can I retrieve EJB from POJO.

As of Bean Validation 1.0, you can't get EJBs injected into validators out of the box. This will change with Bean Validation 1.1, though.
Currently you have the following possibilities:
Retrieve the EJB via JNDI: MyEjb myEjb = InitialContext.doLookup(myEjbName);
Implement a custom ConstraintValidatorFactory which injects EJB references into created validator objects
Use Seam Validation, which enables dependency injection for validator objects using #Inject (disclaimer: I'm the author of Seam Validation)
With Bean 1.1 this will be possible out of box.

Currently, injection is not working in validators.
I've read that there are plans for future extension of bean validaton to enable exactly that behaviour.
However, there should be extension like seam or deltaspike, which could enabled you to provide injection.
Check this:
injection in validators

I don't think jboss will inject your bean to the JPA validator.
You can use JDNI to lookup your EJB for POJO.

Inject Spring beans into RestEasy

Is it possible to inject Spring beans into an RestEasy #Path class? I managed to do it with Jersey, with #InjectParam annotation, but for some other reasons, I need to switch to RestEasy, and I can't seem to find a way to do it (tried good ol' javax.inject.Inject, but nothing).
EDIT
This solution works:
http://www.mkyong.com/webservices/jax-rs/resteasy-spring-integration-example/
but it's not injection.. I'd still prefer something a little more elegant.

Simply annotate your RestEasy class with Spring's #Component and then inject your beans using Spring's #Autowired. Don't forget to include the annotation-config and component-scan elements in your spring configuration.

There is a working example that integrates RestEasy with Spring just try spring-resteasy.

You could use the #Configurable annotation to make a normal class (created by new) a spring Bean.
Then you can use the normal Spring annotation to inject everything in that class/instance like in a "normal" Spring Bean.
But that requires AspectJ!
#See Spring Reference Chapter 7.8.1 Using AspectJ to dependency inject domain objects with Spring

I totally agree with Peter's answer but there is another way to do it: you make all your exposition beans (RESTEasy or JAX-WS, which are not Spring components) extending the SpringBeanAutowiringSupport.
That way you can easily inject your Spring Services by #Autowired annotation in these classes.

Something like EJB wiring in Spring for non EJB's

I've noticed recently that spring can wire up my ejb's for me if I annotate the ejb with #Interceptors(SpringBeanAutowiringInterceptor.class). I've never actually done this so don't know the details.
I was wondering, is there a way to get this to work with other kinds of beans, for example, #WebService annotated ones as well.
At the moment in my web service classes (because the application server manages them) I have to load the dependencies from the BeanFactory and would thus prefer to have them autowired.
I know I could use the #Configurable annotation but am not particularly keen to have to specify and agent on the VM.
Is this possible?

Once again, spring has thought of this use case and catered for it!
The problem is that #WebService is not a spring annotation, it is a JAX-WS annotation and thus classes that are annotated with #WebService to be exposed as web services are not managed by spring, but their life cycle is managed by JAX-WS.
The way to handle this case is to have the JAX-WS managed bean extend org.springframework.web.context.support.SpringBeanAutowiringSupport - this will enable the #Autowire annotation, for example, to work in this bean. see here for more information

Yes, of course. There's #WebService, #Repository, #Controller, #Service, #Endpoint, and other annotations in Spring. Here's an example.