Re: (Re)Licensing question

[Geoff Howard]

On 1/10/06, David Crossley <[EMAIL PROTECTED]> wrote:
> This plain language FAQ is helpful:
> http://www.apache.org/foundation/licence-FAQ.html#WhatDoesItMEAN
> and follow through to the preFAQ which has a good overview,

Any idea why this is stated in the pre-FAQ?


9.  You have questions specifically about the Apache XML projects.

If you have sent us mail about one of the Apache XML software projects
(Xerces, FOP, Cocoon, et cetera), please use the following contact
instead:

http://xml.apache.org/mail.html>


I imagine they can remove Cocoon from that list?

Geoff

Re: rejuvenating the webdav block

[Geoff Howard]

On 1/4/06, Max Pfingsthorn <[EMAIL PROTECTED]> wrote:
>
> Geoff Howard [mailto:[EMAIL PROTECTED] wrote:
> > On 12/20/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote:
> > > > > On another note: I  need the eventcaching block  for webdav, but
> > > > > that  one only  needs jms  in one  class, and  databases in  the
> > > > > samples. So, I'll work on the  dependency issue there instead of
> > > > > in the webdav block directly.
> >
> > ...
> >
> > > The eventcache is needed for more advanced caching. The
> > components need to know about it to be able to construct the
> > right Validity objects for Source.getValidity(). We found out
> > that eventcaching is really key for good performance of the
> > website, so I would consider it a good kind of dependency. Of
> > course, the eventcaching block depending (indirectly) on the
> > database block is a bit silly.
> >
> > Yes, these dependencies were always somewhat painful - as we discussed
> > before [1].  It's only the samples that cause the dependency on the
> > database block IIRC.  There was some work being done on samples
> > dependencies I think - or were samples being separated into samples
> > blocks perhaps?  That would cure this.
> >
> > I see you've implemented some of this in webdav - did you manage to
> > avoid a dependency on the database block somehow?
>
> Yes, well, at least directly. The webdav block now depends only on repository 
> and eventcache, not on database. However, eventcache still depends on 
> database. I was thinking about the same thing, meaning to make a new block 
> for the eventcache samples. That has been done for other blocks and would 
> take care it, as you said.
> However, I don't know if its worth it in the 2.1 branch. Compiling a few more 
> classes doesn't hurt too much for now. It would make more sense and be worth 
> it for 2.2 as it is supposed to be released semi-soon, right?

Oh, I see.  Afraid I haven't been able to follow the 2.2 release
discussions, but I gather it is coming soon - definitely agree it'd be
worth it there.

Geoff

Re: rejuvenating the webdav block

[Geoff Howard]

On 12/20/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote:
> > > On another note: I  need the eventcaching block  for webdav, but
> > > that  one only  needs jms  in one  class, and  databases in  the
> > > samples. So, I'll work on the  dependency issue there instead of
> > > in the webdav block directly.

...

> The eventcache is needed for more advanced caching. The components need to 
> know about it to be able to construct the right Validity objects for 
> Source.getValidity(). We found out that eventcaching is really key for good 
> performance of the website, so I would consider it a good kind of dependency. 
> Of course, the eventcaching block depending (indirectly) on the database 
> block is a bit silly.

Yes, these dependencies were always somewhat painful - as we discussed
before [1].  It's only the samples that cause the dependency on the
database block IIRC.  There was some work being done on samples
dependencies I think - or were samples being separated into samples
blocks perhaps?  That would cure this.

I see you've implemented some of this in webdav - did you manage to
avoid a dependency on the database block somehow?

Geoff

[1] http://marc.theaimsgroup.com/?t=11325928653&r=1&w=2

Re: event aware object cache?

[Geoff Howard]

On 11/23/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote:
>
>
> Geoff Howard [mailto:[EMAIL PROTECTED] wrote:
> ...
> > > > Would it be sufficient to configure JMSEventMessageListener with a
> > > > list of EventAwares?  If the EAManager is necessary, I
> > guess it would
> > > > have to be configured with such a list unless you can
> > think of a way
> > > > for it to discover all EventAwares in the system?
> > >
> > > Well, I was thinking of registering event awares with that
> > manager so its more up to the components... Then again, if
> > you have multiple jms providers, you might want to listen to
> > a specific topic, or only forward events to a subset of EAs...
> > > Its hard to do this kind of thing with lookup IoC.
> > > Also, its a tradeoff between configuring the connections
> > between source and sink of the events (e.g. the path between
> > the jms listener and the cache) as roles to look up or as
> > some sort of routing configuration.
> > > We could do this by:
> > > 1. Letting event awares choose sources/topics to listen to
> > > 2. Configuring a name per event source
> > >
> > > Then, a listener can say, I want to listen to topic "foo",
> > no matter where from, or even listen to "bar" only from
> > source "baz" and "bas".
> > >
> > > WDYT?
> >
> > Yes, that sounds about right though I haven't fully thought
> > it through.
>
> Okay. What about routing tables? Like the one shown under "Internet Routing - 
> Internal Routing Tables" in [1], we could make a list of "routing rules":
>
> Source | Topic | Listener
> -
> foo| bar   | baz << means topic bar from source foo should be 
> delivered to listerner baz
> *  | barr  | baz << baz should also get any message with topic barr 
> from any source
> foo| * | foolist << foolist listens to any topic from source foo
> foo| bing  | *   << foo distributes any "bing" message to any listener
> foobar | * | *   << foobar distributes any message to any listener
> *  | bang  | *   << bang messages are always delivered to all 
> listeners from any source
> *  | * | bazz<< bazz listens to any message

Gotcha.  If you have a need for this now, great - seems like maybe
YAGNI would apply otherwise.

> Now, this table can be configured for the EventAwareManager in cocoon.xconf. 
> I would also add methods such that listeners can add/remove rules, or have 
> some way to do this during runtime in any case. Maybe with an interface using 
> cforms? :D
>
> Covers all cases, right?
> > > ...
> > > > > Another usecase in favor of having a general
> > > > EventAwareManager to keep track of EventAware instances would
> > > > be to have a way to notify a business object model when the
> > > > backend changes, or generally notify it via JMS. We'll be
> > > > running into that soon over here, so it would be nice to get
> > > > some ground work done.
> > > >
> > > > That is outside the original intention but should work.
> > There may be
> > > > some odd block dependencies if someone wants to do that
> > but not use an
> > > > EventAwareCache, they could wind up requiring both the
> > JMS block and
> > > > the EventAware block anyway.  If you can see a way to allow your
> > > > use-case but avoid that false dependency, that'd be great.
> > >
> > > I don't really see that problem as you still have to
> > configure which cache to use in your cocoon.xconf. Otherwise,
> > if you want to use jms/eventaware, of course you need both
> > blocks... I don't really understand the false dependency, can
> > you explain?
> >
> > I thought I had remembered that the EventAware interfaces and
> > implementations were all in the two blocks, but now that I think of
> > it, I guess EventAware itself is in core?  I just switched to a new
> > laptop recently and don't even have a local copy of the source on it
> > yet.
>
> EventAware, EventAwareCacheImpl, EventRegistry, JMSEventMessageListener, etc 
> are all in the eventcache block. JMSEventMessageListener extends 
> AbstractMessageListener from the jms block.

Ah, right (memory's not as bad as I thought).  So if you wanted a more
generic implementation of an EventAware component that wasn't a Cache
or Store, you'd still have to rely on the "

Re: event aware object cache?

[Geoff Howard]

On 11/23/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote:
>
> Geoff Howard [mailto:[EMAIL PROTECTED] wrote:
> > On 11/23/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote:
> > >
> > > Geoff Howard [mailto:[EMAIL PROTECTED] wrote:
> > > > On 11/21/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote:
> ...
> >
> > I missed the deprecation of the Stores discussion. Do you have some
> > pointers in the dev list archives?
>
> Oh, no, nevermind. The Store interfaces moved into excalibur(?), but the 
> stores in general aren't deprecated... My mistake.

Ah, good.  I didn't think I could miss something that big, but you never know.

> > Would it be sufficient to configure JMSEventMessageListener with a
> > list of EventAwares?  If the EAManager is necessary, I guess it would
> > have to be configured with such a list unless you can think of a way
> > for it to discover all EventAwares in the system?
>
> Well, I was thinking of registering event awares with that manager so its 
> more up to the components... Then again, if you have multiple jms providers, 
> you might want to listen to a specific topic, or only forward events to a 
> subset of EAs...
> Its hard to do this kind of thing with lookup IoC.
> Also, its a tradeoff between configuring the connections between source and 
> sink of the events (e.g. the path between the jms listener and the cache) as 
> roles to look up or as some sort of routing configuration.
> We could do this by:
> 1. Letting event awares choose sources/topics to listen to
> 2. Configuring a name per event source
>
> Then, a listener can say, I want to listen to topic "foo", no matter where 
> from, or even listen to "bar" only from source "baz" and "bas".
>
> WDYT?

Yes, that sounds about right though I haven't fully thought it through.

> ...
> > > Another usecase in favor of having a general
> > EventAwareManager to keep track of EventAware instances would
> > be to have a way to notify a business object model when the
> > backend changes, or generally notify it via JMS. We'll be
> > running into that soon over here, so it would be nice to get
> > some ground work done.
> >
> > That is outside the original intention but should work.  There may be
> > some odd block dependencies if someone wants to do that but not use an
> > EventAwareCache, they could wind up requiring both the JMS block and
> > the EventAware block anyway.  If you can see a way to allow your
> > use-case but avoid that false dependency, that'd be great.
>
> I don't really see that problem as you still have to configure which cache to 
> use in your cocoon.xconf. Otherwise, if you want to use jms/eventaware, of 
> course you need both blocks... I don't really understand the false 
> dependency, can you explain?

I thought I had remembered that the EventAware interfaces and
implementations were all in the two blocks, but now that I think of
it, I guess EventAware itself is in core?  I just switched to a new
laptop recently and don't even have a local copy of the source on it
yet.

Anyway, it's almost certainly not important to consider at the moment.

Geoff

Re: event aware object cache?

[Geoff Howard]

On 11/23/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote:
>
> Geoff Howard [mailto:[EMAIL PROTECTED] wrote:
> > On 11/21/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote:
> > > Hi Cocooners!
> > >
> > > I have a question: I couldn't find a nice EventAware object
> > cache in Cocoon, the eventcache block only implements the
> > o.a.c.caching.Cache which I need to pass a byte array.
> > Serializing/deserializing is not really an option for me.
> > > What I would like is a (not necessarily persistent)
> > EventAware cache for objects used for form my responses of a
> > generator. I could imagine that this sort of cache might be
> > useful for others as well. If so, and it is not implemented
> > yet, I would like to go ahead and do so.
> > >
> > > WDYT? Does anyone have any pointers for me?
> >
> > Hmm, it's been a while since I've looked at this and the code base WRT
> > the Cache/Store code has changed since in a way I didn't keep fully
> > abreast of.  The original intention of the EventAware code was to do
> > exactly what you wanted.  IIRC the Cache used to have a transient
> > front-end backed by a persistent backend transparently.  Since then
> > the terminology and code was changed I think to have Stores be
> > transient and Cache persistent.
>
> I see, so your suggestion would be to implement an EventAware MRUMemoryStore? 
> And maybe also make the EHDefaultStore  EventAware?
> I guess for that, an "EventAwareManager" would be required cause right now 
> the JMSEventMessageListener looks up the EventAware cache by itself instead 
> of getting a list of EventAwares and calling processEvent on them.
> One big problem though: Stores are deprecated... :(

I missed the deprecation of the Stores discussion. Do you have some
pointers in the dev list archives?

Would it be sufficient to configure JMSEventMessageListener with a
list of EventAwares?  If the EAManager is necessary, I guess it would
have to be configured with such a list unless you can think of a way
for it to discover all EventAwares in the system?

> > For your need, it may only be necessary to factor the relevant code
> > out of the Cache to a more generic place where both Store and Cache
> > can take advantage of it.
>
> Not sure if that is necessary. I can see that the functionality is rather the 
> same, but making a wrapper around the ehcache Cache or something like that 
> seems a little weird cause we would dictate which cache implementation to use.
> Maybe the EventAware interface is enough, but add a manager for them?
> I guess we could provide ready wrappers around different implementations, 
> WDYT?
>
> > I can't give it a lot of time at the moment, but do want to help make
> > sure this is generally useful.  Can you provide some more details of
> > the problem as it exists now to help me get up to speed quickly?
>
> My problem is that I need to generate xml ( obviously ;) ), but the xml tree 
> represents a directory tree on a webdav server. So, I don't need to walk over 
> all collections to generate my xml, just over the ones that changed. For 
> that, I'd like to keep two things in memory: A list of children per node and 
> a set of attributes per node. These might not be Serializable (right now I 
> just stuff the AttributesImpl object into a map)...
> So, what I want is a way to remove these two from the cache/store if a 
> corresponding event comes in so they are regenerated, but I don't have to 
> rebuild the complete structure.
>
> Another usecase in favor of having a general EventAwareManager to keep track 
> of EventAware instances would be to have a way to notify a business object 
> model when the backend changes, or generally notify it via JMS. We'll be 
> running into that soon over here, so it would be nice to get some ground work 
> done.

That is outside the original intention but should work.  There may be
some odd block dependencies if someone wants to do that but not use an
EventAwareCache, they could wind up requiring both the JMS block and
the EventAware block anyway.  If you can see a way to allow your
use-case but avoid that false dependency, that'd be great.

Geoff

Re: event aware object cache?

[Geoff Howard]

On 11/21/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote:
> Hi Cocooners!
>
> I have a question: I couldn't find a nice EventAware object cache in Cocoon, 
> the eventcache block only implements the o.a.c.caching.Cache which I need to 
> pass a byte array. Serializing/deserializing is not really an option for me.
> What I would like is a (not necessarily persistent) EventAware cache for 
> objects used for form my responses of a generator. I could imagine that this 
> sort of cache might be useful for others as well. If so, and it is not 
> implemented yet, I would like to go ahead and do so.
>
> WDYT? Does anyone have any pointers for me?

Hmm, it's been a while since I've looked at this and the code base WRT
the Cache/Store code has changed since in a way I didn't keep fully
abreast of.  The original intention of the EventAware code was to do
exactly what you wanted.  IIRC the Cache used to have a transient
front-end backed by a persistent backend transparently.  Since then
the terminology and code was changed I think to have Stores be
transient and Cache persistent.

For your need, it may only be necessary to factor the relevant code
out of the Cache to a more generic place where both Store and Cache
can take advantage of it.

I can't give it a lot of time at the moment, but do want to help make
sure this is generally useful.  Can you provide some more details of
the problem as it exists now to help me get up to speed quickly?

Thanks,
Geoff

Re: patch commit request

[Geoff Howard]

Yes, that's what I figured - I'll experiment a little.  

On 9/13/05, hepabolu <[EMAIL PROTECTED]> wrote:
> Geoff Howard wrote:
> > Confirmed - thanks.  Went and corrected a few typos just to get my
> > feet wet.  Simple and quick - just what we have needed.  Thanks to all
> > who worked to get this set up!
> >
> > Anyone have ideas on how to edit disconnected? (e.g., on the plane)
> 
> I don't think that is currently possible. OTOH it's just plain HTML.
> What you could do is study the tags used (just switch to textareas view
> with the button on the top right above the edit box) and write your text
> using these tags in a simple text editor and copy and paste them in later.
> 
> HTH.
> 
> Bye, Helma
>

Re: patch commit request

[Geoff Howard]

Confirmed - thanks.  Went and corrected a few typos just to get my
feet wet.  Simple and quick - just what we have needed.  Thanks to all
who worked to get this set up!

Anyone have ideas on how to edit disconnected? (e.g., on the plane)

Geoff  

On 9/9/05, Upayavira <[EMAIL PROTECTED]> wrote:
> Geoff Howard wrote:
> > ooops
> >
> > so can you boost my rights too?
> 
> done.
> 
> Upayavira
>

Re: patch commit request

[Geoff Howard]

ooops 

so can you boost my rights too?

On 9/9/05, Geoff Howard <[EMAIL PROTECTED]> wrote:
> FYI, I think I've created a daisy account and might start taking a
> whack at documentation.
> 
> On 9/9/05, Upayavira <[EMAIL PROTECTED]> wrote:
> > Jorg Heymans wrote:
> > > Upayavira wrote:
> > >
> > >>Let us know when you've created your account.
> > >>
> > >
> > >
> > > created.
> >
> > You now have doc-editor and doc-committer rights.
> >
> > Regards, Upayavira
> >
>

Re: patch commit request

[Geoff Howard]

FYI, I think I've created a daisy account and might start taking a
whack at documentation.

On 9/9/05, Upayavira <[EMAIL PROTECTED]> wrote:
> Jorg Heymans wrote:
> > Upayavira wrote:
> >
> >>Let us know when you've created your account.
> >>
> >
> >
> > created.
> 
> You now have doc-editor and doc-committer rights.
> 
> Regards, Upayavira
>

Re: Handling oversized uploads with the application

[Geoff Howard]

I'll de-lurk for a minute to say - sounds good to me.  Better than
what we have now.

If you're looking to consider alternatives as well, IIRC there was
some discussion of implementing a delayed wrapper around the multipart
parsing to allow finer-grained control of when, how, and if the parts
were actually parsed.

The problem with the pre-parsing of the upload as it is now is that it
is all or nothing - you have to turn on multipart uploads for every
uri in cocoon's space (which is infinite).  Since I can't really
produce code on this now personally, I'll just toss it out as a
helpful reminder of past discussions.

Geoff

On 8/18/05, Sylvain Wallez <[EMAIL PROTECTED]> wrote:
> Hi all,
> 
> Uploads in Cocoon are handled at the servlet level, including a check of
> the maximum upload size which raises an exception. This exception is a
> major pain because it gives no chance to the application to warn the
> user that she exceeded the allowed limit. All we get is an ugly servlet
> engine-generated error page.
> 
> Rather than throwing an exception, the multipart parser could store in
> the request a special implementation of the Part interface,
> "InvalidPart" that allows the application to know about it and react
> accordingly. For example, the CForms upload widget could show a
> validation error in such occasions.
> 
> All methods of the Part interface (getInputStream, getName, etc) would
> of course throw an exception in InvalidPart, but that exception would
> have a chance to be handled cleanly by a 
> 
> WDYT?
> 
> Sylvain
> 
> --
> Sylvain WallezAnyware Technologies
> http://people.apache.org/~sylvain http://www.anyware-tech.com
> Apache Software Foundation Member Research & Technology Director
> 
>

Re: [vote] Give Max Pfingsthorn temporary and restricted commit privileges to our code repository

[Geoff Howard]

+1
Geoff

On 7/10/05, Reinhard Poetz <[EMAIL PROTECTED]> wrote:
> 
> As you all know, Max Pfingsthorn is one of our Google Summer of Code students
> and he will work on the implementation of the cforms library.
> 
> In order to make his life and the life of his two mentors (Sylvain and I)
> easier, I want to give him *temporary* and *restricted*
> (http://svn.apache.org/repos/asf/cocoon/whiteboard/forms/**) commit privileges
> to our SVN code repository.
> 
> After the project Max' account will be closed and he has to go the usual way 
> of
> becoming a regular Apache Cocoon committer.
> (http://www.apache.org/foundation/how-it-works.html#roles).
> 
> Please cast your votes!

[FYI] Good press for Daisy

[Geoff Howard]

http://www.infoworld.com/testcenter/
http://www.infoworld.com/article/05/07/11/28TCxmlcm_1.html

Geoff

Re: iCal

[Geoff Howard]

You'll find some discussions in the dev archives I believe.  Probably
better to search more generally on "calendar", but iCal comes up
specifically.

Geoff

On 6/20/05, Torsten Curdt <[EMAIL PROTECTED]> wrote:
> > Has anyone thought about integrating iCal with Cocoon?
> 
> ...feel free to do it :)
> 
> cheers
> --
> Torsten
> 
> 
>

Re: [VOTE] Document Editors, and a new Committer

[Geoff Howard]

On 6/9/05, Upayavira <[EMAIL PROTECTED]> wrote:
> As granting committership requires a vote, please cast your votes now:
> 
> [ ] Helma Van Der Linden as a Cocoon committer

+1 - Welcome!

Very excited about the zone and the new live docs env...

Geoff

Re: [VOTE] Removing author tags

[Geoff Howard]

On 5/2/05, Sylvain Wallez <[EMAIL PROTECTED]> wrote:
> So I propose to remove @author tags with people names from all our
> source files.

+1

> Additionally, if you agree with removing names, do you want source files
> to have:
>  [X] no @author tag at all,

> Additionally, non-committers that have contributed significant portions
> of code and think they will lose visibility with this removal can make
> their voice heard. We will consider updating either the release notes or
> the credits file.

I'd rather add them automatically as Stefano suggests, though I expect
this will be commonly forgotten.

Geoff

Re: DO NOT REPLY [Bug 34283] - Tutorial: Write a Custom Generator

[Geoff Howard]

Upayavira,

As I've only been able to marginally follow the new 2.2 docs strategy
(especially because there have been several I think over time!) :)  I
wasn't sure what to do with this doc in 2.2.  I also am not clear how
much of it will be accurate in 2.2.

I'll try to take a look at some point and come up with a logical place
for it.  I have the link to the new docs on brutus, but poking around,
things seem pretty rough still.  Where is the current authoritative
menu structure?

Geoff

On 5/2/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> .
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
> INSERTED IN THE BUG DATABASE.
> 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=34283
> 
> --- Additional Comments From [EMAIL PROTECTED]  2005-05-02 08:11 ---
> Geoff -
> 
> Please consider committing it to 2.2 too. The doc structure there is very
> different, and at an early stage. Either commit it as a c21-custom-generator
> page (as this is an as-yet-unconverted page), or if you wish, find the place 
> in
> the menu structure for your page.
> 
> Thanks, Upayavira
> 
> --
> Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are the assignee for the bug, or are watching the assignee.
>

Re: Directory structure of blocks

[Geoff Howard]

On Apr 12, 2005 2:33 AM, Reinhard Poetz <[EMAIL PROTECTED]> wrote:
> Antonio Gallardo wrote:
> 
> > Is posible to change the name from:
> > block.xml -> cob.xml
> 
> ATM everything is possible ;-)
> 
> >
> > I see the analogy to WEB-INF/ --> web.xml.
> > IMHO this is to keep the same name and avoid confusions. ;-)
> > WDYT?
> 
> fine for me too, so we have
> 
> --
> [cocoon block] [DIR]
>+-- COB-INF [DIR]
>+-- cob.xml
>+-- classes [DIR]
>+-- lib [DIR]
> --
> 
> WDOT?

I don't think the inconsistency (COB-INF -> block.xml) is a big deal. 
There is also a META-INF and it does not have a meta.xml in it.

In fact, it would have the added benefit of helping people guess what
the heck a "COB" is if they are just browsing around the FS.  I think
this argument was made before.

Geoff

Re: Directory structure of blocks

[Geoff Howard]

On Apr 11, 2005 4:57 PM, Vadim Gritsenko <[EMAIL PROTECTED]> wrote:
> Reinhard Poetz wrote:
> >
> > I don't know why we named it "COB-INF" but there was (still is?) a good
> > reason for this because I remember some long discussion.
> 
> IIRC, reason was to avoid conflict with avalon/phoenix/somesuch
> BLOCK-INF/block.xml, hence COB (Cocoon Block).

Yes.  See [1] and [2] (first post got "orphaned" from the rest of the
thread in the archive)

Also, I assume you've seen [3]?

- Geoff

1 http://marc.theaimsgroup.com/?t=10651064313&r=1&w=2
2 http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106510548208709&w=2
3 http://wiki.apache.org/cocoon/BlocksFSLayout

Re: [VOTE] Alfred Nathaniel as committer

[Geoff Howard]

On Apr 9, 2005 6:10 AM, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote:
> Dear community,
...
> Please cast your votes:
> here's my +1

And mine! +1

Geoff

Re: [poll] Seeking eclipse plugin development skills for an opensource Cocoon IDE

[Geoff Howard]

I'm interested and have some eclipse plugin experience (not expert,
but not newbie).  Unfortunately, as you can tell I've been unable to
help much recently.  If you start it I'll certainly at least lurk on
the list and as possible, really jump in.

Geoff


On Thu, 31 Mar 2005 16:04:11 +0300 (EEST), [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> 
> hi Sylvain
> 
> i dont know the level of eclipse skills are you looking for
> but last months i'm working on an Eclipse RCP application
> 
> https://schoolclipse.dev.java.net/
> 
> and i will be happy to contribute something to cocoon's community
> 
> -- stavros
> 
> On Wed, 30 Mar 2005, Sylvain Wallez wrote:
> 
> > Hi folks,
> >
> > Cocoon is now a mature framework and is more and more used in corporate
> > environments. And more and more people are asking for some tools.
> > Several people also experienced lost projects because Cocoon doesn't
> > have a minimal opensource tooling.
> >
> > Building an opensource IDE for Cocoon not only requires some Cocoon
> > knowledge, but also some Eclipse plugin development skills.
> >
> > That's why I'm sending this poll to the whole user and developper community:
> > - do you or your company have Eclipse plugin development skills?
> > - if some opensource project is setup to develop a Cocoon IDE, would you
> > like to join and invest time and effort?
> >
> > Thanks for your answers,
> > Sylvain
> >
> >
> 
>

Agila

[Geoff Howard]

Anyone looked at or working on a Cocoon front-end to Agila?
(http://incubator.apache.org/projects/agila.html)

I've seen a few of you in the incubator archives for it.

Geoff

Re: [announcement/proposal] Moving Linotype out of Cocoon

[Geoff Howard]

Sounds fine.  (not +1 because this isn't a vote and one isn't needed).

I look forward to test-driving the new improved version, and the
potential for further symbiosis with MIT & W3C

Geoff

On Sat, 29 Jan 2005 23:37:57 -0500, Stefano Mazzocchi
<[EMAIL PROTECTED]> wrote:
> For this reason, I propose that we discontinue the distribution of
> Linotype inside cocoon as a block, by deprecating it in the next 2.1.x
> release and by removing it alltogether in 2.2

Re: DO NOT REPLY [Bug 32212] - [PATCH] Enable development of blocks outside of cocoon source tree

[Geoff Howard]

On Fri, 28 Jan 2005 19:27:32 +0100, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=32212
> --- Additional Comments From [EMAIL PROTECTED]  2005-01-28 19:27 ---
> I have added this feature in a different way - didn't know about this patch :|
> (Sorry!). So I will close the bug - if you think that the current version is
> missing something please let us know.

I told you so!  :) 

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

[FYI] Orbeon google keyword for cocoon

[Geoff Howard]

FYI, in the "competition is the sincerest form of flattery" dept: 

People who are subscribed to the list through gmail may have noticed
that the following ad from orbeon is showing up in the "Sponsored
Links" area.  Presumably they have bought a google ad word for
"cocoon"?

www.orbeon.com - Considering Apache Cocoon? Check out the OXF XML Platform

Geoff

Re: [proposal] Cocoon documentation system

[Geoff Howard]

On Sat, 15 Jan 2005 09:42:17 +0100, Reinhard Poetz <[EMAIL PROTECTED]> wrote:
...
> >>My first goal is
> >>reusing existing functionality (SVN, Forrest, static web pages). Writing
> >>the missing pieces (a small web application to edit docs online) shouldn't
> >>be too difficult - especially using CocoonForms (HTMLArea with HTMLCleaning
> >>convertor are shining here!) and Flowscript.
> >>
> >>At the end of the document you find a roadmap. It also contains some parts
> >>where I *really* need some help by others:
> >>
> >> - component (Java) that reads from and commits to SVN - should work over
> >>   WebDAV, shouldn't it?
> >>   I know there are some specialist in this community who could help out
> >>   here (Unico, Gianugo, Guido)
> >
> > We have a huge team of specialists on the dev list.
> 
> Yep. I hope that I can convince at least one of them to help me. Actually I 
> need
> some Java code ;-) So here I ask officially: Who volunteers to write the Java
> code that communicates with the SVN repository (read and commit)?
 
You may find this more problematic than you'd expect.  I follow the
subclipse list a little and have the impression that pure-java library
development against SVN lags behind because it's difficult to keep up
with the evolving standard.  I should have thought that the rate of
evolution has significantly slowed, but that is not the impression I
get.  Subclipse for instance uses jni for the low level svn operations
so it can go against the original native libraries.

On the other hand, there are some attempts to provide pure java svn
libraries (one is called javaSVN I think?) so if these are usable in
practice, the work could be trivial.

Geoff

Re: [RT] Update to build system: location of blocks and gump

[Geoff Howard]

I could swear someone did this about a month ago?

Geoff


On Thu, 13 Jan 2005 13:22:24 +0100, Carsten Ziegeler
<[EMAIL PROTECTED]> wrote:
> I'm currently thinking about making the build system able to include
> blocks from "external" locations, which means blocks that are not
> directly in the cocoon directory.
> I'm thinking of a simple but working solution: I guess the easiest way
> would be to just add the root directory for a block to our gump
> descriptor. Currently the build system assumes that a block is located
> at src/blocks/BLOCKNAME.
> When the build system uses this information from gump.xml, we can simply
> include a "local.gump.xml" containing some more projects into the
> gump.xml and build an aggregated description that is only used by the
> build process. Gump itself is not affected as it still uses the gump.xml.
> 
> So my questions are:
> - Is there a possibility in gump to define the root directory for a block?
> - Does this change have any impact on other parts that I oversee?
> 
> Carsten
>

Re: [VOTE] Creation of a french-speaking users list

[Geoff Howard]

+1 on the French list.  

FWIW, I think the argument below fails to take into consideration the
increase in signal to noise ratio mentioned in Sylvain's original
rationale.  If there are suddenly 5 languages mixed on the lists, most
people are going to find between 50-80% (assuming the average person
worldwide is comfortable in 1-3 languages) meaningless or at least not
worth the trouble.  That combined with the high volume will tend to
make people tune out IMO.

Geoff


On Wed, 12 Jan 2005 18:43:11 +0100, Nathaniel Alfred
<[EMAIL PROTECTED]> wrote:
> >-Original Message-
> >From: Ralph Goers [mailto:[EMAIL PROTECTED]
> >Sent: Mittwoch, 12. Januar 2005 17:30
> >To: dev@cocoon.apache.org
> >Subject: Re: [VOTE] Creation of a french-speaking users list
> 
> >As far as the list goes, I'm generally OK with it but it makes me
> wonder
> >what happens when someone wants a list in German, Italian, Spanish,
> >Klingon, or whatever.  It would be a lot nicer if there was one list
> and
> >when you subscribed and specified you spoke French it translated it for
> >you (and back on replies as well).  Sigh - well, I can dream.
> 
> >Ralph
> 
> I had a similar reaction.  There are more people out there who can
> follow
> written English but don't dare to write questions in English.  I also
> remember occasions where people were told off for posting non-English
> on Cocoon mailing lists.
> 
> I'd rather propose to make it public policy on the user list that one
> may
> post a question in any language.  If the language is not English, the
> poster
> accepts that either
> 
>  a) the answer may be in the same language, or
>  b) the answer may be in English, or
>  c) there may be no answer
> 
> Cheers, Alfred (reading English/French/German/Spanish but answering only
> in English)
>

Re: trunk build broken (Was: how to list all sitemap components)

[Geoff Howard]

On Wed, 12 Jan 2005 16:57:31 +1100, David Crossley <[EMAIL PROTECTED]> wrote:
> Antonio Gallardo wrote:
> > Can you post where the problem is showed to you trying a full build? I am
> > trying to get an idea if the problem is truly random or just because users
> > have diferent blocks configurations in local.blocks.properties. The
> > lastest seems to be the case, but lets to be sure.
> 
> I showed that a few messages ago in this thread.
> Both Ross and i are doing a full build, javadocs and all,
> with no blocks disabled. It breaks in different places
> for each of us.

It looks like you've moved on past the need to understand this, but I think 
you're mistaken here, no?  Ross is doing a default unmodified build, which 
has some blocks excluded by default.  You're reporting all blocks enabled 
which would require some editing of the properties.  I'd guess that Antonio has 
a separate set of blocks chosen, so this still may explain the
different fail points,
though it seems this is now just a curiosity in the larger problem.

Unfortunately, time to crawl back into my hole.

Thanks,
Geoff

Re: trunk build broken (Was: how to list all sitemap components)

[Geoff Howard]

odd that this is breaking in different places for everyone.  Do you
all have different sets of blocks enabled?

If not, I'm suspicious of out of memory error or something odd like
that.  In that case, any chance that the docs build tasks could mask
some odd condition like that with such an error?

Geoff


On Tue, 11 Jan 2005 14:01:08 +, Ross Gardler <[EMAIL PROTECTED]> wrote:
> Jeremy Quinn wrote:
> > I am getting the same problem, but with :
> >
> > BUILD FAILED
> > /Users/jerm/Development/Checkouts/Apache/Cocoon/trunk/tools/targets/
> > docs-build.xml:55: Sitemap component
> > org.apache.cocoon.generation.NekoHTMLGenerator does not implement a
> > sitemap component interface.
> 
> I may be at risk of repeating things already known, but...
> 
> I just did a new svn checkout and got a similar error:
> 
> Building component docs from blocks.
> Collecting sitemap components info
> 
> BUILD FAILED
> D:\openSource\cocoon\tools\targets\docs-build.xml:55: Sitemap component
> org.apache.cocoon.template.jxtg.JXTemplateGenerator does not implement a
> sitemap component interface.
> 
> Ross
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.6.10 - Release Date: 10/01/2005
> 
>

Re: [Vote] Component confs per sitemap [was: [RT]]

[Geoff Howard]

On Mon, 20 Dec 2004 11:54:01 +0100, Carsten Ziegeler
<[EMAIL PROTECTED]> wrote:
> > > 
> > >   ..
> > > 

+1

[HEADSUP] Steven Noels Article

[Geoff Howard]

Maybe I missed it on the list before but google alerted me to the
following which is part two of an interview with Steven:

http://www.builderau.com.au/program/0,39024614,39170563,00.htm

Haven't read it yet, so I hope it's nothing embarassing! :)

Geoff

Re: Templating: experiments with Conal's html-to-xslt transform

[Geoff Howard]

On Fri, 10 Dec 2004 15:04:20 +0100, Bertrand Delacretaz
<[EMAIL PROTECTED]> wrote:
> Le 10 déc. 04, à 14:44, Upayavira a écrit :
> > ...I like this kind of approach, and am implementing a similar system
> > at the moment...
> 
> Great! Let's make this a documented/mainstream part of Cocoon, it's
> cheap to do and could make a big difference in the perception of
> Cocoon.
> 
> I say "perception" because all this is already possible, we're just not
> showing it well enough I think.
> 
> > ...If we are fixated upon Dreamweaver, then we should work out how
> > Dreamweaver extensions work, so that we can, with a bit of HTML and
> > some Javascript, allow GUI access to the various elements we add into
> > the page. This is, in effect, all that is done to give access to ASP,
> > PHP, JSP, etc, in Dreamweaver, so I don't see why we couldn't do the 
> > same for some Cocoon markup (other than lack of interest!)..
> 
> Right.  Links to DW information are welcome, I've searched a bit but

http://www.macromedia.com/support/documentation/en/dreamweaver/ 

Notable links from that page:
- Extending Dreamweaver MX 2004 
- Dreamweaver API Reference

No time to help but very enthusiastic about the idea,
Geoff

Re: how to list all sitemap components

[Geoff Howard]

I'd just use eclipse to find every class that implements the right
interface(s).  Would that work?

Geoff

On Thu, 09 Dec 2004 10:46:36 +1100, David Crossley <[EMAIL PROTECTED]> wrote:
> I am trying to create a list of all sitemap
> components in the Cocoon core and blocks.
> 
> So far i have tried to use 'find and grep'
> by looking for well-known filenames,
> e.g. *Transformer.java and also searching in
> well-known directories, e.g. /transformation/
> However, that misses some components and gets
> too much extra stuff.
> 
> Using the "package" name inside the *.java
> also misses some components.
> 
> Is there a way to uniquely identify the
> sitemap components by grepping the *.java
> e.g. perhaps a unique method name?
> 
> --David
> 
>

Re: Patch 0

[Geoff Howard]

I'll be out with the family today, but if no one does by tonight (GMT
-5), I'll take a look.  Thanks for your work.

Geoff

On Fri, 26 Nov 2004 21:25:54 -0700, Micah Dubinko
<[EMAIL PROTECTED]> wrote:
> I just stuck a patch into Cocoon bugzilla,
> 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=30043
> 
> It was a pretty satisfying fix, too, as it involved specific
> cross-browser techniques to play nice with IE. And for the full learning
> experience, I even flubbed the first patch and had to do a second. :)
> 
> Anyone up for committing this?
> 
> .micah
>

Re: I got my account !!!!!!

[Geoff Howard]

On Thu, 25 Nov 2004 21:51:46 -0500, Vadim Gritsenko
<[EMAIL PROTECTED]> wrote:
> Geoff Howard wrote:
> > bash-2.05b$ groups tschlabach
> > tschlabach apcvs lenya
> >
> > This should mean you have commit access to lenya.  Only one way to be 
> > sure... :)
> 
> No, it does not :) Lenya is in SVN
>   http://svn.apache.org/repos/asf/lenya/
> 
> Which does not use unix groups but svn-authorization file (which I probably 
> have
> no access to). I see that tschlabach is already there. So last step for 
> Torsten
> is to login to minotaur.apache.org and use svnpasswd command to create SVN
> password, and then checkout lenya from svn using https: url.

DOH!

Re: I got my account !!!!!!

[Geoff Howard]

bash-2.05b$ groups tschlabach
tschlabach apcvs lenya

This should mean you have commit access to lenya.  Only one way to be sure... :)

Congrats,
Geoff Howard


On Thu, 25 Nov 2004 14:39:04 -0600 (CST), Antonio Gallardo
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] dijo:
> > Hi all,
> >
> > I received my account information and it works! Thank you to everyone who
> > helped to make this happen!
> 
> Congratulations!
> 
> Best Regards,
> 
> Antonio Gallardo.
>

Re: svn commit: rev 76124 - cocoon/trunk

[Geoff Howard]

On Wed, 17 Nov 2004 16:25:46 +0100, Unico Hommes <[EMAIL PROTECTED]> wrote:
> Geoff Howard wrote:
...
> >I guess my question about optional dependencies gave the wrong
> >impression of the utility of jms in event cache.  I don't think it's a
> >problem having a dependency on the jms api in this block because:
...
> >- This is not a new dependency - it's been there I think from the
> >first commit, though maybe shortly after and was always the intention
> 
> Actually, not quite true [1]. The JMS listener for eventcache used to be
> located in the jms block. I moved that functionality to the eventcache
> block as part of refactoring work I did on the jms block. The dependency
> from eventcache to jms seemed more logical to me than the other way
> around. Unfortunately, it turned out that the jms samples also rely on
> the eventcache block, so that a virtual cyclic dependency broke the
> build at that point. The temporary resolution I did was to comment the
> samples- dependency from jms to eventcache in gump.xml.

ok, ok :) 

What I meant to communicate was that someone didn't just recently add some 
new functionality here and slip in a big "dependency" in the loosest
sense (not gump or
even ant sense).

> >Niclas' advice is the only way to fix gump.  Why this is the first
> >it's come up is a mystery to me, but IMV the dependency should have
> >been there all along.

So, Unico do you agree that this dependency (all meanings) is OK here or do we 
need to try a conditional dependency as Stefano mentions in another
thread (thanks
by the way S.)?

Geoff

[OT] ICAP protocol

[Geoff Howard]

Long shot (based on my google results), but anyone know of a
java-based tool/ highlevel api for working with icap connections such
as that commonly used by anti virus apps?

Geoff

Re: svn commit: rev 76124 - cocoon/trunk

[Geoff Howard]

Please change what?  Remove what is viewed to be a key use-case of a
block to avoid a dependency?  Move one class into its own block?
(there are very few classes in the event cache block anyway).

The jms event cache item could also be moved into the "jms" block, but
that then introduces a deep dependency of the jms block to event
cache, which also is not required and people would complain there.

I guess my question about optional dependencies gave the wrong
impression of the utility of jms in event cache.  I don't think it's a
problem having a dependency on the jms api in this block because:
- It's not introducing a new jar into our cvs
- It exists for the primary envisioned use of the block (though there
are other possible uses as I noted)
- It's an API dependency, not an implementation dependency - you don't
have to have a full JMS server unless you want to use the JMS
functionality.
- This is not a new dependency - it's been there I think from the
first commit, though maybe shortly after and was always the intention

Niclas' advice is the only way to fix gump.  Why this is the first
it's come up is a mystery to me, but IMV the dependency should have
been there all along.

Geoff

On Wed, 17 Nov 2004 07:55:47 -0600 (CST), Antonio Gallardo
<[EMAIL PROTECTED]> wrote:
> Hi Geoff.
> 
> Please change it. I just follow the Niclas' advise. ;-)
> 
> Are there some mock classes to address that?
> 
> Best Regards,
> 
> Antonio Gallardo
> 
> Geoff Howard dijo:
> 
> 
> > And whole of cocoon was not at stake, just the eventcache block.
> > There is one (?)class in eventcache which provides support for JMS
> > messages invalidating cache (which in my original vision was the
> > primary use) and thus this dependency on the JMS api.  Do we in gump,
> > or in blocks build have "conditional"/optional dependencies?  IOW,
> > this block can actually function usefully without JMS except I believe
> > this one impl class.
> >
> > Geoff
> >
> >
> > On Wed, 17 Nov 2004 07:21:00 -0600 (CST), Antonio Gallardo
> > <[EMAIL PROTECTED]> wrote:
> >> Upayavira dijo:
> >>
> >>
> >> > [EMAIL PROTECTED] wrote:
> >> >
> >> >>Author: antonio
> >> >>Date: Wed Nov 17 05:11:21 2004
> >> >>New Revision: 76124
> >> >>
> >> >>Modified:
> >> >>   cocoon/trunk/gump.xml
> >> >>Log:
> >> >>Fix eventcache. Thanks to Niclas Hedhman.
> >> >>
> >> >>Modified: cocoon/trunk/gump.xml
> >> >>==
> >> >>--- cocoon/trunk/gump.xml (original)
> >> >>+++ cocoon/trunk/gump.xml Wed Nov 17 05:11:21 2004
> >> >>@@ -905,6 +905,7 @@
> >> >>
> >> >> 
> >> >> 
> >> >>+
> >> >> 
> >> >>
> >> >> 
> >> >>
> >> >>
> >> > Is this right? Surely it is the cocoon-block-jms 'project' that is
> >> > dependent upon JMS, not the whole of Cocoon?
> >>
> >> The cocoon-block-jms project already had this dependency too.
> >>
> >> Best Regards,
> >>
> >> Antonio Gallardo
> >>
> >>
> >
> 
>

Re: svn commit: rev 76124 - cocoon/trunk

[Geoff Howard]

And whole of cocoon was not at stake, just the eventcache block. 
There is one (?)class in eventcache which provides support for JMS
messages invalidating cache (which in my original vision was the
primary use) and thus this dependency on the JMS api.  Do we in gump,
or in blocks build have "conditional"/optional dependencies?  IOW,
this block can actually function usefully without JMS except I believe
this one impl class.

Geoff


On Wed, 17 Nov 2004 07:21:00 -0600 (CST), Antonio Gallardo
<[EMAIL PROTECTED]> wrote:
> Upayavira dijo:
> 
> 
> > [EMAIL PROTECTED] wrote:
> >
> >>Author: antonio
> >>Date: Wed Nov 17 05:11:21 2004
> >>New Revision: 76124
> >>
> >>Modified:
> >>   cocoon/trunk/gump.xml
> >>Log:
> >>Fix eventcache. Thanks to Niclas Hedhman.
> >>
> >>Modified: cocoon/trunk/gump.xml
> >>==
> >>--- cocoon/trunk/gump.xml (original)
> >>+++ cocoon/trunk/gump.xml Wed Nov 17 05:11:21 2004
> >>@@ -905,6 +905,7 @@
> >>
> >> 
> >> 
> >>+
> >> 
> >>
> >> 
> >>
> >>
> > Is this right? Surely it is the cocoon-block-jms 'project' that is
> > dependent upon JMS, not the whole of Cocoon?
> 
> The cocoon-block-jms project already had this dependency too.
> 
> Best Regards,
> 
> Antonio Gallardo
> 
>

Re: The Gump build

[Geoff Howard]

thanks, Antonio.  I think I was trying to commit at the exact time you were.

Geoff


On Wed, 17 Nov 2004 07:17:56 -0600 (CST), Antonio Gallardo
<[EMAIL PROTECTED]> wrote:
> Hi Niclas:
> 
> Done.
> 
> Best Regards,
> 
> Antonio Gallardo
> 
> Niclas Hedhman dijo:
> 
> 
> >
> > Gang,
> > If you look at
> > http://brutus.apache.org/gump/public/cocoon/cocoon-block-eventcache/gump_work/build_cocoon_cocoon-block-eventcache.html
> >
> > you can see that the project needs JMS as a dependency.
> >
> > Can someone with commit access commit the attached patch, which adds
> >
> > 
> >
> > to the project in question.
> >
> > Thanks
> > Niclas
> > --
> >+--//---+
> >   / http://www.bali.ac/
> >  / http://niclas.hedhman.org /
> > +--//---+
> >
> 
>

Re: DO NOT REPLY [Bug 31067] - [PATCH] MultipartParser can now handle multipart/mixed

[Geoff Howard]

Bugzilla is broken the last few times I've cheked, but if anyone is
tracking this issue on the dev list, I've found a problem with this
patch.  It causes a parse exception when both a text input and a file
are sent in the same request.  I don't have time to track it down
right now - I can send my version of the patch if someone else wants
to work on it.

Geoff


On 13 Nov 2004 16:04:53 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> .
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> INSERTED IN THE BUG DATABASE.
> 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=31067
> 
> [PATCH] MultipartParser can now handle multipart/mixed
> 
> --- Additional Comments From [EMAIL PROTECTED]  2004-11-13 16:04 ---
> I've tested the patch locally and it does appear to work, except that the
> mulitpart request also needed to be modified to account for the Vector of 
> Parts
> which were not being cleaned up at the end of the request.  Before I commit 
> I'd
> like to look over the patch to understand the changes better.
> 
> Geoff
>

Re: [GUMP@brutus]: Project cocoon-block-jms (in module cocoon) failed

[Geoff Howard]

On Tue, 09 Nov 2004 10:33:26 -0500, Stefano Mazzocchi
<[EMAIL PROTECTED]> wrote:
> Stefan Bodewig wrote:
> > On Mon, 08 Nov 2004, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
> >
> >>Geoff Howard wrote:
> >
> >>>I find it hard to believe the jms spec has changed, though I
> >>>suppose this is possible.
> > 
> > Which version does geronimo-* implement?  Maybe it is a change between
> > 1.0.2 (the version of JMS we had before Niclas changed it to the
> > geronimo version) and 1.1 - which seems to be the current version.

Don't know, but I'm confused about why it matters in this case.  The
GUMP site appears to say that this dependency is set up as a static
jar, not an ongoing project.  The jar (presumably the same one since
it hasn't been changed locally) is working in our build.

Still, going forward, Stefano's point is good - if we're building on a
prior spec version, we need to fix that.  I'll look into it.

> > Any reason we use Geronimo snapshots instead of the "official" Sun
> > jars, BTW?
> 
> no really. We shipt it with geronimo's and that compiles so I thought
> that was going to be better, but nope.

We can't redistribute Sun's as we understand it.  See Stefano's
comment here: 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106616095322380&w=2.
 At the time, he suggested ibiblio, but later in the thread the idea
of re-implementing the spec from published docs came up which led to
Geronimo.

> If we identified there is a API change between 1.0.2 and 1.1, I'd rather
> have cocoon update to the latest JMS API rather than having to different
> packages in gump since it seems that cocoon is the only one having that
> problem anyway.

I'll see if that's the case, and if it solves the problem with Gump
all the better.

Geoff

Re: [rfc] commons fileupload replacement

[Geoff Howard]

On Mon, 8 Nov 2004 14:16:45 -0600 (CST), Luigi Bai
<[EMAIL PROTECTED]> wrote:
> 
> On Mon, 8 Nov 2004, Geoff Howard wrote:
> 
> > On Mon, 8 Nov 2004 08:20:56 -0600 (CST), Luigi Bai
> > <[EMAIL PROTECTED]> wrote:
...

> I read your reference and Stefano's proposal. 

Excellent.

> I agree with the concept of
> having request interceptors, but I am not sure I agree with his syntactic
> proposal. In particular, it requires the creation of yet another type of
> sitemap component, meaning that it is heavily integrated into the Cocoon
> core. Why is that necessary?

Well, not really.  While sitemap statements are often also components
I don't think they always are or need to be IIUC.  At the end of the
day, they are nodes recognized by the tree processor.  We have no
construct (including actions) which allow the raw request object
(besides attributes) to be modified, or re-interpreted in any way.  To
grant this power to existing sitemap elements would be dangerous (in
the sense of ripe for abuse or confusion).

> Despite your characterization of Actions (below), I think they are a valid
> method for providing "cross cutting" functionality in a lightweight
> fashion. They don't require a user to implement PipelineNodes and all that
> jazz. And if the functionality proves to be stable and useful, then you
> can "harden" it into more formal syntax.

To clarify, once the proposed "adapt request" support exists, we would
almost certainly bundle and configure by default the very few
capabilities which would require it - multipart file handling would
almost certainly be part of this.  So, users wouldn't have to
implement PipelineNodes unless they had some unique new requirement or
wanted to write an alternative.  Further, this would likely be a
fairly simple contract anyway.

> The problem with Actions is that while they're flexible and lightweight,
> they cannot have access to all the parts of a pipeline that a Node can. I
> lean toward allowing an Action to tell the Environment to replace its
> Request object, allowing it to do the SOAP/DAV/upload processing in the
> Action. Yes, this can allow people to shoot themselves in the foot. But I
> think the benefits outweigh the risk.

:) Most would say that the problem is that Actions have access to too much!

I think though that we're just on some semantics based on the way you
have mentally categorized actions.

Again, the problem as I understand it with actions is that they: 
1) Can perform back-end "actions".
2) Can decide between alternate paths/steps in the sitemap.  
3) Can also completely redirect the request
4) Can also return values back to the sitemap which can trigger later
decision points using any other sitemap directive.

None of these are bad in them selves - it's the mixing of all of them.
 Adding the ability to modify the way in which the request is made
available to later steps in processing would only muddy things
further.

> Otherwise, a valid "hack" would be to have an Action that processed the
> multipart stream (like StreamGenerator) but which put its Parts under the
> RequestAttributes (the only part of the Request it's allowed to
> manipulate). Downstream components would then have to get the parts from
> the Attributes, not Params, but that'd be a contract to observe, nothing
> special.

I think this is why this needs to be handled deeper in the core (the
request adapting, not necessarily the multipart parsing).  And to
reiterate, would then not need to be re-done by people (just as it is
not now re-done by everyone needing to use multipart uploads) but
rather just utilized.

Anyone care to chip in with a path forward?  Can we do "adapt-request" now?

Geoff

> >> By the way, I'm not clear on why Multipart support can't be implemented as
> >> an Action? If it's an Action, then it's clearly pluggable, and all this
> >> goes away. Why is it so early in the process, hard coded in CocoonServlet?
> >
> > - Actions were a muddy concept that have been or can be at least
> > partially if not fully replaced by other items.
>

Re: the multipartparser

[Geoff Howard]

On Tue, 2 Nov 2004 15:43:37 +0100, Ugo Cei <[EMAIL PROTECTED]> wrote:
> Il giorno 02/nov/04, alle 15:29, Jorg Heymans ha scritto:
> 
> > Is there a reason why we have our own multipart parser instead of
> > using commons-fileupload? This has come up already about 1.5 years ago
> > [1].
> 
> Maybe when the multipart parser was invented, commons-fileupload wasn't
> yet there, or maybe it wasn't known or it was just a case of NIH
> syndrome. Anyway, if we can get the same functionality with
> commons-upload, let's drop this other reinvented wheel. +1 if you
> volunteer to do it.

Commons fileupload was spun off from Turbine in March of 2002.  At the
time we relied on MaybeUpload.  This was refactored here in late 2002
and again in early 2003
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105366511921069&w=2)
and the dependency was removed.

Interestingly, the archive link above is Stefano responding to another
inquiry about commons upload.

This is a good discussion to have - see my responses in the other rfc thread.

Geoff

Re: [rfc] commons fileupload replacement

[Geoff Howard]

On Mon, 8 Nov 2004 08:20:56 -0600 (CST), Luigi Bai
<[EMAIL PROTECTED]> wrote:
> I'd like to point out that the Multipart support in Cocoon is one of the
> few things that isn't pluggable or replaceable. I'd like it to be possible
> to configure web.xml/CocoonServlet to take a class name that implements
> some MultipartParser interface, and keep Part as an interface (perhaps
> letting it evolve as different implementations are available).

Some historical/background points (with the caveat that some changes
have happened due to CForms that I have not paid full attention to):
- We also have tried to avoid anti-patterns like "over
componentization" i.e., making things pluggable that really don't need
to be, which was probably judged to be the case here (though see
below).
- There were other grander plans for request handling.  In particular,
see the "Pluggable Request Factories" of Stefano's RT here:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106131747919501&w=2
- You'll notice a third point in the RT above: our "pluggable" problem
extends beyond multipart uploads.  It includes things like WebDAV and
SOAP.

> Keeping the integration at the level of Interface means we don't run into
> the same kind of rigamarole that is going on with ECM etc.

True, although another major lesson learned from ECM was that external
communities can also let you down.  The last time I monitored the
commons list, I didn't get warm fuzzies about the politics and health
there, for what that's worth.

> By the way, I'm not clear on why Multipart support can't be implemented as
> an Action? If it's an Action, then it's clearly pluggable, and all this
> goes away. Why is it so early in the process, hard coded in CocoonServlet?

- Actions were a muddy concept that have been or can be at least
partially if not fully replaced by other items.
- Why so early in the process is another good question.  Two reasons I
remember are:
1) Cocoon is not only a CocoonServlet but also runs in different
environments (Command Line for example) where multipart requests do
not have exact parallel if they exist at all.  We have tried to avoid
dependencies on Servlet specific APIs in part due to this issue.
Combined with the fact that Cocoon's uri abstraction (all uris are
mapped to the CocoonServlet, making total control in sitemap possible)
makes it possible that relying on Commons upload may turn out to be a
bad idea in the end: they do not have the same complexity of concerns.
 In fact, they've had some recent refactoring there to accomodate
portlet environments.  If someone can give an analysis of whether this
helps us or hurts us with respect to our complex needs, that would be
a big plus.
2) The cocoon framework as many frameworks pre-parses the request to
make all parameters available to the pipeline semantics.  The plan of
adaptRequest was to allow this to take place for most parameters up
front, but the multipart bits later.  The work to do this was never
done.

Any patch that addresses all these concerns would probably get some
good attention.

Short of that, a patch that provides backwards compatibility by
wrapping the commons library is next best in my opinion.  Short of
full pluggable request adaptors, encapsulation is as good as
configurability in this case IMO.  In this case, I think people will
be fine with one solution for the project, as long as it's easy to rip
out and replace if necessary.

A third option:  The entire project at Commons as far as I can see is
about 15 classes and hasn't had a release in almost a year and a half.
 (I'm guessing this is because the RFC for file uploads has not
changed and probably isn't expected to?).  In this case, I think it's
entirely reasonable to just fix our existing implementation rather
than depend on another project.

Earlier someone noted the comment in the code about multipart/mixed. 
I am not an expert here, but when I looked into this some time ago, it
was not supported by browsers.  We do support multiple files per form
using multiple input elements, so full conformance with the spec would
be academic.  Am I wrong here?

Geoff

> On Mon, 8 Nov 2004, Jorg Heymans wrote:
> 
> >>
> >> Is posible to add support for both at the same time? If this is possible,
> >> then we can add it in 2.1.6 and deprecate the old approach.
> >
> > so you mean actually wrap a FileItem inside PartOnDisk and PartInMemory,
> > instead of creating our own FileItemPart subclassed from Part? Yes that 
> > would
> > work as well give or take a few bodges.
> >
> > Regards
> > Jorg

Private Cache in XMLFileModule (was Re: DO NOT REPLY [Bug 32095] - Cache Event invalidation not working with non sitemap components)

[Geoff Howard]

Can anyone knowledgeable about either the XMLFileModule or
non-standard uses of the Cache shed light on this bug or the issues I
address below?

Geoff


On 8 Nov 2004 03:14:51 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=32095
> 
> Cache Event invalidation not working with non sitemap components
> 
> --- Additional Comments From [EMAIL PROTECTED]  2004-11-08 03:14 ---
> This is certainly a convoluted situation, but I think the problem is obvious:
> the XMLFileModule uses it's own private cache, and does its own private
> validity computations.  I guess this was necessary because the Cache is built
> around cacheable pipeline results, and the XMLFileModule does not usually act
> on pipelines (except in the case of the cocoon: protocol).
> 
> So, the full solution would be to change XMLFileModule to use the Cache.  This
> may not be possible/desirable.
> 
> I don't know if a work around is possible by changing the behavior of
> EventValidity.isValid().  The point of the event validity is that the source
> itself does not know whether it is still valid.  If it turns out that the Map
> the XMLFileModule uses for its validity is the same object that the event
> registry has access to, it may be possible to modify the behavior there, but
> it's not immediately clear to me if this will work.
> 
> Geoff
>

Re: [GUMP@brutus]: Project cocoon-block-jms (in module cocoon) failed

[Geoff Howard]

Can someone give some help figuring out what is wrong with gump for
the JMS block?  The build snippet below appears to show a failure due
to classpath (unresolved symbol) but the geronimo jms spec jar is in
the classpath (also below) and the block actually does build using the
build script.

gump.xml has a dependency declared:  but I can't see where that project is
declared in our gump descriptor.  I find it hard to believe the jms
spec has changed, though I suppose this is possible.  The gump site
appears to say that the geronimo-spec-jms project is a pseudo project,
just a binary jar included, making this change even less likely.

Any tips for tracking this down?

Geoff


On Sat, 06 Nov 2004 17:47:43 PST, Gump <[EMAIL PROTECTED]> wrote:
> Project cocoon-block-jms has an issue affecting its community integration.

...

CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tool
...
06112004/blocks/hsqldb-block.jar:/usr/local/gump/packages/jms1.0.2/lib/geronimo-spec-jms-DEV.jar
...

> cocoon-block-jms-compile:
>[javac] Compiling 7 source files to 
> /home/gump/workspaces2/public/workspace/cocoon/build/cocoon-06112004/blocks/jms/dest
>[javac] 
> /home/gump/workspaces2/public/workspace/cocoon/src/blocks/jms/java/org/apache/cocoon/components/jms/JMSConnectionManagerImpl.java:217:
>  cannot resolve symbol
>[javac] symbol  : method createConnection 
> (java.lang.String,java.lang.String)
>[javac] location: interface javax.jms.ConnectionFactory
>[javac] return 
> factory.createConnection(cc.getUserName(), cc.getPassword());
>[javac]   ^
>[javac] 
> /home/gump/workspaces2/public/workspace/cocoon/src/blocks/jms/java/org/apache/cocoon/components/jms/JMSConnectionManagerImpl.java:231:
>  cannot resolve symbol
>[javac] symbol  : method createConnection ()
>[javac] location: interface javax.jms.ConnectionFactory
>[javac] return factory.createConnection();
>[javac]   ^
>[javac] 2 errors
> 
> BUILD FAILED
> /home/gump/workspaces2/public/workspace/cocoon/tools/targets/admin-build.xml:57:
>  The following error occurred while executing this line:
> /home/gump/workspaces2/public/workspace/cocoon/build/cocoon-06112004/temp/blocks-build.xml:10011:
>  Compile failed; see the compiler error output for details.
> 
> Total time: 4 seconds

Re: [VOTE] Leszek Gawron and Ralph Goers as committers

[Geoff Howard]

On Thu, 28 Oct 2004 17:04:31 +0200, Torsten Curdt <[EMAIL PROTECTED]> wrote:
... 
> In fact both have been around for quite some
> time, contributed in discussions, sent patches
> and showed they care about cocoon and its community.
...  
> Folks please cast your votes for:
> 
> [+1] Leszek
> [+1] Ralph

When people think you're already a committer and have been for a
while, then watch out!

Geoff

Re: FilesystemStore broken???

[Geoff Howard]

On Thu, 21 Oct 2004 14:57:28 -0400, Vadim Gritsenko
<[EMAIL PROTECTED]> wrote:
> Pier Fumagalli wrote:
> 
> 
> > On 21 Oct 2004, at 04:22, Vadim Gritsenko wrote:
> >
> >> Store:
> >>   "Clean out" here writes stuff out into the persistent store,
> >>   if stuff is Serializable.
> >> Transient store:
> >>   "Clean out" here removes stuff completely, hence the
> >>   name: "transient".
> >> Persistent store:
> >>   Janitor does not touch this store at all. No "clean out"
> >>   happening at all.
> >
> > So, given that the cache is caching in the persistent store, who cleans
> > it out? The cache itself? This is getting _waay_ to frisky for my taste :-(
> 
> Cache caches into Store. Store overflows into PersistentStore when low on memory
> or on shutdown (*).
> 
> Cache cleans up stale items on "as-detected" basis, or, if you use event cache
> pipelines, stale items removed as per external events (**).
> 
> Vadim
> 
> * Might not work with JCS / EHCache implementations
> ** Don't know much about this event stuff myself

You're right about the event-based cache validities - not much more to
say about it in this context.

Also, the unbounded nature of the persistent store (especially as it
relates to the overflow from the cache) has always worried me.  I'd
much prefer to see cached entries examined periodically and if they
can be determined to be invalid, removed.  But, in practice this
apparently has not caused noticeable problems or surely we would have
heard about it?

Geoff

Re: [RT] applying SoC on cocoon itself

[Geoff Howard]

On Mon, 18 Oct 2004 10:20:03 -0700, Stefano Mazzocchi
<[EMAIL PROTECTED]> wrote:
> Pier made me realize that there are 3 different issues on the table
> regarding real blocks:
> 
>  1) classloading isolation
>  2) pojoification
>  3) service isolation

Aha!

...

> So here is my proposal for Cocoon 2.2
> 
>  1) fully incremental transition ...
>  2) addition of the uri="" attribute to the sitemap component ...
>  3) implementation of a single-classloader service lookup manager ...
>  4) implementation of service-based real blocks

Excellent!

...

> So, as I have indicated, I indent to start working on this transition
> *WITHOUT* interfering with the intra-block or inter-block component
> lookup mechanism, since they are orthogonal.
> 
> Comments?

Awesome!!

- Geoff

Re: Request: uncomment and change enabled in coc oon.xconf

[Geoff Howard]

You also should be able to write your xpatch file to replace the
comment containing the text "debugger" (for example) with your desired
setting.  I think this may be done in the jdbc xpatch files?

Geoff


On Wed, 13 Oct 2004 14:27:55 +0200, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Hi,
> 
> small "feature" request: could someone please change the following line in
> cocoon.xconf:
> 
> 
> 
> to
> 
> disabled
> 
> (and if necessary change the code that acts on this).
> 
> I'm using the flowscript debugger and each time I update my Cocoon version
> (from SVN) I have to change this line manually before my XPatchTask works
> again. :-(
> 
> Bye,
> 
> Helma van der Linden
> Medical Informatics
> University Maastricht
> POBOX 616
> 6200 MD Maastricht
> The Netherlands
> [EMAIL PROTECTED]
>

Alternative UI Framework

[Geoff Howard]

http://www.iternum.com/ui-demo/demos.jsp
Google related links popped this up recently on a CForms/Cocoon email.

Anyone know it and can provide a "competitive" analysis?

Geoff

Re: [Fwd: Help I can't get xpatch to work :(]

[Geoff Howard]

Besides not reporting an error, does running from the command line
actually work as expected?  Either way, I'd guess this has to do with
"endorsed libs" and outdated/mismatched versions of the xml libraries.
 I don't know enough of the ant/jEdit plugin or the mechanics of jEdit
classloading to help you track it down but that's the first place I'd
look.

Geoff

On Sat, 25 Sep 2004 21:05:04 -0800, JD Daniels <[EMAIL PROTECTED]> wrote:
> 
> I can't seem to get the xpatch to work for me :(
> When I call the target from the command line, I do not get any errors,
> but calling it with antfarm inside jedit  spits:
> 
> Class javax.xml.transform.TransformerFactory loaded from parent loader
> BUILD FAILED
> 
> java.lang.ExceptionInInitializerError
> 
>   at XConfToolTask.execute(Unknown Source)

...
 
> Caused by: java.lang.ClassCastException
> 
>   at javax.xml.transform.TransformerFactory.newInstance(Unknown Source)
> 
>   at DocumentCache.(Unknown Source)

...

> I am adding the task to my own project in my build file with:
>  classpath="${cocoon.dev.dir}/tools/anttasks"/>
> 
> here is my patch file:
> 
> 
>class="com.blah.HibernateFactory"/>
> 
> 
> This is what ant spits out at debug level on the command line:
> 
> Class org.apache.tools.ant.types.XMLCatalog loaded from parent loader
> (parentFirst)

Re: Updating a patch

[Geoff Howard]

new attachment for the existing bug.  

thanks


- Original Message -
From: Adam Ratcliffe <[EMAIL PROTECTED]>
Date: Sun, 26 Sep 2004 10:21:39 +1200
Subject: Updating a patch
To: [EMAIL PROTECTED]


Hi,
 
I need to update the patch that I submitted for flow/web services
integration, http://issues.apache.org/bugzilla/show_bug.cgi?id=31359
 
Should I create a new attachment for the existing bug, or create a new bug?
 
Regards
Adam

Re: Custom extensions - to be made available if possible

[Geoff Howard]

POV = point of view


On Wed, 15 Sep 2004 07:47:27 +0200, Antonio Fiol Bonnín
<[EMAIL PROTECTED]> wrote:
> > > As I said in a previous e-mail (Sep 10), we downloaded PDF box
> > > (www.pdfbox.org), but it seems to us a bit hard to use.
> >
> > This project uses the BSD license. I think this can be a good candidate
> > for integration with Cocoon. Because of the BSD license, We can be able to
> > include the code and distribute the library as part of the cocon releases.
> 
> Understood. For now, we continue on this line, at least today.
> 
> > > It seems to have a viewer, and so it seems to draw on a Graphics. This
> > > could be used combined with Batik to generate SVG... but that seems a
> > > bit overkill.
> 
> I still believe that this sort of SVG generation is overkill. Does
> anyone agree that a PDF operation processor that spits SVG may be
> simpler to achieve? Most importantly, I reckon this approach allows us
> to generate simple SVG without bells and whistles (e.g. only
> positioned text on a correctly sized page), and improve it with time.
> 
> 
> > > We also found Etymon PJX (www.etymon.com/epub.html), but it's like the
> > > hard part of pdfbox, but without the easier part concerning the
> > > Graphics.
> >
> > This one is GPL. The integration with Cocoon will be more dificult. Same
> > case as Hibernate.
> 
> OK. Difficult to use + Difficult license integration = Discarded.
> 
> 
> > OF course this is just from the license POV. I have not experience with
> > neither of them.
> 
> Sorry, but... What POV? A google search por POV or POV PDF leaded to
> "povray" and many "point of view".
> 
> 
> 
> Thank you very much.
> 
> Antonio Fiol
>

Re: DO NOT REPLY [Bug 31234] - Event Aware cache does not remove registry key

[Geoff Howard]

On 15 Sep 2004 10:29:27 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=31234
> 
> Event Aware cache does not remove registry key

...

> --- Additional Comments From [EMAIL PROTECTED]  2004-09-15 10:29 ---
> Thanks Oliver, I applied your fix.
> 
> About the way AbstractCachingProcessingPipeline tries to find cached objects for
> shorter cache keys, judging from your description, it makes sense to me to
> always try a shorter key to find partially cached contents. I don't think this
> should be the concern of the Cache implementation. To pursue this further I
> suggest you either create a separate bugzilla entry for this or start a
> discussion on [EMAIL PROTECTED]

Thanks, Unico and Oliver - I'm barely keeping up with the list these
days.  It looks like this was a result of some of the cache
re-factoring?  If so, hopefully this is the only remaining effect.

On the caching point behavior - I agree this would be better handled
in the pipeline logic if possible, not the cache.  My original reason
for wanting to clear the object out of cache entirely were obvious but
important:
- It's known that it will never be needed.
- Existing cache/store code has (or had last I looked) no mechanism
for causing old unusable cache items to be cleaned up without a new
request coming in.
- The persistent cache (again last I looked) could not be limited so
that over time a large amount of unusable, never-again-requested items
would build up on disk.  Risk is a too-large index, and a "disk space"
leak.

Geoff

Re: Test

[Geoff Howard]

Yes, unbelievably so!


On Wed, 08 Sep 2004 12:17:57 +0200, Sylvain Wallez <[EMAIL PROTECTED]> wrote:
> Just a test, wondering why the list is so silent lately. Is everyone busy?
> 
> Sylvain

Re: [request] creation of the Tani branch

[Geoff Howard]

On Sat, 28 Aug 2004 10:15:29 -0400, Stefano Mazzocchi
<[EMAIL PROTECTED]> wrote:
> Torsten Curdt wrote:
> > +1 for the branch
> >
> > and although I really like the name "tani"
> > I think we should stick to what we decided.
> > no fancy names.
> >
> > +1 for keeping the "new-kernel" (or naming
> > it "block-kernel")
> 
> Hmmm, what about butterfly then?
> 
> The problem with calling it "new-kernel" is that the new kernel is just
> part of what that branch will host and this will create naming issues.

Good point.

> As for giving up the codename: unlike tomcat's catalina or woody, we
> will not use "tani" in the package name or in any part of the contract,
> since we already expect "tani" to be just a codename and to be thrown
> down the drain once we are done with it and the community decides what
> to do.

Good point.

> Just like Ugo, I feel the need for a clean slate and a place where I can
> work without breaking everybody else's code. I personally don't care if
> the code will be used or not, what I care is to create a prototype to
> show to this community and to my group at MIT, what real blocks can give
> you and how they can make your life better (and, for my group at MIT,
> show why Cocoon is not just an XSLT servlet anymore, shrug)

Sounds great.  I see distinction between "code names" like this and
final block names (which I still think don't serve us well).

Geoff (sorry I've been out of touch)

Re: [RT] A Groovy Kind of Sitemap

[Geoff Howard]

I'm still in skimming mode, but I'll lob a nearly incoherent thought
in from the sidelines...

On Thu, 29 Jul 2004 10:34:29 -0700, Stefano Mazzocchi
<[EMAIL PROTECTED]> wrote:

...

> A little bit of history is needed:
> 
> - at the beginning there was no sitemap. all the pipeline machinery was
> "embedded" into documents using processing instructions. when it was
> proposed to move on, nobody ever objected.
> 
> - cocoon was still a publishing framework. this means it was meant to
> respond to "GET" requests. Pier and I sat down in his office in Erba
> (CO) in Italy and created the first draft of the sitemap. This was 4
> years ago. Given the high declarativity of the sitemap and given the
> impressive mind-bending nature of declarative languages that we had
> experienced for the first time a few years earlier with XSLT, the use of
> XSLT as a guiding path (and Pier's previous experience at IBM with
> StyleBook) was a no brainer. We *never* thought about a different syntax.
> 
> - the sitemap has not changed since then, if only a few things, mostly
> actions, and I was against them, but I saw the need and had no better
> idea (and no time at that time to spend more on it).
> 
> - actions soon showed weaknesses because the degree of reusability of
> actions is *much* lower than that of any other kind of sitemap
> component, showing that they are misplaced.
> 
> - the need to separate "resource production" from "flow control" can be
> seen as an extension of MVC where the view is a pipeline, the controller
> is a mix of flow control, business logic and glue between the two and
> the model is whatever you use to pass data from the two.
> 
> At this point, I went to Giacomo's in Zurich to talk about the
> "flowmap", as we called it at that time. We were so much ingrained into
> finite state machines that we didn't even think about the ability to
> "freeze the execution state" (which is what continuations are all about).
> 
> The flowmap, written in XML, was written on a few whiteboards, but it
> was so ugly that it was never even written into an RT.
> 
> It was Ovidiu that came with that idea and radically changed my way of
> thinking about this "flowmap", which soon became "flowscript".

I'm going to try to express a nagging feeling I don't like about the
current system of flow+sitemap:  It feels weird jumping from place to
place.  Requests come into the sitemap, have the matching/sitemap
rules applied, then possibly go out to flowscript, then back into the
sitemap - matched again, then processed.  So we have,
1) request matching (sitemap)
-
2) backend business logic (flowscript, flowscript-calling-java)
3) complex pipeline selection (flowscript, sendPage)
4) page flow control (flowscript, continuations)
-
5) pipeline construction/composition (sitemap)

At a gut level, something feels awkward about all that - not in any of
the individual pieces but more in how they stitch together/work
together.  I feel like I'd rather have the top section (item 1) and
the last one (item 5) not be the "same" (this is not a "symetry
argument by the way).  Obviously I'm implying some mixing of concerns
is happening, but I'm not sure I see where they are.

Maybe it's just that I'd rather that the uris used to go back to the
sitemap be simple named pipeline definitions with no new
matching/selection functions or no ability to go back into flow. 
Clearly delineated somehow as an endpoint, not room for further
decision branching.

Or maybe the problem is between the first two sections: I have to go
into the sitemap to get into flow, then go back to the sitemap
(somewhere else).  Maybe if some/all uris began being evaluated by
flow, which selected the pipeline, which then couldn't send back into
flow.

Maybe it's only that there is no distinction between the different
"pipeline" definitions in the sitemap, some are end-points, some are
entry-points and some are both.  Sort of a "map:receive" section, and
a "map:process" section, with slightly different rules betweent them.

Why insert this stream of consiousness into this discussion?  I have a
gut feeling that something in this discussion could lead to a solution
along these or totally new lines that cures this "uneasiness", or
could make it even worse.

...

>  - o -
> 
> Instead of arguing about the status quo, let's give Ugo the space he
> needs to show us where we can innovate.

Of course.

> If Cocoon is what it is today, it's not because we remained where we
> were, but because we allowed people to innovate internally and with an
> open and friendly attitude and we "guided" our user base in new
> directions and never failed to provide them a better environment then
> before.
> 
> Let's NOT forget that.

Sounds good.
Geoff

Re: [VOTE] new Cocoon PMC chair

[Geoff Howard]

Steven Noels wrote:
Here's the current list of nominations - people who already clearly 
declined are not on the list anymore. Sort order alphabetic on first name.

 - Vadim Gritsenko
Only one I've met IRL -- +1.  I'd be enthusiastically in favor of any of them, 
though.

Geoff

Re: Enough object store crap, let's get serious

[Geoff Howard]

http://www.sleepycat.com/download/licensinginfo.shtml
Stefano Mazzocchi wrote:
http://www.sleepycat.com/products/je.shtml
Need I say more? ;-)
Now, the only problem is that this requires java 1.4.2 because of memory 
mapped files.

If you ask me, this feature, alone, is enough for throwing 1.3 down the 
drain. I mean, if you are running a serious web site and you need tons 
of cache, and you are still using 1.3, well this is simply not our 
problem and you should be investing to migrate because that's going to 
save you tons of headackes anyway.

BerkeleyDB is an ACID database without the client/server overhead and 
without fancy querying abilities. Everybody and their dog knows that 
BerkeleyDB is the de-facto standard for storing tons of information in a 
reliable and efficient way.

I think we should use BerkeleyDB for the cocoon object store and at this 
point, even the transient/non-transient nature of things could not be 
needed anymore because we can use memory-mapped files or hybrid-memory 
cached file backends.

This means that you can forget about your cache. You can showdown your 
cocoon and restart it and the entire thing would be there as it was before.

Who's with me?

Re: [IMP] Something is wrong with out stores

[Geoff Howard]

Carsten Ziegeler wrote:
The more I look into this store problem, the more I get confused.
I think I understood from Sylvains explanation that the persistent
store should only be used by our store as a back up.
Looking through our code, I found out, that some components
still use the persistent store:
- StatusGenerator
- ClearPersistentStoreAction
- EventAwareCaching
So, should we simply change them to use the store?
That should be fine for EventAwareCaching.  IIRC the reason I had it use 
persistent store directly is that it is used at shutdown to persist the 
cache/event correlation information between runs and it made more sense to me at 
the time to go directly into permanent storage.  Thanks for working on this.

Geoff

[Fwd: Re: [Heads-Up] List Etiquette & Return Recipts (Was: Re: Asking again Portal framework login issue)]

[Geoff Howard]

Ooops, sent to wrong list.  Anyone know enough about ezmlm?

Geoff

Sylvain Wallez wrote:
Tony Collen wrote:

This is a just general FYI for anyone who posts to the user and -dev 
lists:

*Please un-set the option which causes your mail client to request a 
return receipt!*
...

A good way to "invite" people to disable this option is for everybody to 
send the return receipt. I'm sure receiving several hundreds of 
confirmations will make them run to their mailer preferences to disable 
the feature ;-)
As this is controlled by the Disposition-Notification-To header (IIUC) can ezmlm
be configured to strip this off all messages before relaying to the list?  I
hate these things too, but know that some people use them for most business
communication and probably can't pick settings per-email.
Geoff

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


.

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

[Geoff Howard]

Vadim Gritsenko wrote:

Askild Aaberg Olsen wrote:

A link from http://www.mattkruse.com/javascript/calendarpopup/
leads to http://www.webreference.com/dhtml/diner/seethru/
Bingo. And solution is to upgrade to Mozilla.

I'll add another workaround to the pool: hide all "windowed" controls 
before showing popup.
You can also programatically hide only the affected controls.  We've used 
another calendar popup that does this - I'll try to dig up a link.

Geoff

Askild
-
Marc Portier wrote:
 

Hi all,

I just checked in an update for one of our cforms samples that 
reveals a somewhat nasty visual presentation of the nice calendar 
widget we use

please update, build, start cocoon and check over with: 
http://localhost:/samples/blocks/forms/for> m1.flow
then click the calendar icon next to the 'birthday' field

if placed just above a (multi-line) selection list (like done now) 
the calendar popup seems to be kept behind that selection list...

anyone that has a clue what is causing this?

regards
-marc=
  


 

Re: XConfToolTask and more than one patch action per file

[Geoff Howard]

+1 from me - I didn't know why it was that way either and just left things as I 
found them whenever I've touched it.  This task goes back pretty far though IIRC 
- maybe there was a forgotten reason?

Geoff

Ralph Goers wrote:

I had thought about doing this in my last update to XConfToolTask, but I
didn't want to add two features in one patch.
Doing this could actually be pretty easy.  Currently, it looks at the root
node and grabs info from it. It would be pretty easy to see if the child
nodes are some sort of "patch" node, and if so iterate through them getting
the info that would normally be on the root node from each patch node
instead.
It would be nice to do this as you could put related patches in one file.

Ralph

-Original Message-
From: Claas Thiele [mailto:[EMAIL PROTECTED] 
Sent: Monday, May 10, 2004 9:00 AM
To: [EMAIL PROTECTED]
Subject: XConfToolTask and more than one patch action per file

Whats the reason for having one patch action per patchfile only?

Using filesets the execution order of the patches is not predictable and 
so it is a hell writing more complex patches.

Would it be a good idea having a set of actions in one patchfile like 
xupdate has?

Claas

Re: Supersonic block has landed (Power Trio tutorial/example app)

[Geoff Howard]

Bruno Dumon wrote:

On Mon, 2004-05-10 at 14:28, Bertrand Delacretaz wrote:

Le 10 mai 04, à 05:59, David Crossley a écrit :

...I think that it should be called the "tour" block, yet still
have the familiar name of "Supersonic Tour"...
Do others have the same opinion? If so I'm ok to rename the block, I 
agree that it's a more descriptive name.


how about the full "supersonictour" ?
Yes, I have the same opinion too, and either tour or supersonictour are fine 
with me.  Antonio, were you thinking of HSQL (stands for Hypersonic SQL, doesn't 
it?).

Geoff

Re: formation@anyware-tech.com

[Geoff Howard]

Tony Collen wrote:

Geoff Howard wrote:

No, you're not the only one - but far from being upset I am always 
happy to get commercial Cocoon information, especially from someone 
actually involved in the community.

Geoff

Jorg Heymans wrote:

Am i the only one who has received unsollicited cocoon related 
advertisement mail from anyware-tech on several email addresses?
I believe it's a cocoon related company from one of the committers here.


Sorry, the line has been crossed with me.  I also got the spam, and I 
can't even read it since it's

a) Totally in French, and I can't read a lick of French.
b) In HTML
Hmm, mine had a clear bilingual message at the top:

Si le message ne s'affiche pas correctement, aller à l'adresse:
http://www.anyware-tech.com/home/mailing/anyware_formations_04_2004_fr.htm
If you cannot properly see this message, go to:
http://www.anyware-tech.com/home/mailing/anyware_formations_04_2004_en.htm
Geoff

Re: formation@anyware-tech.com

[Geoff Howard]

No, you're not the only one - but far from being upset I am always happy to get 
commercial Cocoon information, especially from someone actually involved in the 
community.

Geoff

Jorg Heymans wrote:

Am i the only one who has received unsollicited cocoon related 
advertisement mail from anyware-tech on several email addresses?
I believe it's a cocoon related company from one of the committers here.

Just curious...

Jorg

Re: [VOTE:RESULTS] Move to SVN

[Geoff Howard]

Klaus Bertram wrote:

I try it as normal user with the subclipse plugin in eclipse but
I don't see any files at
 https://svn.apache.org/repos/test
(with a browser it worked after an error message)
I try to use
 http://svn.apache.org/repos/test
That works and i can checkout files and projects
I have found ssl (https) support still finnicky in subclipse.  I use it for 
work, and have had to pay close attention to subclipse devel and precise eclipse 
release version.  For a while, ssl support was only available on the 3 branch of 
eclipse - not sure if that's still the case.

Geoff


Nicola Ken Barozzi wrote:

Nicola Ken Barozzi wrote:

Since we are working a lot with branches, and there will be even more 
moving stuff around when the blocks will hit the street, I propose 
that we move Cocoon to use SVN. It works very well and we will be 
pushed to use it in any case in the near future.


The result is that we have decided to move to subversion right after 
the next 2.1 branch point release.

In the meantime I warmly suggest all to take a look at the subversion 
manual at http://subversion.tigris.org/ and trying it out with the 
test repo at:

  https://svn.apache.org/repos/test

In particular check and try how to move, copy and rename files, how to 
delete dirs (yes, it can be done :-) and how to branch-merge.

On the subversion site you can find all the information needed for 
plugins and GUIs that can help you work more easily with SVN.

Happy hacking!

Re: CalendarGenerator enhancement suggestion.

[Geoff Howard]

Ugo Cei wrote:

roy huang wrote:

Hi,ugo:
 I checked CalendarGenerator today and thought about how it can be used.I was a Lotus 
Notes programmer,there's a kind of calendar view in Notes.We like to display 
meetings,arrangements(scheduling stuffs) in this kind of view.Today I check 
http://localhost:/samples/cal ,it looks almost the same to Notes's calendar 
view,but only month.
 That's my suggestions:
 1.provide parameter "type",the type can be:
   a.year
   b.month(default,like now)
   c.two weeks
   d.week
   e.work day(week without Saturday and Sunday)
   f.two day
   g.day
 2.like http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=108004670802012&w=2
  provide the dates before the first day of the month and the dates after the last day 
of the month if they are in the same week.
 3.provide an example to display information in the calendar view.
WDYT?


I think yours are sensible suggestions, but I don't think I'm going to
implement any of them any time soon, except maybe number 3. It would be
nice if you could provide some code... ;-).
Another feature might be:

4. Output an element containing the (suitably internationalized) names
of the weekdays to use as column headings.
By the way, I wasn't even aware of the ML thread you have mentioned when
I started writing the CalendarGenerator (maybe I should start monitoring
the users' list more carefully). I just needed a monthly calendar
suitable for a blog or news site, so I did "The Simplest Possible Thing
That Might Work" (TM).
Ugo,

I'm still in the same boat I was then (interested with no time) but I'd love to 
get your observations on the different ideas floated in that thread.

Geoff

Re: Modular database component

[Geoff Howard]

Christopher Oliver wrote:
Reinhard Poetz wrote:



I already said in several mails that we should reduce the recommended 
options:

1.) Use O/R-mapper if possible
2.) if you only have publishing tasks use the sqlTransformer
3.) If the learning curve for an O/R-mapper is too steep for you take 

(In my opinion this is a simple DB-component as described below)

What I want to tell all users clearly is that they should avoid 
writing SQL-statements. Integrating SQL in applications is the start 
of a maintainence nightmare and IMHO we should clearly warn them using 
XSP, Groovy or any other templating system requiring you to write SQL 
*into* the code. Once again, I really like e.g. JXTG but it should 
*never* contain SQL statements.


Just wondering, is there any real difference between having say a 
 macro in JXTG and 
SQL transformer? In fact, wouldn't JXTG be more useful for publishing 
(since you can perform conditional branching and additional variable 
substitution) than SQL Transformer? Or, if not then perhaps SQL 
transformer itself should be eliminated. At any rate, shouldn't it be a 
generator rather than a transformer?
In my personal opinion, we absolutely must have both a SQL Transformer and SQL 
Generator with basic scripting (be it JXTG, ESQL, USQL, Groovy, whatever) which 
is the recommended method in situation 2 above and others like it.

We have PHP, ColdFusion, ASP developers coming over to Cocoon because they've 
heard it's the greatest thing since sliced bread and adding O/R tools to the 
list of things they have to learn just to produce their first page displaying 
data from a database would send them running more than we already do.  There is 
a huge LAMP (linux, apache, MySQL, PHP) world out there and convincing them to 
become LAMCXmlXslSitemapMVCContinuationsFOMOJBJavaAvalonExcaliburSoCGoF people 
in one step is completely unrealistic.

I also think and have thought for some time that repackaging the ModDBActions as 
generalized components accessible from flow would be a great step forward for 
these types of users, and for anyone with relatively simple needs.  We need this 
 to keep people with script template backgrounds from doing data manipulation 
in the view layer (generator or transformer).  The only way to avoid that now is 
to point them back to actions or complicate the issue with OJB.  It may be that 
a scriptable component rather than the declarative moddb approach would be a 
better starting point for people - all the better.

Geoff

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

[Geoff Howard]

Ugo Cei wrote:

Geoff Howard wrote:

If the end-result of this is users seeing more stacktraces, or plain 
404 or 500 errors, I go -1.  
Users should see *shorter* and more meaningful stacktraces.
No, that was my point.  Developers should see shorter more meaningful 
stacktraces.  Users should never see a stack trace in my opinion.  I know this 
is a semantic difference between "users" of the cocoon framework, and users of 
the applications they build.  I thought what you are proposing is not in 
conflict with this, but I didn't have time to figure that out myself, hence my 
comment.

If the end result is developers can still "catch" errors in the 
sitemap and display custom "oops" pages instead (as currently) then I 
go to +0. 
There is no plan to remove "catch" clauses from the sitemap processor, 
so the usual  should still work as usual.
There you go.  Sorry you had to spell it out explicitly.

If, however, this means backwards incompatibility or behavior change 
with existing components (external too, not only in our cvs) then I go 
back to -1 no matter what.
Removing a checked exception from the "throws" clause of a method 
declaration is a backward-compatible change.

However, if we later on decide that this was not a good idea after all, 
readding a checked exception is backward-incompatible. This would only 
affect people who wrote code, calling this method without a try-catch 
block, in the interval between the two changes. I think that this is 
quite improbable and easily caught.

Hope this clears your doubts.
I think this is probably OK risk.  I'm on +0 now.

Geoff

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

[Geoff Howard]

Ugo Cei wrote:

I think everyone interested has had the option of venting his opinion on 
the subject of checked vs. unchecked exceptions. For the record, here 
[1] is the relevant thread.

In order to move forward, I propose to reparent the 
org.apache.cocoon.ProcessingException to extend 
org.apache.avalon.framework.CascadingRuntimeException instead of 
CascadingException.

The change is backward-compatible and is a one-line change that can be 
reverted easily, but might have implications on the way we manage 
exceptions in the future.

I've already performed the change locally and everything compiles. Tests 
fail, but they failed also before the change :-(.

So, please cast your votes.

Ugo

[1] http://marc.theaimsgroup.com/?t=10818860842&r=1&w=2
I have next to no time to follow the discussion, or comment fully, but I lean to 
 -.5 because I have a feeling that the thought process is too geared to how 
developers want to see errors, not how developers should want users to see 
errors.  If the end-result of this is users seeing more stacktraces, or plain 
404 or 500 errors, I go -1.  If the end result is developers can still "catch" 
errors in the sitemap and display custom "oops" pages instead (as currently) 
then I go to +0.  If, however, this means backwards incompatibility or behavior 
change with existing components (external too, not only in our cvs) then I go 
back to -1 no matter what.

Geoff

Re: Something about a new core?

[Geoff Howard]

Berin Loritsch wrote:
I have been following the (un)checked exception dialog because I feel 
that it is the easiest/best place for me to get back in the swing of 
things with Cocoon.  I saw a couple comments about a new core for 
Cocoon, and I was wondering if someone could throw a couple links my way 
for more information.
http://cvs.apache.org/viewcvs.cgi/cocoon-2.2/src/kernel/org/apache/cocoon/kernel/

http://marc.theaimsgroup.com/?t=10800483371&r=1&w=2 (original RT)
http://marc.theaimsgroup.com/?t=10807293574&r=1&w=2 (first landing in cvs)
Misc:
http://marc.theaimsgroup.com/?t=10807269265&r=1&w=2 (source resolving)
http://marc.theaimsgroup.com/?t=10815217281&r=1&w=2 (hotswapability)
http://marc.theaimsgroup.com/?t=10811716734&r=1&w=2 (component devel)
http://marc.theaimsgroup.com/?t=10807314225&r=1&w=2 (comments on cvs)
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108081251820893&w=2
Mother Load:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&w=2&r=1&s=kernel&q=b (search on 
marc archives for "kernel")

HTH,

Geoff

Re: [Kernel22] How to develop a component?

[Geoff Howard]

Carsten Ziegeler wrote:

 
Stefano Mazzocchi wrote:

:) Sounds good to me. Now what do you think of using the 
things from 

Avalon that are good (for us)? Now, I think, some of the interfaces 
(for logging, contextualization, initialization) are good 
and we could 

directly use them instead of building just a clone of them.
There are two issues here, Carsten. One is about the present 
and another is about the future. Present indicates that 
reusing what's available is great, future indicates that if 
we keep dependencies on
org.apache.avalon.* namespace we either end up forking it or, 
more likely, we have potential classloading collision issues 
in the future with things that avalon might produce.

remember the rhino classloading problem with weblogic? same thing.

Sure.


I strongly suggest that we start with org.apache.cocoon.* to 
avoid these problems down the road (including, yes, gump problems)

Yes, I understand of course all these problems, but I'm really afraid
of changing all the components now from Avalon interfaces to Cocoon
interfaces which are more or less the same but just use a different
package. In that case these components run in Cocoon but not in any
other container anymore that provides Avalon compatibility. And
that's imho bad. Not every project uses Cocoon, so it's absolutely 
preferable to have components that I can use in several projects.

Ok, I think if we decide to use our own versions of the interfaces it
will still be possible to do some hacky things and still provide
compatilibity with the Avalon versions.
So what do others think?
I'm under the impression that this is very rare.  The constant fracturing of the 
container wars has to have made true interoperability very hard to achieve.  Are 
you saying that you have specific projects which use components across containers?

Existing components ought to be supported by the proposed avalon compatibility 
block.  Maybe new/updated components which need to interoperate with other 
blocks in Cocoon and with other containers could be constructed carefully to be 
valid components in both worlds.  A pain, but the universe of people who are 
likely to use both cocoon and other avalon components has to be a pretty small 
and capable group.

If this doesn't seem possible in your case, let's think about why and weigh our 
options.

Geoff

Re: new blocks.properties way more painful to use

[Geoff Howard]

Ugo Cei wrote:

Il giorno 05/apr/04, alle 16:54, Geoff Howard ha scritto:

Ugo Cei wrote:

Il giorno 05/apr/04, alle 15:38, Geoff Howard ha scritto:

Is "/" "." that much more harder than "arrow down" "x" ?

The coommand for findiing the next match is "n" not "/".


Actually, it's /-enter (a blank search - it's an old habit) -
they both work.
Geoff

/-enter is two keystrokes instead of one ;-)
:) true.

Geoff

Re: new blocks.properties way more painful to use

[Geoff Howard]

Ugo Cei wrote:

Il giorno 05/apr/04, alle 15:38, Geoff Howard ha scritto:

Is "/" "." that much more harder than "arrow down" "x" ?

The coommand for findiing the next match is "n" not "/".
Actually, it's /-enter (a blank search - it's an old habit) -
they both work.
Geoff

Re: new blocks.properties way more painful to use

[Geoff Howard]

Stefano Mazzocchi wrote:

in the past I was used to:

 1) cp blocks.properties local.blocks.properties
 2) vi local.blocks.properties
 3) uncomment the blocks that I wanted to exclude
Today, I have to go thru a bunch of include and change them from true to 
false. Much more hassle than just uncommenting/commenting one line.
?  With the previous uncomment scheme, you probably did arrow down, and then the 
"x" command to delete the # character.  With the new scheme for the first line 
you would do "/true" (find the word true) and then "cw" "false" "esc".  From 
them on you'd do "/" (repeat the last find) until you found a line you want to 
change then "." (repeat the last edit).

Is "/" "." that much more harder than "arrow down" "x" ?

Geoff

Re: Known concurrency issues in 2.1.4/JISP bugs....possible workaround?

[Geoff Howard]

Sylvain Wallez wrote:

Geoff Howard wrote:

Sylvain Wallez wrote:

Geoff Howard wrote:


I don't know for sure but I think it's the order of the index used 
by the JISP impl.
Thanks for this enlightning explanation, but erm... what is the 
"order" of an index???

;-)
http://www.coyotegulch.com/jisp/docs/com/coyotegulch/jisp/BTreeIndex.html#BTreeIndex(java.lang.String,%20int,%20boolean) 
Ah, ok! Thanks!

But, erm... where does this "2701" come from? And yes, I googled for 
"JISP 2701" before asking ;-)
Unfortunately I have no idea where this came from but assume it was from some 
authoritative source to begin with?  I'm surprised google didn't find something 
in the dev list archives about it.

Geoff

Re: Known concurrency issues in 2.1.4/JISP bugs....possible workaround?

[Geoff Howard]

Sylvain Wallez wrote:

Geoff Howard wrote:

Sylvain Wallez wrote:

Andrzej Jan Taramina wrote:


...





An aside...what the heck is the "order" value anyway?


No idea :-/


I don't know for sure but I think it's the order of the index used by 
the JISP impl.


Thanks for this enlightning explanation, but erm... what is the "order" 
of an index???

;-)
http://www.coyotegulch.com/jisp/docs/com/coyotegulch/jisp/BTreeIndex.html#BTreeIndex(java.lang.String,%20int,%20boolean)

Re: Known concurrency issues in 2.1.4/JISP bugs....possible workaround?

[Geoff Howard]

Sylvain Wallez wrote:
Andrzej Jan Taramina wrote:
...





An aside...what the heck is the "order" value anyway?
No idea :-/
I don't know for sure but I think it's the order of the index used by the JISP impl.

Geoff

Re: excluding unstable blocks by default

[Geoff Howard]

Quick comment on a busy day: I'd rather see us take this opportunity to 
allow/create build profiles.  The core cocoon-provided ones (core, all-stable, 
all-current, all (includes deprecated), "publishing", "dbapps"...) would be 
created out of gump.xml, but the user could then keep multiple options laying 
around simultaneously: client1.(build|blocks).propertes, or live, stage, etc. 
We'd create convenience task aliases for the stock ones as you mention below, 
and build custom would default to the local.properties, but you could also swap 
in a specific profile with -Dbuild.profile=client1 etc.

I proposed the ant side of how this would work a few weeks ago in the "How can I 
help" thread.

WDYT?

Geoff

Joerg Heinicke wrote:
Upayavira  upaya.co.uk> writes:


How hard would it be to switch to having:

build stable
or
build unstable
instead of build webapp?

That would enable someone to choose right up front, without having to do any
file editing.


Hmm, that's indeed an interesting approach IMO. I thought about something
similar (creating blocks.properties on the fly) months ago, but I stopped as the
user would no longer have a base for starting with his blocks selection
settings, i.e. no easy way like "copy blocks.properties to
local.blocks.properties".
With the current implementation a simple build stable/unstable would not work.
You must ignore local.blocks.properties for getting this working.
But the above also leads to new idea: First remove blocks.properties from CVS
and the need for local.blocks.properties, both files will not be read in the
init target. The information stable/unstable is in gump.xml and blocks-build.xml
is created from it, so we don't need the indirection using blocks.properties.
Now build stable and build unstable influence the creation of blocks-build.xml.
Sounds not very difficult IMO.
Now I want to complete this picture:
build (minimum) webapp <== just Cocoon core
build stable webapp <== Cocoon core + stable blocks
build unstable webapp <== Cocoon core + stable + unstable blocks
build complete webapp <== Cocoon core + stable + unstable + deprecated blocks
I also would ignore the backwards incompatibility: We can print out on build
time what is chosen, furthermore I think it's very obvious when build webapp
does no longer include your selected blocks, everybody will get this very fast.
And for a custom blocks selection there is additionally
build custom webapp
This target would look for a local.blocks.properties (or
custom.blocks.properties for consistency with the target). If it's not there it
generates it, stops the build and asks the user for doing the selection in this
file. A further call to the target would execute the build completely.
BTW, if you only introduce build stable/unstable, mapping one or the other to
build webapp, then you can not build the war file with the same
behaviour/default selection of stable/unstable blocks.
WDYT?

Joerg

Re: Replacing JISP with JCS for Cocoon 2,1,4?

[Geoff Howard]

Andrzej Jan Taramina wrote:

Unico:


It's in the scratchpad block. There is a JCS store implementation and an 
 EHCache one. If you build with the scratchpad block included some 
commented-out example configurations will be in cocoon.xconf. All you need to
do is uncomment them.


Wonderful!  This will definitely help me out.  

One final question.do I need the latest scratchpad block from CVS, or is 
there one in the 2.1.4 distribution that is useable?
Latest from CVS.

Geoff

Re: [OT] Re: [Kernel2.2] Comments

[Geoff Howard]

Hunsberger, Peter wrote:

Pier Fumagalli <[EMAIL PROTECTED]> writes:


On 31 Mar 2004, at 21:39, Hunsberger, Peter wrote:


My assembler exposure (many years of OS maintenance) was 
the IBM 370 

(latter 390) variant, more registers, but basically the 
same kind of 

muckity muck with the addition of channel programming; IO that 
modifies IO
I feel so old...  I've coded on the S/36 in the mid 80s :-(
They were good as office-heaters, though!


Heck, you're a young pup. S/34 and S/36 (and maybe even S/32) where all
after IBM 360 and 370.  The first IBM 360 I worked with you could stand
inside (I should have written my first real ASM -- outside of a
machine language class -- was IBM 360.)
Ok, you guys.  Quit banging on your chests and get back to work. :P

By the way, I used to work with Charles Babbage...

Geoff

Re: IDE for cocoon with hot code replace

[Geoff Howard]

Jean-Christophe Kermagoret wrote:

Hi,
I have cocoon in Eclipse 3.0M7 with Tomcat 5.0.19.
I've successfully used a different Eclipse (2.1, and M5 I think) and Jetty 
instead but that should be irrelevant.

I deleted the cocoon-portal.jar and I put the sources instead. When I 
put a breakpoint, the IDE becomes crazy and shows anything but the real 
one.
If I modify the code, the system asks me to relaunch tomcat...
Sounds like the source is not the same version used to built the jar?

Is it possible to develop cocoon with hot code replacement and debugging ?
Does the wiki on cocoon-eclipse integration have more information on this topic? 
 http://wiki.cocoondev.org

Geoff

Re: Nested input module support in sitemap

[Geoff Howard]

Tony Collen wrote:

Upayavira wrote:

Guys,

Is anyone interested in nested input module support in the sitemap? I 
want to be able to say: 
Of course, this would allow something like this:

{urlencode:{request-param:foo}}

Which I think people have been clamoring for for a while ;)
Yup.  Very good.

What should I do with this new code? Swap out the 
PreparedVariableResolver, replacing it with my code? Add a new version 
to run alongside for a while???
Hmm, it's been too long since I've been diving into internals... would 
it be possible to have to configure the PreparedVariableResolver in 
cocoon.xconf, which would allow us to choose between nestable and 
un-nestable resolvers?  Or is this too much configurability? :)
Unless there is an imaginable time where a user who does not want to have neted 
behavior happen has to use such a form in their sitemap (which I can't imagine 
currently) then I see no need for the configuration.

Geoff

Re: Nested input module support in sitemap

[Geoff Howard]

Nicola Ken Barozzi wrote:

Upayavira wrote:

Guys,

Is anyone interested in nested input module support in the sitemap? 


I am (as a user :-)
Me too (though I didn't understand the example below).

I want to be able to say:

{i18n:{1}.{locale}.xml} and have my i18n input module go and look to 
see if the related file exists. [NB. There's subtleties I haven't 
thought through yet in this example - but I'm not worrying about those 
for now - just working on the nested functionality first]

The current parser in the PreparedVariableResolver doesn't handle 
nesting, but I've got a design that has worked on paper, which I'm now 
coding up to handle everything that the existing 
PreparedVariableResolver does.

What should I do with this new code? Swap out the 
PreparedVariableResolver, replacing it with my code? Add a new version 
to run alongside for a while???
I'd put the new code in, as it should be backward compatible. MHO
I agree.

Geoff

Re: What can I do?

[Geoff Howard]

Tim Larson wrote:

On Thu, Mar 25, 2004 at 08:52:21AM -0500, Brian McCallister wrote:

Hi all, been hanging out a long time and am now using Cocoon in 
production for a few apps, and cannot imagine going back to ye olde 
way.


Welcome.


What can I do to help out? (ie -- any pointers on what needs doing and 
no one has stepped up to plate for).


Create a development/live toggle for Cocoon:
  http://marc.theaimsgroup.com/?t=10534775751&r=1&w=2
Of course a lot of what was missing from Xpatch during that thread has since 
been added (see wiki). The xpatch now has if and unless ant-style properties 
which react on either an ant property or a node's existence in the target file, 
as well as property-expansion.

What is still missing and would be helpful (and pretty dead easy I think) would 
be to allow build-time switching user build properties and blocks properties. 
I.e., instead of always using local.blocks.properties, allow something like 
-Dproperties.prefix=live which would cause the build to use 
live.blocks.properties instead.  Actually, that's probably a two liner in 
init-build.xml

Geoff

Re: cvs commit: cocoon-2.1/tools/src blocks-build.xsl

[Geoff Howard]

Joerg Heinicke wrote:
On 23.03.2004 20:23, [EMAIL PROTECTED] wrote:

stephan 2004/03/23 11:23:07

  Modified:tools/src blocks-build.xsl
  Log:
  Allow to share codebase to other blocks.


   
  +
  +
   
 
   


This was the reason for the common classpath, wasn't it? I wanted to 
have a look on it after having reverted the common classpath, but I 
guess that's no longer needed. Thanks for it. BTW, which block depends 
on other block's samples?
Not sure if this is what you mean, but there are some interdependencies between 
block samples involving (I think) database, hsql, eventcache, jms, and maybe 
repository.  No block depends outright on samples, but samples do depend on 
other blocks where the dependency disappears without the samples.  I would 
prefer to see some conditional build steps to allow "soft" dependencies for 
samples and even optional pieces of code.  IOW, some bits are included if the 
dependency is met, otherwise not.

Geoff

Re: [RT] On building on stone

[Geoff Howard]

Sylvain Wallez wrote:

Stefano Mazzocchi wrote:

Fire at will: I have my abstesto underwear on.
 >
Put it off: it doesn't help to get code written (see point 6)!
Please, Stefano - *do not* under any circumstances (despite Sylvain's 
suggestion) take your underwear off while coding.  :)

Geoff

Re: [RT] On building on stone

[Geoff Howard]

Stefano Mazzocchi wrote:
I want Cocoon to last long and to be able to stand the pressure of a big 
user community, a diverse development community and that of companies 
built on top of it.
...

This leads to a rather difficult choice:

 1) avoid implementing real blocks
 2) change our foundation framework
I would go for #2, since I consider real blocks vital for the evolution 
of this project.

Now, if we go #2 there are three choices:

 1) patch avalon
 2) change framework
 3) do our own
Here my choice would not be technologically driven but rather socially 
driven: I would do our own.

Why? because Avalon's communities are not healthy. The turnover rate is 
incredily high and the burn-out period is amazingly short. Its simply 
too fragile to build cocoon on something like this.
I'd add a parallel reason which may also be understood by people who may be less 
convinced about the health of that community or its importance (alas, I am no 
longer one).  We cannot trust this core to a separate entity who have many other 
needs to consider in parallel.  Why?  We have specific needs, and need them 
quick.  Also, we've found in practice that our container needs don't always have 
a lot of overlap with others' needs.  We are far simpler in some ways, more 
complicated in others.  If in some hypothetical future scenario others share a 
good deal of our needs, we can decide at that time if we should enable others to 
use our core by packaging separately - but I would be surprised if we ever would 
a) want this core managed elsewhere, or b) want to have to answer to users with 
different needs totally unrelated to Cocoon.

Fire at will: I have my abstesto underwear on.
Hopefully you will not need it.  Your proposal needs to be tested by fire, but 
not you - let's get that out here early.  Personally, knowing that there is 
already some "code on disk" makes this seem very attainable.  If it means we 
have blocks sooner than later, I am 100% behind it.

Geoff

Re: cvs commit: cocoon-2.1/tools/targets webapp-build.xml

[Geoff Howard]

Carsten Ziegeler wrote:

Geoff Howard wrote:

 

Exactly.  Although I didn't quite understand the bit about 
adding a loglevel property for build.webapp.loglevel - it 
already is a property isn't it?  
   

Yes, but with a long and not so intuitiv name. That's why I
suggested the shorter form.
 

Ah, I see.

And that's the benefit of 
property expansion over filtering
--  you don't have to define the filter tokens and can 
therefore work with arbitrary properties (even ad hoc user 
defined ones).
   

Yes, absolutely. Sorry for the confusion, I will correct this right
now.
 

No, no problem - this was obviously a pretty hidden feature!  I'll make 
a better note on the wiki.  I don't remember who actually implemented it 
(I think it was Unico?) but someone may want to check my wiki edits to 
make sure they're accurate.

Geoff

Re: cvs commit: cocoon-2.1/tools/targets webapp-build.xml

[Geoff Howard]

Upayavira wrote:

Carsten Ziegeler wrote:

Geoff Howard
 

Knowing that properties are already replaced, do you see a purpose 
for this still?

  
Yes, filtering :) Just use a @loglevel@ in a patch file for the 
logging configuration, and without the patch it doesn't work.
Now, if I understand it correctly now (I have to sort out the
difference between filtering and properties), this only affects
the following values:
   
   
   
   
   
   
   
The only really meaningful is loglevel.

Do I understand you correctly that if I would write
${build.webapp.loglevel} in my patch file instead @loglevel@, it would
work? If so, we could simply add a loglevel property with the
value from ${build.webapp.loglevel} and switch from @loglevel@
to ${loglevel} and remove my changes. That would be great and we
all are happy then :)
 

AFAICS, this should work. The only place where we would need these 
filters is when we're working with non-XML files.


Exactly.  Although I didn't quite understand the bit about adding a 
loglevel property for build.webapp.loglevel - it already is a property 
isn't it?  And that's the benefit of property expansion over filtering 
--  you don't have to define the filter tokens and can therefore work 
with arbitrary properties (even ad hoc user defined ones).

Geoff

Re: cvs commit: cocoon-2.1/tools/targets webapp-build.xml

[Geoff Howard]

Carsten Ziegeler wrote:

Joerg Heinicke wrote:
 

Geoff Howard wrote:

   

 Modified:.status.xml
  tools/targets webapp-build.xml
 Log:

  Build System: Apply filtering to patched 
   

configurations coming 
   

from the different blocks (loglevel etc.)

   

Was this necessary?  We already have property substitution 
 

working - 
   

is filtering also necessary?  It seems to create extra 
 

overhead (all 
   

those new copies).
 

Ok, this feature has been requested by users (bug 27217) and if you
use properties in the configuration of the blocks (like loglevel,
see below) then these values are not replaced which is imho very
bad. So I fixed this and yes this requires copying/filtering four
files which might add another second to the ten minutes build time :)
 

Properties are replaced - check out 
src/blocks/slide/conf/slide-target.xlog for example: it uses 
${context-root}.  I think either the bug author did not realize this 
feature exists, or when the feature was added (a few months ago?) we did 
not know the bug existed.

On the copying - I didn't look carefully and assumed the filtering 
happened to each patch file, not the final targets.  Still, these seem 
like completely overlapping (and therefore confusing) features - am I 
misunderstanding?

Now, I thought this property expansion was added to the wiki docs about 
xpatch but can't now find it.  Once we decide what to do about this I'll 
make sure to fix them.

Anyway, if you (or someone else) thinks that this isn't necessary
then I can revert it and we will close the bug with "wontfix".
 

Knowing that properties are already replaced, do you see a purpose for 
this still?

Geoff

Re: cvs commit: cocoon-2.1/tools/targets webapp-build.xml

[Geoff Howard]

[EMAIL PROTECTED] wrote:
cziegeler2004/03/15 10:11:25

  Modified:.status.xml
   tools/targets webapp-build.xml
  Log:
 
   Build System: Apply filtering to patched configurations coming from the different blocks (loglevel etc.)

 
Was this necessary?  We already have property substitution working - is 
filtering also necessary?  It seems to create extra overhead (all those 
new copies).

Geoff

Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)

[Geoff Howard]

Torsten Curdt wrote:

Isn't this missing the whole point of the current licensing 
discussion?  If we cook up a system that allows us to create and 
distribute cocoon but that product now cannot be used to build a 
commercial application without questions of further license 
requirements (source code availability, etc.) have we served our 
users well?


That's exactly the problem I have with this library system. Isn't 
Apache stuff that common because of its ease of use? I don't want to 
do license checking for every dependent project I get from somewhere. 
Moving this to the users is just a poor move and should be avoided if 
possible. It's not just about downloading one more JAR.


Well, AFAIU they will only run into the same legal hassle if
they try to *redistribute* cocoon as a whole!! So no problem
for the simple user.


Is a company using Cocoon to deliver web applications redistributing 
Cocoon? (yes, I think).  Then from what I can tell, a good portion of 
even our own committers, not to mention people on the users list would 
have a problem.

If it's really a problem for the ones distributing is still
the question anyway (I doubt it) But this way it's not the
ASF that would have to take the responsibility for that.
I guess that's the point


Yes, that's the point indeed.  ASL is supposed to be a business-friendly 
license.  If Cocoon uses distribution-time tricks to technically comply 
with the ASL but in the process nullifies its intent for some users, we 
have failed IMO.

Geoff

Re: XSP block status

[Geoff Howard]

Unico Hommes wrote:

Stephan Michels wrote:

Am Mi, den 10.03.2004 schrieb Unico Hommes um 19:24:
 

There remain a few issues that need resolving.

- InputModuleAction had to move along with xsp because it has a 
dependency on some xsp helper class. This is unfortunate and maybe 
unnecessary. Perhaps someone with more knowledge about this class 
could take a look and see if they can solve this?

- Source samples. Some use xsp's. Move these to xsp block or remove 
them altogether?
  


I'm in favour of removing them. But I can't decide that.
 

Me too. I don't think there remains an appropriate place to move them. 
What do others think?

- I18n samples. Needs volunteer.

- simpleform samples. Needs volunteer.
  


Only the first example use XSPs.

 

- session-fw patches are executed before xsp patches but depend on 
them. Move xsp specific stuff from session-fw to xsp.
  


I think this stuff, can stay where it is. The patch mechanism should
now work properly.
 

Nice one! Thanks.

- some blocks have dependencies on xsp. These need to be declared.
  


I think the rest comes the paradigm shift to flow+jx early or later.
 

I was thinking more in the way that some blocks won't work when xsp is 
not included. For instance eventcache comes to mind. I'll see what 
more dependencies I can find.


some block _samples_ won't work is of course what you mean.

What we really need is the concept of optional dependencies.  Examples:
- during the eventcache build, the xsp samples should be copied over if 
it's optional xsp dependency is present.
- during the jms build, the xsp and database caching examples should be 
created if both those optional dependencies are present.

I have been wondering if ant 1.6 gives us some new options for these 
blocks builds which make this more possible.  for example, I think the 
new import facility would allow us to import generic block build tasks 
into the block's own (usually non-present) build.xml, avoid generating 
the blocks build via xsl, and easily add arbitrarily complex 
sub-dependencies.  Does that spark any ideas?

Geoff