Mark Lybarger wrote:
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.
Hi Mark,
What are the problems? Is it something with your local infrastructure or with the ML configuration?
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.
Well, you can approach the question other way round - embed Apache Geronimo (thus OpenEJB). It should give you much more opportunities.
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.
I haven't ever work with Tuxedo, but I guess it's connected to WLS via a Java Connector driver. I don't think it'd be possible in OpenEJB1 yet. However, in Apache Geronimo there's a connector service that would get it plugged in. If there's a connector impl of Tuxedo, it should also be possible to run it in Apache Geronimo.
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.
Yes, that's the way I'd follow.
our app also turns auto commit off for db connections every time it gets one from the data source.
I remember one project where a app server always returned a connection from a data source with autocommit turned on. As the project relied on autocommit being off, it's a nightmare to cope with it. Fixing bugs was a fabulous job ;)
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.
Would you provide us with a snippet/test case which could show the issue? That's the most efective way to improve OpenEJB, people suggest changes that go to the codebase. The patch is also welcome.
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.
I don't think ejb-link's are supported in OpenEJB, neither in OpenEJB1 nor (perhaps) in OpenEJB2.
However, I don't expect any troubles to do a lookup from a EJB to another EJB. It shall work.
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.
Provided, we're on the same track, doing the remote lookup from a EJB is doable. If I'm mistaken please show the code that doesn't work.
thanks again!
Best, Jacek
