The problem with the single bundle approach is extension points. How do you handle letting people handle filters so they can customize authorization, or CORS settings? How do you let them have a custom way to inject session so that they can do something like have a shared session across services? Serialization is a huge one. OSGI seems to be going to the DTO objects but they are very limiting in my opinion and I personally like that different options allow for me to have different providers for gson, jackson, minimal json ... A big one for me is also threading. If each request gets it's own thread then what happens with long running processes that hit a database. I love the ease of rest and agree that J2E has a lot of standards but as projects grow I find myself having to customize many different aspects of how it works and like to have a framework that implements the standards. I currently use https://github.com/hstaudacher/osgi-jax-rs-connector like mentioned earlier but I am starting to do more with vertx and unfortunately finding myself moving away from the standards. The standards and especially JEE seem to be falling behind technology. OSGI has a jaxrs standard in the works https://github.com/osgi/design/blob/master/rfps/rfp-0173-JAX-RS-Services.pdf I would love to see a minimal implementation of it that is really extensible but I think there are tradeoffs that need to be made and having lots of options allows the user to choose which ones they find acceptable.
On Sat, Jul 2, 2016 at 11:41 AM, David Leangen <[email protected]> wrote: > > IMO, this is too fine grained. If I want to install “REST”, there should > ideally be a single bundle. > > Of course, I can imagine that there are people who want/need to work at > that level of granularity. They should have that option, but if I only want > “REST”, then this really complicates my system. :-( If every feature > worked that way, I could imagine pulling in many hundreds of bundles very > quickly. Even the "simplest” system would no longer be simple at the > component level. > > Has anybody considered shipping all this packaged as a single bundle? (And > has anybody questioned if all those dependencies are *really* necessary?) > > Just askin'. :-) > > > Cheers, > =David > > > > On Jul 2, 2016, at 9:58 PM, Christian Schneider <[email protected]> > wrote: > > I am also not sure if we really still need all the spec overrides in Java > 7 and 8. Maybe we can slim that down a bit. > > I am just working on CXF-DOSGi and the multibundle distro contains almost > 100 deps. A lot of these come from pax-web which includes a lot of stuff I > do not really need but it is installed by the lkaraf http feature. > > Christian > > > 2016-07-02 13:53 GMT+02:00 James Carman <[email protected]>: > >> >> >> On Sat, Jul 2, 2016 at 4:13 AM David Leangen <[email protected]> wrote: >> >>> >>> >>> Question: is there a more light-weight JAX-RS implementation out there? >>> I am not happy about how bloated CFX seems to be. I don’t like having to >>> pull in that long list of dependencies. For something as “simple” as REST, >>> it sure complicates my system. Bleh. >>> >>> >> This is the list of dependencies for the "cxf-jaxrs" feature version >> 3.1.6 in Karaf: >> >> feature "cxf-specs": >> >> mvn:org.apache.geronimo.specs/geronimo-osgi-registry/1.1 start-level=9 >> mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.activation-api-1.1/2.6.0 >> start-level=10 >> mvn:javax.annotation/javax.annotation-api/1.2 start-level=10 >> mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.stax-api-1.0/2.6.0 >> start-level=10 >> mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jaxb-api-2.2/2.6.0 >> start-level=10 >> mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jaxws-api-2.2/2.6.0 >> start-level=10 >> mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.saaj-api-1.3/2.6.0 >> start-level=10 >> mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jsr339-api-2.0.1/2.6.0 >> start-level=10 >> mvn:javax.mail/mail/1.4.4 start-level=10 >> mvn:org.codehaus.woodstox/stax2-api/3.1.4 start-level=20 >> mvn:org.codehaus.woodstox/woodstox-core-asl/4.4.1 start-level=20 >> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jaxb-impl/2.2.11_1 >> start-level=20 >> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jaxb-xjc/2.2.11_1 >> start-level=20 >> >> feature "cxf-core": >> >> mvn:org.apache.ws.xmlschema/xmlschema-core/2.2.1 start-level=30 >> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.xmlresolver/1.2_5 >> start-level=25 >> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.fastinfoset/1.2.13_1 >> start-level=30 >> mvn:org.apache.cxf/cxf-core/3.1.6 start-level=40 >> mvn:org.apache.cxf/cxf-rt-management/3.1.6 start-level=40 >> >> feature "cxf-http": >> >> mvn:org.apache.cxf/cxf-rt-transports-http/3.1.6 start-level=40 >> >> feature "cxf-jaxrs": >> >> mvn:org.codehaus.jettison/jettison/1.3.7 start-level=30 >> mvn:org.apache.cxf/cxf-rt-rs-extension-providers/3.1.6 start-level=40 >> mvn:org.apache.cxf/cxf-rt-rs-extension-search/3.1.6 start-level=40 >> mvn:org.apache.cxf/cxf-rt-rs-service-description/3.1.6 start-level=40 >> mvn:org.apache.cxf/cxf-rt-frontend-jaxrs/3.1.6 start-level=40 >> mvn:org.apache.cxf/cxf-rt-rs-client/3.1.6 start-level=40 >> >> Most of that is the "spec" stuff. I wouldn't really consider that too >> bloated. It's extremely easy to install using Karaf features: >> >> feature:repo-add cxf 3.1.6 >> feature:install cxf-jaxrs >> >> > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de> > > Open Source Architect > http://www.talend.com > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com> > > >
