You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Jakob Schwendner <ja...@publicimage.eu.com> on 2004/06/30 05:50:12 UTC
cocoon and hibernate sessions
Hi,
I am using cocoon 2.1.5 and hibernate. I have got a component wrapping the SessionFactory and as far as I can tell everything seems to work pretty well. The issue is that I am using a session-per-user-session anti-pattern as defined by the hibernate documentation http://www.hibernate.org/168.html. I would like to move to a session-per-request pattern. I figured it would be easy to keep a session per thread using a ThreadLocal. The only problem is that I don't know where I could close the session again.
Has anyone done this before? If not, where would be good points to create and close the hibernate session. Maybe in the flow using a threadlocal and close it whenever a page view is called? The problem with that is that the session would need to stay open until after the view call as there might be lazy objects that get displayed.
Any help appreciated,
Jakob Schwendner
------
Public Image
Creative Strategy & Production
for Print, Online & Broadcast Media
Re: cocoon and hibernate sessions
Posted by Ugo Cei <u....@cbim.it>.
Jakob Schwendner wrote:
> I am using cocoon 2.1.5 and hibernate. I have got a component wrapping
> the SessionFactory and as far as I can tell everything seems to work
> pretty well. The issue is that I am using a session-per-user-session
> anti-pattern as defined by the hibernate documentation
> http://www.hibernate.org/168.html. I would like to move to a
> session-per-request pattern. I figured it would be easy to keep a
> session per thread using a ThreadLocal. The only problem is that I don't
> know where I could close the session again.
You could use the "Open Session in View" pattern:
http://hibernate.org/43.html
Ugo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: cocoon and hibernate sessions
Posted by Stephan Coboos <cr...@gmx.net>.
Peter Velychko wrote:
>> <>Another possibility is using Filter to open/close hibernate session as
>> http://www.hibernate.org/43.html.
>> This way was also discussed previously in the list.
>> I plan to try to implement this method in my project.
>
Yes but with filter you will bind your application on the servlet
container. If your application is only a webapp and will never be run
outside a servlet container, this way is OK. Otherwise not.
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: cocoon and hibernate sessions
Posted by Peter Velychko <v_...@ukr.net>.
Hello Stephan,
Wednesday, June 30, 2004, 12:12:10 PM, you wrote:
> Jakob Schwendner wrote:
>>Hi,
>>
>>I am using cocoon 2.1.5 and hibernate. I have got a component wrapping the SessionFactory and as far as I can tell everything seems to work pretty well. The issue is that I am using a
>>session-per-user-session anti-pattern as defined by the hibernate documentation http://www.hibernate.org/168.html. I would like to move to a session-per-request pattern. I figured it would be easy
>>to keep a session per thread using a ThreadLocal. The only problem is that I don't know where I could close the session again.
>>Has anyone done this before? If not, where would be good points to create and close the hibernate session. Maybe in the flow using a threadlocal and close it whenever a page view is called? The
>>problem with that is that the session would need to stay open until after the view call as there might be lazy objects that get displayed.
>>Any help appreciated,
>>
>>
> Hi Jakob,
> I think this problem was discussed here before several times. Not tested
> and just an idea: Why not store the Hibernate-Session-Object into the
> Request-Scope and writting an action which extracts the
> Hibernate-Session and closes them after generating the view. A pipeline
> fragment could be looked like the following:
> <map:match pattern="foo.jxt">
> <map:generate type="jxt" src="foo.jxt"/>
> <map:act type="closeHibernateSession"/>
> <map:serialize type="html"/>
> </map:match>
> Regards
Another possibility is using Filter to open/close hibernate session as
http://www.hibernate.org/43.html.
This way was also discussed previously in the list.
I plan to try to implement this method in my project.
--
Best regards,
Peter Velychko
v_peter@ukr.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: cocoon and hibernate sessions
Posted by Peter Velychko <v_...@ukr.net>.
Hello Jeremy,
Thursday, July 1, 2004, 4:43:33 PM, you wrote:
> On 1 Jul 2004, at 14:30, Peter Velychko wrote:
>> Hello Upayavira,
>>
>> Thank you for your reply.
>>
>>> That could work, but it would be working round, rather than working
>>> with, Cocoon. You would also be buffering your output, which is best
>>> avoided.
>> Yes, this is workaround. But why whole DOM tree caching is so bad idea?
> off the top of my head :
> 1) it makes lazy-initialisation useless, because I assume everything
> would always get read from the DB regardless of whether you need it in
> the view-layer or not
In case of one uses large model wich can be updated I think
lazy-initialisation is usefull because it helps to save system
resources during regenerating response.
> 2) I (for one) have data models that if they are not lazy initialised
> would actually load every record in the database, because everything is
> ultimately linked.
> 3) you could end up with circular dependencies from (2) that make an
> infinitely large DOM
Yes it is fairly. There is some risk.
> 4) there are much better ways of doing it IMHO ;)
Yes I think there are a lot of ways to go.
It was only idea for discussing :)
> So it would depend on your data model as to how well this worked.
> HTH
> regards Jeremy
> --------------------------------------------------------
> If email from this address is not signed
> IT IS NOT FROM ME
> Always check the label, folks !!!!!
> --------------------------------------------------------
--
Best regards,
Peter Velychko
v_peter@ukr.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Caching full pages from flowscript (was Re: cocoon and hibernate sessions)
Posted by Peter Velychko <v_...@ukr.net>.
Hello Upayavira,
Thursday, July 1, 2004, 4:55:27 PM, you wrote:
> Jeremy Quinn wrote:
>>
>> On 1 Jul 2004, at 14:30, Peter Velychko wrote:
>>
>>> Hello Upayavira,
>>>
>>> Thank you for your reply.
>>>
>>>> That could work, but it would be working round, rather than working
>>>> with, Cocoon. You would also be buffering your output, which is best
>>>> avoided.
>>>
>>> Yes, this is workaround. But why whole DOM tree caching is so bad idea?
>>
>>
>> off the top of my head :
>>
>> 1) it makes lazy-initialisation useless, because I assume everything
>> would always get read from the DB regardless of whether you need it in
>> the view-layer or not
>>
>> 2) I (for one) have data models that if they are not lazy initialised
>> would actually load every record in the database, because everything
>> is ultimately linked.
>>
>> 3) you could end up with circular dependencies from (2) that make an
>> infinitely large DOM
>>
>> 4) there are much better ways of doing it IMHO ;)
>>
>> So it would depend on your data model as to how well this worked.
>>
> I don't think it does make lazy initialisation useless - as it produces
> the page, with processPipelineTo. Which is okay. It would work. It is
> more a question of storing the whole page in memory not being very
> advisible. Best avoided. It avoids the pipeline's SAX streaming benefit.
It's also possible to use caching system to store response content.
I think it may be used for pages that have high frequency of requests
to them (a la "pseudostatic" pages).
> Upayavira
--
Best regards,
Peter Velychko
v_peter@ukr.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: cocoon and hibernate sessions
Posted by Upayavira <uv...@upaya.co.uk>.
Jeremy Quinn wrote:
>
> On 1 Jul 2004, at 14:30, Peter Velychko wrote:
>
>> Hello Upayavira,
>>
>> Thank you for your reply.
>>
>>> That could work, but it would be working round, rather than working
>>> with, Cocoon. You would also be buffering your output, which is best
>>> avoided.
>>
>> Yes, this is workaround. But why whole DOM tree caching is so bad idea?
>
>
> off the top of my head :
>
> 1) it makes lazy-initialisation useless, because I assume everything
> would always get read from the DB regardless of whether you need it in
> the view-layer or not
>
> 2) I (for one) have data models that if they are not lazy initialised
> would actually load every record in the database, because everything
> is ultimately linked.
>
> 3) you could end up with circular dependencies from (2) that make an
> infinitely large DOM
>
> 4) there are much better ways of doing it IMHO ;)
>
> So it would depend on your data model as to how well this worked.
>
I don't think it does make lazy initialisation useless - as it produces
the page, with processPipelineTo. Which is okay. It would work. It is
more a question of storing the whole page in memory not being very
advisible. Best avoided. It avoids the pipeline's SAX streaming benefit.
Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: cocoon and hibernate sessions
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 1 Jul 2004, at 14:30, Peter Velychko wrote:
> Hello Upayavira,
>
> Thank you for your reply.
>
>> That could work, but it would be working round, rather than working
>> with, Cocoon. You would also be buffering your output, which is best
>> avoided.
> Yes, this is workaround. But why whole DOM tree caching is so bad idea?
off the top of my head :
1) it makes lazy-initialisation useless, because I assume everything
would always get read from the DB regardless of whether you need it in
the view-layer or not
2) I (for one) have data models that if they are not lazy initialised
would actually load every record in the database, because everything is
ultimately linked.
3) you could end up with circular dependencies from (2) that make an
infinitely large DOM
4) there are much better ways of doing it IMHO ;)
So it would depend on your data model as to how well this worked.
HTH
regards Jeremy
--------------------------------------------------------
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !!!!!
--------------------------------------------------------
Re: cocoon and hibernate sessions
Posted by Peter Velychko <v_...@ukr.net>.
Hello Upayavira,
Thank you for your reply.
> That could work, but it would be working round, rather than working
> with, Cocoon. You would also be buffering your output, which is best
> avoided.
Yes, this is workaround. But why whole DOM tree caching is so bad idea?
> This is an issue that requires a full solution. I believe the preferred
> way is something like:
> cocoon.sendPageAndWait("url", bizData, function(){session.close()});
> But I think there are some issues with this approach, and I believe it
> doesn't work with cocoon.sendPage.
Thank you. I will try to use
cocoon.sendPageAndWait("url", bizData, function(){session.close()})
for my projects.
> Fancy doing some digging into Cocoon's internals?
I'm trying now to understand cocoon more deeper.
But also sometimes crazy ideas visit my head.
> Regards, Upayavira
> Peter Velychko wrote:
>>Hello Upayavira,
>>
>>May be it is off topic.
>>There was discussion on using lazy loading with Hibernate.
>>Just a wild idea about it.
>>In flowscript we have possibility to get OutputStream or even DOM
>>tree to variable. And we can use the resulting DOM tree to generate
>>response.
>>(I'm not clear in my mind how can I use OutputStream in this way.)
>>
>>function doSomething() {
>> var doc;
>>
>> if (doc == undefined || doc == null) {
>> doc = generateContent();
>> }
>>
>> // responsing
>> cocoon.sendPage("response-pipeline", {doc: doc});
>>}
>>
>>function generateContent() {
>> // initialization
>> var factory = cocoon.getComponent(factoryURI);
>> var session = factory.openSession();
>> var someThing = doSomeDataWithSession(session);
>> var viewData = {someThing: someThing};
>>
>> // generating content
>> var pipelineUtil =
>> cocoon.createObject(Packages.org.apache.cocoon.components.flow.util.PipelineUtil);
>> var doc =
>> pipelineUtil.processToDOM("generate-content-pipeline", viewData);
>>
>> // releasing resources
>> session.close();
>> cocoon.releaseComponent(factory);
>>
>> return doc;
>>}
>>
>>So to realize this approach needs 3 sets of pipelines:
>>1. Set for invoking flowscript function
>> <map:match pattern="">
>> <map:call function="doSomething"/>
>> </map:match>
>>
>>2. Set for generating content (DOM)
>> <map:match pattern="generate-content-pipeline">
>> <map:generate type="jx" src="screens/generate.jx">
>> <map:parameter name="lenient-xpath" value="true"/>
>> </map:generate>
>> <map:transform type="i18n"/>
>> <map:serialize type="xml"/>
>> </map:match>
>>
>>3. Set for response
>> <map:match pattern="response-pipeline">
>> <map:generate type="jx" src="screens/response.jx"/>
>> <map:serialize type="html"/>
>> </map:match>
>>
>>I think it would be more advantageous to operate with OutputStream but
>>I don't know how it is possible to respond it from flowscript.
>>
>>
>>
>>>Stephan Coboos wrote:
>>>
>>>
>>
>>
>>
>>>>Upayavira wrote:
>>>>
>>>>
>>>>
>>>>>><map:match pattern="foo.jxt">
>>>>>> <map:generate type="jxt" src="foo.jxt"/>
>>>>>> <map:act type="closeHibernateSession"/>
>>>>>> <map:serialize type="html"/>
>>>>>></map:match>
>>>>>>
>>>>>>
>>>>>>
>>>>>This will not work.
>>>>>
>>>>>Actions are used when building a pipeline, not when processing it. So
>>>>>the action will take place before the view is processed, not after.
>>>>>
>>>>>
>>>>
>>>>Oh, what a pitty. It's a little bit consfusing me why action is
>>>>executed before processing the pipeline, but OK it is so. I think of
>>>>process switch within the pipline?
>>>>
>>>>
>>
>>
>>
>>>Actually, when understood, it makes complete sense.
>>>
>>>
>>
>>
>>
>>>So, to explain:
>>>
>>>
>>
>>
>>
>>>Any pipeline when built, goes generator->transformer...->serializer. And
>>>that is it. Anything else, such as matchers, selectors and actions, that
>>>influence the pipeline, are used when building the pipeline, not when
>>>using it. So imagine a process that goes:
>>>1) Which generator? Which transformers? Which serialiser
>>>2) Okay, I've worked out my pipeline, so: generator, go generate
>>>
>>>
>>
>>
>>
>>>And the generator then starts up, passing SAX events down the pipeline
>>>until the serialiser has consumed all resulting events and something has
>>>been returned to the user.
>>>Thus, actions are used when _building_ pipelines, not when _executing_ them.
>>>Hope that makes sense.
>>>Upayavira
--
Best regards,
Peter Velychko
v_peter@ukr.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: cocoon and hibernate sessions
Posted by Upayavira <uv...@upaya.co.uk>.
Jeremy Quinn wrote:
>
> On 1 Jul 2004, at 11:29, Upayavira wrote:
>
>> That could work, but it would be working round, rather than working
>> with, Cocoon. You would also be buffering your output, which is best
>> avoided.
>
>
> The solution looks far more complicated than it needs to be, also it
> makes lazy loading pointless.
>
>> This is an issue that requires a full solution. I believe the
>> preferred way is something like:
>>
>> cocoon.sendPageAndWait("url", bizData, function(){session.close()});
>
>
> I used the HibernateFactory component that is in the Wiki as a basis
> for my HibernateFactory.
>
> Most of my flowscripts (for just displaying Beans) look like this:
>
> function imageRecord() {
> var factory = cocoon.getComponent (PersistenceFactory.ROLE);
> var session = factory.createSession ();
> try {
> var image = ImagePeer.load (session, new java.lang.Long
> (cocoon.parameters["imageid"]));
> if (image != null) {
> cocoon.sendPage (cocoon.parameters["screen"], { image:
> image });
> } else {
> cocoon.sendPage("screen/error", {message:
> "error.no-record"});
> }
> } catch (e) {
> cocoon.log.error (e);
> cocoon.sendPage("screen/error", {message: e});
> } finally {
> session.close();
> cocoon.releaseComponent (factory);
> }
> }
>
> I use lazy-initialisation but do not have problems using JXTemplate
> with it.
>
> If you do get lazy-initialisation errors, I think the thing to try it
> to put this line after the cocoon.sendPage:
>
> catch (return) {session.close ()}
>
Could you make this:
catch (return) {print "Closing session"; session.close()}
and try again. And see if it actually does close the session.
Regards, Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: cocoon and hibernate sessions
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 1 Jul 2004, at 15:02, Peter Velychko wrote:
> Hello Jeremy,
>
> Thank you for your reply.
>
> Does you object "image" contain lazy collections?
11 of them
> I just accomplish a small experiment. I set up my serializer (that is
> inherited from HTMLSerializer but at end has the line
> System.out.println("from serializer"))
> and added the line
> print("from flowscript");
> to flowscript just after cocoon.sendPage().
> The result is the "from flowscript" message is uppere than
> "from serializer" message.
> So how can I get elements from lazy collection later than I close
> hibernate session after cocoon.sendPage()?
it works ;)
> Thank you for advise of using catch (return)
> I'll try to using it.
>
>> On 1 Jul 2004, at 11:29, Upayavira wrote:
>
>>> That could work, but it would be working round, rather than working
>>> with, Cocoon. You would also be buffering your output, which is best
>>> avoided.
>
>> The solution looks far more complicated than it needs to be, also it
>> makes lazy loading pointless.
>
>>> This is an issue that requires a full solution. I believe the
>>> preferred way is something like:
>>>
>>> cocoon.sendPageAndWait("url", bizData, function(){session.close()});
>
>> I used the HibernateFactory component that is in the Wiki as a basis
>> for my HibernateFactory.
>
>> Most of my flowscripts (for just displaying Beans) look like this:
>
>> function imageRecord() {
>> var factory = cocoon.getComponent (PersistenceFactory.ROLE);
>> var session = factory.createSession ();
>> try {
>> var image = ImagePeer.load (session, new
>> java.lang.Long
>> (cocoon.parameters["imageid"]));
>> if (image != null) {
>> cocoon.sendPage (cocoon.parameters["screen"],
>> { image: image });
>> } else {
>> cocoon.sendPage("screen/error", {message:
>> "error.no-record"});
>> }
>> } catch (e) {
>> cocoon.log.error (e);
>> cocoon.sendPage("screen/error", {message: e});
>> } finally {
>> session.close();
>> cocoon.releaseComponent (factory);
>> }
>> }
>
>> I use lazy-initialisation but do not have problems using JXTemplate
>> with it.
>
>> If you do get lazy-initialisation errors, I think the thing to try it
>> to put this line after the cocoon.sendPage:
>
>> catch (return) {session.close ()}
>
>> and take session.close () out of the finally clause.
>
>> if I am editing via CForms ..... I do a session.close() just before
>> and
>> session = factory.createSession (); just after the form.showForm
>> statement.
>
>> HTH
>
>> regards Jeremy
>
>>> But I think there are some issues with this approach, and I believe
>>> it
>>> doesn't work with cocoon.sendPage.
>>>
>>> Fancy doing some digging into Cocoon's internals?
>>>
>>> Regards, Upayavira
>>>
>>> Peter Velychko wrote:
>>>
>>>> Hello Upayavira,
>>>>
>>>> May be it is off topic.
>>>> There was discussion on using lazy loading with Hibernate.
>>>> Just a wild idea about it.
>>>> In flowscript we have possibility to get OutputStream or even DOM
>>>> tree to variable. And we can use the resulting DOM tree to generate
>>>> response.
>>>> (I'm not clear in my mind how can I use OutputStream in this way.)
>>>>
>>>> function doSomething() {
>>>> var doc;
>>>> if (doc == undefined || doc == null) {
>>>> doc = generateContent();
>>>> }
>>>>
>>>> // responsing
>>>> cocoon.sendPage("response-pipeline", {doc: doc});
>>>> }
>>>>
>>>> function generateContent() {
>>>> // initialization
>>>> var factory = cocoon.getComponent(factoryURI);
>>>> var session = factory.openSession();
>>>> var someThing = doSomeDataWithSession(session);
>>>> var viewData = {someThing: someThing};
>>>>
>>>> // generating content
>>>> var pipelineUtil =
>>>>
>>>> cocoon.createObject(Packages.org.apache.cocoon.components.flow.util.
>>>> Pi
>>>> pelineUtil);
>>>> var doc =
>>>> pipelineUtil.processToDOM("generate-content-pipeline",
>>>> viewData);
>>>> // releasing resources
>>>> session.close();
>>>> cocoon.releaseComponent(factory);
>>>>
>>>> return doc;
>>>> }
>>>>
>>>> So to realize this approach needs 3 sets of pipelines:
>>>> 1. Set for invoking flowscript function
>>>> <map:match pattern="">
>>>> <map:call function="doSomething"/>
>>>> </map:match>
>>>>
>>>> 2. Set for generating content (DOM)
>>>> <map:match pattern="generate-content-pipeline">
>>>> <map:generate type="jx" src="screens/generate.jx">
>>>> <map:parameter name="lenient-xpath" value="true"/>
>>>> </map:generate>
>>>> <map:transform type="i18n"/>
>>>> <map:serialize type="xml"/>
>>>> </map:match>
>>>>
>>>> 3. Set for response
>>>> <map:match pattern="response-pipeline">
>>>> <map:generate type="jx" src="screens/response.jx"/>
>>>> <map:serialize type="html"/>
>>>> </map:match>
>>>>
>>>> I think it would be more advantageous to operate with OutputStream
>>>> but
>>>> I don't know how it is possible to respond it from flowscript.
>>>>
>>>>
>>>>> Stephan Coboos wrote:
>>>>>
>>>>
>>>>
>>>>>> Upayavira wrote:
>>>>>>
>>>>>>
>>>>>>>> <map:match pattern="foo.jxt">
>>>>>>>> <map:generate type="jxt" src="foo.jxt"/>
>>>>>>>> <map:act type="closeHibernateSession"/>
>>>>>>>> <map:serialize type="html"/>
>>>>>>>> </map:match>
>>>>>>>>
>>>>>>>>
>>>>>>> This will not work.
>>>>>>>
>>>>>>> Actions are used when building a pipeline, not when processing
>>>>>>> it.
>>>>>>> So the action will take place before the view is processed, not
>>>>>>> after.
>>>>>>>
>>>>>>
>>>>>> Oh, what a pitty. It's a little bit consfusing me why action is
>>>>>> executed before processing the pipeline, but OK it is so. I think
>>>>>> of process switch within the pipline?
>>>>>>
>>>>
>>>>
>>>>> Actually, when understood, it makes complete sense.
>>>>>
>>>>
>>>>
>>>>> So, to explain:
>>>>>
>>>>
>>>>
>>>>> Any pipeline when built, goes
>>>>> generator->transformer...->serializer.
>>>>> And that is it. Anything else, such as matchers, selectors and
>>>>> actions, that influence the pipeline, are used when building the
>>>>> pipeline, not when using it. So imagine a process that goes:
>>>>> 1) Which generator? Which transformers? Which serialiser
>>>>> 2) Okay, I've worked out my pipeline, so: generator, go generate
>>>>>
>>>>
>>>>
>>>>> And the generator then starts up, passing SAX events down the
>>>>> pipeline until the serialiser has consumed all resulting events and
>>>>> something has been returned to the user.
>>>>>
>>>>
>>>>
>>>>> Thus, actions are used when _building_ pipelines, not when
>>>>> _executing_ them.
>>>>>
>>>>
>>>>
>>>>> Hope that makes sense.
>>>>>
>>>>
>>>>
>>>>> Upayavira
>
>
> --
> Best regards,
> Peter Velychko
> v_peter@ukr.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
--------------------------------------------------------
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !!!!!
--------------------------------------------------------
Re: cocoon and hibernate sessions
Posted by Peter Velychko <v_...@ukr.net>.
Hello Jeremy,
Thank you for your reply.
Does you object "image" contain lazy collections?
I just accomplish a small experiment. I set up my serializer (that is
inherited from HTMLSerializer but at end has the line
System.out.println("from serializer"))
and added the line
print("from flowscript");
to flowscript just after cocoon.sendPage().
The result is the "from flowscript" message is uppere than
"from serializer" message.
So how can I get elements from lazy collection later than I close
hibernate session after cocoon.sendPage()?
Thank you for advise of using catch (return)
I'll try to using it.
> On 1 Jul 2004, at 11:29, Upayavira wrote:
>> That could work, but it would be working round, rather than working
>> with, Cocoon. You would also be buffering your output, which is best
>> avoided.
> The solution looks far more complicated than it needs to be, also it
> makes lazy loading pointless.
>> This is an issue that requires a full solution. I believe the
>> preferred way is something like:
>>
>> cocoon.sendPageAndWait("url", bizData, function(){session.close()});
> I used the HibernateFactory component that is in the Wiki as a basis
> for my HibernateFactory.
> Most of my flowscripts (for just displaying Beans) look like this:
> function imageRecord() {
> var factory = cocoon.getComponent (PersistenceFactory.ROLE);
> var session = factory.createSession ();
> try {
> var image = ImagePeer.load (session, new java.lang.Long
> (cocoon.parameters["imageid"]));
> if (image != null) {
> cocoon.sendPage (cocoon.parameters["screen"], { image: image });
> } else {
> cocoon.sendPage("screen/error", {message: "error.no-record"});
> }
> } catch (e) {
> cocoon.log.error (e);
> cocoon.sendPage("screen/error", {message: e});
> } finally {
> session.close();
> cocoon.releaseComponent (factory);
> }
> }
> I use lazy-initialisation but do not have problems using JXTemplate
> with it.
> If you do get lazy-initialisation errors, I think the thing to try it
> to put this line after the cocoon.sendPage:
> catch (return) {session.close ()}
> and take session.close () out of the finally clause.
> if I am editing via CForms ..... I do a session.close() just before and
> session = factory.createSession (); just after the form.showForm
> statement.
> HTH
> regards Jeremy
>> But I think there are some issues with this approach, and I believe it
>> doesn't work with cocoon.sendPage.
>>
>> Fancy doing some digging into Cocoon's internals?
>>
>> Regards, Upayavira
>>
>> Peter Velychko wrote:
>>
>>> Hello Upayavira,
>>>
>>> May be it is off topic.
>>> There was discussion on using lazy loading with Hibernate.
>>> Just a wild idea about it.
>>> In flowscript we have possibility to get OutputStream or even DOM
>>> tree to variable. And we can use the resulting DOM tree to generate
>>> response.
>>> (I'm not clear in my mind how can I use OutputStream in this way.)
>>>
>>> function doSomething() {
>>> var doc;
>>> if (doc == undefined || doc == null) {
>>> doc = generateContent();
>>> }
>>>
>>> // responsing
>>> cocoon.sendPage("response-pipeline", {doc: doc});
>>> }
>>>
>>> function generateContent() {
>>> // initialization
>>> var factory = cocoon.getComponent(factoryURI);
>>> var session = factory.openSession();
>>> var someThing = doSomeDataWithSession(session);
>>> var viewData = {someThing: someThing};
>>>
>>> // generating content
>>> var pipelineUtil =
>>>
>>> cocoon.createObject(Packages.org.apache.cocoon.components.flow.util.Pi
>>> pelineUtil);
>>> var doc =
>>> pipelineUtil.processToDOM("generate-content-pipeline", viewData);
>>> // releasing resources
>>> session.close();
>>> cocoon.releaseComponent(factory);
>>>
>>> return doc;
>>> }
>>>
>>> So to realize this approach needs 3 sets of pipelines:
>>> 1. Set for invoking flowscript function
>>> <map:match pattern="">
>>> <map:call function="doSomething"/>
>>> </map:match>
>>>
>>> 2. Set for generating content (DOM)
>>> <map:match pattern="generate-content-pipeline">
>>> <map:generate type="jx" src="screens/generate.jx">
>>> <map:parameter name="lenient-xpath" value="true"/>
>>> </map:generate>
>>> <map:transform type="i18n"/>
>>> <map:serialize type="xml"/>
>>> </map:match>
>>>
>>> 3. Set for response
>>> <map:match pattern="response-pipeline">
>>> <map:generate type="jx" src="screens/response.jx"/>
>>> <map:serialize type="html"/>
>>> </map:match>
>>>
>>> I think it would be more advantageous to operate with OutputStream but
>>> I don't know how it is possible to respond it from flowscript.
>>>
>>>
>>>> Stephan Coboos wrote:
>>>>
>>>
>>>
>>>>> Upayavira wrote:
>>>>>
>>>>>
>>>>>>> <map:match pattern="foo.jxt">
>>>>>>> <map:generate type="jxt" src="foo.jxt"/>
>>>>>>> <map:act type="closeHibernateSession"/>
>>>>>>> <map:serialize type="html"/>
>>>>>>> </map:match>
>>>>>>>
>>>>>>>
>>>>>> This will not work.
>>>>>>
>>>>>> Actions are used when building a pipeline, not when processing it.
>>>>>> So the action will take place before the view is processed, not
>>>>>> after.
>>>>>>
>>>>>
>>>>> Oh, what a pitty. It's a little bit consfusing me why action is
>>>>> executed before processing the pipeline, but OK it is so. I think
>>>>> of process switch within the pipline?
>>>>>
>>>
>>>
>>>> Actually, when understood, it makes complete sense.
>>>>
>>>
>>>
>>>> So, to explain:
>>>>
>>>
>>>
>>>> Any pipeline when built, goes generator->transformer...->serializer.
>>>> And that is it. Anything else, such as matchers, selectors and
>>>> actions, that influence the pipeline, are used when building the
>>>> pipeline, not when using it. So imagine a process that goes:
>>>> 1) Which generator? Which transformers? Which serialiser
>>>> 2) Okay, I've worked out my pipeline, so: generator, go generate
>>>>
>>>
>>>
>>>> And the generator then starts up, passing SAX events down the
>>>> pipeline until the serialiser has consumed all resulting events and
>>>> something has been returned to the user.
>>>>
>>>
>>>
>>>> Thus, actions are used when _building_ pipelines, not when
>>>> _executing_ them.
>>>>
>>>
>>>
>>>> Hope that makes sense.
>>>>
>>>
>>>
>>>> Upayavira
--
Best regards,
Peter Velychko
v_peter@ukr.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: cocoon and hibernate sessions
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 1 Jul 2004, at 11:29, Upayavira wrote:
> That could work, but it would be working round, rather than working
> with, Cocoon. You would also be buffering your output, which is best
> avoided.
The solution looks far more complicated than it needs to be, also it
makes lazy loading pointless.
> This is an issue that requires a full solution. I believe the
> preferred way is something like:
>
> cocoon.sendPageAndWait("url", bizData, function(){session.close()});
I used the HibernateFactory component that is in the Wiki as a basis
for my HibernateFactory.
Most of my flowscripts (for just displaying Beans) look like this:
function imageRecord() {
var factory = cocoon.getComponent (PersistenceFactory.ROLE);
var session = factory.createSession ();
try {
var image = ImagePeer.load (session, new java.lang.Long
(cocoon.parameters["imageid"]));
if (image != null) {
cocoon.sendPage (cocoon.parameters["screen"], { image: image });
} else {
cocoon.sendPage("screen/error", {message: "error.no-record"});
}
} catch (e) {
cocoon.log.error (e);
cocoon.sendPage("screen/error", {message: e});
} finally {
session.close();
cocoon.releaseComponent (factory);
}
}
I use lazy-initialisation but do not have problems using JXTemplate
with it.
If you do get lazy-initialisation errors, I think the thing to try it
to put this line after the cocoon.sendPage:
catch (return) {session.close ()}
and take session.close () out of the finally clause.
if I am editing via CForms ..... I do a session.close() just before and
session = factory.createSession (); just after the form.showForm
statement.
HTH
regards Jeremy
> But I think there are some issues with this approach, and I believe it
> doesn't work with cocoon.sendPage.
>
> Fancy doing some digging into Cocoon's internals?
>
> Regards, Upayavira
>
> Peter Velychko wrote:
>
>> Hello Upayavira,
>>
>> May be it is off topic.
>> There was discussion on using lazy loading with Hibernate.
>> Just a wild idea about it.
>> In flowscript we have possibility to get OutputStream or even DOM
>> tree to variable. And we can use the resulting DOM tree to generate
>> response.
>> (I'm not clear in my mind how can I use OutputStream in this way.)
>>
>> function doSomething() {
>> var doc;
>> if (doc == undefined || doc == null) {
>> doc = generateContent();
>> }
>>
>> // responsing
>> cocoon.sendPage("response-pipeline", {doc: doc});
>> }
>>
>> function generateContent() {
>> // initialization
>> var factory = cocoon.getComponent(factoryURI);
>> var session = factory.openSession();
>> var someThing = doSomeDataWithSession(session);
>> var viewData = {someThing: someThing};
>>
>> // generating content
>> var pipelineUtil =
>>
>> cocoon.createObject(Packages.org.apache.cocoon.components.flow.util.Pi
>> pelineUtil);
>> var doc =
>> pipelineUtil.processToDOM("generate-content-pipeline", viewData);
>> // releasing resources
>> session.close();
>> cocoon.releaseComponent(factory);
>>
>> return doc;
>> }
>>
>> So to realize this approach needs 3 sets of pipelines:
>> 1. Set for invoking flowscript function
>> <map:match pattern="">
>> <map:call function="doSomething"/>
>> </map:match>
>>
>> 2. Set for generating content (DOM)
>> <map:match pattern="generate-content-pipeline">
>> <map:generate type="jx" src="screens/generate.jx">
>> <map:parameter name="lenient-xpath" value="true"/>
>> </map:generate>
>> <map:transform type="i18n"/>
>> <map:serialize type="xml"/>
>> </map:match>
>>
>> 3. Set for response
>> <map:match pattern="response-pipeline">
>> <map:generate type="jx" src="screens/response.jx"/>
>> <map:serialize type="html"/>
>> </map:match>
>>
>> I think it would be more advantageous to operate with OutputStream but
>> I don't know how it is possible to respond it from flowscript.
>>
>>
>>> Stephan Coboos wrote:
>>>
>>
>>
>>>> Upayavira wrote:
>>>>
>>>>
>>>>>> <map:match pattern="foo.jxt">
>>>>>> <map:generate type="jxt" src="foo.jxt"/>
>>>>>> <map:act type="closeHibernateSession"/>
>>>>>> <map:serialize type="html"/>
>>>>>> </map:match>
>>>>>>
>>>>>>
>>>>> This will not work.
>>>>>
>>>>> Actions are used when building a pipeline, not when processing it.
>>>>> So the action will take place before the view is processed, not
>>>>> after.
>>>>>
>>>>
>>>> Oh, what a pitty. It's a little bit consfusing me why action is
>>>> executed before processing the pipeline, but OK it is so. I think
>>>> of process switch within the pipline?
>>>>
>>
>>
>>> Actually, when understood, it makes complete sense.
>>>
>>
>>
>>> So, to explain:
>>>
>>
>>
>>> Any pipeline when built, goes generator->transformer...->serializer.
>>> And that is it. Anything else, such as matchers, selectors and
>>> actions, that influence the pipeline, are used when building the
>>> pipeline, not when using it. So imagine a process that goes:
>>> 1) Which generator? Which transformers? Which serialiser
>>> 2) Okay, I've worked out my pipeline, so: generator, go generate
>>>
>>
>>
>>> And the generator then starts up, passing SAX events down the
>>> pipeline until the serialiser has consumed all resulting events and
>>> something has been returned to the user.
>>>
>>
>>
>>> Thus, actions are used when _building_ pipelines, not when
>>> _executing_ them.
>>>
>>
>>
>>> Hope that makes sense.
>>>
>>
>>
>>> Upayavira
>>>
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
--------------------------------------------------------
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !!!!!
--------------------------------------------------------
Re: cocoon and hibernate sessions
Posted by Upayavira <uv...@upaya.co.uk>.
That could work, but it would be working round, rather than working
with, Cocoon. You would also be buffering your output, which is best
avoided.
This is an issue that requires a full solution. I believe the preferred
way is something like:
cocoon.sendPageAndWait("url", bizData, function(){session.close()});
But I think there are some issues with this approach, and I believe it
doesn't work with cocoon.sendPage.
Fancy doing some digging into Cocoon's internals?
Regards, Upayavira
Peter Velychko wrote:
>Hello Upayavira,
>
>May be it is off topic.
>There was discussion on using lazy loading with Hibernate.
>Just a wild idea about it.
>In flowscript we have possibility to get OutputStream or even DOM
>tree to variable. And we can use the resulting DOM tree to generate
>response.
>(I'm not clear in my mind how can I use OutputStream in this way.)
>
>function doSomething() {
> var doc;
>
> if (doc == undefined || doc == null) {
> doc = generateContent();
> }
>
> // responsing
> cocoon.sendPage("response-pipeline", {doc: doc});
>}
>
>function generateContent() {
> // initialization
> var factory = cocoon.getComponent(factoryURI);
> var session = factory.openSession();
> var someThing = doSomeDataWithSession(session);
> var viewData = {someThing: someThing};
>
> // generating content
> var pipelineUtil =
> cocoon.createObject(Packages.org.apache.cocoon.components.flow.util.PipelineUtil);
> var doc =
> pipelineUtil.processToDOM("generate-content-pipeline", viewData);
>
> // releasing resources
> session.close();
> cocoon.releaseComponent(factory);
>
> return doc;
>}
>
>So to realize this approach needs 3 sets of pipelines:
>1. Set for invoking flowscript function
> <map:match pattern="">
> <map:call function="doSomething"/>
> </map:match>
>
>2. Set for generating content (DOM)
> <map:match pattern="generate-content-pipeline">
> <map:generate type="jx" src="screens/generate.jx">
> <map:parameter name="lenient-xpath" value="true"/>
> </map:generate>
> <map:transform type="i18n"/>
> <map:serialize type="xml"/>
> </map:match>
>
>3. Set for response
> <map:match pattern="response-pipeline">
> <map:generate type="jx" src="screens/response.jx"/>
> <map:serialize type="html"/>
> </map:match>
>
>I think it would be more advantageous to operate with OutputStream but
>I don't know how it is possible to respond it from flowscript.
>
>
>
>>Stephan Coboos wrote:
>>
>>
>
>
>
>>>Upayavira wrote:
>>>
>>>
>>>
>>>>><map:match pattern="foo.jxt">
>>>>> <map:generate type="jxt" src="foo.jxt"/>
>>>>> <map:act type="closeHibernateSession"/>
>>>>> <map:serialize type="html"/>
>>>>></map:match>
>>>>>
>>>>>
>>>>>
>>>>This will not work.
>>>>
>>>>Actions are used when building a pipeline, not when processing it. So
>>>>the action will take place before the view is processed, not after.
>>>>
>>>>
>>>
>>>Oh, what a pitty. It's a little bit consfusing me why action is
>>>executed before processing the pipeline, but OK it is so. I think of
>>>process switch within the pipline?
>>>
>>>
>
>
>
>>Actually, when understood, it makes complete sense.
>>
>>
>
>
>
>>So, to explain:
>>
>>
>
>
>
>>Any pipeline when built, goes generator->transformer...->serializer. And
>>that is it. Anything else, such as matchers, selectors and actions, that
>>influence the pipeline, are used when building the pipeline, not when
>>using it. So imagine a process that goes:
>>1) Which generator? Which transformers? Which serialiser
>>2) Okay, I've worked out my pipeline, so: generator, go generate
>>
>>
>
>
>
>>And the generator then starts up, passing SAX events down the pipeline
>>until the serialiser has consumed all resulting events and something has
>>been returned to the user.
>>
>>
>
>
>
>>Thus, actions are used when _building_ pipelines, not when _executing_ them.
>>
>>
>
>
>
>>Hope that makes sense.
>>
>>
>
>
>
>>Upayavira
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: cocoon and hibernate sessions
Posted by Peter Velychko <v_...@ukr.net>.
Hello Upayavira,
May be it is off topic.
There was discussion on using lazy loading with Hibernate.
Just a wild idea about it.
In flowscript we have possibility to get OutputStream or even DOM
tree to variable. And we can use the resulting DOM tree to generate
response.
(I'm not clear in my mind how can I use OutputStream in this way.)
function doSomething() {
var doc;
if (doc == undefined || doc == null) {
doc = generateContent();
}
// responsing
cocoon.sendPage("response-pipeline", {doc: doc});
}
function generateContent() {
// initialization
var factory = cocoon.getComponent(factoryURI);
var session = factory.openSession();
var someThing = doSomeDataWithSession(session);
var viewData = {someThing: someThing};
// generating content
var pipelineUtil =
cocoon.createObject(Packages.org.apache.cocoon.components.flow.util.PipelineUtil);
var doc =
pipelineUtil.processToDOM("generate-content-pipeline", viewData);
// releasing resources
session.close();
cocoon.releaseComponent(factory);
return doc;
}
So to realize this approach needs 3 sets of pipelines:
1. Set for invoking flowscript function
<map:match pattern="">
<map:call function="doSomething"/>
</map:match>
2. Set for generating content (DOM)
<map:match pattern="generate-content-pipeline">
<map:generate type="jx" src="screens/generate.jx">
<map:parameter name="lenient-xpath" value="true"/>
</map:generate>
<map:transform type="i18n"/>
<map:serialize type="xml"/>
</map:match>
3. Set for response
<map:match pattern="response-pipeline">
<map:generate type="jx" src="screens/response.jx"/>
<map:serialize type="html"/>
</map:match>
I think it would be more advantageous to operate with OutputStream but
I don't know how it is possible to respond it from flowscript.
> Stephan Coboos wrote:
>> Upayavira wrote:
>>
>>>>
>>>>
>>>> <map:match pattern="foo.jxt">
>>>> <map:generate type="jxt" src="foo.jxt"/>
>>>> <map:act type="closeHibernateSession"/>
>>>> <map:serialize type="html"/>
>>>> </map:match>
>>>>
>>> This will not work.
>>>
>>> Actions are used when building a pipeline, not when processing it. So
>>> the action will take place before the view is processed, not after.
>>
>>
>>
>> Oh, what a pitty. It's a little bit consfusing me why action is
>> executed before processing the pipeline, but OK it is so. I think of
>> process switch within the pipline?
> Actually, when understood, it makes complete sense.
> So, to explain:
> Any pipeline when built, goes generator->transformer...->serializer. And
> that is it. Anything else, such as matchers, selectors and actions, that
> influence the pipeline, are used when building the pipeline, not when
> using it. So imagine a process that goes:
> 1) Which generator? Which transformers? Which serialiser
> 2) Okay, I've worked out my pipeline, so: generator, go generate
> And the generator then starts up, passing SAX events down the pipeline
> until the serialiser has consumed all resulting events and something has
> been returned to the user.
> Thus, actions are used when _building_ pipelines, not when _executing_ them.
> Hope that makes sense.
> Upayavira
--
Best regards,
Peter Velychko
v_peter@ukr.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: cocoon and hibernate sessions
Posted by Upayavira <uv...@upaya.co.uk>.
Stephan Coboos wrote:
> Upayavira wrote:
>
>>>
>>>
>>> <map:match pattern="foo.jxt">
>>> <map:generate type="jxt" src="foo.jxt"/>
>>> <map:act type="closeHibernateSession"/>
>>> <map:serialize type="html"/>
>>> </map:match>
>>>
>> This will not work.
>>
>> Actions are used when building a pipeline, not when processing it. So
>> the action will take place before the view is processed, not after.
>
>
>
> Oh, what a pitty. It's a little bit consfusing me why action is
> executed before processing the pipeline, but OK it is so. I think of
> process switch within the pipline?
Actually, when understood, it makes complete sense.
So, to explain:
Any pipeline when built, goes generator->transformer...->serializer. And
that is it. Anything else, such as matchers, selectors and actions, that
influence the pipeline, are used when building the pipeline, not when
using it. So imagine a process that goes:
1) Which generator? Which transformers? Which serialiser
2) Okay, I've worked out my pipeline, so: generator, go generate
And the generator then starts up, passing SAX events down the pipeline
until the serialiser has consumed all resulting events and something has
been returned to the user.
Thus, actions are used when _building_ pipelines, not when _executing_ them.
Hope that makes sense.
Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: cocoon and hibernate sessions
Posted by Stephan Coboos <cr...@gmx.net>.
Upayavira wrote:
>>
>>
>> <map:match pattern="foo.jxt">
>> <map:generate type="jxt" src="foo.jxt"/>
>> <map:act type="closeHibernateSession"/>
>> <map:serialize type="html"/>
>> </map:match>
>>
> This will not work.
>
> Actions are used when building a pipeline, not when processing it. So
> the action will take place before the view is processed, not after.
Oh, what a pitty. It's a little bit consfusing me why action is executed
before processing the pipeline, but OK it is so. I think of process
switch within the pipline?
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: cocoon and hibernate sessions
Posted by Upayavira <uv...@upaya.co.uk>.
Stephan Coboos wrote:
> Jakob Schwendner wrote:
>
>> Hi,
>>
>> I am using cocoon 2.1.5 and hibernate. I have got a component
>> wrapping the SessionFactory and as far as I can tell everything seems
>> to work pretty well. The issue is that I am using a
>> session-per-user-session anti-pattern as defined by the hibernate
>> documentation http://www.hibernate.org/168.html. I would like to move
>> to a session-per-request pattern. I figured it would be easy to keep
>> a session per thread using a ThreadLocal. The only problem is that I
>> don't know where I could close the session again. Has anyone done
>> this before? If not, where would be good points to create and close
>> the hibernate session. Maybe in the flow using a threadlocal and
>> close it whenever a page view is called? The problem with that is
>> that the session would need to stay open until after the view call as
>> there might be lazy objects that get displayed. Any help appreciated,
>>
>>
> Hi Jakob,
>
> I think this problem was discussed here before several times. Not
> tested and just an idea: Why not store the Hibernate-Session-Object
> into the Request-Scope and writting an action which extracts the
> Hibernate-Session and closes them after generating the view. A
> pipeline fragment could be looked like the following:
>
> <map:match pattern="foo.jxt">
> <map:generate type="jxt" src="foo.jxt"/>
> <map:act type="closeHibernateSession"/>
> <map:serialize type="html"/>
> </map:match>
>
This will not work.
Actions are used when building a pipeline, not when processing it. So
the action will take place before the view is processed, not after.
Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: cocoon and hibernate sessions
Posted by Stephan Coboos <cr...@gmx.net>.
Jakob Schwendner wrote:
>Hi,
>
>I am using cocoon 2.1.5 and hibernate. I have got a component wrapping the SessionFactory and as far as I can tell everything seems to work pretty well. The issue is that I am using a session-per-user-session anti-pattern as defined by the hibernate documentation http://www.hibernate.org/168.html. I would like to move to a session-per-request pattern. I figured it would be easy to keep a session per thread using a ThreadLocal. The only problem is that I don't know where I could close the session again.
>Has anyone done this before? If not, where would be good points to create and close the hibernate session. Maybe in the flow using a threadlocal and close it whenever a page view is called? The problem with that is that the session would need to stay open until after the view call as there might be lazy objects that get displayed.
>Any help appreciated,
>
>
Hi Jakob,
I think this problem was discussed here before several times. Not tested
and just an idea: Why not store the Hibernate-Session-Object into the
Request-Scope and writting an action which extracts the
Hibernate-Session and closes them after generating the view. A pipeline
fragment could be looked like the following:
<map:match pattern="foo.jxt">
<map:generate type="jxt" src="foo.jxt"/>
<map:act type="closeHibernateSession"/>
<map:serialize type="html"/>
</map:match>
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org