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:
[hidden email]]
Sent: Fri 12/16/2005 10:54 AM
To:
[hidden email]
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:
[hidden email]]
> Sent: Tue 12/13/2005 5:04 PM
> To:
[hidden email]
> 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
>
>
Locked
