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
> > > >
> > > >
> > >
> >
>
