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 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 "problem"....what 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 pushing for a new JSR standard called "Web Beans" based > on the work they've done w/ Seam...so there must be a lot we're > assuming incorrectly about how Seam works....or what the best solution > for this issue would be. > > Perhaps it's another, independent framework entirely outside of > Wicket....Wicket really isn't the issue (though it'd be nice to have a > clean, simple, transparent solution that Wicket could use...it'd make > it all the more appealing for large EJB3-based projects!) > > On 6/1/06, Marco Geier <[EMAIL PROTECTED]> wrote: > > 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 errors. > > So if you don't use a Client-UserTransaction (which is possible, but not > > recommended), a call to any SessionBean which returns any bean will > > implicitly starts a transaction and closes it when the method returns. > > > > So in order to have a "seam-like" behaviour, we should look at the EJB3 > > "Extended" PersistenceContext, that somehow allows re-attaching beans > > (sorry, didn't use that stuff yet, so no experiences). > > > > But still, for performance and concurrency reasons, the main point is: > > > > *When do i start/end my transactions* > > > > One might be tempted (as i was) to just wrap the whole requestcycle into > > one transaction. That works fine, almost no headaches with lazy loading, > > but really doesn't scale because transactions last too long. > > So what i do right now is to have a layer of sepcialized gui-related > > SessionBeans that return *completely initialized* beans, i.e. beans that > > already have any collection loaded that will be needed in the page. > > This is, of course, a pain in the a.., but right now i don't see any > > other solution... > > > > Marco > > > > > > > > > > > > > > > > > > Johan Compagner wrote: > > > 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 context of the > > > app server. There is no way to avoid this. > > > > > > ?? If i ask the persistence layer for BeanB does it open a session get B > > > close the session and then return B? > > > > > > that would be awfull. > > > > > > johan > > > > > > > > > On 6/1/06, Stefan Lindner <[EMAIL PROTECTED]> wrote: > > > > > >> > > >> Dear suffering lazy loaders, > > >> > > >> I want to start a new thread with a discussion that is focused on EJB3 > > >> (not Spring, not Hibernate) because all those "In Hibernate it works like > > >> this..." hints are not helpful. To clearyfy this: > > >> 1. EJB3 is NOT Hibernate. Yes, the EJB3 implementation of JBoss is based > > >> upon Hibernate but other vendors do NOT use Hibernate. > > >> 2. Since Wicket is platform independent, an EJB3 solution for Wicket > > >> should be independent too. > > >> 3. The Problem arises when a Bean references another bean as an object > > >> through a relation: For Example > > >> > > >> SQL: > > >> create table A (id integer, value varchar(100) > > >> create table B (id integer, value varchar(100), ref_to_a integer) > > >> alter table B add constraint ArefB ref_to_a references A(id) > > >> > > >> JAVA > > >> @entity > > >> class BeanA .... > > >> public int getId() > > >> public void setId() > > >> > > >> @entiy > > >> class BeanB ... > > >> private BeanA; > > >> @ManyToOne(fetch=FetchType.LAZY) > > >> public BeanA getBeanA() > > >> > > >> Now if an Instance of BeanB is passed to a wicket component the > > >> following occurs > > >> a) The BeanB instance is detached from the transaction context of the > > >> app server. There is no way to avoid this. > > >> b) The instance of BeanB does not contain a complete BeanA > > >> c) The access of BeanB.getBeanA().getId will throw a > > >> LazyInitaliaziationException > > >> > > >> 4. It is not possible (correct me if I am wrong) to have a EJB3 > > >> transaction on the client. This means it is not possible to bring back > > >> the > > >> BeanB instance into an attached state on the client. > > >> 5. The only solutions I can see may be the following: > > >> a) Find some way of putting an interceptor in the access method for > > >> lazy loades attributes and let the server so the loading in the catch > > >> bock > > >> b) Wrap a try/catch block around the access and let the server so the > > >> loading in the catch bock > > >> c) never do a direct access. Always send the bean back to the server > > >> and do the loading on the server > > >> > > >> All three solutions need the server to do the lazy loading. > > >> 6. Just to clearify: Not Wicket is the problem. The problem lies in the > > >> design of EJB3 lazy loading itself. Any client application has the same > > >> problem in principal. > > >> > > >> Is this correct until this point? Only after we come to a clear > > >> definition > > >> of the problem we may find a way to solve it. Any suggests are welcome. > > >> Please help us to use wicket and EJB3 in a better way. > > >> > > >> Stefan Lindner > > >> > > >> > > > > > > > -- > > ___________________________ > > > > Dipl.-Ing. Marco Geier > > EyeTea GmbH > > Germany > > phone +49 (0)721 662464-0 > > fax +49 (0)721 662464-1 > > mobile +49 (0)177 6579590 > > [EMAIL PROTECTED] > > > > > > ------------------------------------------------------- > > All the advantages of Linux Managed Hosting--Without the Cost and Risk! > > Fully trained technicians. The highest number of Red Hat certifications in > > the hosting industry. Fanatical Support. Click to learn more > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 > > _______________________________________________ > > Wicket-user mailing list > > Wicket-user@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > > ------------------------------------------------------- > All the advantages of Linux Managed Hosting--Without the Cost and Risk! > Fully trained technicians. The highest number of Red Hat certifications in > the hosting industry. Fanatical Support. Click to learn more > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 > _______________________________________________ > Wicket-user mailing list > Wicket-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-user > ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
