Ah--wondered why things were so quiet. Welcome back! I think mutability for local clients is all I'd need. I'm interested in using OpenEJB (sans Geronimo) for testing of MDBs. I know this isn't supported by the current official release of OpenEJB and I'm not sure of the state of the code in CVS. Would you be able to clarify? And is it even possible to run MDBs without Geronimo? (I can pick up some of the Geronimo jars if necessary, but I'd like to avoid server startup.) In the meantime (if the MDB features aren't yet available), I was hoping to use OpenEJB's already-running JNDI to host my other non-MDB context entries. But since these are set by my tests and not through configuration I'm hitting those pesky OperationNotSupportedExceptions. So that's my use case. Just to make sure I understand your suggestion, would the original entry remain in the nested LocalInitialContextFactory but masked by the wrapping class? And do you see the wrapper idea as preferable to LocalInitialContextFactory supporting bind and rebind directly? If I'm able to come up with a solution I'll certainly give back what I do. Not sure I can commit to it, though... Thanks! Jeff
________________________________ From: David Blevins [mailto:[EMAIL PROTECTED] Sent: Fri 12/16/2005 10:54 AM To: [email protected] Subject: Re: [openejb-user] Modifiable context? Hi Jeff, Most of us were at ApacheCon until yesterday night and more or less off the radar. Anyway, having a mutable JNDI context for local clients isn't a bad idea. It'd be something we could add to LocalInitialContextFactory but probably not something we'd add to the RemoteInitialContextFactory. With the LocalInitialContextFactory, it's your memory you are chewing on, so have at it. With the RemoteInitialContextFactory, you would be chewing on the server's memory and bandwidth. I mention the RemoteInitialContextFactory as essentially the Local and the Remote InitialContextFactories are functionally equivalent from the client's perspective more or less and one can be swapped out for another. Something to consider. An idea could be to make a new InitialContextFactory that wraps a Local or Remote InitialContextFactory and provides binding ability that is not distributed and only present on the client using the InitialContext. It would just delegate to the Local or Remote InitialContextFactory if the binding isn't found in it's list of entries. The thing to consider there is that you could potentially "overwrite" a binding in the Local or Remote InitialContextFactory. Alright, so that's an initial brain dump on the feature. No real conclusion. How do you imagine the feature you need working? Some sort of use case on how it helps your testing would be great to make sure we are actually solving the problem. Also, any interest in helping to work on it? Thanks, David On Dec 15, 2005, at 3:02 PM, Jeff Ramsdale wrote: > Hmmm... > > Not having received an answer to this question, let me ask another. Is > it possible to use a different JNDI implementation than the one used > in OpenEJB? That is, there's no special magic in its JNDI > implementation that OpenEJB depends upon, is there? Do other > implementations allow for programatic bindings? I wouldn't have > thought this to be an unusual thing to try to do in a unit-testing > world? Set me straight, please, if I'm going about this wrong! > > Thanks, > > Jeff > > ________________________________ > > From: Jeff Ramsdale [mailto:[EMAIL PROTECTED] > Sent: Tue 12/13/2005 5:04 PM > To: [email protected] > Subject: [openejb-user] Modifiable context? > > > > When running in embedded mode for purposes of unit testing I'd like to > be able to programatically add bindings to my context. Is this > possible? I'm running into OperationNotSupportedExceptions because I'm > receiving a ReadOnlyContext using LocalInitialContextFactory. > > Thanks, > > Jeff > >
