Hi Tim,
It could be a partial answer to your questions, but here's the way I see things on the Gap between EE/Osgi world: The post you mentioned is related to an old Karaf version: Karaf 3.0.x works fine with CDI, you could see it running with my CXFRS-CDI portable extensions, Validation (JSR-303), ConfigAdmin, Camel ones... Just download my project and make a magic mvn clean install on it :). I hope Pax-CDI will raise and become a standard as blueprint is. It may be not as modularizable as blueprint, but I think it's just a dev manpower effort (I just know that Harald Weldmann contribute on it, but hope some folks will pursue the effort, maybe myself too). Concerning the @Transactional annotation, I didn't succeed to make the deltaspike work in OSGI, but think I'm just too young and inexperimented for it (I'm a 5 years old JEE folk, but just a one year old out of work night coder on OSGI/Karaf), and I see some good moves concerning Aries Community (Java 8 support, many mails on tests migrations and a kind of motivation to make things better and better...). Also Pax-CDI/Jpa/Data issue could make things move on (take a closer look at https://ops4j1.jira.com/browse/PAXCDI-89 to see progress). Concerning my use Spring-sec in my framework (for more details: https://github.com/OsgiliathEnterprise/net.osgiliath.parent/blob/master/net.osgiliath.framework/net.osgiliath.features.karaf-features/net.osgiliath.features.karaf-features.itests/net.osgiliath.features.karaf-features.itests.security ), I don't use any spring annotations, just the underlying sec stuff with xml injection: userdetails, roles, etc... But if you really want annotations, you can easily make a CDI portable extension to handle it and make a deltaspike, Pax, SMX (or even Osgiliath ? :O) contribution: we're all opened, and we will all reverse back to each communities depending on the case, it could even be possible to have the both of the two worlds available out of the box (I tried Gemini-blueprint that perfectly handled spring namespaces and annotations, and an aries bridge is always possible/maybe affordable with little hacks). For example, a typical CDI extension have just to listen OSGI service spawn (i.e. spring userdetailsservice implementation via a servicetracker), and intercept bean calls that are typed by annotations (@PreAuthorize?) to throw an exception (UnAuthorizedException) if any, or let the client call the method. Finally, as an OSGI evangelist, I personally think that you're on the good way: don't be afraid of embracing OSGI (and particularly Karaf) because some unresolved EE issues will be solved the OSGI nice way of easily resolving complex issues. I made the same path to go here, starting J2E, moving to Spring (that I liked very much, that pushed me to the dynamic world) then discovering OSGI, with a lot of apprehension, but with a stronger benefit that makes me advocating for this kind of solution comparing with others (JEE, Spring). I can make a non exhaustive list of thinks OSGI is able to solve that JEE/Spring stack will never have: * Hot swap of implementations (feature:install myapp is just a real pleasure). * Semantic versioning (your users will know when they have to change their call to your API). * Hot deployement (no need to stop your server) * ESB/EIP/BUS... (far more easy than stopping your server to redeploy your business module access), and provided by Karaf without any effort you'll do with JBoss. * Application rationalization (no more wars, ears, just jars and manifests). * Scalability (take a look at hazecast, karaf cave... and you'll see that you're already on the cloud). * A responsive community: we're not as many as the JEE ones, but much more responsive and listening for feedback/enhancement. Best Regards, 2014-05-21 22:40 GMT+02:00 Tim Jones <[email protected]>: > Thanks Charlie, I wasn't aware of the deltaspike-jpa @Transactional > annotation. Though I am a bit concerned reading posts such as > https://groups.google.com/forum/#!topic/ops4j/-yNNwvz5yNY that it is > still a > bit early to adopt as an alternative. > > I don't see how you can continue using spring-security with the Blueprint > beans wiring mechanism as I thought it would require a Spring application > context e.g. for a method annotated with @PreAuthorize would this not > require a Spring application context to work? > > So given that 'Blueprint does not aim to replace the entire Spring > framework, only the bean wiring stuff' then what is the migration path for > a > Spring dependent application post Spring 3 as Spring-dm out of the box only > supports [2.5.6,4)? > > > > > > > > -- > View this message in context: > http://karaf.922171.n3.nabble.com/OSGI-and-Spring-tp4033211p4033227.html > Sent from the Karaf - User mailing list archive at Nabble.com. > -- Charlie Mordant Full OSGI/EE stack made with Karaf: https://github.com/OsgiliathEnterprise/net.osgiliath.parent
