[appengine-java] Re: javax.jdo.JDOUserException: Portion of expression could not be parsed: @email.com

2011-01-12 Thread Charms Styler
Most elegant way to pass query params is as follows otherwise you may run 
into special chars that could ruin ur app as in this case..

q.addFilter("login_Id", Query.FilterOperator.EQUAL, login_Id);
q.addFilter("userPassword", Query.FilterOperator.EQUAL, userPassword);


-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.



[appengine-java] Re: Subject: Java documentation updated to use low-level API for example code

2011-01-12 Thread Charms Styler
Hi Ikai, 
As for what I have come across so far, Low level Api is useful for 
performing  a transaction over multiple entities. However is it possible to 
use low level API as well as JPA or JDO ?   The idea is to use low level api 
whenever a need arises to perform a transaction over multiple entities, but 
I am not sure making entity groups using JPA Is doable? What's your say on 
this?

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.



[appengine-java] Re: How to refresh in-memory structures across instances?

2011-01-12 Thread Didier Durand
Hi again,

forgot 1 point: the overhead is pretty low for the end-user, no delay
due to additional I/Os, just some processing (microseconds ?) to
schedule the async request. User doesn't see the possible delay of
(e): i/o not finished when you try to retrieve.

So, I would see it as acceptable on a per user basis.

On a global aggregated scale , this may have a cost (CPU + I/O to
retrieve the data) if you schedule it billions of times a day, but in
that case, you probably have the revenue stream anyway to incurr this
cost

After re-reading myself, I can even propose something simpler: do a
regular synchronous i/o (and construct your mem structure) but after
you returned the result of current request. You would achieve same
result: next user is served with new config.

regards

didier

On Jan 13, 7:02 am, Didier Durand  wrote:
> Hi Ken,
>
> To my understanding also, adressing a specific instance (or each and
> every of the running ones) to make it "do something" is not easily
> possible (impossible ?) in App Engine: I tried for other purposes and
> could not achieve it. I didn't find any solution either: cron jobs,
> queued tasks don't give you guarantee of where they execute.
>
> What you have to to make an instance do something is stimulate it from
> "the inside". Additionnally in your case, you want to minimize impact
> on users.
>
> So, what I would suggest is the use of the new datastore async api:
>    - a) your user request starts in a given instance
>    - b) you start an async query to the ds to a known place to obtain
> new config if it has been changed
>    - c) you do the regular processing corresponding to the user
> request (with the possibly old config)
>    - d) you return the response to the user
>    - e) you obtain the async response from the ds and you update your
> in-mem (cache, singleton, etc.)  config of the current instance
> accordingly
>    - f) next user request will use the updated config.
>
> Of course, you can adjust the frequency of (b) and (e) by adding a
> time_of_last_request in your singleton and do it at the pace you wish.
>
> Your question interests me too so I look forward to seing if people
> come with better proposals to use them myself!
>
> regards
> didier
>
> On Jan 12, 10:16 pm, "b2csand...@kentraub.com"
>
>  wrote:
> > I've got an application that works as follows.
>
> > The main thing it does is handle user request.  Handling a user
> > request entails doing a bunch of processing, then finally returning
> > the result to the user.  It is important that the total time to
> > process a user request be as small as possible.
>
> > There is also a configuration interface used by admins.  The admin can
> > make a change to configuration that affects what processing is done on
> > user requests as described above.  The information in stored in the
> > config database has to be "compiled" into fairly elaborate in-memory
> > structure that handles the user request processing; computing this in-
> > memory structure from the configuration info takes time (much longer
> > than processing a user request).
>
> > It is a goal that the time to "compile" the configuration info into
> > the in-memory structure *not* be on the critical path of processing a
> > user request.
>
> > Here's the problem.  When the admin changes the config info, it's easy
> > enough to update the in-memory structure for the instance that
> > happened to process the admin's request.  But in order to avoid start-
> > up latency in processing user requests, I've got three "always on"
> > instances (which is the minimum number of always on instances -- you
> > can't ask for just one).  How can I get the other instances to realize
> > that the config has changed and that their in-memory structure needs
> > to be recalculated?
>
> > Non-solution:  on each user request, check the database to see if the
> > config has changed.  This is not acceptable, because if the database
> > *has* changed then that user request will incur the latency to update
> > the in-memory structure.
>
> > Non-solution:  just like the previous non-solution, but use a
> > memcache.  I believe this has the same latency problem, just delayed
> > until after the memcache entry expires.
>
> > Lousy solution:  redeploy the app after a config change.  That works
> > because it restarts all instances, but it defeats the purpose of
> > making the config something that can be changed by an admin through UI
> > screens rather than wired into the code.
>
> > If I could direct a request to *all* deployed instances (or,
> > equivalently, to a specific instance coupled with the ability to
> > enumerate all of the instance IDs), then it would be easy for me to
> > "kick" each instance after the config change.  But as far as I know,
> > there's no way to do that.
>
> > I'm sure others have encountered a similar scenario.  Any suggestions?
>
> > Thanks in advance.
>
> > Ken Traub
>
>

-- 
You received this message because you are subscribed to the Goo

[appengine-java] Re: Regarding @Column annotation

2011-01-12 Thread Charms Styler
maxlength in HTML is a good approach but the client code could
manipulated meaning ur application is open to inconsistent data
moreover if your application is serving more than the client HTML it's
a havoc.

For a example in your app if ur planing to tweet with some additional
prefix based on stored events other than html form submission,(As you
know tweet limit is 140 chars). so other than checking length
@prepersist is there any workarounds for this?

On Thu, Jan 13, 2011 at 11:26 AM, Kumar, Susheel
 wrote:
> Well, as I coudnt find a way what I did is I checked the size in the client
> side itself. Like I set maxlength value to the HTML input tags so that it
> will be prevent it right from there.
>
>
>
> Thanks & Regards,
>
> Susheel Kumar
>
> susheel.ku...@ap.sony.com  | +91 9886275353  | 080-67078924 |  SARD-SEZ,
> SISC | BANGALORE, INDIA |
>
>
>
> From: Charms Styler [mailto:charmssty...@gmail.com]
> Sent: Thursday, January 13, 2011 11:04 AM
> To: google-appengine-java@googlegroups.com
> Cc: Kumar, Susheel
> Subject: Re: Regarding @Column annotation
>
>
>
> true.. @Column length or  @size  doesn't seems to work. is there a
> workaround for this??
>
>
>
> hmm only explanation found was about the overall limit of 500 chars on
> String according to
>
> Porperties &
> Values http://code.google.com/appengine/docs/java/datastore/entities.html
>
> 
> This email is confidential and intended only for the use of the individual
> or entity named above and may contain information that is privileged. If you
> are not the intended recipient, you are notified that any dissemination,
> distribution or copying of this email is strictly prohibited. If you have
> received this email in error, please notify us immediately by return email
> or telephone and destroy the original message. - This mail is sent via Sony
> Asia Pacific Mail Gateway..
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.



[appengine-java] Re: How to refresh in-memory structures across instances?

2011-01-12 Thread Didier Durand
Hi Ken,

To my understanding also, adressing a specific instance (or each and
every of the running ones) to make it "do something" is not easily
possible (impossible ?) in App Engine: I tried for other purposes and
could not achieve it. I didn't find any solution either: cron jobs,
queued tasks don't give you guarantee of where they execute.

What you have to to make an instance do something is stimulate it from
"the inside". Additionnally in your case, you want to minimize impact
on users.

So, what I would suggest is the use of the new datastore async api:
   - a) your user request starts in a given instance
   - b) you start an async query to the ds to a known place to obtain
new config if it has been changed
   - c) you do the regular processing corresponding to the user
request (with the possibly old config)
   - d) you return the response to the user
   - e) you obtain the async response from the ds and you update your
in-mem (cache, singleton, etc.)  config of the current instance
accordingly
   - f) next user request will use the updated config.

Of course, you can adjust the frequency of (b) and (e) by adding a
time_of_last_request in your singleton and do it at the pace you wish.

Your question interests me too so I look forward to seing if people
come with better proposals to use them myself!

regards
didier

On Jan 12, 10:16 pm, "b2csand...@kentraub.com"
 wrote:
> I've got an application that works as follows.
>
> The main thing it does is handle user request.  Handling a user
> request entails doing a bunch of processing, then finally returning
> the result to the user.  It is important that the total time to
> process a user request be as small as possible.
>
> There is also a configuration interface used by admins.  The admin can
> make a change to configuration that affects what processing is done on
> user requests as described above.  The information in stored in the
> config database has to be "compiled" into fairly elaborate in-memory
> structure that handles the user request processing; computing this in-
> memory structure from the configuration info takes time (much longer
> than processing a user request).
>
> It is a goal that the time to "compile" the configuration info into
> the in-memory structure *not* be on the critical path of processing a
> user request.
>
> Here's the problem.  When the admin changes the config info, it's easy
> enough to update the in-memory structure for the instance that
> happened to process the admin's request.  But in order to avoid start-
> up latency in processing user requests, I've got three "always on"
> instances (which is the minimum number of always on instances -- you
> can't ask for just one).  How can I get the other instances to realize
> that the config has changed and that their in-memory structure needs
> to be recalculated?
>
> Non-solution:  on each user request, check the database to see if the
> config has changed.  This is not acceptable, because if the database
> *has* changed then that user request will incur the latency to update
> the in-memory structure.
>
> Non-solution:  just like the previous non-solution, but use a
> memcache.  I believe this has the same latency problem, just delayed
> until after the memcache entry expires.
>
> Lousy solution:  redeploy the app after a config change.  That works
> because it restarts all instances, but it defeats the purpose of
> making the config something that can be changed by an admin through UI
> screens rather than wired into the code.
>
> If I could direct a request to *all* deployed instances (or,
> equivalently, to a specific instance coupled with the ability to
> enumerate all of the instance IDs), then it would be easy for me to
> "kick" each instance after the config change.  But as far as I know,
> there's no way to do that.
>
> I'm sure others have encountered a similar scenario.  Any suggestions?
>
> Thanks in advance.
>
> Ken Traub

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.



[appengine-java] Re: Regarding @Column annotation

2011-01-12 Thread Charms Styler
true.. @Column length or  @size  doesn't seems to work. is there a 
workaround for this??

hmm only explanation found was about the overall limit of 500 chars on 
String according to 
Porperties & Values 
http://code.google.com/appengine/docs/java/datastore/entities.html

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.



[appengine-java] How to refresh in-memory structures across instances?

2011-01-12 Thread b2csand...@kentraub.com
I've got an application that works as follows.

The main thing it does is handle user request.  Handling a user
request entails doing a bunch of processing, then finally returning
the result to the user.  It is important that the total time to
process a user request be as small as possible.

There is also a configuration interface used by admins.  The admin can
make a change to configuration that affects what processing is done on
user requests as described above.  The information in stored in the
config database has to be "compiled" into fairly elaborate in-memory
structure that handles the user request processing; computing this in-
memory structure from the configuration info takes time (much longer
than processing a user request).

It is a goal that the time to "compile" the configuration info into
the in-memory structure *not* be on the critical path of processing a
user request.

Here's the problem.  When the admin changes the config info, it's easy
enough to update the in-memory structure for the instance that
happened to process the admin's request.  But in order to avoid start-
up latency in processing user requests, I've got three "always on"
instances (which is the minimum number of always on instances -- you
can't ask for just one).  How can I get the other instances to realize
that the config has changed and that their in-memory structure needs
to be recalculated?

Non-solution:  on each user request, check the database to see if the
config has changed.  This is not acceptable, because if the database
*has* changed then that user request will incur the latency to update
the in-memory structure.

Non-solution:  just like the previous non-solution, but use a
memcache.  I believe this has the same latency problem, just delayed
until after the memcache entry expires.

Lousy solution:  redeploy the app after a config change.  That works
because it restarts all instances, but it defeats the purpose of
making the config something that can be changed by an admin through UI
screens rather than wired into the code.

If I could direct a request to *all* deployed instances (or,
equivalently, to a specific instance coupled with the ability to
enumerate all of the instance IDs), then it would be easy for me to
"kick" each instance after the config change.  But as far as I know,
there's no way to do that.

I'm sure others have encountered a similar scenario.  Any suggestions?

Thanks in advance.

Ken Traub

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.



[appengine-java] Subject: Java documentation updated to use low-level API for example code

2011-01-12 Thread Ikai Lan (Google)
Hey everyone,

I wanted to let you all know that we've updated the docs to show examples
using the Low Level API:

http://code.google.com/appengine/docs/java/datastore/

This includes many improvements such as official documentation about using
the AsyncDatastoreService!

We believe that explaining datastore concepts using the low level API makes
it easier to grasp datastore concepts and helps developers understand how to
solve persistence problems in a non-relational manner. The documentation
will continue to show examples in JDO/JPA, though we will be more
aggressively maintaining the documentation for the low-level API.

Take a look and let us know what you think.

--
Ikai Lan
Developer Programs Engineer, Google App Engine
Blogger: http://googleappengine.blogspot.com
Reddit: http://www.reddit.com/r/appengine
Twitter: http://twitter.com/app_engine

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.



[appengine-java] Re: Unable to navigate my app in production server, while in development server works fine

2011-01-12 Thread Markel Arizaga
Ok, this is a mistery, now, I have deployed again (without changing 
anything, i think, XD) and I can acccess some pages in my website, but 
others remain with problems.

You can see this in the url for the app: www.kokonutcmpny.appspot.com 

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.



Re: [appengine-java] I cannot delete a version of my app

2011-01-12 Thread Ikai Lan (Google)
The version has been deleted.

--
Ikai Lan
Developer Programs Engineer, Google App Engine
Blogger: http://googleappengine.blogspot.com
Reddit: http://www.reddit.com/r/appengine
Twitter: http://twitter.com/app_engine



On Tue, Jan 11, 2011 at 12:36 PM, Victor Dolirio wrote:

> My app victordolirioti, version 3 cannot be deleted.
> Can some one help me?
>
> best regards.
> []s
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine for Java" group.
> To post to this group, send email to
> google-appengine-j...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine-java+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/google-appengine-java?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.



[appengine-java] Re: Unable to navigate my app in production server, while in development server works fine

2011-01-12 Thread Markel Arizaga
Here is it, it was an IllegalStateException. I don't know where the problem 
is. Thanks again


   1. 
   
   Failed startup of context 
com.google.apphosting.utils.jetty.runtimeappenginewebappcont...@ea443f{/,/base/data/home/apps/kokonutcmpny/1.347395332617629339}
   org.mortbay.util.MultiException[java.lang.IllegalStateException: No forced 
path servlet for blog/blog.jsp, java.lang.IllegalStateException: No forced path 
servlet for shop/cart.jsp, java.lang.IllegalStateException: No forced path 
servlet for contact/contact.jsp, java.lang.IllegalStateException: No forced 
path servlet for administration/dashboard.jsp, java.lang.IllegalStateException: 
No forced path servlet for index.jsp, java.lang.IllegalStateException: No 
forced path servlet for shop/product.jsp, java.lang.IllegalStateException: No 
forced path servlet for administration/productEditor.jsp, 
java.lang.IllegalStateException: No forced path servlet for 
administration/shopAdmin.jsp, java.lang.IllegalStateException: No forced path 
servlet for shop/shop.jsp]
at 
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:656)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
at 
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250)
at 
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
at 
org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)
at 
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at 
com.google.apphosting.runtime.jetty.AppVersionHandlerMap.createHandler(AppVersionHandlerMap.java:191)
at 
com.google.apphosting.runtime.jetty.AppVersionHandlerMap.getHandler(AppVersionHandlerMap.java:168)
at 
com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:123)
at 
com.google.apphosting.runtime.JavaRuntime.handleRequest(JavaRuntime.java:261)
at 
com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:8495)
at 
com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:8493)
at 
com.google.net.rpc.impl.BlockingApplicationHandler.handleRequest(BlockingApplicationHandler.java:24)
at com.google.net.rpc.impl.RpcUtil.runRpcInApplication(RpcUtil.java:435)
at com.google.net.rpc.impl.Server$RpcTask.runInContext(Server.java:572)
at 
com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:448)
at com.google.tracing.TraceContext.runInContext(TraceContext.java:688)
at 
com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:326)
at 
com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:318)
at 
com.google.tracing.TraceContext$TraceContextRunnable.run(TraceContext.java:446)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
   java.lang.IllegalStateException: No forced path servlet for blog/blog.jsp
at 
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:679)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
at 
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250)
at 
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
at 
org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)
at 
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at 
com.google.apphosting.runtime.jetty.AppVersionHandlerMap.createHandler(AppVersionHandlerMap.java:191)
at 
com.google.apphosting.runtime.jetty.AppVersionHandlerMap.getHandler(AppVersionHandlerMap.java:168)
at 
com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:123)
at 
com.google.apphosting.runtime.JavaRuntime.handleRequest(JavaRuntime.java:261)
at 
com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:8495)
at 
com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:8493)
at 
com.google.net.rpc.impl.BlockingApplicationHandler.handleRequest(BlockingApplicationHandler.java:24)
at com.google.net.rpc.impl.RpcUtil.runRpcInApplication(RpcUtil.java:435)
at com.google.net.rpc.impl.Server$RpcTask.runInContext(Server.java:572)
at 
com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:448)
at com.google.tracing.TraceContext.runInContext(TraceContext.java:688)
at 
com.google.tracing.TraceContext$AbstractTraceContextCallback.run

[appengine-java] Re: Unable to navigate my app in production server, while in development server works fine

2011-01-12 Thread Markel Arizaga
Here is the exception raised when I try to open a jsp page inside my app. I 
remember I saw a different Exception ona of these days but a can't remember 
it and now it's not in the logs list.

java.lang.RuntimeException: java.io.NotSerializableException: 
resources.LanguageSelector
at 
com.google.apphosting.runtime.jetty.SessionManager.serialize(SessionManager.java:393)
at 
com.google.apphosting.runtime.jetty.SessionManager.createEntityForSession(SessionManager.java:370)
at 
com.google.apphosting.runtime.jetty.SessionManager$AppEngineSession.save(SessionManager.java:164)
at 
com.google.apphosting.runtime.jetty.SaveSessionFilter.doFilter(SaveSessionFilter.java:41)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at 
com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at 
com.google.apphosting.runtime.jetty.AppVersionHandlerMap.handle(AppVersionHandlerMap.java:238)
at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at 
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at 
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923)
at 
com.google.apphosting.runtime.jetty.RpcRequestParser.parseAvailable(RpcRequestParser.java:76)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at 
com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:135)
at 
com.google.apphosting.runtime.JavaRuntime.handleRequest(JavaRuntime.java:261)
at 
com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:8495)
at 
com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:8493)
at 
com.google.net.rpc.impl.BlockingApplicationHandler.handleRequest(BlockingApplicationHandler.java:24)
at com.google.net.rpc.impl.RpcUtil.runRpcInApplication(RpcUtil.java:435)
at com.google.net.rpc.impl.Server$RpcTask.runInContext(Server.java:572)
at 
com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:448)
at com.google.tracing.TraceContext.runInContext(TraceContext.java:688)
at 
com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:326)
at 
com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:318)
at 
com.google.tracing.TraceContext$TraceContextRunnable.run(TraceContext.java:446)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
Caused by: java.io.NotSerializableException: resources.LanguageSelector
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1173)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:343)
at java.util.HashMap.writeObject(HashMap.java:1018)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:962)
at 
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1478)
at 
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1409)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1167)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:343)
at 
com.google.apphosting.runtime.jetty.SessionManager.serialize(SessionManager.java:390)


-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com

Re: [appengine-java] Re: Task queue + datastore transaction + jdo: is it possible?

2011-01-12 Thread Fabrizio Accatino
Thank you very much. It works fine.  :)

Only a note. In my tests I didn't pass the transaction when I call the
queue.add. It seems that queue.add "feels" the current transaction (see the
example at
http://code.google.com/appengine/docs/java/taskqueue/overview.html#Tasks_Within_Transactions
)

My code:

PersistenceManager pm = PMF.get().getPersistenceManager();
try {
pm.currentTransaction().begin();

// JDO
Query jdoquery = pm.newQuery(Friend.class);
 get object x
x.setLastUpdate(new Date());
pm.makePersistent(x);

// Queue
Queue queue = QueueFactory.getQueue("myqueue");

queue.add(taskOpts);

pm.currentTransaction().commit();
} finally {
if (pm.currentTransaction().isActive())
pm.currentTransaction().rollback();
pm.close();
}



   Fabrizio



On Tue, Jan 11, 2011 at 9:29 PM, Ed Murphy  wrote:

> Yes, I do this with JDO.  Just add to you queue within the current
> transaction, for instance;
>
> PersistenceManager pm = PMF.get().getPersistenceManager();
> try
> {
>//
>// start transaction so we can atomically check the secondary key
>//
>pm.currentTransaction().begin();
>
>//
>// enqueue a task to process this ImportTask
>//
>//
>String theUrl = "/tasks"; // whatever your url will be - this is is
> your state;
>Queue queue = QueueFactory.getDefaultQueue();
>queue.add(
>
> DatastoreServiceFactory.getDatastoreService().getCurrentTransaction(),
>TaskOptions.Builder.url(theUrl));
>
>//
>// commit the transaction.
>//
>pm.currentTransaction().commit();   // we finished, so commit
> the
> transaction.
> }
> catch(DataAccessException dae)
> {
>throw dae;  // let prior DataAccessException leave.
> }
> catch(Exception e)
> {
>throw new DataAccessException(e);   // wrap the exception in our
> runtime exception.
> }
> finally
> {
>//
>// if the transactions is still active, then there
>// was an exception thrown.  So we rollback the transaction.
>//
>if(pm.currentTransaction().isActive())
>{
>pm.currentTransaction().rollback();
>}
>
>//
>// we always close the PersistenceManager when done.
>//
>if(!pm.isClosed())
>{
>pm.close();
> }
> }
>
>
> On Jan 11, 10:45 am, Fabrizio Accatino  wrote:
> > Hello,
> >
> > documentation tells I can insert a task in queue during a datastore
> > transaction.
> http://code.google.com/appengine/docs/java/taskqueue/overview.html#Ta...
> >
> > The example uses datastore low level api. Is there a way to do the same
> with
> > JDO?
> >
> > Thank you
> >
> >Fabrizio
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine for Java" group.
> To post to this group, send email to
> google-appengine-j...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine-java+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/google-appengine-java?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.



[appengine-java] I cannot delete a version of my app

2011-01-12 Thread Victor Dolirio
My app victordolirioti, version 3 cannot be deleted.
Can some one help me?

best regards.
[]s

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.



[appengine-java] Re: Our experience with App Engine

2011-01-12 Thread l.denardo
Good points!
Having one year of experience with GAE my only hard complaint is the
lack of polymorphism for the Java datastore (JDO queries), and the
lack of strong type checking of datastore Entities (simply working
with a map entity field is a nightmare if you use the low level API).
This forces to re-engineer your data model in clumsy ways, any time
you must model a tree data structure, even worse if your tree nodes
need to contain different data (subclasses of a same base class)...of
course, my app is full of these...

I guess this will be hard to get rid of, since everything seems  to
track back to the way keys are generated (ancestor, appID, etc.), but
I hope some improvements will be available in the future.

For the rest of the options, I completely agree with you.

>>- JRE whitelisting - yeah, every company we've talked to has mentioned this.
Unfortunately, every developer has different requirements. The
whitelisting
process is a bit more involved, as there are many security issues that
need
to be ironed out. I'd love to see the awt libraries available,
personally.

I hope too, since awt would open up to many PDF generation libraries
and so, which are just impossible to use right now.

Regards
Lorenzo
On Jan 11, 10:09 pm, George Moschovitis 
wrote:
> > - JDO - we've changed the documentation to show examples using the
> > low-level API and are working more closely with third-party library
> > developers. We've realized that there's a passionate community of open
> > source developers out there solving their own itch (itches that are likely
> > shared by others), and we're working on different ways of making it happen.
>
> Interesting, haven't noticed the changes in the docs (maybe a 'New!' marker
> would help). It seems that the low level API is in the spotlight now.
> No problem with that, but I 'd love to see improved support for static
> typing (most probably through generics) in the API.
>
> -g.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.



[appengine-java] javax.jdo.JDOUserException: Portion of expression could not be parsed: @email.com

2011-01-12 Thread spike
Hi..i have two fields namely login id(n...@email.com) & password. The
user on entering them will check if the user exist or not.the code is
given below:
//code
public List userLoginCheck(String login_Id,String
userPassword){

PersistenceManager pm = PMF.get().getPersistenceManager();
//System.out.println("PersistenceManager object created in
userLoginCheck()");
Query query = pm.newQuery(UserDetails.class);
//System.out.println("login_Id = "+login_Id+" userPassword =
"+userPassword);
query.setFilter("login_Id == susheel.ku...@ap.sony.com &&
userPassword == "+userPassword);

try{
//System.out.println("inside try block");
List userDetails = 
(List)
query.execute();
if (!userDetails.isEmpty()) {
for (UserDetails user_detail_obj : userDetails){
System.out.println("inside for 
loop login_Id =
"+user_detail_obj.getLoginId());
}
}

return userDetails;
}catch(Exception e){
System.out.println("Exception at 
userLoginCheck() = "+e);
}finally{
query.closeAll();
}
return null;
}

But when i execute the above code I get the following error

Exception at userLoginCheck() = javax.jdo.JDOUserException: Portion of
expression could not be parsed: @email.com && userPassword == sample
NestedThrowables:
org.datanucleus.store.query.QueryCompilerSyntaxException: Portion of
expression could not be parsed: @email.com && userPassword == sample

This error happens only if email id is used as filter. When I use any
other fields within datastore it doesnt cause any error. Please can
anyone help me out in this?

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.