[German] Cocoon Live Site at Deutsche Börse

[Matthew Langham]

It is unfortunately not that often a Cocoon portal peeks out over the
firewall. This solution at Deutsche Börse (German stock exchange) was built
to showcase the new XML format for balance sheets XBRL:
http://xbrl.deutsche-boerse.com. It is built using the Cocoon portal.

Matthew

Competence Center Open Source
-
S&N AG  Tel.: +49-5251/1581-30
netBank solutions   Fax : +49-5251/1581-71
Klingenderstr. 5
D-33100 Paderborn   http://www.s-und-n.de
-

Re: WebSVN

[Joerg Heinicke]

On 14.10.2004 00:44, David Crossley wrote:
IIRC this has been fixed some weeks/months ago. At least the current versions of
the 2.1 branch and the trunk are correct, aren't they?
http://svn.apache.org/repos/asf/cocoon/trunk/build.sh
http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/build.sh
OT: Is there a WebSVN including the version information as we had it 
with WebCVS? I.e. not just like above, but as at 
http://svn.apache.org/viewcvs.cgi/cocoon-2.1/build.sh

Yes. Start here http://svn.apache.org/viewcvs.cgi/
and note the "Project Root" option at top-left.
http://svn.apache.org/viewcvs.cgi/cocoon/?root=Apache-SVN
Thanks David and Vadim. I was that near ... ;-)
Joerg

Re: WebSVN (was: DO NOT REPLY [Bug 31639] - Cocoon build.sh is not Bourse shell compatible)

[David Crossley]

Joerg Heinicke wrote:
> bugzillawrote:
> 
> > IIRC this has been fixed some weeks/months ago. At least the current versions of
> > the 2.1 branch and the trunk are correct, aren't they?
> > http://svn.apache.org/repos/asf/cocoon/trunk/build.sh
> > http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/build.sh
> 
> OT: Is there a WebSVN including the version information as we had it 
> with WebCVS? I.e. not just like above, but as at 
> http://svn.apache.org/viewcvs.cgi/cocoon-2.1/build.sh

Yes. Start here http://svn.apache.org/viewcvs.cgi/
and note the "Project Root" option at top-left.
http://svn.apache.org/viewcvs.cgi/cocoon/?root=Apache-SVN

-- 
David Crossley

Re: [RT] Some notes about the "Real Blocks" issue

[Vadim Gritsenko]

Ugo Cei wrote:
Folks,
here are some notes I jotted down today while on the train and later on 
the plane, on my way back home from the GT, on the issues we discussed 
Monday WRT "Real Blocks", Butterfly, Kernel (Tani), Spring, blah blah blah
Thanks for the summary. Can you extend on this one point:
- [ ] Two kinds of blocks: Avalon (legacy) and Spring as
  containers
  We need to support Spring (or Picocontainer,
  HiveMind or something of our own doing) and
  Avalon (for backward compatibilty) ONLY. ONE new
  type of container will be supported, otherwise
  it's just FS.

In particular,
 * Why new type of container is needed;
   (I suppose: because some things are broken)
 * What's broken in ECM;
 * Why it can't be fixed in Fortress;
 * Why Avalon compatibility can't be achived with new
   container (so that you need second one in parallel).
Thanks,
Vadim

Re: WebSVN

[Vadim Gritsenko]

Joerg Heinicke wrote:
On 13.10.2004 23:24, [EMAIL PROTECTED] wrote:
IIRC this has been fixed some weeks/months ago. At least the current 
versions of
the 2.1 branch and the trunk are correct, aren't they?
http://svn.apache.org/repos/asf/cocoon/trunk/build.sh
http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/build.sh

OT: Is there a WebSVN including the version information as we had it 
with WebCVS? I.e. not just like above, but as at 
http://svn.apache.org/viewcvs.cgi/cocoon-2.1/build.sh
Here it is...
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/build.sh?root=Apache-SVN
Vadim

Re: Cocoon Sample with Soap

[Joerg Heinicke]

On 13.10.2004 08:31, [EMAIL PROTECTED] wrote:
i am new in using Cocoon and have to implement an application in using
Cocoon and Soap (get data - an xml file - from a web servcie).
Now i am looking for a full example (sitemap, xsp, etc.) herefor to learn
more in usining cocoon.
Welcome, Dirk.
Can anyone give me a link, or send an example to my email about this
thema? I have had a look-around but couldn't find a full sample.
Please try it on the Cocoon users list first, the chance of getting an 
answer there on that topic should be higher than on this list as this 
list is about the development *of* Cocoon not developing *with* Cocoon.

Joerg

DO NOT REPLY [Bug 31640] - [PATCH] JavaClassWidgetListenerBuilder add LifeCycle

[bugzilla]

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

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

[PATCH] JavaClassWidgetListenerBuilder add LifeCycle

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|[PATCH ]|[PATCH]
   |JavaClassWidgetListenerBuild|JavaClassWidgetListenerBuild
   |er add LifeCycle|er add LifeCycle

DO NOT REPLY [Bug 28730] - Environment stack has not been cleaned up properly.

[bugzilla]

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

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

Environment stack has not been cleaned up properly.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

DO NOT REPLY [Bug 28939] - Comment from cli.xconf produces misleading error

[bugzilla]

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

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

Comment  from cli.xconf produces misleading error

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

DO NOT REPLY [Bug 31637] - MountTableMatcher does not work with generated mount-table

[bugzilla]

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

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

MountTableMatcher does not work with generated mount-table

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

DO NOT REPLY [Bug 15316] - FOP does not resolve relative paths

[bugzilla]

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

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

FOP does not resolve relative paths





--- Additional Comments From [EMAIL PROTECTED]  2004-10-13 21:41 ---
Hello Alfred,

as promised I had a look on the patch. It's a very specific one in that way,
that it solves the problem exactly for only one issue (fo:external-graphic) -
though there might not be more at the moment. On the other hand it fixes only
the FileSource's. As you wrote in the TODO comment it does not work for cocoon:/
and I also think it does not work inside WARs.

I talked to some people before eating spare ribs and we decided (nothing
official of course) to reject the patch. If someone wants to use it, he can get
it from here, but not from the official dist. For a real fix we depend on FOP of
course, but maybe sometime it will happen ...

Claas Thiele had the idea to use the JDK resolving (registering a source
resolver for Cocoon resources). On the one hand it's "another" source resolving
than the Excalibur way, on the other hand it's global. The next step by using a
"local" classloader does not work because of security reasons (re-loading classes).

Joerg

WebSVN (was: DO NOT REPLY [Bug 31639] - Cocoon build.sh is not Bourse shell compatible)

[Joerg Heinicke]

On 13.10.2004 23:24, [EMAIL PROTECTED] wrote:
IIRC this has been fixed some weeks/months ago. At least the current versions of
the 2.1 branch and the trunk are correct, aren't they?
http://svn.apache.org/repos/asf/cocoon/trunk/build.sh
http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/build.sh
OT: Is there a WebSVN including the version information as we had it 
with WebCVS? I.e. not just like above, but as at 
http://svn.apache.org/viewcvs.cgi/cocoon-2.1/build.sh

Joerg

DO NOT REPLY [Bug 31639] - Cocoon build.sh is not Bourse shell compatible

[bugzilla]

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

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

Cocoon build.sh is not Bourse shell compatible

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-10-13 21:24 ---
IIRC this has been fixed some weeks/months ago. At least the current versions of
the 2.1 branch and the trunk are correct, aren't they?
http://svn.apache.org/repos/asf/cocoon/trunk/build.sh
http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/build.sh

Please close the bug.

Jörg

DO NOT REPLY [Bug 31634] - [Patch] SQL Transformer attribute namespaces wrong

[bugzilla]

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

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

[Patch] SQL Transformer attribute namespaces wrong

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|SQL Transformer attribute   |[Patch] SQL Transformer
   |namespaces wrong|attribute namespaces wrong

DO NOT REPLY [Bug 25312] - Clean up forms (woody) samples

[bugzilla]

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

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

Clean up forms (woody) samples

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC|[EMAIL PROTECTED]   |
 AssignedTo|[EMAIL PROTECTED]   |[EMAIL PROTECTED]

Re: [RT] Some notes about the "Real Blocks" issue

[Sylvain Wallez]

Ugo Cei wrote:
Folks,
here are some notes I jotted down today while on the train and later 
on the plane, on my way back home from the GT, on the issues we 
discussed Monday WRT "Real Blocks", Butterfly, Kernel (Tani), Spring, 
blah blah blah

Take it as just an outline to fill with your 
opinions/suggestions/critiques. As soon as it starts coalescing into 
something sensible, we should put it on the Wiki.

Damn, I also prepared a RT on this subject while in the plane this 
evening, in a different style. It would be interesting to split its 
content in the different items of our plan. I won't be much available 
until next wednesday, so here it is...

The original subject is "[RT] Towards a POJO-based Cocoon"
There was a panel discussion during the GT hackaton to finally decide 
what we want the kernel and the Cocoon component model to be.

The starting consensus that drives all the rest is that we no more want 
to explicitely depend on a container API. Avalon was the state of the 
art 4 years ago, but things have changed a lot since then both 
technically with the emergence of dependency injection (DI) and socially 
with the problems that led to the death of the Avalon community. This 
consensus means that, in order to be future-proof, both blocks and 
components inside blocks must be POJOs (plain old java objects) hosted 
by a container providing dependency injection. That is the only way that 
will allow components to resist a major change in the container used, 
should it happen again.

There are two levels in containment in Cocoon, corresponding to 
different needs:

- the kernel, which is the root container that hosts blocks: it must 
provide classloader shielding of the blocks contents, wiring of blocks 
through DI and managing static factories (jaxp/trax/commons logging 
etc). Thats basically all. We decided to abandon, at least for now, the 
idea of hot deployment of blocks which is a complicated problem when 
inter-block wirings have to be updated. In case of change in the 
deployment, a global reload will be performed similarily to what is done 
today with the "cocoon-reload" request parameter.

- the container for components within a block (aka "intra-block 
container"): this is where pipeline components will live, along with 
business-logic components. There is no need for classloader shielding 
here, but the need for more J2EE-oriented features like transaction 
management, datasource pooling etc.

For the intra-block container, a good candidate exists today, which is 
quickly becoming a defacto standard because it deserves it: the Spring 
framework. It's more than a container, as it provide a great lot of 
interesting features (as POJOs) helping to quickly develop robust and 
efficient business logic.

For the kernel container, there is no such defacto standard, and adding 
classloader-shielding to Spring is overkill as we only need a very small 
amount of its features. The kernel must be small, efficient and 
rock-solid. Some partial solutions exist today: Pier's Tani which 
provides classloader shielding but not dependency injection, and 
PicoContainer that provides dependency injection but not classloader 
shielding. We have to choose an existing base and augment it to suit our 
needs.

Something that has to be taken into account is the existing component 
base: over the years, a number of people have invested in proprietary 
components based on the Avalon APIs. We cannot tell them to trash their 
stuff and rewrite it to use the new Cocoon. So we need some kind of 
legacy support for the Avalon framework APIs so that only minimal update 
is necessary to existing code or even no update at all. Fortunately, 
Spring may allow us to provide this legacy support, through its 
BeanFactory mechanism. A BeanFactory in Spring is responsible for 
creating a component upon request of the container. How this object is 
created is only a concern of the factory. So we could have an 
AvalonBeanFactory that would allow to host Avalon components within a 
Spring container, going through the lifecycle interfaces when a 
component is created and providing a wrapper showing the Spring 
container as a ServiceManager.

Something that has to be decided is if we're to make a revolution or a 
big evolution. IMO, this should be an evolution. The installed base is 
too large to allow use to have something completely different just 
because we want to change component handling. The ServiceManager wrapper 
on top on Spring may be the way to allow the revolution in the core to 
appear like an evolution to the upper-level code, thus allowing a smooth 
transition.

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

Re: GT2004 was brilliant

[Ugo Cei]

Il giorno 13/ott/04, alle 12:24, Arje Cahn ha scritto:
One big thanks to everyone involved in organizing another brilliant 
G(h)e(n)tTogether.
http://beblogging.com/blog/2004/10/13/203331
Ugo
--
Ugo Cei - http://beblogging.com/


smime.p7s
Description: S/MIME cryptographic signature

Re: Daisy as CMS: why don't use JDO?

[Ugo Cei]

Il giorno 13/ott/04, alle 19:22, Luca Garulli ha scritto:
This is the point. Using JDO allow you to switch the JDO
implementation and obviously repository without lock to a product!!!
Isn't enought?
I don't speak about product preference. I'm talking of STANDARD. JDO
is a STANDARD.
If this were true, everyone would be using JDO exclusively by now. JDBC 
is as much a standard as JDO and SQL even more so.

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


smime.p7s
Description: S/MIME cryptographic signature

Re: GT2004 was brilliant

[Matthew Langham]

One big thanks to everyone involved in organizing another brilliant 
G(h)e(n)tTogether.

A big thanks to Steven and the rest of OT for putting on a GT that just 
keeps getting bigger and better each year.

I would like to just briefly remind people of the fact that bringing 
130 people from 17 different countries together in a room to talk 
peacefully about a subject they love is really a feat in today's age. 
It's what makes this community so special.

Matthew

Re: GT2004 was brilliant

[Pier Fumagalli]

On 13 Oct 2004, at 11:24, Arje Cahn wrote:
Apart for the headache yesterdaymorning ([EMAIL PROTECTED] you English), I hope to 
do it all over again next year, hopefully in Ghent again!
Hey, I'm not "British" :-P But still gave you quite some hard time down 
the pub!

Pier (unable to recover)


smime.p7s
Description: S/MIME cryptographic signature

Re: Daisy as CMS: why don't use JDO?

[Stefano Mazzocchi]

Luca Garulli wrote:
I don't speak about product preference. I'm talking of STANDARD. JDO
is a STANDARD.
Oh, yes, standards are wonderful: there are so many to chose from
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Daisy as CMS: why don't use JDO?

[Luca Garulli]

On Wed, 13 Oct 2004 16:11:21 +0200, Steven Noels
<[EMAIL PROTECTED]> wrote:
> On 13 Oct 2004, at 15:17, Ugo Cei wrote:
>
> ... and that's what Daisy query statements eventually get translated
> into: straight SQL-statements and JDBC calls. The Document object model
> might somehow fit into something an O/R tool could map between objects
> and tables, but we wanted to provide an easy, SQL-like query language
> for searches. And in order to be able to tune execution performance of
> the query language, we figured we'd have to do our own mapping as well,
> if only so that we know which performance issues we might encounter,
> and how we should optimize the database scheme in that respect.

Ok, what I'm trying to say is that using JDO you don't worry so much
about persistence theme, optimization, support of N database, etc.

> Don't be too scared about MySQL dependency of Daisy, BTW:
> 
> "Daisy doesn't really depend on any special MySQL features (though a
> database with transaction support and row-level locking is required),
> but it simply wasn't a priority for us to support other databases as
> well."

Ok, but consider the use of JDO for all the aspects of the persistence.

Just my 0,02 â ;-)

-- 
bye,
Luca Garulli
OrienTechnologies.com
(the light ODBMS, all in one JDO solution)

Re: Daisy as CMS: why don't use JDO?

[Luca Garulli]

On Wed, 13 Oct 2004 15:17:37 +0200, Ugo Cei <[EMAIL PROTECTED]> wrote:
> Il giorno 13/ott/04, alle 11:35, Luca Garulli ha scritto:
> 
> > Why don't use JDO for the persistence? JDO allows to Daisy to be
> > datastore independent. So you can run Daisy on top of an ODBMS or
> > RDBMS or again the file system.
> 
> Probably because everyone has his own likes and dislikes when it comes
> to accessing data stores, so while JDO might be fine with you, others 
> may prefer OJB, Hibernate, Cayenne, iBatis, straight JDBC or something
> entirely different. Even if you decided to adopt JDO, you would have to
> find a reasonably performant, stable, opensource implementation.

This is the point. Using JDO allow you to switch the JDO
implementation and obviously repository without lock to a product!!!
Isn't enought?

I don't speak about product preference. I'm talking of STANDARD. JDO
is a STANDARD.

> Preferably of JDO 2, since I wouldn't actually recommend any JDO 1
> implementation to anyone.

I know that JDO 2 has much more features than JDO 1, but better JDO 1
than a custom product or (another) custom-own implementation.

-- 
bye,
Luca Garulli
OrienTechnologies.com
(the light ODBMS, all in one JDO solution)

[RT] Some notes about the "Real Blocks" issue

[Ugo Cei]

Folks,
here are some notes I jotted down today while on the train and later on 
the plane, on my way back home from the GT, on the issues we discussed 
Monday WRT "Real Blocks", Butterfly, Kernel (Tani), Spring, blah blah 
blah

Take it as just an outline to fill with your 
opinions/suggestions/critiques. As soon as it starts coalescing into 
something sensible, we should put it on the Wiki.

My ideas on what should be used _inside_ blocks are rather clear, but I 
especially need input on the thing (should we call it Tani, Kernel, 
something else?) that is supposed to contain blocks, manage their 
dependencies, make it possible for components defined in one block to 
refer to components defined in another block, etc. What will it look 
like, in practice?

Here we go:
- [ ] GT2004 notes
- [ ] Two levels of containment
- [ ] Intra-block
  Defining components and wiring them together inside a
  single block can be done with a dependency-injection
  type of container. We can do a tentative
  implementation using Spring.
- [ ] Inter-block
  There should be a container for blocks which should
  provide block deployment, classloader isolation and
  of course the means by which components defined in
  one block can be wired to components defined in
  another block.
- [ ] Two kernels?
- [ ] Phase 1 kernel
- [ ] No downloading of blocks from repositories
- [ ] Blocks statically defined, no live deployment
- [ ] No hot swapping
- [ ] No versioning
- [ ] Might be used for development
- [ ] Two kinds of blocks: Avalon (legacy) and Spring as
  containers
  We need to support Spring (or Picocontainer,
  HiveMind or something of our own doing) and
  Avalon (for backward compatibilty) ONLY. ONE new
  type of container will be supported, otherwise
  it's just FS. This container should be
  non-invasive, so that we might reuse components
  if we, later on, decide to change the container's
  implementation.
- [ ] Phase 2 kernel
- [ ] Downloading of blocks from repositories
- [ ] Live deployment without restarting
- [ ] Hot swapping (maybe)
- [ ] Versioning (for sure)
- [ ] Might use something like GBeans from Geronimo
- [ ] Configuration
- [ ] The sitemap
  The sitemap will define pipelines and possibly blocks
  to be loaded at startup or, alternatively, parameters
  for connecting to a naming service that will locate
  remote blocks.
  Use standards where possible for the naming service,
  e.g. LDAP and/or JNDI.
- [ ] The block context specification
  The block context specification will define:
  1. components hosted inside this block and their
  dependencies a-la Spring
  2. Interfaces provided by this block to the external
  world (public contracts) [?]
- [ ] Everything goes inside blocks
  Even core components, like the FileGenerator. Cocoon's
  new core is made up only of a sitemap processor and block
  deployer.
  Q: should a specific environment implementation (e.g.
  servlet, cli) be its own block, so that applications that
  don't need it won't load the block?
  Q: could the flowscript interpreter be its own block?
- [ ] Geronimo/JMX?
  This thread:
  
http://thread.gmane.org/gmane.comp.java.springframework.devel/4910
  might provide some suggestions re the
  implementation of the kernel.
- [ ] Plan of action
- [ ] 1. Define some use cases
- [ ] 2. Write tests
- [ ] 3. Implement complete use cases in the simplest possible
  way
  Use a "Tracer Bullets" approach (see The Pragmatic
  Programmer, item #10).
- [ ] 4. Refactor mercilessly

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

smime.p7s
Description: S/MIME cryptographic signature

Re: GT2004 was brilliant

[Christian Haul]

Arje Cahn wrote:
Hi everyone,
One big thanks to everyone involved in organizing another brilliant G(h)e(n)tTogether.
I had great fun talking to everyone and hearing all about the latest Cocoon news, and 
I'm definitely looking forward to see you all next year. Diner was great, beers were 
great, the talks were great, well just about everything actually.. Apart for the 
headache yesterdaymorning ([EMAIL PROTECTED] you English), I hope to do it all over 
again next year, hopefully in Ghent again!
A big thank you to the great guys from Outerthought for organizing this marvelous 
event.
This has been my third time to a G[h]e[n]t Together, and I still enjoy each one more 
than the previous one.
Looking forward to the next opportunity to meet my old and new friends.
	Chris.

Re: [VOTE] Keep Commons Validator (was Re: svn commit: rev 54668 - cocoon/branches/BRANCH_2_1_X/lib)

[Ugo Cei]

Il giorno 13/ott/04, alle 11:18, Sylvain Wallez ha scritto:
So I go for option 1: rip what need and don't include this additional 
dependency.
Done.
Ugo
--
Ugo Cei - http://beblogging.com/


smime.p7s
Description: S/MIME cryptographic signature

RE: Acessing request within a avalon component?

[Bart Molenkamp]

Yes:

You'll have to implement
org.apache.avalon.framework.context.Contextualizable.

Then implement the contextualize() method:

/* (non-Javadoc)
 * @see ...
 */
public void contextualize(Context context) throws ContextException {
this.context = context;
}

Then you can do:
Request request = ContextHelper.getRequest(context);

HTH,
Bart.
> -Original Message-
> From: Stephan Coboos [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 13, 2004 3:28 PM
> To: [EMAIL PROTECTED]
> Subject: Acessing request within a avalon component?
> 
> Hello,
> 
> is it possible to access the current request within a avalon component
> without passing it as parameter?
> 
> Thank you!
> 
> Regards
> Stephan

Re: continuations and session

[Leszek Gawron]

I would go for the first solution, as it avoid creating a new background 
thread for each new session, which as you state may severly impact 
server load. To achieve this, what comes to mind is having a per-session 
object holding the top-level continuations of a session (and thus, 
indirectly, the continuation trees), have this object implement 
HttpSessionBindingListener, and register it for monitoring by the 
expiration thread.

Sylvain
I have posted a patch at http://issues.apache.org/bugzilla/show_bug.cgi?id=31676
could you please review that?
--
Leszek Gawron  [EMAIL PROTECTED]

RE: Request: uncomment and change enabled in cocoon.xconf

[H . vanderLinden]

Ok, this seems to be what I need, but I cannot find info on the syntax? What
I need the patch file to do is:

if-exist "./debugger" then
   unless "/debugger/text()='enabled'" replace-with "enabled"
else
   insert ""

I have the unless part, but that only works if the  tag exists.


Thanks.

Bye, Helma

> -Original Message-
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, 13 October, 2004 15:35
> To: [EMAIL PROTECTED]
> Subject: Re: Request: uncomment and change 
> enabled in coc oon.xconf
> 
> 
> [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. :-(
> 
> You can just change your patch task to append  tag 
> if it's not 
> present. No need to remove comment.
> 
> Vadim
> 

Re: Daisy as CMS: why don't use JDO?

[Steven Noels]

On 13 Oct 2004, at 15:17, Ugo Cei wrote:
Il giorno 13/ott/04, alle 11:35, Luca Garulli ha scritto:
Why don't use JDO for the persistence? JDO allows to Daisy to be
datastore independent. So you can run Daisy on top of an ODBMS or
RDBMS or again the file system.
Probably because everyone has his own likes and dislikes when it comes 
to accessing data stores, so while JDO might be fine with you, others 
may prefer OJB, Hibernate, Cayenne, iBatis, straight JDBC
  ^
... and that's what Daisy query statements eventually get translated 
into: straight SQL-statements and JDBC calls. The Document object model 
might somehow fit into something an O/R tool could map between objects 
and tables, but we wanted to provide an easy, SQL-like query language 
for searches. And in order to be able to tune execution performance of 
the query language, we figured we'd have to do our own mapping as well, 
if only so that we know which performance issues we might encounter, 
and how we should optimize the database scheme in that respect.

Don't be too scared about MySQL dependency of Daisy, BTW:
"Daisy doesn't really depend on any special MySQL features (though a 
database with transaction support and row-level locking is required), 
but it simply wasn't a priority for us to support other databases as 
well."

(http://new.cocoondev.org/daisy/13)
HTH,

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

CForms Transformer plans...

[Tim Larson]

I plan to modify the forms transformer to match the builder/widget
compiled model like the form model and bindings currently use.
This will allow caching of compiled templates, and allow for
more (possibly optional) complex template analysis during the
build/compile stage, such as finding missing "required" widgets.

Perhaps this would also be a good time to re-evaluate the separation
of concerns between the form model and the template concerning the
choice of which widgets to display on any particular page.
Right now the form model controls this, because widgets not present
in the template get reset to null.  If we had compiled templates,
then there would be a place to record which widgets were sent and
thus which widgets would need to process their request parameters.
Still thinking about how this would interact with "stateless" forms.

We also want to be able to use xmlhttprequest to process updates to
individual widgets and sets of widgets, as well as to update various
markup or styling.  This implies that the "view" implementation for
cforms needs to be able to process restricted collections of widgets
and markup and have an xml format for communicating these updates
to the client.  We have a good start toward this because our cforms
templates are already structured to process widget by widget, but
using these templates is very slow for interactive update of small
parts of a page via xmlhttprequest, putting us at a significant
disadvantage compared with more primitive client-side js solutions...

What if we modify the forms transformer as described above and make
it more a general transformation engine that can perform work similar
to an xslt processor?  Then we could feed it a pipeline of transforms
to process and it could do global optimization to the pipeline during
its build/compile stage.  A sample optimization would be replacing
transforms like A->B->C->D->E with A->E, allowing more clear, modular
transform steps to be created by the programmer, while still allowing
the "compiled" system to run very efficiently.  Another optimization
would be detecting what information later transformation steps need
and automatically registering listeners/counters/aggregators to
earlier transformation steps to record this info to prevent having to
do whole-DOM searches like the current xsl stylesheets perform.

WDYT?
--Tim Larson

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]
>

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

[Vadim Gritsenko]

[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. :-(
You can just change your patch task to append  tag if it's not 
present. No need to remove comment.

Vadim

Acessing request within a avalon component?

[Stephan Coboos]

Hello,
is it possible to access the current request within a avalon component 
without passing it as parameter?

Thank you!
Regards
Stephan

Re: Daisy as CMS: why don't use JDO?

[Ugo Cei]

Il giorno 13/ott/04, alle 11:35, Luca Garulli ha scritto:
Why don't use JDO for the persistence? JDO allows to Daisy to be
datastore independent. So you can run Daisy on top of an ODBMS or
RDBMS or again the file system.
Probably because everyone has his own likes and dislikes when it comes 
to accessing data stores, so while JDO might be fine with you, others 
may prefer OJB, Hibernate, Cayenne, iBatis, straight JDBC or something 
entirely different. Even if you decided to adopt JDO, you would have to 
find a reasonably performant, stable, opensource implementation. 
Preferably of JDO 2, since I wouldn't actually recommend any JDO 1 
implementation to anyone.

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


smime.p7s
Description: S/MIME cryptographic signature

[GUMP][PATCH] excalibur-event has been split

[Stefan Bodewig]

into excalibur-event-api and excalibur-event-impl.

I don't know whether you need the implementation - my guess is you
will at runtime.  Anyway, I've just changed the dependency to -api.

Cheers

Stefan
Index: gump.xml
===
--- gump.xml(revision 54740)
+++ gump.xml(working copy)
@@ -60,7 +60,7 @@
 
 
 
-
+
 
 

Request: uncomment and change enabled in coc oon.xconf

[H . vanderLinden]

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] 

Re: The Cocoon Handbook - info on Log4J requested

[Bertrand Delacretaz]

Hi Helma,
could someone either tell me how to make Cocoon use Log4J rather than 
the
Avalon LogKit ...
Not sure if this is complete, you might want to check it:
a) add this to web.xml

logger-class
LOG4J

b) add log4j.jar in WEB-INF/lib if needed
c) create WEB-INF/classes/log4j.properties to setup logging.
Another useful logging trick is to use log4j for the output of ant as 
well, by setting these options on the ant command line:

  -listener org.apache.tools.ant.listener.Log4jListener
  -Dlog4j.configuration=file:/path-to-log4j-config
This is very useful for crazy folk like me who start their production 
systems via ant ;-)

Hope this helps
-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

Re: GT2004 was brilliant

[Bertrand Delacretaz]

...One big thanks to everyone involved in organizing another brilliant 
G(h)e(n)tTogether.
Big +1, thanks to everybody, in particular the flawless-as-ever 
organizing team!

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

The Cocoon Handbook - info on Log4J requested

[H . vanderLinden]

Guys (and gals),

could someone either tell me how to make Cocoon use Log4J rather than the
Avalon LogKit or point to URLs where it is already explained? I think it
would be great material for the Cocoon215TOC.

Thanks.

Bye, Helma

RE: GT2004 was brilliant

[H . vanderLinden]

Hear hear!! (Apart from the headache which _I_ didn't have :-))

Bye, Helma

> -Original Message-
> From: Arje Cahn [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, 13 October, 2004 12:24
> To: [EMAIL PROTECTED]
> Subject: GT2004 was brilliant
> 
> 
> Hi everyone,
> 
> One big thanks to everyone involved in organizing another 
> brilliant G(h)e(n)tTogether. I had great fun talking to 
> everyone and hearing all about the latest Cocoon news, and 
> I'm definitely looking forward to see you all next year. 
> Diner was great, beers were great, the talks were great, well 
> just about everything actually.. Apart for the headache 
> yesterdaymorning ([EMAIL PROTECTED] you English), I hope to do it all over 
> again next year, hopefully in Ghent again!
> 
> Thanks!
> 

GT2004 was brilliant

[Arje Cahn]

Hi everyone,

One big thanks to everyone involved in organizing another brilliant G(h)e(n)tTogether.
I had great fun talking to everyone and hearing all about the latest Cocoon news, and 
I'm definitely looking forward to see you all next year. Diner was great, beers were 
great, the talks were great, well just about everything actually.. Apart for the 
headache yesterdaymorning ([EMAIL PROTECTED] you English), I hope to do it all over 
again next year, hopefully in Ghent again!

Thanks!



Kind regards,

Arjé Cahn

Hippo  

Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel  +31 (0)20 5224466
-
[EMAIL PROTECTED] / www.hippo.nl
--

Daisy as CMS: why don't use JDO?

[Luca Garulli]

Hi,
I give a look to the Daisy project (http://new.cocoondev.org/daisy/2)
presented these days to the GetTogheter event.

It seems much interesting, but as repository uses RDBMS. Currently
only MySQL and InnoDB are supported as db.

Why don't use JDO for the persistence? JDO allows to Daisy to be
datastore independent. So you can run Daisy on top of an ODBMS or
RDBMS or again the file system.
Furthermore JDO support caching to achieve the best performance.

I think JDO can give much more flexibility (and performance) to Daisy.

What do you think?

bye,
Luca Garulli
OrienTechnologies.com
(the light ODBMS, all in one JDO solution)

Re: [VOTE] Keep Commons Validator (was Re: svn commit: rev 54668 - cocoon/branches/BRANCH_2_1_X/lib)

[Sylvain Wallez]

Ugo Cei wrote:
Il giorno 12/ott/04, alle 14:33, [EMAIL PROTECTED] ha scritto:
set correct commons-validator-1.1.3.jar path (did the guy who's on 
stage now mess up? ;-)

You bet! But the error slipped by because I had to disable jars 
validation because of another library that had broken it just a few 
minutes before ;-)

Anyway, while we're at it, some people *rightfully* pointed out that I 
shouldn't have added just another dependency only to validate email 
addresses in CForms. Well, for one thing, at least email addresses 
validate correctly now, which wasn't the case before. Besides, 
Commons-validator might be useful elsewhere and it's just 84k. And I 
was so nice as to write a handful of testcases for it, so should 
Validator break in a future release, we could be able to catch it early.

On the other hand, I do share those guys' concern over dependencies, 
so I'd like to ask for the developers' opinions before deciding 
whether to keep or to remove it. As I see it, we have two options:

1. [ ] Rip the necessary code from Commons validator and drop it into 
the email validation rule of CForms (shouldn't be more than a few 
lines of code, hopefully).
2. [ ] Keep it on the assumption that we will use it for something else.
3. [ ] Anything else?

At first, integrating Commons Validator looks appealing as it may avoid 
us to write and maintain our own validators, with the added benefit that 
it provides some client-side JS validation.

Now let's look closer at what we can really reuse.
Out of 19 Java classes, only 4 can actually be used in Cocoon: 
CreditCard, Email, ISBN and URL validators. The Field and Form stuff is 
useless, just as the type-oriented validations (int, date, etc) since 
CForms is strongly typed.

I checked the client-side JS which strangely doesn't provide a 
counterpart to all Java classes. Furthermore, the JS mixes actual 
validation logic and user feedback, which uses an alert, meaning we 
can't use the JS files to e.g. add the notification mark besides the 
invalid widgets as we currently do.

So I go for option 1: rip what need and don't include this additional 
dependency.

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

Calling SitemapSource.getInputStream() more than once throws SourceException

[Bart Molenkamp]

Hi all,

I've noticed that it's not possible to call the getInputStream() on
instances of SitemapSource classes can only be called once. Calling it a
second time throws an exception. 

Is that correct behaviour, or is that a bug? If this is a bug, maybe
there are two solutions which I can implement if needed:
1. Cache the input stream in SitemapSource.getInputStream(). First call
will get the input stream data, further calls will simply return the
cached data.
2. Rewrite the SourceDataSource.getInputStream(). Upon every call
resolving the source, then callling the sources getInputStream().

In my use-case, I use pipelines to generate the body for email messages.
I resolve the source, and create a new
org.apache.cocoon.mail.datasource.SourceDataSource instance and pass the
source to it. When sending, it looks like the JavaMail api calls the
getInputStream() more than once.

Thanks,
Bart.