RE: FYI: New Sitemap Treeprocessor for 2.2
Hi,
it seems that when you have vacation that you even have less time than
when you go to work :(
I'm very sorry, but I can't continue the work on the tree processor
this week, there are more important things to do. Unfortunately,
the version I currently have is worse than what we have in 2.2
anyway (apart that it's not that tied to Fortress anymore and it
supports different sitemap versions, but it provides less functionality).
So, I will not commit it.
Sorry,
Carsten
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: Monday, March 22, 2004 12:10 PM
To: [EMAIL PROTECTED]
Subject: Re: FYI: New Sitemap Treeprocessor for 2.2
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Hi,
to avoid double efforts in the same area, I just wanted to
inform you that I will try to write a new tree processor for
2.2 in the next few days.
Why? There are several reasons:
- Reverting to ECM in 2.2 requires some changes to the
tree processor
used in 2.1.x anyway
Curious : are these changes those related to the changes on
Environment, or are there more?
Not only, we removed some of the deprecated component stuff in 2.2
(excalibur component selector etc.)
Ah yeah. But we still need ServiceSelector.
- Implementing Virtual Sitemap Components
- Implementing Inheritance of Views
I do have some ideas about this and am willing to
participate. Where do we start?
Here on my PC :)
Ah, so please commit your PC in the CVS :-)
snip/
With all features? That's quick!
:) - Ehm,...,hmmhok, perhaps not with all features, but
some of them :)
:-P
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
DO NOT REPLY [Bug 27709] - Problem with national chars submitted with form
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27709. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27709 Problem with national chars submitted with form --- Additional Comments From [EMAIL PROTECTED] 2004-03-23 10:54 --- I tried also Tomcat 4.1.27 (as suggested), tested with sample forms included with Cocoon - no positive results. I can comfirm that problem is about wrong escaping (like amp;#321).
[Help]Any change due to this database action error or just getConfiguration?
I use database action to save data into database ,the pipeline looks like:
map:match pattern=*-add
map:act type=mod-db-add
map:parameter name=descriptor value=cocoon:raw:/forms/{1}/define_data.xml /
map:parameter name=table-set value=default /
map:redirect-to uri=cocoon://gtt/message/form/save_ok.html /
/map:act
map:redirect-to uri=cocoon://gtt/message/form/save_fail.html /
/map:match
the cocoon:raw:/forms/{1}/define_data.xml looks like
map:match pattern=forms/*/define_data.xml
map:generate src=forms/{1}/form_define.xml /
map:transform type=formdefine
map:parameter name=type value=data /
/map:transform
map:serialize type=xml /
/map:match
the formdefine transformer is writter by myself to get the corret xml file from the
defien_data.xml(all config save in this file).
It works fine in 2.1.4,but in current cvs version ,it will produce an error:
Original Exception: org.apache.avalon.framework.configuration.ConfigurationException:
Error trying to load configurations for resource:
cocoon://gtt/apps/app1/forms/test/define_data.xml
at
org.apache.cocoon.acting.AbstractComplementaryConfigurableAction.getConfiguration(AbstractComplementaryConfigurableAction.java:102)
at org.apache.cocoon.acting.modular.DatabaseAction.act(DatabaseAction.java:614)
I try to find why this error occour,so:
1.I use an pipeline to get the xml file in the same way to
cocoon:raw:/forms/{1}/define_data.xml,and save it in define_data.xml
2.I change map:match pattern=forms/*/define_data.xml to
map:match pattern=forms/*/define_data.xml
map:generate src=forms/{1}/define_data.xml /
map:serialize type=xml /
/map:match
It works fine,so my transformer did generate the correct xml
3.In my Transformer(extends AbstractSAXTransformer),I insert some println
in startTransformingElement(String uri,String name,String raw,Attributes attributes)
System.out.println(name:+name);//for debug only
if (uri.equals()) {
if (name.equals(root))
this.namespaceURI = Constants.FORM_DEFINE_NS;
else
super.startTransformingElement(uri, name, raw, attributes);
}
...
I found when I use this transformer in other condition ,the console will print all the
name,so it is corrent.
But if I use it just like upper description,it only print name:root(form_define.xml
only has this none prefix name as xml root).
It works fine in 2.1.4,so I guess it is some change to cocoon: protal due to this
error.
WDYT?
Roy Huang
Include XML string into the pipline via transformer
Hello, I need to include xml coming from a database as string into the pipline via my own transformer. (Please do not ask why writing my own transformer. I need it..). I had seen, including xml coming form sources (xml files) is very easy using the SourceUtil. But how can I include xml which exists not as source but as string? Is there already a tool avaiable which makes it easy like the SourceUtil? Any examples? Thank you very much. Regards Stephan
Re: Include XML string into the pipline via transformer
in transform(Document doc) you can access the document in a DOM like fashion ie Element a = document.createElement(myelement); Element b = document.createElement(myelementchild); Element addedParameter = document.createElement(parameter); addedParameter.setAttribute(name, output); Element addedParameterValue = document.createElement(value); addedParameterValue.appendChild(document.createTextNode(some text here)); addedParameter.appendChild(addedParameterValue); b.appendChild(addedParameter); a.appendChild(reqparams); document.appendChild(req); I don't know if there is an easier way than this. HTH Jorg Stephan Coboos wrote: Hello, I need to include xml coming from a database as string into the pipline via my own transformer. (Please do not ask why writing my own transformer. I need it..). I had seen, including xml coming form sources (xml files) is very easy using the SourceUtil. But how can I include xml which exists not as source but as string? Is there already a tool avaiable which makes it easy like the SourceUtil? Any examples? Thank you very much. Regards Stephan
submit-widget validate=false
As ins subject: the button defined this way submits the form and ATTEMPTS validation. Can anybody confirm this in current CVS head? lg -- __ | / \ |Leszek Gawron// \\ \_\\ //_/ [EMAIL PROTECTED] _\\()//_ .'/()\'. Phone: +48(501)720812 / // \\ \ \\ // recursive: adj; see recursive | \__/ |
[RT] On building on stone
I want Cocoon to last long and to be able to stand the pressure of a big user community, a diverse development community and that of companies built on top of it. For this reason, we must identify in advance all moves that lead to making the cocoon project weaker. There are three things that provide foundation for a project: 1) its technology 2) its community 3) its license The three things are not so unrelated as some people think, but this is not the topic for today. Gump indicates that Cocoon has 205 dependencies on external projects. Gump has been able to do a clean cocoon run only *once* in its entire three-years-long existance. This is not good. It shows that we are building on sand. There are two ways to get out of this: 1) better modularity (to reduce dependencies) 2) more solid dependencies for our core (to increase solidity of our foundations) As for better modularity, we designed the Cocoon Blocks. We now have to finish #2. - 0 - I've been helping Pier write a block-like container for his employer and found out that no matter how hard we try, the Avalon interfaces cannot allow to implement Cocoon Blocks the way we designed them. In short: if we want to have hot-deployable, polymorphically dependent high-level cocoon web application components, we can't use Avalon4. - o - This leads to a rather difficult choice: 1) avoid implementing real blocks 2) change our foundation framework I would go for #2, since I consider real blocks vital for the evolution of this project. Now, if we go #2 there are three choices: 1) patch avalon 2) change framework 3) do our own Here my choice would not be technologically driven but rather socially driven: I would do our own. Why? because Avalon's communities are not healthy. The turnover rate is incredily high and the burn-out period is amazingly short. Its simply too fragile to build cocoon on something like this. From a community perspective, Avalon is sand. Avalon's biggest problem is that technology is more important than the community. Purity that leads to forks is more important than compromises that keep the community together. This is such a strong cultural clash which impact was for long underestimated. Not so anymore and since now we need to make a choice, my choice would be to design our own framework and container. - o - So, here is my detailed proposal: 1) implement our own framework and container in order to implement cocoon blocks [this creates the solid foundation that we control] 2) create an avalon emulation layer for the legacy components that would allow avalon components to run unmodified [this allows users to have a smooth migration path and no immediate impact on their development/mainteinance costs] 3) operate as incrementally as possible and work to change as little code as possible [this makes the community transition smoother, reduces enthropy and bugs introduced by the new code] 4) keep the framework and container *MINIMAL* to our own needs. [we WILL NOT redistribute the framework independently] 5) the name for our framework+container will be simply Cocoon Core 6) I volunteer to help directly in writing code - 0 - Now, before everybody and their dog replies to this and wishes to convince us to use their framework, the only measure of judgement would nto be technological but community and its culture. Cocoon needs a rock solid core. Solid in both technical, social and legal way. I believe that social and legal solidity build technical one. The opposite is not true. Cocoon and Avalon (both highly considered from a technical perspective) demonstrate this pretty well. I see no potential cocoon core out there that is not a one-man show and that allows us to do what we want to achieve with real blocks. Thus the proposal to write and maintain our own, in order to finally, once and for all, build on stone and escape the social quicksands in core depenendies. Fire at will: I have my abstesto underwear on. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [GUMP][PATCH] Add avalon-framework impl classes
Stefan Bodewig bodewig at apache.org writes: The build fails since Cocoon only states a dependency on the avalon-framework API but uses implementation classes as well[2]. The appended patch should fix that. Patch applied. Thanks. Please report back if it works. Joerg
Re: submit-widget validate=false
Leszek Gawron ouzo at wlkp.org writes: As ins subject: the button defined this way submits the form and ATTEMPTS validation. Can anybody confirm this in current CVS head? Yes, see bug 27785 [1] for more information. For submit widget with @validate=false the validation should happen, but not be evaluated as the form processing is ended. Does this match your observations? What do you hint at with your attempts in upper case? Joerg [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=27785
Re: [RT] On building on stone
Le 23 mars 04, à 14:25, Stefano Mazzocchi a écrit : snip-good-stuff cause=mucho agreement/ ...So, here is my detailed proposal: 1) implement our own framework and container in order to implement cocoon blocks [this creates the solid foundation that we control] 2) create an avalon emulation layer for the legacy components that would allow avalon components to run unmodified [this allows users to have a smooth migration path and no immediate impact on their development/mainteinance costs] Both sound very good assuming someone is able and willing to do the work. But I understand you and Pier would have (or already have had) energy to contribute. I think the in order to implement cocoon blocks bit is key: although Avalon is obviously shaky at the moment, the current ECM stuff used here is very stable and took a lot of work to polish. There must be a very good reason to replace it, and if it's Real Blocks combined with pouring concrete where needed, great! ... 4) keep the framework and container *MINIMAL* to our own needs. [we WILL NOT redistribute the framework independently].. Sure. But if the next Cocoon Core is sufficiently small (and *perceived* as such) and powerful, people might want to use it just as a container, even for simple things... ...Fire at will: I have my abstesto underwear on. No need for it as far as I'm concerned. Thanks for your realistic and respectful point of view. -Bertrand
Re: [RT] On building on stone
Stefano Mazzocchi wrote: I want Cocoon to last long and to be able to stand the pressure of a big user community, a diverse development community and that of companies built on top of it. ... This leads to a rather difficult choice: 1) avoid implementing real blocks 2) change our foundation framework I would go for #2, since I consider real blocks vital for the evolution of this project. Now, if we go #2 there are three choices: 1) patch avalon 2) change framework 3) do our own Here my choice would not be technologically driven but rather socially driven: I would do our own. Why? because Avalon's communities are not healthy. The turnover rate is incredily high and the burn-out period is amazingly short. Its simply too fragile to build cocoon on something like this. I'd add a parallel reason which may also be understood by people who may be less convinced about the health of that community or its importance (alas, I am no longer one). We cannot trust this core to a separate entity who have many other needs to consider in parallel. Why? We have specific needs, and need them quick. Also, we've found in practice that our container needs don't always have a lot of overlap with others' needs. We are far simpler in some ways, more complicated in others. If in some hypothetical future scenario others share a good deal of our needs, we can decide at that time if we should enable others to use our core by packaging separately - but I would be surprised if we ever would a) want this core managed elsewhere, or b) want to have to answer to users with different needs totally unrelated to Cocoon. Fire at will: I have my abstesto underwear on. Hopefully you will not need it. Your proposal needs to be tested by fire, but not you - let's get that out here early. Personally, knowing that there is already some code on disk makes this seem very attainable. If it means we have blocks sooner than later, I am 100% behind it. Geoff
Re: [RT] On building on stone
On 23 Mar 2004, at 14:25, Stefano Mazzocchi wrote: Thus the proposal to write and maintain our own, in order to finally, once and for all, build on stone and escape the social quicksands in core depenendies. Makes perfect sense to me. I guess we should look at our current investment in ECM knowledge code, look at Pier's alternative, and basically decide and JFDI. We gave Avalon a loyal customer to deal with in the past, but there never was a life-time engagement contract. We already missed various new container efforts over @ Avalon, and I'm confident we now know what we need and are able to build it ourselves in the (new) core of Cocoon. Given the flurry of new containers out there, I think people are demonstrating that container development is not rocket science - and since it's core to Cocoon's operations, it's sensible to deal with that ourselves. There will be aspects of backward-compatibility to deal with, which we can deal with by providing compatibility layers, or by just going for Cocoon 3.0. 2.1 is there, it's solid and used a lot, and if there's consensus that innovation should not be hindered by compatibility, we can simply vote and start 3.0. I would humbly suggest not to change the syntax of the sitemap into Lisp, though. ;-) Fire at will: I have my abstesto underwear on. I honestly see no reason why. Thanks for biting the bullet, and even more thanks to step up and agree to do part of the coding effort. I hope many will join you. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
RE: [RT] On building on stone
Stefano Mazzocchi wrote: SNIP/ So, here is my detailed proposal: 1) implement our own framework and container in order to implement cocoon blocks [this creates the solid foundation that we control] 2) create an avalon emulation layer for the legacy components that would allow avalon components to run unmodified [this allows users to have a smooth migration path and no immediate impact on their development/mainteinance costs] 3) operate as incrementally as possible and work to change as little code as possible [this makes the community transition smoother, reduces enthropy and bugs introduced by the new code] 4) keep the framework and container *MINIMAL* to our own needs. [we WILL NOT redistribute the framework independently] 5) the name for our framework+container will be simply Cocoon Core 6) I volunteer to help directly in writing code +100 for all points ,especially for point 2) The container is our core and it is much easier and also safer to maintain our own container than to rely on someone else. In the past years we always had to struggle each time the used container changed in an unforseeable way. With our own container, our core is independent. Great! Carsten
DO NOT REPLY [Bug 27871] New: - [XSP] logicsheet-util.xsl causes XSP Java class not to be compilable
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27871. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27871 [XSP] logicsheet-util.xsl causes XSP Java class not to be compilable Summary: [XSP] logicsheet-util.xsl causes XSP Java class not to be compilable Product: Cocoon 2 Version: Current CVS 2.1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: blocks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, actually, I am addressing two issues found in logicsheet-util.xsl (that is usualy used in xsp logicsheets): 1. Empty parameter 'default' is not tested correctly, because when used as xsl:call-template name=get-string-parameter xsl:with-param name=namefooparam/xsl:with-param xsl:with-param name=requiredfalse/xsl:with-param xsl:with-param name=defaultxsp-request:get-parameter name=foo//xsl:with-param /xsl:call-template then the test xsl:if string-length($default) = 0 obviously returns true but it should not. 2. template get-nested-string produces invalid string literals because it doesn't always translate LF to single space as it should when converting xsp:text/ to Java string. For example, mylgs:mytag name=command mylgs:param name=value xsp:exprrequest.getParameter(foo)/xsp:expr /mylgs:param /mylgs:mytag produces expression simmilar to: + + request.getParameter(foo) I am providing patch for these changes and they both changes should be backward compatible.
DO NOT REPLY [Bug 27871] - [XSP] logicsheet-util.xsl causes XSP Java class not to be compilable
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27871. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27871 [XSP] logicsheet-util.xsl causes XSP Java class not to be compilable --- Additional Comments From [EMAIL PROTECTED] 2004-03-23 15:30 --- Created an attachment (id=10923) patch for logicsheet-util.xsl (links to above comment)
RE: Transform runs twice
Vadim Gritsenko [EMAIL PROTECTED] comes through once more: Hunsberger, Peter wrote: I've got a straight forward pipeline where it appears that a transform runs twice: map:match pattern=*/systemInformation** map:generate type=CTService/ map:transform src=stylesheets/resolve_sysInfo.xsl/ map:transform src=stylesheets/sysInfo.xsl/ map:serialize/ /map:match If I look at the pipeline output after the generator I have the expected data. If I capture that data and feed it into the resolve...xsl (using Stylus or Xslerator) things work as expected. If I capture the output of the pipeline after the resolve...xsl I see two copies of the output XML The next transform then runs twice and I get the output XHTML twice (complete with two top level body tags, which IE happily accepts). I'm running Cocoon 2.1.4 with Saxon. Any ideas on how to track this down or what to look for? Saxon can do this when endDocument() is sent twice. Insert log transformer in between - check that generated SAX events are ok Many thanks, that was indeed it; sub-class and super class both did a start/endDocument()...
Re: [RT] On building on stone
Stefano Mazzocchi wrote:
I want Cocoon to last long and to be able to stand the pressure of a
big user community, a diverse development community and that of
companies built on top of it.
snip/
So, here is my detailed proposal:
1) implement our own framework and container in order to implement
cocoon blocks [this creates the solid foundation that we control]
2) create an avalon emulation layer for the legacy components that
would allow avalon components to run unmodified [this allows users to
have a smooth migration path and no immediate impact on their
development/mainteinance costs]
3) operate as incrementally as possible and work to change as little
code as possible [this makes the community transition smoother,
reduces enthropy and bugs introduced by the new code]
4) keep the framework and container *MINIMAL* to our own needs. [we
WILL NOT redistribute the framework independently]
5) the name for our framework+container will be simply Cocoon Core
6) I volunteer to help directly in writing code
Although this means that we enter a long road before having 2.2, I think
this is the way to go. The Cocoon house is big, and it must have solid
foundations that it controls in order to continue growing.
Now point 2 is important, as lots of people have invested in Cocoon and
would be very confused if we abruptly changed the way Cocoon works.
Fortunately, we stayed on ECM and avoided the migration to more complex
containers, which should ease the writing of this compatibility layer.
It's also the occasion to consider what we can learn from the good, the
bad and the ugly in existing containers while building our own,
specifically adapted to our needs. As Steven said, so many people write
their own containers nowadays that it's certainly not rocket science,
although it requires clever ideas, an area in which Pier and you have
proved your abilities ;-)
snip/
Fire at will: I have my abstesto underwear on.
Put it off: it doesn't help to get code written (see point 6)!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] On building on stone
Sylvain Wallez wrote: Stefano Mazzocchi wrote: Fire at will: I have my abstesto underwear on. Put it off: it doesn't help to get code written (see point 6)! Please, Stefano - *do not* under any circumstances (despite Sylvain's suggestion) take your underwear off while coding. :) Geoff
DO NOT REPLY [Bug 27875] New: - Profiling data not saved with internal pipelines
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27875. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27875 Profiling data not saved with internal pipelines Summary: Profiling data not saved with internal pipelines Product: Cocoon 2 Version: 2.1.4 Platform: PC OS/Version: All Status: NEW Severity: Minor Priority: Other Component: blocks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When processing an internal pipeline, the 'processXMLPipeline' or 'processReader' methods of the AbstractProcessingPipeline are invoked instead of the 'process' method. These methods are not oberwritten by the Profiling...Pipeline classes and therefore no profiling data will be saved. The fix is straightforward: Copy the 'process' method, rename it and replace the calls to super.process with super.processXMLPipeline resp. super.processReader. I've done it within my testing environment and it works fine.
DO NOT REPLY [Bug 25934] - [PATCH] LuceneIndexContentHandler.java produces CLOBs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=25934.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=25934
[PATCH] LuceneIndexContentHandler.java produces CLOBs
--- Additional Comments From [EMAIL PROTECTED] 2004-03-23 17:51 ---
Applies to both patches:
@@ -130,6 +129,8 @@
...
+text.append(' ');
This doen't look like it's necesarry: text contains only the concatenated
children text-nodes of the current node. It's only used when the current node is
closed, where the text is passed for indexing or storing.
+bodyText.append(' ');
I think this is the relevant line and it looks correct.
After thinking more and more about this problem, I'm no longer sure that adding
spaces is always the right solution to the problem. You already posted two
examples where adding spaces is wrong, while I posted an example where adding
spaces looks like a good idea. So either make adding spaced configurable or
document the facts and mention that the user has to do an extra transformation
step before indexing his XML data, when he heeds extra spaces.
DO NOT REPLY [Bug 27875] - Profiling data not saved with internal pipelines
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27875. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27875 Profiling data not saved with internal pipelines [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2004-03-23 17:58 --- If you have already done it, you can perhaps provide us a patch?!
DO NOT REPLY [Bug 27875] - Profiling data not saved with internal pipelines
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27875.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=27875
Profiling data not saved with internal pipelines
--- Additional Comments From [EMAIL PROTECTED] 2004-03-23 18:21 ---
Hello Stephan,
I've added the following methods to the ProfilingNonCachingProcessingPipeline
and the ProfilingCachingProcessingPipeline classes (Testing was only done using
the noncaching class):
snippet
/**
* Process the SAX event pipeline
*/
protected boolean processXMLPipeline(Environment environment)
throws ProcessingException {
this.index = 0;
if (this.data!=null) {
// Capture environment info
this.data.setEnvironmentInfo(new EnvironmentInfo(environment));
// Execute pipeline
long time = System.currentTimeMillis();
boolean result = super.processXMLPipeline(environment);
this.data.setTotalTime(System.currentTimeMillis()-time);
// Report
profiler.addResult(environment.getURI(), this.data);
return result;
} else {
getLogger().warn(Profiler Data havn't any components to measure);
return super.processXMLPipeline(environment);
}
}
/**
* Process the pipeline using a reader.
* @throws ProcessingException if
*/
protected boolean processReader(Environment environment)
throws ProcessingException {
this.index = 0;
if (this.data!=null) {
// Capture environment info
this.data.setEnvironmentInfo(new EnvironmentInfo(environment));
// Execute pipeline
long time = System.currentTimeMillis();
boolean result = super.processReader(environment);
this.data.setTotalTime(System.currentTimeMillis()-time);
// Report
profiler.addResult(environment.getURI(), this.data);
return result;
} else {
getLogger().warn(Profiler Data havn't any components to measure);
return super.processReader(environment);
}
}
/snippet
Re: [RT] On building on stone
Geoff Howard wrote:
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Fire at will: I have my abstesto underwear on.
Put it off: it doesn't help to get code written (see point 6)!
Please, Stefano - *do not* under any circumstances (despite Sylvain's
suggestion) take your underwear off while coding. :)
Hey Geoff, he doesn't have a webcam, so let him code the way he likes ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] On building on stone
-Mensagem original- De: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] Sure. But if the next Cocoon Core is sufficiently small (and *perceived* as such) and powerful, people might want to use it just as a container, even for simple things... As an ex-avaloner I second that. :-) The last attempt to get a consensus over avalon was to create a simple, lightweight container that would be the basis for the current one. Please refer to http://cvs.apache.org/viewcvs.cgi/avalon-sandbox/aspect ...By the end of last year I would suggest that these effort follow together with avalon team efforts, but now I encourage Cocoon to develop his own rock-solid container. sad but true. But don't loose your faith over Avalon. Things can change... Who knows what the tide will bring? -- hammett
DO NOT REPLY [Bug 27878] New: - XMLResourceBundleFactory is missing catalogs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27878. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27878 XMLResourceBundleFactory is missing catalogs Summary: XMLResourceBundleFactory is missing catalogs Product: Cocoon 2 Version: Current CVS 2.1 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] _select in XMLResourceBundleFactory loops through the directories and locales locating resource bundles. However, it stops when it encounters the first bundle name that doesn't have a locale, missing those that might be in one of the other locations. The provided patch fixes that.
DO NOT REPLY [Bug 27878] - XMLResourceBundleFactory is missing catalogs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27878. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27878 XMLResourceBundleFactory is missing catalogs --- Additional Comments From [EMAIL PROTECTED] 2004-03-23 19:05 --- Created an attachment (id=10930) Patch to correct this defect
Re: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
On 23.03.2004 20:23, [EMAIL PROTECTED] wrote:
stephan 2004/03/23 11:23:07
Modified:tools/src blocks-build.xsl
Log:
Allow to share codebase to other blocks.
pathelement location=${{build.blocks}}/{$block-name}/mocks/
+pathelement location=${{build.blocks}}/{$block-name}/dest/
+pathelement location=${{build.blocks}}/{$block-name}/samples/
xsl:for-each select=$cocoon-block-dependencies
path refid={substring-after(@project,'cocoon-block-')}.classpath/
/xsl:for-each
This was the reason for the common classpath, wasn't it? I wanted to
have a look on it after having reverted the common classpath, but I
guess that's no longer needed. Thanks for it. BTW, which block depends
on other block's samples?
Joerg
Re: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
Am Di, den 23.03.2004 schrieb Joerg Heinicke um 20:37:
On 23.03.2004 20:23, [EMAIL PROTECTED] wrote:
stephan 2004/03/23 11:23:07
Modified:tools/src blocks-build.xsl
Log:
Allow to share codebase to other blocks.
pathelement location=${{build.blocks}}/{$block-name}/mocks/
+pathelement location=${{build.blocks}}/{$block-name}/dest/
+pathelement location=${{build.blocks}}/{$block-name}/samples/
xsl:for-each select=$cocoon-block-dependencies
path refid={substring-after(@project,'cocoon-block-')}.classpath/
/xsl:for-each
This was the reason for the common classpath, wasn't it?
One reason ;-)
I wanted to
have a look on it after having reverted the common classpath, but I
guess that's no longer needed. Thanks for it. BTW, which block depends
on other block's samples?
I think at moment none, but will come next ;-)
Stephan.
DO NOT REPLY [Bug 27875] - Profiling data not saved with internal pipelines
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27875. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27875 Profiling data not saved with internal pipelines [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-03-23 19:51 --- Thanks, for the snippet, To be true, I not really sure how it works. It's a long time ago, since I know enough of the internals. So, please cross check. Stephan Michels.
[Cforms] Minor errors in JavaScriptJXPathBinding*.java
Hi guys, On studying the code in the JavaScriptJXPathBinding files I noticed that the comments (both error comments and javadoc) still use the old namespace convention (i.e. wb instead of fb). Just wanted to let you know. Bye, Helma
Visualisation tree
Has anyone a idea how to present the tree structure of a xml in cocoon. I have a DOM, out of the DOM I want to get all the element nodes (done by a helperclass, integrated in a xsp). Further I want to set a new position for a existing node and give the information to the DOM ... thx for your incitation, Dietmar
Re: Visualisation tree
On Tue, Mar 23, 2004 at 10:31:08PM +0100, [EMAIL PROTECTED] wrote: Has anyone a idea how to present the tree structure of a xml in cocoon. I have a DOM, out of the DOM I want to get all the element nodes (done by a helperclass, integrated in a xsp). Further I want to set a new position for a existing node and give the information to the DOM ... thx for your incitation, If you are slightly brave, take a look at the Woody/Cocoon Forms Form Model GUI sample: (Cocoon 2.1.4) http://127.0.0.1:/samples/woody/form_model_gui.flow or current CVS http://127.0.0.1:/samples/forms/form_model_gui.flow It takes an XML document, in this case it happens to be a cforms model file, and presents it as input fields/etc. Perhaps you could adapt the concepts to suit your needs. --Tim Larson
Internet Explorer, XHTML, and CForms
Tim Larson recently brought up the issue of the serialized representation of empty tags when using the XMLSerializer for serving XHTML [1]. This was sparked from a thread I had started on the users list about this issue. I've done some considerable hair pulling over the past day, and I think I finally nailed it down. The problem I ran into is this. I want to serve my pages as XHTML, so I've been using the XMLSerializer with XHTML doctypes similar to the way it is set up in the stock root sitemap. It is also well known that standards-compliant browsers like Mozilla will only render XHTML properly if sent with the application/xhtml+xml content type, where Internet Explorer will not accept this, and requires you to send it as text/html. This is easily solvable with some pipeline magic I posted about [2] -- I have another solution to this using a Tomcat Filter that I will post shorty. Next I was trying to use a textarea on cforms. No matter what I did, this would render incorrectly on Internet Explorer when the textarea is empty. Because I'm using the XMLSerializer, an empty textarea gets rendered as: textarea name=foo rows=10 cols=10 / And this is why: no combination of doctypes, content types, filename extensions, etc, will make this work... because Internet Explorer just does not understand XHTML! When Internet Explorer encounters an XHTML page, it still parses in tag soup mode and just discards XHTML-isms. Ian Hickson does a good job explaining this in his Sending XHTML as text/html Considered Harmful. [3] This strategy works pretty well, but fails miserably on the empty textarea element. So as things stand right now, if someone wants to use a textarea in their forms and serve them as XHTML, they will run into problems on Internet Explorer. I think this is a problem since it is *possible* to do this -- a textarea rendered with an explicit closing tag will render properly on Internet Explorer and will be valid XHTML. However, I do not believe this is currently possible with Cocoon. I believe the solution lies in extending the default XML stream writer that comes with Xalan (org.apache.xml.serializer.ToXMLStream). A new output setting could be added that provides a list of element names that should never be minimized when they are empty. This would allow the same XHTML pages that work on standards-compliant browsers to render properly in Internet Explorer. It isn't clear to me if a new XML stream writer can be added to Xalan without modifying the Xalan source, but the actual coding does not look very hard. What do you think? cheers, -steve [1] http://marc.theaimsgroup.com/?m=107999114518402 [2] http://marc.theaimsgroup.com/?m=108001750400120 [3] http://www.hixie.ch/advocacy/xhtml
Re: [RT] On building on stone
On 23 Mar 2004, at 13:45, Bertrand Delacretaz wrote: 2) create an avalon emulation layer for the legacy components that would allow avalon components to run unmodified [this allows users to have a smooth migration path and no immediate impact on their development/mainteinance costs] Both sound very good assuming someone is able and willing to do the work. But I understand you and Pier would have (or already have had) energy to contribute. I had quite a lot of time to spare on it as my employer (as the members of the PMC know) asked me to lay down the groundwork for our next back-end platform. And basically, I had to come up with a framework satisfying certain requirements. With the invaluable help of Stefano and his vision on blocks, I'm pretty close to a release of the code, and if this community at large wants to see more of the implementation and what I'm talking about, just speak up, and I'll get a formal authorization from my manager (until now, confirmation is only verbal). I am sorry for those who are not on the PMC (on the PMC I keep a more detailed status update, and occasionally post some code snapshots), but it's not _MY_ code. Yes, I wrote it, but it's my EMPLOYER's code, and legally I personally don't own it. - O - Back from the working bench, right now all I can say is that some of the contracts WILL HAVE to change in the root container, and Stefano's 100% right, we cannot use the contracts outlined by Avalon4. That said, I am sure that on an individual block level (forgetting about infra-block contracts) compatibility can be provided quite easily by re-wrapping some of the interfaces, providing some extensions, and doing some sh***y glue-work. Old blocks can (IMVHO) work just fine in the new container, New blocks will work a bazillion times better! :-P Pier
Re: [RT] On building on stone
I keep forgetting to add something... On 23 Mar 2004, at 13:45, Bertrand Delacretaz wrote: ... 4) keep the framework and container *MINIMAL* to our own needs. [we WILL NOT redistribute the framework independently].. Sure. But if the next Cocoon Core is sufficiently small (and *perceived* as such) and powerful, people might want to use it just as a container, even for simple things... My employer doesn't care really about what happens to the code, we're going to use it anyway as our foundation, whether it's donated to Cocoon and we maintain our own fork, whether you guys want it at all or not... All that VNU cares about is that we deliver a platform based on _OUR_ blocks (lots of which you will never see in a million years, because they're core of our business! :-) BTW, not to scare anyone, I work for a news company http://www.vnunet.com/ , not a software company. OUR blocks will be those blocks linking our websites to our backends (Oracle Databases, Navision Financials, QuarkDMS publishing environments, and yada yada yada). All they asked me for for is some form of recognition if the code ends up in Cocoon land (quick quick, go back and modify the @author fields in the classes to include VNU Publications), so that they can prepare a nice press release to please our investors, and they can have better discounts when asking for something to be developed by Orixo :-) (hi guys! :-P) My _personal_ requirement, is that I wouldn't want a clean-cut fork to happen, because at the end of the day, I'd have to abandon the Cocoon fork and get back to the VNU's fork (doh, they pay me). A directory on the CVS repository which I can check out and build without requiring too many dependancies on Cocoon's main publication core will be more than enough, I can build my own Ant build files. That would make my (working) life _so_ much easier... Pier
Re: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
Joerg Heinicke wrote:
On 23.03.2004 20:23, [EMAIL PROTECTED] wrote:
stephan 2004/03/23 11:23:07
Modified:tools/src blocks-build.xsl
Log:
Allow to share codebase to other blocks.
pathelement
location=${{build.blocks}}/{$block-name}/mocks/
+pathelement location=${{build.blocks}}/{$block-name}/dest/
+pathelement
location=${{build.blocks}}/{$block-name}/samples/
xsl:for-each select=$cocoon-block-dependencies
path
refid={substring-after(@project,'cocoon-block-')}.classpath/
/xsl:for-each
This was the reason for the common classpath, wasn't it? I wanted to
have a look on it after having reverted the common classpath, but I
guess that's no longer needed. Thanks for it. BTW, which block depends
on other block's samples?
Not sure if this is what you mean, but there are some interdependencies between
block samples involving (I think) database, hsql, eventcache, jms, and maybe
repository. No block depends outright on samples, but samples do depend on
other blocks where the dependency disappears without the samples. I would
prefer to see some conditional build steps to allow soft dependencies for
samples and even optional pieces of code. IOW, some bits are included if the
dependency is met, otherwise not.
Geoff
Re: Internet Explorer, XHTML, and CForms
Steve Krulewitz dijo: What do you think? joke Looks to me as a ugly hack. Why we need to hack to patch a buggie browser that not meet the specifications? I think this is a not a good idea? Another solution is tell your users the browser they use is buggie and ask them to download a better browser :-D /joke Seriously, first of all, thanks for digging in this problem and point out the problem. It will be very hard if not imposible adding a special hack for a bug in a current release of a browser. AFAIK a map:selector allow you to know what kind of browser sent the request and based on this info you can use a customized serializer to workaround the problem. Best Regards, Antonio Gallardo
Re: Internet Explorer, XHTML, and CForms
On 23 Mar 2004, at 23:26, Steve Krulewitz wrote: Tim Larson recently brought up the issue of the serialized representation of empty tags when using the XMLSerializer for serving XHTML [1]. This was sparked from a thread I had started on the users list about this issue. I've done some considerable hair pulling over the past day, and I think I finally nailed it down. I thought I fixed it into the XHTML serializers I put in the scratchpad with the old Garbage implmentation, but looking at the code right now, err, no I didn't... I hear you, the serializers for plain XHTML are quite nasty... I noticed some odd behavior also on the script and style tags (not all browsers like when they look like tag /). Well, anyhow, I fixed it now, if you want to try it out, check if this serializer works for you: http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/scratchpad/ garbage/source/java/org/apache/garbage/serializer/XHTMLSerializer.java? rev=1.3view=auto It's in the scratchpad. Pier
Re: [Cforms] Minor errors in JavaScriptJXPathBinding*.java
On 23.03.2004 21:20, [EMAIL PROTECTED] wrote: Hi guys, On studying the code in the JavaScriptJXPathBinding files I noticed that the comments (both error comments and javadoc) still use the old namespace convention (i.e. wb instead of fb). Just wanted to let you know. Fixed, thanks for reporting. Joerg
Re: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
On 24.03.2004 01:53, Geoff Howard wrote: This was the reason for the common classpath, wasn't it? I wanted to have a look on it after having reverted the common classpath, but I guess that's no longer needed. Thanks for it. BTW, which block depends on other block's samples? Not sure if this is what you mean, but there are some interdependencies between block samples involving (I think) database, hsql, eventcache, jms, and maybe repository. No block depends outright on samples, but samples do depend on other blocks where the dependency disappears without the samples. I hope no block's core code is depending on another block's samples code and we will not introduce such a dependency as this would break compiling if one excludes the samples from the build. What I meant was one block's samples dependent on another block's samples (all about compiling Java files). I would prefer to see some conditional build steps to allow soft dependencies for samples and even optional pieces of code. IOW, some bits are included if the dependency is met, otherwise not. Indeed. At the moment in gump.xml both sample and compiling dependencies are mixed and sometimes not specified at all (e.g. OJB samples depend on CForms). AFAIK there is no strict handling of gump.xml and Gump does not stumble about additional attributes, so we might add an @type to the dependency element. This can be used for better dependency information in blocks.properties and maybe also for blocks-build.xsl Joerg
The XML declaration may only appear at the very beginning of the document
Title: Message I am trying to publish xml to pdf. theprocess is established and works most of the time. Would someone know why I sometimes get the cocoonerror "The XML declaration may only appear at the very beginning of the document." on perfecly valid XML? Description:org.apache.cocoon.ProcessingException: Could not read resource file:/D:/Publisher/jakarta-tomcat-4.0.1/webapps/cocoon/test/test.xml: org.xml.sax.SAXParseException: The XML declaration may only appear at the very beginning of the document. The XML declarationis indeed at the topand a sample fragment is below: ?xml version="1.0" encoding="utf-8"?!DOCTYPEbook PUBLIC "company x//DTD company x Technical Publication//EN" "c:\documentum\xml applications\companyx.dtd"[!ENTITY fr PUBLIC "-//company x//Contact fr//EN" "fr.xml"!ENTITY uk PUBLIC "-//company x//Contact uk//EN" "uk.xml"]!--ArborText, Inc., 1988-2001, v.4002-- I hope this is a common enough error with a resolution? Thecocoonserver is Windowsto which I am supplying zipped xml/jpgs remotelyvia the browser. I don't have much information beyond that. Thanks very much, Lyteck
Re: [RT] On building on stone
Pier Fumagalli wrote: snip/ All they asked me for for is some form of recognition if the code ends up in Cocoon land (quick quick, go back and modify the @author fields in the classes to include VNU Publications), so that they can prepare a nice press release to please our investors, and they can have better discounts when asking for something to be developed by Orixo :-) (hi guys! :-P) Just like anybody else that contributes, the status.xml file (i.e. Changes) and the CREDITS.txt provide plenty of exposure. Documentation and examples of use could provide even more. My _personal_ requirement, is that I wouldn't want a clean-cut fork to happen, because at the end of the day, I'd have to abandon the Cocoon fork and get back to the VNU's fork (doh, they pay me). A directory on the CVS repository which I can check out and build without requiring too many dependancies on Cocoon's main publication core will be more than enough, I can build my own Ant build files. That would make my (working) life _so_ much easier... You could just add it to cocoon-2.2 and do whatever you want. --David
The SCO stolen code on Linux
Hi: Here is the link to the stolen code: :-D http://www.linuxstolescocode.com/ Best Regards, Antonio Gallardo
Re: The XML declaration may only appear at the very beginning of the document
On 23.03.2004 23:48, Lyteck Lynhiavu wrote: I am trying to publish xml to pdf. the process is established and works most of the time. Would someone know why I sometimes get the cocoon error The XML declaration may only appear at the very beginning of the document. on perfecly valid XML? Unfortunately that's very unspecific, so I also can you only tell unspecificly that for what ever reason sometimes you have some trash in front of the XML declaration. I guess you first have to make it reproducable and after this do some debugging what exactly comes in. I hope this is a common enough error with a resolution? No, I heard the first time of it. Of course the error message itself is known, but that is normally caused by the developer. I don't know of an error that occurs only sporadically. The cocoon server is Windows to which I am supplying zipped xml/jpgs remotely via the browser. I don't have much information beyond that. You upload the files and process them in the pipeline? How does the sitemap look like? Joerg
Last cocoon-2.1.5-dev does not build
The build fail on 'compile-core'. It needs various velocity packages which are located in './src/blocks/velocity/lib/velocity-1.4-rc1.jar' but are not in the classpath. Approx. check-out time: Wed Mar 24 02:34:52 UTC 2004 Oscar __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html
Re: Internet Explorer, XHTML, and CForms
Pier Fumagalli wrote: I hear you, the serializers for plain XHTML are quite nasty... I noticed some odd behavior also on the script and style tags (not all browsers like when they look like tag /). Well, anyhow, I fixed it now, if you want to try it out, check if this serializer works for you: http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/scratchpad/ garbage/source/java/org/apache/garbage/serializer/XHTMLSerializer.java? rev=1.3view=auto It's in the scratchpad. *THANK YOU* This will help out immensely. I have it checked out and will try it out tomorrow. cheers, -steve
Re: Last cocoon-2.1.5-dev does not build
On 24.03.2004 03:35, Oscar Picasso wrote: The build fail on 'compile-core'. It needs various velocity packages which are located in './src/blocks/velocity/lib/velocity-1.4-rc1.jar' but are not in the classpath. Approx. check-out time: Wed Mar 24 02:34:52 UTC 2004 I can not confirm it. I can build Cocoon though having the velocity block excluded. Can you provide more details? Joerg
Re: Include XML string into the pipline via transformer
Stephan Coboos wrote:
Hello,
I need to include xml coming from a database as string into the
pipline via my own transformer. (Please do not ask why writing my own
transformer. I need it..). I had seen, including xml coming form
sources (xml files) is very easy using the SourceUtil. But how can I
include xml which exists not as source but as string? Is there already
a tool avaiable which makes it easy like the SourceUtil?
Any examples?
XSPUtil.java:
public static void includeString(String string, ComponentManager
manager, ContentHandler contentHandler)
throws RuntimeException {
XSPUtil.includeInputSource(new InputSource(new
StringReader(String.valueOf(string))), manager,
contentHandler);
}
Vadim
Re: current CVS: XSP broken
On 20.03.2004 21:42, leo leonid wrote: Exactly, nobody, neither I did, that was not my concern. Please take a moment and try to see it from my perspective. I did not expect that you or anybody specific answers on this temporary problem, but *that* anybody answers. I use the CVS version for developing, and I'm aware of the implications, that things can change or even break by the ongoing development process. May be it is just a coincidence, or it may be due to the fact that you are one of the most active committers - anyhow - your last commits put my projects in a fine mess. Sorry for that. Well, this happens, it's not the point, absolutely no problem, in general. Whereas I do have some objections, but these only concern the avoidable parts of the mess. That's when you _see_ your patch isn't mature at all and it breaks core parts of cocoon, This was the reason that I sent a mail to the list. I assume that people living from CVS also read the developers list. Therefore I would not update my Cocoon if I knew that something is broken. Of course we avoid non-working as far as possible, but there also must be some time to discuss about things. If something is broken this highers the need for discussion while maybe somebody would not answer if it's not broken (lazy ass syndrom, let it as it is). or spoils users project directories (as with bug 27600) Huh? Sorry, but here I feel innocently accused. *I* added the behaviour that the source directory is not touched at all until you choose otherwise after the complete update worked. Furthermore this helper target was only a few days old, it's not something that breaks anything (i.e. is needed at run time) and was easily changeable by the developer using the target by putting the xslt part into comments. Here the need to revert was very much lower than for the above XSP problem IMO. and you still don't consider to revert it. Why? Are you still not satisfied with the current solution making the xslt part optional? (You wrote the above two days after I added this.) Anyway, glad to hear you fixed it. Thanks. No problem. Joerg
Re: Last cocoon-2.1.5-dev does not build
Follow-up. I think I have a problem in my src/java and the CVS seems correct. __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html
Re: Last cocoon-2.1.5-dev does not build
Follow-up I think I have a problem in my src/java and that CVS is correct. Oscar __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html
RE: [RT] On building on stone
David Crossley wrote: Pier Fumagalli wrote: snip/ With the invaluable help of Stefano and his vision on blocks, I'm pretty close to a release of the code, and if this community at large wants to see more of the implementation and what I'm talking about, just speak up, and I'll get a formal authorization from my manager (until now, confirmation is only verbal). Okay, here is one person speaking up. How many do you need? Yes, let's give it a try! So, Pier, please speak to your manager :) Carsten
Re: [RT] On building on stone
Le 24 mars 04, à 08:27, Carsten Ziegeler a écrit : David Crossley wrote: Pier Fumagalli wrote: ...if this community at large wants to see more of the implementation and what I'm talking about, just speak up, and I'll get a formal authorization from my manager (until now, confirmation is only verbal). Okay, here is one person speaking up. How many do you need? Yes, let's give it a try! So, Pier, please speak to your manager :) +1 from out here. That's three, and counting... -Bertrand
Using Saxon 7.9 with Cocoon?
I've been trying to switch our Cocoon (2.1.4) application from using the latest Xalan over to using Saxon 7.9 to try and improve XSLT performance. The problem I am running into is that I keep getting a Saxon exception being thrown saying that the Saxon DOM implementation cannot be updated (it's read- only). Has anyone managed to get around this and get Cocoon 2.1.4 working using Saxon 7.9 as the default XSLT processor? If so, how did you do this? Did you replace the Saxon DOM implementation (and if so, how)? Thanks! Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com
