hi gernot, the bean-manager of weld doesn't find beans for qualifiers which were created by weld itself. there is a special logic for detecting the type of the conversation and if no special conversation type is found, the normal codi-conversation scope gets used. due to the weld bug, the detection fails and you get a normal conversation-scoped bean. the original test with glassfish v3.0 worked. it looks like a new bean-manager bug of weld. i'll test a workaround for weld.
regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/5/20 Gerhard Petracek <[email protected]> > hi gernot, > > @PreDestroy will be called after rendering the first page which doesn't use > the bean. > it looks like a weld bug (i see the same with weld v1.1.1). > i tested it with owb and it works as expected. > i'll have a look at it, if there is a possible workaround for weld. > > regards, > gerhard > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > > 2011/5/20 Gernot Pfingstl <[email protected]> > >> Hi, >> >> I'm using Glassfish 3.1 and CODI 0.9.5 >> >> I've a bean A annotated with @ViewAccessScoped. >> >> Bean A is used in page1.xhtml. If page1 is called from page1 the state >> of the bean is preserved (as expected). >> >> Then I navigate to page2.xhtml (which does not have any reference to >> bean A), an then I navigate (from page2) to page3.xhtml (which also >> does not have any reference to bean A). >> At this point I supposed bean A has bean invalidated/removed - but a >> @PreDestroy is never calles >> >> Now I navigate (from page3) to page1.xhtml - and bean A has the >> previous values and not an inital state. >> >> Do I misunderstand the @ViewAccessScoped or is there something wrong? >> >> regards, >> Gernot >> > >
