[jira] Closed: (COCOON-1315) I18nTransformer: translation with param substitution
[
https://issues.apache.org/jira/browse/COCOON-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Johnston closed COCOON-1315.
--
Resolution: Fixed
Fix Version/s: 2.2-dev (Current SVN)
2.1.11-dev (Current SVN)
Followup fix applied to trunk and 2.1.x branch. I've verified this resolves the
issue with garbage characters as I was seeing it in one of my projects. Thanks
Gunnar for the fix!
> I18nTransformer: translation with param substitution
>
>
> Key: COCOON-1315
> URL: https://issues.apache.org/jira/browse/COCOON-1315
> Project: Cocoon
> Issue Type: Bug
> Components: - Components: Sitemap
>Affects Versions: 2.2-dev (Current SVN)
> Environment: Operating System: All
> Platform: All
>Reporter: Neil Bacon
> Assigned To: Cocoon Developers Team
> Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
>
> Attachments: ParamSaxBuffer.java.patch
>
>
> The i18n transformer does this occasionally:
> throw new SAXException("Unclosed '}'");
> A FIXME comment on the characters() method in:
> src/java/org/apache/cocoon/xml/ParamSaxBuffer.java 1.6
> indicates that the code doesn't handle the situation where the parser
> provides the opening '{' for an i18n parameter placeholder in one call
> to characters() and the closing '}' in a subsequent call.
> This doesn't seem to have itched anyone else, but we have some big
> translation files and its itching us, so I'll attach a patch in an attachment.
> (a tidier fix would be to always just buffer the text from characters() and
> process it later in endElement())
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2021) NPE in WriteDOMSessionTransformer
[ https://issues.apache.org/jira/browse/COCOON-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Johnston closed COCOON-2021. -- Resolution: Invalid Closing at the request of the issue reporter. > NPE in WriteDOMSessionTransformer > - > > Key: COCOON-2021 > URL: https://issues.apache.org/jira/browse/COCOON-2021 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.10 >Reporter: robert.onslow > > The following POST thru' a Stream generator generates an NPE: > POST: > > http://apache.org/xsp/xscript/1.0"; > xmlns:soap="http://apache.org/xsp/soap/3.0"; > xmlns:xsp-request="http://apache.org/xsp/request/2.0"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xmlns:xhtml="http://www.w3.org/1999/xhtml"; > xmlns:n5="http://xlegal.co.uk/courts/schemas/parties"; > xmlns:n4="http://xlegal.co.uk/courts/schemas/case"; > xmlns:n3="http://xlegal.co.uk/courts/schemas/objects"; > xmlns:n2="http://xlegal.co.uk/courts/schemas/chron"; > xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:n1="http://xlegal.co.uk/XPDLEngine/"; > xmlns:xpdle="http://xlegal.co.uk/XPDLEngine/"; > xmlns:xforms="http://www.w3.org/2002/xforms";> > > >eventDate="2007-01-01"> > http://"; apparentDate="2007-01-01" > statCaseOfType="Claim Form"> > > > > > HC04C1234 > > > > > NEW CLAIMANT > > > NEW DEFENDANT > > > > > > Sitemap: > > > > > > > Exception: > java.lang.NullPointerException > at > org.apache.cocoon.transformation.WriteDOMSessionTransformer.storePrefixMapping(WriteDOMSessionTransformer.java:186) > at > org.apache.cocoon.transformation.WriteDOMSessionTransformer.startPrefixMapping(WriteDOMSessionTransformer.java:123) > at > org.apache.xerces.parsers.AbstractSAXParser.startNamespaceMapping(Unknown > Source) > at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown > Source) > at > org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown > Source) > The namespaces appear to be correct in the POST. The error is still present > when a different dom-root-element is used. > Is the stream generator is generating a startPrefixMapping(null, null) when > the unqualified elements appear? > Robert -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2000) bug in saveXml function
[
https://issues.apache.org/jira/browse/COCOON-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Johnston closed COCOON-2000.
--
Resolution: Fixed
Assignee: Jason Johnston
Closing issue; thanks for the patch!
> bug in saveXml function
> ---
>
> Key: COCOON-2000
> URL: https://issues.apache.org/jira/browse/COCOON-2000
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: Forms
>Affects Versions: 2.1.10, 2.1.11-dev (Current SVN)
>Reporter: Abbas Mousavi
> Assigned To: Jason Johnston
>Priority: Minor
>
> when you use saveXml to save a form
> to disk in flowscript this error happens
> Serialization parameter {indent} must have the value yes or no
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2000) bug in saveXml function
[
https://issues.apache.org/jira/browse/COCOON-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469966
]
Jason Johnston commented on COCOON-2000:
Patch committed at revision 503268.
> bug in saveXml function
> ---
>
> Key: COCOON-2000
> URL: https://issues.apache.org/jira/browse/COCOON-2000
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: Forms
>Affects Versions: 2.1.10, 2.1.11-dev (Current SVN)
>Reporter: Abbas Mousavi
>Priority: Minor
>
> when you use saveXml to save a form
> to disk in flowscript this error happens
> Serialization parameter {indent} must have the value yes or no
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1999) form styling stylesheets dont work with Saxon (forms-field-styling.xsl)
[ https://issues.apache.org/jira/browse/COCOON-1999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469965 ] Jason Johnston commented on COCOON-1999: Sorry, that last comment should have been directed to Abbas. > form styling stylesheets dont work with Saxon (forms-field-styling.xsl) > --- > > Key: COCOON-1999 > URL: https://issues.apache.org/jira/browse/COCOON-1999 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Forms >Affects Versions: 2.1.10, 2.1.11-dev (Current SVN) >Reporter: Abbas Mousavi >Priority: Minor > > when you use saxon, some form block examples show this error: > net.sf.saxon.trans.DynamicError: Ambiguous rule match for > /html/body[1]/fi:form-template[1]/div[1]/fi:group[1]/fi:items[1]/fi:group[1]/fi:items[1]/fi:field[2]/fi:styling[1]/@list-type > Matches both "fi:styling/@list-type | fi:styling/@list-orientation | > fi:styling/@listbox-size | fi:styling/@format | fi:styling/@layout | > fi:styling/@class" on line 149 of > resource://org/apache/cocoon/forms/resources/forms-field-styling.xsl > and "fi:styling/@*" on line 137 of > resource://org/apache/cocoon/forms/resources/forms-field-styling.xsl > resource://org/apache/cocoon/forms/resources/forms-field-styling.xsl - 102:-1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1999) form styling stylesheets dont work with Saxon (forms-field-styling.xsl)
[ https://issues.apache.org/jira/browse/COCOON-1999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469964 ] Jason Johnston commented on COCOON-1999: I agree changing the priority is a more appropriate fix. Grzegorz, can you come up with a patch? I'll be happy to commit it for you. > form styling stylesheets dont work with Saxon (forms-field-styling.xsl) > --- > > Key: COCOON-1999 > URL: https://issues.apache.org/jira/browse/COCOON-1999 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Forms >Affects Versions: 2.1.10, 2.1.11-dev (Current SVN) >Reporter: Abbas Mousavi >Priority: Minor > > when you use saxon, some form block examples show this error: > net.sf.saxon.trans.DynamicError: Ambiguous rule match for > /html/body[1]/fi:form-template[1]/div[1]/fi:group[1]/fi:items[1]/fi:group[1]/fi:items[1]/fi:field[2]/fi:styling[1]/@list-type > Matches both "fi:styling/@list-type | fi:styling/@list-orientation | > fi:styling/@listbox-size | fi:styling/@format | fi:styling/@layout | > fi:styling/@class" on line 149 of > resource://org/apache/cocoon/forms/resources/forms-field-styling.xsl > and "fi:styling/@*" on line 137 of > resource://org/apache/cocoon/forms/resources/forms-field-styling.xsl > resource://org/apache/cocoon/forms/resources/forms-field-styling.xsl - 102:-1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-1879) Make fd:field whitespace trimming behavior configurable
[ http://issues.apache.org/jira/browse/COCOON-1879?page=all ] Jason Johnston closed COCOON-1879. -- Resolution: Fixed > Make fd:field whitespace trimming behavior configurable > --- > > Key: COCOON-1879 > URL: http://issues.apache.org/jira/browse/COCOON-1879 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: Forms >Affects Versions: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) >Reporter: Jason Johnston > Attachments: COCOON-1879.diff > > > Currently fd:field widgets always trim leading and trailing whitespace from > the user's input. Sometimes this behavior is not desired, so it should be > configurable. > See this thread for discussion: > http://marc.theaimsgroup.com/?t=11496023148&r=1&w=2 > Patch forthcoming. -- 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-1879) Make fd:field whitespace trimming behavior configurable
[ http://issues.apache.org/jira/browse/COCOON-1879?page=comments#action_12449230 ] Jason Johnston commented on COCOON-1879: I incorporated the suggestions from Bruno and Simone (thanks!) and committed at revision 474132. The fd:field documentation page has been updated in Daisy. > Make fd:field whitespace trimming behavior configurable > --- > > Key: COCOON-1879 > URL: http://issues.apache.org/jira/browse/COCOON-1879 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: Forms >Affects Versions: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) >Reporter: Jason Johnston > Attachments: COCOON-1879.diff > > > Currently fd:field widgets always trim leading and trailing whitespace from > the user's input. Sometimes this behavior is not desired, so it should be > configurable. > See this thread for discussion: > http://marc.theaimsgroup.com/?t=11496023148&r=1&w=2 > Patch forthcoming. -- 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-1879) Make fd:field whitespace trimming behavior configurable
[ http://issues.apache.org/jira/browse/COCOON-1879?page=all ] Jason Johnston updated COCOON-1879: --- Attachment: COCOON-1879.diff Attached patch implements a new optional 'whitespace' attribute for fd:field. Possible values are: whitespace="preserve" : leading and trailing whitespace is preserved whitespace="trim-start" : only leading whitespace is trimmed whitespace="trim-end" : only trailing whitespace is trimmed whitespace="trim" : (default) both leading and trailing whitespace is trimmed, like old behavior. Input welcome. > Make fd:field whitespace trimming behavior configurable > --- > > Key: COCOON-1879 > URL: http://issues.apache.org/jira/browse/COCOON-1879 > Project: Cocoon > Type: Improvement > Components: Blocks: Forms > Versions: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) > Reporter: Jason Johnston > Attachments: COCOON-1879.diff > > Currently fd:field widgets always trim leading and trailing whitespace from > the user's input. Sometimes this behavior is not desired, so it should be > configurable. > See this thread for discussion: > http://marc.theaimsgroup.com/?t=11496023148&r=1&w=2 > Patch forthcoming. -- 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] Created: (COCOON-1879) Make fd:field whitespace trimming behavior configurable
Make fd:field whitespace trimming behavior configurable --- Key: COCOON-1879 URL: http://issues.apache.org/jira/browse/COCOON-1879 Project: Cocoon Type: Improvement Components: Blocks: Forms Versions: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) Reporter: Jason Johnston Currently fd:field widgets always trim leading and trailing whitespace from the user's input. Sometimes this behavior is not desired, so it should be configurable. See this thread for discussion: http://marc.theaimsgroup.com/?t=11496023148&r=1&w=2 Patch forthcoming. -- 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-1489) [PATCH] XInclude transformer does not handle fallback correctly
[ http://issues.apache.org/jira/browse/COCOON-1489?page=all ] Jason Johnston updated COCOON-1489: --- Attachment: COCOON-1489.diff Patch fixes issue with ill-formed result from xi:include within a fallback. The JUnit testcase for that functionality had a typo which is also fixed by this patch. In addition, the patch fixes multiple-nested fallbacks, which did not function before, and a JUnit testcase was added for that. Junit tests pass successfully, and all xinclude samples function as before. Patch is against 2.1.x branch, but would need to be applied to trunk as well. > [PATCH] XInclude transformer does not handle fallback correctly > --- > > Key: COCOON-1489 > URL: http://issues.apache.org/jira/browse/COCOON-1489 > Project: Cocoon > Type: Bug > Components: * Cocoon Core > Versions: 2.2-dev (Current SVN) > Environment: Operating System: All > Platform: All > Reporter: Joachim Breitsprecher > Attachments: COCOON-1489.diff, cocoon-xinclude-transformer-patch.txt > > When using the element, the XInclude transformer returns a > not-well-formed document. > Example: > http://www.w3.org/2001/XInclude";> > > > This should be here if the file was not found > > > > returns this, if the included resource does not exist: > xmlns:xi="http://www.w3.org/2001/XInclude";> > > This should be here if the file was not found > > -- 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-1753) XInclude transformer uses href fragment rather than xpointer attribute (spec conformance)
[ http://issues.apache.org/jira/browse/COCOON-1753?page=comments#action_12376031 ] Jason Johnston commented on COCOON-1753: I wrote the patch to be entirely backward compatible, though it does write a WARN log message saying support for the old non-standard syntax will be removed in a future release. That can (and should) go up for a vote of course. If it's decided that the old syntax should remain supported (which would technically be a violation of the spec), then you can just remove that WARN message and everything should be dandy. > XInclude transformer uses href fragment rather than xpointer attribute (spec > conformance) > - > > Key: COCOON-1753 > URL: http://issues.apache.org/jira/browse/COCOON-1753 > Project: Cocoon > Type: Bug > Components: - Components: Sitemap > Versions: 2.1.9 > Reporter: Jason Johnston > Assignee: Antonio Gallardo > Attachments: COCOON-1753.diff > > The XInclude 1.0 spec (see http://www.w3.org/TR/xinclude/#include_element) > states the following about the href attribute: > "Fragment identifiers must not be used; their appearance is a fatal error." > Cocoon's XIncludeTransformer incorrectly allows xpointer fragments to be > specified using a fragment identifier in the href attribute. The correct way > to support xpointers is the "xpointer" attribute on xi:include, which the > transformer does not currently recognize. -- 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-1811) [PATCH] Flow Script: Allow dynamic loading of JavaScript objects even when scope is locked
[
http://issues.apache.org/jira/browse/COCOON-1811?page=comments#action_12372945
]
Jason Johnston commented on COCOON-1811:
Would it perhaps make more sense to modify the behavior of cocoon.load() so
that it loads the target script not into the top-level scope but instead into
the scope from which it is called? So in the original example the myObject
class would only be defined within the scope of the loadScript() function. This
seems cleaner to me.
> [PATCH] Flow Script: Allow dynamic loading of JavaScript objects even when
> scope is locked
> --
>
> Key: COCOON-1811
> URL: http://issues.apache.org/jira/browse/COCOON-1811
> Project: Cocoon
> Type: Improvement
> Components: Blocks: Forms
> Versions: 2.2-dev (Current SVN), 2.1.9-dev (current SVN)
> Reporter: Rob Berens
> Priority: Minor
> Attachments: FOM_JavaScriptInterpreter.txt
>
> Currently it is not possible to add variables to the scope of a
> FOM_JavaScriptInterpreter, unless the scope is not locked yet or when still
> in the main loading process or when loading native java classes. Therefore it
> is not possible to dynamically load JavaScript classes like the one below:.
> ---
> function myObject() {// at this point the current
> implementation throws the exception
> // constructor for myObject
> }
> myObject.prototype.myMethod = function() {
> // implementation of myMethod
> }
> ---
> from within a script fragment like this one:
> ---
> function loadScript() {
> var scriptURI = "determineScriptURIFromRequest";
> cocoon.load(scriptURI);
> }
> ---
> The attached patch solves this by allowing also objects of the type
> org.mozilla.javascript.Function to be loaded into a locked scope.
--
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-1753) XInclude transformer uses href fragment rather than xpointer attribute (spec conformance)
[ http://issues.apache.org/jira/browse/COCOON-1753?page=comments#action_12366586 ] Jason Johnston commented on COCOON-1753: Also in the diff are updates to the samples changing them from using url-fragments to xpointer attributes. > XInclude transformer uses href fragment rather than xpointer attribute (spec > conformance) > - > > Key: COCOON-1753 > URL: http://issues.apache.org/jira/browse/COCOON-1753 > Project: Cocoon > Type: Bug > Components: - Components: Sitemap > Versions: 2.1.9-dev (current SVN) > Reporter: Jason Johnston > Attachments: COCOON-1753.diff > > The XInclude 1.0 spec (see http://www.w3.org/TR/xinclude/#include_element) > states the following about the href attribute: > "Fragment identifiers must not be used; their appearance is a fatal error." > Cocoon's XIncludeTransformer incorrectly allows xpointer fragments to be > specified using a fragment identifier in the href attribute. The correct way > to support xpointers is the "xpointer" attribute on xi:include, which the > transformer does not currently recognize. -- 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-1753) XInclude transformer uses href fragment rather than xpointer attribute (spec conformance)
[ http://issues.apache.org/jira/browse/COCOON-1753?page=all ] Jason Johnston updated COCOON-1753: --- Attachment: COCOON-1753.diff Attached patch. Implements xpointer="..." attribute as the preferred way for specifying xpointer fragments. The old href-fragments are still interpreted but produce a WARN log message stating support will be removed in a future release. Tested against the samples and some ad-hoc tests. Needs review. > XInclude transformer uses href fragment rather than xpointer attribute (spec > conformance) > - > > Key: COCOON-1753 > URL: http://issues.apache.org/jira/browse/COCOON-1753 > Project: Cocoon > Type: Bug > Components: - Components: Sitemap > Versions: 2.1.9-dev (current SVN) > Reporter: Jason Johnston > Attachments: COCOON-1753.diff > > The XInclude 1.0 spec (see http://www.w3.org/TR/xinclude/#include_element) > states the following about the href attribute: > "Fragment identifiers must not be used; their appearance is a fatal error." > Cocoon's XIncludeTransformer incorrectly allows xpointer fragments to be > specified using a fragment identifier in the href attribute. The correct way > to support xpointers is the "xpointer" attribute on xi:include, which the > transformer does not currently recognize. -- 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-1570) fi:validation-errors styling element does not work in AJAX mode
[ http://issues.apache.org/jira/browse/COCOON-1570?page=comments#action_12365744 ] Jason Johnston commented on COCOON-1570: Apologies for the delay... yes it is still an issue in current SVN. > fi:validation-errors styling element does not work in AJAX mode > --- > > Key: COCOON-1570 > URL: http://issues.apache.org/jira/browse/COCOON-1570 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.1.8 > Environment: Operating System: other > Platform: Other > Reporter: Jason Johnston > Assignee: Jason Johnston > > The styling element does not work in AJAX mode, > because > it is not generated by a template element and therefore has no way to signal > whether or not it needs to be updated. > An equivalent template "ft:" element should be created to replace the current > "fi:" element, which creates its own instance representation with the optional > bu:replace wrapper when necessary. > See the following threads for discussion: > http://marc.theaimsgroup.com/?t=11229292151&r=1&w=2 > http://marc.theaimsgroup.com/?t=11229747071&r=1&w=2 -- 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] Created: (COCOON-1753) XInclude transformer uses href fragment rather than xpointer attribute (spec conformance)
XInclude transformer uses href fragment rather than xpointer attribute (spec conformance) - Key: COCOON-1753 URL: http://issues.apache.org/jira/browse/COCOON-1753 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.1.9-dev (current SVN) Reporter: Jason Johnston The XInclude 1.0 spec (see http://www.w3.org/TR/xinclude/#include_element) states the following about the href attribute: "Fragment identifiers must not be used; their appearance is a fatal error." Cocoon's XIncludeTransformer incorrectly allows xpointer fragments to be specified using a fragment identifier in the href attribute. The correct way to support xpointers is the "xpointer" attribute on xi:include, which the transformer does not currently recognize. -- 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-1731) Unable to create a new JXParthBinding outside the org.apache.cocoon.forms.binding package
[ http://issues.apache.org/jira/browse/COCOON-1731?page=comments#action_12362651 ] Jason Johnston commented on COCOON-1731: I can verify this is a problem. I brought it up on the developers mailing list a few months ago but I didn't follow up. JXPathBindingBase.CommonAttributes needs to either be made into a public inner class or pulled out into its own class file. > Unable to create a new JXParthBinding outside the > org.apache.cocoon.forms.binding package > - > > Key: COCOON-1731 > URL: http://issues.apache.org/jira/browse/COCOON-1731 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9-dev (current SVN) > Reporter: Philippe Gassmann > Priority: Minor > > I want to create a new custom JXPath binding and I have the following problem > : > My class extends JXPathBindingBase so i must call super(commonAttrs) in my > constructors (commonAttrs is a CommonAttribtues object). > The CommonAttributes class > (org.apache.cocoon.forms.binding.JXPathBindingBuilderBase.CommonAttributes) > is protected so I'm not able to write a custom binding outside the package of > CommonAttributes (org.apache.cocoon.forms.binding) > Is it possible to make Commoattributes public ? -- 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
