RE: accessing the pipeline structure

[Conal Tuohy]

Jorg Heymans wrote:

> Recently there were 2 requests on the users list about accessing the 
> current pipeline structure.



> Having this extra metadata would allow for components that 
> can produce 
> different output depending on how they are used in a pipeline 
> (but this 
> probably breaks a few cocoon design rules right?). 

It certainly creates the _potential_ for components to be horribly tangled up with the 
pipelines that contain them. 



> Thoughts? Is this difficult to implement? A 2.2 feature perhaps?

I don't know about the use cases presented on the user list, but I know another use 
case is for debugging and maintenance people to have direct access _from a 
Cocoon-produced resource_ to the pieces of the pipeline that produced it. In this 
scenario the final output contains a bunch of hyperlinks to the resources (content, 
transforms, stylesheets, etc) which can be used to get quick access to edit one of 
these sources.

As an experiment I implemented this for some pipelines using XML processing 
instructions. Each pipeline component adds a PI to the SAX stream to identify itself 
(a signature), and at the end a transformer can convert them into HTML  elements 
or similar. NB this is totally different to (the inverse of) the use of PIs embedded 
into a source XML file to specify an XSL transformation. It wasn't very convenient to 
add each PI at each stage, but it seemed to me that the pipeline processor could 
certainly maintain this metadata more easily, and make it available to components when 
needed. Perhaps a special pipeline processor could keep track of the pipeline, and use 
a special transformer which is "pipeline aware" ("InsertPipelineMetadataTransformer") 
to insert this metadata into the pipeline only when needed.

Cheers

Con

DO NOT REPLY [Bug 31134] - [PATCH] JXPathMetaModule incorrectly checks for null parameter (can't happen) instead of empty string.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31134

[PATCH] JXPathMetaModule incorrectly checks for null parameter (can't happen) instead 
of empty string.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-09-09 22:09 ---
Patch applied in 2.1 and 2.2, please cross check and close the bug

Re: Cocoon usage in Medical Informatics

[gweinger]

> Guys (and gals),
>
> just to let you know:
>
> I'm currently in San Francisco for a conference on Medical Informatics and
> I
> noticed at least two other projects (excluding mine) where Cocoon was used
> either as a presentation layer or as an intermediate layer between
> distributed data sources.
>
> Bye, Helma
>
Helma,

I'm here as well, and I also use Cocoon in Medical Informatics.  Let me
know if you'd like to meet briefly to compare notes tomorrow at the
conference.  This is my project http://mii.ucla.edu/dataserver/

--Gregory Weinger
UCLA Medical Imaging Informatics

DO NOT REPLY [Bug 31134] - [PATCH] JXPathMetaModule incorrectly checks for null parameter (can't happen) instead of empty string.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31134

[PATCH] JXPathMetaModule incorrectly checks for null parameter (can't happen) instead 
of empty string.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

Re: CForms' shortcomings

[Ugo Cei]

Il giorno 09/set/04, alle 18:51, Sylvain Wallez ha scritto:
About vertical position, I've been thinking about sending it in a 
hidden field along with other form values, so that it can be sent back 
in order to set it whenever the form is redisplayed. Just a workaround 
the problems you mention below though.
I wasn't even aware that you could determine the scrollbar's position, 
not to mention setting it.

If you click the reload button, the browser asks you if you want to 
resend your POST request (try to explain this to your customer).

Well, your customer must be very new to web browsers if he never saw 
this message before...
Yes, some of them are not familiar with using the Internet at all, 
besides causal surfing.

Ugo
--
Ugo Cei - http://beblogging.com/


smime.p7s
Description: S/MIME cryptographic signature

Cocoon usage in Medical Informatics

[H . vanderLinden]

Guys (and gals),

just to let you know:

I'm currently in San Francisco for a conference on Medical Informatics and I
noticed at least two other projects (excluding mine) where Cocoon was used
either as a presentation layer or as an intermediate layer between
distributed data sources.

Bye, Helma

Re: CForms' shortcomings

[Sylvain Wallez]

Ugo Cei wrote:
Don't get me wrong, I love CForms, but there are some problems WRT 
usability of the generated HTML pages.

CForms gives you some very nice features, like repeaters and attaching 
scripts to widgets to be executed on the server when some event 
happens (see the Carselector sample).

But when you start using those features, you run into usability 
problems due to the fact that those events are handled on the server 
and so require a client-server roundtrip and, what is most painful, a 
full redraw of the GUI.

Whenever you form is so large as to require vertical scrolling, every 
time the GUI is redrawn, you lose focus and lose the vertical scroll 
position.

About vertical position, I've been thinking about sending it in a hidden 
field along with other form values, so that it can be sent back in order 
to set it whenever the form is redisplayed. Just a workaround the 
problems you mention below though.

If you click the back button, you aren't sent to the page before the 
form, but to the version of the form before the handling of the event.

I've seen webapps where hitting back reloads the previous page, probably 
because of some clever expiration headers. If we modify form.showForm() 
so that the same continuation is always used (using what's in 
v2/form.js), that could be a way to reload the form in its current state 
whenever the user hits the back button.

If you click the reload button, the browser asks you if you want to 
resend your POST request (try to explain this to your customer).

Well, your customer must be very new to web browsers if he never saw 
this message before...

This really sucks!

Sure :-)
Actually the problems are not CForms' fault, but HTTP's, as we all 
know. HTTP just wasn't designed to handle these kinds of use-cases.

We could turn to some proprietary technologies for a solution (XAML, 
XUL, Flash, ...), wait for a usable XForms implementation or use Java 
applets (b). Or we could use something that is cool, available now 
and a de-facto standard. I mean, something like XMLHTTPRequest [1].

In order to show what I mean, I decided to create a small sample, so I 
just committed a modified carselector sample in the trunk. It's not 
linked from the samples page, but you can find it at 
. I hope 
you agree with me that it's much better, usability-wise, than the 
original carselector.

I think CForms should include some kind of support for this, in order 
to make is as easy as the current methods are, and if you agree with 
me, you are welcome to try and make this happen.

+1000.
There are some limitations to this though, as it mostly applies to 
roundtrips that do not modify the form's structure. In other cases, such 
as adding a repeater row, we could end up with reinventing XUL to make 
it happen using xmlhttprequest.

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

CForms' shortcomings

[Ugo Cei]

Don't get me wrong, I love CForms, but there are some problems WRT 
usability of the generated HTML pages.

CForms gives you some very nice features, like repeaters and attaching 
scripts to widgets to be executed on the server when some event happens 
(see the Carselector sample).

But when you start using those features, you run into usability 
problems due to the fact that those events are handled on the server 
and so require a client-server roundtrip and, what is most painful, a 
full redraw of the GUI.

Whenever you form is so large as to require vertical scrolling, every 
time the GUI is redrawn, you lose focus and lose the vertical scroll 
position.

If you click the back button, you aren't sent to the page before the 
form, but to the version of the form before the handling of the event.

If you click the reload button, the browser asks you if you want to 
resend your POST request (try to explain this to your customer).

This really sucks!
Actually the problems are not CForms' fault, but HTTP's, as we all 
know. HTTP just wasn't designed to handle these kinds of use-cases.

We could turn to some proprietary technologies for a solution (XAML, 
XUL, Flash, ...), wait for a usable XForms implementation or use Java 
applets (b). Or we could use something that is cool, available now 
and a de-facto standard. I mean, something like XMLHTTPRequest [1].

In order to show what I mean, I decided to create a small sample, so I 
just committed a modified carselector sample in the trunk. It's not 
linked from the samples page, but you can find it at 
. I hope 
you agree with me that it's much better, usability-wise, than the 
original carselector.

I think CForms should include some kind of support for this, in order 
to make is as easy as the current methods are, and if you agree with 
me, you are welcome to try and make this happen.

Caveat: the sample works with Mozilla (1.6) and Safari (1.2) but not 
with IE. I haven't got a Windows machine and even if I had one, I 
wouldn't know where to start debugging javascript code, so I hope some 
Windows user will kindly provide a fix. Shouldn't be hard.

Ugo
[1] http://developer.apple.com/internet/webcontent/xmlhttpreq.html
--
Ugo Cei - http://beblogging.com/

smime.p7s
Description: S/MIME cryptographic signature

Re: cforms: add initialize widgets stage?

[Sylvain Wallez]

Tim Larson wrote:
On Thu, Sep 09, 2004 at 03:46:52PM +0200, Sylvain Wallez wrote:

 

I started implementing an "on-create" event listener, but failed on that 
same problem, as the whole form must be in a consistent state before 
that event can be fired, because the event listener can potentially 
reference any other widget.
   

What were you going to use "on-create" events for?  I am guessing mainly
for new repeater rows and newly referenced union cases?
 

Exactly. In flat forms, custom initializations can be done in the 
flowscript between "new Form()" and "form.showForm()", but I the case of 
dynamically created widgets, this cannot be done that way.

I have some complex use cases where the case field of an union, itself 
in a class, has a selection-list that is defined by analyzing the values 
defined somewhere else in the form.

Still following me? If not, you need to attend my presentation at the GT ;-)
So the idea is that in "on-create", the widget gathers in the form the 
necessary data to build and set its own selection list.

Even for flat forms, this create-event can allow custom initialization 
code that currently is written in the flowscript back in the definition, 
thus making the form definition self-contained in a single file.

So your initialize() stuff could be a solution to finish the 
implementation of create-event. However, that event must also be fired 
when a widget is creater later during the life for the form, e.g. when a 
new repeater row is created. So initialize() must also be called in that 
case.
   

I already handle that case, and also calling initialize() for the
created-on-demand child widgets of union widgets.  Should I commit?
 

+1. I'll add the "on-create" stuff on top of this.
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: Custom extensions - to be made available if possible

[Stefano Mazzocchi]

Conal Tuohy wrote:
Antonio Fiol Bonnín wrote:

a) Refactoring SimpleLuceneXMLIndexerImpl so that its private method
indexDocument is not private, and taking it to an external component.
b) Creating a PDFGenerator (in the cocoon sense of generator, 
of course).

Option (a) seems to be giving us more headaches than pleasure, and
option (b) seems cleaner to a certain point. Option (b) would allow to
follow links in the PDF file, if developed to that point.

I like option (b) too. You could start with plain text, but it could later be 
developed to extract basic formatting, hyperlinks, bookmarks (the table of contents), 
images, etc.

However, option (b) implies choosing a format for its output (which?),

An interesting question. Perhaps html, and begin with an implementation which produces:

   
   
  blah blah blah
  blah blah
  
  ... 
   


Later you (or someone else) could add extra things as they need them. 

Alternatively, you could use a more PDF-oriented DTD.
What about using XSL:FO? Would be pretty cool to have the ability to 
transform PDF into FO, basically reversing what FOP does. I know it 
would be pretty painful to make it work with all kinds of PDF, but for 
reasonable ones it shouldn't be that hard (PDF is sort of a markup 
language already).

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

accessing the pipeline structure

[Jorg Heymans]

Hi,
Recently there were 2 requests on the users list about accessing the 
current pipeline structure.

http://marc.theaimsgroup.com/?t=10944833712&r=1&w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=109473546831881&w=2
What does the devlist think about this? Certainly cocoon is being 
stretched in all areas possible, having the need for metadata about the 
executing pipeline structure is just one example of this.

Having this extra metadata would allow for components that can produce 
different output depending on how they are used in a pipeline (but this 
probably breaks a few cocoon design rules right?). In my cocoon video 
rendering application i got around this by creating an xml control 
structure that was used by all components, so a component could find out 
what all previous components did and what the results were.

Thoughts? Is this difficult to implement? A 2.2 feature perhaps?
Jorg

Re: cforms: add initialize widgets stage?

[Tim Larson]

On Thu, Sep 09, 2004 at 03:46:52PM +0200, Sylvain Wallez wrote:

> I started implementing an "on-create" event listener, but failed on that 
> same problem, as the whole form must be in a consistent state before 
> that event can be fired, because the event listener can potentially 
> reference any other widget.

What were you going to use "on-create" events for?  I am guessing mainly
for new repeater rows and newly referenced union cases?

> So your initialize() stuff could be a solution to finish the 
> implementation of create-event. However, that event must also be fired 
> when a widget is creater later during the life for the form, e.g. when a 
> new repeater row is created. So initialize() must also be called in that 
> case.

I already handle that case, and also calling initialize() for the
created-on-demand child widgets of union widgets.  Should I commit?

--Tim Larson

RE: Getting a cocoon:// source from a cron job

[Bart Molenkamp]

If I use another pipeline, which does a , then it works. Why doesn't it work when I
directly call my mail.do pipeline?

> -Original Message-
> From: Bart Molenkamp
> Sent: Thursday, September 09, 2004 1:59 PM
> To: [EMAIL PROTECTED]
> Subject: Getting a cocoon:// source from a cron job
> 
> Hi,
> 
> I've written a cron job that sends email on specific periods. I want
to
> get the content of the message from a pipeline. I try to resolve it
with
> the source resolver, but that fails.
> 
> I have a flowscript, which collects data for the mail. When I try to
> resolve the URI, the flowscript is executed, but it fails on the
> cocoon.sendPage() call. I get an exception:
> org.apache.cocoon.ResourceNotFoundException: No pipeline matched
> request: risks/mail/mail.xml
> 
> My first thought was that it didn't work because the cron job is not
> part of a request/response cycle, but I don't think that it explains
the
> exception... Can someone confirm that this is the problem? (When I
call
> the same resource from a browser, it works fine).
> 
> Bart.

Re: cforms: add initialize widgets stage?

[Sylvain Wallez]

Tim Larson wrote:
A little context first:
I was working with the union widget and decided to change the
case id lookup to use lookupWidget(path) so it could reference
widgets at other levels in the widget tree ("../../somewidget".)
While implementing this I found that this lookup needs to happen
after all the setParent(widget) calls have happened (after the
widget tree has been fully built) or the lookup can fail.
Because widgets are not currently notified when tree building is
finished, there was no place to plug in this lookupWidget() call,
so I added initialize() to the Widget interface and added code to
the form manager, AbstractContainerWidget, etc. to propagate a
notification so I would have a place to initialize union widgets.
Now I realize I could have instead used a lazy lookup when the
case widget is first referenced, and I wonder if I should strip
out the initialize() code or if it would help a use case anyone
else has. WDYT?
 

I started implementing an "on-create" event listener, but failed on that 
same problem, as the whole form must be in a consistent state before 
that event can be fired, because the event listener can potentially 
reference any other widget.

So your initialize() stuff could be a solution to finish the 
implementation of create-event. However, that event must also be fired 
when a widget is creater later during the life for the form, e.g. when a 
new repeater row is created. So initialize() must also be called in that 
case.

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

An OutputModule for session-fw

[lpb+cocoon]

Does anyone know of an OutputModule for session contexts? It doesn't look 
that hard to write, and in a perfect world would use jxpath, but it's on 
my list of "nice to do, after my deadline". I can get by without it for 
now, but if anyone's already made one (say, for 2.1.6 or 2.2), it'd make 
my life a lot easier and would be greatly appreciated. :-)

Thanks!

cforms: add initialize widgets stage?

[Tim Larson]

A little context first:
I was working with the union widget and decided to change the
case id lookup to use lookupWidget(path) so it could reference
widgets at other levels in the widget tree ("../../somewidget".)
While implementing this I found that this lookup needs to happen
after all the setParent(widget) calls have happened (after the
widget tree has been fully built) or the lookup can fail.

Because widgets are not currently notified when tree building is
finished, there was no place to plug in this lookupWidget() call,
so I added initialize() to the Widget interface and added code to
the form manager, AbstractContainerWidget, etc. to propagate a
notification so I would have a place to initialize union widgets.

Now I realize I could have instead used a lazy lookup when the
case widget is first referenced, and I wonder if I should strip
out the initialize() code or if it would help a use case anyone
else has. WDYT?

--Tim Larson

RE: Sharing cocoon.jar between multiple web aplications

[ĎURDINA Michal]

I am using cocoon-2.1.5 release.

I will try to replece Cocoon.java from CVS HEAD. Thanks for pointing me there.

Michal


> -Original Message-
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 09, 2004 12:21 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Sharing cocoon.jar between multiple web aplications
> 
> 
> ÄURDINA Michal wrote:
> 
> > The problem arise only when one web application calls other 
> web application to generate its output (via 
> getRequestDispatcher.include() - crosscontext must be 
> enabled). Then both webapps use the same static field 
> instance in the same thread. And if both are calling method 
> on the same class i.e. Cocoon.process(), then called web 
> application can rewrite the value saved by calling web application.
> 
> IIRC, this particular problem you are describing are resolved in CVS. 
> When last time you had updated your snapshot?
> 
> Vadim
> 
> 

RE: Sharing cocoon.jar between multiple web aplications

[ĎURDINA Michal]

> -Original Message-
> From: peter royal [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 08, 2004 8:32 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Sharing cocoon.jar between multiple web aplications
> 
> 
> On Sep 8, 2004, at 11:17 AM, ÄURDINA Michal wrote:
> > The problem arise only when one web application calls other web 
> > application to generate its output (via 
> getRequestDispatcher.include() 
> > - crosscontext must be enabled). Then both webapps use the 
> same static 
> > field instance in the same thread. And if both are calling 
> method on 
> > the same class i.e. Cocoon.process(), then called web 
> application can 
> > rewrite the value saved by calling web application.
> 
> ah, gotcha.
> 
> why not just put cocoon.jar per-webapp then, and put the rest of the 
> deps at the ear level? :)
> -pete
> 

Yes, thats solves the problem partially.

Instead of duplicating 15MB of libraries, I will be duplicating only about 2,5MB of 
cocoon libraries and libraries that are dependent on cocoon libraries. I.e. castor.jar 
must be moved back from ear to WEB-INF/lib to see cocoon classes needed for xml 
unmarhsalling.

I tried to fix the static ThreadLocal fields on my own and it resulted to change only 
in Cocoon.java to remove checkEnvironment() method. Static field in other classes did 
not affect me either because they are in blocks that we do not use or I am sure that 
they won't be multicalled in one request (i.e. portal-block classes).

Here is the list of them anyway (cocoon-2.1.5 release):
grep -d -l "ThreadLocal" *.java 

File blocks\batik\java\org\apache\cocoon\components\url\SourceProtocolHandler.java:
File blocks\portal\java\org\apache\cocoon\portal\impl\PortletPortalManager.java:
File 
blocks\portal\java\org\apache\cocoon\portal\serialization\IncludingHTMLSerializer.java:
File blocks\portal\java\org\apache\cocoon\portal\util\ReferenceFieldHandler.java:
File 
blocks\portal-fw\java\org\apache\cocoon\webapps\portal\context\SessionContextImpl.java:
File blocks\scratchpad\java\org\apache\cocoon\ant\AntBuildGenerator.java:
File java\org\apache\cocoon\components\CocoonComponentManager.java:
File 
java\org\apache\cocoon\components\treeprocessor\variables\VariableResolverFactory.java:

From those all these are not affected by multicall problem because:
PortletPortalManger - there is not read of the static ThreadLocal copletInstanceData;
VariableResolverFactory - detto - no read of static ThreadLocal disposableCollector;
CocoonComponentManager - immune because of the use of threadlocal stack of variables 
instead of threadlocal variable
IncludingHTMLSerializer - no conflict because this class is called by only on webapp 
(or at least it is very unlikely to be called more than one in one request)
ReferenceFieldHandler - detto - no conflict

So all I needed to change was Cocoon.java. I have not tested this thorougly so I 
cannot say if it really works correctly yet.
But I still would be for using static fields only with special care and with handling 
against webapp multicall (on webapp includes other) problem i.e. as 
CocoonComponentManager does with threadlocal stack and proper cleaning before return.

Michal

Getting a cocoon:// source from a cron job

[Bart Molenkamp]

Hi,

I've written a cron job that sends email on specific periods. I want to
get the content of the message from a pipeline. I try to resolve it with
the source resolver, but that fails.

I have a flowscript, which collects data for the mail. When I try to
resolve the URI, the flowscript is executed, but it fails on the
cocoon.sendPage() call. I get an exception:
org.apache.cocoon.ResourceNotFoundException: No pipeline matched
request: risks/mail/mail.xml

My first thought was that it didn't work because the cron job is not
part of a request/response cycle, but I don't think that it explains the
exception... Can someone confirm that this is the problem? (When I call
the same resource from a browser, it works fine).

Bart.

Re: Custom extensions - to be made available if possible

[Daniel Fagerstrom]

Antonio Fiol Bonnín wrote:
I have implemented something like that, see:
http://issues.apache.org/bugzilla/show_bug.cgi?id=24402. It is not yet
part of Cocoon as we have differing opinions about the design as you can
see in the Bugzilla entry and also in the thread:
http://marc.theaimsgroup.com/?t=10908512634&r=1&w=2.
   

Thank you Daniel.
My approach was, in fact, much simpler.
It is a very simple transformer.
You can configure (in the sitemap, src attribute for the transform
element) the URL to post to.
Everything in the input is posted.
The response is piped back "alone", without anything around.
Of course, your approach is probably much better.
I'm not so certain that my approach is better. When I designed the 
stuff, my first idea was to write something like what you describe. The 
advantage with my approach is that you can embed the web service call in 
an XML document that contains other stuff and that you can make several 
web service calls at once. The disadvantage is that if you have to embed 
your message to the web service in XML tags and strip of XML tags from 
the output. For many use cases you don't need the flexibility you get 
from my approach, it just complicates thing. If your input and/or output 
documents from the web service are large it can also be quite costly to 
add and strip away tags.

So as a conclusion I think that your approach would make a usefull 
adition to Cocoon. If you use the "postable" http source that I 
submitted in the Bugzilla entry, It would be quite easy to write, (read 
the thread cited above first for other opinions, however).

Another thing tha might be worth mentioning is that if you need more 
detailed error control or need to do some decisions based on the output, 
it is often better to call the web service from a flowscript, (you can 
find some example code in the bugzilla entry).

/Daniel

DO NOT REPLY [Bug 31116] - Too Many File handles open

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31116

Too Many File handles open

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-09-09 11:19 ---
I think this is not a bug,
We can control the filehandles with the pools, and the GC suggestion makes the
tomcat GC operation much faster. I will tell the ops guys to work out what the
pools should be.

Thank you everyone for you suggestions and help

Ian

Re: Orbeon Presentation Server - OXF Rebuttal needed again?

[Damon Rand]

Why the bitterness? Competition is a good thing. Personally I am happy
that OXF has been opensourced. It is a good solid product and its main
weakness was not being opensource.

Having used both OXF and Cocoon on several projects they are both good
and both different. I believe OXF started out from Norman Walsh's
pipeline definition.
http://www.w3.org/TR/2002/NOTE-xml-pipeline-20020228/

The result is the almost complete eradication of java in the
presentation tier which is either a good or a bad thing depending on
your perspective. But the way I see it, it just means more choice for
web developers.

In some ways I find OXF is more like Struts than Cocoon -- I see it as
a way to bring my Struts colleagues across to XSLT pipelining rather
than as a replacement for Cocoon.

Looking through the comparison I cant find anything that is actually
untrue? I'm sure if there is anything specific then the Orbeon guys
will change it.

Damon.

> > but I was just wondering if any of the Cocoon developers are interested
> > in taking a look at the current state of the comparison between their
> > Presentation Server and Cocoon and maybe come up with more accurate
> > descriptions of cocoons capabilities?
> 
> Bah. I've seen that they changed it again: whenever they had to
> recognize that Cocoon had the very same (if not better) capabilities,
> they used the "limited" keyword. I see no way and no reason for them
> to come out with an accurate comparison, and their open sourcing seems
> to me the typical last resort they could think of. I would rather let
> them die the painful death they deserve.
>

DO NOT REPLY [Bug 31116] - Too Many File handles open

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31116

Too Many File handles open

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Critical|Normal



--- Additional Comments From [EMAIL PROTECTED]  2004-09-09 10:59 ---
I've done some more tests,

A question, What is the relationshup between Tomcat Threads and the pools.
Is the pool shared between threads, or is it dedicated to each thread. eg

If we have a pool of generators that could contain 32 generators of a particular
type, and 100 threads, it the theoretical numbe of open file handles 3200 or 32 ?

If it is 3200 it makes sense that this is where our problem is and the ops guys
have got too many components in the pool and/or too many threads.

Re: Custom extensions - to be made available if possible

[Antonio Fiol Bonnín]

> I have implemented something like that, see:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=24402. It is not yet
> part of Cocoon as we have differing opinions about the design as you can
> see in the Bugzilla entry and also in the thread:
> http://marc.theaimsgroup.com/?t=10908512634&r=1&w=2.

Thank you Daniel.

My approach was, in fact, much simpler.

It is a very simple transformer.
You can configure (in the sitemap, src attribute for the transform
element) the URL to post to.
Everything in the input is posted.
The response is piped back "alone", without anything around.

Of course, your approach is probably much better.

Yours,


Antonio Fiol

DO NOT REPLY [Bug 31116] - Too Many File handles open

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31116

Too Many File handles open





--- Additional Comments From [EMAIL PROTECTED]  2004-09-09 10:15 ---
cat /proc/sys/fs/file-max 
209715 
 
This is the linux 2.6 default value for 2G RAM 
and is around 10% of RAM in kbytes. 
The more you increase that value the more RAM will be 
available for filehandles and can be pushed to rather high 
values. 
For garbage collection you should read: 
http://java.sun.com/docs/hotspot/gc1.4.2/ 
 
You can try the following to tune the garbage collector: 
 
Multiprocessor machine: 
=== 
1) "-server -XX:+UseConcMarkSweepGC -XX:+UseParNewGC" 
or 
2) "-server -XX:+UseParallelGC" 
 
Uniprocessor machine: 
= 
1) "-server -XX:+UseConcMarkSweepGC" 
or 
2) "-server -Xincgc"

Re: Custom extensions - to be made available if possible

[Daniel Fagerstrom]

Antonio Fiol Bonnín wrote:
Hello,
We have started developing two extensions for cocoon, and we would
like to know if the core team would be interested in getting them into
the trunk, and optionally in maintaining them in the future.
The extensions are:
- A transformer that connects via HTTP POST and sends its XML input to
the server, and returns the XML returned from the server to the
pipeline.
This is similar to the SOAP thing, but without the envelope, and with
a predefined (configured in the sitemap) URL.

I have implemented something like that, see: 
http://issues.apache.org/bugzilla/show_bug.cgi?id=24402. It is not yet 
part of Cocoon as we have differing opinions about the design as you can 
see in the Bugzilla entry and also in the thread: 
http://marc.theaimsgroup.com/?t=10908512634&r=1&w=2.

/Daniel

Re: Custom extensions - to be made available if possible

[Antonio Fiol Bonnín]

> > b) Creating a PDFGenerator (in the cocoon sense of generator,
> > of course).

> > ... and also poses some problems wrt. the sitemap. Until now, we have a
> > pipeline using a reader to read pdf files (static, from disk). And we
> > would need a generator to be invoked instead for the content and links
> > views. How can we do that? Maybe with a selector? But that does not
> > seem very clean. Any hints there?
> 
> I'm not sure. It might work. I hope someone else can help you with that. [...]

Thank you, Con, for your very interesting point of view. We were
working on (a) but I have told my team that we will be changing
approach in one hour if they do not see a clear end.

Other than that, I will look into pdftohtml (is it really html?).

Can anyone please shed some light into the sitemap issue?

The issue, in a few words is:

How can I turn a pipeline which serves static PDFs into one that
serves static PDFs unless cocoon-view=content or cocoon-view=links.

Yours sincerely,


Antonio Fiol

Re: Custom extensions - to be made available if possible

[Antonio Fiol Bonnín]

> How are your PDFs generated? Are they generated by Cocoon? If so, you
> should index the raw data, before you serialize to PDF.
> 
> Just a thought.

Thanks, but PDFs already exist (and their origin is varying). Most of
them are generated from Word documents. But the only thing I have is
the PDF file.

Re: Custom extensions - to be made available if possible

[Upayavira]

Antonio Fiol Bonnín wrote:
Hello,
We have started developing two extensions for cocoon, and we would
like to know if the core team would be interested in getting them into
the trunk, and optionally in maintaining them in the future.
The extensions are:
- A transformer that connects via HTTP POST and sends its XML input to
the server, and returns the XML returned from the server to the
pipeline.
This is similar to the SOAP thing, but without the envelope, and with
a predefined (configured in the sitemap) URL.
- An extension to the Cocoon Lucene searching system (or something
different, yet pending design), so that non-XML content can also be
indexed. In particular, we are interested on PDF, but we are designing
it as generic as possible.
BTW, your opinion may be very valueble for the design. Let me explain
the two approaches we have thought of:
a) Refactoring SimpleLuceneXMLIndexerImpl so that its private method
indexDocument is not private, and taking it to an external component.
b) Creating a PDFGenerator (in the cocoon sense of generator, of course).
Option (a) seems to be giving us more headaches than pleasure, and
option (b) seems cleaner to a certain point. Option (b) would allow to
follow links in the PDF file, if developed to that point.
However, option (b) implies choosing a format for its output (which?),
and also poses some problems wrt. the sitemap. Until now, we have a
pipeline using a reader to read pdf files (static, from disk). And we
would need a generator to be invoked instead for the content and links
views. How can we do that? Maybe with a selector? But that does not
seem very clean. Any hints there?
Any other options?
Any general comments?
 

How are your PDFs generated? Are they generated by Cocoon? If so, you 
should index the raw data, before you serialize to PDF.

Just a thought.
Upayavira

RE: Cocoon Portal Engine Tools

[Matthew Langham]

> So how do we get ahold of this to look at it?
> 

At the moment we hope to have everything ready at the beginning of next
week.

Matthew


> -Original Message-
> From: Ralph Goers [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, September 09, 2004 8:47 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Cocoon Portal Engine Tools
> 
> So how do we get ahold of this to look at it?
> 
> Ralph
> 
> At 9/8/2004  11:40 PM, you wrote:
> 
> >
> >We have some documentation for the framework and the 
> examples, too. Yes 
> >really :-)
> >
> >We would like donate the tool-framework to the cocoon project and we 
> >would be interested in comments as to whether anyone "out 
> there" would 
> >be interested in this and if you think you would want to jump in and 
> >extend the given - basic - toolset.
> >
> >Kind regards
> >Daniel Dost & Jens Maukisch
> >Competence Center Open Source
> >-
> >  S&N AG  Tel.: 05251/1581-0
> >  netBank solutions   Fax : 05251/1581-71
> >  Klingenderstr. 5
> >  D-33100 Paderborn   http://www.s-und-n.de
> >  -
> 

RE: Custom extensions - to be made available if possible

[Conal Tuohy]

Antonio Fiol Bonnín wrote:

> a) Refactoring SimpleLuceneXMLIndexerImpl so that its private method
> indexDocument is not private, and taking it to an external component.
> 
> b) Creating a PDFGenerator (in the cocoon sense of generator, 
> of course).
> 
> Option (a) seems to be giving us more headaches than pleasure, and
> option (b) seems cleaner to a certain point. Option (b) would allow to
> follow links in the PDF file, if developed to that point.

I like option (b) too. You could start with plain text, but it could later be 
developed to extract basic formatting, hyperlinks, bookmarks (the table of contents), 
images, etc.

> However, option (b) implies choosing a format for its output (which?),

An interesting question. Perhaps html, and begin with an implementation which produces:


   
   
  blah blah blah
  blah blah
  
  ... 
   


Later you (or someone else) could add extra things as they need them. 

Alternatively, you could use a more PDF-oriented DTD.

I have used a simple freeware tool called pdftohtml which produces XML according to 
the following DTD:











> and also poses some problems wrt. the sitemap. Until now, we have a
> pipeline using a reader to read pdf files (static, from disk). And we
> would need a generator to be invoked instead for the content and links
> views. How can we do that? Maybe with a selector? But that does not
> seem very clean. Any hints there?

I'm not sure. It might work. I hope someone else can help you with that. But NB 
there's also another way to build a Lucene index - using the LuceneIndexTransformer 
rather than by crawling the site and using views. This technique would certainly work 
with option (b) - a PDFGenerator - but I'm not sure that it would integrate nicely 
with option (a) since it's a transformer and therefore requires XML. So if you could 
resolve the sitemap issue with option (b) then it would work with both indexing 
techniques, whereas option (a) could only ever work with the crawler, I think.

Cheers

Con

Re: [CForms] Change proposal in Custom bindings

[Leszek Gawron]

Marc Portier wrote:

Leszek Gawron wrote:
BTW the patch I submitted already passes the service manager to custom
bindings that implement Serviceable. It doesn't change anything for
existing custom bindings. Maybe useful for custom bindings in general?

I have no vote here but it would be very usable for me and everyone
that binds forms to O/R managed entities.
this just makes sense, and doesn't break backwards compat
mind though that cforms is still marked unstable so we're not there to 
guarantee any compatibility yet (we'll try no to break things of course)

any case: done.
huge thanks!
--
Leszek Gawron  [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65