Re: cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/ cocoon/caching/impl StoreEventRegistryImpl.java DefaultEventRegistryImpl. java

[Geoff Howard]

Ralph Goers wrote:

Geoff,

From what I can see, it looks like the eventcache is just what I need.  We
have data in LDAP that is converted by generators into XML. I only want to
do that when the data in LDAP changes. We manage that by having the wrapper
around LDAP publish to a JMS topic when changes are made and the wrapper
also listens.  I have a Cocoon component that manages our access to LDAP via
the wrapper and it listens for these events.  I envision having my component
generate the events that invalidate the cache. 
 

Really your component would translate the JMS messages to the Event and 
handle the contact with the EventCacheImpl.  Depending on the complexity 
of that translation, you could be able to use the JMSEventListener 
already in the jms block as is.  Otherwise, it's pretty simple to 
implement fresh.

Two questions.
1. Is eventcache stable enough for me to use or will it be undergoing
radical changes?
 

That's a good question.  It's still marked alpha/stable/whatever but 
that is more by inaction than purposeful decision (at least on my 
part).  Of course it's up to the larger community but it's been mostly 
Unico and myself that have worked on it.  Practically, I'd feel more 
comfortable having heard from more people who have used it before 
locking it down - so your use could contribute to its stability. 

Having said that, it's a simple API and shouldn't need much tweaking.  
In fact, the part of the API you would rely on is two _very_ simple 
interfaces (Event and EventAware).  The only thing I ever imagined 
affecting that is a feature I envisioned originally ("wildcard" events) 
but which never came to pass.  I have since wondered whether they would 
be all that useful and now feel they could probably be implemented in a 
back-compatible way anyway.  Originally I was questioning the use of Map 
based hash lookup for events because that would (probably) not support 
wildcards. 

Maybe we should consider marking the block "stable"?

2. From the vague description I have given does this sound like a "proper"
usage of eventcache?
 

Yes, it sounds spot on.

Geoff

-Original Message-
From: 	Geoff Howard [mailto:[EMAIL PROTECTED] 
Sent:	Friday, February 27, 2004 9:49 AM
To:	[EMAIL PROTECTED]
Subject:	Re: cvs commit:
cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl
StoreEventRegistryImpl.java DefaultEventRegistryImpl.java

FYI I recently re-started making the StoreEventReg default, renaming 
DefaultEventReg, refactoring inheritance a little (pulled out an 
AbstractEventRegistry which both inherit from) etc.   It's quite 
unfinished and I have close to no time right now for "play" but just 
wanted to give you a heads up that I have some refactor work going on.  
Next chance I get, I'll try to get it in a working state and either 
commit it or pass it on as a patch for someone else to pick up.  I'd 
like to close the open bug about the serialized data location not being 
configurable but couldn't stand to hack in configuration when we've 
already agreed that some refactoring was needed.

Don't quite get what was wrong before this commit by the way.  Was this 
throwing an NPE all this time? (don't think so...)

Geoff



 

Re: Update to batik 1.5.1

[Antonio Gallardo]

Hi Carlos:

We know that. :-D

Best Regards,

Antonio Gallardo.

Carlos Araya dijo:
> Antonio:
>
> Before you go updating the libraries, realize that FOP on Cocoon's CVS
> depends on a specific version of Batik... PLEASE, please don't update
> without knowing what the dependencies are.
>
> Carlos
>
> - Original Message -
> From: "Antonio Gallardo" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, February 27, 2004 16:09
> Subject: Update to batik 1.5.1
>
>
>> Hi:
>>
>> Batik 1.5.1 was released on feb, 20th. I don't have idea how to update
>> this lib. Please help. :-D
>>
>> Best Regards,
>>
>> Antonio Gallardo
>>
>

Re: Update to batik 1.5.1

[Carlos Araya]

Antonio:

Before you go updating the libraries, realize that FOP on Cocoon's CVS
depends on a specific version of Batik... PLEASE, please don't update
without knowing what the dependencies are.

Carlos

- Original Message - 
From: "Antonio Gallardo" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 27, 2004 16:09
Subject: Update to batik 1.5.1


> Hi:
>
> Batik 1.5.1 was released on feb, 20th. I don't have idea how to update
> this lib. Please help. :-D
>
> Best Regards,
>
> Antonio Gallardo
>

Update to util.concurrent 1.3.3

[Antonio Gallardo]

Hi:

Another needed to be updated is util.concurrent:

http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html

Please help.

Best Regards,

Antonio Gallardo

Update to batik 1.5.1

[Antonio Gallardo]

Hi:

Batik 1.5.1 was released on feb, 20th. I don't have idea how to update
this lib. Please help. :-D

Best Regards,

Antonio Gallardo

[JXTemplate] weird problem w/ formatDate

[Mark Lundquist]

Hi,

(I'm using Cocoon 2.1.3...)

I have something like this in a JXTemplate:



and it barfs:

Cannot format given Object as a Date

But if I change the template to



...then I get this:

Fri Feb 27 15:47:51 PST 2004

!!?!?!?!  Clearly this is a Java Date object...

Not only that, but...

There are a number of places where dates have to display on this page.  I don't have a real model yet, so for right now I'm just prototyping the "VC" of my "MVC" :-), using flow and JXTemplate, with mockup data hardcoded in the flowscript.  So anyway — currently all the date objects that get passed in (via the context object passed to sendPageAndWait) are the identical object. In the flowscript:

var now = new Packages.java.util.Date();

So they're all 'now' (once again, intentionally), but some of the 'nows' JXTemplate chokes on, and some of them it's fine!

So... here's what I tried next:

1) Created my own Java.text.DateFormat object in the flowscript, and used it to format all my dates there
2) Changed the JXTemplate to use  to interpolate all my date displays, since they are now strings at this point.

The result: nice dates, no problem.

Mark

RE: cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/ cocoon/caching/impl StoreEventRegistryImpl.java DefaultEventRegistryImpl. java

[Ralph Goers]

Geoff,

>From what I can see, it looks like the eventcache is just what I need.  We
have data in LDAP that is converted by generators into XML. I only want to
do that when the data in LDAP changes. We manage that by having the wrapper
around LDAP publish to a JMS topic when changes are made and the wrapper
also listens.  I have a Cocoon component that manages our access to LDAP via
the wrapper and it listens for these events.  I envision having my component
generate the events that invalidate the cache. 

Two questions.
1. Is eventcache stable enough for me to use or will it be undergoing
radical changes?
2. From the vague description I have given does this sound like a "proper"
usage of eventcache?

Thanks,
Ralph


 -Original Message-
From:   Geoff Howard [mailto:[EMAIL PROTECTED] 
Sent:   Friday, February 27, 2004 9:49 AM
To: [EMAIL PROTECTED]
Subject:Re: cvs commit:
cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl
StoreEventRegistryImpl.java DefaultEventRegistryImpl.java


FYI I recently re-started making the StoreEventReg default, renaming 
DefaultEventReg, refactoring inheritance a little (pulled out an 
AbstractEventRegistry which both inherit from) etc.   It's quite 
unfinished and I have close to no time right now for "play" but just 
wanted to give you a heads up that I have some refactor work going on.  
Next chance I get, I'll try to get it in a working state and either 
commit it or pass it on as a patch for someone else to pick up.  I'd 
like to close the open bug about the serialized data location not being 
configurable but couldn't stand to hack in configuration when we've 
already agreed that some refactoring was needed.

Don't quite get what was wrong before this commit by the way.  Was this 
throwing an NPE all this time? (don't think so...)

Geoff

Re: cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl StoreEventRegistryImpl.java DefaultEventRegistryImpl.java

[Vadim Gritsenko]

Unico Hommes wrote:

Geoff Howard wrote:

[EMAIL PROTECTED] wrote:

unico   2004/02/27 09:27:04

 Modified:src/blocks/eventcache/java/org/apache/cocoon/caching/impl
   StoreEventRegistryImpl.java
   DefaultEventRegistryImpl.java
 Log:
 fix NPE on first use  


FYI I recently re-started making the StoreEventReg default, renaming 
DefaultEventReg, refactoring inheritance a little (pulled out an 
AbstractEventRegistry which both inherit from) etc.   It's quite 
unfinished and I have close to no time right now for "play" but just 
wanted to give you a heads up that I have some refactor work going 
on.  Next chance I get, I'll try to get it in a working state and 
either commit it or pass it on as a patch for someone else to pick 
up.  I'd like to close the open bug about the serialized data 
location not being configurable but couldn't stand to hack in 
configuration when we've already agreed that some refactoring was 
needed.


Great, the bugzilla entry was also in the back of my mind. I've been 
using the current default registry in production sites until now but 
still had on my todo list to use the persistent store delegating one.

Can one of you guys kill tabs in those files while you are at it?

Vadim

Re: Flowscript and return to pipeline

[Sylvain Wallez]

Antonio Gallardo wrote:



AFAIK, in a webapp you can also review the authentication and authorization:


 
   
   
   
 
 ...


 
   
 
 
 
 

Uh? Don't you use continuations to handle login and automagically return 
the expected initial response when the user successfully authenticate?

Sylvain

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

Re: disabling widgets

[Sylvain Wallez]

Jeremy Quinn wrote:

On 25 Feb 2004, at 12:32, Reinhard Poetz wrote:



-Original Message-
From: Antonio Gallardo [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 25, 2004 1:28 PM
To: [EMAIL PROTECTED]
Subject: Re: disabling widgets
Jeremy Quinn dijo:

Hi All

I have a booleanfield widget, that needs to be disabled
under certain

conditions.

pseudo-code :

if ( album.scenarios.size() > 0 ) {
 disable ( album.publishable );
}
ie. the album.publishable value needs to be in the form, but should
not be alterable by the user.
Is there a way of doing this in Cocoon Forms ?


Another approach (not tested by me, but maybe works) is using
the JXTemplateGenerator. There is a  tag that can be
use to show/hide controls in the rendered page.


IIRC Sylvain extendet the showform function so that you can pass the
objects to the view layer. You could either use Antonio's suggestion or
you add a parameter to the widget styling.

Yep. Form.showForm has the same parameters as cocoon.sendPageAndWait(), 
as there's no reason not to be able to pass some additional application 
data to the view when using forms.

So what you are saying is this? :

1. add appropriate JX-Template conditional statement to my 
booleanfield widget
which will add @readonly="readonly" to the wi:styling if the 
condition is met
2. pass the required BizData to the showform method as required by 
the conditional above
3. use JX-Generator instead of the FileGenerator in my Woody 
pipeline to pre-process
my Woody-Template before it goes to the Woody Transformer


Or also, use the woody template implementation using JX macros sent by 
Christopher a while ago. I started using this approach this week, which 
I needed that for two purposes:
- display a "no items" text when a repeater is empty instead of an empty 
table with only headers,
- implement a very specific styling for an output widget: it contains 
the ID of a node in a tree, and I needed to display the path of this node.

Conclusion: *it rocks*! Being able to access the form model within the 
generator allows to very easily build sophisticated presentations for a 
form.

Sylvain

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

Re: disabling widgets

[Sylvain Wallez]

Antonio Gallardo wrote:

Reinhard Poetz dijo:
 

Sorry, I don't like this client-side approach.
We have to find something better because sometimes the 'presentation
state' of a widget can depend on the 'application state'. Flowscript as
controller should have access to both.
   

Hi Reinhard:

How manage a dynamic "show/hide a control" in a page without doing a
round-trip to the server?
Based on some observation while no-tech oriented users filled HTML forms.
It makes clear to me that they don't liked the round-trip to the server.
It was confusing to him! It is clear a non-conventional interface. Also it
waste time, no matter how fast the connection (including the server) are.
The observation was related to calculated widgets.
I think this is a similar case, because the show/hide control is just a
rendering page issue. Of course, you can add add additional parameters to
reflect the current "application state" and let the page have the right
behavior. If we suspect that it can be a security concerns, there is a
gold rule:
"Anything returned from the client must the checked again, when the
control return to the Flow (serversided)."
 

(jumping in late) I don't think it's *only* a rendering issue.

A colleague of mine recently asked me how to change widgets availability 
in a form depending on the user's role or application state such as when 
a form goes through different people and/or states in a workflow.

The purpose here isn't dynamic interaction within an interaction with a 
single user, but allow to "configure" the form before it is displayed to 
the user.

I came to 3 possible states for a widget:
- enabled: what we have today
- disabled: the widget behaves like an output and it doesn't read its 
value from the request (solves the "Anything returned..." below).
- hidden: the widget doesn't display itself.

A disabled composite widget (e.g. a repeater) doesn't call 
readFromRequest() on its children. Similarily, the woody transformer 
should take into account hidden composite widget references (e.g. 
 by ignoring their content.

WDYT?

Sylvain (first post from my Mac!!)

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

Re: [RT] Cocoon Input Model

[Alan]

* Bertrand Delacretaz <[EMAIL PROTECTED]> [2004-02-25 16:46]:
> Le Mercredi, 25 f?v 2004, ? 16:49 Europe/Zurich, Daniel Fagerstrom a 
> ?crit :
> 
> 
> 
> >...But in many cases using SAX based XML as in pipelines is not enough 
> >we need a data structure i.e. DOM. This leads to flowscript components 
> >that reads some input format to DOM and from DOM to some output format 
> >or some store. We also will need flowscript components that go from 
> >DOM to DOM...
> 
> Just trying to understand from a practical point of view, does this 
> mean something like
> 
> 
> 
> 
> 
> 
> At which point myFlow() is called with a "domIn" variable containing 
> the current pipeline XML as a DOM?
> 
> And maybe the opposite:
> 
> meaning that myFlow() is expected to write a DOM structure to domOut 
> for insertion in the pipeline?

(Note that I still have a lot to learn about sitemaps. My examples
might have some glaring conceptual errors.)

As long as we are talking in sitemap:



  

  

  

  
  


  
  


  
  

  




  


  
  
  


Now that I look at the above, I see that I really want to be able to
do something like this from within stylesheets.



-- 
Alan / [EMAIL PROTECTED] / http://engrm.com/
aim/yim: alanengrm - icq: 228631855 - msn: [EMAIL PROTECTED]

Re: [RT] Cocoon Input Model

[Alan]

* Daniel Fagerstrom <[EMAIL PROTECTED]> [2004-02-25 21:53]:
> Stefano Mazzocchi wrote:
> 
> >After a long silence, Daniel fights back :-) 
> 
> :)
> 
> >On Feb 25, 2004, at 10:49, Daniel Fagerstrom wrote:
> >
> >[snip very good summary]
> >
> >>To sumarize: I think that we could make Cocoon considerably easier to 
> >>use for (web)apps and increase reuse of components by using the 
> >>XML-adaptor and pipes and filter pattern for input as well.
> >
> >
> >There is, admittedly, a perception that cocoon is still somewhat 
> >unbalanced between input and output. CForms and flowscript show nice 
> >ways (easier than many other web technologies!) to deal with data 
> >round-tripping, but Daniel believes that we should do more, balancing 
> >the entire architecture so that what we can do with output, we can do 
> >with input.
> >
> >Now, I agree.
> >
> >I've been opposing the use of a common input adaptation stage because 
> >I thought it was bad from a performance perspective, but, I now 
> >believe that it's a very stupid point: early optimization is the root 
> >of all evil, especially in architectural design.
> >
> >[doesn't mean that you don't think about performance when you 
> >architect, but there are many levels of design]
> >
> >So, I'm happily removing the roadblock because I think we are reaching 
> >a point where this unbalance is hurting us (and potentially limiting 
> >the use of input to go thru cforms, which might be too much) 
> 
> Cool!
> 
> >[can we stop using the term 'woody' at least in RTs? this makes things 
> >easier for people reading archives a few years from now] 

> I used the term "Woody" when I talked about things that I hope that we 
> will replace when we move to CForms ;) The things that Bruno described 
> in his post 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104920680728548&w=2 as:
> 
> BTW, not using XML, XML validation, and XPath expressions as request
> parameter names is a conscious choice, so what I'm describing here is
> quite orthogonal to XMLForm, and leaning more towards
> FormValidatorAction.
> 
> >Ok, Daniel, the ball is in your court: tell us explicitly what you 
> >would propose we change in the sitemap/FOM/cforms, if anything. 
> 
> Ok, I will try to give an overview of my change proposals in prority order:
> 
> XML centric view on input
> -
> 
> The most important part is not a code change but rather a design 
> principle: Input handling is controlled from flowscripts, the flowscript 
> typically adapt various input sources to XML (DOM), possibly by using 
> pipelines described in the sitemap, it can validate the XML wrt to some 
> schema, and it adapts XML to various output and storage formats, 
> (possibly by using a pipeline). (If you are extremely unhappy about 
> flowscripts, you can replace the mentioned flowscripts with your 
> favourite script or programming language ;-) IMHO we should focus on 
> flowscripts however).

Might flowscript become less important if input pipelines where brought into
play?

You might have a validator element in the sitemap. If the document
validates accoriding to the validator the pipeline continues, if it fails,
an error pipeline executes that has validator error message output as a
starting point.

Once data is valid, you would then multiplex it into the various storage
devices, or XML consumers.

Once all the data is consumed, you fire off your output pipeline.

What little flow script I've played with, I'm usually just messing with
request parameters. If I could express this as a sitemap input pipeline, I
wouldn't bother.

> A bidirectional mapping between XML and a relational DB would be usefull.

I offered a unidirectional mapping in my previous post. Now that I think of
it, that is the big difference between what I have in mind and what I
normally see.


Data comes out of a RDBMS easily using SQL, a generator turns that into
XML, you then transform it to output. I've never seen the need for
bi-directional because for one direction at least, there is a perfect way
to preform the mapping. Express your desires in SQL. It is *always* a
table and therefore has an obvious representation in XML.

A bi-directional mapping will always produce a table as output anyway.

The trick is not getting the information out. Most RDBMS are SQL
databases and SQL is a *query* lanaguge.

Most people try to describe a bi-directional mapping and expect some
reward for this touble in (output) query generation. I'd rather describe
the database schema in an XML document, that is describe how I want the
data to go into the database, not how the database maps to an XML
document. There is a difference here.

> Components that store and read XML data from repositories would be usefull
> as well.

MomentoSource!

> CForms should use typed DOM as "form model"
> ---

> I 

Re: [RT] Cocoon Input Model

[Alan]

* Daniel Fagerstrom <[EMAIL PROTECTED]> [2004-02-25 15:49]:

> Why Cocoon rocks for publishing
> ---
> 
> Cocoon is based on three great ideas: XML-adaptors, XML-pipelines and 
> the sitemap. Here we will discuss the first two.
> 
> If you have N different input formats and M output formats you need N*M 
> converers for converting from every input format to every output format. 
> This complexity can be reduced to N+M by finding a standard format...

> Having a common format (XML) also makes it worthwhile to write tools 
> that use that format booth as input and output (e.g. XSLT), and we can 
> use the pipes and filter pattern to build complex transformations in 
> terms of smaller specialized, reusable filters.
> 
> 
> Dataflow in (web)apps
> -

> and for (web)apps:

> [Input format (user) -> Output format (storage)] -> webapp -> [Input 
> format (storage) -> Output format]

This is how I've built by LAMP applications. The first thing is to develop a
database. Then everything goes into the database before it comes back out.
Even if the application only keeps session data, I build a database. It is
a matter of course.

What other ways are there of handing data? Does anyone keep things in
memory, for simply regurgiate the input in their applications?

If so, then there are two pipeline designs, a input / output pipeline pair
and a pass-through pipeline. 

> As we can see publishing has one conversion step and (web)apps has two. 
> In [1] I talked about input and output pipelines for the two conversion 
> steps.

I'd like to expand on this, currently Cocoon treats storage as a filter.
Things like the SQLTransformer filter streams to store data then onward to
a serializer.

What you are proposing is a pipeline that that terminates not at a
serializer, but at something else, that somehow stores the XML. Then it
kicks off a new pipeline that terminates at a serializer.

To my mind, rather than have this parameter things in the site map, I'd much
rather have everything kept as XML.

Session information, for exmaple. I am going to use Momento to keep a
session document, and then skip that name/value pair nonsense. 

Somewhere in my CForms pipelines, I transform input into an XUpdate
statement and build a sub document in a Momento document. Then I can
aggregate or cinclude that session document.

> Comparing input and output pipelines, the input handling have one main 
> source of extra complexity: we cannot trust user input. We need to check 
> that the input is correct and take different action dependent on that, 
> so as a consequence control structure becomes more complicated when we 
> have user input.

> A further reason for detailed control of user input is that while the output
> tend go from strongly typed data (db:s, Java etc) to loosely typed data; in
> presentation most things are strings. Input tend to have the opposite
> requirement, from strings to typed data.

Okay, here is the strongly typed part of it, my apologies, I understand now.

Strongly typed data, but first...

Your solution is nice, except that it your N+M is missing something now.
There are N different input formats, M different output formats, and of
course, S different storage formats.

Consider a e-mail account user registration form, first page they tell us
who they are and choose a password. Second page, we ask them to choose
which junk newsletters they want to recieve.

When the information arrives and becomes XML. Now maybe I want to put the
XML in three different storage areas. Say I want to store the username and
password in an LDAP directory, the user's profile and such in an
relational database, and the fact that the user is now on the second page
of the registration wizzard as session information.

I think it is easy enough to validate and construct strongly typed data once
the input is an XML format. You can use XML Schema, Relax NG, and such to
validate information in the pipeline, then transform it to XUpdate or
ebXML, or SQL statements, to feed to an XML consumer.

For form input, CForms provides validation of form entries in a way that is
interactive and assoicates mistakes with the source widget in the
interface. If you were to offer a web service however, you would have to
have a way to validate XML that would return an error document of a
different nature, thus Relax NG, Schematron, etc. 

(You go on to say this yourself. Good. I'll snip it but I agree.)


> Is Cocoon that great for input handling?
> 
> 
> We see that the situation for input handling have become quite similar 
> to that for output: many input formats and many output formats. But in 
> contrast to the output scenario we have no common design patterns for 
> handling the complexity.

And this makes it very d

Re: PDF Encryption

[Torsten Curdt]

J.Pietschmann wrote:
Torsten Curdt wrote:

 From the FOP documentation I got the impression I could
pass them as shown in the wiki. But does that mean these [1]
are the only options besides fonts that are currently available?


Yes.
Hm...

Without diving into the fop codebase - is it much work to add?


How much is "much"? It would require hacking several files and
some reengineering of the tests whether encryption is available
which are currently in the CLI class. Given that encryption
has several major deficiencies in the maintenance branch code
and that the code is to be abandoned anyway, I don't think it
will be done.
That's more than exspected :-/ I hoped somehow passing the
parameters along would be sufficient.
Thanks for the clarification
--
Torsten

DO NOT REPLY [Bug 27302] New: - jena throws xml parse exception on tomcat startup

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=27302

jena throws xml parse exception on tomcat startup

   Summary: jena throws xml parse exception on tomcat startup
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: blocks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


i have the following when i start up cocoon in tomcat 4.1.27

i do not get the exception when starting with jetty.

java.io.FileNotFoundException
java.io.FileNotFoundException
at
org.apache.naming.resources.DirContextURLConnection.getInputStream(DirContextURLConnection.java:344)
at java.net.URL.openStream(URL.java:913)
at com.hp.hpl.deli.Workspace.getResource(Workspace.java:474)
at com.hp.hpl.deli.JenaProcessProfile.process(JenaProcessProfile.java:84)
at com.hp.hpl.deli.Profile.(Profile.java:51)
at com.hp.hpl.deli.CachedProfile.set(CachedProfile.java:36)
at com.hp.hpl.deli.ProfileCache.get(ProfileCache.java:69)
at com.hp.hpl.deli.Profile.(Profile.java:83)
at org.apache.cocoon.components.deli.DeliImpl.getProfile(DeliImpl.java:179)
at
org.apache.cocoon.components.deli.DeliImpl.getUACapabilities(DeliImpl.java:237)
at
org.apache.cocoon.transformation.DeliTransformer.getLogicSheetParameters(DeliTransformer.java:104)
at
org.apache.cocoon.transformation.TraxTransformer.getKey(TraxTransformer.java:352)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.generateCachingKey(AbstractCachingProc
essingPipeline.java:347)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessin
gPipeline.java:655)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:54
1)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.prepareInternal(AbstractProcessingPipeline.java:55
3)
at
org.apache.cocoon.components.source.impl.SitemapSource.init(SitemapSource.java:394)
at
org.apache.cocoon.components.source.impl.SitemapSource.(SitemapSource.java:258)
at
org.apache.cocoon.components.source.impl.SitemapSourceFactory.getSource(SitemapSourceFactory.java:99)
at
org.apache.excalibur.source.impl.SourceResolverImpl.resolveURI(SourceResolverImpl.java:247)
at
org.apache.cocoon.components.CocoonComponentManager.resolveURI(CocoonComponentManager.java:520)
at
org.apache.cocoon.components.CocoonComponentManager.resolveURI(CocoonComponentManager.java:520)
at
org.apache.cocoon.environment.AbstractEnvironment.resolveURI(AbstractEnvironment.java:566)
at
org.apache.cocoon.environment.AbstractEnvironment.resolveURI(AbstractEnvironment.java:553)
at
org.apache.cocoon.sitemap.ContentAggregator.setup(ContentAggregator.java:321)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:397)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessin
gPipeline.java:652)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:54
1)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:499)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:155)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.ja
va:107)
at
org.apache.cocoon.components.treeprocessor.ContainerNode.invoke(ContainerNode.java:66)
at
org.apache.cocoon.components.treeprocessor.sitemap.CallNode.invoke(CallNode.java:128)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.ja
va:84)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:165)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.ja
va:107)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:162)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.ja
va:107)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.j

Re: FOP with embeded SVG doesn't render at correct size in Cocoon

[J.Pietschmann]

Torsten Curdt wrote:
Can anyone tell me how the Cocoon fop and batik jar files are 
generated and how that is different from the jars supplied with FOP?
THere were some Cocoon releases which shipped with a different
Batik jar than the corresponding FOP release, partly due to
interface changes in Batik which forced FOP to use a CVS
snapshot. I don't know of the current state, but the latest
Batik was released after the latest FOP release, if Cocoon
grabbed the latest Batik jar, there are certainly some differences.
J.Pietschmann

Re: PDF Encryption

[J.Pietschmann]

Torsten Curdt wrote:
 From the FOP documentation I got the impression I could
pass them as shown in the wiki. But does that mean these [1]
are the only options besides fonts that are currently available?
Yes.

Without diving into the fop codebase - is it much work to add?
How much is "much"? It would require hacking several files and
some reengineering of the tests whether encryption is available
which are currently in the CLI class. Given that encryption
has several major deficiencies in the maintenance branch code
and that the code is to be abandoned anyway, I don't think it
will be done.
J.Pietschmann

Re: [RT] Cocoon Input Model

[Guido Casper]

Alan wrote:

What do you mean by strongly typed? Are we discussiong form posts
  here?
Yes, form posts being the use case at hand, but there are other ways 
input may be provided. Quoting Daniel:


Besides using request parameters and "structured" request parameters as 
user input. XML is used for WebDAV and web service applications, XML are 
also becoming more common from more advanced user clients. And with new 
environments like mail, CLI, JMS and possibly more, we will get even 
more user input formats.
<<<


I don't think of request parameters as strongly typed, they are all
strings, often they are html form encoded strings, but that's
does not include type information.
Yes request parameters are strings. But they are not always meant to be 
strings. If the user enters something in a field requesting a date you 
want to receive a date in your server app and don't care how it's 
encoded on the wire.

Guido

Re: FOP with embeded SVG doesn't render at correct size in Cocoon

[Torsten Curdt]

Same FOP version? Do you imply other Cocoon versions are working?
Nope, I'm implying FOP standalone with the same FOP version as Cocoon 
uses works correctly :^)
ok

It looks like when invoked through Cocoon FOP is still reserving the 
right amount of space (based on the svg with/height attributes) but then 
when Batik is invoked it is rendering the image at the incorrect 
scale(my guess?).

I tried dropping in the fop and batik jar files from Cocoon 2.1.4 and 
Cocoon still doesn't render the embedded SVG at large viewBox values 
correctly.
Could you try and use cocoon's fop version as you do with the standalone
version? That would be interesting...
Can anyone tell me how the Cocoon fop and batik jar files are generated 
and how that is different from the jars supplied with FOP?
At least I don't know about any difference... folks?

cheers
--
Torsten

Re: ASF Board Summary for February 18, 2004

[Torsten Curdt]

...so we are right back on track - let's get this unpleasant stuff
sorted out:
for java and text
--
/*
 * Copyright 1999-2004 The Apache Software Foundation. All rights reserved.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *  http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
 * implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
--
for XML
--

--
Regarding the start dates...
...maybe we could check where they need to be exact before we
decide here?
Although there is a perl script in the committers
module this does not look like it's a run-it-and-you-are-done
thing. Plus keeping this consistent in the future might be
a tedious task. Too bad there is no CVS substitution for this
For files other that code... does really every configuration
file or README etc have to have license? ...or only what we
think needs protection?
the NOTICE file
--
This product includes software developed by
The Apache Software Foundation (http://www.apache.org/).
It consists of voluntary contributions made by many individuals
on behalf of the Apache Software Foundation. Please visit the
project homepage (http://cocoon.apache.org) for more information.
Cocoon was originally created by Stefano Mazzocchi <[EMAIL PROTECTED]>.

...add more here
--
and we remove all the author tags :)

cheers
--
Torsten

Re: PDF Encryption

[Torsten Curdt]

J.Pietschmann wrote:
Torsten Curdt wrote:

But the way through the user config
file seems to fail. Maybe someone
else has an idea why?


I implemented only setting the renderer options from the
CLI. I don't think anybody added setting encryption options
(or any other non-font related renderer options beside PDF
filters) from the config file.
From the FOP documentation I got the impression I could
pass them as shown in the wiki. But does that mean these [1]
are the only options besides fonts that are currently available?
Without diving into the fop codebase - is it much work to add?

cheers
--
Torsten
[1] http://xml.apache.org/fop/configuration.html

Re: [Help]writing SAX Transformer

[J.Pietschmann]

roy huang wrote:
...
> 
> 
> a
> 
> 
> b
> 
> 
> c
> 
>  
> if I delete   using startRecording the source code turns into:
> 
> 
> 
> 
> 
> c
> 
> 
> left many blank and tab. How to solve it or I am in the wrong way?
The whitespace is already there in the source (look
carefully). I don't think it hurts, and deleting it
selectively is not all that easy.

> Question 2:
> in the transformer I also and some xinclude tag,like:
>attr.addAttribute(
> "http://www.w3.org/2001/XInclude";,
> "href",
> "href",
> "CDATA",
> flowUri);
>super.startTransformingElement("", "include", "xi:include", attr);
>super.endTransformingElement("", "include", "xi:include");
>attr.clear();
> the xml is fine,but can't be transform by XInclude transformer,

I think you missed the namespace for the xi:include element, but
added the href attribute in the namespace instead. Try
attr.addAttribute(
 "",
 "href",
 "href",
 "CDATA",
 flowUri);
super.startTransformingElement("http://www.w3.org/2001/XInclude";,
 "include", "xi:include", attr);
super.endTransformingElement("http://www.w3.org/2001/XInclude";,
 "include", "xi:include");
instead.
Dealing with namespaced elements and attributes in APIs is
tricky, study the topic carefully.

J.Pietschmann

Re: cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl StoreEventRegistryImpl.java DefaultEventRegistryImpl.java

[Unico Hommes]

Geoff Howard wrote:

[EMAIL PROTECTED] wrote:

unico   2004/02/27 09:27:04

 Modified:src/blocks/eventcache/java/org/apache/cocoon/caching/impl
   StoreEventRegistryImpl.java
   DefaultEventRegistryImpl.java
 Log:
 fix NPE on first use   

FYI I recently re-started making the StoreEventReg default, renaming 
DefaultEventReg, refactoring inheritance a little (pulled out an 
AbstractEventRegistry which both inherit from) etc.   It's quite 
unfinished and I have close to no time right now for "play" but just 
wanted to give you a heads up that I have some refactor work going 
on.  Next chance I get, I'll try to get it in a working state and 
either commit it or pass it on as a patch for someone else to pick 
up.  I'd like to close the open bug about the serialized data location 
not being configurable but couldn't stand to hack in configuration 
when we've already agreed that some refactoring was needed.
Great, the bugzilla entry was also in the back of my mind. I've been 
using the current default registry in production sites until now but 
still had on my todo list to use the persistent store delegating one.

Don't quite get what was wrong before this commit by the way.  Was 
this throwing an NPE all this time? (don't think so...)

Yes, the key map never got initialized.

Unico

Re: PDF Encryption

[J.Pietschmann]

Torsten Curdt wrote:
But the way through the user config
file seems to fail. Maybe someone
else has an idea why?
I implemented only setting the renderer options from the
CLI. I don't think anybody added setting encryption options
(or any other non-font related renderer options beside PDF
filters) from the config file.
J.Pietschmann

DO NOT REPLY [Bug 27301] New: - FilterTransformer: Generates not matching block tags

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=27301

FilterTransformer: Generates not matching block tags

   Summary: FilterTransformer: Generates not matching block tags
   Product: Cocoon 2
   Version: 2.1.4
  Platform: PC
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: sitemap components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


example: 
sitemap:   
  
 
 

   
  
   

test.xml:

http://apache.org/cocoon/include/1.0";>
  
  
  
  


output:


  http://apache.org/cocoon/include/1.0";>




  


I tracked the cause to:
org.apache.cocoon.transformation.FilterTransformer 1.3 Line 186-200
public void endElement(String uri,String name,String raw)
throws SAXException  {
if (this.foundIt && name.equals(this.parentName)) {
// FIXME: VG: This will fail on XML like:
// 
//   
// 
super.contentHandler.endElement(uri, BLOCK, BLOCK);
super.contentHandler.endElement(uri, name, raw);
this.foundIt = false;
this.skip = false;
} else if (!this.skip)  {
super.contentHandler.endElement(uri,name,raw);
}
}

in line 193:
super.contentHandler.endElement(uri, BLOCK, BLOCK);
the uri variable has the namespace of the parent element (in this case from
) and not from the  element, so the end  tag is
written without the namespace prefix i

suggestion: use no namespace for the block tag or a namespace of his own

Re: PDF Encryption

[Torsten Curdt]

Thanks for the help on this guys!
you are welcome :)

cheers
--
Torsten

Re: cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl StoreEventRegistryImpl.java DefaultEventRegistryImpl.java

[Geoff Howard]

[EMAIL PROTECTED] wrote:

unico   2004/02/27 09:27:04

 Modified:src/blocks/eventcache/java/org/apache/cocoon/caching/impl
   StoreEventRegistryImpl.java
   DefaultEventRegistryImpl.java
 Log:
 fix NPE on first use  
 

FYI I recently re-started making the StoreEventReg default, renaming 
DefaultEventReg, refactoring inheritance a little (pulled out an 
AbstractEventRegistry which both inherit from) etc.   It's quite 
unfinished and I have close to no time right now for "play" but just 
wanted to give you a heads up that I have some refactor work going on.  
Next chance I get, I'll try to get it in a working state and either 
commit it or pass it on as a patch for someone else to pick up.  I'd 
like to close the open bug about the serialized data location not being 
configurable but couldn't stand to hack in configuration when we've 
already agreed that some refactoring was needed.

Don't quite get what was wrong before this commit by the way.  Was this 
throwing an NPE all this time? (don't think so...)

Geoff

DO NOT REPLY [Bug 27275] - xsl:sort not sorting correctly

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=27275

xsl:sort not sorting correctly





--- Additional Comments From [EMAIL PROTECTED]  2004-02-27 17:13 ---
It does the same thing. Let me explain what my code is doing exactly.

My sample XML is for testing reasons only. With real data, it would look more 
like :
2:This paragrah is about chapter twoetc.  
1:This paragrah is about chapter oneetc.  

I am substring-before(current(),':') to parse the "1" and "2" out from the 
string. I am using the number to sort which paragraph gets display 
first..etc. ":" is just a delimeter. 
When I display the content, I am displaying everthing after the ":", using 
substring-after(current(),':')

By the way, I've tested using XML Spy. 

I hope this helps. Are you able to reproduce this?

Re: [RT] Cocoon Input Model

[Alan]

* Guido Casper <[EMAIL PROTECTED]> [2004-02-27 08:02]:
> Alan wrote:
> >* Guido Casper <[EMAIL PROTECTED]> [2004-02-26 20:41]:
> >
> >>Daniel Fagerstrom wrote:
> >>
> >>
> >>>So a pipeline for input handling could look like:
> >>>
> >>>g -> t* -> store -> act -> [select] -> g -> t* -> s.
> >>
> >>I'm still not convinced by this symmetry thing :-)

> >>For inbound data flow (as you already mentioned) you need strongly typed
> >>data which requires parsing, validation and error handling. I do see
> >>value in putting this data - once grabbed and converted by the forms
> >>framework - into some sort fo pipeline. What I'm unsure about is if
> >>these pipelines will be of similar power as weakly typed pipelines. I
> >>believe Cocoon's pipelines achieve this level of component reusability
> >>because of its weakly typed (and therefore loosely coupled) nature.
> >>
> >>Now IIUC you suggest a pipelining architecture for inbound data flow
> >>with a DOM-like data model.
> >
> >
> >What do you mean by strongly typed? Are we discussiong form posts
> >here?
> 
> Yes, form posts being the use case at hand, but there are other ways 
> input may be provided. Quoting Daniel:
> 
> >>>
> Besides using request parameters and "structured" request parameters as 
> user input. XML is used for WebDAV and web service applications, XML are 
> also becoming more common from more advanced user clients. And with new 
> environments like mail, CLI, JMS and possibly more, we will get even 
> more user input formats.
> <<<

I don't think of request parameters as strongly typed, they are all
strings, often they are html form encoded strings, but that's
does not include type information.

I can see how XML-RPC is typed, however.

-- 
Alan / [EMAIL PROTECTED] / http://engrm.com/
aim/yim: alanengrm - icq: 228631855 - msn: [EMAIL PROTECTED]

DO NOT REPLY [Bug 27249] - You cannot lookup components on a disposed ComponentLocator exception

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249

You cannot lookup components on a disposed ComponentLocator exception





--- Additional Comments From [EMAIL PROTECTED]  2004-02-27 16:26 ---
What we're looking for is the difference between 
a) a CVS commit when sitemap contains $Id$, which causes the problem
and 
b) a modification of the sitemap with an editor, which is ok

In terms of the detection and processing of the changed sitemap.

So I'd first activate all debug logs and look for messages related to b), then
run scenario a) and see if the logs indicate a different processing sequence or
give a hint as to what might go wrong.

If you want to dig further, you might want to ask on cocoon-dev which classes
are involved in the detection of sitemap changes, to know where to look. I don't
know this part of the code well.

Re: Accessing Servlet request, response and session

[Stephan Coboos]

Miguel Griffa wrote:

Hi all,
I'm new to developing inside cocoon (I'm writing a generator now).
Since I have to migrate an old framework into cocoon, I need to access 
data like request and response

How can I access these?

I have the idea that I'd need to use the manager to lookup() some 
component that will give me these data,
but where can I have a list of which components are available in the 
service manager?

Thanks in advance

Use org.apache.cocoon.environment.ObjectModelHelper to get the request 
in method setup().

Request req = ObjectModelHelper.getRequest(objectModel);

Regards
Stephan

Re: @author tags (WAS: RE: ASF Board Summary for February 18, 2004)

[Stefano Mazzocchi]

Tim Larson wrote:
On Fri, Feb 27, 2004 at 11:33:32AM +0100, Dirk-Willem van Gulik wrote:

On Feb 27, 2004, at 12:45 AM, Conal Tuohy wrote:


I don't think the ASF should discourage developers from keeping useful 
metadata about the code inside the source files. What better place to 
put the metadata than in the code? This makes it more likely to be 
used and kept up to date than if it was stored somewhere else, IMHO.
One way to look at this is that @author tags are in a way factually 
'wrong'; in most cases it just signals which person wrote the  first 
skeleton of that code; but subsequently it was fixes, peer-reviewed and 
looked at by a whole community. Also do not forget the many people in 
your community which help with QA, Documentation, user-feedback and so 
on. To put  one person in the (hot) seat for what is essentially a 
group effort is not quite right.

Looking through the CVS logs of a few tomcat files: each block of 30 
lines seems to have had commits of at least 5 persons; with a median of 
6 and an  average of 9. The average number of @author tags on those 
arbitrary blocks is about 0.5. And that is not counting QA, docs, 
suggestions of mailing lists, bug resolutions, user support. I.e. those 
things which make tomcat such a great supported product.

Secondly what we 'sell' as the ASF brand is a code base which is peer 
reviewed, quality controlled and created by a sustainable group which 
will survive the coming and going of volunteers. One where knowledge is 
generally shared and not just depended on one single individual. This 
is one of the key reasons why large companies, governments, etc have a 
lot less qualms about using apache than using most other open source; 
we mitigate  the worry that it depends on a single person, and can 
implode or fork without warning, right from the get-go.

Finally - a lot of developers do live in countries where you can get 
sued. The ASF can provide a certain level of protection; but this is 
based on the KEY premisse that there is oversight and peer review. That 
what we ship is a community product; and that everything is backed by 
the community and cannot be attributed to a single person. Every commit 
gets peer review; ever release requires +1s' and are backed by the 
community as a whole. @author tags are by necessity incomplete and thus 
portrait the situation inaccurately. Any hint or suggestion that parts 
of the code are not a community product makes defence more complex and 
expensive. We do not want to temp anyone - but rather present a clean 
picture with no blemishes or easy go's.

And to give this a positive slant; be -proud- of this culture; be proud 
of being part of something larger of incredible  quality. Each of you 
did not just write a few pesky lines of code surrounded by an @author 
tag; but where instrumental in getting the -whole- thing work ! And if 
you are ever trying to understand why cocoon made it this far, and 
other commercial/open-source projects did not, then do look there; 
quality and a sense of long term stability.

Take Care, Have fun,

Dw


Thank you for this email.  My +1 for removal of author tags is now
whole hearted.  Could we post something like this writeup in a
committer tips area as an explanation of the policy?
+1

And thanks much to Dirk for taking some of his copious free time to 
write this for us. :-)

[for those of you who don't know or didn't notice, Dirk is the president 
of the ASF]

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: @author tags (WAS: RE: ASF Board Summary for February 18, 2004)

[Tim Larson]

On Fri, Feb 27, 2004 at 11:33:32AM +0100, Dirk-Willem van Gulik wrote:
> On Feb 27, 2004, at 12:45 AM, Conal Tuohy wrote:
> 
> >I don't think the ASF should discourage developers from keeping useful 
> >metadata about the code inside the source files. What better place to 
> >put the metadata than in the code? This makes it more likely to be 
> >used and kept up to date than if it was stored somewhere else, IMHO.
> 
> One way to look at this is that @author tags are in a way factually 
> 'wrong'; in most cases it just signals which person wrote the  first 
> skeleton of that code; but subsequently it was fixes, peer-reviewed and 
> looked at by a whole community. Also do not forget the many people in 
> your community which help with QA, Documentation, user-feedback and so 
> on. To put  one person in the (hot) seat for what is essentially a 
> group effort is not quite right.
> 
> Looking through the CVS logs of a few tomcat files: each block of 30 
> lines seems to have had commits of at least 5 persons; with a median of 
> 6 and an  average of 9. The average number of @author tags on those 
> arbitrary blocks is about 0.5. And that is not counting QA, docs, 
> suggestions of mailing lists, bug resolutions, user support. I.e. those 
> things which make tomcat such a great supported product.
> 
> Secondly what we 'sell' as the ASF brand is a code base which is peer 
> reviewed, quality controlled and created by a sustainable group which 
> will survive the coming and going of volunteers. One where knowledge is 
> generally shared and not just depended on one single individual. This 
> is one of the key reasons why large companies, governments, etc have a 
> lot less qualms about using apache than using most other open source; 
> we mitigate  the worry that it depends on a single person, and can 
> implode or fork without warning, right from the get-go.
> 
> Finally - a lot of developers do live in countries where you can get 
> sued. The ASF can provide a certain level of protection; but this is 
> based on the KEY premisse that there is oversight and peer review. That 
> what we ship is a community product; and that everything is backed by 
> the community and cannot be attributed to a single person. Every commit 
>  gets peer review; ever release requires +1s' and are backed by the 
> community as a whole. @author tags are by necessity incomplete and thus 
> portrait the situation inaccurately. Any hint or suggestion that parts 
> of the code are not a community product makes defence more complex and 
> expensive. We do not want to temp anyone - but rather present a clean 
> picture with no blemishes or easy go's.
> 
> And to give this a positive slant; be -proud- of this culture; be proud 
> of being part of something larger of incredible  quality. Each of you 
> did not just write a few pesky lines of code surrounded by an @author 
> tag; but where instrumental in getting the -whole- thing work ! And if 
> you are ever trying to understand why cocoon made it this far, and 
> other commercial/open-source projects did not, then do look there; 
> quality and a sense of long term stability.
> 
> Take Care, Have fun,
> 
> Dw

Thank you for this email.  My +1 for removal of author tags is now
whole hearted.  Could we post something like this writeup in a
committer tips area as an explanation of the policy?

--Tim Larson

DO NOT REPLY [Bug 27249] - You cannot lookup components on a disposed ComponentLocator exception

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249

You cannot lookup components on a disposed ComponentLocator exception





--- Additional Comments From [EMAIL PROTECTED]  2004-02-27 14:42 ---
But after removing the $Id$ keyword the exception no longer occurs after a CVS
commit.
What should I be looking for in the sitemap debug log?

Accessing Servlet request, response and session

[Miguel Griffa]

Hi all,
I'm new to developing inside cocoon (I'm writing a generator now).
Since I have to migrate an old framework into cocoon, I need to access 
data like request and response

How can I access these?

I have the idea that I'd need to use the manager to lookup() some 
component that will give me these data,
but where can I have a list of which components are available in the 
service manager?

Thanks in advance

--

Miguel Griffa
Technisys.NET  "The First Digital e-nabler"
Transactional Solutions
Miami +1 305 357 8109
Madrid +34 915 726 763
Buenos Aires: +54 11 43227100
[EMAIL PROTECTED]
http://www.technisys.net

DO NOT REPLY [Bug 27249] - You cannot lookup components on a disposed ComponentLocator exception

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249

You cannot lookup components on a disposed ComponentLocator exception





--- Additional Comments From [EMAIL PROTECTED]  2004-02-27 13:52 ---
> So this seems to be solely related to the parsing of the XML
> comment containing the CVS version info.

hmm..if you remove the $Id$ keyword, CVS won't do any change to the file when
doing the commit, so the problem is not necessarily related to the comments.

I was more thinking of the way used by CVS to update the file (some sequence of
file open / write / close / file date change) which causes Cocoon's "file change
detection" to do something funny. 

It might be interesting to look at the debug messages related to how the
sitemap.xmap change is detected by Cocoon.

Re: @author tags (WAS: RE: ASF Board Summary for February 18, 2004)

[Bertrand Delacretaz]

Le Vendredi, 27 fév 2004, à 12:59 Europe/Zurich, Vadim Gritsenko a 
écrit :
"The Apache Cocoon Team"
+1
and +1 on Dirk-Willem's view as well.
-Bertrand

DO NOT REPLY [Bug 27275] - xsl:sort not sorting correctly

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=27275

xsl:sort not sorting correctly





--- Additional Comments From [EMAIL PROTECTED]  2004-02-27 13:30 ---
"Can you also try to sort this snip and port the results?"

A typo, I mean:

"... and post the results"

DO NOT REPLY [Bug 27275] - xsl:sort not sorting correctly

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=27275

xsl:sort not sorting correctly





--- Additional Comments From [EMAIL PROTECTED]  2004-02-27 13:28 ---
Looks like it include in the sorting the "1:", "2:" "3:".
Interesting enough is that later there are removed from the result. As if they
are namespaces!

Not sure what the specs said about this topic. I will consult about this issue.
Can you also try to sort this snip and port the results?:


  three
  two
  one

Re: [Avalon][PMC:VOTE/Release] Check 'em out!

[Hamilton Verissimo de Oliveira (Engenharia - SPO)]

-Mensagem original-
De: Leo Sutic [mailto:[EMAIL PROTECTED]

> Check 'em out and vote for release:

+1


--
hammett

Re: @author tags (WAS: RE: ASF Board Summary for February 18, 2004)

[Vadim Gritsenko]

Antonio Gallardo wrote:

Another related issue:

In Cocoon, we have some HTML docs in the Website that are related to the
authors. Need we to remove the author tags there? Example:
See the down right corner of the following pages:

http://cocoon.apache.org/2.1/ : "by cocoon-dev"
http://cocoon.apache.org/2.1/features.html: "by Cocoon community"
...
The samples, show we have not settled a "standard norm" to this label in
the website. We need this label? If so, then how we will fill it?
 

"The Apache Cocoon Team"

Vadim

Re: excalibur-component

[Antonio Gallardo]

Bertrand Delacretaz dijo:
> Le Vendredi, 27 fév 2004, à 11:33 Europe/Zurich, Joerg Heinicke a écrit
> :
>
>> ...Using only released versions as far it makes sense is a valueable
>> goal. But additionally I suggest whenever somebody commits a dated
>> version he puts the jared/zipped sources into a directory on the above
>> mentioned dist architecture...
>
> +1
>
> What would also help when taking a snapshot of something is to always
> take yesterday's CVS state, if possible (specifiying a precise time
> should also be possible, but I've never used it).
>
> For example, if I do today "cvs export -D 2004-02-26 somemodule" this
> is 100% reproducible later, whereas if I just do "cvs export" and there
> are some changes later today, someone using "-D 2004-02-27" later on
> might get something different.
>
> Hope I'm being clear ;-)

Clear enough! :-D

Good tips are here and there on the lists. What if we can put these hints
in a common place? This hints are for committers.

BTW, the usage of non-released jar has decreased dramatically in Cocoon on
every new release after we agreed to use just released versions of the
jars. In some rare situations (ie: a critical bug was fixed) there was a
vote to include a CVS version of the jars.

Since we cannot depend on other projects to release (Cocoon use many "3rd
party" jars), this hint can help developers and users to find the right
sources when needed.

Best Regards,

Antonio Gallardo

Re: [Avalon][PMC:VOTE/Release] Check 'em out!

[Antonio Gallardo]

Hi Leo:

Many thanks! Cocoon need it! :-)

+1 for release!

Best Regards,

Antonio Gallardo

Leo Sutic dijo:
> AVALON PMC MEMBERS
> ==
>
> The jars are in:
>
> http://cvs.apache.org/~leosutic/release/
>
> Check 'em out and vote for release:
>
>   +1 from me.
>
> I'd like to have this vote done by the end of today, since
> that means I can release them without having to worry about
> the license change.
>
>
> COCOON DEVELOPERS
> =
>
> The jars are in:
>
> http://cvs.apache.org/~leosutic/release/
>
> Check 'em out and let me know if there are any
> immediate issues.
>
> /LS
>

Re: @author tags (WAS: RE: ASF Board Summary for February 18, 2004)

[Antonio Gallardo]

Hi:

I agree with this POV. Initially, I had concerns about how to know who is
behind what code to later be able to ask about. Now, I think the maillist
will be enough to ask.

Another related issue:

In Cocoon, we have some HTML docs in the Website that are related to the
authors. Need we to remove the author tags there? Example:

See the down right corner of the following pages:

http://cocoon.apache.org/2.1/ : "by cocoon-dev"
http://cocoon.apache.org/2.1/features.html: "by Cocoon community"
...

The samples, show we have not settled a "standard norm" to this label in
the website. We need this label? If so, then how we will fill it?

WDYT?

Best Regards,

Antonio Gallardo.

Dirk-Willem van Gulik dijo:
>
> On Feb 27, 2004, at 12:45 AM, Conal Tuohy wrote:
>
>> I don't think the ASF should discourage developers from keeping useful
>> metadata about the code inside the source files. What better place to
>> put the metadata than in the code? This makes it more likely to be
>> used and kept up to date than if it was stored somewhere else, IMHO.
>
> One way to look at this is that @author tags are in a way factually
> 'wrong'; in most cases it just signals which person wrote the  first
> skeleton of that code; but subsequently it was fixes, peer-reviewed and
> looked at by a whole community. Also do not forget the many people in
> your community which help with QA, Documentation, user-feedback and so
> on. To put  one person in the (hot) seat for what is essentially a
> group effort is not quite right.
>
> Looking through the CVS logs of a few tomcat files: each block of 30
> lines seems to have had commits of at least 5 persons; with a median of
> 6 and an  average of 9. The average number of @author tags on those
> arbitrary blocks is about 0.5. And that is not counting QA, docs,
> suggestions of mailing lists, bug resolutions, user support. I.e. those
> things which make tomcat such a great supported product.
>
> Secondly what we 'sell' as the ASF brand is a code base which is peer
> reviewed, quality controlled and created by a sustainable group which
> will survive the coming and going of volunteers. One where knowledge is
> generally shared and not just depended on one single individual. This
> is one of the key reasons why large companies, governments, etc have a
> lot less qualms about using apache than using most other open source;
> we mitigate  the worry that it depends on a single person, and can
> implode or fork without warning, right from the get-go.
>
> Finally - a lot of developers do live in countries where you can get
> sued. The ASF can provide a certain level of protection; but this is
> based on the KEY premisse that there is oversight and peer review. That
> what we ship is a community product; and that everything is backed by
> the community and cannot be attributed to a single person. Every commit
>   gets peer review; ever release requires +1s' and are backed by the
> community as a whole. @author tags are by necessity incomplete and thus
> portrait the situation inaccurately. Any hint or suggestion that parts
> of the code are not a community product makes defence more complex and
> expensive. We do not want to temp anyone - but rather present a clean
> picture with no blemishes or easy go's.
>
> And to give this a positive slant; be -proud- of this culture; be proud
> of being part of something larger of incredible  quality. Each of you
> did not just write a few pesky lines of code surrounded by an @author
> tag; but where instrumental in getting the -whole- thing work ! And if
> you are ever trying to understand why cocoon made it this far, and
> other commercial/open-source projects did not, then do look there;
> quality and a sense of long term stability.
>
> Take Care, Have fun,
>
> Dw
>

[Avalon][PMC:VOTE/Release] Check 'em out!

[Leo Sutic]

AVALON PMC MEMBERS
==

The jars are in:

http://cvs.apache.org/~leosutic/release/

Check 'em out and vote for release:

  +1 from me.

I'd like to have this vote done by the end of today, since
that means I can release them without having to worry about
the license change.


COCOON DEVELOPERS
=

The jars are in:

http://cvs.apache.org/~leosutic/release/

Check 'em out and let me know if there are any
immediate issues.

/LS

Re: @author tags (WAS: RE: ASF Board Summary for February 18, 2004)

[Dirk-Willem van Gulik]

On Feb 27, 2004, at 12:45 AM, Conal Tuohy wrote:

I don't think the ASF should discourage developers from keeping useful 
metadata about the code inside the source files. What better place to 
put the metadata than in the code? This makes it more likely to be 
used and kept up to date than if it was stored somewhere else, IMHO.
One way to look at this is that @author tags are in a way factually 
'wrong'; in most cases it just signals which person wrote the  first 
skeleton of that code; but subsequently it was fixes, peer-reviewed and 
looked at by a whole community. Also do not forget the many people in 
your community which help with QA, Documentation, user-feedback and so 
on. To put  one person in the (hot) seat for what is essentially a 
group effort is not quite right.

Looking through the CVS logs of a few tomcat files: each block of 30 
lines seems to have had commits of at least 5 persons; with a median of 
6 and an  average of 9. The average number of @author tags on those 
arbitrary blocks is about 0.5. And that is not counting QA, docs, 
suggestions of mailing lists, bug resolutions, user support. I.e. those 
things which make tomcat such a great supported product.

Secondly what we 'sell' as the ASF brand is a code base which is peer 
reviewed, quality controlled and created by a sustainable group which 
will survive the coming and going of volunteers. One where knowledge is 
generally shared and not just depended on one single individual. This 
is one of the key reasons why large companies, governments, etc have a 
lot less qualms about using apache than using most other open source; 
we mitigate  the worry that it depends on a single person, and can 
implode or fork without warning, right from the get-go.

Finally - a lot of developers do live in countries where you can get 
sued. The ASF can provide a certain level of protection; but this is 
based on the KEY premisse that there is oversight and peer review. That 
what we ship is a community product; and that everything is backed by 
the community and cannot be attributed to a single person. Every commit 
 gets peer review; ever release requires +1s' and are backed by the 
community as a whole. @author tags are by necessity incomplete and thus 
portrait the situation inaccurately. Any hint or suggestion that parts 
of the code are not a community product makes defence more complex and 
expensive. We do not want to temp anyone - but rather present a clean 
picture with no blemishes or easy go's.

And to give this a positive slant; be -proud- of this culture; be proud 
of being part of something larger of incredible  quality. Each of you 
did not just write a few pesky lines of code surrounded by an @author 
tag; but where instrumental in getting the -whole- thing work ! And if 
you are ever trying to understand why cocoon made it this far, and 
other commercial/open-source projects did not, then do look there; 
quality and a sense of long term stability.

Take Care, Have fun,

Dw

Re: @author tags (WAS: RE: ASF Board Summary for February 18, 2004)

[Dirk-Willem van Gulik]

On Feb 27, 2004, at 12:45 AM, Conal Tuohy wrote:

I don't think the ASF should discourage developers from keeping useful 
metadata about the code inside the source files. What better place to 
put the metadata than in the code? This makes it more likely to be 
used and kept up to date than if it was stored somewhere else, IMHO.
One way to look at this is that @author tags are in a way factually 
'wrong'; in most cases it just signals which person wrote the  first 
skeleton of that code; but subsequently it was fixes, peer-reviewed and 
looked at by a whole community. Also do not forget the many people in 
your community which help with QA, Documentation, user-feedback and so 
on. To put  one person in the (hot) seat for what is essentially a 
group effort is not quite right.

Looking through the CVS logs of a few tomcat files: each block of 30 
lines seems to have had commits of at least 5 persons; with a median of 
6 and an  average of 9. The average number of @author tags on those 
arbitrary blocks is about 0.5. And that is not counting QA, docs, 
suggestions of mailing lists, bug resolutions, user support. I.e. those 
things which make tomcat such a great supported product.

Secondly what we 'sell' as the ASF brand is a code base which is peer 
reviewed, quality controlled and created by a sustainable group which 
will survive the coming and going of volunteers. One where knowledge is 
generally shared and not just depended on one single individual. This 
is one of the key reasons why large companies, governments, etc have a 
lot less qualms about using apache than using most other open source; 
we mitigate  the worry that it depends on a single person, and can 
implode or fork without warning, right from the get-go.

Finally - a lot of developers do live in countries where you can get 
sued. The ASF can provide a certain level of protection; but this is 
based on the KEY premisse that there is oversight and peer review. That 
what we ship is a community product; and that everything is backed by 
the community and cannot be attributed to a single person. Every commit 
 gets peer review; ever release requires +1s' and are backed by the 
community as a whole. @author tags are by necessity incomplete and thus 
portrait the situation inaccurately. Any hint or suggestion that parts 
of the code are not a community product makes defence more complex and 
expensive. We do not want to temp anyone - but rather present a clean 
picture with no blemishes or easy go's.

And to give this a positive slant; be -proud- of this culture; be proud 
of being part of something larger of incredible  quality. Each of you 
did not just write a few pesky lines of code surrounded by an @author 
tag; but where instrumental in getting the -whole- thing work ! And if 
you are ever trying to understand why cocoon made it this far, and 
other commercial/open-source projects did not, then do look there; 
quality and a sense of long term stability.

Take Care, Have fun,

Dw

DO NOT REPLY [Bug 27249] - You cannot lookup components on a disposed ComponentLocator exception

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249

You cannot lookup components on a disposed ComponentLocator exception





--- Additional Comments From [EMAIL PROTECTED]  2004-02-27 10:58 ---
Additional info: as you may suspect, if the CVS id comment is removed from the
sitemap, the
bug doesn't happen. So this seems to be solely related to the parsing of the XML
comment containing the CVS version info.

DO NOT REPLY [Bug 27249] - You cannot lookup components on a disposed ComponentLocator exception

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249

You cannot lookup components on a disposed ComponentLocator exception





--- Additional Comments From [EMAIL PROTECTED]  2004-02-27 10:55 ---
I can confirm the behavior exactly as Bertrand reports; a simple touch doesn't
cause the bug to happen. This is on Cocoon 2.1.3 with Tomcat 4.1.12-jdk14.

Re: excalibur-component

[Bertrand Delacretaz]

Le Vendredi, 27 fév 2004, à 11:33 Europe/Zurich, Joerg Heinicke a écrit 
:

...Using only released versions as far it makes sense is a valueable 
goal. But additionally I suggest whenever somebody commits a dated 
version he puts the jared/zipped sources into a directory on the above 
mentioned dist architecture...
+1

What would also help when taking a snapshot of something is to always 
take yesterday's CVS state, if possible (specifiying a precise time 
should also be possible, but I've never used it).

For example, if I do today "cvs export -D 2004-02-26 somemodule" this 
is 100% reproducible later, whereas if I just do "cvs export" and there 
are some changes later today, someone using "-D 2004-02-27" later on 
might get something different.

Hope I'm being clear ;-)

-Bertrand

DO NOT REPLY [Bug 27249] - You cannot lookup components on a disposed ComponentLocator exception

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249

You cannot lookup components on a disposed ComponentLocator exception





--- Additional Comments From [EMAIL PROTECTED]  2004-02-27 10:37 ---
Could not be much more than a touch without changing anything, a comment with
$ID$ could be changed. Is it reproducable with a simple touch?

DO NOT REPLY [Bug 27249] - You cannot lookup components on a disposed ComponentLocator exception

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249

You cannot lookup components on a disposed ComponentLocator exception





--- Additional Comments From [EMAIL PROTECTED]  2004-02-27 10:34 ---
The failure scenario below is repeatable on my cocoon-2.1rc2-dev installation:

1. Make some change to sitemap
2. cvs commit of the sitemap (to my own CVS), wait for commit to be finished
3. reload page -> gives the above exception

Haven't been able to reproduce it without doing the commit, I tried various
renaming and copying scenarios on sitemap.xmap but didn't see the problem. Maybe
looking at what CVS does to the file during the commit would help.

Re: excalibur-component

[Joerg Heinicke]

On 26.02.2004 20:29, Carsten Ziegeler wrote:

Now, we discussed this topic, but never agreed to anything :)
And I personally don't want to also store hundreds of sources
of other projects in the cocoon cvs.
The way we "agreed" about (it was more a RT IIRC) is to put the source 
JARs/ZIPs into the http://www.apache.org/dist/cocoon/ architecture.

So, I have the hope that starting with 2.1.5 we will stick
to a vote we made ages ago "Only use released versions of other
projects" :)
I guess we will never do this completely as for example for our Rhino it 
makes just no sense, there is no difference between a released and a 
dated version.

Using only released versions as far it makes sense is a valueable goal. 
But additionally I suggest whenever somebody commits a dated version he 
puts the jared/zipped sources into a directory on the above mentioned 
dist architecture.

Joerg

Applying SourceWritingTransformer to file used in pipeline

[Remmerie Bart]

Title: Applying SourceWritingTransformer to file used in pipeline





It appears to be impossible to use the SourceWriting transformer to a file that is in use by the pipeline.
Does anyone have a workaroud / alternative for this ?


A bit more details:


Below is my code (which is not working).
When I try to write to writeTest.xml, I get the following error:


org.apache.cocoon.ProcessingException: Could not process your document.: java.io.IOException: Could not rename C:\cocoon-2.1\build\webapp\samples\testDir\writeTest.xml.tmp to C:\cocoon-2.1\build\webapp\samples\testDir\writeTest.xml

cause: java.io.IOException: Could not rename C:\cocoon-2.1\build\webapp\samples\testDir\writeTest.xml.tmp to C:\cocoon-2.1\build\webapp\samples\testDir\writeTest.xml

I have the following snippet in my pipeline


   
    
    
    
   


and writeTest.xml contains the following:
 
   http://apache.org/cocoon/source/1.0">
 writeTest.xml  
 
   Hello World
   
 This is my first paragraph.
   
 
   
 



Thanks & Regards,
Bart







This message and its attachments may contain confidential information protected by intellectual property rights or other rights & is strictly for the exclusive use of the intended recipient. It is strictly prohibited to copy, alter or disclose this message or its contents to any other person without Elia's prior consent. If you are not the intended recipient of this message, please inform the person who sent it and delete the message from your system. Elia is not liable for any direct or indirect damage arising from errors, inaccuracies or any loss in the message, from unauthorized use, disclosure, copying or alteration of it or as a result of any virus being passed on. This message does not constitute any commitment from Elia except when expressly otherwise agreed between the intended recipient and Elia.

U vindt de Nederlandse versie van deze disclaimer op onze internetsite  www.elia.be

Vous pouvez découvrir la version française de ce disclaimer sur notre site internet www.elia.be

DO NOT REPLY [Bug 27249] - You cannot lookup components on a disposed ComponentLocator exception

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249

You cannot lookup components on a disposed ComponentLocator exception





--- Additional Comments From [EMAIL PROTECTED]  2004-02-27 10:23 ---
I've had the problem again on an existing cocoon-2.1rc2-dev installation
(compiled  on August 8 2003), scenario:

1. Cocoon is running fine
2. Do a CVS commit, causes sitemap.xmap to change (but only XML comments change,
due to the CVS log being written there)
3. Next request which uses the sitemap in question gives the error
4. After adding a space somewhere in the sitemap to cause it to reload, back to
normal.

Interesting part of the stack trace:
java.lang.IllegalStateException: You cannot lookup components on a disposed
ComponentLocator
at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(ExcaliburComponentManager.java:199)
at
org.apache.cocoon.components.CocoonComponentManager.lookup(CocoonComponentManager.java:315)
at org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:165)
at org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:126)
at
org.apache.cocoon.components.treeprocessor.DefaultTreeBuilder.build(DefaultTreeBuilder.java:388)


Line 165 in SourceUtil is:

  xmlizer = (XMLizer) manager.lookup( XMLizer.ROLE);
   
so apparently the manager is not in the expected state when this happens.

I don't have the CVS version number of this SourceUtil handy but it was obtained
with a "cvs export -d 2004-08-08".

RE: PDF Encryption

[Matthew Langham]

Thanks for the help on this guys!

Matthew

> -Original Message-
> From: Torsten Curdt [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 26, 2004 10:17 PM
> To: [EMAIL PROTECTED]
> Subject: Re: PDF Encryption
> 
> 
> >  http://xml.apache.org/fop/pdfencryption.html
> > for how to set up the infrastructure and the relevant
> > cocoon pages for passing options to the renderer.
> 
> Excellent, thanks for the pointer...
> 
> ...I put it into the wiki and added a new
> way to configure the renderer...
> 
> http://wiki.cocoondev.org/Edit.jsp?page=FOPPDFEncryption
> 
> The new parameter passing works.
> 
> But the way through the user config
> file seems to fail. Maybe someone
> else has an idea why?
> 
> cheers
> --
> Torsten
> 

Re: ASF Board Summary for February 18, 2004

[Antonio Gallardo]

Stefano Mazzocchi dijo:
> Antonio Gallardo wrote:
>
>> Steven Noels dijo:
>>
>>>On 26 Feb 2004, at 17:12, Torsten Curdt wrote:
>>>
>>>
+ and we remove all author tags
>>>
>>>I find this just a little bit too reactionary - especially for the
>>>little known/used areas of code. We haven't had "ownership issues"
>>>because of them in the past, not? These tags sometimes help to find a
>>>contact, when questions remain unanswered on the list.
>>
>>
>> [RT]:
>>
>> Will be enough to browse the CVS to find the folks involved in a
>> concrete
>> file or block? No, we cannot trace many files to the first post. The
>> original file, who made changes, etc?
>>
>> "When I started to use the auth-fw, the @author tags allow me to know
>> the
>> names of people that was involved in this. After this I also used the
>> names to harvest the mailarchives looking for help about the auth-fw.
>
> Yes, the author tag says something about who started the code, but
> nothing about how knows about that particular version of it and it
> creates copyright problems and increases spam.
>
> +1 to remove them and +1 to pay back with our credits in the
> Changes/Credits page.

I Agree.

Antonio Gallardo

[Help]writing SAX Transformer

[roy huang]

I wrote a transformer extend AbstractSAXTransformer to transform woody form define 
file base on action and state.
The transformer do two thing:
1.turn  to  for read-only
2.delete some define widgets under certain condition.I use this.startRecording(); 
this.endRecording to delete the widget .
Question 1:
It looks fine when I use browser to see the xml output.But if I check the source ,I 
found if the original xml is like:



a


b


c

 
if I delete   using startRecording the source code turns into:





c


left many blank and tab.How to solve it or I am in the wrong way?
Question 2:
in the transformer I also and some xinclude tag,like:
   attr.addAttribute(
"http://www.w3.org/2001/XInclude";,
"href",
"href",
"CDATA",
flowUri);
   super.startTransformingElement("", "include", "xi:include", attr);
   super.endTransformingElement("", "include", "xi:include");
   attr.clear();
the xml is fine,but can't be transform by XInclude transformer,but if I save the xml 
and use an another pipeline to use the xml in the disk,it can be transform by Xinclude.
If I use a xslt file to transform it first ,it can also transform by Xinclude.
So I believe it my transformer's problem,can you help?

Thanks advanced!

Roy Huang

Re: [RT] Cocoon Input Model

[Guido Casper]

Alan wrote:
* Guido Casper <[EMAIL PROTECTED]> [2004-02-26 20:41]:

Daniel Fagerstrom wrote:


So a pipeline for input handling could look like:

g -> t* -> store -> act -> [select] -> g -> t* -> s.
I'm still not convinced by this symmetry thing :-)

The requirements for inbound data flow seems to be too different from
those of outbound data flow.
For outbound data flow everything is converted to a string which is
quite easy and nicely supported by XML's weakly typed nature (IMO one
major reason for XMLs power and success) and a powerful transformation
language.
For inbound data flow (as you already mentioned) you need strongly typed
data which requires parsing, validation and error handling. I do see
value in putting this data - once grabbed and converted by the forms
framework - into some sort fo pipeline. What I'm unsure about is if
these pipelines will be of similar power as weakly typed pipelines. I
believe Cocoon's pipelines achieve this level of component reusability
because of its weakly typed (and therefore loosely coupled) nature.
Now IIUC you suggest a pipelining architecture for inbound data flow
with a DOM-like data model.


What do you mean by strongly typed? Are we discussiong form posts
here?
Yes, form posts being the use case at hand, but there are other ways 
input may be provided. Quoting Daniel:

>>>
Besides using request parameters and "structured" request parameters as 
user input. XML is used for WebDAV and web service applications, XML are 
also becoming more common from more advanced user clients. And with new 
environments like mail, CLI, JMS and possibly more, we will get even 
more user input formats.
<<<

Guido

For some time now, I've wondered how one would post XML to
Cocoon and start out with it in the pipeline. Cocoon would make
short work of REST implementations.
(Trying to get up to speed.)