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