Here's my output on a request. I'm no expert on reading these, but it looks pretty clear to me that the OSIV filter ("open.hibernate.session.in.view") is being hit before the Wicket filter ("wicket.careerconnect").
DEBUG btpool0-4 - /view-jobs org.mortbay.log - Got Session ID ofm3l3dawnb1 from cookie ... // Here's the call to OSIV filter DEBUG btpool0-4 - /view-jobs org.mortbay.log - call filter open.hibernate.session.in.view DEBUG btpool0-4 - /view-jobs org.springframework.orm.hibernate3.support.OpenSessionInViewFilter - Using SessionFactory 'sessionFactory' for OpenSessionInViewFilter DEBUG btpool0-4 - /view-jobs org.springframework.beans.factory.support.DefaultListableBeanFactory - Returning cached instance of singleton bean 'sessionFactory' DEBUG btpool0-4 - /view-jobs org.springframework.orm.hibernate3.support.OpenSessionInViewFilter - Opening single Hibernate Session in OpenSessionInViewFilter DEBUG btpool0-4 - /view-jobs org.springframework.orm.hibernate3.SessionFactoryUtils - Opening Hibernate Session DEBUG btpool0-4 - /view-jobs org.hibernate.impl.SessionImpl - opened session at timestamp: 5127121449623552 ... // Here's the call to Wicket Filter DEBUG btpool0-4 - /view-jobs org.mortbay.log - call filter wicket.careerconnect DEBUG btpool0-4 - /view-jobs org.springframework.transaction.support.TransactionSynchronizationManager - Retrieved value [org.springframework.orm.hibernate3.sessionhol...@835551] for key [org.hibernate.impl.sessionfactoryi...@11739d] bound to thread [btpool0-4 - /view-jobs] DEBUG btpool0-4 - /view-jobs org.springframework.orm.hibernate3.HibernateTransactionManager - Found thread-bound Session [org.hibernate.impl.sessioni...@14af2c1] for Hibernate transaction DEBUG btpool0-4 - /view-jobs org.springframework.orm.hibernate3.HibernateTransactionManager - Using transaction object [org.springframework.orm.hibernate3.hibernatetransactionmanager$hibernatetransactionobj...@18762b1 ] ... DEBUG btpool0-4 - /view-jobs org.springframework.orm.hibernate3.HibernateTransactionManager - Preparing JDBC Connection of Hibernate Session [org.hibernate.impl.sessioni...@14af2c1 ] TRACE btpool0-4 - /view-jobs org.hibernate.impl.SessionImpl - setting flush mode to: AUTO DEBUG btpool0-4 - /view-jobs org.hibernate.transaction.JDBCTransaction - begin DEBUG btpool0-4 - /view-jobs org.hibernate.jdbc.ConnectionManager - opening JDBC connection DEBUG btpool0-4 - /view-jobs org.hibernate.transaction.JDBCTransaction - current autocommit status: true DEBUG btpool0-4 - /view-jobs org.hibernate.transaction.JDBCTransaction - disabling autocommit TRACE btpool0-4 - /view-jobs org.hibernate.jdbc.JDBCContext - after transaction begin DEBUG btpool0-4 - /view-jobs org.springframework.orm.hibernate3.HibernateTransactionManager - Exposing Hibernate transaction as JDBC transaction [jdbc:hsqldb:mem:mysticpaste-test, UserName=SA, HSQL Database Engine Driver] DEBUG btpool0-4 - /view-jobs org.springframework.transaction.support.TransactionSynchronizationManager - Bound value [org.springframework.jdbc.datasource.connectionhol...@20dc10] for key [org.apache.commons.dbcp.basicdatasou...@1b289cd] to thread [btpool0-4 - /view-jobs] DEBUG btpool0-4 - /view-jobs org.springframework.transaction.support.TransactionSynchronizationManager - Initializing transaction synchronization TRACE btpool0-4 - /view-jobs org.springframework.transaction.interceptor.TransactionInterceptor - Getting transaction for [edu.chemeketa.careerconnect.persistence.EntityDao.get] DEBUG btpool0-4 - /view-jobs org.springframework.orm.hibernate3.SessionFactoryUtils - Opening Hibernate Session DEBUG btpool0-4 - /view-jobs org.hibernate.impl.SessionImpl - opened session at timestamp: 5127121449623553 DEBUG btpool0-4 - /view-jobs org.springframework.orm.hibernate3.SessionFactoryUtils - Registering Spring transaction synchronization for new Hibernate Session DEBUG btpool0-4 - /view-jobs org.springframework.transaction.support.TransactionSynchronizationManager - Bound value [org.springframework.orm.hibernate3.sessionhol...@14fceb7] for key [org.hibernate.impl.sessionfactoryi...@1be6544] to thread [btpool0-4 - /view-jobs] DEBUG btpool0-4 - /view-jobs org.springframework.transaction.support.TransactionSynchronizationManager - Retrieved value [org.springframework.orm.hibernate3.sessionhol...@14fceb7] for key [org.hibernate.impl.sessionfactoryi...@1be6544] bound to thread [btpool0-4 - /view-jobs] DEBUG btpool0-4 - /view-jobs org.springframework.orm.hibernate3.HibernateTemplate - Found thread-bound Session for HibernateTemplate TRACE btpool0-4 - /view-jobs org.hibernate.event.def.DefaultLoadEventListener - loading entity: [edu.chemeketa.careerconnect.model.EmployerInfo#250] TRACE btpool0-4 - /view-jobs org.hibernate.event.def.DefaultLoadEventListener - attempting to resolve: [edu.chemeketa.careerconnect.model.EmployerInfo#250] TRACE btpool0-4 - /view-jobs org.hibernate.event.def.DefaultLoadEventListener - object not resolved in any cache: [edu.chemeketa.careerconnect.model.EmployerInfo#250] TRACE btpool0-4 - /view-jobs org.hibernate.persister.entity.AbstractEntityPersister - Fetching entity: [edu.chemeketa.careerconnect.model.EmployerInfo#250] DEBUG btpool0-4 - /view-jobs org.hibernate.loader.Loader - loading entity: [edu.chemeketa.careerconnect.model.EmployerInfo#250] DEBUG btpool0-4 - /view-jobs org.hibernate.jdbc.AbstractBatcher - about to open PreparedStatement (open PreparedStatements: 0, globally: 0) DEBUG btpool0-4 - /view-jobs org.hibernate.jdbc.ConnectionManager - opening JDBC connection DEBUG btpool0-4 - /view-jobs org.hibernate.SQL - select employerin0_.employer_account_id... // Rest of query here ... On Mon, Aug 31, 2009 at 9:43 AM, James Carman <jcar...@carmanconsulting.com>wrote: > You need the output from Spring classes during a request, not during > application startup. > > On Mon, Aug 31, 2009 at 12:39 PM, Dane Laverty <danelave...@gmail.com > >wrote: > > > Here's the output on startup. The OSIV is being loaded before the > > WicketFilter, and when I set breakpoints I can see that the > > OpenSessionInViewFilter is being hit first on each request. I'm turning > the > > project into a QuickStart and will attach it to a JIRA issue. > > > > DEBUG main org.mortbay.log - loaded class > > org.springframework.orm.hibernate3.support.OpenSessionInViewFilter from > > sun.misc.launcher$appclassloa...@1a7bf11 > > DEBUG main org.mortbay.log - Holding class > > org.springframework.orm.hibernate3.support.OpenSessionInViewFilter > > DEBUG main > > org.springframework.orm.hibernate3.support.OpenSessionInViewFilter - > > Initializing filter 'open.hibernate.session.in.view' > > DEBUG main > > org.springframework.orm.hibernate3.support.OpenSessionInViewFilter - > Filter > > 'open.hibernate.session.in.view' configured successfully > > DEBUG main org.mortbay.log - started open.hibernate.session.in.view > > DEBUG main org.mortbay.log - loaded class > > org.apache.wicket.protocol.http.WicketFilter from > > sun.misc.launcher$appclassloa...@1a7bf11 > > DEBUG main org.mortbay.log - Holding class > > org.apache.wicket.protocol.http.WicketFilter > > DEBUG main org.mortbay.log - loaded class > > org.apache.wicket.spring.SpringWebApplicationFactory from > > sun.misc.launcher$appclassloa...@1a7bf11 > > DEBUG main > > org.springframework.beans.factory.support.DefaultListableBeanFactory - > > Returning cached instance of singleton bean 'wicketApplication' > > > > > > Dane > > > > > > On Mon, Aug 31, 2009 at 9:14 AM, James Carman > > <jcar...@carmanconsulting.com>wrote: > > > > > Or, you can turn on spring logging to see it opening the session. > > > > > > On Mon, Aug 31, 2009 at 10:56 AM, Igor Vaynberg < > igor.vaynb...@gmail.com > > > >wrote: > > > > > > > doesnt look like your osiv is working. you can create a wicket > > > > quickstart project and attach it to a jira issue if you want someone > > > > to take a look at it. other then that you can use the debugger to see > > > > if osiv is actually being hit *before* the wicket filter. > > > > > > > > -igor > > > > > > > > On Mon, Aug 31, 2009 at 7:50 AM, Dane Laverty<danelave...@gmail.com> > > > > wrote: > > > > > Thanks James and Igor for looking it over. Switching the order of > the > > > > filter > > > > > definitions didn't make a difference. If it helps, here's what I'm > > > doing: > > > > > > > > > > 1 - This is the UserInfo class. As far as this test case is > > concerned, > > > it > > > > > has an ID and a Set<String> to check lazy loading. I've commented > out > > > the > > > > > FetchType.EAGER to test the OSIV. When it is uncommented, the > > UserPage > > > > (#2, > > > > > below) renders correctly, otherwise I get a lazy load exception. > > > > > > > > > > @Entity > > > > > @Table(name = "zjp_user_accounts") > > > > > public class UserInfo extends PersonInfo { > > > > > @Id > > > > > Long id; > > > > > > > > > > @OneToMany(mappedBy="employerInfo" /*, fetch=FetchType.EAGER*/) > > > > > Set<String> postedJobs; > > > > > ... > > > > > } > > > > > > > > > > > > > > > 2 - UserPage is the page I'm using to test lazy loading. > > > > > > > > > > public class UserPage extends WebPage { > > > > > @SpringBean(name = "personInfoDao") > > > > > private PersonInfoDao personInfoDao; > > > > > > > > > > public UserPage() { > > > > > > > > > > EntityModel<PersonInfo> personInfoModel = new > > > > > EntityModel<PersonInfo>(UserInfo.class, new Long(1)); > > > > > > > > > > EmployerInfo personInfo = > > > > (EmployerInfo)personInfoModel.getObject(); > > > > > Set<String> jobs = personInfo.getPostedJobs(); > > > > > Iterator<String> itr = jobs.iterator(); > > > > > while (itr.hasNext()) { > > > > > System.out.println(itr.next()); > > > > > } > > > > > } > > > > > } > > > > > > > > > > > > > > > 3 - And this is the EntityModel, based on the Smart EntityModel > > article > > > - > > > > > http://wicketinaction.com/2008/09/building-a-smart-entitymodel/ > > > > > > > > > > public class EntityModel<T extends Identifiable<?>> extends > > > > > AbstractEntityModel<T> { > > > > > > > > > > @SpringBean(name = "entityDao") > > > > > private EntityDao dao; > > > > > > > > > > public EntityModel(Class clazz, Serializable id) { > > > > > super(clazz, id); > > > > > // This makes the class Spring-aware, so we can inject the > > DAOs, > > > > as > > > > > above > > > > > InjectorHolder.getInjector().inject(this); > > > > > } > > > > > > > > > > @Override > > > > > protected T load(Class clazz, Serializable id) { > > > > > return (T)dao.get(clazz, (Long)id); > > > > > }; > > > > > } > > > > > > > > > > > > > > > I'd be happy to supply more code (xml files, etc.) if it would be > > > useful. > > > > I > > > > > feel that this is about as simple a use case as I can create for > the > > > > issue. > > > > > Thanks again for all your help! > > > > > > > > > > Dane > > > > > > > > > > > > > > > > > > > > On Sat, Aug 29, 2009 at 7:41 AM, James Carman < > > > > ja...@carmanconsulting.com>wrote: > > > > > > > > > >> Aren't they chained based on the order of the filter mapping > > > > definitions, > > > > >> not the order of the filter definitions? > > > > >> > > > > >> On Aug 29, 2009 12:40 AM, "Igor Vaynberg" < > igor.vaynb...@gmail.com> > > > > wrote: > > > > >> > > > > >> filters are executed in the order they are defined, so put the > osiv > > > > >> filter declaration before wicket. > > > > >> > > > > >> -igor > > > > >> > > > > >> On Thu, Aug 27, 2009 at 8:08 AM, Dane Laverty< > danelave...@gmail.com > > > > > > > >> wrote: > > > > >> > Thanks for the sugges... > > > > >> > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > > > > > > > > >