Pulled this from the archive... one of the ones that I didn't receive while unsubscribed.
Jacek Laskowski-4 wrote: > > Just run into it and wonder why LocalInitialContextFactory is in > openejb-core not openejb-client? Is there a reason for it? Will I > break anything if I moved the class to openejb-client? > http://sourceforge.net/tracker/index.php?func=detail&aid=619004&group_id=44351&atid=460291 Before that fix, we had these two factories user's had to use/remember: - org.openejb.core.ivm.naming.InitContextFactory - org.openejb.client.JNDIContext One should be used when the client is communicating with a locally embedded OpenEJB and one should be used when communicating with an OpenEJB in a remote vm, but from class names you can't really tell or easily remember which is which. So we created these to make it easier for people: - org.openejb.client.LocalInitialContextFactory - org.openejb.client.RemoteInitialContextFactory The idea being it's easier to remember both and easier to know which is which and even easier to switch back and forth if desired. RemoteInitialContextFactory was made as a subclass of JNDIContext. IIRC, LocalInitialContextFactory would have also been an "empty" subclass of InitContextFactory and I can't remember why it was not. Anyway, it went into the same package, and thus module, as the RemoteInitialContextFactory but it really didn't logically go there and we actually had our ant build setup to copy the LocalInitialContextFactory class into the openejb-core jar on every build where it did need to be. When we moved to maven from ant, the source file was just moved into the module where it really belonged. -David -- View this message in context: http://www.nabble.com/Why-is-LocalInitialContextFactory-in-openejb-core--tf4070851s2756.html#a11654989 Sent from the OpenEJB Dev mailing list archive at Nabble.com.
