Nice one Charlie, with the next version of Pax Web it'll be also possible to use the Websocket JSR-356 annotations without a single Servlet. Just make sure you have the right Web-ContextPath manifest header in your application. For anyone interested give the latest Pax Web 4.1 a try together with the websocket sample of Pax Web [1]. FYI I also did a summary of what's next at [2]
regards, Achim [1] - https://github.com/ops4j/org.ops4j.pax.web/tree/master/samples/websocket-jsr356 [2] - http://notizblog.nierbeck.de/2014/12/pax-web-4-1-whats-next/ 2014-12-05 9:35 GMT+01:00 Charlie Mordant <[email protected]>: > As an addition to Christian, > I also made a full stack sample with CDI and an other for blueprint: > https://github.com/OsgiliathEnterprise/net.osgiliath.parent/tree/master/net.osgiliath.samples > It manipulates REST, JPA, JTA, JMS, Websocket. > > I also made a little CDI bridge for CXF that let's you expose REST > webservices with an @CXFEndpoint annotation. > > > > 2014-12-05 9:26 GMT+01:00 Christian Schneider <[email protected]>: > >> The problem is that we do not yet have some clear winners in the OSGi >> space of enterprise frameworks. >> Each of the current approaches has some advantages and shortcomings. >> >> Dependency injection: >> >> For DI the most mature for enterprise is currently blueprint. The major >> deciding factor there is that it supports jpa and jta which is needed in >> almost any enterprise application. Blueprint also has good support for CXF >> (SOAP and REST) and Camel. I personally would prefer the CDI approach but >> it is not yet fully mature in OSGi. >> >> Achim did a nice example that shows how to use CDI on karaf >> See https://github.com/ANierbeck/karaf-enterprise-sample >> The only downside is that he had to use blueprint for the jpa part but >> that just reflects the state of CDI support. >> >> I am also working on an enterprise example here: >> https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-cdi >> >> It also uses CDI annotations in the java code. I use a aries maven plugin >> to generate blueprint from the annotations. So as a developer you can work >> a lot like in CDI but have the stable blueprint below. The downside here is >> that the maven plugin only supports a very small subset of CDI. Still you >> can already do a lot with it. >> >> So maybe the ideal way here would be to combine the two approaches. Use >> CDI annotations for all layers. Use the maven plugin for the persistence >> layer and mayebe also for rest services (backed by blueprint) and real CDI >> for the other layers. >> >> Security: >> >> For security I would go for plain JAAS for the most part. There is a JAAS >> Feature in CXF that allows a really simple way to enable basic auth in CXF >> services. It establishes a JAAS security context. Then there is the >> blueprint authz extension that allows to use JEE security annotations like >> @RolesAllowed in your business code. Unfortunately there is not much >> documentation about it. I will have to write some reference and examples >> for it. >> In any case my advice for security is to just use JAAS and rather avoid >> the bigger frameworks. They all kind of tie you to their own APIs. >> >> Rest: >> For REST services CXF is the natural choice as it is very well supported >> in karaf. Unfortunately there is no CDI integration available but there is >> good support for blueprint. >> >> Christian >> >> >> >> On 05.12.2014 08:26, Kim Hansen wrote: >> >> Hi! >> >> I'm fairly new to Karaf and it would be really awesome if someone really >> deep into Karaf and/or OSGi could suggest what frameworks and APIs to use >> with Karaf 4 to create applications with the following technologies (and >> not use Spring at all): >> >> - Dependency Injection (Blueprint or J2EE) >> - Security (LDAP, Shiro, OAuth, OpenID, ...) >> - REST (Jetty, Geronimo, ...) >> - ... >> Den 05/12/2014 00.11 skrev "Jean-Baptiste Onofré" <[email protected]>: >> >>> Hi, >>> >>> Spring clearly announced that they don't support OSGi anymore. >>> >>> Even if Spring is supported by Karaf (which is a good point to support >>> non OSGi applications using Spring), I would not recommend to start a >>> project using Spring. >>> Starting with native OSGi stuff is better (like Blueprint which is >>> actually close to Spring, SCR/DS, etc). >>> >>> Regards >>> JB >>> >> >> -- >> Christian Schneiderhttp://www.liquid-reality.de >> >> Open Source Architecthttp://www.talend.com >> >> > > > -- > Charlie Mordant > > Full OSGI/EE stack made with Karaf: > https://github.com/OsgiliathEnterprise/net.osgiliath.parent > -- Apache Member Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> Software Architect / Project Manager / Scrum Master
