Works with createObject:
<cfset cds = createObject('Java',
'com.newatlanta.appengine.datastore.CachingDatastoreService').init() />
Maybe there's an issue with cfobject?
Baz
On Thu, Nov 5, 2009 at 4:27 PM, Bassil Karam <[email protected]> wrote:
> 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 !!
-~----------~----~----~----~------~----~------~--~---
