Re: Vote for Cocoon on the O'Reilly Open source Directory.
On Wed, 27 Aug 2003, Geoff Howard wrote: Robert Simmons wrote: Go vote http://www.osdir.com/Downloads-req-ratedownload-lid-11-ttitle-Cocoon.html Hmmm - the description is taken from the 2.0 site, and no wonder -- the link is to http://xml.apache.org/cocoon -- http://cocoon.apache.org/2.0/ Who can fix that redirect now that 2.1 is released? And anyone know if we can fix the blurb at osdir.com? IIRC, Matthew knows the guy behing osdir.com quite well. /Steven
RE: transformer developer
On Wed, 27 Aug 2003, arnaud daneels wrote: hello, thanks for your advice, i don't understand how the input and output pipe is generated at once and are not affected by each other... can you tell me more please I don't understand your question. Which input/output pipeline? Thanks -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Giacomo Pati Envoyé : mardi 26 août 2003 20:44 À : Cocoon-Dev (E-mail) Objet : Re: transformer developer On Tue, 26 Aug 2003, arnaud daneels wrote: hello, i can't find how to develop transformer with this method: - i would like to begin to analyse SAX events from the input pipeline - without terminate this analyse i would like to put in the output pipeline new events - i don't want to use DOM builder but only SAX events have you explanations or samples for resolving this problem ? I think we have plenty of Transformer sample code in the repository (LDAPTransformer, SQLTransformer). Aren't they doing exactly what you're looking for? -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/pipeline/impl CachingPointProcessingPipeline.java
cziegeler2003/08/27 23:09:29
Modified:src/java/org/apache/cocoon/components/pipeline/impl
CachingPointProcessingPipeline.java
Log:
Code formatting
Revision ChangesPath
1.4 +25 -25
cocoon-2.1/src/java/org/apache/cocoon/components/pipeline/impl/CachingPointProcessingPipeline.java
Index: CachingPointProcessingPipeline.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/pipeline/impl/CachingPointProcessingPipeline.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- CachingPointProcessingPipeline.java 7 Aug 2003 08:52:15 - 1.3
+++ CachingPointProcessingPipeline.java 28 Aug 2003 06:09:29 - 1.4
@@ -219,18 +219,18 @@
((CachingOutputStream)os).getContent());
this.cache.store(this.toCacheKey.copy(),
response);
-//
-// Scan back along the pipelineCacheKey for
-// for any cachepoint(s)
-//
-this.toCacheKey.removeUntilCachePoint();
-
-//
-// adjust the validities object
-// to reflect the new length of the pipeline cache key.
-//
-// REVISIT: Is it enough to simply reduce the length of the validities
array?
-//
+//
+// Scan back along the pipelineCacheKey for
+// for any cachepoint(s)
+//
+this.toCacheKey.removeUntilCachePoint();
+
+//
+// adjust the validities object
+// to reflect the new length of the pipeline cache key.
+//
+// REVISIT: Is it enough to simply reduce the length of the
validities array?
+//
if (this.toCacheKey.size()0) {
SourceValidity[] copy = new
SourceValidity[this.toCacheKey.size()];
System.arraycopy(this.toCacheSourceValidities, 0,
@@ -316,8 +316,8 @@
while ( itt.hasNext() ) {
next = (XMLConsumer) itt.next();
-// if we have cacheable transformers,
-// check the tranformers for cachepoints
+// if we have cacheable transformers,
+// check the tranformers for cachepoints
if (cacheableTransformerCount 0) {
if ( (this.isCachePoint.get(currentTransformerIndex) !=
null)
((Boolean)this.isCachePoint.get(currentTransformerIndex)).booleanValue()) {
@@ -330,8 +330,8 @@
}
-// Serializer is not cacheable,
-// but we have the longest cacheable key. Do default longest key
caching
+// Serializer is not cacheable,
+// but we have the longest cacheable key. Do default
longest key caching
if (localXMLSerializer != null) {
if (cacheableTransformerCount == 0) {
next = new XMLTeePipe(next, localXMLSerializer);
@@ -349,15 +349,15 @@
next = super.lastConsumer;
-// if the serializer is not cacheable, but all the transformers are:
-// (this is default longest key caching)
+// if the serializer is not cacheable, but all the transformers
are:
+// (this is default longest key caching)
if (localXMLSerializer != null) {
next = new XMLTeePipe(next, localXMLSerializer);
this.xmlSerializerArray.add(localXMLSerializer);
localXMLSerializer = null;
}
-// else if the serializer is cacheable and has cocoon views
+// else if the serializer is cacheable and has cocoon views
else if ((currentTransformerIndex ==
this.firstNotCacheableTransformerIndex)
this.nextIsCachePoint) {
cachePointXMLSerializer =
((XMLSerializer)this.manager.lookup( XMLSerializer.ROLE ));
@@ -381,8 +381,8 @@
if (cacheableTransformerCount =
this.firstProcessedTransformerIndex) {
-// if we have cacheable transformers left,
-// then check the tranformers for cachepoints
+// if we have cacheable transformers left,
+// then check the tranformers for cachepoints
if (cacheableTransformerCount
Releasing 2.1.1?
Hi, as several of you have already pointed out, a 2.1.1 release seems to make sense. I can make a release next week, but I really would like to have the scheduling (CommandManager) problem fixed in the release. Is anyone working already on it? Thanks Carsten
RE: lastModificationDate misuse? - old thread - progress
John Williams wrote: Joerg Heinicke wrote Bug was fixed some days ago: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14348. Carsten requested for testers of the patch, so if you can test the behaviour with the current Cocoon 2.0 CVS it will be good. If XSP is the result of a pipeline then the ServerPages Generator can't work out its currency and randomly re-generates and compiles. To make I have inspected the code of 2.0.4 and it is still there, ie code is same as when reported in 2001. Surely a typical use of cocoon is to build XSP using XSLT? I have tested (with cocoon-2.0_20030812221701) and believe the problem has only been partially solved. Instead of the prior situation where the .java .class were re-generated from XSP on a random basis - they now are always regenerated. This is at least consistent - but very wasteful on resources latency in requests. I have investigated the source and found that the test as to whether or not regeneration takes place is: !currValidity.equals(prevValidity) Inspecting the contents of the currValidity and prevValidity Maps I find that they are equivalent excepting that the prevValidity contains an entry S-xml-1_=NOP Validity so the test fails and code is re-generated. Huh! That's strange, now as far as I remember the code, the prevValidity should not contain S-xml-1_=NOP Validity, as this is the validity for the serializer which is not used for internal pipeline calls. Hmm. So, I think we should investigate why this validity object is there instead of ignoring it later on. Carsten
Scheduler + Avalon Q's A's
Good morning Europe,
I've been digging into the Scheduler stuff in Cocoon, and I've been very
pleased.. it's a component I've been waiting for for a while now, and
it fits in very nicely with my main project I have going on.
I have very little experience creating Avalon components, so I thought
I'd run this past -dev, to see if I'm not too far off-base. But first,
a little background of what I have going on.
I'm using the Scheduler, and I have a Target which is triggered called
AggregatorTarget. What this Target does is whenever it's triggered, it
makes an HTTP request to a specified URL and downloads it.
The default way of having things run all the time is nice, and I've
noticed that the included DefaultScheduler has things to remove targets,
add targets, fire targets, etc. I'm mostly interested in pausing my
target from firing, even if it's fired and doesn't do anything based on
a flag.
Here's where my question about Avalon comes in, and how it would relate
to the Cocoon Scheduler. I was thinking about implementing Suspendable
in my AggregatorTarget, and including a suspended flag to check to see
if it should actually run or not. It would be very simple, suspend()
would set the suspended flag to true and resume() would set it to false.
Next comes the Target interface, which means targetTriggered(). This is
what I was thinking:
public void targetTriggered(String name) {
if (!suspended) {
// actually trigger
}
}
Is it this simple? Or should the DefaultScheduler or the ThreadManager
be in charge of determining whether a Target should be triggered?
Sorry for all the n00b questions :)
Regards,
Tony
RE: [RT] Starting 2.2
Hello. Is there anybody in there? Just nod if you can hear me. Is there anyone home? Carsten Ziegeler wrote: Pier Fumagalli wrote: On 13/8/03 16:37, Carsten Ziegeler [EMAIL PROTECTED] wrote: Ok, let's do simple steps perhaps: Do you think that we should start a new repository? This is equivalent to saying we start a new major version (2.2). (if the answer is yes, we can talk about the layout). YES! :-) As I have few [RT]s on my own! :-) :-) :-) Great! Combined with the recent RTs, does still someone feel that starting 2.2 is the right thing? Or are there still objections? Carsten
RE: Cocoon 2.1 Authentication Bug? *Please* Help
Hello Carsten, The authentication works very well and I can enter inside the portal. But inside the portal there are two functions: User Management and Portal Management. These functions use the portal-auth action and the portal-conf and auth-conf generators. The problem is that I can't access to these functions, the error is Cocoon couldn't find the resource requested. Before I changed the authentication pipeline and integrated a LDAP transformer these functions worked very well. How works the portal-auth action? Do the generators read a file (sunrise-user.xml) or another session parameters? Could you help me? Thanks Sylvain -Message d'origine- De: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Date: mercredi, 27. août 2003 16:57 À: [EMAIL PROTECTED] Objet: RE: Cocoon 2.1 Authentication Bug? *Please* Help From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Hi Carsten, I have also a problem with the authentication Administration. I can't access to the admin pages since I have added a LDAP transformer inside the authentication pipeline. Is it for the same reason? Hard to tell from from here, but it might be. The NPE could occur if the authentication pipeline does not produce valid xml or raises an exception. Carsten
cvs commit: cocoon-2.1/src/blocks/webdav/samples/dasl - New directory
gianugo 2003/08/28 01:09:17 cocoon-2.1/src/blocks/webdav/samples/dasl - New directory
Re: Releasing 2.1.1?
On Thu, 28 Aug 2003, Carsten Ziegeler wrote: Hi, as several of you have already pointed out, a 2.1.1 release seems to make sense. I can make a release next week, but I really would like to have the scheduling (CommandManager) problem fixed in the release. Is anyone working already on it? I've just made a standalone main app with the CommandManager and, confusing enought, it works correclty as expected. So, it must be the environment Cocoon runs in that causes troubles (Servlet?) -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
Re: Scheduler + Avalon Q's A's
On Thu, 28 Aug 2003, Tony Collen wrote: Is it this simple? Or should the DefaultScheduler or the ThreadManager be in charge of determining whether a Target should be triggered? To my knowledge, yes, it is the simplest solution :-) -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
Re: lastModificationDate misuse? - old thread - progress
Carsten Ziegeler wrote:
Inspecting the contents of the currValidity and prevValidity Maps I find
that they are equivalent excepting that the prevValidity contains an
entry
S-xml-1_=NOP Validity so the test fails and code is
re-generated.
Huh! That's strange, now as far as I remember the code, the prevValidity
should
not contain S-xml-1_=NOP Validity, as this is the validity for the
serializer
which is not used for internal pipeline calls. Hmm.
I assume you mean src=cocoon://foo calls and not internal-only pipelines,
ie one with internal-only=true.
I have a fairly deep pipeline underlying the generated XSP file from which
.java is generated. Maybe this depth exposes a problem in discarding
NOPCacheValidity for internal pipeline calls. Can you see from the following
which class is adding the S-xml-1_=NOP Validity, I will then have a poke
around/debug.
Below are some details of the case causing the problems:
create-categories.xsp - which has the S-xml-1_=NOP Validity in the
prevValidity is:
{
aggregation of {
aggregation of {tableDefs/categories.xml,
appDef/categories/UISpecifics.xml and appDef/terminologyMappings.xml}
transformed with stylesheets/buildUIStructure.xsl
and
appDef/categories/aCustomisation.xml
}
transformed with stylesheets/applyCustomisation.xsl
}
transformed with stylesheets/create.xsl
This is what validities look like: (equal besides the S-xml-1_=NOP
Validity)
prev: {G-file-7747944243312186483_=TimeStamp Validity[1062058603973],
T-xslt--3690387136403106359_=Aggregated Validity[TimeStamp
Validity[106198276]:TimeStamp Validity[1061976654000]], S-xml-1_=NOP
Validity}
curr: {G-file-7747944243312186483_=TimeStamp Validity[1062058603973],
T-xslt--3690387136403106359_=Aggregated Validity[TimeStamp
Validity[106198276]:TimeStamp Validity[1061976654000]]}
Relevant part of the sitemap is as follows:
map:match pattern=table-*_*.xml
map:aggregate element=root
map:part src=cocoon://crm/table-{1}.xml/
map:part src=appDef/{1}/{2}.xml strip-root=true/
/map:aggregate
map:transform src=stylesheets/applyCustomisation.xsl/
map:serialize type=xml/
/map:match
map:match pattern=table-*.xml
map:aggregate element=UIDef
map:part src=tableDefs/{1}.xml/
map:part src=appDef/{1}/UISpecifics.xml/
map:part src=appDef/terminologyMappings.xml/
/map:aggregate
map:transform src=stylesheets/buildUIStructure.xsl/
map:serialize type=xml/
/map:match
map:match pattern=*-*.xsp
map:generate src=cocoon://crm/table-{2}.xml/
map:transform src=stylesheets/{1}.xsl/
map:serialize type=xml/
/map:match
Re: [RT] Starting 2.2
Bertrand Delacretaz wrote: Le Jeudi, 28 aoû 2003, à 09:18 Europe/Zurich, Carsten Ziegeler a écrit : ...Great! Combined with the recent RTs, does still someone feel that starting 2.2 is the right thing? Or are there still objections?... I'm +1 on starting 2.2 given what's going on (or planned) with blocks, forms, etc. -Bertrand I think, as has been said before, we need to discuss _what_ it is that would require a new repository. So far, we've had a number of RTs, but to my knowledge, no one is working on implementing any of these yet, and no one is working on code that cannot be placed into the 2.1 repository without breaking interfaces (at least ones that aren't still alpha). I think we should consider the 2.2 repository _only_ when we've got a concrete proposal for code that _cannot_ be included in the 2.1 repository. Switching repositories last time was a pain. Switching to a 2.2 repository will also be a pain, and that pain has to be worth it, and at present I do not see any proposals being made (that is, people proposing to implement proposals) that actually require this 2.2 repository. Therefore, at present I think we should stick with 2.1, until concrete proposals emerge that make it worth the effort. Regards, Upayavira
Re: cvs commit: cocoon-2.1/src/blocks/webdav/samples/dasl sitemap.xmaptest-dasl.xml
Bertrand Delacretaz wrote: Le Jeudi, 28 aoû 2003, à 10:11 Europe/Zurich, [EMAIL PROTECTED] a écrit : A first cut at a DASL query component. Needs tweaking, but it's basically working. Just curious, which DASL-enabled server are you using? (I tested the DASL support in Slide a while ago but it was very slow, basically scanned the whole store). I'm using Catacomb ATM. It's pretty fast and reliable, with the only limitation of being MySQL only (but we might have a surprise out of the door pretty soon :-)). Also, today a wild idea came to my mind. Since DAV:basicsearch is just XML-ized SQL it should be pretty simple to XSL-transform it into a plain SQL query to run against a database. With a few Cocoon components, then, it might be pretty simple to have a poor man's DASL-enabled WebDAV server, augmenting the davmap example of Guido. Something to think about, but it could be as simple as match patternSEARCH generate type=stream/ transform src=DASL2SQLTransformer.xsl/ transform type=sql/ transform type=sql2propfind.xsl/ serialize type=xml status-code=207/ /match Something to think about on a cold winter night. :-) Next step might be having a query engine on top of InspectableSource(s), but I'm afraid that it would be dog slow. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
RE: Porting Cocoon Logging to Log4j - Proposal and Discussion
The Avalon Logging can be changed to use Log4J. Currently the usage of the LogKit is hard-coded in Cocoon. I added the possibility to configure which logging framework you want to use to the avalon core, but never had time to test it. If this is working, only minor changes have to be made to Cocoon (changing three or four lines of code) and you can use Log4j in Cocoon. Carsten -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Robert Simmons Sent: Thursday, August 28, 2003 11:32 AM To: [EMAIL PROTECTED] Subject: Porting Cocoon Logging to Log4j - Proposal and Discussion One of the major implementaiton complaints I have about Cocoon is its lack of Log4J logging functionality. Log4j, is without a doubt the best logging package for java. No other package can even hope to compare to it. If Cocoon was built to use Log4j instead of the avalon logging mechanism, it would gain an enormous amount of functionality that it lacks now. Personally, when working in a production environment, I dont want my log files to be put into direcroies in my web app. Id rather have them forwarded to a central log accumulation server or even sent out via JMS. Log4j allows this and many more configurations. Furthermore, it allows you to turn on and off logging on individual components with ease. Finally, Log4J is used in so many other products that it is a recognized standard logging mechanism that many organizations and even network engineers are quite familiar with. Therefore, I think Cocoon should migrate to Log4j. In order to contemplate this, its important that we discuss the complexities of it in the following quesitons. 1) Why has this not already been done? Is it a question of a lack of manpower or expertise? If so then I as well as others would most likely be happy to volunteer time to accomplish it. 2) How difficult is it to rip out the avalon logging from the cocoon core components? Im no avalon expert so I couldnt answer this myself. 3) Is there standard expressions that can be used for locatting logging lines in cocoon? 4) Do we upgrade some of the blocks or leave them as is and only upgrade core cocoon? I would be interested in comments and opinions. -- Robert
Re: cvs commit: cocoon-2.1/src/blocks/webdav/samples/dasl sitemap.xmap test-dasl.xml
Bertrand Delacretaz [EMAIL PROTECTED] wrote: Le Jeudi, 28 aoû 2003, à 10:11 Europe/Zurich, [EMAIL PROTECTED] a écrit : A first cut at a DASL query component. Needs tweaking, but it's basically working. Just curious, which DASL-enabled server are you using? (I tested the DASL support in Slide a while ago but it was very slow, basically scanned the whole store). Yes, Slide supports DASL queries. However there is no way to index them. Lucene integration is on their roadmap for more than 2 years now. Guido
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
Robert Simmons wrote: One of the major implementaiton complaints I have about Cocoon is its lack of Log4J logging functionality. Log4j, is without a doubt the best logging package for java. No other package can even hope to compare to it. If Cocoon was built to use Log4j instead of the avalon logging mechanism, it would gain an enormous amount of functionality that it lacks now. Log4J is already integrated into avalon logkit. I'm not a logkit expert, but I guess it would require very little (if any) work to have Cocoon logging to Log4J targets. Is the opposite true? :-) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: cvs commit: cocoon-2.1/src/blocks/webdav/samples/dasl sitemap.xmap test-dasl.xml
Gianugo Rabellino [EMAIL PROTECTED] wrote: Bertrand Delacretaz wrote: Le Jeudi, 28 aoû 2003, à 10:11 Europe/Zurich, [EMAIL PROTECTED] a écrit : A first cut at a DASL query component. Needs tweaking, but it's basically working. Just curious, which DASL-enabled server are you using? (I tested the DASL support in Slide a while ago but it was very slow, basically scanned the whole store). I'm using Catacomb ATM. It's pretty fast and reliable, with the only limitation of being MySQL only (but we might have a surprise out of the door pretty soon :-)). Also, today a wild idea came to my mind. Since DAV:basicsearch is just XML-ized SQL it should be pretty simple to XSL-transform it into a plain SQL query to run against a database. With a few Cocoon components, then, it might be pretty simple to have a poor man's DASL-enabled WebDAV server, augmenting the davmap example of Guido. Something to think about, but it could be as simple as match patternSEARCH generate type=stream/ transform src=DASL2SQLTransformer.xsl/ transform type=sql/ transform type=sql2propfind.xsl/ serialize type=xml status-code=207/ /match Something to think about on a cold winter night. :-) Next step might be having a query engine on top of InspectableSource(s), but I'm afraid that it would be dog slow. It doesn't necessarily has to be slow. You could have special property views that would be indexed by Lucene. Guido
Re: cvs commit: cocoon-2.1/src/blocks/webdav/samples/dasl sitemap.xmaptest-dasl.xml
Guido Casper wrote: A first cut at a DASL query component. Needs tweaking, but it's basically working. Wow, this is really cool! I immediately tried it (against Tamino WebDAV). Works great! :-) Thanks (I'll extend your congrats to Daniele, the guy from Pro-netics who did the actual DASL query thing). Unfortunately there is still a major issue to solve, and once again it's the SWCL to blame. DASL results are put into an HashMap, so that when you try to retrieve them all you get is completely unordered (making d:orderby useless). Unfortunately this is a behaviour of the abstract class above, which supersedes all the WebDAV methods. I'm thinking of a workaround (which will be pretty rough), but I want to solve the issue even on the Slide part. DASL without ordering is nearly useless. :-/ Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: EU Software Patents protest action
+1 I added a link from our user group web site. http://www.struts-atlanta.org/ We are a small group (currently 201 members on the mailing list), but I am happy to do my part. -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 770-822-3359 AIM:jmitchtx - Original Message - From: Steven Noels [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 9:11 AM Subject: EU Software Patents protest action Hi peeps, my colleagues are just back from the live demonstration in front of the EU offices. Several hundreds of people where effectively there, and while we will never know whether such actions have any effect, I was proud to be able to tell them that all ASF sites were participating with the online action. So whoever who made the necessary changes acting under the root account on minotaur: thanks! /Steven - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
Robert Simmons wrote: Actually, I was proposign the removal of the avalon logging mechanism completely. You'll have to provide a very good technical reason for that, much more than I like Log4J better or Log4J is cool. Consider that: 1. Avalon logkit can use Log4J as the backend enging while, to the best of my knowledge, the opposite is not true; 2. logging is tightly integrated inside the Avalon lifecycle, which is tied to logkit. Changing it to Log4J would be painful to say the least. But, in case there are very good reasons for it, I guess no Cocoon developer was ever married to logkit, and a better solution is always welcome. Let me be skeptical, though. :-) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
RE: Porting Cocoon Logging to Log4j - Proposal and Discussion
I for one would be -1 on this. Cocoon relies heavily on Avalon, it makes IMNSHO little sense when Avalon supports multiple logging mechanisms to rip it out and recode. J. Robert Simmons wrote: Actually, I was proposign the removal of the avalon logging mechanism completely. -- Robert Carsten Ziegeler [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] The Avalon Logging can be changed to use Log4J. Currently the usage of the LogKit is hard-coded in Cocoon. I added the possibility to configure which logging framework you want to use to the avalon core, but never had time to test it. If this is working, only minor changes have to be made to Cocoon (changing three or four lines of code) and you can use Log4j in Cocoon. Carsten -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Robert Simmons Sent: Thursday, August 28, 2003 11:32 AM To: [EMAIL PROTECTED] Subject: Porting Cocoon Logging to Log4j - Proposal and Discussion One of the major implementaiton complaints I have about Cocoon is its lack of Log4J logging functionality. Log4j, is without a doubt the best logging package for java. No other package can even hope to compare to it. If Cocoon was built to use Log4j instead of the avalon logging mechanism, it would gain an enormous amount of functionality that it lacks now. Personally, when working in a production environment, I dont want my log files to be put into direcroies in my web app. Id rather have them forwarded to a central log accumulation server or even sent out via JMS. Log4j allows this and many more configurations. Furthermore, it allows you to turn on and off logging on individual components with ease. Finally, Log4J is used in so many other products that it is a recognized standard logging mechanism that many organizations and even network engineers are quite familiar with. Therefore, I think Cocoon should migrate to Log4j. In order to contemplate this, its important that we discuss the complexities of it in the following quesitons. 1) Why has this not already been done? Is it a question of a lack of manpower or expertise? If so then I as well as others would most likely be happy to volunteer time to accomplish it. 2) How difficult is it to rip out the avalon logging from the cocoon core components? Im no avalon expert so I couldnt answer this myself. 3) Is there standard expressions that can be used for locatting logging lines in cocoon? 4) Do we upgrade some of the blocks or leave them as is and only upgrade core cocoon? I would be interested in comments and opinions. -- Robert == Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other binding commitment through the use of this electronic communication unless it is issued in accordance with the Experian Limited standard terms and conditions of purchase or other express written agreement between Experian Limited and the recipient Experian Limited (registration number 653331) Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
Re: cvs commit: cocoon-2.1/src/blocks/webdav/samples/dasl sitemap.xmap test-dasl.xml
Le Jeudi, 28 aoû 2003, à 11:34 Europe/Zurich, Gianugo Rabellino a écrit : ...I'm using Catacomb ATM. It's pretty fast and reliable, with the only limitation of being MySQL only (but we might have a surprise out of the door pretty soon :-)). Thanks for the info! match patternSEARCH generate type=stream/ transform src=DASL2SQLTransformer.xsl/ transform type=sql/ transform type=sql2propfind.xsl/ serialize type=xml status-code=207/ /match Wow - looks really interesting. Make sure you mark down these cool winter nights in your agenda ;-) -Bertrand
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
Gianugo Rabellino [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] Robert Simmons wrote: Actually, I was proposign the removal of the avalon logging mechanism completely. You'll have to provide a very good technical reason for that, much more than I like Log4J better or Log4J is cool. Consider that: How about the fact that multiple layers of logging exacerbate performance problems intrinsic to logging. Also how about the fact that Log4j is faster and far more powerful and flexible in production environments where you may want logging to go to a specific server. Also how about the fact that most other java products that log use log4j and very very few use avalon logging. This allows a support center to set up a logging monitor stations for system health monitoring. I think about the business applications of cocoon which are far different than the open source programming aspects. 1. Avalon logkit can use Log4J as the backend enging while, to the best of my knowledge, the opposite is not true; Then you have a multi-layer logging mechanism which is evil for performance reasons. 2. logging is tightly integrated inside the Avalon lifecycle, which is tied to logkit. Changing it to Log4J would be painful to say the least. This point I cant speak to. Personally I know so few products that use avalon that I wonder why cocoon hasnt gotten away from it but perhaps that isnt possible. *shrug* Avalon is as old as AWT and I think just as outdated. But, in case there are very good reasons for it, I guess no Cocoon developer was ever married to logkit, and a better solution is always welcome. Let me be skeptical, though. :-) Skeptical is good as long as it doesnt change into stubborness. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
Robert Simmons wrote: Actually, I was proposign the removal of the avalon logging mechanism completely. You'll have to provide a very good technical reason for that, much more than I like Log4J better or Log4J is cool. Consider that: How about the fact that multiple layers of logging exacerbate performance problems intrinsic to logging. Also how about the fact that Log4j is faster and far more powerful and flexible in production environments where you may want logging to go to a specific server. Also how about the fact that most other java products that log use log4j and very very few use avalon logging. All nice dandy, but I'd like to see some figures to prove your statements: what does faster actually mean? Are there any benchmarks around? So far the only problem you outlined was the multi-layer performance hit. Now, I can't speak for the actual Log4J avalon adapter performance, but: 1. are you sure that you can't achieve the same result with logkit? I'm succesfully logging to a remote server ATM using syslog, and I have no problems with it; 2. JMS logging and performance concerns are oxymorons. Multi layered logging would be a breeze compared to what it takes to build and send a JMS message; 3. A production Cocoon does not log much. If you raise the log level to WARN (or even INFO), you won't get so much logging to be concerned about performance. Since (almost) every log statament is wrapped if is*Enabled() methods, you will never hit the multilayer performance issue. I think about the business applications of cocoon which are far different than the open source programming aspects. Avalon is as old as AWT and I think just as outdated. These two statements are overly aggressive and somehow insulting. We do business with Cocoon, and most of us have experience with large sites and serious logging needs. Accusing the Cocoon and Avalon committers of being childish open source kiddies playing with their toy and not being innovative is not a good way to sell your point. welcome. Let me be skeptical, though. :-) Skeptical is good as long as it doesnt change into stubborness. Lets make a deal and avoid both stubborness and aggressive attitude then. I would suggest you to discuss the Log4J vs. Logkit implementation issues on the proper lists and come back here with more evidence. You might even convince the Avalon guys to switch to Logkit... Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
RE: Porting Cocoon Logging to Log4j - Proposal and Discussion
From: Robert Simmons Gianugo Rabellino [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] Robert Simmons wrote: Actually, I was proposign the removal of the avalon logging mechanism completely. You'll have to provide a very good technical reason for that, much more than I like Log4J better or Log4J is cool. Consider that: How about the fact that multiple layers of logging exacerbate performance problems intrinsic to logging. Also how about the fact that Log4j is faster Have you ever done some serious tests that you can claim this? and far more powerful and flexible in production environments where you may want logging to go to a specific server. Also how about the fact that most other java products that log use log4j and very very few use avalon logging. This allows a support center to set up a logging monitor stations for system health monitoring. I think about the business applications of cocoon which are far different than the open source programming aspects. 1. Avalon logkit can use Log4J as the backend enging while, to the best of my knowledge, the opposite is not true; Then you have a multi-layer logging mechanism which is evil for performance reasons. 2. logging is tightly integrated inside the Avalon lifecycle, which is tied to logkit. Changing it to Log4J would be painful to say the least. This point I cant speak to. Personally I know so few products that use avalon that I wonder why cocoon hasnt gotten away from it but perhaps that isnt possible. *shrug* Avalon is as old as AWT and I think just as outdated. could you please fill in: AWT : Avalon = Swing : ? Sorry, I can't take it very serious if someone says we should remove Avalon from Cocoon. This would be the same if I say you should completly rewrite a working Swing application in favour of SWT ... But, in case there are very good reasons for it, I guess no Cocoon developer was ever married to logkit, and a better solution is always welcome. Let me be skeptical, though. :-) Skeptical is good as long as it doesnt change into stubborness. You say it - I hope it was meant in both directions. Cheers, Reinhard
jxforms scratchpad big
hy , i download the CVS version i would just know if it's normal that the jxforms scratchpad is so big ( threre is inside the ant doc , ant src , avalon merlin doc , cocoon 2 historical lib, etc...)
Re: Cocoon CLI: excluding URIs
Upayavira wrote: ... 4) I just started thinking about your excludes code (assuming that link gathering does start working again). Basically, there's a number of things one can exclude upon - source URI, source prefix, full source URI (prefix and URI), final destination URI . How about something like: exclude type=regexp| wildcard src=source-uri | source-prefix | full-source-uri | dest-uri match=pattern/ include type=regexp| wildcard src=source-uri | source-prefix | full-source-uri | dest-uri match=pattern/ I'd be happy with a simple 'ignore this link', but wildcards would be great. I'm a bit confused by all the @src types though. Is 'dest-uri' the final filesystem destination? Is there anything possible with src=dest-uri that isn't possible otherwise? Does 'src-prefix' mean ignore URIs starting with this prefix? If so, why not just use a wildcard? The thing is, you might want to exclude a certain URL from going to one destination but not another, so you'd need to specify a wildcard on either source or destination. However, given that a wildcard can be used to deal with prefixes, we don't need to specifically worry about prefixes. So, I propose: exclude-source match=wildcard pattern/ exclude-destination match=wildcard pattern/ exclude-source match=wildcard pattern/ exclude-destination match=wildcard pattern/ I don't want to use exclude type=source ... as I wan to reserve the type attribute for specifying whether to use a wildcard or regexp matcher. Thoughts? I've got some basic code in place to do includes/excludes - I'll keep you posted. I've just run my code through, and it seems to have worked. I'll give it a bit more testing later today and commit it either this evening or tomorrow. It is very simple - I haven't yet implemented 'destination' excludes, and have only done wildcard excludes. And the matching happens with the 'absolute' url, i.e. including any source prefix. I've also implemented includes in the same way, but have not yet tested it. I've made it so that if both includes and excludes are present, a URL is first checked to see if it should be included, and then to see if it should be excluded. So you might say include pattern=subsite/**/ and exclude pattern=subsite/images/**/. I have tested the following, which generates the docs, but without any images. exclude pattern=**/images/**/ uri type=append src-prefix=docs/ src=index.html dest=build/dest/ / Regards, Upayavira
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
It is .. Ive been wrong before and I admit Im no Avalon or cocoon source code expert. Im very direct in my style and I wish people wouldnt take it offensively. I merely abhor cheerleading. There are lots of things I love about cocoon but the logging irritates me. *shrug* =^) Reinhard Poetz [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] From: Robert Simmons Gianugo Rabellino [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] Robert Simmons wrote: Actually, I was proposign the removal of the avalon logging mechanism completely. You'll have to provide a very good technical reason for that, much more than I like Log4J better or Log4J is cool. Consider that: How about the fact that multiple layers of logging exacerbate performance problems intrinsic to logging. Also how about the fact that Log4j is faster Have you ever done some serious tests that you can claim this? and far more powerful and flexible in production environments where you may want logging to go to a specific server. Also how about the fact that most other java products that log use log4j and very very few use avalon logging. This allows a support center to set up a logging monitor stations for system health monitoring. I think about the business applications of cocoon which are far different than the open source programming aspects. 1. Avalon logkit can use Log4J as the backend enging while, to the best of my knowledge, the opposite is not true; Then you have a multi-layer logging mechanism which is evil for performance reasons. 2. logging is tightly integrated inside the Avalon lifecycle, which is tied to logkit. Changing it to Log4J would be painful to say the least. This point I cant speak to. Personally I know so few products that use avalon that I wonder why cocoon hasnt gotten away from it but perhaps that isnt possible. *shrug* Avalon is as old as AWT and I think just as outdated. could you please fill in: AWT : Avalon = Swing : ? Sorry, I can't take it very serious if someone says we should remove Avalon from Cocoon. This would be the same if I say you should completly rewrite a working Swing application in favour of SWT ... But, in case there are very good reasons for it, I guess no Cocoon developer was ever married to logkit, and a better solution is always welcome. Let me be skeptical, though. :-) Skeptical is good as long as it doesnt change into stubborness. You say it - I hope it was meant in both directions. Cheers, Reinhard
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
Robert Simmons wrote: I wasnt accusing anyone of being childish. I wish you wouldnt put words in my mouth. I merely meant that the demands of a business environment are quite different then the demands of non-business environments. Please rest assured that many (probably most) of us know what the demands of business environments are. Many open source projects have yet to bridge this gulf and only a few have done it sucessfully (apache web server, ant, log4j, tomcat, jboss). For example, the decision to NOT distribute a binary build of cocoon is a good example of going in the opposite direction of business. Many business consultants are not interested in building source, but rather using the product as is. Oh, gosh... will not distributing a binary build be enough for us not to cross the bridge? Let's have a party on this side of the river with Linus then. Oh, and please tell me where you are going to find Gnome or KDE binary distributions (RPM, DEB and other linux distro packages don't count). And tell the FreeBSD guys that their port system is doomed. Anyway, here is your binary distribution: $ cat setup.sh ./build.sh war install.log 21 if [ $? == 0 ] then echo Installation successful, Cocoon war installed in `pwd`/build/cocoon.war else echo Installation failed, plese check install.log for details fi ^D Rant apart, you might have a point in blaming Cocoon of not being business friendly, and I'm starting to consider that there might be room for someone to come up and be Cocoon's RedHat, providing production builds and certified WARs, thus relieving the Cocoon community in these issues. Any Orixians listening? ;-)) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
On Thu, 28 Aug 2003, Robert Simmons wrote: It is .. Ive been wrong before and I admit Im no Avalon or cocoon source code expert. Im very direct in my style and I wish people wouldnt take it offensively. I merely abhor cheerleading. There are lots of things I love about cocoon but the logging irritates me. *shrug* =^) From someone who learned this himself the hard way: In an email conversation, don't expect your recipients to cope with 'your style' just because you have explained them you mean no harm, and you 'just happen to be direct'. I find it much more effective if you try and shape your style towards optimal reception by your recipients: not by easy excuses for your directness, but by showing _you_ are aware of this directness, and are willing to tone down in respect for your recipients. I'll now refrain from helping you in getting connected with this community, and I do hope you are able to flex your directness into a more positive style of communication. Don't expect us to feel honoured just by your presence. The fact you are coming back says all. With the best intentions, Cheers, /Steven
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
To be honest, the condescending attitude you display here doesnt help me feel warm and fuzzy all over. I can take criticism. Can you? But then I think I will drop this convewrsation as it likely doesnt belong in this list. -- Robert Steven Noels [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] On Thu, 28 Aug 2003, Robert Simmons wrote: It is .. Ive been wrong before and I admit Im no Avalon or cocoon source code expert. Im very direct in my style and I wish people wouldnt take it offensively. I merely abhor cheerleading. There are lots of things I love about cocoon but the logging irritates me. *shrug* =^) From someone who learned this himself the hard way: In an email conversation, don't expect your recipients to cope with 'your style' just because you have explained them you mean no harm, and you 'just happen to be direct'. I find it much more effective if you try and shape your style towards optimal reception by your recipients: not by easy excuses for your directness, but by showing _you_ are aware of this directness, and are willing to tone down in respect for your recipients. I'll now refrain from helping you in getting connected with this community, and I do hope you are able to flex your directness into a more positive style of communication. Don't expect us to feel honoured just by your presence. The fact you are coming back says all. With the best intentions, Cheers, /Steven
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
quoteI wasnt insulting anyone and i appologize if it sounded like that. /quote I noticed you failed to copy that block into your acerbic reply. I appologized once, I wont do it again. -- Robert Gianugo Rabellino [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] Robert Simmons wrote: I wasnt accusing anyone of being childish. I wish you wouldnt put words in my mouth. I merely meant that the demands of a business environment are quite different then the demands of non-business environments. Please rest assured that many (probably most) of us know what the demands of business environments are. Many open source projects have yet to bridge this gulf and only a few have done it sucessfully (apache web server, ant, log4j, tomcat, jboss). For example, the decision to NOT distribute a binary build of cocoon is a good example of going in the opposite direction of business. Many business consultants are not interested in building source, but rather using the product as is. Oh, gosh... will not distributing a binary build be enough for us not to cross the bridge? Let's have a party on this side of the river with Linus then. Oh, and please tell me where you are going to find Gnome or KDE binary distributions (RPM, DEB and other linux distro packages don't count). And tell the FreeBSD guys that their port system is doomed. Anyway, here is your binary distribution: $ cat setup.sh ./build.sh war install.log 21 if [ $? == 0 ] then echo Installation successful, Cocoon war installed in `pwd`/build/cocoon.war else echo Installation failed, plese check install.log for details fi ^D Rant apart, you might have a point in blaming Cocoon of not being business friendly, and I'm starting to consider that there might be room for someone to come up and be Cocoon's RedHat, providing production builds and certified WARs, thus relieving the Cocoon community in these issues. Any Orixians listening? ;-)) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: Blocks Manual
And am willing to contribute if I can do so in a manner that doesnt require months of learning before I can accomplish anything. I wonder if that means cocoon is too big that it scares off newbies. =) Happens to the best of them, JBoss, Apache Web Server, etc. Like I said before, I tend to be direct in my language and if I offend, I certainly dont mean to and I appologize. On-topic: that blocks manual would be cool. Im having a hard time figuring out what blocks I will need for my production build. -- Robert Steven Noels [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] On Wed, 27 Aug 2003, Robert Simmons wrote: Greetings, Is there a manual that describes all of what each block in cocoon 2.1 does ? Perhaps I missed it. Nope, it isn't there. Don't forget to have a look at http://cocoon.apache.org/2.1/plan/index.html, http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Cocoon+2short_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitorder=%27Importance%27, http://wiki.cocoondev.org/Wiki.jsp?page=RT as well, and http://cocoon.apache.org/community/contrib.html as a way to solve all this. It's good to have you back, Robert. While we ain't a bunch of academics, we still primarily scratch our own itches. We hope our users do as well, and this, together with some respect for the time all of us voluntarily contribute to the Cocoon project, is essentially what community-based open source development is all about. The 'strategy' behind shipping software with rough edges is two-fold: (1) Cocoon won't be finished until its community declares so, by no longer contributing to it, and (2) we like to see every user as a possible future contributor. We don't employ a professional helpdesk, since our users happen to help each other, and several devs are keen to help with major issues. All this is done in the best possible spirit, and I hope you can respect that. Your enquiries are meaningful, and many of them would merit being implemented, but it's not by simply stating them that they effectively will be resolved. The leaky abstraction in software communities is human beings doing the actual work. Cheers, /Steven
Re: [RT] Improving Sitemap and Flowscript
Nicola Ken Barozzi wrote: snip/ *IMPORTANT* (and the reason why I started the RT): So in he CLI, instead of asking for the link view and then generate, I simply ask Cocoon to insert a transformer that gathers links in the same positions where the links view would. This would make it possible for the CLI to have the configurability of the view gatherer but the speed of the transfomer gatherer. Links view is not a transformer. It's a view, meaning that it can have actions, matchers, selectors, transformers, and should end with text serializer. So, you cannot simply add one transformer and think that you are done with links view. In addition to this, adding a transformer would not work because this alters pipeline cache key which prevents such legitimate CLI usages as pre-populating persistent cache. Solution to the CLI problem was already found (attach links view as a tee to main pipeline, see Link View Goodness on approx 2003/07/01) and Upayavira is looking into ways of implementing it. I would help him out but right now I can't. Vadim
Re: Blocks Manual
Le Jeudi, 28 aoû 2003, à 13:45 Europe/Zurich, Robert Simmons a écrit : ...On-topic: that blocks manual would be cool. Im having a hard time figuring out what blocks I will need for my production build There were lots of discussion a while ago on the docs list regarding component reference pages, basically manpage-like reference docs on the various components (Blocks or not). The general idea was to have a reference page for each component, partly generated from the component's source code javadoc tags, augmented by xml or text-based narration. This hasn't happened yet as nobody really took the plunge, but anybody willing to help on this is welcome - in the meantime the qdox block allows javadoc-like tags to be processed by Cocoon when generating the docs. In the meantime, the best reference for the blocks are the samples, but you're right that a well-organized documentation would be better. -Bertrand
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
Gianugo Rabellino wrote: Robert Simmons wrote: snip/ Many open source projects have yet to bridge this gulf and only a few have done it sucessfully (apache web server, ant, log4j, tomcat, jboss). For example, the decision to NOT distribute a binary build of cocoon is a good example of going in the opposite direction of business. Many business consultants are not interested in building source, but rather using the product as is. Oh, gosh... will not distributing a binary build be enough for us not to cross the bridge? Let's have a party on this side of the river with Linus then. Oh, and please tell me where you are going to find Gnome or KDE binary distributions (RPM, DEB and other linux distro packages don't count). And tell the FreeBSD guys that their port system is doomed. Gianugo, I'm outraged! How could you forget to mention Gentoo???!!! LOL Vadim
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
Gianugo Rabellino said: Rant apart, you might have a point in blaming Cocoon of not being business friendly, and I'm starting to consider that there might be room for someone to come up and be Cocoon's RedHat, providing production builds and certified WARs, thus relieving the Cocoon community in these issues. Any Orixians listening? ;-)) YES, I couldn't agree more, and Forrest has kind of shown the way (although it could be a lot better). I foresee a future, where the Cocooners will be at the bedrock of the framework, and most people today using Cocoon will be using one out of a few Cocoon-based App Servers, each targetting different production environments, publishing, CMS, Wiki, eCommerce, process control and so on. Niclas
Re: Integratign a W3C XForms implementation into the Cocoon Project?
Robert Simmons wrote: Greetings, One thing that I would like to see is Cocoon supporting the XForms 1.0 standard as described on W3C. http://www.w3.org/MarkUp/Forms/ I would advise against the XForms standard because it is severely broken for client/server type applications. XForms ONLY makes sense in a pure client setting. -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
Robert Simmons wrote: Actually, I was proposign the removal of the avalon logging mechanism completely. -1000 If I want to use a NullLogger (no logging completely, and no need for a logging toolkit) then I should be able to. If I want to use Log4J I should be able to. And if I am happy with LogKit (which is smaller BTW), then why should I loose that ability? -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
Robert, putting aside the attitude discussion for a while and go back to the facts on the table; You would like to use Log4J in the production environment. GOOD! You want to re-write Cocoon to explicitly do the Log4J lookup of the Logger through the Logger static method. NOT SO GOOD, in my humble opinion. I have been convinced about the advantage of Inversion of Control that Avalon is strongly promoting. Provide the logger to the component is much more flexible, and some say more secure (of which I can't tell.) The Avalon approach, allows that a very slim Logger layer can be mapped on top of basically any logger backend, and the Avalon community provides a few, although I am not sure if it is fully supported in the older ECM (agree ancient Avalon container), but I think it is. So, I am sure Carsten Co, can provide some easier way to configure this, than present day, and perhaps it should be the default configuration to use Log4J as the backend. The performance hit, using the extra layer, would be far less than it takes Log4J to do something about the message, and if the Cocoon code properly use, logger.isXXXEnabled(), the main culprit of logging (debug statements being constructed) performance degrade is eliminated. Isn't this what you are REALLY asking for? Instead of; Let's throw all that out, and re-implement against a package, that we can't easily change in the future. Trying to be constructive. Niclas Robert Simmons said: quoteI wasnt insulting anyone and i appologize if it sounded like that. /quote I noticed you failed to copy that block into your acerbic reply. I appologized once, I wont do it again. -- Robert Gianugo Rabellino [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] Robert Simmons wrote: I wasnt accusing anyone of being childish. I wish you wouldnt put words in my mouth. I merely meant that the demands of a business environment are quite different then the demands of non-business environments. Please rest assured that many (probably most) of us know what the demands of business environments are. Many open source projects have yet to bridge this gulf and only a few have done it sucessfully (apache web server, ant, log4j, tomcat, jboss). For example, the decision to NOT distribute a binary build of cocoon is a good example of going in the opposite direction of business. Many business consultants are not interested in building source, but rather using the product as is. Oh, gosh... will not distributing a binary build be enough for us not to cross the bridge? Let's have a party on this side of the river with Linus then. Oh, and please tell me where you are going to find Gnome or KDE binary distributions (RPM, DEB and other linux distro packages don't count). And tell the FreeBSD guys that their port system is doomed. Anyway, here is your binary distribution: $ cat setup.sh ./build.sh war install.log 21 if [ $? == 0 ] then echo Installation successful, Cocoon war installed in `pwd`/build/cocoon.war else echo Installation failed, plese check install.log for details fi ^D Rant apart, you might have a point in blaming Cocoon of not being business friendly, and I'm starting to consider that there might be room for someone to come up and be Cocoon's RedHat, providing production builds and certified WARs, thus relieving the Cocoon community in these issues. Any Orixians listening? ;-)) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RT] Improving Sitemap and Flowscript
Vadim Gritsenko wrote: Nicola Ken Barozzi wrote: snip/ *IMPORTANT* (and the reason why I started the RT): So in he CLI, instead of asking for the link view and then generate, I simply ask Cocoon to insert a transformer that gathers links in the same positions where the links view would. This would make it possible for the CLI to have the configurability of the view gatherer but the speed of the transfomer gatherer. Links view is not a transformer. It's a view, meaning that it can have actions, matchers, selectors, transformers, and should end with text serializer. So, you cannot simply add one transformer and think that you are done with links view. You are right - Nicola Ken is here mixing up Link View and Link Gathering - two different approaches. What he says though is relevant to the link gathering approach, i.e. that it could be implemented with an 'aspect' allowing the user to insert the gathering stage at any point in their pipeline, by attaching a gathering transformer to a label (defaulting to the last stage, just before the serializer). In addition to this, adding a transformer would not work because this alters pipeline cache key which prevents such legitimate CLI usages as pre-populating persistent cache. Interesting point. That would also apply to the link translator, which, if confirm-extensions is used (which it is by default), is inserted before the serializer. So, to be able to pre-populate a persistent cache, you've got to (a) use link view (b) make sure you don't confirm extensions. Solution to the CLI problem was already found (attach links view as a tee to main pipeline, see Link View Goodness on approx 2003/07/01) and Upayavira is looking into ways of implementing it. I would help him out but right now I can't. Having reread Nicola Ken's post, I think I understood it this time (rather than being confused by all the references to aspects as I was last time). He does propose an interesting and more generic way to achieve what Vadim has already suggested - using an XML Tee component to feed SAX events into two pipeline segments simultaneously. To do that hard coded would be hard, and require quite a bit of work within AbstractProcessingPipeline. Doing it in Nicola Ken's way strikes me as cleaner and more generic. So you'd be able to add 'aspects' that use generators/transformers/serializers in the following combinations: 1) G-T-S (pretty useless as it doesn't really interact with the pipeline as it is) 2) T-S (takes the current SAX events, using a Tee, and feeds them to a section of pipeline that serializes somewhere else - e.g. link view) 3) G-T (replaces or augments SAX events with an additional source) 4) T (transforms existing SAX events, e.g. link gatherer) So we get a generic way of implementing our two gathering methods, and probably some additional methods we hadn't thought of. In case 2), we'd probably want to have another component after the serializer which defines what to do with the content, e.g. an ObjectModelWriter that writes it to the ObjectModel, a FileWriter that writes it to a file (or more likely a SourceWriter). Does this make sense? Or is it barking? (barking is shorthand for 'barking mad', like wild dogs can be sometimes). Regards, Upayavira
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
Gianugo Rabellino wrote, On 28/08/2003 13.19: ... Rant apart, you might have a point in blaming Cocoon of not being business friendly, and I'm starting to consider that there might be room for someone to come up and be Cocoon's RedHat, providing production builds and certified WARs, thus relieving the Cocoon community in these issues. Use Forrest, a prepackaged and starter-friendly Cocoon. :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
Berin Loritsch wrote, On 28/08/2003 15.08: Robert Simmons wrote: Actually, I was proposign the removal of the avalon logging mechanism completely. -1000 If I want to use a NullLogger (no logging completely, and no need for a logging toolkit) then I should be able to. If I want to use Log4J I should be able to. And if I am happy with LogKit (which is smaller BTW), then why should I loose that ability? Berin, I think that Robert has a valid point here, and that is similar to what Avalon said about Logkit and Log4j. When I was still in Avalon, Avalon had informally agreed to push Logkit EOL in favor of log4j, and the log4j community accepted the challenge of bridging the last differences still remaining. Why is this point much different from the one Robert is talking about? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] Improving Sitemap and Flowscript
Upayavira wrote: Vadim Gritsenko wrote: Nicola Ken Barozzi wrote: snip/ *IMPORTANT* (and the reason why I started the RT): So in he CLI, instead of asking for the link view and then generate, I simply ask Cocoon to insert a transformer that gathers links in the same positions where the links view would. This would make it possible for the CLI to have the configurability of the view gatherer but the speed of the transfomer gatherer. Links view is not a transformer. It's a view, meaning that it can have actions, matchers, selectors, transformers, and should end with text serializer. So, you cannot simply add one transformer and think that you are done with links view. You are right - Nicola Ken is here mixing up Link View and Link Gathering - two different approaches. What he says though is relevant to the link gathering approach, i.e. that it could be implemented with an 'aspect' allowing the user to insert the gathering stage at any point in their pipeline, by attaching a gathering transformer to a label (defaulting to the last stage, just before the serializer). Once we have links view working allright, we will kill link gathering alltogether -- anyway it was just a hack ;-) Vadim
RE: Integratign a W3C XForms implementation into the Cocoon Project?
Surprised you didn't see this: http://sourceforge.net/project/shownotes.php?group_id=20274release_id=150523 I haven't looked at in depth so it might not be what you're after, but the Chiba site has a Chicoon project that is labeled as an integration of Cocoon and Chiba. -Original Message- From: Robert Simmons [SMTP:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 4:31 PM To: [EMAIL PROTECTED] Subject: Integratign a W3C XForms implementation into the Cocoon Project? Greetings, One thing that I would like to see is Cocoon supporting the XForms 1.0 standard as described on W3C. http://www.w3.org/MarkUp/Forms/ There is currently a product in the open source community called Chiba that accomplishes a good portion of this integration. This could be built upon using the higher developer resources to the benefit of Cocoon. http://chiba.sourceforge.net/ I think it might be worth it to have Cocoon and Apache talk to the developer of Chiba about integrating it into the Cocoon project. Although XMLForms is useful, it simply isnt the standard anymore. Why implement what is already most of the way working? -- Robert
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
Nicola Ken Barozzi said: Berin, I think that Robert has a valid point here, and that is similar to what Avalon said about Logkit and Log4j. When I was still in Avalon, Avalon had informally agreed to push Logkit EOL in favor of log4j, and the log4j community accepted the challenge of bridging the last differences still remaining. Why is this point much different from the one Robert is talking about? Well, Robert's assertion is ambigious. Does he say; Drop void enableLogging( Logger logger ); and let every component do, logger = Logger.getLogger( this.getClass().getLogger() ); OR, Let Log4J be the default logger backend, and have the Log4J configuration handily available. I think Berin is -1 on the first, but more receptible to the latter. Niclas
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
Robert Simmons wrote: One of the major implementaiton complaints I have about Cocoon is its lack of Log4J logging functionality. Log4j, is without a doubt the best logging package for java. No other package can even hope to compare to it. If Cocoon was built to use Log4j instead of the avalon logging mechanism, it would gain an enormous amount of functionality that it lacks now. It is doable with Fortress, Merlin, or Phoenix. Phoenix is not designed for Cocoon like applications, so your choise is Fortress and Merlin. There is already support for it. Personally, when working in a production environment, I dont want my log files to be put into direcroies in my web app. Id rather have them forwarded to a central log accumulation server or even sent out via JMS. Log4j allows this and many more configurations. Furthermore, it allows you to turn on and off logging on individual components with ease. Finally, Log4J is used in so many other products that it is a recognized standard logging mechanism that many organizations and even network engineers are quite familiar with. Still doable with LogKit. As to turning logging on and off to individual components: It is assuming that you have a class name == component name relationship. That is not really helpful in a situation where we have many instances of the same class. LogKit can turn on and off individual *categories* which is what Log4J does. Both provide this ability. Therefore, I think Cocoon should migrate to Log4j. In order to contemplate this, its important that we discuss the complexities of it in the following quesitons. 1) Why has this not already been done? Is it a question of a lack of manpower or expertise? If so then I as well as others would most likely be happy to volunteer time to accomplish it. Avalon has a logger wrapping system. All that needs to be done is rip out the LogKit backed loggers and place in the Log4J ones. That is assuming that all logging components are using LogEnabled as opposed to Loggable. 2) How difficult is it to rip out the avalon logging from the cocoon core components? Im no avalon expert so I couldnt answer this myself. Not hard at all. The main thing I would advise against is using the static accessors. The components are assigned the categories from the container, and I would prefer to keep it that way. 3) Is there standard expressions that can be used for locatting logging lines in cocoon? Not sure. No need for it though. 4) Do we upgrade some of the blocks or leave them as is and only upgrade core cocoon? You only need to upgrade the core cocoon. -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
Gianugo Rabellino wrote: Lets make a deal and avoid both stubborness and aggressive attitude then. I would suggest you to discuss the Log4J vs. Logkit implementation issues on the proper lists and come back here with more evidence. You might even convince the Avalon guys to switch to Logkit... For what its worth, Avalon is working with the Log4J folks. The new containers (ECM is old and outdated) there is no die-hard need to use LogKit. There also is no die-hard need to tie ourselves to Log4J. Some people might want to use (gasp, cough, choke) JDK 1.4 logging. It's still possibile with Avalon. Say what you will, we are ahead of you on this matter. -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
Nicola Ken Barozzi wrote: Berin Loritsch wrote, On 28/08/2003 15.08: Robert Simmons wrote: Actually, I was proposign the removal of the avalon logging mechanism completely. -1000 If I want to use a NullLogger (no logging completely, and no need for a logging toolkit) then I should be able to. If I want to use Log4J I should be able to. And if I am happy with LogKit (which is smaller BTW), then why should I loose that ability? Berin, I think that Robert has a valid point here, and that is similar to what Avalon said about Logkit and Log4j. When I was still in Avalon, Avalon had informally agreed to push Logkit EOL in favor of log4j, and the log4j community accepted the challenge of bridging the last differences still remaining. Why is this point much different from the one Robert is talking about? I would be very much against marrying the Cocoon system to Log4J despite it's advantages over LogKit. Let's assume for the moment that JDK 1.4 logging becomes mainstream over Log4J (not likely, but play devil's advocate for a moment). If you have forceably ripped out the LogEnabled interfaces and hardcoded against Log4J, the migration path would be very painful to say the least. Also, to make matters worse, not everyone has the same needs. Some shops will blindly use corporate products or language APIs regardless of their merit. Other shops evaluate the available libraries. If we have a very lightweight logging abstraction that doesn't tie us down to one implementation, we can easily make everyone happy. Not everyone uses Log4J (as Robert asserts). I would be against coding ourselves into a corner when there are legitimate ways to avoid the situation _already_ in place. Yes, informally the Avalon team will be deprecating LogKit in favor of Log4J 2.0 but it isn't out yet. Plans can change (although this seems to be a pretty safe bet). Lastly, the NullLogger included in Avalon Framework is orders of magnitude faster than any of the full Logging toolkits like LogKit, Log4J, and java.util.logging. If you don't need/want logging (extreme example), why force it? I can understand going backwards a short distance if the alternate route let's us go farther. However, the proposal seems to take a good route and trade it for a dead end. I am not for that. -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
Niclas Hedhman wrote: Well, Robert's assertion is ambigious. Does he say; Drop void enableLogging( Logger logger ); and let every component do, logger = Logger.getLogger( this.getClass().getLogger() ); OR, Let Log4J be the default logger backend, and have the Log4J configuration handily available. I think Berin is -1 on the first, but more receptible to the latter. I am very -1 for the first. I am pretty +1 for the latter. -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
Re: Integratign a W3C XForms implementation into the Cocoon Project?
Robert Simmons said: Wehn XForms is widely adopted, do we want cocoon to be the only web publishing framework that doesnt support them? I am far from an XForm expert, but saying that Cocoon will not support XForm when the User Agents doesn is a little bit of overstatement isn't it? The POST from the UA will be an XML document, and if there is something Cocoon is good at, it is to take care of XML input. So, when Xform is widely adopted I think this is not an issue in Cocoon. However, Cocoon has many times in the past proved a useful platform for bridging new technologies with olds (such as creating PNG out of SVGs for non-svg capable UAs), and that is when we need Cocoon support of a new technology. (For some reason, my mails takes a long time to reach the mailing list. I already covered this an hour ago. Maybe have to re-send.) Niclas
Re: Blocks Manual
On Thu, 28 Aug 2003, Robert Simmons wrote: Like I said before, I tend to be direct in my language and if I offend, I certainly dont mean to and I appologize. You don't seem to understand what I'm trying to explain, so pardon my shouting: QUIT APOLOGIZING - DO SOMETHING ABOUT IT. Except for the JMS logging thing, most of your remarks make some sense. Now, what if nobody cares enough to actually do the work for you? Will you do it yourself? Cheers, /Steven
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
Berin Loritsch said: Niclas Hedhman wrote: Well, Robert's assertion is ambigious. Does he say; Drop void enableLogging( Logger logger ); and let every component do, logger = Logger.getLogger( this.getClass().getLogger() ); OR, Let Log4J be the default logger backend, and have the Log4J configuration handily available. I think Berin is -1 on the first, but more receptible to the latter. I am very -1 for the first. I am pretty +1 for the latter. Then the question to the community would be; Should Cocoon be configured out-of-the-box for logging to a Log4J backend? I am in strong favour of this too, although I have no official say in it... Niclas
Re: Integratign a W3C XForms implementation into the Cocoon Project?
Since it never arrived... Berin Loritsch said: Robert Simmons wrote: Greetings, One thing that I would like to see is Cocoon supporting the XForms 1.0 standard as described on W3C. http://www.w3.org/MarkUp/Forms/ I would advise against the XForms standard because it is severely broken for client/server type applications. XForms ONLY makes sense in a pure client setting. I would like to hear an elaboration of why this is the case. Why would this not be useful? App--XForm --XHTML adaption-- XHTML form | | user action | | V App--XML Result --adaption-- XHTML Response And later when the UA is XForm capable, the adaption stage is dropped from the pipeline. Just curious. Niclas
Re: [RT] Improving Sitemap and Flowscript
Vadim Gritsenko wrote, On 28/08/2003 14.00: Nicola Ken Barozzi wrote: snip/ *IMPORTANT* (and the reason why I started the RT): So in he CLI, instead of asking for the link view and then generate, I simply ask Cocoon to insert a transformer that gathers links in the same positions where the links view would. This would make it possible for the CLI to have the configurability of the view gatherer but the speed of the transfomer gatherer. Links view is not a transformer. It's a view, meaning that it can have actions, matchers, selectors, transformers, and should end with text serializer. So, you cannot simply add one transformer and think that you are done with links view. When I say Transformer here I mean Virtual Transformer, that can be all you say above, as I suggest in the RT. This also means that this virtual Transformer can also do the link exclusion and other things that are needed and that a simple transformer cannot do. In addition to this, adding a transformer would not work because this alters pipeline cache key which prevents such legitimate CLI usages as pre-populating persistent cache. I do not see the case in which this happens. Could you explain more please? Solution to the CLI problem was already found (attach links view as a tee to main pipeline, see Link View Goodness on approx 2003/07/01) http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105708533500966w=2 and Upayavira is looking into ways of implementing it. I would help him out but right now I can't. I know, but doing it as I say is conceptually equivalent to attaching links tee to main pipeline, so it's an alternative way, but that has extra features. Conceptually generator inserted gatherer vt --- (links hashmap) serializer What propose generator inserted tee - view - parser --- (links hashmap) serializer Which is basically the same, only that I use a virtual transformer and you use a view. Make the view call the same virtual transformer, and the results are the same only that my proposal is more generic. Oh well, whatever, as long as it works... -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
Hi, Should Cocoon be configured out-of-the-box for logging to a Log4J backend? I'd put my two cents worth of opinion in favor of this suggestion. Regards, Pelle
[Proposal] Simple production build directions
--Simple proposal for a production build for Cocoon-- Create a new file production.build.properties, and refer to it in a new step 2 in INSTALL.txt: Proposed changes to INSTALL.txt: (Insert a new step 2) 2) For a full build skip to step 3 To make a production build without the documentation, samples, scratchpad, or deprecated code simply copy the file production.build.properties to local.build.properties before going on to step 3. See below if you are rebuilding or wish to further customize the build. (And, of course, renumber the following steps) 3) Build Cocoon by typing build or ./build.sh 4) Run Cocoon by typing cocoon servlet or ./cocoon.sh servlet 5) Open http://localhost:/ with your browser Proposed new file production.build.properties: # Webapp Exclusions exclude.webapp.documentation=true exclude.webapp.javadocs=true exclude.webapp.idldocs=true exclude.webapp.scratchpad=true exclude.webapp.samples=true # Build Exclusions exclude.scratchpad=true exclude.deprecated=true exclude.javadocs=true exclude.idldocs=true How is this for a simple solution? --Tim Larson __ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
Re: Integratign a W3C XForms implementation into the Cocoon Project?
Berin Loritsch said: Robert Simmons wrote: Greetings, One thing that I would like to see is Cocoon supporting the XForms 1.0 standard as described on W3C. http://www.w3.org/MarkUp/Forms/ I would advise against the XForms standard because it is severely broken for client/server type applications. XForms ONLY makes sense in a pure client setting. I would like to hear an elaboration of why this is the case. Why would this not be useful? App--XForm --XHTML adaption-- XHTML form | | user action | | V App--XML Result --adaption-- XHTML Response And later when the UA is XForm capable, the adaption stage is dropped from the pipeline. Just curious. Niclas
Re: Blocks Manual
If I had the qualifications to, yes. However it would be terribly inefficient for me to spend months studying the source code to the blocks in order to make complete documentation when there are people that already know these blocks and could make the documentation a lot quicker. Cocoon has a number of huge documentation holes. Do you bring in a source newbie to plug them or do you get on the developers that actually know what is going on to plug them? Option B is much more reasonable. -- Robert Steven Noels [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] On Thu, 28 Aug 2003, Robert Simmons wrote: Like I said before, I tend to be direct in my language and if I offend, I certainly dont mean to and I appologize. You don't seem to understand what I'm trying to explain, so pardon my shouting: QUIT APOLOGIZING - DO SOMETHING ABOUT IT. Except for the JMS logging thing, most of your remarks make some sense. Now, what if nobody cares enough to actually do the work for you? Will you do it yourself? Cheers, /Steven
Re: Cocoon in Business Environements and its shortfalls
Robert Simmons wrote: *Snip many good points* Issues Im not privy to directly but concerned about: 6) Project Lint. Over time any project accumulates an amount of lint in the form of dead code, unused classes and unused methods. How much of this is in cocoon and how can we get it out? I have found that trying to use tools to verify the lint in a project with true separation of components and interfaces, the method coverage metrics generate a bunch of false positives. You will find that all your Generators won't be directly connected to in code, so they will be tagged unused code. You might be able to find which methods on an interface are not used, but tools for environments like this are not advanced enough yet. Nevertheless, certain IDEs like JetBrains IDEA is very good at finding dead private methods, unused variables, unused parameters (and determining if the method is from an interface or not), etc. I wish I was aware of an OS project that was that advanced. -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
RE: Blocks Manual
Robert Simmons wrote: If I had the qualifications to, yes. However it would be terribly inefficient for me to spend months studying the source code to the blocks in order to make complete documentation when there are people that already know these blocks and could make the documentation a lot quicker. Cocoon has a number of huge documentation holes. Do you bring in a source newbie to plug them or do you get on the developers that actually know what is going on to plug them? Option B is much more reasonable. I think everyone ranging from a user to the expert can help here. Starting a documentation doesn't mean that you know everything. You can provide a frame with the things you know (or you think you know) and others can step in and fill the holes. This is a community work then. You will see this happen as soon as you do the starting work. Carsten
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/generation JXTemplateGenerator.java
mpo 2003/08/28 07:29:43
Modified:src/java/org/apache/cocoon/generation
JXTemplateGenerator.java
Log:
Making sure the continuation is present in the Jexl context even if the flowContext
is missing.
Revision ChangesPath
1.7 +3 -1
cocoon-2.1/src/java/org/apache/cocoon/generation/JXTemplateGenerator.java
Index: JXTemplateGenerator.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/generation/JXTemplateGenerator.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- JXTemplateGenerator.java 11 Aug 2003 12:48:56 - 1.6
+++ JXTemplateGenerator.java 28 Aug 2003 14:29:43 - 1.7
@@ -2662,7 +2662,6 @@
map = globalJexlContext.getVars();
if (contextObject != null) {
map.put(flowContext, contextObject);
-map.put(continuation, kont);
// FIXME (VG): Is this required (what it's used for - examples)?
// Here I use Rhino's live-connect objects to allow Jexl to call
// java constructors
@@ -2670,6 +2669,9 @@
Object pkgs = JavaScriptFlow.getPackages(objectModel);
map.put(java, javaPkg);
map.put(Packages, pkgs);
+}
+if (kont!=null) {
+map.put(continuation, kont);
}
map.put(request, request);
map.put(response, response);
Re: Integratign a W3C XForms implementation into the Cocoon Project?
Niclas Hedhman wrote: Since it never arrived... Berin Loritsch said: Robert Simmons wrote: Greetings, One thing that I would like to see is Cocoon supporting the XForms 1.0 standard as described on W3C. http://www.w3.org/MarkUp/Forms/ I would advise against the XForms standard because it is severely broken for client/server type applications. XForms ONLY makes sense in a pure client setting. I would like to hear an elaboration of why this is the case. Why would this not be useful? App--XForm --XHTML adaption-- XHTML form | | user action | | V App--XML Result --adaption-- XHTML Response And later when the UA is XForm capable, the adaption stage is dropped from the pipeline. In the eXFormula project I did a while ago, with the spec as it was, we could only go so far. Not to mention that the XForms document mixes alot in the equation. You need to gain information from three sources: model, view, and controller. These are wired together via XML documents. Unfortunately, sometimes the XML documents are all assembled into one and other times they are completely separate. This makes the adaptation layer very complex. In many cases it would be far easier to work it all in the client where we have access to the documents in a much more easily used manner. -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
Re: [Proposal] Simple production build directions
Timothy Larson wrote: --Simple proposal for a production build for Cocoon-- Create a new file production.build.properties, and refer to it in a new step 2 in INSTALL.txt: Proposed changes to INSTALL.txt: (Insert a new step 2) 2) For a full build skip to step 3 To make a production build without the documentation, samples, scratchpad, or deprecated code simply copy the file production.build.properties to local.build.properties before going on to step 3. See below if you are rebuilding or wish to further customize the build. (And, of course, renumber the following steps) 3) Build Cocoon by typing build or ./build.sh 4) Run Cocoon by typing cocoon servlet or ./cocoon.sh servlet 5) Open http://localhost:/ with your browser Proposed new file production.build.properties: # Webapp Exclusions exclude.webapp.documentation=true exclude.webapp.javadocs=true exclude.webapp.idldocs=true exclude.webapp.scratchpad=true exclude.webapp.samples=true # Build Exclusions exclude.scratchpad=true exclude.deprecated=true exclude.javadocs=true exclude.idldocs=true How is this for a simple solution? It will be easy to add a new build target production-seed (or something to that effect) which would set those values and perform other steps as needed. This would change the instructions to 1) edit blocks properties 2) ./build.sh production-seed. Would that be better in your mind, or is a sample properties better? I can see positives with both solutions. The key is not how to accomplish it (because the pieces are already in place in the build to do either), but _what_ to accomplish. Also, are there other config issues can be agreed on for this target/recommended setting? Logging level? Allow/Deny uploads? Geoff
Re: Cocoon in Business Environements and its shortfalls
Robert Simmons wrote: I wanted to open a general discussion thread on the shortfalls of Cocoon in business environments. I have some very clear opinions on the matter, but then my opinions are just that -- opinions. Others may differ with me. ... I will start by stating my issues with cocoon as is: 1) Production builds are lacking. What I mean by this are builds that a developer would use if he is USING cocoon and not developing on it at all. Robert, I think you are making the (understandable) assumption that getting rid of the binary build betrayed a focus on people developing on Cocoon itself, but this is incorrect. Have you found the recent (last week or two) comments I made explaining this on the users list? I have had several people with the same initial feeling you're expressing write back to me privately after that indicating that the current (temporary) solution is not nearly as bad as they perceived it to be. To restate simply, the build step really is a configure step and a build step rolled into one. We could probably (now that the JDK dependencies are fixed) distribute a half built Cocoon, where all classes are compiled but the webapp is not configured/assembled. That would not get you out of having to run ./something.sh target-name to do the last step. So it has been the judgement of the community that since that's necessary anyway, there is not a big functional difference between the two and what we have can do for now. We could probably rename build.sh to configure.sh and remove the bulk of the perception problem. 1a) One might object that blocks have to be described dureing the build process. This could be true but needs to change. The ideal solution is that someone cha drop in a block into the blocks directory post build and then indicate the block in the sitemap. This would allow a binary build that would give users the chance to merely delete blocks that they are not interested in and add their own blocks to a binary build. You need to note that we already have an excellent solution in the works which will allow binary drop-in of new components/applications/services into a pre-built binary core. I believe this will exceed most people's expectations. We just released 2.1. Planning for the next step has been in the works for probably a year and execution is beginning now. 1b) Examples for blocks need to be out of the blocks themselves. In my opinion, the only thing in the blocks directory should be the blocks jars themselves and perhaps something akin to a deployment descriptor for the blocks in the directory. Examples should be in a completely different locations. Are you aware that including a block with exclude.webapp.samples (or whatever) configured excludes the examples for that block already? Given that, I completely disagree that the samples should be moved somewhere else. A block (as it exists now, not in the full 2.2 implementation under development now) is not a discrete thing that can be picked up and deleted. It's an aggregation of java classes and configuration, and (optionally) samples. ... 4) Cocoon documentation is minimal and non-cohesive. (But you knew this already) Although wiki is good for knowledge sharing, the information in Wiki is oftewn out of date and its reliability is sometimes questionable. Unfortunately, so is the official documentation in places. Newcomers who don't feel comforatble writing new docs could still help immensely in giving good detailed feedback about what is missing, what is out of date or questionable, and what should move from the wiki to the official docs. Geoff
RE: Cocoon in Business Environements and its shortfalls
2) Monitoring is not intuitive. If you are deploying a business application with 20 cocurrent Cocoon instances, you need a way to cohesively monitor the health of the entire cluster. Separate log files just arent sufficient. Something like JMX instrumentation would be ideal. Understood. Keep in mind that Cocoon does have some instrumentation available to it through Avalon's instrumentation package. It has a nice client that can connect to remote servers. That way you can monitor your Cocoon instances from your desk, and see their relative happiness. (More appropriate for the User's list, yes, but since it was mentioned here...) Is there any documentation on this? How to use/access? I don't remember reading anything about this on the Cocoon site... For reference, I'm currently just using the bundled version of Jetty. Thanks, Chris
Re: [RT] Improving Sitemap and Flowscript
Vadim Gritsenko wrote, On 28/08/2003 16.23: ... With a tee-view, pipeline would be: G[data] - T[content] - Tee - T[page] - T[html] - S - Browser \ - T[links] - Hashmap With a virtual transformer as far as I understand resulting pipeline will be: G[data] - T[content] - T[links] - LinkGatherer - T[page] - T[html] - S - Browser And the output sent to the browser will be garbage, right? Or, you are also proposing to use a tee (I haven't seen it in your proposal)? Thanks for explaining it this way, now I understand what you mean. Well, I did not talk of how to insert a T[links] section, so now I see why you say it is flawed. What I mean is that the LinkGatherer is a virtual transformer that does not modify its output WRT the input. How to do it is not part of my example, and using a tee is one way, using an xslt, then gathering, then retransforming again is another (kind of tee using namespaces). The problem arises when you insert the tee or the virtual transformer and have problems with caching, *or* have to keep that step even if you don't want it. Anyway, as I said, both are ok as long as it remains fast and gives us the features we need. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] WebDAV proxy / DASL search in Cocoon
Bertrand Delacretaz wrote: Following up on Gianugo's wild idea [1] that Cocoon could be used to implement the DASL part of a WebDAV server.. Cocoon would proxy the following operations to the WebDAV backend: GET, HEAD, POST, PUT, DELETE, MKCOL Not really. You need to keep your metadata repository in sync, so you need to intercept PUT, DELETE MKCOL, acting accordingly on the JDBC store, so you would need a bit more than just proxying. And handle the following operations: PROPFIND, PROPPATCH, SEARCH Problem areas: -OPTIONS, backend response must be completed with DASL info (easy) -MOVE and COPY, URIs must stay in sync between file storage and properties, not too hard to do Same with methods above... -Locking must lock both file contents and properties (I assume), slightly harder Not really. You need to keep trace of lock tokens, but it shouldn't be that hard. Does this sound too hackish? ;-) Not at all, infact it was something I wanted to investigate sooner or later (with DAV ACL being the next one to tackle). Care to jump in? :-) -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [Proposal] Simple production build directions
Thanks Cocoon developers for thinking thru and working this out. It is much appreciated. -- Roger - Original Message - From: Timothy Larson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 28, 2003 11:06 AM Subject: Re: [Proposal] Simple production build directions --- Geoff Howard [EMAIL PROTECTED] wrote: It will be easy to add a new build target production-seed (or something to that effect) which would set those values and perform other steps as needed. This would change the instructions to 1) edit blocks properties 2) ./build.sh production-seed. Would that be better in your mind, or is a sample properties better? I can see positives with both solutions. I lean toward a example properties file, because that introduces the customization system that Cocoon uses. I updated to proposed text to refer to the production.build.properties as an example file: To make a production build without the documentation, samples, scratchpad, or deprecated code simply copy the example production.build.properties file to local.build.properties before going on to step 3. See below if you are rebuilding or wish to further customize the build. The key is not how to accomplish it (because the pieces are already in place in the build to do either), but _what_ to accomplish. The example production build does not have to be perfect for everybody, just reasonable and relatively secure. We already have the customization instructions for making it perfect. Also, are there other config issues can be agreed on for this target/recommended setting? Logging level? Allow/Deny uploads? The default log level is already INFO, which is a reasonable default. A default setting of Deny uploads is the most secure. Perhaps we should add these two settings to the example production build properties file, since they are among the most likely to be customized: # Configuration #config.enable-uploads=true # Webapp Build Properties build.webapp.loglevel=INFO --Tim Larson __ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
Re: [Proposal] Simple production build directions
Thanks for the suggestion. I added the proposal to the wiki here: http://wiki.cocoondev.org/Wiki.jsp?page=ProductionInstallProposal --- Bertrand Delacretaz [EMAIL PROTECTED] wrote: ... Instead of adding a production target, I'd suggest working on Timothy's instructions on the wiki (including the production.build.properties example) and adding the result to CVS as PRODUCTION-INSTALL.TXT or something once they're stabilized. -Bertrand __ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
cvs commit: cocoon-2.0/src/java/org/apache/cocoon/components/search SimpleLuceneXMLIndexerImpl.java
asavory 2003/08/28 09:52:54 Modified:src/java/org/apache/cocoon/components/search SimpleLuceneXMLIndexerImpl.java Log: Fixing markup Revision ChangesPath 1.3 +2 -2 cocoon-2.0/src/java/org/apache/cocoon/components/search/SimpleLuceneXMLIndexerImpl.java Index: SimpleLuceneXMLIndexerImpl.java === RCS file: /home/cvs/cocoon-2.0/src/java/org/apache/cocoon/components/search/SimpleLuceneXMLIndexerImpl.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- SimpleLuceneXMLIndexerImpl.java 19 Mar 2003 10:46:12 - 1.2 +++ SimpleLuceneXMLIndexerImpl.java 28 Aug 2003 16:52:54 - 1.3 @@ -94,7 +94,7 @@ * Example configuration (goes in cocoon.xconf) * prett * lt;lucene-xml-indexer logger=core.search.lucenegt; - * lt;store-fieldsgt;title, summarylt;store-fieldsgt; + * lt;store-fieldsgt;title, summarylt;/store-fieldsgt; * lt;content-view-querygt;cocoon-view=searchlt;/content-view-querygt; * lt;/lucene-xml-indexergt; * /tt/pre/p
DO NOT REPLY [Bug 22795] New: - reuse-parsers is set to false (shouldn't be true?)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22795. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22795 reuse-parsers is set to false (shouldn't be true?) Summary: reuse-parsers is set to false (shouldn't be true?) Product: Cocoon 2 Version: 2.0.1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] cocoon.xconf:/cocoon/xml-parser/[EMAIL PROTECTED]'reuse-parsers']/@value is set to false. There is a commented description above: !--+ | [...] | - reuse-parsers (boolean, default = true) : do we want to reuse | parsers or create a new parser for each parse ? | [...] +-- So shouldn't it be set true by default? Doesn't it influence cocoon performance?
RE: [RT] Starting 2.2
Carsten Ziegeler dijo: Hello. Is there anybody in there? Just nod if you can hear me. Is there anyone home? Great :) Antonio Gallardo
DO NOT REPLY [Bug 22796] New: - Flow: cocoon.sendPage() enforces text/plain in the response
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22796. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22796 Flow: cocoon.sendPage() enforces text/plain in the response Summary: Flow: cocoon.sendPage() enforces text/plain in the response Product: Cocoon 2 Version: Current CVS 2.1 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] cocoon.sendPage() enforces text/plain in the response, regardless of what serialization method is used in the redircted-to pipeline. All the examples in the Cocoon CVS now doesn't work because of that, the output is merly text.
Re: [Proposal] Simple production build directions
Roger I Martin PhD wrote: Thanks Cocoon developers for thinking thru and working this out. It is much appreciated. Your patience with us, poor human beings, is even more appreciated. Cheers! /Steven
Re: [RT] Starting 2.2
So my eye finally caught on the Starting 2.2 thread today, it seemed interesting, and I went to read through this... and I must say the main reaction I ended up having to it is HUH?!?. :) Is the reason you need a new repository because CVS doesn't support move/copy/rename (especially so on directories?). I guess I've just been using Subversion so long that some of the solutions people have been proposing sound rather terrifying... making a new repository and copying all of the RCS files into it in order to preserve history? But then you'd still be maintaining the files in both versions seperately with no computer way to know this file is a copy of that one to try to help you do that. Then there was the suggestion to have the new repository copy stuff from the 2.1 repository during build or something... With Subversion you could just copy the current trunk off to a cocoon-2.1 branch (as you'd likely be doing many less fixes on that over the future than enhancements to 2.2, so that would be considered the branch) and then start reorganizing the directories in the trunk by just moving them around and committing the move operations (so far with no space duplication on the server as all of these copy/move operations are just references to the same file data in the repository), files that need to be renamed could easily be done so, and this entire process would be keeping track of the history through all of the move operations... (although merging the 2.1 branch changes into 2.2 still wouldn't be entirely automated, but I'm pretty sure the Subversion people are working on this; 0.28.0, released a few days ago, has some features that is bringing it a lot closer). Has any thought been put into the next time we have to create another new repository should be the day we look into better version control? Sincerely, Jay Freeman (saurik) [EMAIL PROTECTED] - Original Message - From: Carsten Ziegeler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 2:18 AM Subject: RE: [RT] Starting 2.2 Pier Fumagalli wrote: On 13/8/03 16:37, Carsten Ziegeler [EMAIL PROTECTED] wrote: Ok, let's do simple steps perhaps: Do you think that we should start a new repository? This is equivalent to saying we start a new major version (2.2). (if the answer is yes, we can talk about the layout). YES! :-) As I have few [RT]s on my own! :-) :-) :-) Great! Combined with the recent RTs, does still someone feel that starting 2.2 is the right thing? Or a there still objections? Carsten
cvs commit: cocoon-2.0/src/documentation/xdocs/installing index.xml
asavory 2003/08/28 11:15:47 Modified:src/documentation/xdocs/installing index.xml Log: Fixing typo Revision ChangesPath 1.9 +2 -2 cocoon-2.0/src/documentation/xdocs/installing/index.xml Index: index.xml === RCS file: /home/cvs/cocoon-2.0/src/documentation/xdocs/installing/index.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- index.xml 21 Aug 2003 01:15:27 - 1.8 +++ index.xml 28 Aug 2003 18:15:47 - 1.9 @@ -400,11 +400,11 @@ source [unix] ./build.sh -Dinclude.webapp.libs=yes -Dexclude.webapp.samples=yes - -Dexclude.webapp.documenation=yes + -Dexclude.webapp.documentation=yes -Dexclude.webapp.javadocs=yes webapp [win32] .\build.bat -Dinclude.webapp.libs=yes -Dexclude.webapp.samples=yes - -Dexclude.webapp.documenation=yes + -Dexclude.webapp.documentation=yes -Dexclude.webapp.javadocs=yes webapp /source pyou get a minimal Cocoon web application without any samples or documentation.
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
On Thu, 28 Aug 2003, Robert Simmons wrote: Actually, I was proposign the removal of the avalon logging mechanism completely. I would still be -1 on this because of the reasons mentioned in my earlier mail. Giacomo -- Robert Carsten Ziegeler [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] The Avalon Logging can be changed to use Log4J. Currently the usage of the LogKit is hard-coded in Cocoon. I added the possibility to configure which logging framework you want to use to the avalon core, but never had time to test it. If this is working, only minor changes have to be made to Cocoon (changing three or four lines of code) and you can use Log4j in Cocoon. Carsten -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Robert Simmons Sent: Thursday, August 28, 2003 11:32 AM To: [EMAIL PROTECTED] Subject: Porting Cocoon Logging to Log4j - Proposal and Discussion One of the major implementaiton complaints I have about Cocoon is its lack of Log4J logging functionality. Log4j, is without a doubt the best logging package for java. No other package can even hope to compare to it. If Cocoon was built to use Log4j instead of the avalon logging mechanism, it would gain an enormous amount of functionality that it lacks now. Personally, when working in a production environment, I dont want my log files to be put into direcroies in my web app. Id rather have them forwarded to a central log accumulation server or even sent out via JMS. Log4j allows this and many more configurations. Furthermore, it allows you to turn on and off logging on individual components with ease. Finally, Log4J is used in so many other products that it is a recognized standard logging mechanism that many organizations and even network engineers are quite familiar with. Therefore, I think Cocoon should migrate to Log4j. In order to contemplate this, its important that we discuss the complexities of it in the following quesitons. 1) Why has this not already been done? Is it a question of a lack of manpower or expertise? If so then I as well as others would most likely be happy to volunteer time to accomplish it. 2) How difficult is it to rip out the avalon logging from the cocoon core components? Im no avalon expert so I couldnt answer this myself. 3) Is there standard expressions that can be used for locatting logging lines in cocoon? 4) Do we upgrade some of the blocks or leave them as is and only upgrade core cocoon? I would be interested in comments and opinions. -- Robert -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
On Thu, 28 Aug 2003, Gianugo Rabellino wrote: Robert Simmons wrote: I wasnt accusing anyone of being childish. I wish you wouldnt put words in my mouth. I merely meant that the demands of a business environment are quite different then the demands of non-business environments. Please rest assured that many (probably most) of us know what the demands of business environments are. Many open source projects have yet to bridge this gulf and only a few have done it sucessfully (apache web server, ant, log4j, tomcat, jboss). For example, the decision to NOT distribute a binary build of cocoon is a good example of going in the opposite direction of business. Many business consultants are not interested in building source, but rather using the product as is. Oh, gosh... will not distributing a binary build be enough for us not to cross the bridge? Let's have a party on this side of the river with Linus then. Oh, and please tell me where you are going to find Gnome or KDE binary distributions (RPM, DEB and other linux distro packages don't count). And tell the FreeBSD guys that their port system is doomed. Anyway, here is your binary distribution: $ cat setup.sh ./build.sh war install.log 21 if [ $? == 0 ] then echo Installation successful, Cocoon war installed in `pwd`/build/cocoon.war else echo Installation failed, plese check install.log for details fi ^D Rant apart, you might have a point in blaming Cocoon of not being business friendly, and I'm starting to consider that there might be room for someone to come up and be Cocoon's RedHat, providing production builds and certified WARs, thus relieving the Cocoon community in these issues. Any Orixians listening? ;-)) Thanks for taking the energy. I couldn't say it any better. -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/bean CocoonBean.java CocoonWrapper.java
upayavira2003/08/28 12:21:00
Modified:src/java/org/apache/cocoon Main.java
src/java/org/apache/cocoon/bean CocoonBean.java
CocoonWrapper.java
Log:
Moved error detection to correct place
Added basic support for include/exclude
Revision ChangesPath
1.13 +26 -2 cocoon-2.1/src/java/org/apache/cocoon/Main.java
Index: Main.java
===
RCS file: /home/cvs/cocoon-2.1/src/java/org/apache/cocoon/Main.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- Main.java 27 Aug 2003 19:18:18 - 1.12
+++ Main.java 28 Aug 2003 19:21:00 - 1.13
@@ -163,7 +163,10 @@
private static final String NODE_LOAD_CLASS = load-class;
private static final String NODE_DEFAULT_FILENAME = default-filename;
-
+private static final String NODE_INCLUDE = include;
+private static final String NODE_EXCLUDE = exclude;
+private static final String ATTR_INCLUDE_EXCLUDE_PATTERN = pattern;
+
private static final String NODE_URI = uri;
private static final String ATTR_URI_TYPE = type;
private static final String ATTR_URI_SOURCEPREFIX = src-prefix;
@@ -501,6 +504,14 @@
} else if (nodeName.equals(NODE_DEFAULT_FILENAME)) {
cocoon.setDefaultFilename(getNodeValue(node));
+} else if (nodeName.equals(NODE_INCLUDE)) {
+String pattern = Main.parseIncludeExcludeNode(cocoon, node,
NODE_INCLUDE);
+cocoon.addIncludePattern(pattern);
+
+} else if (nodeName.equals(NODE_EXCLUDE)) {
+String pattern = Main.parseIncludeExcludeNode(cocoon, node,
NODE_EXCLUDE);
+cocoon.addExcludePattern(pattern);
+
} else if (nodeName.equals(NODE_URI)) {
Main.parseURINode(cocoon, node, destDir);
@@ -551,6 +562,19 @@
NodeList nodes = node.getChildNodes();
if (nodes.getLength()!=0) {
throw new IllegalArgumentException(Unexpected children of +
NODE_BROKEN_LINKS + node);
+}
+}
+
+private static String parseIncludeExcludeNode(CocoonBean cocoon, Node node,
final String NODE_TYPE) throws IllegalArgumentException {
+NodeList nodes = node.getChildNodes();
+if (nodes.getLength() != 0) {
+throw new IllegalArgumentException(Unexpected children of +
NODE_INCLUDE + node);
+}
+
+if (Main.hasAttribute(node, ATTR_INCLUDE_EXCLUDE_PATTERN)) {
+return Main.getAttributeValue(node, ATTR_INCLUDE_EXCLUDE_PATTERN);
+} else {
+throw new IllegalArgumentException(Expected a
+ATTR_INCLUDE_EXCLUDE_PATTERN+ attribute for +NODE_TYPE+ node);
}
}
1.18 +79 -23cocoon-2.1/src/java/org/apache/cocoon/bean/CocoonBean.java
Index: CocoonBean.java
===
RCS file: /home/cvs/cocoon-2.1/src/java/org/apache/cocoon/bean/CocoonBean.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- CocoonBean.java 27 Aug 2003 19:18:18 - 1.17
+++ CocoonBean.java 28 Aug 2003 19:21:00 - 1.18
@@ -60,6 +60,7 @@
import org.apache.cocoon.components.notification.Notifier;
import org.apache.cocoon.components.notification.DefaultNotifyingBuilder;
import org.apache.cocoon.components.notification.Notifying;
+import org.apache.cocoon.matching.helpers.WildcardHelper;
import org.apache.excalibur.source.ModifiableSource;
import org.apache.excalibur.source.SourceResolver;
@@ -77,10 +78,13 @@
import java.util.List;
/**
- * The Cocoon Bean simplifies usage of the Cocoon object. Allows to create,
+ * pThe Cocoon Bean simplifies usage of the Cocoon object. Allows to create,
* configure Cocoon instance and process requests, one by one or multiple
- * with link traversal.
+ * with link traversal./p
*
+ * pbWARNING:/b This interface is not stable and could be changed in
+ * backward incompatible way without prior notice./p
+
* @author a href=mailto:[EMAIL PROTECTED]Stefano Mazzocchi/a
* @author a href=mailto:[EMAIL PROTECTED]Nicola Ken Barozzi/a
* @author a href=mailto:[EMAIL PROTECTED]Vadim Gritsenko/a
@@ -97,6 +101,8 @@
private List targets = new ArrayList();
private boolean brokenLinkGenerate = false;
private String brokenLinkExtension = ;
+private List excludePatterns = new ArrayList();
+private List includePatterns = new ArrayList();
// Internal Objects
private Map allProcessedLinks;
@@ -105,6 +111,7 @@
private List listeners = new ArrayList();
private boolean verbose;
Re: [RT] Starting 2.2
Nicola Ken Barozzi wrote: Maybe start 2.5, just to be in line with Linux? ;-P Screw that, let's just skip a couple major versions, everyone's doing it now, how does Cocoon 5.0 look? :) Better yet, let's just change the name alltogether: Cocoon XP Cocoon MX Cocoon MX 2004 I just love Macromedia, at least they admit MX doesn't mean anything: What does MX mean? The MX moniker is not an acronym and doesn't have a literal translation. They add the MX, and then they realize they have to release a new version so they tack a 2004 on the end. In all seriousness, I'm all for 2.2, but what sorts of loose ends are there that could be tied up for 2.1.x? Howabout a push to clear out some bugs from bugzilla? Regards, Tony
Re: [RT] Starting 2.2 (was going to be The Project Formerly KnownAs Cocoon)
Tony Collen wrote: Nicola Ken Barozzi wrote: Maybe start 2.5, just to be in line with Linux? ;-P Screw that, let's just skip a couple major versions, everyone's doing it now, how does Cocoon 5.0 look? :) Better yet, let's just change the name alltogether: Cocoon XP Cocoon MX Cocoon MX 2004 I just love Macromedia, at least they admit MX doesn't mean anything: What does MX mean? The MX moniker is not an acronym and doesn't have a literal translation. What about renaming the next release to an unpronounceable set of symbols, like Prince, or that Led Zepplin album? I'd suggest !#. In all seriousness, I'm all for 2.2, but what sorts of loose ends are there that could be tied up for 2.1.x? Howabout a push to clear out some bugs from bugzilla? Me too, but a push for bug fix (and I'd like to see a docs blitz) wouldn't need to hold up creating the repository and working out the best way of working two trees at once would it? By the way, I thought we were planning on breaking from ECM in 2.2 because it would make blocks easier among other great benefits. Is this still a thought? That would certainly make a new repo an attractive thing. Geoff
Re: [RT] Starting 2.2
Jay Freeman (saurik) wrote: Has any thought been put into the next time we have to create another new repository should be the day we look into better version control? Amen! Personally I'd +1 the subversion switch in any moment. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RT] Starting 2.2 (was going to be The Project Formerly KnownAs Cocoon)
Geoff Howard wrote: What about renaming the next release to an unpronounceable set of symbols, like Prince, or that Led Zepplin album? I'd suggest !#. How about: Cocoon Interrobang It would be pronounced, Cocoon?! In all seriousness, I'm all for 2.2, but what sorts of loose ends are there that could be tied up for 2.1.x? Howabout a push to clear out some bugs from bugzilla? Me too, but a push for bug fix (and I'd like to see a docs blitz) wouldn't need to hold up creating the repository and working out the best way of working two trees at once would it? Hrm, actually a docs push would be more like it, since I was prodded by a few people to do up some nice InputModule docs, so I am guilty as charged :) I just didn't want to see new stuff get started and have older issues unresolved. I don't see why we'd need to postpone a new repository, really, I'd just hate to see things forgotten about. Side note: Is a build of 2.1.x or 2.2 going to be using the new forrest-style skins for the docs anytime soon? It's kind of nasty seeing the old site design when I build docs from the current CVS. By the way, I thought we were planning on breaking from ECM in 2.2 because it would make blocks easier among other great benefits. Is this still a thought? That would certainly make a new repo an attractive thing. I'm not a hugely knowledgeable on Avalon, so I'm not sure about the issues surrounding it. Just when I thought I'd start to learn Avalon stuff, the carpet gets pulled out from under me! :) Regards, Tony
Re: [RT] Starting 2.2
Timothy Larson wrote: I also wondered about Subversion when the repositories started multiplying :) Is this a possibility? Is there a good CVS-Subversion repository converter? What's good? The Subversion project has a converter, last time I checked they said it still can't convert branches, and that this was *the* killer for declaring SVN to be production ready. Trunk only CVS repositories seem to work for a long time already (disclaimer: gathered from various messages, I didn't try personally). J.Pietschmann
Re: [RT] Starting 2.2
J.Pietschmann wrote: Timothy Larson wrote: I also wondered about Subversion when the repositories started multiplying :) Is this a possibility? Is there a good CVS-Subversion repository converter? What's good? The Subversion project has a converter, last time I checked they said it still can't convert branches, and that this was *the* killer for declaring SVN to be production ready. Trunk only CVS repositories seem to work for a long time already (disclaimer: gathered from various messages, I didn't try personally). Hmm. Do we still have a test server available? The last time I played with SVN, the Windows client was a bit buggy. However that was roughly a year ago. I'm sure it has gotten better since then. -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
Re: [RT] Starting 2.2
Berin Loritsch wrote: What's good? The Subversion project has a converter, last time I checked they said it still can't convert branches, and that this was *the* killer for declaring SVN to be production ready. Trunk only CVS repositories seem to work for a long time already (disclaimer: gathered from various messages, I didn't try personally). Hmm. Do we still have a test server available? The last time I played with SVN, the Windows client was a bit buggy. However that was roughly a year ago. I'm sure it has gotten better since then. Look at: http://cvs.apache.org/repos/asf/ On infrastructure@ there was an email describing how to add yourself to the right passwd file (with htpasswd). I don't know how sensible that information is, so I'd rather not write it here. Just contact me if you feel lik playing around. :-) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RT] Starting 2.2 (was going to be The Project Formerly KnownAs Cocoon)
Tony Collen wrote: Geoff Howard wrote: What about renaming the next release to an unpronounceable set of symbols, like Prince, or that Led Zepplin album? I'd suggest !#. How about: Cocoon Interrobang It would be pronounced, Cocoon?! Actually, my proposal could be pronounced bang and pound which might not be positive... In all seriousness, I'm all for 2.2, but what sorts of loose ends are there that could be tied up for 2.1.x? Howabout a push to clear out some bugs from bugzilla? Me too, but a push for bug fix (and I'd like to see a docs blitz) wouldn't need to hold up creating the repository and working out the best way of working two trees at once would it? Hrm, actually a docs push would be more like it, since I was prodded by a few people to do up some nice InputModule docs, so I am guilty as charged :) I just didn't want to see new stuff get started and have older issues unresolved. I don't see why we'd need to postpone a new repository, really, I'd just hate to see things forgotten about. Agreed. Side note: Is a build of 2.1.x or 2.2 going to be using the new forrest-style skins for the docs anytime soon? It's kind of nasty seeing the old site design when I build docs from the current CVS. I asked about this before and got the impression that some people are getting the forrest look. Near as I can tell, it falls back to the old xml.apache metal look if forrest is not downloaded at ../xml-forrest or as specified in build.properties? So far I've been too lazy to confirm. I'd much rather be able to import the stylesheets, etc. which would be needed but I've been too lazy for that as well. By the way, I thought we were planning on breaking from ECM in 2.2 because it would make blocks easier among other great benefits. Is this still a thought? That would certainly make a new repo an attractive thing. I'm not a hugely knowledgeable on Avalon, so I'm not sure about the issues surrounding it. Just when I thought I'd start to learn Avalon stuff, the carpet gets pulled out from under me! :) Hopefully it's not as bad as that. Avalon's not going away, just the implementation that's changing... Geoff
Pretty Printing Output HTML
Is there a way with cocoon to make the final output of HTML to the browser be pretty printed with spaces and proper wrapping. I would like this for debugging reasons. -- Robert
Re: Pretty Printing Output HTML
Robert Simmons wrote: Is there a way with cocoon to make the final output of HTML to the browser be pretty printed with spaces and proper wrapping. I would like this for debugging reasons. Robert, This is an oldie but goodie; http://cocoon.apache.org/2.0/faq/faq-xslt.html AFAIK the ability to do this was disabled on purpose. Regards, Tony
Re: [Proposal] Simple production build directions
Timothy Larson [EMAIL PROTECTED] wrote: Thanks for the suggestion. I added the proposal to the wiki here: http://wiki.cocoondev.org/Wiki.jsp?page=ProductionInstallProposal I won't edit that file but I would like to add here my suggestion about cocoon-2.1 build system, in general. I try to contribute to Cocoon project as much as I can and I hope my 2 cents will help you improve that great product Coocoon is. According to my expirence some issues make building uncomfortable. These issues are: 1. customconf property doesn't work properly at my linuxbox :( I have some .xweb, .xconf and .xmap files in 'myconf' directory but they are not seen by buildtools when 'myconf' is outside cocoon source directory. customconf=../myconf - doesn't work. after moving it into cocoonsrc dir ($ mv ../myconf .) and changing customconf in local.build.properties to: customconf=myconf everything works fine. Of course file permis and modes are ok. Is this a bug? 2. The second issue that is annoying for me is that the distribution build.sh is so little parametrized. There should be a possibility for invoking build.sh with local.build.properties and local.blocks.properties as parameters ($2, $3), for example: .build.sh webapp ../myconf/mywebapp.build.properties \ ../myconf/mywebapp.blocks.properties I think this is a must. 3. Next issue is prepare-webapp target. Lets say I have some 'initial' dirs and files in ../mywebapp: ../mywebapp/content/ ../mywebapp/content/welcome.xml ../mywebapp/logic/ ../mywebapp/style/ ../mywebapp/style/images/ ../mywebapp/style/javascripts/ ../mywebapp/style/javascripts/system/ ../mywebapp/style/javascripts/system/error.js ../mywebapp/style/stylesheets/ ../mywebapp/style/stylesheets/welcome.xsl ../mywebapp/style/stylesheets/system/ ../mywebapp/style/stylesheets/system/error.xsl ../mywebapp/WEB-INF/ ../mywebapp/WEB-INF/.. -- here the same files as in src/webapp/WEB-INF but this is not the way I'd like Of course I do default pipelines substitute by xpatch at ../myconf/pipelines.xmap: xmap xpath=/sitemap remove=/sitemap/pipelines if-prop=config.pipelines map:pipelines !-- ... mypipelines here ... -- /map:pipelines xmap webapp property of local.build.properties seemed promising at first, but then I realized that webapp-build.xml copies only specific files and directories that are in distribution (file per file). So I can't change the layout of my brand new built webapp :( I think prepare-webapp target should copy to build.webapp dir: 1) only WEB-INF/ from src/webapp 2) probably also samples from src/webapp (if exclude.webapp.samples not true) 3) and then copy whole directory set by 'webapp' property (../mywebapp) - overwriting .xfiles if any i mywebapp, - combining ../mywebapp/WEB-INF/classes with build/webapp/WEB-INF/classes - combining ../mywebapp/samples with samples etc.. This just my idea. 4. I really don't understand why src/blocks/databases/conf/datasources.xconf is in databases block, not in hsqldb block. If that node is to be an example for database usage - it should be a) commented out and probably b) configured to example a more common database (propably these one's that that drivers are included by local.build.properties) datasources !-- jdbc name=postgres pool-controller min=5 max=10/ auto-committrue/auto-commit dburljdbc:postgresql://localhost:5432/test?charSet=UTF-8/dburl user/user password/password /jdbc -- /datasources 5. src/blocks/databases/conf lacks still popular mysql.Driver.xweb. I know PostgreSQL is much better, but... --- Going back to production build setup - I generally agree with ProductionInstallProposal that are at wiki right now, but I have some additional remarks: a) WHEN any of include.driver.* is set to true, corresponding commented out datasource included by databases/conf/datasources.xconf SHOULD BE uncommented then b) shouldn't be config.enable-uploads set to true? --- If 1, 2, 3, 4, 5 and a) where implemented - the build system would be just ideal for me :) -- Tomasz Nowak Netventure, http://www.netventure.pl/
AW: We want to donate a XML / Cocoon / EJB / WebStart - based CMS
we've developed a XML-based Content Management System based on different technologies like Cocoon, XML, EJB and a WebStart Client Application. It is in our interest, that we contribute this project with about 200.000 Lines of Code to the Apache Foundation. 200.000? Impressive, I just checked and Cocoon is 350.000... Yes, but with the normal quotes. Just the work of one year :) The project is existing since one year at our company as a closed source application. We've already running many websites with the CMS', but it was one of the major interests of our initial customer, that we will open the source for everyone. This is interesting, could you elaborate? Should I gather that your company doesn't have an interest to open source it and that it's just because of a customer of yours that you're considering it? I'm honestly curious, I have a deep personal interest in Open Sourcing dynamics. No, it is also in our interest, you're right :) It is a little bit of we want to give the community something back, something of reputation, some interest of good ideas of other developers and so on. Putting the site online would help. :-) I'm trying since this morning, but it's always unavailable. Sorry, this was a server error - it is just fixed now: http://conquest.juwimm.net/cocoon/cms/conquest/conquest Regards, Sascha
Re: We want to donate a XML / Cocoon / EJB / WebStart - based CMS
Sascha-Matthias Kulawik wrote: we've developed a XML-based Content Management System based on different technologies like Cocoon, XML, EJB and a WebStart Client Application. It is in our interest, that we contribute this project with about 200.000 Lines of Code to the Apache Foundation. 200.000? Impressive, I just checked and Cocoon is 350.000... The project is existing since one year at our company as a closed source application. We've already running many websites with the CMS', but it was one of the major interests of our initial customer, that we will open the source for everyone. This is interesting, could you elaborate? Should I gather that your company doesn't have an interest to open source it and that it's just because of a customer of yours that you're considering it? I'm honestly curious, I have a deep personal interest in Open Sourcing dynamics. So let me know how I can show you how powerful this project is and how I can convince you to become the CMS a subproject of one of your projects. Putting the site online would help. :-) I'm trying since this morning, but it's always unavailable. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: We want to donate a XML / Cocoon / EJB / WebStart - based CMS
Sorry, this was a server error - it is just fixed now: http://conquest.juwimm.net/cocoon/cms/conquest/conquest It is broken. Andreas
Re: Vote for Cocoon on the O'Reilly Open source Directory.
Robert Simmons wrote: Go vote http://www.osdir.com/Downloads-req-ratedownload-lid-11-ttitle-Cocoon.html Hmmm - the description is taken from the 2.0 site, and no wonder -- the link is to http://xml.apache.org/cocoon -- http://cocoon.apache.org/2.0/ Who can fix that redirect now that 2.1 is released? And anyone know if we can fix the blurb at osdir.com? Geoff P.S. does being a committer disqualify me from voting since they reqest not voting for your app?
Re: Vote for Cocoon on the O'Reilly Open source Directory.
Geoff Howard wrote: Robert Simmons wrote: Go vote http://www.osdir.com/Downloads-req-ratedownload-lid-11-ttitle-Cocoon.html Hmmm - the description is taken from the 2.0 site, and no wonder -- the link is to http://xml.apache.org/cocoon -- http://cocoon.apache.org/2.0/ Who can fix that redirect now that 2.1 is released? And anyone know if we can fix the blurb at osdir.com? Geoff P.S. does being a committer disqualify me from voting since they reqest not voting for your app? Oh, and we should see about being re-classified. We're in web publishing and should probably be here: http://www.osdir.com/Downloads-req-viewsdownload-sid-11.html Geoff
Cocoon in Business Environements and its shortfalls
I wanted to open a general discussion thread on the shortfalls of Cocoon in business environments. I have some very clear opinions on the matter, but then my opinions are just that -- opinions. Others may differ with me. First of all, I should say that I have a very direct, a-political, style that sometimes treads on toes unintentionally. Trust me when I say that if I thought Cocoon was a piece of junk, I would say so. As a matter of fact I think it is an excellent product with some shortcommings like all products have. However, Im not particularly into ra-ra chearleading so I tend to only point out things I see as deficiencies. In addition, Im not opposed to putting my time where my mouth is so long as what I would contribute is feasible without 2 months of study to understand the source base. Back to the subject at hand. If we analyze the shortcommings in a business environment, we can potentially plan out strategies to make Cocoon leap from a sometimes used app to something as ubiquitous as ant or Apache web server. This is a leap from pure open source to business ready open source and is not an easy one. I will start by stating my issues with cocoon as is: 1) Production builds are lacking. What I mean by this are builds that a developer would use if he is USING cocoon and not developing on it at all. 1a) One might object that blocks have to be described dureing the build process. This could be true but needs to change. The ideal solution is that someone cha drop in a block into the blocks directory post build and then indicate the block in the sitemap. This would allow a binary build that would give users the chance to merely delete blocks that they are not interested in and add their own blocks to a binary build. 1b) Examples for blocks need to be out of the blocks themselves. In my opinion, the only thing in the blocks directory should be the blocks jars themselves and perhaps something akin to a deployment descriptor for the blocks in the directory. Examples should be in a completely different locations. 2) Monitoring is not intuitive. If you are deploying a business application with 20 cocurrent Cocoon instances, you need a way to cohesively monitor the health of the entire cluster. Separate log files just arent sufficient. Something like JMX instrumentation would be ideal. 3) Cocoon needs cluster management and load balancing functionality. You should be able to set up a cluster of cocoon instances that know about each other and have them perform load balancing and failover. This needs to be established at the cocoon level because the servlet engine wont have information about how busy cocoon is. For example, a cocoon instance getting a single reuest per second might be more busy than one getting 20 requests per second because that single request takes lots more processing time and resources. 4) Cocoon documentation is minimal and non-cohesive. (But you knew this already) Although wiki is good for knowledge sharing, the information in Wiki is oftewn out of date and its reliability is sometimes questionable. 5) Performance. Cocoon needs to have some routines gone over with a fine tooth comb for performance reasons. Think of deploying cocoon in a 100 concurrent user environment and having it take the load. Things Id like to see include URL per-caching at startup, pipeline timing for performance tuning and component execution timing. If these items were instrumented with JMX it would be even better. Issues Im not privy to directly but concerned about: 6) Project Lint. Over time any project accumulates an amount of lint in the form of dead code, unused classes and unused methods. How much of this is in cocoon and how can we get it out? Comments? Additions? Suggestions? (Please route flames to /dev/null). -- Robert
Re: [Proposal] Simple production build directions
Switching back to users, as the feedback we need is really for them. Any developers (besides me) interested please follow over there, and whoever responds to this, please remove dev from the to: field. Timothy Larson wrote: --- Geoff Howard [EMAIL PROTECTED] wrote: It will be easy to add a new build target production-seed (or something to that effect) which would set those values and perform other steps as needed. This would change the instructions to 1) edit blocks properties 2) ./build.sh production-seed. Would that be better in your mind, or is a sample properties better? I can see positives with both solutions. I lean toward a example properties file, because that introduces the customization system that Cocoon uses. I updated to proposed text to refer to the production.build.properties as an example file: To make a production build without the documentation, samples, scratchpad, or deprecated code simply copy the example production.build.properties file to local.build.properties before going on to step 3. See below if you are rebuilding or wish to further customize the build. Ok, point well taken and I agree this will work the best. This is not really what was asked for orginally though -- will this be perceived as any better than the current state? The benefit is that the less-often modified properties will be removed from this file to reduce the shock of wading through so much that doesn't need to be understood. Still, I'll experiment with a build target that would load these defaults without the file-rename step which may scratch the other itch. The key is not how to accomplish it (because the pieces are already in place in the build to do either), but _what_ to accomplish. The example production build does not have to be perfect for everybody, just reasonable and relatively secure. We already have the customization instructions for making it perfect. Also, are there other config issues can be agreed on for this target/recommended setting? Logging level? Allow/Deny uploads? The default log level is already INFO, which is a reasonable default. A default setting of Deny uploads is the most secure. I agree on the uploads, but INFO will really be too verbose for production for most people, don't you think? It will contain every component lookup, every step of every access, etc. Perhaps as developers we've too much treated INFO as FINE, but that's too late to change. I'd strongly suggest WARN or ERROR. Perhaps we should add these two settings to the example production build properties file, since they are among the most likely to be customized: # Configuration #config.enable-uploads=true # Webapp Build Properties build.webapp.loglevel=INFO Yes, that's the way to do it. The values can change as we come to consensus of course. Geoff
