on 6/22/03 1:36 PM Christopher Oliver wrote:
> Agree. I've moved Database.js and related out of the core and into the
> scratchpad for now, until petstore gets refactored.
Thanks dude.
--
Stefano.
> From: Stefano Mazzocchi
>
>
> on 6/20/03 11:52 AM Reinhard Pötz wrote:
>
> > Yes, you are right. The current draft of the FOM does not contain a
> > database layer.
> >
> > I see two options:
> >
> > 1.) remove it complety
> > 2.) add it to the petstore examples (which are based on those
Agree. I've moved Database.js and related out of the core and into the
scratchpad for now, until petstore gets refactored.
Chris
Stefano Mazzocchi wrote:
on 6/20/03 11:52 AM Reinhard Pötz wrote:
Yes, you are right. The current draft of the FOM does not contain a
database layer.
I see two op
on 6/20/03 11:52 AM Reinhard Pötz wrote:
> Yes, you are right. The current draft of the FOM does not contain a
> database layer.
>
> I see two options:
>
> 1.) remove it complety
> 2.) add it to the petstore examples (which are based on those JS
> functions)
>
> I'm in favour of removing the
x27;ve found is that the flowscript works just fine when i start the
> > > cocoon engine, but whenever i make any change to the script, it
> > > just loose the cocoon.componentManager!
> > >
> > >
> > > On Fri, 2003-06-20 at 16:19, Frank Taffelt wrote:
&g
t; Subject: Re: flow - database.js - Componentmanager
>
>
> um, isn't this database access directly from flow one of the
> deprecated parts of the API??
>
> Geoff
>
> At 11:55 AM 6/20/2003, you wrote:
> >I think i solve it. Chec
've found is that the flowscript works just fine when i start the
> cocoon engine, but whenever i make any change to the script, it
> just loose the cocoon.componentManager!
>
>
> On Fri, 2003-06-20 at 16:19, Frank Taffelt wrote:
> > > I also found this bug in the flo
any change to the script, it
> just loose the cocoon.componentManager!
>
>
> On Fri, 2003-06-20 at 16:19, Frank Taffelt wrote:
> > > I also found this bug in the flow Database.js!
> > > It seems that the componentManager is null whenever the
> > > script is reloaded!
> >
gt; It seems that the componentManager is null whenever the
> > script is reloaded!
>
> Hmm, what do you mean with "script is reloaded"? I didn't find any rational
> reason for this ...
--
Nuno Santos <[EMAIL PROTECTED]>
> I also found this bug in the flow Database.js!
> It seems that the componentManager is null whenever the
> script is reloaded!
Hmm, what do you mean with "script is reloaded"? I didn't find any rational
reason for this ...
I also found this bug in the flow Database.js!
It seems that the componentManager is null whenever the
script is reloaded!
On Thu, 2003-06-12 at 18:59, Christopher Oliver wrote:
> You're right, this is a serious problem. I'll try to look into it. Can
> you provide more informati
> You're right, this is a serious problem. I'll try to look into it. Can
> you provide more information about what is causing it?
my flowscript code looks like the following example:
---
cocoon.load("resource://org/apache/cocoon/components/flow/javascript/Databas
e.js");
function myLogic {
tabase.js;
line 13)
I'put some debug statements into databsae.js and found that the
componentManager object
var selector = cocoon.componentManager.lookup(..)
is null.
The problem occurs under cocoon-2.1m2 and current cvs (11.06.2003). In my
eyes this is a serious issue and we should try to fin
;, line
13: uncaught JavaScript exception: TypeError: Cannot convert null to an
object.(resource://org/apache/cocoon/components/flow/javascript/Database.js;
line 13)
I'put some debug statements into databsae.js and found that the
componentManager object
var selector = cocoon.componentManager.lookup(.
gzilla/show_bug.cgi?id=15312
Parent ComponentManager does not get disposed
--- Additional Comments From [EMAIL PROTECTED] 2002-12-12 14:43 ---
Created an attachment (id=4142)
Zip file containing diffs for a proposed fix for th
gzilla/show_bug.cgi?id=15312
Parent ComponentManager does not get disposed
Summary: Parent ComponentManager does not get disposed
Product: Cocoon 2
Version: Current CVS
Platform: Other
OS/Version: Other
Status: NEW
Severity:
On Fri, 22 Jun 2001, Carsten Ziegeler wrote:
> > Carsten Ziegeler wrote:
> >
> > Hello,
> >
> > I again and again face the big problem that the Environment cannot
> > get any components as it does not have access to the ComponentManager.
> >
> >
> Carsten Ziegeler wrote:
>
> Hello,
>
> I again and again face the big problem that the Environment cannot
> get any components as it does not have access to the ComponentManager.
>
> Is there any chance to make some simple changes that the Environment
> gets a Comp
Hello,
I again and again face the big problem that the Environment cannot
get any components as it does not have access to the ComponentManager.
Is there any chance to make some simple changes that the Environment
gets a ComponentManager from somewhere? Or is this bad design?
(By the way: As
lasses.
>
> Isn't it reasonable to have a static access to the
> component manager as there is e.g. for the logger?
> Or should this be considered a bad design/idea?
No. It is not necessary for a class to be a Component for
it to implement Composable. You would have to manage the
pa
At least for me it would be useful to have a static
method to get to the cocoon component manager instance.
Not all of our classes are really what I would characterize
as a component. So I need to pass the component manager
to all my classes.
Isn't it reasonable to have a static access to the
co
Berin Loritsch wrote:
>
> Sylvain Wallez wrote:
> >
> > I added a call to cocoon.dispose() in CocoonServlet.destroy(). The main
> > purpose was to gracefully close all Jdbc connections held by the
> > connection pool (otherwise Hsql keeps the database locked), but this
> > produces the following
Sylvain Wallez wrote:
>
> I added a call to cocoon.dispose() in CocoonServlet.destroy(). The main
> purpose was to gracefully close all Jdbc connections held by the
> connection pool (otherwise Hsql keeps the database locked), but this
> produces the following exceptions in the log :
>
> DEBUG
I added a call to cocoon.dispose() in CocoonServlet.destroy(). The main
purpose was to gracefully close all Jdbc connections held by the
connection pool (otherwise Hsql keeps the database locked), but this
produces the following exceptions in the log :
DEBUG 60137 [cocoon ] (Thread-21): Erro
24 matches
Mail list logo
