Thanks for clarifying David, so with the agent and annotation issues aside, I still don't understand what's tricky in supporting @EJB, @Resource, etc. compared to standalone OpenEJB. I'd for one would like to see this working out of the box and would like to help Dain out here if feasible.
-Dario > On Sep 13, 2007, at 1:35 PM, Dario Laverde wrote: > >> Actually it would be nice to have the reverse of: >> >> openejb.remotable.businessLocals=true >> >> esp for tomcat+openejb i.e. where remote lookups become local lookups. > > You can set "openejb.localcopy=false" to shut of the spec required > pass by value semantics for remote interfaces. All remote interfaces > will be pass by reference exactly as local interfaces are. > > Other than that, using the LocalInitialContextFactory doesn't involve > sockets, ports and net connections, we just have to add the copy > semantics on remote interfaces (copying via serializing and > deserializaing) per spec rules which can be shut off as shown above. > >> Restrictions >> o The installer only runs on Unix. Windows support will require a >> tweaked catalina.bat and a work around for Windows file locking. >> >> This is only because of backing up catalina.sh for adding javaagent >> correct? Why >> exactly do we need the agent? Again, I'm more interested in the >> multiple instance >> and not the single instance of OpenEJB per Tomcat. > > AGENT (OPENJPA) > > It's OpenJPA that requires the agent for enhancing byte code of JPA > beans and the classes that reference JPA beans. They very recently > started adding unenhanced support but it's only 80 there still. > Maybe more, but not 100% yet. When they get the unenhanced support > nailed, we can skip the agent installation unless you want it for > performance (enhanced mode is faster than unenhanced mode). > > Installing the agent into the catalina.bat file is just as easy on > windows, just lack of time on this one. /me hangs up a help wanted sign > It can still be done by hand, or you can skip it completely if you > don't plan to use CMP or JPA, or if you wish to use a different JPA > provider like hibernate. > > INVALID ANNOTATIONS-API.JAR > > The other thing is that Tomcat has a completely non-compliant > annotations-api.jar where @Resource, @EJB and the like have all the > wrong attributes. When they fix it, this headache will be gone and > half of the "reboot" issues will go away and a windows installer will > be easy (it is easy now to just replace the jar manually). > > Until they fix it, no compliant JavaEE 5 apps will run! So we have > to get it out of the classpath and put a working one in. If this > happens at runtime, you'll have to reboot to get those old class > definitions out. You can do this part by hand ahead of time when > Tomcat is shutdown, just delete annotations-api.jar and replace it > with geronimo-annotation_1.0_spec-1.1.jar. > > The trick with doing this on a running Tomcat installation is that > windows locks the jar files if they are in a classpath of a living > classloader and won't allow you modify, move or delete them (no write > access of any kind). There might be some vm specific tricks we can > pull to get around this, but just as with linux you'll have to reboot > to get the invalid class definitions out of the tomcat classloaders. > >> o There is no uninstaller. Currently, the installer deletes the non- >> compliant Tomcat annotations-api.jar so in addition to backing out >> the changes, you need to restore this file. >> >> Could you at least backup it up to .orig like you did with >> catalina.sh and server.xml? > > We can do that, but any apps using the compliant annotations jar > might not run with the non-compliant annotations jar. You're better > off keeping the compliant jar. > >> o Annotations in servlets to OpenEJB resources (EJBs, >> PersistenceUnits, Topics, Queues, DataSources, etc) don't resolve. >> You will have to use global JNDI for the time being. >> >> This is a show stopper IMO - is it because of having more than one >> classloader? > > Just time. Tomcat doesn't process any of this stuff so we have to do > it for them. Dain's already working on it. > >> Can we also avoid the reboot re: server.xml by moving the listener >> into the webapp's >> web.xml instead? > > As noted above the reboot is primarily to get the agent in and the > annotations jar fixed. If those weren't there we could probably find > a way to avoid the server restart and still install our listener. > >> Again, I'm more interested in the multiple instance >> and not the single instance of OpenEJB per Tomcat. > > Just to note, both approaches work in the same integration; i.e. you > can put ejbs in the tomcat lib dir or anywhere you specify in a > <Deployments> declaration in your openejb.xml file, as well as having > ejbs right in your webapp in collapsed ear style. > > What no longer works is having OpenEJB itself embedded right in your > webapp and not visible to other webapps. Were the agent and > annotation jar issues fixed we could probably do that again, however > it'd be tricky to support new things like processing @EJB and > @Resource, etc. annotations for Servlets, Filters and Listeners in > the webapp where OpenEJB is embedded as there's a sort of chicken and > egg problem. We can certainly give it a go if this is what people want. > > Thoughts? > > >
