Ok, putting aside the name - just wanted to keep the old one to not break that usage which is still numerous due to openejb 3 upgrades, and not speaking of our codebase.
- The factory is complicated - reflection - probably due to old support (maybe OSGi) or very legacy stuff which is useless today so we can get rid of it - The factory contains init logic we should get rid of for a context factory (separation of concerns + leads to the fact to put in the factory logic related to boot which is no more accurate) - The context has this global security config which shouldn't be used at runtime but is used in tests and embedded scenarii (legacy) - The context has all this boot/shutdown logic of the container - The context has this "inject" and @LocalClient hacks which is today no more accurate thanks to CDI - The OpenEJBInitialContextFactory supports local EJB but also resources lookup which is the main valid usage today of specifying explicitly a local factory (unmanaged/controlled environment + lookup of resources: typically JPA provider DataSource lookup) Happy to move the old factory in openejb-core-legacy (same fqn) and release it once and remove it after, just as a compatibility module. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress 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-10-24 1:23 GMT+02:00 David Blevins <david.blev...@gmail.com>: > Let’s discuss this one a bit. > > Aside from the ClientSecurity aspect, what’s wrong with this class? > > And to be clear I’m more in favor of deprecating specific functionality > rather than the name itself. Keeping things symmetrical with > RemoteInitialContextFactory and LocalInitialContextFactory is quite nice. > > The second thing is we tend to always copy code, leave the old code > broken, port some of the features and then we have 5 80% functional > versions of the same thing. So in the sake of learning a better way, I > think it’d be great to have a discussion on what it is we’re trying to fix > or deprecate. > > > -- > David Blevins > http://twitter.com/dblevins > http://www.tomitribe.com > >
