On Mar, 12 de Abril de 2005, 0:59, Reinhard Poetz dijo:
Geoff Howard wrote:
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.
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
Stefano Mazzocchi wrote:
So, my proposal is to keep the above semantics, but differentiate
between 'real' and 'virtual' pipeline components, with the existance of
the src= attribute. If missing, the tree processor will consider it a
virtual one and construct it from there.
I like this.
Could we
Le 12 avr. 05, à 08:33, Reinhard Poetz a écrit :
...
--
[cocoon block] [DIR]
+-- COB-INF [DIR]
+-- cob.xml
+-- classes [DIR]
+-- lib [DIR]
--
+1, sounds
Sylvain Wallez wrote:
Hi all,
I was reading http://wiki.apache.org/cocoon/CocoonPerformanceResults and
the nice graphics that were attached to this page on the cocoondev wiki
seem to have been lost.
Upayavira, our slashdotted infrastructure guy, any hint on how to have
them back? :-)
Our
It seems there is a bug that affects jxtg scripts that use jx:import
--
Leszek Gawron MobileBox
[EMAIL PROTECTED] http://www.mobilebox.pl
On 11 Apr 2005, at 15:50, Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Ok, I had some remembrance that we had decided to have a particular
directory structure on the COBs, but I couldn't find any
documentation on that, do you have any link or example?
no. But AFAIK there aren't many rules.
Pier Fumagalli wrote:
--
[cocoon block] [DIR]
|
+-- BLOCK-INF [DIR]
+-- block.xml
+-- classes [DIR]
+-- lib [DIR]
--
WDYT?
Again, to sound stupid, but why in
Leszek Gawron wrote:
It seems there is a bug that affects jxtg scripts that use jx:import
sh** I thought I cancelled that. Should go to drafts.
Never mind. You can reproduce the bug like this:
?xml version=1.0 encoding=UTF-8?
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
map:views
Stefano Mazzocchi [EMAIL PROTECTED] wrote on 11.04.2005 17:57:54:
Upayavira wrote:
FWIW, stefano's -1 was for dynamic sitemaps, not for a context
attribute
to map:mount.
correct.
--
Stefano.
So do I enter the context patch into bugzilla now?
Regards,
Jochen
On Mar, 12 de Abril de 2005, 5:23, Jochen Kuhnle dijo:
Stefano Mazzocchi [EMAIL PROTECTED] wrote on 11.04.2005 17:57:54:
Upayavira wrote:
FWIW, stefano's -1 was for dynamic sitemaps, not for a context
attribute
to map:mount.
correct.
--
Stefano.
So do I enter the context patch into
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Sorry, not much time to dig into the implementation for now, but I
will :-)
Good :)
In order to have a better opinion on the naming issue (virtual-blah /
special src=... / no src) I started digging in the implementation.
VPCs aren't an easy
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. ;-)
On Mar, 12 de Abril de 2005, 7:17, Geoff Howard dijo:
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
Pier Fumagalli wrote:
On 11 Apr 2005, at 15:50, Reinhard Poetz wrote:
[cocoon block] [DIR]
|
+-- BLOCK-INF [DIR]
+-- block.xml
+-- classes [DIR]
+-- lib [DIR]
Again, to sound stupid, but why in the world a cocoon block would
contain classes and libraries? Those should be
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Sorry, not much time to dig into the implementation for now, but I
will :-)
Good :)
In order to have a better opinion on the naming issue (virtual-blah /
special src=... / no src) I started digging in the implementation.
VPCs
Sylvain Wallez wrote:
What we see here is that VPCs aren't regular components from the way
their configuration is parsed. This configuration isn't parsed by the
component itself, but by the surrounding environment which is the
TreeProcessor.
This can be changed so that VPC create own instance
On Apr 11, 2005 5:44 PM, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
I mean, look at you: sitemap via webdav? via JCR170? what's next? SOAP?
what about describing the sitemap in LDAP directly, you could use
netinfo to edit it! hmmm, no, wait, what about sitemap via email? you
post the sitemap
Reinhard Poetz wrote:
Thanks Geoff and Vadim
as we already had a vote, we should respect the result and have
following intra-block file-system structure:
--
[cocoon block] [DIR]
|
+-- COB-INF [DIR]
+-- block.xml
+--
Ralph Goers wrote:
Reinhard Poetz wrote:
Thanks Geoff and Vadim
as we already had a vote, we should respect the result and have
following intra-block file-system structure:
--
[cocoon block] [DIR]
|
+-- COB-INF [DIR]
+--
Reinhard Poetz wrote:
Ralph Goers wrote:
Reinhard Poetz wrote:
Thanks Geoff and Vadim
as we already had a vote, we should respect the result and have
following intra-block file-system structure:
--
[cocoon block] [DIR]
|
+-- COB-INF
Reinhard Poetz wrote:
Ralph Goers wrote:
Question. What else is in a block that requires that COB-INF exist at
all? Why can't it just be:
[cocoon block] [DIR]
+--block.xml
+--classes [DIR]
+--lib [DIR]
Ralph
IMO its as usefull/useless as WEB-INF for web archives.
Presumably the case for
On Apr 12, 2005 5:50 AM, Sylvain Wallez [EMAIL PROTECTED] wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
big snip/
So in the end, my opinion is that sitemap fragments for VPCs should be
declared in their own section of the sitemap, just as views, resources
and flows. Components
Peter Hunsberger wrote:
On Apr 12, 2005 5:50 AM, Sylvain Wallez [EMAIL PROTECTED] wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
big snip/
So in the end, my opinion is that sitemap fragments for VPCs should be
declared in their own section of the sitemap, just as views,
Is it me or do others have the same problem that no log messages of the category
sitemap reach the logger output? (core and access works for me)
I have the same problem with the latest trunk and with a version that is about 2
weeks old. A very recent 2.1.X checkout works fine for me ...
--
Daniel Fagerstrom wrote:
So I don't see this so much as an implementation question as a
conceptual question. Are we considering the VPCs as sitemap components
or something else, to me they look like sitemap components.
Conceptually, I think VPCs are components first and foremost. So they are
On Apr 12, 2005 9:05 AM, Daniel Fagerstrom [EMAIL PROTECTED] wrote:
Peter Hunsberger wrote:
On Apr 12, 2005 5:50 AM, Sylvain Wallez [EMAIL PROTECTED] wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
big snip/
So in the end, my opinion is that sitemap fragments
Daniel Fagerstrom wrote:
...
So I don't see this so much as an implementation question as a
conceptual question. Are we considering the VPCs as sitemap components
or something else, to me they look like sitemap components.
To me, a VPC is a better _resource_: IMHO it should be on the same level.
Peter Hunsberger wrote:
On Apr 12, 2005 9:05 AM, Daniel Fagerstrom [EMAIL PROTECTED] wrote:
snip/
I don't see that there is any harm in separating VPC's into a new
section, but I do see a lot of possible good in the long run.
Might be. But as long as I haven't seen any concrete use cases I
Pier Fumagalli wrote:
On 11 Apr 2005, at 15:50, Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Ok, I had some remembrance that we had decided to have a particular
directory structure on the COBs, but I couldn't find any
documentation on that, do you have any link or example?
no. But AFAIK there
Geoff Howard wrote:
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.
Ralph Goers wrote:
Reinhard Poetz wrote:
Thanks Geoff and Vadim
as we already had a vote, we should respect the result and have
following intra-block file-system structure:
--
[cocoon block] [DIR]
|
+-- COB-INF [DIR]
+--
[EMAIL PROTECTED] wrote:
} catch (ProcessingException e) {
+// Log the original exception
+getLogger().error(Failed to process error handler for
exception, e);
throw e;
I think we had an agreement against mile-long log files. Why log
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
} catch (ProcessingException e) {
+// Log the original exception
+getLogger().error(Failed to process error handler
for exception, e);
throw e;
I think we had an agreement against
While we're talnking about exceptions, what about NOT logging a
stacktrace whenever no sitemap match is found? With the current
behavior, we get a stacktrace, for example, everytime a browser
requests /favicon.ico, which happens quite frequently. Can't we just
log a one-line message?
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
So I don't see this so much as an implementation question as a
conceptual question. Are we considering the VPCs as sitemap
components or something else, to me they look like sitemap components.
Conceptually, I think VPCs are components first and
Daniel Fagerstrom wrote:
Peter Hunsberger wrote:
On Apr 12, 2005 9:05 AM, Daniel Fagerstrom [EMAIL PROTECTED] wrote:
snip/
I don't see that there is any harm in separating VPC's into a new
section, but I do see a lot of possible good in the long run.
Might be. But as long as I haven't seen
Ugo Cei wrote:
While we're talnking about exceptions, what about NOT logging a
stacktrace whenever no sitemap match is found? With the current
behavior, we get a stacktrace, for example, everytime a browser
requests /favicon.ico, which happens quite frequently. Can't we just
log a one-line
Amen, i have been known to put a matcher in my sitemaps for this, just
to get rid of it. A one-liner suffices.
I had a quick glance at the code in PipelineNode.java where this
exception is thrown but i'm not sure at which level the code can be
modified without disturbing the flow of events.
I
Gianugo Rabellino wrote:
On Apr 11, 2005 5:44 PM, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
I mean, look at you: sitemap via webdav? via JCR170? what's next? SOAP?
what about describing the sitemap in LDAP directly, you could use
netinfo to edit it! hmmm, no, wait, what about sitemap via email?
Ugo Cei wrote:
While we're talnking about exceptions, what about NOT logging a
stacktrace whenever no sitemap match is found? With the current
behavior, we get a stacktrace, for example, everytime a browser requests
/favicon.ico, which happens quite frequently. Can't we just log a
one-line
Hi,
I may have something to suggest concernig the new documentation effort.
The main problem that I had to face while begining to work with Cocoon
was the enormous gap between the level of the first tutorials I found
on the wiki or other sources like theserverside.com or IBM
DeveloperWorks. I
Le 13 avr. 05, à 00:09, Sylvain Wallez a écrit :
...2 - rank each solution from 1 to 4, and choose the one with the
highest sum. Seems good except that it allows people to rank several
choices equally..
I also like this way, but if two solutions come out very close we might
want to rediscuss
Sebastien Arbogast wrote:
snip/
Moreover this documentation could be written and reviewed in parallel
and tight collaboration with the new Cocoon 2.2 documentation effort
to make sure that the information is accurate and exact and to keep
stuff in sync. And it could be written and
44 matches
Mail list logo
