Re: cvs commit: cocoon-2.1/legal util.concurrent-1.3.3.jar.license.txt

[Antonio Gallardo]

[EMAIL PROTECTED] dijo:
> crossley2004/06/03 23:38:52
>
>   Modified:legalutil.concurrent-1.3.3.jar.license.txt
>   Log:
>   Point to Doug Lea website and let him explain the issues.

Hmm. This is pointing the the current version. In this case to 1.3.4. We
use 1.3.3

The point is: The file is not mantained by us and without notice it can be
changed and broke our license.

(I will update the library to 1.3.4).

Best Regards,

Antonio Gallardo

RE: error handling

[Carsten Ziegeler]

Vadim Gritsenko wrote:

> 
> IIRC, last first friday we had a chat with Carsten about 
> adding an attribute to the  or to the 
>  which will indicate what behavior is needed in 
> case of internal request: throw exception or process 
> . Carsten?
> 
Yes, nothing of that is implemented yet. The discussion started
because of internal redirects.
Now, in general the error handlers are never called for internal
requests - that was a design decision. Starting with 2.1.5 we
have one exception, internal redirects, so if you do a 
 then - and only then -
the error handler of the internal pipeline is called.

HTH?
Carsten

Re: cvs commit: cocoon-2.1/src/webapp/samples/hello-world/style/xsl page2swf.xsl

[Joerg Heinicke]

On 04.06.2004 02:12, [EMAIL PROTECTED] wrote:
  Log:
  removed the deprecated swf block and added a simple flash example in the hello world 
section
Just want to point on some errors:
  Index: blocks.properties

   #-[dependency]: "apples" depends on "forms" (for samples).
  -#include.block.apples=false
  +include.block.apples=false
   #-[dependency]: "asciiart" is needed by "mail".
Apples should not be excluded by default.
  Index: status.xml

  
  - Serializers: Fixed the namespace handling.
  + Fixed the namespace handling of the new XMLSerializer.
  
  
  - Serializers: Added support for indentation to the new XML Serializer.
  + Added support for indentation to the new XMLSerializer.
  
You overwrote Vadim's changes.
  1.1  cocoon-2.1/src/webapp/samples/hello-world/style/swf/hello.fla
  
  	<>
  
  
  1.1  cocoon-2.1/src/webapp/samples/hello-world/style/swf/hello.swf
  
  	<>
Are they really binary?
Joerg

[portal] Form-Coplet communication

[Alex Romayev]

Another form coplet -- another problem ;-)

Problem
---

Here is what I'm trying to do.  I have a "Search"
coplet, which is a form with lots of search criteria
(about 15 fields).  It has 2 buttons: "Search" and
"Save Search".  

If "Search" button is pressed, 2 things need to
happen:
- "Search Results" coplet (on the same page) needs to
use the criteria to run a query and display the
results.
- "Search" coplet needs to pre-populate itself with
the entered criteria.

If "Save Search" button is pressed, another portal
page ("Save Search") needs to be presented, the name
of the search needs to be entered, the search saved
and the "Search" page displayed with appropriate
results and pre-populated "Search" coplet.

Questions
-

1. "Using Forms" doc
(http://cocoon.apache.org/2.1/developing/portal/forms.html)
shows how to implement a form using CachingURICoplet. 
This would allow me to use form binding to bind form
to/from SearchCriteria object, which then can be used
to run search or be saved to the database.  However, I
think CachingURICoplet only works when the coplet does
*not* need to communicate with other coplets.  In my
case, SearchCriteria object needs to be passed to
"Search Results" coplet or possibly to "Save Search"
coplet on another portal page.  This is similar to my
previous problem with login coplet, which needed to
communicate outside of its own context.


I know, this problem keeps coming up in one form or
another – must be my luck :-(  In general, though, it
seems that coplet to coplet or coplet to portal
communication is allowed via events, however, it would
be great to see it extended to use flow as well. 
Given that flow is now the primary place to put
controller type logic, it seems inconsistent having to
do it in two places: flow and events.  Especially it
becomes tough when the two are not well integrated. 
Ideally, it would be nice to be able to do all of it
in flow with simple sendPage/sendPageAndWait’s, but
I’m not sure how well they would fit into the portal
model.


2. Not using CachingURICoplet, in conjunction with
temporary:application-uri attibute, would allow the
"Search" coplet to communicate with other coplets (I
think), however, the fact that request parameters will
not be available to it, means I cannot use Cforms for
binding.  Now, say I could pass all 15 of my search
parameters to my "Search Results" via coplet
attributes (a bit painful, but can be done).  How
would I pass the events to other coplets/pages? 
"Event Handling" doc, has the following paragraph:

"Imagine a form coplet where the user can enter a
city. When this form is processed by the form coplet,
it can generate one (or more) CopletJXPathEvents and
push the entered city information to a weather coplet
and a hotel guide coplet. So, these two coplets
display the information about the selected city."

Sounds like what I need.  How does the form generate
these events and how do these events get passed on to
other coplets?  Is there a way I need to tag input
fields?  Anything I need to add to my submit buttons?

Thanks,
-Alex

Re: error handling

[Vadim Gritsenko]

Torsten Curdt wrote:
I have an interal pipeline which sometimes
throws an exception due to broken links.
  



  
  

  
And another one using it
  

 --> calls the intenal pipeline
...
  
Using the first pipeline works just
fine. Exceptions are being caught and
a default xml file is being presented
instead.
Unfortunately using it through the
second pipeline (through the cinclude
transformer) brings up the exception.
Anyone a clue what's happing here?

IIRC, last first friday we had a chat with Carsten about adding an 
attribute to the  or to the  which will 
indicate what behavior is needed in case of internal request: throw 
exception or process . Carsten?

Vadim

Re: Quick Question about Javaflow

[Antonio Gallardo]

Torsten Curdt dijo:
>> I am kinda worried about javascript flow dissapearing on me with the
>> licensing issues.
>
> A lot of people are using the javascript
> version ...don't be too concerned - on
> the other hand giving javaflow a try
> might be not a too bad idea.

As Torsten said, Javascript cannot desappear. The problem will be solved.
There is a new proposal is to solve it. Don't have concerns about
javascript flow code.

Best Regards,

Antonio Gallardo

DO NOT REPLY [Bug 29381] - Can't process DOM document passed from flowscript to jx template

[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=29381

Can't process DOM document passed from flowscript to jx template





--- Additional Comments From [EMAIL PROTECTED]  2004-06-03 22:17 ---
Hey, that works! I had tried #{document} but not #{document/*}. My workaround
was to save the file to disk and load it again using a file generator, which was
ugly. It still seems very odd that with ${document}, it can serialize the XML
but not transform it, though.

Thanks!

DO NOT REPLY [Bug 29381] - Can't process DOM document passed from flowscript to jx template

[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=29381

Can't process DOM document passed from flowscript to jx template





--- Additional Comments From [EMAIL PROTECTED]  2004-06-03 21:43 ---
I've experienced the same problem.

If you change ${document} to #{document/*}, 
do you get the expected result?

It still seems like a bug, but if this is a showstopper for you, maybe this 
helps you move along.

DO NOT REPLY [Bug 29381] New: - Can't process DOM document passed from flowscript to jx template

[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=29381

Can't process DOM document passed from flowscript to jx template

   Summary: Can't process DOM document passed from flowscript to jx
template
   Product: Cocoon 2
   Version: 2.1.5
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Flowscript
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If I attempt to pass a w3c dom document from a flowscript to a jx template
generator, I get a runtime error as soon as I attempt to run a transformation on
the output of the generator.

The js flowscript passes the document like this: 

sendPage("success-pipeline", {document: document});

The pipeline starts with a jx generator (with "${document}" in
the template file) and does a single xsl transformation. If I serialize to xml
after the generator (i.e. no transformation), I see the XML as expected (valid,
no extraneous XML header in the body or anything); but if I run even a trivial
transformation (e.g. ""), I get this:

org.apache.cocoon.ProcessingException: Failed to execute pipeline.:
java.lang.RuntimeException
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:552)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:173)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:490)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:120)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:126)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:101)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:336)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.handleCocoonRedirect(TreeProcessor.java:386)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.access$000(TreeProcessor.java:66)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor$TreeProcessorRedirector.cocoonRedirect(TreeProcessor.java:547)
at
org.apache.cocoon.environment.ForwardRedirector.redirect(ForwardRedirector.java:58)
at
org.apache.cocoon.components.flow.AbstractInterpreter.forwardTo(AbstractInterpreter.java:182)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.forwardTo(FOM_JavaScriptInterpreter.java:837)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.forwardTo(FOM_Cocoon.java:1482)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsFunction_sendPage(FOM_Cocoon.java:265)

(etc.)

Re: [heads up] PMC chair nominations

[Steven Noels]

On 03 Jun 2004, at 17:55, Stefano Mazzocchi wrote:
If this wasn't the correct wording, blame yourself, not others.
I see no blame in what I wrote, nor was it my intention to blame 
anyone. Please remember who *wrote* what I committed to CVS. I just 
added one phrase at the end of what you (very kindly) provided, and 
committed it as-is.

FYI, as a rule, I never vote for to somebody who nominated 
himself/herself for something.
Valid opinion, but quite honestly I don't see what this has to do with 
what I wrote. PMC Chairing is a Volunteer Job IMHO. That's all I wanted 
to say.

Chill out, man. What do you want to prove here?

--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java & XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

RE: error handling

[Hunsberger, Peter]

> 
> Torsten Curdt <[EMAIL PROTECTED]> asks:
>  
> > After further investigations it seems like exceptions
> > are passed to the error handler inside the treeprocessor.
> > But requests using the cocoon protcol don't go through
> > the treeprocessor the same way as external ones.
> > So basically error handling is missing - or broken for
> > such internal requests.
> > 
> > I think this is a vital feature and I am
> > wondering why noone hit that before.
> 
> We came across this and I had assumed it was intentional.  I 
> believe there was some discussion about changing this, but I 
> can't find the thread.  

Spoke too quick, have a look at:

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107402329728352&w=2

> I can find my message:
> 
>   
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107402329728352&w=2

Where it turns out that the problem was because the pipeline was
internal...

Re: [heads up] PMC chair nominations

[Andrew Savory]

Hi,
On 3 Jun 2004, at 08:18, Steven Noels wrote:
I'll start the vote tomorrow, as the list of volunteers seems to be 
stabilizing. Would candidates mind if this is a public vote? Also, I'd 
like the vote to be held on the users list as well - to raise the 
level of their awareness of Cocoon community matters.
Damn, sorry Steven - was typing and emailing on the train, and missed 
your email.

+1 for a public + users vote.
Andrew.
--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658  Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Orixo alliance: http://www.orixo.com/


smime.p7s
Description: S/MIME cryptographic signature

RE: error handling

[Hunsberger, Peter]

Torsten Curdt <[EMAIL PROTECTED]> asks:
 
> After further investigations it seems like exceptions
> are passed to the error handler inside the treeprocessor.
> But requests using the cocoon protcol don't go through
> the treeprocessor the same way as external ones.
> So basically error handling is missing - or broken for
> such internal requests.
> 
> I think this is a vital feature and I am
> wondering why noone hit that before.

We came across this and I had assumed it was intentional.  I believe
there was some discussion about changing this, but I can't find the
thread.  I can find my message:


http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107402329728352&w=2

Where it turns out that the problem was because the pipeline was
internal...

Re: error handling

[Torsten Curdt]

After further investigations it seems like exceptions
are passed to the error handler inside the treeprocessor.
But requests using the cocoon protcol don't go through
the treeprocessor the same way as external ones.
So basically error handling is missing - or broken for
such internal requests.
I think this is a vital feature and I am
wondering why noone hit that before.
What do you guys think?
Mr. Treeprocessor (Sylvain) and
Mr. Pipeline (Carsten) in particular ;-)
cheers
--
Torsten

DO NOT REPLY [Bug 29373] New: - portal: NPE in AbstractUserProfileManager with noncaching pipelines

[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=29373

portal: NPE in AbstractUserProfileManager with noncaching pipelines

   Summary: portal: NPE in AbstractUserProfileManager with
noncaching pipelines
   Product: Cocoon 2
   Version: 2.1.5
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: blocks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


How to reproduce:
In the root sitemap set 
and now try the portal block sample; A NPE will occur.

Original Exception: org.apache.avalon.framework.CascadingRuntimeException:
Exception during loading of profile.
at
org.apache.cocoon.portal.profile.impl.AbstractUserProfileManager.getPortalLayout(AbstractUserProfileManager.java:355)
at
org.apache.cocoon.portal.impl.PortalManagerImpl.showPortal(PortalManagerImpl.java:70)
at
org.apache.cocoon.portal.impl.PortletPortalManager.showPortal(PortletPortalManager.java:240)
at
org.apache.cocoon.portal.generation.PortalGenerator.generate(PortalGenerator.java:59)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:545)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:490)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:120)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49)
at
org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke(ActTypeNode.java:138)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:126)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:101)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:336)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:277)
at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:103)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:126)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:101)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:336)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:277)
at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:103)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:126)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:101)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:336)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:2

Re: Quick Question about Javaflow

[Torsten Curdt]

Is it working well enough to start reading up and using it?
Well, we are still missing auto-compilation and
I am sure you will run into some issues. It's
very new and noone uses in production yet.
But we need people to play with it.
I am kinda worried about javascript flow dissapearing on me with the 
licensing issues.
A lot of people are using the javascript
version ...don't be too concerned - on
the other hand giving javaflow a try
might be not a too bad idea.
Depends on how time critical your
projects are...
I hit th ewiki and searched for "javaflow" and nothing up :)
Have a look at the samples ...should
give you a good starting point. If
you got lost - ask :)
cheers
--
Torsten

DO NOT REPLY [Bug 29369] New: - Move commons-logging-1.0.3.jar to lib/core as jcs.jar depends on it

[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=29369

Move  commons-logging-1.0.3.jar to lib/core as jcs.jar depends on it

   Summary: Move  commons-logging-1.0.3.jar to lib/core as jcs.jar
depends on it
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: PC
OS/Version: All
Status: NEW
  Severity: Minor
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Trying to upgrade cocoon to version 2.1.5 I got this error that was caused by
the missing commons-logging-1.0.3.jar, so there is a dependency on 
jcs-1.0-dev-20040516.jar.

Exception in thread "main" java.lang.NoClassDefFoundError:
org/apache/commons/logging/LogFactory
at
org.apache.jcs.engine.control.CompositeCacheManager.(CompositeCacheManager.java:46)
at
org.apache.cocoon.components.store.impl.JCSDefaultStore.initialize(JCSDefaultStore.java:177)
at
org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil.java:283)
at
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:277)
at
org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:108)
at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(ExcaliburComponentManager.java:276)
at
org.apache.cocoon.components.CocoonComponentManager.lookup(CocoonComponentManager.java:297)
at
org.apache.avalon.framework.service.WrapperServiceManager.lookup(WrapperServiceManager.java:107)
at
org.apache.cocoon.transformation.helpers.DefaultIncludeCacheManager.parameterize(DefaultIncludeCacheManager.java:410)
at
org.apache.avalon.framework.container.ContainerUtil.parameterize(ContainerUtil.java:267)
at
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:274)
at
org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:108)
at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.initialize(ExcaliburComponentManager.java:522)
at
org.apache.cocoon.components.CocoonComponentManager.initialize(CocoonComponentManager.java:527)
at
org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil.java:283)
at org.apache.cocoon.Cocoon.initialize(Cocoon.java:306)
at
org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil.java:283)
at org.apache.cocoon.bean.CocoonWrapper.initialize(CocoonWrapper.java:151)
at org.apache.cocoon.bean.CocoonBean.initialize(CocoonBean.java:97)
at org.apache.cocoon.Main.main(Main.java:320)

Quick Question about Javaflow

[JD Daniels]

Is it working well enough to start reading up and using it?
I am kinda worried about javascript flow dissapearing on me with the 
licensing issues.

I hit th ewiki and searched for "javaflow" and nothing up :)
JD

Re: [heads up] [cforms] problem with calendar popup on ie6

[JD Daniels]

My solution was to have an iframe in the page and put the calendar div 
inside it.. they behave the same as the select lists, so they cover it up.

Jon Evans wrote:
Hi Marc,
On 10 May 2004, at 21:21, Marc Portier wrote:
I just checked in an update for one of our cforms samples that reveals a
somewhat nasty visual presentation of the nice calendar widget we use

if placed just above a (multi-line) selection list (like done now) the
calendar popup seems to be kept behind that selection list...
anyone that has a clue what is causing this?

As others have said, it's an IE issue, and manipulating z-order 
doesn't help. :-(

For our app we have added some javascript - just before the popup 
appears, we do a collision check on all drop-downs on the page (we 
don't use multi-selects, but it could be extended to include them).  
Any that collide are hidden until the popup goes away.  Originally we 
just hid all drop-downs, but that was too noticeable.

If you want the code, let me know.
Incidentally Safari/Mac has the same issue with the scroll bars on 
text areas (they always appear on top).

Jon

Re: [heads up] PMC chair nominations

[Stefano Mazzocchi]

Steven Noels wrote:
On 31 May 2004, at 12:25, Stefano Mazzocchi wrote:
The ASF board decided not to accept Steven's resigns until the PMC 
itself came up with a new informed decision on who should follow him.

This means that Steven remains the chair until the board ratifies it.

(I've been away for a couple of days)
Just to clarify things: we agreed little more than a year ago that we 
should make this "Chair" job a low-fuzz/low-profile thing. One way to 
ensure this is to keep terms short, but still effective - something like 
a year. It's been little more than a year now that I did my part of the 
duty, and I announced my *willingness* to resign by this summer to the 
PMC list. This somehow was communicated to the board as "my 
resignation"
Steven, *YOU* committed this to CVS:
  Steven Noels has indicated his intention to step down from PMC chair.
  Bertrand was nominated but indicated his lack of continous time in 
the next
  few months. Nominations are still undergoing.

If this wasn't the correct wording, blame yourself, not others.
, however I had indicated that I would stay on the job as 
long as no successor had been voted on. So the board didn't *have* to 
accept anything, since we haven't forwarded them a resolution to agree 
upon.

Here I would like to start the nominations (in no particular order):

While it's a low profile thing, it requires some energy and dedication, 
and I would everybody advise *not* to propose anyone but themselves. 
I STRONGLY suggest the opposite. I think the job of a PMC is done 
*better* but those who would *NOT* think they are up to the task.

You don't propose yourself for ASF membership, you get nominated by 
somebody else and you have the faculty to reject the nomination and, if 
you accept, you get voted by your peers.

The model applies here as well.
FYI, as a rule, I never vote for to somebody who nominated 
himself/herself for something.

This is not a question of nominations and votes, it's just a matter of 
finding people who want to *do* the job (rather than *be* the chair). 
Sure. that's why you have the ability to turn the nomination down (like 
Bertrand did).

Let's not make this into a popularity contest, nor nominate anyone but 
yourself, and let volunteers step up and propose themselves. This was my 
rationale for *not* proposing successors myself.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

DO NOT REPLY [Bug 29365] New: - Zip file remains 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=29365

Zip file remains open

   Summary: Zip file remains open
   Product: Cocoon 2
   Version: 2.1.5
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have the following pipeline:











If I call from the browser the "b" pipeline, it works ok, but the zip file
"myfile.sxw" remains opened and cannot be replaced unless the Web server is
restarted. 

The inputstream isn't closed.

The problem doesn't happen if I call the "a" pipeline directly.

I've tried to solve it myself, but I see the code quite complicated.  :-(

Confirmed it happens also in Cocoon 2.1.3

Java version: 1.4.2.04
Operating system: Windows 2003 Server.

Pipeline recursion (sort of)?

[Hunsberger, Peter]

I've been starting to generalize our systems architecture and I realized
that there is one generalization that might be problematic with Cocoon.
Basically, we allow a hierarchy of metadata.  For example (use fixed
fonts):

system
   |
   V
  application
   |
   V
service
   |
   V
   division
   |
   V
   department
   |
   V
section
   |
   V
   individual

At each level it is possible to override the metadata of the previous
level. We currently support two (sort of three) layers of metadata with
hard coded generators for each layer and a subsequent XSLT that merges
the results. The generalization I'm after would allow the number of
levels to be dynamically determined for each individual.  

The simple minded implementation just runs a single generator that
handles all the dynamics and spits out the merged results. The big issue
is caching.  As you move down the hierarchy each level of metadata has
to be cached for a smaller population, but the odds of it changing are
smaller and it can likely be cached for a longer period of time.
Basically, I want each level of metadata to have it's own cache key and
cache validity. 

I think I might be able to do this with flow script and
"processPipelineTo"?  I'm guessing I'd be able to just keep looping on
the pipeline calls (a previous pipeline would supply the meta-metadata
that tells me what metadata is required dynamically)? Each invocation
would basically pick up a variable from the previous invocation and add
it's results in some predictable pattern. If I subsequently re-invoke a
pipeline with "processPipelineTo" is there any reason the normal cache
checking wouldn't work?

The biggest problem I see with this approach is the cacheability of the
overall results (which we would really need).  Here I think I'd be able
to use some kind of composite cache validity, basically picking up the
cache validity from each step of the "processPipelineTo" calls and using
them in some kind of container cache validity checker that would
determine if the overall pipeline was still valid (basically a identity
transformer that does nothing but generate a cache key and cache
validity on the overall pipeline results). How the heck would I pick up
the cache validity objects from the processPipelineTo steps for the
overall composite validity? 

Any of this make sense, or am I wondering off into a world of
generalization that Cocoon is just not suited for?

Peter Hunsberger

Re: JXTG and caching - IT'S DONE

[Leszek Gawron]

Upayavira wrote:
It seems to me that Sylvains suggested extension of jxt has a great 
deal of power in it.

OK. Then I'll continue my work and try to provide the appropriate 
patch as I have already started to make needed changes.

Great. I'd love to see a cacheable jxt.
Regards, Upayavira
You can test the first implementation if you fetch this file :
http://ouzo.wlkp.org/cjxtg.zip
it contains :
CachingJXTemplateGenerator.java which you should put to the same directory as 
JXTG.java and rebuild your cocoon.

There also is a simple test case in test directory. Put it into your webapp 
root and then issue this url:

http://localhost:/test/test.do?key=
if I got it right the view is generated once for each key and cached so the 
date on the page won't change if you refresh your page.

How it works:
1. every attribute in "http://apache.org/cocoon/templates/jx/1.0"; namespace 
get stripped from attributes and end up in StartDocument event in 
templateProperties map (which I added). This is something that could be used 
for providing additional parameters to template in the future.
These attributes are not generated to output. They are only stored in map. 
This was the simplest solution. I think it's acceptable. How about you?

2. In template's root element (or any element really) you put:

The key should be Serializable and the Validity should be SourceValidity of 
course.

Voilla .. the page gets cached.
What changed:
1. CachingJXTemplateGenerator implements CacheableProcessingComponent
   of course :)
2. StartDocument.templateProperties added
3. I had to move template parsing from generate to setup(). Otherwise that 
happened:

- fetch http://localhost:/test/test.do?key=abc
- setup() called
- getKey() called - template not parsed yet, cannot compute key - no view
  caching will be done
- generate() - template gets parsed and generated, template cached
- refresh browser
- setup() called
- getKey() - got parsed template, can evaluate cache-key
- lookup from cache fails as the first response was not cached
- generate() - template already parsed
- response cached, getValidity() called somewhere of course
The response gets cached after second page hit because getKey() first time is 
called before template is parsed. When parsing is moved to setup() this happens:

- fetch http://localhost:/test/test.do?key=abc
- setup() called, template gets parsed
- getKey() called, template accessible, key computed
- cache lookup falils
- generate() called
- response cached!
This class can become standard JXTemplateGenerator as if you do not provide 
caching attributes the page never gets cached so it works like it did before.

Please make your comments
--
Leszek Gawron  [EMAIL PROTECTED]

Re: [BUG] Registering of JavaFlow fails (was: [JavaFlow] java.lang.VerifyException)

[Stephan Michels]

Am Do, den 03.06.2004 schrieb Stephan Michels um 15:00:
> Am Di, den 01.06.2004 schrieb Stephan Coboos um 20:23:
> > Hello,
> > 
> > I have a problem using Objects in JavaFlow before a while loop. Please 
> > see my first posting [JavaFlow] java.lang.VerifyException. In my opinion 
> > it can be a bug in the JavaFlow block.
> > 
> > Because my fist posting was not so clear, I had tried to reproduce the 
> > error for a while and I had discovered the following code which creates 
> > such an error (you need the packages of Lucene):
> >
> > java.lang.VerifyError: (class: foo/bar/TestFlow, method: doTest 
> > signature: ()V) Incompatible object argument for function call
> >
> > Is it really a bug? Why is it not possible to declare these three line 
> > within the method doTest? What can I do?
> 
> Yes, it seems to be a bug. I guess its a problem the following line
> 
>   query = QueryParser.parse("foo", "bar", new StandardAnalyzer());
> 
> I had many problem in the past with uninitialized objects and saving the
> continuation. I will take a look into it.

It was a problem with null objects, which were stored into the
continuation. If the frame will be restored, the null object cannot
be casted into the right type. So, at the end the correct signatur
couldn't be found.

Hits hits;
IndexSearcher searcher = null;
sendPageAndWait("foo");
hits = searcher.search(query);

I have fixed it now.

Stephan.

RE: [RT] Cocoon component container and excalibur

[Hunsberger, Peter]

Antonio Gallardo <[EMAIL PROTECTED]> writes:

> Hi:
> 
> Thanks to all for the answers. All posts helped a lot to go 
> out of my confusion.

Ok, I'll bite, what did you decide?

[CVS] Flow bug in redirections? Test case inside.

[Antonio Gallardo]

Hi:

I have 2 days with this problem. Here is a test case of the redirection
problem in flow:

1-Build Cocoon with samples.
2-Run ./cocoon.sh servlet
3-Copy $COCOON_HOME/build/webapp/samples/flow to
$COCOON_HOME/build/webapp/samples/flowbug
(we need it because we will make a call from flowbug to flow.

4-Change line 38 in
$COCOON_HOME/build/webapp/samples/flowbug/jxcalc/calc.js to any of:

A-var uri = "samples/flow/jxcalc/page/getNumber" + name.toUpperCase();
B-var uri = "/samples/flow/jxcalc/page/getNumber" + name.toUpperCase();
C-var uri = "//samples/flow/jxcalc/page/getNumber" + name.toUpperCase();
D-var uri = "///samples/flow/jxcalc/page/getNumber" + name.toUpperCase();

5- On a browser, connect to:

http://localhost:/samples/flowbug/jxcalc/

You will get:
--
A-No pipeline matched request:
samples/flowbug/jxcalc/samples/flow/jxcalc/page/getNumberA

org.apache.cocoon.ResourceNotFoundException: No pipeline matched request:
samples/flowbug/jxcalc/samples/flow/jxcalc/page/getNumberA

COMMENT: It is OK. There does not exist in relative path.
--
B-No pipeline matched request: samples/flow/jxcalc/page/getNumberA

org.apache.cocoon.ResourceNotFoundException: No pipeline matched request:
samples/flow/jxcalc/page/getNumberA

COMMENT: Why? It must go to the redirection in flow directory using the
sitemap that is in flow dir!

--
C-No pipeline matched request: /samples/flow/jxcalc/page/getNumberA

org.apache.cocoon.ResourceNotFoundException: No pipeline matched request:
/samples/flow/jxcalc/page/getNumberA

COMMENT: Again, why? As above, the link exists!
--
D-No pipeline matched request: //samples/flow/jxcalc/page/getNumberA

org.apache.cocoon.ResourceNotFoundException: No pipeline matched request:
//samples/flow/jxcalc/page/getNumberA

COMMENT: Again, why? As above, the link exists!
--

It will never go to the requested path!

If it works, it would be the same as:

http://localhost:/samples/flow/jxcalc/page/getNumberA

And we would need to receive a diferent error:

org.apache.cocoon.ProcessingException: Failed to execute pipeline.:
file:/home/agallardo/workspace/cocoon-2.1/build/webapp/samples/flow/jxcalc/screens/getNumberA.xml:30:72:org.apache.commons.jxpath.JXPathException:
No value for xpath: $cocoon/continuation/id

Now the question is what is affecting that?

Best Regards,

Antonio Gallardo

RE: [RT] Cocoon component container and excalibur

[Hunsberger, Peter]

Antonio Gallardo <[EMAIL PROTECTED]> asks:

> Hi:
> 
> I need to accept I am lost in the component containers.
> 
> Cocoon is migrating to a new container architecture. The 
> question remaining in my mind is: How to develop components 
> right now? 

Good question, I was just wondering this myself yesterday.

some alternatives

> The things are even worse: some people suggest Web services 
> as the right path, others said that Flow with Javascript is a 
> nowhere path. Don't miss the pressure of EJB vs. lightweight 
> containers, etc.
 
We've got an EJB container, but it really doesn't buy us anything.
There's little real reason for us to use EJB that can't be achieved some
other way.  I'd love to have a lightweight, low overhead, poolable DB
layer that we could migrate to.

Re: [RT] Cocoon component container and excalibur

[Andreas Hartmann]

Pier Fumagalli wrote:
[...]
I guess I got this wrong - isn't this distinction based on
the difference between compile time / runtime? My component
will use a logger and a configuration in any case, but maybe
it doesn't know which services it will need later on. When it
"requires" each other block it might want to use, wouldn't
this generate some overhead?

You declare your requirement in the descriptor, but access the instance 
at runtime...

I'm not concerned about the access mechanism, but about the selection 
mechanism. The block should be given a specific instance of a Generator 
(for example) if they require one. But they should not be allowed to 
look up for a ComponentSelector upon which the block itself "chooses" 
which one of the generator it wants...
OK, so you mean it shouldn't be possible to choose among several
Generators using a specific hint? I must admit that I never really
felt comfortable with the concept of hints. When you define the
behaviour of a component using an implementation-independent
interface, don't you bypass this concept when you obtain a specific
implementation using a hint?
It is obvious that an implementation should be chosen based on
certain priorities (speed, memory consumption, ...) - how would
this be managed without selection?
Thanks for your explanations!
-- Andreas

Re: swf block

[Sylvain Wallez]

Torsten Curdt wrote:
As we decided to deprecate the swf block in the last 2.1.5 release I 
create a new sample how to use flash with cocoon.

If there aren't any objections I will nuke the swf block and add the 
flash sample. (no further components are needed anymore)

Everyone alright with that?

+1 since Spark is dead and not featured enough for some serious work.
But the need to produce Flash exists (opposed to having the Flash 
fetching XML data) : we're using it to display animated diagrams on 
small devices (PDAs & phones) where SVG is not available. In order to 
save bandwidth and CPU, we send the diagram as a Flash movie (generated 
by Cocoon), and XML fetching is only used for animation (changing 
colors, moving objects, etc).

We've investigating KineticFusion (commercial, [1]) which does a nice 
job. Anybody else having some experience with it or some other 
equivalent tool?

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

Re: error handling

[Torsten Curdt]

I have an interal pipeline which sometimes
throws an exception due to broken links.
  
  
  
  
  

  
  

  
And another one using it
  

   --> calls the intenal pipeline
...
  
...of course
We were discussing it here... does the cocoon
protocol create a new or use the existing
pipeline? ...if it's the same pipeline it
would explain the behaviour.
But IMHO it should work like in the
example above... WDYT?
cheers
--
Torsten

Re: swf block

[Torsten Curdt]

I'm interested to see what you come up with.
Nothing fancy ...just a "hello world"
served by cocoon :) Gonna commit it
later on today then...
cheers
--
Torsten

Re: [RT] Cocoon component container and excalibur

[Pier Fumagalli]

On 3 Jun 2004, at 13:16, Andreas Hartmann wrote:

Second of all (but I think this is solvable) component selection is 
kinda weird and goes totally against the IOC principles.
A block should require another block, it should not by any means 
"select" a block as we do now with component selectors)...
>
It's kinda mixed at the moment, I'm given a logger, I'm given a 
configuration, but I have to ask for a component?
I guess I got this wrong - isn't this distinction based on
the difference between compile time / runtime? My component
will use a logger and a configuration in any case, but maybe
it doesn't know which services it will need later on. When it
"requires" each other block it might want to use, wouldn't
this generate some overhead?
You declare your requirement in the descriptor, but access the instance 
at runtime...

I'm not concerned about the access mechanism, but about the selection 
mechanism. The block should be given a specific instance of a Generator 
(for example) if they require one. But they should not be allowed to 
look up for a ComponentSelector upon which the block itself "chooses" 
which one of the generator it wants...

Pier


smime.p7s
Description: S/MIME cryptographic signature

Re: Strange behaviour from 2.1.5

[Pier Fumagalli]

On 3 Jun 2004, at 10:52, Jeremy Quinn wrote:
Hi All
I just upgraded an existing project to 2.1.5 and am experiencing some 
strange problems with FlowScript.
[...]
What was worse was that these messages would GO AWAY on reload !
[...]
I suspect the new caching system (which throws exceptions on shutdown)
If you remember, all our problems with the VNUNET project got sorted 
out when we started using non-caching pipelines, weirdly enough...

All those components that didn't actually render correctly after a 
little while, and that (magically) re-appeared on reloads...

Maybe there is something wrong with the cache
	Pier (just throwing ideas on the wall out here)


smime.p7s
Description: S/MIME cryptographic signature

error handling

[Torsten Curdt]

I have an interal pipeline which sometimes
throws an exception due to broken links.
  



  
  

  
And another one using it
  

 --> calls the intenal pipeline
...
  
Using the first pipeline works just
fine. Exceptions are being caught and
a default xml file is being presented
instead.
Unfortunately using it through the
second pipeline (through the cinclude
transformer) brings up the exception.
Anyone a clue what's happing here?
cheers
--
Torsten

Re: swf block

[Joerg Heinicke]

On 03.06.2004 14:44, Upayavira wrote:
As we decided to deprecate the swf block
in the last 2.1.5 release I create a new
sample how to use flash with cocoon.
If there aren't any objections I will
nuke the swf block and add the flash
sample. (no further components are
needed anymore)
Everyone alright with that?
+1
I'm interested to see what you come up with.
+1 Same here!
Joerg

DO NOT REPLY [Bug 29360] - precompile xsp's without starting URI

[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=29360

precompile xsp's without starting URI

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|[EMAIL PROTECTED]   |[EMAIL PROTECTED]

Re: Strange behaviour from 2.1.5

[Jeremy Quinn]

On 3 Jun 2004, at 13:48, Antonio Gallardo wrote:
Hi Jeremy:
Thanks for the answer. Can be the problem related to switching between
sitemaps? ie: Lets said your are in a form in the record.xmap and from
inside a flow you call a function from search.xmap.
no, this kind of thing is not being done
apart from authentication (which is not fully applied yet anyway) we do 
not re-use across sub-sitemaps via flow-called pipelines.

Reading again your problem, is posible you have similar function names
between the .js files? Maybe this is the problem.
No, I avoid this like the plague ;)
We have all unique function names across all of the flowscript files
I have a similar problem, but now I think it is quite diferent. My 
problem
is not related to 2.1.5, it is related to lastest CVS.
OK, we are trying to avoid using non-release versions as it makes sure 
all developers are using exactly the same environment.

regards Jeremy

smime.p7s
Description: S/MIME cryptographic signature

DO NOT REPLY [Bug 29360] New: - precompile xsp's without starting URI

[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=29360

precompile xsp's without starting URI

   Summary: precompile xsp's without starting URI
   Product: Cocoon 2
   Version: 2.1.5
  Platform: PC
OS/Version: All
Status: NEW
  Severity: Critical
  Priority: Other
 Component: general components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I want precompile my xsp's with the Command line Interface using by ant.

snipped from build.xml:


in Cocoon 2.1.4 works this fine, but not Cocoon 2.1.5
 Error: Please, specify at least one starting URI.

Snipped from your documentation:
"If no URIs are specified, it will scan all directories within the context 
directory looking for XSP files, each of which will be compiled."

Only we can use this variant. The variant with the starting URI functioned not 
with ant without application server, datebase, ours license service etc.

Greetings from
Andrea Pöschel
Knowledge Engine Development

Re: [BUG] Registering of JavaFlow fails (was: [JavaFlow] java.lang.VerifyException)

[Stephan Michels]

Am Di, den 01.06.2004 schrieb Stephan Coboos um 20:23:
> Hello,
> 
> I have a problem using Objects in JavaFlow before a while loop. Please 
> see my first posting [JavaFlow] java.lang.VerifyException. In my opinion 
> it can be a bug in the JavaFlow block.
> 
> Because my fist posting was not so clear, I had tried to reproduce the 
> error for a while and I had discovered the following code which creates 
> such an error (you need the packages of Lucene):
>
> java.lang.VerifyError: (class: foo/bar/TestFlow, method: doTest 
> signature: ()V) Incompatible object argument for function call
>
> Is it really a bug? Why is it not possible to declare these three line 
> within the method doTest? What can I do?

Yes, it seems to be a bug. I guess its a problem the following line

  query = QueryParser.parse("foo", "bar", new StandardAnalyzer());

I had many problem in the past with uninitialized objects and saving the
continuation. I will take a look into it.

Stephan.

Re: [RT] Cocoon component container and excalibur

[Andreas Hartmann]

Antonio Gallardo wrote:
Andreas Hartmann dijo:
I'm sorry to join the discussion without any knowledge
about the blocks concept, but I'm interested in learning them.
Could somebody give me a short pointer to a useful resource?

http://wiki.cocoondev.org/Wiki.jsp?page=BlockIntroduction
http://wiki.cocoondev.org/Wiki.jsp?page=GT2003RealBlocks
http://wiki.cocoondev.org/Wiki.jsp?page=Blocks
http://wiki.cocoondev.org/Wiki.jsp?page=BlocksUseCases
http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
Aah - it's about Cocoon blocks, I thought it's about Avalon blocks :)
Thank you!
-- Andreas

Re: Strange behaviour from 2.1.5

[Antonio Gallardo]

Hi Jeremy:

Thanks for the answer. Can be the problem related to switching between
sitemaps? ie: Lets said your are in a form in the record.xmap and from
inside a flow you call a function from search.xmap.

Reading again your problem, is posible you have similar function names
between the .js files? Maybe this is the problem.

I have a similar problem, but now I think it is quite diferent. My problem
is not related to 2.1.5, it is related to lastest CVS.

Best Regards,

Antonio Gallardo

Re: swf block

[Antonio Gallardo]

Torsten Curdt dijo:
> As we decided to deprecate the swf block
> in the last 2.1.5 release I create a new
> sample how to use flash with cocoon.
>
> If there aren't any objections I will
> nuke the swf block and add the flash
> sample. (no further components are
> needed anymore)
>
> Everyone alright with that?

+1

Best Regards,

Antonio Gallardo

DO NOT REPLY [Bug 29308] - issue with javaflow continuations

[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=29308

issue with javaflow continuations

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Additional Comments From [EMAIL PROTECTED]  2004-06-03 12:49 ---
The problem is that Im mixing instrumented and uninstrumented classes.
And it seems that if you have different types of classes coming from the
same source file, then you will get an IllegalAccessError.
And have now added an option to declare whole package paths as Continuable.


 


I havn't fully tested it, so, would be fine if you tell me if it works.

Re: Strange behaviour from 2.1.5

[Andreas Schmid]

I just read it to late that you're using FlowScript... not JavaFlow...
In JavaFlow you declare classes, so you are abel to create Variables 
from outside the functions which we call global, because you can use 
them all over the class...
Jeremy Quinn wrote:

On 3 Jun 2004, at 13:02, Andreas Schmid wrote:
I know that this will not fix the "bug". But we've postet this bug 2 
Days ago and till now there is no answer. So we needed to make a 
workaround to  continue working.
What i did was just telling you who to do a workaround...
:-)

Sorry for my misunderstanding.
You are saying that adding any old global variable to each of the 
flowscript magically solves the problem?

Remind me, is there a special syntax for global variables ?
thanks
regards Jeremy

Jeremy Quinn wrote:
On 3 Jun 2004, at 11:53, Andreas Schmid wrote:
Just try to declare your variables as globals outside the functions.
This should help that the JavaFlow willl Work...

Many thanks for your reply, but I cannot see how this will solve the 
problem.
These are flowscripts that are known to work (in 2.1.4 and 
eventually in 2.1.5).

The functionality of the scripts does not require nor want global 
variables.

regards Jeremy
Jeremy Quinn wrote:
Hi All
I just upgraded an existing project to 2.1.5 and am experiencing 
some strange problems with FlowScript.

I am seeing a lot of these errors:
org.apache.avalon.framework.CascadingRuntimeException: 
"resource://org/apache/cocoon/forms/flow/javascript/Form.js", line 
203: uncaught JavaScript exception: at handleForm 
(resource://org/apache/cocoon/forms/flow/javascript/Form.js, Line 
203): "uploadImage" is not a function.

These appear to be erroneous (it clearly IS a function and worked 
fine under previous versions), and nearly random in appearance 
(sometimes you get this sometimes you don't).

The next problem I started seeing was errors related to 
instantiating Java Objects from Flow, where the flow engine would 
complain that the package paths were ambiguous. What was worse was 
that these messages would GO AWAY on reload !

I suspect the new caching system (which throws exceptions on 
shutdown).

I am using the Release version of Cocoon 2.1.5 (we always attempt 
to only use release versions for development and we have several 
people working on the same project at the same time, and that 
makes it far easier).

Are there any known issues with 2.1.5 release that may be causing 
this behaviour ?

Many thanks for any suggestions.
regards Jeremy

Re: swf block

[Upayavira]

Torsten Curdt wrote:
As we decided to deprecate the swf block
in the last 2.1.5 release I create a new
sample how to use flash with cocoon.
If there aren't any objections I will
nuke the swf block and add the flash
sample. (no further components are
needed anymore)
Everyone alright with that?
+1
I'm interested to see what you come up with.
Upayavira

Re: [RT] Cocoon component container and excalibur

[Antonio Gallardo]

Andreas Hartmann dijo:
> I'm sorry to join the discussion without any knowledge
> about the blocks concept, but I'm interested in learning them.
> Could somebody give me a short pointer to a useful resource?

http://wiki.cocoondev.org/Wiki.jsp?page=BlockIntroduction
http://wiki.cocoondev.org/Wiki.jsp?page=GT2003RealBlocks
http://wiki.cocoondev.org/Wiki.jsp?page=Blocks
http://wiki.cocoondev.org/Wiki.jsp?page=BlocksUseCases
http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition

Best Regards,

Antonio Gallardo

Re: swf block

[Bertrand Delacretaz]

Le 3 juin 04, à 14:36, Torsten Curdt a écrit :
If there aren't any objections I will
nuke the swf block and add the flash
sample.
+1
-Bertrand

[portal] NPE accessing bookmarks

[Alex Romayev]

Hi,

The NPE happens under the following conditions:
- The bookmark needs to contain events with
targettype=coplet
- The bookmark must be the first link that the user
clicks within portal.  It seems that
CopletInstanceDatas don't get initialized.

Below is the stack,
-Alex


Original Exception: java.lang.NullPointerException
at
org.apache.cocoon.portal.profile.impl.AbstractUserProfileManager.getCopletInstanceData(AbstractUserProfileManager.java:157)
at
org.apache.cocoon.portal.acting.helpers.CopletMapping.getEvent(CopletMapping.java:34)
at
org.apache.cocoon.portal.acting.BookmarkAction.act(BookmarkAction.java:200)
at
org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke(ActTypeNode.java:119)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49)
at
org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke(ActTypeNode.java:138)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:126)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:101)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:336)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.buildPipeline(TreeProcessor.java:295)
at
org.apache.cocoon.components.source.impl.SitemapSource.init(SitemapSource.java:348)
at
org.apache.cocoon.components.source.impl.SitemapSource.(SitemapSource.java:223)
at
org.apache.cocoon.components.source.impl.SitemapSourceFactory.getSource(SitemapSourceFactory.java:64)
at
org.apache.excalibur.source.impl.SourceResolverImpl.resolveURI(SourceResolverImpl.java:208)
at
org.apache.cocoon.components.CocoonComponentManager.resolveURI(CocoonComponentManager.java:500)
at
org.apache.cocoon.components.CocoonComponentManager.resolveURI(CocoonComponentManager.java:500)
at
org.apache.cocoon.environment.AbstractEnvironment.resolveURI(AbstractEnvironment.java:531)
at
org.apache.cocoon.environment.AbstractEnvironment.resolveURI(AbstractEnvironment.java:518)
at
org.apache.cocoon.generation.FileGenerator.setup(FileGenerator.java:79)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:362)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessingPipeline.java:646)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:506)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:464)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:120)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:126)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:101)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:336)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:277)
at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:103)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:126)
at
org.apache.coco

Re: Strange behaviour from 2.1.5

[Jeremy Quinn]

On 3 Jun 2004, at 13:02, Andreas Schmid wrote:
I know that this will not fix the "bug". But we've postet this bug 2 
Days ago and till now there is no answer. So we needed to make a 
workaround to  continue working.
What i did was just telling you who to do a workaround...
:-)
Sorry for my misunderstanding.
You are saying that adding any old global variable to each of the 
flowscript magically solves the problem?

Remind me, is there a special syntax for global variables ?
thanks
regards Jeremy

Jeremy Quinn wrote:
On 3 Jun 2004, at 11:53, Andreas Schmid wrote:
Just try to declare your variables as globals outside the functions.
This should help that the JavaFlow willl Work...

Many thanks for your reply, but I cannot see how this will solve the 
problem.
These are flowscripts that are known to work (in 2.1.4 and eventually 
in 2.1.5).

The functionality of the scripts does not require nor want global 
variables.

regards Jeremy
Jeremy Quinn wrote:
Hi All
I just upgraded an existing project to 2.1.5 and am experiencing 
some strange problems with FlowScript.

I am seeing a lot of these errors:
org.apache.avalon.framework.CascadingRuntimeException: 
"resource://org/apache/cocoon/forms/flow/javascript/Form.js", line 
203: uncaught JavaScript exception: at handleForm 
(resource://org/apache/cocoon/forms/flow/javascript/Form.js, Line 
203): "uploadImage" is not a function.

These appear to be erroneous (it clearly IS a function and worked 
fine under previous versions), and nearly random in appearance 
(sometimes you get this sometimes you don't).

The next problem I started seeing was errors related to 
instantiating Java Objects from Flow, where the flow engine would 
complain that the package paths were ambiguous. What was worse was 
that these messages would GO AWAY on reload !

I suspect the new caching system (which throws exceptions on 
shutdown).

I am using the Release version of Cocoon 2.1.5 (we always attempt 
to only use release versions for development and we have several 
people working on the same project at the same time, and that makes 
it far easier).

Are there any known issues with 2.1.5 release that may be causing 
this behaviour ?

Many thanks for any suggestions.
regards Jeremy





smime.p7s
Description: S/MIME cryptographic signature

Re: Strange behaviour from 2.1.5

[Jeremy Quinn]

On 3 Jun 2004, at 13:10, Antonio Gallardo wrote:
Hi Jeremy:
I have another problem, but maybe it is related. I have a question. Are
you using subsitemaps? Can you explain how are distributed the .js 
files?
Yes we are using sub-sitemaps.
"sitemap.xmap" :
cocoon's main sitemap mounts our top-level 'project' sitemap :
"sitemap.xmap" :
uses 'authentication.js' flowscript
provides views of static XML documents
mounts each sub-section sitemap :

"authenticate.xmap" :
provides authentication services
uses 'authentication.js' flowscript
"record.xmap" :
provides database record viewing services
uses 'records.js' and 'pager.js' flowscript
"search.xmap" :
provides lucene index searching services
uses 'search.js' and 'pager.js' flowscript
"lucene.xmap" :
provides database record indexing services
uses 'lucene.js' flowscript
"upload.xmap" :
provides database record creation and asset uploading services
uses 'upload.js' flowscript

HTH
regards Jeremy
Best Regards,
Antonio Gallardo
Jeremy Quinn dijo:
Hi All
I just upgraded an existing project to 2.1.5 and am experiencing some
strange problems with FlowScript.
I am seeing a lot of these errors:
org.apache.avalon.framework.CascadingRuntimeException:
"resource://org/apache/cocoon/forms/flow/javascript/Form.js", line 
203:
uncaught JavaScript exception: at handleForm
(resource://org/apache/cocoon/forms/flow/javascript/Form.js, Line 
203):
"uploadImage" is not a function.

These appear to be erroneous (it clearly IS a function and worked fine
under previous versions), and nearly random in appearance (sometimes
you get this sometimes you don't).
The next problem I started seeing was errors related to instantiating
Java Objects from Flow, where the flow engine would complain that the
package paths were ambiguous. What was worse was that these messages
would GO AWAY on reload !
I suspect the new caching system (which throws exceptions on 
shutdown).

I am using the Release version of Cocoon 2.1.5 (we always attempt to
only use release versions for development and we have several people
working on the same project at the same time, and that makes it far
easier).
Are there any known issues with 2.1.5 release that may be causing this
behaviour ?
Many thanks for any suggestions.
regards Jeremy



smime.p7s
Description: S/MIME cryptographic signature

swf block

[Torsten Curdt]

As we decided to deprecate the swf block
in the last 2.1.5 release I create a new
sample how to use flash with cocoon.
If there aren't any objections I will
nuke the swf block and add the flash
sample. (no further components are
needed anymore)
Everyone alright with that?
cheers
--
Torsten

Re: [RT] Cocoon component container and excalibur

[Andreas Hartmann]

Pier Fumagalli wrote:
[...]
As a first, all selections are based on real-java-objects (tell me how 
to "require" a block that has no components, like a Forrest Skin and 
I'll be happy).
I'm sorry to join the discussion without any knowledge
about the blocks concept, but I'm interested in learning them.
Could somebody give me a short pointer to a useful resource?
Second of all (but I think this is solvable) component selection is 
kinda weird and goes totally against the IOC principles.

A block should require another block, it should not by any means 
"select" a block as we do now with component selectors)...
>
It's kinda mixed at the moment, I'm given a logger, I'm given a 
configuration, but I have to ask for a component?
I guess I got this wrong - isn't this distinction based on
the difference between compile time / runtime? My component
will use a logger and a configuration in any case, but maybe
it doesn't know which services it will need later on. When it
"requires" each other block it might want to use, wouldn't
this generate some overhead?
Thanks!
-- Andreas

Re: Strange behaviour from 2.1.5

[Antonio Gallardo]

Hi Jeremy:

I have another problem, but maybe it is related. I have a question. Are
you using subsitemaps? Can you explain how are distributed the .js files?

Best Regards,

Antonio Gallardo

Jeremy Quinn dijo:
> Hi All
>
> I just upgraded an existing project to 2.1.5 and am experiencing some
> strange problems with FlowScript.
>
> I am seeing a lot of these errors:
>
> org.apache.avalon.framework.CascadingRuntimeException:
> "resource://org/apache/cocoon/forms/flow/javascript/Form.js", line 203:
> uncaught JavaScript exception: at handleForm
> (resource://org/apache/cocoon/forms/flow/javascript/Form.js, Line 203):
> "uploadImage" is not a function.
>
> These appear to be erroneous (it clearly IS a function and worked fine
> under previous versions), and nearly random in appearance (sometimes
> you get this sometimes you don't).
>
> The next problem I started seeing was errors related to instantiating
> Java Objects from Flow, where the flow engine would complain that the
> package paths were ambiguous. What was worse was that these messages
> would GO AWAY on reload !
>
> I suspect the new caching system (which throws exceptions on shutdown).
>
> I am using the Release version of Cocoon 2.1.5 (we always attempt to
> only use release versions for development and we have several people
> working on the same project at the same time, and that makes it far
> easier).
>
> Are there any known issues with 2.1.5 release that may be causing this
> behaviour ?
>
>
> Many thanks for any suggestions.
>
> regards Jeremy

Re: Strange behaviour from 2.1.5

[Andreas Schmid]

I know that this will not fix the "bug". But we've postet this bug 2 
Days ago and till now there is no answer. So we needed to make a 
workaround to  continue working.
What i did was just telling you who to do a workaround...
:-)

CYA
Andreas
Jeremy Quinn wrote:
On 3 Jun 2004, at 11:53, Andreas Schmid wrote:
Just try to declare your variables as globals outside the functions.
This should help that the JavaFlow willl Work...

Many thanks for your reply, but I cannot see how this will solve the 
problem.
These are flowscripts that are known to work (in 2.1.4 and eventually 
in 2.1.5).

The functionality of the scripts does not require nor want global 
variables.

regards Jeremy
Jeremy Quinn wrote:
Hi All
I just upgraded an existing project to 2.1.5 and am experiencing 
some strange problems with FlowScript.

I am seeing a lot of these errors:
org.apache.avalon.framework.CascadingRuntimeException: 
"resource://org/apache/cocoon/forms/flow/javascript/Form.js", line 
203: uncaught JavaScript exception: at handleForm 
(resource://org/apache/cocoon/forms/flow/javascript/Form.js, Line 
203): "uploadImage" is not a function.

These appear to be erroneous (it clearly IS a function and worked 
fine under previous versions), and nearly random in appearance 
(sometimes you get this sometimes you don't).

The next problem I started seeing was errors related to 
instantiating Java Objects from Flow, where the flow engine would 
complain that the package paths were ambiguous. What was worse was 
that these messages would GO AWAY on reload !

I suspect the new caching system (which throws exceptions on shutdown).
I am using the Release version of Cocoon 2.1.5 (we always attempt to 
only use release versions for development and we have several people 
working on the same project at the same time, and that makes it far 
easier).

Are there any known issues with 2.1.5 release that may be causing 
this behaviour ?

Many thanks for any suggestions.
regards Jeremy

Re: Strange behaviour from 2.1.5

[Jeremy Quinn]

On 3 Jun 2004, at 11:53, Andreas Schmid wrote:
Just try to declare your variables as globals outside the functions.
This should help that the JavaFlow willl Work...
Many thanks for your reply, but I cannot see how this will solve the 
problem.
These are flowscripts that are known to work (in 2.1.4 and eventually 
in 2.1.5).

The functionality of the scripts does not require nor want global 
variables.

regards Jeremy
Jeremy Quinn wrote:
Hi All
I just upgraded an existing project to 2.1.5 and am experiencing some 
strange problems with FlowScript.

I am seeing a lot of these errors:
org.apache.avalon.framework.CascadingRuntimeException: 
"resource://org/apache/cocoon/forms/flow/javascript/Form.js", line 
203: uncaught JavaScript exception: at handleForm 
(resource://org/apache/cocoon/forms/flow/javascript/Form.js, Line 
203): "uploadImage" is not a function.

These appear to be erroneous (it clearly IS a function and worked 
fine under previous versions), and nearly random in appearance 
(sometimes you get this sometimes you don't).

The next problem I started seeing was errors related to instantiating 
Java Objects from Flow, where the flow engine would complain that the 
package paths were ambiguous. What was worse was that these messages 
would GO AWAY on reload !

I suspect the new caching system (which throws exceptions on 
shutdown).

I am using the Release version of Cocoon 2.1.5 (we always attempt to 
only use release versions for development and we have several people 
working on the same project at the same time, and that makes it far 
easier).

Are there any known issues with 2.1.5 release that may be causing 
this behaviour ?

Many thanks for any suggestions.
regards Jeremy



smime.p7s
Description: S/MIME cryptographic signature

Re: Strange behaviour from 2.1.5

[Andreas Schmid]

Just try to declare your variables as globals outside the functions.
This should help that the JavaFlow willl Work...
Jeremy Quinn wrote:
Hi All
I just upgraded an existing project to 2.1.5 and am experiencing some 
strange problems with FlowScript.

I am seeing a lot of these errors:
org.apache.avalon.framework.CascadingRuntimeException: 
"resource://org/apache/cocoon/forms/flow/javascript/Form.js", line 
203: uncaught JavaScript exception: at handleForm 
(resource://org/apache/cocoon/forms/flow/javascript/Form.js, Line 
203): "uploadImage" is not a function.

These appear to be erroneous (it clearly IS a function and worked fine 
under previous versions), and nearly random in appearance (sometimes 
you get this sometimes you don't).

The next problem I started seeing was errors related to instantiating 
Java Objects from Flow, where the flow engine would complain that the 
package paths were ambiguous. What was worse was that these messages 
would GO AWAY on reload !

I suspect the new caching system (which throws exceptions on shutdown).
I am using the Release version of Cocoon 2.1.5 (we always attempt to 
only use release versions for development and we have several people 
working on the same project at the same time, and that makes it far 
easier).

Are there any known issues with 2.1.5 release that may be causing this 
behaviour ?

Many thanks for any suggestions.
regards Jeremy

Re: DO NOT REPLY [Bug 27249] - disposed ComponentLocator exception (when sitemap has timestamp in the future?)

[Bertrand Delacretaz]

Le 3 juin 04, à 11:45, Sylvain Wallez a écrit :
The ultimate source of information is  
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/ 
cocoon/components/treeprocessor/

And it's not there :-(
So I've been running a placebo system in the last week - I like it ;-)
-Bertrand

Re: [RT] Cocoon component container and excalibur

[Pier Fumagalli]

On 3 Jun 2004, at 07:30, Gianugo Rabellino wrote:
Anyway, the thing is we are considering moving towards a container 
that doesn't follow even Framework's specs. But in that case, be 
assured that there will be some kind of compatibility.
On 3 Jun 2004, at 07:40, Carsten Ziegeler wrote:
I don't want to freak out again but if you look at the discussions
about the block implementations, there were a lot of discussions
to also remove the framework api from the block system. So if you
want to use the benefit of blocks, you can't use the avalon
framework api for your components. And I still think this is bad.
There are some core problems with the Avalon APIs which are orthogonal 
to blocks deployment...

As a first, all selections are based on real-java-objects (tell me how 
to "require" a block that has no components, like a Forrest Skin and 
I'll be happy).

Second of all (but I think this is solvable) component selection is 
kinda weird and goes totally against the IOC principles.

A block should require another block, it should not by any means 
"select" a block as we do now with component selectors)...

It's kinda mixed at the moment, I'm given a logger, I'm given a 
configuration, but I have to ask for a component?

Cocoon did a _VERY_ good job in implementing component selection by 
extending the ECM itself and having all its blocks to be given things 
(I'm given a SourceResolver, from a Generator point of view), but if 
you take one step back, well...

And (of course) this is related to the second problem I outlined in my 
longish email before...

The Cocoon approach can be used in the new framework, and we can have 
Cocoon itself (only central point knowing what's going on both in 
Avalon and Kernel) to merge those two worlds and make them work 
together...

And, Carsten, I too still think it's bad if we don't somehow reuse all 
that code that we have out there built on Avalon... I don't like to 
re-write stuff when it's not absolutely needed...

Pier



smime.p7s
Description: S/MIME cryptographic signature

Strange behaviour from 2.1.5

[Jeremy Quinn]

Hi All
I just upgraded an existing project to 2.1.5 and am experiencing some 
strange problems with FlowScript.

I am seeing a lot of these errors:
org.apache.avalon.framework.CascadingRuntimeException: 
"resource://org/apache/cocoon/forms/flow/javascript/Form.js", line 203: 
uncaught JavaScript exception: at handleForm 
(resource://org/apache/cocoon/forms/flow/javascript/Form.js, Line 203): 
"uploadImage" is not a function.

These appear to be erroneous (it clearly IS a function and worked fine 
under previous versions), and nearly random in appearance (sometimes 
you get this sometimes you don't).

The next problem I started seeing was errors related to instantiating 
Java Objects from Flow, where the flow engine would complain that the 
package paths were ambiguous. What was worse was that these messages 
would GO AWAY on reload !

I suspect the new caching system (which throws exceptions on shutdown).
I am using the Release version of Cocoon 2.1.5 (we always attempt to 
only use release versions for development and we have several people 
working on the same project at the same time, and that makes it far 
easier).

Are there any known issues with 2.1.5 release that may be causing this 
behaviour ?

Many thanks for any suggestions.
regards Jeremy

smime.p7s
Description: S/MIME cryptographic signature

Re: DO NOT REPLY [Bug 27249] - disposed ComponentLocator exception (when sitemap has timestamp in the future?)

[Sylvain Wallez]

[EMAIL PROTECTED] wrote:
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=27249
disposed ComponentLocator exception (when sitemap has timestamp in the future?)
--- Additional Comments From [EMAIL PROTECTED]  2004-06-03 08:34 ---
huh? I've been working for the last week with HEAD and haven't seen the bug
anymore, on a setup where it was often visible before.
What, placebo effect on code??
If you tell me where to look I can check if I have your corrected code or not.
 

The ultimate source of information is 
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/

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

Re: [RT] Cocoon component container and excalibur

[Pier Fumagalli]

As I'm one of the people who did pick up the "container challenge" 
(twice now, first with Avalon, and now with my take on the Cocoon 
Kernel), I ought to give an answer...

There are two core problems that "real blocks" are trying to solve, and 
both of them are not rocket science.

The first problem is to define a structure for blocks, so that 
"agglomerates" of code and/or resources could be accessed not by their 
operational aspect, but by an abstraction of their functionality.

The second is to allow each single block to be hot-deployed and 
hot-swapped in a container (and this is, right now, the whole big can 
of worms).


Issue 1: block structures
-
Let's start with defining what kinds of block we can have: Interface 
and Implementation blocks.

Interface blocks are much like interfaces in Java: no code, only a 
skeleton of the functional aspects of all its implementations.

An example of an interface block might be (for example) the "Forrest 
Skin" block. This block might be empty, but in itself define that any 
block implementing it must contain one (or more) resources which can be 
used by Forrest to represent a skin (for example an implementation of 
this interface should contain the XSLT for rendering pages, the 
furniture images to put on pages, and so on and so forth).

Another example of interface block might be the "Generator" block. This 
block should contain the o.a.c.g.Generator interface, and by virtue of 
its definition, components generated by this block must implement the 
given interface.

So, for example, the FileGenerator block will return instances of 
o.a.c.g.FileGenerator which by itself, implements the o.a.c.g.Generator 
interface...

Not much new here, right now we rely on java interfaces to do this, we 
simply add another layer on top of this one by introducing formal block 
definitions which can be parsed and processed and allow us to take the 
concept of "interfaces" one step further: interface blocks can 
represent (as in Java) code components, or (as in the case of the 
"Forrest Skin" block) collections of resources following a certain 
standard, or a combination of both...

Easy... It works already on the kernel I wrote, and it's quite a nice 
concept (I'm using the kernel in another application, and it's pretty 
funky once you get used to it! :-P)


Issue 2: Hot deployment
---
The second issue that "real blocks" trying to solve is hot swapping and 
deployment. What does it mean? Quite simple: if (for example) I want to 
change the look-and-feel of my Forrest-generated site, I can "rewire" 
the implementation of the "Forrest Skin" block to another 
implementation, and VOILA`, my site changes...

And this should be done live, while Cocoon is running.
Now, it's pretty easy to do this when we're talking about resources 
(XSLTs and so on) as they don't impact the ClassLoader, but how can we 
do it when we're talking about code?

For example, how can we replace (at runtime) Xalan with SAXON? Or how 
can we upgrade FOP from 1.2.3 to 1.2.4 without shutting down the whole 
of Cocoon?

Again the problem is quite simple, by designing the stack of class 
loaders correctly (and not having the whole shabang to use one class 
loader), and by using proxy "Wire" instances to manage components 
between blocks.

Separate class loaders allow us to reload code, proxy instances allow 
us to "isolate" wired blocks from one another so that when a block is 
reloaded, a new wire can be independently created and there are no 
object references lying around preventing us to garbage collect stuff.


The problems

Now, this all seems quite simple, and partly it is already implemented 
on the kernel I wrote.

Now, the problem lies in the fact that before declaring the kernel as 
"stable" I wanted to use it for one internal project here at VNU.

Our backend is built entirely on the kernel, it is made up of roughly 
20-or-so blocks, but during its development I faced one major issue 
that right now I address as "blocker".

I'm talking about event handling: basically, events always require a 
two-way linking in the kernel: the event listener must register itself 
in the event dispatcher, and the event dispatcher must have an instance 
of the listener to send events

The problem lies when either the listener or the dispatcher gets 
reloaded... In theory when this happens the registration should be 
re-performed, and the old one interrupted, but this would involve 
having blocks to listen to kernel events themselves, and blocks to be 
notified of reloads, destructions and so on and so forth... A MESS

I want to try to solve this problem before calling the kernel API 
stable (at least from my point of view), and hopefully I'll have some 
time to think about it next week while on vacation...

There is another non trivial problem, which is related to component 
selection. This is more tied to Cocoon itself, as I can't find any 
other case in wh

Re: [heads up] PMC chair nominations

[Pier Fumagalli]

On 3 Jun 2004, at 08:48, Gianugo Rabellino wrote:
On Jun 3, 2004, at 9:30 AM, Bertrand Delacretaz wrote:
Le 3 juin 04, à 09:18, Steven Noels a écrit :
...I'll start the vote tomorrow, as the list of volunteers seems to 
be stabilizing. Would candidates mind if this is a public vote? 
Also, I'd like the vote to be held on the users list as well - to 
raise the level of their awareness of Cocoon community matters
+1 for public vote (although I'm not a candidate)
+1 for having it on users as well, let's be open!
(but IIUC only committers votes are binding)
Actually I think only PMC members votes are binding. Just to reassure 
our fellow readers that there is no hidden/restricted committee: every 
committer *can* be a PMC member but it's up to the single person to 
decide whether to take this (very light) burden or not. Since we don't 
have as many PMC members as committers (for one, most emeritus people 
didn't ask to be part of it), I just wanted to be a bit nitpicking on 
that. :)
You're correct... And by the way, I'm not on the PMC (so don't count 
me) :-P

	Pier


smime.p7s
Description: S/MIME cryptographic signature

DO NOT REPLY [Bug 27249] - disposed ComponentLocator exception (when sitemap has timestamp in the future?)

[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=27249

disposed ComponentLocator exception (when sitemap has timestamp in the future?)





--- Additional Comments From [EMAIL PROTECTED]  2004-06-03 08:56 ---
Indeed I wondered there was no CVS commit message, when Sylvain closed the bug.
I thought it will come soon - and forgot about it.

RE: [RT] Cocoon component container and excalibur

[Antonio Gallardo]

Carsten Ziegeler dijo:
> Sylvain Wallez wrote:
>>
>> You have to consider two very different things:
>> - the Avalon framework APIs (LogEnabled, Serviceable,
>> Configurable, etc.)
>> - the container that implements the framework behaviour
>>
>> Although the container implementation may change, there's a
>> strong commitment to the framework APIs as this is what we've
>> used and invested in for many years.
>>
>> So even if a new container comes with new features (e.g. IOC
>> type 2/3), it will also have to implement the Avalon
>> framework behaviour. We cannot trash years of use of this API
>> overnight.
>>
> I don't want to freak out again but if you look at the discussions
> about the block implementations, there were a lot of discussions
> to also remove the framework api from the block system. So if you
> want to use the benefit of blocks, you can't use the avalon
> framework api for your components. And I still think this is bad.
>
> Anyways, if for example we would move to Fortress (without using
> the meta-info stuff and keeping our current configuration files
> which is possible!) we could add own lifecycle interfaces over
> time and provide a smooth migration path to whatever comes with
> blocks.

Thanks Carsten, this exactly what I remember. It moves me to write the RT.
This seems to be still not cleared. BTW, sorry for start the same again.
;) I think it is time to make some decisions. The development stall if we
don't decide how to go and the clock is ticking.

I wanted to include in the RT a question about Excalibur, as Gianugo said,
Excalibur is a TLP now and ask if is worth to collaborate there while we
(Cocoon) are switching out of it.

This are the things that disturb me now.

Best Regards,

Antonio Gallardo

Re: PMC chair vote (was Re: [heads up] PMC chair nominations)

[Sylvain Wallez]

Matthew Langham wrote:
Ok, assuming no-one else wants to nominate, I guess we should 
move to a vote now.
   

I guess everyone is confused now :-). 

It looks like Andrew and Steven's mails crossed in flight and I would
suggest we go with Steven's suggestion and start a fresh vote based on the
current confirmed nominee list tomorrow.
 

+1 :-)
STOP VOTING NOW! And wait for Steven to start it tomorrow.
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

DO NOT REPLY [Bug 27249] - disposed ComponentLocator exception (when sitemap has timestamp in the future?)

[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=27249

disposed ComponentLocator exception (when sitemap has timestamp in the future?)





--- Additional Comments From [EMAIL PROTECTED]  2004-06-03 08:34 ---
huh? I've been working for the last week with HEAD and haven't seen the bug
anymore, on a setup where it was often visible before.

What, placebo effect on code??

If you tell me where to look I can check if I have your corrected code or not.

DO NOT REPLY [Bug 27249] - disposed ComponentLocator exception (when sitemap has timestamp in the future?)

[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=27249

disposed ComponentLocator exception (when sitemap has timestamp in the future?)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2004-06-03 08:23 ---
Just found that the commit didn't went through when I closed the bug (may have
not paid attention to some CVS error message)

And inbetween there were *lots* of changes in the pipeline processing. This
means I have to do the work again.

:-

Re: PMC chair vote (was Re: [heads up] PMC chair nominations)

[Ugo Cei]

Andrew Savory wrote:
Here is my +1 for Sylvain. Please vote!
+1 for Sylvain too.
	Ugo

FirstFriday coming up!

[Bertrand Delacretaz]

Hi Cocoonistas,
Tomorrow is FirstFriday [1], and the cross-posting is intentional: you 
don't necessarily need to be a committer to participate, there are 
plenty of bugs and patches waiting for our collective squashing and 
patching [2].

See you there! (on and off tomorrow for me)
[1] http://wiki.cocoondev.org/Wiki.jsp?page=FirstFriday
[2] http://wiki.cocoondev.org/Wiki.jsp?page=ProjectManagement
-Bertrand

RE: PMC chair vote (was Re: [heads up] PMC chair nominations)

[Matthew Langham]

> Ok, assuming no-one else wants to nominate, I guess we should 
> move to a vote now.
> 

I guess everyone is confused now :-). 

It looks like Andrew and Steven's mails crossed in flight and I would
suggest we go with Steven's suggestion and start a fresh vote based on the
current confirmed nominee list tomorrow.

Matthew

Re: [heads up] PMC chair nominations

[Gianugo Rabellino]

On Jun 3, 2004, at 9:30 AM, Bertrand Delacretaz wrote:
Le 3 juin 04, à 09:18, Steven Noels a écrit :
...I'll start the vote tomorrow, as the list of volunteers seems to 
be stabilizing. Would candidates mind if this is a public vote? Also, 
I'd like the vote to be held on the users list as well - to raise the 
level of their awareness of Cocoon community matters
+1 for public vote (although I'm not a candidate)
+1 for having it on users as well, let's be open!
(but IIUC only committers votes are binding)
Actually I think only PMC members votes are binding. Just to reassure 
our fellow readers that there is no hidden/restricted committee: every 
committer *can* be a PMC member but it's up to the single person to 
decide whether to take this (very light) burden or not. Since we don't 
have as many PMC members as committers (for one, most emeritus people 
didn't ask to be part of it), I just wanted to be a bit nitpicking on 
that. :)

Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com

Re: [RT] Cocoon component container and excalibur

[Sylvain Wallez]

Carsten Ziegeler wrote:
Sylvain Wallez wrote:
 

You have to consider two very different things:
- the Avalon framework APIs (LogEnabled, Serviceable, 
Configurable, etc.)
- the container that implements the framework behaviour

Although the container implementation may change, there's a 
strong commitment to the framework APIs as this is what we've 
used and invested in for many years.

So even if a new container comes with new features (e.g. IOC 
type 2/3), it will also have to implement the Avalon 
framework behaviour. We cannot trash years of use of this API 
overnight.
   

I don't want to freak out again but if you look at the discussions
about the block implementations, there were a lot of discussions
to also remove the framework api from the block system. So if you
want to use the benefit of blocks, you can't use the avalon
framework api for your components. And I still think this is bad.
 

I definitely think we'll find a bridge between them, e.g. 
manager.lookup("block:block-name:org.apache.cocoon.Role");

Anyways, if for example we would move to Fortress (without using
the meta-info stuff and keeping our current configuration files
which is possible!) we could add own lifecycle interfaces over
time and provide a smooth migration path to whatever comes with
blocks.
 

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

Re: [heads up] PMC chair nominations

[Bertrand Delacretaz]

Le 3 juin 04, à 09:18, Steven Noels a écrit :
...I'll start the vote tomorrow, as the list of volunteers seems to be 
stabilizing. Would candidates mind if this is a public vote? Also, I'd 
like the vote to be held on the users list as well - to raise the 
level of their awareness of Cocoon community matters
+1 for public vote (although I'm not a candidate)
+1 for having it on users as well, let's be open!
(but IIUC only committers votes are binding)
-Bertrand

PMC chair vote (was Re: [heads up] PMC chair nominations)

[Andrew Savory]

Hi,
Ok, assuming no-one else wants to nominate, I guess we should move to a 
vote now.

So, here are the nominees:
 - Vadim Gritsenko
 - Sylvain Wallez
 - Matthew Langham
 - Andrew Savory
We already have the following votes for Sylvain:
+1 from Pier
+1 from Gianugo
+1 from Matthew
+1 from Antonio
+1 from Betrand
Here is my +1 for Sylvain. Please vote!
Andrew.
--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658  Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Orixo alliance: http://www.orixo.com/


smime.p7s
Description: S/MIME cryptographic signature

Re: [RT] Cocoon component container and excalibur

[Bertrand Delacretaz]

Le 3 juin 04, à 09:22, Antonio Gallardo a écrit :
...Yep. I told switch, because it was not clear if all of us will 
accept to
drop the Rhino merge effort...
Is anybody actually working on this merge?
(apart from the work done on clearing out the licensing issues)
As "he who does the work decides", if no one's working on it the 
decision is easy ;-)

-Bertrand

Re: [RT] Cocoon component container and excalibur

[Antonio Gallardo]

Steven Noels dijo:
> On 03 Jun 2004, at 08:41, Antonio Gallardo wrote:
>
>> Yep. The Sylvain idea sound great! Can we switch the Rhino merge for
>> this
>> new task?
>
> Do you mean 'drop' instead of 'switch'?

Yep. I told switch, because it was not clear if all of us will accept to
drop the Rhino merge effort.

> I'm all +1 for continuing on the research path of
> webcontinuations. If Java continuations have a more stable foundation
> to build upon, we shouldn't waste our precious effort in trying to
> salvage the Rhino+cont fork.

OK.

Best Regards,

Antonio Gallardo

Re: [heads up] PMC chair nominations

[Steven Noels]

On 01 Jun 2004, at 14:55, Antonio Gallardo wrote:
The decision will be a hard one. All candidates are great! ;-)
I'll start the vote tomorrow, as the list of volunteers seems to be 
stabilizing. Would candidates mind if this is a public vote? Also, I'd 
like the vote to be held on the users list as well - to raise the level 
of their awareness of Cocoon community matters.

Cheers,

--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java & XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

Re: [RT] Cocoon component container and excalibur

[Antonio Gallardo]

Bertrand Delacretaz dijo:
> Le 3 juin 04, à 08:41, Antonio Gallardo a écrit :
>
>> ...Yep. The Sylvain idea sound great! Can we switch the Rhino merge
>> for this
>> new task?
>
> Well, if you have the resources I'd say: go for it!

I don't have the resources right now. :(

But, since it is a very important issue, I think we remove the "Rhino
merge task" in favour of Sylvain idea!

Hmm... there will be a lot to be learn.

Best Regards,

Antonio Gallardo

Re: [RT] Cocoon component container and excalibur

[Steven Noels]

On 03 Jun 2004, at 08:41, Antonio Gallardo wrote:
Yep. The Sylvain idea sound great! Can we switch the Rhino merge for 
this
new task?
Do you mean 'drop' instead of 'switch'?
I'm all +1 for continuing on the research path of 
webcontinuations. If Java continuations have a more stable foundation 
to build upon, we shouldn't waste our precious effort in trying to 
salvage the Rhino+cont fork.


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java & XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

Re: [RT] Cocoon component container and excalibur

[Bertrand Delacretaz]

Le 3 juin 04, à 08:41, Antonio Gallardo a écrit :
...Yep. The Sylvain idea sound great! Can we switch the Rhino merge 
for this
new task?
Well, if you have the resources I'd say: go for it!
-Bertrand