Unfortunately, I'm still living in EJB land, and therefore would prefer
something to bridge the gap (between legacy and new code).  Goatrodeo looks
very exciting, but something for our next new component.

I actually had a layer I was using between our EJB beans + LIft that perhaps
with some time I can re-write in a open-source setting.  I make no promises
on time, but I do see interfacing with legacy systems as being a huge win
for promoting lift/scala use in the enterprise.  Basically, my Lift->EJB
Layer looked like the following:

import EJBHelper._

def retreiveSomeValue = {

   val result = withBean[BeanLocalInterface] { bean =>


What I'd like is to be able to migrate scala further down my EJB stack when
refactoring.  For example:

class MyBean extends MyBeanLocal with ScalaEJBHelper {

   def getMyData(id : Long) {
         (for {
             tx <- transaction(JOIN_OR_NEW)
             result <- ejb_single_query("from MyDataBean where MyDataBean.id
= ?") % id
         } yield result).first

At least until it becomes more acceptable/feasible to migrate to better
solutions than EJB.

- Josh

On Fri, May 29, 2009 at 11:36 PM, David Pollak <
feeder.of.the.be...@gmail.com> wrote:

> On Fri, May 29, 2009 at 7:19 PM, Josh Suereth <joshua.suer...@gmail.com>wrote:
>> +30000000000000
> See http://github.com/dpp/goatrodeo/tree/master

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to