RE: Modifiable context?

[Jeff Ramsdale-2]

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

[dblevins]

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
>
>

[Jeff Ramsdale-2]

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
>
>

[dblevins]

On Dec 19, 2005, at 11:25 AM, Jeff Ramsdale wrote:

> 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.)
>

The MDB support is bound tight into Geronimo for OpenEJB 2.  The not-
yet-developed OpenEJB 3.0 aims to be the upgrade path for people  
using OpenEJB 1.0 and want ejb 2.1 and eventually ejb 3.0 functionality.

> 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?
>

I tell you what, if you can get something working that meets your use  
case, I'll find a way to make it fit cleanly with what we have.  
Write it however is easiest for you and we'll steam it out later.  
Don't worry about style and all that junk.   I'll whip up any test  
cases required to make sure I don't loose any functionality you need  
and then refactor it to fit in place with what is there and where we  
are going.  Refactoring is quick when you know all the code.

> 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...
>

Something like this would get you commit fairly quickly.  We are very  
happy to have new people.

Happy holidays!

-David

> 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
>>
>>
>
>
>