RE: svn commit: rev 55618 - cocoon/trunk/src/blocks/axis/conf

[Carsten Ziegeler]

Thanks Unico!

Carsten 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, October 26, 2004 6:59 PM
> To: [EMAIL PROTECTED]
> Subject: svn commit: rev 55618 - cocoon/trunk/src/blocks/axis/conf
> 
> Author: unico
> Date: Tue Oct 26 09:58:44 2004
> New Revision: 55618
> 
> Modified:
>cocoon/trunk/src/blocks/axis/conf/soapserver.xconf
> Log:
> instrumentation descriptor was removed
> 
> Modified: cocoon/trunk/src/blocks/axis/conf/soapserver.xconf
> ==
> 
> --- cocoon/trunk/src/blocks/axis/conf/soapserver.xconf
> (original)
> +++ cocoon/trunk/src/blocks/axis/conf/soapserver.xconf
> Tue Oct 26 09:58:44 2004
> @@ -23,7 +23,6 @@
>src="resource://org/apache/cocoon/webservices/memory/Deploymen
> tDescriptor.wsdd"/>
>src="resource://org/apache/cocoon/webservices/system/Deploymen
> tDescriptor.wsdd"/>
>src="resource://org/apache/cocoon/webservices/cache/Deployment
> Descriptor.wsdd"/>
> -  src="resource://org/apache/cocoon/webservices/instrument/Deplo
> ymentDescriptor.wsdd"/> 
> 
>   
>  
> 

Re: HtmlCleaningConvertor

[Reinhard Poetz]

Bruno Dumon wrote:
On Mon, 2004-10-25 at 18:38 +0200, Reinhard Poetz wrote:
While browsing Daisy I saw a very interesting cForms extension in Daisy: the 
HtmlCleaningConvertor. Are there any plans to move it to Cocoon?

Didn't think of that yet. Keeping it with Daisy would make it follow
Daisy releases, which is somewhat easier for us at this stage.
You also have to know that the htmlcleaner is quite strict, in that it
drops all elements and attributes that are not explicitely allowed
(configurable using an XML file), which is exactly what we wanted for
Daisy, but might be different for other use-cases.

I think this 
could be valuable for many other users.

Nothing prevents reuse of course. The htmlcleaner is an independent
library, bundled in its own jar, with minimal dependencies
(nekohtml/nekodtd, which in itself requires xerces). The
HtmlCleaningConvertor and HtmlCleaningConvertorBuilder classes that do
the integration with Cocoon would need to be copied to your own project.
Another possibility would be to just move those last two classes to
Cocoon, and add the daisy-htmlcleaner.jar as an external dependency to
cforms.
IIUC you mean that the HtmlCleaningConvertor and HtmlCleaningConvertorBuilder 
are moved to Cocoon and are deleted in Daisy. The HtmlCleaner.jar with the code 
actually doing the cleaning stays (at least for now) at Daisy. If this is no 
problem for you, I would really appreciate it, as I think it could be a very 
useful extension for Cocoon.

One question to the "strict" cleaning. IIRC Steven's presentation you use 
HtmlArea at the client. So I guess that the HtmlCleaner is in some way optimized 
(at least testet) with it and it should work fine with it. I mean that it 
doesn't swallow some parts of the user's HtmlArea input, does it?

--
Reinhard

Re: [RT] doco lite?

[Bertrand Delacretaz]

Le 26 oct. 04, à 22:56, Frédéric Glorieux a écrit :
...T2. Build an index with Lucene, triggered via SVN post-commit 
hooks, uses a live Cocoon instance to generate an easy to index XML 
document for Lucene. Include metadata fields as mentioned in G2 
above, generated from (enhanced as compared to now) document content
I'm working on that (nto enough), it seems to me only a consequence of 
upper.,,,
Great! So we might be able to use your stuff IIRC.
...For delete, a hook from SVN is needed.
Right, gotta check if SVN provides this.
...T5. Put mod_cache in front to minimize server load (HTTP POST can 
be used to invalidate pages if quick updates are needed to check 
edits).
You give me the trick for something that I was asking to Sylvain, a 
kind of pure cocoon mod_cache with 

http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=109636070505876&w=2
Why pure Cocoon? mod_cache works so well.
-Bertrand

smime.p7s
Description: S/MIME cryptographic signature

Re: [RT] doco lite?

[Bertrand Delacretaz]

Le 26 oct. 04, à 22:34, Upayavira a écrit :
...So you'd use HEAD or whatever to view the latest commit, and the 
public would see the "current-docs" tag. That could work. But would we 
want the HEAD to be password protected, or in some way hidden so that 
it doesn't get regularly viewed when it isn't live yet?...
I'd just add a notice to pages when one's not viewing the released 
version. No need for any secrets or passwords IMHO.

So, when do you start?..
That's the problem - I'd like to say "right now" but I have to keep my 
business going at the same time.

- Bertrand

smime.p7s
Description: S/MIME cryptographic signature

Re: [RT] doco lite?

[Bertrand Delacretaz]

Le 26 oct. 04, à 21:56, Jorg Heymans a écrit :
...1)Does all this actually make the documentation any better?
The content, would not immediately be improved of course. But 
simplifying the docs publishing process is an enabler for improving the 
docs.

2)Should any effort towards documentation ATM go into improving its 
*quality* or improving its 
{searchability|updateability|scaleability|auto-generateability}
Both, but many of us agree that the biggest problem now is 
accessibility (both from the user's and from the writer's point of 
views) of the docs.

-Bertrand

smime.p7s
Description: S/MIME cryptographic signature

Re: Let's deprecate the PHP block

[Stefano Mazzocchi]

David Crossley wrote:
So when a real, potentially damaging, issue arises
we will have no way to sensibly handle it.
It has been working fine so far and I see no evidence of things changing.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

How to make things better

[Stefano Mazzocchi]

Luigi Bai wrote:
If you have ideas on how to make it better, we are wide open to 
suggestions.
Okay, assuming your sincerity - what is the current method for 
committers to find/fix/close issues in Bugzilla? 
there is no codified method. Basically, one those patches/fixes/bugs 
that are promoted by somebody that really cares (and really keeps 
bugging us) get in. The others remain in a limbo until somebody cares.

Are votes used, or longest time open, number of comments? 
we have cronned script that sends a list of unapplied patches to the 
mail list every sunday. it was a nice try but if everybody skips over it 
the way I do, it's pretty much useless.

currently, we have no way to "rank" the most important issues. I agree 
that would be a great addition. Something like "vote your issue" would 
go a long way to identify what things we can work on.

How often are these criteria 
applied (periodically, only FirstFriday, only before release)?

Knowing these, we can figure out a way to improve the system, or the 
users's expectations (or both!).
We tried to improve the system with FirstFriday. It was a nice try but I 
think it's not keeping up with the expectations.

The "bugathon" worked well for the past 2 years, but we need something 
more continous.

I like your suggestion of improving the 'ranking' of the pending issues, 
so that one doesn't feel overwhelmed without an indication of importance.

Of course, on the other hand, every ranking methodology might hide some 
of the issues even more.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] doco lite?

[David Crossley]

Upayavira wrote:
> Bertrand Delacretaz wrote:
> > Upayavira a écrit :
> >
> >> ...The thing you seem to have missed is the staging process. If I 
> >> have written an xdoc, I want to see that as HTML, on a staging 
> >> server, before I actually publish it. After all, the XML might not 
> >> even be valid,

As always, people need to do xml validation prior to commit.

> or there might be mistakes. I need to be able to see 
> >> the page on the site before I publish it...

Definitely.

> > How about using SVN tags for this?
> >
> > -Current known good version of the docs is always tagged as 
> > "current-docs"
> > -Website serves this tagged version on the public site
> > -New docs releases are done by moving this tag to the appropriate 
> > revision (I didn't try moving tags in SVN yet but it shouldn't be a 
> > problem)
> >
> > Then you'd use the current release for the staging process, and update 
> > the public version by moving the SVN tag.
> 
> So you'd use HEAD or whatever to view the latest commit, and the public 
> would see the "current-docs" tag. That could work. But would we want the 
> HEAD to be password protected, or in some way hidden so that it doesn't 
> get regularly viewed when it isn't live yet? I like the idea of being 
> able to tag the docs whenever we release. If we can get the available 
> tags for a document from SVN, we could have a dropdown that allows you 
> to see the docs for a specific version, which would be absolutely 
> fantastic. That would solve soo many problems.
> 
> So, when do you start?

The website is currently built from the release version,
so i presume that that is HEAD of the branch.

So we would have two separate instances of Cocoon (or Forrest).
One is the staging server, which is the head. The other is the
live site, which uses the "current-docs" tag.

The same would happen for the proposed "Cocoon Samples" site.

I do see some issues with this proposal. When one edits a
single document, they can click and view, and will be able
to see any structural and content problems. When one edits
a heap of documents, then would need to click on each doc
to see if it works.

Broken internal links are not apparent by just looking.

One thing to bear in mind, people can still run the
'./cocoon.sh cli -x cli.xconf' or './build.sh docs'
locally to reveal global issues. Actually the "Forrestbot"
proposal can still apply here too. People can still use
that to trigger a complete website build, via the online
interface and can review the build log for issues. Just
they would not use the "deploy" phase of Forrestbot.

Does SVN enable us to "move" tags? If not, then this
proposal might fail. We could not have a new tag
for every little documentation tweak.

-- 
David Crossley

Cocoon read-only (ex: CD-ROM) add ${context-work} parameter to logkit.xconf from CocoonServlet.java

[Frédéric Glorieux]

Hello,
For sysadmin, it may be important for the cocoon servlet to be totally 
read-only, even logs. I used to try to run a same cocoon in parallel in 
different servlet contexts (same JVM, same tomcat, different URIs). Logs 
were quite funny to read but a bit broken. For a fast patch, I added 2 
lines in *CocoonServlet.java* to make cocoon write is logs in work.

line 774
subcontext.put("servlet-context", this.servletContext);
if (this.servletContextPath == null) {
File logSCDir = new File(this.workDir, "log");
logSCDir.mkdirs();
if (logger.isWarnEnabled()) {
logger.warn("Setting servlet-context for LogKit to " +
logSCDir);
}
subcontext.put("context-root", logSCDir.toString());
+   subcontext.put("context-work", this.workDir);
} else {
subcontext.put("context-root", this.servletContextPath);
+   subcontext.put("context-work", this.workDir);
}
Same is easy to do with a log Target, Forrest gave us an example here
http://svn.apache.org/viewcvs.cgi/forrest/trunk/src/java/org/apache/forrest/log/
but this is a so little change ? I can't guess consequences in a so 
central class.

--
Frédéric Glorieux (ingénieur documentaire, AJLSM)

Re: Let's deprecate the PHP block

[David Crossley]

Stefano Mazzocchi wrote:
> Bertrand Delacretaz wrote:
> >
> > I see David's point though, using [VOTE] in subject (and [PROPOSAL] 
> > maybe) helps in not missing stuff that's happening.
> > 
> > But I like our +1 way of saying "me? I like it" even if outside of a 
> > vote - it's part of our "slang" I think.

Well i do not like it. It just introduces confusion
and votes tend to start happening in the middle of
the discussion. Inefficient.

> > So +1 on being more careful with [appropriate headers] in subjects ;-)
>
> I hear you and I agree.
> 
> But one thing is saying "next time use [vote] so that people don't miss 
> it", another is "start over and follow the rules".
> 
> The first is common sense, the second is burocracy.

If you referring to me, i never did say "start over".

Anyway, Cocoon does not have any project guidelines.
So when a real, potentially damaging, issue arises
we will have no way to sensibly handle it.

-- 
David Crossley

Re: handling Bugzilla backlog (Was: Let's deprecate the PHP block)

[Luigi Bai]

On Tue, 27 Oct 2004, David Crossley wrote:
Luigi Bai wrote:
Stefano Mazzocchi wrote:
Maybe it is more precise to say "When shit works /mostly/ well...". The
presence of a large number of outstanding Bugzilla issues, especially ones
with [PATCH]es attached, implies that things work well for committers, less
well for those of us who have to wait until "someone just gets around to
it". Fixing bugs isn't sexy, like Flow or Forms or Real Blocks. But it
should happen every once in a while, especially when other people have
already proposed the patches.
If you have ideas on how to make it better, we are wide open to suggestions.
Okay, assuming your sincerity - what is the current method for committers
to find/fix/close issues in Bugzilla? Are votes used, or longest time
open, number of comments? How often are these criteria applied
(periodically, only FirstFriday, only before release)?
Knowing these, we can figure out a way to improve the system, or the
users's expectations (or both!).
None of the things that you mentioned are really criteria.
Bugs get addressed and patches applied when a committer
finds some spare time and jumps in to address them.
Contributers can ease this process by clearly describing
their issues and using sensible bug titles to attract attention.
The system you describe seems very subjective; there's no way to measure 
how much attention can be brought to an issue. Would it be helpful to more 
aggressively use the "voting" system in Bugzilla? In that way, users and 
developers can "lobby" for issues they are most concerned with; and then 
committers can better know what things the community considers a priority. 
Right now it doesn't seem that many people use (know about?) the voting 
facility.

All of us, committers and contributers, need to review the
contributions. Don't just leave it up to the poor overworked
committers. When other developers review the patches and issues,
then add constructive comments, that would help immensely.
A side-effect of that is to send an automated message
to the dev list, which reminds committers of the importance.
Many of the open issues have a subject line of [PATCH] - this implies to 
me that someone has taken the time and effort to track down a problem and 
provide a solution. It seems to me that those should certainly get 
priority from a committer, if only to validate the work of the individual 
and to provide feedback so a final solution can be put in place.

And the issue of "poor overworked committers" can be partially alleviated 
by increasing the number of people deputized to commit bug fixes. This 
will likely get even easier to administer when "real blocks" become a 
reality; then individuals can be deputized "per block" (they can be 
separate projects) without necessarily having commit access to "core 
cocoon". Even now, with svn, if a committer puts crummy code in, it can 
always be rolled back, so it seems that there's a net benefit (less the 
potential risk of bad code) to having more committers.

--
David Crossley

Re: getInputStream() in FOM_Cocoon.FOM_Request ?

[Frédéric Glorieux]

This seemed to be related to the removal of instrumentation from the 
axis block. Should be fixed now.

--
Unico
Thanks a lot. This is working well for me. I'm glad to delete my ugly 
patches.

--
Frédéric Glorieux (ingénieur documentaire, AJLSM)

handling Bugzilla backlog (Was: Let's deprecate the PHP block)

[David Crossley]

Luigi Bai wrote:
> Stefano Mazzocchi wrote:
> >> 
> >> Maybe it is more precise to say "When shit works /mostly/ well...". The 
> >> presence of a large number of outstanding Bugzilla issues, especially ones 
> >> with [PATCH]es attached, implies that things work well for committers, less 
> >> well for those of us who have to wait until "someone just gets around to 
> >> it". Fixing bugs isn't sexy, like Flow or Forms or Real Blocks. But it 
> >> should happen every once in a while, especially when other people have 
> >> already proposed the patches.
> >
> > If you have ideas on how to make it better, we are wide open to suggestions.
> 
> Okay, assuming your sincerity - what is the current method for committers 
> to find/fix/close issues in Bugzilla? Are votes used, or longest time 
> open, number of comments? How often are these criteria applied 
> (periodically, only FirstFriday, only before release)?
> 
> Knowing these, we can figure out a way to improve the system, or the 
> users's expectations (or both!).

None of the things that you mentioned are really criteria.
Bugs get addressed and patches applied when a committer
finds some spare time and jumps in to address them.

Contributers can ease this process by clearly describing
their issues and using sensible bug titles to attract attention.

All of us, committers and contributers, need to review the
contributions. Don't just leave it up to the poor overworked
committers. When other developers review the patches and issues,
then add constructive comments, that would help immensely.
A side-effect of that is to send an automated message
to the dev list, which reminds committers of the importance.

-- 
David Crossley

Re: svn commit: rev 55059 - in cocoon/trunk/src/java/org/apache/cocoon: . components/flow

[Ugo Cei]

Il giorno 19/ott/04, alle 15:11, [EMAIL PROTECTED] ha scritto:
Removed:

cocoon/trunk/src/java/org/apache/cocoon/components/flow/ 
InterpreterSelector.java
This class is referred to in the javaflow block's tests. See  
JavaFlowTestCase.xtest:


shorthand="flow-interpreters"
 
default-class="org.apache.cocoon.components.flow.InterpreterSelector"/>

What should be changed to make tests pass again?
Ugo
--
Ugo Cei - http://beblogging.com/


smime.p7s
Description: S/MIME cryptographic signature

RE: [RT] doco lite?

[Conal Tuohy]

Jorg Heymans wrote:

> 2)Should any effort towards documentation ATM go into improving its 
> *quality* or improving its 
> {searchability|updateability|scaleability|auto-generateability}
> 
> WDYT?

Personally, I think that Cocoon has a lot of good documentation, but 
poorly/inconsistently organised. I know I have many bookmarks of Cocoon-related 
resources, many of which deal with the same actual topic. Often I know I've seen some 
useful documentation somewhere but it takes a while to find it again. That's why I 
think that Bertrand's idea of harvesting metadata from the docs and using Lucene to 
cluster them semantically and automatically is an excellent one. With a live Cocoon 
instance it would not be too hard (just in XSLT) to harvest a lot of useful lucene 
fields from the xdocs, wiki docs, mail archives, etc. Java class names, namespace 
URIs, sitemap tags, etc, are all there already, and could all be used to pull the docs 
together into a more topical framework.

Cheers

Con

Re: [RT] doco lite?

[Helma van der Linden]

Upayavira wrote:
GOALS

G4. Make submitting documentation a more straight forward process. I 
haven't yet looked at the ins and outs of the xdocs, but I know from the 
times I tried to find the documentation in the checked out tree that I 
was unable to figure out how it worked.

TOOLS / TECHNIQUES

1)Does all this actually make the documentation any better?
2)Should any effort towards documentation ATM go into improving its 
*quality* or improving its 
{searchability|updateability|scaleability|auto-generateability}
Unless the proposal will (also) lead to simple way of adding 
documentation (and I'm thinking about only slightly more difficult than 
the wiki), I think this process will result in a technical overhaul 
without improving the quality of the documentation.

As we discussed at the hackathon, I think both are concerns that 
interrelate, and effort can be applied separately to either.
True, but, at the moment all discussions about documentation tend to 
sway into the technical area and the actual writing is forgotten.

As it is, we have a complex system that few people know how to operate. 
I've written docs, but I've never deployed them to the site. This acts 
as a dis-incentive to existing and potential documentation writers.
Put them in the wiki! Why haven't you done so, yet? :-)
Other than that, we have a xdocs system that does work, and a wiki that 
works. We can use right now to write better docs. We just need to make 
the effort.
By all means, do implement this proposal if everyone feels it improves 
the infrastructure of the documentation. I will immediately agree to any 
proposal that will simplify the documentation generation process which 
will improve the update frequency.
However, we should also think about how to get the quality of the 
documentation updated and how to encourage potential documentation 
writers to actually sit down and produce the actual text.

Bye, Helma

Re: Let's deprecate the PHP block

[Luigi Bai]

On Tue, 26 Oct 2004, Stefano Mazzocchi wrote:
Luigi Bai wrote:
On Tue, 26 Oct 2004, Stefano Mazzocchi wrote:
forth: some of us spend a great amount of their life trying to come up 
with strategies that avoid the use of those rules, and understand how 
complex groups form and dissolve, how innovation happens and how community 
fractures can be avoided. When shit works well, like this project, it's 
easy to think it 'just happened' and much harder to see all the social 
work that made it possible, including allowing informal votes to happen 
and keeping rules to a bare minimum.

Maybe it is more precise to say "When shit works /mostly/ well...". The 
presence of a large number of outstanding Bugzilla issues, especially ones 
with [PATCH]es attached, implies that things work well for committers, less 
well for those of us who have to wait until "someone just gets around to 
it". Fixing bugs isn't sexy, like Flow or Forms or Real Blocks. But it 
should happen every once in a while, especially when other people have 
already proposed the patches.
If you have ideas on how to make it better, we are wide open to suggestions.
Okay, assuming your sincerity - what is the current method for committers 
to find/fix/close issues in Bugzilla? Are votes used, or longest time 
open, number of comments? How often are these criteria applied 
(periodically, only FirstFriday, only before release)?

Knowing these, we can figure out a way to improve the system, or the 
users's expectations (or both!).

Luigi

Re: Let's deprecate the PHP block

[Nicola Ken Barozzi]

Stefano Mazzocchi wrote:
...
If you have ideas on how to make it better, we are wide open to 
suggestions.
Making the Subject match the content of this thread would be a good start.
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

Re: Let's deprecate the PHP block

[Stefano Mazzocchi]

Luigi Bai wrote:
On Tue, 26 Oct 2004, Stefano Mazzocchi wrote:
forth: some of us spend a great amount of their life trying to come up 
with strategies that avoid the use of those rules, and understand how 
complex groups form and dissolve, how innovation happens and how 
community fractures can be avoided. When shit works well, like this 
project, it's easy to think it 'just happened' and much harder to see 
all the social work that made it possible, including allowing informal 
votes to happen and keeping rules to a bare minimum.

Maybe it is more precise to say "When shit works /mostly/ well...". The 
presence of a large number of outstanding Bugzilla issues, especially 
ones with [PATCH]es attached, implies that things work well for 
committers, less well for those of us who have to wait until "someone 
just gets around to it". Fixing bugs isn't sexy, like Flow or Forms or 
Real Blocks. But it should happen every once in a while, especially when 
other people have already proposed the patches.
If you have ideas on how to make it better, we are wide open to suggestions.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Let's deprecate the PHP block

[Luigi Bai]

On Tue, 26 Oct 2004, Stefano Mazzocchi wrote:
forth: some of us spend a great amount of their life trying to come up with 
strategies that avoid the use of those rules, and understand how complex 
groups form and dissolve, how innovation happens and how community fractures 
can be avoided. When shit works well, like this project, it's easy to think 
it 'just happened' and much harder to see all the social work that made it 
possible, including allowing informal votes to happen and keeping rules to a 
bare minimum.

Maybe it is more precise to say "When shit works /mostly/ well...". The 
presence of a large number of outstanding Bugzilla issues, especially ones 
with [PATCH]es attached, implies that things work well for committers, 
less well for those of us who have to wait until "someone just gets around 
to it". Fixing bugs isn't sexy, like Flow or Forms or Real Blocks. But it 
should happen every once in a while, especially when other people have 
already proposed the patches.

Luigi

Re: [RT] doco lite?

[Frédéric Glorieux]

G3. Index the latest version of the docs, including structured fields 
(keywords, target audience, components mentioned, etc), to implement 
"prepared queries" (as links, simply) to improve our docs' accessibility
It seems a good occasion to provide a better LuceneTransformer 
implementation for cocoon ?

T2. Build an index with Lucene, triggered via SVN post-commit hooks, 
uses a live Cocoon instance to generate an easy to index XML document 
for Lucene. Include metadata fields as mentioned in G2 above, generated 
from (enhanced as compared to now) document content
I'm working on that (nto enough), it seems to me only a consequence of 
upper.


  
  
  
  
  

myschema2lucene.xsl handle the original doc, let everything pass but add 
something for indexation


  
  










  
  

The Lucene transformer handle  and let other things go for 
publish.

If [EMAIL PROTECTED] haven't changed, should be cached, so not too much 
transform and indexation, if not, index is update.

For delete, a hook from SVN is needed.
T4. Use queries like "find all documents which talk about sitemap 
matchers" to build navigation pages semi-automatically.
After some experience of cocoon with lucene, don't forget list of terms 
(from untokenized fields), because it allows you to have the list of 
existing keywords (for example), so that you can generate your queries 
on what you have in your docs (instead of constraints on vocabularies 
for production).

T5. Put mod_cache in front to minimize server load (HTTP POST can be 
used to invalidate pages if quick updates are needed to check edits).
You give me the trick for something that I was asking to Sylvain, a kind 
of pure cocoon mod_cache with 

http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=109636070505876&w=2
problem was update. The cocoon app produces a regular www folder 
directly served for public by an httpd, update could be a consequence of 
SVN hook, and il nothing works, there's still the handling of HTTP POST 
to force update from www.

Frédéric.
--
Frédéric Glorieux (ingénieur documentaire, AJLSM)

Re: Let's deprecate the PHP block

[Stefano Mazzocchi]

I'm trying really really really hard not to reply to this but I can't.
Frédéric Glorieux wrote:
For computing, you are really incredible guys, but for politics, I'm 
sorry to say that but you are "reinventing the wheel". Rules are not 
"bureaucratic" but the only way to have a stable democracy, which is the 
less unefficient governement (for long periods).
first: we are not doing politics, not establishing a government, nor we 
believe in democratic development metodologies.

second: I've been around open source long enough to know that rules are 
necessary, *BUT* I've also seeing people that love rules more than the 
reason why they exist. Rules are not made to create cages, but 
guidelines. Our philosophy follows the Postel principle for internet 
architectural design: "be strict in what you send, be flexible in what 
you receive".

third: if there is one thing that the ASF never did was to "reinvent the 
wheel" in the labor collaboration and management space. Several business 
schools of the major universities of the world are studying how we 
managed to achive what we achieved. Some of them believe this is some of 
the most innovative critique of existing labor cooperation since Marx.

forth: some of us spend a great amount of their life trying to come up 
with strategies that avoid the use of those rules, and understand how 
complex groups form and dissolve, how innovation happens and how 
community fractures can be avoided. When shit works well, like this 
project, it's easy to think it 'just happened' and much harder to see 
all the social work that made it possible, including allowing informal 
votes to happen and keeping rules to a bare minimum.

Now, go back and re-read my comments under this light.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] doco lite?

[Upayavira]

Bertrand Delacretaz wrote:
Le 26 oct. 04, à 21:20, Upayavira a écrit :
...The thing you seem to have missed is the staging process. If I 
have written an xdoc, I want to see that as HTML, on a staging 
server, before I actually publish it. After all, the XML might not 
even be valid, or there might be mistakes. I need to be able to see 
the page on the site before I publish it...

How about using SVN tags for this?
-Current known good version of the docs is always tagged as 
"current-docs"
-Website serves this tagged version on the public site
-New docs releases are done by moving this tag to the appropriate 
revision (I didn't try moving tags in SVN yet but it shouldn't be a 
problem)

Then you'd use the current release for the staging process, and update 
the public version by moving the SVN tag.
So you'd use HEAD or whatever to view the latest commit, and the public 
would see the "current-docs" tag. That could work. But would we want the 
HEAD to be password protected, or in some way hidden so that it doesn't 
get regularly viewed when it isn't live yet? I like the idea of being 
able to tag the docs whenever we release. If we can get the available 
tags for a document from SVN, we could have a dropdown that allows you 
to see the docs for a specific version, which would be absolutely 
fantastic. That would solve soo many problems.

So, when do you start?
Regards, Upayavira

Re: [RT] doco lite?

[Upayavira]

Jorg Heymans wrote:

Bertrand Delacretaz wrote:
GOALS
G1. Generate our docs and website dynamically, directly from the SVN 
repository accessed over http
G2. Give access to older versions of the docs using standard SVN 
mechanisms (tags etc)
G3. Index the latest version of the docs, including structured fields 
(keywords, target audience, components mentioned, etc), to implement 
"prepared queries" (as links, simply) to improve our docs' accessibility

TOOLS / TECHNIQUES
T1. Get content from SVN, editing is considered a separate problem
T2. Build an index with Lucene, triggered via SVN post-commit hooks, 
uses a live Cocoon instance to generate an easy to index XML document 
for Lucene. Include metadata fields as mentioned in G2 above, 
generated from (enhanced as compared to now) document content

T3. Generate pages using a live Cocoon instance, maybe Forrest. SVN 
tags "pass through" the URLs to give access to older releases of the 
docs.

T4. Use queries like "find all documents which talk about sitemap 
matchers" to build navigation pages semi-automatically.

T5. Put mod_cache in front to minimize server load (HTTP POST can be 
used to invalidate pages if quick updates are needed to check edits).

WDYT?

I pondered long (well, about 5 minutes) and hard on how to correctly 
phrase the first two things that came to my mind when I read your 
proposal - so here goes :

1)Does all this actually make the documentation any better?
2)Should any effort towards documentation ATM go into improving its 
*quality* or improving its 
{searchability|updateability|scaleability|auto-generateability}
As we discussed at the hackathon, I think both are concerns that 
interrelate, and effort can be applied separately to either.

As it is, we have a complex system that few people know how to operate. 
I've written docs, but I've never deployed them to the site. This acts 
as a dis-incentive to existing and potential documentation writers.

Other than that, we have a xdocs system that does work, and a wiki that 
works. We can use right now to write better docs. We just need to make 
the effort.

So I think both are valid - documentation quality and publication tools.
Regards, Upayavira

Re: Let's deprecate the PHP block

[Frédéric Glorieux]

One trouble is that Cocoon does not yet have any
project guidelines. Another trouble is that people
seem to use the +1 thing even when a vote is not
happening. The proposal phase for the discussion,
then the vote phase for the decision, is an Apache
way to get things done efficiently. We forget that.
Please, don't get over-bureaucratic. We've got governments for this (and yes, 
this CMM thingy as well).

No, it is not bureaucratic. It is about efficiency.
Sorry to interfer in a debate in which I have no voice (in spite of my 
account). It's not about PHP block (even if I'm +1 on that), but I can't 
let alone David Crossley (I never met) with his common sense opinion. 
For computing, you are really incredible guys, but for politics, I'm 
sorry to say that but you are "reinventing the wheel". Rules are not 
"bureaucratic" but the only way to have a stable democracy, which is the 
less unefficient governement (for long periods).  This was only because 
I can't let a true assertion without any support, sorry for any trouble.

--
Frédéric Glorieux (ingénieur documentaire, AJLSM)

Re: [RT] doco lite?

[Jorg Heymans]

Bertrand Delacretaz wrote:
GOALS
G1. Generate our docs and website dynamically, directly from the SVN 
repository accessed over http
G2. Give access to older versions of the docs using standard SVN 
mechanisms (tags etc)
G3. Index the latest version of the docs, including structured fields 
(keywords, target audience, components mentioned, etc), to implement 
"prepared queries" (as links, simply) to improve our docs' accessibility

TOOLS / TECHNIQUES
T1. Get content from SVN, editing is considered a separate problem
T2. Build an index with Lucene, triggered via SVN post-commit hooks, 
uses a live Cocoon instance to generate an easy to index XML document 
for Lucene. Include metadata fields as mentioned in G2 above, generated 
from (enhanced as compared to now) document content

T3. Generate pages using a live Cocoon instance, maybe Forrest. SVN tags 
"pass through" the URLs to give access to older releases of the docs.

T4. Use queries like "find all documents which talk about sitemap 
matchers" to build navigation pages semi-automatically.

T5. Put mod_cache in front to minimize server load (HTTP POST can be 
used to invalidate pages if quick updates are needed to check edits).

WDYT?
I pondered long (well, about 5 minutes) and hard on how to correctly 
phrase the first two things that came to my mind when I read your 
proposal - so here goes :

1)Does all this actually make the documentation any better?
2)Should any effort towards documentation ATM go into improving its 
*quality* or improving its 
{searchability|updateability|scaleability|auto-generateability}

WDYT?
Jorg

Re: HtmlCleaningConvertor

[Bruno Dumon]

On Mon, 2004-10-25 at 18:38 +0200, Reinhard Poetz wrote:
> While browsing Daisy I saw a very interesting cForms extension in Daisy: the 
> HtmlCleaningConvertor. Are there any plans to move it to Cocoon?

Didn't think of that yet. Keeping it with Daisy would make it follow
Daisy releases, which is somewhat easier for us at this stage.

You also have to know that the htmlcleaner is quite strict, in that it
drops all elements and attributes that are not explicitely allowed
(configurable using an XML file), which is exactly what we wanted for
Daisy, but might be different for other use-cases.

>  I think this 
> could be valuable for many other users.

Nothing prevents reuse of course. The htmlcleaner is an independent
library, bundled in its own jar, with minimal dependencies
(nekohtml/nekodtd, which in itself requires xerces). The
HtmlCleaningConvertor and HtmlCleaningConvertorBuilder classes that do
the integration with Cocoon would need to be copied to your own project.

Another possibility would be to just move those last two classes to
Cocoon, and add the daisy-htmlcleaner.jar as an external dependency to
cforms.

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: Let's deprecate the PHP block

[JD Daniels]

Torsten Curdt wrote:
+1
...I guess noone really used it anyway
--
Torsten

I really really really tried when I first moved to cocoon :(
JD

Re: [RT] doco lite?

[Bertrand Delacretaz]

Le 26 oct. 04, à 21:23, Scherler, Thorsten a écrit :
To understand it right you do not want online editing, workflow,... 
right?
Why not, but separating this concern from the publishing process makes 
the problem easier to tackle IMHO.

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

Re: [RT] doco lite?

[Bertrand Delacretaz]

Le 26 oct. 04, à 21:20, Upayavira a écrit :
...The thing you seem to have missed is the staging process. If I have 
written an xdoc, I want to see that as HTML, on a staging server, 
before I actually publish it. After all, the XML might not even be 
valid, or there might be mistakes. I need to be able to see the page 
on the site before I publish it...
How about using SVN tags for this?
-Current known good version of the docs is always tagged as 
"current-docs"
-Website serves this tagged version on the public site
-New docs releases are done by moving this tag to the appropriate 
revision (I didn't try moving tags in SVN yet but it shouldn't be a 
problem)

Then you'd use the current release for the staging process, and update 
the public version by moving the SVN tag.

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

Re: [RT] doco lite?

[Scherler, Thorsten]

To understand it right you do not want online editing, workflow,... right?
Sounds like a nice start for doco. Small, slim and lite. ;-)
thorsten
Antonio Gallardo escribió:
Bertrand Delacretaz dijo:
Recent discussions here, along with David's "ASF-wide documentation
staging and publishing" post to infrastructure@ made me think about
this, in a "there must be an easier way" mood. I'm not ready to discuss
this on  infrastructure@ though, it feels safer here ATM ;-)
The apparently realistic possibility of having a live instance of
Cocoon could make it much easier to handle our docs and website, and
unless I'm overlooking something important the concept described below
seems really simple to implement. So I cannot refrain from sharing this
idea, although I have no code to back it up yet...
GOALS
G1. Generate our docs and website dynamically, directly from the SVN
repository accessed over http
G2. Give access to older versions of the docs using standard SVN
mechanisms (tags etc)
G3. Index the latest version of the docs, including structured fields
(keywords, target audience, components mentioned, etc), to implement
"prepared queries" (as links, simply) to improve our docs'
accessibility
TOOLS / TECHNIQUES
T1. Get content from SVN, editing is considered a separate problem
T2. Build an index with Lucene, triggered via SVN post-commit hooks,
uses a live Cocoon instance to generate an easy to index XML document
for Lucene. Include metadata fields as mentioned in G2 above, generated
from (enhanced as compared to now) document content
T3. Generate pages using a live Cocoon instance, maybe Forrest. SVN
tags "pass through" the URLs to give access to older releases of the
docs.
T4. Use queries like "find all documents which talk about sitemap
matchers" to build navigation pages semi-automatically.
T5. Put mod_cache in front to minimize server load (HTTP POST can be
used to invalidate pages if quick updates are needed to check edits).

Is very nice and seems to be easy reachable! I will add:
T6. Build javadocs directly from the SVN too. Maybe using "qdox.jar"
Best Regards,
Antonio Gallardo
/me wondering how Bertrand usually comes with so simple and powerfull
solutions. ;-)

Re: [RT] doco lite?

[Upayavira]

Bertrand Delacretaz wrote:
Recent discussions here, along with David's "ASF-wide documentation 
staging and publishing" post to infrastructure@ made me think about 
this, in a "there must be an easier way" mood. I'm not ready to 
discuss this on  infrastructure@ though, it feels safer here ATM ;-)

The apparently realistic possibility of having a live instance of 
Cocoon could make it much easier to handle our docs and website, and 
unless I'm overlooking something important the concept described below 
seems really simple to implement. So I cannot refrain from sharing 
this idea, although I have no code to back it up yet...

GOALS
G1. Generate our docs and website dynamically, directly from the SVN 
repository accessed over http
G2. Give access to older versions of the docs using standard SVN 
mechanisms (tags etc)
G3. Index the latest version of the docs, including structured fields 
(keywords, target audience, components mentioned, etc), to implement 
"prepared queries" (as links, simply) to improve our docs' accessibility

TOOLS / TECHNIQUES
T1. Get content from SVN, editing is considered a separate problem
T2. Build an index with Lucene, triggered via SVN post-commit hooks, 
uses a live Cocoon instance to generate an easy to index XML document 
for Lucene. Include metadata fields as mentioned in G2 above, 
generated from (enhanced as compared to now) document content

T3. Generate pages using a live Cocoon instance, maybe Forrest. SVN 
tags "pass through" the URLs to give access to older releases of the 
docs.

T4. Use queries like "find all documents which talk about sitemap 
matchers" to build navigation pages semi-automatically.

T5. Put mod_cache in front to minimize server load (HTTP POST can be 
used to invalidate pages if quick updates are needed to check edits).

WDYT?
The thing you seem to have missed is the staging process. If I have 
written an xdoc, I want to see that as HTML, on a staging server, before 
I actually publish it. After all, the XML might not even be valid, or 
there might be mistakes. I need to be able to see the page on the site 
before I publish it.

Thoughts?
Regards,
Upayavira

Re: [RT] doco lite?

[Antonio Gallardo]

Bertrand Delacretaz dijo:
> Recent discussions here, along with David's "ASF-wide documentation
> staging and publishing" post to infrastructure@ made me think about
> this, in a "there must be an easier way" mood. I'm not ready to discuss
> this on  infrastructure@ though, it feels safer here ATM ;-)
>
> The apparently realistic possibility of having a live instance of
> Cocoon could make it much easier to handle our docs and website, and
> unless I'm overlooking something important the concept described below
> seems really simple to implement. So I cannot refrain from sharing this
> idea, although I have no code to back it up yet...
>
> GOALS
> G1. Generate our docs and website dynamically, directly from the SVN
> repository accessed over http
> G2. Give access to older versions of the docs using standard SVN
> mechanisms (tags etc)
> G3. Index the latest version of the docs, including structured fields
> (keywords, target audience, components mentioned, etc), to implement
> "prepared queries" (as links, simply) to improve our docs'
> accessibility
>
> TOOLS / TECHNIQUES
> T1. Get content from SVN, editing is considered a separate problem
>
> T2. Build an index with Lucene, triggered via SVN post-commit hooks,
> uses a live Cocoon instance to generate an easy to index XML document
> for Lucene. Include metadata fields as mentioned in G2 above, generated
> from (enhanced as compared to now) document content
>
> T3. Generate pages using a live Cocoon instance, maybe Forrest. SVN
> tags "pass through" the URLs to give access to older releases of the
> docs.
>
> T4. Use queries like "find all documents which talk about sitemap
> matchers" to build navigation pages semi-automatically.
>
> T5. Put mod_cache in front to minimize server load (HTTP POST can be
> used to invalidate pages if quick updates are needed to check edits).

Is very nice and seems to be easy reachable! I will add:

T6. Build javadocs directly from the SVN too. Maybe using "qdox.jar"

Best Regards,

Antonio Gallardo

/me wondering how Bertrand usually comes with so simple and powerfull
solutions. ;-)

Re: Let's deprecate the PHP block

[Torsten Curdt]

+1
...I guess noone really used it anyway
--
Torsten

[GUMP@brutus]: Project cocoon (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon has an issue affecting its community integration.
This issue affects 56 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon :  Java XML Framework
- cocoon-block-apples :  Java XML Framework
- cocoon-block-asciiart :  Java XML Framework
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-axis :  Java XML Framework
- cocoon-block-batik :  Java XML Framework
- cocoon-block-bsf :  Java XML Framework
- cocoon-block-chaperon :  Java XML Framework
- cocoon-block-cron :  Java XML Framework
- cocoon-block-databases :  Java XML Framework
- cocoon-block-deli :  Java XML Framework
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-faces :  Java XML Framework
- cocoon-block-fop :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-hsqldb :  Java XML Framework
- cocoon-block-html :  Java XML Framework
- cocoon-block-itext :  Java XML Framework
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-jfor :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-jsp :  Java XML Framework
- cocoon-block-linkrewriter :  Java XML Framework
- cocoon-block-linotype :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-mail :  Java XML Framework
- cocoon-block-midi :  Java XML Framework
- cocoon-block-naming :  Java XML Framework
- cocoon-block-ojb :  Java XML Framework
- cocoon-block-paranoid :  Java XML Framework
- cocoon-block-petstore :  Java XML Framework
- cocoon-block-php :  Java XML Framework
- cocoon-block-poi :  Java XML Framework
- cocoon-block-portal :  Java XML Framework
- cocoon-block-portal-fw :  Java XML Framework
- cocoon-block-profiler :  Java XML Framework
- cocoon-block-proxy :  Java XML Framework
- cocoon-block-python :  Java XML Framework
- cocoon-block-qdox :  Java XML Framework
- cocoon-block-repository :  Java XML Framework
- cocoon-block-scratchpad :  Java XML Framework
- cocoon-block-serializers :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework
- cocoon-block-slide :  Java XML Framework
- cocoon-block-slop :  Java XML Framework
- cocoon-block-stx :  Java XML Framework
- cocoon-block-taglib :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- cocoon-block-velocity :  Java XML Framework
- cocoon-block-web3 :  Java XML Framework
- cocoon-block-webdav :  Java XML Framework
- cocoon-block-woody :  Java XML Framework
- cocoon-block-xmldb :  Java XML Framework
- cocoon-block-xsp :  Java XML Framework
- forrest :  Apache Forrest is an XML standards-oriented documentation fr...
- lenya :  Content Management System


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon]
 -DEBUG- Output [cocoon-tests.jar] identifier set to output basename: [cocoon-tests]
 -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: 
[cocoon-deprecated]
 -DEBUG- Dependency on avalon-framework-api exists, no need to add for property 
avalonapi.jar.
 -INFO- Made directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-26102004/test]
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/cocoon/build/cocoon-26102004/test/output
 -WARNING- No directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-26102004/test/output]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html
Work Name: build_cocoon_cocoon (Type: Build)
Work ended in a state of : Failed
Elapsed: 2 mins 2 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
-Davalonapi.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/d

Re: Cocoon and JDK 1.5

[Antonio Gallardo]

Hi Bert:

Thnks for the effort. Please see this:

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

I think the next release is soon.

Best Regards,

Antonio Gallardo

[RT] doco lite?

[Bertrand Delacretaz]

Recent discussions here, along with David's "ASF-wide documentation 
staging and publishing" post to infrastructure@ made me think about 
this, in a "there must be an easier way" mood. I'm not ready to discuss 
this on  infrastructure@ though, it feels safer here ATM ;-)

The apparently realistic possibility of having a live instance of 
Cocoon could make it much easier to handle our docs and website, and 
unless I'm overlooking something important the concept described below 
seems really simple to implement. So I cannot refrain from sharing this 
idea, although I have no code to back it up yet...

GOALS
G1. Generate our docs and website dynamically, directly from the SVN 
repository accessed over http
G2. Give access to older versions of the docs using standard SVN 
mechanisms (tags etc)
G3. Index the latest version of the docs, including structured fields 
(keywords, target audience, components mentioned, etc), to implement 
"prepared queries" (as links, simply) to improve our docs' 
accessibility

TOOLS / TECHNIQUES
T1. Get content from SVN, editing is considered a separate problem
T2. Build an index with Lucene, triggered via SVN post-commit hooks, 
uses a live Cocoon instance to generate an easy to index XML document 
for Lucene. Include metadata fields as mentioned in G2 above, generated 
from (enhanced as compared to now) document content

T3. Generate pages using a live Cocoon instance, maybe Forrest. SVN 
tags "pass through" the URLs to give access to older releases of the 
docs.

T4. Use queries like "find all documents which talk about sitemap 
matchers" to build navigation pages semi-automatically.

T5. Put mod_cache in front to minimize server load (HTTP POST can be 
used to invalidate pages if quick updates are needed to check edits).

WDYT?
-Bertrand




smime.p7s
Description: S/MIME cryptographic signature

Re: Howto drive response payload directly

[Mark Lundquist]

On Oct 26, 2004, at 3:46 AM, Vadim Gritsenko wrote:

Ugo Cei wrote:
Il giorno 26/ott/04, alle 08:54, Leszek Gawron ha scritto:
Mark Lundquist wrote:

Hi,
I have a Java object persisted using Hibernate... it contains an image (java.sql.Blob) that I need to serve. I can get the object in flowscript, now I just need to stream out this data (e.g. "image.getBinaryStream()"). How can I do this?
Thanks,
/~ml
/

I think you should implement a Reader or a new Source.
A Reader is the way to go.

Existing ResourceReader and one of the existing sources reading data from request attribute should work just fine in ths case. Probably, flow attribute input module.

Vadim\

Thx Vadim (and also Ugo for bringing this over from the users' list)...  I will check into this!
~ml

Re: Let's deprecate the PHP block

[Bertrand Delacretaz]

Le 26 oct. 04, à 18:19, Sylvain Wallez a écrit :
...Yup. You can even have a T-Shirt with it: 
http://www.cafepress.com/meepzor.10338499
Wow. +1 ;-)
-Bertrand

smime.p7s
Description: S/MIME cryptographic signature

Re: svn commit: rev 55619 - in cocoon/branches/BRANCH_2_1_X/src: test/anteater webapp/samples/test/reader-mime-type

[Vadim Gritsenko]

Unico Hommes wrote:
Now only one release blocker remains: NPE in AbstractEnvironment.release()
No, not exactly. As I see it, ResourceReader should return Source's mimeType in 
this particular case, as per:

public String getMimeType() {
Context ctx = ObjectModelHelper.getContext(objectModel);
if (ctx != null) {
final String mimeType = ctx.getMimeType(source);
if (mimeType != null) {
return mimeType;
}
}
return inputSource.getMimeType();
}
But in this case, it was not able to get mime type of the SitemapSource. 
SitemapSource, in its turn, was retrieving mimeType from the environment:

344:this.mimeType = this.environment.getContentType();
But for some reason it is not there. I think that is the problem and it was a 
valid test case for this problem. Unless I am mistaken... If I'm not, we should 
revert the removal of test case.

Vadim

--
Unico
[EMAIL PROTECTED] wrote:
Author: unico
Date: Tue Oct 26 10:07:04 2004
New Revision: 55619
Modified:
  cocoon/branches/BRANCH_2_1_X/src/test/anteater/reader-mime-type.xml
  
cocoon/branches/BRANCH_2_1_X/src/webapp/samples/test/reader-mime-type/explain-test.xml 

  
cocoon/branches/BRANCH_2_1_X/src/webapp/samples/test/reader-mime-type/sitemap.xmap 

Log:
remove testcase that no longer complies with expected behavior:
internal requests should not be able to alter response headers
as discussed in http://marc.theaimsgroup.com/?t=10978326015&r=1&w=2
 

Re: svn commit: rev 55619 - in cocoon/branches/BRANCH_2_1_X/src: test/anteater webapp/samples/test/reader-mime-type

[Unico Hommes]

Now only one release blocker remains: NPE in AbstractEnvironment.release()
--
Unico
[EMAIL PROTECTED] wrote:
Author: unico
Date: Tue Oct 26 10:07:04 2004
New Revision: 55619
Modified:
  cocoon/branches/BRANCH_2_1_X/src/test/anteater/reader-mime-type.xml
  
cocoon/branches/BRANCH_2_1_X/src/webapp/samples/test/reader-mime-type/explain-test.xml
  cocoon/branches/BRANCH_2_1_X/src/webapp/samples/test/reader-mime-type/sitemap.xmap
Log:
remove testcase that no longer complies with expected behavior:
internal requests should not be able to alter response headers 

as discussed in http://marc.theaimsgroup.com/?t=10978326015&r=1&w=2
 

Re: getInputStream() in FOM_Cocoon.FOM_Request ?

[Unico Hommes]

This seemed to be related to the removal of instrumentation from the 
axis block. Should be fixed now.

--
Unico
Tim Larson wrote:
On Tue, Oct 26, 2004 at 01:49:24PM +0200, Unico Hommes wrote:
 

On 24-okt-04, at 13:47, Unico Hommes wrote:
   

The Request interface itself does not have getInputStream method, only 
HttpRequest does. So first step would be to add getInputStream method 
to the Request and then add it to FOM.
 

Done. I've applied the changes to the trunk only for now because I had 
to do an incompatible change. HttpRequest.getInputStream method 
returned ServletInputStream which has been changed to InputStream. 
Should I port the changes to the branch anyway ? I've also deprecated 
ActionRequest.getPortletInputStream in the portlet environment.
   

Accessing the root page from a clean build of the trunk gives:
Initialization Problem
Message: Error during configuration
Description: org.apache.avalon.framework.configuration.ConfigurationException: Error 
during configuration
Sender: org.apache.cocoon.servlet.CocoonServlet
Source: Cocoon Servlet
cause
java.lang.NullPointerException
request-uri
/
full exception chain stacktrace
org.apache.avalon.framework.configuration.ConfigurationException: Error during 
configuration
at 
org.apache.cocoon.components.axis.SoapServerImpl.configure(SoapServerImpl.java:207)
at 
org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:240)
at 
org.apache.cocoon.core.container.ComponentFactory.newInstance(ComponentFactory.java:131)

Caused by: java.lang.NullPointerException
at 
org.apache.excalibur.source.impl.ResourceSource.getInputStream(ResourceSource.java:97)
at 
org.apache.cocoon.components.axis.SoapServerImpl.setManagedServices(SoapServerImpl.java:366)
at 
org.apache.cocoon.components.axis.SoapServerImpl.configure(SoapServerImpl.java:201)

--Tim Larson
 

Re: Let's deprecate the PHP block

[Sylvain Wallez]

Bertrand Delacretaz wrote:
Le 26 oct. 04, à 17:41, Stefano Mazzocchi a écrit :
..Bah, burocrats.

;-)
I see David's point though, using [VOTE] in subject (and [PROPOSAL] 
maybe) helps in not missing stuff that's happening.

But I like our +1 way of saying "me? I like it" even if outside of a 
vote - it's part of our "slang" I think.

Yup. You can even have a T-Shirt with it: 
http://www.cafepress.com/meepzor.10338499

So +1 on being more careful with [appropriate headers] in subjects ;-)

+1 also :-p
And +1 to deprecate the PHP block :-D
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: Let's deprecate the PHP block

[Stefano Mazzocchi]

Bertrand Delacretaz wrote:
Le 26 oct. 04, à 17:41, Stefano Mazzocchi a écrit :
..Bah, burocrats.

;-)
I see David's point though, using [VOTE] in subject (and [PROPOSAL] 
maybe) helps in not missing stuff that's happening.

But I like our +1 way of saying "me? I like it" even if outside of a 
vote - it's part of our "slang" I think.

So +1 on being more careful with [appropriate headers] in subjects ;-)
I hear you and I agree.
But one thing is saying "next time use [vote] so that people don't miss 
it", another is "start over and follow the rules".

The first is common sense, the second is burocracy.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

DO NOT REPLY [Bug 30040] - JS 'popups' are rendered behind select lists and applets.

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

JS 'popups' are rendered behind select lists and applets.





--- Additional Comments From [EMAIL PROTECTED]  2004-10-26 15:57 ---
This fix doesn't work in Firefox, all popups are rendered on the left bottom
side of the screen and they don't disappear anymore. 

Note that the Firefox does not suffer from the bug this patch was originally
created for.

Re: Let's deprecate the PHP block

[Joerg Heinicke]

On 26.10.2004 15:11, Antonio Gallardo wrote:
Let's deprecate the PHP block for the remainder of our 2.1.X releases
and then dump it in 2.2.  If people want to "use" PHP with Cocoon, the
best solution is to just use a FileGenerator and an http:// URL.

Seems we are alredy voting on that. Here is mine:
also +1
NOTE: Please add a user doc page to show people how they can use PHP with
Cocoon. Outthere is a lot of people doing PHP stuff and a path to go into
Cocoon will be fine for them.
The problem is just that the PHP block does not work. If we reactivate 
it, we do not need to deprecate it :)

Joerg

Re: Let's deprecate the PHP block

[Bertrand Delacretaz]

Le 26 oct. 04, à 17:41, Stefano Mazzocchi a écrit :
..Bah, burocrats.
;-)
I see David's point though, using [VOTE] in subject (and [PROPOSAL] 
maybe) helps in not missing stuff that's happening.

But I like our +1 way of saying "me? I like it" even if outside of a 
vote - it's part of our "slang" I think.

So +1 on being more careful with [appropriate headers] in subjects ;-)
-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

Re: Let's deprecate the PHP block

[Tony Collen]

Stefano Mazzocchi wrote:
Oh, c'mon, we have a gazillion +1 and no -1, go ahead and deprecate it.
It's not like we can't reverse the thing if a -1 shows up.
Bah, burocrats.
Sir, I'll have to ask you to file a formal complaint, and you can expect 
a response in 6 to 8 weeks. :) :)

Tony

Re: Let's deprecate the PHP block

[Stefano Mazzocchi]

Tony Collen wrote:
Bertrand Delacretaz wrote:
+1, I agree with the formal vote but if you start it by counting all 
the +1s here we don't need to vote again.

Alright, well I guess I phrased my message as a pseudo-vote, so the 
confusion is my fault!

Anyway, I'l count the existing votes as if it were an official vote 
through Thursday night GMT.  If anybody who's already voted wants to 
change their mind in the meantime, go ahead (but it doesn't seem likely).

Here's my implicit +1, too.
Oh, c'mon, we have a gazillion +1 and no -1, go ahead and deprecate it.
It's not like we can't reverse the thing if a -1 shows up.
Bah, burocrats.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Let's deprecate the PHP block

[Stefano Mazzocchi]

David Crossley wrote:
No, it is not bureaucratic. It is about efficiency.
That's what bureaucrats always say ;-)
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Let's deprecate the PHP block

[Tony Collen]

Bertrand Delacretaz wrote:
+1, I agree with the formal vote but if you start it by counting all the 
+1s here we don't need to vote again.
Alright, well I guess I phrased my message as a pseudo-vote, so the 
confusion is my fault!

Anyway, I'l count the existing votes as if it were an official vote 
through Thursday night GMT.  If anybody who's already voted wants to 
change their mind in the meantime, go ahead (but it doesn't seem likely).

Here's my implicit +1, too.
Tony

RE: Portal - coplet instance data attributes

[Ralph Goers]

I'm noticing that the mapping file for copletinstancedata specifies that
AttributesFieldHandler should be used.  I haven't used Castor much, but it
seems I could make a simple change to that class to make sure it gets only
the attributes from copletinstancedata when necessary.  If so, would that
fix the problem?  I could then make the copletinstancedata getAttributes
and getAttribute methods use the lists in copletinstancedata and
copletdata.  That would minimize the amount of code I'd need to change in
other classes.

I guess the real question is, does Castor retrieve the data through the
AttributesFieldHandler class when building the XML?

Ralph


Carsten Ziegeler said:
> Hmm, I really can't remember everything. Now one problem was that if
> you save the objects to XML, you can't save all available attributes
> for the instance. You have to filter and only save the attributes that
> are part of the instance and not those of the coplet data.
>
> An additional problem is removing of attributes etc. What do you do if
> the attribute you want to remove is not an attribute of the instance?
> Do you delegate it to the data object? And so on.
> Now, rethinkink everything, perhaps the simplest solutions is to leave
> everything as it is and only add a "get value from all attributes method",
> which is just a getter method that first looks in the instance and then
> in the coplet data object. But for setting and removing everything could
> be left unchanged.
>
> HTH
> Carsten

>

Re: getInputStream() in FOM_Cocoon.FOM_Request ?

[Tim Larson]

On Tue, Oct 26, 2004 at 01:49:24PM +0200, Unico Hommes wrote:
> On 24-okt-04, at 13:47, Unico Hommes wrote:
> >The Request interface itself does not have getInputStream method, only 
> >HttpRequest does. So first step would be to add getInputStream method 
> >to the Request and then add it to FOM.
> 
> Done. I've applied the changes to the trunk only for now because I had 
> to do an incompatible change. HttpRequest.getInputStream method 
> returned ServletInputStream which has been changed to InputStream. 
> Should I port the changes to the branch anyway ? I've also deprecated 
> ActionRequest.getPortletInputStream in the portlet environment.

Accessing the root page from a clean build of the trunk gives:

Initialization Problem
Message: Error during configuration
Description: org.apache.avalon.framework.configuration.ConfigurationException: Error 
during configuration
Sender: org.apache.cocoon.servlet.CocoonServlet
Source: Cocoon Servlet
cause
java.lang.NullPointerException
request-uri
/
full exception chain stacktrace
org.apache.avalon.framework.configuration.ConfigurationException: Error during 
configuration
at 
org.apache.cocoon.components.axis.SoapServerImpl.configure(SoapServerImpl.java:207)
at 
org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:240)
at 
org.apache.cocoon.core.container.ComponentFactory.newInstance(ComponentFactory.java:131)

Caused by: java.lang.NullPointerException
at 
org.apache.excalibur.source.impl.ResourceSource.getInputStream(ResourceSource.java:97)
at 
org.apache.cocoon.components.axis.SoapServerImpl.setManagedServices(SoapServerImpl.java:366)
at 
org.apache.cocoon.components.axis.SoapServerImpl.configure(SoapServerImpl.java:201)


--Tim Larson

Re: VMWare host for us @apache.org

[Ross Gardler]

David Crossley wrote:
David Crossley wrote:
Upayavira wrote:
David Crossley wrote:

The docs aspect needs lots of consideration. If Cocoon wants to
continue using Forrest, then we would like help to implement
our plans for the Forrestbot and staging server for reviewing
docs prior to publication.
We had a huge discussion on this at infrastructure.at.a.o a few
months ago. That needs to be summarised and brought into the open.
I think this is the sort of thing I was referring to. If we can clarify 
what we have in mind, and get a number of us behind it, then I could see 
it as being possible.

But there's a lot to clarify/understand. Would you be willing to explain 
here what you had in mind for your Forrestbot setup? Presumably this 
setup would still use CVS/SVN as the versioning system for the actual 
xdoc files?
Yes it does.
Well i will try. It is a big task. Did anyone see the
infrastructure@ discussion to which i refer. It was not
just about "forrestbot", rather the whole situation of
publishing of documentation at Apache. There are
so many aspects: oversight of content, staging, workflow,
recoverability, quick turnaround, secure access,
Forrestbot, Lenya, Doco, ...
The thread finished with the feeling that we had solutions,
just in need of implementation.
Anyway, going off to dig through mail archives again ...

... back to the surface.
I have summarised that previous discussion from
[EMAIL PROTECTED] and built two proposal documents.
These are at the Forrest website.
Draft: Proposal for ASF-wide documentation staging and publishing
http://forrest.apache.org/proposal-asf-publish.html
This draws together various past discussions to address
the diverse issues with documentation publishing at apache.org
With respect to the following "scratch note" in the above document:
Noel: We need to accommodate sites that come from a single source,
and sites that come from multiple sources,
e.g. Jakarta or the XML Federation.
A recent plugin for Forrest allows sites to use an IMS Manifest to 
define their structure, one of the main advantages of using this method 
over the existing method (which remains the default method) is that it 
allows a site to include other sites within their own site. That is, 
each subproject in Jakarta/XML would maintain their site independently 
of the main Jakarta/XML site. These "sub-sites" can be built 
independently of the main Jakarta/XML site for local testing purposes.

How will this impact the building process described in the above document?
Stages A through G will be unaffected. Each individual site would have 
its own staging area, hence there is no need to build the whole Jakarta 
or XML site in order to review minor changes in one of the sub sites. 
The main site can also be staged in the way described in the document.

Actions in stages H and I would depend on how the main site was built 
and the changes that have been made.

If the main site simply links to the subsites (as is currently the case) 
then this site will only need to be rebuilt when such a link is updated, 
or the contents of the main site are updated.

However, using this new plugin it is possible to have the menus for the 
sub-sites appear as collapsible menus in the main site. In this case the 
main site will need to be rebuilt whenever the structure of a subsite 
changes (i.e. a new page is added).

If changes to subsites are minor (text changes in a page for example), 
then only the sub-site need be published.

CAVEAT: This forrest plugin is currently in alpha. It is not even in SVN 
yet (pending a restructure of SVN to accommodate the new plugin 
functionality of Forrest). As author of the plugin I can assure you that 
I will assist in any changes required to meet the requirements of the 
ASF (I need similar functionality in the project this came from anyway).

Ross

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

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2004-10-26 13:54 ---
I have tested. The result is negative. The same error is in main.java
I have corrected the error as well. The result is a new error:
No xsp was compiled!
output:
deploy.rules:
 [java] 

 [java] cocoon 2.1.5.1
 [java] Copyright (c) 1999-2004 Apache Software Foundation. All rights reser
ved.
 [java] 



 [java] 0 [main] INFO control.CompositeCacheConfigurator  - setting defaults
 to DC
 [java] 30 [main] INFO control.CompositeCacheConfigurator  - setting default
CompositeCacheAttributes to [ useLateral = true, useRemote = true, useDisk = tru
e, maxObjs = 100, maxSpoolPerRun = -1 ]
 [java] 30 [main] WARN config.OptionConverter  - Could not find value for ke
y jcs.default.elementattributes
 [java] 30 [main] WARN control.CompositeCacheConfigurator  - Could not insta
ntiate eAttr named 'jcs.default.elementattributes', using defaults.
 [java] 30 [main] INFO control.CompositeCacheConfigurator  - setting default
ElementAttributes to [ IS_LATERAL = false, IS_SPOOL = false, IS_REMOTE = false,
IS_ETERNAL = true, MaxLifeSeconds = -1, IdleTime = -1, CreateTime = 109879727983
8, LastAccessTime = 1098797279838, getTimeToLiveSeconds() = -1000, createTime =
1098797279838 ]
 [java] 90 [main] WARN config.OptionConverter  - Could not find value for ke
y jcs.system.groupIdCache.elementattributes
 [java] 90 [main] WARN control.CompositeCacheConfigurator  - Could not insta
ntiate eAttr named 'jcs.system.groupIdCache.elementattributes', using defaults.
 [java] 180 [main] INFO lru.LRUMemoryCache  - initialized LRUMemoryCache for
 groupIdCache
 [java] 180 [main] INFO control.CompositeCache  - Constructed cache with nam
e: groupIdCache
 [java] 2183 [main] INFO indexed.IndexedDiskCache  - Cache file root directo
ry: C:\AIDOS\KAIBox_Haupt_Cocoon2.1.5\Server\java\src\core\src\web\build\webapp\
WEB-INF\work\cache-dir
 [java] 2433 [main] WARN config.OptionConverter  - Could not find value for
key jcs.region.main.elementattributes
 [java] 2433 [main] WARN control.CompositeCacheConfigurator  - Could not ins
tantiate eAttr named 'jcs.region.main.elementattributes', using defaults.
 [java] 2433 [main] INFO lru.LRUMemoryCache  - initialized LRUMemoryCache fo
r main
 [java] 2433 [main] INFO control.CompositeCache  - Constructed cache with na
me: main
 [java] 2433 [main] INFO indexed.IndexedDiskCache  - Cache file root directo
ry: C:\AIDOS\KAIBox_Haupt_Cocoon2.1.5\Server\java\src\core\src\web\build\webapp\
WEB-INF\work\cache-dir
 [java] 2864 [CacheEventQueue.QProcessor-2] INFO engine.CacheEventQueue  - Q
Processor exiting for listenerId=-57, cacheName=main
 [java] 2874 [main] INFO engine.CacheEventQueue  - Cache event queue destroy
ed: listenerId=-57, cacheName=main
 [java] 3124 [main] INFO indexed.IndexedDiskCache  - Optomizing file keyHash
.size()=0
 [java] 3144 [main] WARN indexed.IndexedDiskCache  - Closing files, base fil
ename: main
 [java] 3144 [main] WARN control.CompositeCache  - Called close for main
 [java] 3144 [CacheEventQueue.QProcessor-1] INFO engine.CacheEventQueue  - Q
Processor exiting for listenerId=-57, cacheName=groupIdCache
 [java] 3144 [main] INFO engine.CacheEventQueue  - Cache event queue destroy
ed: listenerId=-57, cacheName=groupIdCache
 [java] 3505 [main] INFO indexed.IndexedDiskCache  - Optomizing file keyHash
.size()=0
 [java] 3505 [main] WARN indexed.IndexedDiskCache  - Closing files, base fil
ename: groupIdCache
 [java] Total time: 0 minutes 6 seconds,  Site size: 0 Site pages: 0
 [java] 3525 [main] WARN control.CompositeCache  - Called close for groupIdC
ache 

Andrea Pöschel

DO NOT REPLY [Bug 31760] - Handle / Semaphore Leak?

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

Handle / Semaphore Leak?





--- Additional Comments From [EMAIL PROTECTED]  2004-10-26 13:44 ---
It does; it is too low level.

Re: VMWare host for us @apache.org

[David Crossley]

David Crossley wrote:
> Upayavira wrote:
> > David Crossley wrote:
> >
> > >The docs aspect needs lots of consideration. If Cocoon wants to
> > >continue using Forrest, then we would like help to implement
> > >our plans for the Forrestbot and staging server for reviewing
> > >docs prior to publication.
> > >
> > >We had a huge discussion on this at infrastructure.at.a.o a few
> > >months ago. That needs to be summarised and brought into the open.
> >
> > I think this is the sort of thing I was referring to. If we can clarify 
> > what we have in mind, and get a number of us behind it, then I could see 
> > it as being possible.
> > 
> > But there's a lot to clarify/understand. Would you be willing to explain 
> > here what you had in mind for your Forrestbot setup? Presumably this 
> > setup would still use CVS/SVN as the versioning system for the actual 
> > xdoc files?
> 
> Yes it does.
> 
> Well i will try. It is a big task. Did anyone see the
> infrastructure@ discussion to which i refer. It was not
> just about "forrestbot", rather the whole situation of
> publishing of documentation at Apache. There are
> so many aspects: oversight of content, staging, workflow,
> recoverability, quick turnaround, secure access,
> Forrestbot, Lenya, Doco, ...
> 
> The thread finished with the feeling that we had solutions,
> just in need of implementation.
> 
> Anyway, going off to dig through mail archives again ...

... back to the surface.

I have summarised that previous discussion from
[EMAIL PROTECTED] and built two proposal documents.
These are at the Forrest website.

Draft: Proposal for ASF-wide documentation staging and publishing
http://forrest.apache.org/proposal-asf-publish.html
This draws together various past discussions to address
the diverse issues with documentation publishing at apache.org

Draft: Proposal for ASF-wide Forrestbot
http://forrest.apache.org/proposal-asf-forrestbot.html
This shows the Forrestbot role.

How Forrest can help the Cocoon publishing situation
should be evident from those proposals.

I am going to continue the previous discussions on the
Infrastructure mailing list. Any Apache committers can
join in to help.
http://www.apache.org/foundation/mailinglists.html#foundation-infrastructure

-- 
David Crossley

DO NOT REPLY [Bug 31760] - Handle / Semaphore Leak?

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

Handle / Semaphore Leak?





--- Additional Comments From [EMAIL PROTECTED]  2004-10-26 13:14 ---
Does util.concurrent provide thread pooling or is it too low level?

Re: Let's deprecate the PHP block

[Antonio Gallardo]

Tony Collen dijo:
> Let's deprecate the PHP block for the remainder of our 2.1.X releases
> and then dump it in 2.2.  If people want to "use" PHP with Cocoon, the
> best solution is to just use a FileGenerator and an http:// URL.

Seems we are alredy voting on that. Here is mine:

+1

NOTE: Please add a user doc page to show people how they can use PHP with
Cocoon. Outthere is a lot of people doing PHP stuff and a path to go into
Cocoon will be fine for them.

Best Regards,

Antonio Gallardo

DO NOT REPLY [Bug 31760] - Handle / Semaphore Leak?

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

Handle / Semaphore Leak?





--- Additional Comments From [EMAIL PROTECTED]  2004-10-26 13:11 ---
Don't think we should depend on d-haven; so if there is real a problem in event
stuff we could fix it there (in excalibur). Is it something like file handles
leak, or what are those handles?

Re: Let's deprecate the PHP block

[David Crossley]

Vadim Gritsenko wrote:
> David Crossley wrote:
> > Bertrand Delacretaz wrote:
> > 
> >>Reinhard Poetz a écrit :
> >>
> >>>Tony Collen wrote:
> >>>
> ...Let's deprecate the PHP block for the remainder of our 2.1.X 
> releases and then dump it in 2.2.  If people want to "use" PHP with 
> Cocoon, the best solution is to just use a FileGenerator and an 
> http:// URL...
> >>>
> >>>+1 too. Could you set up a formal vote which is needed to change the 
> >>>status of the PHP block?
> >>
> >>+1, I agree with the formal vote but if you start it by counting all 
> >>the +1s here we don't need to vote again.
> > 
> > 
> > One trouble is that Cocoon does not yet have any
> > project guidelines. Another trouble is that people
> > seem to use the +1 thing even when a vote is not
> > happening. The proposal phase for the discussion,
> > then the vote phase for the decision, is an Apache
> > way to get things done efficiently. We forget that.
> 
> Please, don't get over-bureaucratic. We've got governments for this (and yes, 
> this CMM thingy as well).

No, it is not bureaucratic. It is about efficiency.

-- 
David Crossley

Re: Howto drive response payload directly

[Vadim Gritsenko]

Ugo Cei wrote:
Il giorno 26/ott/04, alle 08:54, Leszek Gawron ha scritto:
Mark Lundquist wrote:
Hi,
I have a Java object persisted using Hibernate... it contains an 
image (java.sql.Blob) that I need to serve. I can get the object in 
flowscript, now I just need to stream out this data (e.g. 
"image.getBinaryStream()"). How can I do this?
Thanks,
/~ml
/
I think you should implement a Reader or a new Source.

A Reader is the way to go.
Existing ResourceReader and one of the existing sources reading data from 
request attribute should work just fine in ths case. Probably, flow attribute 
input module.

Vadim

Re: Let's deprecate the PHP block

[Nicola Ken Barozzi]

Tony Collen wrote:
...
Let's deprecate the PHP block for the remainder of our 2.1.X releases 
and then dump it in 2.2.  If people want to "use" PHP with Cocoon, the 
best solution is to just use a FileGenerator and an http:// URL.
I had written a similar mail a loong time ago, so I only find it natural 
that I vote +1, let's deprecate it.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

Re: Let's deprecate the PHP block

[Vadim Gritsenko]

David Crossley wrote:
Bertrand Delacretaz wrote:
Reinhard Poetz a écrit :
Tony Collen wrote:
...Let's deprecate the PHP block for the remainder of our 2.1.X 
releases and then dump it in 2.2.  If people want to "use" PHP with 
Cocoon, the best solution is to just use a FileGenerator and an 
http:// URL...
+1 too. Could you set up a formal vote which is needed to change the 
status of the PHP block?
+1, I agree with the formal vote but if you start it by counting all 
the +1s here we don't need to vote again.

One trouble is that Cocoon does not yet have any
project guidelines. Another trouble is that people
seem to use the +1 thing even when a vote is not
happening. The proposal phase for the discussion,
then the vote phase for the decision, is an Apache
way to get things done efficiently. We forget that.
Please, don't get over-bureaucratic. We've got governments for this (and yes, 
this CMM thingy as well).

Vadim

DO NOT REPLY [Bug 31760] - Handle / Semaphore Leak?

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

Handle / Semaphore Leak?





--- Additional Comments From [EMAIL PROTECTED]  2004-10-26 12:51 ---
It's been replaced by some stuff from d-haven (Berin)

DO NOT REPLY [Bug 31760] - Handle / Semaphore Leak?

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

Handle / Semaphore Leak?





--- Additional Comments From [EMAIL PROTECTED]  2004-10-26 12:44 ---
Agreed, Quartz seems to be too complex here.
Does event package resides in
http://svn.apache.org/repos/asf/excalibur/trunk/deprecated/event/ ?
If it is deprecated, what is its replacement?

Re: getInputStream() in FOM_Cocoon.FOM_Request ?

[Unico Hommes]

On 24-okt-04, at 13:47, Unico Hommes wrote:
On 24-okt-04, at 1:38, Frédéric Glorieux wrote:
Hello,
Like explained in another thread, I'm trying to implement a PUT 
binaries in the webdav/davmap demo. I wrote a simple "RequestReader" 
like waited in the sitemap sample, it works well for httpRequest, 
because there is a  getInputStream() method. But the sample sitemap 
is calling a pipeline from flow, and  FOM_Cocoon.FOM_Request doesn't 
seem to accept to give an InputStream in the API. I have a simple 
question, why ? There's a piece of architecture I can't understand 
there between all these requests.

The Request interface itself does not have getInputStream method, only 
HttpRequest does. So first step would be to add getInputStream method 
to the Request and then add it to FOM.

Done. I've applied the changes to the trunk only for now because I had 
to do an incompatible change. HttpRequest.getInputStream method 
returned ServletInputStream which has been changed to InputStream. 
Should I port the changes to the branch anyway ? I've also deprecated 
ActionRequest.getPortletInputStream in the portlet environment.

--
Unico

Re: Let's deprecate the PHP block

[David Crossley]

Bertrand Delacretaz wrote:
> Reinhard Poetz a écrit :
> 
> > Tony Collen wrote:
> >> ...Let's deprecate the PHP block for the remainder of our 2.1.X 
> >> releases and then dump it in 2.2.  If people want to "use" PHP with 
> >> Cocoon, the best solution is to just use a FileGenerator and an 
> >> http:// URL...
> >
> > +1 too. Could you set up a formal vote which is needed to change the 
> > status of the PHP block?
> 
> +1, I agree with the formal vote but if you start it by counting all 
> the +1s here we don't need to vote again.

One trouble is that Cocoon does not yet have any
project guidelines. Another trouble is that people
seem to use the +1 thing even when a vote is not
happening. The proposal phase for the discussion,
then the vote phase for the decision, is an Apache
way to get things done efficiently. We forget that.

A vote on this topic is probably a foregone conclusion.
So here is another +1 like Bertrand said.

-- 
David Crossley

RE: Gump help requested

[Carsten Ziegeler]

Yes, it's ant-contrib. Thanks for the patch, it's applied.

Carsten 

> -Original Message-
> From: Niclas Hedhman [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, October 26, 2004 12:33 PM
> To: [EMAIL PROTECTED]
> Subject: Gump help requested
> 
> 
> Gang,
> 
> I am trying to get Gump to build Cocoon. In the build script 
> there is a  element. I guess that it comes from the 
> ant-contrib package.
> 
> If so, the following patch would be needed for gump.xml in 
> the 2.2 branch.
> 
> 
> Cheers
> Niclas
> -- 
>+--//---+
>   / http://www.bali.ac/
>  / http://niclas.hedhman.org / 
> +--//---+
> 

DO NOT REPLY [Bug 31760] - Handle / Semaphore Leak?

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

Handle / Semaphore Leak?





--- Additional Comments From [EMAIL PROTECTED]  2004-10-26 11:07 ---
Exactly. And I think "use simple things for simple tasks". Quartz e.g. is great 
for complex scheduling, but imho it's overkill here.

DO NOT REPLY [Bug 31760] - Handle / Semaphore Leak?

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

Handle / Semaphore Leak?





--- Additional Comments From [EMAIL PROTECTED]  2004-10-26 11:03 ---
So the main question is whether the described behaviour (opening of file handles
by a thread owned by excalibur event) is a bug or not. If yes, we have to find
alternatives or fix it.

DO NOT REPLY [Bug 31760] - Handle / Semaphore Leak?

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

Handle / Semaphore Leak?





--- Additional Comments From [EMAIL PROTECTED]  2004-10-26 10:44 ---
But still there is a need for some thread pooling & scheduling API. It's not
optimal if each component spawns as meny threads as it desires...

Gump help requested

[Niclas Hedhman]

Gang,

I am trying to get Gump to build Cocoon. In the build script there is a  
element. I guess that it comes from the ant-contrib package.

If so, the following patch would be needed for gump.xml in the 2.2 branch.


Cheers
Niclas
-- 
   +--//---+
  / http://www.bali.ac/
 / http://niclas.hedhman.org / 
+--//---+
Index: gump.xml
===
--- gump.xml	(revision 55597)
+++ gump.xml	(working copy)
@@ -43,6 +43,7 @@
 
 
 
+
 
 
 

DO NOT REPLY [Bug 31760] - Handle / Semaphore Leak?

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

Handle / Semaphore Leak?





--- Additional Comments From [EMAIL PROTECTED]  2004-10-26 10:23 ---
Haven't you implemented similar functionality for the cached source?

DO NOT REPLY [Bug 31760] - Handle / Semaphore Leak?

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

Handle / Semaphore Leak?





--- Additional Comments From [EMAIL PROTECTED]  2004-10-26 10:13 ---
Great! So any volunteers?

Re: getInputStream() in FOM_Cocoon.FOM_Request ?

[Frédéric Glorieux]

You can find some samples in: 
http://cvs.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/scratchpad/samples/module-source/?root=Apache-SVN 

And some documentation in:
http://wiki.apache.org/cocoon/ModuleSource
There are docu and samples for XModuleSource also:
http://cvs.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/scratchpad/samples/xmodule-source/?root=Apache-SVN 

http://wiki.apache.org/cocoon/XModuleSource
Thanks a lot, sorry for a question better to post on users.
/Daniel
Fred.
--
Frédéric Glorieux (ingénieur documentaire, AJLSM)

DO NOT REPLY [Bug 31760] - Handle / Semaphore Leak?

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

Handle / Semaphore Leak?





--- Additional Comments From [EMAIL PROTECTED]  2004-10-26 09:59 ---
As we only have this simple strategy of invalidating Continuations it should be
that easy :-)

Re: Let's deprecate the PHP block

[Bertrand Delacretaz]

Le 26 oct. 04, à 11:33, Reinhard Poetz a écrit :
Tony Collen wrote:
...Let's deprecate the PHP block for the remainder of our 2.1.X 
releases and then dump it in 2.2.  If people want to "use" PHP with 
Cocoon, the best solution is to just use a FileGenerator and an 
http:// URL...
+1 too. Could you set up a formal vote which is needed to change the 
status of the PHP block?
+1, I agree with the formal vote but if you start it by counting all 
the +1s here we don't need to vote again.

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

DO NOT REPLY [Bug 31760] - Handle / Semaphore Leak?

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

Handle / Semaphore Leak?





--- Additional Comments From [EMAIL PROTECTED]  2004-10-26 09:48 ---
Ok, but what does this scheduler do? I thought - perhaps I'm wrong - that it 
simply is invoked every 30 minutes (configurable) and then cleans up the 
continuations. - If it is only that, we can simply add our own implementation - 
some lines of code, and have no dependency at all.
Or does it do more?

Re: Let's deprecate the PHP block

[Daniel Fagerstrom]

Tony Collen wrote:
To my knowledge, the PHPGenerator hasn't worked for quite some time.  
In all the time I've been working with Cocoon, I have never seen it 
work correctly.

However, I believe the problem is within the PHP Servlet itself, 
which, if you do some research, tons of people have had problems with 
it being FUBAR for ages.

There are lots of messages from people looking to get it working on 
the lists as well:

cocoon-dev: 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&w=2&r=1&s=phpgenerator&q=b
cocoon-users: 
http://marc.theaimsgroup.com/?l=xml-cocoon-users&w=2&r=1&s=phpgenerator&q=b 

Here's a good example of recent attempt of using the PHP Servlet:
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=107340894710274&w=2
It's my personal opinion that we'll never see a good PHP servlet, 
especially since it's been "in beta" for a number of years.

Let's deprecate the PHP block for the remainder of our 2.1.X releases 
and then dump it in 2.2.  If people want to "use" PHP with Cocoon, the 
best solution is to just use a FileGenerator and an http:// URL.

Tony
+1
Tried to get it to work a half a year ago and didn't succeed. I came to 
the same conclusion as you: that it would not be worthwhile to make it 
work and that using http:// is a better option.

/Daniel

[GUMP@brutus]: Project cocoon (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon has an issue affecting its community integration.
This issue affects 56 projects,
 and has been outstanding for 7 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon :  Java XML Framework
- cocoon-block-apples :  Java XML Framework
- cocoon-block-asciiart :  Java XML Framework
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-axis :  Java XML Framework
- cocoon-block-batik :  Java XML Framework
- cocoon-block-bsf :  Java XML Framework
- cocoon-block-chaperon :  Java XML Framework
- cocoon-block-cron :  Java XML Framework
- cocoon-block-databases :  Java XML Framework
- cocoon-block-deli :  Java XML Framework
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-faces :  Java XML Framework
- cocoon-block-fop :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-hsqldb :  Java XML Framework
- cocoon-block-html :  Java XML Framework
- cocoon-block-itext :  Java XML Framework
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-jfor :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-jsp :  Java XML Framework
- cocoon-block-linkrewriter :  Java XML Framework
- cocoon-block-linotype :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-mail :  Java XML Framework
- cocoon-block-midi :  Java XML Framework
- cocoon-block-naming :  Java XML Framework
- cocoon-block-ojb :  Java XML Framework
- cocoon-block-paranoid :  Java XML Framework
- cocoon-block-petstore :  Java XML Framework
- cocoon-block-php :  Java XML Framework
- cocoon-block-poi :  Java XML Framework
- cocoon-block-portal :  Java XML Framework
- cocoon-block-portal-fw :  Java XML Framework
- cocoon-block-profiler :  Java XML Framework
- cocoon-block-proxy :  Java XML Framework
- cocoon-block-python :  Java XML Framework
- cocoon-block-qdox :  Java XML Framework
- cocoon-block-repository :  Java XML Framework
- cocoon-block-scratchpad :  Java XML Framework
- cocoon-block-serializers :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework
- cocoon-block-slide :  Java XML Framework
- cocoon-block-slop :  Java XML Framework
- cocoon-block-stx :  Java XML Framework
- cocoon-block-taglib :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- cocoon-block-velocity :  Java XML Framework
- cocoon-block-web3 :  Java XML Framework
- cocoon-block-webdav :  Java XML Framework
- cocoon-block-woody :  Java XML Framework
- cocoon-block-xmldb :  Java XML Framework
- cocoon-block-xsp :  Java XML Framework
- forrest :  Apache Forrest is an XML standards-oriented documentation fr...
- lenya :  Content Management System


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon]
 -DEBUG- Output [cocoon-tests.jar] identifier set to output basename: [cocoon-tests]
 -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: 
[cocoon-deprecated]
 -DEBUG- Dependency on avalon-framework-api exists, no need to add for property 
avalonapi.jar.
 -INFO- Made directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-26102004/test]
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/cocoon/build/cocoon-26102004/test/output
 -WARNING- No directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-26102004/test/output]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html
Work Name: build_cocoon_cocoon (Type: Build)
Work ended in a state of : Failed
Elapsed: 19 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
-Davalonapi.jar=/usr/local/gump/public/workspace/avalon-trun

Re: getInputStream() in FOM_Cocoon.FOM_Request ?

[Daniel Fagerstrom]

Vadim Gritsenko wrote:
Sylvain Wallez wrote:
But we have to define the behavior of getInputStream for environments 
where it has no meaning (e.g. background env,
It can be initialized with java.io.InputStream (File, byte array), or 
null. If null, throw exception.

sitemap source, cocoonbean
I believe you mean CLI environment. CocoonBean does not (should not) 
depend on environment (hopefully). For CLI, InputStream can be 
initialized with either FileInputStream, or System.in, or null. If 
null, throw exception. 
FileInputStream or System.in could possibly usefull for testing (or even 
using), Webservices written in Cocoon from the command line. And for 
using Cocoon as a command line XML filter.

etc).
MailEnvironment - has input stream.
HttpEnvironment - has input stream as well.
PortletEnvironment - action request has input stream.
IMO, we should throw an exception for these cases.
Agreed.
Vadim 
And +1 for adding getInputStream to the Request interface.
/Daniel

Re: Let's deprecate the PHP block

[Reinhard Poetz]

Tony Collen wrote:
To my knowledge, the PHPGenerator hasn't worked for quite some time.  In 
all the time I've been working with Cocoon, I have never seen it work 
correctly.

However, I believe the problem is within the PHP Servlet itself, which, 
if you do some research, tons of people have had problems with it being 
FUBAR for ages.

There are lots of messages from people looking to get it working on the 
lists as well:

cocoon-dev: 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&w=2&r=1&s=phpgenerator&q=b
cocoon-users: 
http://marc.theaimsgroup.com/?l=xml-cocoon-users&w=2&r=1&s=phpgenerator&q=b

Here's a good example of recent attempt of using the PHP Servlet:
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=107340894710274&w=2
It's my personal opinion that we'll never see a good PHP servlet, 
especially since it's been "in beta" for a number of years.

Let's deprecate the PHP block for the remainder of our 2.1.X releases 
and then dump it in 2.2.  If people want to "use" PHP with Cocoon, the 
best solution is to just use a FileGenerator and an http:// URL.

Tony
+1 too. Could you set up a formal vote which is needed to change the status of 
the PHP block?

--
Reinhard

DO NOT REPLY [Bug 31760] - Handle / Semaphore Leak?

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

Handle / Semaphore Leak?





--- Additional Comments From [EMAIL PROTECTED]  2004-10-26 09:33 ---
IIUC the ContinuationsMgr needs a scheduler. So we could move to Quartz. The
question are, who maintains Excalibur event and do we want a dependency of
Cocoon core on another third party software?

Re: getInputStream() in FOM_Cocoon.FOM_Request ?

[Daniel Fagerstrom]

Frédéric Glorieux wrote:
Request reader and this

works as well. This writing is nice, I like it.
Is there some more samples of those things ? 
You can find some samples in: 
http://cvs.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/scratchpad/samples/module-source/?root=Apache-SVN

And some documentation in:
http://wiki.apache.org/cocoon/ModuleSource
There are docu and samples for XModuleSource also:
http://cvs.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/scratchpad/samples/xmodule-source/?root=Apache-SVN
http://wiki.apache.org/cocoon/XModuleSource
/Daniel

Re: Let's deprecate the PHP block

[Giacomo Pati]

On Mon, 25 Oct 2004, Tony Collen wrote:
Let's deprecate the PHP block for the remainder of our 2.1.X releases and 
then dump it in 2.2.  If people want to "use" PHP with Cocoon, the best 
solution is to just use a FileGenerator and an http:// URL.
+1
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

DO NOT REPLY [Bug 31813] - [Sample] DreamTeam (dependent widgets in a repeater)

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

[Sample] DreamTeam (dependent widgets in a repeater)





--- Additional Comments From [EMAIL PROTECTED]  2004-10-26 09:26 ---
Sorry, I overlooked your answer: I committed the missing file. I will add  the
mentioned comment when moving it to BRANCH_21.

Coult you again crosscheck whether your sample works fine?

Re: Questions to be answered for link request - V2

[gounis]

On Fri, 22 Oct 2004, Bertrand Delacretaz wrote:

> Le 22 oct. 04, ΰ 15:49, Hunsberger, Peter a ιcrit :
> > ...Would an "Intranet applications" section also make sense?  As I see 
> > it,
> > this list would be a list of organizations and applications with a 
> > brief
> > description of the application.  Perhaps a screen shot or two would 
> > also
> > be encouraged or even required?...
> 
> +1, having more success stories is certainly good.
> 
> Requiring an image (screenshot, architecture, whatever makes the thing 
> more real to outsiders) is a good idea IMHO.
> 
> -Bertrand
> 


for light cocoon usage and preview purposes they  are cocoon's samples 
area. what if they are people that want to share a biger project with the 
public but they dont want to setup an open source project (web site, CVS, 
etc)

Will an area that host those projects force people to share the work they 
have do?


--stavros 

RE: Portal - coplet instance data attributes

[Carsten Ziegeler]

Hmm, I really can't remember everything. Now one problem was that if
you save the objects to XML, you can't save all available attributes
for the instance. You have to filter and only save the attributes that
are part of the instance and not those of the coplet data.

An additional problem is removing of attributes etc. What do you do if
the attribute you want to remove is not an attribute of the instance?
Do you delegate it to the data object? And so on.
Now, rethinkink everything, perhaps the simplest solutions is to leave
everything as it is and only add a "get value from all attributes method",
which is just a getter method that first looks in the instance and then
in the coplet data object. But for setting and removing everything could
be left unchanged.

HTH
Carsten




From: Ralph Goers [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 26, 2004 8:52 AM
To: [EMAIL PROTECTED]
Subject: Re: Portal - coplet instance data attributes


What problems were you experiencing?  I don't want to waste my time
if it won't work.

Ralph

Carsten Ziegeler wrote: 

Now, the original idea was exactly to have this behaviour,
but
unfortunately we soon ran into problems with Castor
converting
the objects to XML. But apart from that I see no problems
with it.
(PS: if anyone has a better way for the conversion than
Castor
it would make me very happy).

Carsten

  

Re: Howto drive response payload directly

[Ugo Cei]

Il giorno 26/ott/04, alle 08:54, Leszek Gawron ha scritto:
Mark Lundquist wrote:
Hi,
I have a Java object persisted using Hibernate... it contains an 
image (java.sql.Blob) that I need to serve. I can get the object in 
flowscript, now I just need to stream out this data (e.g. 
"image.getBinaryStream()"). How can I do this?
Thanks,
/~ml
/
I think you should implement a Reader or a new Source.
A Reader is the way to go. Which is a PITA, since it would be much 
nicer if we could have a method in the "cocoon" object that would take 
a byte array or an InputStream and serve a binary response directly 
without going through another pipeline.

I'm redirecting this to the dev- list to see if other developers have 
any thoughts about this.

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


smime.p7s
Description: S/MIME cryptographic signature