Re: Errors in screen while running findByAnd

[Jacopo Cappellato]

Adam, all,

this is interesting, thanks for the research.

I would suggest the following approach:

1) identify which one of the recent changes we did caused this error to happen
2) if possible, commit a temporary workaround for this to let the system work 
as before
3) file a bug in the Freemarker issue tracker
4) contact the Freemarker community to discuss the issue and try to schedule 
with them a new release date for the new release (2.3.20); ideally this will 
also contain my fixes for the deadlock condition affecting Freemarker
5) when the new Freemarker release will be issued, we upgrade OFBiz to it and 
we revert #2

I can help with #4 as I recently have been in touch with them.
Did you get a chance to figure out how many screens could are affected? If 
there are just a few then, instead of #2,we could commit a temporaray fix for 
the screens rather than a global one.

Kind regards,

Jacopo

On May 16, 2012, at 9:55 PM, Adam Heath wrote:

> On 05/16/2012 11:30 AM, Adam Heath wrote:
>> On 05/16/2012 11:18 AM, Adam Heath wrote:
>>> On 05/16/2012 11:05 AM, Adam Heath wrote:
 On 05/16/2012 06:41 AM, Jacopo Cappellato wrote:
> https://demo-trunk.ofbiz.apache.org/ordermgr/control/orderview?orderId=Demo1002
 
 This may be a stupid question, but why doesn't "admin/ofbiz" work as a
 login?  (right now, the admin account is disabled for 5 minutes,
 that's my fault).
 
 I can't yet see this error.  I'm updating to trunk, and will attempt
 the same thing locally.
>>> 
>>> Is freemarker really this stupid?  Really?  That line is:
>>> 
>>> shipmentRouteSegments=delegator.findByAnd("ShipmentRouteSegment",
>>> {"shipmentId" : shipment.shipmentId}, null, false) [on line 581,
>>> column 25 in
>>> component://order/webapp/ordermgr/order/ordershippinginfo.ftl]
>>> 
>>> And there *is* a findByAnd in Delegator that has (String, Map, List,
>>> boolean).  Why is thinking that findByAnd(String, Object...) is the
>>> correct one to use?  I'm leaning towards this being a freemarker bug.
>>> 
>>> If one other person agrees with me, then I'll attempt to simulate it
>>> as a real freemark bug(new freemarker template, new object that
>>> implements similiar interfaces, isolated from any/all ofbiz code), to
>>> make reporting a freemark bug simpler.  And then fix freemarker myself.
>> 
>> Gah.  As a test, I tried placing the Object... variant last in both
>> the interface and the class.  No change, it still picks the wrong method.
>> 
>> Velocity, Freemarker, Groovy, Asm, and other similiar tools all go
>> from free-form text, to eventually call a method.  Every single tool
>> needs to be the most correct method to call.  And they all implement
>> their own way of figuring that out.  Does anyone know of something
>> that does that correctly in a simple library?  There is nothing in the
>> default java spec that does this(which is an oversite, imho).
> 
> Yes, absolute bug in freemarker.
> 
> s/null/[]/ in the ftl, and it picks the correct method.  I read the
> freemarker code to come to a workaround.  But I do not want to commit
> the workaround into ofbiz.
> 

[jira] [Created] (OFBIZ-4882) QuickAdd screen rendering exception in ecommerce

[Wai (JIRA)]

Wai created OFBIZ-4882:
--

 Summary: QuickAdd screen rendering exception in ecommerce
 Key: OFBIZ-4882
 URL: https://issues.apache.org/jira/browse/OFBIZ-4882
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: SVN trunk
Reporter: Wai


Exception trace:

Method public java.lang.String 
org.ofbiz.widget.screen.ScreenRenderer.render(java.lang.String) throws 
org.ofbiz.base.util.GeneralException,java.io.IOException,org.xml.sax.SAXException,javax.xml.parsers.ParserConfigurationException
 threw an exception when invoked on 
org.ofbiz.widget.screen.ScreenRenderer@79108c69 with arguments of types 
[java.lang.String,] The problematic instruction: -- ==> 
${screens.render(quickaddsummaryScreen)} [on line 71, column 13 in 
component://order/webapp/ordermgr/entry/catalog/quickadd.ftl] -- Java 
backtrace for programmers: -- 
freemarker.template.TemplateModelException: Method public java.lang.String 
org.ofbiz.widget.screen.ScreenRenderer.render(java.lang.String) throws 
org.ofbiz.base.util.GeneralException,java.io.IOException,org.xml.sax.SAXException,javax.xml.parsers.ParserConfigurationException
 threw an exception when invoked on 
org.ofbiz.widget.screen.ScreenRenderer@79108c69 with arguments of types 
[java.lang.String,] at 
freemarker.ext.beans.OverloadedMethodModel.exec(OverloadedMethodModel.java:134) 
at freemarker.core.MethodCall._getAsTemplateModel(MethodCall.java:93) at 
freemarker.core.Expression.getAsTemplateModel(Expression.java:89) at 
freemarker.core.Expression.getStringValue(Expression.java:93) at 
freemarker.core.DollarVariable.accept(DollarVariable.java:76) at 
freemarker.core.Environment.visit(Environment.java:221) at 
freemarker.core.MixedContent.accept(MixedContent.java:92) at 
freemarker.core.Environment.visit(Environment.java:221) at 
freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:167) at 
freemarker.core.Environment.visit(Environment.java:428) at 
freemarker.core.IteratorBlock.accept(IteratorBlock.java:102) at 
freemarker.core.Environment.visit(Environment.java:221) at 
freemarker.core.MixedContent.accept(MixedContent.java:92) at 
freemarker.core.Environment.visit(Environment.java:221) at 
freemarker.core.IfBlock.accept(IfBlock.java:82) at 
freemarker.core.Environment.visit(Environment.java:221) at 
freemarker.core.MixedContent.accept(MixedContent.java:92) at 
freemarker.core.Environment.visit(Environment.java:221) at 
freemarker.core.Environment.process(Environment.java:199) at 
org.ofbiz.base.util.template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:257)
 at org.ofbiz.widget.screen.HtmlWidget.renderHtmlTemplate(HtmlWidget.java:225) 
at 
org.ofbiz.widget.screen.HtmlWidget$HtmlTemplate.renderWidgetString(HtmlWidget.java:270)
 at org.ofbiz.widget.screen.HtmlWidget.renderWidgetString(HtmlWidget.java:130) 
at 
org.ofbiz.widget.screen.ModelScreenWidget$PlatformSpecific.renderWidgetString(ModelScreenWidget.java:915)
 at 
org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:104)
 at 
org.ofbiz.widget.screen.ModelScreenWidget$DecoratorSection.renderWidgetString(ModelScreenWidget.java:613)
 at 
org.ofbiz.widget.screen.ModelScreenWidget$SectionsRenderer.render(ModelScreenWidget.java:129)
 at 
org.ofbiz.widget.screen.ModelScreenWidget$DecoratorSectionInclude.renderWidgetString(ModelScreenWidget.java:646)
 at 
org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:104)
 at 
org.ofbiz.widget.screen.ModelScreenWidget$Container.renderWidgetString(ModelScreenWidget.java:260)
 at 
org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:104)
 at 
org.ofbiz.widget.screen.ModelScreenWidget$Container.renderWidgetString(ModelScreenWidget.java:260)
 at 
org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:104)
 at 
org.ofbiz.widget.screen.ModelScreenWidget$Section.renderWidgetString(ModelScreenWidget.java:191)
 at 
org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:104)
 at 
org.ofbiz.widget.screen.ModelScreenWidget$Section.renderWidgetString(ModelScreenWidget.java:191)
 at 
org.ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:396) at 
org.ofbiz.widget.screen.ScreenFactory.renderReferencedScreen(ScreenFactory.java:216)
 at 
org.ofbiz.widget.screen.ModelScreenWidget$DecoratorScreen.renderWidgetString(ModelScreenWidget.java:580)
 at 
org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:104)
 at 
org.ofbiz.widget.screen.ModelScreenWidget$Section.renderWidgetString(ModelScreenWidget.java:191)
 at 
org.ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:396) at 
org.ofbiz.widget.screen.ScreenRenderer.render(ScreenRenderer.java:135) at 
org.ofbiz.widget.screen.ScreenRenderer.render(Scre

[jira] [Commented] (OFBIZ-4749) OfBiz 10.04 Does not compile with Oracle JDK 7

[Paul Foxworthy (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277478#comment-13277478
 ] 

Paul Foxworthy commented on OFBIZ-4749:
---

Can anyone confirm if the patch for OFBIZ-4387 fixes this issue?

> OfBiz 10.04 Does not compile with Oracle JDK 7
> --
>
> Key: OFBIZ-4749
> URL: https://issues.apache.org/jira/browse/OFBIZ-4749
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Release 10.04
> Environment: Windows 7, Oracle JDK 7
>Reporter: Karl Laird
>Priority: Critical
>  Labels: build-failure
> Fix For: Release 10.04
>
>
> The OFBIZ version is apache-ofbiz-10.04
> When I'm compiling the project with the embedded and using ant run-install 
> run there is a error message
> classes:
>   [javac16] Compiling 13 source files to 
> C:\_portable\PortableApps\apache-ofbiz-10.04\framework\security\build\classes
>   [javac16] warning: [options] bootstrap class path not set in conjunction 
> with -source 1.6
>   [javac16] 
> C:\_portable\PortableApps\apache-ofbiz-10.04\framework\security\src\org\ofbiz\security\OFBizSecurity.java:52:
>  error: invalid inferred types for V; inferred type does not conform to 
> declared bound(s)
>   [javac16] protected static final Map> 
> simpleRoleEntity = UtilMisc.toMap(
>   [javac16]   
>^
>   [javac16] inferred: Map
>   [javac16] bound(s): Map
>   [javac16]   where V,V1,V2,V3 are type-variables:
>   [javac16] V extends Object declared in method 
> toMap(String,V1,String,V2,String,V3)
>   [javac16] V1 extends V declared in method 
> toMap(String,V1,String,V2,String,V3)
>   [javac16] V2 extends V declared in method 
> toMap(String,V1,String,V2,String,V3)
>   [javac16] V3 extends V declared in method 
> toMap(String,V1,String,V2,String,V3)
>   [javac16] 1 error
>   [javac16] 1 warning
> Changing to use JDK 6 works around this issue - however given that EOL for 
> JDK6 is November 2012 (IE this year, already extended from July) this is not 
> a long term solution.
> Regards
> Karl

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: CommonEmptyHeader

[Paul Foxworthy]

If the intention is to override the default behaviour, wouldn't it be clearer
to add an attribute to the widget  along the lines of

showTitle="false"

or perhaps

useFieldNameForTitle="false"

instead of fighting with a fake title that's not really a title at all?

The default value out of the schema for the attribute would, of course, be
"true".

What do people think?

Cheers

Paul Foxworthy


Adrian Crum-3 wrote
> 
> On 5/16/2012 11:44 AM, Christian Geisert wrote:
>> What's the point of CommonEmptyHeader?
>>
>> It's definied in CommonUiLabels.xml as:
>>
>> 
>>  
>>
>> 
>>
>> It is just a simple space (0x20)
>>
>> It is used ~500 times in forms as a title in a field definition
>>
>> Example:
>>
>> >...
>>>
>>  >description="${uiLabelMap.CommonCancelDone}">
>>
>>  
>>
>> 
>>
>>
>> This is a button which should have no label, but if the title attribute
>> is empty then the name attribute is used as label.
>>
>> Why not just put a space (" ") into the title attribute - still a hack,
>> but exactly same result a using CommonEmptyHeader without the need using
>> CommonEmptyHeader.
>>
>> The real solution is of course not to display a label if the title
>> attribute is empty.
> 
> An empty title attribute is meant to be a shortcut, or a developer's 
> convenience - the widgets will use the field name to look up the correct 
> label.
> 
> Putting a space in the title attribute is the only way to turn off the 
> default behavior.
> 
> -Adrian
> 


-
--
Coherent Software Australia Pty Ltd
http://www.cohsoft.com.au/

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/

--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Re-svn-commit-r1338836-in-ofbiz-branches-release12-04-framework-base-dtd-framework-base-src-org-ofbi-tp4631741p4631853.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[jira] [Comment Edited] (OFBIZ-4657) ArrayIndexOutOfBoundsException in OrderServices.xml:updateOrderItemShipGroup

[Paul Foxworthy (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277265#comment-13277265
 ] 

Paul Foxworthy edited comment on OFBIZ-4657 at 5/16/12 11:35 PM:
-

Turns out there is a problem after all. I'm pretty sure this is the same 
problem as OFBIZ-4865, which has a patch. Thanks to Leon for tracking it down.

  was (Author: paul_foxworthy):
Turns out there is a problem after all. I'm pretty sure this is the same 
problem as OFBIZ-4865, which has a patch. Thanks to Leon for tracking it.
  
> ArrayIndexOutOfBoundsException in OrderServices.xml:updateOrderItemShipGroup
> 
>
> Key: OFBIZ-4657
> URL: https://issues.apache.org/jira/browse/OFBIZ-4657
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: SVN trunk
>Reporter: Alexander Reelsen
>Assignee: Jacques Le Roux
>
> When changing the billing or shipping address of a sales order in the 
> ordermgr, a bsh exception is logged - with absolutely no trace where it is 
> coming from. And the change of the adress is successful as well.
> The exception occurs here in OrderServices.xml in updateOrderItemShipGroup() 
> in the BSH script
> 
> Splitting for not existing chars and assuming the array was split 
> successfully leads to the exception. The fix could work liks this, but as I 
> do not have a clue at all, why it is split by the at-sign anyway I dont know 
> if this fix does what it should. For us it does, because we do not care for 
> sales order ship groups.
> 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (OFBIZ-4657) ArrayIndexOutOfBoundsException in OrderServices.xml:updateOrderItemShipGroup

[Paul Foxworthy (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277265#comment-13277265
 ] 

Paul Foxworthy edited comment on OFBIZ-4657 at 5/16/12 11:34 PM:
-

Turns out there is a problem after all. I'm pretty sure this is the same 
problem as OFBIZ-4865, which has a patch. Thanks to Leon for tracking it.

  was (Author: paul_foxworthy):
I'm pretty sure this is the same problem as OFBIZ-4865, which has a patch. 
Thanks to Leon for tracking down the problem.
  
> ArrayIndexOutOfBoundsException in OrderServices.xml:updateOrderItemShipGroup
> 
>
> Key: OFBIZ-4657
> URL: https://issues.apache.org/jira/browse/OFBIZ-4657
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: SVN trunk
>Reporter: Alexander Reelsen
>Assignee: Jacques Le Roux
>
> When changing the billing or shipping address of a sales order in the 
> ordermgr, a bsh exception is logged - with absolutely no trace where it is 
> coming from. And the change of the adress is successful as well.
> The exception occurs here in OrderServices.xml in updateOrderItemShipGroup() 
> in the BSH script
> 
> Splitting for not existing chars and assuming the array was split 
> successfully leads to the exception. The fix could work liks this, but as I 
> do not have a clue at all, why it is split by the at-sign anyway I dont know 
> if this fix does what it should. For us it does, because we do not care for 
> sales order ship groups.
> 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4865) Exception there when trying to update order's "Shipping Destination Address"

[Paul Foxworthy (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277263#comment-13277263
 ] 

Paul Foxworthy commented on OFBIZ-4865:
---

Thanks Leon.

My apologies for missing the call to updateOrderItemShipGroup from the 
updateOrderContactMech service in my OFBIZ-4389 patch.

> Exception there when trying to update order's "Shipping Destination Address"
> 
>
> Key: OFBIZ-4865
> URL: https://issues.apache.org/jira/browse/OFBIZ-4865
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: SVN trunk
>Reporter: Leon
> Attachments: OFBIZ-4865.patch
>
>
> If click the "update" button of "Shipping Destination Address" in order view 
> page, an exception thrown out as:
> {quote}
> The Following Errors Occurred:
> BeanShell execution caused an error: Sourced file: inline evaluation of: `` 
> shipmentMethod = parameters.get("shipmentMethod"); if(s . . . ''
> {quote}
> I'm not familiar with beanshell and the mechanism of how ofbiz handling it, 
> but I'm sure that there'no such error days ago.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: svn commit: r1339314 - /ofbiz/branches/release11.04/mergefromtrunk.sh

[Jacopo Cappellato]

Hi Erwan,

in 11.04 the run-install task has not been renamed load-demo.

Jacopo

On May 16, 2012, at 9:18 PM, er...@apache.org wrote:

> Author: erwan
> Date: Wed May 16 19:18:27 2012
> New Revision: 1339314
> 
> URL: http://svn.apache.org/viewvc?rev=1339314&view=rev
> Log:
> using internal ant and the right target load-demo
> 
> Modified:
>ofbiz/branches/release11.04/mergefromtrunk.sh
> 
> Modified: ofbiz/branches/release11.04/mergefromtrunk.sh
> URL: 
> http://svn.apache.org/viewvc/ofbiz/branches/release11.04/mergefromtrunk.sh?rev=1339314&r1=1339313&r2=1339314&view=diff
> ==
> --- ofbiz/branches/release11.04/mergefromtrunk.sh (original)
> +++ ofbiz/branches/release11.04/mergefromtrunk.sh Wed May 16 19:18:27 2012
> @@ -93,9 +93,9 @@ case "$cmd" in
>   svn merge -r "$prevRev:$rev" 
> https://svn.apache.org/repos/asf/ofbiz/trunk 
>   ;;
>   (test)
> - ant clean-all
> - ant run-install
> - ant run-tests
> + ./ant clean-all
> + ./ant load-demo
> + ./ant run-tests
>   ;;
>   (commit)
>   svn commit -F runtime/merge-state/log-message
> 
> 

Re: Errors in screen while running findByAnd

[Adam Heath]

On 05/16/2012 11:30 AM, Adam Heath wrote:
> On 05/16/2012 11:18 AM, Adam Heath wrote:
>> On 05/16/2012 11:05 AM, Adam Heath wrote:
>>> On 05/16/2012 06:41 AM, Jacopo Cappellato wrote:
 https://demo-trunk.ofbiz.apache.org/ordermgr/control/orderview?orderId=Demo1002
>>>
>>> This may be a stupid question, but why doesn't "admin/ofbiz" work as a
>>> login?  (right now, the admin account is disabled for 5 minutes,
>>> that's my fault).
>>>
>>> I can't yet see this error.  I'm updating to trunk, and will attempt
>>> the same thing locally.
>>
>> Is freemarker really this stupid?  Really?  That line is:
>>
>> shipmentRouteSegments=delegator.findByAnd("ShipmentRouteSegment",
>> {"shipmentId" : shipment.shipmentId}, null, false) [on line 581,
>> column 25 in
>> component://order/webapp/ordermgr/order/ordershippinginfo.ftl]
>>
>> And there *is* a findByAnd in Delegator that has (String, Map, List,
>> boolean).  Why is thinking that findByAnd(String, Object...) is the
>> correct one to use?  I'm leaning towards this being a freemarker bug.
>>
>> If one other person agrees with me, then I'll attempt to simulate it
>> as a real freemark bug(new freemarker template, new object that
>> implements similiar interfaces, isolated from any/all ofbiz code), to
>> make reporting a freemark bug simpler.  And then fix freemarker myself.
> 
> Gah.  As a test, I tried placing the Object... variant last in both
> the interface and the class.  No change, it still picks the wrong method.
> 
> Velocity, Freemarker, Groovy, Asm, and other similiar tools all go
> from free-form text, to eventually call a method.  Every single tool
> needs to be the most correct method to call.  And they all implement
> their own way of figuring that out.  Does anyone know of something
> that does that correctly in a simple library?  There is nothing in the
> default java spec that does this(which is an oversite, imho).

Yes, absolute bug in freemarker.

s/null/[]/ in the ftl, and it picks the correct method.  I read the
freemarker code to come to a workaround.  But I do not want to commit
the workaround into ofbiz.

[jira] [Commented] (OFBIZ-4876) missing form product/widget/catalog/ImageManagementForms.xml#productImageReplace

[Erwan de FERRIERES (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277044#comment-13277044
 ] 

Erwan de FERRIERES commented on OFBIZ-4876:
---

rev 1339320 for release 12.04
rev 1339314 for release 11.04

> missing form 
> product/widget/catalog/ImageManagementForms.xml#productImageReplace
> 
>
> Key: OFBIZ-4876
> URL: https://issues.apache.org/jira/browse/OFBIZ-4876
> Project: OFBiz
>  Issue Type: Bug
>  Components: product
>Affects Versions: SVN trunk
>Reporter: Wai
>Assignee: Erwan de FERRIERES
> Fix For: SVN trunk
>
>
> product/widget/catalog/ImageManagementScreens.xml#ListImageReplace# is not 
> defined.
> Hence, under certain condition when productId is not available or become 
> lost, the following error occurs.
> :ERROR MESSAGE:
> org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen 
> [component://common/widget/CommonScreens.xml#GlobalDecorator]: 
> java.lang.RuntimeException: Error rendering included form named 
> [productImageReplace] at location 
> [component://product/widget/catalog/ImageManagementForms.xml]: 
> java.lang.NullPointerException (Error rendering included form named 
> [productImageReplace] at location 
> [component://product/widget/catalog/ImageManagementForms.xml]: 
> java.lang.NullPointerException)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (OFBIZ-4876) missing form product/widget/catalog/ImageManagementForms.xml#productImageReplace

[Erwan de FERRIERES (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erwan de FERRIERES closed OFBIZ-4876.
-


> missing form 
> product/widget/catalog/ImageManagementForms.xml#productImageReplace
> 
>
> Key: OFBIZ-4876
> URL: https://issues.apache.org/jira/browse/OFBIZ-4876
> Project: OFBiz
>  Issue Type: Bug
>  Components: product
>Affects Versions: SVN trunk
>Reporter: Wai
>Assignee: Erwan de FERRIERES
> Fix For: SVN trunk
>
>
> product/widget/catalog/ImageManagementScreens.xml#ListImageReplace# is not 
> defined.
> Hence, under certain condition when productId is not available or become 
> lost, the following error occurs.
> :ERROR MESSAGE:
> org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen 
> [component://common/widget/CommonScreens.xml#GlobalDecorator]: 
> java.lang.RuntimeException: Error rendering included form named 
> [productImageReplace] at location 
> [component://product/widget/catalog/ImageManagementForms.xml]: 
> java.lang.NullPointerException (Error rendering included form named 
> [productImageReplace] at location 
> [component://product/widget/catalog/ImageManagementForms.xml]: 
> java.lang.NullPointerException)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Errors in screen while running findByAnd

[Adam Heath]

On 05/16/2012 11:18 AM, Adam Heath wrote:
> On 05/16/2012 11:05 AM, Adam Heath wrote:
>> On 05/16/2012 06:41 AM, Jacopo Cappellato wrote:
>>> https://demo-trunk.ofbiz.apache.org/ordermgr/control/orderview?orderId=Demo1002
>>
>> This may be a stupid question, but why doesn't "admin/ofbiz" work as a
>> login?  (right now, the admin account is disabled for 5 minutes,
>> that's my fault).
>>
>> I can't yet see this error.  I'm updating to trunk, and will attempt
>> the same thing locally.
> 
> Is freemarker really this stupid?  Really?  That line is:
> 
> shipmentRouteSegments=delegator.findByAnd("ShipmentRouteSegment",
> {"shipmentId" : shipment.shipmentId}, null, false) [on line 581,
> column 25 in
> component://order/webapp/ordermgr/order/ordershippinginfo.ftl]
> 
> And there *is* a findByAnd in Delegator that has (String, Map, List,
> boolean).  Why is thinking that findByAnd(String, Object...) is the
> correct one to use?  I'm leaning towards this being a freemarker bug.
> 
> If one other person agrees with me, then I'll attempt to simulate it
> as a real freemark bug(new freemarker template, new object that
> implements similiar interfaces, isolated from any/all ofbiz code), to
> make reporting a freemark bug simpler.  And then fix freemarker myself.

Gah.  As a test, I tried placing the Object... variant last in both
the interface and the class.  No change, it still picks the wrong method.

Velocity, Freemarker, Groovy, Asm, and other similiar tools all go
from free-form text, to eventually call a method.  Every single tool
needs to be the most correct method to call.  And they all implement
their own way of figuring that out.  Does anyone know of something
that does that correctly in a simple library?  There is nothing in the
default java spec that does this(which is an oversite, imho).

Re: Errors in screen while running findByAnd

[Adam Heath]

On 05/16/2012 11:05 AM, Adam Heath wrote:
> On 05/16/2012 06:41 AM, Jacopo Cappellato wrote:
>> https://demo-trunk.ofbiz.apache.org/ordermgr/control/orderview?orderId=Demo1002
> 
> This may be a stupid question, but why doesn't "admin/ofbiz" work as a
> login?  (right now, the admin account is disabled for 5 minutes,
> that's my fault).
> 
> I can't yet see this error.  I'm updating to trunk, and will attempt
> the same thing locally.

Is freemarker really this stupid?  Really?  That line is:

shipmentRouteSegments=delegator.findByAnd("ShipmentRouteSegment",
{"shipmentId" : shipment.shipmentId}, null, false) [on line 581,
column 25 in
component://order/webapp/ordermgr/order/ordershippinginfo.ftl]

And there *is* a findByAnd in Delegator that has (String, Map, List,
boolean).  Why is thinking that findByAnd(String, Object...) is the
correct one to use?  I'm leaning towards this being a freemarker bug.

If one other person agrees with me, then I'll attempt to simulate it
as a real freemark bug(new freemarker template, new object that
implements similiar interfaces, isolated from any/all ofbiz code), to
make reporting a freemark bug simpler.  And then fix freemarker myself.

Re: Errors in screen while running findByAnd

[Adam Heath]

On 05/16/2012 06:41 AM, Jacopo Cappellato wrote:
> https://demo-trunk.ofbiz.apache.org/ordermgr/control/orderview?orderId=Demo1002

This may be a stupid question, but why doesn't "admin/ofbiz" work as a
login?  (right now, the admin account is disabled for 5 minutes,
that's my fault).

I can't yet see this error.  I'm updating to trunk, and will attempt
the same thing locally.

use of UtilMisc.to(Map|List) in groovy and ftl

[Adam Heath]

==
find -name '*.groovy' -printf '%P\n'|xargs egrep
"UtilMisc\.(toList|toMap)"|wc -l
197
find -name '*.ftl' -printf '%P\n'|xargs egrep
"Static\\[[\"']org.ofbiz.base.util.UtilMisc[\"']\\]\.(toList|toMap)"|wc -l
132
==

There is no reason to use toMap or toList in groovy or ftl files.
Both languages have native markup for maps and lists.

groovy:

map -> [plainKey: variable]
list -> [value, value]

ftl:

map -> {"plainKey": variable]
list -> [value, value]

I'm not completely certain about the ftl list syntax.  What is
annoying is that in a single ftl file, I see the native map syntax,
*and* UtilMisc.toMap.

Does anyone want to fix these?  It'd be a good way for someone to get
their feet wet with the code.  I use these kinds of changes as a way
to do a code review.

[jira] [Commented] (OFBIZ-4865) Exception there when trying to update order's "Shipping Destination Address"

[Leon (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13276800#comment-13276800
 ] 

Leon commented on OFBIZ-4865:
-

Adrian,  Sorry for that. This one is correct.

> Exception there when trying to update order's "Shipping Destination Address"
> 
>
> Key: OFBIZ-4865
> URL: https://issues.apache.org/jira/browse/OFBIZ-4865
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: SVN trunk
>Reporter: Leon
> Attachments: OFBIZ-4865.patch
>
>
> If click the "update" button of "Shipping Destination Address" in order view 
> page, an exception thrown out as:
> {quote}
> The Following Errors Occurred:
> BeanShell execution caused an error: Sourced file: inline evaluation of: `` 
> shipmentMethod = parameters.get("shipmentMethod"); if(s . . . ''
> {quote}
> I'm not familiar with beanshell and the mechanism of how ofbiz handling it, 
> but I'm sure that there'no such error days ago.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4865) Exception there when trying to update order's "Shipping Destination Address"

[Leon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leon updated OFBIZ-4865:


Attachment: OFBIZ-4865.patch

> Exception there when trying to update order's "Shipping Destination Address"
> 
>
> Key: OFBIZ-4865
> URL: https://issues.apache.org/jira/browse/OFBIZ-4865
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: SVN trunk
>Reporter: Leon
> Attachments: OFBIZ-4865.patch
>
>
> If click the "update" button of "Shipping Destination Address" in order view 
> page, an exception thrown out as:
> {quote}
> The Following Errors Occurred:
> BeanShell execution caused an error: Sourced file: inline evaluation of: `` 
> shipmentMethod = parameters.get("shipmentMethod"); if(s . . . ''
> {quote}
> I'm not familiar with beanshell and the mechanism of how ofbiz handling it, 
> but I'm sure that there'no such error days ago.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4865) Exception there when trying to update order's "Shipping Destination Address"

[Leon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leon updated OFBIZ-4865:


Attachment: (was: OFBIZ-4856.patch)

> Exception there when trying to update order's "Shipping Destination Address"
> 
>
> Key: OFBIZ-4865
> URL: https://issues.apache.org/jira/browse/OFBIZ-4865
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: SVN trunk
>Reporter: Leon
> Attachments: OFBIZ-4865.patch
>
>
> If click the "update" button of "Shipping Destination Address" in order view 
> page, an exception thrown out as:
> {quote}
> The Following Errors Occurred:
> BeanShell execution caused an error: Sourced file: inline evaluation of: `` 
> shipmentMethod = parameters.get("shipmentMethod"); if(s . . . ''
> {quote}
> I'm not familiar with beanshell and the mechanism of how ofbiz handling it, 
> but I'm sure that there'no such error days ago.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: svn commit: r1328356 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/util/GroovyUtil.java

[Jacopo Cappellato]

Adam, all,

I am resurrecting this part of the thread: is it ok if we fix the 10.04 with 
the patch below (Adam's commit with rev. 948333 that adds the putIfAbsent 
method and then the same fix I committed to 11.04, 12.04 and trunk)?

Thanks,

Jacopo

On May 12, 2012, at 9:17 AM, Jacopo Cappellato wrote:

> As regards the 10.04, what if we backport the putIfAbsent method there and 
> then apply a similar fix? Here is the patch I would like to backport:
> 
> Index: framework/base/src/org/ofbiz/base/util/cache/test/UtilCacheTests.java
> ===
> --- framework/base/src/org/ofbiz/base/util/cache/test/UtilCacheTests.java 
> (revision 1337449)
> +++ framework/base/src/org/ofbiz/base/util/cache/test/UtilCacheTests.java 
> (working copy)
> @@ -323,6 +323,19 @@
> basicTest(cache);
> }
> 
> +public void testPutIfAbsent() throws Exception {
> +UtilCache cache = createUtilCache(5, 5, 2000, false, 
> false);
> +Listener gotListener = createListener(cache);
> +Listener wantedListener = new Listener String>();
> +wantedListener.noteKeyAddition(cache, "two", "dos");
> +assertNull("putIfAbsent", cache.putIfAbsent("two", "dos"));
> +assertHasSingleKey(cache, "two", "dos");
> +assertEquals("putIfAbsent", "dos", cache.putIfAbsent("two", 
> "double"));
> +assertHasSingleKey(cache, "two", "dos");
> +cache.removeListener(gotListener);
> +assertEquals("listener", wantedListener, gotListener);
> +}
> +
> public void testChangeMemSize() throws Exception {
> int size = 5;
> long ttl = 2000;
> Index: framework/base/src/org/ofbiz/base/util/cache/UtilCache.java
> ===
> --- framework/base/src/org/ofbiz/base/util/cache/UtilCache.java   
> (revision 1337449)
> +++ framework/base/src/org/ofbiz/base/util/cache/UtilCache.java   
> (working copy)
> @@ -289,6 +289,10 @@
> return putInternal(key, value, expireTimeNanos);
> }
> 
> +public V putIfAbsent(K key, V value) {
> +return putIfAbsentInternal(key, value, expireTimeNanos);
> +}
> +
> CacheLine createSoftRefCacheLine(final Object key, V value, long 
> loadTimeNanos, long expireTimeNanos) {
> return tryRegister(loadTimeNanos, new SoftRefCacheLine(value, 
> loadTimeNanos, expireTimeNanos) {
> @Override
> @@ -366,6 +370,10 @@
> return putInternal(key, value, 
> TimeUnit.NANOSECONDS.convert(expireTimeMillis, TimeUnit.MILLISECONDS));
> }
> 
> +public V putIfAbsent(K key, V value, long expireTimeMillis) {
> +return putIfAbsentInternal(key, value, 
> TimeUnit.NANOSECONDS.convert(expireTimeMillis, TimeUnit.MILLISECONDS));
> +}
> +
> V putInternal(K key, V value, long expireTimeNanos) {
> Object nulledKey = fromKey(key);
> CacheLine oldCacheLine = memoryTable.put(nulledKey, 
> createCacheLine(key, value, expireTimeNanos));
> @@ -388,6 +396,41 @@
> }
> }
> 
> +V putIfAbsentInternal(K key, V value, long expireTimeNanos) {
> +Object nulledKey = fromKey(key);
> +V oldValue;
> +if (fileTable != null) {
> +try {
> +synchronized (this) {
> +oldValue = fileTable.get(nulledKey);
> +if (oldValue == null) {
> +memoryTable.put(nulledKey, createCacheLine(key, 
> value, expireTimeNanos));
> +fileTable.put(nulledKey, value);
> +jdbmMgr.commit();
> +}
> +}
> +} catch (IOException e) {
> +Debug.logError(e, module);
> +oldValue = null;
> +}
> +} else {
> +CacheLine newCacheLine = createCacheLine(key, value, 
> expireTimeNanos);
> +CacheLine oldCacheLine = memoryTable.putIfAbsent(nulledKey, 
> newCacheLine);
> +if (oldCacheLine == null) {
> +oldValue = null;
> +} else {
> +oldValue = oldCacheLine.getValue();
> +cancel(newCacheLine);
> +}
> +}
> +if (oldValue == null) {
> +noteAddition(key, value);
> +return null;
> +} else {
> +return oldValue;
> +}
> +}
> +
> /** Gets an element from the cache according to the specified key.
>  * @param key The key for the element, used to reference it in the 
> hastables and LRU linked list
>  * @return The value of the element specified by the key
> Index: framework/base/src/org/ofbiz/base/util/GroovyUtil.java
> ===
> --- framework/base/src/org/ofbiz/base/util/GroovyUtil.java(revision 
> 1337449)
> +++ framework/base/src/org/ofbiz/base/util/GroovyUtil.java(working copy)
> @@ -102,26 +102,20 @@

[jira] [Commented] (OFBIZ-4865) Exception there when trying to update order's "Shipping Destination Address"

[Adrian Crum (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13276744#comment-13276744
 ] 

Adrian Crum commented on OFBIZ-4865:


Leon - I think you attached the wrong patch file.

> Exception there when trying to update order's "Shipping Destination Address"
> 
>
> Key: OFBIZ-4865
> URL: https://issues.apache.org/jira/browse/OFBIZ-4865
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: SVN trunk
>Reporter: Leon
> Attachments: OFBIZ-4856.patch
>
>
> If click the "update" button of "Shipping Destination Address" in order view 
> page, an exception thrown out as:
> {quote}
> The Following Errors Occurred:
> BeanShell execution caused an error: Sourced file: inline evaluation of: `` 
> shipmentMethod = parameters.get("shipmentMethod"); if(s . . . ''
> {quote}
> I'm not familiar with beanshell and the mechanism of how ofbiz handling it, 
> but I'm sure that there'no such error days ago.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4865) Exception there when trying to update order's "Shipping Destination Address"

[Leon (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13276739#comment-13276739
 ] 

Leon commented on OFBIZ-4865:
-

I searched the log and find the root cause is 
"java.lang.ArrayIndexOutOfBoundsException" from bsh script. As Paul told, there 
should be at least two "@" chars in "shipmentmethod" value. So I guess maybe 
somewhere "@" is missing. I tried to lookup for codes which construct 
parameters map for calling, and fortunately, I found it.

See attached patch for detail.

Thanks you all.

> Exception there when trying to update order's "Shipping Destination Address"
> 
>
> Key: OFBIZ-4865
> URL: https://issues.apache.org/jira/browse/OFBIZ-4865
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: SVN trunk
>Reporter: Leon
> Attachments: OFBIZ-4856.patch
>
>
> If click the "update" button of "Shipping Destination Address" in order view 
> page, an exception thrown out as:
> {quote}
> The Following Errors Occurred:
> BeanShell execution caused an error: Sourced file: inline evaluation of: `` 
> shipmentMethod = parameters.get("shipmentMethod"); if(s . . . ''
> {quote}
> I'm not familiar with beanshell and the mechanism of how ofbiz handling it, 
> but I'm sure that there'no such error days ago.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4865) Exception there when trying to update order's "Shipping Destination Address"

[Leon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leon updated OFBIZ-4865:


Attachment: OFBIZ-4856.patch

> Exception there when trying to update order's "Shipping Destination Address"
> 
>
> Key: OFBIZ-4865
> URL: https://issues.apache.org/jira/browse/OFBIZ-4865
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: SVN trunk
>Reporter: Leon
> Attachments: OFBIZ-4856.patch
>
>
> If click the "update" button of "Shipping Destination Address" in order view 
> page, an exception thrown out as:
> {quote}
> The Following Errors Occurred:
> BeanShell execution caused an error: Sourced file: inline evaluation of: `` 
> shipmentMethod = parameters.get("shipmentMethod"); if(s . . . ''
> {quote}
> I'm not familiar with beanshell and the mechanism of how ofbiz handling it, 
> but I'm sure that there'no such error days ago.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4814) eCommerce Profile Back Button Fail

[Sebastian Leitner (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13276732#comment-13276732
 ] 

Sebastian Leitner commented on OFBIZ-4814:
--

Hi Jacques,

sorry for the typo. I saw it the second after i pressed the send button ;)

I didn't test the (whole) specialpurpose/ecommerce, but we extend the 
controller.xml in our own module and use this request. This is not a big deal, 
I simply copied this request to our own controller. I just wanted to mention, 
that this _could_ cause problems and for backward compatability I would suggest 
to leave this feature there, even if not used there any more.

> eCommerce Profile Back Button Fail
> --
>
> Key: OFBIZ-4814
> URL: https://issues.apache.org/jira/browse/OFBIZ-4814
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/ecommerce
>Affects Versions: SVN trunk
> Environment: demo-trunk
>Reporter: Tom Burns
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk
>
> Attachments: OFBIZ-4814 eCommerce Profile GoBack Branch.patch, 
> OFBIZ-4814 eCommerce Profile GoBack Trunk.patch, OFBIZ-4814 eCommerce Profile 
> GoBack.patch
>
>
> 1. Some navigation buttons reached from the eCommerce Profile screen fail to 
> return to the Profile screen.
> Example:
> Login as DemoCustomer
> Click Profile
> Click Update In the "Contact Information" > "Postal Address" section.
> Click Go Back
> Expected: Return to profile page
> Actual: Remain on Edit Contact Information page
> 2. Naming and display of back buttons is inconsistent across Profile Editing 
> screens.
> Example:
> Changes Password label should be "Go Back" but is "[Go Back]"
> 3. Create New Postal Address fails from OFBIZ-4801 Rev 1326397
> Error message
> State/Province --  
> Selected\Expected State Name = Expression selectedStateName is undefined on 
> line 163, column 42 in 
> component://ecommerce/webapp/ecommerce/customer/editcontactmech.ftl. The 
> problematic instruction: -- ==> ${selectedStateName} [on line 163,
> 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4881) Possible Freemarker error in ordershippinginfo.ftl

[Sebastian Leitner (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebastian Leitner updated OFBIZ-4881:
-

Attachment: ordershippinginfo.ftl.patch

> Possible Freemarker error in ordershippinginfo.ftl
> --
>
> Key: OFBIZ-4881
> URL: https://issues.apache.org/jira/browse/OFBIZ-4881
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Reporter: Sebastian Leitner
>Priority: Trivial
> Fix For: SVN trunk
>
> Attachments: ordershippinginfo.ftl.patch
>
>
> If the shipgroup does not have a carrierPartyId (which is the case, if an 
> order does not need shipping and its shipping method is _NA_), there is an 
> FTL-error.
> I will attach a fix for this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OFBIZ-4881) Possible Freemarker error in ordershippinginfo.ftl

[Sebastian Leitner (JIRA)]

Sebastian Leitner created OFBIZ-4881:


 Summary: Possible Freemarker error in ordershippinginfo.ftl
 Key: OFBIZ-4881
 URL: https://issues.apache.org/jira/browse/OFBIZ-4881
 Project: OFBiz
  Issue Type: Bug
  Components: order
Reporter: Sebastian Leitner
Priority: Trivial
 Fix For: SVN trunk


If the shipgroup does not have a carrierPartyId (which is the case, if an order 
does not need shipping and its shipping method is _NA_), there is an FTL-error.
I will attach a fix for this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: CommonEmptyHeader

[Jacques Le Roux]

From: "Christian Geisert" 

Adrian Crum schrieb:

On 5/16/2012 12:17 PM, Christian Geisert wrote:

Adrian Crum schrieb:

On 5/16/2012 11:44 AM, Christian Geisert wrote:

What's the point of CommonEmptyHeader?

It's definied in CommonUiLabels.xml as:


  
 


It is just a simple space (0x20)

It is used ~500 times in forms as a title in a field definition

Example:



  




This is a button which should have no label, but if the title attribute
is empty then the name attribute is used as label.

Why not just put a space (" ") into the title attribute - still a hack,
but exactly same result a using CommonEmptyHeader without the need
using
CommonEmptyHeader.

The real solution is of course not to display a label if the title
attribute is empty.

An empty title attribute is meant to be a shortcut, or a developer's
convenience - the widgets will use the field name to look up the correct
label.

Ah, ok that's this FormFieldTitle_ stuff (which I don't like and use ;-)
  - IMHO it is bad for re-using labels...)


Putting a space in the title attribute is the only way to turn off the
default behavior.

Ok, so there is nothing against replacing
"${uiLabelMap.CommonEmptyHeader}" with " "?



That is what we would like to do - but it doesn't work. That is what
needs to be fixed.


But if I do this in the above mentioned example (see attached patch) it
seems to give the expected result (= no label). I'm a missing something?

Christian



Maybe something has changed and this works without Scott's suggested change (if 
it works) now?
BTW I checked, I thought I was using CommonEmptyHeader in another way, than simply form title ,in a custom project, but I was wrong. 
So one of the solutions proposed is ok with me, the simpler the better


Jacques







Index: applications/party/widget/partymgr/PartyForms.xml
===
--- applications/party/widget/partymgr/PartyForms.xml (Revision 1339064)
+++ applications/party/widget/partymgr/PartyForms.xml (Arbeitskopie)
@@ -90,7 +90,7 @@



-
+

Re: CommonEmptyHeader

[Adrian Crum]

On 5/16/2012 12:33 PM, Christian Geisert wrote:

Adrian Crum schrieb:

On 5/16/2012 12:17 PM, Christian Geisert wrote:

Adrian Crum schrieb:

On 5/16/2012 11:44 AM, Christian Geisert wrote:

What's the point of CommonEmptyHeader?

It's definied in CommonUiLabels.xml as:


   
   


It is just a simple space (0x20)

It is used ~500 times in forms as a title in a field definition

Example:


 
   
 



This is a button which should have no label, but if the title attribute
is empty then the name attribute is used as label.

Why not just put a space (" ") into the title attribute - still a hack,
but exactly same result a using CommonEmptyHeader without the need
using
CommonEmptyHeader.

The real solution is of course not to display a label if the title
attribute is empty.

An empty title attribute is meant to be a shortcut, or a developer's
convenience - the widgets will use the field name to look up the correct
label.

Ah, ok that's this FormFieldTitle_ stuff (which I don't like and use ;-)
   - IMHO it is bad for re-using labels...)


Putting a space in the title attribute is the only way to turn off the
default behavior.

Ok, so there is nothing against replacing
"${uiLabelMap.CommonEmptyHeader}" with " "?


That is what we would like to do - but it doesn't work. That is what
needs to be fixed.

But if I do this in the above mentioned example (see attached patch) it
seems to give the expected result (= no label). I'm a missing something?


Most likely I am missing something. The last time I checked it didn't 
work - but that was a long time ago. Maybe it has been fixed since then.


-Adrian

Re: CommonEmptyHeader

[Christian Geisert]

Adrian Crum schrieb:
> On 5/16/2012 12:17 PM, Christian Geisert wrote:
>> Adrian Crum schrieb:
>>> On 5/16/2012 11:44 AM, Christian Geisert wrote:
 What's the point of CommonEmptyHeader?

 It's definied in CommonUiLabels.xml as:

 
   
  
 

 It is just a simple space (0x20)

 It is used ~500 times in forms as a title in a field definition

 Example:

 >>> ...
 >>>
   >>> description="${uiLabelMap.CommonCancelDone}">
 
   
 
 


 This is a button which should have no label, but if the title attribute
 is empty then the name attribute is used as label.

 Why not just put a space (" ") into the title attribute - still a hack,
 but exactly same result a using CommonEmptyHeader without the need
 using
 CommonEmptyHeader.

 The real solution is of course not to display a label if the title
 attribute is empty.
>>> An empty title attribute is meant to be a shortcut, or a developer's
>>> convenience - the widgets will use the field name to look up the correct
>>> label.
>> Ah, ok that's this FormFieldTitle_ stuff (which I don't like and use ;-)
>>   - IMHO it is bad for re-using labels...)
>>
>>> Putting a space in the title attribute is the only way to turn off the
>>> default behavior.
>> Ok, so there is nothing against replacing
>> "${uiLabelMap.CommonEmptyHeader}" with " "?
>>
> 
> That is what we would like to do - but it doesn't work. That is what
> needs to be fixed.

But if I do this in the above mentioned example (see attached patch) it
seems to give the expected result (= no label). I'm a missing something?

Christian

Index: applications/party/widget/partymgr/PartyForms.xml
===
--- applications/party/widget/partymgr/PartyForms.xml	(Revision 1339064)
+++ applications/party/widget/partymgr/PartyForms.xml	(Arbeitskopie)
@@ -90,7 +90,7 @@
 
 
 
-
+
 
 
 

[jira] [Resolved] (OFBIZ-4876) missing form product/widget/catalog/ImageManagementForms.xml#productImageReplace

[Erwan de FERRIERES (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erwan de FERRIERES resolved OFBIZ-4876.
---

   Resolution: Fixed
Fix Version/s: SVN trunk

done at rev 1339122
Thanks Wai for reporting

> missing form 
> product/widget/catalog/ImageManagementForms.xml#productImageReplace
> 
>
> Key: OFBIZ-4876
> URL: https://issues.apache.org/jira/browse/OFBIZ-4876
> Project: OFBiz
>  Issue Type: Bug
>  Components: product
>Affects Versions: SVN trunk
>Reporter: Wai
>Assignee: Erwan de FERRIERES
> Fix For: SVN trunk
>
>
> product/widget/catalog/ImageManagementScreens.xml#ListImageReplace# is not 
> defined.
> Hence, under certain condition when productId is not available or become 
> lost, the following error occurs.
> :ERROR MESSAGE:
> org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen 
> [component://common/widget/CommonScreens.xml#GlobalDecorator]: 
> java.lang.RuntimeException: Error rendering included form named 
> [productImageReplace] at location 
> [component://product/widget/catalog/ImageManagementForms.xml]: 
> java.lang.NullPointerException (Error rendering included form named 
> [productImageReplace] at location 
> [component://product/widget/catalog/ImageManagementForms.xml]: 
> java.lang.NullPointerException)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: CommonEmptyHeader

[Scott Gray]

On 16/05/2012, at 11:27 PM, Scott Gray wrote:

> On 16/05/2012, at 11:21 PM, Adrian Crum wrote:
> 
>> On 5/16/2012 12:17 PM, Christian Geisert wrote:
>>> Adrian Crum schrieb:
 On 5/16/2012 11:44 AM, Christian Geisert wrote:
> What's the point of CommonEmptyHeader?
> 
> It's definied in CommonUiLabels.xml as:
> 
> 
> 
>
> 
> 
> It is just a simple space (0x20)
> 
> It is used ~500 times in forms as a title in a field definition
> 
> Example:
> 
>    ...
>    
>    description="${uiLabelMap.CommonCancelDone}">
>   
> 
>   
> 
> 
> 
> This is a button which should have no label, but if the title attribute
> is empty then the name attribute is used as label.
> 
> Why not just put a space (" ") into the title attribute - still a hack,
> but exactly same result a using CommonEmptyHeader without the need using
> CommonEmptyHeader.
> 
> The real solution is of course not to display a label if the title
> attribute is empty.
 An empty title attribute is meant to be a shortcut, or a developer's
 convenience - the widgets will use the field name to look up the correct
 label.
>>> Ah, ok that's this FormFieldTitle_ stuff (which I don't like and use ;-)
>>> - IMHO it is bad for re-using labels...)
>>> 
 Putting a space in the title attribute is the only way to turn off the
 default behavior.
>>> Ok, so there is nothing against replacing
>>> "${uiLabelMap.CommonEmptyHeader}" with " "?
>>> 
>> 
>> That is what we would like to do - but it doesn't work. That is what needs 
>> to be fixed.
>> 
>> -Adrian
> 
> Does element.hasAttribute really return false if an attribute exists with an 
> empty value?  You'd think the javadoc would call that out since it defies 
> common sense.
> 
> Regards
> Scott


If it does actually return true then we could just change this:
if (UtilValidate.isNotEmpty(this.title)) return title.expandString(context);
to this:
if (this.title != null) return title.expandString(context);

[jira] [Assigned] (OFBIZ-4876) missing form product/widget/catalog/ImageManagementForms.xml#productImageReplace

[Erwan de FERRIERES (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erwan de FERRIERES reassigned OFBIZ-4876:
-

Assignee: Erwan de FERRIERES

> missing form 
> product/widget/catalog/ImageManagementForms.xml#productImageReplace
> 
>
> Key: OFBIZ-4876
> URL: https://issues.apache.org/jira/browse/OFBIZ-4876
> Project: OFBiz
>  Issue Type: Bug
>  Components: product
>Affects Versions: SVN trunk
>Reporter: Wai
>Assignee: Erwan de FERRIERES
>
> product/widget/catalog/ImageManagementScreens.xml#ListImageReplace# is not 
> defined.
> Hence, under certain condition when productId is not available or become 
> lost, the following error occurs.
> :ERROR MESSAGE:
> org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen 
> [component://common/widget/CommonScreens.xml#GlobalDecorator]: 
> java.lang.RuntimeException: Error rendering included form named 
> [productImageReplace] at location 
> [component://product/widget/catalog/ImageManagementForms.xml]: 
> java.lang.NullPointerException (Error rendering included form named 
> [productImageReplace] at location 
> [component://product/widget/catalog/ImageManagementForms.xml]: 
> java.lang.NullPointerException)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: CommonEmptyHeader

[Scott Gray]

On 16/05/2012, at 11:21 PM, Adrian Crum wrote:

> On 5/16/2012 12:17 PM, Christian Geisert wrote:
>> Adrian Crum schrieb:
>>> On 5/16/2012 11:44 AM, Christian Geisert wrote:
 What's the point of CommonEmptyHeader?
 
 It's definied in CommonUiLabels.xml as:
 
 
  
 
 
 
 It is just a simple space (0x20)
 
 It is used ~500 times in forms as a title in a field definition
 
 Example:
 
 >>>...
>>> 
  >>>description="${uiLabelMap.CommonCancelDone}">

  

 
 
 
 This is a button which should have no label, but if the title attribute
 is empty then the name attribute is used as label.
 
 Why not just put a space (" ") into the title attribute - still a hack,
 but exactly same result a using CommonEmptyHeader without the need using
 CommonEmptyHeader.
 
 The real solution is of course not to display a label if the title
 attribute is empty.
>>> An empty title attribute is meant to be a shortcut, or a developer's
>>> convenience - the widgets will use the field name to look up the correct
>>> label.
>> Ah, ok that's this FormFieldTitle_ stuff (which I don't like and use ;-)
>>  - IMHO it is bad for re-using labels...)
>> 
>>> Putting a space in the title attribute is the only way to turn off the
>>> default behavior.
>> Ok, so there is nothing against replacing
>> "${uiLabelMap.CommonEmptyHeader}" with " "?
>> 
> 
> That is what we would like to do - but it doesn't work. That is what needs to 
> be fixed.
> 
> -Adrian

Does element.hasAttribute really return false if an attribute exists with an 
empty value?  You'd think the javadoc would call that out since it defies 
common sense.

Regards
Scott

Re: CommonEmptyHeader

[Adrian Crum]

On 5/16/2012 12:17 PM, Christian Geisert wrote:

Adrian Crum schrieb:

On 5/16/2012 11:44 AM, Christian Geisert wrote:

What's the point of CommonEmptyHeader?

It's definied in CommonUiLabels.xml as:


  
 


It is just a simple space (0x20)

It is used ~500 times in forms as a title in a field definition

Example:



  




This is a button which should have no label, but if the title attribute
is empty then the name attribute is used as label.

Why not just put a space (" ") into the title attribute - still a hack,
but exactly same result a using CommonEmptyHeader without the need using
CommonEmptyHeader.

The real solution is of course not to display a label if the title
attribute is empty.

An empty title attribute is meant to be a shortcut, or a developer's
convenience - the widgets will use the field name to look up the correct
label.

Ah, ok that's this FormFieldTitle_ stuff (which I don't like and use ;-)
  - IMHO it is bad for re-using labels...)


Putting a space in the title attribute is the only way to turn off the
default behavior.

Ok, so there is nothing against replacing
"${uiLabelMap.CommonEmptyHeader}" with " "?



That is what we would like to do - but it doesn't work. That is what 
needs to be fixed.


-Adrian

[jira] [Commented] (OFBIZ-4852) Improper layout for ebay store product listing

[Erwan de FERRIERES (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13276663#comment-13276663
 ] 

Erwan de FERRIERES commented on OFBIZ-4852:
---

Hi Wai,

could be please attach screenshots and explain what's wrong ?

Thanks,

> Improper layout for ebay store product listing
> --
>
> Key: OFBIZ-4852
> URL: https://issues.apache.org/jira/browse/OFBIZ-4852
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/ebaystore
>Affects Versions: SVN trunk
>Reporter: Wai
>
> Improper layout of category listing in 
> http://demo-trunk.ofbiz.apache.org/ebaystore/control/exportProductListing
> Bizzness theme is ok
> Bluelight theme is not ok
> DroppingCrumbs theme is not ok
> FlatGrey theme is not ok
> Tomahawk theme is not ok

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: CommonEmptyHeader

[Christian Geisert]

Adrian Crum schrieb:
> On 5/16/2012 11:44 AM, Christian Geisert wrote:
>> What's the point of CommonEmptyHeader?
>>
>> It's definied in CommonUiLabels.xml as:
>>
>> 
>>  
>>
>> 
>>
>> It is just a simple space (0x20)
>>
>> It is used ~500 times in forms as a title in a field definition
>>
>> Example:
>>
>> >...
>>>
>>  >description="${uiLabelMap.CommonCancelDone}">
>>
>>  
>>
>> 
>>
>>
>> This is a button which should have no label, but if the title attribute
>> is empty then the name attribute is used as label.
>>
>> Why not just put a space (" ") into the title attribute - still a hack,
>> but exactly same result a using CommonEmptyHeader without the need using
>> CommonEmptyHeader.
>>
>> The real solution is of course not to display a label if the title
>> attribute is empty.
> 
> An empty title attribute is meant to be a shortcut, or a developer's
> convenience - the widgets will use the field name to look up the correct
> label.

Ah, ok that's this FormFieldTitle_ stuff (which I don't like and use ;-)
 - IMHO it is bad for re-using labels...)

> Putting a space in the title attribute is the only way to turn off the
> default behavior.

Ok, so there is nothing against replacing
"${uiLabelMap.CommonEmptyHeader}" with " "?

Christian

[jira] [Updated] (OFBIZ-4878) Remove Survey Question Option not working.

[Harsha Chadhar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Harsha Chadhar updated OFBIZ-4878:
--

Attachment: OFBIZ-4878.patch

> Remove Survey Question Option not working.
> --
>
> Key: OFBIZ-4878
> URL: https://issues.apache.org/jira/browse/OFBIZ-4878
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: content
>Affects Versions: Release 10.04, Release Branch 11.04, SVN trunk, Release 
> Branch 12.04
>Reporter: Harsha Chadhar
> Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk, 
> Release Branch 12.04
>
> Attachments: OFBIZ-4878.patch
>
>
> On trying to delete/remove Survey Question Options for Survey Question Type= 
> Selected Option, the following error is occurred :
> Url : 
> https://demo-trunk.ofbiz.apache.org:8443/content/control/removeSurveyQuestionAppl?surveyId=1501&surveyQuestionId=1&surveyOptionSeqId=1
>  
> Error calling event: org.ofbiz.webapp.event.EventHandlerException: Found URL 
> parameter [surveyId] passed to secure (https) request-map with uri 
> [removeSurveyQuestionAppl] with an event that calls service 
> [deleteSurveyQuestionAppl]; this is not allowed for security reasons! The 
> data should be encrypted by making it part of the request body (a form field) 
> instead of the request URL. Moreover it would be kind if you could create a 
> Jira sub-task of https://issues.apache.org/jira/browse/OFBIZ-2330 (check 
> before if a sub-task for this error does not exist). If you are not sure how 
> to create a Jira issue please have a look before at 
> http://cwiki.apache.org/confluence/x/JIB2 Thank you in advance for your help.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4878) Remove Survey Question Option not working.

[Harsha Chadhar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Harsha Chadhar updated OFBIZ-4878:
--

Attachment: (was: OFBIZ-4878.patch)

> Remove Survey Question Option not working.
> --
>
> Key: OFBIZ-4878
> URL: https://issues.apache.org/jira/browse/OFBIZ-4878
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: content
>Affects Versions: Release 10.04, Release Branch 11.04, SVN trunk, Release 
> Branch 12.04
>Reporter: Harsha Chadhar
> Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk, 
> Release Branch 12.04
>
>
> On trying to delete/remove Survey Question Options for Survey Question Type= 
> Selected Option, the following error is occurred :
> Url : 
> https://demo-trunk.ofbiz.apache.org:8443/content/control/removeSurveyQuestionAppl?surveyId=1501&surveyQuestionId=1&surveyOptionSeqId=1
>  
> Error calling event: org.ofbiz.webapp.event.EventHandlerException: Found URL 
> parameter [surveyId] passed to secure (https) request-map with uri 
> [removeSurveyQuestionAppl] with an event that calls service 
> [deleteSurveyQuestionAppl]; this is not allowed for security reasons! The 
> data should be encrypted by making it part of the request body (a form field) 
> instead of the request URL. Moreover it would be kind if you could create a 
> Jira sub-task of https://issues.apache.org/jira/browse/OFBIZ-2330 (check 
> before if a sub-task for this error does not exist). If you are not sure how 
> to create a Jira issue please have a look before at 
> http://cwiki.apache.org/confluence/x/JIB2 Thank you in advance for your help.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4878) Remove Survey Question Option not working.

[Harsha Chadhar (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13276657#comment-13276657
 ] 

Harsha Chadhar commented on OFBIZ-4878:
---

Please refer to the patch attached. This issue is dependent on issue number 
OFBIZ-2959.

> Remove Survey Question Option not working.
> --
>
> Key: OFBIZ-4878
> URL: https://issues.apache.org/jira/browse/OFBIZ-4878
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: content
>Affects Versions: Release 10.04, Release Branch 11.04, SVN trunk, Release 
> Branch 12.04
>Reporter: Harsha Chadhar
> Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk, 
> Release Branch 12.04
>
> Attachments: OFBIZ-4878.patch
>
>
> On trying to delete/remove Survey Question Options for Survey Question Type= 
> Selected Option, the following error is occurred :
> Url : 
> https://demo-trunk.ofbiz.apache.org:8443/content/control/removeSurveyQuestionAppl?surveyId=1501&surveyQuestionId=1&surveyOptionSeqId=1
>  
> Error calling event: org.ofbiz.webapp.event.EventHandlerException: Found URL 
> parameter [surveyId] passed to secure (https) request-map with uri 
> [removeSurveyQuestionAppl] with an event that calls service 
> [deleteSurveyQuestionAppl]; this is not allowed for security reasons! The 
> data should be encrypted by making it part of the request body (a form field) 
> instead of the request URL. Moreover it would be kind if you could create a 
> Jira sub-task of https://issues.apache.org/jira/browse/OFBIZ-2330 (check 
> before if a sub-task for this error does not exist). If you are not sure how 
> to create a Jira issue please have a look before at 
> http://cwiki.apache.org/confluence/x/JIB2 Thank you in advance for your help.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4878) Remove Survey Question Option not working.

[Harsha Chadhar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Harsha Chadhar updated OFBIZ-4878:
--

Attachment: OFBIZ-4878.patch

> Remove Survey Question Option not working.
> --
>
> Key: OFBIZ-4878
> URL: https://issues.apache.org/jira/browse/OFBIZ-4878
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: content
>Affects Versions: Release 10.04, Release Branch 11.04, SVN trunk, Release 
> Branch 12.04
>Reporter: Harsha Chadhar
> Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk, 
> Release Branch 12.04
>
> Attachments: OFBIZ-4878.patch
>
>
> On trying to delete/remove Survey Question Options for Survey Question Type= 
> Selected Option, the following error is occurred :
> Url : 
> https://demo-trunk.ofbiz.apache.org:8443/content/control/removeSurveyQuestionAppl?surveyId=1501&surveyQuestionId=1&surveyOptionSeqId=1
>  
> Error calling event: org.ofbiz.webapp.event.EventHandlerException: Found URL 
> parameter [surveyId] passed to secure (https) request-map with uri 
> [removeSurveyQuestionAppl] with an event that calls service 
> [deleteSurveyQuestionAppl]; this is not allowed for security reasons! The 
> data should be encrypted by making it part of the request body (a form field) 
> instead of the request URL. Moreover it would be kind if you could create a 
> Jira sub-task of https://issues.apache.org/jira/browse/OFBIZ-2330 (check 
> before if a sub-task for this error does not exist). If you are not sure how 
> to create a Jira issue please have a look before at 
> http://cwiki.apache.org/confluence/x/JIB2 Thank you in advance for your help.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: CommonEmptyHeader

[Adrian Crum]

On 5/16/2012 11:44 AM, Christian Geisert wrote:

What's the point of CommonEmptyHeader?

It's definied in CommonUiLabels.xml as:


 
   


It is just a simple space (0x20)

It is used ~500 times in forms as a title in a field definition

Example:


   
 
   



This is a button which should have no label, but if the title attribute
is empty then the name attribute is used as label.

Why not just put a space (" ") into the title attribute - still a hack,
but exactly same result a using CommonEmptyHeader without the need using
CommonEmptyHeader.

The real solution is of course not to display a label if the title
attribute is empty.


An empty title attribute is meant to be a shortcut, or a developer's 
convenience - the widgets will use the field name to look up the correct 
label.


Putting a space in the title attribute is the only way to turn off the 
default behavior.


-Adrian

CommonEmptyHeader (was: Re: svn commit: r1338836 - in /ofbiz/branches/release12.04: ./ framework/base/dtd/ framework/base/src/org/ofbiz/base/util/ framework/common/config/ framework/webtools/src/org/o

[Christian Geisert]

What's the point of CommonEmptyHeader?

It's definied in CommonUiLabels.xml as:



 


It is just a simple space (0x20)

It is used ~500 times in forms as a title in a field definition

Example:


  

  



This is a button which should have no label, but if the title attribute
is empty then the name attribute is used as label.

Why not just put a space (" ") into the title attribute - still a hack,
but exactly same result a using CommonEmptyHeader without the need using
CommonEmptyHeader.

The real solution is of course not to display a label if the title
attribute is empty.

Christian

Adrian Crum schrieb:
> The bad thing about this change is that it is not necessary. This change
> hides a problem - it does not solve it. I mentioned that in the Jira issue.
> 
> The method is supposed to pretty-print an XML document, and if you turn
> off space removal, the indentation will be wrong. In other words, it
> will not be pretty.
> 
> -1 on this change in any version.
> 
> -Adrian
> 
> On 5/16/2012 2:25 AM, Scott Gray wrote:
>> I see in your subsequent commits that you encountered the problems
>> caused by this type of change.
>>
>> They're also a pretty good indication that once again you didn't
>> compile or test before back-porting, I'm not sure what I can do to
>> make the need for this any clearer to you.  Please remember your
>> responsibilities as a committer.
>>
>> Regards
>> Scott
>>
>> On 16/05/2012, at 1:17 PM, Scott Gray wrote:
>>
>>> You've changed the signature on the UtilXml methods, that should not
>>> be done and especially not be back-ported to the branches.  Even in
>>> the trunk the correct thing to do is to add a new method with the new
>>> signature and then (if needed) deprecate the old method.  Obviously
>>> deprecation shouldn't be back-ported.
>>>
>>> There's nothing new in this comment Jacques, the general rule of
>>> thumb is never change a method signature unless it is private.
>>>
>>> Regards
>>> Scott
>>>
>>> On 16/05/2012, at 7:11 AM, jler...@apache.org wrote:
>>>
 Author: jleroux
 Date: Tue May 15 19:11:13 2012
 New Revision: 1338836

 URL: http://svn.apache.org/viewvc?rev=1338836&view=rev
 Log:
 "Applied fix from trunk for revision: 1338831" (conflict in
 CommonUiLabels.xml handled by hand)
 

 r1338831 | jleroux | 2012-05-15 21:03:26 +0200 (mar., 15 mai 2012) |
 14 lines

 Fixes https://issues.apache.org/jira/browse/OFBIZ-4652 "The Label
 Manager is wrongly overriding CommonEmptyHeader"
 * Adds a keepSpace boolean to UtilXml.writeXmlDocument(), this
 allows to use xsl:preserve-space into UtilXml.createOutputTransformer()
 * Uses it into SaveLabelsToXmlFile.saveLabelsToXmlFile()
 * Adds some French labels into CommonUiLabels.xml using Labels
 Manager to test the new functionality
 * Adds the xml:space attribute into the valueType complexType
 * Adds the ofbiz-properties.xsd schema into the base-catalog.xml

 I got an issue when 1st trying to commit:
 Commit failed (details follow):
 While preparing
 'D:\workspace\ofbizClean\framework\common\config\CommonUiLabels.xml'
 for commit
 Inconsistent line ending style

 So I forced the EOLs to my locale platform value (Win XP)
 

 

 Modified:
ofbiz/branches/release12.04/   (props changed)
ofbiz/branches/release12.04/framework/base/dtd/base-catalog.xml
ofbiz/branches/release12.04/framework/base/dtd/ofbiz-properties.xsd
   
 ofbiz/branches/release12.04/framework/base/src/org/ofbiz/base/util/UtilXml.java

   
 ofbiz/branches/release12.04/framework/common/config/CommonUiLabels.xml
   
 ofbiz/branches/release12.04/framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java


 Propchange: ofbiz/branches/release12.04/
 --

 Merged /ofbiz/trunk:r1338831

 Modified:
 ofbiz/branches/release12.04/framework/base/dtd/base-catalog.xml
 URL:
 http://svn.apache.org/viewvc/ofbiz/branches/release12.04/framework/base/dtd/base-catalog.xml?rev=1338836&r1=1338835&r2=1338836&view=diff

 ==

 --- ofbiz/branches/release12.04/framework/base/dtd/base-catalog.xml
 (original)
 +++ ofbiz/branches/release12.04/framework/base/dtd/base-catalog.xml
 Tue May 15 19:11:13 2012
 @@ -29,4 +29,5 @@ under the License.
 http://ofbiz.apache.org/dtds/jndi-config.xsd";
 uri="jndi-config.xsd"/>
 >>> systemId="http://ofbiz.apache.org/dtds/ofbiz-component.xsd";
 uri="ofbiz-component.xsd"/>
 >>> systemId="http://ofbiz.apache.org/dtds/ofbiz-containers.xsd";
>

Re: local tests are failing

[Jacques Le Roux]

Success here also at r1339088

Jacques

From: "Jacques Le Roux" 

Ha sorry no, there is also r1339079, OK running test here anyway...

Jacques

From: "Jacques Le Roux" 

You mean r1339089, right?

Jacques

From: "Adrian Crum" 

I ran tests before committing rev 1339079 and they all passed.

-Adrian

On 5/16/2012 10:43 AM, Jacopo Cappellato wrote:

I see 12 failures when I run tests on trunk locally; however I have some local 
changes that *shouldn't* cause these failures.
Am I the only one? I will check my code regardless but in the meantime it would help if any of you could comment if you see 
issues.


Thanks
Jacopo 

Re: local tests are failing

[Jacopo Cappellato]

Ok, it happened to be a local change, sorry for the confusion.

Jacopo

On May 16, 2012, at 12:10 PM, Jacques Le Roux wrote:

> Ha sorry no, there is also r1339079, OK running test here anyway...
> 
> Jacques
> 
> From: "Jacques Le Roux" 
>> You mean r1339089, right?
>> Jacques
>> From: "Adrian Crum" 
>>> I ran tests before committing rev 1339079 and they all passed.
>>> 
>>> -Adrian
>>> 
>>> On 5/16/2012 10:43 AM, Jacopo Cappellato wrote:
 I see 12 failures when I run tests on trunk locally; however I have some 
 local changes that *shouldn't* cause these failures.
 Am I the only one? I will check my code regardless but in the meantime it 
 would help if any of you could comment if you see issues.
 
 Thanks
 Jacopo 
>> 

[jira] [Commented] (OFBIZ-4872) Functional Test Implementation

[Erwan de FERRIERES (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13276641#comment-13276641
 ] 

Erwan de FERRIERES commented on OFBIZ-4872:
---

> Difficulties:
>decide which approach is easy to maintain and extend: go by page(one page 
> contain many test cases) or go by case(one case cover a single scenario). The 
> first approach requires a few huge classes. The second approach requires 
> great pool of tiny classes, yet easy to distribute cases.

Hi,
I prefer the 2nd approach: working case by case, with reusable components


> Functional Test Implementation
> --
>
> Key: OFBIZ-4872
> URL: https://issues.apache.org/jira/browse/OFBIZ-4872
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Reporter: Nguyen Hoang Thanh Duc
>Priority: Trivial
>  Labels: gsoc2012, webdriver
>   Original Estimate: 2,184h
>  Remaining Estimate: 2,184h
>
> This issue covers progressively implementation of the functional test for the 
> OFBiz.
> The implementation relies mainly on the WebDriver, and assist developers with 
> ease to add/remove/edit test cases and obtain a complete test report then. 
> For more information: 
> https://cwiki.apache.org/confluence/display/OFBIZ/Implementation+Documentation

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4880) ajaxSubmitRequestUpdateAreas JavaScript function should be able to update content-messages

[Chatree Srichart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chatree Srichart updated OFBIZ-4880:


Attachment: ajaxSubmitRequestUpdateAreas.patch

> ajaxSubmitRequestUpdateAreas JavaScript function should be able to update 
> content-messages
> --
>
> Key: OFBIZ-4880
> URL: https://issues.apache.org/jira/browse/OFBIZ-4880
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
> Environment: Ubuntu 10.04
>Reporter: Chatree Srichart
>  Labels: ajax
> Attachments: ajaxSubmitRequestUpdateAreas.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Hi all,
> In the selectall.js file, the ajaxSubmitRequestUpdateAreas function should 
> check the response data if it contains an error message, or not. It then 
> should update the content-message content if it found an error message like 
> the ajaxSubmitFormUpdateAreas function.
> Regards,
> Chatree Srichart

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OFBIZ-4880) ajaxSubmitRequestUpdateAreas JavaScript function should be able to update content-messages

[Chatree Srichart (JIRA)]

Chatree Srichart created OFBIZ-4880:
---

 Summary: ajaxSubmitRequestUpdateAreas JavaScript function should 
be able to update content-messages
 Key: OFBIZ-4880
 URL: https://issues.apache.org/jira/browse/OFBIZ-4880
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
 Environment: Ubuntu 10.04
Reporter: Chatree Srichart
 Attachments: ajaxSubmitRequestUpdateAreas.patch

Hi all,

In the selectall.js file, the ajaxSubmitRequestUpdateAreas function should 
check the response data if it contains an error message, or not. It then should 
update the content-message content if it found an error message like the 
ajaxSubmitFormUpdateAreas function.

Regards,
Chatree Srichart

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: local tests are failing

[Jacques Le Roux]

Ha sorry no, there is also r1339079, OK running test here anyway...

Jacques

From: "Jacques Le Roux" 

You mean r1339089, right?

Jacques

From: "Adrian Crum" 

I ran tests before committing rev 1339079 and they all passed.

-Adrian

On 5/16/2012 10:43 AM, Jacopo Cappellato wrote:

I see 12 failures when I run tests on trunk locally; however I have some local 
changes that *shouldn't* cause these failures.
Am I the only one? I will check my code regardless but in the meantime it would help if any of you could comment if you see 
issues.


Thanks
Jacopo 

Re: local tests are failing

[Jacques Le Roux]

You mean r1339089, right?

Jacques

From: "Adrian Crum" 

I ran tests before committing rev 1339079 and they all passed.

-Adrian

On 5/16/2012 10:43 AM, Jacopo Cappellato wrote:

I see 12 failures when I run tests on trunk locally; however I have some local 
changes that *shouldn't* cause these failures.
Am I the only one? I will check my code regardless but in the meantime it would help if any of you could comment if you see 
issues.


Thanks
Jacopo 

Re: local tests are failing

[Jacques Le Roux]

Trying "ant clean-all load-demo run-tests" here with a clean instance (trunk 
HEAD)

Jacques

From: "Jacopo Cappellato" 

I see 12 failures when I run tests on trunk locally; however I have some local 
changes that *shouldn't* cause these failures.
Am I the only one? I will check my code regardless but in the meantime it would help if any of you could comment if you see 
issues.


Thanks
Jacopo 

[jira] [Updated] (OFBIZ-4879) Edit Survey Question option not working

[Harsha Chadhar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Harsha Chadhar updated OFBIZ-4879:
--

Description: 
For a Survey Question of Type= Selected option, while trying to edit a survey 
question option the following error is encountered :

In set-pk-fields a value was not found with the specified valueAcsr: 
lookupKeyValue, not setting fields

URL : 
https://demo-trunk.ofbiz.apache.org:8443/content/control/EditSurveyQuestions?surveyId=1501
 
Screenlet:
Survey Options .


  was:
For a Survey Question of Type= Selected option, while trying to edit a survey 
question option the following error is encountered :

In set-pk-fields a value was not found with the specified valueAcsr: 
lookupKeyValue, not setting fields

URL : https://localhost:8443/content/control/EditSurveyQuestions?surveyId=1501 
Screenlet:
Survey Options .



> Edit Survey Question option not working
> ---
>
> Key: OFBIZ-4879
> URL: https://issues.apache.org/jira/browse/OFBIZ-4879
> Project: OFBiz
>  Issue Type: Bug
>  Components: content
>Affects Versions: Release 10.04, Release 11.04.01, Release Branch 12.04
>Reporter: Harsha Chadhar
> Fix For: Release Branch 10.04, Release Branch 11.04, Release 
> Branch 12.04
>
> Attachments: EditSurveyQuestionOption.bmp, OFBIZ-4879.patch
>
>
> For a Survey Question of Type= Selected option, while trying to edit a survey 
> question option the following error is encountered :
> In set-pk-fields a value was not found with the specified valueAcsr: 
> lookupKeyValue, not setting fields
> URL : 
> https://demo-trunk.ofbiz.apache.org:8443/content/control/EditSurveyQuestions?surveyId=1501
>  
> Screenlet:
> Survey Options .

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4879) Edit Survey Question option not working

[Harsha Chadhar (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13276627#comment-13276627
 ] 

Harsha Chadhar commented on OFBIZ-4879:
---

Please refer to the attached patch and screenshot. The issue is dependent on 
OFBIZ-2959.

> Edit Survey Question option not working
> ---
>
> Key: OFBIZ-4879
> URL: https://issues.apache.org/jira/browse/OFBIZ-4879
> Project: OFBiz
>  Issue Type: Bug
>  Components: content
>Affects Versions: Release 10.04, Release 11.04.01, Release Branch 12.04
>Reporter: Harsha Chadhar
> Fix For: Release Branch 10.04, Release Branch 11.04, Release 
> Branch 12.04
>
> Attachments: EditSurveyQuestionOption.bmp, OFBIZ-4879.patch
>
>
> For a Survey Question of Type= Selected option, while trying to edit a survey 
> question option the following error is encountered :
> In set-pk-fields a value was not found with the specified valueAcsr: 
> lookupKeyValue, not setting fields
> URL : 
> https://localhost:8443/content/control/EditSurveyQuestions?surveyId=1501 
> Screenlet:
> Survey Options .

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4879) Edit Survey Question option not working

[Harsha Chadhar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Harsha Chadhar updated OFBIZ-4879:
--

Attachment: OFBIZ-4879.patch

> Edit Survey Question option not working
> ---
>
> Key: OFBIZ-4879
> URL: https://issues.apache.org/jira/browse/OFBIZ-4879
> Project: OFBiz
>  Issue Type: Bug
>  Components: content
>Affects Versions: Release 10.04, Release 11.04.01, Release Branch 12.04
>Reporter: Harsha Chadhar
> Fix For: Release Branch 10.04, Release Branch 11.04, Release 
> Branch 12.04
>
> Attachments: EditSurveyQuestionOption.bmp, OFBIZ-4879.patch
>
>
> For a Survey Question of Type= Selected option, while trying to edit a survey 
> question option the following error is encountered :
> In set-pk-fields a value was not found with the specified valueAcsr: 
> lookupKeyValue, not setting fields
> URL : 
> https://localhost:8443/content/control/EditSurveyQuestions?surveyId=1501 
> Screenlet:
> Survey Options .

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4879) Edit Survey Question option not working

[Harsha Chadhar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Harsha Chadhar updated OFBIZ-4879:
--

Attachment: EditSurveyQuestionOption.bmp

> Edit Survey Question option not working
> ---
>
> Key: OFBIZ-4879
> URL: https://issues.apache.org/jira/browse/OFBIZ-4879
> Project: OFBiz
>  Issue Type: Bug
>  Components: content
>Affects Versions: Release 10.04, Release 11.04.01, Release Branch 12.04
>Reporter: Harsha Chadhar
> Fix For: Release Branch 10.04, Release Branch 11.04, Release 
> Branch 12.04
>
> Attachments: EditSurveyQuestionOption.bmp
>
>
> For a Survey Question of Type= Selected option, while trying to edit a survey 
> question option the following error is encountered :
> In set-pk-fields a value was not found with the specified valueAcsr: 
> lookupKeyValue, not setting fields
> URL : 
> https://localhost:8443/content/control/EditSurveyQuestions?surveyId=1501 
> Screenlet:
> Survey Options .

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: local tests are failing

[Adrian Crum]

I ran tests before committing rev 1339079 and they all passed.

-Adrian

On 5/16/2012 10:43 AM, Jacopo Cappellato wrote:

I see 12 failures when I run tests on trunk locally; however I have some local 
changes that *shouldn't* cause these failures.
Am I the only one? I will check my code regardless but in the meantime it would 
help if any of you could comment if you see issues.

Thanks
Jacopo

local tests are failing

[Jacopo Cappellato]

I see 12 failures when I run tests on trunk locally; however I have some local 
changes that *shouldn't* cause these failures.
Am I the only one? I will check my code regardless but in the meantime it would 
help if any of you could comment if you see issues.

Thanks
Jacopo

[jira] [Created] (OFBIZ-4879) Edit Survey Question option not working

[Harsha Chadhar (JIRA)]

Harsha Chadhar created OFBIZ-4879:
-

 Summary: Edit Survey Question option not working
 Key: OFBIZ-4879
 URL: https://issues.apache.org/jira/browse/OFBIZ-4879
 Project: OFBiz
  Issue Type: Bug
  Components: content
Affects Versions: Release 10.04, Release 11.04.01, Release Branch 12.04
Reporter: Harsha Chadhar
 Fix For: Release Branch 10.04, Release Branch 11.04, Release 
Branch 12.04


For a Survey Question of Type= Selected option, while trying to edit a survey 
question option the following error is encountered :

In set-pk-fields a value was not found with the specified valueAcsr: 
lookupKeyValue, not setting fields

URL : https://localhost:8443/content/control/EditSurveyQuestions?surveyId=1501 
Screenlet:
Survey Options .


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4652) The Label Manager is wrongly overriding CommonEmptyHeader

[Jacques Le Roux (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13276619#comment-13276619
 ] 

Jacques Le Roux commented on OFBIZ-4652:


I reverted all (trunk and r12.04), because it would break the correct 
indentation done by UtilXml.writeXmlDocument()
We will rather try this (quoting Adrian)
{quote}
There is a chance the XML parser treats an attribute containing a single space 
as an empty attribute. If that is the case, then the widget schemas can be 
updated to prevent that interpretation.
{quote}

> The Label Manager is wrongly overriding CommonEmptyHeader
> -
>
> Key: OFBIZ-4652
> URL: https://issues.apache.org/jira/browse/OFBIZ-4652
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release 09.04, Release 10.04, Release Branch 11.04, SVN 
> trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>  Labels: labe, manager
> Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk, 
> Release Branch 12.04
>
>
> So 
> 
> is replaced by
>  
> We shoul also add  to docvument the 
> feature (todo better, more a reminder)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OFBIZ-4878) Remove Survey Question Option not working.

[Harsha Chadhar (JIRA)]

Harsha Chadhar created OFBIZ-4878:
-

 Summary: Remove Survey Question Option not working.
 Key: OFBIZ-4878
 URL: https://issues.apache.org/jira/browse/OFBIZ-4878
 Project: OFBiz
  Issue Type: Sub-task
  Components: content
Affects Versions: Release 10.04, Release Branch 11.04, SVN trunk, Release 
Branch 12.04
Reporter: Harsha Chadhar
 Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk, 
Release Branch 12.04


On trying to delete/remove Survey Question Options for Survey Question Type= 
Selected Option, the following error is occurred :
Url : 
https://demo-trunk.ofbiz.apache.org:8443/content/control/removeSurveyQuestionAppl?surveyId=1501&surveyQuestionId=1&surveyOptionSeqId=1
 

Error calling event: org.ofbiz.webapp.event.EventHandlerException: Found URL 
parameter [surveyId] passed to secure (https) request-map with uri 
[removeSurveyQuestionAppl] with an event that calls service 
[deleteSurveyQuestionAppl]; this is not allowed for security reasons! The data 
should be encrypted by making it part of the request body (a form field) 
instead of the request URL. Moreover it would be kind if you could create a 
Jira sub-task of https://issues.apache.org/jira/browse/OFBIZ-2330 (check before 
if a sub-task for this error does not exist). If you are not sure how to create 
a Jira issue please have a look before at 
http://cwiki.apache.org/confluence/x/JIB2 Thank you in advance for your help.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: svn commit: r1338836 - in /ofbiz/branches/release12.04: ./ framework/base/dtd/ framework/base/src/org/ofbiz/base/util/ framework/common/config/ framework/webtools/src/org/ofbiz/webtools/labelmanag

[Adrian Crum]

Thank you.

There is a chance the XML parser treats an attribute containing a single 
space as an empty attribute. If that is the case, then the widget 
schemas can be updated to prevent that interpretation.


-Adrian


On 5/16/2012 10:03 AM, Jacques Le Roux wrote:
Thanks for the answer. What I really missed is the point 4: the whole 
file is rewritten for each label change


OK I will revert and try to fix the empty title issue. It seems indeed 
to be the only reason why CommonEmptyHeader  is used. I need to double 
check that before though, there are 491 occurences


Jacques


From: "Adrian Crum" 
I tried to explain it to you in the Jira issue and in my initial 
response to this commit. Clearly, you are not understanding the 
problem. If you don't understand the problem, then you shouldn't be 
committing half-baked "solutions."


I will try to explain it again:

1. CommonEmptyHeader exists as a workaround to a flaw in the screen 
widget rendering. The simple fact that a single space character - 
which never needs to be translated - is in the UI label file makes it 
obvious that it is a hack.


2. Label Manager removes the single space from CommonEmptyHeader  
while saving changes to the file. That is because a stylesheet is 
used to format the XML, and the stylesheet removes the space.


3. The correct solution to this problem (#2) is to fix the screen 
widget rendering (#1).


4. Disabling space removal in the stylesheet effectively disables the 
entire stylesheet. The whole point of the method you modified is to 
strip all spaces from the XML, and then indent the XML with the 
specified spacing. If you turn off the space removal then the XML 
will not be indented properly.


I can't make it any simpler than that.

In case you missed it in my previous replies:

-1 on this commit and the others like it.

If you can't understand the problem, then that's fine - revert the 
code and unassign yourself from the Jira issue so someone more 
qualified can fix it.


-Adrian

On 5/16/2012 9:05 AM, Jacques Le Roux wrote:
Why don't you answer on my proposition? Why don't you *clearly 
explain* why this change is unnecessary instead of yelling?


I really want to fix this bug, wich removes the xml:space="preserve" 
attribute from CommonEmptyHeader


Jacques

From: "Adrian Crum" 

I repeat: THIS CHANGE IS UNNECESSARY.

Please revert it.

And in case you missed it the first time:

-1 on this commit and the others like it.

-Adrian

On 5/16/2012 8:28 AM, Jacques Le Roux wrote:

I don't agree, it does not hide a problem, it solves a problem.

The (keepSpace=true) version  is only used in 
SaveLabelsToXmlFile.saveLabelsToXmlFile(), nothing else is changed 
functionally.


Would you not agree with this patch?

Index: 
framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java

===
--- 
framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java 
(revision 1338984)
+++ 
framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java 
(working copy)

@@ -113,6 +113,7 @@
resourceElem.setAttribute("xmlns:xsi", 
"http://www.w3.org/2001/XMLSchema-instance";);

resourceElem.setAttribute("xsi:noNamespaceSchemaLocation","http://ofbiz.apache.org/dtds/ofbiz-properties.xsd";);

for (String labelKey : labelsList) {
+boolean keepSpaces = false;
LabelInfo labelInfo = labels.get(labelKey);
if 
(!(labelInfo.getFileName().equalsIgnoreCase(fileName))) {

continue;
@@ -136,6 +137,7 @@
valueElem.setAttribute("xml:lang", 
localeFound);

if (valueString.trim().isEmpty()) {

valueElem.setAttribute("xml:space", "preserve");

+keepSpaces = true;
}
if 
(UtilValidate.isNotEmpty(labelValue.getLabelComment())) {

Comment labelComment =
resourceDocument.createComment(StringEscapeUtils.unescapeHtml(labelValue.getLabelComment())); 


@@ -149,7 +151,7 @@
if (apacheLicenseText != null) {
fos.write(apacheLicenseText.getBytes());
}
-UtilXml.writeXmlDocument(resourceElem, 
fos, "UTF-8", !(apacheLicenseText == null), true, 4, true);
+UtilXml.writeXmlDocument(resourceElem, 
fos, "UTF-8", !(apacheLicenseText == null), true, 4, keepSpaces);

} finally {
fos.close();
// clear cache to see immediately the new 
labels and


Jacques

From: "Adrian Crum" 
The bad thing about this change is that it is not necessary. This 
change hides a problem - it does not solve it. I mentioned that

in the Jira issue.

The method is supposed 

Re: svn commit: r1338836 - in /ofbiz/branches/release12.04: ./ framework/base/dtd/ framework/base/src/org/ofbiz/base/util/ framework/common/config/ framework/webtools/src/org/ofbiz/webtools/labelmanag

[Jacques Le Roux]

Thanks for the answer. What I really missed is the point 4: the whole file is 
rewritten for each label change

OK I will revert and try to fix the empty title issue. It seems indeed to be the only reason why CommonEmptyHeader  is used. I need 
to double check that before though, there are 491 occurences


Jacques


From: "Adrian Crum" 
I tried to explain it to you in the Jira issue and in my initial response to this commit. Clearly, you are not understanding the 
problem. If you don't understand the problem, then you shouldn't be committing half-baked "solutions."


I will try to explain it again:

1. CommonEmptyHeader exists as a workaround to a flaw in the screen widget rendering. The simple fact that a single space 
character - which never needs to be translated - is in the UI label file makes it obvious that it is a hack.


2. Label Manager removes the single space from CommonEmptyHeader  while saving changes to the file. That is because a stylesheet 
is used to format the XML, and the stylesheet removes the space.


3. The correct solution to this problem (#2) is to fix the screen widget 
rendering (#1).

4. Disabling space removal in the stylesheet effectively disables the entire stylesheet. The whole point of the method you 
modified is to strip all spaces from the XML, and then indent the XML with the specified spacing. If you turn off the space 
removal then the XML will not be indented properly.


I can't make it any simpler than that.

In case you missed it in my previous replies:

-1 on this commit and the others like it.

If you can't understand the problem, then that's fine - revert the code and unassign yourself from the Jira issue so someone more 
qualified can fix it.


-Adrian

On 5/16/2012 9:05 AM, Jacques Le Roux wrote:

Why don't you answer on my proposition? Why don't you *clearly explain* why 
this change is unnecessary instead of yelling?

I really want to fix this bug, wich removes the xml:space="preserve" attribute 
from CommonEmptyHeader

Jacques

From: "Adrian Crum" 

I repeat: THIS CHANGE IS UNNECESSARY.

Please revert it.

And in case you missed it the first time:

-1 on this commit and the others like it.

-Adrian

On 5/16/2012 8:28 AM, Jacques Le Roux wrote:

I don't agree, it does not hide a problem, it solves a problem.

The (keepSpace=true) version  is only used in 
SaveLabelsToXmlFile.saveLabelsToXmlFile(), nothing else is changed functionally.

Would you not agree with this patch?

Index: 
framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java
===
--- 
framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java (revision 1338984)

+++ 
framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java 
(working copy)
@@ -113,6 +113,7 @@
resourceElem.setAttribute("xmlns:xsi", 
"http://www.w3.org/2001/XMLSchema-instance";);

resourceElem.setAttribute("xsi:noNamespaceSchemaLocation","http://ofbiz.apache.org/dtds/ofbiz-properties.xsd";);
for (String labelKey : labelsList) {
+boolean keepSpaces = false;
LabelInfo labelInfo = labels.get(labelKey);
if (!(labelInfo.getFileName().equalsIgnoreCase(fileName))) {
continue;
@@ -136,6 +137,7 @@
valueElem.setAttribute("xml:lang", localeFound);
if (valueString.trim().isEmpty()) {
valueElem.setAttribute("xml:space", "preserve");
+keepSpaces = true;
}
if 
(UtilValidate.isNotEmpty(labelValue.getLabelComment())) {
Comment labelComment =
resourceDocument.createComment(StringEscapeUtils.unescapeHtml(labelValue.getLabelComment()));
@@ -149,7 +151,7 @@
if (apacheLicenseText != null) {
fos.write(apacheLicenseText.getBytes());
}
-UtilXml.writeXmlDocument(resourceElem, fos, "UTF-8", 
!(apacheLicenseText == null), true, 4, true);
+UtilXml.writeXmlDocument(resourceElem, fos, "UTF-8", !(apacheLicenseText == null), true, 4, 
keepSpaces);

} finally {
fos.close();
// clear cache to see immediately the new labels and

Jacques

From: "Adrian Crum" 
The bad thing about this change is that it is not necessary. This change hides a problem - it does not solve it. I mentioned 
that

in the Jira issue.

The method is supposed to pretty-print an XML document, and if you turn off space removal, the indentation will be wrong. In 
other

words, it will not be pretty.

-1 on this change in any version.

-Adrian

On 5/16/2012 2:25 AM, Scott Gray wrote:

I see in your subsequent commits that you encountered the problems ca

Re: svn commit: r1338836 - in /ofbiz/branches/release12.04: ./ framework/base/dtd/ framework/base/src/org/ofbiz/base/util/ framework/common/config/ framework/webtools/src/org/ofbiz/webtools/labelmanag

[Adrian Crum]

I tried to explain it to you in the Jira issue and in my initial 
response to this commit. Clearly, you are not understanding the problem. 
If you don't understand the problem, then you shouldn't be committing 
half-baked "solutions."


I will try to explain it again:

1. CommonEmptyHeader exists as a workaround to a flaw in the screen 
widget rendering. The simple fact that a single space character - which 
never needs to be translated - is in the UI label file makes it obvious 
that it is a hack.


2. Label Manager removes the single space from CommonEmptyHeader  while 
saving changes to the file. That is because a stylesheet is used to 
format the XML, and the stylesheet removes the space.


3. The correct solution to this problem (#2) is to fix the screen widget 
rendering (#1).


4. Disabling space removal in the stylesheet effectively disables the 
entire stylesheet. The whole point of the method you modified is to 
strip all spaces from the XML, and then indent the XML with the 
specified spacing. If you turn off the space removal then the XML will 
not be indented properly.


I can't make it any simpler than that.

In case you missed it in my previous replies:

-1 on this commit and the others like it.

If you can't understand the problem, then that's fine - revert the code 
and unassign yourself from the Jira issue so someone more qualified can 
fix it.


-Adrian

On 5/16/2012 9:05 AM, Jacques Le Roux wrote:
Why don't you answer on my proposition? Why don't you *clearly 
explain* why this change is unnecessary instead of yelling?


I really want to fix this bug, wich removes the xml:space="preserve" 
attribute from CommonEmptyHeader


Jacques

From: "Adrian Crum" 

I repeat: THIS CHANGE IS UNNECESSARY.

Please revert it.

And in case you missed it the first time:

-1 on this commit and the others like it.

-Adrian

On 5/16/2012 8:28 AM, Jacques Le Roux wrote:

I don't agree, it does not hide a problem, it solves a problem.

The (keepSpace=true) version  is only used in 
SaveLabelsToXmlFile.saveLabelsToXmlFile(), nothing else is changed 
functionally.


Would you not agree with this patch?

Index: 
framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java

===
--- 
framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java 
(revision 1338984)
+++ 
framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java 
(working copy)

@@ -113,6 +113,7 @@
resourceElem.setAttribute("xmlns:xsi", 
"http://www.w3.org/2001/XMLSchema-instance";);

resourceElem.setAttribute("xsi:noNamespaceSchemaLocation","http://ofbiz.apache.org/dtds/ofbiz-properties.xsd";);

for (String labelKey : labelsList) {
+boolean keepSpaces = false;
LabelInfo labelInfo = labels.get(labelKey);
if 
(!(labelInfo.getFileName().equalsIgnoreCase(fileName))) {

continue;
@@ -136,6 +137,7 @@
valueElem.setAttribute("xml:lang", 
localeFound);

if (valueString.trim().isEmpty()) {
valueElem.setAttribute("xml:space", 
"preserve");

+keepSpaces = true;
}
if 
(UtilValidate.isNotEmpty(labelValue.getLabelComment())) {

Comment labelComment =
resourceDocument.createComment(StringEscapeUtils.unescapeHtml(labelValue.getLabelComment())); 


@@ -149,7 +151,7 @@
if (apacheLicenseText != null) {
fos.write(apacheLicenseText.getBytes());
}
-UtilXml.writeXmlDocument(resourceElem, fos, 
"UTF-8", !(apacheLicenseText == null), true, 4, true);
+UtilXml.writeXmlDocument(resourceElem, fos, 
"UTF-8", !(apacheLicenseText == null), true, 4, keepSpaces);

} finally {
fos.close();
// clear cache to see immediately the new 
labels and


Jacques

From: "Adrian Crum" 
The bad thing about this change is that it is not necessary. This 
change hides a problem - it does not solve it. I mentioned that

in the Jira issue.

The method is supposed to pretty-print an XML document, and if you 
turn off space removal, the indentation will be wrong. In other

words, it will not be pretty.

-1 on this change in any version.

-Adrian

On 5/16/2012 2:25 AM, Scott Gray wrote:
I see in your subsequent commits that you encountered the problems 
caused by this type of change.


They're also a pretty good indication that once again you didn't 
compile or test before back-porting, I'm not sure what I can do
to make the need for this any clearer to you.  Please remember 
your responsibilities as a committer.


Regards
Scott

On 16/05/2012, at 1:17 PM, Scott 

Re: svn commit: r1338836 - in /ofbiz/branches/release12.04: ./ framework/base/dtd/ framework/base/src/org/ofbiz/base/util/ framework/common/config/ framework/webtools/src/org/ofbiz/webtools/labelmanag

[Jacques Le Roux]

Why don't you answer on my proposition? Why don't you *clearly explain* why 
this change is unnecessary instead of yelling?

I really want to fix this bug, wich removes the xml:space="preserve" attribute 
from CommonEmptyHeader

Jacques

From: "Adrian Crum" 

I repeat: THIS CHANGE IS UNNECESSARY.

Please revert it.

And in case you missed it the first time:

-1 on this commit and the others like it.

-Adrian

On 5/16/2012 8:28 AM, Jacques Le Roux wrote:

I don't agree, it does not hide a problem, it solves a problem.

The (keepSpace=true) version  is only used in 
SaveLabelsToXmlFile.saveLabelsToXmlFile(), nothing else is changed functionally.

Would you not agree with this patch?

Index: 
framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java
===
--- 
framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java (revision 1338984)

+++ 
framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java 
(working copy)
@@ -113,6 +113,7 @@
resourceElem.setAttribute("xmlns:xsi", 
"http://www.w3.org/2001/XMLSchema-instance";);

resourceElem.setAttribute("xsi:noNamespaceSchemaLocation","http://ofbiz.apache.org/dtds/ofbiz-properties.xsd";);
for (String labelKey : labelsList) {
+boolean keepSpaces = false;
LabelInfo labelInfo = labels.get(labelKey);
if (!(labelInfo.getFileName().equalsIgnoreCase(fileName))) {
continue;
@@ -136,6 +137,7 @@
valueElem.setAttribute("xml:lang", localeFound);
if (valueString.trim().isEmpty()) {
valueElem.setAttribute("xml:space", "preserve");
+keepSpaces = true;
}
if 
(UtilValidate.isNotEmpty(labelValue.getLabelComment())) {
Comment labelComment =
resourceDocument.createComment(StringEscapeUtils.unescapeHtml(labelValue.getLabelComment()));
@@ -149,7 +151,7 @@
if (apacheLicenseText != null) {
fos.write(apacheLicenseText.getBytes());
}
-UtilXml.writeXmlDocument(resourceElem, fos, "UTF-8", 
!(apacheLicenseText == null), true, 4, true);
+UtilXml.writeXmlDocument(resourceElem, fos, "UTF-8", 
!(apacheLicenseText == null), true, 4, keepSpaces);
} finally {
fos.close();
// clear cache to see immediately the new labels and

Jacques

From: "Adrian Crum" 
The bad thing about this change is that it is not necessary. This change hides a problem - it does not solve it. I mentioned 
that

in the Jira issue.

The method is supposed to pretty-print an XML document, and if you turn off space removal, the indentation will be wrong. In 
other

words, it will not be pretty.

-1 on this change in any version.

-Adrian

On 5/16/2012 2:25 AM, Scott Gray wrote:

I see in your subsequent commits that you encountered the problems caused by 
this type of change.

They're also a pretty good indication that once again you didn't compile or test before back-porting, I'm not sure what I can 
do

to make the need for this any clearer to you.  Please remember your 
responsibilities as a committer.

Regards
Scott

On 16/05/2012, at 1:17 PM, Scott Gray wrote:

You've changed the signature on the UtilXml methods, that should not be done and especially not be back-ported to the 
branches.

Even in the trunk the correct thing to do is to add a new method with the new 
signature and then (if needed) deprecate the old
method.  Obviously deprecation shouldn't be back-ported.

There's nothing new in this comment Jacques, the general rule of thumb is never change a method signature unless it is 
private.


Regards
Scott

On 16/05/2012, at 7:11 AM, jler...@apache.org wrote:


Author: jleroux
Date: Tue May 15 19:11:13 2012
New Revision: 1338836

URL: http://svn.apache.org/viewvc?rev=1338836&view=rev
Log:
"Applied fix from trunk for revision: 1338831" (conflict in CommonUiLabels.xml 
handled by hand)
 


r1338831 | jleroux | 2012-05-15 21:03:26 +0200 (mar., 15 mai 2012) | 14 lines

Fixes https://issues.apache.org/jira/browse/OFBIZ-4652 "The Label Manager is wrongly 
overriding CommonEmptyHeader"
* Adds a keepSpace boolean to UtilXml.writeXmlDocument(), this allows to use 
xsl:preserve-space into
UtilXml.createOutputTransformer()
* Uses it into SaveLabelsToXmlFile.saveLabelsToXmlFile()
* Adds some French labels into CommonUiLabels.xml using Labels Manager to test 
the new functionality
* Adds the xml:space attribute into the valueType complexType
* Adds the ofbiz-properties.xsd schema into the base-catalog.xml

I got an 

Re: svn commit: r1338836 - in /ofbiz/branches/release12.04: ./ framework/base/dtd/ framework/base/src/org/ofbiz/base/util/ framework/common/config/ framework/webtools/src/org/ofbiz/webtools/labelmanag

[Adrian Crum]

I repeat: THIS CHANGE IS UNNECESSARY.

Please revert it.

And in case you missed it the first time:

-1 on this commit and the others like it.

-Adrian

On 5/16/2012 8:28 AM, Jacques Le Roux wrote:

I don't agree, it does not hide a problem, it solves a problem.

The (keepSpace=true) version  is only used in 
SaveLabelsToXmlFile.saveLabelsToXmlFile(), nothing else is changed 
functionally.


Would you not agree with this patch?

Index: 
framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java

===
--- 
framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java 
(revision 1338984)
+++ 
framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java 
(working copy)

@@ -113,6 +113,7 @@
resourceElem.setAttribute("xmlns:xsi", 
"http://www.w3.org/2001/XMLSchema-instance";);

resourceElem.setAttribute("xsi:noNamespaceSchemaLocation","http://ofbiz.apache.org/dtds/ofbiz-properties.xsd";);

for (String labelKey : labelsList) {
+boolean keepSpaces = false;
LabelInfo labelInfo = labels.get(labelKey);
if 
(!(labelInfo.getFileName().equalsIgnoreCase(fileName))) {

continue;
@@ -136,6 +137,7 @@
valueElem.setAttribute("xml:lang", 
localeFound);

if (valueString.trim().isEmpty()) {
valueElem.setAttribute("xml:space", 
"preserve");

+keepSpaces = true;
}
if 
(UtilValidate.isNotEmpty(labelValue.getLabelComment())) {

Comment labelComment =
resourceDocument.createComment(StringEscapeUtils.unescapeHtml(labelValue.getLabelComment())); 


@@ -149,7 +151,7 @@
if (apacheLicenseText != null) {
fos.write(apacheLicenseText.getBytes());
}
-UtilXml.writeXmlDocument(resourceElem, fos, 
"UTF-8", !(apacheLicenseText == null), true, 4, true);
+UtilXml.writeXmlDocument(resourceElem, fos, 
"UTF-8", !(apacheLicenseText == null), true, 4, keepSpaces);

} finally {
fos.close();
// clear cache to see immediately the new 
labels and


Jacques

From: "Adrian Crum" 
The bad thing about this change is that it is not necessary. This 
change hides a problem - it does not solve it. I mentioned that

in the Jira issue.

The method is supposed to pretty-print an XML document, and if you 
turn off space removal, the indentation will be wrong. In other

words, it will not be pretty.

-1 on this change in any version.

-Adrian

On 5/16/2012 2:25 AM, Scott Gray wrote:
I see in your subsequent commits that you encountered the problems 
caused by this type of change.


They're also a pretty good indication that once again you didn't 
compile or test before back-porting, I'm not sure what I can do
to make the need for this any clearer to you.  Please remember your 
responsibilities as a committer.


Regards
Scott

On 16/05/2012, at 1:17 PM, Scott Gray wrote:

You've changed the signature on the UtilXml methods, that should 
not be done and especially not be back-ported to the branches.
Even in the trunk the correct thing to do is to add a new method 
with the new signature and then (if needed) deprecate the old

method.  Obviously deprecation shouldn't be back-ported.

There's nothing new in this comment Jacques, the general rule of 
thumb is never change a method signature unless it is private.


Regards
Scott

On 16/05/2012, at 7:11 AM, jler...@apache.org wrote:


Author: jleroux
Date: Tue May 15 19:11:13 2012
New Revision: 1338836

URL: http://svn.apache.org/viewvc?rev=1338836&view=rev
Log:
"Applied fix from trunk for revision: 1338831" (conflict in 
CommonUiLabels.xml handled by hand)
 

r1338831 | jleroux | 2012-05-15 21:03:26 +0200 (mar., 15 mai 2012) 
| 14 lines


Fixes https://issues.apache.org/jira/browse/OFBIZ-4652 "The Label 
Manager is wrongly overriding CommonEmptyHeader"
* Adds a keepSpace boolean to UtilXml.writeXmlDocument(), this 
allows to use xsl:preserve-space into

UtilXml.createOutputTransformer()
* Uses it into SaveLabelsToXmlFile.saveLabelsToXmlFile()
* Adds some French labels into CommonUiLabels.xml using Labels 
Manager to test the new functionality

* Adds the xml:space attribute into the valueType complexType
* Adds the ofbiz-properties.xsd schema into the base-catalog.xml

I got an issue when 1st trying to commit:
Commit failed (details follow):
While preparing
'D:\workspace\ofbizClean\framework\common\config\CommonUiLabels.xml' 
for commit

Inconsistent line ending style

So I forced the EOLs to my locale platform v

[jira] [Comment Edited] (OFBIZ-4652) The Label Manager is wrongly overriding CommonEmptyHeader

[Jacques Le Roux (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13276550#comment-13276550
 ] 

Jacques Le Roux edited comment on OFBIZ-4652 at 5/16/12 7:30 AM:
-

== TYPO ==
Hi Adrian,

Answered on dev ML :)

  was (Author: jacques.le.roux):
Hi Adrian,

Answered on de ML :)
  
> The Label Manager is wrongly overriding CommonEmptyHeader
> -
>
> Key: OFBIZ-4652
> URL: https://issues.apache.org/jira/browse/OFBIZ-4652
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release 09.04, Release 10.04, Release Branch 11.04, SVN 
> trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>  Labels: labe, manager
> Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk, 
> Release Branch 12.04
>
>
> So 
> 
> is replaced by
>  
> We shoul also add  to docvument the 
> feature (todo better, more a reminder)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4652) The Label Manager is wrongly overriding CommonEmptyHeader

[Jacques Le Roux (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13276550#comment-13276550
 ] 

Jacques Le Roux commented on OFBIZ-4652:


Hi Adrian,

Answered on de ML :)

> The Label Manager is wrongly overriding CommonEmptyHeader
> -
>
> Key: OFBIZ-4652
> URL: https://issues.apache.org/jira/browse/OFBIZ-4652
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release 09.04, Release 10.04, Release Branch 11.04, SVN 
> trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>  Labels: labe, manager
> Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk, 
> Release Branch 12.04
>
>
> So 
> 
> is replaced by
>  
> We shoul also add  to docvument the 
> feature (todo better, more a reminder)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: svn commit: r1338836 - in /ofbiz/branches/release12.04: ./ framework/base/dtd/ framework/base/src/org/ofbiz/base/util/ framework/common/config/ framework/webtools/src/org/ofbiz/webtools/labelmanag

[Jacques Le Roux]

I don't agree, it does not hide a problem, it solves a problem.

The (keepSpace=true) version  is only used in 
SaveLabelsToXmlFile.saveLabelsToXmlFile(), nothing else is changed functionally.

Would you not agree with this patch?

Index: 
framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java
===
--- 
framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java 
(revision 1338984)
+++ 
framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java 
(working copy)
@@ -113,6 +113,7 @@
resourceElem.setAttribute("xmlns:xsi", 
"http://www.w3.org/2001/XMLSchema-instance";);

resourceElem.setAttribute("xsi:noNamespaceSchemaLocation","http://ofbiz.apache.org/dtds/ofbiz-properties.xsd";);
for (String labelKey : labelsList) {
+boolean keepSpaces = false;
LabelInfo labelInfo = labels.get(labelKey);
if (!(labelInfo.getFileName().equalsIgnoreCase(fileName))) {
continue;
@@ -136,6 +137,7 @@
valueElem.setAttribute("xml:lang", localeFound);
if (valueString.trim().isEmpty()) {
valueElem.setAttribute("xml:space", "preserve");
+keepSpaces = true;
}
if 
(UtilValidate.isNotEmpty(labelValue.getLabelComment())) {
Comment labelComment =
resourceDocument.createComment(StringEscapeUtils.unescapeHtml(labelValue.getLabelComment()));
@@ -149,7 +151,7 @@
if (apacheLicenseText != null) {
fos.write(apacheLicenseText.getBytes());
}
-UtilXml.writeXmlDocument(resourceElem, fos, "UTF-8", 
!(apacheLicenseText == null), true, 4, true);
+UtilXml.writeXmlDocument(resourceElem, fos, "UTF-8", 
!(apacheLicenseText == null), true, 4, keepSpaces);
} finally {
fos.close();
// clear cache to see immediately the new labels and

Jacques

From: "Adrian Crum" 

The bad thing about this change is that it is not necessary. This change hides 
a problem - it does not solve it. I mentioned that
in the Jira issue.

The method is supposed to pretty-print an XML document, and if you turn off 
space removal, the indentation will be wrong. In other
words, it will not be pretty.

-1 on this change in any version.

-Adrian

On 5/16/2012 2:25 AM, Scott Gray wrote:

I see in your subsequent commits that you encountered the problems caused by 
this type of change.

They're also a pretty good indication that once again you didn't compile or 
test before back-porting, I'm not sure what I can do
to make the need for this any clearer to you.  Please remember your 
responsibilities as a committer.

Regards
Scott

On 16/05/2012, at 1:17 PM, Scott Gray wrote:


You've changed the signature on the UtilXml methods, that should not be done 
and especially not be back-ported to the branches.
Even in the trunk the correct thing to do is to add a new method with the new 
signature and then (if needed) deprecate the old
method.  Obviously deprecation shouldn't be back-ported.

There's nothing new in this comment Jacques, the general rule of thumb is never 
change a method signature unless it is private.

Regards
Scott

On 16/05/2012, at 7:11 AM, jler...@apache.org wrote:


Author: jleroux
Date: Tue May 15 19:11:13 2012
New Revision: 1338836

URL: http://svn.apache.org/viewvc?rev=1338836&view=rev
Log:
"Applied fix from trunk for revision: 1338831" (conflict in CommonUiLabels.xml 
handled by hand)

r1338831 | jleroux | 2012-05-15 21:03:26 +0200 (mar., 15 mai 2012) | 14 lines

Fixes https://issues.apache.org/jira/browse/OFBIZ-4652 "The Label Manager is wrongly 
overriding CommonEmptyHeader"
* Adds a keepSpace boolean to UtilXml.writeXmlDocument(), this allows to use 
xsl:preserve-space into
UtilXml.createOutputTransformer()
* Uses it into SaveLabelsToXmlFile.saveLabelsToXmlFile()
* Adds some French labels into CommonUiLabels.xml using Labels Manager to test 
the new functionality
* Adds the xml:space attribute into the valueType complexType
* Adds the ofbiz-properties.xsd schema into the base-catalog.xml

I got an issue when 1st trying to commit:
Commit failed (details follow):
While preparing
'D:\workspace\ofbizClean\framework\common\config\CommonUiLabels.xml' for commit
Inconsistent line ending style

So I forced the EOLs to my locale platform value (Win XP)



Modified:
   ofbiz/branches/release12.04/   (props changed)
   ofbiz/branches/release12.04/framework/base/dtd/base-catalog.xml
   ofbiz/br

[jira] [Commented] (OFBIZ-4652) The Label Manager is wrongly overriding CommonEmptyHeader

[Adrian Crum (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13276539#comment-13276539
 ] 

Adrian Crum commented on OFBIZ-4652:


Jacques, that email link describes what needs to be fixed, NOT why it should 
stay that way.


> The Label Manager is wrongly overriding CommonEmptyHeader
> -
>
> Key: OFBIZ-4652
> URL: https://issues.apache.org/jira/browse/OFBIZ-4652
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release 09.04, Release 10.04, Release Branch 11.04, SVN 
> trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>  Labels: labe, manager
> Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk, 
> Release Branch 12.04
>
>
> So 
> 
> is replaced by
>  
> We shoul also add  to docvument the 
> feature (todo better, more a reminder)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: svn commit: r1338836 - in /ofbiz/branches/release12.04: ./ framework/base/dtd/ framework/base/src/org/ofbiz/base/util/ framework/common/config/ framework/webtools/src/org/ofbiz/webtools/labelmanag

[Jacques Le Roux]

Ha yes, of course. I was blinded by my will to not duplicate createOutputTransformer() for only one word (preserve & strip) when I 
did not see that the DRY principle is lower than the constraints on backward compatibitlity. I will do that.


Jacques

From: "Scott Gray" 

You can add a method by the same name if you need to, but you can't change an 
existing method's signature.

Regards
Scott

On 16/05/2012, at 3:27 PM, Jacques Le Roux wrote:


Mmm... but then how do you fix the bug in released branches?

Jacques

From: "Jacques Le Roux" 

Ha indeed, I have reverted R10.04 and R11.04. I will deprecate on trunk and 
R12.04

Jacques

From: "Scott Gray" 
You've changed the signature on the UtilXml methods, that should not be done and especially not be back-ported to the branches. 
Even in the trunk the correct thing to do is to add a new method with the new signature and then (if needed) deprecate the old 
method.  Obviously deprecation shouldn't be back-ported.


There's nothing new in this comment Jacques, the general rule of thumb is never 
change a method signature unless it is private.

Regards
Scott

On 16/05/2012, at 7:11 AM, jler...@apache.org wrote:


Author: jleroux
Date: Tue May 15 19:11:13 2012
New Revision: 1338836

URL: http://svn.apache.org/viewvc?rev=1338836&view=rev
Log:
"Applied fix from trunk for revision: 1338831" (conflict in CommonUiLabels.xml 
handled by hand)

r1338831 | jleroux | 2012-05-15 21:03:26 +0200 (mar., 15 mai 2012) | 14 lines

Fixes https://issues.apache.org/jira/browse/OFBIZ-4652 "The Label Manager is wrongly 
overriding CommonEmptyHeader"
* Adds a keepSpace boolean to UtilXml.writeXmlDocument(), this allows to use xsl:preserve-space into 
UtilXml.createOutputTransformer()

* Uses it into SaveLabelsToXmlFile.saveLabelsToXmlFile()
* Adds some French labels into CommonUiLabels.xml using Labels Manager to test 
the new functionality
* Adds the xml:space attribute into the valueType complexType
* Adds the ofbiz-properties.xsd schema into the base-catalog.xml

I got an issue when 1st trying to commit:
Commit failed (details follow):
While preparing
'D:\workspace\ofbizClean\framework\common\config\CommonUiLabels.xml' for commit
Inconsistent line ending style

So I forced the EOLs to my locale platform value (Win XP)



Modified:
  ofbiz/branches/release12.04/   (props changed)
  ofbiz/branches/release12.04/framework/base/dtd/base-catalog.xml
  ofbiz/branches/release12.04/framework/base/dtd/ofbiz-properties.xsd
  
ofbiz/branches/release12.04/framework/base/src/org/ofbiz/base/util/UtilXml.java
  ofbiz/branches/release12.04/framework/common/config/CommonUiLabels.xml
  
ofbiz/branches/release12.04/framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java

Propchange: ofbiz/branches/release12.04/
--
Merged /ofbiz/trunk:r1338831

Modified: ofbiz/branches/release12.04/framework/base/dtd/base-catalog.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/branches/release12.04/framework/base/dtd/base-catalog.xml?rev=1338836&r1=1338835&r2=1338836&view=diff

==
--- ofbiz/branches/release12.04/framework/base/dtd/base-catalog.xml (original)
+++ ofbiz/branches/release12.04/framework/base/dtd/base-catalog.xml Tue May 15 
19:11:13 2012
@@ -29,4 +29,5 @@ under the License.
   http://ofbiz.apache.org/dtds/jndi-config.xsd"; 
uri="jndi-config.xsd"/>
   http://ofbiz.apache.org/dtds/ofbiz-component.xsd"; 
uri="ofbiz-component.xsd"/>
   http://ofbiz.apache.org/dtds/ofbiz-containers.xsd"; 
uri="ofbiz-containers.xsd"/>
+http://ofbiz.apache.org/dtds/ofbiz-properties.xsd"; 
uri="ofbiz-properties.xsd"/>


Modified: ofbiz/branches/release12.04/framework/base/dtd/ofbiz-properties.xsd
URL: 
http://svn.apache.org/viewvc/ofbiz/branches/release12.04/framework/base/dtd/ofbiz-properties.xsd?rev=1338836&r1=1338835&r2=1338836&view=diff

==
--- ofbiz/branches/release12.04/framework/base/dtd/ofbiz-properties.xsd 
(original)
+++ ofbiz/branches/release12.04/framework/base/dtd/ofbiz-properties.xsd Tue May 
15 19:11:13 2012
@@ -42,6 +42,7 @@ under the License.
   
   
   
+
   
   
   

Modified: 
ofbiz/branches/release12.04/framework/base/src/org/ofbiz/base/util/UtilXml.java
URL: 
http://svn.apache.org/viewvc/ofbiz/branches/release12.04/framework/base/src/org/ofbiz/base/util/UtilXml.java?rev=1338836&r1=1338835&r2=1338836&view=diff

==
--- 
ofbiz/branches/release12.04/framework/base/src/org/ofbiz/base/util/UtilXml.java 
(original)
+++ 
ofbiz/branches/release12.04/framework/base/src/org/ofbiz/base/util/UtilXml.java