The error is:
Type InternalTag Context CFOBJECT
(/home/baz/Source/ThinkLOOP-GAE/war/index.cfm, Line=1, Column=1) Source
1: <cfobject name="CDS"
component="com.newatlanta.appengine.datastore.CachingDatastoreService"
type="java" />
2: <cfdump var="#CDS#">
3: <cfabort>
4: <cfsilent>
5: <cfif not StructKeyExists(url, 'think')>
^ Snippet from underlying CFML source Stack Trace
java.lang.NullPointerException
at com.naryx.tagfusion.cfm.tag.cfOBJECT.render(Unknown Source)
at com.naryx.tagfusion.cfm.tag.cfTag.coreRender(Unknown Source)
at com.naryx.tagfusion.cfm.tag.cfTag.render(Unknown Source)
at com.naryx.tagfusion.cfm.file.cfFile.render(Unknown Source)
at com.naryx.tagfusion.cfm.engine.cfSession.onRequest(Unknown Source)
at com.naryx.tagfusion.cfm.engine.cfEngine.service(Unknown Source)
at com.naryx.tagfusion.cfm.cfServlet.service(Unknown Source)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
com.google.apphosting.utils.jetty.DevAppEngineWebAppContext.handle(DevAppEngineWebAppContext.java:54)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:268)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:126)
at
com.google.appengine.tools.development.StaticFileUtils.serveWelcomeFileAsForward(StaticFileUtils.java:80)
at
com.google.appengine.tools.development.LocalResourceFileServlet.maybeServeWelcomeFile(LocalResourceFileServlet.java:247)
at
com.google.appengine.tools.development.LocalResourceFileServlet.doGet(LocalResourceFileServlet.java:120)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at
com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
com.google.appengine.tools.development.StaticFileFilter.doFilter(StaticFileFilter.java:121)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
com.google.apphosting.utils.jetty.DevAppEngineWebAppContext.handle(DevAppEngineWebAppContext.java:54)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at
com.google.appengine.tools.development.JettyContainerService$ApiProxyHandler.handle(JettyContainerService.java:342)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:313)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:830)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
On Thu, Nov 5, 2009 at 4:12 PM, Bassil Karam <[email protected]> wrote:
> Ok, I got the class to compile into the classes folder under:
>
>
> /home/baz/Source/ThinkLOOP-GAE/war/WEB-INF/classes/com/newatlanta/appengine/datastore/CachingDatastoreService.class
>
> How do I call it now, variations of this don't seem to work:
>
> <cfobject name="CDS"
> component="com.newatlanta.appengine.datastore.CachingDatastoreService"
> type="java" />
>
> Thanks,
> Baz
>
>
> On Thu, Nov 5, 2009 at 3:05 PM, Vince Bonfanti <[email protected]>wrote:
>
>>
>> You can add it directly to your project just as you would any other
>> Java class (within your projects's "src" directory, within an
>> appropriate directory structure to match the package). The class file
>> will be automatically build into your "war/WEB-INF/classes" directory.
>>
>> Vince
>>
>> On Thu, Nov 5, 2009 at 3:28 PM, Bassil Karam <[email protected]> wrote:
>> > Can I build CachingDatastoreService.java right from my GAE project? How?
>> > Once built, where would I put it, somewhere in the WAR folder?
>> > Excuse my ignorance....
>> > Baz
>> >
>> > On Mon, Nov 2, 2009 at 11:31 AM, Vince Bonfanti <[email protected]>
>> wrote:
>> >>
>> >> Query caching and page caching in BD are currently implemented via
>> >> memory-based caches. So, yes, they would exist on a
>> >> per-application-instance basis in GAE. We plan to modify these in
>> >> OpenBD-GAE to use memcache.
>> >>
>> >> I'd recommend just building the CachingDatastoreServvice class--it
>> >> doesn't have any dependencies on the rest of GaeVFS.
>> >>
>> >> Vince
>> >>
>> >> On Mon, Nov 2, 2009 at 2:08 PM, Bassil Karam <[email protected]> wrote:
>> >> >
>> >> > Very interesting Vince. So far from my informal tests, I can tell you
>> >> > that my app scope resets several times a day at least. So I see what
>> >> > you mean when you say it wouldn't be best for framework
>> >> > initialization. Also inappropriate would be object pools, or
>> temporary
>> >> > cache's that get flushed to the db as a batch. I take it query
>> caching
>> >> > and page caching also rely on the same mechanisms and have the same
>> >> > gotchas? Come to think of it, are those even wired up?
>> >> >
>> >> > Next I will play around with memcached and your
>> >> > CachingDatastoreService if I can figure out how to build it and
>> >> > replace the current GAE-VFS.
>> >> >
>> >> > Cheers,
>> >> > Baz
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Mon, Nov 2, 2009 at 9:00 AM, Vince Bonfanti <[email protected]>
>> >> > wrote:
>> >> >>
>> >> >> RE: "could application.myvariable return different values depending
>> on
>> >> >> which machine it pulls it from? What about session scope?"
>> >> >>
>> >> >> I asked this question on the GAE forum--more than once--back in
>> June,
>> >> >> and never received a direct answer. However, the Servlet spec
>> (version
>> >> >> 2.4) has this to say (Section SRV.3.4.1):
>> >> >>
>> >> >> "Context attributes are local to the JVM in which they were
>> >> >> created. This prevents ServletContext attributes from being a shared
>> >> >> memory store in a distributed container. When information needs to
>> be
>> >> >> shared between servlets running in a distributed environment, the
>> >> >> information should be placed into a session (See Chapter SRV.7,
>> >> >> “Sessions”), stored in a database, or set in an Enterprise
>> JavaBeansTM
>> >> >> component."
>> >> >>
>> >> >> Therefore, my assumption is that there will be a separate
>> >> >> ServletContext for each JVM instance--and possibly each application
>> >> >> instance, if within the same JVM--that is created by GAE. (I posted
>> >> >> this assumption on the GAE forum and was not contradicted--though
>> also
>> >> >> not confirmed either).
>> >> >>
>> >> >> Because the CFML Application scope in BD is implemented on top of
>> the
>> >> >> ServletContext, you will therefore get a different Application scope
>> >> >> for each instance of your application created by GAE. So yes,
>> >> >> "application.myvariable" might return different values for different
>> >> >> instances of your application, just as it would if your application
>> >> >> was deployed on several different servers within a cluster.
>> >> >>
>> >> >> According the GAE documentation: "App Engine includes an
>> >> >> implementation of sessions, using the servlet session interface. The
>> >> >> implementation uses the App Engine datastore and memcache to store
>> >> >> session data." While I haven't tested this (yet), the implication is
>> >> >> pretty clear than sessions are shared across instances of your
>> >> >> application. Therefore "session.myvariable" should always return the
>> >> >> same value across multiple instances of your application. Note that
>> >> >> sessions are disabled by default and must be explicitly enabled; see
>> >> >> the heading Enabling Sessions on the following page:
>> >> >>
>> >> >> http://code.google.com/appengine/docs/java/config/appconfig.html
>> >> >>
>> >> >> RE: "Will the app scope be reset quite often as machines spin up and
>> >> >> down?"
>> >> >>
>> >> >> Possibly, yes. Google has not been very forthcoming regarding what
>> to
>> >> >> expect regarding how often and under what circumstances new
>> instances
>> >> >> of your application will be created or destroyed.
>> >> >>
>> >> >> RE: "Will it be the recommendation of openbd to favor memcached
>> >> >> instead of those scopes?"
>> >> >>
>> >> >> Using the Session scope for per-user data is probably best. Doing
>> >> >> "heavy" initialization of the Application scope is probably not a
>> good
>> >> >> idea; many applications and frameworks do this under the assumption
>> >> >> that application initialization happens only once, but GAE turns
>> this
>> >> >> assumption on its head. It might be best to look to memcache to
>> store
>> >> >> data that might otherwise be stored in the Application scope,
>> >> >> especially if you need to share this data across multiple instances
>> of
>> >> >> your application.
>> >> >>
>> >> >> RE: "what's the status and plans for memcached integration? Will it
>> be
>> >> >> transparently linked to the app scope, or will there be a specific
>> set
>> >> >> of functions to interact with it?"
>> >> >>
>> >> >> It's not likely that we'll transparently link the Application scope
>> to
>> >> >> memcache (though this is an interesting idea). One thought is to
>> >> >> emulate the "Cluster" scope introduced by Railo and implement that
>> >> >> scope on memcache (possibly backed by the datastore). Otherwise,
>> we'll
>> >> >> provide a specific set of functions to interact with memcache.
>> >> >>
>> >> >> RE: "For now, should I just use the datastore as my cache instead of
>> >> >> app scope, session scope or memcached?"
>> >> >>
>> >> >> I would use the Session scope just as you normally would. For the
>> >> >> Application scope, it depends what you're doing. If you're doing
>> >> >> fairly lightweight initialization of values that don't change during
>> >> >> the application lifetime, then I'd continue using the Application
>> >> >> scope. If you're doing "heavy" initialization, or storing variables
>> >> >> whose values change during the application lifetime, then I'd
>> consider
>> >> >> use CFOBJECT to interact with memcache directly (it would be pretty
>> >> >> easy to write a set of CFML UDFs--or a CFC--to do this). I'd
>> recommend
>> >> >> using the low-level API rather than JCache:
>> >> >>
>> >> >> http://code.google.com/appengine/docs/java/memcache/
>> >> >>
>> >> >> If you're feeling really adventurous, you might want to take a look
>> at
>> >> >> using the CachingDatastoreService (again, via CFOBJECT) that I've
>> >> >> implemented for GaeVFS. This allows you to store values in the
>> >> >> datastore with automatic caching in memcache:
>> >> >>
>> >> >>
>> >> >>
>> http://code.google.com/p/gaevfs/source/browse/trunk/src/com/newatlanta/appengine/datastore/CachingDatastoreService.java
>> >> >>
>> >> >> Note that the CachingDatastoreService is *not* included in the
>> latest
>> >> >> GaeVFS download, so you'll have to download the source and build it
>> >> >> yourself.
>> >> >>
>> >> >> RE: "Additionally, does onApplicationStart() get invoked every time
>> a
>> >> >> new server spins up?"
>> >> >>
>> >> >> Yes.
>> >> >>
>> >> >> On Sun, Nov 1, 2009 at 4:24 PM, Bassil Karam <[email protected]>
>> wrote:
>> >> >>>
>> >> >>> The way I understand it, GAE spins up and spins down servers to
>> meet
>> >> >>> the needs of an app - or even just because it feels like it. What
>> >> >>> effects does this have on the *persistent* scopes (sorry Sean I
>> know
>> >> >>> you hate them being called that :) like application and session?
>> More
>> >> >>> specifically:
>> >> >>>
>> >> >>> - Are those scopes synchronized between machines? That is, could
>> >> >>> application.myvariable return different values depending on which
>> >> >>> machine it pulls it from? What about session scope?
>> >> >>> - Will the app scope be reset quite often as machines spin up and
>> >> >>> down?
>> >> >>> - Will it be the recommendation of openbd to favor memcached
>> instead
>> >> >>> of those scopes?
>> >> >>>
>> >> >>> Which leads me to my next question: what's the status and plans for
>> >> >>> memcached integration? Will it be transparently linked to the app
>> >> >>> scope, or will there be a specific set of functions to interact
>> with
>> >> >>> it? For now, should I just use the datastore as my cache instead of
>> >> >>> app scope, session scope or memcached?
>> >> >>>
>> >> >>> Thanks,
>> >> >>> Baz
>> >> >>>
>> >> >>>
>> >> >>
>> >> >> >
>> >> >>
>> >> >
>> >> > >
>> >> >
>> >>
>> >>
>> >
>> >
>> > >
>> >
>>
>> >>
>>
>
--~--~---------~--~----~------------~-------~--~----~
Open BlueDragon Public Mailing List
http://groups.google.com/group/openbd?hl=en
official site @ http://www.openbluedragon.org/
!! save a network - trim replies before posting !!
-~----------~----~----~----~------~----~------~--~---
