RE: Flow Database stuff ( The new FOM? )
From: Christopher Oliver [mailto:[EMAIL PROTECTED]
Reinhard Pötz wrote:
From: Jeremy Quinn
What I do not grok ATM, how does the Hibernate Session automatically
get closed at the appropriate time (ie. after the view layer has
completed)?
IIU the current flow implementation correctly you have no
chance but to
use lazy initializiation as implemented by you because after reaching
sendPageAndWait() the flow interpreter has no chance to
react. Maybe we
need something like a finalize in pipeline processing where those
things (releasing of components) are done.
HTH
Reinhard
Actually, although not particularly user-friendly, there is a
way to do
this, even now, with the extended catch syntax supported by Rhino
(which is intended to provide functionality similar to
dynamic-wind in
Scheme):
var hibSession = null;
function getSession() {
if (hibSession == null) {
hibSession = cocoon.getComponent(hibernateSession);
}
}
function releaseSession() {
if (hibSession != null) {
cocoon.releaseComponent(hibSession);
hibSession = null;
}
}
catch (break) {
// a continuation is being captured,
// code to handle that goes here
releaseSession();
}
... and this is called after the pipeline has been processed? How is
this possible from a technical POV? If the view layer is called by
sendPageAndWait the flow interpreter isn't active until the response
returns from the client (map:call continuation=...).
Reinhard
catch (continue) {
// a continuation is being restored
// code to handle that goes here
}
function myFlow() {
var custBean = getSession().blah;
sendPageAndWait(cust.xml, custBean);
var anotherBean = getSession().blahblah
}
Re: Flow Database stuff ( The new FOM? )
Reinhard Pötz wrote:
From: Christopher Oliver [mailto:[EMAIL PROTECTED]
snip
catch (break) {
// a continuation is being captured,
// code to handle that goes here
releaseSession();
}
... and this is called after the pipeline has been processed? How is
this possible from a technical POV? If the view layer is called by
sendPageAndWait the flow interpreter isn't active until the response
returns from the client (map:call continuation=...).
Reinhard
Unfortunately, you're right. In this case the call to releaseSession()
is made when the continuation is created - which is before the view
layer is called (see fom_system.js).
I've just commited an update to Rhino that [re-]enables a further syntax
extension, namely:
catch (return) {
// This continuation is about to be replaced with another continuation
// code to handle that goes here
}
By placing the code to release the hibernate session inside, i.e.
catch (return) {
cocoon.releaseComponent(hibSession);
}
you get the effect you're looking for: namely that the session is
released after calling the view layer but before control leaves the
interpreter.
As I said, Ovidiu and I decided to put these features in to try to
provide the functionality provided by dynamic-wind in Scheme, but this
kind of explicit resource management seems awkard and error-prone.
Chris
Re: Flow Database stuff ( The new FOM? )
On Tuesday, July 15, 2003, at 07:21 AM, Reinhard Pötz wrote: From: Jeremy Quinn What I do not grok ATM, how does the Hibernate Session automatically get closed at the appropriate time (ie. after the view layer has completed)? IIU the current flow implementation correctly you have no chance but to use lazy initializiation as implemented by you because after reaching sendPageAndWait() the flow interpreter has no chance to react. Maybe we need something like a finalize in pipeline processing where those things (releasing of components) are done. OK, I must have completely misunderstood what Chris's auto-magic component releasing was all about. Incidentally, someone tell me what 'IIU' stands for, cannot find it anywhere . regards Jeremy
Re: Flow Database stuff ( The new FOM? )
IIU(C) = If I understand (correctly) IIRC :) Joerg Jeremy Quinn wrote: Incidentally, someone tell me what 'IIU' stands for, cannot find it anywhere . regards Jeremy -- System Development VIRBUS AG Fon +49(0)341-979-7419 Fax +49(0)341-979-7409 [EMAIL PROTECTED] www.virbus.de
Re: Flow Database stuff ( The new FOM? )
On Tuesday, July 15, 2003, at 08:28 AM, Christopher Oliver wrote:
Reinhard Pötz wrote:
From: Christopher Oliver [mailto:[EMAIL PROTECTED]
snip
catch (break) {
// a continuation is being captured, // code to
handle that goes here
releaseSession();
}
... and this is called after the pipeline has been processed? How is
this possible from a technical POV? If the view layer is called by
sendPageAndWait the flow interpreter isn't active until the response
returns from the client (map:call continuation=...).
Reinhard
Unfortunately, you're right. In this case the call to releaseSession()
is made when the continuation is created - which is before the view
layer is called (see fom_system.js).
I've just commited an update to Rhino that [re-]enables a further
syntax extension, namely:
catch (return) {
// This continuation is about to be replaced with another
continuation
// code to handle that goes here
}
By placing the code to release the hibernate session inside, i.e.
catch (return) {
cocoon.releaseComponent(hibSession);
}
you get the effect you're looking for: namely that the session is
released after calling the view layer but before control leaves the
interpreter.
As I said, Ovidiu and I decided to put these features in to try to
provide the functionality provided by dynamic-wind in Scheme, but this
kind of explicit resource management seems awkard and error-prone.
Thanks Chris
I think I will stick with the TomCat Filter technique at the moment, I
am struggling to see the advantage of using cocoon.***Component() stuff
in this situation to be honest.
regards Jeremy
RE: Flow Database stuff ( The new FOM? )
From: Jeremy Quinn [mailto:[EMAIL PROTECTED]
On Tuesday, July 15, 2003, at 08:28 AM, Christopher Oliver wrote:
Reinhard Pötz wrote:
From: Christopher Oliver [mailto:[EMAIL PROTECTED]
snip
catch (break) {
// a continuation is being captured,
// code to
handle that goes here
releaseSession();
}
... and this is called after the pipeline has been
processed? How is
this possible from a technical POV? If the view layer is called by
sendPageAndWait the flow interpreter isn't active until
the response
returns from the client (map:call continuation=...).
Reinhard
Unfortunately, you're right. In this case the call to
releaseSession()
is made when the continuation is created - which is before the view
layer is called (see fom_system.js).
I've just commited an update to Rhino that [re-]enables a further
syntax extension, namely:
catch (return) {
// This continuation is about to be replaced with another
continuation
// code to handle that goes here
}
By placing the code to release the hibernate session inside, i.e.
catch (return) {
cocoon.releaseComponent(hibSession);
}
you get the effect you're looking for: namely that the session is
released after calling the view layer but before control leaves the
interpreter.
As I said, Ovidiu and I decided to put these features in to try to
provide the functionality provided by dynamic-wind in
Scheme, but this
kind of explicit resource management seems awkard and error-prone.
Thanks Chris
I think I will stick with the TomCat Filter technique at the
IIRC filters are part of the servlet spec, aren't they?
moment, I
am struggling to see the advantage of using
cocoon.***Component() stuff
in this situation to be honest.
In this case it's a matter of taste. But I will do some research with
the alternative implementation by Chris.
Cheers,
Reinhard
Re: Flow Database stuff ( The new FOM? )
Reinhard Pötz wrote: To understand this correctly: Does e.g. Hibernate give you this typed object repository? You only have to deal with beans and all the persistence stuff is done for you by magic. No. You still have to open a Session to your database and use its methods to load and store objects. What Hibernate (and other ORM tools like JDO, if I'm not mistaken) gives you is that now you are working with POJOs (Plain Old Java Objects) instead of with ResultSets or with EJBs. You also map relations to object references and Collections (Maps, Sets, Lists) and so you manage your objects in an idiomatic way that is more friendly to us Java programmers. Ugo -- Ugo Cei - http://www.beblogging.com/blog/
Re: Flow Database stuff ( The new FOM? )
On Sunday, July 13, 2003, at 10:30 AM, Reinhard Pötz wrote:
From: Jeremy Quinn [mailto:[EMAIL PROTECTED]
By passing a Bean persisted by Hibernate from the flow layer to the
view layer, you are implementing SoC by allowing the view layer to
decide what is relevant for that view. This aspect not being
the Flow's
concern.
Only to make it transparent (for me): The flow layer passes e.g. a
user bean with the id 4711 to the view layer. The view layer only
knows that it can expect a user bean and has tho show e.g. the name
and the adress and so it doesn't care where the bean comes from
(database,
webservice, ...). Do we agree on this?
I reckon we do
However, once you have triggered the view layer with
SendPageAndWait(),
control does not return to the flow layer until the Response has been
sent and the next Request received, thus loosing you the
opportunity to
close the Hibernate Session from the Flow layer before the
Response is
sent.
Chris' experimental implementation of cocoon.getComponent() should
solve
this problem.
Interesting .
I am not entirely sure how right now, but will look into this.
SendPage() might not suffer this problem, but due to the nature of a
SAX event pipeline, I would not bet on it.
With 'lazy initialisation' SQL Queries are only made when getter
methods of the Bean are executed. If you have passed the Bean to the
view layer, XPath expressions in JXPathTemplate (etc.) will result in
those getter methods being accessed. If your flowscript has already
released it's Hibernate Component, you are in trouble.
You could clone the Bean to pass it to the view layer, but it is kind
of self-defeating IMHO.
Why do you think it is self-defeating? IIUC the point of lazy
initialization
is calling the persistence layer at the time when it is really needed
(when I generate some output). If I pass the bean with
sendPageAndWait(myPage, {bean:bean}) I *already know* that I need
this
bean
- otherwise I wouldn't pass it, wouldn't I?
OK, yes in this simple case you are right.
I am too tied up in my head with my current project where I have lots
of one-to-many and many-to-many relationships between composite
beans, whereby loading one Bean would conceptually load 10k rows out
of my DB.
Under these circumstances I take advantage of lazy-initialisation and
let the view layer decide that it wants to show (eg.) siblings
(bean.parent.children) for navigation purposes, or just a few local
properties (bean.name, bean.description etc.) for editing.
Additionally, in the case of editing, I tend to copy the editable
properties to a temporary JS Properties list to pass to the view layer
as I do not wish to be bothered with rolling back any changes if the
user cancels halfway through, though this might not be one of my best
design decisions ;)
regards Jeremy
Re: Flow Database stuff ( The new FOM? )
On Sunday, July 13, 2003, at 10:40 AM, Reinhard Pötz wrote: However, once you have triggered the view layer with SendPageAndWait(), control does not return to the flow layer until the Response has been sent and the next Request received, thus loosing you the opportunity to close the Hibernate Session from the Flow layer before the Response is sent. Chris' experimental implementation of cocoon.getComponent() should solve this problem. I am not very confidant with the lifecycle of Cocoon/Avalon components, would someone be kind enough to recommend which methods I should ideally write to implement a (Hibernate Factory) component, and at which stage in FlowScript processing they get called? TIA regards Jeremy
RE: Flow Database stuff ( The new FOM? )
Title: RE: Flow Database stuff ( The new FOM? ) The lifecycle for components is defined by avalon. There is a good explanation of the order in which the methods are called during the initialization at avalon's website. http://avalon.apache.org/framework/reference-the-lifecycle.html Jon -Original Message- From: Jeremy Quinn [mailto:[EMAIL PROTECTED]] Sent: Monday, July 14, 2003 8:43 AM To: [EMAIL PROTECTED] Subject: Re: Flow Database stuff ( The new FOM? ) On Sunday, July 13, 2003, at 10:40 AM, Reinhard Pötz wrote: However, once you have triggered the view layer with SendPageAndWait(), control does not return to the flow layer until the Response has been sent and the next Request received, thus loosing you the opportunity to close the Hibernate Session from the Flow layer before the Response is sent. Chris' experimental implementation of cocoon.getComponent() should solve this problem. I am not very confidant with the lifecycle of Cocoon/Avalon components, would someone be kind enough to recommend which methods I should ideally write to implement a (Hibernate Factory) component, and at which stage in FlowScript processing they get called? TIA regards Jeremy
Re: Flow Database stuff ( The new FOM? )
On Monday, July 14, 2003, at 04:39 PM, Hugo Burm wrote: -Original Message- From: Jeremy Quinn [mailto:[EMAIL PROTECTED] Sent: Monday, July 14, 2003 3:43 PM To: [EMAIL PROTECTED] Subject: Re: Flow Database stuff ( The new FOM? ) On Sunday, July 13, 2003, at 10:40 AM, Reinhard Pötz wrote: However, once you have triggered the view layer with SendPageAndWait(), control does not return to the flow layer until the Response has been sent and the next Request received, thus loosing you the opportunity to close the Hibernate Session from the Flow layer before the Response is sent. Chris' experimental implementation of cocoon.getComponent() should solve this problem. I am not very confidant with the lifecycle of Cocoon/Avalon components, would someone be kind enough to recommend which methods I should ideally write to implement a (Hibernate Factory) component, and at which stage in FlowScript processing they get called? TIA regards Jeremy 1) There is an Avalon Hibernate Factory in the Hibernate_ext contributed package (see the Hibernate project at Sourceforge), and one in the Hibernate examples on the Wiki. Thanks for the pointers. What I do not grok ATM, how does the Hibernate Session automatically get closed at the appropriate time (ie. after the view layer has completed)? I can see that initialize() and dispose() (are these the ones that would get called on each Request?) seem to be dealing with SessionFactory, not the Session itself. TIA regards Jeremy
RE: Flow Database stuff ( The new FOM? )
From: Berin Loritsch Ugo Cei wrote: Reinhard Pötz wrote: As I'm curious I have a technical question: What's the difference if I read the necessary data in the flow or some milliseconds latter in the view layer? What do I gain? You gain a cleaner separation of concerns. I simply don't like accessing my persistence layer from the view. The view is passed a model that consisits of Javascript objects, Java beans or DOMs and it should not care where it comes from. Just IMHO, There is no right answer on this. Some folks don't mind the overhead of populating and passing objects around while others prefer a more direct approach. The latter is most common in the prototyping stage where you are telling management about new things you can do. That said, I prefer both the view and the flow to merely use objects and not control persistence directly. This allows me the freedom to define a typed object repository that encapsulates persistence and caching concerns. But I have worked on projects where it was easier for a quick and dirty approach. To understand this correctly: Does e.g. Hibernate give you this typed object repository? You only have to deal with beans and all the persistence stuff is done for you by magic. Cheers, Reinhard
RE: Flow Database stuff ( The new FOM? )
From: Berin Loritsch Ugo Cei wrote: Reinhard Pötz wrote: As I'm curious I have a technical question: What's the difference if I read the necessary data in the flow or some milliseconds latter in the view layer? What do I gain? You gain a cleaner separation of concerns. I simply don't like accessing my persistence layer from the view. The view is passed a model that consisits of Javascript objects, Java beans or DOMs and it should not care where it comes from. Just IMHO, There is no right answer on this. Some folks don't mind the overhead of populating and passing objects around while others prefer a more direct approach. The latter is most common in the prototyping stage where you are telling management about new things you can do. That said, I prefer both the view and the flow to merely use objects and not control persistence directly. This allows me the freedom to define a typed object repository that encapsulates persistence and caching concerns. But I have worked on projects where it was easier for a quick and dirty approach. To understand this correctly: Does e.g. Hibernate give you this typed object repository? You only have to deal with beans and all the persistence stuff is done for you by magic. Cheers, Reinhard
Re: Flow Database stuff ( The new FOM? )
On Thursday, July 10, 2003, at 09:04 AM, Reinhard Pötz wrote: IMO no. I would use Object/Relational mapping tools like OJB http://db.apache.org/ojb/ or Hibernate (http://hibernate.bluemars.net). Is there a wiki somewhere on this type of thing? http://wiki.cocoondev.org/ Wiki.jsp?page=XMLFormJXFormHibernateAndFlowscr ipt and here you find a component providing a Hibernate session: http://cvs.werken.com/viewcvs.cgi/plexus-components/hibernate /src/java/org/apache/plexus/hibernate/ DefaultHibernateService.java?cvsro ot=plexus Forgive me if I have not entirely understood the usage patterns of the classes above. However, with the generous assistance of Ugo Cei, I am successfully using the technique highlighted in the first sample here [1] for managing Hibernate Sessions in my FlowApp. The basic issue is that you want to avoid maintaining an open Hibernate Session whilst the user is interacting with a form (etc.). The Session should to be opened and closed during each Request (and any Transient Beans refreshed before re-use). The above technique uses a Servlet Filter to manage this, with a static method to retrieve a Session in your flowscript at the beginning of each Request that needs it. [1] http://hibernate.bluemars.net/43.html HTH regards Jeremy
RE: Flow Database stuff ( The new FOM? )
From: Jeremy Quinn
On Thursday, July 10, 2003, at 09:04 AM, Reinhard Pötz wrote:
IMO no. I would use Object/Relational mapping tools like OJB
http://db.apache.org/ojb/ or Hibernate
(http://hibernate.bluemars.net).
Is there a wiki somewhere on this type of thing?
http://wiki.cocoondev.org/
Wiki.jsp?page=XMLFormJXFormHibernateAndFlowscr
ipt
and here you find a component providing a Hibernate session:
http://cvs.werken.com/viewcvs.cgi/plexus-components/hibernate
/src/java/org/apache/plexus/hibernate/
DefaultHibernateService.java?cvsro
ot=plexus
Forgive me if I have not entirely understood the usage
patterns of the
classes above.
IIUC this component provides a Hibernate Session. At the current
FOM implementation you have to take care that you open and close
these sessions correctly.
However, with the generous assistance of Ugo Cei, I am successfully
using the technique highlighted in the first sample here [1] for
managing Hibernate Sessions in my FlowApp.
The basic issue is that you want to avoid maintaining an open
Hibernate
Session whilst the user is interacting with a form (etc.).
The Session
should to be opened and closed during each Request (and any
Transient
Beans refreshed before re-use). The above technique uses a Servlet
Filter to manage this, with a static method to retrieve a Session in
your flowscript at the beginning of each Request that needs it.
[1] http://hibernate.bluemars.net/43.html
Sounds cool and I remember that I've already heard from it but
haven't found the time to try it myself.
dream-mode
I would like to use this Avalon component mentioned above and
the Flow interpreter takes care of releasing (and providing)
stateful components within my scripts. So I would have to
lookup the Hibernate Session at the beginning(2) and until I
finally release(8) it I don't have to take care for it.
1 function xxx() {
2var hibS = cocoon.getComponent( hibernateSession );
3var custBean = hibS.blablabla // get your beans with hibernate
4sendPageAndWait( bla, {customer : custBean} );
5// do something (updates, reads, whatever)
6var someDifferentBean = hibS.blalbalba
7sendPageAndWait( bla, {diff : someDifferentBean } );
8sendPageAndRelease( thankYou, {} );
9 }
This would be IMO a very elegant way and IIU the recent discussion
correctly possible from a technical point of view. Maybe Chris
can comment on this :-)
Thoughts?
/dream-mode
Cheers,
Reinhard
RE: Flow Database stuff ( The new FOM? )
From: Jeremy Quinn
The problem arises when you wish to use a (brilliant) feature of
Hibernate called 'lazy-initialisation', whereby access to the DB is
only made when you actually ask for Bean Properties.
This is particularly useful when you have large 'graphs' of related
Beans, for instance child/parent relationships, whereby loading one
Bean may result in the whole database loading!!
If you have closed your Hibernate Session in your Flowscript, your
display layer can throw LazyInitialisationExceptions, because the
connection is no longer available.
Not closing the Session after you have sent the Response, is
considered
bad practise, so the Servlet Filter is a handy solution.
It's a pity that Hibernate is under LGPL - this would be a great example
...
Have the Hibernate people ever been asked if they would put their
great piece of software under a more Apache like licence?
As I'm curious I have a technical question:
What's the difference if I read the necessary data in the flow or some
milliseconds latter in the view layer? What do I gain?
However, with the generous assistance of Ugo Cei, I am
successfully
using the technique highlighted in the first sample here [1] for
managing Hibernate Sessions in my FlowApp.
The basic issue is that you want to avoid maintaining an open
Hibernate Session whilst the user is interacting with a
form (etc.).
The Session
should to be opened and closed during each Request (and any
Transient
Beans refreshed before re-use). The above technique uses a Servlet
Filter to manage this, with a static method to retrieve a
Session in
your flowscript at the beginning of each Request that needs it.
[1] http://hibernate.bluemars.net/43.html
Sounds cool and I remember that I've already heard from it
but haven't
found the time to try it myself.
I am using it ATM on a client project and it is a dream!
dream-mode
I would like to use this Avalon component mentioned above and the
Flow interpreter takes care of releasing (and providing) stateful
components within my scripts. So I would have to lookup
the Hibernate
Session at the beginning(2) and until I finally release(8)
it I don't
have to take care for it.
1 function xxx() {
2var hibS = cocoon.getComponent( hibernateSession );
3var custBean = hibS.blablabla // get your beans with hibernate
4sendPageAndWait( bla, {customer : custBean} );
5// do something (updates, reads, whatever)
6var someDifferentBean = hibS.blalbalba
7sendPageAndWait( bla, {diff : someDifferentBean } );
8sendPageAndRelease( thankYou, {} );
9 }
This would be IMO a very elegant way and IIU the recent
discussion
correctly possible from a technical point of view. Maybe Chris can
comment on this :-)
Thoughts?
This is a reality!
Wake up and smell the toast ;)
;-)
I just do not use the Component Manager, because I cannot manage the
Hibernate Session entirely from the FlowScript layer as explained
above. I have a static method that gives me a fresh Session. I get s
Session at the beginning of Function, or directly after a
sendPageAndWait().
Is it possible to have a look at the sources? I would be very
interested!
Cheers,
Reinhard
Re: Flow Database stuff ( The new FOM? )
Will the attached work?
Reinhard Pötz wrote:
dream-mode
I would like to use this Avalon component mentioned above and
the Flow interpreter takes care of releasing (and providing)
stateful components within my scripts. So I would have to
lookup the Hibernate Session at the beginning(2) and until I
finally release(8) it I don't have to take care for it.
1 function xxx() {
2var hibS = cocoon.getComponent( hibernateSession );
3var custBean = hibS.blablabla // get your beans with hibernate
4sendPageAndWait( bla, {customer : custBean} );
5// do something (updates, reads, whatever)
6var someDifferentBean = hibS.blalbalba
7sendPageAndWait( bla, {diff : someDifferentBean } );
8sendPageAndRelease( thankYou, {} );
9 }
This would be IMO a very elegant way and IIU the recent discussion
correctly possible from a technical point of view. Maybe Chris
can comment on this :-)
Thoughts?
/dream-mode
Cheers,
Reinhard
/*
The Apache Software License, Version 1.1
Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
Redistribution and use in source and binary forms, with or without modifica-
tion, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
3. The end-user documentation included with the redistribution, if any, must
include the following acknowledgment: This product includes software
developed by the Apache Software Foundation (http://www.apache.org/).
Alternately, this acknowledgment may appear in the software itself, if
and wherever such third-party acknowledgments normally appear.
4. The names Apache Cocoon and Apache Software Foundation must not be
used to endorse or promote products derived from this software without
prior written permission. For written permission, please contact
[EMAIL PROTECTED]
5. Products derived from this software may not be called Apache, nor may
Apache appear in their name, without prior written permission of the
Apache Software Foundation.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU-
DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This software consists of voluntary contributions made by many individuals
on behalf of the Apache Software Foundation and was originally created by
Stefano Mazzocchi [EMAIL PROTECTED]. For more information on the Apache
Software Foundation, please see http://www.apache.org/.
*/
package org.apache.cocoon.components.flow.javascript.fom;
import java.io.OutputStream;
import java.util.Enumeration;
import java.util.Iterator;
import java.util.LinkedList;
import java.util.List;
import java.util.Map;
import java.util.Set;
import java.util.HashSet;
import org.apache.avalon.framework.component.Component;
import org.apache.avalon.framework.component.ComponentManager;
import org.apache.avalon.framework.logger.Logger;
import org.apache.cocoon.components.flow.ContinuationsManager;
import org.apache.cocoon.components.flow.WebContinuation;
import org.apache.cocoon.environment.Cookie;
import org.apache.cocoon.environment.Environment;
import org.apache.cocoon.environment.ObjectModelHelper;
import org.apache.cocoon.environment.Request;
import org.apache.cocoon.environment.Response;
import org.apache.cocoon.environment.Session;
import org.mozilla.javascript.*;
import org.mozilla.javascript.continuations.Continuation;
/**
* Implementation of FOM (Flow Object Model).
*
* @since 2.1
* @author a href=mailto:coliver.at.apache.org;Christopher Oliver/a
* @author a href=mailto:reinhard.at.apache.org;Reinhard Pötz/a
* @version CVS $Id: FOM_Cocoon.java,v 1.3 2003/07/10 11:40:57 cziegeler Exp $
*/
public class FOM_Cocoon extends ScriptableObject {
private FOM_JavaScriptInterpreter interpreter;
private Environment environment;
private
RE: Flow Database stuff ( The new FOM? )
Hello, I tried to raise this LGPL issue in the Hibernate community. The answer of Gaving King and Cristian Bauer was: we stick to LGPL untill we have a compelling reason (a real case) to change our minds. I did not try to explain that Apache is refusing LGPL altogether. Hugo -Original Message- From: Reinhard Pötz [mailto:[EMAIL PROTECTED] Sent: Friday, July 11, 2003 6:46 PM To: [EMAIL PROTECTED] Subject: RE: Flow Database stuff ( The new FOM? ) It's a pity that Hibernate is under LGPL - this would be a great example ... Have the Hibernate people ever been asked if they would put their great piece of software under a more Apache like licence? Cheers, Reinhard
Re: Flow Database stuff ( The new FOM? )
Reinhard Pötz wrote:
Hi Chris,
I'll give it a try this weekend.
To understand the changes: In a function with continuations I
call a component once and if sendPageAndWait() is called the
component is released automatically. If the continuation
created is called later the variable with a pointer to a
component will be reassigned with a newly created component of
the same type?
Yep.
I know this sounds very disbelieving but I wrote my mail only
a few hours ago and you come up with a solution ... ;-)
I had already prototyped it. I didn't write it after you sent your message.
Another question: The JXTemplate* stuff and the petstore are
moved to the main trunk or a block. Do you plan to move the
JXForms into the XMLForms package? (I want to avoid duplicate
work because could have time this weekend doing it but can't
promise it now.) So if you have time don't hesitate ;-)
I think it would be easiest to move it to its own block. Then we could
deprecate XMLForm and those who are using it won't get broken. I'm not
sure how you would merge it with the XMLForm block, anyway. If making
JXForms its own block is ok, then I can do that. Otherwise, I don't
think I'll be able to spend time merging it with XMLForm.
Cheers,
Reinhard
-Original Message-
From: Christopher Oliver [mailto:[EMAIL PROTECTED]
Sent: Friday, July 11, 2003 6:56 PM
To: [EMAIL PROTECTED]
Subject: Re: Flow Database stuff ( The new FOM? )
Will the attached work?
Reinhard Pötz wrote:
dream-mode
I would like to use this Avalon component mentioned above and the
Flow interpreter takes care of releasing (and providing) stateful
components within my scripts. So I would have to lookup the
Hibernate
Session at the beginning(2) and until I finally release(8)
it I don't
have to take care for it.
1 function xxx() {
2var hibS = cocoon.getComponent( hibernateSession );
3var custBean = hibS.blablabla // get your beans with hibernate
4sendPageAndWait( bla, {customer : custBean} );
5// do something (updates, reads, whatever)
6var someDifferentBean = hibS.blalbalba
7sendPageAndWait( bla, {diff : someDifferentBean } );
8sendPageAndRelease( thankYou, {} );
9 }
This would be IMO a very elegant way and IIU the recent discussion
correctly possible from a technical point of view. Maybe Chris can
comment on this :-)
Thoughts?
/dream-mode
Cheers,
Reinhard
RE: Flow Database stuff ( The new FOM? )
From: Hugo Burm Hello, This dreammode is almost a reality. See the Wiki pages on Hibernate. Main spoilers are: - A user can quit in the middle of your function xxx (e.g. by closing the browser). This will generate a zombie Hibernate session. Jeremy and Ugo are using a workaround based on an newer version of the servlet api. Maybe Chris' latest prototyp of FOM_Cocoon can help to manage the zombie session problem. - Hibernate is LGPL. This is a pain in the ass. I cannot provide a ready-to-use Hibernate cocoon block because of LGPL versus Apache license issues. We (the Cocoon community) should contact them. Maybe there's a chance ... Cheers, Reinhard
Re: Flow Database stuff ( The new FOM? )
I definately plan to write up some stuff on what it took to get me running.
I have taken a few clients and used cocoon to solve small, specific issues
with alot less hassle and better maintainablity than PHP/PERL has proven to
be.
I have taken an in house project (An office manger to track our time and
project issues) and am developing it with flow. we use it everyday, and alot
of time is spent hack-hack-hacking. alot is still in xsp.. just because it
is faster to build. Once I get it all usable, I will start writing wiki on
where I got stuck (Being new to java)
The issue I am having right now is this one:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105612521608516w=2
After I saw the recent activity on the FOM, I gave it a go, but waaayy over
my head for now.
Basically.. I have sitemap match a lookup time ticket form, which calls a
JXForm (sitemap calls jxform function), then displays the results. ( I used
the petstore sample to get me going.) The error happens if someone else logs
in from another machine. and does the same action. The first person in gets
cannot convert null to an object. Seems that the second user's database
connection bumps the first one into nothingness.
I tried to implement the change posted to the list, (In the above thread),
but I must be mixed up about what has been changed in the cvs, because I got
a nullpointer errors loading JXForms.js in my flowscript.
So I thought I would try to figure out what the best practice for this would
be :)
JD
- Original Message -
From: Reinhard Pötz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, July 10, 2003 12:04 AM
Subject: RE: Flow Database stuff ( The new FOM? )
From: JD Daniels
ok, I am confused on what is happening to the Datbase.js
file. but instead of a request for the long explanation, I
will settle for a quick yes or no.
I am a java newbie... so bear with me...
From the petstore:
// temporary hack to avoid requiring datasource
config in cocoon.xconf
java.lang.Class.forName(org.hsqldb.jdbcDriver);
var jdbc =
java.sql.DriverManager.getConnection(jdbc:hsqldb:.,
sa, )
var conn = new Database(jdbc);
if (this.hsql == null) {
// keep hsql in-memory database alive
this.hsql =
java.sql.DriverManager.getConnection(jdbc:hsqldb:., sa, );
}
return conn;
} else {
// lookup datasource in cocoon.xconf
return Database.getConnection(id);
}
Is what has been talked about here on the list mean the Best
Practice way to get a database connection in flow is the way
that is commented here as a temporary hack ie. use
java.lang.whatever and code as if we were writing the app in
pure java?
IMO no. I would use Object/Relational mapping tools like OJB
http://db.apache.org/ojb/ or Hibernate (http://hibernate.bluemars.net).
Is there a wiki somewhere on this type of thing?
http://wiki.cocoondev.org/Wiki.jsp?page=XMLFormJXFormHibernateAndFlowscr
ipt
and here you find a component providing a Hibernate session:
http://cvs.werken.com/viewcvs.cgi/plexus-components/hibernate
/src/java/org/apache/plexus/hibernate/DefaultHibernateService.java?cvsro
ot=plexus
(I have been
building apps in PHP and PERL for a few years, and its gets
frustrating KNOWING way better tools are RIGHT HERE in front of me :)
Currently we are finishing the flow itself and try to find a way how to
continue with XMLForms/JXForms in the future. After this we will have
to write *a lot of* documentation. I know, this doesn't help you
right now but of course we can help you here on the cocoon mailing
lists.
;-) hint: We would be very pleased if you could help us writing
some of the docs that guide other users into the right direction if they
have similar problems (espacially as you have a lot of knowledge in
other
languages/framworks and this is of course one of our most important
target
groups)
Sorry if this is a pain in the *** question, bu tthe idea of
flow has me giddy. But I am stuck on the cannot convert null
to an object issue
Where do you get this error? Usually this happens if you change your
scripts and the context is reset and all variables are reset.
Cheers,
Reinhard
RE: Flow Database stuff ( The new FOM? )
From: JD Daniels Thanks! I think I will go have a look at Hibernate .. that looks helpful While I wait for FOM to settle down... stay tuned ... the vote is already running! Cheers, Reinhard
