Re: [RT] what cocoon forms lack

[Gianugo Rabellino]

Andrzej Jan Taramina wrote:
now, what do you think?


I think that following/supporting the XForms standard, which seems to be 
getting traction, would be a good thing.

Not sure the world needs YAFF (yet another forms framework).  

Or is the NIH syndrome rearing it's ugly head here? ;-)
We have been through this so many times that unless something new (but 
it should be _incredibly_ new) comes up the discussion is pretty much 
over. Please do dig the archives: you'll find that this XForms/Woody 
debate showed up in quite a few occasions and in the end there was 
consensus on simply not being good enough for server side form handling.

Ciao,

--
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)

Re: Track feature requests in bugzilla?

[Bertrand Delacretaz]

Le Vendredi, 10 oct 2003, à 00:26 Europe/Zurich, Torsten Curdt a écrit :



Thanks for the information.

If there is no real alternative to bugzilla, we should use it.
Ah, BTW, Scarab *is* better than bugzilla and stable enough for 
use... I just heard it's a pain to migrate stuff from bugzilla.
any project that has already been going down that road?
maybe we could borrow scripts etc...
On the scarab front page they say that it supports XML importing.
Exporting our current bugzilla stuff to XML is not hard (with Cocoon 
for example ;-)

...
Another issue is the configuration of bugzilla itself. Isn't it 
customizable? Furthermore more recent versions offer more options.
I bet ...but doesn't Bertrand know? :)
Newer versions of bugzilla use HTML templates which can make it look 
much nicer if that's the problem. I think it is part of the problem if 
we're going to make more serious use of bugzilla, there's no excuse for 
looking bad on the web today.

Also, the query form in 2.16 has a better layout which helps a lot when 
you start using it.

Finally, saved queries help a lot, you can create the 4-5 queries that 
you need regularly and then mostly forget about the query page.
I don't know if they exist in the 2.14.2 version that we're using, but 
if they are they seem to be disabled (Pier?).

An easy workaround if saved queries cannot be enabled for some reason 
is to create more links like the "patch queue" and "open bugs" links 
that we have on the web and wiki. "What happened in the last X days" 
and "what's unassigned" come to mind and are easy to do.

But I agree with Andrew and Jeff that the current bugzilla works - it 
might not be pretty (it is ugly actually), and is lacking in ways of 
classifying issue types, but it does the job if one is willing to use 
it.

I'm not sure about switching to another tracking system. The "new toy" 
syndrom could help people make more use of it, OTOH if people are not 
willing to use it they will not and we will only have wasted time. A 
bugzilla upgrade might be good though.

My suggestion would be to stay with bugzilla until the next 1-2 
FirstFridays at least  and see how we do. Until then, have a vote on 
where we want to track feature requests, bugzilla or wiki will both 
work for these IMHO, this is not such a big deal.

Ciao,
Bertrand

Re: Proper filenames for all jars

[David Crossley]

Antonio Gallardo wrote:
> David Crossley dijo:


Thanks for the clarification about jar filenames.

> > The same applies to xml-apis.jar Also does this new version
> > come from xml-commons?
> 
> This is a problem, that I tried to raise in the xml-commons community, but
> this is not easy. The code inside the xml-apis-jar is not part of ASF.
> xml-apis.jar is a recopilation of many standards. The xml-apis.jar is used
> by many projects: xalan, xerces, ant, cocoon, etc.

Yes, that is why xml-commons is so important. This stuff is vital to
many projects.

> I tried to push a version of the file, but this ended in a blah, blah,
> blah.  Maybe if all us push about this, we will have and xml-apis.jar with
> a version.
> 
> I suggested that each change in some api will change the version of the
> file. But nobody did nothing.
> 
> I am concerning about this too.

Ah, poor old xml-commons. Unfortunately, not many people from
other projects are interested in it. So it is very hard to get
things moving. I think that we should try to help rather than push.
All cocoon committers are also committers there by default. So along
with the help of other Cocoon developers, we should be there.
http://xml.apache.org/commons/

--David

Re: Proper filenames for all jars

[Antonio Gallardo]

David Crossley dijo:
> antonio wrote:
>> antonio 2003/10/09 14:23:06
>>
>>   Modified:lib/endorsed xml-apis.jar
>>   Log:
>>   Updating xml.apis from Xerces 2.5.0.
>>   Suggested by Torten Curdt and Vadim Gritsenko.
>
> Hi Antonio, i have been intending to ask you to please assign
> the new ojb/lib/*.jar proper filenames using a version number
> if it is released or a compilation date if not yet released.

Yep. I am aware of the problem. I tried to define the versions, but there
are not clear. I requested the version from the OJB project. I hope they
will helps us.

> The validate-jars build task tries to remind us about this.
> It is important so that everyone knows which version of the
> jars we are using.

I know, sorry.

> The same applies to xml-apis.jar Also does this new version
> come from xml-commons?

This is a problem, that I tried to raise in the xml-commons community, but
this is not easy. The code inside the xml-apis-jar is not part of ASF.
xml-apis.jar is a recopilation of many standards. The xml-apis.jar is used
by many projects: xalan, xerces, ant, cocoon, etc.

I tried to push a version of the file, but this ended in a blah, blah,
blah.  Maybe if all us push about this, we will have and xml-apis.jar with
a version.

I suggested that each change in some api will change the version of the
file. But nobody did nothing.

I am concerning about this too.

Best Regards,

Antonio Gallardo.

DO NOT REPLY [Bug 23714] New: - Bug in SessionAttributeGenerator, double startDoc/endDoc SAX events generated

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23714

Bug in SessionAttributeGenerator, double startDoc/endDoc SAX events generated

   Summary: Bug in SessionAttributeGenerator, double startDoc/endDoc
SAX events generated
   Product: Cocoon 2
   Version: 2.1.2
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: sitemap components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I ran into what seems to be the infamous "failed to execute pipeline"
problem with Cocoon 2.1.2 in trying to execute a simple XSLT transform.  

Eliminating the transform from the pipeline and serializing directly to
XML showed well formed XML going into the transform step, which was very
frustrating, so I put in a logging transform. Lo and behold, the logger
showed that the startDocument and endDocument SAX events were doubled up!

What caused this problem is that I had set a session attribute to hold the
XML document I wanted transformed, but I had set that attribute to be the
DOM Document object, then used SessionAttributeGenerator to create the SAX
event stream for the transformation.  This should be perfectly acceptable!

Problem is that the generate() method in SessionAttributeGenerator looks
as follows:

public void generate() throws IOException, SAXException,
ProcessingException {
 xmlConsumer.startDocument();

 if (this.elementName != null) {
  xmlConsumer.startElement("", this.elementName, this.elementName, new
  AttributesImpl()); XMLUtils.valueOf(xmlConsumer, this.attrObject);
  xmlConsumer.endElement("", this.elementName, this.elementName);
 } else {
  XMLUtils.valueOf(xmlConsumer, this.attrObject);
 }

 xmlConsumer.endDocument();
}

The bug is evident because if the this.attrObject is set to a Document
object (rather than the document root Element), the method generates a
start/end documentbut so does the interior code! So you get duplicate
start/endDocument events generated and downstream XSLT transforms barf on
the input (funny that the XML serializer doesn't much care about this
duplication).

Anyway, rewriting the generate() method of SessionAttributeGenerator will
correct this insidious bug:

public void generate() throws IOException, SAXException,
ProcessingException {
 if( !( attrObject instanceof Document ) {
  xmlConsumer.startDocument();
 }

 ...same interior code as before

 if( !( attrObject instanceof Document ) {
  xmlConsumer.endDocument();
 }  
}

Of course, also need to add:

 import org.w3c.dom.Document;

Can one of the developers make this change for 2.1.3 and thus kill this
bug once and for all?

Thanks guys!

Andrzej

mounting blocks question

[Geoff Howard]

We decided that wiring.xml would have entries like:

/mail/

How would this work for using hostname based mounting?

Use case:
http://mail.mydomain.com
http://www.mydomain.com
Two different applications, same cocoon instance.

(mail block)
/
??

 (main site block)
/
... (authentication block)

/login (defaults to all hosts)

?,
Geoff

Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)

[Jeff Turner]

On Thu, Oct 09, 2003 at 03:05:41PM +0100, Andrew Savory wrote:
> 
> Hi,
> 
> On Thu, 9 Oct 2003, Stefano Mazzocchi wrote:
> 
> > Forrest uses Jira. Jira is much better than bugzilla. Jeff works for
> > the company that produces it. There is also a migration tool between
> > bugzilla and Jira. It's commercial, but free for open source use.
> >
> > I would be +1 to migrate to Jira.
> 
> -1 for Jira.
> 
> Sorry Stefano, but I don't believe we should be using proprietary software
> for critical infrastructure.
> 
> - We would have no access to the source code

True, though it's just a fancy GUI over a database.

> - We would have to rely on a single organisation for development and support

True.  There's also a pretty active jira-user list for support, with some
very savvy users.

> - We have no guarantee that the license would be in perpetuity (I can't
> find a copy of the license on their site).

JIRA open source licenses do not expire (nor do the commercial ones).

> For open source bts, Atlassian recommend bugzilla.
> http://www.atlassian.com/software/jira/docs/latest/faq.html#is_jira_open_source
> 
> I know bugzilla's interface can be tiresome, but it _does_ do the job,
> it's tested and deployed worldwide, and it is free/libre.

Personally I don't mind bugzilla.  It does the job despite UI crudeness.

Getting on my soapbox.. IMO all current bugtrackers suck when it comes to
email support.  Email should be a *primary* interface.  JIRA is better
than most in that it supports issue creation and commenting through
email, but its outgoing emails could be significantly improved:

http://jira.atlassian.com/secure/ViewIssue.jspa?key=JRA-2326

It's my pet JIRA bug ;)  That and the sucky URI space (JRA-2058).


--Jeff

> Andrew.
> 
> -- 
> Andrew SavoryEmail: [EMAIL PROTECTED]
> Managing Director  Tel:  +44 (0)870 741 6658
> Luminas Internet Applications  Fax:  +44 (0)700 598 1135
> Orixo alliance: http://www.orixo.com/  Web:www.luminas.co.uk

Re: [RT] Finishing the first phase of block design

[Geoff Howard]

Stefano Mazzocchi wrote:

On Wednesday, Oct 8, 2003, at 04:50 Europe/Rome, Geoff Howard wrote:

Stefano Mazzocchi wrote:

I have updated the block design documents on the wiki. Changes were:
...

A few things are left to decide:
 1) the block metadata information in the block.xml file
  see http://wiki.cocoondev.org/Wiki.jsp?page=BlocksCob
 2) how blocks expose classloading to other blocks
...

Exposing classes

Stephen proposed to separate the classes to expose in a different jar 
and expose that. I like this. It's simple and effective.
But instead of declaring classloaders or classpaths in the blocks, I 
propose to extend the block FS layout so that we have
for individual classes and resources:
 /classes
 /classes/public
 /classes/private
for jars:
 /lib
 /lib/public
 /lib/private
Hmmm.  That is quite different than what one would expect from the WAR 
paradigm, no?  Would

COB-INF/[classes|lib]
COB-INF/public/[classes|lib]
or

COB-INF/private/[classes|lib]
COB-INF/public/[classes|lib]
be any better?


This might suggest the concept that private is the location of all the 
things that are private so

 private/lib

means "I have libraries in the private section", so maybe I can put 
something else as well to have it protected? while

 lib/private

means "these are the private libraries"... but doesn't say anything 
about non-lib things. I still like this approach better, even if it 
moves away from the WAR paradigm (which is not a big deal, IMO, since 
blocks are different enough already)
Ok, that's a good point.  I have a parallel concern that something like

COB-INF/classes/com/mypackage/whyisntitfound/NotFound.class

or

package public.com.myconfused.package
public Class StillNotFound {...
will pop up regularly on the users list.

One more idea to try to avert potential confusion.

COB-INF/private-lib/
COB-INF/private-classes/
COB-INF/public-lib/
COB-INF/public-classes/
?

the block manager will tranparently make available the classes found 
in the "public" folders to the blocks that depend on this block (and 
*ONLY* to those! classloading isolation is very important to achieve 
hot deployment functionality without impacting the performance of a 
running system too much)
Is there never a way to avoid duplicating common jars between blocks?
Avoid? well, not architecturally, that could means weird classloading 
issues.

I think we may be wise to go this way but I know this will be 
unpopular and misunderstood and deserves some thought.
good point, though.

the classloader will also check for conflicts: in fact, it will be 
considered an error to depend on two blocks that provide one or more 
classes with the same absolute name.
Hmmm.  not sure I can mentally eliminate all valid cases at this 
stage.  Would there ever be an older version and a newer version of a 
block deployed in the same space for example? (probably not but 
thinking out loud)
Oh, yeah, the above "modulo versioning". If the same class applies in 
blocks that differ only for their versions, it's good. The problem is 
when two completely different blocks do. (we might signal a warning 
instead of an error, but that's an implementation detail).
OK, sounds good.

Exposing Resources
--
I'm adding this because my brain is still a little unsure about this. 
So far, we've said that file resources (an xsl for example)

1) need to be exposed via a sitemap pipeline, even if only by a reader
2) are not anywhere declared explicitly (except in the pipeline of 
course)
3) are not distinguised from resources meant to be private by any 
formal semantics, though this information could be conveyed 
human-to-human in any block docs (blocs? blockumentation? ;) ).

Here are my oustanding questions:

- Will we regret requiring the overhead of pipeline setup (runtime I 
mean) for blocks which expose a great deal of otherwise static resources?
could be. remember though that the block: protocol will be caching 
friendly, so we might even gain performance.

- Not found resources will have to go through every pipeline to 
determine that it's not found.  With fallback behavior due to 
polymorphism this gets worse.
I fail to see this, can you explain why you think this is the case?
sitemap references:
block:external-skin:/stylesheets/news2html.xslt
block manager has external-skin -> 
http://mycompany.com/skins/corporate/34.3.345
 -> extends ->
http://yetanothercompany.com/skins/fancy/1.2.2

checks WEB-INF/blocks/384938958499/sitemap.xmap (by the way, the Cob 
samples at the wiki don't have sitemaps for the skins blocks which would 
presumably need them to expose their xslt in the example right?)

If that sitemap doesn't override /stylesheets/news2html.xslt, every
pipeline in that sitemap needs to be checked _then_ block manager goes 
on to 
WEB-INF/blocks/how-does-the-block-wiring-handle-blocks-extended-but-not-otherwise-used/sitemap.xmap

if there are several levels of extension, this could be a long process.

But now a worse thought 

Re: [GT2003] Thank you

[Thor Heinrichs-Wolpert]

Thanks for the great sessions and hospitality.
Everyone involved put in a lot of work to make this a great even.  I 
sure appreciated.

I'm looking forward to next years!

Cheers all,
Thor HW

Proper filenames for all jars

[David Crossley]

antonioapache.org wrote:
> antonio 2003/10/09 14:23:06
> 
>   Modified:lib/endorsed xml-apis.jar
>   Log:
>   Updating xml.apis from Xerces 2.5.0.
>   Suggested by Torten Curdt and Vadim Gritsenko.

Hi Antonio, i have been intending to ask you to please assign
the new ojb/lib/*.jar proper filenames using a version number
if it is released or a compilation date if not yet released.

The validate-jars build task tries to remind us about this.
It is important so that everyone knows which version of the
jars we are using.

The same applies to xml-apis.jar Also does this new version
come from xml-commons?

--David
 

multiple XML input to render SVG

[Scott A Malec]

Hi there,
Has anyone any experience with using multiple XML files with an XSL Script
to generate SVG in Cocoon?
Thanks,
Scott Malec

Re: [RT] what cocoon forms lack

[Andrzej Jan Taramina]

> now, what do you think?

I think that following/supporting the XForms standard, which seems to be 
getting traction, would be a good thing.

Not sure the world needs YAFF (yet another forms framework).  

Or is the NIH syndrome rearing it's ugly head here? ;-)

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: [RT] Using modifiers within Cocoon components

[Geoff Howard]

Stefano Mazzocchi wrote:
On Thursday, Oct 9, 2003, at 14:00 Europe/Rome, Geoff Howard wrote:

Bertrand Delacretaz wrote:
...

I like access="private" and access="public".

- Which is the default if none is specified? (public)
it would be back incompatible, but defaulting to private would be better 
from an evolutionary perspective.
I was thinking of back compatibility too, but come to think of it which 
old version of Cocoon with block polymorphism do we have to worry about?
;)

Hmmm, on second thought,

uri access : @internal-only
block access : @access
are these two orthoganal concepts named deceptively in the case of 
pipelines?
...

If
we never envision anything other than private/public would something 
like block-private="true" convey more meaning? block-access="private" 
might do the same but leave freedom for other than private/public.
random though, but you could think of "protected" as exposed to 
extending blocks but not outside that extending block (maybe to allow a 
different style of wrapping), while "private" is not exposed to 
extending blocks and public

so, leaving block-access="" (on both components and pipelines) is 
probably a better idea.
Sounds good - not sure if we'll need or want those kind of distinctions 
but it's hard to predict now.

Geoff

Re: Track feature requests in bugzilla?

[Torsten Curdt]

Thanks for the information.

If there is no real alternative to bugzilla, we should use it.


Ah, BTW, Scarab *is* better than bugzilla and stable enough for use... I 
just heard it's a pain to migrate stuff from bugzilla.
any project that has already been going down that road?
maybe we could borrow scripts etc...
what are the php guys using anyway?
IIRC I liked that interface more than bugzilla
Another issue is the configuration of bugzilla itself. Isn't it 
customizable? Furthermore more recent versions offer more options.
I bet ...but doesn't Bertrand know? :)

Bertrand?
--
Torsten

Re: [RT] Separation of Blocks and Avalon

[Stephen McConnell]

Stefano Mazzocchi wrote:

On Thursday, Oct 9, 2003, at 17:15 Europe/Rome, Ryan Hoegg wrote:

Rather than have cocoon blocks extend avalon blocks, I think cocoon 
blocks could use avalon blocks.


Ok, I see your point.

Instead of having a /COB-INF and a /BLOCK-inf, perhaps we include 
avalon blocks in /COB-INF/lib and delegate their deployment to the 
avalon container.  This could even allow cocoon blocks to provide 
avalon blocks to the container, as well as require them.


I would not know how to do this! I'm not scared by merlin, I'm scared 
about the million little details that cocoon assumes on top of ECM and 
that are now considered deprecated by the "modern" containers. 


The million little details that cocoon assumes on top of ECM is also the 
thing that scares me the most.

if Fortress was there, admittedly, things would be easier... but then 
again, lots of talks, but nobody is able, wants or has 
time/energy/braveness to do the migration.


Is there someone who provide the breakdown of what Cocoon is doing over 
and above ECM?  However things roll out - one of the biggest obsticles I 
see is that we need to move away from ECM/Fortress extension and to a 
solution where Cocoon does not need to access container APIs.  With that 
information the Avalon crowd can address how to addres these 
requirements in a way that makes the concern indpendent of the container 
implementaiton.


It may help to distinguish between different types of dependencies:
1. Block dependency.  As described in 
http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition and 
specified in http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring .  
What we (I think) have been talking about in several threads.
2a. Avalon dependency by block.  This would be some avalon 
service/component that is required by the block, and would be 
explicitly declared.  An example might be a Transformer or the Flow 
engine.
2b. Avalon dependency by avalon block/component/service.  This would 
be some avalon service that is required by an avalon service or block 
that is included with the cocoon block.  For example, I have a 
UserManager service that depends on a UserRepository service, which 
could be implemented by an OJBUserRepository.  If the cocoon block 
included the UserManager block, it might ask the Parent Component 
Manager for a UserManager, and might be provided with the 
OJBUserRepository.


I fear the complexity of such a move. 


Break the complexity down into managable chunks.

1. migrate from Component to Object
2. migrate from roles files to meta
Just achiving the above opens up a much broader spectrum of 
possibilities and the question become much more concrete and substantive 
(from both sides of the equation). We have been discussing this over on 
Avalon land - subjects such as transition vehicles, migration tools, 
etc. these are way up on the agenda. 

Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]

Re: [RT] Separation of Blocks and Avalon

[Ryan Hoegg]

Berin Loritsch wrote:

Stefano Mazzocchi wrote:

if Fortress was there, admittedly, things would be easier... but then 
again, lots of talks, but nobody is able, wants or has 
time/energy/braveness to do the migration.
Huh?  I have offered, and have been told to wait until Cocoon 2.2.

So, is the repository ready?  A can take care of it fairly quickly if so.

I'll offer my help here, if there's something I can help with.  Feel 
free to e-mail me personally, Berin.

--
Ryan Hoegg

Re: [RT] Separation of Blocks and Avalon

[Stefano Mazzocchi]

On Thursday, Oct 9, 2003, at 22:52 Europe/Rome, Berin Loritsch wrote:

Stefano Mazzocchi wrote:


if Fortress was there, admittedly, things would be easier... but then 
again, lots of talks, but nobody is able, wants or has 
time/energy/braveness to do the migration.
Huh?  I have offered, and have been told to wait until Cocoon 2.2.

So, is the repository ready?  A can take care of it fairly quickly if 
so.
no, it's not, but it's time we start. I'll ask infrastructure to create 
it, then start to move stuff around (from the server, so we don't loose 
CVS history).

I'll ring the bell when I'm done and the repository is ready.

--
Stefano.

Re: cvs commit: cocoon-2.1/src/webapp/WEB-INF cocoon.xconf

[Antonio Gallardo]

Stefano Mazzocchi dijo:
>
> On Thursday, Oct 9, 2003, at 22:30 Europe/Rome, Antonio Gallardo wrote:
>
>>> antonio 2003/10/09 13:12:35
>>>
>>>   Modified:src/webapp/WEB-INF cocoon.xconf
>>>   Log:
>>>   Fixing bug related to woody form handling posted
>>>   by Carlos Chávez. Bruno Dumon suggested the fix
>>>   and it works back again.
>>>
>>>   Revision  ChangesPath
>>>   1.31  +1 -1  cocoon-2.1/src/webapp/WEB-INF/cocoon.xconf
>>>
>>>   Index: cocoon.xconf
>>>   ===
>>> RCS file: /home/cvs//cocoon-2.1/src/webapp/WEB-INF/cocoon.xconf,v
>>> retrieving revision 1.30
>>>   retrieving revision 1.31
>>>   diff -u -r1.30 -r1.31
>>>   --- cocoon.xconf  6 Oct 2003 16:10:55 -   1.30
>>>   +++ cocoon.xconf  9 Oct 2003 20:12:35 -   1.31
>>>   -
>>>   +
>>
>> Next time we need to be more carefully :)
>
> i don't get it. if the above breaks woody, this is a hack, not a fix.
> we need to really fix the bug, not to route around it. any info on
> where the problem is?

This problem does not breaks woody. It breaks Flow, continuations, woody
and maybe other areas that I am not using. Maybe someone else can post
other related problems.

The problem looks to be part of Xerces. Snip from cocoon.xconf:


| - reuse-parsers (boolean, default = true) : do we want to reuse
| parsers or create a new parser for each parse ?
| Note : even if this parameter is true, parsers are not recycled
| in case of parsing errors : some parsers (e.g. Xerces) do not like
| to be reused after failure.


I don't know if this is a hack or not, but this was always false since I
am using Cocoon. Also, don't know if we need to go into Xerces parser and
repair the error.

Best Regards,

Antonio Gallardo.

[gt2003] thank YOU !

[Steven Noels]

Hi all,

browsing through all the 'thank you' mails, getting increasingly
embarrased, I'd simply like to say 'thank YOU'.
Thanks for the enthusiasm, expressed by signing up and showing up,
sometimes after considerable travel or lodging adventures. Thanks for
the trust, expressed by happily paying the registration fee, allowing us
to organize all this without going bust. Also thanks for the many, many
people who showed up for their second GetTogether: you guys rock.
Organizing an event is like preparing an infrastructure which the
participants *can* make use of, *if* they choose to - like a unassembled
box of Meccano. Having Wifi on a conference floor is kinda cool, but
becomes great when people start using it as a communication mesh to
jointly take notes, and pushing them live as fast as possible, so that
those who couldn't make it can still be part of it. Kudos to Bertrand
and Jeremy, who started this, as well as those who joined them.
I'd also like to thank Gianugo, Matthew, Massimo, Andrew & David and
Sylvain, whose companies agreed to help organizing the GetTogether. Oh
yes, I should address them as Orixians, but in the end, when preparing
badges, setting up WiFi access, rehearsing Bach with soaked pants and
crawling on the floor with power plugs, it's about being a bunch of
friends rather than some dull business thing.
As I concluded the 'thank you' sessions during the event, I'd especially
like to thank my friends & colleagues, Marc & Bruno, working hard on
paid-for projects, buying me time to organize things, and coping with
the occasional crisis when I'm messing up.
The day after, we were already jotting down notes for next year's
edition. Some cool new things we are dreaming about, taking into account
serious suggestions and wild ideas gathered during these intense,
tiring, but extremely rewarding two days (and three nights). This won't
become yet another dull conference, be sure of that.
The fact that so many of you showed up, and the intense buzz of people
connecting with each other during these two days, shows how strong our
community is. Above code and wonderful technology, Cocoon is a people's
project. I feel proud being able to create a meeting ground for such a
wonderful group of people. Thank YOU for this.
See you next year,


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

Re: [RT] what cocoon forms lack

[Upayavira]

I have a prototype of an upload widget on my HDD. Just need to finalise 
a sample before committing. It is what you describe as 'passive'. It 
holds within itself the Part when a file is uploaded, which can then be 
accessed from flow.

Oh, and I would _love_ to see a CocoonForms linotype widget. Ideas start 
streaming forth...

Regards, Upayavira

Stefano Mazzocchi wrote:

Thanks to the great energy that Sylvain is able to put into things, we 
now have a community consensus on making woody the official cocoon 
form framework.

On the trip back from the GT, I spent some time talking to David 
Nuescheler. A while ago, I suggested him to take a look at linotype 
and he liked the concept and told his guys to use it.

On the train, he told me: "you know, the idea of making linotype a 
woody widget is not so far off as it seems, we did our own form 
framework and editing framework and came up with nothing that could 
distinguish the two, so we are making an effort to merge the two".

This triggered an incredible amount of thinking... during the hours 
that took me to get back and thanks to sylvain's handouts, I was able 
to have a solid reference for my thinking.

   - o -

There are two widgets that cforms are missing:

 - editor
 - uploader
I see two potential types of editor:

 - plain text
 - stuctured text
Rich text is one of the potential structured text.

I dislike "textarea" as a style if an string input field. it doesn't 
feel right: a textarea is the style of an editor.

I also see two potential types of uploaders:

 - active
 - passive
Passive uploaders are the usual ones, the ones with a input field and 
a "browse" button. (normally native widgets that are not CSS modifiable)

Active uploaders are the one that react on the content being uploaded 
and show it (like the image uplaoder in linotype).

The idea is the following: both widgets make available to the 
controller (after having been processed), an object model that 
contains the content. The template generators should be able to 
process the object model of a structured text and crawl it 
transparently to generate SAX events.

- o -

Note, however that these widgets don't resolve the need for a 
semi-structured editing capabilities of the page (a-la 
contentEditable), but they go a pretty long way to provide capabilities.

Another interesting feature would be providing different "modes" for 
the editor, just like different tab panes that react on the content.

In linotype you have Wysiwig and markup, introducing a wiki mode is in 
my todo list.

I would love to have linotype as a cform widget with pluggable editing 
modes that share content: so that you can write your wiki text, then 
click on the wysiwig tag and edit content like that, back and forward, 
you can cut/paste stuff in and out.

now, what do you think?

--
Stefano.

Re: cvs commit: cocoon-2.1/src/webapp/WEB-INF cocoon.xconf

[Stefano Mazzocchi]

On Thursday, Oct 9, 2003, at 22:30 Europe/Rome, Antonio Gallardo wrote:

antonio 2003/10/09 13:12:35

  Modified:src/webapp/WEB-INF cocoon.xconf
  Log:
  Fixing bug related to woody form handling posted
  by Carlos Chávez. Bruno Dumon suggested the fix
  and it works back again.
  Revision  ChangesPath
  1.31  +1 -1  cocoon-2.1/src/webapp/WEB-INF/cocoon.xconf
  Index: cocoon.xconf
  ===
RCS file: /home/cvs//cocoon-2.1/src/webapp/WEB-INF/cocoon.xconf,v
retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- cocoon.xconf  6 Oct 2003 16:10:55 -   1.30
  +++ cocoon.xconf  9 Oct 2003 20:12:35 -   1.31
  -
  +
Next time we need to be more carefully :)
i don't get it. if the above breaks woody, this is a hack, not a fix. 
we need to really fix the bug, not to route around it. any info on 
where the problem is?

--
Stefano.

[RT] what cocoon forms lack

[Stefano Mazzocchi]

Thanks to the great energy that Sylvain is able to put into things, we 
now have a community consensus on making woody the official cocoon form 
framework.

On the trip back from the GT, I spent some time talking to David 
Nuescheler. A while ago, I suggested him to take a look at linotype and 
he liked the concept and told his guys to use it.

On the train, he told me: "you know, the idea of making linotype a 
woody widget is not so far off as it seems, we did our own form 
framework and editing framework and came up with nothing that could 
distinguish the two, so we are making an effort to merge the two".

This triggered an incredible amount of thinking... during the hours 
that took me to get back and thanks to sylvain's handouts, I was able 
to have a solid reference for my thinking.

   - o -

There are two widgets that cforms are missing:

 - editor
 - uploader
I see two potential types of editor:

 - plain text
 - stuctured text
Rich text is one of the potential structured text.

I dislike "textarea" as a style if an string input field. it doesn't 
feel right: a textarea is the style of an editor.

I also see two potential types of uploaders:

 - active
 - passive
Passive uploaders are the usual ones, the ones with a input field and a 
"browse" button. (normally native widgets that are not CSS modifiable)

Active uploaders are the one that react on the content being uploaded 
and show it (like the image uplaoder in linotype).

The idea is the following: both widgets make available to the 
controller (after having been processed), an object model that contains 
the content. The template generators should be able to process the 
object model of a structured text and crawl it transparently to 
generate SAX events.

- o -

Note, however that these widgets don't resolve the need for a 
semi-structured editing capabilities of the page (a-la 
contentEditable), but they go a pretty long way to provide capabilities.

Another interesting feature would be providing different "modes" for 
the editor, just like different tab panes that react on the content.

In linotype you have Wysiwig and markup, introducing a wiki mode is in 
my todo list.

I would love to have linotype as a cform widget with pluggable editing 
modes that share content: so that you can write your wiki text, then 
click on the wysiwig tag and edit content like that, back and forward, 
you can cut/paste stuff in and out.

now, what do you think?

--
Stefano.

Re: Ant/Maven/Centipede discussion

[Stephen McConnell]

Geoff Howard wrote:

Stephen McConnell wrote:

Geoff Howard wrote:

If you havn't read up on the blocks docs on the wiki lately (the 
last two weeks) you really should.  Stefano has put a good series of 
pages up detailing the plan and the current implementation ideas. 


Another followup question related to the following note on the wiki:

   * dependencies:
 o the URI(s) of the blocks on which this blocks depends on
   (optional)
I'm thinking about this relative to Avalon Merlin Block 
dependencies.  Under Merlin a block dependency is implicit - not 
explicit.  By implicit I mean that you can establish the dependencies 
that a blocks has relative to the computational dependencies that the 
blocks implementation exposes.  This means that a deployment system 
(tool or container) can resolve dependencies at runtime, using (a) 
locally available resources, (b) external repositories, or via more 
complex means (roadmap stuff) using (c) a remotely accessible service 
provider, or (d) remotely provided serialized block descriptions.


And as I see it and understand it - it must be this way because a 
Cocoon block as envisioned so far employs a "weak typing" in some of 
the "services" (maybe better expressed as "behavior") it exposes.  The 
reason services is in quotes is that they are not Avalon Services but 
weakly (intentionally) defined resources.  For example, an xsl (though 
currently it is required that this be exposed via a pipeline).  
Clearly in that case all the explicitness of java that makes 
computational dependencies possible is out the window and you have to 
fall back on some rude indentifier for a generalized block "behavior".

By the way, I think you and Stefano were misunderstanding each other 
over the description of this issue.  When he was describing blocks as 
"functional" units you seemed to read that more as "function_ing_" 
(i.e., 'they work' or 'self-contained').  I think he was describing 
this generalized behavior aspect.

Now, a major question in the back of my mind is whether this 
generalized behavior contract can be represented (implicitly from a 
block developer's standpoint) via an Avalon Service which may make 
Avalon/Merlin blocks closer to Cocoon blocks than they seem at present.


Geoff:

The above is a good summary.  It also hilights the need to describe weak 
typing - but I'm sure that underling this is a correlation with strong 
typing and general service management concerns.  My hunch is that the 
soft/weak typing is comming from a data-driven perspectives wheras the 
hard/strong typing is comming from the comutational service management 
perspective.

Having said that though, I definitely resonate with the need to get 
going.  I feel the best way forward is to look for true synergy 
(either present or future) in the implementation phase without bogging 
down.


Similar sentiments here.

There are two distinctly different ways of looking at synergy - each 
with different risks and potential impact.  From a component/service 
management perspective there is some interesting stuff evolving in 
avalon that has significant potential here.  The two different aspects 
concerns (a) passive usage - as in using containment tools for service 
deployment, and (b) active usage where container side APIs are 
extended.  Generally speaking the active usage is something I'm not keen 
on seeing - i.e. directly using container-side APIs is something we 
should be avoiding.  But there are exceptions - for example the 
meta-info package and repository packages could be highly useful in 
dealing with some of the issues currently in focus. 


What I have not resolved in my head yet is how the dependency url for 
cocoon blocks translate to computational descriptions (or to put this 
into Merlin terms, how can I translate a cocoon block uri into 
computation service request that could be used in Merlin to return a 
serialized Merlin block descriptor)?


I am not sure I have wrapped my head around the parallel universe to 
even understand the question.  Ever see the Seinfeld where they meet 
up with the "bizarro" parallel Seinfeld/Kramer/George? 


And a similar feeling from the other side of the spectum :-)

A key thing in the above question is the point that things like XML 
descriptors rapidly dissapear in the current Avalon object model.  You 
have XML descriptors of component types (detailing things like 
dependencies, context criteria, etc.) - the meta info.  These get 
translated into Type instances.  Then above this you have a similar 
process with the block.xml files with builders that translate XML into 
deployment and container distrectives (meta data).  Above this you have 
a meta model - which brings together meta-info descriptors with 
meta-data  and a runtime context.  The end result is a deployment model 
and this is the thing that is used when updating configuration, or 
adding a ne component or sub-container, etc. 

All of the meta-info and meta data is seri

Re: [HUM] block names (Re: Renaming Woody to "Cocoon Forms" ?)

[Michael Melhem]

On Thu, Oct 09, 2003 at 10:55:58PM +0200, Marc Portier wrote:
> 
> 
> Michael Melhem wrote:
> 
> >On Thu, Oct 09, 2003 at 01:13:38PM +0200, Carsten Ziegeler wrote:
> >
> >>Bertrand Delacretaz wrote:
> >>
> 
> 
> 
> >>>We can probably keep Woody as the block name though, in homage to the
> >>>great sandwiches delivered to the great original authors of Cocoon
> >>>Forms ;-)
> >>
> >>I had a "Woody" yesterday; well...it's not that bad.
> >
> > 
> > Carsten, tooo much information mate, ;)
> >
> > cheers,
> > Michael
> >
> 
> eheh, next time we need a name for a new block I'll propose 'rooster' ;-)

hmmm...I think we might need a "rooster" plugin :)

Michael
> 
> -marc=
> -- 
> Marc Portierhttp://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog at  http://radio.weblogs.com/0116284/
> [EMAIL PROTECTED]  [EMAIL PROTECTED]
> 
> 
> 

[HUM] block names (Re: Renaming Woody to "Cocoon Forms" ?)

[Marc Portier]

Michael Melhem wrote:

On Thu, Oct 09, 2003 at 01:13:38PM +0200, Carsten Ziegeler wrote:

Bertrand Delacretaz wrote:



We can probably keep Woody as the block name though, in homage to the
great sandwiches delivered to the great original authors of Cocoon
Forms ;-)
I had a "Woody" yesterday; well...it's not that bad.

Carsten, tooo much information mate, ;)
cheers,
Michael
eheh, next time we need a name for a new block I'll propose 'rooster' ;-)

-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at  http://radio.weblogs.com/0116284/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: [RT] Separation of Blocks and Avalon

[Berin Loritsch]

Stefano Mazzocchi wrote:


if Fortress was there, admittedly, things would be easier... but then 
again, lots of talks, but nobody is able, wants or has 
time/energy/braveness to do the migration.
Huh?  I have offered, and have been told to wait until Cocoon 2.2.

So, is the repository ready?  A can take care of it fairly quickly if so.



--

"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
- Benjamin Franklin

Re: [RT] Separation of Blocks and Avalon

[Upayavira]

Stefano Mazzocchi wrote:
...
if Fortress was there, admittedly, things would be easier... but then 
again, lots of talks, but nobody is able, wants or has 
time/energy/braveness to do the migration.
My impression is that Berin is willing, but he's just waiting on the 2.2 
repository.

Regards, Upayavira

JIRA (was Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity))

[Ugo Cei]

Stefano Mazzocchi wrote:
but I agree on your third point: locking could be applied (even if a  
very bad move for them).
But remember that you can always export your entire JIRA database in XML 
with a single command. So maybe your code can be locked, but your data not.

Stefano.
	Ugo

Re: Renaming Woody to "Cocoon Forms" ?

[Marc Portier]

Joerg Heinicke wrote:

Bertrand Delacretaz wrote:

I think there was agreement on Monday about this, do we need a vote, 
or am I mistaken about the agreement?


Someone mentioned that "Forms" in the name is "to official" and Stefano 
answered "if we won't have forms in the name we don't need to rename it 
at all". Such a nice toy name :) But I have no problem with renaming it.

Naming it "Cocoon Forms" is a nice parallel to "Cocoon Flow", and 
shows that we're betting the farm on it, which I like.


+1

+1

We can probably keep Woody as the block name though, in homage to the 
great sandwiches delivered to the great original authors of Cocoon 
Forms ;-)


-1 either "Woody" or "Cocoon Forms", not a mixture

yes, same feeling here

however I do like the idea of holding on to some 
historic-faits-dhiver-reference by adding a cocoon forms sample that 
shows how to use it for building a sandwich-lunch-ordering application :-)

actually we should change namespaces too, and the used prefixes

as well as some classnames,
and some stuff in the samples, possible references from other blocks, 
the (wiki) docos,...

any feelings around this?

regards,
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at  http://radio.weblogs.com/0116284/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: Ant Class Loading & CocoonTask

[Upayavira]

Stefano Mazzocchi wrote:

On Thursday, Oct 9, 2003, at 21:45 Europe/Rome, Upayavira wrote:

Stefano Mazzocchi wrote:

On Thursday, Oct 9, 2003, at 14:19 Europe/Rome, Upayavira wrote:

I have written a Cocoon Ant task, which is really neat, and, as 
Marc was suggesting, it shares its config code with the CLI.

However, I'm having some classloading problems with it. I set up an 
AntClassLoader which points only to WEB-INF/lib, and it 
successfully loads in CocoonBean and associated classes. When it 
gets into the initialisation phase, however, it gets a Logger from 
Ant's copy of Velocity, rather than from a Cocoon jar.

How can I force the class loader to ignore Ant's classpath and just 
use Cocoon's for everything?


Did you try forcing the classloader in the task' thread context? you 
can basically ask the current classloader, wrap it with yours and 
set that one in (this is what the ParanoidCocoonServlet does, BTW, 
Sylvain was also able to get classes directly from Eclipse without 
the need redeploy)

that might trigger security exceptions in protected environments, 
but ant is never used under a security manager (AFAIK).


Below is the relevant code snippet (note the consciously hard coded 
path!). I just create an AntClassLoader and off I go. But it tries to 
load org.apache.log.Hierarchy from Ant's copy of Velocity, rather 
than our own library. The loader.setThreadContextLoader() 
does force the classloader in the task's thread context, I think. But 
it is still getting me a class from Ant. The AntClassLoader does wrap 
the thread class loader, as I think you're saying.

I tried extending the AntClassLoader and copying the 
paranoidclassloader's loadClass method across into my subclass, but 
my loadClass method was never called.

Any ideas? This is frustrating because I think I'm so close...

   AntClassLoader loader = null;
   Project project = getProject();
 Path path = new Path(project);
 FileSet classes = new FileSet();
   classes.setDir(new File("d:/documents/cocoon/cocoon 
dev/build/eclipse/classes"));
   path.addFileset(classes);
 FileSet fileSet = new FileSet();
 fileSet.setDir(getLibDir(xconf));
   fileSet.setIncludes("*.jar");
 path.addFileset(fileSet);

   loader = new AntClassLoader(project.getCoreLoader(), project,
   path, false);
//loader.setParent(null); uncommenting this makes no difference
loader.setIsolated(true);
   loader.setThreadContextLoader();
 try {
   CocoonBean cocoon = new CocoonBean();
   OutputStreamListener listener = new 
OutputStreamListener(System.out);
   cocoon.addListener(listener);
   BeanConfigurator.configure(xconf, cocoon, "", uriGroup, 
listener);

   System.out.println(getProlog(Constants.NAME, 
Constants.VERSION, Constants.YEAR));

   cocoon.initialize();
   cocoon.process();
   cocoon.dispose();
   listener.complete();
   int exitCode = (listener.isSuccessful() ? 0 : 1);
   } catch (Exception e){
   System.out.println("Exception: "+e.getMessage());
   e.printStackTrace();
   }
   loader.resetThreadContextLoader();
Regards, Upayavira

Don't know how the AntClassLoader works, but I don't know if you are 
setting the classloader at all.

You should be doing something like this

  Thread thread = Thread.currentThread();
  ClassLoader oldCL= thread.getContextClassLoader();
  ClassLoader newCL = new YourClassloader(oldCL);
  thread.setContextClassLoader(newCL);
HTH
That's pretty much what the Ant stuff does. And it's got a 'parentFirst' 
option which defines the order in which parent/child should be queried, 
but it doesn't seem to work. I'll keep on on the Ant list.

Oh, and I'm s close :-(

Regards, Upayavira

Re: [RT] Separation of Blocks and Avalon

[Stefano Mazzocchi]

On Thursday, Oct 9, 2003, at 17:15 Europe/Rome, Ryan Hoegg wrote:

Rather than have cocoon blocks extend avalon blocks, I think cocoon 
blocks could use avalon blocks.
Ok, I see your point.

Instead of having a /COB-INF and a /BLOCK-inf, perhaps we include 
avalon blocks in /COB-INF/lib and delegate their deployment to the 
avalon container.  This could even allow cocoon blocks to provide 
avalon blocks to the container, as well as require them.
I would not know how to do this! I'm not scared by merlin, I'm scared 
about the million little details that cocoon assumes on top of ECM and 
that are now considered deprecated by the "modern" containers.

if Fortress was there, admittedly, things would be easier... but then 
again, lots of talks, but nobody is able, wants or has 
time/energy/braveness to do the migration.

It may help to distinguish between different types of dependencies:
1. Block dependency.  As described in 
http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition and specified 
in http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring .  What we (I 
think) have been talking about in several threads.
2a. Avalon dependency by block.  This would be some avalon 
service/component that is required by the block, and would be 
explicitly declared.  An example might be a Transformer or the Flow 
engine.
2b. Avalon dependency by avalon block/component/service.  This would 
be some avalon service that is required by an avalon service or block 
that is included with the cocoon block.  For example, I have a 
UserManager service that depends on a UserRepository service, which 
could be implemented by an OJBUserRepository.  If the cocoon block 
included the UserManager block, it might ask the Parent Component 
Manager for a UserManager, and might be provided with the 
OJBUserRepository.
I fear the complexity of such a move.

2b is the situation in which I think we could leverage the work being 
done by the various avalon containers.  We would not have to 
explicitly define transitive avalon dependencies, as the avalon 
container can infer those from the avalon block that we give to it.
True and what you describe is a sane and balanced proposal.

I just think that we should keep going with the design with have and 
with the use of the component model that we are used to and move on 
incrementally.

The machinery required to implement a component manager that is 
block-aware is very simple, probably a few lines on top of what we 
already have. even classloading should be trivial since dependencies 
are explicit.

but changing the way cocoon works in respect of component model, well, 
that's touching every single class!!! most of the cocoon developers are 
scared by this (me included), as this is the main reason why it didn't 
happen yet.

I'm willing to implement blocks, even if this means to rewrite some 
code that is already somewhere else. I might be wrong, but the 
implementation should be relatively easy (Sylvain and I discussed 
things in detail).

But moving from ECM to Fortress and from Fortress to Merlin for the 
entire cocoon component model? well, that scares the crap out of me in 
terms of number of lines of code to modify and potential bugs to 
introduce.

But if someone more knowledgble wants to do the transition, I'd be more 
than happy to be proven wrong and have cocoon move to a technology that 
is supported actively and not considered obsolete by the community 
around it.

Note, also, that your proposal is orthogonal to the implementation of 
cocoon blocks: today we use ECM and we keep use the same approach for 
java components provided by the cocoon blocks.

if in the future we change to a different java component model, we 
change it everywhere, including blocks.

if the migration is painless for cocoon own components (as it should 
be), it will be for blocks too.

the two things are, IMO, independent and can happen at different times.

--
Stefano.

ReSTy continuations (was Re: Renaming Woody to "Cocoon Forms" ?)

[Marc Portier]

Stefano Mazzocchi wrote:



[at the hackaton, there was a discussion on why the REST-based approach 
that Marc proposed cannot be matched one-2-one with the flow approach. 
Marc agreed that his idea of continuation and the current continuation 
are different concepts and forcing them into the same terminology might 
stretch the paradigm too much]

yep, hackathon discussion made me see some fundamental diffs

yet still I see loads of opportunities in the ReSTy approach and I do 
think Cocoon's sitemap fits big time to the general ideas behind it

I'm currently somewhat in doubth around next steps, and am just betting 
on some background-mind-processing thread working out how the ReST 
benefits could be more naturally added or at least made available to the 
cocoon user base.

basically I'm still all ears to others wanting to join in the fun.

regards,
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at  http://radio.weblogs.com/0116284/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: [RT] FirstFriday - monthly virtual Hackathon

[Bertrand Delacretaz]

Le Jeudi, 9 oct 2003, à 22:20 Europe/Zurich, Michael Melhem a écrit :
Is this thing on 7.11.2003?
it is, see 
http://wiki.cocoondev.org/Wiki.jsp?page=FirstFridayNovember2003

-Bertrand

Re: Track feature requests in bugzilla?

[Stefano Mazzocchi]

On Thursday, Oct 9, 2003, at 21:18 Europe/Rome, Joerg Heinicke wrote:

Stefano Mazzocchi wrote:

also, i don't want to do conversations over bugzilla, it's painful 
and removes the ability to estimate people relationships (think >> 
agora)
Hmm, stupid answer, but is it better to communicate over the wiki? I 
don't think so.
nono, you missed my point: bugzilla forces discussion to happen over 
the issue comments. wiki, since it's hard to do communication 
overthere (as you suggest), forces you to write comments on email, 
like it should be.
And what's so bad about communication on bugzilla? Every mail is sent 
to the lists. The issues can also be discussed on the list by simply 
replying to an email. The only missing point is the "real" sender of a 
mail for bugzilla comments, isn't it?
yes, and the ability to sort messages in threads since every bugzilla 
email is detached.

Scarab is cool, but like every tigris project seems to be in 
continous alpha mode and has been so for years. This is unlikely to 
change fast.
Thanks for the information.

If there is no real alternative to bugzilla, we should use it.
Ah, BTW, Scarab *is* better than bugzilla and stable enough for use... 
I just heard it's a pain to migrate stuff from bugzilla.

Nowhere else information about specific issues are collected so 
compactly.
true

Mailing lists must be searched for an issue like a haystack for the 
needle (it's overstated but I think you know what I mean).
true

I'm not against it, I just suggest we don't use it for communication.

Another issue is the configuration of bugzilla itself. Isn't it 
customizable? Furthermore more recent versions offer more options.
I'll gladly let you guys take care of this ;-)

--
Stefano.

Re: [RT] FirstFriday - monthly virtual Hackathon

[Michael Melhem]

On Thu, Oct 09, 2003 at 02:01:16PM +0200, Bertrand Delacretaz wrote:
> Le Jeudi, 9 oct 2003, ? 13:57 Europe/Zurich, Michael Melhem a ?crit :
> >...  Perhaps the IRC session should be logged (by a channel bot?)
> > and then the transcript mailed to the cocoon-dev mailing list
> > so that the discussion can be archived.
> > 
> > This would negate the "synchronous" nature of an IRC meet and
> > alleviate fears that some of the desgin discussions/decisions would
> > be effectively taken "off line" with the introduction of IRC
> 
> Sounds good, would you be able to do that?
> I have no idea how to run a "channel bot".

Sure would be happy to help if i can - not that i know much
about bots myself.

Is this thing on 7.11.2003?

cheers,
Michael
> 
> There *will* be discussions on IRC certainly, so this might be a good 
> experiment for the first FirstFriday (got got it?).
> 
> -Bertrand
> 
> 

Re: Ant Class Loading & CocoonTask

[Stefano Mazzocchi]

On Thursday, Oct 9, 2003, at 21:45 Europe/Rome, Upayavira wrote:

Stefano Mazzocchi wrote:

On Thursday, Oct 9, 2003, at 14:19 Europe/Rome, Upayavira wrote:

I have written a Cocoon Ant task, which is really neat, and, as Marc 
was suggesting, it shares its config code with the CLI.

However, I'm having some classloading problems with it. I set up an 
AntClassLoader which points only to WEB-INF/lib, and it successfully 
loads in CocoonBean and associated classes. When it gets into the 
initialisation phase, however, it gets a Logger from Ant's copy of 
Velocity, rather than from a Cocoon jar.

How can I force the class loader to ignore Ant's classpath and just 
use Cocoon's for everything?


Did you try forcing the classloader in the task' thread context? you 
can basically ask the current classloader, wrap it with yours and set 
that one in (this is what the ParanoidCocoonServlet does, BTW, 
Sylvain was also able to get classes directly from Eclipse without 
the need redeploy)

that might trigger security exceptions in protected environments, but 
ant is never used under a security manager (AFAIK).
Below is the relevant code snippet (note the consciously hard coded 
path!). I just create an AntClassLoader and off I go. But it tries to 
load org.apache.log.Hierarchy from Ant's copy of Velocity, rather than 
our own library. The loader.setThreadContextLoader() does 
force the classloader in the task's thread context, I think. But it is 
still getting me a class from Ant. The AntClassLoader does wrap the 
thread class loader, as I think you're saying.

I tried extending the AntClassLoader and copying the 
paranoidclassloader's loadClass method across into my subclass, but my 
loadClass method was never called.

Any ideas? This is frustrating because I think I'm so close...

   AntClassLoader loader = null;
   Project project = getProject();
 Path path = new Path(project);
 FileSet classes = new FileSet();
   classes.setDir(new File("d:/documents/cocoon/cocoon 
dev/build/eclipse/classes"));
   path.addFileset(classes);
 FileSet fileSet = new FileSet();
 fileSet.setDir(getLibDir(xconf));
   fileSet.setIncludes("*.jar");
 path.addFileset(fileSet);

   loader = new AntClassLoader(project.getCoreLoader(), project,
   path, false);
//loader.setParent(null); uncommenting this makes no difference
loader.setIsolated(true);
   loader.setThreadContextLoader();
 try {
   CocoonBean cocoon = new CocoonBean();
   OutputStreamListener listener = new 
OutputStreamListener(System.out);
   cocoon.addListener(listener);
   BeanConfigurator.configure(xconf, cocoon, "", uriGroup, 
listener);

   System.out.println(getProlog(Constants.NAME, 
Constants.VERSION, Constants.YEAR));

   cocoon.initialize();
   cocoon.process();
   cocoon.dispose();
   listener.complete();
   int exitCode = (listener.isSuccessful() ? 0 : 1);
   } catch (Exception e){
   System.out.println("Exception: "+e.getMessage());
   e.printStackTrace();
   }
   loader.resetThreadContextLoader();
Regards, Upayavira

Don't know how the AntClassLoader works, but I don't know if you are 
setting the classloader at all.

You should be doing something like this

  Thread thread = Thread.currentThread();
  ClassLoader oldCL= thread.getContextClassLoader();
  ClassLoader newCL = new YourClassloader(oldCL);
  thread.setContextClassLoader(newCL);
HTH

--
Stefano.

Re: [RT] FirstFriday - monthly virtual Hackathon

[Stefano Mazzocchi]

On Thursday, Oct 9, 2003, at 21:22 Europe/Rome, Torsten Curdt wrote:

So which tools are we going to use?

I think IIRC + bot sounds like a good and simple
start. At least for the virtual hackathon...
Did anyone try the other options yet?
I would love to have a shared whiteboard, P2P would be better, but even 
client server is not that bad since we have plenty of servers that we 
can use to host it.

--
Stefano.

Re: Ant Class Loading & CocoonTask

[Upayavira]

Stefano Mazzocchi wrote:

On Thursday, Oct 9, 2003, at 14:19 Europe/Rome, Upayavira wrote:

I have written a Cocoon Ant task, which is really neat, and, as Marc 
was suggesting, it shares its config code with the CLI.

However, I'm having some classloading problems with it. I set up an 
AntClassLoader which points only to WEB-INF/lib, and it successfully 
loads in CocoonBean and associated classes. When it gets into the 
initialisation phase, however, it gets a Logger from Ant's copy of 
Velocity, rather than from a Cocoon jar.

How can I force the class loader to ignore Ant's classpath and just 
use Cocoon's for everything?


Did you try forcing the classloader in the task' thread context? you 
can basically ask the current classloader, wrap it with yours and set 
that one in (this is what the ParanoidCocoonServlet does, BTW, Sylvain 
was also able to get classes directly from Eclipse without the need 
redeploy)

that might trigger security exceptions in protected environments, but 
ant is never used under a security manager (AFAIK). 
Below is the relevant code snippet (note the consciously hard coded 
path!). I just create an AntClassLoader and off I go. But it tries to 
load org.apache.log.Hierarchy from Ant's copy of Velocity, rather than 
our own library. The loader.setThreadContextLoader() does force 
the classloader in the task's thread context, I think. But it is still 
getting me a class from Ant. The AntClassLoader does wrap the thread 
class loader, as I think you're saying.

I tried extending the AntClassLoader and copying the 
paranoidclassloader's loadClass method across into my subclass, but my 
loadClass method was never called.

Any ideas? This is frustrating because I think I'm so close...

   AntClassLoader loader = null;
   Project project = getProject();
  
   Path path = new Path(project);
  
   FileSet classes = new FileSet();
   classes.setDir(new File("d:/documents/cocoon/cocoon 
dev/build/eclipse/classes"));
   path.addFileset(classes);
  
   FileSet fileSet = new FileSet();
  
   fileSet.setDir(getLibDir(xconf));
   fileSet.setIncludes("*.jar");
  
   path.addFileset(fileSet);

   loader = new AntClassLoader(project.getCoreLoader(), project,
   path, false);
//loader.setParent(null); uncommenting this makes no difference
 
   loader.setIsolated(true);
   loader.setThreadContextLoader();
  
   try {
   CocoonBean cocoon = new CocoonBean();
   OutputStreamListener listener = new 
OutputStreamListener(System.out);
   cocoon.addListener(listener);
   BeanConfigurator.configure(xconf, cocoon, "", uriGroup, 
listener);

   System.out.println(getProlog(Constants.NAME, 
Constants.VERSION, Constants.YEAR));

   cocoon.initialize();
   cocoon.process();
   cocoon.dispose();
   listener.complete();
   int exitCode = (listener.isSuccessful() ? 0 : 1);
   } catch (Exception e){
   System.out.println("Exception: "+e.getMessage());
   e.printStackTrace();
   }
   loader.resetThreadContextLoader();
Regards, Upayavira

Re: [RT] Finishing the first phase of block design

[Andreas Hochsteger]

Stefano Mazzocchi wrote:

- Will not explicitly declaring which resources are meant to be public 
cause trouble for block implementors and extenders?


?? well, in the sitemap I can be very precise on what I want to expose. 
and everything else is not exposed. the sitemap is like a virtual file 
system description, powerful enough to describe all possible systems.

If you have


 
  
 

than the contract moves at the file system level, but that's up to you 
to decide and a block extender can do


 
  
  
  
 

to provide extension that is procedural (but without exposing, for 
example layout.xml and layout2stylesheet.xslt which are just used 
internally)

With a single mechanism, it's much easier to do meaningful block extension.

Of course the flexibility of decoupling the uri space from the 
filesystem is a benefit - but is it necessary?


see above: I think so.

How hard is it really to keep filenames and directory locations for a 
selected group of public resources?


no, that's not the issue: the real issue is: if both resources and 
pipeline outputs are streams, why make a difference?

I agree with Stefano at this point.
The independence of the physical filesystem layout is one of the best 
features of Cocoon and it wouldn't be good to loose this great concept 
for blocks.

--
Stefano.
Bye,
Andreas

Re: [Austrian Cocoon Day] - Registration Open

[Andreas Hochsteger]

Great!
Just registered myself :-)
Reinhard Poetz wrote:

As some of you already know on

 ++
 |   November, 18th 2003  |
 ++
the first 

 ++
 |   Austrian Cocoon Day  |
 ++
will take place. 

You can find all necessary information (including an English section) at
our 
website: http://cocoon.ifs.tuwien.ac.at. 
Please note that the conference language will be mainly German.

So if you want to join us, hurry up and register at 
http://cocoon.ifs.tuwien.ac.at/anmeldung.html! The attendance of this
event
will be free.

Special thanks go to our speakers 
(http://cocoon.ifs.tuwien.ac.at/vortragende.html), 
the Vienna University of Technology and our sponsors Software AG and
Sun.

Cheers,
Reinhard and Alex

Re: [RT] FirstFriday - monthly virtual Hackathon

[Torsten Curdt]

So which tools are we going to use?

I think IIRC + bot sounds like a good and simple
start. At least for the virtual hackathon...
Did anyone try the other options yet?

cheers
--
Torsten

Re: Track feature requests in bugzilla?

[Joerg Heinicke]

Stefano Mazzocchi wrote:

also, i don't want to do conversations over bugzilla, it's painful 
and removes the ability to estimate people relationships (think >> 
agora)
Hmm, stupid answer, but is it better to communicate over the wiki? I 
don't think so.
nono, you missed my point: bugzilla forces discussion to happen over the 
issue comments. wiki, since it's hard to do communication overthere (as 
you suggest), forces you to write comments on email, like it should be.
And what's so bad about communication on bugzilla? Every mail is sent to 
the lists. The issues can also be discussed on the list by simply 
replying to an email. The only missing point is the "real" sender of a 
mail for bugzilla comments, isn't it?

Scarab is cool, but like every tigris project seems to be in continous 
alpha mode and has been so for years. This is unlikely to change fast.
Thanks for the information.

If there is no real alternative to bugzilla, we should use it. Nowhere 
else information about specific issues are collected so compactly. 
Mailing lists must be searched for an issue like a haystack for the 
needle (it's overstated but I think you know what I mean).

Another issue is the configuration of bugzilla itself. Isn't it 
customizable? Furthermore more recent versions offer more options.

Joerg

RE: getxml in XSP throws NPE if @path is invalid

[Antonio Gallardo]

Carsten Ziegeler dijo:
> Hi,
>
> I just checked in a patch that should fix this problem.
> Could you please test it?

Thanks Carsten, I am really busy with the OJB block.

Antonio Gallardo

RE: [RT] Source extensions

[Unico Hommes]

Hi Guido,

Thanks for your reply. See the comments inline.

Guido Casper wrote:
> 
> Hi Unico,
> 
> first let me say thank you for all you efforts in this area. I'm very
> excited about that (I start wondering ...). I'm sorry I cannot help
out
> more currently.
> 
> Unico Hommes <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > This is to let you know I've just submitted a patch [1] to cocoon
> > bugzilla for some enhancements to the SourceInspector code. It
solves
> > the problem of more efficiently finding specific properties than is
> > the case now. You may also be interested in a related patch [2] I
> > submitted earlier for basing SourceDescriptionGenerator on the
> > emerging TraversableGenerator that is now still in the scratchpad
> > area. I hope you like the enhancements and look forward to any
> > comments or questions you may have.
> >
> > One of the things I've noticed that I would like to discuss is that
> > the Source extensions such as LockableSource, InspectableSource,
etc.
> > are currently all located inside the Slide block, whereas they
should
> > probably be located in a more general block (a repository block?) or
> > else move them to excalibur sourceresolve.
> 
> I thought about that as well. The problem is that some of them do not
> seem general enough to move to excalibur. I'm +1 for a separate block
> although I'm not sure about the name.
>

Yes, a separate block seems more obvious to me too, at least for some of
the functionality. Property management may be general enough for
Excalibur imho.

> > SourceProperties 
> >
> > A SourceProperty is a piece of meta data in the form of an XML
> > element that can be associated with a Source. Currently the API
> > separates 'live' properties from 'computed' properties by handling
> > them in different ways.
> >
> > Computed properties are handled by components that implement the
> > SourceInspector interface [3]. Current implementations include
> > [Image]SourceInspectors that support 'width' and 'height' properties
> > and an XPathSourceInspector that queries a Source its XML content.
> > Modifiable properties on the other hand seem to be covered by the
> > InspectableSource interface [4] that has methods for setting and
> > removing SourceProperties.
> >
> > As these interfaces seem to partly overlap I think it would be
useful
> > to try and merge them or choose between one or the other. What I
like
> > about SourceInspector interface is the ability to plug in different
> > implementations of property handlers. We could extend the function
of
> > SourceInspectors to support writing SourceProperties and then
> > deprecate InspectableSource. Off course the SourceInspector would
> > have evolved into something else that would probably be better
> > described by a different name (SourceDescriptor?). This would allow
> > the definition of different datasources for storing SourceProperties
> > too. (I actually have a use case for that).
> 
> I like that. A SourceInspector implementation for inspect-enabling any
> ModifiableSource. 

Not necessarily ModifiableSource but just Source.

> Another step forward (besides RequestFactories) for
> making Cocoon a great WebDAV Server.

Actually, enabling Cocoon as a WebDAV server is the main reason I'm
interested in this.

> However I still feel the SourceInspector covers a different need than
a
> natively inspectable source. It sort of enhances source
implementations
> with additional properties. A natively inspectable source does not
need
> a SourceInspector for ordinary explicitely managed properties (with
> read/write access only through the InspectableSource interface).

True, but again the downside is that clients need to be aware of two
ways to approach SourceProperties.

> However I'm +1 making the SourceInspector support modifiable
properties.
> 
> >
> > As individual Source protocols may have their own way of storing
> > properties (f.i. a WebDAV Source), special SourceDescriptor
> > implementations will still be able to cover those situations
> > elegantly.
> 
> As it stands today the SourceInspector does not (and should not) care
> about the source implementation so it works with any source.
> 
> But I may be just missing the point.

You might ;) I admit that I wasn't very clear so let me explain. Suppose
you have a particular SourceProperty you want to expose that is stored
on a separate WebDAV server. A SourceInspector implementation could look
as follows:

WebdavSourceInspector {
   
   SourceProperty getSourceProperty(Source source, String uri, String
name)
   {
  if (source instanceof WebdavSource) {
 // we know where to look
 davLocation = source.getURI();
 return propfind(davLocation,uri,name);
  }
  return null;
   }
}

You are right that the inspector is aware of a concrete Source
implementation in this particular case. OTOH that is why it is called
WebdavSourceInspector.

By the way, I am not adamant about this

Re: Why is the link to the wiki so far away ?

[Litrik De Roy]

- Original Message - 
From: "Torsten Curdt" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 09, 2003 1:16 PM
Subject: Re: Why is the link to the wiki so far away ?


> Litrik De Roy wrote:
>
> > Remember during the GT2003 when Steven asked the audience whether they
check
> > the website or the wiki for docs?
> >
> > I was surprised to see how hard it is to find out about the wiki when
> > visiting the Cocoon website:
> >
> > There is no link on the navigation bar on http://cocoon.apache.org/ nor
on
> > http://cocoon.apache.org/2.1/ . There is a link on
> > http://cocoon.apache.org/link/sites.html and some other pages but they
are
> > too far away.
> >
> > A link to the Wiki would fit under the category "Community" I guess.
>
> that's a good one!
>
> ...but why not have it right on the front page if
> people use it that much?

Fine as well.

Just make sure that it is on all "homepages". Since 2.1 there is the main
page at http://cocoon.apache.org/ and the homepage for each version
http://cocoon.apache.org/2.0/ and http://cocoon.apache.org/2.1/

If there is only a link on the real homepage, people that jump right to the
homepage of the current release would miss it.

Litrik De Roy
www.litrik.com

> --
> Torsten
>
>
>

Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)

[Nicola Ken Barozzi]

Andrew Savory wrote:

On Thu, 9 Oct 2003, Nicola Ken Barozzi wrote:

The question is, what problem are we trying to solve?
AIUI, tracking serious feature requests.
And what's the problem, currently? AFAIK it's more about having people 
to do stuff rather than seeing what to do ;-)

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

Re: [RT] Source extensions

[Guido Casper]

Hi Unico,

first let me say thank you for all you efforts in this area. I'm very
excited about that (I start wondering ...). I'm sorry I cannot help out
more currently.

Unico Hommes <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This is to let you know I've just submitted a patch [1] to cocoon
> bugzilla for some enhancements to the SourceInspector code. It solves
> the problem of more efficiently finding specific properties than is
> the case now. You may also be interested in a related patch [2] I
> submitted earlier for basing SourceDescriptionGenerator on the
> emerging TraversableGenerator that is now still in the scratchpad
> area. I hope you like the enhancements and look forward to any
> comments or questions you may have.
>
> One of the things I've noticed that I would like to discuss is that
> the Source extensions such as LockableSource, InspectableSource, etc.
> are currently all located inside the Slide block, whereas they should
> probably be located in a more general block (a repository block?) or
> else move them to excalibur sourceresolve.

I thought about that as well. The problem is that some of them do not
seem general enough to move to excalibur. I'm +1 for a separate block
although I'm not sure about the name.

>
> I'd like to review some the issues I came across while exploring this
> package.
>
>
> SourceProperties 
>
> A SourceProperty is a piece of meta data in the form of an XML
> element that can be associated with a Source. Currently the API
> separates 'live' properties from 'computed' properties by handling
> them in different ways.
>
> Computed properties are handled by components that implement the
> SourceInspector interface [3]. Current implementations include
> [Image]SourceInspectors that support 'width' and 'height' properties
> and an XPathSourceInspector that queries a Source its XML content.
> Modifiable properties on the other hand seem to be covered by the
> InspectableSource interface [4] that has methods for setting and
> removing SourceProperties.
>
> As these interfaces seem to partly overlap I think it would be useful
> to try and merge them or choose between one or the other. What I like
> about SourceInspector interface is the ability to plug in different
> implementations of property handlers. We could extend the function of
> SourceInspectors to support writing SourceProperties and then
> deprecate InspectableSource. Off course the SourceInspector would
> have evolved into something else that would probably be better
> described by a different name (SourceDescriptor?). This would allow
> the definition of different datasources for storing SourceProperties
> too. (I actually have a use case for that).

I like that. A SourceInspector implementation for inspect-enabling any
ModifiableSource. Another step forward (besides RequestFactories) for
making Cocoon a great WebDAV Server.

However I still feel the SourceInspector covers a different need than a
natively inspectable source. It sort of enhances source implementations
with additional properties. A natively inspectable source does not need
a SourceInspector for ordinary explicitely managed properties (with
read/write access only through the InspectableSource interface).

However I'm +1 making the SourceInspector support modifiable properties.

>
> As individual Source protocols may have their own way of storing
> properties (f.i. a WebDAV Source), special SourceDescriptor
> implementations will still be able to cover those situations
> elegantly.

As it stands today the SourceInspector does not (and should not) care
about the source implementation so it works with any source.

But I may be just missing the point.

I could however imagine a special Source implementation that will be
configured for which SourceInspector implementation to use to
inspect-enable  modifiable sources (like FileSource).

>
>
>  Other Source meta data 
>
> The other Source extensions that exist in the Slide block all deal
> with a seperate area of meta management of Sources. Except for
> VersionableSource interface I have not reviewed them very well yet
> but am wondering inhowfar these could be covered by just
> SourceProperties (I am just guessing here). At the very least I am
> concerned with the fact that implementing all these different
> interfaces leads to rather large class definitions.
>
> Comments?

I share the concern that the Source classes get bigger and bigger.
However I fail to see how outsourcing the inspectable part solves the
problem in general. I think this should be decided from case to case
(LockableSource comes to mind).

Not being familiar with JSR147 or JSR170 I wonder how these approaches
deal with it. BTW wasn't a JSR170 draft available somewhere?

For the WebDAVSource (being based on the Slide webdav client lib) it
would be more convienient (implementation-wise) to leave the inspectable
code there.

Guido

>
> Regards, Unico
>
>
> 

DO NOT REPLY [Bug 23700] - Error in XSLT (Xalan)

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23700

Error in XSLT (Xalan)





--- Additional Comments From [EMAIL PROTECTED]  2003-10-09 17:40 ---
I post a zip file with the data that produces the error. In the zip, there are 
two html files: output_error.html (generated with Cocoon) and output_ok.html 
(generated with J2SDK1.4 transformer). input.xml is the input data and 
transformer.xsl is the transformer. The transformer generates a HTML menu. You 
can see that output_error.html is wrong lookin at the Menu Principal->SFB-
>Valores submenu. You will see an item "ema> <" that is not correct (compare to 
the output_ok.html). Others submenus with errors are: 
Menu Principal->SFB->Clientes
Menu Principal->SFB->Seguridad->Mantenimiento de
Menu Principal->SFB->Cuentas Corrientes->Mantenimiento de Acuerdos

for example.

Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)

[Andrew Savory]

On Thu, 9 Oct 2003, Nicola Ken Barozzi wrote:

> The question is, what problem are we trying to solve?

AIUI, tracking serious feature requests.

Andrew.

-- 
Andrew SavoryEmail: [EMAIL PROTECTED]
Managing Director  Tel:  +44 (0)870 741 6658
Luminas Internet Applications  Fax:  +44 (0)700 598 1135
Orixo alliance: http://www.orixo.com/  Web:www.luminas.co.uk

DO NOT REPLY [Bug 23700] - Error in XSLT (Xalan)

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23700

Error in XSLT (Xalan)





--- Additional Comments From [EMAIL PROTECTED]  2003-10-09 17:30 ---
Created an attachment (id=8515)
Bug in Xalan

Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)

[Nicola Ken Barozzi]

Andrew Savory wrote:

On Thu, 9 Oct 2003, Stefano Mazzocchi wrote:

...
but don't impose bugzilla as the center of our work organization, it's
just too bad. :-(
It depends how we use it. I agree that conversations don't belong in
bugzilla, but I think conversation summaries added to bugzilla with
"Enhancement" tags could be effective organisation.
Of course, I guess summary emails of feature conversations are effective,
too.
The question is, what problem are we trying to solve?

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

[Austrian Cocoon Day] - Registration Open

[Reinhard Poetz]

As some of you already know on

 ++
 |   November, 18th 2003  |
 ++

the first 

 ++
 |   Austrian Cocoon Day  |
 ++

will take place. 


You can find all necessary information (including an English section) at
our 
website: http://cocoon.ifs.tuwien.ac.at. 
Please note that the conference language will be mainly German.

So if you want to join us, hurry up and register at 
http://cocoon.ifs.tuwien.ac.at/anmeldung.html! The attendance of this
event
will be free.

Special thanks go to our speakers 
(http://cocoon.ifs.tuwien.ac.at/vortragende.html), 
the Vienna University of Technology and our sponsors Software AG and
Sun.

Cheers,
Reinhard and Alex

Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)

[Andrew Savory]

On Thu, 9 Oct 2003, Stefano Mazzocchi wrote:

> hey, you sound like RMS, scary ;-)

I have my beard and sandles on back-order!

> but don't impose bugzilla as the center of our work organization, it's
> just too bad. :-(

It depends how we use it. I agree that conversations don't belong in
bugzilla, but I think conversation summaries added to bugzilla with
"Enhancement" tags could be effective organisation.

Of course, I guess summary emails of feature conversations are effective,
too.


Andrew.

-- 
Andrew SavoryEmail: [EMAIL PROTECTED]
Managing Director  Tel:  +44 (0)870 741 6658
Luminas Internet Applications  Fax:  +44 (0)700 598 1135
Orixo alliance: http://www.orixo.com/  Web:www.luminas.co.uk

Re: TR : Problem in SVGSerializer

[Sylvain Wallez]

BORGES Charles wrote:

Hi,

In the configure method of org.apache.cocoon.serialization.SVGSerializer
there is a problem when mapping config parameters to transcoder hints:
When  the parameter type is string, nothing is set. 
For example if you're using 
 in the
configuration of a SVGSerializer, the corresponding batik
KEY_USER_STYLESHEET_URI is set to "" In configure():

String keyType = parameters[i].getAttribute("type", "STRING").toUpperCase();
if ("FLOAT".equals(keyType)) {
// Can throw an exception.
 value = new Float(parameters[i].getAttributeAsFloat("value"));
} else if {
	...

} else {
// Assume String, and get the value. Allow an empty string.
 value = parameters[i].getValue("");
}
I think it should be value = parameters[i].getAttribute("value") instead.
 

Actually, this is more an inconsistency than a real bug: when @type is 
"string" or when there's no type, the value is considered as being the 
_content_ of the element, and not the @value attribute, i.e.


bar-string-value
Anyway, I fixed the inconsistency (2.1 CVS).

Thanks for reporting,
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)

[Stefano Mazzocchi]

On Thursday, Oct 9, 2003, at 16:05 Europe/Rome, Andrew Savory wrote:

Hi,

On Thu, 9 Oct 2003, Stefano Mazzocchi wrote:

Forrest uses Jira. Jira is much better than bugzilla. Jeff works for
the company that produces it. There is also a migration tool between
bugzilla and Jira. It's commercial, but free for open source use.
I would be +1 to migrate to Jira.
-1 for Jira.

Sorry Stefano, but I don't believe we should be using proprietary  
software
for critical infrastructure.

- We would have no access to the source code
- We would have to rely on a single organisation for development and  
support
- We have no guarantee that the license would be in perpetuity (I can't
find a copy of the license on their site).

For open source bts, Atlassian recommend bugzilla.
http://www.atlassian.com/software/jira/docs/latest/ 
faq.html#is_jira_open_source

I know bugzilla's interface can be tiresome, but it _does_ do the job,
it's tested and deployed worldwide, and it is free/libre.
hey, you sound like RMS, scary ;-)

all right, all right. don't want to fight but just remember that  
Forrest uses Jira (which is also installed already on cocoondev.org)  
and that i believe Jeff would patch a bug report much faster than you  
could do with the bugzilla source code in hand (having perl sourcecode  
or java binary code, IMO, it's the same thing)

but I agree on your third point: locking could be applied (even if a  
very bad move for them).

but don't impose bugzilla as the center of our work organization, it's  
just too bad. :-(

--
Stefano.

Re: [RT] FirstFriday - monthly virtual Hackathon

[Ryan Hoegg]

Marcus Crafter wrote:

The werken.com people have their IRC channel logged to the web, eg:

http://irc.codehaus.org/channels/geronimo/2003-09-15.html

and its updated in realtime. Maybe something similar might be possible?
Probably depends on the admins on the irc server we choose.
Cheers,

Marcus

 

Probably done with http://jerk.codehaus.org/

--ryan

[RT] Source extensions

[Unico Hommes]

Hi,

This is to let you know I've just submitted a patch [1] to cocoon bugzilla for some 
enhancements to the SourceInspector code. It solves the problem of more efficiently 
finding specific properties than is the case now. You may also be interested in a 
related patch [2] I submitted earlier for basing SourceDescriptionGenerator on the 
emerging TraversableGenerator that is now still in the scratchpad area. I hope you 
like the enhancements and look forward to any comments or questions you may have.

One of the things I've noticed that I would like to discuss is that the Source 
extensions such as LockableSource, InspectableSource, etc. are currently all located 
inside the Slide block, whereas they should probably be located in a more general 
block (a repository block?) or else move them to excalibur sourceresolve.

I'd like to review some the issues I came across while exploring this package.


    SourceProperties 

A SourceProperty is a piece of meta data in the form of an XML element that can be 
associated with a Source. Currently the API separates 'live' properties from 
'computed' properties by handling them in different ways. 

Computed properties are handled by components that implement the SourceInspector 
interface [3]. Current implementations include [Image]SourceInspectors that support 
'width' and 'height' properties and an XPathSourceInspector that queries a Source its 
XML content. Modifiable properties on the other hand seem to be covered by the 
InspectableSource interface [4] that has methods for setting and removing 
SourceProperties. 

As these interfaces seem to partly overlap I think it would be useful to try and merge 
them or choose between one or the other. What I like about SourceInspector interface 
is the ability to plug in different implementations of property handlers. We could 
extend the function of SourceInspectors to support writing SourceProperties and then 
deprecate InspectableSource. Off course the SourceInspector would have evolved into 
something else that would probably be better described by a different name 
(SourceDescriptor?). This would allow the definition of different datasources for 
storing SourceProperties too. (I actually have a use case for that).

As individual Source protocols may have their own way of storing properties (f.i. a 
WebDAV Source), special SourceDescriptor implementations will still be able to cover 
those situations elegantly.


 Other Source meta data 

The other Source extensions that exist in the Slide block all deal with a seperate 
area of meta management of Sources. Except for VersionableSource interface I have not 
reviewed them very well yet but am wondering inhowfar these could be covered by just 
SourceProperties (I am just guessing here). At the very least I am concerned with the 
fact that implementing all these different interfaces leads to rather large class 
definitions.

Comments?

Regards, Unico


[1]. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23694

[2]. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23699

[3] 
http://birgit.s.castasoftware.com:3080/api/java/org/apache/cocoon/components/source/InspectableSource.html
 *

[4] 
http://birgit.s.castasoftware.com:3080/api/java/org/apache/cocoon/components/source/InspectableSource.html
 *


* The cocoon website does not seem to list the complete javadocs.

Re: [RT] Separation of Blocks and Avalon

[Ryan Hoegg]

Stefano Mazzocchi wrote:

On Wednesday, Oct 8, 2003, at 19:22 Europe/Rome, Ryan Hoegg wrote:

Hi,

I've been following the block design discussion and wiki evolution 
with great interest for a couple months now (blame Geoff).  Blocks 
look wonderful, and I can't wait to develop my cocoon based 
applications as blocks.

I have a concern about the bundling of exposed avalon services with 
blocks.  Specifically, in the recent thread about "Finishing the 
First Phase of Block Design" and on 
http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition I see some 
duplicated effort.  As Stephen McConnell noticed, some of this 
functionality is already built, tested, and maintained in several 
avalon containers.  Why not package avalon blocks/services/components 
in the way the container expects, and include them somewhere like 
/COB-INF/lib or /COB-INF/public/lib?  Or, even cleaner separation can 
be had in some cases by deploying them to the avalon container 
independently.

If things are done this way, the problem noted in the thread I 
mentioned above could be completely avoided.  There would be no need 
to expose classes through the block interface because all java would 
be exposed as avalon services.
I think this would simplify the block design greatly, and allow us to 
focus on cocoon-specific aspects.


Let me see if I get this right: you are proposing that we make cocoon 
blocks
somewhat extend avalon blocks and we have /block-inf/ for information 
on the java components and /cob-inf/ for all the remainding 
cocoon-specific things, in order to be able to reuse existing avalon 
code?

But how can I describe dependencies if one part uses implicit ones and 
the rest uses explicit ones?

--
Stefano.
Rather than have cocoon blocks extend avalon blocks, I think cocoon 
blocks could use avalon blocks.  Instead of having a /COB-INF and a 
/BLOCK-inf, perhaps we include avalon blocks in /COB-INF/lib and 
delegate their deployment to the avalon container.  This could even 
allow cocoon blocks to provide avalon blocks to the container, as well 
as require them.

It may help to distinguish between different types of dependencies:
1. Block dependency.  As described in 
http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition and specified 
in http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring .  What we (I 
think) have been talking about in several threads.
2a. Avalon dependency by block.  This would be some avalon 
service/component that is required by the block, and would be explicitly 
declared.  An example might be a Transformer or the Flow engine.
2b. Avalon dependency by avalon block/component/service.  This would be 
some avalon service that is required by an avalon service or block that 
is included with the cocoon block.  For example, I have a UserManager 
service that depends on a UserRepository service, which could be 
implemented by an OJBUserRepository.  If the cocoon block included the 
UserManager block, it might ask the Parent Component Manager for a 
UserManager, and might be provided with the OJBUserRepository.

2b is the situation in which I think we could leverage the work being 
done by the various avalon containers.  We would not have to explicitly 
define transitive avalon dependencies, as the avalon container can infer 
those from the avalon block that we give to it.

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net

TR : Problem in SVGSerializer

[BORGES Charles]

Hi,

In the configure method of org.apache.cocoon.serialization.SVGSerializer
there is a problem when mapping config parameters to transcoder hints:

When  the parameter type is string, nothing is set. 
For example if you're using 
 in the
configuration of a SVGSerializer, the corresponding batik
KEY_USER_STYLESHEET_URI is set to "" In configure():

String keyType = parameters[i].getAttribute("type", "STRING").toUpperCase();
if ("FLOAT".equals(keyType)) {
// Can throw an exception.
  value = new Float(parameters[i].getAttributeAsFloat("value"));
} else if {

...

} else {
// Assume String, and get the value. Allow an empty string.
  value = parameters[i].getValue("");
}

I think it should be value = parameters[i].getAttribute("value") instead.

Re: Renaming Woody to "Cocoon Forms" ?

[Michael Hartle]

Sylvain Wallez wrote:

Torsten Curdt wrote:

...I doubt everyone knows what "woody" means in Australia ;) 
ROFTL ;-D

For those who hadn't special aussie lessons with Michael, check out 
the "vulgar slang" meaning at 
http://dictionary.reference.com/search?q=woody

Sylvain

It reminds me of one the "Austin Powers" movies with Mike Meyers (the 
one prior to "Goldmember", I think), where Woody Harrolson played a part 
in the very funny "Spotting Dr. Evils Spaceship"-style scenes :-)

Best regards,

Michael Hartle

Re: Renaming Woody to "Cocoon Forms" ?

[Sylvain Wallez]

Torsten Curdt wrote:



This is why having one official direction on the various areas is 
good(tm) and having a simple name for it "cocoon sitemap" "cocoon 
flow" "cocoon forms" would help our users to choose and feel more 
protected and a more solid foundation.


+1 


+1 also.

that's exactly what I was preaching in my presentation at the GT last 
year ;) glad we finally have something that seems to be community driven! 


I must say that I was totally amazed by the feedback after my 
presentation on Woody. Lots of people came to me asking questions, 
saying they agreed Woody was the way to go, saying they already used it 
and liked it, and proposing enhancements (more on my blog).

Maybe the community was expecting some kind of "go" sign to rush on 
Woody and it appears I clearly gave this sign at Gent. Amazing 
community, and sudden amazing responsibility for those that thought they 
were a bit alone on this stuff in their "woody corner of the blocks 
directory" ;-)

I love it :-)

Sylvain

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

Re: Renaming Woody to "Cocoon Forms" ?

[Sylvain Wallez]

Torsten Curdt wrote:

I had a "Woody" yesterday; well...it's not that bad.

Carsten, tooo much information mate, ;)

cheers,
Michael


...I doubt everyone knows what "woody" means in Australia ;) 


ROFTL ;-D

For those who hadn't special aussie lessons with Michael, check out the 
"vulgar slang" meaning at http://dictionary.reference.com/search?q=woody

Sylvain

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

Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)

[Andrew Savory]

Hi,

On Thu, 9 Oct 2003, Stefano Mazzocchi wrote:

> Forrest uses Jira. Jira is much better than bugzilla. Jeff works for
> the company that produces it. There is also a migration tool between
> bugzilla and Jira. It's commercial, but free for open source use.
>
> I would be +1 to migrate to Jira.

-1 for Jira.

Sorry Stefano, but I don't believe we should be using proprietary software
for critical infrastructure.

- We would have no access to the source code
- We would have to rely on a single organisation for development and support
- We have no guarantee that the license would be in perpetuity (I can't
find a copy of the license on their site).

For open source bts, Atlassian recommend bugzilla.
http://www.atlassian.com/software/jira/docs/latest/faq.html#is_jira_open_source

I know bugzilla's interface can be tiresome, but it _does_ do the job,
it's tested and deployed worldwide, and it is free/libre.


Andrew.

-- 
Andrew SavoryEmail: [EMAIL PROTECTED]
Managing Director  Tel:  +44 (0)870 741 6658
Luminas Internet Applications  Fax:  +44 (0)700 598 1135
Orixo alliance: http://www.orixo.com/  Web:www.luminas.co.uk

DO NOT REPLY [Bug 23700] - Error in XSLT (Xalan)

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23700

Error in XSLT (Xalan)





--- Additional Comments From [EMAIL PROTECTED]  2003-10-09 14:07 ---
Try to give some more information, otherwise the bug won't be accepted because
the encoding is correctly handled by Xalan in general.

What's your input, what's your output? What editor are you using to look at the
output? Are you sure it understands the output encoding and does not assume a
(wrong) default one?

Joerg

Re: Renaming Woody to "Cocoon Forms" ?

[Torsten Curdt]

This is why having one official direction on the various areas is 
good(tm) and having a simple name for it "cocoon sitemap" "cocoon flow" 
"cocoon forms" would help our users to choose and feel more protected 
and a more solid foundation.
+1

that's exactly what I was preaching in my presentation at the GT last 
year ;) glad we finally have something that seems to be community driven!
--
Torsten

DO NOT REPLY [Bug 23700] New: - Error in XSLT (Xalan)

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23700

Error in XSLT (Xalan)

   Summary: Error in XSLT (Xalan)
   Product: Cocoon 2
   Version: 2.0.4
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Minor
  Priority: Other
 Component: general components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Performing XSLT transformations whith special character put garbage in some 
text outputs. I found that the problem happens if the input has special 
characters, like accents (áéíóú). I try changing the encoding (UTF-8 and ISO-
8859-1), but the problem still persists.

RE: Renaming Woody to "Cocoon Forms" ?

[Carsten Ziegeler]

Stefano Mazzocchi wrote:
> 
>
> No matter what the result was, I think forcing people with one solution 
> forced  discussions to happen, which helped all the parties involved, 
> even to understand thing that were not previously understood by both 
> sides.
> 
> This is why having one official direction on the various areas is 
> good(tm) and having a simple name for it "cocoon sitemap" "cocoon flow" 
> "cocoon forms" would help our users to choose and feel more protected 
> and a more solid foundation.
> 
+1

In some areas we have two or three (or more) different solutions
all not satisfying the real users needs which is really crap. 
So, I consider this one of the most important discussions at
the GT and the result might be the most important one.

Carsten

Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)

[Stefano Mazzocchi]

On Thursday, Oct 9, 2003, at 14:51 Europe/Rome, Joerg Heinicke wrote:

also, i don't want to do conversations over bugzilla, it's painful 
and removes the ability to estimate people relationships (think >> agora)
Hmm, stupid answer, but is it better to communicate over the wiki? I 
don't think so.
nono, you missed my point: bugzilla forces discussion to happen over 
the issue comments. wiki, since it's hard to do communication overthere 
(as you suggest), forces you to write comments on email, like it should 
be.

Does anybody know the status of the move to Scarab? Is it project 
dependent? Does Scarab improve the usability/issue category handling?
Forrest uses Jira. Jira is much better than bugzilla. Jeff works for 
the company that produces it. There is also a migration tool between 
bugzilla and Jira. It's commercial, but free for open source use.

Scarab is cool, but like every tigris project seems to be in continous 
alpha mode and has been so for years. This is unlikely to change fast.

I would be +1 to migrate to Jira.

--
Stefano.

DO NOT REPLY [Bug 23699] - [PATCH] SourceInspector enhancements

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23699

[PATCH] SourceInspector enhancements

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||LATER



--- Additional Comments From [EMAIL PROTECTED]  2003-10-09 13:44 ---
Unico, thanks again. But please consider submitting an RT on this particular
topic: the Inspectable interface has been questioned a few times already, and I
think it's time to clean up the basement. Your ideas (and code!) are most
welcome, but I suggest we discuss them first in a broader way.

RE: Renaming Woody to "Cocoon Forms" ?

[Carsten Ziegeler]

Matthew Langham wrote:
> 
> >>> I had a "Woody" yesterday; well...it's not that bad.
> >>
> >>Carsten, tooo much information mate, ;)
> >>cheers,
> >>Michael
> >
> > ...I doubt everyone knows what "woody" means
> > in Australia ;)
> >
> 
> Hahaha - that's really funny :-).
> 
Ok, before someone finds a "really funny" description/picture
of a "Woody" in google (I just found someone which I wont
post here!), the "Woody" I ate yesterday is a SANDWICH
as everyone in the cocoon community should know anyway :)

Carsten

Re: Renaming Woody to "Cocoon Forms" ?

[Stefano Mazzocchi]

On Thursday, Oct 9, 2003, at 14:50 Europe/Rome, Michael Melhem wrote:

On Thu, Oct 09, 2003 at 01:13:38PM +0200, Carsten Ziegeler wrote:
Bertrand Delacretaz wrote:
I think there was agreement on Monday about this, do we need a vote, 
or
am I mistaken about the agreement?
I think we had consensus, however not all committers attended the 
hackathon,
so it might be that someone is -1 on it and has a good reason.

Naming it "Cocoon Forms" is a nice parallel to "Cocoon Flow", and 
shows
that we're betting the farm on it, which I like.
+1
Im not against naming it "Cocoon Forms" but we need to be
sure we want to lock Cocoon to a single Forms implementation.
I do. Just like I wouldn't want multiple flow, FOM or sitemap 
implementation as core.

We allow other people to write their own, but we support only one of a 
kind: this forces discussions instead of forking... remember the 
balkanization thread.

Which is a nice example, here, btw: the OT team proposed an alternative 
flow control concept and an alternative form framework, the community 
considered the first inferior to what we already had, but considered 
superior the second and promoted it as "official".

[at the hackaton, there was a discussion on why the REST-based approach 
that Marc proposed cannot be matched one-2-one with the flow approach. 
Marc agreed that his idea of continuation and the current continuation 
are different concepts and forcing them into the same terminology might 
stretch the paradigm too much]

No matter what the result was, I think forcing people with one solution 
forced  discussions to happen, which helped all the parties involved, 
even to understand thing that were not previously understood by both 
sides.

This is why having one official direction on the various areas is 
good(tm) and having a simple name for it "cocoon sitemap" "cocoon flow" 
"cocoon forms" would help our users to choose and feel more protected 
and a more solid foundation.

--
Stefano.

Re: Renaming Woody to "Cocoon Forms" ?

[Bertrand Delacretaz]

...I doubt everyone knows what "woody" means
in Australia ;)
hum. I'm starting to agree with you guys on the renaming ;-)

-Bertrand

P.S. http://psy.otago.ac.nz/r_oshea/slang.html

Re: Use of a connection in an avalon component

[Olivier Billard]

On 09/10/2003 15:10, Sylvain Wallez wrote:

Olivier Billard wrote:

Hi all !

I wonder how to use a DataSourceComponent and its connection in a 
custom cocoon avalon component, that is ThreadSafe, to use all 
performance and connection pool used in Cocoon.

Should I :
 - get a connection via datasource.getConnection() and close() it for 
each public method call,
 - get a connection in the initialize() method from the interface 
Initializable, close() it on the dispose() method from Disposable 
interface, and only create a Statement for each public method call ?
 - implement another avalon interface, like Runnable, to get/relase 
the Connection ?

I looked for exemples in the databases block, but the helpers are not 
Components. 


If your component is ThreadSafe, a single instance of it will exist in 
the whole system. JDBC connections being non thread safe, you *must* get 
and close them at each call. Don't be afraid to call close(): the 
connection you get is a wrapper managed by the DataSourceComponent which 
puts back the real request in the pool for later reuse when close() is 
called on the wrapper.
by later reuse, do you mean datasource.getConnection() ?

--
Olivier

Re: Renaming Woody to "Cocoon Forms" ?

[Matthew Langham]

I had a "Woody" yesterday; well...it's not that bad.

Carsten, tooo much information mate, ;)
cheers,
Michael
...I doubt everyone knows what "woody" means
in Australia ;)
Hahaha - that's really funny :-).

Matthew

Re: [RT] FirstFriday - monthly virtual Hackathon

[Stefano Mazzocchi]

On Thursday, Oct 9, 2003, at 14:24 Europe/Rome, Marcus Crafter wrote:

The werken.com people have their IRC channel logged to the web, eg:

http://irc.codehaus.org/channels/geronimo/2003-09-15.html
Impressive example of zero signal/noise ratio, BTW.

I really hope we do better than this.

--
Stefano.

DO NOT REPLY [Bug 23699] - [PATCH] SourceInspector enhancements

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23699

[PATCH] SourceInspector enhancements





--- Additional Comments From [EMAIL PROTECTED]  2003-10-09 13:29 ---
Created an attachment (id=8507)
zip file containing diffs for respective java source files

DO NOT REPLY [Bug 23699] New: - [PATCH] SourceInspector enhancements

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23699

[PATCH] SourceInspector enhancements

   Summary: [PATCH] SourceInspector enhancements
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: general components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The SourceInspector interface currently has no way to communicate the types of
properties it handles. In order to facilitate more efficient property lookups
this patch adds this functionality in the form of a method with the following
signiture:

String[] getExposedSourcePropertyTypes();

The returned strings are the qualified property names: format is of the form
namespace + "#" + name.

Additionally the patch contains some documentation improvements.

Re: Ant Class Loading & CocoonTask

[Stefano Mazzocchi]

On Thursday, Oct 9, 2003, at 14:19 Europe/Rome, Upayavira wrote:

I have written a Cocoon Ant task, which is really neat, and, as Marc 
was suggesting, it shares its config code with the CLI.

However, I'm having some classloading problems with it. I set up an 
AntClassLoader which points only to WEB-INF/lib, and it successfully 
loads in CocoonBean and associated classes. When it gets into the 
initialisation phase, however, it gets a Logger from Ant's copy of 
Velocity, rather than from a Cocoon jar.

How can I force the class loader to ignore Ant's classpath and just 
use Cocoon's for everything?
Did you try forcing the classloader in the task' thread context? you 
can basically ask the current classloader, wrap it with yours and set 
that one in (this is what the ParanoidCocoonServlet does, BTW, Sylvain 
was also able to get classes directly from Eclipse without the need 
redeploy)

that might trigger security exceptions in protected environments, but 
ant is never used under a security manager (AFAIK).

Any Ant experts out there?

[I've posted on ant-dev, but thought there might be an Ant expert or 
two over here too].

Regards,  Upayavira



--
Stefano.

Re: Renaming Woody to "Cocoon Forms" ?

[Torsten Curdt]

I had a "Woody" yesterday; well...it's not that bad.

Carsten, tooo much information mate, ;)
cheers,
Michael
...I doubt everyone knows what "woody" means
in Australia ;)
cheers
--
Torsten

DO NOT REPLY [Bug 23694] - [PATCH] TraversableSourceDescriptionGenerator

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23694

[PATCH] TraversableSourceDescriptionGenerator





--- Additional Comments From [EMAIL PROTECTED]  2003-10-09 13:23 ---
Created an attachment (id=8506)
zip containing updated java source

DO NOT REPLY [Bug 23694] - [PATCH] TraversableSourceDescriptionGenerator

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23694

[PATCH] TraversableSourceDescriptionGenerator





--- Additional Comments From [EMAIL PROTECTED]  2003-10-09 13:23 ---
Nice to hear you like the idea. I just noticed that the above attachement still
had some debug statements I should have cleaned up. If you or anybody do apply
this patch please use the updated attachement I am just about to commit.

Re: [RT] Finishing the first phase of block design

[Stefano Mazzocchi]

On Wednesday, Oct 8, 2003, at 04:50 Europe/Rome, Geoff Howard wrote:

Stefano Mazzocchi wrote:

I have updated the block design documents on the wiki. Changes were:
...

A few things are left to decide:
 1) the block metadata information in the block.xml file
  see http://wiki.cocoondev.org/Wiki.jsp?page=BlocksCob
 2) how blocks expose classloading to other blocks
 - o -
Descriptive Block metadata
--
The descriptive block metadata that we currently include is:
 ***
 ***
 ***
 ***
+1

Andreas suggested version number which is really handled already in 
the block id and release date.  I think a date though may be a useful 
additional piece of info.
Good point.

Ah, remember that "certification" or any other metadata on the 
"status" of the block is time dependent and therefore should *NOT* be 
included in this file.
Yup.

Exposing classes

Stephen proposed to separate the classes to expose in a different jar 
and expose that. I like this. It's simple and effective.
But instead of declaring classloaders or classpaths in the blocks, I 
propose to extend the block FS layout so that we have
for individual classes and resources:
 /classes
 /classes/public
 /classes/private
for jars:
 /lib
 /lib/public
 /lib/private
Hmmm.  That is quite different than what one would expect from the WAR 
paradigm, no?  Would

COB-INF/[classes|lib]
COB-INF/public/[classes|lib]
or

COB-INF/private/[classes|lib]
COB-INF/public/[classes|lib]
be any better?
This might suggest the concept that private is the location of all the 
things that are private so

 private/lib

means "I have libraries in the private section", so maybe I can put 
something else as well to have it protected? while

 lib/private

means "these are the private libraries"... but doesn't say anything 
about non-lib things. I still like this approach better, even if it 
moves away from the WAR paradigm (which is not a big deal, IMO, since 
blocks are different enough already)

the block manager will tranparently make available the classes found 
in the "public" folders to the blocks that depend on this block (and 
*ONLY* to those! classloading isolation is very important to achieve 
hot deployment functionality without impacting the performance of a 
running system too much)
Is there never a way to avoid duplicating common jars between blocks?
Avoid? well, not architecturally, that could means weird classloading 
issues.

I think we may be wise to go this way but I know this will be 
unpopular and misunderstood and deserves some thought.
good point, though.

the classloader will also check for conflicts: in fact, it will be 
considered an error to depend on two blocks that provide one or more 
classes with the same absolute name.
Hmmm.  not sure I can mentally eliminate all valid cases at this 
stage.  Would there ever be an older version and a newer version of a 
block deployed in the same space for example? (probably not but 
thinking out loud)
Oh, yeah, the above "modulo versioning". If the same class applies in 
blocks that differ only for their versions, it's good. The problem is 
when two completely different blocks do. (we might signal a warning 
instead of an error, but that's an implementation detail).

Exposing Resources
--
I'm adding this because my brain is still a little unsure about this. 
So far, we've said that file resources (an xsl for example)

1) need to be exposed via a sitemap pipeline, even if only by a reader
2) are not anywhere declared explicitly (except in the pipeline of 
course)
3) are not distinguised from resources meant to be private by any 
formal semantics, though this information could be conveyed 
human-to-human in any block docs (blocs? blockumentation? ;) ).

Here are my oustanding questions:

- Will we regret requiring the overhead of pipeline setup (runtime I 
mean) for blocks which expose a great deal of otherwise static 
resources?
could be. remember though that the block: protocol will be caching 
friendly, so we might even gain performance.

- Not found resources will have to go through every pipeline to 
determine that it's not found.  With fallback behavior due to 
polymorphism this gets worse.
I fail to see this, can you explain why you think this is the case?

- Will not explicitly declaring which resources are meant to be public 
cause trouble for block implementors and extenders?
?? well, in the sitemap I can be very precise on what I want to expose. 
and everything else is not exposed. the sitemap is like a virtual file 
system description, powerful enough to describe all possible systems.

If you have


 
  
 

than the contract moves at the file system level, but that's up to you 
to decide and a block extender can do


 
  
  
  
 

to provide extension that is procedural (but without exposing, for 
example layout.xml and layout2stylesheet.xslt which are just used 
internally)

With a single mechanism, it's much easier to do meani

Re: Track feature requests in bugzilla?

[Bertrand Delacretaz]

Le Jeudi, 9 oct 2003, à 14:33 Europe/Zurich, Stefano Mazzocchi a écrit :
...I'm sorry, but I hate bugzilla enough, we should try to reduce its 
use rather than increase it. it's usability is terrible, it's a punch 
in the face everytime you try to do something.

the wiki is much friendlier and feature requests are not something 
that requires lots of structure (rather the opposite)...
In my view, bugzilla (or any better tool if there is one) could/should 
be used for the following issues:
-bugs
-patches
-release coordination: have a script enter issues in bugzilla before 
doing the release, a "master issue" which is the release and depends on 
other issues representing the tests that must be performed
-feature requests

Which ones do you like today, and which ones would you like with a 
better tracking tool?

I don't terribly mind using the wiki for feature requests/wishlists, 
just trying to understand your point of view.

...also, i don't want to do conversations over bugzilla, it's painful 
and removes the ability to estimate people relationships (think agora)
Although I'm a fan of tracking tools, I agree that in our case 
dispersing conversations would not be optimal.

-Bertrand

Re: Use of a connection in an avalon component

[Sylvain Wallez]

Olivier Billard wrote:

Hi all !

I wonder how to use a DataSourceComponent and its connection in a 
custom cocoon avalon component, that is ThreadSafe, to use all 
performance and connection pool used in Cocoon.

Should I :
 - get a connection via datasource.getConnection() and close() it for 
each public method call,
 - get a connection in the initialize() method from the interface 
Initializable, close() it on the dispose() method from Disposable 
interface, and only create a Statement for each public method call ?
 - implement another avalon interface, like Runnable, to get/relase 
the Connection ?

I looked for exemples in the databases block, but the helpers are not 
Components. 


If your component is ThreadSafe, a single instance of it will exist in 
the whole system. JDBC connections being non thread safe, you *must* get 
and close them at each call. Don't be afraid to call close(): the 
connection you get is a wrapper managed by the DataSourceComponent which 
puts back the real request in the pool for later reuse when close() is 
called on the wrapper.

Sylvain

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

Re: [RT] Separation of Blocks and Avalon

[Stefano Mazzocchi]

On Wednesday, Oct 8, 2003, at 19:22 Europe/Rome, Ryan Hoegg wrote:

Hi,

I've been following the block design discussion and wiki evolution 
with great interest for a couple months now (blame Geoff).  Blocks 
look wonderful, and I can't wait to develop my cocoon based 
applications as blocks.

I have a concern about the bundling of exposed avalon services with 
blocks.  Specifically, in the recent thread about "Finishing the First 
Phase of Block Design" and on 
http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition I see some 
duplicated effort.  As Stephen McConnell noticed, some of this 
functionality is already built, tested, and maintained in several 
avalon containers.  Why not package avalon blocks/services/components 
in the way the container expects, and include them somewhere like 
/COB-INF/lib or /COB-INF/public/lib?  Or, even cleaner separation can 
be had in some cases by deploying them to the avalon container 
independently.

If things are done this way, the problem noted in the thread I 
mentioned above could be completely avoided.  There would be no need 
to expose classes through the block interface because all java would 
be exposed as avalon services.
I think this would simplify the block design greatly, and allow us to 
focus on cocoon-specific aspects.
Let me see if I get this right: you are proposing that we make cocoon 
blocks
somewhat extend avalon blocks and we have /block-inf/ for information 
on the java components and /cob-inf/ for all the remainding 
cocoon-specific things, in order to be able to reuse existing avalon 
code?

But how can I describe dependencies if one part uses implicit ones and 
the rest uses explicit ones?

--
Stefano.

DO NOT REPLY [Bug 15558] - IMAPGenerator Contribution

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15558

IMAPGenerator Contribution

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC|[EMAIL PROTECTED]   |
 AssignedTo|[EMAIL PROTECTED]|[EMAIL PROTECTED]
 Status|REOPENED|NEW

DO NOT REPLY [Bug 15558] - IMAPGenerator Contribution

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15558

IMAPGenerator Contribution

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |



--- Additional Comments From [EMAIL PROTECTED]  2003-10-09 12:56 ---
> mail block

Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)

[Joerg Heinicke]

Stefano Mazzocchi wrote:

However,
can't we use bugzilla also to track (serious) feature requests? There
are a couple of other "enhancement" requests in there, should we also
close them and add them to the wiki page?
We created 
http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatureRequests Monday 
in the frenzy of the Hackathon, but IMHO (and in retrospect) having 
them in Bugzilla makes more sense.

The Wiki page can then explain how we handle them and include a 
bugzilla link to the list of currently open feature requests.

We have to be clear on how we separate them from bugs though, I think 
feature requests should all have priority=Enhancment, is that ok? And 
what about [PATCH]es?
I'm sorry, but I hate bugzilla enough, we should try to reduce its use 
rather than increase it. it's usability is terrible, it's a punch in the 
face everytime you try to do something.
But as long as it is in use we should it use as much as possible. Dividing 
issues on many resource locations does not help.

the wiki is much friendlier and feature requests are not something that 
requires lots of structure (rather the opposite).
It's only the thing of having similar thing on different locations.

also, i don't want to do conversations over bugzilla, it's painful and 
removes the ability to estimate people relationships (think agora)
Hmm, stupid answer, but is it better to communicate over the wiki? I don't 
think so.

Does anybody know the status of the move to Scarab? Is it project dependent? 
Does Scarab improve the usability/issue category handling?

Joerg

--
System Development
VIRBUS AG
Fon  +49(0)341-979-7419
Fax  +49(0)341-979-7409
[EMAIL PROTECTED]
www.virbus.de

Re: Renaming Woody to "Cocoon Forms" ?

[Stefano Mazzocchi]

On Thursday, Oct 9, 2003, at 14:07 Europe/Rome, Geoff Howard wrote:

Bertrand Delacretaz wrote:
I think there was agreement on Monday about this, do we need a vote, 
or am I mistaken about the agreement?
Naming it "Cocoon Forms" is a nice parallel to "Cocoon Flow", and 
shows that we're betting the farm on it, which I like.
+1
+1

We can probably keep Woody as the block name though, in homage to the 
great sandwiches delivered to the great original authors of Cocoon 
Forms ;-)
No, I think that block name reduces visibility.
Agreed, +1 to change the block name as well.

In fact, I'm starting to feel that non-descriptive names for projects 
are a marketing liability unless the "brand" can really be equated 
with its meaning.
True. But when a brand indicates use (think "kleenex", "googling") 
that's where you have marketing connected to the use of the term. We 
might be achiving that status with cocoon "let's cocoon our web site", 
anyone? ;-)

--
Stefano.

Re: Renaming Woody to "Cocoon Forms" ?

[Michael Melhem]

On Thu, Oct 09, 2003 at 01:13:38PM +0200, Carsten Ziegeler wrote:
> Bertrand Delacretaz wrote:
> >
> > I think there was agreement on Monday about this, do we need a vote, or
> > am I mistaken about the agreement?
> I think we had consensus, however not all committers attended the hackathon,
> so it might be that someone is -1 on it and has a good reason.
> 
> >
> > Naming it "Cocoon Forms" is a nice parallel to "Cocoon Flow", and shows
> > that we're betting the farm on it, which I like.
> +1

Im not against naming it "Cocoon Forms" but we need to be
sure we want to lock Cocoon to a single Forms implementation.

Just to play "devils advocate", an alternative name could be 
"Woody Forms" or "WForms"
> 
> >
> > We can probably keep Woody as the block name though, in homage to the
> > great sandwiches delivered to the great original authors of Cocoon
> > Forms ;-)
> I had a "Woody" yesterday; well...it's not that bad.

Carsten, tooo much information mate, ;)

cheers,
Michael
> 
> But I think that it makes sense to rename the block as well. If someone
> is looking for form handling he will soon notice that the "form" block
> is about forms. But that's not visible if we keep the name "woody".
> 
> Carsten
> 
> 
> 

Re: [RT] Using modifiers within Cocoon components

[Stefano Mazzocchi]

On Thursday, Oct 9, 2003, at 14:00 Europe/Rome, Geoff Howard wrote:

Bertrand Delacretaz wrote:
Le Jeudi, 1 jan 1970, à 13:40 Europe/Zurich, Stefano Mazzocchi a 
écrit :
...We could use the same syntax for the so called interal pipelines


[...]
We could use two different component managers for each sitemap to 
manage
these components, this should make the lookup easier.


I like this as well. internal-only="true" sounds hacky.
+1, but someone mentioned using
  access="private"
instead, which is clearer.
"modifier" does not convey the exact meaning.
I like access="private" and access="public".

- Which is the default if none is specified? (public)
it would be back incompatible, but defaulting to private would be 
better from an evolutionary perspective.

Hmmm, on second thought,

uri access : @internal-only
block access : @access
are these two orthoganal concepts named deceptively in the case of 
pipelines?
I think so, yes.

 @access is not meant to imply whether a pipeline can be accessed but 
whether it can be extended or used outside the block.
yes

If
we never envision anything other than private/public would something 
like block-private="true" convey more meaning? block-access="private" 
might do the same but leave freedom for other than private/public.
random though, but you could think of "protected" as exposed to 
extending blocks but not outside that extending block (maybe to allow a 
different style of wrapping), while "private" is not exposed to 
extending blocks and public

so, leaving block-access="" (on both components and pipelines) is 
probably a better idea.

--
Stefano.

Re: [RT] FirstFriday - monthly virtual Hackathon

[Stefano Mazzocchi]

On Thursday, Oct 9, 2003, at 13:57 Europe/Rome, Michael Melhem wrote:

On Wed, Oct 08, 2003 at 10:50:00AM +0200, Bertrand Delacretaz wrote:
Could we have a monthly "virtual hackathon" on the first Friday of 
each
month?

Suggestions:

-Takes place on the first Friday of every month

-Use IRC for real-time coordination

-Use normal bugzilla coordination once someone actually starts working
on a bug
-Possibly use SubEthaEdit or similar whiteboarding tools [1] for pair
programming/reviews
-The goal is to close as many Bugzilla issues as possible, or bring
them to a useful state (asking for clarifications etc)
How does this sound?

Perhaps the IRC session should be logged (by a channel bot?)
and then the transcript mailed to the cocoon-dev mailing list
so that the discussion can be archived.

This would negate the "synchronous" nature of an IRC meet and
alleviate fears that some of the desgin discussions/decisions would
be effectively taken "off line" with the introduction of IRC.
Or maybe put in the wiki? (it could need a little rediting afterwards, 
like placing links to thinks and so on)

I like the idea though: solidified higher-bandwidth discussions, maybe 
with the dumps of a shared whiteboard.

I like the idea of us experimenting with new tools and ways to 
collaborate.

Will not replace email, for sure, asynchronicity and low-tech is too 
important for worldwide acceptance, but might help improving things 
during intensive design (brainstorming on a virtual whiteboard) or 
intensive polishing (pre-releasing, testing, bugfixing).

--
Stefano.

Re: Why is the link to the wiki so far away ?

[Stefano Mazzocchi]

On Thursday, Oct 9, 2003, at 13:16 Europe/Rome, Torsten Curdt wrote:

Litrik De Roy wrote:

Remember during the GT2003 when Steven asked the audience whether 
they check
the website or the wiki for docs?
I was surprised to see how hard it is to find out about the wiki when
visiting the Cocoon website:
There is no link on the navigation bar on http://cocoon.apache.org/ 
nor on
http://cocoon.apache.org/2.1/ . There is a link on
http://cocoon.apache.org/link/sites.html and some other pages but 
they are
too far away.
A link to the Wiki would fit under the category "Community" I guess.
that's a good one!

...but why not have it right on the front page if
people use it that much?
+1

--
Stefano.

Re: [RT] Virtual components and JXTemplate

[Sylvain Wallez]

Stephan Michels wrote:

On Tue, 7 Oct 2003, Sylvain Wallez wrote:

 

Stephan Michels wrote:

   

Just another thought,

I noticed that the JXTemplateGenerator/Transformer implements both
contracts: generator and transformer. It should be easier to
implements this component as transformer, and offer this transformer
also as virtual generator.


and







I should mention that I already rewrote the this components to be a
transformer only, but only for the xpath syntax. If thers is any
interest I could commit it.
 

AFAIU, the use of JXTemplate as a generator allows the template to be
pre-analyzed and stored into the cache, thus allowing a greater
performance. This cannot be achieved with the transformer.
There are use cases where templates are dynamically computed. In these
cases, you can either use the JXTemplate transformer or use the
generator with a cocoon: source. In that latter case, you also benefit
of the fact that the cocoon: source may be cached as well.
   

Yes, but the problem is that the output of the JXTemplate is high
dynamic, and isn't cachable, so I make most of transformations before
like i18n and some other.
That's why I was suggesting to use a "cocoon:" source as the input of 
JXTemplateGenerator: this allows the template to be cached. The other 
solution is to use CachingPointPipeline.

There is also some other thing, the newest jvm are optimized to dispatch
great numbers of small classes, like the classes, which be used to store
the events.
Sorry, what do you mean by "dispatch great number of small classes" ? Is 
it that about the handling of small short-lived objects ?

Sylvain

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

Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)

[Stefano Mazzocchi]

On Thursday, Oct 9, 2003, at 12:01 Europe/Rome, Bertrand Delacretaz 
wrote:

Le Jeudi, 9 oct 2003, à 11:42 Europe/Zurich, Bruno Dumon a écrit :
...I agree it's a feature request and added it to the wiki page. 
However,
can't we use bugzilla also to track (serious) feature requests? There
are a couple of other "enhancement" requests in there, should we also
close them and add them to the wiki page?
We created 
http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatureRequests Monday 
in the frenzy of the Hackathon, but IMHO (and in retrospect) having 
them in Bugzilla makes more sense.

The Wiki page can then explain how we handle them and include a 
bugzilla link to the list of currently open feature requests.

We have to be clear on how we separate them from bugs though, I think 
feature requests should all have priority=Enhancment, is that ok? And 
what about [PATCH]es?
I'm sorry, but I hate bugzilla enough, we should try to reduce its use 
rather than increase it. it's usability is terrible, it's a punch in 
the face everytime you try to do something.

the wiki is much friendlier and feature requests are not something that 
requires lots of structure (rather the opposite).

also, i don't want to do conversations over bugzilla, it's painful and 
removes the ability to estimate people relationships (think agora)

--
Stefano.

Re: [RT] Using modifiers within Cocoon components

[Sylvain Wallez]

Geoff Howard wrote:

Bertrand Delacretaz wrote:

Le Jeudi, 1 jan 1970, à 13:40 Europe/Zurich, Stefano Mazzocchi a écrit :

...We could use the same syntax for the so called interal pipelines


[...]
We could use two different component managers for each sitemap to 
manage
these components, this should make the lookup easier.


I like this as well. internal-only="true" sounds hacky.


+1, but someone mentioned using

  access="private"

instead, which is clearer.
"modifier" does not convey the exact meaning.


I like access="private" and access="public".

- Which is the default if none is specified? (public)

Hmmm, on second thought,

uri access : @internal-only
block access : @access
are these two orthoganal concepts named deceptively in the case of 
pipelines?  @access is not meant to imply whether a pipeline can be 
accessed but whether it can be extended or used outside the block.


I think your analysis is right: @internal-only is related to the origin 
of the request, while @access is about inter-block relations. It may 
make sense to have a pipeline with internal-only="true" and 
access="public", meaning it's not visible from the non-Cocoon world 
(i.e. only through "cocoon:" requests), but that other blocks can use it.

If we never envision anything other than private/public would 
something like block-private="true" convey more meaning? 
block-access="private" might do the same but leave freedom for other 
than private/public.


Blocks can be extended, and so having "protected" along with "public" 
and "private" may be needed. I don't see a need for "package" 
visibility, though.

Sylvain

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

Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)

[Stefano Mazzocchi]

On Thursday, Oct 9, 2003, at 11:42 Europe/Rome, Bruno Dumon wrote:

--- Additional Comments From [EMAIL PROTECTED]  2003-10-08 
17:28 ---
Ah, ok you're right. Although I guess that it's technical possible it 
will get
even more messy than the whole caching code is already.
In my opinion, it's sufficient to document this behaviour. Users can 
take care
of it - if they know.

On the other hand, I think this is more a feature request than a bug. 
So I
suggest to add this to our feature request page at the wiki and close 
this bug.
Or you can start a vote if this is more a bug or more a feature 
request first.
I agree it's a feature request and added it to the wiki page. However,
can't we use bugzilla also to track (serious) feature requests? There
are a couple of other "enhancement" requests in there, should we also
close them and add them to the wiki page?
+1

--
Stefano.

Re: GT2003: a few pictures

[Stefano Mazzocchi]

On Thursday, Oct 9, 2003, at 11:00 Europe/Rome, Luca Morandini wrote:

Marc Portier wrote:

congrats man,
thanks, I'll pass it along to my wife (she was the release manager, 
after all).
LOL ;-)

--
Stefano.

Re: [ANN] sunBow 2.0 available for download

[Stefano Mazzocchi]

On Thursday, Oct 9, 2003, at 10:58 Europe/Rome, Martin Dulisch wrote:

The new sunBow version is now available for download. It is
tested with eclipse 2.1.1. Eclipse 3.0 is not supported yet.
Following features has been added:
* Cocoon Debugger: Stepping through the sitemap. Trace the XML
stream and sitemap variables.
* Log-Level editor for logkit.xconf

* Log Viewer: A viewer for log files. Can be configured by
regular expressions.
* Extended the XML schema for the sitemap with the new flow
elements.
* Alternative tag closer in the XML editor

It can be downloaded here: http://radio.weblogs.com/0108489/

There is also a sunBow users mailing list. Subscription is
described on the website. Please use this list for questions.
Regards
Martin
Any chance of having the xml editing part open sourced?

--
Stefano.

Re: [RT] FirstFriday - monthly virtual Hackathon

[Marcus Crafter]

On Thu, 2003-10-09 at 14:01, Bertrand Delacretaz wrote:
> Le Jeudi, 9 oct 2003, à 13:57 Europe/Zurich, Michael Melhem a écrit :
> > ... Perhaps the IRC session should be logged (by a channel bot?)
> > and then the transcript mailed to the cocoon-dev mailing list
> > so that the discussion can be archived.
> > 
> > This would negate the "synchronous" nature of an IRC meet and
> > alleviate fears that some of the desgin discussions/decisions would
> > be effectively taken "off line" with the introduction of IRC
> 
> Sounds good, would you be able to do that?
> I have no idea how to run a "channel bot".
> 
> There *will* be discussions on IRC certainly, so this might be a good 
> experiment for the first FirstFriday (got got it?).

The werken.com people have their IRC channel logged to the web, eg:

http://irc.codehaus.org/channels/geronimo/2003-09-15.html

and its updated in realtime. Maybe something similar might be possible?
Probably depends on the admins on the irc server we choose.

Cheers,

Marcus