Thanks for the response!
Jacek Laskowski wrote:
Mark Lybarger wrote:
yeah! i've got openejb working now doing intravm testing on a simple stateless session bean which uses a datasource. very cool stuff.
Hi,
Excellent! Would you show us the configuration files? How long did it take? Do you think there're areas to improve? Which ones?
the test takes 9 seconds to run according to ant. that's running one test case, creating a few tables in axion, and deploying 15 or so slsb's into openejb. i may be able to share the config, but it's not that complicated really. that work is all on my work machine and i haven't been able to sub to the mailing list from there yet. i tried a couple weeks back but it didn't seem to go through.
some areas to improve would be to include mdb support in openejb. i hear that's slated for the 2.0 series,and i eagerly await it. i was told that all the "magic" needed to do the intravm type of testing that we're doing isn't yet in the 2.0 code base.
i'm not too familiar with integrating other "data sources" just yet in with openejb, but we're using a tuxedo connector from within weblogic to call out to an external tuxedo service. it would be nice to have documentation on how to setup this type of thing. for testing, we'd probably want to stub/mock out the actual service, but in a way to not touch the code/dd just to test.
our app also turns auto commit off for db connections every time it gets one from the data source. this of course was an issue using openejb as it throws a not implemented exception there. i patched the code to just not throw that exception and was on my way. i'm not really familiar with why our code base does this (performance benefits maybe i dunno), but again, i'd like to minimize touching the code base.
with intravm, is a remote lookup like this possible?
I wouldn't expect any troubles there. Should work smothly (unless there's a bug :)).
i may have been unclear, i would like the bean under test to be able to do a lookup on another bean deployed also within the same openejb instance. i would like to minimize the coding changes required to existing beans just to be able to test them more quickly. we seem to have side stepped the spec in a few areas which seems to bite us when we least expect it.
and if so, is there a way to configure openejb so that i can say, "hey container, i know these here beans are going to declare some garbage in their env-entries, but i'd like you to use _THIS_ value instead." ? so that i can force a url/context factory the service locator will use.
Don't understand. Do you want to change env-entries at runtime? If so, unless I'm mistaken it's not permitted by the spec. The env-entries are bound to the read-only initial context where bind/unbind methods will simply throw OperationNotSupportedExceptions.
yes, that was one idea to maybe work around the remote lookup that we're currently doing.
thanks again!
Jacek
