[GT2007] REMINDER: final days to register!
Hello everybody, the Cocoon GetTogether is getting close, and there are only a few days left before we wrap registrations up. Registration will *CLOSE* on September 30th, which means you have only got SIX days left to secure your place. The program is online and, as usual, we will have a great speaker lineup. A great hackathon and amazing evening events will be the perfect icing on the GT cake. Hurry up, don't wait! Due to organizational requirements we won't be able to accept walk-ins, so please reserve your spot. See you in Rome! -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com (blogging at http://www.rabellino.it/blog/)
[GT2007] The program is out!
The CocoonGT team is pleased to announce the conference schedule has been finalized and is available at http://www.cocoongt.org/PROGRAM.html As usual, we had a great number of high-quality submissions. In keeping with the tradition of having a conference day packed full with great content, we managed to squeeze a lot of excellent speakers and talks – from customer experience to hands-on core stuff, to tightly-coupled frameworks and solutions. Be sure to visit the Web site for more details: the CocoonGT is just a few weeks away. Hurry and reserve your seat today – we look forward to seeing you in Rome! -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com (blogging at http://www.rabellino.it/blog/)
Re: [GT2007] The program is out!
On 9/18/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote: Gianugo Rabellino pisze: Thanks Gianugo for putting this. There is small problem, title contains still 2006 instead of 2007. Good catch! Fixed. Ciao, -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com (blogging at http://www.rabellino.it/blog/)
Re: CocoonGT
On 9/13/07, Leszek Gawron [EMAIL PROTECTED] wrote: As something broke during registration I was not able to pay with PayPal. Question is: what email address should I send the money to? [EMAIL PROTECTED] Arjé is your man and our accountant, so I'll leave him the confirmation to him. Second question is: does anyone play squash? Are there any squash courts around? I might take my gear with me if somebody wanted some evening exercise... :) I used to, but it was some 20 years and possibly 40kgs ago in all honesty I'm not aware of any squash courts around, maybe Simone knows better? Ciao, -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com (blogging at http://www.rabellino.it/blog/)
Re: [GT2007] how long from Fiumicino to the GT venue?
On 9/8/07, Bertrand Delacretaz [EMAIL PROTECTED] wrote: Hi, Looks like I'll make it to the conference day only - how long does it take from FCO airport to the GT venue? Uhm... I would account for 1, 1.5 hours (10-15 minutes venue-metro + 10-15 minutes metro - railway station and 30 minutes train). Can be faster with a cab but, considering Rome traffic at rush hour on a friday afternoon... I guess I'd rather stay for the night. -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [CocoonGT] Has anyone considered inviting folks from Wicket?
On 9/8/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote: hepabolu pisze: Gianugo Rabellino said the following on 4/9/07 13:36: On 9/4/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote: That would be great! Would you do the honors? What about Upayavira and Sylvain? I guess that they follow Wicket's mailing list so if we sent an invitation there I guess they would see it. However, I'm not sure if it makes sense to send that mail without addressing issues I outlined. Er, I don't quite think so. I think the GT could be an excellent venue for them to spend a few days out in a nice location and hack around their Wicket stuff. Of course, having Cocooners in the same room might help crosspollination as well. So I would just send an informal invite along the lines of we're going to have some fun, food, beers and hacking. Fancy a Wi-Fi connected table and a glass of italian wine? Then come to Rome and join us! Ciao, -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
[GT2007] Accomodation in Rome
Hello fellow Cocooners! A couple of pages have been created on the Cocoon Wiki to help in finding good accomodation for your Roman days: 1. Simone Gianni has been hand picking a few hotels. Have a look at http://wiki.apache.org/cocoon/GT2007Hotels. Please feel free to use the wiki to ask if other fellow Cocooners are willing to share a room 2. a possible (and cheaper) alternative can be renting an apartment. Considering you're getting a full-board (and then some!) treatment from the conference itself, that might be a nice possibility to save a few bucks and do something different. We are more then willing to provide assistance in finding a good spot for you in Rome. Surf to http://wiki.apache.org/cocoon/GT2007Apartments and indicate if you're interested. Rooms in Rome are filling up fast, and price are going up! Don't hesitate and secure your accomodation as soon as possible. See you in Rome! -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: CocoonGT hotels
On 9/3/07, Gianugo Rabellino [EMAIL PROTECTED] wrote: On 9/3/07, Leszek Gawron [EMAIL PROTECTED] wrote: Grzegorz Kossakowski wrote: Gianugo Rabellino pisze: Any chance for concrete names of hotels you recommend? It would be much easier for us... I second this request - the only hotels I found are doubles for 320 EUR per night... Working on that. You'll have a list by tonight. Sorry for being late. Simone is finalizing a couple of deals with good hotels. We'll post them today. Ciao, -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [CocoonGT] Has anyone considered inviting folks from Wicket?
On 9/4/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote: Hello, I saw that there are people interested in Cocoon-Wicket cooperation and we have already some plans to play with Wicket in Cocoon 2.2. I also have seen few folks from Wicket interested in bringing Cocoon strengths into Wicket so why not to invite some gurus? Opinions? That would be great! Would you do the honors? Ciao, -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
[GT2007] CFP deadline is approaching! Submit your papers!
Hurry up and secure a place on the Cocoon GT podium! With little more than three days left to submit you papers, it's time to get your proposal in. We are after building a great conference program and a great GetTogether overall, and we have been busy preparing venues and social events for you. It's now your turn to help make this event a continuing success, so don't be shy and send us your ideas by sending a note to info (at) cocoongt (dot) org: we are eager to hear from you! Remember: you don't need to be a Cocoon committer to speak at the Cocoon Get Together! See you in Rome, -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: CocoonGT hotels
On 9/3/07, Leszek Gawron [EMAIL PROTECTED] wrote: Grzegorz Kossakowski wrote: Gianugo Rabellino pisze: On 8/27/07, Reinhard Poetz [EMAIL PROTECTED] wrote: The GT website doesn't have much to say about recommended hotels yet (http://www.cocoongt.org/Venue.html). Will there be some updates by the end of the weekend? (I will be offline afterwards and would like to have a reservation before my holidays.) Indeed. I expect to finalize that tomorrow. Thanks for your patience, Any chance for concrete names of hotels you recommend? It would be much easier for us... I second this request - the only hotels I found are doubles for 320 EUR per night... Working on that. You'll have a list by tonight. Ciao, -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
[GT2007] Announcing the venue
*** CocoonGT 2007 - October 3rd-5th - Rome, Italy *** The CocoonGT team is pleased to announce that the upcoming Cocoon Get Together will take place at the Rome Bioparco[1], in the beautiful landscape of Villa Borghese, one of the most stunning urban parks in the world. For more information please see http://www.cocoongt.org/Venue.html The location is easily reached by public transport and provides an excellent place for users and developers to meet and greet. As an added perk, participants will get full free admission to the Bioparco for the whole three days of the event. Hurry up to reserve your seat at http://www.cocoongt.org/Registration.html! [1] http://www.bioparco.it/forma/bioparco_eng/bioparco_eng_ID737.php [2] http://en.villaborghese.it/ -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: CocoonGT hotels
On 8/27/07, Reinhard Poetz [EMAIL PROTECTED] wrote: The GT website doesn't have much to say about recommended hotels yet (http://www.cocoongt.org/Venue.html). Will there be some updates by the end of the weekend? (I will be offline afterwards and would like to have a reservation before my holidays.) Indeed. I expect to finalize that tomorrow. Thanks for your patience, -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
[GT2007] ANN: The 6th Cocoon GetTogether, Rome, October 2007
The Apache Cocoon community is proud to announce the sixth edition of the Cocoon GetTogether, the main annual gathering of current and future Cocoon users and developers. Do mark October 3th through 5th down on your calendars, and get ready for a trip to beautiful Italy. The Cocoon enthusiasts will be waiting for you to join the party in beautiful Rome! During this event, you'll have a unique chance to meet and intermingle with fellow Cocoon hackers, to hear what's hot and what's not, and to get your hands dirty with some real on-site Cocoon coding. Alongside the presentation program, there'll be an exhibition of companies with Cocoon-based or related products and services. During the traditional Hackathon, developers and users will team up to discuss the Cocoon internals and work side by side on current Cocoon issues. It's definitely worth coming to the Hackathon if you really want to know what the inside of Cocoon is all about! Following a tradition of participation with other Open Source communities, the Hackathon will be open to any group of Open Source enthusiasts: feel free to crash the party and enjoy getting together with fellow Open Source developers and users. Apart from this official program, everyone is invited to the (also very traditional) Cocoon community evening events. Italy is well known for great food and wine: other than enjoying the outstanding beauty of Rome, do get ready for some serious eating experience! More information is available on http://www.cocoongt.org. See you in Rome! -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
[GT2007] Request for papers
The sixth edition of the Cocoon GetTogether needs your help! We want you to come on stage and talk about all things Cocoon, the best topics being end-user experience, and reallife, down-to-earth demonstrations of best practices around Apache Cocoon or it's related projects. Please take a look at the below list of ideas and see if there's one or more subjects that you would like to talk about. Talks on different subjects are most definitely welcome! The list below is only there as a guideline to help you in finding a good subject, not to limit your originality. ANYONE is invited to send in a proposal - even if you prefer doing a really short talk, or perhaps a four hour tutorial, don't hesitate to send it in! And no... You don't have to be a committer to do a talk. If you want to present during the GetTogether you are kindly requested to send in a presentation proposal. Presentation topics will be screened for cluefulness, in the sense that we don't want any commercial presentations. Please send in your presentation proposal to info at cocoongt.org - see below for a template to help you in filling out a proposal. DEADLINE Deadline for RFP'S: September 6, 2007, 23:59 hours CET (Wednesday evening) GUIDELINES FOR SUBMITTING A PROPOSAL Do not include proprietary or confidential material in your proposals. We will assume that you do not consider any material included in the proposals to be confidential. All conference presentations are vendor-agnostic and should focus on technology. Your proposal should contain the following information: 1. Proposed title for the talk/session/debate. 2. Brief outline or abstract of the talk/session/debate 3. * Please be as concise as possible. * Please write in third-person context. * Please list any prerequisite sessions or knowledge you feel is essential. * Indicate, if applicable, if this is a beginning or advanced talk. 4. For all proposed speakers, include: speaker name, title, company, address, email, phone number, fax and website. 5. Biography for the proposed speaker(s) showing relevant experience and qualification to speak on the proposed subject matter (not to exceed 250 words). 6. Primary contact/founder name, title, company, address, email and phone number. Proposals should be sent to: info at cocoongt.org. All speakers are required to submit copies of their presentations before September 29th, 2007. These presentations will be included in the conference notes. All presentations will be made available after the conference in electronic (PDF) format. More information, together with a few ideas for topics, is available at http://www.cocoongt.org -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: CocoonGT2007 - When?
On 7/21/07, Gianugo Rabellino [EMAIL PROTECTED] wrote: On 7/17/07, Reinhard Poetz [EMAIL PROTECTED] wrote: Hi Gianugo, are there already some concrete plans, when the GT will take place this year? I would be very interested to know it asap, because a project will start around the suggested dates of end of September or beginning of October and if possible I want to avoid timing collisions as far as possible. Hey Reinhard, sorry to keep you (and everyone else) waiting. We are busy crossing t's and dotting i's, but I plan to send the dates, CFPs and other info RSN. For now, here is the sneak peek: mark October 3th and 4th down. :-) I stand corrected. While we're busy confirming the final location, we decided to add another day, so we're back on our usual 3-day track, which means 3-5th October. Which also makes a great occasion for a weekend in Rome! Stay tuned for updates, there is a great program coming up! -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: CocoonGT2007 - When?
On 7/17/07, Reinhard Poetz [EMAIL PROTECTED] wrote: Hi Gianugo, are there already some concrete plans, when the GT will take place this year? I would be very interested to know it asap, because a project will start around the suggested dates of end of September or beginning of October and if possible I want to avoid timing collisions as far as possible. Hey Reinhard, sorry to keep you (and everyone else) waiting. We are busy crossing t's and dotting i's, but I plan to send the dates, CFPs and other info RSN. For now, here is the sneak peek: mark October 3th and 4th down. :-) Ciao, -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [GT2007] It's that time of the year again...
On 3/16/07, Reinhard Poetz [EMAIL PROTECTED] wrote: Daniel Fagerstrom wrote: Arje Cahn skrev: Hi all, (quoting Joerg quoting the Cocoon analysis report that Daniel found:) Over the last twelve months, Cocoon (Apache) has seen a substantial increase in activity... Good news! What about a Cocoon GetTogether 2007? +1! stuff-I-might-regret-soon *cough* Italy? *cough* :-) /stuff-I-might-regret-soon -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [vote] Jeroen Reijn as a new Cocoon committer
On 3/5/07, Andrew Savory [EMAIL PROTECTED] wrote: Hi, I'd like to propose Jeroen Reijn as a Cocoon committer. +1 -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: ExpiresCachingProcessingPipeline and cache-expires
On 12/13/06, Matthias Epheser [EMAIL PROTECTED] wrote: According to the documentation here http://cocoon.zones.apache.org/daisy/documentation/components/1063/g1/939.html it should be possible to declare the expires time in mod_expires style (e.g.. access plus 4 ours). We couldn't find something about the apache-style support here. We are using a 2.2 development version from about early this year. Are we missing some point or is the documentation pointing to a feature that doesn't exist (any more) ? Definitely a documentation bug. I wrote that piece of code, and the corresponding docs, then the Apache style was dropped sometimes in the process (I found it out the hard way as well, but it was definitely too late at night to fix the docs). Probably, as Carsten notes, this happened when the component was moved from the sandbox. -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Blueprint references
On 10/3/06, Simone Gianni [EMAIL PROTECTED] wrote: Hi there, for those interested, you can checkout current Blueprint code from the SourceSense SVN repository here : https://forge.pronetics.it/svn/scratchpad/blueprint/ FTR, there has been a small fubar in the subversion conf. Should be fixed now. -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [VOTE] Lars Trieloff as a new Cocoon committer
On 10/3/06, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: Dear Community, I think time has come for Lars Trieloff to become a Cocoon committer, +1, bring the Heineken kegs! Ciao, -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [Vote] New committers
On 6/14/06, Joerg Heinicke [EMAIL PROTECTED] wrote: 1. Andreas Hochsteger +1 2. Peter Hunsberger +1 3. Jason Johnston +1 -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [vote] Simone Gianni as a new Cocoon committer
On 3/24/06, Sylvain Wallez [EMAIL PROTECTED] wrote: Hi all, It's spring time, new committers are blossoming! I'd like to propose Simone Gianni for Cocoon committership. I consider Simone a good friend of mine, an excellent developer and a great person overall: I'm certain he will do lots of good stuff. I'm delighted to see him join the Cocoon team, so here is my +1. Given my personal relationship with him, however, I'd like to ask you guys to consider it as a non-binding vote, much rather as an enthousiastic pat on his back. Welcome aboard, Simone! -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [vote] Niclas Hedhman as a new Cocoon committer
On 3/23/06, Daniel Fagerstrom [EMAIL PROTECTED] wrote: I'd like to propose Niclas Hedhman as a new Cocoon committer. +1 -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [RT] a simple release plan
On 3/21/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: Daniel Fagerstrom wrote: Didn't work for me. I copied configuration files and samples as described in http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2 and http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114085759822501w=2 and still gets the same problem as Ben reports in the link above. I.e. that components are not inherited properly to subsitemaps. Stack trace below. Ok, you're right (of course): the hierarchy of bean factories is correctly initialized, including for example the jx generator. For some strange reason, the tree processor of a sub sitemap is creating the correct bean factory but using the root bean factory. Therefore the jx generator can't be found. What's the easiest way to debug the code? Can I easily run jetty in debug mode? http://tinyurl.com/s66vt Just change to suspend=n and you should be ready to go! Ciao, -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [Vote] Release plan for 2.1.9
On 3/21/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) Please cast your votes +1 -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Null session object in JXTG
Guys,
please have a look at:
http://marc.theaimsgroup.com/?t=11382114604r=1w=2n=4
While the documentation seems to imply that the session object should
be available to JXTG, it doesn't seem the case at all. Are we missing
something or is that a bug? The relevant lines to blame seem to be:
src/java/org/apache/cocoon/generation/JXTemplateGenerator.java line 2433:
if (session != null) {
cocoon.put(session,
FOM_JavaScriptFlowHelper.getFOM_Session(objectModel));
}
given that no session object is available in the objectModel, and
given that a few lines above the session is grabbed anyways:
final Object session = request.getSession(false);
that line should become
if (session != null) {
cocoon.put(session, session);
}
which works for us. Or are we missing something? I'm wondering what
should FOM_JavaScriptFlowHelper.getFOM_Session(objectModel) do at all,
if that's the case...
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
In for a beer tomorrow in London?
Hi, I'm coming to London tomorrow, staying overnight. Is anyone willing to join me for a beer or two, some curry and whatever comes to mind? Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Success stories
On 1/19/06, Antonio Gallardo [EMAIL PROTECTED] wrote: Hi Nicolás, Glad to see you considering Cocoon. I think it is a good choice. Unfortunately, I tried to find the Gianugo presentation online but seems like there is not. Maybe Gianugo can share with us the presentation in http://cocoon.apache.org/mirror.cgi under Material form events presentations. Gianugo? :-) Sorry guys, when asking around the various people who were with me on stage I got a few of them who didn't like the idea of such material being available for download, this is why it hasn't been published. I can't blame them for that, actually I'm happy for what I've got which was a massive attention and willingness to collaborate. BUT, Nicolas, do get in touch with me: I have a few references for you of banking projects and I'm more than willing to help you in the evaluation process. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: M10N
On 1/16/06, Reinhard Poetz [EMAIL PROTECTED] wrote: Daniel Fagerstrom wrote: Ben Pope skrev: When Building Cocoon Block Deployer I get a compile error: java.lang.IllegalStateException: basedir src\main\resources\xsd does not exist I get the same error, the directory is there but the castor plugin doesn't find it. Hopefully Reinhard can give a better answer on what is going on. I have no idea what's going wrong here. I just can say it works for me. Don't know if that helps, but I've got it working by changing: configuration propertiessrc/main/castor/castorbuilder.properties/properties schemaDirectorysrc/main/resources/xsd/schemaDirectory /configuration to: configuration propertiescocoon-deployer/src/main/castor/castorbuilder.properties/properties schemaDirectorycocoon-deployer/src/main/resources/xsd/schemaDirectory /configuration in cocoon-deployer's pom.xml. Looks like a basedir issue... Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: M10N
On 1/16/06, Reinhard Poetz [EMAIL PROTECTED] wrote: Gianugo Rabellino wrote: On 1/16/06, Reinhard Poetz [EMAIL PROTECTED] wrote: Uh? Untouched cocoon-trunk, full dir is /Users/gianugo/dev/src/cocoon/trunk/ from where I'm launching mvn... Ahh, that's the difference. I'm running it from ./cocoon/trunk/cocoon-deployer/ ... seems to be a bug either in M2 in general or in the Castor plugin in particular :-( So you mean Cocoon's full build should be run from the cocoon-deployer directory? How so? Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: svn commit: r369374 - /cocoon/trunk/pom.xml
On 1/16/06, Giacomo Pati [EMAIL PROTECTED] wrote: Just a shy question. Is this comparable to the @author tag in the sources? I don't think so. I see it as the POMified way of saying who we are as in http://cocoon.apache.org/whoweare.html, there is no relationship with actual code which was why @author tags were removed. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Jetty and Eclipse
On 1/15/06, Daniel Fagerstrom [EMAIL PROTECTED] wrote: Jorg Heymans skrev: Jorg Heymans wrote: Anyhow, there seems to be something not quite right yet with our eclipse setup. If you run eclipse:eclipse from the top level pom in whiteboard/cocoon-flat-layout, you'll see that the plugin generates eclipse project dependencies between the different modules (very useful!) . For some reason, it's not doing this in trunk. I'm currently investigating this ... The trick here is to do $mvn clean install eclipse:clean eclipse:eclipse before importing the project. The plugin seems to need the projects to be *installed* before it will generate eclipse project references from a reactor build. I tried it and it worked. Guys, sorry for the wasted electrons but I just feel the compelling need to thank you so much for this most promising work. You made me open my eyes on how Maven 2 could help us getting a solid build system which is a huge first step towards semplification: I'm sold on your approach. I hope this short note from the skeptical camp might cheer you up and let you know how welcome your efforts are! Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [VOTE] green light for flattening repo structure in trunk
On 1/5/06, Jorg Heymans [EMAIL PROTECTED] wrote: [+1 ] flatten the structure and pave the way for a 2.2 release [ ] no because And thanks for taking care of that! -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [RT] Simplifying component handling
On 1/3/06, Upayavira [EMAIL PROTECTED] wrote: Reinhard Poetz wrote: --- Carsten Ziegeler [EMAIL PROTECTED] schrieb: Gianugo Rabellino wrote: Yeah, and I really don't understand this - I (and others) propose small but simple steps to a) improve using Cocoon and b) provide a smooth migration path. So I'm coming back to my idea, is anyone against adding constructor injection to ECM++ or at least make it pluggable so I can add it for my own projects? The change adds only a feature while maintaining 100% compatibility. Without having time to understand in depth what you guys are talking about, I'd say that we should not block any features that don't introduce any backwards incompatibilities. If people disagree here, I would be very intersted in their reasons ... So +1 for your enhancements Carsten! Even more - Gianugo makes some valid points about the future. However, at this point, we cannot prove that his opinion is correct. So in my view, we should be taking multiple paths until one shows up to be the clear winner. It's not so easy. First let me state that I don't have any particular blocker if all we're talking about is adding constructor injection to ECM++: whatever goes in the direction of a lighter and less-Avalon-dependant Cocoon gets my applause. I do have issues, though, when mixing models. something we're very good at. Keeping both interface injection and constructor-injection (well, why not setter injection as well at this point, shouldn't be too hard and, hey, gives one more choice) and telling users to take their pick isn't going to work: adding features blindly not because of architectural/design issues but because it's tiresome to add 5 lines of code and - at the same time - not considering how users might be confused by the fact that we're still using Avalon but we're subverting its very principles is just not going to work. Careful also about taking multiple paths (and again, this isn't quite the case of this constructor-injection stuff which gets my +0 as in it's not my favourite solution but I'm fine with it): removing cruft later on is hard, and the situation we are in how should prove it: once you've baked a cake, there is no way to get your flour, butter and eggs back to bake another one. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [RT] Simplifying component handling
On 1/2/06, Ralph Goers [EMAIL PROTECTED] wrote: That seems to be a catch-22. How do you move away from Avalon without making these kind of changes? Honestly, I don't see how anything in the 2.x series could move away from Avalon. Too much refactoring needed, too many issues on the table. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: W3C XML Processing working group
On 1/1/06, Michael Wechner [EMAIL PROTECTED] wrote: I'm not that much interested into yet another DSL expressed in XML, and I don't feel alone at all. Actually I'd much rather drift towards a programmatic pipeline API. what do you mean by a programmatic pipeline API? Uhm, part of the story is on my blog[1] but I'll give you an excerpt and save you a click ;-) It strikes me how, in early 2006, people are still thinking that another XML domain-specific language is the way to go. We are all learning the hard way how the XML verbiage has been useless and, to some extents, detrimental: from Jelly onwards (and yes, I deserve some blame as well) it became crystal clear how programming in XML leads to unmaintainable, opaque and unreadable stuff. The fake myth that XML can be written by grandmas, coupled with the low entry barrier in creating new languages (no compiler's compiler needed, yay!) has produced a plethora of half-baked solutions that just don't get how grandmas aren't going to code anyway, while angle brackets get heavily in the way of anyone who understands even just the basics of programming. Now, don't get me wrong: XML is great when properly used. That is, data (some grandmas might even write data at a certain point), information interchange and tool-oriented stuff. But please, pretty please, when talking about programming (that is, data processing and component connections), take those angle brackets out of the picture and give us the power of effective syntaxes. There might be some exceptions: transformation languages such as XSLT, having to deal with XML all the way, are consistently expressed in XML, but that's not the case for XML pipelines. Pipelines are about connecting, chaining, concatenating: there's nothing there that needs XML to be expressed. It's meta-XML, in a way, a side order to the main XML dish. What we (well, I at least) need are APIs: a standard and effective way to tie XML processing components together so that data manipulation can work in a multistage environment. We then need some machinery around it that provides transparent adapters between the different XML processing world (SAX, DOM, StAX) and we could definitely use some services (logging, management, security) on top of it. But we don't need XML for that. We might want to use it at a later point, as a sort of wrapper around the pipeline language if, and only if, there is a clear need for tooling that could use a well-established and easy to parse data format, but please save our aging eyes and our carpal tunnels from angle brackets whenever possible. [1] http://www.rabellino.it/blog/?p=117 -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: W3C XML Processing working group
On 12/30/05, Sylvain Wallez [EMAIL PROTECTED] wrote: Hi all, The W3C recently set up an XML Processing working group[1] whose primary goal is to define an XML processing language (i.e. pipelines). Wow, innovation at work! :-) AFAIU the group's direction is not to reinvent something new, but to standardize what already exists, taking as inputs two pipeline languages that were submitted as W3C notes, namely Norman Walsh's[2] and XPL from Orbeon[3] (that BTW they claim to be the pipeline language that has in fact been used the most[4]. My impression is that what this WG will end up defining yet another programming language in XML, and that this language will either be very limited in the processing types it allows in order to be implemented on a wide range of platforms (including browsers), or allow a lot of extensibility, thus actually limiting its portability. WDYT, should we join the party? I'm not that much interested into yet another DSL expressed in XML, and I don't feel alone at all. Actually I'd much rather drift towards a programmatic pipeline API. Anyone has the guts to start a JSR on that? :) -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [RT] Simplifying component handling
On 12/30/05, Carsten Ziegeler [EMAIL PROTECTED] wrote:
Aren't you tired of implementing a service/dispose combo for each of
your components over and over again? Now, actually, I am. Big time.
Way too much code me thinks. So what about:
class MyComponent implements SOMETHING, ThreadSafe {
protected final ClassA compA;
protected final ClassB compB;
public MyComponent(ClassA a, ClassB b) {
compA = a;
compB = b;
}
}
I'm definitely not a fan of constructor injection, exp. when we
consider how (way too) often we resorted to inheritance in Cocoon
components. Now, while interface injection is clearly out of fashion,
sticking with Avalon/Excalibur also means that it would be difficult
to get around the container (e.g., how do you release components with
your approach? I assume Excalibur still kinda needs that).
But I think it can even get easier:
1. Let's just assume that every component is ThreadSafe - unless
otherwise stated - no need to declare the interface anymore. I think
apart from the interpreter most components are threadsafe or poolable
anyway.
Again, until Avalon is around I don't see how a marker interface can
really bug you...
2. Let's remove support for pooled components - yes, seriously. Fiddling
with the pool sizes is really annoying. We have a working factory
approach for sitemap components, so why not simply use it overall? And
rewriting the remaining pooled components shouldn't be that hard. (I now
that we are proxying pooled components to simplify the lookup, but you
still have to configure pool sizes).
I'm also still not completely sold on factories. Indeed, they work and
they're a brilliant solution, but am I the only one smelling hack and
workaround?
My final idea is to use even more magic (but it might be too much magic?):
class MyComponent implements SOMETHING {
protected final ClassA component_A;
protected final ClassB component_B;
}
When the component is instantiated all instance variables prefixed with
component_ are setup using some injection mechanism - or perhaps using
annotations?
Yes, that's definitely too much magic. ;-) I'd rather favor an
annotation/attribute based approach rather than reflection hacks...
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: [RT] Simplifying component handling
On 12/30/05, Giacomo Pati [EMAIL PROTECTED] wrote: On Fri, 30 Dec 2005, Vadim Gritsenko wrote: Carsten Ziegeler wrote: Gianugo Rabellino wrote: I'm definitely not a fan of constructor injection, exp. when we consider how (way too) often we resorted to inheritance in Cocoon components. Now, while interface injection is clearly out of fashion, sticking with Avalon/Excalibur also means that it would be difficult to get around the container (e.g., how do you release components with your approach? I assume Excalibur still kinda needs that). Yes, Excalibur still needs it - but it's easy. Bascially, you emulate the service() method on construction of the object and then you emulate the dispose method when destroying the object. Everything our ecm++ needs to know is there. As I said, I've done this in Fortress and we can use that code in ecm++ as well. And we could implement setter injection with some kind of auto wiring as well. It's not really that harder. But using setters again requires to code more than using a constructor. I'm with Gianugo on this one - I'd better have setter injection instead of constructor injection. Actually the problem I see with setter injection is that you normally will open up the setter method (make it public) to your configurator/instatiator and thus to everybody else. I guess we could waste a near to infinite number of electrons debating the various IoC types and their downsides, so I won't delve any further on this (apart from +1ing Vadim's reply to your concerns, exp. the part about final members). My point is actually a tad different: like it or not, we are still working with Avalon which is interface-injection based: bastardizing the model with some clever hacks won't get us anywhere and will just confuse people. Now, if we were to completely change the approach, this discussion might have much more sense, but arguing about it while sticking with Avalon is moot, IMHO. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Supporting conditional GET in Cocoon
On 12/30/05, Sylvain Wallez [EMAIL PROTECTED] wrote: Other issues that I'm going to dive into are redirects and cache control. I'm afraid that if we want to make Cocoon into a well-behaved participant in a Web 2.0 world, we have lots of work to do. Indeed. My impression is that this work is concentrated it two main locations: the http source for incoming streams, and the pipeline engine for outgoing streams where we must better handle etags and last-modified headers. ETags shouldn't be too hard. What we basically need is a hash of some sort on the cache key (you don't really want to use the key directly for security reasons). What's needed, then, is some sort of etag-cache key lookup (or even etag-cache lookup, or even use the hash has the cache key and be done with it) and you should be set. Last-modified stuff is a bit harder since the current cache works on Validity objects and doesn't take modification time into account, but then again it should be enough to augment the cache metadata with the generation date and add some logic (I have something ongoing on my hard drive) to handle the protocol headers. All in all, I have no +1 big enough for the idea of a better behaved Cocoon when it comes to HTTP. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
On 12/22/05, Andrew Savory [EMAIL PROTECTED] wrote: Everyone: Jean-Baptiste is becoming more and more active on the dev list, and has been diligently filing bugs and patches for the last few months. The first post about his activity is from July, 2004 [1]. He seems to have a good grasp of the guts of Cocoon. I think it's time for him to become a committer. Please cast your votes! +1 -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: rejuvenating the webdav block
On 12/16/05, Max Pfingsthorn [EMAIL PROTECTED] wrote: Dear Cocooners, I would like to start rejuventating the webdav block. We have some code to do cool things like event caching and a more general purpose WebDAVTransformer (which can also do propfind, proppatch, etc). If you know anything you would like to see in the webdav block, please say so now. Maybe I can work it in! Lovely! You might also want, while you're at it, considering the new block layout so that it will be easier to build it as a block proper. I might also have some stuff to commit (flowscript support, basically): will get back with that ASAP. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
On 12/13/05, Daniel Fagerstrom [EMAIL PROTECTED] wrote: I agree that the main focus must be to get a 2.2 release. So the question is what to do with the real blocks. They are currently rather close to the specification, but we don't know if the specification is good enough without getting experience from the blocks. For ditching the environment abstraction, that should of course not block any releases. It can always be solved by making the change in a branch and merge it back when it works. I tend to disagree. The environment abstraction is to me part of the underlying public contracts users rely upon: changing contracts between minor versions is borderline but acceptable given the cost/benefit ratio, but it's out of question between revision. Having 2.2 with the old environment and, say, 2.2.1 with a new one seems like breaking our versioning guidelines to me. I'd suggest we ditch it altogether while we still have time. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: JavaScript BOF at ApacheCon
On 12/7/05, Sylvain Wallez [EMAIL PROTECTED] wrote: Hi all, I was contacted recently by Martin Cooper, Struts PMC chair -- yikes! :-) -- that happens to know quite well the people behind DojoToolkit, and we chatted about the opportunity to have some coordinated effort wrt to JavaScript at Apache, both client-side and server-side. So we've setup a BOF [1] on this subject next Monday at ApacheCon. Cool! While at it, I took the liberty to reserve the slot right after this one for a Cocoon BOF: http://wiki.apache.org/apachecon/CocoonReloadedBof Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: JavaScript BOF at ApacheCon
On 12/8/05, Sylvain Wallez [EMAIL PROTECTED] wrote: Gianugo Rabellino wrote: On 12/7/05, Sylvain Wallez [EMAIL PROTECTED] wrote: Cool! While at it, I took the liberty to reserve the slot right after this one for a Cocoon BOF: http://wiki.apache.org/apachecon/CocoonReloadedBof Hmm... it conflicts with the OSGi BOF, which I'd like to attend. Whoops, right! Moved it the day after. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [RT] The next shiny thing?
On 12/5/05, David Crossley [EMAIL PROTECTED] wrote: Gianugo Rabellino wrote: Daniel Fagerstrom wrote: It is so easy to ditch other peoples work, isn't it? Oh, come on Daniel, you're taking this personally. I reckon that Daniel has hit on many important issues related to community-building. If people are not careful then we are going to lose many of our current developers. Which is what, more or less, is happening today, albeit at a slow pace. Just look at the commits or try to find common patterns in the evolutionary discussion: what you will see is a really small bunch of people talking and coding, whereas this community used to have long threads and fast paces. Daniel is right, when you talk APIs people get bored: you could look at it from an ivory tower and label that as childish attitude and , or you can do something to change that and address the real issue which, to me, is lack of people that are confident enough to talk about internals because, basically, they don't feel they belong. C3 is, to me, a step forward in that direction. I strongly respect and admire what you've been doing to push Cocoon 2.2 forward, but you also have to realize how hard it would be for you to carry the burden of being the main responsible for such a core part of Cocoon without a real committment from the community, which I'm not really seeing at the moment. You should realize how the biggest feeling floating around the Cocoon community is that we want to do something to make Cocoon fly and soar high in the skies, instead than strive to survive its own complexity. Cocoon would have already been soaring if we had polished the system and documented as we went. Symptoms, again. Then why on earth the system isn't polished? Lazy butts or nearly-to-impossible work? Cocoon 2.2 is cleaner, but it won't refrain people from telling me how their project could benefit from some Cocoon features, but since the beast is so complex, they're just looking elsewhere or implement in-house Cocoon clones. Cocoon, today, is a terrific tool if you have complex needs (simplifying hard stuff) but it falls short to address the medium to simple stuff, which is where the real beef, community wise, is. We would have retained many of the new people that we had attracted. I get the feeling that our discussions are going to frighten the hell out of our existing community. We have not yet solidified our current offering and now are racing on to the next new thing. So why should they trust us to not repeat that behaviour. We are in danger of being seen as a research project. I'm surprised to hear from you what to me looks like sweeping problems under the rug because they'd scare people away: to me, what's really going on is a bunch of children shouting that the Emperor is naked, what I'd actually expect from the community I want to belong to is understanding how we are able to identify what the real issues are, and address them accordingly. Mind you, having some strong business interests in terms of existing projects with Cocoon 2, I shouldn't really be this much shouting about moving on in possibly incompatible ways: if I've been repeating from months now that we need a 3.0 (remember AC EU?), this is because I think that without a clear step forward, all we can do are small steps solving our self-induced problems while the world is clearly moving to different solutions and scenarios. The Cocoon community has never been a (late) follower as we risk of being now: if shaking the tree helps regaining momentum, then I'm all for an open discussion about it. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: JMX integration (was: Re: [RT][long] Cocoon 3.0: the necessary mutation)
On 12/5/05, Giacomo Pati [EMAIL PROTECTED] wrote: While we are at it. I actually have the need for some JMX instrumentation in Cocoon 2.1. But instead of just writing some MBean wrappers for my components, I'd like to spent some more time on it for a more general solution to it (monitoring component pool sizes come to my mind quickly). Is there any interest do discuss this topic for a possible implementation? Most definitely yes. However, be warned that retrofitting JMX to the current Cocoon architecture seemed like a big headache to me. Maybe going through Excalibur instrumentation (which I've never been able to see working) could do, otherwise expect pain. Lots of. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: JMX integration (was: Re: [RT][long] Cocoon 3.0: the necessary mutation)
On 12/5/05, Giacomo Pati [EMAIL PROTECTED] wrote: On 12/5/05, Giacomo Pati [EMAIL PROTECTED] wrote: While we are at it. I actually have the need for some JMX instrumentation in Cocoon 2.1. But instead of just writing some MBean wrappers for my components, I'd like to spent some more time on it for a more general solution to it (monitoring component pool sizes come to my mind quickly). Is there any interest do discuss this topic for a possible implementation? Most definitely yes. However, be warned that retrofitting JMX to the current Cocoon architecture seemed like a big headache to me. Maybe going through Excalibur instrumentation (which I've never been able to see working) could do, otherwise expect pain. Lots of. Could you elaborate a bit more? I'm interested about oppiions. If my memory serves me correctly (and don't count on it!) I remember skimming through a JMX book with growing pain and anger: basically what I recall is that it's trivially easy to write from scratch code the JMX way, but when it comes to retrofitting (no more vanilla MBeans, you basically have to resort to Model MBeans) I seem to recall a long and outstanding pain in terms of required code to be written in terms of descriptos, not to mention a long sleeve of what seemed to me reflection based bug-prone hacks. But don't trust my FUD: go and read it yourself, I just gave it a cursory look at it, which left me with a sore feeling. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [RT] The next shiny thing?
* refactoring and rearchitecturing mercelesly * 2.2 during Q1 This work will continue to be evolutionary and incremental. And when we have the block system and have cleaned the contracts and the messy implementation of the core, it will be easy and safe to experiment with new great ideas. And we are getting rather close to this point, we just need to finish what we have started. And for the messines we solve that with refactoring. Gosh, Daniel, an outstanding agenda. I'll be watching closely what seems to be a notable list of accomplishments, hoping to help out as well (whatever happens to 3.0, I intend to provide strong and long-standing support for 2.x as well, so every step further is most welcome). But I'm also most interested in seeing things moving forward from a community point of view, stopping the drift of people looking elsewhere (there must be a reason for that, right?). quite risky to try to rewrite everything from scratch, although I have felt the urge myself countless time while struggling with the messy internals. But before you go ahead and rewrite everything from scratch, take some minutes and read why Joel Spolesky thinks that rewriting software from scratch is the: *single worst strategic mistake* that any software company can make http://www.joelonsoftware.com/articles/fog69.html. Two notes here: 1. Joel is talking about companies. Open Source is *much* different. 2. I don't read Sylvain's proposal as a let's dump everything. What I see is a different and fresh approach to real issues, and a solution that goes towards maximum reuse of what we've got so far, ditching as much as we can of the infrastructure burden we've been carrying on for ages. For the actual functionality that Sylvain proposed I think much of it is great and I have argued for things similar to some of them earlier. And they can be added in an incremental way. Here is where we basically disagree. I have this feeling that, unless a major revamp, there is a very slim chance for Cocoon to progress incrementally. I thought OSGi would have helped, with modularization and the like, but as you can see, this is clearly has not been the case: maybe the problem is elsewhere, e.g. the current core being too heavyweight and the user visible part being way to hard to understand? These are my major gripes at the moment, and while I still do believe that the steep learning curve of Cocoon pays off big time, I've come to think lately that we could actually do something to make it better. Leaving our core offering and rewriting everything from scratch means community and product suicide, don't do it. Again, I don't feel this is rewriting from scratch. And while I see your point, I can clearly a stagnation and starvation risk ahead if we don't shift gears and move on. How would you risk manage that? Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [RT] The next shiny thing?
On 12/4/05, Daniel Fagerstrom [EMAIL PROTECTED] wrote: Gianugo Rabellino wrote: Daniel, thank you for taking the time to write this. I understand your frustration, since the behaviour you're describing in your email has clearly been a recurring pattern lately on [EMAIL PROTECTED] However, I'd like to ask you to try and see beyond what happened, Sorry, while I'm not juging people, I base my trust on what they will deliver in the future on what they have delivered in the past, rather than on promisses that everything will be different this time. Are you sure you're being fair to this community? Just look back and see what people has brought you before many of us even faced up: this is what has been delivered in the past, and it's no peanuts to me. Sure enough, if you consider the past year or so, there has been a lot more talk then just code, but I don't think it's fair to look at what we're currently discussing with a snicker, thinking that it's just talk as usual. This team did deliver lots of good stuff, then, while enjoying some success, lost somehow motivation. What you don't seem to understand is how, even among this closed group of highly committed people, who nearly bet the house upon Cocoon, there is a clear will to move on and, while at it, have fun again. why we have been able to build Cocoon 2 but we seem not to be able to go any further: the answer to that, to me, clearly denotes the need for some kind of (soft?) revolution, e.g. Cocoon 3. We are having a soft revolution right now, I ask you and the rest of the community for some persistance instead of start running in still another direction. I'm sorry, Daniel, but what I'm seeing doesn't look interesting enough to (re)attract a large user base over here. Of course what I'm expecting from 2.2 is a set of very nice improvements and some solutions to a few problems, but I don't see how blocks would take the real complexity out of Cocoon. Or better: some complexity will be hidden, but still using Cocoon will mean committing to it and to the way it does things, which is increasingly of little interest to the vast majority of web developers out there. No fun, no gain. And, to answer your specific question, yes, we can stick a few more months watching you guys doing a terrific work in rationalising internals, but even if you were doing the best work in the world, once finished you'll risk to hear us saying h... so what? again and again. My reading of what's happening over here is that we've got to a point where Cocoon internals have become way too complicated, way to difficult to understand and way too difficult to interact with: I think we'd need no more than one hand to count the number of (active) people over here who could comfortably talk about the pipeline engine, the sitemap interpreter, the caching sytem and all that. How can you be so certain that we would getting less complicated if we started from scratch? It might be complicated because it does something complicated. As long as you don't understand the internals you cannot really know, can you? Sure, I might not grasp completely what's going on under the hood today. But my gut feeling is that Cocoon is overengineered in many parts of it and not correctly layered on some other parts. I have a few opinions about it, but they are way off topic in this discussion. Managing complexity is much about finding the right concepts and work really hard to get the right interfaces. The people who built Cocoon from the begining spent a lot of time and effort in getting the apis right. Since then we have made the apis bulky whithout doing that much refactoring to keep things simple. What we need to do is to refactor and rearchitecture Cocoon so that we get rid of bulk that isn't used anymore. And to adapt for things that we would like to add. I have the feeling that we're saying the same thing. What you don't seem to grasp is why there is a camp that feels this is actually Cocoon 3, something different from what we have now, something that can be - and here is where we differ - achived best with revolution rather than with evolution. Now, I think there is a major misunderstanding in what start from scratch really means: to me, it means getting back to the drawing board, trying to reuse what can be reused but being ready to ditch unnecessary load just because it could be incompatible with the vision. Every time I try to discuss apis people get bored. So I have not much faith in that the current community would end up with something better and more elegant than what we have if we started from scratch. Neither do I see that anyone would be prepared to spend the time and effort that it would take. But please, suprise me. Oh, definitely hope so! :-) The good news for you is that so far such attempts had a tendency to sudden failure, so I guess we'll see in a very short time if this could be the right occasion to move things forward or if we'll
Re: [Docs] Articles on Cocoon - reminder
Helma, thanks for keeping the ball rolling. I'm still willing to help out and do my part of the work, that is: - Cocoon and enterprise application integration by Gianugo - Cocoon as service integration platform (suggested by Stefano), by Massimo, Matthew and Gianugo. I'm not sure how much overlap there is between this and the previous one. A huge overlap, actually it's the same thing, basically. :-) - Cocoon success stories, award winning sites, by ??? Here, I've done already a couple years ago a presentation at the Cocoon GT: having companies available to be quoted in print is definitely a different thing, but I'm willing to give it a try. Just: Please let me know if you are willing to write the article and have it done by mid January. If I have two articles to write, I can't really commit to mid January: I will have to process them serially, which means - I guess - one more month to go. Let me know if that sounds good to you. I'll see if I can get them published on xml.com when they start coming in. I have no particular experience in having such stuff published, but I kinda feel that the most prominent websites are unwilling to just re-publish stuff that is part of something else as well. That means, basically, that such articles, if published on, say, xml.com, will have to remain there and just there. I might of course be wrong, but I don't think publishers will like us to include that material in the official Cocoon documentation (well, links are fine of course). Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [Vote] Releasing 2.1.8 tomorrow
On 11/8/05, Carsten Ziegeler [EMAIL PROTECTED] wrote: This is another try to get 2.1.8 finally out: Please cast your votes for releasing 2.1.8 tomorrow, 8th of November. +1 Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [VOTE] new committer: Max Pfingsthorn
On 10/11/05, Bertrand Delacretaz [EMAIL PROTECTED] wrote: So I have the pleasure of proposing Max as our new committer! +1, welcome Max! Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: XULifying CForms (yet another attempt?)
On 10/10/05, Stefano Mazzocchi [EMAIL PROTECTED] wrote: I've been working heavily with XUL recently and I have to say, it could be a refreshing experience if you were used to build DHTML applications. At the same time, be aware that XUL is normally used inside the mozilla security sandbox (say, loaded with chrome:// instead of being loaded with http:// or file://), things change rather dramatically when you use remote XUL (as it is called when you load XUL from http:// as opposed to local XUL. From what I reckon, the security sandbox shouldn't be that much of an issue when dealing just with forms with no access to local resources. Things of course would change when it comest to mangling with the user's station, such as writing files or opening socket connections to different hosts, but it shouldn't be different from applets, to say the least. As far as XBL goes, I would suggest to start without and see how far you can keep going without it (which, for me, is pretty far since I'm not developing reusable UI widgets) Then again, a good lot of CForms is about reusable UI widgets, which makes me think that we'll need XBL pretty soon. Is there a reason to be scared though? I don't quite find XBL, in its simplest incarnations, a daunting technology: if you use it as a poor's man XSLT/macro processor it's more or less a piece of cake. I agree, though, on staying away from overcomplication as much as we can. As for as XHTML, XUL does *NOT* replace XHTML, in fact, you can consider it as an extension to it. There are things that are, IMO, but better than in XHTML (the vbox/hbox/flex model, for example, *WAY* better than the stinking table/tr/td or even better than the CSS3 column layouts) but some XUL widgets are nothing but reusable XHTML constructs with embedded style and behavior (and that's why XBL is related to CSS, you can think if XBL as an extension to CSS to make behavior portable and isolated.. too bad they got the syntax wrong, the use of the XML for XBL is a total golden hammer instance if you ask me) rant Now, call me an old fart, but I don't quite like the continuous and oh-so-fashionable XML bashing I see nowadays. Clearly, writing angle brackets all over the place isn't the most comfortable way of working, but as long as I will be able to (per)use transformations so that I will be able to generate an application using just an XSL stylesheet from a model, I'll be an happy puppy. I just wish we had a (successful) alternate syntax to avoid the carpal tunnel syndrome, yet XSLT/XPath/validations and friends are just too powerful technologies that make me easily fogive input verbosity. /rant As far as roundtripping, Ajax all over the place is the only reasonable answer, IMO... be aware that this makes browser history and bookmarking an interesting problem. Yup, my point exactly. One of the first problems to dissect is how CForms can go from a navigation based framework to a real GUI, where navigation happens locally and it's calculated (mostly) on the client. This is my first and foremost concern and at times I have the feeling that Xul in CForms will have to remain a pure translation of html interfaces (as in s/\.html/\.xul/g). Not a big deal after all. At the same time, browsers are *NOT* build with that in mind and remote XUL cannot prevent the users from clicking the back button Well, this is where continuation should help us. At least possibly. :-) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [Docs] Articles on Cocoon
On 10/11/05, hepabolu [EMAIL PROTECTED] wrote: So the article should not be too technical, but give enough information to help the readers in the second group to find more information. Given the target group the articles should not be too long, certainly not more than 5 pages, probably less. So far I've been promised: - Cocoon and large websites by Pier and Ross McDonald, focus on performance issues - Cocoon and security by Ralph, focus on security issues in internet banking - Cocoon and AJAX by Sylvain, focus on how easy it is in Cocoon - Cocoon and performance by Jack Ivers and Vadim, focus on a comparison of XSLT processors - Cocoon and CMS by Steven, focus on the role/advantages of Cocoon in Daisy Requests: - are there more people willing to contribute articles that could fit this series? Would you be interested in some Cocoon and Enterprise Application Integration stuff, with some JBI flavor on top? I could come up with something. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: XULifying CForms (yet another attempt?)
On 10/11/05, Joerg Heinicke [EMAIL PROTECTED] wrote: Gianugo Rabellino gianugo at gmail.com writes: 1. server roundtrip model: Xul doesn't really fit in a request-response model where all data travel at once upon hitting a submit button. This might lead to two different alternatives: (a) ajax all over the place, where more or less every widget submits events to a Cocoon server or (b) server roundtrips being avoided whenever possible thanks to the richest functionalities of a Xul frontend (think repeaters). Is it an either-or-decision? Well, the way I see it is that either the Xul incarnation of CForms provides a different roundtrip model for client-server communication or it would just be a 1:1 mapping to the current HTML forms. Not much added value compared to an HTML rendering, given it would still be browser based *and* strongly tied to just one browser. Why should anyone choose to use the Xul version nowadays then? I think it's clear using XUL the HTML-way makes no sense. My either-or was related to the two mentioned alternatives. And these two depend heavily on the widget IMO. I see your point. Problem is whether the CForms approach can be abstracted so that a CForm can be transparently rendered both as HTML or as XUL, something I don't see likely to happen at the moment. Consider repeaters in a non-Ajax scenario (i.e. no ajax=true): the HTML CForm will need a roundtrip to the server, which would be overkill for the more powerful XUL rendering. Convergence with the new Ajax model of CForms somewhat blurs the line, yet I feel that a mere translation of CForms widgets to Xul without a rethink of the roundtrip model might be somewhat limiting (as in uh, ok, so what?). Actually, I might go as far as saying that the whole Xul/CForms marriage might not have that much sense now that we have Ajax and all the Web 2.0 yadda-yadda. That is, unless we figure out some real advantage in server interaction. Claas and I came to the conclusion that Ajax as-is does not work with XUL. If you mean as-is as the current Cocoon incarnation, I don't quite see why, apart from some tweaks that might be necessary. The whole idea of Ajax actually was in Xul since day one, given that manipulation of the widget tree is delegated to javascript and network communication has to happen through XmlHttpRequest. And I have the perception that XBL might play a role even here I meant the browser update instructions which is actually only a client-side replacement of elements. The idea of rich clients includes the move of the view to the client, which does not happen with the current Ajax stuff. Only data should be sent to the client. This is what the RDF and XUL template stuff is about. Well, definitely the ideal scenario would be the (rich) client handling navigation and posting pure data back and forth (either bound or unbound to the underlying model - better, the underlying model's XML view, even for objects). Then again, however, this would stretch the CForm paradigm quite a bit. Not sure it's feasible without a major impact in CForms as a whole. My first idea was to provide one CForms template which knows how to display all the widgets described in the RDF, which means the RDF has to include information about the view (e.g. radio buttons vs. drop-down list). Besides this disadvantage Claas mentioned it is impossible to match all and everything in my super CForms template. So we switched to the approach I attached to the bug. Clean separation of data and view (form instance markup is generated with the FormsGenerator, so it contains no details about the view). The template is only on the client, but form-specific. That's what form1_template.xul is for example. Unfortunately this approach seems to be horrible to template writers. If you have to learn the concepts of RDF and this horrible templates of XUL before getting something to work ... Well, I have been tempted by XUL templates, then took some time to read a few rants here and there and became convinced that it's not that mature and reliable as a technology (see http://www.jerf.org/resources/xblinjs/whyNotMozilla/notXulTemplates.html). I know I keep pestering with XBL, but I have the gut feeling that XBL won't be as difficult as Xul templates and could provide a much better experience for form template writers. But I really need to get my feet wet and provide some code. Our conclusion: it's neither the correct approach. Now Claas tries something else on the client-side which is more or less a replacement for XUL templates: DOM 3 XPath or XSLT. The XPath approach would only work for Gecko engine at the moment, but maybe also in future IEs. Uhm, so what? Aren't we targetting XUL in Gecko? It's similar to XUL template in that extent that it tries to match on elements and creates some markup if an XPath matches. Yup, document.evaluate
Re: [VOTE] Move to Jira (Was: Re: Jira or Bugzilla...)
On 10/11/05, Pier Fumagalli [EMAIL PROTECTED] wrote: Ok, there we go, here's the vote... [ ] +1 Yes please, let's move all our bugs to Jira and set it up to work in the following way: +1 Ciao, -- Gianugo
XULifying CForms (yet another attempt?)
I've been playing quite a bit these days with Xul, after a few years' hyatus which made me appreciate the comeback even more. :) I'm more and more inclined in devoting some of my Copious Free Time to a Xul CForms renderer, and I wanted to catch up with other fellow members and see what's going on. I understand from http://issues.apache.org/bugzilla/show_bug.cgi?id=25295 that Jorg is already doing something, so before reinventing wheels I'd love to know what the current status is and if/how I might help. So far, I have identified a few points on my radar: 1. server roundtrip model: Xul doesn't really fit in a request-response model where all data travel at once upon hitting a submit button. This might lead to two different alternatives: (a) ajax all over the place, where more or less every widget submits events to a Cocoon server or (b) server roundtrips being avoided whenever possible thanks to the richest functionalities of a Xul frontend (think repeaters). Convergence with the new Ajax model of CForms somewhat blurs the line, yet I feel that a mere translation of CForms widgets to Xul without a rethink of the roundtrip model might be somewhat limiting (as in uh, ok, so what?). Actually, I might go as far as saying that the whole Xul/CForms marriage might not have that much sense now that we have Ajax and all the Web 2.0 yadda-yadda. That is, unless we figure out some real advantage in server interaction. 2. the role of XBL. I feel XBL (xul binding/extension language) might play an important role in producing advanced widgets (again, think repeaters, calendar popups, double selection lists... well, you name it). Still, XBL is tightly coupled with CSS, and I'm not sure how to manage the CSS-XBL relationship within Cocoon. 3. HTML orientation of CForms: despite a clear intention to stay as neutral as possibile, CForms has a strong bias towards HTML in its most advanced widgets (well, think HTMLarea to see my point). I'm not sure if it's entirely possible to get rid of the HTML heritage, and I kinda feel that in some cases it even doesn't make much sense (hey, after all Xul is happy with xhtml snippets). Well, these are just a few initial thoughts, which don't even deserve the status of [RT]: let's say I'm just trying to break the ice and see what's going on in Xul/Cocoonland. Awaiting for your comments! Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: XULifying CForms (yet another attempt?)
On 10/10/05, Joerg Heinicke [EMAIL PROTECTED] wrote: Gianugo Rabellino gianugo at gmail.com writes: 1. server roundtrip model: Xul doesn't really fit in a request-response model where all data travel at once upon hitting a submit button. This might lead to two different alternatives: (a) ajax all over the place, where more or less every widget submits events to a Cocoon server or (b) server roundtrips being avoided whenever possible thanks to the richest functionalities of a Xul frontend (think repeaters). Is it an either-or-decision? Well, the way I see it is that either the Xul incarnation of CForms provides a different roundtrip model for client-server communication or it would just be a 1:1 mapping to the current HTML forms. Not much added value compared to an HTML rendering, given it would still be browser based *and* strongly tied to just one browser. Why should anyone choose to use the Xul version nowadays then? Convergence with the new Ajax model of CForms somewhat blurs the line, yet I feel that a mere translation of CForms widgets to Xul without a rethink of the roundtrip model might be somewhat limiting (as in uh, ok, so what?). Actually, I might go as far as saying that the whole Xul/CForms marriage might not have that much sense now that we have Ajax and all the Web 2.0 yadda-yadda. That is, unless we figure out some real advantage in server interaction. Claas and I came to the conclusion that Ajax as-is does not work with XUL. If you mean as-is as the current Cocoon incarnation, I don't quite see why, apart from some tweaks that might be necessary. The whole idea of Ajax actually was in Xul since day one, given that manipulation of the widget tree is delegated to javascript and network communication has to happen through XmlHttpRequest. And I have the perception that XBL might play a role even here 2. the role of XBL. I feel XBL (xul binding/extension language) might play an important role in producing advanced widgets (again, think repeaters, calendar popups, double selection lists... well, you name it). Still, XBL is tightly coupled with CSS, and I'm not sure how to manage the CSS-XBL relationship within Cocoon. That's really advanced stuff. Starting with simple stuff will be hard enough ;) Hmm... point is I'm afraid you won't go much farther than a few text input, checkboxes, radios and selection lists without XBL... Breaking the ice might be necessary :) Wait for the code submit and the status I will send. Sure thing, looking forward to it! -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [vote] Ross Gardler as a new Cocoon committer
On 10/5/05, Daniel Fagerstrom [EMAIL PROTECTED] wrote: Hi all! I'd like to propose Ross Gardler as a Cocoon committer. He is one of the driving forces in the Forrest project, he has been quite active in our documentation efforts and in integrating Forrest, Lenya and Cocoon. +1, Ross well deserves it. -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Validation block: multiple step validations and errors
As promised, we're ready to start hacking on the validation stufff, and here comes a first request. :) Our typical use case (may I remind you that we're building a full fledged validation server?) requires multisptep validation, that is validating an input against a set of different schemas (say an XML Schema and a Schematron file, as an example). This process, to the final user, should be as transparent as possible, and we wont to provide her with an error report, in case something goes wrong, that gives as much information as possible: this means that, in case there are errors coming both from the first and the second phase, we don't want to stop processing the XML right away and provide just the first step errors. With the current validation block this isn't quite possible: the validation report transformer either passes the original events through or provides a totally different (error reporting) XML stream. We are currently thinking of somewhat hack our way through by providing a custom error handler, shared between the different validation steps (implementation note: a ThreadLocal, I guess), that silently accumulates error notifications, providing them all at once when processing ends. The final step of the pipeline could then be either a validation transformer that somewhat is aware of his final role or a custom transformer that checks if there are errors streaming them away or, if everything went smooth, just passes events through. Yes, we know how having a full fledged error reporting is somewhat a holy grail, but we'd like to strive to get as far as possible. Of course we are open to alternatives, and we'd love to know if this effort might be of interest to the validation block as a whole or if our needs are just too vertical to become a shared component. Opinions, anyone? (and yes, Pier, once this thingy is sorted out, the Schematron factory is next :)) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Do we want a GUI installer?
On 9/22/05, Upayavira [EMAIL PROTECTED] wrote: Daniele Madama wrote: Idea is simple, but works. I like the fact that it respects the dependency information. That will ease people's lives a lot. My Ant based installer didn't do that. Here's a few thoughts: 1. Could you show the dependency information in the right hand pane? It isn't always clear as to why a block's tick is grayed out. 2. Could you add a page/tab for the basic options in build.properties? 3. Could you add a pane that actually invokes Ant? If you could do that, and added a 'welcome' pane, you'd have written a full installer, which would be excellent. All it would need to do is set stdout to an output stream that gets written to a list box or text box, and has a cancel button. 4. Could you make it use a more modern UI style? I'll add #5 then: adding a Jetty control pane to start/stop the webapp. -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Do we want a GUI installer?
On 9/22/05, Upayavira [EMAIL PROTECTED] wrote: Gianugo Rabellino wrote: On 9/22/05, Upayavira [EMAIL PROTECTED] wrote: Now, pushing this a little further - a pane to enter details of a single mount that can be added automatically into the root sitemap - or to create a mounttable file. That way, you run this app, select your blocks, tell it where your own site is, click 'configure', click 'run' and you're away. Then, you realise you need an extra block, you click 'stop', you click to select your block, you click start, it says I need to rebuild, hang on, and it rebuilds. Then it starts the webapp, with your app mounted already, and we're all really happy :-) Hmmm... you're the guy who presented the SVNClassLoader at ApacheCon, right? Well, it shows. :-)) Anyway, yeah, that sounds great indeed, and definitely no rocket science. My take would be grabbing the current source code, commit it and start hacking on it. How about it? -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Do we want a GUI installer?
On 9/22/05, Upayavira [EMAIL PROTECTED] wrote: Gianugo Rabellino wrote: On 9/22/05, Upayavira [EMAIL PROTECTED] wrote: Gianugo Rabellino wrote: On 9/22/05, Upayavira [EMAIL PROTECTED] wrote: Now, pushing this a little further - a pane to enter details of a single mount that can be added automatically into the root sitemap - or to create a mounttable file. That way, you run this app, select your blocks, tell it where your own site is, click 'configure', click 'run' and you're away. Then, you realise you need an extra block, you click 'stop', you click to select your block, you click start, it says I need to rebuild, hang on, and it rebuilds. Then it starts the webapp, with your app mounted already, and we're all really happy :-) Hmmm... you're the guy who presented the SVNClassLoader at ApacheCon, right? Well, it shows. :-)) Oh, infamy already? ;-( Nh, sound respect to a bright mind: we need dreamers. :-) Anyway, yeah, that sounds great indeed, and definitely no rocket science. My take would be grabbing the current source code, commit it and start hacking on it. How about it? Sounds great. Although do I detect some suggestion that I might be doing some of that coding? :-) Really, before we commit it, we need some buy in from a number of people who are prepared to develop it/keep an eye upon it. Well, I for one, would be glad to back this effort and provide oversight as well as some code (well, not that I've been doing much coding in Cocoonland lately, but I have a few things simmering on my hard drive...including a Jetty stop/start panel. I just wish I had 48hrs days). In any case, while I have great expectations for 2.2, I also think that increasing the user experience even for the time being could be a good thing, and this small tool might help people in their first impact with Cocoon. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Do we want a GUI installer?
On 9/20/05, Upayavira [EMAIL PROTECTED] wrote: If someone is still interested, I'll happily give pointers/ideas, maybe even find the time to revisit and implement it myself. However, things with OSGi/blocks are much clearer now than they were. Do we still need to improve the user experience of building 2.1? What do people think? I think so, Cocoon 2.1 is here to stay for a while. FWIW, a colleague of mine (Daniele Madama) wrote a small GUI to manage blocks selection (think make xconfig for the linux kernel). If you deem it useful, my take is Daniele would be glad to contribute it. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Do we want a GUI installer?
On 9/20/05, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: * Gianugo Rabellino: I think so, Cocoon 2.1 is here to stay for a while. FWIW, a colleague of mine (Daniele Madama) wrote a small GUI to manage blocks selection (think make xconfig for the linux kernel). If you deem it useful, my take is Daniele would be glad to contribute it. On FreeBSD, there is a Cocoon installer that has such a GUI. See attached screenshot. This is based on a BSD Makefile. If I ever needed another reason to praise the FreeBSD guys, here it is... however, I fear that tool is less than portable, given it requires make and ncurses/dialog/whatever. My take is that a minimal Swing app able to deal with dependencies might be a good step forward anyway. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Validation: documentation
On 9/13/05, Pier Fumagalli [EMAIL PROTECTED] wrote: Wrote some documentation for the validation tonight: http://cocoon.zones.apache.org/daisy/documentation/blocks/ validation.html I know that Gianugo wanted to know how to integrate Schematron with it. Gianugo, does the doc make sense for you? Look at the last chapter. Yup, definitely and thanks for the effort. Now, if only I wasn't drowning in deep and stinky stuff, I would write the Schematron part right away. Give me a few more days. :-) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [vote] Arje Cahn as a new Cocoon committer
On 9/8/05, Sylvain Wallez [EMAIL PROTECTED] wrote: I'd like to be the voice of a general opinion among Cocoon developers that Arjé Cahn should be made a Cocoon committer. +1 and welcome! Now, where is my beer? ;-) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: validation block: RELAX-NG, XML-Schema, any other languages required?
On 9/7/05, Pier Fumagalli [EMAIL PROTECTED] wrote: I'm almost done implementing XSD (XML Schema) validation using Xerces' internals! :-P That was hard, but I got it working outside Cocoon's sandbox, now it only needs a couple of wrappers for source/entity resolution between Cocoon and Xerces. Any other languages that _seriously_ deserve some attention before marking the block as stable ? I'd love to see Schematron, as the only language which allows easy and selective validation (not to mention domain-specific validation as well). I still don't quite see why you didn't go the MSV way apart from distribution issues (we have schema, rng and schematron implemented as msv plugins in our validation stuff), but hey, as long as you're giving free code away, I'm happy ;) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: validation block: RELAX-NG, XML-Schema, any other languages required?
On 9/8/05, Pier Fumagalli [EMAIL PROTECTED] wrote: On 8 Sep 2005, at 10:19, Gianugo Rabellino wrote: On 9/7/05, Pier Fumagalli [EMAIL PROTECTED] wrote: If you want to use MSV, simply write a couple of mocks classes for what you need, and from there you can build a MSVSchemaParser and a MSVSchema you can use directly with the components provided within the validation block. That should be straightforward to do. Someone could do exactly the same for javax.xml.validation in JAXP 1.4 and so on and so forth (actually, javax.xml.validation _is_ redistributed with cocoon, I'll do something with it)... ... javax.xml.validation *is* MSV ;-) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Warped Text...
On 9/2/05, Pier Fumagalli [EMAIL PROTECTED] wrote: Guys, for one of our registration projects, we needed to verify that a user is really in front of the browser (no automatons allowed). I wrote, then, a little text-warper that randomly stretches text for a user to see (and re-type) and writes out JPEG files. In addition to that I wrote a little random-text generator and encryptor (so that you can be sure the text displayed is nowhere in your HTML). An example of a generated image is attached here. Did you look at what Ugo did with captchas? http://agylen.com/2005/05/16/captcha-validator-for-cocoon-forms/ Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: JING Transformer...
On 8/30/05, Pier Fumagalli [EMAIL PROTECTED] wrote: I'm working on a JING Transformer (using JING in the pipeline to validate a document using RNG). Is there interest to have it in Subversion? I, for one, would be very interested. We're doing some complex validation stuff using MSV, Jing would definitely be interesting as well. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [VOTE] Jorg Heymans as new committer
On 7/31/05, Antonio Gallardo [EMAIL PROTECTED] wrote: So, I'm pleased to propose Jorg Heymans, as a committer. +1, and welcome aboard! -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: DirectoryGenerator using abstract Source
On 7/14/05, Daniel Fagerstrom [EMAIL PROTECTED] wrote:
I don't think it is a good idea to deprecate things that have been
arround in Cocoon from the very beginning and is part of about every
book, tutorial and article that have been written about Cocoon.
I can clearly see your point. Being DG so much part of core Cocoon,
it's tough stuff to handle. However, it's also very clear how much TG
is more flexible: if you consider that a guy like Michi, a Cocoon and
Lenya committer, was unaware of its existence, you'll realize how
we're doing a very bad job in promoting our stuff, and how having
old stuff lying around stops the way to evolution and might become a
maintenance nightmare.
If they where considered harmfull in some way, hard to maintain or was
in the way for developing new important stuff I would agree in
deprecating them. But I don't see that it is the case.
Could well be. DG is solid stuff indeed, much like XSP who have been
there almost forever with little to no need for maintainance.
A much better way to handle old stuff where we have found better ways of
achieving what they are intended for is IMO doing like we did for XSP,
remove it from core and move it to a block.
For the DirectoryGenerator we could have a certain DirectoryGenerator
block, or put it together with some other obsololete stuff that belong
together in some way in a block. Or we could have an
backcompability2.1 block, with everything that we find old fashoned
and want to move away from core.
I like that. It would be a nice way of migrating stuff. However, to
make it happen, we should make sure first that TG does everything DG
and relatives can do (images, Mp3, etc...).
In any case, avoid extends like the plague. If anything, the hassle
we're going to have because of that bunch of generators extending DG
should prove how extends can be harmful.
I don't follow you here, care to expand on it?
It's just the old fart of favoring composition over inheritance. This
stuff (taken from o.a.c.generation.ImageDirectoryGenerator) smells
Fragile Base Class:
protected void setNodeAttributes(File path) throws SAXException {
super.setNodeAttributes(path);
[...]
}
(wherever I see super(), I tend to frown :-)). I'd much rather see a
different pattern based on source descriptors and inspectors, much
like what has been done in the repository block with
InspectableSource, SourceDescriptor and SourceInspector.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: DirectoryGenerator using abstract Source
On 7/14/05, Joerg Heinicke [EMAIL PROTECTED] wrote: Michael Wechner michael.wechner at wyona.com writes: Wow, 2 years ago! And what about starting a real migration now by starting with the unclean way (DirectoryG extends TraversableG with old namespace and directory/file metaphore as you wrote it), deprecating it at the same time and making the TraversableG the officially supported one? just one note re such a migration. Wouldn't it make sense to actually rename the TraversableGenerator to CollectionGenerator and introduce something like ResourceGenerator (or does that exist already?) and do DirectoryGenerator extends CollectionGenerator FileGenerator extends ResourceGenerator such that the terminology is consistent? For the FileGenerator I have another name in mind since a long time: XMLGenerator. This would make it consistent with HTMLGenerator and nearly any else generator too. From where the XML is read is independent on the generator itself, but only depends on the source provided via @src in sitemap. Having this in mind ResourceGenerator is not the best name possible IMO and will continue the irritating naming. Don't want to rain on the party, but this has been exactly the kind of discussion that led nowhere a couple years ago. I'm now convinced that File/DirectoryGenerator are there to stay, there is just too much stuff depending on it. Apart from naming issues (beware the bikeshed effect), my take would be: 1. move TraversableGenerator to src/core, deprecate DirectoryGenerator leaving it untouched 2. insert some log.xxx(DG is now deprecated, please use TG instead), where xxx is promoted from debug to error in a few release cycles 3. optionally start introducing XMLGenerator the same way (though the only path I can foresee is via cp) In any case, avoid extends like the plague. If anything, the hassle we're going to have because of that bunch of generators extending DG should prove how extends can be harmful. Actually, it might be worth thinking about refactoring the whole stuff using composition. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: DirectoryGenerator using abstract Source
On 7/13/05, Michael Wechner [EMAIL PROTECTED] wrote: Unico Hommes wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Wechner wrote I think it would make sense to make a note within the DirectoryGenerator that the TraversableGenerator exists and is more generic. In fact IMHO, it should be deprecated in favor of TraversableGenerator... I didn't dare to suggest that ;-), but on the other hand I have to say, that DirectoryGenerator sounds more familiar than TraversableGenerator, but maybe one just wants to subclass it: DirectoryGenerator extends TraversableGenerator We've been through this before: http://marc.theaimsgroup.com/?t=10578281593r=1w=2 In a word: backward compatibility. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: looking for a moderation volunteer
On 7/6/05, Steven Noels [EMAIL PROTECTED] wrote: Hi all, I'm having my annual full-month holiday shortly, and since my main source of spam are the mailing list moderation messages, I'd like to pauze moderating during these four weeks. IIRC, Andrew is my sole companion moderator - so having another volunteer on the job while I'm temporarily on leave would be nice. One more list won't hurt. Count me in. -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [QVOTE] Add getSitemapURIPrefix() to the Request
Lazy vote here on the subject of adding getSitemapURIPrefix method to the Request interface. Details are in the bug mentioned below. Wholehearted +1! Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [VOTE] Document Editors, and a new Committer
On 6/9/05, Upayavira [EMAIL PROTECTED] wrote: [ ] Helma Van Der Linden as a Cocoon committer +1 Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Session replication
On 6/7/05, Matthew Langham [EMAIL PROTECTED] wrote: ...Obviously Cocoon doesn't yet support this - through the problems in Flow etc. (and maybe others)... FYI, in case you hadn't seen it, there's http://wiki.apache.org/general/SummerOfCode2005#cocoon-flowscript- serialization Of course this doesn't solve the problem *today* ;-) No, unfortunately not. The customer considers this requirement to be a make-or-break for using Cocoon :(. Doesn't Javaflow support serialization? In any case, when I stumble across such kind of issues, my answer tends to be twofold: first of all I question the real need for unconditional failover, since this is an issue that tends to become gold plating in no time flat. I still have to see a single application that fails over nicely, given that devs tends to put in session objects any kind of stuff (most notably database connections). Remember that a single non-serializable object in your session will make failover support useless. Technically wise it's much better to plan for failures (don't use sessions unless you really have to) instead than leaving it to the underlying framework: high availability is much better achieved by redundancy than clustering (I saw just too many clusters failing). Having said that, it's definitely true that flowscript by itself isn't serializable (yet). However, in a business continuity scenario, what you should do is keep your sendPageAndWait() to a bare minimum: ideally a continuation shouldn't spawn more than two or three screens, whereas the business model should be kept elsewhere. Consider CForms, as an example: most of the time, the continuation is used for two or three screens: fill, [confirm], commit. The real use of continuations, here, is when form validation fails: this is where you might have a continuation lasting for a dangerous number of screens and, if a failure occurs, you might be stuck. However, it shouldn't be much of an hassle to perform (partial) bindings upon every submit on a clusterizable object, so that if something fails you can start a (new) form on the fallback server, losing as little work as possible. Bottom line: I consider this more as an uneducated CIO issue rather than a real technical blocker. But you will always find clueless people. :) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [VOTE] Removing author tags
On 5/2/05, Sylvain Wallez [EMAIL PROTECTED] wrote: So I propose to remove @author tags with people names from all our source files. +1 Additionally, if you agree with removing names, do you want source files to have: [X ] no @author tag at all, [ ] @author The Cocoon development team [ ] @author . (something else) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Manually specifying a mounted sub sitemap's context
On Apr 11, 2005 5:44 PM, Stefano Mazzocchi [EMAIL PROTECTED] wrote: I mean, look at you: sitemap via webdav? via JCR170? what's next? SOAP? what about describing the sitemap in LDAP directly, you could use netinfo to edit it! hmmm, no, wait, what about sitemap via email? you post the sitemap attached to an email to a mailing list and then the last becomes the published one? I'll take the offensive bit out, enjoy the ironic part and comment on the beef. I have always considered Cocoon as a *framework*. Frameworks are supposed to be horizontal foundations on which vertical layers can be built. With Cocoon you can build an e-commerce site, a CMS, a banking application or an XML middleware: to do so you use the tools of the trade, sitemaps, pipelines and all the yadda-yadda. However, it very possible (and actually likely) that application's high-level business rules don't quite map to a Cocoon sitemap because either a) all they need is a small subset of the sitemap crop or b) the semantic equivalence is poor. Now, let me make you a concrete example: we are currently building an XML validation server which is supposed to be able to solve a few issues in the XML validation world for some B2B humpfko. Basically what we do is provide a sequence of validation steps where you can define an arbitrary set of schema, relaxng, schematron and the like. Every validation step is logged separately so that you can spot problems in the incoming flow, This is clearly a pipeline and Cocoon is - to me - the right tool for the job. However, this tool has to be administered day in day out from non Cocoon people, so compare this: map:match type=xpath pattern=/document/[EMAIL PROTECTED]'something'] map:generate type=stream/ map:transform type=msv src=repo://some-schema.xsd/ map:transform type=mylogger map:parameter name=level value=warning/ /map:transform map:transform type=schematron src=repo://some-schematron.sch/ map:transform type=mylogger map:parameter name=level value=error/ /map:transform map:serialize type=xml/ /map:match (and consider that this is hidden within the whole sitemap shabang, with components, resources, views and whatever) to this: select xpath=/document/[EMAIL PROTECTED]'something'] validate src=repo://some-schema.xsd log=warning/ validate src=repo://some-schematron.error log=error/ /select If you were the one having to maintain some 500-ish of these statements, which format would you prefer? Heck, even I, notwhitstanding my Cocoon experience, would go for the second option - also considering how easy it would be to GUI-fy that format. Now, the second option can be clearly translated into an equivalent sitemap by means of an almost braindead xslt. And whether it can be disputed whether such a sitemap should be generated dynamically or in an offline way, I don't think that favoring a more domain-oriented vocabulary for a specific application can be FS. Not, for that matter, is FS willing to persist such configuration files in places other than the local filesystem (think clusters). I fail to see how webapp componentization and blocks are going to solve issues like this one. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Manually specifying a mounted sub sitemap's context
On Apr 10, 2005 4:24 PM, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Sylvain Wallez wrote: So, although we may accept a new context attribute (I'm currently -0.9 for this), I'm -1 for accepting dynamically generated sitemaps. I'm -1 as well. (that was easy to guess ;-) Uhm, first of all I'd say that the context attribute could be really useful in contexts other than dynamic sitemaps, so I'd welcome that addition. WRT dynamic sitemaps, I don't quite have a real opinion, I can clearly see how it might lead to abuse, but I also tend to think that Cocoon, as a framework, should allow applications built on top of it using subsets of functionalities abstracted in high level configuration files. However, if it's agreed once and for all that dynamic sitemaps are to be considered harmful, so be it and let's enforce it: it slipped through already, and now it doesn't work anymore because of a bug. A check failing with an error message would be enough to prevent stupid people like me to try it again in the future (even though there will always be the http route...). Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Manually specifying a mounted sub sitemap's context
On Apr 10, 2005 10:17 PM, Sylvain Wallez [EMAIL PROTECTED] wrote: Gianugo Rabellino wrote: However, if it's agreed once and for all that dynamic sitemaps are to be considered harmful, so be it and let's enforce it: it slipped through already, and now it doesn't work anymore because of a bug. A check failing with an error message would be enough to prevent stupid people like me to try it again in the future (even though there will always be the http route...). Well, as long as there is the http route, blocking cocoon: will just lead people to use an uglier workaround which you just engraved in the archives for posterity ;-) Hey, I wasn't the first one to suggest that ;-) So if we're to enforce something, it should be that a sitemap is a file, or a classpath resource (yes, I have this usecase). Yep. Tricky, though: I sure can imagine sitemaps stored anywhere (why not a JSR170 repo? or a webdav server? as long as it's static stuff...), and blocking this possibility just to avoid (ab)use of possibly dynamic protocols such as cocoon or http could be a bit too much. I'd rather go for a big fat warning then... Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Cocoon Hackathon at ApacheCon
On Apr 1, 2005 8:40 AM, Torsten Curdt [EMAIL PROTECTED] wrote: [X ] there is a chance I gonna make it -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [Vote] Release of 2.1.7 on wednesday
On Tue, 22 Mar 2005 15:48:34 +0100, Carsten Ziegeler [EMAIL PROTECTED] wrote: It seems that most of us agree that the current reported problems are no blockers, so I suggest to release tomorrow (wednesday) +1 -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: cocoon:// protocol and map:mount
On Mon, 21 Mar 2005 13:49:20 +0100, Carsten Ziegeler
[EMAIL PROTECTED] wrote:
Gianugo Rabellino wrote:
OK, I'm doing something highly unortodox but believe me, I have a good
reason for it. :-)
The application we're developing ATM could really use some dynamic
generation of sitemaps (no, I'm not talking about
dynamic-per-request-and-conditional stuff: what I need is a sort of
macro system generating a whole sitemap out of a very simplified
configuration file). However, if I try this:
map:match pattern=mymaps/**
map:mount src=cocoon:/generate-mymaps-sitemap/{1}
uri-prefix=mymaps/{1} check-reloads=true/
/map:match
I'm hit by a of java.lang.StackOverflowError, with some bus errors(!)
Any pointers on where to start looking?
Hmm, I know that this worked as we used it as well in some rare cases...
Did you try using an absolute path (cocoon://...) ?
Actually no, I used cocoon:/. However, changing it with cocoon://
causes a SourceNotFoundException, with Cocoon seemingly using a
file:// URL to resolve the inputstream, which is even weirder... does
it rely on SourceResolver at all?
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: [RT] Configuring Cocoon
On Thu, 17 Feb 2005 08:45:33 +0100, Carsten Ziegeler
[EMAIL PROTECTED] wrote:
I think you missed the point. 99% of cocoon.xconf belongs in the war
file, hidden away. However, there are a few configuration items such as
the pool sizes that need to be configured when Cocoon is started, not
when the war is built. IMO, that is the value of Carsten's enhancement.
Exactly :)
Now, it doesn't make sense to me to have copies of the whole
cocoon.xconf or logkit.xconf just because one or two values are
different. That's not maintainable.
It is maintainable if those files are automatically generated from a
common template. OTOH, how can be more maintainable having the same
configuration data split over two different resources, one of which
can reside in four different places, resolved at runtime? I kinda
expect all sort of weirdos happening... and I still feel that this is
a hackish way to solve a real issue which might deserve more
attention.
Ralph is right saying that a few configuration data belong to the
sysadmins. Having been a sysadmin myself, I used to complain a lot
about the missing SoC in the average Java applications configuration
files, where developer-oriented information is intermixed with
performance and system administration. However the solution to me is
pinning out those settings who belong to the application
administration and provide a (tool/file/registry) for them.
Let's take pool settings as an example: I don't feel that
pool-max=${whatever} * 10 / 2} is a good solution: what if
${whatever} is unspecified? How would you log the failure? How would
you log what is the actual runtime setting been applied when you're
trying to debug a performance problem, just to find out that you had a
stale cocoon-setting.properties lying somewhere and having precedence
on your carefully tuned setting? Me, as a sysadmin, would be quite
pissed about this indirection mechanism: I sure want a way to
configure my application easily, which means that I need clear
directions and possibly tools for that: what I definitely don't need
is an arbitrarily opaque setting in a config file, requiring me to
hunt for the real data somewhere else.
But hey, sysadmining is purely a matter of taste, and this starts
looking much like bikeshedding: so don't bother about me being an old
fart and go ahead. I'll keep for myself the pleasure of stating an I
told you so at a proper time. :-)
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: [RT] Configuring Cocoon
The problem with cocoon.xconf is that it is part of the war file. This makes it very difficult for our operations folks to change it since it will get over-ridden each time the app is redeployed. Doesn't have to be. The location of the .xconf is specified in web.xml (now, if you ask me, it could well be a system property). This is how exactly how we handle different configurations: they are stored elsewhere (actually version-controlled inside the project itself) and referenced by the web.xml setting. Same for logkit.xconf. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [RT] How scripting made me hate java
make it interesting. The Cocoon core isn't sexy anymore: people wants easy isolation development, testing tools, up-to-date IoC techniques and, most of all, they don't want to have to learn a ton of non-standard technologies just to itch their own scratch. The clean slate, if ever going to happen, should take all that (and possibly more) into account. As you can see, I sincerely believe that the java try/fail cycle is really just a small corner of the overall picture. But yes, we have a problem. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Adding the sitemap path to Cocoon's Request object
On Mon, 14 Feb 2005 09:29:08 +0100, Carsten Ziegeler [EMAIL PROTECTED] wrote: Gianugo Rabellino wrote: SNIP/ I am very bad in naming stuff, but I would say that something like getSitemapPath() could do the trick. Hmm, did you have a look at the Request interface in 2.2: String getSitemapPath(); Is this what you're looking for :) D'OH! OK, I'm going to write 200 times every committer is supposed to check out 2.2 as well as a punishment. So, let's change the question: what's wrong in backporting this functionality to 2.1? Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [OT] Personal news
On Mon, 14 Feb 2005 09:43:21 +0100, Bertrand Delacretaz [EMAIL PROTECTED] wrote: Le 14 févr. 05, à 09:40, Sylvain Wallez a écrit : ...Subscribed? I can't find the RSS feed. Reinhard? hmmm...Monday over there hey? Look under All poetz.cc channels that you can subscribe. [RSS] at http://www.poetz.cc/weblog/ It has to be monday over here as well. This is my source of the snippet, nothing I can really use: pAll apoetz.cc channels/a that you can subscribe. [RSS]/p And, meanwhile, all my best wishes as well Reinhard :-) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Adding the sitemap path to Cocoon's Request object
The fellow readers of my blog might have noticed that pretty much on top of my Cocoon rant list is how unnecessarily complex is to build relocatable Cocoon applications, that is applications who can work no matter how shallow or deep are nested within the Cocoon hierarchy. The problem I'm facing is that in order to build relocatable links you either have to: 1. resort to strictly relative links, something that quickly becomes unmanageable; 2. perform string manipulation by substracting request.getSitemapURI() from request.getRequestURI(). This is painful and slow in XSLT, as an example, and requires two parameters instead than the one you're actually looking for (hence being error prone at best); The solution is technically a piece of cake, and we have been using a braindead custom inputmodule exactly for that. However, I feel that this data should be available from the Cocoon environment straight away, the best place being o.a.c.environment.Request (which will provide immediate user access through the RequestInputModule). I am very bad in naming stuff, but I would say that something like getSitemapPath() could do the trick. Being this a change in the core environment API, no matter how harmless, the issue might deserve some discussion and a vote. Or a big slap in my face if I'm missing the obvious solution. :-) So, is that only me having to face this issue day in day out? Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com
Re: [proposal] Cocoon documentation system
Actually, and I'm not joking, I think we should have a hero plate on our web page and put the name and have a nomination!... some ego stimulation goes a lng way... h Wow, employee^H^H^H^H^H^H^H^Hcommitter of the month! Now that would feel like working at McDonald's :-) -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [proposal] Cocoon documentation system
On Sat, 15 Jan 2005 09:17:10 -0500, Geoff Howard [EMAIL PROTECTED] wrote: - component (Java) that reads from and commits to SVN - should work over WebDAV, shouldn't it? I know there are some specialist in this community who could help out here (Unico, Gianugo, Guido) We have a huge team of specialists on the dev list. Yep. I hope that I can convince at least one of them to help me. Actually I need some Java code ;-) So here I ask officially: Who volunteers to write the Java code that communicates with the SVN repository (read and commit)? You may find this more problematic than you'd expect. I follow the subclipse list a little and have the impression that pure-java library development against SVN lags behind because it's difficult to keep up with the evolving standard. Sorry for being late in jumping in. Just wanted to let you know that I already am using SVN+WebDAVblock+CForms editing for braindead content management (but it works, and I have code ready to contribute) Is there any peculiar reason for using Subversion proprietary calls when autoversioning works out of the box with plain old WebDAV? Going to read the wiki page now, but definitely count me in, at least for support. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
fb:insert-bean class hierarchies
Pardon me if this has been discussed already... I did some quick search and was unable to find anything relevant. We are currently being severely bitten by a limitation in the Java reflection API that hits on fb:insert-bean. If class B extends A, and you have a method in your binding base such as void addA(A a) you cannot bind it using a B instance since Java will complain about not finding a void addA(B b) method. Now, apart from this being quite silly from the reflection POV, is there anything we're missing of is that a confirmed limitation? And, if, so, would anyone here be interested in a fix? I can see three solutions for that: 1. brute force approach: try to call the method with every possible superclass of the parameter giving an error; 2. lookup: get all the methods, grab the one that needs to be called, find out which is the correct superclass to use; 3. insert a cast semantic to the binding instruction and then cast (using a Proxy?) to the correct implementation the class is expecting. Of course the 4th solution still applies: 4. I'm a moron and I'm overlooking how this has been discussed at lenght and solved long ago. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com
Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)
On Fri, 07 Jan 2005 12:26:12 +0100, Torsten Curdt [EMAIL PROTECTED] wrote:
IMO this only leads to mixing of concepts.
What concepts? Remember that python and Java 1.5 have this capability,
because it's useful... are they both so wrong?
No ...it *is* useful!! ...a variable amount
of parameters!
Bah, I don't like varargs that much, it's just syntax sugar adding
opacity in exchange for a few keystrokes. The compiler is changing
varargs into arrays, and the receiving method needs to be written
against an array anyway, so why bother?
Some people will
use the {} some won't. To be honest I would not feel very happy
with UGLI since IMHO this interface is only half-backed. Sorry.
Half baked because it has the parameter stuff?
Either make it use the 1.5 stuff (and make
1.5 a requirement) or leave it out ...but
this mixture is what I call half baked.
Remember that log4j uses that interface. Is log4j also half-baked?
Not quite, but still this shaky interface adds up to the list of Log4J
poorly engineered stuff that makes me wish for an interface to isolate
myself from it (even though I do reckon that we have to suppport it
given how pervasive it has become). UGLI looks like the less worst
alternative, so I can digest it. But getting to like that... well,
that's entirely another issue.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
Re: [RT] Logging in 2.2
On Wed, 05 Jan 2005 12:45:27 +0100, Carsten Ziegeler [EMAIL PROTECTED] wrote: In the past we had several arguments about why logkit is better and so on but I think most of these arguments are not valid any more. Well, AFAIU a big one still stands true: security. I really hate the idea that other code can write to my channel just by doing a Logger.getLoggerFor(). But hey, that's life... all in all syslogd has been around for quite some time and works exactly that way, so let's move on. I tend to back the UGLI logging interface ATM... but I just love Torsten's just4log suggestion as well. Yeah, something I'm still missing is the good old -DDEBUG switch... -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com
