[jira] Closed: (COCOON-1379) [i18n] extending the I18nTransformer
[ http://issues.apache.org/jira/browse/COCOON-1379?page=all ] Jean-Baptiste Quenot closed COCOON-1379. Fix Version/s: 2.2-dev (Current SVN) Resolution: Fixed Assignee: (was: Cocoon Developers Team) I think we can close this one now. [i18n] extending the I18nTransformer Key: COCOON-1379 URL: http://issues.apache.org/jira/browse/COCOON-1379 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Christoph Gaffga Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: AbstractI18nTransformer.java, I18nTransformer.java copy of my mail to dev@cocoon.apache.org: - (see source attached) recently I needed to extend cocoon's I18nTransfomer for loading multiple sets of catalogues for different pipelines. The information what catalogues form a set, which sets to use for the different pipelines was stored in DB. So I had to change a lot and recognized that it is quite difficult for me to extend the existing I18N transformer. The Idea was, whenever cocoon's I18N transformer is enhanced with some more functionallity, my new transfomer should support the features too. With the existing I18nTransformer class this seems not to be possible. So my Idea was to move all the stuff doing the real transformations, implementing the logic for the i18n:*-Elements and doing lookups in the catalugues to an abstract class called AbstractI18nTransformer. Now the cocoon I18nTransformer extends this class and implements only the logic for loading the right catalogues as configured in the sitemap, mainly the setup(..) and configure(..) methods and the Cachable interface are implemented here. Like this I have a nice separation between the real transforming part and the part loading and configuring the catalogues. Now I can simply extend this AbstractI18nTransformer and add my own catalogue loading logic. Coming back to my point that I want to have enhancments to the I18n functions also in my transfomer without editing my code again and again: My separation of the two parts of the I18n transfomer only makes sense if there is some interest in having this AbstractI18nTransformer integrated into cocoon. So I'd like to know if there is some interest in having this change integrated into cocoon. I sent my example how this separation could be done as an enhancement to the bugzilla. Would be nice to hear some thoughts about the idea. kind regards, Christoph Gaffga [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer
[
http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441369
]
Cyriaque Dupoirieux commented on COCOON-1928:
-
Here is my problem,
I want to use two variables to be able to define the doctype-public and the
doctype-system.
At the moment if I try this :
map:serializer logger=sitemap.serializer.xhtml mime-type=text/html
name=xhtml pool-grow=2 pool-max=64 pool-min=2
src=org.apache.cocoon.serialization.XMLSerializer
doctype-public${doctype-public}/doctype-public
doctype-system${doctype-system}/doctype-system
encodingUTF-8/encoding
indentyes/indent
omit-xml-declarationno/omit-xml-declaration
/map:serializer
I get this :
!DOCTYPE html PUBLIC ${doctype-public} ${doctype-system}
And I have seen example where variable are used in a tag attribute value :
map:parameter name=dispatcher.caching
value={forrest:dispatcher.caching} /
So I think my problem should be solve if I could write the example exposed in
my first comment...
Add the ability to pass the doctype in parameter for Serializer
---
Key: COCOON-1928
URL: http://issues.apache.org/jira/browse/COCOON-1928
Project: Cocoon
Issue Type: New Feature
Components: * Cocoon Core
Affects Versions: 2.2-dev (Current SVN)
Reporter: Cyriaque Dupoirieux
Priority: Minor
Attachments: AbstractTextSerializer.diff
I need - with forrest - to get the doctype-system and doctype-public in a
parameter like following :
map:serializer logger=sitemap.serializer.xhtml mime-type=text/html
name=xhtml pool-grow=2 pool-max=64 pool-min=2
src=org.apache.cocoon.serialization.XMLSerializer
parameter name=doctype-public value=-//W3C//DTD XHTML 1.0
Transitional//EN /
parameter name=doctype-system
value=http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; /
encodingUTF-8/encoding
indentyes/indent
omit-xml-declarationno/omit-xml-declaration
/map:serializer
here is a patch which apply to the AbstractTextSerializer.
in case the doctype is also found in the childs, child have priority.
Regards,
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Closing JIRA issues
* Antonio Gallardo: Jean-Baptiste Quenot closed COCOON-1774. Resolution: Won't Fix Please reopen the issue if the problem persists with the new Dojo stuff. Thanks! I don't think it is the best way to close bugs. IMHO, the first part of a problem resolution is the problem identification and an open issue without a patch provides this first part. I would left open this bug (and onther of the current closed) until somebody comes with a solution. I don't know if you talked about this in GT2006, but if jira now becomes only a patch repository, I will like to know. At least we should vote for this policy change. Please don't take it personally. ;-) Hello Antonio, Sorry for the late reply, I missed your comment. Here is an explanation, I'm closing issues when: * it has been sitting in JIRA for a very long time * it is in « Feedback Required » state and reporter did not reply for a long time * no patch was provided * none of the Cocoon developers contributed to fix this issue or one of the developers says issue is already fixed I think there is no good reason to keep the issue open forever if no one intends to work on it, especially as the JIRA is full of these. BTW I discussed this with Vadim at the Hackathon. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
[jira] Closed: (COCOON-1416) JXTemplate Bug List(For Refactoring info)
[ http://issues.apache.org/jira/browse/COCOON-1416?page=all ]
Jean-Baptiste Quenot closed COCOON-1416.
Resolution: Won't Fix
Assignee: (was: Cocoon Developers Team)
Please reopen if this is still an issue, thanks.
JXTemplate Bug List(For Refactoring info)
-
Key: COCOON-1416
URL: http://issues.apache.org/jira/browse/COCOON-1416
Project: Cocoon
Issue Type: Bug
Components: Blocks: Templating
Affects Versions: 2.2-dev (Current SVN)
Environment: Operating System: Linux
Platform: Other
Reporter: Tibor Katelbach
The jx:set var=myvarany string/jx:set
${myvar} will be empty when used.
hack is to pass by jx:macros
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Named links in generated site docs (Re: updating the Cocoon website)
David Crossley wrote: See the new section at http://wiki.apache.org/cocoon/CocoonWebsiteUpdate to explain the quick way to update the Cocoon 2.1 docs. Any committer can do it. I followed this today (it has been 2 months since last update). However i don't have time to find out what is going wrong. Would someone else please follow up. -- Some links in the lef-hand navigation menus are being changed, and named documents are becoming numbers, e.g. -a href=http://cocoon.apache.org/community/contrib.html;Contributing/a +a href=../2.1/1177.htmlContributing/a Has a navigation file changed in Cocoon's Daisy. Daisy does not store documents by name, it stores them by number. It is possible, via the navigation documents, to map a name to the number. Forrest does its best to work to what the intended name is when creating links, in the same way that Daisy does. The above problem is probably caused by (I have not verified this) the document in Daisy not being assigned a name in the navigation document. If it's not this then we have uncovered a bug in the Forrest XSL that generates the links. I've no time to investigate at present, but if someone can check the status of the Daisy navigation docs then it will at least tell us if we need to dig into the Forrest XSL. New documents are being added without names and not linked in to the navigation menus. Are these missing entries in a Daisy navigation file? Not necessarily. It is possible to have documents that are not in a navigation menu but are linked from another page. However, as I understand it, if they do not have a mapping from node number to name in the Daisy navigation docs then they cannot appear with a name in the final output. This is not a problem for new documents (no existing external links, therefore no broken links). However, if an old document is removed from a navigation page then the URL will change and any external links will break (which may be what is happening above). Ross
[jira] Created: (COCOON-1931) Provide more information when compiling a Flowscript fails
Provide more information when compiling a Flowscript fails -- Key: COCOON-1931 URL: http://issues.apache.org/jira/browse/COCOON-1931 Project: Cocoon Issue Type: Improvement Components: - Flowscript Affects Versions: 2.1.8, 2.1.9, 2.2-dev (Current SVN), 2.1.10-dev (current SVN) Reporter: Georg Hüttenegger Priority: Minor When a flowscript defined in the sitemap cannot be loaded a NullPointerException is thrown without telling the developer the real cause of the issue. The same is true for certain Javascript coding errors (at least missing closing bracket of a for loop). The provided patch throws a CascadingRuntimeException with the name of the flowscript instead of just a simple NullPointerException. In that way the developer is lead directly to the cause of the problem instead of wondering what the real issue might be. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1931) Provide more information when compiling a Flowscript fails
[ http://issues.apache.org/jira/browse/COCOON-1931?page=all ] Georg Hüttenegger updated COCOON-1931: -- Attachment: FOM_JavaScriptInterpreter.java.MoreErrorInfoPatch Provide more information when compiling a Flowscript fails -- Key: COCOON-1931 URL: http://issues.apache.org/jira/browse/COCOON-1931 Project: Cocoon Issue Type: Improvement Components: - Flowscript Affects Versions: 2.1.8, 2.1.9, 2.2-dev (Current SVN), 2.1.10-dev (current SVN) Reporter: Georg Hüttenegger Priority: Minor Attachments: FOM_JavaScriptInterpreter.java.MoreErrorInfoPatch When a flowscript defined in the sitemap cannot be loaded a NullPointerException is thrown without telling the developer the real cause of the issue. The same is true for certain Javascript coding errors (at least missing closing bracket of a for loop). The provided patch throws a CascadingRuntimeException with the name of the flowscript instead of just a simple NullPointerException. In that way the developer is lead directly to the cause of the problem instead of wondering what the real issue might be. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer
[ http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441410 ] Jörg Heinicke commented on COCOON-1928: --- Sorry, but this really looks like FS (Flexibility Syndrome aka featuritis). Why do you need this dynamic? Where do those values come from? Aren't there other include mechanisms possible like XML entities? Jörg Add the ability to pass the doctype in parameter for Serializer --- Key: COCOON-1928 URL: http://issues.apache.org/jira/browse/COCOON-1928 Project: Cocoon Issue Type: New Feature Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Cyriaque Dupoirieux Priority: Minor Attachments: AbstractTextSerializer.diff I need - with forrest - to get the doctype-system and doctype-public in a parameter like following : map:serializer logger=sitemap.serializer.xhtml mime-type=text/html name=xhtml pool-grow=2 pool-max=64 pool-min=2 src=org.apache.cocoon.serialization.XMLSerializer parameter name=doctype-public value=-//W3C//DTD XHTML 1.0 Transitional//EN / parameter name=doctype-system value=http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; / encodingUTF-8/encoding indentyes/indent omit-xml-declarationno/omit-xml-declaration /map:serializer here is a patch which apply to the AbstractTextSerializer. in case the doctype is also found in the childs, child have priority. Regards, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1416) JXTemplate Bug List(For Refactoring info)
[ http://issues.apache.org/jira/browse/COCOON-1416?page=all ]
Jörg Heinicke closed COCOON-1416.
-
Resolution: Cannot Reproduce
JXTemplate Bug List(For Refactoring info)
-
Key: COCOON-1416
URL: http://issues.apache.org/jira/browse/COCOON-1416
Project: Cocoon
Issue Type: Bug
Components: Blocks: Templating
Affects Versions: 2.2-dev (Current SVN)
Environment: Operating System: Linux
Platform: Other
Reporter: Tibor Katelbach
The jx:set var=myvarany string/jx:set
${myvar} will be empty when used.
hack is to pass by jx:macros
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: The Binding Samples doesn't work
Jean-Baptiste Quenot wrote: * Vadim Gritsenko: Antonio Gallardo wrote: I can confirm this error on the cocoon zones. It was not before, I suspect some changes done in the hackathon intriduced this bug, but I did not check this yet. EnhancedRepeaterJXPathBinding was the culprit. Hi Vadim, Just curious: if you wrote an « enhanced » binding, what prevents you from replacing the old one? I did not wrote it [1]; I'm not even sure what it's for. Vadim [1] http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/binding/EnhancedRepeaterJXPathBinding.java?view=log
[jira] Commented: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer
[ http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441446 ] Cyriaque Dupoirieux commented on COCOON-1928: - Because the core of forrest - an internal plugin exactly... - defines the serializer with : doctype-public -//W3C//DTD XHTML 1.0 Strict//EN /doctype-public doctype-system http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd /doctype-system It may be complex for webmasters using Forrest to be XHTM Strict compliant - I don't know if you have tried... And it is not possible at the moment to configure it through a forrest configuration file. That's all. I am not sure it is featuritis - I didn't know the word, but I like it - since I need it and have no other solution than to have a local change a file of the core of Forrest to do what I want... - The next step can be to have a local change a class of the core of Cocoon ? What do you mean by include XML entities ? It may be the solution ? Add the ability to pass the doctype in parameter for Serializer --- Key: COCOON-1928 URL: http://issues.apache.org/jira/browse/COCOON-1928 Project: Cocoon Issue Type: New Feature Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Cyriaque Dupoirieux Priority: Minor Attachments: AbstractTextSerializer.diff I need - with forrest - to get the doctype-system and doctype-public in a parameter like following : map:serializer logger=sitemap.serializer.xhtml mime-type=text/html name=xhtml pool-grow=2 pool-max=64 pool-min=2 src=org.apache.cocoon.serialization.XMLSerializer parameter name=doctype-public value=-//W3C//DTD XHTML 1.0 Transitional//EN / parameter name=doctype-system value=http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; / encodingUTF-8/encoding indentyes/indent omit-xml-declarationno/omit-xml-declaration /map:serializer here is a patch which apply to the AbstractTextSerializer. in case the doctype is also found in the childs, child have priority. Regards, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer
[
http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441449
]
Vadim Gritsenko commented on COCOON-1928:
-
To Joerg:
Doctype is configurable right now, see Cocoon samples:
map:serializer logger=sitemap.serializer.html mime-type=text/html
name=html pool-max=${html-serializer.pool-max}
src=org.apache.cocoon.serialization.HTMLSerializer
doctype-public-//W3C//DTD HTML 4.01 Transitional//EN/doctype-public
doctype-systemhttp://www.w3.org/TR/html4/loose.dtd/doctype-system
/map:serializer
What Cyriaque is suggesting is syntax change, which I am against since it does
not give anything, and introduces inconsistent syntax.
To Cyriaque:
You are mistaken, syntax change will not help you. Variable substitution in
component configuration has to happen manually. Sitemap variable susbstitution
in parameter values is happening only within map:pipeline section, not within
map:components section.
Another mistake is to confuse properties substitution in cocoon 2.2 (using ${}
syntax) with sitemap variable substitution (using {} syntax).
Vadim
Add the ability to pass the doctype in parameter for Serializer
---
Key: COCOON-1928
URL: http://issues.apache.org/jira/browse/COCOON-1928
Project: Cocoon
Issue Type: New Feature
Components: * Cocoon Core
Affects Versions: 2.2-dev (Current SVN)
Reporter: Cyriaque Dupoirieux
Priority: Minor
Attachments: AbstractTextSerializer.diff
I need - with forrest - to get the doctype-system and doctype-public in a
parameter like following :
map:serializer logger=sitemap.serializer.xhtml mime-type=text/html
name=xhtml pool-grow=2 pool-max=64 pool-min=2
src=org.apache.cocoon.serialization.XMLSerializer
parameter name=doctype-public value=-//W3C//DTD XHTML 1.0
Transitional//EN /
parameter name=doctype-system
value=http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; /
encodingUTF-8/encoding
indentyes/indent
omit-xml-declarationno/omit-xml-declaration
/map:serializer
here is a patch which apply to the AbstractTextSerializer.
in case the doctype is also found in the childs, child have priority.
Regards,
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer
[
http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441464
]
Jörg Heinicke commented on COCOON-1928:
---
Doctype is configurable right now, see Cocoon samples
Of course it is. But I wondered why he wants to make even the configuration
configurable with the parameter substitution. That's why I called it FS.
Because the core of forrest - an internal plugin exactly... - defines the
serializer with ...
I don't know how Forrest works internally, but does Forrest provide other
extension mechanisms? Have you asked on the Forrest list for possibilities?
Another mistake is to confuse properties substitution in cocoon 2.2 (using
${} syntax) with sitemap variable substitution (using {} syntax).
That probably results from Forrest already being based on Cocoon 2.2?
What do you mean by include XML entities?
!DOCTYPE root [
!ENTITY dtPublic SYSTEM file://doctype-public.xml
!ENTITY dtSystem SYSTEM file://doctype-system.xml
]
map:serializer logger=sitemap.serializer.xhtml mime-type=text/html
name=xhtml pool-grow=2 pool-max=64 pool-min=2
src=org.apache.cocoon.serialization.XMLSerializer
dtPublic;
dtSystem;
encodingUTF-8/encoding
indentyes/indent
omit-xml-declarationno/omit-xml-declaration
/map:serializer
with doctype-public.xml:
doctype-public -//W3C//DTD XHTML 1.0 Strict//EN /doctype-public
and doctype-system.xml:
doctype-system http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
/doctype-system
And so both files could be used as configuration.
Jörg
Add the ability to pass the doctype in parameter for Serializer
---
Key: COCOON-1928
URL: http://issues.apache.org/jira/browse/COCOON-1928
Project: Cocoon
Issue Type: New Feature
Components: * Cocoon Core
Affects Versions: 2.2-dev (Current SVN)
Reporter: Cyriaque Dupoirieux
Priority: Minor
Attachments: AbstractTextSerializer.diff
I need - with forrest - to get the doctype-system and doctype-public in a
parameter like following :
map:serializer logger=sitemap.serializer.xhtml mime-type=text/html
name=xhtml pool-grow=2 pool-max=64 pool-min=2
src=org.apache.cocoon.serialization.XMLSerializer
parameter name=doctype-public value=-//W3C//DTD XHTML 1.0
Transitional//EN /
parameter name=doctype-system
value=http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; /
encodingUTF-8/encoding
indentyes/indent
omit-xml-declarationno/omit-xml-declaration
/map:serializer
here is a patch which apply to the AbstractTextSerializer.
in case the doctype is also found in the childs, child have priority.
Regards,
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer
[ http://issues.apache.org/jira/browse/COCOON-1928?page=all ] Jörg Heinicke updated COCOON-1928: -- Add the ability to pass the doctype in parameter for Serializer --- Key: COCOON-1928 URL: http://issues.apache.org/jira/browse/COCOON-1928 Project: Cocoon Issue Type: New Feature Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Cyriaque Dupoirieux Priority: Minor Attachments: AbstractTextSerializer.diff I need - with forrest - to get the doctype-system and doctype-public in a parameter like following : map:serializer logger=sitemap.serializer.xhtml mime-type=text/html name=xhtml pool-grow=2 pool-max=64 pool-min=2 src=org.apache.cocoon.serialization.XMLSerializer parameter name=doctype-public value=-//W3C//DTD XHTML 1.0 Transitional//EN / parameter name=doctype-system value=http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; / encodingUTF-8/encoding indentyes/indent omit-xml-declarationno/omit-xml-declaration /map:serializer here is a patch which apply to the AbstractTextSerializer. in case the doctype is also found in the childs, child have priority. Regards, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Closing JIRA issues
Hi Ard, IMHO, we should leave open this bug, because the fixi is not finished yet until we update excalibur. Best Regards, Antonio Gallardo. Ard Schrijvers escribió: A different question, but related to closing issues practices: What is common practice for bugs that are reported in cocoon's jira, but are actually for example an excalibur bug? For example, I just fixed the bug regarding imported stylesheets not invalidating the parent-parent stylesheet despite when check-includes is set to true (http://issues.apache.org/jira/browse/COCOON-1909). But, it was in excalibur-xmlutil. So, the cocoon issue will be solved when a new excalibur release has been done, and the jars used by cocoon have been updated. What do I do with COCOON-1909 in the meantime? Is there some wiki page around with rules or guidelines according these kind of bugs (probably, but I just don't know where to look)? Thx for any explanation on the subject, Regards Ard On 10/11/06, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: ...I think there is no good reason to keep the issue open forever if no one intends to work on it, especially as the JIRA is full of these... Agreed - if an issue sits in the feedback required for a long time and nothing happens, it means people are not interested in it anymore. Won't fix issues do not disappear anyway, they can be reopened if something concrete happens to them. -Bertrand
Re: Closing JIRA issues
On 10/11/06, Antonio Gallardo [EMAIL PROTECTED] wrote: ...IMHO, we should leave open this bug, because the fixi is not finished yet until we update excalibur... Same here. If update excalibur is a Jira or bugzilla issue somewhere, I'd make a link or a dependency to it to indicate what's happening. -Bertrand
[jira] Commented: (COCOON-1931) Provide more information when compiling a Flowscript fails
[ http://issues.apache.org/jira/browse/COCOON-1931?page=comments#action_12441507 ] Jörg Heinicke commented on COCOON-1931: --- IMO we should fix the flow, not the symptoms - if it is possible. Where is the NPE thrown? Can you provide a stacktrace? Jörg Provide more information when compiling a Flowscript fails -- Key: COCOON-1931 URL: http://issues.apache.org/jira/browse/COCOON-1931 Project: Cocoon Issue Type: Improvement Components: - Flowscript Affects Versions: 2.1.8, 2.1.9, 2.2-dev (Current SVN), 2.1.10-dev (current SVN) Reporter: Georg Hüttenegger Priority: Minor Attachments: FOM_JavaScriptInterpreter.java.MoreErrorInfoPatch When a flowscript defined in the sitemap cannot be loaded a NullPointerException is thrown without telling the developer the real cause of the issue. The same is true for certain Javascript coding errors (at least missing closing bracket of a for loop). The provided patch throws a CascadingRuntimeException with the name of the flowscript instead of just a simple NullPointerException. In that way the developer is lead directly to the cause of the problem instead of wondering what the real issue might be. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Subscription: COCOON-open-with-patch
Issue Subscription
Filter: COCOON-open-with-patch (87 issues)
Subscriber: cocoon
Key Summary
COCOON-1931 Provide more information when compiling a Flowscript fails
http://issues.apache.org/jira/browse/COCOON-1931
COCOON-1929 [PATCH] Reloading classloader in Cocoon 2.2
http://issues.apache.org/jira/browse/COCOON-1929
COCOON-1921 A bug in org.apache.cocoon.classloader.DefaultClassLoader
http://issues.apache.org/jira/browse/COCOON-1921
COCOON-1917 Request Encoding problem: multipart/form vs. url encoded
http://issues.apache.org/jira/browse/COCOON-1917
COCOON-1915 Nullable value with additional String or XMLizable in
JavaSelectionList
http://issues.apache.org/jira/browse/COCOON-1915
COCOON-1914 Text as XMLizable in EmptySelectionList
http://issues.apache.org/jira/browse/COCOON-1914
COCOON-1899 [PATCH] Cocoon XML:DB Implementation should not depend on Xindice
http://issues.apache.org/jira/browse/COCOON-1899
COCOON-1898 [PATCH] XPatch support for maven-cocoon-deployer-plugin
http://issues.apache.org/jira/browse/COCOON-1898
COCOON-1893 XML-Binding: Problem creating a new element
http://issues.apache.org/jira/browse/COCOON-1893
COCOON-1890 Provide a tool to update artifact versions within multiple POMs
http://issues.apache.org/jira/browse/COCOON-1890
COCOON-1879 Make fd:field whitespace trimming behavior configurable
http://issues.apache.org/jira/browse/COCOON-1879
COCOON-1877 [PATCH] Pageable Repeater
http://issues.apache.org/jira/browse/COCOON-1877
COCOON-1870 Lucene block does not store attributes when instructed so
http://issues.apache.org/jira/browse/COCOON-1870
COCOON-1846 [PATCH] BooleanField and radio do not send on-value-changed at the
rigth time with IE
http://issues.apache.org/jira/browse/COCOON-1846
COCOON-1843 LDAPTransformer: add-entry tag doesn't work
http://issues.apache.org/jira/browse/COCOON-1843
COCOON-1842 LDAPTransformer: ClassCastException with Binary fields
http://issues.apache.org/jira/browse/COCOON-1842
COCOON-1838 Always use 3-digit version number
http://issues.apache.org/jira/browse/COCOON-1838
COCOON-1811 [PATCH] Flow Script: Allow dynamic loading of JavaScript objects
even when scope is locked
http://issues.apache.org/jira/browse/COCOON-1811
COCOON-1810 [PATCH] JMSEventMessageListener does not work
http://issues.apache.org/jira/browse/COCOON-1810
COCOON-1794 [PATCH] Propagation of namespaces to a repeaters child bindings and
implementation of a move-node binding
http://issues.apache.org/jira/browse/COCOON-1794
COCOON-1776 [PATCH]Reload Bookmarks on bookmark file validity
http://issues.apache.org/jira/browse/COCOON-1776
COCOON-1738 double-listbox problem in repeaters
http://issues.apache.org/jira/browse/COCOON-1738
COCOON-1726 Implementation of Source that supports conditional GETs
http://issues.apache.org/jira/browse/COCOON-1726
COCOON-1717 Use custom cache keys for caching uri coplets using input modules.
http://issues.apache.org/jira/browse/COCOON-1717
COCOON-1703 A patch for caching fonts (fixes GDI issues), vertical text
orientation, color code fix, prefered unit for margins and measure unit
converter
http://issues.apache.org/jira/browse/COCOON-1703
COCOON-1697 Allow request parameters to be used in for (var k in h) kind of
Javascript Loops
http://issues.apache.org/jira/browse/COCOON-1697
COCOON-1686 [PATCH] COCOON-1671 Form not binding when prefix in binding
definition is unequal to that in the instance data for the same namespace.
http://issues.apache.org/jira/browse/COCOON-1686
COCOON-1648 Add support for ISO8601 in I18nTransformer and Forms
http://issues.apache.org/jira/browse/COCOON-1648
COCOON-1622 [PATCH] SendMailTransformer and HTML body
http://issues.apache.org/jira/browse/COCOON-1622
COCOON-1618 [PATCH] SoapGenerator/Serializer for Axis Block
http://issues.apache.org/jira/browse/COCOON-1618
COCOON-1611 [PATCH] Add additonal constructor to FormInstance.java to be able
to pass a locale
http://issues.apache.org/jira/browse/COCOON-1611
COCOON-1603 [PATCH] handling of alternatives in MailTransformer
http://issues.apache.org/jira/browse/COCOON-1603
COCOON-1573 Improvement SetAttributeJXPathBinding and Contribution
SetNodeValueJXPathBinding
http://issues.apache.org/jira/browse/COCOON-1573
COCOON-1557 [PATCH] Change access to AbstractContinuable.getContext to protected
http://issues.apache.org/jira/browse/COCOON-1557
COCOON-1556 [PATCH] Add a JXPathConvertor for conversion betwean beans and
Strings
http://issues.apache.org/jira/browse/COCOON-1556
COCOON-1535 [PATCH] enhancement to {global:} input module: return all sitemap
globals
[jira] Commented: (COCOON-1931) Provide more information when compiling a Flowscript fails
[ http://issues.apache.org/jira/browse/COCOON-1931?page=comments#action_12441513 ] Jörg Heinicke commented on COCOON-1931: --- flow = flaw Provide more information when compiling a Flowscript fails -- Key: COCOON-1931 URL: http://issues.apache.org/jira/browse/COCOON-1931 Project: Cocoon Issue Type: Improvement Components: - Flowscript Affects Versions: 2.1.8, 2.1.9, 2.2-dev (Current SVN), 2.1.10-dev (current SVN) Reporter: Georg Hüttenegger Priority: Minor Attachments: FOM_JavaScriptInterpreter.java.MoreErrorInfoPatch When a flowscript defined in the sitemap cannot be loaded a NullPointerException is thrown without telling the developer the real cause of the issue. The same is true for certain Javascript coding errors (at least missing closing bracket of a for loop). The provided patch throws a CascadingRuntimeException with the name of the flowscript instead of just a simple NullPointerException. In that way the developer is lead directly to the cause of the problem instead of wondering what the real issue might be. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: new avalon/excalibur test release
Joerg Heinicke wrote: Yes, that should be the way to go. Furthermore (if it is possible) you should add a dependency on the xmlutil issue to the Cocoon issue, so that we get informed when xmlutil is fixed. Yes that sounds about right to me. Create the ticket and I'll see to it that it gets applied. OTOH, if you feel confident enough about the patch you can commit it directly yourself, all Cocoon committers have write access to excalibur/avalon svn. Cheers Jorg
[jira] Closed: (COCOON-267) Lucene index/search broken, wrong contentType each doc so ignored
[ http://issues.apache.org/jira/browse/COCOON-267?page=all ] Jörg Heinicke closed COCOON-267. Resolution: Fixed So trying to set it to fixed again. Lucene index/search broken, wrong contentType each doc so ignored - Key: COCOON-267 URL: http://issues.apache.org/jira/browse/COCOON-267 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.0.5-dev (Current CVS) Environment: Operating System: All Platform: All Reporter: David Crossley Assigned To: Cocoon Developers Team Christian Zoffoli wrote: I have just downloaded the last CVS ...and I have found that lucene cant do any search on the indexed pages. The indexing process seems to work fine but Index Statistics says Total Count of Documents 0. I looked at my core.log and found many entries like this ... - DEBUG (2002-05-04) 17:28.33:193 [core.search.lucene](/cocoon/search/create) HttpProcessor[8080][3]/SimpleLuceneXMLIndexerImpl: Ignoring http://localhost:8080/cocoon/documents/mail-archives.html?cocoon-view=content (text/html) - I see from the code that the Ignoring message arises when the contentType is null or not an allowed contentType. The code builds a small list of allowedContentType (xml, xhtml). CVS shows that the code and the samples pages have not changed for a while. So why would the contentType returned by cocoon-view have suddenly changed to be html? According to the sample/search/sitemap.xmap the cocoon-view=content does in fact serialise to xml. So why would the contentType be reporting as html? Perhaps there has been a change in that arena. --David -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (COCOON-907) Move Woody into CocoonForms block
[ http://issues.apache.org/jira/browse/COCOON-907?page=all ] Jörg Heinicke reopened COCOON-907: -- Reopening this issue as it is closed, but not resolved. Move Woody into CocoonForms block - Key: COCOON-907 URL: http://issues.apache.org/jira/browse/COCOON-907 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: andrew Assigned To: Reinhard Poetz Priority: Minor Attachments: woody2cforms.xsl Rename all packages, namespaces and namespace-prefixes. (This is also a test of the voting facility in bugzilla) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-907) Move Woody into CocoonForms block
[ http://issues.apache.org/jira/browse/COCOON-907?page=all ] Jörg Heinicke closed COCOON-907. Resolution: Fixed So trying to set it to fixed. Move Woody into CocoonForms block - Key: COCOON-907 URL: http://issues.apache.org/jira/browse/COCOON-907 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: andrew Assigned To: Reinhard Poetz Priority: Minor Attachments: woody2cforms.xsl Rename all packages, namespaces and namespace-prefixes. (This is also a test of the voting facility in bugzilla) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Closing JIRA issues
Jean-Baptiste Quenot wrote: * Antonio Gallardo: Jean-Baptiste Quenot closed COCOON-1774. Resolution: Won't Fix Please reopen the issue if the problem persists with the new Dojo stuff. Thanks! I don't think it is the best way to close bugs. IMHO, the first part of a problem resolution is the problem identification and an open issue without a patch provides this first part. I would left open this bug (and onther of the current closed) until somebody comes with a solution. I don't know if you talked about this in GT2006, but if jira now becomes only a patch repository, I will like to know. At least we should vote for this policy change. Please don't take it personally. ;-) Hello Antonio, Sorry for the late reply, I missed your comment. Here is an explanation, I'm closing issues when: I disagree with most of this. Why are you wanting to close such issues? Why don't we use Jira to classify them, and then use Jira filters to see what needs to be attended to? At Forrest for example, we try to regularly go through the open issues and schedule them to be attended to (Fix Version) for either the current release or the next release. Anything else is left in an unscheduled state. Then a Jira Filter shows us the roadmap. BTW I discussed this with Vadim at the Hackathon. * it has been sitting in JIRA for a very long time So what? That just shows that people are too busy or don't bother to look at Jira. * it is in Feedback Required state and reporter did not reply for a long time Okay, should be closed. * no patch was provided It is still an issue that needs attention. * none of the Cocoon developers contributed to fix this issue So what? That just shows that people are too busy or don't bother to look at Jira. or one of the developers says issue is already fixed Okay, should be closed. I think there is no good reason to keep the issue open forever if no one intends to work on it, especially as the JIRA is full of these. Closing issues prematurely is disrespectful. -David
[jira] Commented: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer
[ http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441620 ] David Crossley commented on COCOON-1928: Cyriaque, have you tried declaring the serializer in your project's sitemap.xmap file? I am not sure which one takes precedence. Add the ability to pass the doctype in parameter for Serializer --- Key: COCOON-1928 URL: http://issues.apache.org/jira/browse/COCOON-1928 Project: Cocoon Issue Type: New Feature Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Cyriaque Dupoirieux Priority: Minor Attachments: AbstractTextSerializer.diff I need - with forrest - to get the doctype-system and doctype-public in a parameter like following : map:serializer logger=sitemap.serializer.xhtml mime-type=text/html name=xhtml pool-grow=2 pool-max=64 pool-min=2 src=org.apache.cocoon.serialization.XMLSerializer parameter name=doctype-public value=-//W3C//DTD XHTML 1.0 Transitional//EN / parameter name=doctype-system value=http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; / encodingUTF-8/encoding indentyes/indent omit-xml-declarationno/omit-xml-declaration /map:serializer here is a patch which apply to the AbstractTextSerializer. in case the doctype is also found in the childs, child have priority. Regards, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
