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
<matthew.broadh...@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
<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.
--
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 administra...@nbmlaw.co.uk