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 =>
          bean.someBusinessMethod()
  }

  result.openOrElse(SomeOtherValue)
}


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


@Stateless
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 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to