date:20110919

No HTML comments in CSV rendering
-

 Key: OFBIZ-4429
 URL: https://issues.apache.org/jira/browse/OFBIZ-4429
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
Reporter: Jacques Le Roux
Priority: Minor
 Fix For: SVN trunk


HTML comments are outputted for CSV (because there's no csv element and you 
have to use html) element. No HTML comments should be outputted for csv.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: widgetVerbose

Yes, but I guess we will set widget.verbose in the properties file to true (as we do for all defaults to be dev friendly). Will that 
suit Hans? Else why do you Hans ask for now overriding in web.xml? For instance what for Birt by defaut? Why not keeping the example 
in example component commented out? Waht for testtools? Not sure why it's false in googlecheckout but I guess there is a reason..


In other word I guess Hans expect widget.verbose in the properties file to be 
false...

Jacques

From: Adrian Crum adrian.c...@sandglass-software.com

Let's see if we can bring this to a happy ending.

If the widget.verbose setting in the properties file is false, then it overrides any other setting and all boundary comments are 
shut off.


If the widget.verbose setting in the properties file is true, then it follows the previous pattern, where true is the default, but 
it can be overridden in web.xml and in the context Map.


Will that work for everyone?

-Adrian

On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:

I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments should be output specific (i.e no output for CSV etc...) instead of 
always rendering as html comments.
As regards the logic to determine if comments should be enabled or not, I don't have a strong opinion because I have always used 
this feature in a very rough way (enable all or disable all); however I can understand the we may want to avoid that (when 
widget.properties.enableBoundaryComments == false) the comments are enabled by passing a URL parameter to the screen.


Kind regards,

Jacopo

On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:


Someone I work with suggested:

I have to point out though that I kind of agree with the way David put it in that the false setting could have a priority, 
i.e. it's like in security permissions where deny has precedence over allow, so if you set it in widget.properties to false 
then you're sure comments will never be enabled anywhere... security-wise it makes sense despite the comment about qc...


Maybe something like this? (compromise between the two)

if (widget.properties.enableBoundaryComments == false
   || web.xml.enableBoundaryComments == false
   || context.enableBoundaryComments == false) {
   return false;
} else { // This is the solution Scott wrote, but use overriding settings only 
for null and true values
   if (context.enableBoundaryComments != null) return 
context.enableBoundaryComments;
   if (web.xml.enableBoundaryComments != null) return 
web.xml.enableBoundaryComments;
   if (widget.properties.enableBoundaryComments != null) return 
widget.properties.enableBoundaryComments;
   return false;
}

Could probably rewrite that to be less redundant but you get the idea...

jleroux: I quickly reformated my own way ;o), It seems a good idea to me, what 
do you think?

Also my colleague also wrote:
Only thing I have to add is that I didn't see anyone address the issue that HTML comments are outputted for CSV (because there's 
nocsv  element and you have to usehtml) element. No matter what widget.verbose is set to, there should never be HTmL 
comments outputted for csv. so this only addresses half the bugs...


We have no patches so far...

Jacques



Dimitri Unruh wrote:

+1


Dimitri Unruh
Consultant AEW
Lynx-Consulting GmbH
Johanniskirchplatz 6
33615 Bielefeld
Deutschland
Fon: +49 521 5247-0
Fax: +49 521 5247-250
Mobil: +49 160 90 57 55 13


Company and Management Headquarters:
Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland
Fon: +49 521 5247-0, Fax: +49 521 5247-250, www.lynx.de

Court Registration: Amtsgericht Bielefeld HRB 35946
Chief Executive Officers: Karsten Noss, Dirk Osterkamp


http://www.lynx.de/haftungsausschluss


Wir laden Sie herzlich ein:
DSAG-Jahreskongress
Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle 2 Stand B01

Besuchen Sie uns an unserem Stand und freuen Sie sich auf einen intensiven 
Informations- und Erfahrungsaustausch rund um das
Thema Mobility!


Am 13.09.2011 um 14:35 schrieb Bilgin Ibryambibr...@gmail.com:


On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
adrian.c...@sandglass-software.com  wrote:

Thanks Scott - those are my feelings exactly.

I like the way the design worked previously, and changing it because a user
might accidentally leave the comments enabled in production seems silly.
That is a user's QC problem, not a widget comment design problem.

-Adrian


+ 1

Bilgin

[jira] [Created] (OFBIZ-4430) Replace OFBiz HttpClient either by org.apache.commons.httpclient.HttpClient or rewrite it using NIO

Replace OFBiz HttpClient either by org.apache.commons.httpclient.HttpClient or 
rewrite it using NIO
---

 Key: OFBIZ-4430
 URL: https://issues.apache.org/jira/browse/OFBIZ-4430
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
Reporter: Jacques Le Roux
 Fix For: SVN trunk


The main problem with current implementation is that it does not handle 
connections release. You must rely on the SO to release them (timeout).

Related thread: http://markmail.org/message/qgmdgqqxakio6fja

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: ofbiz HttpClient versus org.apache.commons.httpclient.HttpClient;


1) This is what I mean: 
http://hc.apache.org/httpclient-3.x/performance.html#Connection_persistence
In other words, not relying on the SO to release connections. Most of the time it's not a big deal, but in some cases this can be 
annoying

2) You are welcome https://issues.apache.org/jira/browse/OFBIZ-4430. Maybe it's 
not harder indeed...

Jacques

From: BJ Freeman bjf...@free-man.net

Ok a longer version of my terse reply.
there are two concerns in this thread you brought up.
1) TIMENOUT
2) implementing a different package that does not support the newer
java.nio.channel like the APJ does.
#1 is something than if you set to long it will waste response time, on
a bad connection, if to short will have the effect in the Email.
when I started in 96 the latency of the internet was uder 100 ms max.
Now the latency of the net is upwards of what used to be considered
intoloralbe latency (200 ms).
On top of that you have the Server response time which during the
Holidays gets really long so you will time out before the server
responds causing resends that only bog down the server more.
the above is a long winded way of saying your time out has to change
with the conditions.
#2 in looking at the http library they are still using the java.net for
connection. So in my estimation, we do a re-factor of ofbiz to java.nio
and fix the httpclient we have.


Jacques Le Roux sent the following on 9/17/2011 9:13 AM:

I'm resurrecting this thread because, as outlined by this other thread
http://markmail.org/message/j4s6tq2ccit3wtbf, unlike Apache
HttpClient, OFBiz's is not closing connections.
I have not the time at the moment to replace it, but I'd like to do so
in October or November. I will open a Jira then (this message
more as a self reminder...)

Interesting link also
http://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html

Jacques

From: BJ Freeman bjf...@free-man.net

I have done more investigation, and found the methods I depend on in the
jar come from java 1.31. in looking at the current httpclient, it does
not support the code I have.
I am not sure what I will do at this point but for the trunk it would be
best to use the current httpclient.
I am still going thru the current httpclient class in ofbiz to figure
out how is would be used, mostly in communication with third parties.

Adrian Crum sent the following on 10/23/2008 2:39 PM:

I was thinking we could deprecate the constructors, and point people to
the new class.

-Adrian

BJ Freeman wrote:

just as a note there are methods in the ofbiz one that work with ofbiz
structure. I would like to review those to see if they can be used
I guess the proper steps is to depreciate those.

BJ Freeman sent the following on 10/23/2008 1:47 PM:

works for me.
it has been moved around
found it under
http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/module-client/




Adrian Crum sent the following on 10/23/2008 1:37 PM:

I'd rather switch to the commons one and eliminate the OFBiz one.
It's
only used in one or two places, so it wouldn't be a difficult
change to
make.

-Adrian

BJ Freeman wrote:

I have been looking at HTMLUnit since our last conversation, for
implementing user test screens.
this is more that there are two HttpClient classes and the ofbiz
one is
used in the framework.
it seemed the simplest solution would be to use implements to
append the
 apache one to the ofbiz one thus making the ofbiz one more
versatile.

Adrian Crum sent the following on 10/23/2008 1:06 PM:

I would recommend using any suitable replacement for the OFBiz
HttpClient - it is very rudimentary.

If you need an HTTP client that handles cookies and JavaScript,
then
take a look at HTMLUnit - http://htmlunit.sourceforge.net. I used
it in
my mashup POC code -
https://issues.apache.org/jira/browse/OFBIZ-1873.

-Adrian

BJ Freeman wrote:

while working with yahoo API
I came accross the org.apache.commons.httpclient.HttpClient;
which has more functionality than the ofbiz HttpClient
is there any problem with making the ofbiz an HttpClient
implementation
of the apache?

Re: widgetVerbose

I as sorry i do not see the problem here.

as long as the properties setting in the trunk will show or hide all
widget comments (so in the trunk NO override) then it is fine.

why? because i think an override is an overkill anyway

Regards,
Hans


On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
 Yes, but I guess we will set widget.verbose in the properties file to true 
 (as we do for all defaults to be dev friendly). Will that 
 suit Hans? Else why do you Hans ask for now overriding in web.xml? For 
 instance what for Birt by defaut? Why not keeping the example 
 in example component commented out? Waht for testtools? Not sure why it's 
 false in googlecheckout but I guess there is a reason..
 
 In other word I guess Hans expect widget.verbose in the properties file to be 
 false...
 
 Jacques
 
 From: Adrian Crum adrian.c...@sandglass-software.com
  Let's see if we can bring this to a happy ending.
 
  If the widget.verbose setting in the properties file is false, then it 
  overrides any other setting and all boundary comments are 
  shut off.
 
  If the widget.verbose setting in the properties file is true, then it 
  follows the previous pattern, where true is the default, but 
  it can be overridden in web.xml and in the context Map.
 
  Will that work for everyone?
 
  -Adrian
 
  On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
  I am going to feel bad if I don't add my 2 cents to this thread :-)
  I agree with Jacques that the formatting of boundary comments should be 
  output specific (i.e no output for CSV etc...) instead of 
  always rendering as html comments.
  As regards the logic to determine if comments should be enabled or not, I 
  don't have a strong opinion because I have always used 
  this feature in a very rough way (enable all or disable all); however I 
  can understand the we may want to avoid that (when 
  widget.properties.enableBoundaryComments == false) the comments are 
  enabled by passing a URL parameter to the screen.
 
  Kind regards,
 
  Jacopo
 
  On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
 
  Someone I work with suggested:
 
  I have to point out though that I kind of agree with the way David put it 
  in that the false setting could have a priority, 
  i.e. it's like in security permissions where deny has precedence over 
  allow, so if you set it in widget.properties to false 
  then you're sure comments will never be enabled anywhere... security-wise 
  it makes sense despite the comment about qc...
 
  Maybe something like this? (compromise between the two)
 
  if (widget.properties.enableBoundaryComments == false
 || web.xml.enableBoundaryComments == false
 || context.enableBoundaryComments == false) {
 return false;
  } else { // This is the solution Scott wrote, but use overriding settings 
  only for null and true values
 if (context.enableBoundaryComments != null) return 
  context.enableBoundaryComments;
 if (web.xml.enableBoundaryComments != null) return 
  web.xml.enableBoundaryComments;
 if (widget.properties.enableBoundaryComments != null) return 
  widget.properties.enableBoundaryComments;
 return false;
  }
 
  Could probably rewrite that to be less redundant but you get the idea...
 
  jleroux: I quickly reformated my own way ;o), It seems a good idea to me, 
  what do you think?
 
  Also my colleague also wrote:
  Only thing I have to add is that I didn't see anyone address the issue 
  that HTML comments are outputted for CSV (because there's 
  nocsv  element and you have to usehtml) element. No matter what 
  widget.verbose is set to, there should never be HTmL 
  comments outputted for csv. so this only addresses half the bugs...
 
  We have no patches so far...
 
  Jacques
 
 
 
  Dimitri Unruh wrote:
  +1
 
 
  Dimitri Unruh
  Consultant AEW
  Lynx-Consulting GmbH
  Johanniskirchplatz 6
  33615 Bielefeld
  Deutschland
  Fon: +49 521 5247-0
  Fax: +49 521 5247-250
  Mobil: +49 160 90 57 55 13
 
 
  Company and Management Headquarters:
  Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland
  Fon: +49 521 5247-0, Fax: +49 521 5247-250, www.lynx.de
 
  Court Registration: Amtsgericht Bielefeld HRB 35946
  Chief Executive Officers: Karsten Noss, Dirk Osterkamp
 
 
  http://www.lynx.de/haftungsausschluss
 
 
  Wir laden Sie herzlich ein:
  DSAG-Jahreskongress
  Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle 2 Stand B01
 
  Besuchen Sie uns an unserem Stand und freuen Sie sich auf einen 
  intensiven Informations- und Erfahrungsaustausch rund um das
  Thema Mobility!
 
 
  Am 13.09.2011 um 14:35 schrieb Bilgin Ibryambibr...@gmail.com:
 
  On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
  adrian.c...@sandglass-software.com  wrote:
  Thanks Scott - those are my feelings exactly.
 
  I like the way the design worked previously, and changing it because a 
  user
  might accidentally leave the comments enabled in production seems 
  silly.
  That is a user's QC

[jira] [Created] (OFBIZ-4431) Error when deleting a product image from content

2011-09-19 Thread Sam Hamilton (JIRA)

Error when deleting a product image from content


 Key: OFBIZ-4431
 URL: https://issues.apache.org/jira/browse/OFBIZ-4431
 Project: OFBiz
  Issue Type: Bug
  Components: content
Affects Versions: SVN trunk
Reporter: Sam Hamilton
Priority: Minor


When you try and delete a product image e.g. 
https://localhost:8443/catalog/control/EditProductContent?productId=WG- the 
following error is produced in the log:

2011-09-19 15:41:47,793 (http-0.0.0.0-8443-8) [
Log.java:117:INFO ] [CommonPermissionServices.xml#genericBasePermissionCheck 
line 41] Checking for primary permission CATALOG_VIEW
2011-09-19 15:41:47,795 (http-0.0.0.0-8443-8) [ 
ServiceEcaRule.java:137:INFO ] For Service ECA [catalogPermissionCheck] on 
[return] got false for condition: [hasPermission][equals][false][true][Boolean]
2011-09-19 15:41:47,834 (http-0.0.0.0-8443-8) [   
ServerHitBin.java:627:INFO ] Visit delegatorName=default, ServerHitBin 
delegatorName=default
2011-09-19 15:41:47,840 (http-0.0.0.0-8443-8) [ 
ControlServlet.java:324:INFO ] [[[LookupProduct(Domain:https://localhost)] 
Request Done- total:0.067,since last([LookupProduct(Do...):0.067]]
2011-09-19 15:41:47,861 (http-0.0.0.0-8443-8) [ 
ControlServlet.java:141:INFO ] [[[LookupContent(Domain:https://localhost)] 
Request Begun, encoding=[UTF-8]- total:0.0,since last(Begin):0.0]]
2011-09-19 15:41:47,867 (http-0.0.0.0-8443-8) [ 
RequestHandler.java:750:INFO ] Rendering View [LookupContent], 
sessionId=863FB4E665376D4A9F650C1D4CF784B2.jvm1
2011-09-19 15:41:47,885 (http-0.0.0.0-8443-8) [   
ServerHitBin.java:627:INFO ] Visit delegatorName=default, ServerHitBin 
delegatorName=default
2011-09-19 15:41:47,891 (http-0.0.0.0-8443-8) [ 
ControlServlet.java:324:INFO ] [[[LookupContent(Domain:https://localhost)] 
Request Done- total:0.029,since last([LookupContent(Do...):0.029]]
2011-09-19 15:41:47,956 (http-0.0.0.0-8443-8) [ 
ControlServlet.java:141:INFO ] 
[[[removeContentFromProduct(Domain:https://localhost)] Request Begun, 
encoding=[UTF-8]- total:0.0,since last(Begin):0.0]]
2011-09-19 15:41:48,020 (http-0.0.0.0-8443-8) [   
ModelService.java:565:ERROR] [ModelService.validate] : {removeProductContent} : 
(IN) Required test error: org.ofbiz.service.ServiceValidationException: The 
following required parameter is missing: [IN] 
[removeProductContent.contentId]The following required parameter is missing: 
[IN] [removeProductContent.fromDate]The following required parameter is 
missing: [IN] [removeProductContent.productContentTypeId]The following required 
parameter is missing: [IN] [removeProductContent.productId]
2011-09-19 15:41:48,021 (http-0.0.0.0-8443-8) [  
ServiceDispatcher.java:381:ERROR] 
 exception report --
Incoming context (in runSync : removeProductContent) does not match expected 
requirements
Exception: org.ofbiz.service.ServiceValidationException
Message: The following required parameter is missing: [IN] 
[removeProductContent.contentId]The following required parameter is missing: 
[IN] [removeProductContent.fromDate]The following required parameter is 
missing: [IN] [removeProductContent.productContentTypeId]The following required 
parameter is missing: [IN] [removeProductContent.productId]
 stack trace ---
org.ofbiz.service.ServiceValidationException: The following required parameter 
is missing: [IN] [removeProductContent.contentId]The following required 
parameter is missing: [IN] [removeProductContent.fromDate]The following 
required parameter is missing: [IN] 
[removeProductContent.productContentTypeId]The following required parameter is 
missing: [IN] [removeProductContent.productId]
org.ofbiz.service.ModelService.validate(ModelService.java:626)
org.ofbiz.service.ModelService.validate(ModelService.java:562)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:379)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:226)
org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:163)
org.ofbiz.webapp.event.ServiceEventHandler.invoke(ServiceEventHandler.java:337)
org.ofbiz.webapp.control.RequestHandler.runEvent(RequestHandler.java:647)
org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:393)
org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:224)
javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:336)

[jira] [Updated] (OFBIZ-4432) Service setInvoiceStatus improved


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

Christian Fischer updated OFBIZ-4432:
-

Attachment: secas_olap.xml.patch

 Service setInvoiceStatus improved
 -

 Key: OFBIZ-4432
 URL: https://issues.apache.org/jira/browse/OFBIZ-4432
 Project: OFBiz
  Issue Type: Improvement
Reporter: Christian Fischer
 Attachments: secas_olap.xml.patch


 Event is now global-commit instead of commit.
 The service now starts only, when the invoice is created and is persistent.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: widgetVerbose


Hans,

Jacques gave some examples of where an override is currently used and 
why it is needed. Could you give us another reason besides i think an 
override is an overkill - like a reason based on a design issue or a 
real-world problem?


-Adrian

On 9/19/2011 7:55 AM, Hans Bakker wrote:

I as sorry i do not see the problem here.

as long as the properties setting in the trunk will show or hide all
widget comments (so in the trunk NO override) then it is fine.

why? because i think an override is an overkill anyway

Regards,
Hans


On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:

Yes, but I guess we will set widget.verbose in the properties file to true (as 
we do for all defaults to be dev friendly). Will that
suit Hans? Else why do you Hans ask for now overriding in web.xml? For instance 
what for Birt by defaut? Why not keeping the example
in example component commented out? Waht for testtools? Not sure why it's false 
in googlecheckout but I guess there is a reason..

In other word I guess Hans expect widget.verbose in the properties file to be 
false...

Jacques

From: Adrian Crumadrian.c...@sandglass-software.com

Let's see if we can bring this to a happy ending.

If the widget.verbose setting in the properties file is false, then it 
overrides any other setting and all boundary comments are
shut off.

If the widget.verbose setting in the properties file is true, then it follows 
the previous pattern, where true is the default, but
it can be overridden in web.xml and in the context Map.

Will that work for everyone?

-Adrian

On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:

I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments should be output 
specific (i.e no output for CSV etc...) instead of
always rendering as html comments.
As regards the logic to determine if comments should be enabled or not, I don't 
have a strong opinion because I have always used
this feature in a very rough way (enable all or disable all); however I can 
understand the we may want to avoid that (when
widget.properties.enableBoundaryComments == false) the comments are enabled by 
passing a URL parameter to the screen.

Kind regards,

Jacopo

On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:


Someone I work with suggested:

I have to point out though that I kind of agree with the way David put it in that the 
false setting could have a priority,
i.e. it's like in security permissions where deny has precedence over allow, 
so if you set it in widget.properties to false
then you're sure comments will never be enabled anywhere... security-wise it 
makes sense despite the comment about qc...

Maybe something like this? (compromise between the two)

if (widget.properties.enableBoundaryComments == false
|| web.xml.enableBoundaryComments == false
|| context.enableBoundaryComments == false) {
return false;
} else { // This is the solution Scott wrote, but use overriding settings only 
for null and true values
if (context.enableBoundaryComments != null) return 
context.enableBoundaryComments;
if (web.xml.enableBoundaryComments != null) return 
web.xml.enableBoundaryComments;
if (widget.properties.enableBoundaryComments != null) return 
widget.properties.enableBoundaryComments;
return false;
}

Could probably rewrite that to be less redundant but you get the idea...

jleroux: I quickly reformated my own way ;o), It seems a good idea to me, what 
do you think?

Also my colleague also wrote:
Only thing I have to add is that I didn't see anyone address the issue that 
HTML comments are outputted for CSV (because there's
nocsv   element and you have to usehtml) element. No matter what 
widget.verbose is set to, there should never be HTmL
comments outputted for csv. so this only addresses half the bugs...

We have no patches so far...

Jacques



Dimitri Unruh wrote:

+1


Dimitri Unruh
Consultant AEW
Lynx-Consulting GmbH
Johanniskirchplatz 6
33615 Bielefeld
Deutschland
Fon: +49 521 5247-0
Fax: +49 521 5247-250
Mobil: +49 160 90 57 55 13


Company and Management Headquarters:
Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland
Fon: +49 521 5247-0, Fax: +49 521 5247-250, www.lynx.de

Court Registration: Amtsgericht Bielefeld HRB 35946
Chief Executive Officers: Karsten Noss, Dirk Osterkamp


http://www.lynx.de/haftungsausschluss


Wir laden Sie herzlich ein:
DSAG-Jahreskongress
Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle 2 Stand B01

Besuchen Sie uns an unserem Stand und freuen Sie sich auf einen intensiven 
Informations- und Erfahrungsaustausch rund um das
Thema Mobility!


Am 13.09.2011 um 14:35 schrieb Bilgin Ibryambibr...@gmail.com:


On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
adrian.c...@sandglass-software.com   wrote:

Thanks Scott - those are my feelings exactly.

I like the way the design worked previously, and changing it because a user
might accidentally

[jira] [Created] (OFBIZ-4433) product.groovy improved

product.groovy improved
---

 Key: OFBIZ-4433
 URL: https://issues.apache.org/jira/browse/OFBIZ-4433
 Project: OFBiz
  Issue Type: Improvement
Reporter: Christian Fischer
 Attachments: Product.groovy.patch

Productname now comes from the content instead of the entity,

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4433) product.groovy improved


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

Christian Fischer updated OFBIZ-4433:
-

Attachment: Product.groovy.patch

 product.groovy improved
 ---

 Key: OFBIZ-4433
 URL: https://issues.apache.org/jira/browse/OFBIZ-4433
 Project: OFBiz
  Issue Type: Improvement
Reporter: Christian Fischer
 Attachments: Product.groovy.patch


 Productname now comes from the content instead of the entity,

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4433) product.groovy improved


[ 
https://issues.apache.org/jira/browse/OFBIZ-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107709#comment-13107709
 ] 

Adrian Crum commented on OFBIZ-4433:


Why is this change needed? And why is the issue marked as Resolved?


 product.groovy improved
 ---

 Key: OFBIZ-4433
 URL: https://issues.apache.org/jira/browse/OFBIZ-4433
 Project: OFBiz
  Issue Type: Improvement
Reporter: Christian Fischer
 Attachments: Product.groovy.patch


 Productname now comes from the content instead of the entity,

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: widgetVerbose

If i use the widget comments option i want it to be generally applied
and taken away depending on the properties setting. I do not want to
find out that somewhere it is not following the setting, then have to
dig in the code and find out that is, because somebody put an
undocumented override somewhere by default as happened the first time.
Bird and google checkout is fine.

I think how it is implemented now is fine. I hope i commented now
enough?

Regards,
Hans

On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
 Hans,
 
 Jacques gave some examples of where an override is currently used and 
 why it is needed. Could you give us another reason besides i think an 
 override is an overkill - like a reason based on a design issue or a 
 real-world problem?
 
 -Adrian
 
 On 9/19/2011 7:55 AM, Hans Bakker wrote:
  I as sorry i do not see the problem here.
 
  as long as the properties setting in the trunk will show or hide all
  widget comments (so in the trunk NO override) then it is fine.
 
  why? because i think an override is an overkill anyway
 
  Regards,
  Hans
 
 
  On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
  Yes, but I guess we will set widget.verbose in the properties file to true 
  (as we do for all defaults to be dev friendly). Will that
  suit Hans? Else why do you Hans ask for now overriding in web.xml? For 
  instance what for Birt by defaut? Why not keeping the example
  in example component commented out? Waht for testtools? Not sure why it's 
  false in googlecheckout but I guess there is a reason..
 
  In other word I guess Hans expect widget.verbose in the properties file to 
  be false...
 
  Jacques
 
  From: Adrian Crumadrian.c...@sandglass-software.com
  Let's see if we can bring this to a happy ending.
 
  If the widget.verbose setting in the properties file is false, then it 
  overrides any other setting and all boundary comments are
  shut off.
 
  If the widget.verbose setting in the properties file is true, then it 
  follows the previous pattern, where true is the default, but
  it can be overridden in web.xml and in the context Map.
 
  Will that work for everyone?
 
  -Adrian
 
  On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
  I am going to feel bad if I don't add my 2 cents to this thread :-)
  I agree with Jacques that the formatting of boundary comments should be 
  output specific (i.e no output for CSV etc...) instead of
  always rendering as html comments.
  As regards the logic to determine if comments should be enabled or not, 
  I don't have a strong opinion because I have always used
  this feature in a very rough way (enable all or disable all); however I 
  can understand the we may want to avoid that (when
  widget.properties.enableBoundaryComments == false) the comments are 
  enabled by passing a URL parameter to the screen.
 
  Kind regards,
 
  Jacopo
 
  On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
 
  Someone I work with suggested:
 
  I have to point out though that I kind of agree with the way David put 
  it in that the false setting could have a priority,
  i.e. it's like in security permissions where deny has precedence over 
  allow, so if you set it in widget.properties to false
  then you're sure comments will never be enabled anywhere... 
  security-wise it makes sense despite the comment about qc...
 
  Maybe something like this? (compromise between the two)
 
  if (widget.properties.enableBoundaryComments == false
  || web.xml.enableBoundaryComments == false
  || context.enableBoundaryComments == false) {
  return false;
  } else { // This is the solution Scott wrote, but use overriding 
  settings only for null and true values
  if (context.enableBoundaryComments != null) return 
  context.enableBoundaryComments;
  if (web.xml.enableBoundaryComments != null) return 
  web.xml.enableBoundaryComments;
  if (widget.properties.enableBoundaryComments != null) return 
  widget.properties.enableBoundaryComments;
  return false;
  }
 
  Could probably rewrite that to be less redundant but you get the idea...
 
  jleroux: I quickly reformated my own way ;o), It seems a good idea to 
  me, what do you think?
 
  Also my colleague also wrote:
  Only thing I have to add is that I didn't see anyone address the issue 
  that HTML comments are outputted for CSV (because there's
  nocsv   element and you have to usehtml) element. No matter what 
  widget.verbose is set to, there should never be HTmL
  comments outputted for csv. so this only addresses half the bugs...
 
  We have no patches so far...
 
  Jacques
 
 
 
  Dimitri Unruh wrote:
  +1
 
 
  Dimitri Unruh
  Consultant AEW
  Lynx-Consulting GmbH
  Johanniskirchplatz 6
  33615 Bielefeld
  Deutschland
  Fon: +49 521 5247-0
  Fax: +49 521 5247-250
  Mobil: +49 160 90 57 55 13
 
 
  Company and Management Headquarters:
  Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, 
  Deutschland
  Fon: +49 521 5247-0, Fax: +49 521

[jira] [Reopened] (OFBIZ-4432) Service setInvoiceStatus improved


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

Christian Fischer reopened OFBIZ-4432:
--


needs to be tested

 Service setInvoiceStatus improved
 -

 Key: OFBIZ-4432
 URL: https://issues.apache.org/jira/browse/OFBIZ-4432
 Project: OFBiz
  Issue Type: Improvement
Reporter: Christian Fischer
 Attachments: secas_olap.xml.patch


 Event is now global-commit instead of commit.
 The service now starts only, when the invoice is created and is persistent.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4433) product.groovy improved


[ 
https://issues.apache.org/jira/browse/OFBIZ-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107714#comment-13107714
 ] 

Christian Fischer commented on OFBIZ-4433:
--

If you take the name frome the entity, you aren't able to take the localized 
names. This patch is useful, if you have different names for products in 
different languages.

To the Resolved-mark: I think, I interpreted it wrong. I thought,Resolved 
means, that its fixed and ready to be tested. Sorry for that, won't happen 
again.

 product.groovy improved
 ---

 Key: OFBIZ-4433
 URL: https://issues.apache.org/jira/browse/OFBIZ-4433
 Project: OFBiz
  Issue Type: Improvement
Reporter: Christian Fischer
 Attachments: Product.groovy.patch


 Productname now comes from the content instead of the entity,

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4433) product.groovy improved


[ 
https://issues.apache.org/jira/browse/OFBIZ-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107716#comment-13107716
 ] 

Adrian Crum commented on OFBIZ-4433:


You can localize entity fields by using the UI labels files. There are examples 
of this in code already.


 product.groovy improved
 ---

 Key: OFBIZ-4433
 URL: https://issues.apache.org/jira/browse/OFBIZ-4433
 Project: OFBiz
  Issue Type: Improvement
Reporter: Christian Fischer
 Attachments: Product.groovy.patch


 Productname now comes from the content instead of the entity,

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OFBIZ-4434) ajaxAutocompleteOptions.ftl

ajaxAutocompleteOptions.ftl
---

 Key: OFBIZ-4434
 URL: https://issues.apache.org/jira/browse/OFBIZ-4434
 Project: OFBiz
  Issue Type: Improvement
Reporter: Christian Fischer
 Attachments: ajaxAutocompleteOptions.ftl.patch

Before the patch, the content was made HTML-safe, what wasn't necessary for the 
autocomplete. Also, it displayed things like Fumlr, because it made the 
umlauts HTML-safe, too.
The patch uses the stringwrapper from the stringUtil.java to avoid the general 
HTML auto-encoding.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4434) ajaxAutocompleteOptions.ftl


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

Christian Fischer updated OFBIZ-4434:
-

Attachment: ajaxAutocompleteOptions.ftl.patch

 ajaxAutocompleteOptions.ftl
 ---

 Key: OFBIZ-4434
 URL: https://issues.apache.org/jira/browse/OFBIZ-4434
 Project: OFBiz
  Issue Type: Improvement
Reporter: Christian Fischer
 Attachments: ajaxAutocompleteOptions.ftl.patch


 Before the patch, the content was made HTML-safe, what wasn't necessary for 
 the autocomplete. Also, it displayed things like Fumlr, because it made 
 the umlauts HTML-safe, too.
 The patch uses the stringwrapper from the stringUtil.java to avoid the 
 general HTML auto-encoding.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4433) product.groovy improved


[ 
https://issues.apache.org/jira/browse/OFBIZ-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107722#comment-13107722
 ] 

Christian Fischer commented on OFBIZ-4433:
--

In this Patch we get a productName from Content. I dont think it is usefull to 
get individual ProductData from EntityLabels.

 product.groovy improved
 ---

 Key: OFBIZ-4433
 URL: https://issues.apache.org/jira/browse/OFBIZ-4433
 Project: OFBiz
  Issue Type: Improvement
Reporter: Christian Fischer
 Attachments: Product.groovy.patch


 Productname now comes from the content instead of the entity,

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4274) Implement a REST Servlet


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

Adrian Crum updated OFBIZ-4274:
---

Comment: was deleted

(was: REST payloads are a Map that contains the service parameters and service 
results.

XStream will be used for the XML representation:

http://xstream.codehaus.org/converters.html
)

 Implement a REST Servlet
 

 Key: OFBIZ-4274
 URL: https://issues.apache.org/jira/browse/OFBIZ-4274
 Project: OFBiz
  Issue Type: New Feature
  Components: framework
Reporter: Adrian Crum
Priority: Minor
 Attachments: RestExampleSchema.xsd, RestXmlRepresentation.xml, 
 rest-conf.xml


 Implement a REST servlet that will map REST requests to OFBiz services. 
 Details are in the comments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (OFBIZ-4274) Implement a REST Servlet

[
https://issues.apache.org/jira/browse/OFBIZ-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031517#comment-13031517
]

Adrian Crum edited comment on OFBIZ-4274 at 9/19/11 10:13 AM:
--

OFBiz services are based on the concept of Map In, Map Out. So the HTTP request
and response bodies are nothing more than the Maps going into and out of the
services. This simple approach leverages all of the existing OFBiz service
documentation and web tools - there is no new API to learn.

Representation handlers will convert the in/out Maps to various representations
- HTML, XML, JSON, etc. Applications can implement custom representation
handlers.

XStream will be used for the XML representation:

http://xstream.codehaus.org/converters.html

was (Author: adri...@hlmksw.com):
By default, request payloads (HTTP entity) are basically the target
service's parameters wrapped in the resource name. In an XML payload the
service parameters are child elements of the resource element (whose tag name
is the resource name). This approach leverages the existing service definitions
to define a REST resource API.

By default, response payloads are the service results. The service result Map
is converted to the requested media type.

In cases where the request payload is controlled by an external application, a
custom media handler can be provided for conversion. See the attached patch for
an example.

The servlet will support media handlers that convert payloads to/from media
types (XML, JSON). See the attached patch for an example.

Implement a REST Servlet

Key: OFBIZ-4274
URL: https://issues.apache.org/jira/browse/OFBIZ-4274
Project: OFBiz
Issue Type: New Feature
Components: framework
Reporter: Adrian Crum
Priority: Minor
Attachments: RestExampleSchema.xsd, RestXmlRepresentation.xml,
rest-conf.xml

Implement a REST servlet that will map REST requests to OFBiz services.
Details are in the comments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4274) Implement a REST Servlet


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

Adrian Crum updated OFBIZ-4274:
---

Comment: was deleted

(was: RestXmlRepresentation.pdf is the proposed XML representation.
)

 Implement a REST Servlet
 

 Key: OFBIZ-4274
 URL: https://issues.apache.org/jira/browse/OFBIZ-4274
 Project: OFBiz
  Issue Type: New Feature
  Components: framework
Reporter: Adrian Crum
Priority: Minor
 Attachments: RestExampleSchema.xsd, RestXmlRepresentation.xml, 
 rest-conf.xml


 Implement a REST servlet that will map REST requests to OFBiz services. 
 Details are in the comments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (OFBIZ-4274) Implement a REST Servlet


[ 
https://issues.apache.org/jira/browse/OFBIZ-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031141#comment-13031141
 ] 

Adrian Crum edited comment on OFBIZ-4274 at 9/19/11 10:15 AM:
--

The attached files show how the Example component can support REST requests.



  was (Author: adri...@hlmksw.com):
RestConfig.patch is a POC configuration that shows how the Example 
component can support REST requests.


  
 Implement a REST Servlet
 

 Key: OFBIZ-4274
 URL: https://issues.apache.org/jira/browse/OFBIZ-4274
 Project: OFBiz
  Issue Type: New Feature
  Components: framework
Reporter: Adrian Crum
Priority: Minor
 Attachments: RestExampleSchema.xsd, RestXmlRepresentation.xml, 
 rest-conf.xml


 Implement a REST servlet that will map REST requests to OFBiz services. 
 Details are in the comments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4274) Implement a REST Servlet


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

Adrian Crum updated OFBIZ-4274:
---

Comment: was deleted

(was: Replaced PDF file with original XML file.)

 Implement a REST Servlet
 

 Key: OFBIZ-4274
 URL: https://issues.apache.org/jira/browse/OFBIZ-4274
 Project: OFBiz
  Issue Type: New Feature
  Components: framework
Reporter: Adrian Crum
Priority: Minor
 Attachments: RestExampleSchema.xsd, RestXmlRepresentation.xml, 
 rest-conf.xml


 Implement a REST servlet that will map REST requests to OFBiz services. 
 Details are in the comments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4274) Implement a REST Servlet


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

Adrian Crum updated OFBIZ-4274:
---

Comment: was deleted

(was: Updated patch and PDF file so anyone who is interested can see the 
configuration file without applying the patch.
)

 Implement a REST Servlet
 

 Key: OFBIZ-4274
 URL: https://issues.apache.org/jira/browse/OFBIZ-4274
 Project: OFBiz
  Issue Type: New Feature
  Components: framework
Reporter: Adrian Crum
Priority: Minor
 Attachments: RestExampleSchema.xsd, RestXmlRepresentation.xml, 
 rest-conf.xml


 Implement a REST servlet that will map REST requests to OFBiz services. 
 Details are in the comments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4274) Implement a REST Servlet


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

Adrian Crum updated OFBIZ-4274:
---

Comment: was deleted

(was: Updated POC config patch.
)

 Implement a REST Servlet
 

 Key: OFBIZ-4274
 URL: https://issues.apache.org/jira/browse/OFBIZ-4274
 Project: OFBiz
  Issue Type: New Feature
  Components: framework
Reporter: Adrian Crum
Priority: Minor
 Attachments: RestExampleSchema.xsd, RestXmlRepresentation.xml, 
 rest-conf.xml


 Implement a REST servlet that will map REST requests to OFBiz services. 
 Details are in the comments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4274) Implement a REST Servlet


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

Adrian Crum updated OFBIZ-4274:
---

Attachment: (was: RestXmlRepresentation.xml)

 Implement a REST Servlet
 

 Key: OFBIZ-4274
 URL: https://issues.apache.org/jira/browse/OFBIZ-4274
 Project: OFBiz
  Issue Type: New Feature
  Components: framework
Reporter: Adrian Crum
Priority: Minor
 Attachments: RestExampleSchema.xsd, RestXmlRepresentation.xml, 
 rest-conf.xml


 Implement a REST servlet that will map REST requests to OFBiz services. 
 Details are in the comments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4274) Implement a REST Servlet


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

Adrian Crum updated OFBIZ-4274:
---

Attachment: (was: RestExampleSchema.xsd)

 Implement a REST Servlet
 

 Key: OFBIZ-4274
 URL: https://issues.apache.org/jira/browse/OFBIZ-4274
 Project: OFBiz
  Issue Type: New Feature
  Components: framework
Reporter: Adrian Crum
Priority: Minor
 Attachments: RestExampleSchema.xsd, RestXmlRepresentation.xml, 
 rest-conf.xml


 Implement a REST servlet that will map REST requests to OFBiz services. 
 Details are in the comments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4274) Implement a REST Servlet


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

Adrian Crum updated OFBIZ-4274:
---

Attachment: RestXmlRepresentation.xml
RestExampleSchema.xsd

 Implement a REST Servlet
 

 Key: OFBIZ-4274
 URL: https://issues.apache.org/jira/browse/OFBIZ-4274
 Project: OFBiz
  Issue Type: New Feature
  Components: framework
Reporter: Adrian Crum
Priority: Minor
 Attachments: RestExampleSchema.xsd, RestXmlRepresentation.xml, 
 rest-conf.xml


 Implement a REST servlet that will map REST requests to OFBiz services. 
 Details are in the comments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (OFBIZ-4274) Implement a REST Servlet

[
https://issues.apache.org/jira/browse/OFBIZ-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13105193#comment-13105193
]

Adrian Crum edited comment on OFBIZ-4274 at 9/19/11 10:19 AM:
--

A clear distinction needs to be made between HTTP status and service status.
OFBiz service results will not be used to modify the HTTP response status. The
service results are contained within the response body - so there is no need to
manipulate the HTTP response status. If the request is sent to a valid URL, and
if the service was invoked successfully, then the HTTP response status will be
200 (OK). The HTTP response status will be used as intended - to indicate an
invalid URL (404), user is not authenticated (401), an exception was thrown
while processing the request (500), etc. If a service returns an error, then
the HTTP response status will be 200 (OK) and the response body will contain
the service results - which will describe the error.

was (Author: adri...@hlmksw.com):
A clear distinction needs to be made between HTTP status and service
status. OFBiz service results will not be used to modify the HTTP response
status. The service results are contained within the response payload - so
there is no need to manipulate the HTTP response status. If the request is sent
to a valid URL, and if the service was invoked successfully, then the HTTP
response status will be 200 (OK). The HTTP response status will be used as
intended - to indicate an invalid URL (404), user is not authenticated (401),
an exception was thrown while processing the request (500), etc. If a service
returns an error, then the HTTP response status will be 200 (OK) and the
response body will contain the service results - which will describe the error.

Implement a REST Servlet

Implement a REST servlet that will map REST requests to OFBiz services.
Details are in the comments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (OFBIZ-4274) Implement a REST Servlet


[ 
https://issues.apache.org/jira/browse/OFBIZ-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102570#comment-13102570
 ] 

Adrian Crum edited comment on OFBIZ-4274 at 9/19/11 10:19 AM:
--

A nice feature to have would be the ability to support dynamic XML stylesheets 
so that REST XML clients can validate request/response bodies. The body XML 
would contain the stylesheet reference URL, and the servlet would create a 
stylesheet based on the REST configuration file/service definition.

Example XML request payload:

{code}
post xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;

xsi:noNamespaceSchemaLocation=http://localhost/webtools/entities/orderheaders/post.xsd;
...
/post
{code}



  was (Author: adri...@hlmksw.com):
A nice feature to have would be the ability to support dynamic XML 
stylesheets so that REST XML clients can validate request/response payloads. 
The payload XML would contain the stylesheet reference URL, and the servlet 
would create a stylesheet based on the REST configuration file/service 
definition.

Example XML request payload:

{code}
post xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;

xsi:noNamespaceSchemaLocation=http://localhost/webtools/entities/orderheaders/post.xsd;
...
/post
{code}


  
 Implement a REST Servlet
 

 Key: OFBIZ-4274
 URL: https://issues.apache.org/jira/browse/OFBIZ-4274
 Project: OFBiz
  Issue Type: New Feature
  Components: framework
Reporter: Adrian Crum
Priority: Minor
 Attachments: RestExampleSchema.xsd, RestXmlRepresentation.xml, 
 rest-conf.xml


 Implement a REST servlet that will map REST requests to OFBiz services. 
 Details are in the comments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

REST Servlet


Hi All.

I apologize for all the noise from Jira - I am finished with the high 
level REST servlet design and I wanted to clean up the issue so it would 
be easier to read.


I know everyone is busy, but if you could spare a few minutes to take a 
look at the proposed REST servlet design I would really appreciate it:


https://issues.apache.org/jira/browse/OFBIZ-4274

-Adrian

[jira] [Reopened] (OFBIZ-4433) product.groovy improved


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

Jacques Le Roux reopened OFBIZ-4433:



 product.groovy improved
 ---

 Key: OFBIZ-4433
 URL: https://issues.apache.org/jira/browse/OFBIZ-4433
 Project: OFBiz
  Issue Type: Improvement
Reporter: Christian Fischer
 Attachments: Product.groovy.patch


 Productname now comes from the content instead of the entity,

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4433) product.groovy improved


[ 
https://issues.apache.org/jira/browse/OFBIZ-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107732#comment-13107732
 ] 

Jacques Le Roux commented on OFBIZ-4433:


Aboutthe Resolved status: if you provide a patch you should rather use Patch 
provided status

 product.groovy improved
 ---

 Key: OFBIZ-4433
 URL: https://issues.apache.org/jira/browse/OFBIZ-4433
 Project: OFBiz
  Issue Type: Improvement
Reporter: Christian Fischer
 Attachments: Product.groovy.patch


 Productname now comes from the content instead of the entity,

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (OFBIZ-4433) product.groovy improved


[ 
https://issues.apache.org/jira/browse/OFBIZ-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107732#comment-13107732
 ] 

Jacques Le Roux edited comment on OFBIZ-4433 at 9/19/11 10:28 AM:
--

Aboutthe Resolved status: if you provide a patch you should rather use Patch 
provided status

Edit I meaned Patch available

  was (Author: jacques.le.roux):
Aboutthe Resolved status: if you provide a patch you should rather use 
Patch provided status
  
 product.groovy improved
 ---

 Key: OFBIZ-4433
 URL: https://issues.apache.org/jira/browse/OFBIZ-4433
 Project: OFBiz
  Issue Type: Improvement
Reporter: Christian Fischer
 Attachments: Product.groovy.patch


 Productname now comes from the content instead of the entity,

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OFBIZ-4435) Fixed typo in ProductionRun class.

2011-09-19 Thread Deepak Dixit (JIRA)

Fixed typo in ProductionRun class.
--

 Key: OFBIZ-4435
 URL: https://issues.apache.org/jira/browse/OFBIZ-4435
 Project: OFBiz
  Issue Type: Bug
  Components: manufacturing
Reporter: Deepak Dixit
Priority: Minor
 Fix For: Release Branch 09.04, Release Branch 10.04, Release 
Branch 11.04, SVN trunk




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4435) Fixed typo in ProductionRun class.

2011-09-19 Thread Deepak Dixit (JIRA)


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

Deepak Dixit updated OFBIZ-4435:


Attachment: OFBIZ-4435.patch
OFBIZ-4435-Trunk.patch

OFBIZ-4435-Trunk.patch for latest trunk.
OFBIZ-4435.patch for release 9.04, release 10.04 and release 11.04.

 Fixed typo in ProductionRun class.
 --

 Key: OFBIZ-4435
 URL: https://issues.apache.org/jira/browse/OFBIZ-4435
 Project: OFBiz
  Issue Type: Bug
  Components: manufacturing
Reporter: Deepak Dixit
Priority: Minor
 Fix For: Release Branch 09.04, Release Branch 10.04, Release 
 Branch 11.04, SVN trunk

 Attachments: OFBIZ-4435-Trunk.patch, OFBIZ-4435.patch




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4296) JmsTopicListener started twice when distributed-cache-clear is active

2011-09-19 Thread Dimitri Unruh (JIRA)


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

Dimitri Unruh updated OFBIZ-4296:
-

Attachment: OFBIZ-4296.patch

 JmsTopicListener started twice when distributed-cache-clear is active
 -

 Key: OFBIZ-4296
 URL: https://issues.apache.org/jira/browse/OFBIZ-4296
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: SVN trunk
Reporter: Martin Kreidenweis
Assignee: Jacques Le Roux
 Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk

 Attachments: OFBIZ-4296.patch, changeset_2683.patch


 This is a follow up issue of OFBIZ-3987 and OFBIZ-4202. Apparently the 
 problem was not properly fixed. The infinite loop during startup went away, 
 but there still are other side effects. 
 Log output excerpt:
 {code}
 2011-05-26 09:43:56,336 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [ 
 JmsListenerFactory.java:64 :INFO ] Starting JMS Listener Factory Thread
 ...
 2011-05-26 09:44:00,499 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [ 
 JmsListenerFactory.java:64 :INFO ] Starting JMS Listener Factory Thread
 2011-05-26 09:44:01,076 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [ 
   JmsTopicListener.java:88 :INFO ] Listening to topic [ofbiz-cache] on 
 [activemq]...
 2011-05-26 09:44:01,111 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [ 
   JmsTopicListener.java:88 :INFO ] Listening to topic [ofbiz-cache] on 
 [activemq]...
 ...
 2011-05-26 09:44:21,081 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [ 
 JmsListenerFactory.java:74 :INFO ] JMS Listener Factory Thread Finished; All 
 listeners connected.
 2011-05-26 09:44:21,111 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [ 
 JmsListenerFactory.java:74 :INFO ] JMS Listener Factory Thread Finished; All 
 listeners connected.
 {code}
 What happens is this: 
 {{DelegatorFactory.getDelegator(default)}} is called during startup 
 (CatalinaContainer init). After creating the delegator and putting it in the 
 cache it calls {{delegator.initEntityEcaHandler()}}. Somewhere inside it 
 tries to get a dispatcher, so the first ServiceDispatcher instance is 
 initialized. Inside the constructor code the JobManager wants to access the 
 database and somewhere inside the {{EntityExpr}} another call to 
 {{DelegatorFactory.getDelegator(default)}} is done. As the ECAHandler is 
 already initialized it now initializes the DCC using 
 {{EntityCacheServices.setDelegator()}}. This creates the second 
 {{ServiceDispatcher}} instance and starts up the first {{JmsListenerFactory}} 
 thread. Further up the call stack, a little later the outer 
 {{ServiceDispatcher}} now also creates a {{JmsListenerFactory}} thread. So we 
 have two listeners and every JMS message is handled twice. 
 As a workaround we broke the recursion in the {{ServiceDispatcher}} 
 constructor by doing a lazy initialization of the dispatcher in 
 {{EntityCacheServices}}: We moved the call to 
 {{EntityServiceFactory.getLocalDispatcher(delegator)}} out from the 
 {{setDelegator}} method to when it is first needed. 
 This doesn't seem like the proper solution, though. Maybe someone with more 
 insight on how all the initialization of the dispatcher and delegator works 
 can contribute a proper fix. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4386) Order not completed when filled from more than one InventoryItem

[
https://issues.apache.org/jira/browse/OFBIZ-4386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107748#comment-13107748
]

Paul Foxworthy commented on OFBIZ-4386:
---

Hi Jacques,

The same line was in the patch for OFBIZ-4344 committed in r1167517. I'll
refresh the patch against the latest trunk and remove that line.

Cheers

Paul Foxworthy

Order not completed when filled from more than one InventoryItem

Key: OFBIZ-4386
URL: https://issues.apache.org/jira/browse/OFBIZ-4386
Project: OFBiz
Issue Type: Bug
Affects Versions: SVN trunk
Environment: rev 1163479
Reporter: Paul Foxworthy
Assignee: Jacques Le Roux
Labels: issuance, order, shipment
Attachments: OFBIZ-4386_IssuanceServices.patch,
OFBIZ-4386_IssuanceServices.patch, OFBIZ-4386_IssuanceServices.patch,
OFBIZ-4386_IssuanceTests.patch

There is a nasty bug in IssuanceServices in the situation where the order is
filled from more than one InventoryItem. When the order is created, there are
OrderItemShipGrpInvRes reservations created for all the inventory items
needed to fill the order.
In the simple method issueOrderItemShipGrpInvResToShipment in
IssuanceServices, at line 173
(https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/product/script/org/ofbiz/shipment/issuance/IssuanceServices.xml?hb=true#to173),
there is an assumption that if the OrderShipment already exists, we are some
sort of adjustment, and we should adjust the OrderShipment quantity by the
difference between the old OrderShipment quantity and the new one. This all
works fine in the situation where there is only one InventoryItem needed to
fill the order. However, if there are two or more InventoryItems, the simple
method is called twice, and an incorrect quantity is calculated.
The crux of the problem is that OrderShipment doesn't care about
InventoryItems, so there will be only one OrderShipment row for a given
product. In contrast, ItemIssuance does care about InventoryItems, so there
will be more than one if the product is supplied from more than one
InventoryItem. The ItemIssuance code doesn't take account of this distinction.
I have provided two patches. One is a new unit test that exemplifies the bug.
If you just apply this patch to trunk, the unit test will fail with an
OrderShipment quantity of 4 when it ought to be 6.
The other patch is my fix for IssuanceServices, which now looks for a
relevant ItemIssuance to decide if we are adjusting quantities, or creating a
new ItemIssuance (and possibly a new OrderShipment).
Feedback welcomed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4296) JmsTopicListener started twice when distributed-cache-clear is active

2011-09-19 Thread Dimitri Unruh (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107749#comment-13107749
 ] 

Dimitri Unruh commented on OFBIZ-4296:
--

Jacques,

thank you for your comment.
I provided a new patch to resolve the listener problem.

Anyway, I would like to do some JMS handling improvements/refactoring and will 
open a new ticket for this


 JmsTopicListener started twice when distributed-cache-clear is active
 -

 Key: OFBIZ-4296
 URL: https://issues.apache.org/jira/browse/OFBIZ-4296
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: SVN trunk
Reporter: Martin Kreidenweis
Assignee: Jacques Le Roux
 Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk

 Attachments: OFBIZ-4296.patch, changeset_2683.patch


 This is a follow up issue of OFBIZ-3987 and OFBIZ-4202. Apparently the 
 problem was not properly fixed. The infinite loop during startup went away, 
 but there still are other side effects. 
 Log output excerpt:
 {code}
 2011-05-26 09:43:56,336 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [ 
 JmsListenerFactory.java:64 :INFO ] Starting JMS Listener Factory Thread
 ...
 2011-05-26 09:44:00,499 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [ 
 JmsListenerFactory.java:64 :INFO ] Starting JMS Listener Factory Thread
 2011-05-26 09:44:01,076 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [ 
   JmsTopicListener.java:88 :INFO ] Listening to topic [ofbiz-cache] on 
 [activemq]...
 2011-05-26 09:44:01,111 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [ 
   JmsTopicListener.java:88 :INFO ] Listening to topic [ofbiz-cache] on 
 [activemq]...
 ...
 2011-05-26 09:44:21,081 (org.ofbiz.service.jms.JmsListenerFactory@44648ff3) [ 
 JmsListenerFactory.java:74 :INFO ] JMS Listener Factory Thread Finished; All 
 listeners connected.
 2011-05-26 09:44:21,111 (org.ofbiz.service.jms.JmsListenerFactory@590e6359) [ 
 JmsListenerFactory.java:74 :INFO ] JMS Listener Factory Thread Finished; All 
 listeners connected.
 {code}
 What happens is this: 
 {{DelegatorFactory.getDelegator(default)}} is called during startup 
 (CatalinaContainer init). After creating the delegator and putting it in the 
 cache it calls {{delegator.initEntityEcaHandler()}}. Somewhere inside it 
 tries to get a dispatcher, so the first ServiceDispatcher instance is 
 initialized. Inside the constructor code the JobManager wants to access the 
 database and somewhere inside the {{EntityExpr}} another call to 
 {{DelegatorFactory.getDelegator(default)}} is done. As the ECAHandler is 
 already initialized it now initializes the DCC using 
 {{EntityCacheServices.setDelegator()}}. This creates the second 
 {{ServiceDispatcher}} instance and starts up the first {{JmsListenerFactory}} 
 thread. Further up the call stack, a little later the outer 
 {{ServiceDispatcher}} now also creates a {{JmsListenerFactory}} thread. So we 
 have two listeners and every JMS message is handled twice. 
 As a workaround we broke the recursion in the {{ServiceDispatcher}} 
 constructor by doing a lazy initialization of the dispatcher in 
 {{EntityCacheServices}}: We moved the call to 
 {{EntityServiceFactory.getLocalDispatcher(delegator)}} out from the 
 {{setDelegator}} method to when it is first needed. 
 This doesn't seem like the proper solution, though. Maybe someone with more 
 insight on how all the initialization of the dispatcher and delegator works 
 can contribute a proper fix. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4274) Implement a REST Servlet

2011-09-19 Thread Raj Saini (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107750#comment-13107750
 ] 

Raj Saini commented on OFBIZ-4274:
--

I am not the expert but one of my quick observation is RESTful responses should 
return HTTP status. HTTP response should be packaged as standard HTTP headers 
including status codes. http://restpatterns.org/HTTP_Status_Codes have lists of 
RESTful codes.

 Implement a REST Servlet
 

 Key: OFBIZ-4274
 URL: https://issues.apache.org/jira/browse/OFBIZ-4274
 Project: OFBiz
  Issue Type: New Feature
  Components: framework
Reporter: Adrian Crum
Priority: Minor
 Attachments: RestExampleSchema.xsd, RestXmlRepresentation.xml, 
 rest-conf.xml


 Implement a REST servlet that will map REST requests to OFBiz services. 
 Details are in the comments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4274) Implement a REST Servlet

[
https://issues.apache.org/jira/browse/OFBIZ-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107755#comment-13107755
]

Adrian Crum commented on OFBIZ-4274:

Raj,

I apologize if the design description was not clear about HTTP status codes.
Yes, of course HTTP status codes will be returned (since REST is nothing more
than HTTP 1.1).

What I tried to describe is the HTTP status code behavior when an OFBiz service
returns an error: The service error will not affect the HTTP status code.
Instead, a 200 HTTP status will be returned and the response body will contain
the result of the service call - which describes the error returned by the
service.

The reason why OFBiz service errors are handled this way should be obvious from
a web client perspective. If an OFBiz service returned an error and that error
resulted in an HTTP error status being returned, then how would a web client
(or developer) know what the service error was?

Implement a REST Servlet

Implement a REST servlet that will map REST requests to OFBiz services.
Details are in the comments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4386) Order not completed when filled from more than one InventoryItem

[
https://issues.apache.org/jira/browse/OFBIZ-4386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107758#comment-13107758
]

Jacques Le Roux commented on OFBIZ-4386:

Paul, it's already done in the last patch. I have just to review it again...

Order not completed when filled from more than one InventoryItem

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4386) Order not completed when filled from more than one InventoryItem

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

Paul Foxworthy updated OFBIZ-4386:
--

Attachment: OFBIZ-4386_IssuanceServices.patch

Order not completed when filled from more than one InventoryItem

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4386) Order not completed when filled from more than one InventoryItem

[
https://issues.apache.org/jira/browse/OFBIZ-4386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107762#comment-13107762
]

Paul Foxworthy commented on OFBIZ-4386:
---

Hi Jacques, I've uploaded one more. Refreshed against trunk, fixed one typo,
removed one line that was also in OFBIZ-4344.

Order not completed when filled from more than one InventoryItem

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: New link between communication event and sales opportunity


I did not look into details yet, but why SalesOpportunityWorkEffort exists if 
we don't use it?

Also I agree with Scott on
The business case could be redescribed as:
- Email Received (CommunicationEvent)
- WorkEffort created to handle the communication
- Communication deemed to be a sales opportunity and record is created

This is also what BJ outlined (the need of a WorkEffort)

Also Anne's remark about  Marketing Tasks on page 293 of Volume 2 of the Data Model book is worth reading (again WorkEffort), even 
if it's particularily in the Financials domain.


Jacques

From: Hans Bakker mailingl...@antwebsystems.com

Ok sounds fair, let wait for other comments.

On Thu, 2011-09-15 at 19:37 +1200, Scott Gray wrote:
Ask for comments and then ignore them, well done Hans.  If you don't have time to wait for opinions and have proper discussions 
then keep your changes local until you do.


Regards
Scott

On 15/09/2011, at 7:33 PM, Hans Bakker wrote:

 then we have to agree to disagree?

 Ok my last question, you are going to block this?'
 cannot spend too much time on this...


 Regards,
 Hans

 On Thu, 2011-09-15 at 19:08 +1200, Scott Gray wrote:
 It really doesn't seem very difficult to me and coupling SalesOpportunity and WorkEffort will give you much more flexibility 
 in the future.


 Regards
 Scott

 On 15/09/2011, at 7:00 PM, Hans Bakker wrote:

 I do not agree, i want to list all commevents on an opportunity which
 gets now too difficul

 Hans

 On Thu, 2011-09-15 at 18:19 +1200, Scott Gray wrote:
 Not necessarily every communication event, but if it requires action then a WorkEffort seems like the logic choice to track 
 the work done.


 If you were to send more emails in connection with the opportunity then 
they would be linked to the existing WorkEffort.

 Ask yourself this, why is there a SalesOpportunityWorkEffort entity?  What purpose does it fulfill if not the type of 
 problem that you are describing here?


 Regards
 Scott

 On 15/09/2011, at 6:10 PM, Hans Bakker wrote:

 Sure I am all in favor to use the existing datamodel, this means however
 that every communication event will have a workeffort connected to it
 because somebody has to handle it? sounds  a it bureaucratic?,

 then as a result of the creation of the opportunity more emails are sent
 from the opportunity, we need a workeffort to create another
 communication event? What kind of information the workeffort adds?

 Regards,
 Hans


 On Thu, 2011-09-15 at 17:37 +1200, Scott Gray wrote:
 It is possible to have a link between CommunicationEvent and SalesOpportunity via SalesOpportunityWorkEffort - 
 WorkEffort - CommunicationEventWorkEffort.


 The business case could be redescribed as:
 - Email Received (CommunicationEvent)
 - WorkEffort created to handle the communication
 - Communication deemed to be a sales opportunity and record is created

 Regards
 Scott

 On 15/09/2011, at 4:13 PM, Hans Bakker wrote:

 Business case:
 An email is received requesting more information about certain services
 where the originator could be interested in.
 The support person receives the email and creates an opportunity in SFA
 for the sales people.

 Problem:
 currently it is not possible to have a link between CommunicationEvent
 and SalesOpportunity entity.

 Proposal:
 create a new entity:
 SalesOpportCommEvent:
 key: salesOpportunityId, communicationEventId

 comments please?

 Regards,
 Hans


 -- 
 Ofbiz on twitter: http://twitter.com/apache_ofbiz

 Alternative ofbiz website: http://www.ofbiz.info
 http://www.antwebsystems.com : Quality services for competitive rates.



 -- 
 Ofbiz on twitter: http://twitter.com/apache_ofbiz

 Alternative ofbiz website: http://www.ofbiz.info
 http://www.antwebsystems.com : Quality services for competitive rates.



 -- 
 Ofbiz on twitter: http://twitter.com/apache_ofbiz

 Alternative ofbiz website: http://www.ofbiz.info
 http://www.antwebsystems.com : Quality services for competitive rates.



 -- 
 Ofbiz on twitter: http://twitter.com/apache_ofbiz

 Alternative ofbiz website: http://www.ofbiz.info
 http://www.antwebsystems.com : Quality services for competitive rates.




--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Alternative ofbiz website: http://www.ofbiz.info
http://www.antwebsystems.com : Quality services for competitive rates.

Re: REST Servlet


Unfortunately, I believe Hans's answer was


I think how it is implemented now is fine. I hope i commented now
enough?


In other words, he don't want to cvhange the way it's done at the moment. Did yo consider my proposition Adrian, Hans? I think 
it's a good compromise...


Jacques

From: Adrian Crum adrian.c...@sandglass-software.com

Hi All.

I apologize for all the noise from Jira - I am finished with the high level REST servlet design and I wanted to clean up the issue 
so it would be easier to read.


I know everyone is busy, but if you could spare a few minutes to take a look at the proposed REST servlet design I would really 
appreciate it:


https://issues.apache.org/jira/browse/OFBIZ-4274

-Adrian

Re: REST Servlet


Perhaps your reply was meant for another thread?

-Adrian

On 9/19/2011 1:10 PM, Jacques Le Roux wrote:

Unfortunately, I believe Hans's answer was


I think how it is implemented now is fine. I hope i commented now
enough?


In other words, he don't want to cvhange the way it's done at the 
moment. Did yo consider my proposition Adrian, Hans? I think it's a 
good compromise...


Jacques

From: Adrian Crum adrian.c...@sandglass-software.com

Hi All.

I apologize for all the noise from Jira - I am finished with the high 
level REST servlet design and I wanted to clean up the issue so it 
would be easier to read.


I know everyone is busy, but if you could spare a few minutes to take 
a look at the proposed REST servlet design I would really appreciate it:


https://issues.apache.org/jira/browse/OFBIZ-4274

-Adrian

[jira] [Updated] (OFBIZ-4427) Possible runtime errors with UtilValidate.isEmpty(Object) should be rather caught during compilation


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

Paul Foxworthy updated OFBIZ-4427:
--

Attachment: OFBIZ-4427.patch

I tried commenting out isEmpty( Object ) and isNotEmpty(Object), and here's a 
patch for the first few problems I found. Plenty more to be done!

 Possible runtime errors with UtilValidate.isEmpty(Object) should be rather 
 caught during compilation
 

 Key: OFBIZ-4427
 URL: https://issues.apache.org/jira/browse/OFBIZ-4427
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
Reporter: Jacques Le Roux
Priority: Minor
  Labels: UtilValidate.isEmpty
 Fix For: SVN trunk

 Attachments: OFBIZ-4427.patch


 Hence we need tp remove the UtilValidate.isEmpty(Object) method and provide 
 methods that accept explicit types.  
 Scripting languages should use a facade class that provides methods for 
 working with generic Objects or providing default behaviors.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4427) Possible runtime errors with UtilValidate.isEmpty(Object) should be rather caught during compilation

[
https://issues.apache.org/jira/browse/OFBIZ-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107806#comment-13107806
]

Paul Foxworthy commented on OFBIZ-4427:
---

https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/framework/base/src/org/ofbiz/base/util/UtilHttp.java?r=1170525#to614
has a call to UtilValidate.isEmpty with appDefaultLocale, which was declared
as Object. Can it be tightened to String? The call at
https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/product/src/org/ofbiz/product/store/ProductStoreWorker.java?r=1044931#to111
passes a String.

And thanks, Adrian. At a guess most of the 166 calls will be OK so there are a
manageable number to fix.

Possible runtime errors with UtilValidate.isEmpty(Object) should be rather
caught during compilation

Key: OFBIZ-4427
URL: https://issues.apache.org/jira/browse/OFBIZ-4427
Project: OFBiz
Issue Type: Improvement
Components: framework
Affects Versions: SVN trunk
Reporter: Jacques Le Roux
Priority: Minor
Labels: UtilValidate.isEmpty
Fix For: SVN trunk

Attachments: OFBIZ-4427.patch

Hence we need tp remove the UtilValidate.isEmpty(Object) method and provide
methods that accept explicit types.
Scripting languages should use a facade class that provides methods for
working with generic Objects or providing default behaviors.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: REST Servlet


Oops, indeed :/

Jacques

From: Adrian Crum adrian.c...@sandglass-software.com

Perhaps your reply was meant for another thread?

-Adrian

On 9/19/2011 1:10 PM, Jacques Le Roux wrote:

Unfortunately, I believe Hans's answer was


I think how it is implemented now is fine. I hope i commented now
enough?


In other words, he don't want to cvhange the way it's done at the 
moment. Did yo consider my proposition Adrian, Hans? I think it's a 
good compromise...


Jacques

From: Adrian Crum adrian.c...@sandglass-software.com

Hi All.

I apologize for all the noise from Jira - I am finished with the high 
level REST servlet design and I wanted to clean up the issue so it 
would be easier to read.


I know everyone is busy, but if you could spare a few minutes to take 
a look at the proposed REST servlet design I would really appreciate it:


https://issues.apache.org/jira/browse/OFBIZ-4274

-Adrian

Re: widgetVerbose


Unfortunately, I believe Hans's answer was


I think how it is implemented now is fine. I hope i commented now
enough?


In other words, he does not want to change the way it's done at the moment. Did yoy consider my proposition (based on Scott's) 
Adrian, Hans? I think it's a good compromise...


Jacques

From: Adrian Crum adrian.c...@sandglass-software.com

Hans,

We can document the behavior in the properties file, and we have this discussion on record to describe the behavior and the reason 
why it was done that way. I believe those things will help avoid confusion in the future.


So, can we implement the behavior I described? I believe you already answered this question, but I am asking again just to be 
sure.


-Adrian

On 9/19/2011 10:14 AM, Hans Bakker wrote:

If i use the widget comments option i want it to be generally applied
and taken away depending on the properties setting. I do not want to
find out that somewhere it is not following the setting, then have to
dig in the code and find out that is, because somebody put an
undocumented override somewhere by default as happened the first time.
Bird and google checkout is fine.

I think how it is implemented now is fine. I hope i commented now
enough?

Regards,
Hans

On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:

Hans,

Jacques gave some examples of where an override is currently used and
why it is needed. Could you give us another reason besides i think an
override is an overkill - like a reason based on a design issue or a
real-world problem?

-Adrian

On 9/19/2011 7:55 AM, Hans Bakker wrote:

I as sorry i do not see the problem here.

as long as the properties setting in the trunk will show or hide all
widget comments (so in the trunk NO override) then it is fine.

why? because i think an override is an overkill anyway

Regards,
Hans


On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
Yes, but I guess we will set widget.verbose in the properties file to true (as we do for all defaults to be dev friendly). 
Will that
suit Hans? Else why do you Hans ask for now overriding in web.xml? For instance what for Birt by defaut? Why not keeping the 
example
in example component commented out? Waht for testtools? Not sure why it's false in googlecheckout but I guess there is a 
reason..


In other word I guess Hans expect widget.verbose in the properties file to be 
false...

Jacques

From: Adrian Crumadrian.c...@sandglass-software.com

Let's see if we can bring this to a happy ending.

If the widget.verbose setting in the properties file is false, then it overrides any other setting and all boundary comments 
are

shut off.

If the widget.verbose setting in the properties file is true, then it follows the previous pattern, where true is the 
default, but

it can be overridden in web.xml and in the context Map.

Will that work for everyone?

-Adrian

On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:

I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments should be output specific (i.e no output for CSV etc...) 
instead of

always rendering as html comments.
As regards the logic to determine if comments should be enabled or not, I don't have a strong opinion because I have always 
used

this feature in a very rough way (enable all or disable all); however I can 
understand the we may want to avoid that (when
widget.properties.enableBoundaryComments == false) the comments are enabled by 
passing a URL parameter to the screen.

Kind regards,

Jacopo

On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:


Someone I work with suggested:

I have to point out though that I kind of agree with the way David put it in that the false setting could have a 
priority,
i.e. it's like in security permissions where deny has precedence over allow, so if you set it in widget.properties to 
false

then you're sure comments will never be enabled anywhere... security-wise it 
makes sense despite the comment about qc...

Maybe something like this? (compromise between the two)

if (widget.properties.enableBoundaryComments == false
 || web.xml.enableBoundaryComments == false
 || context.enableBoundaryComments == false) {
 return false;
} else { // This is the solution Scott wrote, but use overriding settings only 
for null and true values
 if (context.enableBoundaryComments != null) return 
context.enableBoundaryComments;
 if (web.xml.enableBoundaryComments != null) return 
web.xml.enableBoundaryComments;
 if (widget.properties.enableBoundaryComments != null) return 
widget.properties.enableBoundaryComments;
 return false;
}

Could probably rewrite that to be less redundant but you get the idea...

jleroux: I quickly reformated my own way ;o), It seems a good idea to me, what 
do you think?

Also my colleague also wrote:
Only thing I have to add is that I didn't see anyone address the issue that HTML comments are outputted for CSV (because 
there's

[jira] [Commented] (OFBIZ-4274) Implement a REST Servlet

2011-09-19 Thread Raj Saini (JIRA)

[
https://issues.apache.org/jira/browse/OFBIZ-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107812#comment-13107812
]

Raj Saini commented on OFBIZ-4274:
--

Adrian,

Thanks for the clarification.

There are RESTful client APIs in Java and other framework and developers may
want to take advantage of these APIs. These client API follow the RESTful
standard and they may depend on the HTTP headers and statuses. If we plan to
use the XML based packaging and error handing, it will become the
responsibility of the developer to handle all standard application errors at
application level instead of delegating it to application. Below is a code
snippet consuming RESTful services using Oracle Jersey client API. Client API
is trying to get the response status and I guess it is only possible if
response is a standard.

WebResource webResource = client.resource(http://example.com/base;);
ClientResponse response =
webResource.accept(text/plain).get(ClientResponse.class);
int status = response.getStatus();
String textEntity = response.getEntity(String.class);

Implement a REST Servlet

Implement a REST servlet that will map REST requests to OFBiz services.
Details are in the comments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: widgetVerbose

Jacques:

what i wrote?

 as long as the properties setting in the trunk will show or hide all
 widget comments (so in the trunk NO override) then it is fine.

Regards,
Hans

On Mon, 2011-09-19 at 15:24 +0200, Jacques Le Roux wrote:
 Unfortunately, I believe Hans's answer was
 
  I think how it is implemented now is fine. I hope i commented now
  enough?
 
 In other words, he does not want to change the way it's done at the moment. 
 Did yoy consider my proposition (based on Scott's) 
 Adrian, Hans? I think it's a good compromise...
 
 Jacques
 
 From: Adrian Crum adrian.c...@sandglass-software.com
  Hans,
 
  We can document the behavior in the properties file, and we have this 
  discussion on record to describe the behavior and the reason 
  why it was done that way. I believe those things will help avoid confusion 
  in the future.
 
  So, can we implement the behavior I described? I believe you already 
  answered this question, but I am asking again just to be 
  sure.
 
  -Adrian
 
  On 9/19/2011 10:14 AM, Hans Bakker wrote:
  If i use the widget comments option i want it to be generally applied
  and taken away depending on the properties setting. I do not want to
  find out that somewhere it is not following the setting, then have to
  dig in the code and find out that is, because somebody put an
  undocumented override somewhere by default as happened the first time.
  Bird and google checkout is fine.
 
  I think how it is implemented now is fine. I hope i commented now
  enough?
 
  Regards,
  Hans
 
  On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
  Hans,
 
  Jacques gave some examples of where an override is currently used and
  why it is needed. Could you give us another reason besides i think an
  override is an overkill - like a reason based on a design issue or a
  real-world problem?
 
  -Adrian
 
  On 9/19/2011 7:55 AM, Hans Bakker wrote:
  I as sorry i do not see the problem here.
 
  as long as the properties setting in the trunk will show or hide all
  widget comments (so in the trunk NO override) then it is fine.
 
  why? because i think an override is an overkill anyway
 
  Regards,
  Hans
 
 
  On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
  Yes, but I guess we will set widget.verbose in the properties file to 
  true (as we do for all defaults to be dev friendly). 
  Will that
  suit Hans? Else why do you Hans ask for now overriding in web.xml? For 
  instance what for Birt by defaut? Why not keeping the 
  example
  in example component commented out? Waht for testtools? Not sure why 
  it's false in googlecheckout but I guess there is a 
  reason..
 
  In other word I guess Hans expect widget.verbose in the properties file 
  to be false...
 
  Jacques
 
  From: Adrian Crumadrian.c...@sandglass-software.com
  Let's see if we can bring this to a happy ending.
 
  If the widget.verbose setting in the properties file is false, then it 
  overrides any other setting and all boundary comments 
  are
  shut off.
 
  If the widget.verbose setting in the properties file is true, then it 
  follows the previous pattern, where true is the 
  default, but
  it can be overridden in web.xml and in the context Map.
 
  Will that work for everyone?
 
  -Adrian
 
  On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
  I am going to feel bad if I don't add my 2 cents to this thread :-)
  I agree with Jacques that the formatting of boundary comments should 
  be output specific (i.e no output for CSV etc...) 
  instead of
  always rendering as html comments.
  As regards the logic to determine if comments should be enabled or 
  not, I don't have a strong opinion because I have always 
  used
  this feature in a very rough way (enable all or disable all); however 
  I can understand the we may want to avoid that (when
  widget.properties.enableBoundaryComments == false) the comments are 
  enabled by passing a URL parameter to the screen.
 
  Kind regards,
 
  Jacopo
 
  On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
 
  Someone I work with suggested:
 
  I have to point out though that I kind of agree with the way David 
  put it in that the false setting could have a 
  priority,
  i.e. it's like in security permissions where deny has precedence 
  over allow, so if you set it in widget.properties to 
  false
  then you're sure comments will never be enabled anywhere... 
  security-wise it makes sense despite the comment about qc...
 
  Maybe something like this? (compromise between the two)
 
  if (widget.properties.enableBoundaryComments == false
   || web.xml.enableBoundaryComments == false
   || context.enableBoundaryComments == false) {
   return false;
  } else { // This is the solution Scott wrote, but use overriding 
  settings only for null and true values
   if (context.enableBoundaryComments != null) return 
  context.enableBoundaryComments;
   if (web.xml.enableBoundaryComments != null) return

[jira] [Commented] (OFBIZ-4274) Implement a REST Servlet


[ 
https://issues.apache.org/jira/browse/OFBIZ-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107903#comment-13107903
 ] 

Adrian Crum commented on OFBIZ-4274:


Raj,

I understand what you are saying, but the OFBiz service result does not provide 
enough information to affect the HTTP response headers. For example, if a user 
was not authorized to create a resource, then an HTTP status code of 403 should 
be returned. The problem is, OFBiz services do not categorize results that way 
- the results are either success or error - so there is no way for the 
servlet to map service responses to HTTP status codes. We could introduce a new 
service return type - like not-authorized or something similar, but that 
would involve rewriting all of the OFBiz services. There is no one-to-one 
mapping of OFBiz service results to HTTP response codes.

As far as web client development is concerned, OFBiz REST client skeleton code 
could be provided to make development easier. There is nothing in the code 
snippet you provided that would prohibit a developer from connecting the Oracle 
Jersey client API to an OFBiz REST client API:

{code}

OFBizRestClientRepresentation orcr = new OFBizRestClientRepresentation(xml);
WebResource webResource = 
client.resource(https://localhost:8443/example/services/example;);
ClientResponse response = 
webResource.accept(orcr.getContentType()).get(ClientResponse.class);
orcr.setResponse(response);
if (orcr.success()) {
  // Process response
} else {
  // Process error
}

{code}



 Implement a REST Servlet
 

 Key: OFBIZ-4274
 URL: https://issues.apache.org/jira/browse/OFBIZ-4274
 Project: OFBiz
  Issue Type: New Feature
  Components: framework
Reporter: Adrian Crum
Priority: Minor
 Attachments: RestExampleSchema.xsd, RestXmlRepresentation.xml, 
 rest-conf.xml


 Implement a REST servlet that will map REST requests to OFBiz services. 
 Details are in the comments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: widgetVerbose

+1
KISS
one place to turn off and on. common sense says you use for development
then you turn it off so there are no comments in the ouput.
So there is not need to have the comments turned off at component level.


Hans Bakker sent the following on 9/19/2011 2:14 AM:
 If i use the widget comments option i want it to be generally applied
 and taken away depending on the properties setting. I do not want to
 find out that somewhere it is not following the setting, then have to
 dig in the code and find out that is, because somebody put an
 undocumented override somewhere by default as happened the first time.
 Bird and google checkout is fine.
 
 I think how it is implemented now is fine. I hope i commented now
 enough?
 
 Regards,
 Hans
 
 On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
 Hans,

 Jacques gave some examples of where an override is currently used and 
 why it is needed. Could you give us another reason besides i think an 
 override is an overkill - like a reason based on a design issue or a 
 real-world problem?

 -Adrian

 On 9/19/2011 7:55 AM, Hans Bakker wrote:
 I as sorry i do not see the problem here.

 as long as the properties setting in the trunk will show or hide all
 widget comments (so in the trunk NO override) then it is fine.

 why? because i think an override is an overkill anyway

 Regards,
 Hans


 On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
 Yes, but I guess we will set widget.verbose in the properties file to true 
 (as we do for all defaults to be dev friendly). Will that
 suit Hans? Else why do you Hans ask for now overriding in web.xml? For 
 instance what for Birt by defaut? Why not keeping the example
 in example component commented out? Waht for testtools? Not sure why it's 
 false in googlecheckout but I guess there is a reason..

 In other word I guess Hans expect widget.verbose in the properties file to 
 be false...

 Jacques

 From: Adrian Crumadrian.c...@sandglass-software.com
 Let's see if we can bring this to a happy ending.

 If the widget.verbose setting in the properties file is false, then it 
 overrides any other setting and all boundary comments are
 shut off.

 If the widget.verbose setting in the properties file is true, then it 
 follows the previous pattern, where true is the default, but
 it can be overridden in web.xml and in the context Map.

 Will that work for everyone?

 -Adrian

 On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
 I am going to feel bad if I don't add my 2 cents to this thread :-)
 I agree with Jacques that the formatting of boundary comments should be 
 output specific (i.e no output for CSV etc...) instead of
 always rendering as html comments.
 As regards the logic to determine if comments should be enabled or not, 
 I don't have a strong opinion because I have always used
 this feature in a very rough way (enable all or disable all); however I 
 can understand the we may want to avoid that (when
 widget.properties.enableBoundaryComments == false) the comments are 
 enabled by passing a URL parameter to the screen.

 Kind regards,

 Jacopo

 On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:

 Someone I work with suggested:

 I have to point out though that I kind of agree with the way David put 
 it in that the false setting could have a priority,
 i.e. it's like in security permissions where deny has precedence over 
 allow, so if you set it in widget.properties to false
 then you're sure comments will never be enabled anywhere... 
 security-wise it makes sense despite the comment about qc...

 Maybe something like this? (compromise between the two)

 if (widget.properties.enableBoundaryComments == false
 || web.xml.enableBoundaryComments == false
 || context.enableBoundaryComments == false) {
 return false;
 } else { // This is the solution Scott wrote, but use overriding 
 settings only for null and true values
 if (context.enableBoundaryComments != null) return 
 context.enableBoundaryComments;
 if (web.xml.enableBoundaryComments != null) return 
 web.xml.enableBoundaryComments;
 if (widget.properties.enableBoundaryComments != null) return 
 widget.properties.enableBoundaryComments;
 return false;
 }

 Could probably rewrite that to be less redundant but you get the idea...

 jleroux: I quickly reformated my own way ;o), It seems a good idea to 
 me, what do you think?

 Also my colleague also wrote:
 Only thing I have to add is that I didn't see anyone address the issue 
 that HTML comments are outputted for CSV (because there's
 nocsv   element and you have to usehtml) element. No matter what 
 widget.verbose is set to, there should never be HTmL
 comments outputted for csv. so this only addresses half the bugs...

 We have no patches so far...

 Jacques



 Dimitri Unruh wrote:
 +1


 Dimitri Unruh
 Consultant AEW
 Lynx-Consulting GmbH
 Johanniskirchplatz 6
 33615 Bielefeld
 Deutschland
 Fon: +49 521 5247-0
 Fax: +49 521 5247-250
 Mobil: +49 160 90 57 55 13

Re: widgetVerbose


BJ,

The original message of this thread points out why that approach does 
not work. If comments are defaulted to on, then there MUST be a way to 
turn them off for things like CSV output.


-Adrian

On 9/19/2011 4:39 PM, BJ Freeman wrote:

+1
KISS
one place to turn off and on. common sense says you use for development
then you turn it off so there are no comments in the ouput.
So there is not need to have the comments turned off at component level.


Hans Bakker sent the following on 9/19/2011 2:14 AM:

If i use the widget comments option i want it to be generally applied
and taken away depending on the properties setting. I do not want to
find out that somewhere it is not following the setting, then have to
dig in the code and find out that is, because somebody put an
undocumented override somewhere by default as happened the first time.
Bird and google checkout is fine.

I think how it is implemented now is fine. I hope i commented now
enough?

Regards,
Hans

On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:

Hans,

Jacques gave some examples of where an override is currently used and
why it is needed. Could you give us another reason besides i think an
override is an overkill - like a reason based on a design issue or a
real-world problem?

-Adrian

On 9/19/2011 7:55 AM, Hans Bakker wrote:

I as sorry i do not see the problem here.

as long as the properties setting in the trunk will show or hide all
widget comments (so in the trunk NO override) then it is fine.

why? because i think an override is an overkill anyway

Regards,
Hans


On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:

Yes, but I guess we will set widget.verbose in the properties file to true (as 
we do for all defaults to be dev friendly). Will that
suit Hans? Else why do you Hans ask for now overriding in web.xml? For instance 
what for Birt by defaut? Why not keeping the example
in example component commented out? Waht for testtools? Not sure why it's false 
in googlecheckout but I guess there is a reason..

In other word I guess Hans expect widget.verbose in the properties file to be 
false...

Jacques

From: Adrian Crumadrian.c...@sandglass-software.com

Let's see if we can bring this to a happy ending.

If the widget.verbose setting in the properties file is false, then it 
overrides any other setting and all boundary comments are
shut off.

If the widget.verbose setting in the properties file is true, then it follows 
the previous pattern, where true is the default, but
it can be overridden in web.xml and in the context Map.

Will that work for everyone?

-Adrian

On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:

I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments should be output 
specific (i.e no output for CSV etc...) instead of
always rendering as html comments.
As regards the logic to determine if comments should be enabled or not, I don't 
have a strong opinion because I have always used
this feature in a very rough way (enable all or disable all); however I can 
understand the we may want to avoid that (when
widget.properties.enableBoundaryComments == false) the comments are enabled by 
passing a URL parameter to the screen.

Kind regards,

Jacopo

On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:


Someone I work with suggested:

I have to point out though that I kind of agree with the way David put it in that the 
false setting could have a priority,
i.e. it's like in security permissions where deny has precedence over allow, 
so if you set it in widget.properties to false
then you're sure comments will never be enabled anywhere... security-wise it 
makes sense despite the comment about qc...

Maybe something like this? (compromise between the two)

if (widget.properties.enableBoundaryComments == false
 || web.xml.enableBoundaryComments == false
 || context.enableBoundaryComments == false) {
 return false;
} else { // This is the solution Scott wrote, but use overriding settings only 
for null and true values
 if (context.enableBoundaryComments != null) return 
context.enableBoundaryComments;
 if (web.xml.enableBoundaryComments != null) return 
web.xml.enableBoundaryComments;
 if (widget.properties.enableBoundaryComments != null) return 
widget.properties.enableBoundaryComments;
 return false;
}

Could probably rewrite that to be less redundant but you get the idea...

jleroux: I quickly reformated my own way ;o), It seems a good idea to me, what 
do you think?

Also my colleague also wrote:
Only thing I have to add is that I didn't see anyone address the issue that 
HTML comments are outputted for CSV (because there's
nocsvelement and you have to usehtml) element. No matter what 
widget.verbose is set to, there should never be HTmL
comments outputted for csv. so this only addresses half the bugs...

We have no patches so far...

Jacques



Dimitri Unruh wrote:

+1


Dimitri Unruh

Re: ofbiz HttpClient versus org.apache.commons.httpclient.HttpClient;

actually I was suggesting that ofbiz as a whole would be re-factored to NIO
My underlying motivation is to stop expanding libraries and start only
having what ofbiz is really using.
and that is a harder effort but well worth it.
But I am willing to work with the jira.

Jacques Le Roux sent the following on 9/18/2011 11:51 PM:
 1) This is what I mean:
 http://hc.apache.org/httpclient-3.x/performance.html#Connection_persistence
 In other words, not relying on the SO to release connections. Most of
 the time it's not a big deal, but in some cases this can be annoying
 2) You are welcome https://issues.apache.org/jira/browse/OFBIZ-4430.
 Maybe it's not harder indeed...
 
 Jacques
 
 From: BJ Freeman bjf...@free-man.net
 Ok a longer version of my terse reply.
 there are two concerns in this thread you brought up.
 1) TIMENOUT
 2) implementing a different package that does not support the newer
 java.nio.channel like the APJ does.
 #1 is something than if you set to long it will waste response time, on
 a bad connection, if to short will have the effect in the Email.
 when I started in 96 the latency of the internet was uder 100 ms max.
 Now the latency of the net is upwards of what used to be considered
 intoloralbe latency (200 ms).
 On top of that you have the Server response time which during the
 Holidays gets really long so you will time out before the server
 responds causing resends that only bog down the server more.
 the above is a long winded way of saying your time out has to change
 with the conditions.
 #2 in looking at the http library they are still using the java.net for
 connection. So in my estimation, we do a re-factor of ofbiz to java.nio
 and fix the httpclient we have.


 Jacques Le Roux sent the following on 9/17/2011 9:13 AM:
 I'm resurrecting this thread because, as outlined by this other thread
 http://markmail.org/message/j4s6tq2ccit3wtbf, unlike Apache
 HttpClient, OFBiz's is not closing connections.
 I have not the time at the moment to replace it, but I'd like to do so
 in October or November. I will open a Jira then (this message
 more as a self reminder...)

 Interesting link also
 http://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html


 Jacques

 From: BJ Freeman bjf...@free-man.net
 I have done more investigation, and found the methods I depend on in
 the
 jar come from java 1.31. in looking at the current httpclient, it does
 not support the code I have.
 I am not sure what I will do at this point but for the trunk it
 would be
 best to use the current httpclient.
 I am still going thru the current httpclient class in ofbiz to figure
 out how is would be used, mostly in communication with third parties.

 Adrian Crum sent the following on 10/23/2008 2:39 PM:
 I was thinking we could deprecate the constructors, and point
 people to
 the new class.

 -Adrian

 BJ Freeman wrote:
 just as a note there are methods in the ofbiz one that work with
 ofbiz
 structure. I would like to review those to see if they can be used
 I guess the proper steps is to depreciate those.

 BJ Freeman sent the following on 10/23/2008 1:47 PM:
 works for me.
 it has been moved around
 found it under
 http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/module-client/





 Adrian Crum sent the following on 10/23/2008 1:37 PM:
 I'd rather switch to the commons one and eliminate the OFBiz one.
 It's
 only used in one or two places, so it wouldn't be a difficult
 change to
 make.

 -Adrian

 BJ Freeman wrote:
 I have been looking at HTMLUnit since our last conversation, for
 implementing user test screens.
 this is more that there are two HttpClient classes and the ofbiz
 one is
 used in the framework.
 it seemed the simplest solution would be to use implements to
 append the
  apache one to the ofbiz one thus making the ofbiz one more
 versatile.

 Adrian Crum sent the following on 10/23/2008 1:06 PM:
 I would recommend using any suitable replacement for the OFBiz
 HttpClient - it is very rudimentary.

 If you need an HTTP client that handles cookies and JavaScript,
 then
 take a look at HTMLUnit - http://htmlunit.sourceforge.net. I used
 it in
 my mashup POC code -
 https://issues.apache.org/jira/browse/OFBIZ-1873.

 -Adrian

 BJ Freeman wrote:
 while working with yahoo API
 I came accross the org.apache.commons.httpclient.HttpClient;
 which has more functionality than the ofbiz HttpClient
 is there any problem with making the ofbiz an HttpClient
 implementation
 of the apache?

Re: widgetVerbose

yes I understand. but a simple turn off all comments lets you work with
that. but if you want to see what is generating that, then turn them all on.
Like Hans said, I really don't want to have to go through code to find
where it is turned off or on.

Adrian Crum sent the following on 9/19/2011 8:56 AM:
 BJ,
 
 The original message of this thread points out why that approach does
 not work. If comments are defaulted to on, then there MUST be a way to
 turn them off for things like CSV output.
 
 -Adrian
 
 On 9/19/2011 4:39 PM, BJ Freeman wrote:
 +1
 KISS
 one place to turn off and on. common sense says you use for development
 then you turn it off so there are no comments in the ouput.
 So there is not need to have the comments turned off at component level.


 Hans Bakker sent the following on 9/19/2011 2:14 AM:
 If i use the widget comments option i want it to be generally applied
 and taken away depending on the properties setting. I do not want to
 find out that somewhere it is not following the setting, then have to
 dig in the code and find out that is, because somebody put an
 undocumented override somewhere by default as happened the first time.
 Bird and google checkout is fine.

 I think how it is implemented now is fine. I hope i commented now
 enough?

 Regards,
 Hans

 On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
 Hans,

 Jacques gave some examples of where an override is currently used and
 why it is needed. Could you give us another reason besides i think an
 override is an overkill - like a reason based on a design issue or a
 real-world problem?

 -Adrian

 On 9/19/2011 7:55 AM, Hans Bakker wrote:
 I as sorry i do not see the problem here.

 as long as the properties setting in the trunk will show or hide all
 widget comments (so in the trunk NO override) then it is fine.

 why? because i think an override is an overkill anyway

 Regards,
 Hans


 On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
 Yes, but I guess we will set widget.verbose in the properties file
 to true (as we do for all defaults to be dev friendly). Will that
 suit Hans? Else why do you Hans ask for now overriding in web.xml?
 For instance what for Birt by defaut? Why not keeping the example
 in example component commented out? Waht for testtools? Not sure
 why it's false in googlecheckout but I guess there is a reason..

 In other word I guess Hans expect widget.verbose in the properties
 file to be false...

 Jacques

 From: Adrian Crumadrian.c...@sandglass-software.com
 Let's see if we can bring this to a happy ending.

 If the widget.verbose setting in the properties file is false,
 then it overrides any other setting and all boundary comments are
 shut off.

 If the widget.verbose setting in the properties file is true,
 then it follows the previous pattern, where true is the default, but
 it can be overridden in web.xml and in the context Map.

 Will that work for everyone?

 -Adrian

 On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
 I am going to feel bad if I don't add my 2 cents to this thread :-)
 I agree with Jacques that the formatting of boundary comments
 should be output specific (i.e no output for CSV etc...) instead of
 always rendering as html comments.
 As regards the logic to determine if comments should be enabled
 or not, I don't have a strong opinion because I have always used
 this feature in a very rough way (enable all or disable all);
 however I can understand the we may want to avoid that (when
 widget.properties.enableBoundaryComments == false) the comments
 are enabled by passing a URL parameter to the screen.

 Kind regards,

 Jacopo

 On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:

 Someone I work with suggested:

 I have to point out though that I kind of agree with the way
 David put it in that the false setting could have a priority,
 i.e. it's like in security permissions where deny has
 precedence over allow, so if you set it in widget.properties to
 false
 then you're sure comments will never be enabled anywhere...
 security-wise it makes sense despite the comment about qc...

 Maybe something like this? (compromise between the two)

 if (widget.properties.enableBoundaryComments == false
  || web.xml.enableBoundaryComments == false
  || context.enableBoundaryComments == false) {
  return false;
 } else { // This is the solution Scott wrote, but use
 overriding settings only for null and true values
  if (context.enableBoundaryComments != null) return
 context.enableBoundaryComments;
  if (web.xml.enableBoundaryComments != null) return
 web.xml.enableBoundaryComments;
  if (widget.properties.enableBoundaryComments != null)
 return widget.properties.enableBoundaryComments;
  return false;
 }

 Could probably rewrite that to be less redundant but you get
 the idea...

 jleroux: I quickly reformated my own way ;o), It seems a good
 idea to me, what do you think?

 Also my colleague also wrote:
 Only thing I have to add is

Re: widgetVerbose

And there are others who don't like the all-or-nothing approach. Please, 
unless you have something new to add, can we stop talking in circles?


-Adrian

On 9/19/2011 5:02 PM, BJ Freeman wrote:

yes I understand. but a simple turn off all comments lets you work with
that. but if you want to see what is generating that, then turn them all on.
Like Hans said, I really don't want to have to go through code to find
where it is turned off or on.

Adrian Crum sent the following on 9/19/2011 8:56 AM:

BJ,

The original message of this thread points out why that approach does
not work. If comments are defaulted to on, then there MUST be a way to
turn them off for things like CSV output.

-Adrian

On 9/19/2011 4:39 PM, BJ Freeman wrote:

+1
KISS
one place to turn off and on. common sense says you use for development
then you turn it off so there are no comments in the ouput.
So there is not need to have the comments turned off at component level.


Hans Bakker sent the following on 9/19/2011 2:14 AM:

If i use the widget comments option i want it to be generally applied
and taken away depending on the properties setting. I do not want to
find out that somewhere it is not following the setting, then have to
dig in the code and find out that is, because somebody put an
undocumented override somewhere by default as happened the first time.
Bird and google checkout is fine.

I think how it is implemented now is fine. I hope i commented now
enough?

Regards,
Hans

On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:

Hans,

Jacques gave some examples of where an override is currently used and
why it is needed. Could you give us another reason besides i think an
override is an overkill - like a reason based on a design issue or a
real-world problem?

-Adrian

On 9/19/2011 7:55 AM, Hans Bakker wrote:

I as sorry i do not see the problem here.

as long as the properties setting in the trunk will show or hide all
widget comments (so in the trunk NO override) then it is fine.

why? because i think an override is an overkill anyway

Regards,
Hans


On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:

Yes, but I guess we will set widget.verbose in the properties file
to true (as we do for all defaults to be dev friendly). Will that
suit Hans? Else why do you Hans ask for now overriding in web.xml?
For instance what for Birt by defaut? Why not keeping the example
in example component commented out? Waht for testtools? Not sure
why it's false in googlecheckout but I guess there is a reason..

In other word I guess Hans expect widget.verbose in the properties
file to be false...

Jacques

From: Adrian Crumadrian.c...@sandglass-software.com

Let's see if we can bring this to a happy ending.

If the widget.verbose setting in the properties file is false,
then it overrides any other setting and all boundary comments are
shut off.

If the widget.verbose setting in the properties file is true,
then it follows the previous pattern, where true is the default, but
it can be overridden in web.xml and in the context Map.

Will that work for everyone?

-Adrian

On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:

I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments
should be output specific (i.e no output for CSV etc...) instead of
always rendering as html comments.
As regards the logic to determine if comments should be enabled
or not, I don't have a strong opinion because I have always used
this feature in a very rough way (enable all or disable all);
however I can understand the we may want to avoid that (when
widget.properties.enableBoundaryComments == false) the comments
are enabled by passing a URL parameter to the screen.

Kind regards,

Jacopo

On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:


Someone I work with suggested:

I have to point out though that I kind of agree with the way
David put it in that the false setting could have a priority,
i.e. it's like in security permissions where deny has
precedence over allow, so if you set it in widget.properties to
false
then you're sure comments will never be enabled anywhere...
security-wise it makes sense despite the comment about qc...

Maybe something like this? (compromise between the two)

if (widget.properties.enableBoundaryComments == false
  || web.xml.enableBoundaryComments == false
  || context.enableBoundaryComments == false) {
  return false;
} else { // This is the solution Scott wrote, but use
overriding settings only for null and true values
  if (context.enableBoundaryComments != null) return
context.enableBoundaryComments;
  if (web.xml.enableBoundaryComments != null) return
web.xml.enableBoundaryComments;
  if (widget.properties.enableBoundaryComments != null)
return widget.properties.enableBoundaryComments;
  return false;
}

Could probably rewrite that to be less redundant but you get
the idea...

jleroux: I quickly reformated my own way

Re: widgetVerbose

Then I suggest a vote, though mine is none binding.

Adrian Crum sent the following on 9/19/2011 9:06 AM:
 And there are others who don't like the all-or-nothing approach. Please,
 unless you have something new to add, can we stop talking in circles?
 
 -Adrian
 
 On 9/19/2011 5:02 PM, BJ Freeman wrote:
 yes I understand. but a simple turn off all comments lets you work with
 that. but if you want to see what is generating that, then turn them
 all on.
 Like Hans said, I really don't want to have to go through code to find
 where it is turned off or on.

 Adrian Crum sent the following on 9/19/2011 8:56 AM:
 BJ,

 The original message of this thread points out why that approach does
 not work. If comments are defaulted to on, then there MUST be a way to
 turn them off for things like CSV output.

 -Adrian

 On 9/19/2011 4:39 PM, BJ Freeman wrote:
 +1
 KISS
 one place to turn off and on. common sense says you use for development
 then you turn it off so there are no comments in the ouput.
 So there is not need to have the comments turned off at component
 level.


 Hans Bakker sent the following on 9/19/2011 2:14 AM:
 If i use the widget comments option i want it to be generally applied
 and taken away depending on the properties setting. I do not want to
 find out that somewhere it is not following the setting, then have to
 dig in the code and find out that is, because somebody put an
 undocumented override somewhere by default as happened the first time.
 Bird and google checkout is fine.

 I think how it is implemented now is fine. I hope i commented now
 enough?

 Regards,
 Hans

 On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
 Hans,

 Jacques gave some examples of where an override is currently used and
 why it is needed. Could you give us another reason besides i
 think an
 override is an overkill - like a reason based on a design issue or a
 real-world problem?

 -Adrian

 On 9/19/2011 7:55 AM, Hans Bakker wrote:
 I as sorry i do not see the problem here.

 as long as the properties setting in the trunk will show or hide all
 widget comments (so in the trunk NO override) then it is fine.

 why? because i think an override is an overkill anyway

 Regards,
 Hans


 On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
 Yes, but I guess we will set widget.verbose in the properties file
 to true (as we do for all defaults to be dev friendly). Will that
 suit Hans? Else why do you Hans ask for now overriding in web.xml?
 For instance what for Birt by defaut? Why not keeping the example
 in example component commented out? Waht for testtools? Not sure
 why it's false in googlecheckout but I guess there is a reason..

 In other word I guess Hans expect widget.verbose in the properties
 file to be false...

 Jacques

 From: Adrian Crumadrian.c...@sandglass-software.com
 Let's see if we can bring this to a happy ending.

 If the widget.verbose setting in the properties file is false,
 then it overrides any other setting and all boundary comments are
 shut off.

 If the widget.verbose setting in the properties file is true,
 then it follows the previous pattern, where true is the
 default, but
 it can be overridden in web.xml and in the context Map.

 Will that work for everyone?

 -Adrian

 On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
 I am going to feel bad if I don't add my 2 cents to this
 thread :-)
 I agree with Jacques that the formatting of boundary comments
 should be output specific (i.e no output for CSV etc...)
 instead of
 always rendering as html comments.
 As regards the logic to determine if comments should be enabled
 or not, I don't have a strong opinion because I have always used
 this feature in a very rough way (enable all or disable all);
 however I can understand the we may want to avoid that (when
 widget.properties.enableBoundaryComments == false) the comments
 are enabled by passing a URL parameter to the screen.

 Kind regards,

 Jacopo

 On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:

 Someone I work with suggested:

 I have to point out though that I kind of agree with the way
 David put it in that the false setting could have a priority,
 i.e. it's like in security permissions where deny has
 precedence over allow, so if you set it in widget.properties to
 false
 then you're sure comments will never be enabled anywhere...
 security-wise it makes sense despite the comment about qc...

 Maybe something like this? (compromise between the two)

 if (widget.properties.enableBoundaryComments == false
   || web.xml.enableBoundaryComments == false
   || context.enableBoundaryComments == false) {
   return false;
 } else { // This is the solution Scott wrote, but use
 overriding settings only for null and true values
   if (context.enableBoundaryComments != null) return
 context.enableBoundaryComments;
   if (web.xml.enableBoundaryComments != null) return
 web.xml.enableBoundaryComments;
   if

[jira] [Commented] (OFBIZ-4430) Replace OFBiz HttpClient either by org.apache.commons.httpclient.HttpClient or rewrite it using NIO

2011-09-19 Thread BJ Freeman (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-4430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107984#comment-13107984
 ] 

BJ Freeman commented on OFBIZ-4430:
---

My suggestion to use NIO was more for all of Ofbiz.
I don't see adding another package that has the same basic function as the 
java.net just for HttpClient.
So will review the commons package to see what can be down with current 
httpClient.

 Replace OFBiz HttpClient either by org.apache.commons.httpclient.HttpClient 
 or rewrite it using NIO
 ---

 Key: OFBIZ-4430
 URL: https://issues.apache.org/jira/browse/OFBIZ-4430
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
Reporter: Jacques Le Roux
 Fix For: SVN trunk


 The main problem with current implementation is that it does not handle 
 connections release. You must rely on the SO to release them (timeout).
 Related thread: http://markmail.org/message/qgmdgqqxakio6fja

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4430) Replace OFBiz HttpClient either by org.apache.commons.httpclient.HttpClient or rewrite it using NIO

2011-09-19 Thread BJ Freeman (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-4430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13108006#comment-13108006
 ] 

BJ Freeman commented on OFBIZ-4430:
---

Quick review there are two possible solutions with current code.
1)modify  org.ofbiz.base.util.URLConnector to handle the close automatically.
2)Call org.ofbiz.base.util.URLConnector.close in HttpClient. 
The way Commons does this is when the stream is closed the connector is closed.
will look at it again shortly to see if I agree with what I just wrote.

 Replace OFBiz HttpClient either by org.apache.commons.httpclient.HttpClient 
 or rewrite it using NIO
 ---

 Key: OFBIZ-4430
 URL: https://issues.apache.org/jira/browse/OFBIZ-4430
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
Reporter: Jacques Le Roux
 Fix For: SVN trunk


 The main problem with current implementation is that it does not handle 
 connections release. You must rely on the SO to release them (timeout).
 Related thread: http://markmail.org/message/qgmdgqqxakio6fja

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4410) breadcrumbs.ftl code is not efficient

2011-09-19 Thread Kiran Gawde (JIRA)


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

Kiran Gawde updated OFBIZ-4410:
---

Attachment: OFBIZ-4410-breadcrumbsEfficientCode.patch

Updated the patch to work with trunk

 breadcrumbs.ftl code is not efficient
 -

 Key: OFBIZ-4410
 URL: https://issues.apache.org/jira/browse/OFBIZ-4410
 Project: OFBiz
  Issue Type: Improvement
  Components: order
Affects Versions: Release Branch 10.04
Reporter: Kiran Gawde
Priority: Minor
 Attachments: OFBIZ-4410-breadcrumbsEfficientCode.patch, 
 OFBIZ-4410-breadcrumbsEfficientCode.patch


 breadcrumbs.ftl recuses all the categories to show the correct breadcrumbs. 
 Instead it should iterate over values from trail.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: widgetVerbose

2011-09-19 Thread Anne

If the main problem is not wanting to go through all the code to find
where the comments are on/off, perhaps a solution would be log
messages at startup saying which comments are turned on where? Then
when anyone sees/doesn't see comments they do/don't want, they can
look at the startup logs to see exactly what is on and off. And then
no one will care as strongly about the details.

I'm not familiar with this code, but I'd guess adding a logging
statement where each relevant property is loaded wouldn't be
difficult? Of course, if they are loaded lots of times all over the
place, then it isn't that simple.

In which case maybe something in webtools that reports what is on and
off and where?

Cheers,
Anne.

On 20 September 2011 02:02, BJ Freeman bjf...@free-man.net wrote:
 yes I understand. but a simple turn off all comments lets you work with
 that. but if you want to see what is generating that, then turn them all on.
 Like Hans said, I really don't want to have to go through code to find
 where it is turned off or on.

 Adrian Crum sent the following on 9/19/2011 8:56 AM:
 BJ,

 The original message of this thread points out why that approach does
 not work. If comments are defaulted to on, then there MUST be a way to
 turn them off for things like CSV output.

 -Adrian

 On 9/19/2011 4:39 PM, BJ Freeman wrote:
 +1
 KISS
 one place to turn off and on. common sense says you use for development
 then you turn it off so there are no comments in the ouput.
 So there is not need to have the comments turned off at component level.


 Hans Bakker sent the following on 9/19/2011 2:14 AM:
 If i use the widget comments option i want it to be generally applied
 and taken away depending on the properties setting. I do not want to
 find out that somewhere it is not following the setting, then have to
 dig in the code and find out that is, because somebody put an
 undocumented override somewhere by default as happened the first time.
 Bird and google checkout is fine.

 I think how it is implemented now is fine. I hope i commented now
 enough?

 Regards,
 Hans

 On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
 Hans,

 Jacques gave some examples of where an override is currently used and
 why it is needed. Could you give us another reason besides i think an
 override is an overkill - like a reason based on a design issue or a
 real-world problem?

 -Adrian

 On 9/19/2011 7:55 AM, Hans Bakker wrote:
 I as sorry i do not see the problem here.

 as long as the properties setting in the trunk will show or hide all
 widget comments (so in the trunk NO override) then it is fine.

 why? because i think an override is an overkill anyway

 Regards,
 Hans


 On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
 Yes, but I guess we will set widget.verbose in the properties file
 to true (as we do for all defaults to be dev friendly). Will that
 suit Hans? Else why do you Hans ask for now overriding in web.xml?
 For instance what for Birt by defaut? Why not keeping the example
 in example component commented out? Waht for testtools? Not sure
 why it's false in googlecheckout but I guess there is a reason..

 In other word I guess Hans expect widget.verbose in the properties
 file to be false...

 Jacques

 From: Adrian Crumadrian.c...@sandglass-software.com
 Let's see if we can bring this to a happy ending.

 If the widget.verbose setting in the properties file is false,
 then it overrides any other setting and all boundary comments are
 shut off.

 If the widget.verbose setting in the properties file is true,
 then it follows the previous pattern, where true is the default, but
 it can be overridden in web.xml and in the context Map.

 Will that work for everyone?

 -Adrian

 On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
 I am going to feel bad if I don't add my 2 cents to this thread :-)
 I agree with Jacques that the formatting of boundary comments
 should be output specific (i.e no output for CSV etc...) instead of
 always rendering as html comments.
 As regards the logic to determine if comments should be enabled
 or not, I don't have a strong opinion because I have always used
 this feature in a very rough way (enable all or disable all);
 however I can understand the we may want to avoid that (when
 widget.properties.enableBoundaryComments == false) the comments
 are enabled by passing a URL parameter to the screen.

 Kind regards,

 Jacopo

 On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:

 Someone I work with suggested:

 I have to point out though that I kind of agree with the way
 David put it in that the false setting could have a priority,
 i.e. it's like in security permissions where deny has
 precedence over allow, so if you set it in widget.properties to
 false
 then you're sure comments will never be enabled anywhere...
 security-wise it makes sense despite the comment about qc...

 Maybe something like this? (compromise between the two)

 if (widget.properties.enableBoundaryComments ==

Re: widgetVerbose


Anne,

Logging the settings is not necessary because the design is not that 
complicated. A setting in the widget.properties file is the default. 
That setting can be overridden in web.xml, and the setting in web.xml 
can be overridden in an individual screen widget by setting a value in 
the rendering context. So:


properties file - web.xml - rendering context

There is no need to go through code. If you enabled the widget comments 
in the properties file and the comments are not appearing in a 
particular web application, then check the web.xml file. If the comments 
are appearing in a web application but not in a particular screen, then 
check the screen widget xml file. It's very simple. We just have a 
couple of people who are trying to make it seem hard.


-Adrian

On 9/20/2011 12:56 AM, Anne wrote:

If the main problem is not wanting to go through all the code to find
where the comments are on/off, perhaps a solution would be log
messages at startup saying which comments are turned on where? Then
when anyone sees/doesn't see comments they do/don't want, they can
look at the startup logs to see exactly what is on and off. And then
no one will care as strongly about the details.

I'm not familiar with this code, but I'd guess adding a logging
statement where each relevant property is loaded wouldn't be
difficult? Of course, if they are loaded lots of times all over the
place, then it isn't that simple.

In which case maybe something in webtools that reports what is on and
off and where?

Cheers,
Anne.

On 20 September 2011 02:02, BJ Freemanbjf...@free-man.net  wrote:

yes I understand. but a simple turn off all comments lets you work with
that. but if you want to see what is generating that, then turn them all on.
Like Hans said, I really don't want to have to go through code to find
where it is turned off or on.

Adrian Crum sent the following on 9/19/2011 8:56 AM:

BJ,

The original message of this thread points out why that approach does
not work. If comments are defaulted to on, then there MUST be a way to
turn them off for things like CSV output.

-Adrian

On 9/19/2011 4:39 PM, BJ Freeman wrote:

+1
KISS
one place to turn off and on. common sense says you use for development
then you turn it off so there are no comments in the ouput.
So there is not need to have the comments turned off at component level.


Hans Bakker sent the following on 9/19/2011 2:14 AM:

If i use the widget comments option i want it to be generally applied
and taken away depending on the properties setting. I do not want to
find out that somewhere it is not following the setting, then have to
dig in the code and find out that is, because somebody put an
undocumented override somewhere by default as happened the first time.
Bird and google checkout is fine.

I think how it is implemented now is fine. I hope i commented now
enough?

Regards,
Hans

On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:

Hans,

Jacques gave some examples of where an override is currently used and
why it is needed. Could you give us another reason besides i think an
override is an overkill - like a reason based on a design issue or a
real-world problem?

-Adrian

On 9/19/2011 7:55 AM, Hans Bakker wrote:

I as sorry i do not see the problem here.

as long as the properties setting in the trunk will show or hide all
widget comments (so in the trunk NO override) then it is fine.

why? because i think an override is an overkill anyway

Regards,
Hans


On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:

Yes, but I guess we will set widget.verbose in the properties file
to true (as we do for all defaults to be dev friendly). Will that
suit Hans? Else why do you Hans ask for now overriding in web.xml?
For instance what for Birt by defaut? Why not keeping the example
in example component commented out? Waht for testtools? Not sure
why it's false in googlecheckout but I guess there is a reason..

In other word I guess Hans expect widget.verbose in the properties
file to be false...

Jacques

From: Adrian Crumadrian.c...@sandglass-software.com

Let's see if we can bring this to a happy ending.

If the widget.verbose setting in the properties file is false,
then it overrides any other setting and all boundary comments are
shut off.

If the widget.verbose setting in the properties file is true,
then it follows the previous pattern, where true is the default, but
it can be overridden in web.xml and in the context Map.

Will that work for everyone?

-Adrian

On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:

I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments
should be output specific (i.e no output for CSV etc...) instead of
always rendering as html comments.
As regards the logic to determine if comments should be enabled
or not, I don't have a strong opinion because I have always used
this feature in a very rough way (enable all or disable all);
however I can

Re: widgetVerbose

2011-09-19 Thread Anne

Thanks Adrian. I was just trying to work out a way everyone would get
what they really wanted.

Your precedence makes sense to me, and I'm not sure I understand
others' concerns. But that doesn't mean I think they are unimportant,
just that I haven't managed to understand yet.

I was thinking their concern was that it was difficult to determine
what's on/off and where, and hence thought I'd suggest a possible
solution to that problem. Maybe I'm wrong.

Cheers,
Anne.

On 20 September 2011 10:06, Adrian Crum
adrian.c...@sandglass-software.com wrote:
 Anne,

 Logging the settings is not necessary because the design is not that
 complicated. A setting in the widget.properties file is the default. That
 setting can be overridden in web.xml, and the setting in web.xml can be
 overridden in an individual screen widget by setting a value in the
 rendering context. So:

 properties file - web.xml - rendering context

 There is no need to go through code. If you enabled the widget comments in
 the properties file and the comments are not appearing in a particular web
 application, then check the web.xml file. If the comments are appearing in a
 web application but not in a particular screen, then check the screen widget
 xml file. It's very simple. We just have a couple of people who are trying
 to make it seem hard.

 -Adrian

 On 9/20/2011 12:56 AM, Anne wrote:

 If the main problem is not wanting to go through all the code to find
 where the comments are on/off, perhaps a solution would be log
 messages at startup saying which comments are turned on where? Then
 when anyone sees/doesn't see comments they do/don't want, they can
 look at the startup logs to see exactly what is on and off. And then
 no one will care as strongly about the details.

 I'm not familiar with this code, but I'd guess adding a logging
 statement where each relevant property is loaded wouldn't be
 difficult? Of course, if they are loaded lots of times all over the
 place, then it isn't that simple.

 In which case maybe something in webtools that reports what is on and
 off and where?

 Cheers,
 Anne.

 On 20 September 2011 02:02, BJ Freemanbjf...@free-man.net  wrote:

 yes I understand. but a simple turn off all comments lets you work with
 that. but if you want to see what is generating that, then turn them all
 on.
 Like Hans said, I really don't want to have to go through code to find
 where it is turned off or on.

 Adrian Crum sent the following on 9/19/2011 8:56 AM:

 BJ,

 The original message of this thread points out why that approach does
 not work. If comments are defaulted to on, then there MUST be a way to
 turn them off for things like CSV output.

 -Adrian

 On 9/19/2011 4:39 PM, BJ Freeman wrote:

 +1
 KISS
 one place to turn off and on. common sense says you use for development
 then you turn it off so there are no comments in the ouput.
 So there is not need to have the comments turned off at component
 level.


 Hans Bakker sent the following on 9/19/2011 2:14 AM:

 If i use the widget comments option i want it to be generally applied
 and taken away depending on the properties setting. I do not want to
 find out that somewhere it is not following the setting, then have to
 dig in the code and find out that is, because somebody put an
 undocumented override somewhere by default as happened the first time.
 Bird and google checkout is fine.

 I think how it is implemented now is fine. I hope i commented now
 enough?

 Regards,
 Hans

 On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:

 Hans,

 Jacques gave some examples of where an override is currently used and
 why it is needed. Could you give us another reason besides i think
 an
 override is an overkill - like a reason based on a design issue or a
 real-world problem?

 -Adrian

 On 9/19/2011 7:55 AM, Hans Bakker wrote:

 I as sorry i do not see the problem here.

 as long as the properties setting in the trunk will show or hide all
 widget comments (so in the trunk NO override) then it is fine.

 why? because i think an override is an overkill anyway

 Regards,
 Hans


 On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:

 Yes, but I guess we will set widget.verbose in the properties file
 to true (as we do for all defaults to be dev friendly). Will that
 suit Hans? Else why do you Hans ask for now overriding in web.xml?
 For instance what for Birt by defaut? Why not keeping the example
 in example component commented out? Waht for testtools? Not sure
 why it's false in googlecheckout but I guess there is a reason..

 In other word I guess Hans expect widget.verbose in the properties
 file to be false...

 Jacques

 From: Adrian Crumadrian.c...@sandglass-software.com

 Let's see if we can bring this to a happy ending.

 If the widget.verbose setting in the properties file is false,
 then it overrides any other setting and all boundary comments are
 shut off.

 If the widget.verbose setting in the properties file is true,
 then it follows the

Re: widgetVerbose


Anne,

Your suggestions are appreciated.

We're already making a mountain out of a molehill with this issue, and 
logging the setting would just add to the mountain.


-Adrian

On 9/20/2011 1:29 AM, Anne wrote:

Thanks Adrian. I was just trying to work out a way everyone would get
what they really wanted.

Your precedence makes sense to me, and I'm not sure I understand
others' concerns. But that doesn't mean I think they are unimportant,
just that I haven't managed to understand yet.

I was thinking their concern was that it was difficult to determine
what's on/off and where, and hence thought I'd suggest a possible
solution to that problem. Maybe I'm wrong.

Cheers,
Anne.

On 20 September 2011 10:06, Adrian Crum
adrian.c...@sandglass-software.com  wrote:

Anne,

Logging the settings is not necessary because the design is not that
complicated. A setting in the widget.properties file is the default. That
setting can be overridden in web.xml, and the setting in web.xml can be
overridden in an individual screen widget by setting a value in the
rendering context. So:

properties file -  web.xml -  rendering context

There is no need to go through code. If you enabled the widget comments in
the properties file and the comments are not appearing in a particular web
application, then check the web.xml file. If the comments are appearing in a
web application but not in a particular screen, then check the screen widget
xml file. It's very simple. We just have a couple of people who are trying
to make it seem hard.

-Adrian

On 9/20/2011 12:56 AM, Anne wrote:

If the main problem is not wanting to go through all the code to find
where the comments are on/off, perhaps a solution would be log
messages at startup saying which comments are turned on where? Then
when anyone sees/doesn't see comments they do/don't want, they can
look at the startup logs to see exactly what is on and off. And then
no one will care as strongly about the details.

I'm not familiar with this code, but I'd guess adding a logging
statement where each relevant property is loaded wouldn't be
difficult? Of course, if they are loaded lots of times all over the
place, then it isn't that simple.

In which case maybe something in webtools that reports what is on and
off and where?

Cheers,
Anne.

On 20 September 2011 02:02, BJ Freemanbjf...@free-man.netwrote:

yes I understand. but a simple turn off all comments lets you work with
that. but if you want to see what is generating that, then turn them all
on.
Like Hans said, I really don't want to have to go through code to find
where it is turned off or on.

Adrian Crum sent the following on 9/19/2011 8:56 AM:

BJ,

The original message of this thread points out why that approach does
not work. If comments are defaulted to on, then there MUST be a way to
turn them off for things like CSV output.

-Adrian

On 9/19/2011 4:39 PM, BJ Freeman wrote:

+1
KISS
one place to turn off and on. common sense says you use for development
then you turn it off so there are no comments in the ouput.
So there is not need to have the comments turned off at component
level.


Hans Bakker sent the following on 9/19/2011 2:14 AM:

If i use the widget comments option i want it to be generally applied
and taken away depending on the properties setting. I do not want to
find out that somewhere it is not following the setting, then have to
dig in the code and find out that is, because somebody put an
undocumented override somewhere by default as happened the first time.
Bird and google checkout is fine.

I think how it is implemented now is fine. I hope i commented now
enough?

Regards,
Hans

On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:

Hans,

Jacques gave some examples of where an override is currently used and
why it is needed. Could you give us another reason besides i think
an
override is an overkill - like a reason based on a design issue or a
real-world problem?

-Adrian

On 9/19/2011 7:55 AM, Hans Bakker wrote:

I as sorry i do not see the problem here.

as long as the properties setting in the trunk will show or hide all
widget comments (so in the trunk NO override) then it is fine.

why? because i think an override is an overkill anyway

Regards,
Hans


On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:

Yes, but I guess we will set widget.verbose in the properties file
to true (as we do for all defaults to be dev friendly). Will that
suit Hans? Else why do you Hans ask for now overriding in web.xml?
For instance what for Birt by defaut? Why not keeping the example
in example component commented out? Waht for testtools? Not sure
why it's false in googlecheckout but I guess there is a reason..

In other word I guess Hans expect widget.verbose in the properties
file to be false...

Jacques

From: Adrian Crumadrian.c...@sandglass-software.com

Let's see if we can bring this to a happy ending.

If the widget.verbose setting in the properties file is false,
then it overrides any other setting

Re: widgetVerbose

Thank you everyone for your patience and comments during this 
discussion. I believe we are near a resolution.


From my perspective, this is where we stand:

1. I proposed the following design based on David's suggestion:

If the widget.verbose setting in the properties file is false, then it 
overrides any other setting and all boundary comments are

shut off.

If the widget.verbose setting in the properties file is true, then it 
follows the previous pattern, where true is the default, but

it can be overridden in web.xml and in the context Map.

2. Hans is willing to accept the design, as long as there are no 
undocumented surprises where the setting is changed in web.xml files. 
Some web applications that require the setting to be off even when the 
default is on are okay.


3. I asked Hans for a confirmation that my understanding of his replies 
is correct. He has not replied.


4. If there are no further objections, then we can proceed with 
implementing the design.


-Adrian


On 9/19/2011 10:23 AM, Adrian Crum wrote:

Hans,

We can document the behavior in the properties file, and we have this 
discussion on record to describe the behavior and the reason why it 
was done that way. I believe those things will help avoid confusion in 
the future.


So, can we implement the behavior I described? I believe you already 
answered this question, but I am asking again just to be sure.


-Adrian

On 9/19/2011 10:14 AM, Hans Bakker wrote:

If i use the widget comments option i want it to be generally applied
and taken away depending on the properties setting. I do not want to
find out that somewhere it is not following the setting, then have to
dig in the code and find out that is, because somebody put an
undocumented override somewhere by default as happened the first time.
Bird and google checkout is fine.

I think how it is implemented now is fine. I hope i commented now
enough?

Regards,
Hans

On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:

Hans,

Jacques gave some examples of where an override is currently used and
why it is needed. Could you give us another reason besides i think an
override is an overkill - like a reason based on a design issue or a
real-world problem?

-Adrian

On 9/19/2011 7:55 AM, Hans Bakker wrote:

I as sorry i do not see the problem here.

as long as the properties setting in the trunk will show or hide all
widget comments (so in the trunk NO override) then it is fine.

why? because i think an override is an overkill anyway

Regards,
Hans


On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
Yes, but I guess we will set widget.verbose in the properties file 
to true (as we do for all defaults to be dev friendly). Will that
suit Hans? Else why do you Hans ask for now overriding in web.xml? 
For instance what for Birt by defaut? Why not keeping the example
in example component commented out? Waht for testtools? Not sure 
why it's false in googlecheckout but I guess there is a reason..


In other word I guess Hans expect widget.verbose in the properties 
file to be false...


Jacques

From: Adrian Crumadrian.c...@sandglass-software.com

Let's see if we can bring this to a happy ending.

If the widget.verbose setting in the properties file is false, 
then it overrides any other setting and all boundary comments are

shut off.

If the widget.verbose setting in the properties file is true, 
then it follows the previous pattern, where true is the default, but

it can be overridden in web.xml and in the context Map.

Will that work for everyone?

-Adrian

On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:

I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments 
should be output specific (i.e no output for CSV etc...) instead of

always rendering as html comments.
As regards the logic to determine if comments should be enabled 
or not, I don't have a strong opinion because I have always used
this feature in a very rough way (enable all or disable all); 
however I can understand the we may want to avoid that (when
widget.properties.enableBoundaryComments == false) the comments 
are enabled by passing a URL parameter to the screen.


Kind regards,

Jacopo

On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:


Someone I work with suggested:

I have to point out though that I kind of agree with the way 
David put it in that the false setting could have a priority,
i.e. it's like in security permissions where deny has 
precedence over allow, so if you set it in widget.properties to 
false
then you're sure comments will never be enabled anywhere... 
security-wise it makes sense despite the comment about qc...


Maybe something like this? (compromise between the two)

if (widget.properties.enableBoundaryComments == false
 || web.xml.enableBoundaryComments == false
 || context.enableBoundaryComments == false) {
 return false;
} else { // This is the solution Scott wrote, but use

Re: widgetVerbose

Ok Adrian, at least for the third time: (five times in a different
wording)

what i wrote?

 as long as the properties setting in the trunk will show or hide all
 widget comments (so in the trunk NO override) then it is fine.

Regards,
Hans


On Tue, 2011-09-20 at 02:10 +0100, Adrian Crum wrote:
 Thank you everyone for your patience and comments during this 
 discussion. I believe we are near a resolution.
 
  From my perspective, this is where we stand:
 
 1. I proposed the following design based on David's suggestion:
 
 If the widget.verbose setting in the properties file is false, then it 
 overrides any other setting and all boundary comments are
 shut off.
 
 If the widget.verbose setting in the properties file is true, then it 
 follows the previous pattern, where true is the default, but
 it can be overridden in web.xml and in the context Map.
 
 2. Hans is willing to accept the design, as long as there are no 
 undocumented surprises where the setting is changed in web.xml files. 
 Some web applications that require the setting to be off even when the 
 default is on are okay.
 
 3. I asked Hans for a confirmation that my understanding of his replies 
 is correct. He has not replied.
 
 4. If there are no further objections, then we can proceed with 
 implementing the design.
 
 -Adrian
 
 
 On 9/19/2011 10:23 AM, Adrian Crum wrote:
  Hans,
 
  We can document the behavior in the properties file, and we have this 
  discussion on record to describe the behavior and the reason why it 
  was done that way. I believe those things will help avoid confusion in 
  the future.
 
  So, can we implement the behavior I described? I believe you already 
  answered this question, but I am asking again just to be sure.
 
  -Adrian
 
  On 9/19/2011 10:14 AM, Hans Bakker wrote:
  If i use the widget comments option i want it to be generally applied
  and taken away depending on the properties setting. I do not want to
  find out that somewhere it is not following the setting, then have to
  dig in the code and find out that is, because somebody put an
  undocumented override somewhere by default as happened the first time.
  Bird and google checkout is fine.
 
  I think how it is implemented now is fine. I hope i commented now
  enough?
 
  Regards,
  Hans
 
  On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
  Hans,
 
  Jacques gave some examples of where an override is currently used and
  why it is needed. Could you give us another reason besides i think an
  override is an overkill - like a reason based on a design issue or a
  real-world problem?
 
  -Adrian
 
  On 9/19/2011 7:55 AM, Hans Bakker wrote:
  I as sorry i do not see the problem here.
 
  as long as the properties setting in the trunk will show or hide all
  widget comments (so in the trunk NO override) then it is fine.
 
  why? because i think an override is an overkill anyway
 
  Regards,
  Hans
 
 
  On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
  Yes, but I guess we will set widget.verbose in the properties file 
  to true (as we do for all defaults to be dev friendly). Will that
  suit Hans? Else why do you Hans ask for now overriding in web.xml? 
  For instance what for Birt by defaut? Why not keeping the example
  in example component commented out? Waht for testtools? Not sure 
  why it's false in googlecheckout but I guess there is a reason..
 
  In other word I guess Hans expect widget.verbose in the properties 
  file to be false...
 
  Jacques
 
  From: Adrian Crumadrian.c...@sandglass-software.com
  Let's see if we can bring this to a happy ending.
 
  If the widget.verbose setting in the properties file is false, 
  then it overrides any other setting and all boundary comments are
  shut off.
 
  If the widget.verbose setting in the properties file is true, 
  then it follows the previous pattern, where true is the default, but
  it can be overridden in web.xml and in the context Map.
 
  Will that work for everyone?
 
  -Adrian
 
  On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
  I am going to feel bad if I don't add my 2 cents to this thread :-)
  I agree with Jacques that the formatting of boundary comments 
  should be output specific (i.e no output for CSV etc...) instead of
  always rendering as html comments.
  As regards the logic to determine if comments should be enabled 
  or not, I don't have a strong opinion because I have always used
  this feature in a very rough way (enable all or disable all); 
  however I can understand the we may want to avoid that (when
  widget.properties.enableBoundaryComments == false) the comments 
  are enabled by passing a URL parameter to the screen.
 
  Kind regards,
 
  Jacopo
 
  On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
 
  Someone I work with suggested:
 
  I have to point out though that I kind of agree with the way 
  David put it in that the false setting could have a priority,
  i.e. it's like in security permissions where deny has 
  precedence

Re: widgetVerbose

Thank you Hans, but repeating your confusing replies does not make them 
any clearer.


I need a simple yes or no answer: May we implement the design I proposed?

-Adrian

On 9/20/2011 2:17 AM, Hans Bakker wrote:

Ok Adrian, at least for the third time: (five times in a different
wording)

what i wrote?


as long as the properties setting in the trunk will show or hide all
widget comments (so in the trunk NO override) then it is fine.

Regards,
Hans


On Tue, 2011-09-20 at 02:10 +0100, Adrian Crum wrote:

Thank you everyone for your patience and comments during this
discussion. I believe we are near a resolution.

  From my perspective, this is where we stand:

1. I proposed the following design based on David's suggestion:

If the widget.verbose setting in the properties file is false, then it
overrides any other setting and all boundary comments are
shut off.

If the widget.verbose setting in the properties file is true, then it
follows the previous pattern, where true is the default, but
it can be overridden in web.xml and in the context Map.

2. Hans is willing to accept the design, as long as there are no
undocumented surprises where the setting is changed in web.xml files.
Some web applications that require the setting to be off even when the
default is on are okay.

3. I asked Hans for a confirmation that my understanding of his replies
is correct. He has not replied.

4. If there are no further objections, then we can proceed with
implementing the design.

-Adrian


On 9/19/2011 10:23 AM, Adrian Crum wrote:

Hans,

We can document the behavior in the properties file, and we have this
discussion on record to describe the behavior and the reason why it
was done that way. I believe those things will help avoid confusion in
the future.

So, can we implement the behavior I described? I believe you already
answered this question, but I am asking again just to be sure.

-Adrian

On 9/19/2011 10:14 AM, Hans Bakker wrote:

If i use the widget comments option i want it to be generally applied
and taken away depending on the properties setting. I do not want to
find out that somewhere it is not following the setting, then have to
dig in the code and find out that is, because somebody put an
undocumented override somewhere by default as happened the first time.
Bird and google checkout is fine.

I think how it is implemented now is fine. I hope i commented now
enough?

Regards,
Hans

On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:

Hans,

Jacques gave some examples of where an override is currently used and
why it is needed. Could you give us another reason besides i think an
override is an overkill - like a reason based on a design issue or a
real-world problem?

-Adrian

On 9/19/2011 7:55 AM, Hans Bakker wrote:

I as sorry i do not see the problem here.

as long as the properties setting in the trunk will show or hide all
widget comments (so in the trunk NO override) then it is fine.

why? because i think an override is an overkill anyway

Regards,
Hans


On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:

Yes, but I guess we will set widget.verbose in the properties file
to true (as we do for all defaults to be dev friendly). Will that
suit Hans? Else why do you Hans ask for now overriding in web.xml?
For instance what for Birt by defaut? Why not keeping the example
in example component commented out? Waht for testtools? Not sure
why it's false in googlecheckout but I guess there is a reason..

In other word I guess Hans expect widget.verbose in the properties
file to be false...

Jacques

From: Adrian Crumadrian.c...@sandglass-software.com

Let's see if we can bring this to a happy ending.

If the widget.verbose setting in the properties file is false,
then it overrides any other setting and all boundary comments are
shut off.

If the widget.verbose setting in the properties file is true,
then it follows the previous pattern, where true is the default, but
it can be overridden in web.xml and in the context Map.

Will that work for everyone?

-Adrian

On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:

I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments
should be output specific (i.e no output for CSV etc...) instead of
always rendering as html comments.
As regards the logic to determine if comments should be enabled
or not, I don't have a strong opinion because I have always used
this feature in a very rough way (enable all or disable all);
however I can understand the we may want to avoid that (when
widget.properties.enableBoundaryComments == false) the comments
are enabled by passing a URL parameter to the screen.

Kind regards,

Jacopo

On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:


Someone I work with suggested:

I have to point out though that I kind of agree with the way
David put it in that the false setting could have a priority,
i.e. it's like in security permissions where deny has
precedence

Re: widgetVerbose

Sorry my English Adrian, as usual, every change in the system you make
as difficult as possible, technically you are very good and from that
point of view happy to have you in the community, but communication and
consideration of end users, no one is perfectso sure (that means
YES) you can go ahead.

Regards
Hans

On Tue, 2011-09-20 at 02:21 +0100, Adrian Crum wrote:
 Thank you Hans, but repeating your confusing replies does not make them 
 any clearer.
 
 I need a simple yes or no answer: May we implement the design I proposed?
 
 -Adrian
 
 On 9/20/2011 2:17 AM, Hans Bakker wrote:
  Ok Adrian, at least for the third time: (five times in a different
  wording)
 
  what i wrote?
 
  as long as the properties setting in the trunk will show or hide all
  widget comments (so in the trunk NO override) then it is fine.
  Regards,
  Hans
 
 
  On Tue, 2011-09-20 at 02:10 +0100, Adrian Crum wrote:
  Thank you everyone for your patience and comments during this
  discussion. I believe we are near a resolution.
 
From my perspective, this is where we stand:
 
  1. I proposed the following design based on David's suggestion:
 
  If the widget.verbose setting in the properties file is false, then it
  overrides any other setting and all boundary comments are
  shut off.
 
  If the widget.verbose setting in the properties file is true, then it
  follows the previous pattern, where true is the default, but
  it can be overridden in web.xml and in the context Map.
 
  2. Hans is willing to accept the design, as long as there are no
  undocumented surprises where the setting is changed in web.xml files.
  Some web applications that require the setting to be off even when the
  default is on are okay.
 
  3. I asked Hans for a confirmation that my understanding of his replies
  is correct. He has not replied.
 
  4. If there are no further objections, then we can proceed with
  implementing the design.
 
  -Adrian
 
 
  On 9/19/2011 10:23 AM, Adrian Crum wrote:
  Hans,
 
  We can document the behavior in the properties file, and we have this
  discussion on record to describe the behavior and the reason why it
  was done that way. I believe those things will help avoid confusion in
  the future.
 
  So, can we implement the behavior I described? I believe you already
  answered this question, but I am asking again just to be sure.
 
  -Adrian
 
  On 9/19/2011 10:14 AM, Hans Bakker wrote:
  If i use the widget comments option i want it to be generally applied
  and taken away depending on the properties setting. I do not want to
  find out that somewhere it is not following the setting, then have to
  dig in the code and find out that is, because somebody put an
  undocumented override somewhere by default as happened the first time.
  Bird and google checkout is fine.
 
  I think how it is implemented now is fine. I hope i commented now
  enough?
 
  Regards,
  Hans
 
  On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
  Hans,
 
  Jacques gave some examples of where an override is currently used and
  why it is needed. Could you give us another reason besides i think an
  override is an overkill - like a reason based on a design issue or a
  real-world problem?
 
  -Adrian
 
  On 9/19/2011 7:55 AM, Hans Bakker wrote:
  I as sorry i do not see the problem here.
 
  as long as the properties setting in the trunk will show or hide all
  widget comments (so in the trunk NO override) then it is fine.
 
  why? because i think an override is an overkill anyway
 
  Regards,
  Hans
 
 
  On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
  Yes, but I guess we will set widget.verbose in the properties file
  to true (as we do for all defaults to be dev friendly). Will that
  suit Hans? Else why do you Hans ask for now overriding in web.xml?
  For instance what for Birt by defaut? Why not keeping the example
  in example component commented out? Waht for testtools? Not sure
  why it's false in googlecheckout but I guess there is a reason..
 
  In other word I guess Hans expect widget.verbose in the properties
  file to be false...
 
  Jacques
 
  From: Adrian Crumadrian.c...@sandglass-software.com
  Let's see if we can bring this to a happy ending.
 
  If the widget.verbose setting in the properties file is false,
  then it overrides any other setting and all boundary comments are
  shut off.
 
  If the widget.verbose setting in the properties file is true,
  then it follows the previous pattern, where true is the default, but
  it can be overridden in web.xml and in the context Map.
 
  Will that work for everyone?
 
  -Adrian
 
  On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
  I am going to feel bad if I don't add my 2 cents to this thread :-)
  I agree with Jacques that the formatting of boundary comments
  should be output specific (i.e no output for CSV etc...) instead of
  always rendering as html comments.
  As regards the logic to determine if comments should be enabled
  or not, I don't have a

Re: widgetVerbose


Thank you Hans.

I will work on the proposed design and get it committed. If there are 
any issues with the commit, I hope we can discuss them here and not 
engage in a commit war.


-Adrian


On 9/20/2011 2:31 AM, Hans Bakker wrote:

Sorry my English Adrian, as usual, every change in the system you make
as difficult as possible, technically you are very good and from that
point of view happy to have you in the community, but communication and
consideration of end users, no one is perfectso sure (that means
YES) you can go ahead.

Regards
Hans

On Tue, 2011-09-20 at 02:21 +0100, Adrian Crum wrote:

Thank you Hans, but repeating your confusing replies does not make them
any clearer.

I need a simple yes or no answer: May we implement the design I proposed?

-Adrian

On 9/20/2011 2:17 AM, Hans Bakker wrote:

Ok Adrian, at least for the third time: (five times in a different
wording)

what i wrote?


as long as the properties setting in the trunk will show or hide all
widget comments (so in the trunk NO override) then it is fine.

Regards,
Hans


On Tue, 2011-09-20 at 02:10 +0100, Adrian Crum wrote:

Thank you everyone for your patience and comments during this
discussion. I believe we are near a resolution.

   From my perspective, this is where we stand:

1. I proposed the following design based on David's suggestion:

If the widget.verbose setting in the properties file is false, then it
overrides any other setting and all boundary comments are
shut off.

If the widget.verbose setting in the properties file is true, then it
follows the previous pattern, where true is the default, but
it can be overridden in web.xml and in the context Map.

2. Hans is willing to accept the design, as long as there are no
undocumented surprises where the setting is changed in web.xml files.
Some web applications that require the setting to be off even when the
default is on are okay.

3. I asked Hans for a confirmation that my understanding of his replies
is correct. He has not replied.

4. If there are no further objections, then we can proceed with
implementing the design.

-Adrian


On 9/19/2011 10:23 AM, Adrian Crum wrote:

Hans,

We can document the behavior in the properties file, and we have this
discussion on record to describe the behavior and the reason why it
was done that way. I believe those things will help avoid confusion in
the future.

So, can we implement the behavior I described? I believe you already
answered this question, but I am asking again just to be sure.

-Adrian

On 9/19/2011 10:14 AM, Hans Bakker wrote:

If i use the widget comments option i want it to be generally applied
and taken away depending on the properties setting. I do not want to
find out that somewhere it is not following the setting, then have to
dig in the code and find out that is, because somebody put an
undocumented override somewhere by default as happened the first time.
Bird and google checkout is fine.

I think how it is implemented now is fine. I hope i commented now
enough?

Regards,
Hans

On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:

Hans,

Jacques gave some examples of where an override is currently used and
why it is needed. Could you give us another reason besides i think an
override is an overkill - like a reason based on a design issue or a
real-world problem?

-Adrian

On 9/19/2011 7:55 AM, Hans Bakker wrote:

I as sorry i do not see the problem here.

as long as the properties setting in the trunk will show or hide all
widget comments (so in the trunk NO override) then it is fine.

why? because i think an override is an overkill anyway

Regards,
Hans


On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:

Yes, but I guess we will set widget.verbose in the properties file
to true (as we do for all defaults to be dev friendly). Will that
suit Hans? Else why do you Hans ask for now overriding in web.xml?
For instance what for Birt by defaut? Why not keeping the example
in example component commented out? Waht for testtools? Not sure
why it's false in googlecheckout but I guess there is a reason..

In other word I guess Hans expect widget.verbose in the properties
file to be false...

Jacques

From: Adrian Crumadrian.c...@sandglass-software.com

Let's see if we can bring this to a happy ending.

If the widget.verbose setting in the properties file is false,
then it overrides any other setting and all boundary comments are
shut off.

If the widget.verbose setting in the properties file is true,
then it follows the previous pattern, where true is the default, but
it can be overridden in web.xml and in the context Map.

Will that work for everyone?

-Adrian

On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:

I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments
should be output specific (i.e no output for CSV etc...) instead of
always rendering as html comments.
As regards the logic to determine if comments should be

[jira] [Commented] (OFBIZ-4430) Replace OFBiz HttpClient either by org.apache.commons.httpclient.HttpClient or rewrite it using NIO

2011-09-19 Thread BJ Freeman (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-4430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13108329#comment-13108329
 ] 

BJ Freeman commented on OFBIZ-4430:
---

in current httpClient.sendHttpRequest()
   while ((line = post.readLine()) != null) {
if (Debug.verboseOn() || debug) Debug.log([HttpClient] :  + 
line, module);
buf.append(line);
if (lineFeed) {
buf.append(\n);
}
}
//have to set org.ofbiz.base.util.URLConnector.close() to protected.
//add the following line. 
con.close();//sent request got back response so close connection.


 Replace OFBiz HttpClient either by org.apache.commons.httpclient.HttpClient 
 or rewrite it using NIO
 ---

 Key: OFBIZ-4430
 URL: https://issues.apache.org/jira/browse/OFBIZ-4430
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
Reporter: Jacques Le Roux
 Fix For: SVN trunk


 The main problem with current implementation is that it does not handle 
 connections release. You must rely on the SO to release them (timeout).
 Related thread: http://markmail.org/message/qgmdgqqxakio6fja

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: svn commit: r1171093 - in /ofbiz/trunk/applications: accounting/servicedef/ order/src/org/ofbiz/order/order/ product/script/org/ofbiz/shipment/issuance/ product/script/org/ofbiz/shipment/receipt/