Google App Engine for Scala!

Lift just got extremely interesting for me personally.   <dances/>

From: Walter Chang [mailto:weihsiu [at] gmail [dot] com]
Sent: 08 April 2009 07:45
To: Scala list
Subject: [scala] Google App Engine for Scala!

well, google app engine for java is out and according to this blog: http://feeds2.feedburner.com/GoogleAppEngineBlog, they wanted scala to run on it as well.  has anyone tried it?  i read it on groovy and jruby blogs that they need to do some modifications before they can run on GAE, how about scala?

walter
--
.......__o
.......\<,
....( )/ ( )...

============================

A BNY Mellon Company(SM). Pareto Investment Management Limited is authorised and regulated by the Financial Services Authority (Firm Ref. No. 416024), and registered in England and Wales with Number 03169281. Registered Office: Mellon Financial Centre, 160 Queen Victoria Street, London EC4V 4LA, United Kingdom. Pareto is the registered trademark of Pareto Investment Management Limited. This message may contain confidential and privileged information and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorised. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator and then immediately delete this message.

 

2009/4/8 Kieron Wilkinson :
> Lift just got extremely interesting for me personally.
>
>

Can Lift deal with the security settings? In particular its heavy use
of actors sounds like it would play badly with "A Java application
cannot create a new java.lang.ThreadGroup nor a new java.lang.Thread.
These restrictions also apply to JRE classes that make use of threads.
For example, an application cannot create a new
java.util.concurrent.ThreadPoolExecutor, or a java.util.Timer."
(http://code.google.com/appengine/docs/java/runtime.html#The_Sandbox)

Isn't one of the selling points of actors that it is not necessarily
tied to threads? So (being far too optimistic I know) perhaps it can be
made to scale accordingly by allowing just the current thread for it to
use? I suppose it depends on how Lift is written, and I am getting my
hopes up far to early I know. However, given that the GAE is such a
developer magnet, I would guess that the Lift team would try to support
it if it is practical to do so...

On reading further on the documentation of GAE, it sounds a bit like it
is best suited for short-running user-driven requests. I don't know the
aritecture of Lift, so I guess it would depend on that too.

> -----Original Message-----
> From: David MacIver [mailto:david [dot] maciver [at] gmail [dot] com]
> Sent: 08 April 2009 09:19
> To: Kieron Wilkinson
> Cc: Walter Chang; Scala list
> Subject: Re: [scala] Google App Engine for Scala!
>
> 2009/4/8 Kieron Wilkinson :
> > Lift just got extremely interesting for me personally.
> >
> >
>
> Can Lift deal with the security settings? In particular its heavy use
> of actors sounds like it would play badly with "A Java application
> cannot create a new java.lang.ThreadGroup nor a new java.lang.Thread.
> These restrictions also apply to JRE classes that make use of threads.
> For example, an application cannot create a new
> java.util.concurrent.ThreadPoolExecutor, or a java.util.Timer."
> (http://code.google.com/appengine/docs/java/runtime.html#The_Sandbox)
>

============================
A BNY Mellon Company(SM). Pareto Investment Management Limited is authorised and regulated by the Financial Services Authority (Firm Ref. No. 416024), and registered in England and Wales with Number 03169281. Registered Office: Mellon Financial Centre, 160 Queen Victoria Street, London EC4V 4LA, United Kingdom. Pareto is the registered trademark of Pareto Investment Management Limited. This message may contain confidential and privileged information and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorised. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator and then immediately delete this message.

Kieron Wilkinson wrote:
> Isn't one of the selling points of actors that it is not necessarily
> tied to threads? So (being far too optimistic I know) perhaps it can be
> made to scale accordingly by allowing just the current thread for it to
> use? I suppose it depends on how Lift is written, and I am getting my
> hopes up far to early I know. However, given that the GAE is such a
> developer magnet, I would guess that the Lift team would try to support
> it if it is practical to do so...
>
> On reading further on the documentation of GAE, it sounds a bit like it
> is best suited for short-running user-driven requests. I don't know the
> aritecture of Lift, so I guess it would depend on that too.
>
>
Hi,

We made some experiments with Lift and Scala (I'm sure it will be
blogged soon).
The consensus was that Lift doesn't really work at all - the Thread
restrictions are just too hard.

You can definitely use Scala, though, and it runs without trouble as
long as you stay away from the things that need Thread or ThreadGroup.

Cheers

I think there would have to be a possibilty to create at least one additiional thread and still you could only use react/loop event based actors.

Maybe GAE could (in the future realeases) precreate a small pool of threads....

In general what is so unsafe in giving the ability to create threads if you limit the number of them?

Szymon

On Wed, Apr 8, 2009 at 10:37 AM, Kieron Wilkinson <Kieron [dot] Wilkinson [at] paretopartners [dot] com> wrote:

Isn't one of the selling points of actors that it is not necessarily
tied to threads? So (being far too optimistic I know) perhaps it can be
made to scale accordingly by allowing just the current thread for it to
use? I suppose it depends on how Lift is written, and I am getting my
hopes up far to early I know. However, given that the GAE is such a
developer magnet, I would guess that the Lift team would try to support
it if it is practical to do so...

On reading further on the documentation of GAE, it sounds a bit like it
is best suited for short-running user-driven requests. I don't know the
aritecture of Lift, so I guess it would depend on that too.

> -----Original Message-----
> From: David MacIver [mailto:david [dot] maciver [at] gmail [dot] com]
> Sent: 08 April 2009 09:19
> To: Kieron Wilkinson
> Cc: Walter Chang; Scala list
> Subject: Re: [scala] Google App Engine for Scala!
>
> 2009/4/8 Kieron Wilkinson <Kieron [dot] Wilkinson [at] paretopartners [dot] com>:
> > Lift just got extremely interesting for me personally.
> >
> > <dances/>
>
> Can Lift deal with the security settings? In particular its heavy use
> of actors sounds like it would play badly with "A Java application
> cannot create a new java.lang.ThreadGroup nor a new java.lang.Thread.
> These restrictions also apply to JRE classes that make use of threads.
> For example, an application cannot create a new
> java.util.concurrent.ThreadPoolExecutor, or a java.util.Timer."
> (http://code.google.com/appengine/docs/java/runtime.html#The_Sandbox)
>

============================
A BNY Mellon Company(SM). Pareto Investment Management Limited is authorised and regulated by the Financial Services Authority (Firm Ref. No. 416024), and registered in England and Wales with Number 03169281. Registered Office: Mellon Financial Centre, 160 Queen Victoria Street, London EC4V 4LA, United Kingdom. Pareto is the registered trademark of Pareto Investment Management Limited. This message may contain confidential and privileged information and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorised. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator and then immediately delete this message.

--
ʎɐqǝ uo pɹɐoqʎǝʞ ɐ ʎnq ı ǝɯıʇ ʇsɐן ǝɥʇ sı sıɥʇ

Google has posted a
http://groups.google.com/group/google-appengine-java/web/will-it-play-in...
list of supported frameworks .

David MacIver wrote:
>
> 2009/4/8 Kieron Wilkinson :
>> Lift just got extremely interesting for me personally.
>>
>>
>
> Can Lift deal with the security settings? In particular its heavy use
> of actors sounds like it would play badly with "A Java application
> cannot create a new java.lang.ThreadGroup nor a new java.lang.Thread.
> These restrictions also apply to JRE classes that make use of threads.
> For example, an application cannot create a new
> java.util.concurrent.ThreadPoolExecutor, or a java.util.Timer."
> (http://code.google.com/appengine/docs/java/runtime.html#The_Sandbox)
>
>

Kieron Wilkinson wrote:
> Isn't one of the selling points of actors that it is not necessarily
> tied to threads? So (being far too optimistic I know) perhaps it can be
> made to scale accordingly by allowing just the current thread for it to
> use? I suppose it depends on how Lift is written, and I am getting my
> hopes up far to early I know. However, given that the GAE is such a
> developer magnet, I would guess that the Lift team would try to support
> it if it is practical to do so...

Indeed, one can override the def `scheduler` in the `Actor` trait and
provide an `IScheduler` (for instance, using `SchedulerAdapter`) that
uses only the current thread to execute the message handlers.

Cheers,
Philipp

>> -----Original Message-----
>> From: David MacIver [mailto:david [dot] maciver [at] gmail [dot] com]
>> Sent: 08 April 2009 09:19
>> To: Kieron Wilkinson
>> Cc: Walter Chang; Scala list
>> Subject: Re: [scala] Google App Engine for Scala!
>>
>> 2009/4/8 Kieron Wilkinson :
>>> Lift just got extremely interesting for me personally.
>>>
>>>
>> Can Lift deal with the security settings? In particular its heavy use
>> of actors sounds like it would play badly with "A Java application
>> cannot create a new java.lang.ThreadGroup nor a new java.lang.Thread.
>> These restrictions also apply to JRE classes that make use of threads.
>> For example, an application cannot create a new
>> java.util.concurrent.ThreadPoolExecutor, or a java.util.Timer."
>> (http://code.google.com/appengine/docs/java/runtime.html#The_Sandbox)
>>
>
> ============================
> A BNY Mellon Company(SM). Pareto Investment Management Limited is authorised and regulated by the Financial Services Authority (Firm Ref. No. 416024), and registered in England and Wales with Number 03169281. Registered Office: Mellon Financial Centre, 160 Queen Victoria Street, London EC4V 4LA, United Kingdom. Pareto is the registered trademark of Pareto Investment Management Limited. This message may contain confidential and privileged information and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorised. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator and then immediately delete this message.
>

Philipp,
I look forward to the day you get time to write a more complete and up-to-date manual for the Actors API than exists at the moment, in which you include tips like the one below; the scaladoc, papers and Prog' in Scala book only get you so far.
Rob

2009/4/8 Philipp Haller <philipp [dot] haller [at] epfl [dot] ch>

Kieron Wilkinson wrote:

Isn't one of the selling points of actors that it is not necessarily
tied to threads? So (being far too optimistic I know) perhaps it can be
made to scale accordingly by allowing just the current thread for it to
use? I suppose it depends on how Lift is written, and I am getting my
hopes up far to early I know. However, given that the GAE is such a
developer magnet, I would guess that the Lift team would try to support
it if it is practical to do so...

Indeed, one can override the def `scheduler` in the `Actor` trait and provide an `IScheduler` (for instance, using `SchedulerAdapter`) that uses only the current thread to execute the message handlers.

Cheers,
Philipp

-----Original Message-----
From: David MacIver [mailto:david [dot] maciver [at] gmail [dot] com] Sent: 08 April 2009 09:19
To: Kieron Wilkinson
Cc: Walter Chang; Scala list
Subject: Re: [scala] Google App Engine for Scala!

2009/4/8 Kieron Wilkinson <Kieron [dot] Wilkinson [at] paretopartners [dot] com>:

Lift just got extremely interesting for me personally.

<dances/>

Can Lift deal with the security settings? In particular its heavy use
of actors sounds like it would play badly with "A Java application
cannot create a new java.lang.ThreadGroup nor a new java.lang.Thread.
These restrictions also apply to JRE classes that make use of threads.
For example, an application cannot create a new
java.util.concurrent.ThreadPoolExecutor, or a java.util.Timer."
(http://code.google.com/appengine/docs/java/runtime.html#The_Sandbox)

============================
A BNY Mellon Company(SM). Pareto Investment Management Limited is authorised and regulated by the Financial Services Authority (Firm Ref. No. 416024), and registered in England and Wales with Number 03169281. Registered Office: Mellon Financial Centre, 160 Queen Victoria Street, London EC4V 4LA, United Kingdom. Pareto is the registered trademark of Pareto Investment Management Limited. This message may contain confidential and privileged information and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorised. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator and then immediately delete this message.

Probably for the same reason you don't create threads in EJBs.  The idea being that you let someone *else* scala your application, and if you're creating resources they're going to use to scala you, well you're shooting your own foot in that case. 

To use magic, you must give up something.  Otherwise I'd be farming.

- Josh

On Wed, Apr 8, 2009 at 5:10 AM, Szymon Jachim <sjachim [at] gmail [dot] com> wrote:

I think there would have to be a possibilty to create at least one additiional thread and still you could only use react/loop event based actors.

Maybe GAE could (in the future realeases) precreate a small pool of threads....

In general what is so unsafe in giving the ability to create threads if you limit the number of them?

Szymon

On Wed, Apr 8, 2009 at 10:37 AM, Kieron Wilkinson <Kieron [dot] Wilkinson [at] paretopartners [dot] com> wrote:

Isn't one of the selling points of actors that it is not necessarily
tied to threads? So (being far too optimistic I know) perhaps it can be
made to scale accordingly by allowing just the current thread for it to
use? I suppose it depends on how Lift is written, and I am getting my
hopes up far to early I know. However, given that the GAE is such a
developer magnet, I would guess that the Lift team would try to support
it if it is practical to do so...

On reading further on the documentation of GAE, it sounds a bit like it
is best suited for short-running user-driven requests. I don't know the
aritecture of Lift, so I guess it would depend on that too.

> -----Original Message-----
> From: David MacIver [mailto:david [dot] maciver [at] gmail [dot] com]
> Sent: 08 April 2009 09:19
> To: Kieron Wilkinson
> Cc: Walter Chang; Scala list
> Subject: Re: [scala] Google App Engine for Scala!
>
> 2009/4/8 Kieron Wilkinson <Kieron [dot] Wilkinson [at] paretopartners [dot] com>:
> > Lift just got extremely interesting for me personally.
> >
> > <dances/>
>
> Can Lift deal with the security settings? In particular its heavy use
> of actors sounds like it would play badly with "A Java application
> cannot create a new java.lang.ThreadGroup nor a new java.lang.Thread.
> These restrictions also apply to JRE classes that make use of threads.
> For example, an application cannot create a new
> java.util.concurrent.ThreadPoolExecutor, or a java.util.Timer."
> (http://code.google.com/appengine/docs/java/runtime.html#The_Sandbox)
>

============================
A BNY Mellon Company(SM). Pareto Investment Management Limited is authorised and regulated by the Financial Services Authority (Firm Ref. No. 416024), and registered in England and Wales with Number 03169281. Registered Office: Mellon Financial Centre, 160 Queen Victoria Street, London EC4V 4LA, United Kingdom. Pareto is the registered trademark of Pareto Investment Management Limited. This message may contain confidential and privileged information and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorised. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator and then immediately delete this message.

--
ʎɐqǝ uo pɹɐoqʎǝʞ ɐ ʎnq ı ǝɯıʇ ʇsɐן ǝɥʇ sı sıɥʇ

Can we use Google Datastore @Persistent annotations with Scala?

toivo

I have been working with the gae beta.  I have not had time to fix the actor related issues (and am very pissed that google is reporting jdbc dependencies because mapper is not required for Lift apps and they did bother to contact me before posting, despite that I'm part of the beta... there... it's off my chest.) 

I'll get code checked up next week that makes core Lift work with gae (without comet support).

Thanks,

David

On Apr 8, 2009 1:40 AM, "Ola Bini" <ola [dot] bini [at] gmail [dot] com> wrote:

Kieron Wilkinson wrote: > > Isn't one of the selling points of actors that it is not necessarily > t...

Hi,

We made some experiments with Lift and Scala (I'm sure it will be blogged soon).
The consensus was that Lift doesn't really work at all - the Thread restrictions are just too hard.

You can definitely use Scala, though, and it runs without trouble as long as you stay away from the things that need Thread or ThreadGroup.

Cheers

On Wed, Apr 8, 2009 at 4:09 PM, David Pollak <feeder [dot] of [dot] the [dot] bears [at] gmail [dot] com> wrote:

I have been working with the gae beta.  I have not had time to fix the actor related issues (and am very pissed that google is reporting jdbc dependencies because mapper is not required for Lift apps and they did bother to contact me before posting, despite that I'm part of the beta... there... it's off my chest.) 

I'll get code checked up next week that makes core Lift work with gae (without comet support).

Great, David!
So basically now all we can do is hope that they start support Servlet 3.0 so we can get Comet online for GAE.

 

Thanks,

David

On Apr 8, 2009 1:40 AM, "Ola Bini" <ola [dot] bini [at] gmail [dot] com> wrote:

Kieron Wilkinson wrote: > > Isn't one of the selling points of actors that it is not necessarily > t...

Hi,

We made some experiments with Lift and Scala (I'm sure it will be blogged soon).
The consensus was that Lift doesn't really work at all - the Thread restrictions are just too hard.

You can definitely use Scala, though, and it runs without trouble as long as you stay away from the things that need Thread or ThreadGroup.

Cheers

Hi there,

On Wed, Apr 8, 2009 at 11:09 PM, David Pollak
wrote:
> I have been working with the gae beta. I have not had time to fix the actor
> related issues (and am very pissed that google is reporting jdbc
> dependencies because mapper is not required for Lift apps and they did
> bother to contact me before posting, despite that I'm part of the beta...
> there... it's off my chest.)
>
> I'll get code checked up next week that makes core Lift work with gae
> (without comet support).

As a proof of concept, I have succeeded to run lift-example on GAE/J,
it is running at
http://lift-example.appspot.com/index

Of course, CometAcotr is not functional, and DB is not available
because of jdbc usage.
In this weekend, if possible, I will try JPA.

Here is a fork of liftweb source code to run lift-example on GAE/J,
http://github.com/ymnk/liftweb/tree/master

Sincerely,
--
Atsuhiko Yamanaka
JCraft,Inc.
1-14-20 HONCHO AOBA-KU,
SENDAI, MIYAGI 980-0014 Japan.
Tel +81-22-723-2150
+1-415-578-3454
Fax +81-22-224-8773
Skype callto://jcraft/

Thank you! Thank you! Thank you!

I'd like to kiss you (but my wife might get upset)

Next time you come to the Bay Area, I will buy you lunch or dinner!

On Apr 10, 2009 1:46 AM, "Atsuhiko Yamanaka" <atsuhiko [dot] yamanaka [at] gmail [dot] com> wrote:

Hi there,

On Wed, Apr 8, 2009 at 11:09 PM, David Pollak

<feeder [dot] of [dot] the [dot] bears [at] gmail [dot] com> wrote:

> I have been working with the gae beta. I have not had time to fix the actor > related issues (and...

As a proof of concept, I have succeeded to run lift-example on GAE/J,
it is running at
 http://lift-example.appspot.com/index

Of course, CometAcotr is not functional, and DB is not available
because of jdbc usage.
In this weekend, if possible, I will try JPA.

Here is a fork of liftweb source code to run lift-example on GAE/J,
 http://github.com/ymnk/liftweb/tree/master


Sincerely,
--
Atsuhiko Yamanaka
JCraft,Inc.
1-14-20 HONCHO AOBA-KU,
SENDAI, MIYAGI 980-0014 Japan.
Tel +81-22-723-2150
   +1-415-578-3454
Fax +81-22-224-8773
Skype callto://jcraft/

Hi,

On Fri, Apr 10, 2009 at 10:03 PM, David Pollak
wrote:
> Thank you! Thank you! Thank you!
> I'd like to kiss you (but my wife might get upset)
> Next time you come to the Bay Area, I will buy you lunch or dinner!

If I get an opportunity to be there in the future, I'll want to enjoy
lunch with you!

> On Apr 10, 2009 1:46 AM, "Atsuhiko Yamanaka" wrote:
> As a proof of concept, I have succeeded to run lift-example on GAE/J, it is running at
>  http://lift-example.appspot.com/index
>
> Of course, CometAcotr is not functional, and DB is not available
> because of jdbc usage.
> In this weekend, if possible, I will try JPA.
>
> Here is a fork of liftweb source code to run lift-example on GAE/J,
>  http://github.com/ymnk/liftweb/tree/master

It seems that JDBC API must not have be forbidden on GAE/J .
I have succeeded to use H2 mem db by updating to its latest version[1] and
now DB functionalities have worked on
http://lift-example.appspot.com/index

However, it is not adequate for the practical usages, of course.
FYI, I found an interesting message[2] about a plan to implement
"JDBC to com.google.appengine.api.datastore wrapper"

PS. I will add CC to liftweb [at] googlegroups [dot] com and further discussions
should be there.

[1] http://www.h2database.com/html/changelog.html
[2] http://groups.google.com/group/google-appengine-java/msg/71278bbee901c652

Sincerely,
--
Atsuhiko Yamanaka
JCraft,Inc.
1-14-20 HONCHO AOBA-KU,
SENDAI, MIYAGI 980-0014 Japan.
Tel +81-22-723-2150
+1-415-578-3454
Fax +81-22-224-8773
Skype callto://jcraft/

Simple Scala source :

package gbook

import javax.jdo.annotations.IdentityType;
import javax.jdo.annotations.PersistenceCapable;

@PersistenceCapable{val identityType = IdentityType.APPLICATION}
class Autu {

}

Compiles fine, no Scala errors.

But DataNucleus Enhancer throws error:

DataNucleus Enhancer (version 1.1.0) : Enhancement of classes

Apr 13, 2009 10:22:31 PM org.datanucleus.metadata.MetaDataManager
loadClasses
SEVERE: Class "gbook.Autu" was not found in the CLASSPATH. Please check your
specification and your CLASSPATH.
org.datanucleus.exceptions.ClassNotResolvedException: Class "gbook.Autu" was
not found in the CLASSPATH. Please check your specification and your
CLASSPATH.
at
org.datanucleus.JDOClassLoaderResolver.classForName(JDOClassLoaderResolver.java:255)
at
org.datanucleus.JDOClassLoaderResolver.classForName(JDOClassLoaderResolver.java:420)
at
org.datanucleus.metadata.MetaDataManager.loadClasses(MetaDataManager.java:337)
at
org.datanucleus.enhancer.DataNucleusEnhancer.getFileMetadataForInput(DataNucleusEnhancer.java:723)
at
org.datanucleus.enhancer.DataNucleusEnhancer.enhance(DataNucleusEnhancer.java:525)
at
org.datanucleus.enhancer.DataNucleusEnhancer.main(DataNucleusEnhancer.java:1235)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.google.appengine.tools.enhancer.Enhancer.execute(Enhancer.java:57)
at com.google.appengine.tools.enhancer.Enhance.(Enhance.java:60)
at com.google.appengine.tools.enhancer.Enhance.main(Enhance.java:41)

DataNucleus Enhancer completed with success for 1 classes. Timings :
input=332 ms, enhance=155 ms, total=487 ms. Consult the log for full details

What's wrong?

My configuration:

Eclipse Platform
Version: 3.4.1
Build id: M20080911-1700

Scala plugin 2.8.0r17471-b20090411023214

Google App Engine Plug-in 1.0.0.v200904062334

<?xml version="1.0" encoding="UTF-8"?>

?xml version="1.0" encoding="UTF-8"?>

Gbook

ch.epfl.lamp.sdt.core.scalabuilder

com.google.appengine.eclipse.core.enhancerbuilder

com.google.appengine.eclipse.core.projectValidator

com.google.gdt.eclipse.core.webAppProjectValidator

ch.epfl.lamp.sdt.core.scalanature
org.eclipse.jdt.core.javanature
com.google.appengine.eclipse.core.gaeNature
com.google.gdt.eclipse.core.webAppNature

DataNucleus Enhancer works fine with Java source files.

Thanks
toivo

On Tue, Apr 14, 2009 at 7:44 AM, toivo wrote:
> But DataNucleus Enhancer throws error:

Not sure if it's related, but there was a DataNucleus bug reported on
this list a few days ago.

http://thread.gmane.org/gmane.comp.lang.scala/15571
http://www.datanucleus.org/servlet/jira/browse/NUCENHANCER-34

Rich
--
http://blog.richdougherty.com/

it worked fine for me.  i am using ant to build and just adapt the ant build.xml to compile scala instead.

On Tue, Apr 14, 2009 at 3:44 AM, toivo <tom [dot] tad [at] mail [dot] ee> wrote:

Simple Scala source :

package gbook

import javax.jdo.annotations.IdentityType;
import javax.jdo.annotations.PersistenceCapable;

@PersistenceCapable{val identityType = IdentityType.APPLICATION}
class Autu {

}

Compiles fine, no Scala errors.

But DataNucleus Enhancer throws error:

DataNucleus Enhancer (version 1.1.0) : Enhancement of classes

Apr 13, 2009 10:22:31 PM org.datanucleus.metadata.MetaDataManager
loadClasses
SEVERE: Class "gbook.Autu" was not found in the CLASSPATH. Please check your
specification and your CLASSPATH.
org.datanucleus.exceptions.ClassNotResolvedException: Class "gbook.Autu" was
not found in the CLASSPATH. Please check your specification and your
CLASSPATH.
       at
org.datanucleus.JDOClassLoaderResolver.classForName(JDOClassLoaderResolver.java:255)
       at
org.datanucleus.JDOClassLoaderResolver.classForName(JDOClassLoaderResolver.java:420)
       at
org.datanucleus.metadata.MetaDataManager.loadClasses(MetaDataManager.java:337)
       at
org.datanucleus.enhancer.DataNucleusEnhancer.getFileMetadataForInput(DataNucleusEnhancer.java:723)
       at
org.datanucleus.enhancer.DataNucleusEnhancer.enhance(DataNucleusEnhancer.java:525)
       at
org.datanucleus.enhancer.DataNucleusEnhancer.main(DataNucleusEnhancer.java:1235)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
       at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:597)
       at com.google.appengine.tools.enhancer.Enhancer.execute(Enhancer.java:57)
       at com.google.appengine.tools.enhancer.Enhance.<init>(Enhance.java:60)
       at com.google.appengine.tools.enhancer.Enhance.main(Enhance.java:41)

DataNucleus Enhancer completed with success for 1 classes. Timings :
input=332 ms, enhance=155 ms, total=487 ms. Consult the log for full details


What's wrong?


My configuration:

Eclipse Platform
Version: 3.4.1
Build id: M20080911-1700

Scala plugin 2.8.0r17471-b20090411023214

Google App Engine Plug-in  1.0.0.v200904062334


<?xml version="1.0" encoding="UTF-8"?>
<classpath>
       <classpathentry kind="src" path="src"/>
       <classpathentry kind="con"
path="ch.epfl.lamp.sdt.launching.SCALA_CONTAINER" />
       <classpathentry kind="con"
path="com.google.appengine.eclipse.core.GAE_CONTAINER"/>
       <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
       <classpathentry kind="output" path="war/WEB-INF/classes"/>
</classpath>


?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
       <name>Gbook</name>
       <comment></comment>
       <projects>
       </projects>
       <buildSpec>
               <buildCommand>
           <name>ch.epfl.lamp.sdt.core.scalabuilder</name>
           <arguments>
           </arguments>
       </buildCommand>
               <buildCommand>
                       <name>com.google.appengine.eclipse.core.enhancerbuilder</name>
                       <arguments>
                       </arguments>
               </buildCommand>
               <buildCommand>
                       <name>com.google.appengine.eclipse.core.projectValidator</name>
                       <arguments>
                       </arguments>
               </buildCommand>
               <buildCommand>
                       <name>com.google.gdt.eclipse.core.webAppProjectValidator</name>
                       <arguments>
                       </arguments>
               </buildCommand>
       </buildSpec>
       <natures>
               <nature>ch.epfl.lamp.sdt.core.scalanature</nature>
               <nature>org.eclipse.jdt.core.javanature</nature>
               <nature>com.google.appengine.eclipse.core.gaeNature</nature>
               <nature>com.google.gdt.eclipse.core.webAppNature</nature>
       </natures>
</projectDescription>


DataNucleus Enhancer works fine with Java source files.


Thanks
toivo

--
View this message in context: http://www.nabble.com/-scala--Google-App-Engine-for-Scala%21-tp22944265p23027111.html
Sent from the Scala mailing list archive at Nabble.com.

--
.......__o
.......\<,
....( )/ ( )...

i don't think they are related.  the previous bug was on a entity class with constructor arguments.

On Tue, Apr 14, 2009 at 4:18 AM, Rich Dougherty <rich [at] rd [dot] gen [dot] nz> wrote:

On Tue, Apr 14, 2009 at 7:44 AM, toivo <tom [dot] tad [at] mail [dot] ee> wrote:
> But DataNucleus Enhancer throws error:

Not sure if it's related, but there was a DataNucleus bug reported on
this list a few days ago.

http://thread.gmane.org/gmane.comp.lang.scala/15571
http://www.datanucleus.org/servlet/jira/browse/NUCENHANCER-34

Rich
--
http://blog.richdougherty.com/

--
.......__o
.......\<,
....( )/ ( )...

Hi,

On Tue, Apr 14, 2009 at 4:44 AM, toivo wrote:
> DataNucleus Enhancer (version 1.1.0) : Enhancement of classes
>
> Apr 13, 2009 10:22:31 PM org.datanucleus.metadata.MetaDataManager
> loadClasses
> SEVERE: Class "gbook.Autu" was not found in the CLASSPATH. Please check your
> specification and your CLASSPATH.
> org.datanucleus.exceptions.ClassNotResolvedException: Class "gbook.Autu" was
> not found in the CLASSPATH. Please check your specification and your
> CLASSPATH.

If you add scala-library.jar to the CLASSPATH for the enhance command,
that error will be disappeared.

Sincerely,
--
Atsuhiko Yamanaka
JCraft,Inc.
1-14-20 HONCHO AOBA-KU,
SENDAI, MIYAGI 980-0014 Japan.
Tel +81-22-723-2150
+1-415-578-3454
Fax +81-22-224-8773
Skype callto://jcraft/

toivo wrote:
>
> Class "gbook.Autu" was not found in the CLASSPATH. Please check your
> specification and your CLASSPATH.
>
I get the same error, and I haven't even got around to any persistence yet.

I'm wondering if it's related to the dual nature of the Eclipse project - I
created a Google project then copied various settings - Scala nature, Scala
builder, etc - by hand from a Scala project into the project files. That may
have thrown it for a loop.

Atsuhiko Yamanaka-2 wrote:
>
> If you add scala-library.jar to the CLASSPATH for the enhance command,
> that error will be disappeared.
>
Where do I do that? Is that in .project?

On Tue, Apr 14, 2009 at 5:25 PM, Atsuhiko Yamanaka
wrote:
> On Tue, Apr 14, 2009 at 4:44 AM, toivo wrote:
>> DataNucleus Enhancer (version 1.1.0) : Enhancement of classes
>>
>> Apr 13, 2009 10:22:31 PM org.datanucleus.metadata.MetaDataManager
>> loadClasses
>> SEVERE: Class "gbook.Autu" was not found in the CLASSPATH. Please check your
>> specification and your CLASSPATH.
>> org.datanucleus.exceptions.ClassNotResolvedException: Class "gbook.Autu" was
>> not found in the CLASSPATH. Please check your specification and your
>> CLASSPATH.
>
> If you add scala-library.jar to the CLASSPATH for the enhance command,
> that error will be disappeared.

Is anyone willing to write this up for the Scala Trac Wiki? A
walkthrough of getting a Scala GAE project up and running in Eclipse
would be extremely helpful.

While we're about it, the current Wiki entry for using the Scala IDE
for Eclipse for Lift development consists of exactly one line. While
I'd be delighted if things really were as simple, straightforward and
reliable as that implies, I fear that in fact the picture isn't so
rosy.

It'd be fantastic if someone could also contribute a walkthough of
setting up a Lift project in Eclipse. And for bonus points a
walkthrough of getting a Scala Lift GAE project up and running in
Eclipse would be Just Awesome.

Cheers,

Miles