Standalone Configuration and CDI Implementation

[aaccioly]

As requested by the @nurkiewicz I'm opening a new Issue (Enchantment Request) for standalone and CDI Implementations and Documentation (Link to original discussion).

Original request content:

Hello @nurkiewicz . Thanks for the wonderful software. Could you please write some instructions about how to run it outside of the spring container? Maybe a Standalone usage example or CDI Integration sections like in Spring Data JPA Documentation.

I would like to write a CDI Producer for repositories and and consume it in EJBs (using standard Java EE Declarative Transactions. Is it possible?

[aaccioly]

Hi @nurkiewicz, any progress on this?

I'm currently tackling the integration with a bridge layer (that wires Spring Beans and Produces CDI beans):

@SuppressWarnings("SpringJavaAutowiredMembersInspection")
@Singleton(name = "SpringBridgeEJB")
@Interceptors(SpringBeanAutowiringInterceptor.class)
@Lock(LockType.READ)
public class SpringBridgeBeanImpl implements SpringBridgeBean {

     @Autowired
     private MyRepository myRepository;

     @Autowired
     private MyOtherRepository myOtherRepository;

    @Override
    @Produces
    @SpringRepository
    public ServerRepository getMyRepository() {
        return myRepository;
    }

    @Override
    @Produces
    @SpringRepository
    public ServerRepository getMyOtherRepository() {
        return myOtherRepository;
    }
}

But I would love to ditch the boilerplate code and the Spring Container altogether. If we could simple inject a DataSource in a similar fashion that Spring Data JPA users injects EntityManagers it would be heaven. No more Spring, no more having to handle different DI scopes (I would just annotate my repository with one of CDI scopes and let it inject the DataSource), no more spring managed transactions (hello @Transactional CDIs), pure bliss.

[aaccioly]

One more thing, it would be nice to have public constructors / setters so that people could use and mutate DataSources in a DI independent fashion. As it stands we have to use the setJdbcOperations method with a new JdbcTemplate wrapping the desired DataSource. It would be nice if the JdbcRepository implementation exposes some convenience setDataSource and getDataSource methods.

[nurkiewicz]

@aaccioly Apologies for leaving this task open for so long, I will look into this and document Spring-less configuration in the nearest days.

[nurkiewicz]

Check out StandaloneUsageTest.java. It shows how to setup JDBC repository without Spring context. Unfortunately I couldn't test it with external transaction manager, so I am also manually using TransactionTemplate from Spring.

The only change I made was adding setDataSource() convenience method. Please upgrade to 0.4.1. I don't think this solves your problem entirely, so feel free to drop a line in this ticket, which I am not closing for now.

[aaccioly]

Thanks @nurkiewicz! I will download the new version and test it tomorrow. As for my Christmas Wishes, I would love to use your project without relying on the Spring Container at all. Something like Spring Data JPA CDI Support in which I (or rater the container) would make a DataSource available and your implementation would wire everything out together without bootstrapping Spring. Being able to @Inject repositories would also be nice. As I understand it, this means making your implementation compatible with CDI. While I don't know much about how to write good library code, I guess that the following steps could work:

• Replacing @Autowired and spring proprietary configuration with @Inject (which is also supported by Spring)
• Assuring that JdbcRepository plays nice with CDI @Transactional support
• Exposing your beans to the CDI container
• Writing the glue layer that tries to wire everything out with CDI before resorting to Spring beanFactory.

Finally, testing with a Java EE App Sever (or a CDI Enabled container) and checking if your library works without bootstrapping Spring if there is a DataSource registered with the container.

[nurkiewicz]

@aaccioly Sorry, I have no experience with CDI so I cannot proceed with further CDI integration. However if you feel like this library needs some improvements to play nice with CDI, I offer my help.

[aaccioly]

@nurkiewicz, no problem. I wish I could do better than ask for it (I will try and fork your library, but I'm not all that familiar with Spring intricacies either). The 4 points mentioned above would be enough to get your library rolling with CDI and most application servers (easier said that done, I know).