What is that client where you talk about? Do you have a App server that contains the EJB and a App/Web server == client? that runs wicket?Why does this happen:Now if an Instance of BeanB is passed to a wicket component the following occurs
a) The BeanB instance is detached from the transaction
I want to add some thoughts about how NOT to do it. Its for completeness
sake.
@entiy
class BeanB ...
private BeanA;
@ManyToOne(fetch=FetchType.LAZY)
public BeanA getBeanA()
I solved the problem with fetch=FetchType.EAGER. This has a serious impact
We have planned to look at this issue because we also want to use a pure EJB3
implementation. But there are some other issues with the EJB3 specification
that makes it almost useless for production applications:
- it does not have a simple solution for value converters, so converting for
It doesn't matter if the Web-Layer is on a separate machin eor VM,
it just depends on the availability of a PersistenceContext, which is,
in all cases i encountered so far, equivalent to a EJB-Transaction.
I.e., while in a transaction, you are free to call /load any relations,
w/o getting nasty
I think this is exactly how Seam deals w/ the problemwhat I
don't understand is then; why would they be pushing it as an
enterprise solution for JSF + EJB3? If it wouldn't scale, assuming
this is how Seam works, then it would be useless in a high-concurrency
environment.
Also, JBoss is
Maybe Nathan's DataBinder project could serve as a starting point there?
Eelco
On 6/1/06, Vincent Jenks [EMAIL PROTECTED] wrote:
I think this is exactly how Seam deals w/ the problemwhat I
don't understand is then; why would they be pushing it as an
enterprise solution for JSF + EJB3? If
I've been meaning to take a look at that and I think I will this
weekend. I have another internal project here at work I'd like to
convert to Wicket (currently uses very crude servlet+JSP MVC approach)
- and it uses Hibernate.
On 6/1/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Maybe Nathan's
You can't just set all of your collections to be eagerly loaded, that is most definitely *not* the solution...and is in 99% of cases, a bad idea. You're better off doing separate queries for the exact data you need as opposed to eagerly-loading everything + the kitchen sink. You can only
