Thought yall might find this useful, but beware of the side-effects of DOOM!
:o)
| protected static void loadChildren(Object obj, int loadLevel) {
| if(loadLevel > 0) {
| Method[] methods = obj.getClass().getDeclaredMethods();
| Object r
I'm doing something similar. However, I notice that you are making sure the
items actual get loaded via
this.getOrders().size();
Have you found that this does not in fact do anything when compiled and run due
to Java optimizations? This was previously posted about on this thread and
still h
Hi, Marin,
Your idea of LoadLevel is a a great idea. It solved most of my problems.
Here is my approch for a tipical senario of Customer-Order-LineItem-Product.
only one session bean is needed, all the business rules are at the server
side(EjbAction).
public interface BaseEntity extends Serial
If you have this scenario:
A is associated with C. B is associated with D. B extends A.
A, B, C and D are Entity Beans. A and B use the JOINED strategy for Inheritance.
What is the best way to represent this kind of scenario with Session Beans?
I thought about these 3 possibilities:
1- 4 Session
Hi again.
I tried this solution:
I set all relations in entity beans to LAZY. and any references to relations as
"transient". So serialization makes them null when they are sent to client.
On the client side I check if the refernce is null I call some session bean
method to fill it. I do this ins
i haven't checked it yet as i'm not in the office for the moment but maybe an
optimization of java is not to actually return the result when it's not
necessasry (in the first case you don't use the result of a.getListB())
i'll try the code in the office today and i'll let you know
View the orig
@Phon: I found something useful in EJB3 trailblazer
http://trailblazer.demo.jboss.com/EJB3Trail/services/apptrans/index.html
Im testing the loadlevel solution with a simple application:
There are 4 entities A,B,C,D.
A has OneToMany associations with both B and D (C extends A, i'll use it for
oth
where can i read more about an Extended EJB3 Persistence Context ? Does it put
the client and server in the same "session" so you don't have to implicitly
inialize lazy attributes that you may need on the client ?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p
No, it is absolutely not possible.
Use a Seam-managed extended persistence context to solve this problem (or an
EJB3 extended persistence context).
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3911822#3911822
Reply to the post :
http://www.jboss.com/index.
Just a thought... I do not know enough about the Hibernate internals to
determine if this is a viable solution, but it seems to me that Lazy loading of
detached objects is a concern best addressed by Hibernate itself.
Would it be possible to modify hibernate (at the cache, Proxy, Session or CGLI
yes, the cascade (but not lazy, because let's say you want to display some
parts of relations but to update only one object on the tree)
if you update the relations on the detached part ... and you call merge ...
also the cascaded relations with MERGE | ALL are propagated .. so this creates
a l
"pego" wrote :
| Im approaching to design the server "session side" of an application.
| I've already done the "persistence side" using entity bean and it is quite
complex (a lot of hierarchies and associations between entities).
|
again, i'm in the same situation as you are :) i finishe
another issue is the propagation of relations ...
if something wrong is done in client on the relations of object to be merged -
those relations are also merged ...
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3911502#3911502
Reply to the post :
http://www
IMHO the load-level solution is the best: fast, effective and clean.
I have a question, probably a little off-topic (however it's about ejb3
design)... :)
Im approaching to design the server "session side" of an application.
I've already done the "persistence side" using entity bean and it is q
Hey guys,
forget about catching lazy load exceptions in the client! This is something
that you might can implement but take a look at you client code!!
It will look terrible (especially if you have complex hierarchies) and you
always have to add new or remove code if you change the fetch strateg
Hi again.
I've tried to do what I've written above and
I can't catch Lazy exception. Even if i catch "Exception" on highest possible
level, it is throwed probably because it is on server side and on client only
redisplayed ???
I don't know
View the original post :
http://www.jboss.com/index
i agree with heinrich
i think it's a way that could work but i think it's better to make your
structure so that no exceptions are thrown (as heinrich said, you know when
they will be thrown)..
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3911250#3911250
Rep
Hmm, ok,
i think this would work.
Although this is not very nice. Why to use exception handling when you know
when there is no nested data available?
But just do as you think and give leave us a note how it works.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p
HI all!!
My idea is to keep Entity Beans in client side and set fetch to LAZY.
Session Beans returns Entity Instances with empty references.
If I get empty reference I catch Lazy exception and call another session bean
method that returns full reference and I replace empty reference with return
v
Hello,
thank you for your positive response.
In my application by using the load level strategy I only see the solution to
fetch the whole object again - even if you already have half of the data.
This is not very effective but it is easy to handle.
Books:
As far as I know there are no books
i'm developping a similar application (java GUI and EJB3 server) and i'm
struggling with the same problem..
My Customer object has lot of nested objects (Address, SaleCondition, etc) and
right now i just grabbed the whole object in one fetch when returning query
results, which i can't keep doin
Hmm, ok i have to check this.
But sounds good :-)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3910926#3910926
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3910926
---
Hello Heinrich,
from my point of view you don't need a load level within insert or update
methods at all. You define the strategy that nested objects will be handeled
when persisting in the entity beans by using the cascade type!
In my existing app (for example) I have a CustomerOrder entity bea
Sure =)
i thought about if there are these methodes containing the loadlevel to obtain
entities, there must be methods containing the loadlevel to store entities
because the methods normaly do not know which nested objects are available.
Know you can think about my confusing last post :-)
I do
Hello heinrich,
I must admit that I don't understand exactly what you want to tell me.
But from my point of view persisting and/or merging an entity bean is not the
problem when working with a remote client. You just have to build a proper
remote method that covers that issue.
Example:
| Cus
Hi Martin,
not a bad idea. I think i will try to use it.
But when we do it like this to read out Beans we also need an appropriate
method to store beans.
I it is not sufficiant so store a transfered new entity just by using
| em.persiste(myNewCreatedEntity);
|
with nested classes.
| Enti
Hello,
yesterday I was thinking about another approach that I will might consider for
my apps with remote clients. Heinrich wrote that he creates different accessor
methods in session beans for different use cases.
Wouldn't it be nice to use only one method?
Example:
Let's assume one has a comp
Hello,
I agree with heinrich. The approach with the id is very strange.
If you work on a remote client there are only two possible ways to work with
ejb:
1. Working with Value Objects
Build different value objects for every use case. A value object consists of
one or more entity objects and ma
hi,
i do not exactly understand why in the first case the business logic is on
client side.
The entity methods are probably the getters and setters. In my opinion this is
no business logic.
The fact, that when entities are changed the client has also to be changes is
ok. But thats not so signif
29 matches
Mail list logo
