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

Reply via email to