Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Dali » Testing Strategy
Testing Strategy [message #434048] Tue, 31 October 2006 22:48 Go to next message
Andy Czerwonka is currently offline Andy CzerwonkaFriend
Messages: 42
Registered: July 2009
Member
Which vendors support out-of-container entity managers?

My real questions is, what's a best-practice testing strategy? There are
tests where I'd like to take the middle tier out. We're a rich client built
on Eclipse RCP and it'd be nice to remove the middle tier for a many tests.
Basically pull out the proxy.


Note: Hey Shaun, hope you're well. Let's catch up sometime.

--
Andy Czerwonka
Re: Testing Strategy [message #434277 is a reply to message #434048] Fri, 03 November 2006 18:28 Go to previous messageGo to next message
Shaun Smith is currently offline Shaun SmithFriend
Messages: 197
Registered: July 2009
Senior Member
Nice to hear from you Andy! My direct email is first.last at oracle
dot com.

> Which vendors support out-of-container entity managers?

AFAIK all do. That's because the ones I'm aware of all come from the out
of container POJO persistence world like TopLink, Hibernate, and Kodo.
Unlike the others, TopLink has been providing in-container CMP support for
a number of years.

> My real questions is, what's a best-practice testing strategy? There are
> tests where I'd like to take the middle tier out. We're a rich client built
> on Eclipse RCP and it'd be nice to remove the middle tier for a many tests.
> Basically pull out the proxy.

The issues you face when running out of container will be 1) transaction
control, and 2) bytecode weaving/enhancement.

When running in container with an EJB 3.0 session bean the transactions
are handled by the container and you don't have to worry about them in
code. Running out of container there's an API on
EntityManager.getTransaction() that you need to use to
begin/commit/rollback transactions yourself. Fortunately, if you're using
EJB 3.0 Session Beans your test can play the role of the container by:
- obtaining an EntityManager,
- beginning the transaction,
- injecting the EntityManger into the Session Bean
- calling your method under test
- commit the transaction if no exception occured

Then you can do your assertions.

The second issue is bytecode weaving or whatever other technology your
provider is using to do things like transparent 1:1 lazy loading. In
TopLink Essentials you need to either perform static weaving or start your
vm with a -javaagent for the agent jar that does the weaving. You don't
have to do either of these things but if you don't you can't get lazy 1:1
loading.

Hope that helps!

Shaun
Re: Testing Strategy [message #434279 is a reply to message #434277] Sun, 05 November 2006 14:18 Go to previous message
Andy Czerwonka is currently offline Andy CzerwonkaFriend
Messages: 42
Registered: July 2009
Member
> The issues you face when running out of container will be 1) transaction
> control, and 2) bytecode weaving/enhancement.
>
> When running in container with an EJB 3.0 session bean the transactions
> are handled by the container and you don't have to worry about them in
> code. Running out of container there's an API on
> EntityManager.getTransaction() that you need to use to
> begin/commit/rollback transactions yourself. Fortunately, if you're using
> EJB 3.0 Session Beans your test can play the role of the container by:
> - obtaining an EntityManager, - beginning the transaction, - injecting the
> EntityManger into the Session Bean
> - calling your method under test
> - commit the transaction if no exception occured
>
> Then you can do your assertions.
Yes, I think that should be straight forward.


>
> The second issue is bytecode weaving or whatever other technology your
> provider is using to do things like transparent 1:1 lazy loading. In
> TopLink Essentials you need to either perform static weaving or start your
> vm with a -javaagent for the agent jar that does the weaving. You don't
> have to do either of these things but if you don't you can't get lazy 1:1
> loading.
I'll try it. We're looking at both JBoss and Glassfish, so I'll need to
hunt down how JBoss does the weaving - clearly using their AOP product.
Re: Testing Strategy [message #591000 is a reply to message #434048] Fri, 03 November 2006 18:28 Go to previous message
Shaun Smith is currently offline Shaun SmithFriend
Messages: 197
Registered: July 2009
Senior Member
Nice to hear from you Andy! My direct email is first.last at oracle
dot com.

> Which vendors support out-of-container entity managers?

AFAIK all do. That's because the ones I'm aware of all come from the out
of container POJO persistence world like TopLink, Hibernate, and Kodo.
Unlike the others, TopLink has been providing in-container CMP support for
a number of years.

> My real questions is, what's a best-practice testing strategy? There are
> tests where I'd like to take the middle tier out. We're a rich client built
> on Eclipse RCP and it'd be nice to remove the middle tier for a many tests.
> Basically pull out the proxy.

The issues you face when running out of container will be 1) transaction
control, and 2) bytecode weaving/enhancement.

When running in container with an EJB 3.0 session bean the transactions
are handled by the container and you don't have to worry about them in
code. Running out of container there's an API on
EntityManager.getTransaction() that you need to use to
begin/commit/rollback transactions yourself. Fortunately, if you're using
EJB 3.0 Session Beans your test can play the role of the container by:
- obtaining an EntityManager,
- beginning the transaction,
- injecting the EntityManger into the Session Bean
- calling your method under test
- commit the transaction if no exception occured

Then you can do your assertions.

The second issue is bytecode weaving or whatever other technology your
provider is using to do things like transparent 1:1 lazy loading. In
TopLink Essentials you need to either perform static weaving or start your
vm with a -javaagent for the agent jar that does the weaving. You don't
have to do either of these things but if you don't you can't get lazy 1:1
loading.

Hope that helps!

Shaun
Re: Testing Strategy [message #591017 is a reply to message #434277] Sun, 05 November 2006 14:18 Go to previous message
Andy Czerwonka is currently offline Andy CzerwonkaFriend
Messages: 42
Registered: July 2009
Member
> The issues you face when running out of container will be 1) transaction
> control, and 2) bytecode weaving/enhancement.
>
> When running in container with an EJB 3.0 session bean the transactions
> are handled by the container and you don't have to worry about them in
> code. Running out of container there's an API on
> EntityManager.getTransaction() that you need to use to
> begin/commit/rollback transactions yourself. Fortunately, if you're using
> EJB 3.0 Session Beans your test can play the role of the container by:
> - obtaining an EntityManager, - beginning the transaction, - injecting the
> EntityManger into the Session Bean
> - calling your method under test
> - commit the transaction if no exception occured
>
> Then you can do your assertions.
Yes, I think that should be straight forward.


>
> The second issue is bytecode weaving or whatever other technology your
> provider is using to do things like transparent 1:1 lazy loading. In
> TopLink Essentials you need to either perform static weaving or start your
> vm with a -javaagent for the agent jar that does the weaving. You don't
> have to do either of these things but if you don't you can't get lazy 1:1
> loading.
I'll try it. We're looking at both JBoss and Glassfish, so I'll need to
hunt down how JBoss does the weaving - clearly using their AOP product.
Previous Topic:Dali Disappeared?
Next Topic:Dali integration into WTP Plan?
Goto Forum:
  


Current Time: Sun Dec 21 10:58:32 GMT 2014

Powered by FUDForum. Page generated in 0.01781 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software