It doesn't and is not related actually if you expose ejbd endpoints/any not configured RMI endpoint. Point was more RMI will imply a verbose configuration you will likely not like or want to maintain (whitelist) vs JAX-RS.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-05-30 18:36 GMT+02:00 Trenton D. Adams <[email protected]>: > Wouldn't SELinux take care of the serialization exploit? I mean exploits > come along all the time, which is why SELinux should be in use; assuming > the use of Linux. > > On Mon, May 30, 2016 at 2:47 AM, Romain Manni-Bucau <[email protected] > > > wrote: > > > you can also see the 0-day vulnerability as another step requiring > > configuration with RMI and not with JAX-RS/JSON default usage. Also > another > > thing to justify if you get an audit ;) > > > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <http://rmannibucau.wordpress.com> | Github < > > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber > > <http://www.tomitribe.com> | JavaEE Factory > > <https://javaeefactory-rmannibucau.rhcloud.com> > > > > 2016-05-30 10:14 GMT+02:00 Trenton D. Adams <[email protected]>: > > > > > Also, another aspect to all of this, is that we have a moderately sized > > > application, which uses RMI for the business logic. Converting that to > > > @Stateful EJB, would be a breeze, and we could really be confident it > > would > > > continue working once we've gone through our testing cycle. I'm > guessing > > > that converting it to JAX-RS, could be very painful, error prone, and > > > consume a lot of develop, test, fix, test, fix, test, fix, before we > > could > > > even go live. Essentially, @Stateful EJB can literally have no code > > > changes to the RMI code, except annotations, and it would work almost > > > identically, except the authentication part of it. > > > > > > Also, OpenEJB certainly adds some nice multicast distributed server > > > capabilities. > > > > > > On Mon, May 30, 2016 at 2:02 AM, Trenton D. Adams < > > > [email protected] > > > > wrote: > > > > > > > That is very interesting. Apparently Jersey has a proxy client API > as > > > > well. > > > > > > > > There has to be some sort of state, even if it's as simple as > > maintaining > > > > that your user is authenticated. With this proxy client api, is it > > > > possible to have cookies automatically kept, and sent during each > > > request? > > > > > > > > On Mon, May 30, 2016 at 12:23 AM, Romain Manni-Bucau < > > > > [email protected]> wrote: > > > > > > > >> 2016-05-30 7:52 GMT+02:00 Trenton D. Adams < > [email protected] > > >: > > > >> > > > >> > On Sun, May 29, 2016 at 1:05 PM, Romain Manni-Bucau < > > > >> [email protected] > > > >> > > > > > >> > wrote: > > > >> > > > > >> > > Hello > > > >> > > > > > >> > > 2016-05-29 20:57 GMT+02:00 Trenton D. Adams < > > > >> [email protected]>: > > > >> > > > > > >> > > > Good day, > > > >> > > > > > > >> > > > I've had discussions with people that think JAX-RS should be > > used > > > >> as a > > > >> > > > replacement for technologies like EJB, for making n-tier > > > solutions. > > > >> > Some > > > >> > > > of my main concerns about that would be... > > > >> > > > > > > >> > > > - JAX-RS is mainly a structured approach to solving the > problem, > > > and > > > >> > does > > > >> > > > not use OOD very well. > > > >> > > > > > > >> > > > > > >> > > Assuming you don't mix local EJB and JAX-RS which are very > > different > > > >> and > > > >> > > that EJB means there remote EJB. > > > >> > > > > > >> > > Since it does serialize the payload it is 1-1 with EJB(d), you > > have > > > >> more > > > >> > or > > > >> > > less the exact same constraints there. Then you can use > different > > > >> format > > > >> > > over JAX-RS (JSON/XML obviously, but java serialization like > EJBd > > > too, > > > >> > and > > > >> > > more advanced formats too) > > > >> > > > > > >> > > > > >> > Yeah, I'm referring to remotable EJBs. > > > >> > > > > >> > > > > >> > > > > > >> > > > > > >> > > > - Having stateless remote calls is fine for certain types of > > data, > > > >> but > > > >> > > I've > > > >> > > > found stateful technologies remove a lot of boilerplate stuff. > > > >> > Combined > > > >> > > > with good OOD, the savings are even better. JAX-RS is > intended > > to > > > >> be > > > >> > > > stateless, so you'd be required to pass all of the state > > > >> information on > > > >> > > > each call. That requires a lot more thought, planning, and I > > > think > > > >> > it's > > > >> > > > more prone to development errors, etc. > > > >> > > > > > > >> > > > > > >> > > Nothing prevents you to have a stateful JAX-RS endpoint, you > just > > > >> need to > > > >> > > ensure your client maintains the session properly. > > > >> > > > > > >> > > > > >> > Yes, I know nothing prevents you, but the whole point of REST, is > > to > > > be > > > >> > stateless, is it not? > > > >> > > > > >> > > > > >> > > > > >> Well actually no. JAX-RS is just a nice API on top of HTTP/Servlet > > > layer. > > > >> Then you do what you want. Stateless architectures are super nice > for > > a > > > >> lot > > > >> of reasons > > > >> but it is not bound to JAX-RS or EJB where the recommanded practise > > can > > > be > > > >> to be stateless as well. > > > >> > > > >> > > > >> > > > > >> > > > > > >> > > > > > > >> > > > I know TomEE supports JAX-RS as well as EJB, JAX-WS, etc. > But, > > if > > > >> EJB > > > >> > is > > > >> > > > better for enterprise software, I'd like to be able to > > articulate > > > >> it. > > > >> > > Or, > > > >> > > > perhaps JAX-RS is best, and I'd like to be able to articulate > > > that. > > > >> > > > > > > >> > > > > > > >> > > Technically both (remote EJB and JAX-RS) are globally the same > in > > > >> term of > > > >> > > architecture. In term of ecosystem JAX-RS+JSON/XML is really > > bigger > > > >> and > > > >> > > more standard (you will find clients for all languages in 5mn, > not > > > for > > > >> > > EJBd). > > > >> > > > > > >> > > > > >> > I'm curious, how do you see EJB and JAX-RS as being the same > > > >> architecture? > > > >> > EJB has the capability of maintaining state, and obfuscates the > > remote > > > >> call > > > >> > entirely, while JAX-RS does not. As far as I've ever seen, it's > up > > to > > > >> you > > > >> > to develop the boilerplate code to make the call, even when you're > > > using > > > >> > JAX-RS 2 with the client api. I mean you could use something like > > > >> retrofit > > > >> > to make it sort of like EJB. > > > >> > > > > >> > > > > >> > > > >> Use CXF client factory then you will create a proxy from your JAX-RS > > > >> contract => you hide the JAX-RS calls behind an interface. It makes > it > > > >> more > > > >> or less the same as EJB excepted you replaced EJBException by > > > >> WebApplicationException: > > > >> > > > >> > > > > > > http://cxf.apache.org/docs/jax-rs-client-api.html#JAX-RSClientAPI-Proxy-basedAPI > > > >> > > > > > > > > > > > > > >
