Re: [RT] Starting 2.2
Yeah, the Win32 client used to have all kinds of / vs. \ issues and they tended to break the build a lot. However, nowadays, the windows client (at least the command line one, which is what I first thought you meant) works quite well. RapidSVN (a Win32 GUI) is probably buggy as all hell still. However! TortoiseSVN (a Win32 shell extension) works extremely well. When I'm not using the command line client that's what I now use (and what I set up the few other developers at Gnostic Labs with when I finally switched us over to Subversion a week or two ago). As for the CVS to Subversion repository importer, it seems to at least partially support branches. BUT, it doesn't seem to support the Cocoon2 repository somehow. *Got it out of rsync earlier and let it sit for an hour or something converting.* I'm working on looking at the input, generated dump file, and partial output to try to figure out what's going wrong (it has something to do with a branch where some files got added to the branch later and then got deleted and it doesn't know they weren't int the branch to begin with for whatever reason). Sincerely, Jay Freeman (saurik) [EMAIL PROTECTED] - Original Message - From: Berin Loritsch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 28, 2003 3:30 PM Subject: 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: Pretty Printing Output HTML
Robert Simmons wrote: Uhh .. I dont get how that FAQ answers me. I dont need the pretty print in production, just in development. It would be cool if I could use a cocoon view to do it. This would be more to the point: http://cocoon.apache.org/2.1/userdocs/serializers/xml-serializer.html See parameter 'indent'. Never tried it though myself. Vadim -- Robert Tony Collen [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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: [RT] Implementing Cocoon Blocks
Getting the ball rolling on Phase One...
Stefano Mazzocchi wrote:
This is a collection of (more or less) random thoughts about the
implementation of Cocoon Blocks that I collected while talking with
Ricardo and Sylvain IRL.
Please note that anything proposed here, while organic and workable, is
not to be considered carved in stone, but rather a suggestion on how to
move forward.
...
File System Layout and wiring data
--
...
The deployment process added the mounting, wiring and configuration
information
cob:mycompany.com/webmail/1.3.43
located at - WEB-INF/blocks/384938958499
mounted on - /mail/
external-skin - cob:yetanothercompany.com/skins/fancy/1.2.2
internal-skin - cob:mycompany.com/skins/corporate/34.3.345
repository - cob:mycompany.com/repositories/email/exchange/3.2.1
configured as:
user - guest
password - sj3u493
cob:mycompany.com/repositories/email/exchange/3.2.1
located at - WEB-INF/blocks/394781274834
configured as:
host - mail.blah.org
cob:yetanothercompany.com/skins/fancy/1.2.2
located at - WEB-INF/blocks/947384127832
cob:mycompany.com/skins/corporate/34.3.345
located at - WEB-INF/blocks/746394782637
the file system layout (relative to the cocoon webapp context) is
[-] WEB-INF
L___ [-] blocks
L___ wiring.xml
L___ [-] 384938958499
| L___ [-] BLOCK-INF
| | L___ block.xml
| L_ (the contents of cob:mycompany.com/webmail/1.3.43)
L___ [-] 947384127832
| L___ [-] BLOCK-INF
| | L___ block.xml
| L_ (the contents of
cob:yetanothercompany.com/skins/fancy/1.2.2)
L___ [-] 746394782637
| L___ [-] BLOCK-INF
| | L___ block.xml
| L_ (the contents of
cob:mycompany.com/skins/corporate/34.3.345)
L___ [-] 394781274834
L___ [-] BLOCK-INF
| L___ block.xml
L_ (the contents of
cob:mycompany.com/repositories/email/exchange/3.2.1
where
wiring.xml contains the block IDs (which also identifies their location
on disk) wiring, mounting and configurations.
block.xml contains the block metadata (which belong to the block and
cannot be changed at deployment time).
NOTE: if the location path of the block is relative, it is searched by
starting from the cocoon war context. The block content is *always*
extracted from the archives and saves as is inside the folder.
NOTE (development time): in order to simplify block creation and
development, it will be possible to explicity indicate the location of
an already existing and extracted block implementation on disk. The
block manager should also have autoreloading features (configurable, of
course) that should reload the configurations, the wiring and the
exposed components when they are changed.
...
Implementation Phases
-
Phase 1: definition of the contract between the block manager inside
cocoon and the standalone block deployer. These contracts include:
1) description of the file system layout (see above for a suggestion)
2) description of the wiring document schema
3) description of the block metadata schema
Ok, the file system seems fine - how about starting the discussion with
the following for the wiring document? (I'm assuming stuff will have to
change - just trying to get the ball rolling)
?xml version=1.0 encoding=UTF-8?
blocks version=1.0
block uri=cob:mycompany.com/webmail/1.3.43 wire-id=384938958499
mount/mail//mount
connections
connection
name=external-skincob:yetanothercompany.com/skins/fancy/1.2.2/connection
connection
name=internal-skincob:mycompany.com/skins/corporate/34.3.345/connection
connection
name=repositorycob:mycompany.com/repositories/email/exchange/3.2.1/connection
/connections
configuration
param name=userguest/param
param name=passwordsj3u493/param
/configuration
/block
block uri=cob:mycompany.com/repositories/email/exchange/3.2.1
wire-id=394781274834
configuration
param name=hostmail.blah.org/param
/configuration
/block
block uri=cob:yetanothercompany.com/skins/fancy/1.2.2
wire-id=947384127832/
block uri=cob:mycompany.com/skins/corporate/34.3.345
wire-id=746394782637/
/blocks
Wiki'd here: http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring
For sake of discussion, I recorded a wire-id instead of the location.
Can blocks be in other locations other than WEB-INF/blocks/{$wire-id} ?
I also considered recording the wire-id instead of the uri for
connections between blocks - what are the arguments for each?
connection was out of the blue using the wiring metaphore. Other
options? Free association: connect, attach, solder, wire, use ...
Is it wise to limit configurations to name-value pairs, or should that
allow arbitrary foreign xml markup?
For configuration, should a distinction be made between any
Re: WG: We want to donate a XML / Cocoon / EJB / WebStart - based CMS
Sascha-Matthias Kulawik said: 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. To continue on Steve's pessimistic intro to Apache incubations, perhaps you need some encouragements; 1. Put it up on SourceForge, or perhaps some other place such as CodeHaus. 2. Get the OSS structure in place, licenses, documentation, committers, evolution and so on... 3. Market the package. I'm sure that OSS mailing lists are tolerant to occassional OSS marketing. 4. Some indviduals typically shows an interest (if your stuff is good enough). Try to tie them into the project, perhaps by helping out with testing, documentation, installation procedures and more. 5. Some individuals wants extra features, if it is not available, try to encourage them to add these features themselves. Tell how it should/could be done, and be very helpful. If they manage, grant committer status more easily than Apache generally does. 6. Then come back to Apache. If you at such time have half a dozen external committers (who has contributed and understand the codebase to a reasonable degree), documentation, and overall an healthy project, it is more likely for it to be accepted. Also, your customer wants the project to go OSS, which IMHO is a GOOD THING (tm), but Apache is not equivalent with OSS. Cocoon founder, Stefano, has a remarkable attitude to OSS projects; Bad Code, Great Ideas = Good Community. Indirectly it also means that production quality code has a harder time to gather good community, since the codebase is better than BAD. Cheers. Niclas
[RT] Cocoon Distro support
Hi all, the recent comments about production build and binary builds have caused me to think about Cocoon Distros and what must core Cocoon do to allow for Cocoon Distros from 3rd parties. Since this overlap quite a degree with the average Cocoon user's need of upgrade running systems, I think it is desirable to start a discussion. Currently I see these hurdles; * Block Modularization. * cocoon.xconf Management * Sitemap Management. Block Modularization. This is an on-going effort, but I have a few things I would like to clarify. Blocks are NOT ONLY CODE! IMHO, Blocks are the traditional JAR based resources (classes, bundles, etc), but more importantly(!) documentation of the block, meta-data (see Avalon discussions), examples, source code (optional) and so on. And all of that should be wrapped in a single container... That container should be sealed and I shouldn't need to know anything about the internal content, and if Cocoon needs to expand it, it can do so anywhere with my knowledge about it. Internally there is a default configuration file, but by putting an external config file at the same place, it will override the defaults, preferably merged. Security is another concern. Do I trust any blocks? NO, therefor the security policy is declared per block externally, but the default in Cocoon should be pretty restrictive (like no write or network permissions). cocoon.xconf Once the Block Modularization is in place, it will have addressed these aspects, and very little I hope will remain in this file. So if all Block related stuff is removed, and we are down to Core funcationality, I think a Distro maker can handle this file fairly easily. Sitemap Management I would like to see a minimalistic sitemap, basically only containing the AutoMount of all directories' sub-sitemaps. The question is whether the component declarations should be in the main sitemap or not. I think maybe not. The main argument here is Start simple, expand on demand. The elaborate main sitemap today can still be around as a sub-sitemap in the elaborate/ directory... Block Modularization probably need to address sitemap declarations as well, with a formal way of defaults being added automatically and other sitemap declaration should perhaps be adjacent to the Block and not to the sitemap, after all keeping the Block stuff at the Block makes more sense to me. Bottom line; Cocoon is about to broken into smaller, more managable pieces. This will easier allow 3rd parties to package Cocoon into nice binary distros. Comments? Niclas
DO NOT REPLY [Bug 22809] New: - Cocoon+resin work error in linux,but work correctly in windows 2000
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=22809. 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=22809 Cocoon+resin work error in linux,but work correctly in windows 2000 Summary: Cocoon+resin work error in linux,but work correctly in windows 2000 Product: Cocoon 2 Version: 2.0.4 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: sitemap components AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have install cocoon 2.0.4+resin2.0.10+apache2+j2sdk1.4.0 in win2k,it work correctly,but I startup cocoon in linux ,it startup error!(redhat linux 9+ j2sdk1.4.0_1 + apache2 + cocoon 2.0.4) The following is error information: who can help me. Cocoon 2 - Internal server error type fatal message Language Exception description org.apache.cocoon.ProcessingException: Language Exception: org.apache.cocoon.components.language.LanguageException: Error compiling sitemap_xmap: Line 1816, column 38: ';' expected Line 2403, column 10: illegal start of expression Line 4690, column 91: ')' expected Line 7668, column 44: unclosed character literal Line 7668, column 42: ')' expected Line 7878, column 11: expected Line 9324, column 58: expected Line 9324, column 79: expected Line 9324, column 91: expected Line 9324, column 110: expected Line 9324, column 124: expected Line 9326, column 6: illegal start of type Line 9330, column 28: expected Line 9331, column 10: illegal start of type Line 9333, column 8: illegal start of type Line 10328, column 34: ';' expected Line 10737, column 15: ';' expected Line 11835, column 5: '}' expected Line 7466, column 36: class EventPipelne not found in class org.apache.cocoon.www.sitemap_xmap Line 7878, column 4: class priate not found in class org.apache.cocoon.www.sitemap_xmap Line 9716, column 36: class SiteapRedirector not found in class org.apache.cocoon.www.sitemap_xmap.. Line 10532, column 19: class ConectionResetException not found in class org.apache.cocoon.www.sitemap_xmap.. Line 11565, column 36: class EventPpeline not found in class org.apache.cocoon.www.sitemap_xmap.. Line 9330, column 21: cannot access class remove; file listOfMaps/remove.class not found Line 1165, column 18: method lod_component(int, java.lang.String, java.lang.String, org.apache.avalon.framework.configuration.DefaultConfiguration, java.lang.String) not found in class org.apache.cocoon.www.sitemap_xmap Line 2389, column 15: variable matcher_N10956_expr not found in class org.apache.cocoon.www.sitemap_xmap Line 2785, column 15: variable pipelne not found in class org.apache.cocoon.www.sitemap_xmap Line 3175, column 25: method error_process_1_500(org.apache.cocoon.sitemap.SitemapRedirector, org.apache.cocoon.environment.Environment, java.util.Map, java.lang.Exception, boolean) not found in class org.apache.cocoon.www.sitemap_xmap Line 3236, column 19: class ResourceNtFoundException not found in class org.apache.cocoon.www.sitemap_xmap Line 3866, column 25: method error_process_7_500(org.apache.cocoon.sitemap.SitemapRedirector, org.apache.cocoon.environment.Environment, java.util.Map, java.lang.Exception, boolean) not found in class org.apache.cocoon.www.sitemap_xmap Line 3510, column 8: method matchN1069C(org.apache.cocoon.sitemap.SitemapRedirector, org.apache.cocoon.environment.Environment, org.apache.cocoon.components.pipeline.StreamPipeline, org.apache.cocoon.components.pipeline.EventPipeline, boolean, java.util.List) not found in class org.apache.cocoon.www.sitemap_xmap Line 3518, column 8: method matchN106AB(org.apache.cocoon.sitemap.SitemapRedirector, org.apache.cocoon.environment.Environment, org.apache.cocoon.components.pipeline.StreamPipeline, org.apache.cocoon.components.pipeline.EventPipeline, boolean, java.util.List) not found in class org.apache.cocoon.www.sitemap_xmap Line 3524, column 8: method matchN106B7(org.apache.cocoon.sitemap.SitemapRedirector, org.apache.cocoon.environment.Environment, org.apache.cocoon.components.pipeline.StreamPipeline, org.apache.cocoon.components.pipeline.EventPipeline, boolean, java.util.List) not found in class org.apache.cocoon.www.sitemap_xmap Line 3532, column 8: method matchN106BF(org.apache.cocoon.sitemap.SitemapRedirector, org.apache.cocoon.environment.Environment, org.apache.cocoon.components.pipeline.StreamPipeline, org.apache.cocoon.components.pipeline.EventPipeline, boolean, java.util.List) not found in class org.apache.cocoon.www.sitemap_xmap Line 3538, column 8: method matchN106CB(org.apache.cocoon.sitemap.SitemapRedirector,
Re: WG: We want to donate a XML / Cocoon / EJB / WebStart - basedCMS
Niclas Hedhman wrote, On 29/08/2003 6.51: Sascha-Matthias Kulawik said: 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. To continue on Steve's pessimistic intro to Apache incubations, perhaps you need some encouragements; 1. Put it up on SourceForge, or perhaps some other place such as CodeHaus. I would not recommend CodeHaus if they want to later apply for Apache, as it does not follow the same community rules as Apache. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] Implementing Cocoon Blocks
On Wednesday, Aug 27, 2003, at 11:35 Europe/Rome, Christian Haul wrote: Which is the whole point of my mail. Don't use dependency ranges, use metadata specifying capabilities and requirements for this. I think you greatly underestimate the complexity of the approach you are proposing. Last thing I want is to enter the ontology problem space. But in case I'm missing your point, please provide an explicit example. -- Stefano.
Re: [RT] Blocks and Really Making them Work
On Wednesday, Aug 27, 2003, at 14:39 Europe/Rome, Berin Loritsch wrote: [snip] I would start with something like this, and see how far it can take you--and if there are new features required, add them. This is (more or less) what I was planning to implement ;-) -- Stefano.
Re: [RT] Improving Sitemap and Flowscript
On Wednesday, Aug 27, 2003, at 17:41 Europe/Rome, Nicola Ken Barozzi wrote: Calling a resource, inserting a virtual pipeline and using the cocoon: protocol are for most uses equivalent. I agree when you say that since the introduction of the cocoon: protocol, map:resource is now redundant (and less appealing, as well). In fact, we could go as far as saying that map:resource is no longer needed and could be deprecated. This would leave us only with pipelines, components and virtual components (which are, in fact, typed pipeline fragments), and the cocoon: protocol to mix them, if needed. What remains is the views part, that has introduced pipeline-stage metadata, as a label. It's an aspect that gets called when that particular condition is met IOW, I'm rephrasing, using different terminology, that a view is an orthogonal mechanism, that interacts with the normal sitemap using some metadata and an exit pipeline. The labels are effectively metadata, as they describe the pipeline. The exit pipelines, ie the views themselves, are what has to be done. Yes, views are orthogonal pipelines. (I won't use AOP terminology that I personally don't yet like) See, I don't like it too! ;-) well, when you propose something like map:aspects it seems AOP-ish enough for me ;-) that's not coherent with the above. So we can generalize it, and add configurability to the view mechanism to specify other conditions. Thus views effectively insert pipeline fragments at a certain condition. In fact they insert their contents after a label. So the label is the condition. I know it's a matter of terminology pickyness, but I disagree. The condition that triggers the view is the view request. The result of this condition is the execution of the pipeline that is 'instrumented' to route its output somewhere else (to the view, which can now be seen as a virtual serializer) *first proposal* I propose that we define other conditions. map:view name=content from-label=content map:serialize type=xml/ /map:view becomes: map:view name=content type=from-label test=content map:serialize type=xml/ /map:view This makes it possible to make a different position where to start from... What can also be made configurable is *when*, in which condition, it's triggered, but the logic has to be inverted. What I mean here is that views are triggered only by the user. Normal results are done *without* calling views. So if I want to say: insert a logger after each generator, I cannot do it easily, as I would have to call a logger-view for it to be called. And I would have only one possible insertion per pipeline, as only one view is called at a time. ok, now I get it Now we say: when the view is triggered, start at a label After it could be: when the view is triggered, start at position Instead we need: when the position is met, check if it has to be triggered. Here is an example that uses this inverted AOPish system for views. Let me rephrase this: the following is a way of defining views in a more generic way. Here I don't say anymore: when the user asks for a view trigger the label (or more generic as in the first proposal) condition, but at every stage check if a condition is met, and if so execute the generalized view. hm *second proposal* Make it possible to tell Cocoon to add pipeline snippets (ie virtual pipelines) given certain rules. This makes it possible to have views be made with this more generic mechanism. The following adds two aspects: - an aspect gets called from every content position and gathers links. - the other one gets called from every content position. If the request has a cocoon-view=links, then the links are serialized. map:aspects map:aspect type=from-label test=content !-- Any required link munging -- map:transformer type=gather-links/ /map:aspect map:aspect type=from-label test=content map:action type=request-param map:param name=cocoon-view value=link map:serializer type=links/ /map:action /map:aspect /map:aspects you are using AOP the micro-granular way. This is: remove crosscutting by making all overlapping aspect objects and compose them together. I tend to dislike this practice since it leads, IMHO, to poor readability (users don't have the vision of crosscutting concerns that we developers do, and they perceive it as unnecessary overcomponentization) a critic to the above is: why would you want to gather-links if you are not going to serialize them? You are suggesting that a more general aspect-oriented approach to pipeline composability might be general enough to allow views to be replaced by such a more powerful approach. I agree. What I don't understand is why we should give away a perfectly fine system for a new flexibility we don't need. [note how I avoided to named this FS even if I was very tempted to do so ;-)] This would make it very easy to add security-based
Re: WG: We want to donate a XML / Cocoon / EJB / WebStart - based
Codehaus is another community, I'm sure its rules aren't exactly the same. The information on the web site claims to place a firm priority on the production of useful code, and less on non-coding exercises such as voting, committee-forming and proposal-writing. Why would that have an affect on the hosted project's potential future with Apache? -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net Nicola Ken Barozzi wrote: I would not recommend CodeHaus if they want to later apply for Apache, as it does not follow the same community rules as Apache.
Re: [RT] Cocoon Distro support
You've read my mind, didn't you? ;-) Seriously, I think you've brought many things down to the point. Specifically the security issues you've mentioned were given too less attention before. Good work, I like it! -- Andreas Niclas Hedhman wrote: Hi all, the recent comments about production build and binary builds have caused me to think about Cocoon Distros and what must core Cocoon do to allow for Cocoon Distros from 3rd parties. Since this overlap quite a degree with the average Cocoon user's need of upgrade running systems, I think it is desirable to start a discussion. Currently I see these hurdles; * Block Modularization. * cocoon.xconf Management * Sitemap Management. Block Modularization. This is an on-going effort, but I have a few things I would like to clarify. Blocks are NOT ONLY CODE! IMHO, Blocks are the traditional JAR based resources (classes, bundles, etc), but more importantly(!) documentation of the block, meta-data (see Avalon discussions), examples, source code (optional) and so on. And all of that should be wrapped in a single container... That container should be sealed and I shouldn't need to know anything about the internal content, and if Cocoon needs to expand it, it can do so anywhere with my knowledge about it. Internally there is a default configuration file, but by putting an external config file at the same place, it will override the defaults, preferably merged. Security is another concern. Do I trust any blocks? NO, therefor the security policy is declared per block externally, but the default in Cocoon should be pretty restrictive (like no write or network permissions). cocoon.xconf Once the Block Modularization is in place, it will have addressed these aspects, and very little I hope will remain in this file. So if all Block related stuff is removed, and we are down to Core funcationality, I think a Distro maker can handle this file fairly easily. Sitemap Management I would like to see a minimalistic sitemap, basically only containing the AutoMount of all directories' sub-sitemaps. The question is whether the component declarations should be in the main sitemap or not. I think maybe not. The main argument here is Start simple, expand on demand. The elaborate main sitemap today can still be around as a sub-sitemap in the elaborate/ directory... Block Modularization probably need to address sitemap declarations as well, with a formal way of defaults being added automatically and other sitemap declaration should perhaps be adjacent to the Block and not to the sitemap, after all keeping the Block stuff at the Block makes more sense to me. Bottom line; Cocoon is about to broken into smaller, more managable pieces. This will easier allow 3rd parties to package Cocoon into nice binary distros. Comments? Niclas
Re: Blocking SPAM and daedalus.
Antonio Gallardo wrote: Andrew Savory dijo: On Fri, 29 Aug 2003, Antonio Gallardo wrote: It seems like our server daedalus.apache.org is being blocked by the black-hole list http://relays.osirusoft.com/. The osirusoft black-hole list has been shut down due to a denial of service attack. I suggest you remove it from your mailserver configs. Thanks, Yep. I already done this. I blocked other maillists we are subscribed. But interesting is that this happens today. Before osirusoft worked well. FYI: http://slashdot.org/article.pl?sid=03/08/27/0214238mode=threadtid=111tid=126 Vadim
Re: Releasing 2.1.1?
On Thu, 2003-08-28 at 08:12, 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? Not over here. If all else fails, we could disable the CommandManager and let the ContinuationsManager start a thread of its own (like e.g. the StoreJanitor does). -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
[Vote] Move from LogKitManager to LoggerManager
Triggered by the recent discussions about using log4j, I propose that we move from the deprecated LogKitManager to the new LoggerManager. This will make using log4j much easier (and I would implement that then next). There is a patch for the move already in bugzilla: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21730 But: this is an incompatible change (however the impace should be very small). So, please vote on the change. and please vote if this is a change for 2.1.1 or 2.2. Thanks Carsten
Re: [Vote] Move from LogKitManager to LoggerManager
Carsten Ziegeler wrote: Triggered by the recent discussions about using log4j, I propose that we move from the deprecated LogKitManager to the new LoggerManager. This will make using log4j much easier (and I would implement that then next). There is a patch for the move already in bugzilla: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21730 But: this is an incompatible change (however the impace should be very small). So, please vote on the change. and please vote if this is a change for 2.1.1 or 2.2. 2.1.1, +1. Vadim
Re: [Vote] Move from LogKitManager to LoggerManager
Vadim Gritsenko wrote: Carsten Ziegeler wrote: Triggered by the recent discussions about using log4j, I propose that we move from the deprecated LogKitManager to the new LoggerManager. This will make using log4j much easier (and I would implement that then next). There is a patch for the move already in bugzilla: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21730 But: this is an incompatible change (however the impace should be very small). So, please vote on the change. and please vote if this is a change for 2.1.1 or 2.2. 2.1.1, +1. Or should it be 2.1.2? I thought you are going to release 2.1.1 Really Soon Now? btw, what about 2.0.5? Vadim
RE: [Vote] Move from LogKitManager to LoggerManager
Vadim Gritsenko wrote: 2.1.1, +1. Or should it be 2.1.2? I thought you are going to release 2.1.1 Really Soon Now? btw, what about 2.0.5? :), yepp, we will see, we could rephrase it to 2.1.x then. I will not release 2.1.1 without a fix for the event handling (commandmanager) bug. It seems that there is currently no need for 2.0.5. But if someone wants to release it I'm fine with it. Carsten
Re: [RT] Improving Sitemap and Flowscript
Stefano Mazzocchi wrote, On 28/08/2003 17.27: On Wednesday, Aug 27, 2003, at 17:41 Europe/Rome, Nicola Ken Barozzi wrote: Calling a resource, inserting a virtual pipeline and using the cocoon: protocol are for most uses equivalent. I agree when you say that since the introduction of the cocoon: protocol, map:resource is now redundant (and less appealing, as well). In fact, we could go as far as saying that map:resource is no longer needed and could be deprecated. This would leave us only with pipelines, components and virtual components (which are, in fact, typed pipeline fragments), and the cocoon: protocol to mix them, if needed. +1 from me for this ... (I won't use AOP terminology that I personally don't yet like) See, I don't like it too! ;-) well, when you propose something like map:aspects it seems AOP-ish enough for me ;-) that's not coherent with the above. Only the name aspect. I refrained talking about pointcuts, advises, etc... (ugh, I do hate those...) So we can generalize it, and add configurability to the view mechanism to specify other conditions. Thus views effectively insert pipeline fragments at a certain condition. In fact they insert their contents after a label. So the label is the condition. I know it's a matter of terminology pickyness, but I disagree. The condition that triggers the view is the view request. The result of this condition is the execution of the pipeline that is 'instrumented' to route its output somewhere else (to the view, which can now be seen as a virtual serializer) Correct. You know how messy I am in describing things. Put the right terminology instead of condition. ... you are using AOP the micro-granular way. This is: remove crosscutting by making all overlapping aspect objects and compose them together. I tend to dislike this practice since it leads, IMHO, to poor readability (users don't have the vision of crosscutting concerns that we developers do, and they perceive it as unnecessary overcomponentization) a critic to the above is: why would you want to gather-links if you are not going to serialize them? Yes, I've come to the same conclusion yesterday too. You are suggesting that a more general aspect-oriented approach to pipeline composability might be general enough to allow views to be replaced by such a more powerful approach. I agree. Ok. What I don't understand is why we should give away a perfectly fine system for a new flexibility we don't need. [note how I avoided to named this FS even if I was very tempted to do so ;-)] ;-) Yes, I see this too now. The RT started out of a link-gathering evolution, and for that only it may be too much... This would make it very easy to add security-based checks, logging, or any other stuff. map:aspects map:aspect type=pipeline test=start map:action type=check-security/ /map:aspect map:aspect type=pipeline test=all map:transformer type=logger/ /map:aspect map:aspect type=error test=all map:action type=notify-admin/ /map:aspect /map:aspects I don't like this and I don't see any reasonable use of the above system besides views. [c'mon, a logging aspect is much easier implemented by a different pipeline implementation, an admin-notifier is much better placed in a error-handler, where it belongs, and for flow-related actions, well, you know my opinion on those] What am I missing? Simple: AOP does not make you do more things, it factorizes common behaviours in a single place. If the places where these things must be placed are a lot, then it makes sense, else it doesn't. You have much more experience in seeing working systems, so you can judge better than me on this. ... *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. This is probably the point I'm missing. Instead of discussion the solution, can't we start over again from the problem? maybe there are easier solutions that you didn't think about. This is the last iteration of a looong discussion ;-) Summary: - CLI crawling link-views is slow - it's slow because it's multipass - make it monopass by instrumenting the pipeline with a gatherer - this brings 50% speed increase - but the instrumentation is not configurable: - no place where to tell where ti gather - no link filtering - add a filter to the links (done in CVS) - Vadim has the idea of using a tee instead So let's leave this where it is now till some real need comes up, and let's continue the thread from the last mail of Upayavira on this. Below the last comments. What do others think? Is it already possible to do this today with other components and skillful pipeline writing? what do you mean with this?
Re: [Vote] Move from LogKitManager to LoggerManager
Carsten Ziegeler wrote: Triggered by the recent discussions about using log4j, I propose that we move from the deprecated LogKitManager to the new LoggerManager. This will make using log4j much easier (and I would implement that then next). There is a patch for the move already in bugzilla: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21730 But: this is an incompatible change (however the impace should be very small). Please give us more details of the impact on both Cocoon core and external components. Loggable to LogEnabled meant a hell of a mess to me in the past, I don't want to go down that path again... 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: [Vote] Move from LogKitManager to LoggerManager
On 29.Aug.2003 -- 02:20 PM, Carsten Ziegeler wrote: Triggered by the recent discussions about using log4j, I propose that we move from the deprecated LogKitManager to the new LoggerManager. This will make using log4j much easier (and I would implement that then next). There is a patch for the move already in bugzilla: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21730 But: this is an incompatible change (however the impace should be very small). So, please vote on the change. +1 and please vote if this is a change for 2.1.1 or 2.2. I prefer to have 2.1.1 released without this change and a 2.1.2 immediately afterwards including this change due to the other fixes scheduled for 2.1.1 Chris. -- C h r i s t i a n H a u l [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
On Thursday, Aug 28, 2003, at 15:47 Europe/Rome, Niclas Hedhman wrote: 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. I *strongly* dislike the use of static methods for multi-context environments. If I have two instances of cocoon running in the same servlet container, which Log4j configurations will handle them? what if the log of one servlet ends up being in the log of another one? Huge security issue here. -- Stefano.
[FYI] away
I'll be offline for 2 weeks starting from now. -- Stefano.
Re: [RT] Cocoon Distro support
On Friday, Aug 29, 2003, at 08:12 Europe/Rome, Niclas Hedhman wrote: Hi all, the recent comments about production build and binary builds have caused me to think about Cocoon Distros and what must core Cocoon do to allow for Cocoon Distros from 3rd parties. [snip] *everything* about ease of distribution, ease of webapp-level composability, ease of reuse, ease of configuration, ease of deployment, ease of staging, updating, cluster replication and what not has *ALREADY* been considered in the block design. Can people *PLEASE* take a look at that before restarting anew everytime? Thanks. -- Stefano, frustrated when people base their context on their own assumptions instead of reading previous context.
Re: [RT] Starting 2.2
On Thursday, Aug 28, 2003, at 20:00 Europe/Rome, Jay Freeman ((saurik)) wrote: 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? Yes, you are right, CVS sucks, but the way it's integrated with the apache infrastructure and with tools that people use is not. there is a huge inertia there. greatly underestimated by the subversion people, expecially for people used to IDEs like eclipse that hide CVS stuff under the hood and do things automatically. I'm sick of this thread. It's stopping evolution. Carsten, forget beauty of versioning and let's start working on cocoon-2.1 HEAD, this will: 1) reduce effort and duplication 2) keep people sane since every commit will have to keep the tree in shape (it's entirely possible to implement real blocks with what we have, without moving things around, even turning the current static blocks into real ones). So, my vote is: cut the crap, let's work on the thing right here and right now, we'll think about what to do later. Evolution is always prefered to revolution. [believe me, I've made this mistake so many times that I learned my way thru] -- Stefano.
RE: [RT] Starting 2.2
Stefano Mazzocchi wrote: Carsten, forget beauty of versioning and let's start working on cocoon-2.1 HEAD, this will: 1) reduce effort and duplication 2) keep people sane since every commit will have to keep the tree in shape (it's entirely possible to implement real blocks with what we have, without moving things around, even turning the current static blocks into real ones). This is a very optimistic assumption, which I personally doubt. But, ok, I can live with doing everything in cocoon-2.1 HEAD, no problem. I'm absolutely frustrated as well: over the last months people always said, Let's get 2.1 out, we want to start 2.2. Now that we can do it, I'm the only one keeping to it. Great! Now I can already imagine what will happen. Someday someone checks in something that is not suitable for a 2.1.x version and then a new flame war against this person will begin. Ok, agreed. Let's stop the crap and work with the 2.1 repo then. joke Ah, btw. I will replace ECM with fortress over the weekend. Any problems with that? /joke Carsten
RE: Releasing 2.1.1?
Have a look at this thread: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106189194527050w=2 and this bug http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18131 Now, it seems that the CommandManager is not working in all environments. In my it's not working but I don't have the shutdown problem and I guess it's vice versa. We are using the released version 1.0.3, but I tested the latest CVS and I guess Giacomo is also using the latest. Carsten Berin Loritsch [mailto:[EMAIL PROTECTED] wrote: What version of CommandManager are you using? I am very interested in fixing it so that it works all the time. Also, under what circumstances does it break?
Re: [Proposal] Simple production build directions
Lets try to fix the first issue on your list.
The last target in src/targets/webapp-build.xml is custom-conf.
This is the only place the customconf property is used.
Notice that the customconf property is applied to the included
filename, not to the srcdir attribute:
xpatch file=${build.webapp}/WEB-INF/cocoon.xconf srcdir= addComments=true
include name=${customconf}/*.xconf /
/xpatch
If I read the xpatch source code correctly, this limits the customconf to
only working with subdirectories. I think we can fix this by changing the
target to apply the customconf to the srcdir instead of to the included
filename, like this:
xpatch file=${build.webapp}/WEB-INF/cocoon.xconf srcdir=${customconf}
addComments=true
include name=*.xconf /
/xpatch
Here is the whole converted target if you would not mind testing it
with your desired configuration:
target name=custom-conf depends=init-tasks description=Uses Cocoon's xpatch
task to
customize runtime configuration
xpatch file=${build.webapp}/sitemap.xmap srcdir=${customconf}
include name=*.xmap /
include name=*.xpipe /
/xpatch
xpatch file=${build.webapp}/WEB-INF/cocoon.xconf srcdir=${customconf}
addComments=true
include name=*.xconf /
/xpatch
xpatch file=${build.webapp}/WEB-INF/logkit.xconf srcdir=${customconf}
include name=*.xlog /
/xpatch
xpatch file=${build.webapp}/WEB-INF/web.xml srcdir=${customconf}
include name=*.xweb /
/xpatch
/target
Please let me know how this goes,
--Tim Larson
--- Tomasz Nowak [EMAIL PROTECTED] wrote:
...
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?
...
__
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
Re: [RT] Starting 2.2
Carsten Ziegeler wrote: joke Ah, btw. I will replace ECM with fortress over the weekend. Any problems with that? /joke Don't tease me... Want I should do it? -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/bean CocoonBean.java
upayavira2003/08/29 07:05:50 Modified:src/java/org/apache/cocoon/bean CocoonBean.java Log: Removing printing of timestamp - will re-add it properly by extending the BeanListener interface Revision ChangesPath 1.19 +3 -1 cocoon-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.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- CocoonBean.java 28 Aug 2003 19:21:00 - 1.18 +++ CocoonBean.java 29 Aug 2003 14:05:50 - 1.19 @@ -553,9 +553,11 @@ targets.add(target.getDerivedTarget(link)); } } +/* Commenting out timestamp - will reimplement properly using the BeanListener interface double d = (System.currentTimeMillis()- startTimeMillis); String time = [ + (d/1000) + seconds]; System.out.println(+ time); +*/ return targets; }
RE: [RT] Starting 2.2
Berin Loritsch wrote: joke Ah, btw. I will replace ECM with fortress over the weekend. Any problems with that? /joke Don't tease me... Want I should do it? Hey, great! I'm definitly +5 for this! So if you want to do it, you could start a vote and see what will happen next... Carsten
Re: Releasing 2.1.1?
On Fri, 2003-08-29 at 15:35, Berin Loritsch wrote: Bruno Dumon wrote: On Thu, 2003-08-28 at 08:12, 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? Not over here. If all else fails, we could disable the CommandManager and let the ContinuationsManager start a thread of its own (like e.g. the StoreJanitor does). What version of CommandManager are you using? The one shipping with Cocoon. I am very interested in fixing it so that it works all the time. Also, under what circumstances does it break? Don't know exactly. Here's what I've found out till now: For me it works with Linux/Sun jdk 1.4.2, it doesn't work with 1.3.1. For Carsten it doesn't work with Windows/jdk 1.4 either. I've done all my testing with the Jetty which ships with Cocoon. I've added some println's here and there and it appears that, with 1.3.1, the CommandManager starts working but stops as soon as Jetty prints out the following lines: Fri Aug 29 13:58:07 CEST 2003 Listening for connections ... 13:58:07.575 EVENT Started SocketListener on 0.0.0.0: It seems that the thread that was executing the commands is somehow not released (or whathever), so when the ThreadManager wants to execute the next command it keeps waiting for a thread to be released (this waiting happens in Doug Lea's Executor). If the threads-per-processor parameter is augmented to 2, then it keeps working. According to Giacomo, the CommandManager works just fine in a non-servlet environment. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
[Linotype] for IE
Hi all, I have implement for the Linotype block the editor that also works with IE versions 5.0 For my self I had test it with MOZ and IE 5.0, 6.0 and here are some of the main changes: - the image names on upload there was an problem withe the name geneartion of the images the old one generate a number with an image counter, but when you edit a side with 3 images and delete the second, save it and edit it again, by adding an image the new name is image-3 which exists in the side and these one change his content. image name is the original name + prefix (default image-) - in the news2edit.xslt stylesheet must the edit.js script load before the script code (when not all IE displays a white side) (BUG / Feature by redirect with IE5.0) when I hit the Finish button by an IE5.0 browser the content and images are saved and then comes an error from the servlet. After debugging I found that the multipart Servlet is calld twice 1. with the POST data from the side 2. with no data and GET from the redirection. BUG in IE or in Cocoon ? So what should I do next, so that some other can test it? should I make a PATCH to Bugzilla? the patch with diff's of the stylesheets and the editor.js full? Klaus
Re: [Linotype] for IE
Klaus Bertram wrote: Hi all, I have implement for the Linotype block the editor that also works with IE versions 5.0 For my self I had test it with MOZ and IE 5.0, 6.0 and here are some of the main changes: - the image names on upload there was an problem withe the name geneartion of the images the old one generate a number with an image counter, but when you edit a side with 3 images and delete the second, save it and edit it again, by adding an image the new name is image-3 which exists in the side and these one change his content. image name is the original name + prefix (default image-) - in the news2edit.xslt stylesheet must the edit.js script load before the script code (when not all IE displays a white side) (BUG / Feature by redirect with IE5.0) when I hit the Finish button by an IE5.0 browser the content and images are saved and then comes an error from the servlet. After debugging I found that the multipart Servlet is calld twice 1. with the POST data from the side 2. with no data and GET from the redirection. BUG in IE or in Cocoon ? So what should I do next, so that some other can test it? should I make a PATCH to Bugzilla? the patch with diff's of the stylesheets and the editor.js full? Yes, that'd be great. probably doesn't matter whether the diffs are created together or not - use your best judgement. Geoff
DO NOT REPLY [Bug 22813] - [PATCH] Linotype for IE
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=22813. 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=22813 [PATCH] Linotype for IE --- Additional Comments From [EMAIL PROTECTED] 2003-08-29 15:07 --- Created an attachment (id=7991) linotype diffs
DO NOT REPLY [Bug 22813] - [PATCH] Linotype for IE
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=22813. 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=22813 [PATCH] Linotype for IE --- Additional Comments From [EMAIL PROTECTED] 2003-08-29 15:09 --- Created an attachment (id=7992) editor.js
Re: [RT] Starting 2.2
Carsten Ziegeler wrote: joke Ah, btw. I will replace ECM with fortress over the weekend. Any problems with that? Yep. Aren't we supposed to use Merlin instead? I'm checking in the code as we speak... /joke Vadim
Re: [Vote] Move from LogKitManager to LoggerManager
...and please vote if this is a change for 2.1.1 or 2.2. +1 for 2.1.1 -Bertrand
Re: [RT] Implementing Cocoon Blocks
Geoff Howard wrote: Vadim Gritsenko wrote: Stefano Mazzocchi wrote: ... Ok, great. Does anybody have a problem with the proposed file system layout? AFAIU, blocks are expanded into WEB-INF/blocks/\d+/ directories: By default - but as I understood Stefano's last email, it should be possible to override? the file system layout (relative to the cocoon webapp context) is [-] WEB-INF L___ [-] blocks L___ [-] 384938958499 | L___ [-] BLOCK-INF | | L___ block.xml | L_ (the contents of cob:mycompany.com/webmail/1.3.43) Why temp directory is not used here? And, where unpacked blocks are stored? Temp dir: I've been assuming this file and dir structure is the persistent state for the block manager. The only servlet engine which wipes out deployment (aka temp, aka staging) directory on restart is Jetty. None of the others known to me do this. If it has deployed the blocks, it records its state in this structure. At Cocoon restart, this structure (wiring.xml and resulting filesystem tree) is used to initialize the blocks/components/etc. Otherwise the block deployer has to re-deploy everything on restart. Have I got that right? Remember, Cocoon is deployed here as a webapp. And webapp can be archived into the war file. Now the question: how funny (e.g. 384938958499) directories get into the war file in the first place? Unpacked blocks: Good question -- maybe in WEB-INF/blocks ? I'd suggest to store blocks in WEB-INF/blocks/, and unpack/wire/etc them into $temp/blocks, where $temp is temporary directory configured in web.xml. WEB-INF/blocks/ can also have blocks.xml to point out to blocks which are located outside of the blocks directory, for development needs. Vadim
[VOTE] Migrate from the aging ECM
The new Cocoon should be able to use the new Fortress container. This should have little to no impact on component writers. It boasts faster startup, and it provides easier component definition. I will be happy to do the work. +1 from me. -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
Re: [VOTE] Migrate from the aging ECM
Berin Loritsch wrote: The new Cocoon should be able to use the new Fortress container. This should have little to no impact on component writers. It boasts faster startup, and it provides easier component definition. I will be happy to do the work. +1 from me. +1 for you.
Re: [VOTE] Migrate from the aging ECM
Berin Loritsch wrote: The new Cocoon should be able to use the new Fortress container. This should have little to no impact on component writers. It boasts faster startup, and it provides easier component definition. I will be happy to do the work. +1 from me. I'm scared but I trust you. :-) +1 from me too. -- 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: [VOTE] Migrate from the aging ECM
From: Berin Loritsch The new Cocoon should be able to use the new Fortress container. This should have little to no impact on component writers. It boasts faster startup, and it provides easier component definition. I will be happy to do the work. +1 from me. +1 from me too :) J.
Re: [VOTE] Migrate from the aging ECM
Berin Loritsch wrote: The new Cocoon should be able to use the new Fortress container. This should have little to no impact on component writers. It boasts faster startup, and it provides easier component definition. I will be happy to do the work. +1 from me. +1, but I (still) would like to hear quick comment on Fortress vs Merlin. I heard on avalon-dev that merlin is gonna be that new craze. Vadim
WebDAV proxy available (was: [RT] WebDAV proxy / DASL search in Cocoon)
Bertrand Delacretaz wrote:
If I'm right, this would allow Cocoon to proxy most WebDAV operations to
a non-DASL WebDAV backend, and process the few operations that relate to
properties (PROPFIND, PROPPATCH, SEARCH) directly, storing properties in
a database.
This was an itch I just had to scratch. :-) I have now committed to the
proxy block a new ProxyGenerator that takes whatever method and forwards
it to an origin server specified as a sitemap parameter. To do so, I had
to put together a new httpclient method (I'm wondering if the httpclient
team might be interested in it once polished...) that clones an incoming
HttpServletRequest and makes a call to an origin server. So far I've
tried it with cadaver and skunkdav, surprisingly enough it seems to work
with all the webdav methods.
We have a starting point then, but beware:
1. header handling is *hacky*. I had to filter by hand some headers in
order to make the application behave (don't ask me why, but
Content-Length in the Cocoon proxied response was off by one byte);
2. no HTTP/1.1 keepalive. I see no way of handling it in Cocoon, since
every request has to go through the pipeline, and the response
OutputStream cannot be reused. This might be a major performance hit.
Anyway, it's there for you to play. :-) To access a DAV repository
running at localhost on port 81 under the /dav context, all you have to
do is
map:generator label=content
logger=sitemap.generator.proxy
name=generic-proxy
src=org.apache.cocoon.generation.GenericProxyGenerator/
[...]
map:match pattern=dav/
map:generate type=generic-proxy
map:parameter name=url value=http://localhost:81/dav//
map:parameter name=path value=/dav//
/map:generate
map:serialize type=xml/
/map:match
map:match pattern=dav/**
map:generate type=generic-proxy
map:parameter name=url value=http://localhost:8881/dav//
map:parameter name=path value=/dav/{1}/
/map:generate
map:serialize type=xml/
/map:match
Anyone willing to tackle DASL searches now? :-)
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: Releasing 2.1.1?
On Fri, 29 Aug 2003, Berin Loritsch wrote: Bruno Dumon wrote: On Thu, 2003-08-28 at 08:12, 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? Not over here. If all else fails, we could disable the CommandManager and let the ContinuationsManager start a thread of its own (like e.g. the StoreJanitor does). What version of CommandManager are you using? I am very interested in fixing it so that it works all the time. Also, under what circumstances does it break? I'm using the latest (from CVS) put alot of gebugging into it to see wher it goes. Unfortunately at some time in the startup of the servlet container it stops working (I've put a test command right after constructing the CommandManager in Cocoon.java). -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
Re: Releasing 2.1.1?
On Fri, 29 Aug 2003, Bruno Dumon wrote: For me it works with Linux/Sun jdk 1.4.2, it doesn't work with 1.3.1. For Carsten it doesn't work with Windows/jdk 1.4 either. I've done all my testing with the Jetty which ships with Cocoon. I've added some println's here and there and it appears that, with 1.3.1, the CommandManager starts working but stops as soon as Jetty prints out the following lines: Fri Aug 29 13:58:07 CEST 2003 Listening for connections ... 13:58:07.575 EVENT Started SocketListener on 0.0.0.0: I have the above also in with sun jdk 1.4.2 on Linux. It seems that the thread that was executing the commands is somehow not released (or whathever), so when the ThreadManager wants to execute the next command it keeps waiting for a thread to be released (this waiting happens in Doug Lea's Executor). If the threads-per-processor parameter is augmented to 2, then it keeps working. Have not tried using a second Thread. According to Giacomo, the CommandManager works just fine in a non-servlet environment. Right. -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
Re: [Vote] Move from LogKitManager to LoggerManager
On Fri, 29 Aug 2003, Carsten Ziegeler wrote: Triggered by the recent discussions about using log4j, I propose that we move from the deprecated LogKitManager to the new LoggerManager. This will make using log4j much easier (and I would implement that then next). There is a patch for the move already in bugzilla: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21730 But: this is an incompatible change (however the impace should be very small). So, please vote on the change. and please vote if this is a change for 2.1.1 or 2.2. +1 for 2.1.x -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
RE: [VOTE] Migrate from the aging ECM
+1 Carsten Berin Loritsch wrote: The new Cocoon should be able to use the new Fortress container. This should have little to no impact on component writers. It boasts faster startup, and it provides easier component definition. I will be happy to do the work. +1 from me.
Re: [VOTE] Migrate from the aging ECM
Vadim Gritsenko wrote: Berin Loritsch wrote: The new Cocoon should be able to use the new Fortress container. This should have little to no impact on component writers. It boasts faster startup, and it provides easier component definition. I will be happy to do the work. +1 from me. +1, but I (still) would like to hear quick comment on Fortress vs Merlin. I heard on avalon-dev that merlin is gonna be that new craze. Consider Fortress a stepping stone from ECM to Merlin. Once Cocoon has done all the work to move to Fortress, it becomes trivial to host in Merlin. The main things here are: 1) Merlin does not support ServiceSelector. 2) Fortress provides mechanisms to make the ServiceSelector unecessary, but seamlessly supports components that still hold on to it. 3) Merlin does not support the ThreadSafe, SingleThreaded, Poolable interfaces. 4) Fortress still supports them for legacy components--but it encourages the new meta-data enabled way. These are the key areas where Cocoon *needs* Fortress for the immediate shift. I would much rather work toward the immediate need, because we can still work with Cocoon while we are doing the other migrations. It is important to note that Merlin has a number of features that Fortress does not have--but Fortress provides a number of features that ECM doesn't have. When Merlin is officially released, it will be 100% Fortress compatible. -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
cvs commit: cocoon-2.0/src/documentation/xdocs/userdocs/generators search-generator.xml
asavory 2003/08/29 11:54:37 Modified:src/documentation/xdocs/userdocs/generators search-generator.xml Log: Fixing capitalisation Revision ChangesPath 1.2 +1 -1 cocoon-2.0/src/documentation/xdocs/userdocs/generators/search-generator.xml Index: search-generator.xml === RCS file: /home/cvs/cocoon-2.0/src/documentation/xdocs/userdocs/generators/search-generator.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- search-generator.xml 9 Mar 2003 00:01:13 - 1.1 +++ search-generator.xml 29 Aug 2003 18:54:37 - 1.2 @@ -66,7 +66,7 @@ /td /tr tr - tdquery-string/tdtdQueryString/td + tdquery-string/tdtdqueryString/td td This parameter specifies the name of the query paramter name used for passing the query-string, eg.
cvs commit: cocoon-2.1/src/documentation/xdocs/userdocs/generators search-generator.xml
asavory 2003/08/29 11:54:50 Modified:src/documentation/xdocs/userdocs/generators search-generator.xml Log: Fixing capitalisation Revision ChangesPath 1.3 +1 -1 cocoon-2.1/src/documentation/xdocs/userdocs/generators/search-generator.xml Index: search-generator.xml === RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/userdocs/generators/search-generator.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- search-generator.xml 8 Jul 2003 08:46:33 - 1.2 +++ search-generator.xml 29 Aug 2003 18:54:50 - 1.3 @@ -66,7 +66,7 @@ /td /tr tr - tdquery-string/tdtdQueryString/td + tdquery-string/tdtdqueryString/td td This parameter specifies the name of the query parameter name used for passing the query-string, eg.
cvs commit: cocoon-2.1/src/blocks/apples/java/org/apache/cocoon/components/flow/apples ApplesProcessor.java
mpo 2003/08/29 15:11:25
Modified:src/blocks/apples/java/org/apache/cocoon/components/flow/apples
ApplesProcessor.java
Log:
Let logging include the continuation id.
Revision ChangesPath
1.5 +3 -2
cocoon-2.1/src/blocks/apples/java/org/apache/cocoon/components/flow/apples/ApplesProcessor.java
Index: ApplesProcessor.java
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/apples/java/org/apache/cocoon/components/flow/apples/ApplesProcessor.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ApplesProcessor.java 26 Aug 2003 09:06:43 - 1.4
+++ ApplesProcessor.java 29 Aug 2003 22:11:25 - 1.5
@@ -84,9 +84,10 @@
WebContinuation wk = this.continuationsMgr.createWebContinuation(app, null,
TIMETOLIVE, this);
-getLogger().debug(Pulling fresh apple through the lifecycle...);
DefaultContext appleContext = new DefaultContext();
appleContext.put(continuation-id, wk.getId());
+
+getLogger().debug(Pulling fresh apple through the lifecycle... |
continuationid= + wk.getId());
//TODO: also add the componentManager for Apples that took the other
approach
LifecycleHelper.setupComponent(app, getLogger(), appleContext,
this.serviceManager, null, null, null);
@@ -151,7 +152,7 @@
env.redirect(false, res.getURI());
} else {
String uri = res.getURI();
-getLogger().debug(Apple forwards to + uri + with bizdata= +
res.getData());
+getLogger().debug(Apple forwards to + uri + with bizdata= +
res.getData() + and continuationid= + wk.getId());
this.forwardTo(uri, res.getData(), wk, env);
}
cvs commit: cocoon-2.1/src/blocks/apples/samples/calc - New directory
mpo 2003/08/29 15:12:50 cocoon-2.1/src/blocks/apples/samples/calc - New directory
cvs commit: cocoon-2.1/src/blocks/apples/samples/guess - New directory
mpo 2003/08/29 15:22:18 cocoon-2.1/src/blocks/apples/samples/guess - New directory
cvs commit: cocoon-2.1/src/blocks/apples/java/org/apache/cocoon/components/flow/apples/samples CalculationApple.java
mpo 2003/08/29 15:22:05 Added: src/blocks/apples/samples/calc getNumberA.xsp getOperator.xsp getNumberB.xsp displayResult.xsp src/blocks/apples/java/org/apache/cocoon/components/flow/apples/samples CalculationApple.java Log: Adding Calculator Example showing difference between Apples and FlowScript. Revision ChangesPath 1.1 cocoon-2.1/src/blocks/apples/samples/calc/getNumberA.xsp Index: getNumberA.xsp === ?xml version=1.0? !--+ | CVS: $Id: getNumberA.xsp,v 1.1 2003/08/29 22:22:05 mpo Exp $ | Author: Ovidiu Predescu [EMAIL PROTECTED] | Date: March 23, 2002 +-- xsp:page language=java xmlns:xsp=http://apache.org/xsp; xmlns:jpath=http://apache.org/xsp/jpath/1.0; page titleCalculator/title content para This sample is explicitely designed to provide an easy comparison grounds against the same kind of application in flowScript. (check the Calculator sample there too) /para para You should note especially how they handle continuation after pressing the back-button. That should also explain why this approach chooses to provide links to explicitely edit the previsouly entered values. /para form method=post xsp:attribute name=actionxsp:exprjpath:continuation/+.continue/xsp:expr/xsp:attribute paraEnter value of stronga/strong: input type=text name=a//para input type=submit name=submit value=Enter/ /form /content /page /xsp:page 1.1 cocoon-2.1/src/blocks/apples/samples/calc/getOperator.xsp Index: getOperator.xsp === ?xml version=1.0? !--+ | CVS: $Id: getOperator.xsp,v 1.1 2003/08/29 22:22:05 mpo Exp $ | Author: Ovidiu Predescu [EMAIL PROTECTED] | Date: March 23, 2002 +-- xsp:page language=java xmlns:xsp=http://apache.org/xsp; xmlns:jpath=http://apache.org/xsp/jpath/1.0; page titleCalculator/title content form method=post xsp:attribute name=actionxsp:exprjpath:continuation/+ .continue/xsp:expr/xsp:attribute paraa = a xsp:attribute name=hrefxsp:exprjpath:continuation/+.continue?change=a/xsp:expr/xsp:attribute strongjpath:value-of select=a//strong /a /para parab = a xsp:attribute name=hrefxsp:exprjpath:continuation/+.continue?change=b/xsp:expr/xsp:attribute strongjpath:value-of select=b//strong /a /para paraEnter operator select name=operator optionplus/option optionminus/option optionmultiply/option optiondivide/option /select /para input type=submit name=submit value=Do it!/ /form /content /page /xsp:page 1.1 cocoon-2.1/src/blocks/apples/samples/calc/getNumberB.xsp Index: getNumberB.xsp === ?xml version=1.0? !--+ | CVS: $Id: getNumberB.xsp,v 1.1 2003/08/29 22:22:05 mpo Exp $ | Author: Ovidiu Predescu [EMAIL PROTECTED] | Date: March 23, 2002 +-- xsp:page language=java xmlns:xsp=http://apache.org/xsp; xmlns:jpath=http://apache.org/xsp/jpath/1.0; page titleCalculator/title content form method=post xsp:attribute name=actionxsp:exprjpath:continuation/+.continue/xsp:expr/xsp:attribute paraa = a xsp:attribute name=hrefxsp:exprjpath:continuation/+.continue?change=a/xsp:expr/xsp:attribute strongjpath:value-of select=a//strong /a /para paraEnter value of strongb/strong: input type=text name=b//para input type=submit name=submit value=Enter/ /form /content /page /xsp:page 1.1 cocoon-2.1/src/blocks/apples/samples/calc/displayResult.xsp Index: displayResult.xsp === ?xml version=1.0? !--+ | CVS: $Id: displayResult.xsp,v 1.1 2003/08/29 22:22:05 mpo Exp $ | Author: Ovidiu Predescu [EMAIL PROTECTED] | Date: March 23, 2002 +-- xsp:page language=java xmlns:xsp=http://apache.org/xsp; xmlns:jpath=http://apache.org/xsp/jpath/1.0; page titleCalculator/title content form action=./calc.flow method=post paraa = a xsp:attribute
cvs commit: cocoon-2.1/src/blocks/apples/samples sitemap.xmap welcome.xml
mpo 2003/08/29 15:33:00
Modified:src/blocks/apples/samples sitemap.xmap welcome.xml
Log:
Adding the new samples to the sitemap and the welcome page.
Revision ChangesPath
1.3 +131 -65 cocoon-2.1/src/blocks/apples/samples/sitemap.xmap
Index: sitemap.xmap
===
RCS file: /home/cvs/cocoon-2.1/src/blocks/apples/samples/sitemap.xmap,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- sitemap.xmap 6 Aug 2003 15:54:13 - 1.2
+++ sitemap.xmap 29 Aug 2003 22:33:00 - 1.3
@@ -1,71 +1,77 @@
-?xml version=1.0?
-map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
-
- map:components
-
- map:generators default=file
-map:generator name=woody
src=org.apache.cocoon.woody.generation.WoodyGenerator logger=woody/
-map:generator name=jx src=org.apache.cocoon.generation.JXTemplateGenerator
label=content,data logger=sitemap.generator.jx/
- /map:generators
-
- map:transformers default=xalan
-map:transformer name=woody
src=org.apache.cocoon.woody.transformation.WoodyTemplateTransformer logger=woody/
-map:transformer name=i18n
src=org.apache.cocoon.transformation.I18nTransformer
- catalogues default=other
-catalogue id=other name=OtherMessages
location=context://samples/woody/messages/
-catalogue id=woody name=WoodyMessages
location=context://samples/woody/messages/
- /catalogues
- cache-at-startuptrue/cache-at-startup
-/map:transformer
- /map:transformers
-
- map:selectors default=browser
-map:selector name=request-method
src=org.apache.cocoon.selection.RequestMethodSelector/
- /map:selectors
-
- map:actions/
-
- map:pipes default=caching
- /map:pipes
-
- /map:components
-
- map:views
- map:view name=content from-label=content
- map:serialize type=xml/
- /map:view
-
- map:view name=pretty-content from-label=data
- map:transform src=context://stylesheets/system/xml2html.xslt/
- map:serialize type=html/
- /map:view
-
- map:view name=links from-position=last
- map:serialize type=links/
- /map:view
- /map:views
-
- map:flow language=apples /
-
- map:pipelines
- map:pipeline
-
- map:match pattern=
- map:generate src=welcome.xml/
- map:transform
src=context://samples/common/style/xsl/html/simple-samples2html.xsl
- map:parameter name=contextPath value={request:contextPath}/
- /map:transform
- map:serialize/
- /map:match
+?xml version=1.0 encoding=ISO-8859-1?
- !--
-| Binding form sample, stolen from woody
---
-
+map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
+
+ map:components
+map:generators default=file
+ map:generator name=woody
src=org.apache.cocoon.woody.generation.WoodyGenerator logger=woody/
+ map:generator name=jx
src=org.apache.cocoon.generation.JXTemplateGenerator label=content,data
logger=sitemap.generator.jx/
+/map:generators
+map:transformers default=xalan
+ map:transformer name=woody
src=org.apache.cocoon.woody.transformation.WoodyTemplateTransformer logger=woody/
+ map:transformer name=i18n
src=org.apache.cocoon.transformation.I18nTransformer
+catalogues default=other
+ catalogue id=other name=OtherMessages
location=context://samples/woody/messages/
+ catalogue id=woody name=WoodyMessages
location=context://samples/woody/messages/
+/catalogues
+cache-at-startuptrue/cache-at-startup
+ /map:transformer
+/map:transformers
+map:selectors default=browser
+ map:selector name=request-method
src=org.apache.cocoon.selection.RequestMethodSelector/
+/map:selectors
+map:actions/
+map:pipes default=caching/
+ /map:components
+
+ map:views
+map:view name=content from-label=content
+ map:serialize type=xml/
+/map:view
+map:view name=pretty-content from-label=data
+ map:transform src=context://stylesheets/system/xml2html.xslt/
+ map:serialize type=html/
+/map:view
+map:view name=links from-position=last
+ map:serialize type=links/
+/map:view
+ /map:views
+
+ map:resources
+map:resource name=serialize-jx-screen
+map:transform
src=context://samples/common/style/xsl/html/simple-page2html.xsl
+ map:parameter name=servletPath value={request:servletPath}/
+ map:parameter name=sitemapURI value={request:sitemapURI}/
+ map:parameter name=contextPath value={request:contextPath}/
+ map:parameter name=file value=/samples/apples/{screen-src}/
+ map:parameter name=remove value={0}/
+/map:transform
+map:serialize type=html /
+/map:resource
+
Re: Blocking SPAM and daedalus.
Vadim Gritsenko dijo: FYI: http://slashdot.org/article.pl?sid=03/08/27/0214238mode=threadtid=111tid=126 Vadim Thank you for the link :) Best Regards, Antonio Gallardo
Re: Releasing 2.1.1?
On Fri, 2003-08-29 at 19:55, Giacomo Pati wrote:
On Fri, 29 Aug 2003, Bruno Dumon wrote:
For me it works with Linux/Sun jdk 1.4.2, it doesn't work with 1.3.1.
For Carsten it doesn't work with Windows/jdk 1.4 either. I've done all
my testing with the Jetty which ships with Cocoon.
I've added some println's here and there and it appears that, with
1.3.1, the CommandManager starts working but stops as soon as Jetty
prints out the following lines:
Fri Aug 29 13:58:07 CEST 2003 Listening for connections ...
13:58:07.575 EVENT Started SocketListener on 0.0.0.0:
I have the above also in with sun jdk 1.4.2 on Linux.
It's probably a coincidence. If you supply a higher value for the
sleep-time parameter of the CommandManager, for example 1000 ms, it
will probably keep working for you too (with 1.3 also).
I think the problem lies somewhere in the PooledExecutor and/or
SynchronousChannel classes from the concurrent package.
If you take a look at the PooledExecutor class, there's a getTask method
that is called by worker threads (see the inner class Worker). Shortly
before jetty binds to port it probably does something cpu
intensive, causing the poll(sleep-time) call in the getTask method to
timeout, and the getTask() method to return null, which in itself causes
the worker thread to be released. More or less at the same time, the
PooledExecutor is asked to execute another runnable but it thinks no
threads are available anymore and hands off the runnable to the
SynchronousChannel. How it then needs to get out of that situation is
currently still a mystery for me...
ok, 10 minutes later now, got an idea:
if you add the following code before the closing bracket of the
PooledExecutor.workerDone(...) method, then it --seems to-- work:
if (!shutdown_) {
if (poolSize_ maximumPoolSize_) {
Runnable r= null;
try {
r = getTask();
} catch (InterruptedException e) {
e.printStackTrace();
}
if (r != null)
addThread(r);
}
}
Could someone else also try this out? For your convenience, here's a
compiled jar with this change:
http://outerthought.net/~bruno/concurrent.jar
just copy it over the util.concurrent-1.3.1.jar
It seems that the thread that was executing the commands is somehow not
released (or whathever), so when the ThreadManager wants to execute the
next command it keeps waiting for a thread to be released (this waiting
happens in Doug Lea's Executor). If the threads-per-processor
parameter is augmented to 2, then it keeps working.
Have not tried using a second Thread.
According to Giacomo, the CommandManager works just fine in a
non-servlet environment.
Right.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
OSCOM @ Seybold SF
Seybold organizers just told me that they want to cancel the OSCOM hackathon/sprint @ Seybold if there aren't enough participants which have signed up until tomorrow Friday (western times). The reason seems to be that room and internet connection are too expensive for hosting just a few people. So far 3 people have signed up, but they are expecting around 20 people. I think it's a great opportunity to meet in person and do some coding on Atom and WebDAV related stuff So, please subscribe NOW if you want to participate for real. Participation is for FREE and you can sign up here: http://www.seybold365.com/common/index.php?s=hackathon more info can be found here http://www.oscom.org/Conferences/Sprints/San%20Francisco%20September%202003.html Thanks Michael
