Re: Quick fix for the dreaded org.hibernate.LazyInitializationException with WicketTester
I managed to make a similar workaround to enable reopening of session in unit
tests using your approach. I'm using wicket 6.7, hibernate 4 and spring
3.2.2.
please let me know if you have any problem in this configuration
Thanks a lot
Leon Nieuwoudt wrote
Hi all,
After about 5 minutes of omfg not that error again, I think I found a
quick hack to avoid org.hibernate.LazyInitializationException with
WicketTester. I've checked everywhere on the lists but didn't find a
similar
solution, so apologies if someone else already posted this. There may also
be a better way to do it.
If I can explain it properly:
* I have an abstract BaseAdminApplication class that extends
WebApplication,
and does the standard application configurations (mounting/stuff), but no
Spring injection configuration yet.
* Then I have a SpringAdminApplication that extends from
BaseAdminApplication. This is referenced for the normal
applicationContext.xml, and correctly configures Spring Injection.
* There is another subclass, called JUnitAdminApplication, that also
extends
from BaseAdminApplication. This is referenced in the Unit Testing
application context.
* The JUnitAdminApplication mimics the OSIV pattern, inside Wicket's
WebSession.attach() and .detach() methods.
* Configure Spring Injection outside of the WebApplication. For some
reason
there were odd errors when configuring during the WebApplication.init()
process.
I do hope it makes sense. Unfortunately I can't give out all the code, but
I'm sure it'll set the next person on the right track before redoing tests
with Selenium at the 11th hour. So far there are no strange surprises,
yet.
---
package com.SECRETAPP.web;
import ..;
public class JUnitAdminApplication extends BaseAdminApplication {
@Autowired
SessionFactory sessionFactory;
@Override
public Session newSession(Request request, Response response) {
return new WebSession(request) {
@Override
protected void attach() {
// Do the attach magic that I don't care about right now
super.attach();
// Force the creation of a new Hibernate session using
Spring
SessionFactoryUtils.getSession(sessionFactory, true);
// Force the session to be closed only when we tell it to
// By default, the Hibernate session is closed somewhere
during
// the request cycle. Similar to OpenSessionInViewFilter
SessionFactoryUtils.initDeferredClose(sessionFactory);
}
@Override
protected void detach() {
super.detach();
// Only close the Hibernate Session now, after all
rendering
is done
SessionFactoryUtils.processDeferredClose(sessionFactory);
}
};
}
// Other code...
}
In com/SECRETAPP/web/BaseTester-context.xml ..
beans.
context:component-scan base-package=com.SECRETAPP /
bean id=wicketApplication
class=com.SECRETAPP.web.JUnitAdminApplication/
/beans
In my WicketTestBase abstract class...
public abstract class WicketTestBase {
// Stripped code
protected WicketTester createTester() {
if(tester != null) {
return tester;
}
WebApplication app = (WebApplication)
applicationContext.getBean(wicketApplication);
tester = new WicketTester(app) {
@Override
public ServletContext newServletContext(String path) {
MockServletContext servletContext = (MockServletContext)
super.newServletContext(path);
servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE,
applicationContext);
return servletContext;
}
};
app.addComponentInstantiationListener(new
SpringComponentInjector(tester.getApplication(), applicationContext,
true))
// Stripped code
return tester;
}
}
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Quick-fix-for-the-dreaded-org-hibernate-LazyInitializationException-with-WicketTester-tp1864931p4659304.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
SV: Quick fix for the dreaded org.hibernate.LazyInitializationException with WicketTester
After about 5 minutes of omfg not that error again, I think I found a quick hack to avoid org.hibernate.LazyInitializationException with WicketTester. I've checked everywhere on the lists but didn't find a similar solution, so apologies if someone else already posted this. There may also be a better way to do it. I thought the medicine against LazyInitializationException was spring-hibernate's OpenSessionInViewFilter, where you leave to the filter to open and close the session at the beginning and end of the request? - Tor Iver - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Quick fix for the dreaded org.hibernate.LazyInitializationException with WicketTester
Yes this works when running the program in the Application Server environment. For JUnit testing (outside of the AS), I ran into this problem. Is there maybe a better way to maybe wrap the OSIV Filter around Unit Tests? On Tue, Feb 16, 2010 at 9:07 AM, Wilhelmsen Tor Iver toriv...@arrive.nowrote: I thought the medicine against LazyInitializationException was spring-hibernate's OpenSessionInViewFilter, where you leave to the filter to open and close the session at the beginning and end of the request? - Tor Iver - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Quick fix for the dreaded org.hibernate.LazyInitializationException with WicketTester
all you have to do is start a transaction before each unit test and roll it back after. spring has base unit tests and test runners that do this for you... -igor On Tue, Feb 16, 2010 at 12:13 AM, Leon Nieuwoudt leon.nieuwo...@gmail.com wrote: Yes this works when running the program in the Application Server environment. For JUnit testing (outside of the AS), I ran into this problem. Is there maybe a better way to maybe wrap the OSIV Filter around Unit Tests? On Tue, Feb 16, 2010 at 9:07 AM, Wilhelmsen Tor Iver toriv...@arrive.nowrote: I thought the medicine against LazyInitializationException was spring-hibernate's OpenSessionInViewFilter, where you leave to the filter to open and close the session at the beginning and end of the request? - Tor Iver - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Quick fix for the dreaded org.hibernate.LazyInitializationException with WicketTester
Hi Igor
Glad to hear there's another way.
I'm already using the Spring JUnit runner, like this:
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class UserTest extends . {
@Test
public void testCRUD() {
// Code...
}
}
This what I tried:
* Adding @Transactional over testCRUD() out of desperation
* Subclassing the base tester from
AbstractTransactionalDataSourceSpringContextTests, according to the docs
this will automatically begin a transaction and rollback. It also looks like
it's for JUnit 3.x.
The above didn't work though, so I tried the attach()/detach() route to
emulate OSIV which worked fine. I therefore assume I'm missing something.
On Tue, Feb 16, 2010 at 9:18 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
all you have to do is start a transaction before each unit test and
roll it back after. spring has base unit tests and test runners that
do this for you...
Re: Quick fix for the dreaded org.hibernate.LazyInitializationException with WicketTester
Just an update, the quick hack failed completely when testing on an XP
system, but it worked perfectly on Ubuntu.
Any links or example on getting Spring/Hibernate/WicketTester/JUnit4 to work
will be appreciated. lmgtfy will also suffice ;)
On Tue, Feb 16, 2010 at 9:57 AM, Leon Nieuwoudt leon.nieuwo...@gmail.comwrote:
Hi Igor
Glad to hear there's another way.
I'm already using the Spring JUnit runner, like this:
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class UserTest extends . {
@Test
public void testCRUD() {
// Code...
}
}
This what I tried:
* Adding @Transactional over testCRUD() out of desperation
* Subclassing the base tester from
AbstractTransactionalDataSourceSpringContextTests, according to the docs
this will automatically begin a transaction and rollback. It also looks like
it's for JUnit 3.x.
The above didn't work though, so I tried the attach()/detach() route to
emulate OSIV which worked fine. I therefore assume I'm missing something.
On Tue, Feb 16, 2010 at 9:18 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
all you have to do is start a transaction before each unit test and
roll it back after. spring has base unit tests and test runners that
do this for you...
Quick fix for the dreaded org.hibernate.LazyInitializationException with WicketTester
Hi all,
After about 5 minutes of omfg not that error again, I think I found a
quick hack to avoid org.hibernate.LazyInitializationException with
WicketTester. I've checked everywhere on the lists but didn't find a similar
solution, so apologies if someone else already posted this. There may also
be a better way to do it.
If I can explain it properly:
* I have an abstract BaseAdminApplication class that extends WebApplication,
and does the standard application configurations (mounting/stuff), but no
Spring injection configuration yet.
* Then I have a SpringAdminApplication that extends from
BaseAdminApplication. This is referenced for the normal
applicationContext.xml, and correctly configures Spring Injection.
* There is another subclass, called JUnitAdminApplication, that also extends
from BaseAdminApplication. This is referenced in the Unit Testing
application context.
* The JUnitAdminApplication mimics the OSIV pattern, inside Wicket's
WebSession.attach() and .detach() methods.
* Configure Spring Injection outside of the WebApplication. For some reason
there were odd errors when configuring during the WebApplication.init()
process.
I do hope it makes sense. Unfortunately I can't give out all the code, but
I'm sure it'll set the next person on the right track before redoing tests
with Selenium at the 11th hour. So far there are no strange surprises, yet.
---
package com.SECRETAPP.web;
import ..;
public class JUnitAdminApplication extends BaseAdminApplication {
@Autowired
SessionFactory sessionFactory;
@Override
public Session newSession(Request request, Response response) {
return new WebSession(request) {
@Override
protected void attach() {
// Do the attach magic that I don't care about right now
super.attach();
// Force the creation of a new Hibernate session using
Spring
SessionFactoryUtils.getSession(sessionFactory, true);
// Force the session to be closed only when we tell it to
// By default, the Hibernate session is closed somewhere
during
// the request cycle. Similar to OpenSessionInViewFilter
SessionFactoryUtils.initDeferredClose(sessionFactory);
}
@Override
protected void detach() {
super.detach();
// Only close the Hibernate Session now, after all rendering
is done
SessionFactoryUtils.processDeferredClose(sessionFactory);
}
};
}
// Other code...
}
In com/SECRETAPP/web/BaseTester-context.xml ..
beans.
context:component-scan base-package=com.SECRETAPP /
bean id=wicketApplication
class=com.SECRETAPP.web.JUnitAdminApplication/
!-- other stuff --
/beans
In my WicketTestBase abstract class...
public abstract class WicketTestBase {
// Stripped code
protected WicketTester createTester() {
if(tester != null) {
return tester;
}
WebApplication app = (WebApplication)
applicationContext.getBean(wicketApplication);
tester = new WicketTester(app) {
@Override
public ServletContext newServletContext(String path) {
MockServletContext servletContext = (MockServletContext)
super.newServletContext(path);
servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE,
applicationContext);
return servletContext;
}
};
app.addComponentInstantiationListener(new
SpringComponentInjector(tester.getApplication(), applicationContext, true))
// Stripped code
return tester;
}
}
