You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Matthew Broadhead <ma...@nbmlaw.co.uk> on 2016/10/24 08:34:31 UTC
fetching associations
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.
Re: fetching associations
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Hi!
I sounds like you did hit the classic lazy loading issue. eclipselink opens a connection again, but this is not specced. In Hibernate you will end up with a LazyInitializationException.
It's not an OpenJPA issue but the way transactions work in JavaEE by default.
For JSF I recommend to not use EJB transactions but a @RequestScoped EntityManager producer in CDI together with Apache DeltaSpike @Transactional.
Can add links later when on notebook.
lieGrue,
Strub
> Am 27.10.2016 um 21:07 schrieb gilbertoca <gi...@gmail.com>:
>
> I'm not entirely sure, but you need to make the enhancement of the entities
> [1].
>
> Regards,
>
> Gilberto
>
> [1]
> https://openjpa.apache.org/builds/2.4.1/apache-openjpa/docs/manual.html#ref_guide_pc_enhance
>
>
>
> --
> View this message in context: http://openjpa.208410.n2.nabble.com/fetching-associations-tp7589828p7589836.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: fetching associations
Posted by gilbertoca <gi...@gmail.com>.
I'm not entirely sure, but you need to make the enhancement of the entities
[1].
Regards,
Gilberto
[1]
https://openjpa.apache.org/builds/2.4.1/apache-openjpa/docs/manual.html#ref_guide_pc_enhance
--
View this message in context: http://openjpa.208410.n2.nabble.com/fetching-associations-tp7589828p7589836.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: fetching associations
Posted by gilbertoca <gi...@gmail.com>.
Matthew Broadhead wrote
> so if the managedbean is not an ejb anymore and therefore the
> transaction is closed how does it work for eclipselink? do they use
> some magic? are there any plans for implementing this "feature" in the
> future? after spending a few months migrating to myfaces and openjpa on
> the suggestion of romain i now find that openjpa cannot lazy load
> entities from jsf which is fairly disappointing to say the least.
Indeed it a killer feature, it makes our life easier. It is the main point
for us to stay with it.
Matthew Broadhead wrote
> is my best route to go back to eclipselink?
We are using the webprofile version of the TomEE 7.01 with:
hibernate validation;
mojara;
eclipselink.
deltaspike-data-module.
Now studying how OpenJPA do things and reading the
"LazyInitializationException Hell" [1]
[1]
https://www.google.com.br/search?client=firefox-b&q=LazyInitializationException&oq=LazyInitializationException&gs_l=serp.3...26714.27166.0.27503.2.2.0.0.0.0.0.0..0.0....0...1c.1.64.serp..2.0.0.G4YKt3zUkdE
On 09/11/2016 17:40, Mark Struberg wrote:
> 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.broadhead@.co> 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.broadhead@.co>:
>>>> 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.
>>
--
View this message in context: http://openjpa.208410.n2.nabble.com/fetching-associations-tp7589828p7589916.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: fetching associations
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
it seems like quite a complicated example for my needs. I really just
wanted a simple way to view database data in JSF.
but i will try to push on...
BaseEntity implements two functions
public abstract Long getId();
public abstract Integer getOptlock();
my entities have id names like widget1Id, widget2Id, widget3Id. also i
have no such field as optlock. so how do i make a generic baseentity in
this case? do i need to include this in my database structure?
On 14/11/2016 23:03, Mark Struberg wrote:
> Hi Matthew!
>
> EclipseLink seems to open a new connection for lazy loading by using a new temporary EntityManager and Transaction. And no XA transaction afaik.
> Of course this is by far not a portable behaviour as neither Hibernate nor OpenJPA support this. I also have no clue how it behaves in case of an OptimisticLockException. I mean the lazy loading can literally happen a few minutes later...
>
> Whether to go back to EclipseLink is a question on how your whole application looks like. You did use a non-portable feature and of course it is now a bit harder to switch providers. But it's not impossible.
> The usual solution is to keep the EntityManager open for the whole request.
> How big is your app and how old is the codebase?
> Do you use XA or resource-local?
> Does it use many EJBs or do you already mainly use CDI?
>
> In case of the later you can use a @RequestScoped EntityManager + DeltaSpike @Transactional for example.
> https://deltaspike.apache.org/documentation/jpa.html
>
> Sample code
> With XA (JTA):
> https://github.com/struberg/lightweightEE/blob/jtacdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/tools/EntityManagerProducer.java#L35
> https://github.com/struberg/lightweightEE/blob/jtacdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/impl/EmployeeServiceImpl.java
> https://github.com/struberg/lightweightEE/blob/jtacdi11/backend-api/src/main/resources/META-INF/persistence.xml#L9
> https://github.com/struberg/lightweightEE/blob/jtacdi11/gui/src/main/tomee/conf/tomee.xml
>
> With ResourceLocal:
> https://github.com/struberg/lightweightEE/blob/cdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/tools/EntityManagerProducer.java
> https://github.com/struberg/lightweightEE/blob/cdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/impl/EmployeeServiceImpl.java
> https://github.com/struberg/lightweightEE/blob/cdi11/backend/src/main/resources/persistence-CaroLine.properties
> https://github.com/struberg/lightweightEE/blob/cdi11/backend-api/src/main/resources/META-INF/persistence.xml
>
>
> I also wrote a few blog posts which might help you understand this topic, e.g.
> https://struberg.wordpress.com/2015/04/21/transaction-and-exception-handling-in-ejbs-and-javaee7-transactional/
>
> Of course the entitymanager-per-request pattern also has a few limitations, e.g. if cannot lazy load data in subsequent responses (data has to be rendered during the initial request).
> But it's rather easy to prevent such a scenario. Usually you will only use Entities in CRUD dialogues anyway.
> I would e.g. _not_ use the entities in DataTables on a search dialogue. In that case I'd rather use a dedicated list item via SELECT NEW. This is much faster, has way less memory overhead and also will prevent you from a lot optimistic locking pain.
>
> Feel free to ask more questions, this is a rather complex and often not well enough understood topic.
>
> LieGrue,
> strub
>
>
>
>
>> Am 14.11.2016 um 20:12 schrieb Matthew Broadhead <ma...@nbmlaw.co.uk>:
>>
>> so if the managedbean is not an ejb anymore and therefore the transaction is closed how does it work for eclipselink? do they use some magic? are there any plans for implementing this "feature" in the future? after spending a few months migrating to myfaces and openjpa on the suggestion of romain i now find that openjpa cannot lazy load entities from jsf which is fairly disappointing to say the least. is my best route to go back to eclipselink?
>>
>> On 09/11/2016 17:40, Mark Struberg wrote:
>>> 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 <ma...@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
>>>> <ma...@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.
>>>>
Re: fetching associations
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
sorry just found it. my bad
On 15/11/2016 14:07, Matthew Broadhead wrote:
> Hi strub,
>
> i am making a test project using cdi. i am creating an equivalent of
> the EmployeeServiceImpl. it implements
> de.jaxenter.eesummit.caroline.backend.api.EmployeeService; which
> doesn't seem to be in the repository. am i missing something?
>
> Matthew
>
> On 14/11/2016 23:03, Mark Struberg wrote:
>> Hi Matthew!
>>
>> EclipseLink seems to open a new connection for lazy loading by using
>> a new temporary EntityManager and Transaction. And no XA transaction
>> afaik.
>> Of course this is by far not a portable behaviour as neither
>> Hibernate nor OpenJPA support this. I also have no clue how it
>> behaves in case of an OptimisticLockException. I mean the lazy
>> loading can literally happen a few minutes later...
>>
>> Whether to go back to EclipseLink is a question on how your whole
>> application looks like. You did use a non-portable feature and of
>> course it is now a bit harder to switch providers. But it's not
>> impossible.
>> The usual solution is to keep the EntityManager open for the whole
>> request.
>> How big is your app and how old is the codebase?
>> Do you use XA or resource-local?
>> Does it use many EJBs or do you already mainly use CDI?
>>
>> In case of the later you can use a @RequestScoped EntityManager +
>> DeltaSpike @Transactional for example.
>> https://deltaspike.apache.org/documentation/jpa.html
>>
>> Sample code
>> With XA (JTA):
>> https://github.com/struberg/lightweightEE/blob/jtacdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/tools/EntityManagerProducer.java#L35
>>
>> https://github.com/struberg/lightweightEE/blob/jtacdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/impl/EmployeeServiceImpl.java
>>
>> https://github.com/struberg/lightweightEE/blob/jtacdi11/backend-api/src/main/resources/META-INF/persistence.xml#L9
>>
>> https://github.com/struberg/lightweightEE/blob/jtacdi11/gui/src/main/tomee/conf/tomee.xml
>>
>>
>> With ResourceLocal:
>> https://github.com/struberg/lightweightEE/blob/cdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/tools/EntityManagerProducer.java
>>
>> https://github.com/struberg/lightweightEE/blob/cdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/impl/EmployeeServiceImpl.java
>>
>> https://github.com/struberg/lightweightEE/blob/cdi11/backend/src/main/resources/persistence-CaroLine.properties
>>
>> https://github.com/struberg/lightweightEE/blob/cdi11/backend-api/src/main/resources/META-INF/persistence.xml
>>
>>
>>
>> I also wrote a few blog posts which might help you understand this
>> topic, e.g.
>> https://struberg.wordpress.com/2015/04/21/transaction-and-exception-handling-in-ejbs-and-javaee7-transactional/
>>
>>
>> Of course the entitymanager-per-request pattern also has a few
>> limitations, e.g. if cannot lazy load data in subsequent responses
>> (data has to be rendered during the initial request).
>> But it's rather easy to prevent such a scenario. Usually you will
>> only use Entities in CRUD dialogues anyway.
>> I would e.g. _not_ use the entities in DataTables on a search
>> dialogue. In that case I'd rather use a dedicated list item via
>> SELECT NEW. This is much faster, has way less memory overhead and
>> also will prevent you from a lot optimistic locking pain.
>>
>> Feel free to ask more questions, this is a rather complex and often
>> not well enough understood topic.
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>> Am 14.11.2016 um 20:12 schrieb Matthew Broadhead
>>> <ma...@nbmlaw.co.uk>:
>>>
>>> so if the managedbean is not an ejb anymore and therefore the
>>> transaction is closed how does it work for eclipselink? do they use
>>> some magic? are there any plans for implementing this "feature" in
>>> the future? after spending a few months migrating to myfaces and
>>> openjpa on the suggestion of romain i now find that openjpa cannot
>>> lazy load entities from jsf which is fairly disappointing to say the
>>> least. is my best route to go back to eclipselink?
>>>
>>> On 09/11/2016 17:40, Mark Struberg wrote:
>>>> 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
>>>>> <ma...@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
>>>>> <ma...@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.
>>>>>
>
--
Matthew Broadhead
NBM Solicitors
See the latest jobs available at NBM @www.nbmlaw.co.uk/recruitment.htm
32 Rainsford Road
Chelmsford Essex CM1 2QG
Tel: 01245 269909 Fax: 01245 261932
www.nbmlaw.co.uk
Partners: WJ Broadhead NP Eason SJ Lacey CR Broadhead D Seepaul T Carley
NBM Solicitors are authorised and regulated by the Solicitors Regulation Authority. We are also bound by their code of conduct. Registered no. 00061052
NBM also provide a will writing service, see http://www.nbmlaw.co.uk/wills.htm for more information
Confidentiality
Information in this message is confidential and may be legally privileged. It is intended solely for the recipient to whom it is addressed. If you receive the message in error, please notify the sender and immediately destroy all copies.
Security warning
Please note that this e-mail has been created in the knowledge that e-mail is not a 100% secure communications medium. We advise you that you understand and observe this lack of security when e-mailing us. This e-mail does not constitute a legally binding document. No contracts may be concluded on behalf of Nigel Broadhead Mynard Solicitors by e-mail communications.
If you have any queries, please contact administrator@nbmlaw.co.uk
Re: fetching associations
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
Hi strub,
i am making a test project using cdi. i am creating an equivalent of
the EmployeeServiceImpl. it implements
de.jaxenter.eesummit.caroline.backend.api.EmployeeService; which doesn't
seem to be in the repository. am i missing something?
Matthew
On 14/11/2016 23:03, Mark Struberg wrote:
> Hi Matthew!
>
> EclipseLink seems to open a new connection for lazy loading by using a new temporary EntityManager and Transaction. And no XA transaction afaik.
> Of course this is by far not a portable behaviour as neither Hibernate nor OpenJPA support this. I also have no clue how it behaves in case of an OptimisticLockException. I mean the lazy loading can literally happen a few minutes later...
>
> Whether to go back to EclipseLink is a question on how your whole application looks like. You did use a non-portable feature and of course it is now a bit harder to switch providers. But it's not impossible.
> The usual solution is to keep the EntityManager open for the whole request.
> How big is your app and how old is the codebase?
> Do you use XA or resource-local?
> Does it use many EJBs or do you already mainly use CDI?
>
> In case of the later you can use a @RequestScoped EntityManager + DeltaSpike @Transactional for example.
> https://deltaspike.apache.org/documentation/jpa.html
>
> Sample code
> With XA (JTA):
> https://github.com/struberg/lightweightEE/blob/jtacdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/tools/EntityManagerProducer.java#L35
> https://github.com/struberg/lightweightEE/blob/jtacdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/impl/EmployeeServiceImpl.java
> https://github.com/struberg/lightweightEE/blob/jtacdi11/backend-api/src/main/resources/META-INF/persistence.xml#L9
> https://github.com/struberg/lightweightEE/blob/jtacdi11/gui/src/main/tomee/conf/tomee.xml
>
> With ResourceLocal:
> https://github.com/struberg/lightweightEE/blob/cdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/tools/EntityManagerProducer.java
> https://github.com/struberg/lightweightEE/blob/cdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/impl/EmployeeServiceImpl.java
> https://github.com/struberg/lightweightEE/blob/cdi11/backend/src/main/resources/persistence-CaroLine.properties
> https://github.com/struberg/lightweightEE/blob/cdi11/backend-api/src/main/resources/META-INF/persistence.xml
>
>
> I also wrote a few blog posts which might help you understand this topic, e.g.
> https://struberg.wordpress.com/2015/04/21/transaction-and-exception-handling-in-ejbs-and-javaee7-transactional/
>
> Of course the entitymanager-per-request pattern also has a few limitations, e.g. if cannot lazy load data in subsequent responses (data has to be rendered during the initial request).
> But it's rather easy to prevent such a scenario. Usually you will only use Entities in CRUD dialogues anyway.
> I would e.g. _not_ use the entities in DataTables on a search dialogue. In that case I'd rather use a dedicated list item via SELECT NEW. This is much faster, has way less memory overhead and also will prevent you from a lot optimistic locking pain.
>
> Feel free to ask more questions, this is a rather complex and often not well enough understood topic.
>
> LieGrue,
> strub
>
>
>
>
>> Am 14.11.2016 um 20:12 schrieb Matthew Broadhead <ma...@nbmlaw.co.uk>:
>>
>> so if the managedbean is not an ejb anymore and therefore the transaction is closed how does it work for eclipselink? do they use some magic? are there any plans for implementing this "feature" in the future? after spending a few months migrating to myfaces and openjpa on the suggestion of romain i now find that openjpa cannot lazy load entities from jsf which is fairly disappointing to say the least. is my best route to go back to eclipselink?
>>
>> On 09/11/2016 17:40, Mark Struberg wrote:
>>> 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 <ma...@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
>>>> <ma...@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.
>>>>
--
Matthew Broadhead
NBM Solicitors
See the latest jobs available at NBM @www.nbmlaw.co.uk/recruitment.htm
32 Rainsford Road
Chelmsford Essex CM1 2QG
Tel: 01245 269909 Fax: 01245 261932
www.nbmlaw.co.uk
Partners: WJ Broadhead NP Eason SJ Lacey CR Broadhead D Seepaul T Carley
NBM Solicitors are authorised and regulated by the Solicitors Regulation Authority. We are also bound by their code of conduct. Registered no. 00061052
NBM also provide a will writing service, see http://www.nbmlaw.co.uk/wills.htm for more information
Confidentiality
Information in this message is confidential and may be legally privileged. It is intended solely for the recipient to whom it is addressed. If you receive the message in error, please notify the sender and immediately destroy all copies.
Security warning
Please note that this e-mail has been created in the knowledge that e-mail is not a 100% secure communications medium. We advise you that you understand and observe this lack of security when e-mailing us. This e-mail does not constitute a legally binding document. No contracts may be concluded on behalf of Nigel Broadhead Mynard Solicitors by e-mail communications.
If you have any queries, please contact administrator@nbmlaw.co.uk
Re: fetching associations
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Hi Matthew!
EclipseLink seems to open a new connection for lazy loading by using a new temporary EntityManager and Transaction. And no XA transaction afaik.
Of course this is by far not a portable behaviour as neither Hibernate nor OpenJPA support this. I also have no clue how it behaves in case of an OptimisticLockException. I mean the lazy loading can literally happen a few minutes later...
Whether to go back to EclipseLink is a question on how your whole application looks like. You did use a non-portable feature and of course it is now a bit harder to switch providers. But it's not impossible.
The usual solution is to keep the EntityManager open for the whole request.
How big is your app and how old is the codebase?
Do you use XA or resource-local?
Does it use many EJBs or do you already mainly use CDI?
In case of the later you can use a @RequestScoped EntityManager + DeltaSpike @Transactional for example.
https://deltaspike.apache.org/documentation/jpa.html
Sample code
With XA (JTA):
https://github.com/struberg/lightweightEE/blob/jtacdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/tools/EntityManagerProducer.java#L35
https://github.com/struberg/lightweightEE/blob/jtacdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/impl/EmployeeServiceImpl.java
https://github.com/struberg/lightweightEE/blob/jtacdi11/backend-api/src/main/resources/META-INF/persistence.xml#L9
https://github.com/struberg/lightweightEE/blob/jtacdi11/gui/src/main/tomee/conf/tomee.xml
With ResourceLocal:
https://github.com/struberg/lightweightEE/blob/cdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/tools/EntityManagerProducer.java
https://github.com/struberg/lightweightEE/blob/cdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/impl/EmployeeServiceImpl.java
https://github.com/struberg/lightweightEE/blob/cdi11/backend/src/main/resources/persistence-CaroLine.properties
https://github.com/struberg/lightweightEE/blob/cdi11/backend-api/src/main/resources/META-INF/persistence.xml
I also wrote a few blog posts which might help you understand this topic, e.g.
https://struberg.wordpress.com/2015/04/21/transaction-and-exception-handling-in-ejbs-and-javaee7-transactional/
Of course the entitymanager-per-request pattern also has a few limitations, e.g. if cannot lazy load data in subsequent responses (data has to be rendered during the initial request).
But it's rather easy to prevent such a scenario. Usually you will only use Entities in CRUD dialogues anyway.
I would e.g. _not_ use the entities in DataTables on a search dialogue. In that case I'd rather use a dedicated list item via SELECT NEW. This is much faster, has way less memory overhead and also will prevent you from a lot optimistic locking pain.
Feel free to ask more questions, this is a rather complex and often not well enough understood topic.
LieGrue,
strub
> Am 14.11.2016 um 20:12 schrieb Matthew Broadhead <ma...@nbmlaw.co.uk>:
>
> so if the managedbean is not an ejb anymore and therefore the transaction is closed how does it work for eclipselink? do they use some magic? are there any plans for implementing this "feature" in the future? after spending a few months migrating to myfaces and openjpa on the suggestion of romain i now find that openjpa cannot lazy load entities from jsf which is fairly disappointing to say the least. is my best route to go back to eclipselink?
>
> On 09/11/2016 17:40, Mark Struberg wrote:
>> 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 <ma...@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
>>> <ma...@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.
>>>
Re: fetching associations
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
so if the managedbean is not an ejb anymore and therefore the
transaction is closed how does it work for eclipselink? do they use
some magic? are there any plans for implementing this "feature" in the
future? after spending a few months migrating to myfaces and openjpa on
the suggestion of romain i now find that openjpa cannot lazy load
entities from jsf which is fairly disappointing to say the least. is my
best route to go back to eclipselink?
On 09/11/2016 17:40, Mark Struberg wrote:
> 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 <ma...@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
>> <ma...@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.
>>
Re: fetching associations
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
can you point me to any examples of a strategy i can use which will give
it the same behaviour as eclipselink? ideally i want to grab the
objects and view them in jsf without any messing around
On 09/11/2016 17:40, Mark Struberg wrote:
> 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 <ma...@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
>> <ma...@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.
>>
Re: fetching associations
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <ma...@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
> <ma...@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.
>
Re: fetching associations
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
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 <ma...@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.
Re: fetching associations
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <ma...@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.