I've attached a new patch to Jira issue OPENEJB-1188. This seems to be working, and I'd like to get it committed soon. I'm going to change the format of the generated proxy name, and have another look at classloader code for the proxies over the next few days.
If anyone has a chance to give it a spin, any feedback would be gratefully received. Cheers Jon On Fri, Mar 26, 2010 at 12:44 AM, David Blevins <[email protected]>wrote: > > On Mar 25, 2010, at 4:19 PM, Jonathan Gallimore wrote: > > On Thu, Mar 25, 2010 at 11:05 PM, David Blevins <[email protected] >> >wrote: >> >> >>> No need. No-interface views can be remoted, so remote clients using >>> openejb-client can never get one. >>> >>> >> Should that be "No-interface views cannot be remoted"? >> > > Yes, sorry, hate when I do that. > > > BUT... it might be fun to do one day anyway, someday in the future, and >>> then sure more deps may be required. Spec-wise some of the original >>> annotation name ideas were @NoInterface, etc.. which didn't imply local >>> vs >>> remote. @LocalBean was my suggestion and in the back of my mind I was >>> thinking an @RemoteBean might be a cool thing to add. >>> >>> >> It didn't really occur to me that the "Local" part meant it wouldn't be >> remotely accessible, but its kinda obvious now! *blush* ;-) >> > > Hehe. That's the way it goes. > > > I was going to >> make it work from a client because it didn't seem like it would be that >> difficult >> > > My thoughts exactly. I did propose the @RemoteBean concept and it was not > well liked, but I don't see a problem with it. It does mean that users have > to have *all* the libraries that their bean class uses in their client VM, > but oh well, not so terrible. Only some people bother to split them up > these days anymore. > > If people you don't want that, then they can just use a plain @Remote > interface. > > > now I've got the asm code done, along with the additional >> openejb-jee and DeploymentInfo code, and I've got a simple case working in >> Embedded mode. I'll hold off on that and write some more tests and get >> this >> packaged up instead, and perhaps do a @RemoteBean implementation later on. >> > > Sure. > > -David > >
