Oki all clear. The internal EntityManager will get closed when you leave the
outer @Stateless method.
@Stateless EJBSs really are nothing else than beans with an interceptor which
opens and commits the transaction and EntityManager on the outermost EJB level.
Since the @ManagedBean is not an EJB anymore you don't have any transaction nor
EntityManager open anymore in your render_response phase in JSF. Which means
that OpenJPA cannot provide lazyloading for you.
I personally prefer to use the entitymanager-per-request patter and using CDI
with a @RequestScoped EntityManager. But that might be a bigger change in
architecture for you.
Other options are:
* touching the required bits in your DAO
* using eager fetching
* using a fetch-plan
* using DTOs
LieGrue,
strub
> On Wednesday, 9 November 2016, 17:31, Matthew Broadhead
> <matthew.broadh...@nbmlaw.co.uk> wrote:
> > sorry for the delay in replying i was very busy
>
> as a simple example there is a generic Dao class to return the results
> of a namedquery
> @Stateless
> public class DAO {
> @PersistenceContext(unitName = "widgetDataSource")
> private EntityManager em;
> ....
> @SuppressWarnings("unchecked")
> public <E> List<E> namedFind(Class<E> clazz, String
> query) {
> return em.createNamedQuery(query, clazz).getResultList();
> }
> ....
> }
> call the namedFind from another stateless
> @Stateless
> public class WidgetDAO {
> @EJB
> private DAO dao;
> ...
> public List<Widget> findAll() {
> return dao.namedFind(Widget.class, "Widget.findAll");
> }
> ....
> }
> this is loaded into a managedbean
> @ManagedBean
> @ViewScoped
> public class WidgetBean {
> @EJB
> private WidgetDAO widgetDao;
> private List<Widget> widgetList;
> public void onload(){
> setWigdetList(widgetDao.fildAll());
> }
> ...setter getter of widgetList
> }
> which is supposed to display in jsf
> <?xml version="1.0" encoding="UTF-8"?>
> <ui:composition xmlns="http://www.w3.org/1999/xhtml";
> xmlns:h="http://java.sun.com/jsf/html";
> xmlns:ui="http://java.sun.com/jsf/facelets";
> xmlns:f="http://java.sun.com/jsf/core";
> template="/WEB-INF/include/layout.xhtml">
> ...
> <ui:repeat var="widget"
> value="#{widgetBean.widgetList}">
> <ui:repeat var="subWidget"
> value="#{widget.subWidgets}">
> ...where are the sub widgets?
> </ui:repeat>
> </ui:repeat>
> </ui:composition>
>
> Like i say if i loop through the widgets (or maybe the subwidgets as
> well) it then loads in the JSF. so it lazy loads in java but not in
> JSF. should i change to eager when i generate the entities or is there
> something else i can do? is it supposed to work the same as eclipselink?
>
>
> On 02/11/2016 08:06, Mark Struberg wrote:
>> Hi Matthew!
>>
>> Now I'm back on my notebook.
>> What transaction mechanism are you using? JTA or ResourceLocal?
>> And what technology to control the transactions? EJBs? CDI? Spring?
>>
>> It boils down to be more a question about appliction architecture than
> about OpenJPA, but still very important to cover. So just go ahead, I'm
> pretty sure we can help you.
>>
>> LieGrue,
>> strub
>>
>>> Am 24.10.2016 um 10:34 schrieb Matthew Broadhead
> <matthew.broadh...@nbmlaw.co.uk>:
>>>
>>> HI, I am using TomEE 7.0.1 and I just switched from Plume to Plus. I
> was using eclipselink and now I am converting to OpenJPA. When I fetch a set
> of
> entities and then try to iterate through their associations in JSF the list
> is
> empty. in eclipselink they were populated by default. if i loop through the
> entities in Java before displaying in JSF then they are populated (i guess
> they
> get lazy loaded). is there a setting that needs to be changed? like
> generating
> with all associations as eager or setting a flag in persistence.xml? what
> would
> give the same default as eclipselink? seemed like an easy question but i
> could
> not find anything by searching.
>
