Thank you Bruno, I created a PR to fix missing header On Mon, Dec 17, 2018 at 9:46 AM Otávio Gonçalves de Santana < osant...@tomitribe.com> wrote:
> Hello, I created the backport to version 7.0.x: > https://github.com/apache/tomee/pull/283 > > On Wed, Dec 5, 2018 at 4:21 PM Gurkan Erdogdu <cgerdo...@gmail.com> wrote: > >> For the ORB case, there are places where ORB class is imported >> (openejb-core and openejb-client). For java 11, this will probably not >> compile and needs to have some 3th party Jar. For CMP case, as you have >> already experienced, the codebase is very complicated and it is really old >> technology and has not been updated since years. Therefore, it is a good >> idea to declare it as --deprecated-- and remove it from the future 8.1.x >> or 9.0.x versions. >> Regards. >> Gurkan >> >> >> On Wed, Dec 5, 2018 at 8:33 PM Jonathan Gallimore < >> jonathan.gallim...@gmail.com> wrote: >> >> > 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 <david.blev...@gmail.com> >> > wrote: >> > >> > > > On Dec 4, 2018, at 4:08 PM, Jonathan Gallimore < >> > > jonathan.gallim...@gmail.com> 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 >> > > >> > > >> > > >> > >> >
