Thanks for the background David, that's much appreciated. I agree about the webapp. Our last CVE was due to an XSS issue in that webapp - I'd be inclined to remove it as well. Our Arquillian test suite tests all the distros *and* has a couple of phases doing an install with the webapp, so losing the webapp could shorten the build a bit too.
Back on the CMP changes, my Arquillian test is now working, and I'm quite happy with the change itself. If there's no objections, I'll merge this in tomorrow. I'll do some documentation and check some more stuff out with this functionality after that merge. Thanks Jon On Wed, Dec 5, 2018 at 1:09 AM David Blevins <[email protected]> wrote: > > On Dec 4, 2018, at 4:08 PM, Jonathan Gallimore < > [email protected]> wrote: > > > > I don't know that we have stuff that is deprecated pending removal at the > > moment. In terms of removing the CMP/BMP stuff... well, people are using > > it, which is why I'm working on it :-). I would be ok with marking it as > > deprecated, as long as we print out an explicit warning if your > application > > is using it, so you know to migrate. In terms of the gain... I don't > know. > > There'd be less code, but I suspect still the same dependencies, so we'd > be > > removing a small part of openejb-core effectively. I think its a good > > discussion, but I'd prefer to see graceful deprecation with clear > warnings > > before removal. > > Contextual information on the CMP implementation. We actually had a > separate CMP implementation in OpenEJB 2.0 that was working and passed the > TCK and used to certify Geronimo for J2EE 1.5. > > When JPA was added in EJB 3.0 / Java EE 5, we made a deliberate decision > to throw out all of that code and write a new CMP implementation in OpenEJB > 3.0 on top of JPA to protect ourselves in the future from the inevitable > cost of CMP legacy. What we have is actually a very thin layer on top of > JPA, which I think provides people more value than cost. > > If someone is still stuck on CMP, our implementation is the best in the > industry in terms of helping you migrate to JPA, because it *is* JPA and > you can freely mix the two and even have them backed by the same > persistence unit. > > There is no code in TomEE/OpenEJB that implements Corba or JAX-RPC. All > the Corba and ORB related code stayed in Geronimo as we didn't want it > OpenEJB 3.0 because even for 2006 it would have been instant legacy. Same > with JAX-RPC which would have brought in at least 10BM in dependencies. > > If we hadn't completely rewritten OpenEJB between 2 and 3 I suspect we > would have good candidates for the chopping block. > > One thing I think is a great candidate for the chopping block is the > "tomee-webapp" used to bootstrap our Tomcat integration for people who do > not have the ability to just use an already built TomEE dis. I don't think > it ever took off. I'm not aware of anyone using it. Removing it would > allow us to drop binaries from our release process. We could optimize our > Tomcat integration because there are quirky things we do only for the > benefit of that unused webapp. > > Rather than use that quirky webapp, we could simply build our TomEE > distros using the TomEE Maven Plugin. It's there to help others build > their own TomEE distros, but we don't use it only because of the > tomee-webapp legacy. We chose to use the tomee-webapp to "eat our own > dogfood", but we should probably switch the dog food to the TomEE Maven > Plugin. > > > -David > > >
